Chaîne décisionnelle coûteuse dans les systèmes d’IA

Les coûts en ligne augmenteront. Dans de nombreux cas, ce n’est pas seulement le prix unitaire symbolique qui coûte cher, mais également le même type de problèmes qui doivent être vérifiés à plusieurs reprises. En apparence, vous pourriez penser que vous achetez un service d’inférence, mais en réalité, vous achetez un système dont le comportement peut changer à tout moment. Si quelque chose ne va pas, vous ne pourrez pas produire une chaîne complète de preuves.

C’est pourquoi je me méfie de plus en plus de l’algorithme “AI unit = token”.

Pour le même appel, la différence entre reproductible et non reproductible détermine ce qui doit être payé dans la série suivante de coûts d’ingénierie, de coûts de révision et de coûts de conformité.

Comment les choses sont devenues incontrôlables

Au début, notre analyse des coûts était très simple et tous les comptes pouvaient être placés sur une seule ligne :

-Prix unitaire du jeton

• Nombre de jetons d’entrée et de sortie
• Volume d’appel

Une fois le rapport rédigé, il est très beau, avec une courbe claire de réduction des coûts, et peut même dire au monde extérieur « de combien le coût unitaire a baissé ».

Le véritable problème est survenu la deuxième semaine après le lancement.

Le personnel du service client a commencé à signaler : « Parfois, on peut répondre correctement à la même question, et parfois, on peut y répondre de manière incorrecte. » Le produit demandait : « Le modèle se détériore-t-il ? » Notre première réaction a été de regarder la version modèle, mais il s’est avéré que la version modèle n’a pas été déplacée.

Ensuite, nous avons regardé le mot d’invite, et le mot d’invite n’a pas bougé.

En parcourant le journal plus loin, j’ai découvert que cette demande passait en fait par un routage multi-modèle, touchant différents modèles de différents fournisseurs, et que les appels d’outils étaient incohérents. Ce qui est encore plus terrible, c’est que le journal à ce moment-là n’enregistrait que la « sortie finale » et n’enregistrait pas les raisons de la décision de routage à ce moment-là, ni n’enregistrait l’instantané de contexte.

Ce genre de problème deviendra donc une impasse de dépannage très typique :

• Ne peut pas être reproduit
• Ne peut être attribué
• Je ne peux que deviner

Il y a généralement deux résultats approximatifs, tous deux faux :

1. Attribuez le problème au « caractère aléatoire du modèle », puis utilisez le refroidissement et la punition pour le supprimer.
2. Attribuez le problème au « le mot d’invite n’a pas été bien écrit », puis commencez à empiler les instructions jusqu’à ce que le mot d’invite devienne un autre système incontrôlable.

Ces deux approches rendront le token plus cher sur le compte, mais ne rendront pas le système plus contrôlable.

Ce type de coût va exploser le budget

Le coût du token est linéaire : un appel qui coûte 10 % de plus coûte probablement en réalité 10 % de plus.

Le coût de la non-reproductibilité est exponentiel car il va amplifier le processus de traitement de chaque problème en ligne :

• Le temps de dépannage est passé de 30 minutes à 3 heures car la même requête ne peut pas être rejouée localement.
• Les décisions de restauration sont plus lentes car on ne sait pas quel modèle de restauration, quelle route de restauration ou quel outil de restauration.
• La collecte de preuves de conformité devient difficile car il est impossible de répondre « pourquoi cette conclusion a été émise à ce moment-là et sur quelles données elle était fondée ».
• Les coûts de retouche deviennent plus élevés car les correctifs doivent être effectués en « ajoutant plus de garde-corps », mais le garde-corps lui-même nécessite également un entretien.

Le plus caché est qu’ils sont souvent obligés d’investir beaucoup de ressources d’ingénierie dans la « stabilisation du comportement en ligne » au lieu d’investir dans « l’amélioration des capacités ».

Cela montre également que de nombreuses équipes s’efforcent de plus en plus de maintenir un système de règles complexe. En fin de compte, ils n’économisent pas d’argent et ne deviennent pas plus intelligents.

En quoi dois-je recalculer les unités d’IA ?

Si vous ne comptez que les « unités IA » comme jetons, vous optimiserez souvent un tas de stratégies très dangereuses :

• Pour économiser de l’argent, effectuez un routage et des déclassements plus agressifs.
• Pour économiser de l’argent, déplacez plus de logique dans les invites et les outils.
• Afin d’économiser de l’argent, laissez plus de jugements au modèle pour qu’il « décide automatiquement ».

Ceux-ci poussent le système dans le sens de « l’irreproductibilité ».

Je préfère diviser les unités IA en deux parties :

1. Unité d’inférence : jeton, délai, débit.
2. Unité de preuve : quel est le coût de traçabilité requis pour une décision.

L’unité de raisonnement résout “combien ça coûte de fonctionner”.

L’unité des preuves se penche sur « combien cela coûte-t-il si quelque chose ne va pas ».

Le plus cher est souvent le deuxième.

Une chaîne décisionnelle reproductible, du moins à quoi elle devrait ressembler

Je le considère comme un “grand livre”, et chaque requête doit pouvoir enchaîner des nœuds clés.

Au moins ces types de champs sont obligatoires. Si l’un d’entre eux manque, le lien sera rompu lors d’une sorte d’accident :

• Décision de routage : quel modèle est touché, pourquoi, quels sont les candidats et s’il doit être rétrogradé.
• Version du mot d’invite : système + développeur + numéro de version du modèle, paramètres clés.
• Context Snapshot : participez au résumé des résultats de recherche générés, à la version du document et aux résultats de filtrage des autorisations.
• Chaîne d’appel d’outils : quels outils sont appelés, quels sont les paramètres d’entrée, ce qui est renvoyé et combien de temps cela prend.
• Sortie et post-traitement : sortie finale, résultats de la règle de filtrage, motifs de rejet (si rejet).

Je ne considère délibérément pas le “contexte du texte intégral” comme un élément obligatoire ici, car de nombreux scénarios ne peuvent pas être enregistrés ou les risques de non-conformité sont trop importants s’ils sont enregistrés.

Mais assurez-vous au moins qu’il peut être rejoué selon le « même chemin de décision » si nécessaire.

Les malentendus les plus courants

Malentendu 1 : S’appuyer sur la température pour supprimer le hasard

Le hasard n’est pas le problème central.

Le vrai problème est le suivant : je ne peux même pas expliquer d’où vient cette sortie. Abaisser la température ne fait que « ressembler davantage à une boîte noire stable ».

Malentendu 2 : Traitez l’invite comme le centre de configuration

Lorsque l’invite contient de plus en plus de règles métier, il ne s’agit plus d’un mot d’invite, mais d’une « configuration d’exécution » sans système de types, sans tests et sans mécanisme de restauration.

Cela fera monter directement l’unité de preuve.

Malentendu 3 : mémorisez uniquement le résultat final, pas le chemin intermédiaire

Le simple fait de se souvenir du résultat équivaut à transformer le dépannage en « deviner ».

De nombreux problèmes en ligne sont causés par une certaine erreur d’appel d’outil, une certaine erreur de recherche ou une certaine erreur de rétrogradation d’itinéraire. Si vous n’enregistrez pas le chemin, vous pourrez toujours déduire le résultat, et l’inférence rétrospective ne peut généralement pas être effectuée.

Limites applicables

Tous les systèmes ne nécessitent pas un registre complet pour chaque demande.

J’utiliserai trois conditions pour décider d’inclure ou non des unités de preuve :

• Ce résultat entrera-t-il dans la boucle fermée de l’entreprise (affectant les transactions, les approbations, le contrôle des risques et les engagements externes) ?
• Si ces résultats peuvent être tenus responsables par les utilisateurs ou par des audits externes.
• Une fois que ce résultat est erroné, le coût de la réparation est-il supérieur au coût d’une inférence ?

Si deux des trois conditions sont remplies, je considérerai la « chaîne de décision reproductible » comme la première priorité du contrôle des coûts.

Résumé

Le jeton est un coût explicite et la non-récurrence est une taxe implicite.

Un système d’IA véritablement rentable transforme chaque comportement en ligne en une chaîne de preuves traçable.

Ce qui est épargné, ce sont ces nuits lors du prochain accident.