Pour de nombreuses entreprises, la promesse des informations basées sur l’IA se heurte à un mur structurel. Bien que la Retrieval-Augmented Generation (RAG) soit devenue la norme pour connecter les grands modèles linguistiques (LLM) aux données privées, elle s’avère de plus en plus inadaptée aux questions commerciales complexes et réelles.
Une nouvelle recherche de Databricks suggère que la limitation ne réside pas dans l’intelligence des modèles eux-mêmes, mais plutôt dans l’architecture utilisée pour les interroger. L’étude met en évidence un changement crucial : l’abandon de la récupération en un seul tour vers des workflows agents en plusieurs étapes.
Le problème des « données hybrides »
La plupart des business intelligence nécessitent de connecter deux mondes différents :
1. Données structurées : Chiffres précis, chiffres de ventes et tableaux relationnels (SQL).
2. Données non structurées : Avis clients, articles universitaires et documents d’assistance.
Un système RAG standard est conçu pour ce dernier. Il excelle dans la recherche de texte qui « ressemble » à une requête, mais il a du mal à effectuer des filtres mathématiques précis ou à joindre des données dans différents formats.
“RAG fonctionne, mais il n’est pas évolutif”, déclare Michael Bendersky, directeur de recherche chez Databricks. “Si vous voulez comprendre pourquoi vos ventes diminuent, vous devez aider l’agent à voir les tableaux et à examiner les données de ventes. Votre pipeline RAG deviendra incompétent pour cette tâche.”
Architecture vs Intelligence : l’écart de 21 %
Pour prouver que le problème réside dans la manière dont les données sont accessibles plutôt que dans l’intelligence du modèle, Databricks a mené une série de tests à l’aide du benchmark STaRK (couvrant les produits Amazon, Microsoft Academic Graph et les données biomédicales).
Ils ont comparé un système RAG monotour de pointe et hautement performant à une approche agentique en plusieurs étapes. Même en utilisant un modèle de fondation beaucoup plus solide, le système RAG à un tour a perdu :
* 21% dans le domaine académique.
* 38% dans le domaine biomédical.
Cet écart de performances démontre que même le modèle le plus « intelligent » ne peut pas compenser une architecture de récupération qui est fondamentalement incapable de combler le fossé entre une feuille de calcul et un document texte.
Comment fonctionne l’”Agent Superviseur”
La solution de Databricks, le Supervisor Agent, s’éloigne de l’idée de « récupération hybride » (essayer de fusionner des intégrations et des tables) et traite plutôt le problème comme une orchestration d’outils. L’agent fonctionne à travers trois fonctionnalités principales :
- Décomposition par outils parallèles : Au lieu d’une recherche massive, l’agent déclenche simultanément des requêtes SQL pour les nombres et des recherches vectorielles pour le texte. Il analyse ensuite les résultats combinés pour former une réponse cohérente.
- Auto-correction : Si une recherche initiale ne donne aucun résultat, comme la recherche d’un auteur spécifique avec un nombre de publications précis, l’agent n’abandonne pas. Il reformule la requête, effectue un « JOIN » SQL et vérifie le résultat via une seconde recherche.
- Configuration déclarative : contrairement aux pipelines traditionnels qui nécessitent que les ingénieurs « aplatissent » ou normalisent les données en morceaux de texte, cet agent utilise des descriptions en langage clair. Pour ajouter une nouvelle source de données, un ingénieur décrit simplement la nature des données ; l’agent apprend à l’utiliser.
Le passage de l’ingénierie à la configuration
Les implications pour l’ingénierie des données sont importantes. Dans une configuration RAG traditionnelle, chaque nouvelle source de données nécessite une énorme quantité de « plomberie de données » : conversion de JSON, normalisation des tables et gestion des intégrations. Cela crée un goulot d’étranglement qui s’accentue à mesure que l’entreprise se développe.
L’approche agent inverse ce modèle : “Amenez simplement l’agent aux données.”
Points clés à retenir pour la mise en œuvre :
- Évolutivité : Le modèle agentique est plus durable pour les ensembles de données croissants, car l’ajout d’une source est une tâche de configuration et non une tâche de codage.
- Limites de complexité : Bien que puissante, l’approche fonctionne mieux avec 5 à 10 sources de données. Connecter trop de sources contradictoires à la fois peut dégrader la vitesse et la fiabilité.
– Intégrité des données : Même si l’agent peut naviguer dans différents formats, il ne peut pas corriger les « déchets entrants et sortants ». Les données sources doivent être factuellement exactes pour que l’agent soit efficace.
Conclusion
La transition de RAG vers des agents multi-étapes représente une évolution fondamentale dans l’IA d’entreprise : passer de systèmes qui se contentent de trouver des informations à des systèmes capables de raisonner à travers divers écosystèmes de données. En traitant les sources de données comme des outils plutôt que comme de simples morceaux de texte, les entreprises peuvent enfin commencer à répondre aux questions complexes et interfonctionnelles qui guident les décisions commerciales.
