L'IA opérationnelle : pourquoi elle échoue malgré des modèles avancés

Les défis persistants de l'IA opérationnelle

Dans le domaine de l'intelligence artificielle, il arrive fréquemment qu'un modèle de langage de grande taille (LLM) produise des résultats qui semblent impeccables à première vue. Cependant, lorsque ces résultats sont intégrés dans un système opérationnel, des problèmes surgissent. Les champs sont présents, la structure est correcte, et les valeurs semblent plausibles, mais quelque chose ne fonctionne pas. Cela peut être un type de données incorrect, un champ manquant, ou une valeur qui, bien que techniquement correcte, est contextuellement inappropriée. Ces problèmes ne sont pas dus à des défauts des modèles eux-mêmes, mais à des lacunes dans l'architecture des systèmes. Tant que ces questions ne seront pas traitées comme des problèmes d'architecture, elles persisteront.

La majorité des discussions autour de ces problèmes sont menées par des ingénieurs pour d'autres ingénieurs, se concentrant sur des solutions techniques comme le réglage fin des modèles, l'optimisation des prompts, et l'infrastructure de déploiement. Bien que ces outils soient réels et utiles, ils ne sont pas toujours accessibles à ceux qui en ont besoin, notamment les chefs de projet et les responsables des opérations. Ces derniers, bien qu'ils ne construisent pas directement des produits d'IA, cherchent à intégrer l'IA dans leurs flux de travail existants pour en améliorer l'efficacité.

Pour ces professionnels, les défis apparaissent sous un angle différent. Les modes d'échec qu'ils rencontrent ne sont pas ceux que l'on trouve dans les manuels techniques sur les LLM. L'architecture qui fonctionne dans la pratique ne ressemble souvent pas à celle décrite dans les tutoriels standards.

Comprendre les erreurs de l'IA opérationnelle

Le problème fondamental n'a jamais été un manque d'intelligence des systèmes, mais plutôt une mauvaise compréhension de la nature des tâches opérationnelles. Avec l'accessibilité croissante des LLM, l'idée était que ces systèmes, capables de comprendre le langage et de raisonner, pourraient résoudre les problèmes opérationnels. Cependant, ces problèmes ne sont pas liés au raisonnement, mais à la répétabilité. Les opérations nécessitent que la même entrée produise systématiquement la même sortie. Lorsque l'IA commence à raisonner de manière créative sur des tâches comme le traitement des remboursements ou la mise à jour des enregistrements, la confiance dans les résultats est compromise.

Les LLM sont intrinsèquement non déterministes, ce qui signifie qu'une même question posée deux fois peut générer deux réponses différentes, toutes deux correctes mais jamais identiques. Cette variabilité est acceptable pour un assistant conversationnel, mais problématique pour des systèmes nécessitant une exécution fiable et répétable. Dans un environnement où les résultats doivent être exacts et conformes à des normes précises, cette variabilité devient une incompatibilité structurelle.

La plupart des démonstrations montrent comment construire un outil qui fonctionne en isolation, prenant une entrée et produisant une sortie qui semble correcte à l'écran. Cependant, elles ne montrent pas ce qui se passe lorsque cette sortie doit être intégrée dans un autre système, une base de données, ou un processus en aval qui attend une structure spécifique. À ce stade, la sortie n'est plus évaluée sur son apparence correcte, mais sur sa conformité exacte aux attentes du système récepteur.

Les limites de l'automatisation pure

Face à l'imprévisibilité des LLM, une solution apparente serait de revenir à des systèmes basés sur des règles explicites, avec des sorties prévisibles. Ces systèmes fonctionnent bien tant que le monde reste inchangé. Cependant, le monde évolue constamment, et les systèmes basés sur des règles deviennent rapidement obsolètes. Les formats d'entrée, les noms de champs, et la structure des données sont conçus pour une version du monde qui change dès que l'automatisation est mise en place. Lorsque ces changements surviennent, le système ne s'adapte pas et finit par se briser.

Un autre problème est le coût de la maintenance. Chaque exception aux règles nécessite une intervention humaine, suivie d'une mise à jour des règles, de tests, et d'un déploiement. Ce processus devient rapidement une charge de travail considérable, transformant la gestion du processus en une tâche à part entière. Ce qui manque dans ce processus est le jugement humain, cette capacité à gérer des situations inattendues avec discernement, que ni l'automatisation pure ni les LLM ne peuvent remplacer.

Vers une architecture hybride

La solution ne réside pas dans l'amélioration des LLM, mais dans une meilleure répartition des responsabilités entre les différents systèmes. Les LLM et les systèmes déterministes échouent pour des raisons opposées, et la clé est de comprendre quelle partie du problème chaque outil est le mieux à même de résoudre. Les LLM excellent dans la conversion de l'ambiguïté en structure, transformant des entrées désordonnées en sorties normalisées. Ce processus est crucial mais ne constitue pas la solution complète.

Les systèmes déterministes, quant à eux, sont parfaits pour l'exécution. Avec une entrée structurée, ils peuvent exécuter la même opération de manière répétée et fiable. Cette prévisibilité est leur force et ce qui les rend fiables à grande échelle. Le modèle hybride propose donc de placer chaque système là où il est le plus efficace : les LLM pour structurer les données et les systèmes déterministes pour l'exécution répétable.

En conclusion, pour que l'IA opérationnelle réussisse, il est essentiel de repenser l'architecture des systèmes en intégrant les forces des LLM et des systèmes déterministes. Cette approche hybride pourrait bien être la clé pour surmonter les échecs actuels de l'IA dans les opérations.