Pneuma-Seeker: A Relational Reification Mechanism to Align AI Agents with Human Work over Relational Data

Le papier présente Pneuma-Seeker, un système qui aligne les agents d'IA sur les besoins humains en matière de données relationnelles en représentant l'intention de l'utilisateur sous forme de schéma relationnel évolutif et en l'affinant itérativement pour générer des réponses précises et inspectables, surpassant ainsi les approches basées sur les LLM traditionnels.

L'essentiel

🕵️‍♂️ Le Problème : La demande floue et l'assistant qui hallucine

Imaginez que vous êtes un chef de cuisine (l'utilisateur) et que vous avez un assistant très intelligent mais un peu trop confiant (l'Intelligence Artificielle ou LLM).

Vous lui dites : "Je veux préparer un plat qui utilise des ingrédients dangereux mais qui ne fait pas mal au ventre."

Le problème, c'est que votre demande est floue.

• Qu'entendez-vous par "dangereux" ? Des épices fortes ? Des champignons toxiques ?
• Où sont les ingrédients ? Dans le frigo, au marché, ou dans un autre pays ?

Si vous demandez directement à l'IA de vous donner la recette, elle va probablement inventer des choses. Elle va peut-être vous dire : "Voici un plat avec des champignons de la lune" (hallucination) ou mélanger des ingrédients qui n'existent pas ensemble. C'est ce qu'on appelle la "fragilité" : dès que la demande n'est pas parfaite, l'IA se trompe.

💡 La Solution : Pneuma-Seeker et le "Plan de Construction"

Les chercheurs de l'Université de Chicago ont créé Pneuma-Seeker. Au lieu de demander à l'IA de donner directement la réponse (la recette), ils lui demandent de dessiner un plan de construction précis avant de cuisiner.

Ils appellent cela la "Réification Relationnelle". C'est un mot compliqué pour dire : "Transformer une idée vague en un schéma concret."

L'analogie de l'Architecte et du Maçon

Imaginez que vous voulez construire une maison.

1. L'ancienne méthode (sans Pneuma) : Vous dites à l'architecte (l'IA) : "Je veux une belle maison." Il vous donne directement un dessin final. S'il a mal compris, vous vous retrouvez avec une maison sans toit.
2. La méthode Pneuma-Seeker : Vous dites à l'architecte : "Dessine-moi d'abord le plan des fondations, puis celui des murs, et enfin le toit."
   • L'architecte vous montre un plan (le schéma relationnel).
   • Vous regardez et dites : "Attends, j'ai dit 'belle', pas 'en bois'. Et pour les fondations, il faut du béton, pas du sable."
   • L'architecte corrige le plan.
   • Une fois le plan validé, l'architecte envoie les ouvriers chercher les bons matériaux et construire la maison.

🛠️ Comment ça marche concrètement ?

Le système fonctionne en trois étapes clés, comme une équipe de détectives :

1. Le Chef d'Orchestre (Conductor) : C'est le manager. Il ne cherche pas les données lui-même. Il écoute votre demande, propose un "plan de données" (quelles colonnes, quels tableaux, comment les relier), et vous demande : "Est-ce que c'est ça que vous voulez ?".

   • Exemple : Vous voulez savoir si les produits dangereux coûtent plus cher. Le chef propose un tableau avec "Type de produit" et "Prix". Vous dites : "Non, il faut séparer les produits radioactifs des autres." Il corrige le plan.

2. Le Chasseur (Retriever) : Une fois le plan validé, ce chasseur va chercher les bons documents (les tableaux de données) dans l'immense bibliothèque de l'entreprise. Il ne lit pas tout, il va chercher exactement ce qui correspond au plan.

3. Le Constructeur (Materializer) : Il prend les documents trouvés et les assemble selon le plan. Il utilise des outils précis (comme des formules Excel ou du code) pour créer le tableau final.

   • Le petit secret : Si le constructeur a un doute (par exemple : "Est-ce que cette colonne contient vraiment des années 2025 ?"), il peut lancer un petit test automatique pour vérifier avant de continuer. Cela évite les erreurs.

🌟 Pourquoi c'est génial ? (Les avantages)

• On ne se trompe plus sur l'objectif : Au lieu de deviner ce que vous voulez, le système vous montre son interprétation sous forme de tableau. Vous pouvez dire "Non, ce n'est pas ça" avant qu'il ne perde du temps.
• C'est transparent (Inspectable) : Si le système vous donne un chiffre, vous pouvez voir exactement d'où il vient. C'est comme avoir la facture détaillée d'un restaurant : vous savez quel ingrédient a été utilisé et comment il a été cuisiné.
• C'est robuste : Même si les données sont mal rangées ou très volumineuses, le système sait comment les trier et les assembler sans s'épuiser.

🏁 En résumé

Pneuma-Seeker, c'est comme passer d'un chat avec un ami qui devine (souvent faux) à un travail avec un architecte rigoureux.

Au lieu de demander une réponse magique, vous construisez ensemble le plan de la réponse. Vous validez le plan, vous corrigez les détails, et ensuite le système exécute le travail. Cela rend l'intelligence artificielle plus fiable, plus honnête et beaucoup plus utile pour les gens qui travaillent avec des données complexes.

C'est la différence entre demander "Dis-moi la vérité" et dire "Montre-moi comment tu as trouvé la vérité, et je te dirai si je suis d'accord."

Résumé technique

1. Problématique et Contexte

Les travailleurs des données (analystes, ingénieurs, experts métier) font face à un défi majeur : l'articulation imprécise de leurs besoins en information. Souvent, les requêtes initiales sont vagues, évolutives et difficiles à opérationnaliser pour un système logiciel.

Bien que les Grands Modèles de Langage (LLM) puissent interpréter le langage naturel, ils échouent souvent lorsque l'intention est sous-spécifiée. Ils tendent à :

• Halluciner des champs de données manquants.
• Supposer des chemins de jointure incorrects.
• Produire des réponses plausibles mais non fondées sur les données réelles.

Les workflows actuels de découverte et de préparation de données sont manuels, coûteux en temps et nécessitent une coordination inter-équipes importante. Les systèmes existants (catalogues de données, outils BI) aident à la visibilité mais ne résolvent pas le problème de la traduction d'un besoin flou en une structure de données exécutable.

Le problème central est donc de concevoir un système capable d'aider l'utilisateur à converger vers une intention précise tout en découvrant et préparant automatiquement les données nécessaires, sans que l'utilisateur n'ait à décrire parfaitement le besoin dès le départ.

2. Méthodologie : La Réification Relationnelle

L'idée centrale de Pneuma-Seeker est la réification relationnelle. Au lieu de répondre directement à une requête textuelle, le système représente le besoin d'information évolutif de l'utilisateur comme un schéma relationnel concret (un modèle de données prêt à l'analyse).

Le Concept de $(T, S)$

Le système décompose la réponse en deux artefacts explicites :

1. $T$ (Tableaux Cibles) : Un ensemble de vues dérivées (tables) qui contiennent les attributs, types et sémantiques nécessaires.
2. $S$ (Transformation Exécutable) : Un programme (SQL ou Python) qui transforme les sources brutes en $T$ pour produire la réponse finale.

Ce schéma devient un artefact partagé entre l'humain et la machine :

• Pour l'utilisateur : Il peut inspecter le schéma proposé, critiquer les hypothèses (ex: "le champ 'dangereux' est trop large, utilisez 'radioactif'") et itérer.
• Pour le système : Il a une cible claire à atteindre (matérialiser $T$ et exécuter $S$), ce qui réduit les hallucinations et permet une traçabilité complète (provenance).

Architecture Agente et Gestion du Contexte

Pneuma-Seeker utilise une architecture multi-agents orchestrée par un Conductor (chef d'orchestre), reposant sur deux stratégies de gestion de contexte :

1. Gestion Macro-Contextuelle :

   • Décomposition du flux de travail en trois composants spécialisés pour réduire la charge de contexte de chaque agent :
     • Retriever : Découvre les tables pertinentes dans un corpus hétérogène.
     • Materializer : Construit les tables $T$ à partir des sources trouvées.
     • Conductor : Orchestre le processus, gère les boucles d'itération et interagit avec l'utilisateur.
   • Cette séparation évite de surcharger le LLM avec tout le corpus de données.

2. Gestion Micro-Contextuelle :

   • Reconnaissant que même les tables récupérées peuvent être trop volumineuses pour le contexte du LLM (ex: 5 millions de lignes), le système permet au LLM d'exécuter des scripts Python pour interroger la base de données à la demande.
   • Le LLM peut poser des questions précises aux données (ex: "Y a-t-il des valeurs nulles dans cette colonne ?", "Quelle est la distribution des années ?") pour valider ses hypothèses avant de construire le schéma final. Cela transforme l'exécution de requêtes en un mécanisme d'acquisition de contexte actif.

3. Contributions Clés

1. Intention Réifiée pour la Découverte de Données : Formalisation de la notion de besoin d'information comme un schéma relationnel itératif, transformant une question "cible mouvante" en un artefact concret vérifiable.
2. Techniques de Gestion de Contexte :
   • Une approche macro (décomposition en agents) standard.
   • Une contribution novatrice en micro-gestion de contexte, permettant aux agents d'interagir dynamiquement avec de grandes bases de données relationnelles via l'exécution de scripts pour obtenir des preuves factuelles.
3. Système Pneuma-Seeker : Implémentation d'un pipeline agentic complet qui découvre, prépare et exécute des programmes sur des données hétérogènes, tout en assurant l'inspectabilité et la traçabilité (via un graphe de provenance).
4. Évaluation et Déploiement : Preuves empiriques de la supériorité du système sur des benchmarks académiques et industriels, couplées à des enseignements tirés d'un déploiement réel au sein de l'Université de Chicago.

4. Résultats de l'Évaluation

Les auteurs ont évalué Pneuma-Seeker sur le benchmark KramaBench (6 domaines : archéologie, astronomie, biomédical, etc.) et comparé les résultats avec des baselines de pointe (DS-Guru, smolagents).

• Qualité des Réponses (RQ1) : Pneuma-Seeker obtient une précision nettement supérieure, en particulier sur les datasets complexes (Biomédical : 94,44% contre ~66% pour les baselines). L'ablation montre que la réification $(T, S)$ et l'extraction de contexte sont les facteurs déterminants de cette performance.
• Coût et Évolutivité (RQ2) :
  • Le système offre un excellent compromis coût/qualité (frontière de Pareto).
  • En termes d'évolutivité, Pneuma-Seeker reste performant sur des jeux de données allant jusqu'à 1,9 Go. Contrairement aux baselines qui chargent toutes les données en mémoire (causant des goulots d'étranglement), Pneuma-Seeker repose sur une exécution basée sur la base de données (DuckDB), limitant l'utilisation mémoire même si le temps d'exécution LLM reste dominant.
• Robustesse (RQ3) : Même avec un LLM plus faible (non raisonneur), Pneuma-Seeker surpasse les autres systèmes, démontrant que l'architecture et la gestion de contexte compensent partiellement les limites du modèle de langage.

Cas d'usage réel : Le déploiement a mis en évidence que la confiance et l'inspectabilité sont des exigences critiques. Les utilisateurs ne font confiance aux résultats que s'ils peuvent voir comment les données ont été assemblées (le schéma $T$ et le code $S$).

5. Signification et Conclusion

Pneuma-Seeker propose un changement de paradigme dans l'interaction homme-machine pour l'analyse de données. Au lieu de demander au LLM de "deviner" la réponse, le système force une négociation explicite de la structure des données avant la génération de la réponse.

• Pour les utilisateurs : Cela réduit le coût de coordination et permet d'affiner progressivement leurs hypothèses.
• Pour les systèmes : Cela aligne l'intention de haut niveau avec les opérations de bas niveau, rendant le processus vérifiable et reproductible.

En conclusion, la réification relationnelle s'avère être une fondation pratique et robuste pour créer des systèmes de découverte et de préparation de données pilotés par l'IA, capables de gérer la complexité et l'ambiguïté inhérentes aux besoins réels des organisations.