Comment utiliser des agents coordonnés pour réduire les coûts de l'IA

Utiliser un modèle frontière comme GPT-5.2 ou Claude 3.5 Opus pour extraire une date d'une facture ou classer un ticket de support est une solution criminalité économique. Vous achetez une fiabilité perçue et vous la payez avec la latence, la consommation de jetons et la dépendance à l'inférence série qui devient un goulot d'étranglement du processus. Lorsque le travail est répétitif et vérifiable, l’omniscience n’est qu’un moyen sophistiqué de dépenser son budget.

Au MIT, CSAIL a développé une alternative qui pourrait devenir une bonne solution technique à ce problème. DisCIPL, dans le journal, est l'acronyme de Contraintes distributionnelles par programmation d'inférence avec des modèles de langage. L'idée centrale est de demander à un modèle très performant d'écrire un programme d'inférence décrivant comment rechercher la solution et de la vérifier, puis de faire exécuter ce programme par une population de petits modèles travaillant en parallèle. Le résultat attendu est un contrôle du respect des contraintes et une utilisation plus rationnelle du calcul.

Comment fonctionne DisCIPL

DisCIPL sépare deux tâches souvent confondues dans les entreprises en matière d'IA : définir le travail et exécuter le travail. La définition de l'ouvrage est confiée à un grand modèle, appelé Planner. Le Planificateur ne produit pas directement la réponse finale, mais rédige un ensemble d'instructions exécutables qui précisent ce qui doit être respecté et comment vérifier qu'il est respecté. Dans l'article, ce jeu d'instructions est appelé programme d'inférence.

L'exécution des travaux est confiée à des petits modèles, appelés Suiveurs. Les abonnés génèrent des propositions de réponse et des parties de réponse en suivant les instructions. Le moteur d'inférence coordonne plusieurs Followers en parallèle, compare les résultats et continue la recherche jusqu'à ce qu'il trouve une sortie qui réussit les vérifications. L’idée clé est que le calcul est transféré vers des essais parallèles bon marché, tandis que le modèle coûteux est utilisé pour écrire les règles et la procédure.

Pour appliquer le cadre dans la pratique, il est donc nécessaire de comprendre si le cas d'utilisation spécifique a des règles vérifiables et s'il existe des marges pour remplacer un seul appel coûteux, qui essaie de tout faire, par une procédure qui guide de nombreuses tentatives économiques et contrôlées.

DisCIPL appliqué dans l'entreprise

Dans l'article et dans les démos citées par le MIT, les contraintes sont des exigences objectives qui peuvent être vérifiées par un test : longueur exacte d'une phrase, mots obligatoires à des positions précises, limite de dépenses dans une liste de courses, nombre de jours dans un itinéraire, nombre maximum de mots dans un texte. Si une réponse ne respecte pas la contrainte, elle se voit immédiatement, sans interprétations.

Dans les applications métiers pratiques, les contraintes sont partout. Une date doit être dans un format valide et plausible. Un montant doit correspondre à la TVA et au total. Un ticket doit aboutir dans une catégorie autorisée par le catalogue, avec des champs obligatoires, peut-être en JSON, peut-être avec un niveau de confiance minimum. Si vous pouvez rédiger le chèque, vous pouvez également créer un système qui élimine automatiquement les mauvaises réponses.

L’avantage économique de l’application de ce système réside dans la manière dont l’inférence est dépensée. Les modèles de raisonnement haut de gamme ont tendance à raisonner en produisant beaucoup de texte intermédiaire, et ce texte coûte de l’argent. DisCIPL déplace une partie de ce travail dans un programme court et des tentatives parallèles sur de petits modèles.

Les résultats du DisCIPL

Le laboratoire de recherche du MIT rapporte que, dans ses expériences, DisCIPL a réalisé un raisonnement 40,1 % plus court et 80,2 % d'économies de coûts par rapport à o1, le modèle OpenAI utilisé comme référence. Il rapporte également que les petits modèles utilisés comme Followers sont 1 000 à 10 000 fois moins chers par jeton que les grands modèles. raisonnement comparable, et que cela permet à des dizaines de modèles de fonctionner en parallèle à faible coût. La dépense devient également plus prévisible, car vous payez avant tout pour la définition de la procédure et beaucoup moins pour l'exploration contrôlée des alternatives.

Le contexte idéal pour DisCIPL est celui des pipelines qui impliquent une génération de texte contrainte, comme une liste de courses avec des budgets et des itinéraires. MIT News mentionne explicitement des tâches telles que liste des ingrédients avec budget, itinéraire de voyage Et propositions de subventions avec des limites de mots, utilisé pour comparer les approches GPT-4o et o1.

Le passage de ces applications de laboratoire vers des applications d’entreprise de gestion des factures et des tickets de support en est une conséquence logique. Cela fonctionne lorsque vous pouvez traduire l’objectif en contrôles clairs.

Une facture, par exemple, permet des contrôles standards : date au format valide, date non future, date cohérente avec l'expiration, montants renvoyés, devise acceptée, champs présents. Le Planificateur peut générer une procédure qui vous indique où chercher les candidats dans le texte et comment les valider. Les adeptes produisent plusieurs hypothèses en parallèle. Le système n'accepte que ce qui réussit les contrôles. Si aucune hypothèse n’est retenue, le système signale une exception au lieu d’inventer une date plausible.

Même un ticket d'assistance permet des contrôles tout aussi standardisés, tels que des catégories finies, des règles de routage, des champs obligatoires, une sortie structurée. Là aussi, l'avantage ne vient pas d'une réponse intelligente au sens générique, mais d'une classification verticale respectueuse des normes et qui passe par une phase d'audit structurée.

Comment adopter DisCIPL

DisCIPL n'est pas un produit prêt à l'emploi et industrialisé. Il s’agit d’un cadre de recherche et surtout d’un modèle reproductible dans des contextes réels. L'adoption en entreprise signifie créer un pipeline dans lequel les contraintes sont formalisées, les contrôles deviennent partie intégrante du processus et le cas d'utilisation est soigneusement choisi.

Le point de départ est d'identifier les processus dans lesquels l'erreur est définie par un test et non par une opinion. Ensuite, nous mesurons combien coûte aujourd’hui l’approche qui utilise un modèle frontière en termes de jetons, de temps, de retraitement et de cas ambigus à l’échelle de l’opérateur. La dernière étape est la discussion pratique de l’architecture à mettre en œuvre. Si le processus est plein d'ambiguïtés invérifiables, DisCIPL perd son avantage car les contrôles n'existent pas ou ne sont pas fiables.