Construire un harnais d'évaluation avant de construire la fonctionnalité

Le plus difficile, quand on met un modèle de langage en production, ce n’est pas le modèle. C’est tout ce qui l’entoure — les relances, les timeouts, la mise en cache, la dérive lente des coûts — qui décide si la chose survit au contact du trafic réel.

La partie que personne ne budgétise

La première chose que je fais désormais, c’est écrire l’évaluation avant la fonctionnalité. Pas une suite exhaustive — juste une douzaine de cas qui encodent ce que « bon » signifie pour cette tâche précise. Ça ressemble à une surcharge inutile jusqu’au jour où une mise à jour du modèle change silencieusement la sortie, et où l’évaluation est la seule chose à le remarquer.

Une checklist avant le lancement

Le coût est une fonction des tokens, et les tokens sont une fonction des décisions que vous prenez dans le code. Le contexte que vous attachez, les relances que vous autorisez, la verbosité que vous réclamez — chacun est une molette, et la plupart des équipes livrent avec toutes les molettes à fond parce que personne n’a regardé.

Je traite chaque réponse du modèle comme non fiable jusqu’à preuve du contraire. Parsez-la, validez-la, et ayez un plan pour le moment où elle ne correspondra pas à la forme attendue — car tôt ou tard ce sera le cas, et le parseur en aval n’a aucun sens de l’humour.

La discipline ennuyeuse

La latence, c’est surtout ce que vous faites pendant que vous attendez. Diffusez en continu quand l’utilisateur lit, parallélisez quand les appels sont indépendants, et mettez en cache les parties qui ne changent pas. La vitesse brute du modèle est la partie que vous contrôlez le moins.

Là où ça casse

La dégradation gracieuse est une décision de conception que l’on prend avant la panne, pas pendant. Décidez maintenant de ce que fait la fonctionnalité quand le modèle est lent, en panne ou dans l’erreur, et la mauvaise journée devient un non-événement au lieu d’un incident.

La première chose que je fais désormais, c’est écrire l’évaluation avant la fonctionnalité. Pas une suite exhaustive — juste une douzaine de cas qui encodent ce que « bon » signifie pour cette tâche précise. Ça ressemble à une surcharge inutile jusqu’au jour où une mise à jour du modèle change silencieusement la sortie, et où l’évaluation est la seule chose à le remarquer.

Rien de tout cela n’est exotique. C’est la plomberie sans gloire qui décide si une fonctionnalité d’IA est un atout ou un fardeau six mois après le billet de lancement. Livrez la plomberie.