Le prochain goulot d’étranglement de l’IA n’est pas le modèle : c’est le système d’inférence

J’ai vu beaucoup de choses lorsque je travaille avec des équipes d’IA d’entreprise : elles blâment presque toujours le modèle lorsque quelque chose ne va pas. C’est compréhensible, mais c’est aussi souvent incorrect et cela finit par s’avérer assez coûteux.

Le scénario habituel est le suivant. Les résultats sont incohérents ; quand quelqu’un en parle, la première réaction est de blâmer le modèle. Cela peut nécessiter davantage de données d’entraînement, une autre exécution de réglage précis ou un modèle de base différent. Après des semaines de travail, la problématique reste la même ou n’a que légèrement changé. Le véritable problème, qui réside souvent dans la couche de récupération, la fenêtre contextuelle ou la manière dont les tâches étaient acheminées, n’a jamais été examiné.

J’ai vu cela se produire tellement de fois auparavant que je pense que cela vaut la peine d’en parler.

Le réglage fin est utile, mais il est surutilisé

Dans de nombreux cas, cela vaut la peine de procéder à quelques ajustements. Si une adaptation de domaine, un alignement de tonalité ou un étalonnage de sécurité sont nécessaires, cela doit faire partie du flux de travail. Je ne dis pas que vous ne devriez pas l’utiliser.

Le problème est que c’est la réponse automatique à n’importe quel problème, même si ce n’est pas l’outil approprié. En partie parce que j’ai l’impression que c’est une chose productive à faire. Vous commencez un travail de mise au point, quelque chose se passe clairement, et il y a un avant et un après. Il semble que vous résolvez le problème alors que ce n’est pas le cas.

Un exemple de ceci est un système d’analyse de contrat, que j’observais en train de déboguer une équipe. Les résultats n’étaient pas fiables pour des documents complexes, et l’idée initiale était que le modèle manquait de capacités de raisonnement juridique. Ils ont donc effectué plusieurs itérations de réglage. Le problème n’a pas disparu. Finalement, quelqu’un a remarqué que la couche de récupération effectuait les mêmes récupérations plusieurs fois et les ajoutait à la fenêtre contextuelle. Le modèle tentait de traiter un grand nombre de textes de faible valeur répétés encore et encore. Ils ont ajusté le classement de récupération et introduit la compression du contexte, et cela est finalement devenu bien meilleur.

Le modèle lui-même n’a jamais été modifié. Et c’est un phénomène assez courant.

Que se passe-t-il au moment de l’inférence

Pendant longtemps, l’inférence n’était que l’étape où l’on utilisait le modèle. C’est à l’entraînement que toutes les décisions intéressantes ont été prises. Cela change maintenant.

L’une des raisons à cela est que certains modèles ont commencé allouer plus de calcul à la génération plutôt que de l’intégrer au processus de formation. Un autre facteur est que la recherche a démontré que des comportements tels que l’auto-vérification ou la réécriture d’une réponse peuvent être appris grâce à l’apprentissage par renforcement. Tous deux ont souligné l’inférence elle-même comme un endroit où les performances pourraient être améliorées.

Ce que je vois maintenant, c’est que les équipes d’ingénierie commencent à traiter l’inférence comme quelque chose que vous pouvez réellement concevoir, plutôt que comme une simple étape fixe que vous acceptez. Quelle profondeur de raisonnement cette tâche nécessite-t-elle ? Comment est gérée la mémoire ? Quelle est la priorité de la récupération ? Ce sont de vraies questions plutôt que des défauts auxquels vous ne pensez pas.

Le problème de l’allocation des ressources

Ce qui est souvent sous-estimé, c’est que la plupart des systèmes d’IA utilisent une approche uniforme pour toutes leurs requêtes. Une seule question concernant l’état du compte suit le même processus qu’un processus de conformité en plusieurs étapes, avec des informations à rapprocher dans plusieurs documents contradictoires. Le même coût, le même processus, le même calcul.

Cela ne semble pas avoir beaucoup de sens quand on y pense. Dans toutes les autres applications d’ingénierie, les ressources seraient allouées en fonction du travail requis. Certaines équipes commencent à le faire avec l’IA, en transférant des inférences plus légères vers des charges de travail plus légères et en acheminant les calculs plus lourds vers des tâches qui en ont réellement besoin. Les aspects économiques s’améliorent et la qualité des tâches les plus difficiles s’améliore également, puisque vous ne manquez plus de ressources.

Ces systèmes comportent plus de niveaux que ce que les gens pensent

Aujourd’hui, lorsque vous examinez l’intérieur d’un système d’IA de production, il ne s’agit généralement pas d’un seul modèle répondant à des questions. Elle s’accompagne souvent d’une étape de récupération, d’une étape de classement, éventuellement d’une étape de vérification, et d’une étape de synthèse ; plusieurs étapes en tandem pour générer le résultat final. Il ne s’agit pas seulement de la capacité du modèle sous-jacent, mais également de la manière dont tous ces éléments s’assemblent pour produire le résultat.

Si le classement de récupération n’est pas correctement calibré, il produira des résultats similaires aux erreurs de modèle. Une fenêtre contextuelle qui peut s’agrandir sans restriction affectera subtilement la qualité du raisonnement, mais rien n’échouera évidemment. Il s’agit de problèmes systémiques, et non de problèmes de modèle, et ils doivent être résolus par une réflexion systémique.

Un exemple pratique de ce type de réflexion est le décodage spéculatif. Le concept est qu’un modèle plus petit génère des résultats candidats et qu’un modèle plus grand les vérifie. Cela a commencé comme une optimisation de la latence, mais c’est en réalité un exemple de répartition du raisonnement sur plusieurs composants plutôt que d’attendre qu’un seul modèle fasse tout. Deux équipes utilisant le même modèle de base mais des architectures d’inférence différentes peuvent aboutir à des résultats très différents en production.

La mémoire devient un véritable problème

Des fenêtres contextuelles plus grandes ont été utiles, mais au-delà d’un certain point, plus de contexte n’améliore pas le raisonnement ; ça le dégrade. La récupération devient plus bruyante, le modèle suit moins efficacement et les coûts d’inférence augmentent. Les équipes qui gèrent l’IA à grande échelle consacrent du temps réel à des tâches telles que l’attention paginée et la compression du contexte, dont il n’est pas passionnant de parler mais qui sont très importantes sur le plan opérationnel.

L’idée est d’avoir le bon contexte, mais pas trop, et de bien le gérer.

Emporter

La sélection du modèle compte moins qu’avant. Des modèles de base performants sont désormais disponibles auprès de plusieurs fournisseurs, et les écarts de capacités se sont réduits pour la plupart des cas d’utilisation. Ce qui détermine réellement la réussite d’un déploiement, c’est l’infrastructure autour du modèle, la manière dont la récupération est ajustée, la manière dont le calcul est alloué et la manière dont le système gère les cas extrêmes au fil du temps.

Les équipes qui seront en bonne position dans quelques années sont celles qui traitent l’architecture d’inférence comme quelque chose qui mérite d’être conçu avec soin, plutôt que de supposer qu’un modèle suffisamment bon réglera tout le reste. D’après mon expérience, ce n’est généralement pas le cas.