LLMOps & evaluation

La démo qui passe et le produit qui échoue

Début 2024, Air Canada a perdu une affaire devant une juridiction de petites crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →éances qui devrait terrifier tout CDO pilotant de l'IA génératives. Un passager en deuil a interrogé le chatbot du site de la compagnie sur les tarifs de deuil. Le bot a inventé avec assurance une politique qui n'existait pas, a dit au client qu'il pouvait demander un remboursement de façon rétroactive, et le tribunal a tenu la compagnie responsable de ce que son bot avait dit. Le chatbot avait presque certainement passé sa démo interne. Il répondait avec aisance. Il avait l'air utile. Il se trompait d'une manière que personne n'avait testée.

C'est la tromperie centrale des systèmes à base de LLMLLMUn Large Language Model est un système d'IA entraîné sur d'énormes volumes de texte pour prédire et générer du langage, ce qui permet de rédiger, résumer ou répondre à des questions.Voir la définition complète → : l'aisance se fait passer pour l'exactitude. Un modèle classique qui classe mal une transaction échoue bruyamment et de façon mesurable. Un LLM échoue *de manière persuasive*. Il produit une réponse assurée, grammaticale, plausible, qui est subtilement ou catastrophiquement fausse, et il le fait de façon non déterministe : le même prompt peut passer mardi et échouer jeudi.

Vous savez déjà monter du MLOpsMLOpsMachine Learning Operations : combinaison des pratiques ML et DevOps pour industrialiser, déployer, monitorer et réentraîner les modèles de façon fiable en production.Voir la définition complète → pour un classifieur : versionner le modèle, monitorer le drift, réentraîner selon un calendrier. Ce playbook ne se transpose pas proprement. Le LLMOps est une discipline différente parce que les modes de défaillance sont différents, les entrées sont du langage naturel non borné, et la « vérité terrain » relève souvent du jugement. Le plus dur dans votre programme GenAI n'est pas de construire le pilote. C'est de prouver que le pilote est digne de confiance, et de construire la machinerie qui continue de le prouver après le lancement. Cette machinerie, c'est ce que cette leçon rend concret.

Pourquoi l'évaluation est le goulot d'étranglement, pas le modèle

Le réflexe de la plupart des équipes est de s'obséder sur le choix du modèle et le prompt engineeringprompt engineeringLe prompt engineering consiste à concevoir et affiner des instructions textuelles pour guider les grands modèles de langage vers des réponses justes, pertinentes et fiables.Voir la définition complète →. C'est le travail visible et amusant. Mais si 80 % des pilotes GenAI s'arrarrL'Annual Recurring Revenue (ARR) est le revenu normalisé et prévisible qu'une entreprise par abonnement attend de ses contrats actifs sur une année.Voir la définition complète →êtent avant la production, c'est parce que personne n'a construit un moyen crédible de répondre à la question que votre conseil posera : *« Comment savons-nous que ça marche ? »*

Demandez-vous ce que « marcher » signifie pour un assistant support augmenté par retrieval. Il y a au moins quatre dimensions distinctes, et elles s'arbitrent entre elles :

• Exactitude, la réponse est-elle factuellement juste au regard de vos documents sources ?
• Groundedness (fidélité), la réponse reste-t-elle ancrée dans le contexte récupéré, ou hallucine-t-elle au-delà ?
• Pertinence, répond-elle effectivement à ce que l'utilisateur a demandé ?
• Sécurité/conformité, évite-t-elle les contenus interdits, les fuites de PII, les conseils non autorisés ?

Un chiffre d'exactitude unique ne peut pas capturer cela. Et contrairement à un classifieur, vous ne pouvez pas calculer ces dimensions par une simple comparaison de labels, parce qu'il n'existe pas une seule chaîne correcte. « Votre remboursement sera traité sous 5 à 7 jours ouvrés » et « Comptez une semaine pour votre remboursement » sont tous deux corrects.

D'où la séparation de la discipline en deux régimes, que le CDO doit financer tous les deux :

L'évaluation offline tourne sur un eval set curé et versionné avant toute mise en production. L'évaluation online mesure le comportement face au trafic réel et imprévisible. Les équipes qui ne font que de l'offline se font surprendre par les requêtes qu'elles n'avaient jamais imaginées. Celles qui ne surveillent qu'en ligne volent sans check pré-vol. Il vous faut les deux, et elles utilisent des outils différents.

Construisez le golden eval set d'abord, avant le pilote

L'artefact le plus à effet de levier de tout votre programme GenAI n'est pas le modèle. C'est le golden evaluation set : une collection curée d'entrées représentatives associées à des comportements attendus, des critères notés et des cas limites connus. C'est un actif data que vous possédez, que les concurrents ne peuvent pas acheter, et qui prend de la valeur avec le temps.

Un eval set sérieux, ce n'est pas 20 questions tapées par un ingénieur un vendredi. Il s'assemble délibérément :

1. Exploitez les intentions réelles. Récupérez les requêtes historiques réelles, les tickets support, les logs de recherche, les transcriptions d'agents. Si vous êtes avant lancement, faites-les écrire par des experts métier. Stratifiez par fréquence pour que les cas courants soient pondérés correctement.
2. Sur-échantillonnez volontairement la queue de distribution. Les défaillances qui créent du risque juridique et réputationnel vivent dans les cas limites : prompts adverses, questions ambiguës, demandes hors périmètre (« Puis-je avoir un conseil médical ? ») et tentatives de prompt injection.
3. Attachez des attentes notées, pas seulement des réponses. Pour chaque item, précisez ce qu'une bonne réponse doit contenir, ne doit pas contenir, et comment elle doit se comporter (par exemple « doit citer la source de la politique », « doit refuser et escalader »).
4. Versionnez-le comme du code. L'eval set vit dans votre dépôt, est revu à chaque modification, et chaque release de modèle ou de prompt est scorée contre une version figée afin de comparer ce qui est comparable.

Une cible pratique : 200 à 500 items curés pour un premier pilote en production, à enrichir en continu à mesure que la production révèle de nouveaux modes de défaillance. Chaque défaillance réelle devient un nouveau cas de test permanent. C'est ainsi que l'actif se capitalise.

Noter à l'échelle : LLM-as-judge, utilisé honnêtement

Le problème évident : qui note 500 réponses ouvertes à chaque fois que vous ajustez un prompt ? La revue humaine ne tient pas la vitesse d'itération dont vous avez besoin. La réponse désormais standard est le LLM-as-judge, un modèle puissant qui score les sorties contre vos critères.

Ça fonctionne, mais seulement si vous traitez le juge avec le même scepticisme que n'importe quel autre instrument de mesure. Le juge a ses propres biais : il favorise les réponses longues, il préfère les réponses qui collent à son propre style, et il peut être contourné. La discipline consiste à calibrer le juge contre des labels humains. Faites noter manuellement par vos experts métier un échantillon de quelques centaines de sorties, puis mesurez l'accord entre votre juge LLM et eux. Si l'accord juge-humain est élevé, vous pouvez lui faire confiance pour passer à l'échelle. S'il est faible, votre prompt de juge doit être retravaillé avant que vous ne vous appuyiez dessus.

Un prompt de juge doit forcer une décision structurée fondée sur une grille, plutôt qu'une vague impressionimpressionLe nombre total de fois qu'une publicité ou un contenu est affiché, indépendamment des clics. Chaque affichage compte pour une impression, même auprès de la même personne.Voir la définition complète → de qualité :

You are evaluating a support answer for GROUNDEDNESS.
Context provided to the assistant:
{retrieved_context}
User question: {question}
Assistant answer: {answer}

Score groundedness 1-5:
5 = every claim is directly supported by the context
1 = answer contains claims not present in the context
Return JSON: {"score": int, "unsupported_claims": [..], "reasoning": "..."}

Notez que cela oblige le juge à *énumérer* les affirmations non étayées. Cette structure améliore l'exactitude et donne à votre équipe une sortie débogable : vous voyez *pourquoi* quelque chose a mal scoré, pas seulement qu'il a mal scoré.

GuardrailsGuardrailsRègles et contrôles qui maintiennent un système d'IA dans des limites sûres, légales et conformes à la marque, en bloquant les sorties et actions hors cadre.Voir la définition complète → : la couche runtime entre le modèle et l'utilisateur

L'évaluation vous dit comment le système se comporte globalement. Les guardrails sont les contrôles en temps réel qui contraignent chaque réponse individuelle avant qu'elle n'atteigne un utilisateur ou n'agisse sur un système. Voyez l'évaluation comme votre processus qualité et les guardrails comme vos disjoncteurs.

Les guardrails opèrent à deux endroits, et les systèmes mûrs utilisent les deux :

Les guardrails d'entrée filtrent ce qui entre dans le modèle : détection de prompt injection (« ignore tes instructions et… »), filtrage des PII avant qu'elles n'atteignent une APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → tierce, et classification de la demande pour savoir si elle est même dans le périmètre. Une question médicale hors périmètre adressée à un bot bancaire doit être attrapée ici, pas traitée.

Les guardrails de sortie filtrent ce qui revient : vérification des hallucinations contre les sources récupérées, blocage des contenus toxiques ou non conformes, validation du format de réponse, et, point critique dans les secteurs régulés, application de l'obligation que certaines réponses incluent des avertissements ou déclenchent une escalade humaine.

La décision d'architecture que le CDO doit prendre porte sur la localisation de la responsabilité. Ne laissez pas les ingénieurs applicatifs bricoler un filtre regex et appeler ça de la gouvernance. Les guardrails doivent être une couche de service partagée, détenue centralement, de sorte que votre politique sur le traitement des PII ou le refus de conseil médical soit définie une fois et appliquée de façon cohérente dans chaque application GenAI de l'entreprise. C'est le moment où votre mandat de gouvernance existant devient du code exécutable. La politique que rédige votre comité de gouvernance doit se traduire en un guardrail que quelqu'un peut appliquer et auditer.

Voilà l'arbitrage qui fait trébucher les équipes : les guardrails ajoutent de la latence et du coût, car chaque vérification est souvent un appel de modèle supplémentaire. Un guardrail de validation de sortie agressif peut doubler votre temps de réponse. Vous ferez des compromis explicites : des vérifications légères sur chaque requête et une vérification coûteuse seulement sur les intentions à haut risque. Ce risk-tiering est une décision de CDO, pas une pensée d'après-coup d'ingénierie.

Monitoring : la confiance est une propriété d'exécution, pas un jalon de lancement

L'hypothèse la plus dangereuse en GenAI est que réussir l'évaluation offline vous accorde une confiance permanente. Faux. Les systèmes à base de LLM se dégradent d'une manière que les classifieurs ne connaissent pas. Votre fournisseur met silencieusement à jour le modèle sous-jacent. Les comportements utilisateurs évoluent et envoient des requêtes que votre eval set n'a jamais couvertes. Votre propre corpus de retrieval devient obsolète à mesure que les documents changent. Un système scoré à 92 % au lancement peut dériver discrètement à 70 % sans aucun changement de code de votre côté.

Le monitoring en production n'est donc pas de la télémétrie optionnelle, c'est le mécanisme par lequel la confiance est *maintenue*. Un CDO doit exiger que la stack de monitoring capte quatre couches :

• Métriques système, latence (en particulier le time-to-first-token, qui pilote la qualité perçue), coût par requête, débit, taux d'erreur. Le coût GenAI est variable et peut s'envoler ; non surveillée, une seule intégration qui déraille peut brûler six chiffres en un week-end.
• Signaux de qualité, un échantillon glissant de réponses de production scorées par votre juge LLM contre les mêmes grilles qu'en offline. C'est ainsi que vous détectez le drift.
• Taux de déclenchement des guardrails, à quelle fréquence chaque guardrail se déclenche. Un pic soudain de blocages de prompt injection signifie que vous êtes attaqué ; un pic de refus « hors périmètre » signifie que les utilisateurs veulent quelque chose que vous ne proposez pas, ce qui est de l'intelligence produit.
• Retours utilisateurs, pouces haut/bas, taux d'escalade vers un humain, abandon de conversation. Le taux d'escalade est souvent votre proxy de qualité le plus honnête.

La discipline opérationnelle qui relie le tout est une boucle de feedback : chaque défaillance de production signalée est triée, et les vraies défaillances sont promues dans le golden eval set. C'est le flywheel. Votre eval set s'enrichit précisément là où la réalité vous a donné tort, et la release suivante est testée contre la défaillance exacte qui vous a embarrassé la fois précédente. Un programme GenAI sans cette boucle n'est pas un produit ; c'est une démo en sursis.

Le rythme opérationnel que le CDO doit installer

Concrètement, voici la cadence à mettre en place avant qu'un pilote ne passe en production :

• Gate de pré-déploiement : aucune release ne part sans avoir été scorée contre le golden eval set figé et sans franchir un seuil défini sur chaque dimension, exactitude, groundedness, sécurité. Cette gate n'est pas négociable et est détenue par une personne nommée.
• Déploiement canary : les nouveaux modèles ou prompts vont d'abord sur une petite tranche de trafic, avec des scores de qualité online comparés à l'existant avant le déploiement complet. Traitez un changement de modèle comme un déploiement de code, car c'en est un.
• Revue qualité hebdomadaire : une réunion récurrente où produit, data et risque passent en revue les métriques de drift, les taux de déclenchement des guardrails et les nouveaux cas d'eval promus. C'est là que la dégradation est attrapée avant qu'un client ne l'attrape.
• Playbook d'incident : un chemin défini pour revenir en arrière sur une version de prompt ou de modèle en quelques minutes, parce que vous *en aurez* besoin.

Les organisations qui gagnent en GenAI d'entreprise ne sont pas celles qui ont les meilleurs modèles, tout le monde loue les mêmes modèles frontières. Elles gagnent parce qu'elles ont construit la machinerie d'évaluation et de monitoring qui leur permet d'itérer vite *et sûrement*, en livrant des améliorations chaque semaine avec confiance au lieu de livrer un pilote une fois et de prier.

À retenir

1. Financez le golden eval set avant le pilote. C'est votre actif data le plus durable et le plus cumulatif, 200 à 500 cas curés et versionnés qui sur-échantillonnent la queue risquée. Pas d'eval set, pas de production. Traitez-le comme un artefact de niveau conseil d'administration, pas comme une tâche annexe d'ingénierie.
2. Ne faites jamais confiance à un juge non validé. Le LLM-as-judge permet de noter à l'échelle, mais calibrez-le d'abord contre des labels humains et imposez un scoring structuré fondé sur une grille. Un juge non calibré est un menteur assuré qui mesure un autre menteur assuré.
3. Faites des guardrails un service partagé, pas de la plomberie par application. Centralisez les contrôles d'entrée et de sortie pour que votre politique de gouvernance soit appliquée une fois et auditée partout, et hiérarchisez explicitement par le risque les vérifications coûteuses au regard de la latence et du coût.
4. Instrumentez la confiance comme une propriété d'exécution. Surveillez en continu les couches système, qualité, guardrails et retours utilisateurs ; un score du jour du lancement ne veut rien dire trois semaines plus tard, une fois que le fournisseur a mis à jour le modèle ou que le trafic a bougé.
5. Bouclez la boucle ou perdez la guerre. Chaque défaillance réelle en production doit devenir un cas d'eval permanent. C'est ce flywheel, et non le choix du modèle, qui sépare un produit GenAI défendable d'une démo en sursis.