La comptabilité des tokens pour ceux qui détestent les tableurs

Toute fonctionnalité d’IA paraît bon marché dans le prototype et chère sur la facture. L’écart entre ces deux chiffres est fait de détails, et ceci est une note sur les détails.

La part que personne ne budgétise

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 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.

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 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é.

La discipline ennuyeuse

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.

Le déploiement, c’est là que la bonne ingénierie se fait défaire par l’impatience. Derrière un flag, sur une cohorte, avec une métrique à laquelle vous vous fiez et un interrupteur d’arrêt que vous avez réellement testé — c’est la différence entre livrer et parier.

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.