Leçon 5 — Mettre un LLM en production
Le prototype prend quelques jours. La mise en production prend quelques mois. Cette leçon explique où passe la différence.
Le coût : comment il se calcule et comment il dérape
La facturation se fait en tokens d'entrée et tokens de sortie, avec des tarifs différents — la sortie coûte typiquement trois à cinq fois plus cher que l'entrée à l'unité.
L'erreur d'estimation classique est de ne compter que la réponse. Dès qu'on fait du RAG, l'entrée domine largement : cinq passages de 600 tokens, une consigne système de 500 tokens et un historique de conversation, cela fait facilement 4 000 tokens d'entrée pour une réponse de 300 tokens.
Autre effet sous-estimé : dans une conversation, l'historique est renvoyé à chaque tour. Au dixième échange, vous payez dix fois le début de la conversation.
Les leviers, par ordre d'efficacité :
Choisir un modèle plus petit là où il suffit. C'est le levier le plus puissant, et de très loin. Pour de la classification, de l'extraction, du routage ou de la reformulation, un petit modèle fait aussi bien pour dix à cinquante fois moins cher. Réservez le grand modèle au raisonnement difficile.
Router les demandes. Un classifieur léger en amont oriente les demandes simples vers un modèle économique et les demandes complexes vers un modèle puissant. Sur un trafic réel, la majorité des demandes est simple.
Mettre en cache. Beaucoup de questions se répètent. Un cache sur les réponses fréquentes supprime purement et simplement l'appel. Certains fournisseurs proposent en outre une mise en cache de la partie stable du contexte, ce qui réduit fortement le coût d'entrée des consignes système longues.
Réduire le contexte envoyé. Cinq passages bien choisis valent mieux que vingt passages moyens, coûtent quatre fois moins cher, et donnent souvent une meilleure réponse — le milieu du contexte étant mal exploité, comme vu dans le cours d'IA générative.
Tronquer l'historique. Gardez les derniers échanges et un résumé des précédents, plutôt que l'intégralité.
Un système conçu sans attention au coût dépense couramment dix fois le nécessaire. La différence ne vient pas d'une optimisation fine mais des choix structurels ci-dessus, en particulier le dimensionnement du modèle.
La latence : ce que perçoit l'utilisateur
Deux mesures distinctes, et la seconde compte moins qu'on ne croit.
Le temps jusqu'au premier token détermine le sentiment de réactivité. C'est celui qu'il faut optimiser.
Le débit en tokens par seconde détermine la vitesse d'apparition du texte. Au-delà d'une vingtaine de tokens par seconde, c'est plus rapide que la lecture, donc l'améliorer n'apporte plus rien de perceptible.
Ce qui réduit la latence perçue :
Le streaming, en priorité absolue. Afficher les tokens au fur et à mesure fait passer une réponse de huit secondes pour bien plus rapide qu'une attente de quatre secondes suivie d'un affichage d'un coup. C'est le meilleur rapport effort-résultat de toute cette leçon.
Le parallélisme. Lancez la récupération documentaire et les appels indépendants en parallèle plutôt qu'en série.
Un modèle plus petit, qui produit ses premiers tokens plus vite.
Attention aux agents. Chaque étape ajoute un aller-retour complet. Un agent à huit étapes met dix fois plus de temps qu'un appel simple, et c'est ce qui rend beaucoup d'agents inutilisables en interaction synchrone. Pour ces cas, basculez en traitement asynchrone avec notification.
La sécurité : quatre garde-fous indispensables
Filtrer l'entrée
Ne faites pas confiance à ce qui arrive. Vérifiez la longueur, refusez ce qui sort du périmètre fonctionnel, et balisez explicitement le contenu non fiable — documents, messages d'utilisateurs, pages web — pour le séparer de vos instructions.
Filtrer la sortie
Ne renvoyez jamais directement une sortie de modèle à un autre système. Validez-la contre un schéma avant utilisation. Si vous attendez un JSON avec trois champs, vérifiez-le. Si vous attendez une catégorie parmi cinq, vérifiez qu'elle en fait partie. Un modèle produit occasionnellement du texte hors format, et un système qui ne le prévoit pas plantera.
Contrôler les droits d'accès
Point rappelé de la leçon 3 parce qu'il est le plus souvent négligé : filtrez à la récupération, selon l'identité de l'utilisateur. On ne demande jamais au modèle de garder un secret ; on ne lui donne pas le document.
Limiter les actions
Aucune action irréversible sans validation humaine. Aucun accès en écriture qui ne soit strictement nécessaire. Une liste blanche plutôt qu'une liberté. Une journalisation de tout.
Évaluer un système non déterministe
C'est la difficulté propre aux LLM : la même entrée peut produire des sorties différentes, et il n'existe souvent pas de « bonne réponse » unique.
La base minimale, à mettre en place dès le premier jour :
Un jeu de tests figé de cinquante à deux cents cas, couvrant les demandes courantes, les cas limites, les questions hors périmètre et les questions sans réponse dans votre base. Ce jeu ne change pas, sinon vous ne mesurez plus rien de comparable.
Des critères écrits avant de regarder les sorties. « La réponse cite au moins une source », « la réponse ne contient aucune affirmation absente des passages », « la réponse respecte le format demandé ».
Un passage complet à chaque modification. Consigne, modèle, découpage, réglages : tout changement demande de repasser le jeu entier. Une amélioration sur un cas se paie très souvent par une régression ailleurs, et c'est invisible autrement.
L'évaluation par modèle — utiliser un LLM pour juger les sorties d'un autre — est utile pour passer à l'échelle et comporte des biais connus : préférence pour les réponses longues, pour son propre style, et indulgence générale. Calibrez-la sur un échantillon jugé par un humain avant de lui faire confiance, et ne l'utilisez pas comme unique juge.
En production, suivez ce qui se mesure sans annotation : taux de réponses « je ne sais pas », longueur moyenne des réponses, taux d'échec de validation de schéma, latence, coût par requête, et retours utilisateurs avec un simple pouce en haut ou en bas. Une dérive sur l'un de ces indicateurs précède généralement une dégradation constatée.
Le piège de la version du modèle
Un point pratique qui surprend beaucoup d'équipes : votre système peut se dégrader sans que vous ayez rien changé.
Les fournisseurs mettent à jour leurs modèles. Un modèle plus récent est globalement meilleur et peut être moins bon sur votre cas particulier, notamment parce que vos consignes avaient été ajustées au comportement de l'ancien.
Ce qu'il faut faire : épingler une version précise du modèle plutôt qu'un alias générique, tester toute nouvelle version sur votre jeu figé avant de basculer, et prévoir dans votre planning la migration régulière, parce que les anciennes versions sont retirées.
Les six étapes du prototype à la production
Ce qui sépare la démonstration du service, dans l'ordre où cela se fait :
- Un jeu d'évaluation figé et des critères écrits. Sans cela, tout le reste est de l'opinion.
- La gestion des erreurs : que fait le système quand l'API est indisponible, quand la réponse est hors format, quand la récupération ne trouve rien ? Ces trois cas arriveront.
- Les droits d'accès, filtrés à la récupération.
- L'observabilité : journaliser chaque requête, chaque contexte, chaque réponse, avec le coût et la latence. Sans cela, aucun diagnostic n'est possible.
- Les limites : quota par utilisateur, plafond de dépense, nombre maximal d'itérations.
- La supervision humaine sur les décisions qui comptent, et un chemin de recours pour l'utilisateur.
Le cours MLOps reprend ces dispositifs dans un cadre plus général.
À retenir
- Le coût est dominé par les tokens d'entrée dès qu'on fait du RAG, et l'historique est renvoyé à chaque tour.
- Le levier le plus puissant est de prendre un modèle plus petit là où il suffit ; ensuite, router, mettre en cache, réduire le contexte.
- Le streaming est le meilleur rapport effort-résultat sur la latence perçue.
- Quatre garde-fous : filtrer l'entrée, valider la sortie contre un schéma, filtrer les droits à la récupération, limiter les actions.
- Évaluez sur un jeu figé avec des critères écrits d'avance, repassé intégralement à chaque modification.
- L'évaluation par modèle aide à passer à l'échelle et doit être calibrée sur du jugement humain.
- Épinglez la version du modèle : votre système peut se dégrader sans que vous changiez quoi que ce soit.
Leçon suivante — Récapitulatif, glossaire et FAQ →