Pourquoi RAG ne suffit pas : une couche sémantique pour les requêtes graphiques, SQL et vectorielles
RAG échoue sur les questions d’entreprise multi-hop, numériques et ambiguës. Une couche sémantique gère la décomposition, le routage et la mise en correspondance des schémas, avec Apache Ossie pour assurer la portabilité.
Les modèles de langage ont facilité l’expression des questions d’entreprise en termes simples. Obtenir une réponse est une chose, mais comprendre ce que signifie la question dans différents systèmes de données en est une autre. Prenons cet exemple :
Imaginez qu’un analyste demande : quels fonds négociés en bourse possèdent des entreprises qui collaborent stratégiquement avec NVIDIA, gèrent plus d’un milliard de dollars et bénéficient d’une couverture positive dans les dernières notes de recherche ?
Cela ressemble à une seule question, mais elle implique en réalité trois types de tâches :
- NVIDIA, partenaire stratégique, fonds négocié en bourse : représenter les relations sous forme de graphe.
- Montant géré supérieur à 1 milliard de dollars : filtrage numérique précis.
- Recherches récentes positives : interprétation de texte non structuré.
Il y a un problème plus profond en dessous. Que signifie AUM dans le modèle de données sous-jacent, et quelle source en est l’autorité ? Avant qu’un système ne puisse répondre correctement, il doit comprendre le sens des données et pas seulement les données elles-mêmes. L’ingénierie sémantique vise à combler cette lacune.
Où RAG s’arrête
Le pipeline typique de RAG récupère des extraits pertinents et permet au modèle de répondre à partir d’eux. C’est excellent lorsque la tâche consiste à trouver du texte pertinent et à y répondre. Les questions d’entreprise nécessitent souvent plus que de la simple similarité, et la récupération vectorielle pure échoue de quatre manières reconnaissables.
Récupération fragmentée
Imaginez un manuel de produit divisé en trois parties :
Chunk 1: Atlas Enterprise — vendor, category
Chunk 2: Pricing — base fee, usage fee
Chunk 3: Risks — lock-in, migration, data residency
Quelqu’un demande les prix et les risques d’Atlas Enterprise. Le nom du produit ne doit apparaître que dans le premier bloc. Le deuxième et le troisième contiennent la réponse, mais après segmentation ils ne conservent plus le contexte de l’entité. L’enrichissement des métadonnées, la récupération des relations parent-enfant et le réclassement aident tous, mais la fragmentation reste une faiblesse fondamentale.
Aucune navigation entre relations
Demandez maintenant quels ETF possèdent des entreprises partenaires de NVIDIA. Le chemin de raisonnement ne repose pas sur une simple correspondance de mot-clé :
NVIDIA
↓ HAS_STRATEGIC_PARTNER
Company
↓ HELD_BY
ETF
La recherche vectorielle permettra de trouver des documents mentionnant NVIDIA, ses partenaires ou des ETF. Ce qu’elle ne peut pas faire de manière fiable, c’est conclure que ces mentions forment une relation à plusieurs étapes spécifique. Un graphe peut parcourir ce chemin de manière explicite :
?nvidia corp:hasStrategicPartner ?company .
?etf etf:hasConstituent ?company .
Un texte similaire n’est pas identique à une connexion entre des entités.
Ambiguïté des entités
Un nom comme « NVIDIA » peut faire référence à plusieurs choses :
NVIDIA → Company
NVIDIA International → Subsidiary
NVIDIA AI Enterprise → Product
Leurs embeddings peuvent être proches l’un de l’autre, mais il s’agit d’entités différentes de types distincts. Une ontologie fournit l’identité, le type et les relations, ce que la similarité de texte ne peut pas faire.
Aucun filtrage numérique exact
Une requête telle que « clients ayant un chiffre d’affaires annuel supérieur à 1 million de dollars et une probabilité de désabonnement inférieure à 5 % » est simplement du SQL :
SELECT customer_id
FROM customer_metrics
WHERE annual_revenue > 1000000
AND churn_probability < 0.05;
Les embeddings capturent la similarité. Ils ne permettent pas de manière fiable d’effectuer des comparaisons de type plus grand que, plus petit que, entre, d’effectuer des agrégations ou des classements.
Une question, plusieurs moteurs
La question posée nécessite plus d’une stratégie de recherche, et chaque moteur convient à un type différent de raisonnement :
Vector → meaning and unstructured text
BM25 → exact lexical matching
Graph → relationships and multi-hop traversal
SQL → filters, numbers and aggregation
La tâche a cessé d’être une récupération pour devenir une exécution de requête fédérée. La fédération soulève trois problèmes plus difficiles : la décomposition, le routage et la mise en correspondance.
Décomposition
Le système doit diviser la question en langage naturel en unités qu’il peut exécuter :
1. Resolve NVIDIA as a Company
2. Find its strategic partners
3. Find ETFs holding those companies
4. Filter AUM > $1B
5. Retrieve the latest research reports
6. Identify positive views
Acheminement
Chaque unité doit se rendre à la source qui est compétente pour elle :
relationships → Graph
AUM → SQL
research view → Vector Search
Se contenter de relier les bases de données ne suffit pas. Le système doit savoir quelle source répond à quelle partie.
Mappage
C’est souvent la partie la plus difficile. Un utilisateur indique AUM, tandis que la base de données peut contenir des champs tels que ceux-ci :
NET_ASSET_AMT
AUM_USD
FUND_NET_ASSET
Lequel est le concept géré ? De même, un ETF pourrait être fund:ETF dans le graphe, dim_fund.fund_id en SQL et metadata.product_id dans l’index vectoriel. Le système a besoin d’un pont entre le vocabulaire métier et les schémas physiques. C’est ce qu’on appelle l’ancrage des schémas, et sans cela un LLM peut générer du SQL parfaitement crédible concernant des colonnes qui n’existent pas.
La couche sémantique
Une couche sémantique se situe entre ce que les gens entendent et la manière dont les données sont stockées. Au lieu de montrer à un LLM des centaines de tables brutes et de propriétés, on expose des concepts :
Company
Strategic Partner
ETF
Constituent
Assets Under Management
Research Report
et attribuer un sens à chacun :
Assets Under Management
├─ business definition
├─ currency / unit
├─ effective date
├─ authoritative source
└─ physical column
Cette couche peut alors participer directement au cycle de vie de la requête. Cela change la fonction d’une ontologie : elle cesse d’être une documentation statique pour devenir un contexte exécutable pour le système d’intelligence artificielle.
Comment elle pourrait être organisée
Pour un système qui combine une base de données relationnelle, un graphe de connaissances et une recherche vectorielle, la couche pourrait être structurée comme suit :
semantic_layer/
├── ontology/
│ ├── tbox.ttl # classes and relationships
│ └── vocabulary.yaml # business terms and synonyms
├── schemas/
│ ├── rdb.yaml # tables, columns, types
│ ├── graph.yaml # entities, predicates, graph paths
│ └── vector.yaml # indexes and document metadata
├── semantics/
│ ├── metrics.yaml # governed metrics such as AUM
│ ├── mappings.yaml # concept → physical source mapping
│ └── relationships.yaml # cross-domain relationships
├── query/
│ ├── routing.yaml # Graph vs SQL vs Vector routing
│ └── examples.yaml # representative query plans
└── validation/
└── rules.yaml # allowed fields and business rules
Dans cette structure, tbox.ttl est l’endroit où des classes telles que Company et ETF sont déclarées, ainsi que le lien HAS_STRATEGIC_PARTNER entre elles, tandis que rdb.yaml décrit les tables et colonnes réelles. mappings.yaml établit un lien entre le concept d’Actifs gérés et la colonne fund_metrics.net_asset_amt. Enfin, routing.yaml permet au planificateur de décider si une étape doit être envoyée au graphe, à SQL ou à une recherche vectorielle.
Les fichiers exacts dépendent de l’implémentation. Ce qui importe, c’est d’écrire explicitement le sens, les mappages physiques et les chemins d’exécution valides, plutôt que de laisser le LLM les redécouvrir à chaque requête. Quatre tâches en bénéficient directement :
- Désambiguïsation : l’entreprise et les produits portant des noms similaires appartiennent à des classes d’entités différentes.
fund_metrics.net_asset_amt.C’est pourquoi l’ingénierie sémantique va au-delà de la simple création d’une ontologie. L’objectif est de rendre les significations commerciales utilisables en temps réel, grâce à un vocabulaire partagé, une ontologie, des définitions de métriques, des relations, des mappages de schémas, des règles métier, des métadonnées sources et des vérifications de validation. Vu de cette manière, une couche sémantique ressemble bien plus à une étape de compilation pour les données d’entreprise qu’à un simple glossaire.
De la couche au temps de exécution
De nombreux designs d’agents actuels ressemblent à ceci :
User → LLM → Tools
Le LLM reçoit des descriptions d’outils et décide comment les nommer. Une architecture sémantique peut être plus contraignante :
User
↓
Semantic Resolution
↓
Logical Query Plan
↓
Validated Execution
↓
Evidence
↓
LLM
Le modèle n’a pas besoin de deviner comment gérer chaque tableau, chaque métrique, chaque prédicat graphique et chaque règle métier. Il fonctionne au sein d’un environnement sémantique défini. L’objectif est d’améliorer l’interface entre le modèle et les données de l’entreprise, et non simplement de créer un modèle plus volumineux.
Pourquoi un format d’échange ouvert est important
Les définitions sémantiques elles-mêmes ont tendance à se fragmenter. Une entreprise peut définir le chiffre d’affaires net séparément dans sa plateforme de données, son outil de BI, son catalogue, son application d’analyse et son agent d’IA, et avec le temps ces définitions s’éloignent les unes des autres.
Open Semantic Interchange (OSI) a pour but de résoudre ce problème. Cette initiative a rejoint l’Apache Incubator en juin 2026 et continue sous le nom d’Apache Ossie (en incubation). Elle vise à fournir aux systèmes un moyen neutre d’échanger des métadonnées sémantiques. La spécification principale est écrite en YAML et couvre les ensembles de données, les champs, les relations, les métriques et le contexte de l’IA. Un modèle simplifié ressemble à ceci :
version: "0.2.0.dev0"
semantic_model:
- name: investment_products
datasets:
- name: etf
source: analytics.dim_etf
fields:
- name: aum
datatype: Decimal
ai_context:
synonyms: ["assets under management", "net assets"]
metrics:
- name: total_aum
expression:
dialects:
- dialect: ANSI_SQL
expression: SUM(etf.aum)
La syntaxe importe peu. Ce qui compte, c’est que aum dispose d’une définition unique, incluant sa source physique, son type de données, sa logique métrique ainsi que ses synonymes destinés aux systèmes d’IA, et que cette définition est transmise sous forme de métadonnées portables au lieu d’être réécrite dans chaque outil.
┌→ BI
├→ Analytics
Semantic Model ───┼→ AI Agents
├→ Data Catalogs
└→ Data Applications
Un catalogue pourrait afficher la définition officielle et l’historique d’évolution d’AUM, et un agent IA pourrait lire ces mêmes métadonnées pour associer l’expression « actifs gérés » au champ approprié, plutôt que de deviner en se basant uniquement sur des schémas bruts.
En outre, Ossie valide les modèles selon un JSON Schema, permet plusieurs dialectes d’expressions, et définit un modèle de conversion pour passer d’un format à un autre. Les travaux prévus comprennent l’introduction de métriques plus riches, une meilleure composabilité, une intégration avec des catalogues, ainsi que des sémantiques de relations et des représentations ontologiques plus précises.
La direction liée à l’ontologie est particulièrement intéressante pour l’IA, car seules les métriques et les dimensions ne permettent pas à un agent d’obtenir de telles informations.
Customer is an Organization
Company HAS_SUBSIDIARY Company
Company OWNS_PRODUCT Product
Document DESCRIBES Entity
Si les modèles sémantiques et les ontologies plus riches convergent, les systèmes d’IA pourraient recevoir un sens métier portable, et non seulement des schémas portables.
Retour à la question NVIDIA
Un système de requêtes sémantiques peut traiter la question initiale étape par étape, chaque décision étant fondée sur des métadonnées explicites. Sans couche sémantique, le LLM doit inférer le sens, la source, le schéma et les relations à chaque étape, et une seule hypothèse erronée peut briser toute la chaîne.
Le changement plus large
L’IA d’entreprise a évolué à travers plusieurs étapes :
LLM + Prompt
↓
LLM + RAG
↓
LLM + Tools
↓
LLM + Federated Data
↓
Semantic Layer + Federated Execution + LLM
La récupération indique quels documents semblent pertinents. Un graphe montre comment les entités sont liées. SQL précise quels enregistrements répondent à des conditions exactes. La couche sémantique traite la question fondamentale : comment cette question se traduit-elle dans le vocabulaire de nos données ?
Les systèmes continueront d’acquérir des bases de données, des graphes, des documents, des API et des outils, et il ne suffira pas de simplement relier davantage de données. Leur signification doit également être reliée. L’IA d’entreprise pourra moins compter sur l’ajout de données supplémentaires à un modèle et davantage sur lui donner une compréhension claire de ce que ces données représentent.