CoT avec RAG Vector Database VS Chain of Task avec Graph Database
Vous avez mis en place un RAG avec une base vectorielle et vous avez quelques problèmes pour les recherches complexes ?
Comment ça fonctionne ?
- Le RAG vectoriel fait du matching, pas du raisonnement
- CoT, qui représente a priori la technique de raisonnement la plus avancée des LLMs, raisonne de manière implicite, sans garantir une précision de 100 %
- Il existe une alternative plus simple : structurer, classifier et interroger efficacement avec un graph
Regardons comment mettre en place un RAG avec 100% de précision grâce au Chain of Task.
1. Pourquoi le scaling des RAG vectoriels échoue en prod ?
Mettre en place un RAG sur une base vectorielle semble séduisant :
Vous chunkiez votre base documentaire, vous vectorisez, vous interrogez… et ça marche sur vos premiers tests.
Mais la plupart du temps, le scaling ne fonctionne pas, pourquoi ?
IVFFlat (FAISS, ChromaDB, Qdrant) :
– Mauvais nlist (nombre de clusters) → clusters mal séparés.
– Mauvais nprobe (nombre de clusters interrogés) → couverture partielle du top-k.
➔ Résultat : perte de rappel.
HNSW (ChromaDB, Weaviate, Pinecone, Qdrant) :
– Optimisé pour la rapidité, mais sensible aux limites de la géométrie vectorielle.
– La proximité géométrique ne garantit pas la vraie pertinence sémantique.
➔ Résultat : faux positifs, confusion entre notions proches.
Reranker a posteriori :
Le reranker est souvent utilisé pour améliorer la qualité du top-k après la recherche vectorielle.
Cependant, il se heurte à un problème courant lié aux chevauchements entre clusters :
- Plusieurs embeddings très proches, mais appartenant à des clusters différents, se retrouvent dans le top-k initial.
- Le reranker doit alors départager ces résultats, mais il peut se faire piéger par ces overlaps et sélectionner un faux positif comme étant le plus pertinent.
Nous avons même illustré ce problème dans une visualisation montrant comment les zones de chevauchement faussent le reranking et la sélection du top-k.
➔ Résultat : surcoût, latence accrue, et pertinence du top-k dégradée, malgré l’effort de reranking.
2. CoT avec RAG vectoriel
Le Chain of Thought (CoT) consiste à demander au LLM de dérouler son raisonnement pas à pas, plutôt que de répondre directement.
Cela apporte plusieurs avantages :
- Le modèle structure sa réponse en plusieurs étapes logiques.
- Cela améliore la compréhension humaine du raisonnement.
- Cela réduit parfois les erreurs en forçant une vérification intermédiaire.
Mais dans un RAG vectoriel, le CoT est limité par plusieurs facteurs :
Le raisonnement du LLM dépend entièrement des documents extraits en top-k.
➔ Si les documents récupérés sont bruités ou non pertinents, le CoT raisonne à partir de mauvaises bases.
Le modèle ne remet pas en question la pertinence des documents fournis.
➔ Le CoT fait confiance aveuglément aux documents récupérés.
Le contenu injecté dans le prompt (retrieved context) reste figé, même si le modèle détecte une contradiction ou un manque d’information.
Le coût est multiplié :
- d’abord par la recherche vectorielle et le reranking,
- puis par le raisonnement pas à pas, qui augmente le nombre de tokens générés, donc la latence et la facture.
En résumé :
- Le CoT ne compense pas les limites de la recherche vectorielle.
- Il améliore la présentation, mais pas la qualité si le top-k est déjà biaisé.
Vous obtenez un raisonnement plus lisible, mais pas nécessairement plus juste.
3. L’alternative : Chain of Task avec classification et graph
Plutôt que de déléguer le raisonnement au modèle, vous structurez le raisonnement une fois pour toutes.
Le Chain of Task fonctionne en plusieurs inférence, donc fonctionne en plusieurs étapes contrairement au CoT qui déstructure le prompt en plusieurs raisonnements.
Étape 1 – Classification préalable du prompt
Dès la réception du prompt, vous :
– Attribuez des labels métier (intention, domaine, contexte, contraintes, temporalité, etc.)
– Sélectionnez dynamiquement les bons nodes dans le graph, c’est le node qui contient le chunk (plus le node est labellisé, plus il y a de granularité, plus le node est singulier)
Les labels sont hiérarchisés avec une taxonomie à plusieurs niveaux pour mieux structurer l’information.
Même une classification naïve suffit si votre graph est bien structuré.
Résultat : 0 bruit, 100 % de précision, pas de calcul inutile.
Étape 2 – Retrieval contrôlé
Vous contrôlez quoi interroger, comment relier, quoi restituer.
Exemple :
Prompt : « Quels sont les seuils critiques d’un blackout électrique en France ? »
Classification : Seuil critique, Capacité d’équilibrage rapide, Interconnexions pays limitrophes, Charge réseau actuelle, Délai d’ajustement, Absence de black-start, Risque de désynchronisation, Vulnérabilité SCADA, Plage critique de fréquence, Sensibilité climatique.
Comment obtenir cette classification ?
BART, ModernBERT ou Qwen3 0.6
Soit avec du fine-tuning (LoRa) soit avec du prompt-tuning.
Étape 3 – Retrieval des chunks
Retrieval :
- Requête directe sur les labels.
- Navigation des relations interconnexions, réserves, climat.
Les chunks spécifiques sont récupérés. Si des calculs sont nécessaire, je recommande un fine-tuning spécifique.
Autrement, on diminue tout le raisonnement complexe en petite tâches simple, rapide et efficace.
Comment construire le graph – Ontologie et taxonomie
Le graph structure :
- Les chunks (nodes)
- Les labels (metadata du node) qui sont hiérarchisés.
- Les relations métier (arêtes).
- Les clusters
Vous interrogez le graph directement :
– Par requêtes sur les labels (GraphQL, DQL, Cypher).
– Ou par algorithmes légers (Jaccard, SimRank).
Pas besoin d’un reranker ou d’un CoT coûteux.
4. Pourquoi cette approche est plus robuste et plus simple
– Le graphe gère la complexité par les relations, pas par un score de similarité approximatif.
– La classification réduit l’espace de recherche à ce qui est pertinent.
– Le retrieval est contrôlé, explicite et vérifiable.
Résultat :
✅ 100 % de précision atteignable*, même avec un petit modèle de 7–8B.
✅ Coût maîtrisé.
✅ Comportement prévisible.
* 100% de précision dépend de la qualité initiale de la structuration (ontologie/taxonomie), de la couverture des labels et des mises à jour de votre graph.
CoT avec vectorDB reste quand même intéressant :
- Domaines à faible structuration préalable
- Recherche créative et exploratoire
- Systèmes génériques multi-domaines
- Contextes nécessitant une adaptation rapide
- Projets avec contraintes de ressources
En conclusion
Le Chain of Task décompose le traitement en tâches explicites et contrôlées, tandis que le CoT décompose le raisonnement dans la génération elle-même, ce qui reste coûteux et peu contrôlable. Encore mieux, là où le multi-indexing crée du chevauchement entre les clusters et biaise le retrieval, le multi-labelling côté graph crée de la granularité et améliore la précision.