LLM en production, partie 1 — la stack honnête
La version conférence d'un produit LLM, c'est un seul appel à GPT-4 avec un prompt astucieux. La version production, c'est quinze briques d'infrastructure, trois fournisseurs, deux bases de données, et une politique de retry qui a pris six semaines à régler. Cette série parle de la deuxième.
Les pièces dont personne ne parle
Construire au-delà du démo signifie posséder, sous une forme ou une autre :
- Un registre de prompts. Les prompts sont du code. Ils ont des versions, ils sont relus, ils sont rollbackables. Si vos prompts vivent comme des chaînes littérales dans votre code applicatif, vous avez un problème de junior déguisé en décision technique.
- Une suite d'évaluation. Sans elle, chaque modification de prompt est une supposition. Avec elle, vous pouvez livrer 20 itérations par semaine en sachant lesquelles ont régressé.
- Un cache de réponses. Même question, même réponse, dix fois moins cher. Le levier numéro un de réduction de coûts pour presque toutes les apps LLM en production.
- Un rate limiter côté entrée. Pas parce que vos utilisateurs vont abuser. Parce que les limites d'OpenAI ne se soucient pas de la forme de votre trafic ; c'est à vous de le modeler.
- Une politique de fallback. Le fournisseur A tombe une fois par trimestre. Le fournisseur B existe. Votre code doit savoir quel template de prompt fonctionne pour les deux.
Où la plupart des équipes sous-investissent
D'après notre expérience, deux zones :
Couverture des évaluations
Les équipes livrent une douzaine de prompts en production avec des suites d'éval à un chiffre chacune. Puis un upgrade de modèle casse la moitié silencieusement parce que la suite ne contenait pas les cas limites importants. Le minimum syndical, c'est 50 exemples par prompt, dont la moitié adverses.
Observabilité des entrées, pas seulement des sorties
Vous instrumentez la latence, le coût en tokens, le statut de la réponse. Vous n'instrumentez pas la distribution des entrées — et c'est là que le drift se cache. Six mois plus tard, le phrasing de vos utilisateurs change ; votre prompt était calibré pour la distribution d'origine ; la qualité se dégrade ; vous n'avez aucun signal.
Ce qu'on va couvrir
La partie 2 de cette série rentre dans les arbitrages entre RAG, fine-tuning, et l'approche prompt-seul — et quand chacun est le bon choix. La partie 3 (un autre article, une autre série) abordera l'orchestration multi-agents, mais c'est un autre bordel.
Le but de cette série n'est pas d'être exhaustif. C'est de court-circuiter quelques-unes des leçons coûteuses qu'on a payées pour que vous n'ayez pas à le faire.
