Votre logique de retry vous ment
Par Ulrich Dohou, AI Engineer à Paris
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 c’est dans les bords que vit réellement le travail.
La discipline ennuyeuse
La première chose que je fais désormais, c’est d’é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 perte de temps jusqu’au jour où une mise à jour du modèle change silencieusement la sortie, et où l’éval est la seule chose à le remarquer.
Là où ça casse
Le coût est fonction des tokens, et les tokens sont fonction des décisions que vous prenez dans le code. Le contexte que vous attachez, les retries 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 du 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 — parce que tôt ou tard elle n’y correspondra pas, et le parser en aval n’a aucun sens de l’humour.
Ce que je fais à la place
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 ce qui ne change pas. La vitesse brute du modèle est la part que vous contrôlez le moins.
La partie que personne ne budgète
La dégradation gracieuse est une décision de conception qu’on prend avant la panne, pas pendant. Décidez dès maintenant ce que fait la fonctionnalité quand le modèle est lent, indisponible ou faux, et le mauvais jour devient un non-événement au lieu d’un incident.
La première chose que je fais désormais, c’est d’é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 perte de temps jusqu’au jour où une mise à jour du modèle change silencieusement la sortie, et où l’éval est la seule chose à le remarquer.
Rien de tout cela n’est exotique. C’est la plomberie ingrate qui décide si une fonctionnalité IA est un atout ou un passif six mois après le post de lancement. Livrez la plomberie.
Abonnez-vous pour recevoir l'article de vendredi prochain ci-dessous.
Un e-mail · le vendredi · désabonnement à tout moment