La mise à jour de modèle qui a discrètement cassé la production

Il y a un moment, une semaine ou deux après le lancement, où les graphiques cessent d’être flatteurs. La fonctionnalité marche encore — en gros. Mais les bords commencent à se voir, et les bords sont là où le vrai travail se trouve.

Une checklist avant le lancement

La première chose que je fais maintenant, c’est écrire l’éval avant la fonctionnalité. Pas une suite exhaustive — juste une douzaine de cas qui encodent ce que « bon » veut dire pour ce travail précis. Ça ressemble à une corvée jusqu’au jour où une mise à jour de modèle change silencieusement la sortie et que l’éval est la seule chose à le remarquer.

La discipline ennuyeuse

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 réessais que vous autorisez, la verbosité que vous demandez — chacun est un curseur, et la plupart des équipes livrent avec tous les curseurs poussés au maximum parce que personne n’a regardé.

Je traite chaque réponse de modèle comme non fiable jusqu’à preuve du contraire. Parsez-la, validez-la, et ayez un plan pour quand elle ne correspond pas à la forme attendue — car un jour elle ne correspondra pas, et le parseur en aval n’a aucun sens de l’humour.

Là où ça casse

La latence, c’est surtout ce que vous faites pendant que vous attendez. Streamez 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 part que vous contrôlez le moins.

Ce que je fais à la place

La dégradation gracieuse est une décision de conception que vous prenez avant la panne, pas pendant. Décidez maintenant de ce que la fonctionnalité fait quand le modèle est lent, hors service ou faux, et la mauvaise journée devient un non-événement plutôt qu’un incident.

La première chose que je fais maintenant, c’est écrire l’éval avant la fonctionnalité. Pas une suite exhaustive — juste une douzaine de cas qui encodent ce que « bon » veut dire pour ce travail précis. Ça ressemble à une corvée jusqu’au jour où une mise à jour de modèle change silencieusement la sortie et que l’éval est la seule chose à le remarquer.

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