Les LLM ne sont pas des solutions miracles : repensez leur usage

Les limites des LLM dans la résolution de problèmes complexes

Dans le cadre d'un projet ambitieux, j'ai entrepris de transformer un ensemble complexe de 100 PDF de conformité en règles JSON structurées. L'idée initiale était simple : confier cette tâche à un agent capable de traiter le texte source, de comprendre la mission, et de générer les règles attendues. Cette approche, bien que directe, a rapidement montré ses limites.

À première vue, les résultats semblaient prometteurs. Le JSON produit était valide et conforme aux attentes initiales. Cependant, une vérification minutieuse a révélé des failles importantes. Certaines règles étaient trop générales, d'autres manquaient de précision, et certaines ne respectaient pas les subtilités du texte original. J'ai tenté d'utiliser un autre agent pour corriger ces erreurs, mais la tâche s'est avérée trop vaste pour garantir une vérification exhaustive.

Cette expérience a mis en lumière la fragilité de cette méthode. Les erreurs étaient souvent subtiles et difficiles à détecter, rendant cette approche peu viable à grande échelle. Bien que je ne puisse pas partager les détails techniques de l'implémentation, les leçons tirées de cette expérience pourraient être précieuses pour ceux qui cherchent à développer des systèmes d'IA robustes et évolutifs.

Réduire la complexité pour améliorer les résultats

Après plusieurs tentatives, j'ai compris que l'amélioration ne résidait pas dans un meilleur prompt ou un outil plus sophistiqué, mais dans la redéfinition du problème lui-même. Au lieu de chercher à rendre l'agent plus intelligent, j'ai réduit la complexité de sa tâche.

Le premier ajustement a été de préparer les données en amont. Plutôt que de laisser l'agent naviguer dans une base de données pour récupérer les informations nécessaires, j'ai opté pour une approche plus contrôlée en stockant temporairement les données pertinentes localement. Bien que cette méthode ne soit pas toujours applicable, elle réduit l'incertitude liée à la récupération des données.

J'ai également simplifié la tâche de l'agent en éliminant les métadonnées et autres informations superflues avant de lui soumettre le contenu brut. Cette réduction du contexte non pertinent a permis de diminuer les distractions et de clarifier la tâche de raisonnement.

Le changement le plus significatif a été de traiter les documents de manière itérative, un par un, plutôt que de tout gérer en une seule fois. Cette méthode a rendu chaque tâche plus petite, plus facile à vérifier et à corriger. J'ai mis en place cinq sous-agents pour traiter les documents en parallèle, chacun enregistrant ses progrès individuellement. Si un document échouait, je pouvais réessayer uniquement ce document. De plus, si une sortie présentait des problèmes de formatage, je pouvais corriger ce cas spécifique sans relancer l'ensemble du lot. Le pipeline était conçu pour reprendre à partir du dernier point de contrôle réussi, grâce à la mise en cache des progrès.

Une meilleure gestion des responsabilités

La séparation des responsabilités est devenue essentielle. L'agent était chargé du travail sémantique : comprendre le contenu, identifier les parties pertinentes, et générer la sortie JSON. Le code environnant, quant à lui, gérait les aspects mécaniques : paralléliser les tâches, faire respecter le schéma, générer des identifiants, écrire des fichiers, et valider les références.

Un orchestrateur surveillait l'ensemble du processus, assurant une gestion fluide et efficace des tâches. Cette approche a permis de rendre le système plus fiable, non pas en perfectionnant l'agent, mais en structurant le flux de travail pour faciliter la traçabilité, la validation et la récupération des sorties.

Améliorer l'auditabilité des résultats

Pour rendre la sortie plus facilement vérifiable, j'ai ajouté des ID de référence à chaque règle générée. Chaque élément de sortie pouvait ainsi être relié à une source spécifique, facilitant l'audit. Plutôt que de se demander si une règle générée était correcte, il était possible de vérifier si le texte source cité existait réellement.

Cette méthode a également permis de faire appel à un autre agent pour effectuer des audits sélectifs sur des documents plus complexes, garantissant ainsi la préservation des nuances importantes. J'ai également mis en place une version allégée des évaluations en testant un petit lot de documents bruts pour vérifier manuellement la couverture et l'exactitude des résultats.

Une leçon sur l'utilisation des LLM

L'enseignement principal de cette expérience est qu'il ne faut pas considérer les LLM comme des solutions complètes. Le système est devenu plus fiable non pas parce que l'agent est devenu parfait, mais parce que le flux de travail a été structuré pour rendre ses sorties plus faciles à tracer et à valider.

Cette réflexion a été renforcée lors de ma participation à la conférence inaugurale AI Engineer Singapore, qui s'est tenue du 15 au 17 mai 2026. Lors de cet événement, JJ Geewax, Directeur de l'IA appliquée chez Google DeepMind, a souligné la nécessité de cesser d'utiliser les LLM comme des solveurs de problèmes universels.

Pour des systèmes de production fiables, une approche hybride est souvent la meilleure. Laissez l'agent gérer les tâches nécessitant un jugement sémantique, tandis que le code s'occupe des aspects structurels, de validation et de contrôle.

Je partagerai bientôt d'autres réflexions sur cette conférence et les ateliers auxquels j'ai assisté. En espérant que cet article vous ait été utile, à bientôt pour de nouvelles découvertes.