· Hernán Pérez Rodal · Engineering · 4 min read
RAG sur 10+ bases de données : ce que la production nous a appris
Pourquoi RAG vector-only ne passe pas à l'échelle en conformité, comment nous avons conçu du retrieval hybride sur plusieurs stores, et les décisions architecturales qui ont fonctionné en production.
TL;DR — En 2026 le consensus est clair : le RAG vector-only ne passe pas à l’échelle en production. Chez Darwin nous avons construit un système agentic de compliance avec retrieval hybride sur 10+ bases de données. Les meilleures décisions que nous avons prises n’ont pas eu à voir avec le modèle, mais avec la couche de données.
Le problème
Notre système agentic de compliance doit répondre à des questions comme :
“Quels lots de mangue du producteur X, traités entre mai et juillet, respectent les CTEs exigés par FSMA 204, et lesquels ont des gaps d’évidence ?”
Une seule question qui combine :
- Connaissance réglementaire (définitions CTE/KDE de FSMA 204 — texte structuré)
- Événements de traçabilité (CTEs enregistrés avec timestamp, géolocalisation, fournisseur, lot)
- Règles métier internes (gap analysis, risk scoring — logique dynamique)
- Relations entre entités (producteur → usine → expédition → détaillant)
Un vector store avec des embeddings de tout mélangé ne sert pas à répondre correctement à ça. La bonne réponse exige join de données structurées + retrieval sémantique + calcul agrégé.
L’architecture
Notre stack de retrieval :
| Source | Type | Usage |
|---|---|---|
| Qdrant | Vector store | Réglementations, doctrine, cas historiques (données non structurées) |
| PostgreSQL | Relationnel | Événements de traçabilité (CTE/KDE avec timestamps, IDs, geo) |
| Firebase/Firestore | Document | Configuration par client, UI state |
| Cloud Storage | Blob | PDFs originaux, audit trails, preuves numériques |
| On-chain (Polygon) | Immutable | Attestations critiques, signatures numériques |
L’agent ne sait pas où vit chaque chose — l’orchestrator le résout.
LangGraph comme orchestrator
Nous utilisons LangGraph pour router les queries en plusieurs étapes :
- Classify — quel type de question c’est (réglementaire / opérationnelle / mixte)
- Plan — quels retrievals sont nécessaires (vector + SQL + graph traversal)
- Fan-out — exécuter les retrievals en parallèle
- Synthesize — passer les résultats au LLM avec contexte structuré
- Validate — guardrails pour prévenir les hallucinations sur données numériques
L’étape clé a été la #2 : donner au LLM un query planner qui décide la stratégie de retrieval avant d’aller chercher. Sans ça, le modèle hallucine des données ou ramène du contexte non pertinent.
Ce qui n’a pas marché
Vector-only avec chunking agressif — notre première tentative. Échec sur deux dimensions :
- Queries de counting / aggregation (combien de lots ? moyenne par semaine ?) — le LLM inventait des chiffres quand il ne les avait pas explicitement en contexte
- Joins relationnels (producteur X + fenêtre temporelle Y + certification Z) — impossible sans query structurée
La solution n’a pas été “meilleur chunking” — ça a été de séparer retrieval sémantique et requêtes structurées.
Ce qui a marché
Query routing explicite → le planner décide si une question exige vector search, SQL, graph traversal ou combinaison.
Guardrails numériques → si la réponse du LLM contient des nombres, nous vérifions qu’ils correspondent à ce que la query structurée a renvoyé. Sinon, on fail fast au lieu de renvoyer des données incorrectes.
Semantic caching au niveau des questions similaires → réduit les coûts de LLM de ~40 % sans impact sur la qualité.
Observabilité full-trace avec OpenTelemetry → chaque query est trackée end-to-end (planner → retrieval → LLM → guardrails). Critique pour le debug.
Lessons learned
- Le goulot d’étranglement du RAG en production n’est pas le retrieval — c’est la décision de quel retrieval utiliser
- Les guardrails numériques sauvent des vies quand la correctness de la réponse affecte des décisions réglementaires
- LangGraph est meilleur que des chaînes linéaires pour orchestrer des retrievals conditionnels
- Multi-store + planner > single vector store avec meilleur chunking
- Les LLMs vont halluciner sur les aggregations structurées — peu importe à quel point le modèle est bon
Et maintenant ?
La prochaine itération est de remplacer certaines règles du planner par un fine-tuning du router avec des exemples réels de production. Le planner comme LLM est flexible mais cher — cacher ses décisions dans un modèle plus petit est un step logique.
Si vous construisez du RAG pour des domaines régulés, mon conseil est : commencez par le query planner, pas par le vector store.
Vous construisez quelque chose de similaire ? Parlons-en — nous sommes ouverts à partager l’architecture et apprendre d’autres cas.
