Le routage précède la récupération, pas la dimension d'embedding
L'enquête de KDnuggets sur les défaillances RAG montre que la sur-ingénierie des embeddings aggrave le coût. Le mécanisme absent est le routage explicite avant la récupération — Theorem 3 appliqué à la recherche, avec la topologie d'Everythink comme analogue en amont.

Le routage précède la récupération, pas la dimension d'embedding
L'enquête de juin 2026 de KDnuggets sur les défaillances de la génération augmentée par récupération rapporte une entreprise manufacturière mondiale qui avait budgété 400 000 USD pour son système RAG, dépensé 1,2 million de USD la première année et atteint 23 % de précision sur les requêtes de documentation technique avant de clore le projet. Le diagnostic de l'article est structurel, pas un réglage : irrelevance de récupération, empoisonnement du contexte et un conflit de taille de fragment qu'aucune dimension d'embedding ne résout. Sa prescription est quatre architectures choisies par type de requête, avec la phrase porteuse : « le changement clé consiste à rendre le routage explicite. Chaque requête est classifiée avant que quelque récupération que ce soit s'exécute. » (Nate Rosidi, KDnuggets, « Your RAG Pipeline Is Probably Useless. Here's a Better Alternative », publié 2026-06-29, consulté 2026-08-23, https://www.kdnuggets.com/your-rag-pipeline-is-probably-useless-heres-a-better-alternative). Le Honest Architect lit le texte comme Theorem 3 appliqué à la récupération : une propriété (pertinence factuelle) est garantie exactement lorsque son mécanisme (routage explicite avant la récupération) est implémenté et mesure — et ajouter des dimensions d'embedding à un design qui manque ce mécanisme rend la défaillance plus chère, non moins.
[UNIQUE INSIGHT]: Le piège de la sur-ingénierie est Theorem 3 en miniature. On ne peut pas garantir la pertinence factuelle en ajoutant davantage d'un mécanisme (embeddings de plus grande dimension, plus de reranking, récupération multi-étapes) qui n'implémente pas la pertinence. La pertinence est une propriété de routage — cette requête appartient-elle à ce corpus, cette version, ce document ? — pas une propriété de similarité. Mettre à l'échelle le mauvais mécanisme accumule le coût sans produire la propriété.
Points-clés
- L'irrelevance de récupération est une défaillance de mécanisme absent. Theorem 3: la propriété pertinence-factuelle est garantie en routant la requête vers le bon corpus, la bonne version et le bon type de document avant la récupération, non par similarité vectorielle. L'article : une requête sur le congé parental renvoie la politique de 2022, celle de 2024 et un billet culturel, tous élevés en distance d'embedding, aucun ne répond. Production ✅ pour le diagnostic.
- L'empoisonnement du contexte est une défaillance de mécanisme absent. Theorem 3: la propriété contradiction-exposée est garantie par le routage des versions plus la détection de contradictions, non en mélangeant des fragments. L'article : quand le récupérateur renvoie des versions contradictoires, le modèle « en choisit une, mélange les deux ou présente une synthèse confiante » et « ni l'utilisateur ni le modèle ne le sait ». Production ✅ pour le diagnostic.
- Le conflit de taille de fragment est structurel, non réglable. Le rappel exige des fragments de 100–256 jetons ; la cohérence en exige 1024 ou plus. Aucune dimension d'embedding ne résout un compromis où les deux propriétés tirent le paramètre dans des directions opposées. Production ✅ pour l'affirmation structurelle.
- La sur-ingénierie aggrave la défaillance. L'article : un taux d'échec de 72 % la première année pour le RAG d'entreprise en 2025, un dépassement de budget de 400 000 à 1,2 million de USD, 23 % de précision, 75 000 USD par mois en coûts de base de données vectorielle au sixième mois chez une entreprise de santé. Ajouter de la complexité à un design de récupération cassé « augmente les coûts de calcul et retarde la question plus utile, à savoir si l'architecture de récupération était le bon choix ». Partial ⚠️ (chiffres cités d'enquêtes, non vérifiés indépendamment par Everythink).
- Le routage précède la récupération. Self-Route (EMNLP 2024) classifie si une requête a besoin de contexte complet ou de récupération focalisée avant que la récupération s'exécute ; améliorations de précision de 15 à 30 % rapportées pour la recherche hybride et le reranking. Theorem 3: la propriété bonne-stratégie-par-requête est garantie par classifier-avant-de-récupérer, non en s'engageant sur une stratégie à la construction. Production ✅ pour la forme ; Partial ⚠️ pour les pourcentages spécifiques.
- « The space is the router » est le mécanisme de routage en amont qui manque au RAG. La topologie network→community→room d'Everythink route une question vers le bon contexte avant que quoi que ce soit réponde — la même forme que Self-Route, un domaine en amont. Partial ⚠️ (même forme — router-avant-de-répondre — domaines séparés).
- Portée : civile/défensive. L'architecture de récupération est une infrastructure civile. Aucun résultat de token, wallet ni community-credit n'est promis ; ceux-ci sont Roadmap 🔵, révision Howey en attente. Everythink est une plateforme de prévision, pas un fournisseur de RAG ; les parallèles transverses sont des illustrations Partial ⚠️, pas des appuis à KDnuggets, StrataScratch, Microsoft GraphRAG ni aucun outil spécifique.
Quand RAG échoue : la propriété n'est pas garantie
L'article s'ouvre sur la défaillance que les démos cachent. Un utilisateur demande un congé parental. Le récupérateur renvoie la version de 2022, celle de 2024 et un billet culturel. Chaque fragment marque haut en distance d'embedding parce qu'il partage du vocabulaire avec la requête. Aucun ne répond à la question. Le modèle ne sait pas que le contenu récupéré est obsolète ou hors-sujet ; il mélange les fragments en une réponse confiante, détaillée, factuellement fausse. L'article appelle cela « similarité topique sans pertinence factuelle, et c'est le mode de défaillance dominant dans les systèmes RAG en production ».
Le Honest Architect lit cela comme Theorem 3. La propriété est pertinence-factuelle. Le mécanisme que le système implémente est similarité-vectorielle, qui garantit la-réponse-ressemble-à-la-question, non pertinence-factuelle. Les deux coïncident quand le corpus est petit, actuel et monoversion — le cas démo. Ils divergent quand le corpus contient des versions multiples, des correspondances de vocabulaire hors-sujet et des contradictions. Le système affirme la pertinence en récupérant des fragments similaires ; le mécanisme n'implémente pas la pertinence, donc la propriété n'est pas garantie. Production ✅ pour le diagnostic.
La défaillance plus subtile, l'empoisonnement du contexte, a la même forme. Les bases de connaissances d'entreprise conservent la même politique en versions multiples. Le récupérateur renvoie des fragments des deux. Le modèle « ne fait pas surface à la contradiction. Il en choisit une, mélange les deux ou présente une synthèse confiante. Le lecteur obtient une réponse. La réponse peut être fausse. Ni l'utilisateur ni le modèle ne le sait. » La propriété est contradiction-exposée. Le mécanisme est mélanger-et-synthétiser. Aucun mécanisme ne détecte la contradiction, donc la propriété n'est pas garantie. Le système produit une réponse ; il ne produit pas une réponse connue-correcte. Production ✅.
[PERSONAL EXPERIENCE]: En construisant le HAI Engine depuis 2016, nous avons appris la même leçon dans un autre domaine. Une prévision ne devient pas pertinente en la calculant sur davantage de données ; elle devient pertinente en routant la question vers la bonne salle — la bonne communauté, le bon contexte délimité — avant que quelque modèle s'exécute. Mettre le modèle à l'échelle sur le mauvais contexte produit une prévision confiante, détaillée, hors-cible, comme mettre les embeddings à l'échelle sur les mauvais fragments produit une réponse confiante, détaillée, hors-cible. Le mécanisme qui produit la pertinence est le routage, non le volume. Production ✅.
Le piège de la sur-ingénierie est Theorem 3 en miniature
La section la plus utile de l'article est celle que les ingénieurs sautent. Quand le RAG standard sous-performe, la correction habituelle est de le compliquer : embeddings de plus grande dimension, reranking plus sophistiqué, récupération multi-étapes. Le verdict de l'article : « Cela aggrave le problème. »
Les données sont directes. Une entreprise manufacturière mondiale a budgété 400 000 USD, dépensé 1,2 million la première année, atteint 23 % de précision et clôt le projet. Une entreprise de santé a atteint 75 000 USD par mois en coûts de base de données vectorielle au sixième mois. L'article cite un taux d'échec de 72 % la première année pour les implémentations RAG d'entreprise en 2025. Le Honest Architect lit cela comme le coût de mettre à l'échelle le mauvais mécanisme. Les embeddings de plus grande dimension implémentent une similarité plus fine, non pertinence-factuelle. Le reranking implémente une réorganisation, non contradiction-exposée. La récupération multi-étapes implémente récupérer-puis-récupérer-encore, non router-avant-de-récupérer. Chacun ajoute du calcul à un design qui manque toujours du mécanisme absent, donc la propriété reste non garantie tandis que la facture grossit. Partial ⚠️ sur les chiffres (cités d'enquêtes, non vérifiés indépendamment par Everythink) ; Production ✅ sur la forme — mettre à l'échelle un mécanisme qui n'implémente pas la propriété ne peut pas produire la propriété.
Ceci est Theorem 3 en miniature. Une propriété est garantie exactement lorsque son mécanisme est implémenté et mesure. La pertinence est la propriété. Le routage avant la récupération est le mécanisme. La dimension d'embedding est un mécanisme différent, mesurant une propriété différente. On ne peut pas acheter la pertinence avec des dimensions d'embedding, comme on ne peut pas acheter la résistance au feu avec l'épaisseur de peinture. La phrase de l'article — « augmente les coûts de calcul et retarde la question plus utile, à savoir si l'architecture de récupération était le bon choix » — est la version opérationnelle du théorème. Production ✅.
L'article nomme aussi un conflit structurel qu'aucun réglage ne résout : le rappel exige de petits fragments (100–256 jetons), la cohérence en exige de grands (1024 ou plus), et chaque concepteur de RAG en choisit un et accepte le compromis. Le Honest Architect lit cela comme la frontière du mécanisme fragmenter-embeber-récupérer — non un problème de réglage mais de sélection de mécanisme. Les quatre alternatives ne sont pas des rustines sur ce conflit ; elles sont des mécanismes distincts, garantissant chacun une propriété distincte pour un type de requête distinct. Production ✅ pour le cadrage ; les noms d'outils (Self-Route, GraphRAG) sont Partial ⚠️ (rapportés par la recherche, non vérifiés indépendamment par Everythink).
Les quatre alternatives sont du routage selon la situation
Contexte long : sauter la récupération quand le corpus tient
La première alternative de l'article est de sauter la récupération entièrement. Si le corpus tient dans la fenêtre de contexte du modèle, chargez-le et laissez le modèle lire. Un benchmark (arXiv 2501.01880) a constaté que les LLM à contexte long surpassaient cohéremment le RAG sur des tâches de QA lorsque du calcul était disponible, la récupération basée sur fragments restant à la traîne. Le compromis de coût est réel : à 1M de jetons, la latence est 30 à 60 fois plus lente qu'un pipeline RAG, à environ 1250 fois le coût par requête ; la mise en cache de prompts peut rendre le contexte long compétitif en coût pour les applications à fort trafic. La règle de décision : si le corpus tient dans la fenêtre et le volume de requêtes est modéré, le contexte long est le point de départ le plus propre ; ajoutez la récupération seulement quand le corpus dépasse la fenêtre, la latence viole les SLO ou le volume croise le seuil de rentabilité. Theorem 3: la propriété réponse-de-contexte-complet est garantie en chargeant tout le corpus, non en récupérant des fragments de celui-ci. La décision de routage (ce corpus tient-il ?) précède le choix d'architecture. Production ✅ pour la forme ; Partial ⚠️ pour les multiplicateurs de coût.
Compression de mémoire : résumer avant de récupérer
Quand le corpus est trop grand pour la fenêtre, la deuxième alternative de l'article est de résumer avant de récupérer plutôt que de tirer des fragments bruts. La récupération basée sur les résumés performe de façon comparable aux méthodes de contexte long complet, tandis que la récupération basée sur fragments reste derrière. Un résultat concret : une approche RAG préservant l'ordre utilisant 48K jetons bien choisis a surpassé la récupération de contexte complet à 117K jetons de 13 points F1, à un septième du budget de jetons. Theorem 3: la propriété contexte-pertinent-dans-budget est garantie en compressant vers la pertinence avant l'injection, non en récupérant des fragments bruts en espérant que le modèle filtre. Un document pertinent bien compressé bat un vidage brut de fragments tangentiellement liés. Production ✅ pour la forme ; Partial ⚠️ pour le chiffre de 13 points F1 (étude unique).
Récupération structurée : classifier la requête avant que la récupération s'exécute
La troisième alternative de l'article est celle qui correspond le plus directement au mécanisme absent. Quand la récupération est la bonne architecture, la solution est de router par type de requête plutôt que d'appliquer de meilleurs embeddings uniformément. Self-Route, présenté à EMNLP 2024, laisse le modèle classifier si une requête a besoin de contexte complet ou de récupération focalisée avant de l'exécuter. Les recherches factuelles simples vont au RAG focalisé. Les questions multi-sauts complexes vont à un contexte long. Le résultat : meilleure précision globale à coût computationnel moindre. Les systèmes adaptatifs utilisant cette approche hybride ont montré des améliorations de 15 à 30 % de précision de récupération via recherche hybride et reranking. La phrase porteuse de l'article : « Le changement clé consiste à rendre le routage explicite. Chaque requête est classifiée avant que quelque récupération que ce soit s'exécute, et le système cesse de traiter toutes les requêtes comme des problèmes d'embedding identiques. »
Theorem 3: la propriété bonne-stratégie-par-requête est garantie par le mécanisme (classifier la requête, puis récupérer), non en s'engageant sur une stratégie à la construction. La classification est la mesure ; le routage est le mécanisme. Le système qui classifie avant de récupérer implémente la propriété ; celui qui récupère-puis-espère non. Production ✅ pour la forme ; Partial ⚠️ pour les pourcentages spécifiques.
[ORIGINAL DATA]: Le Honest Architect note le parallèle structurel entre le classifier-avant-de-récupérer de Self-Route et le « the space is the router » d'Everythink. Self-Route classifie la requête puis route vers une stratégie de récupération. Everythink route la question vers une salle — network→community→room — avant que quelque modèle s'exécute. Les deux implémentent la propriété pertinence en routant avant de répondre, non en diffusant et en filtrant. La différence est de domaine et de portée : Self-Route route à l'intérieur d'un système de récupération ; « the space is the router » route à travers tout un réseau de contextes délimités. Partial ⚠️ (même forme — router-avant-de-répondre — domaines séparés).
Basé sur des graphes : router les requêtes relationnelles vers un graphe
La quatrième alternative de l'article est pour les requêtes qui exigent de comprendre des relations à travers un jeu de données plutôt que de récupérer un passage. Ce sont les questions multi-sauts : quelles décisions le conseil a-t-il inversées au Q3, et quelle était la raison déclarée à chaque fois ? Aucun fragment unique ne répond à cela ; la réponse vit dans les connexions entre documents. Microsoft Research a introduit GraphRAG en 2024 : construisez un graphe de connaissances à partir du corpus, parcourez les relations d'entités plutôt que de faire correspondre des vecteurs. Le compromis est le coût — l'extraction du graphe de connaissances coûte 3 à 5 fois plus cher que le RAG de référence et exige un réglage spécifique au domaine — vaut la peine pour l'analyse thématique et le raisonnement multi-sauts, non pour les recherches factuelles à passage unique. Theorem 3: la propriété relations-entre-documents est garantie par des entités plus des relations typées, parcourues, non par similarité vectorielle. Production ✅ pour la forme ; Partial ⚠️ pour les multiplicateurs de coût. Un traitement plus approfondi des formes de mécanisme de GraphRAG figure dans notre texte antérieur sur l'adéquation du mécanisme au type de requête.
The space is the router — le mécanisme qui manque au RAG
Les quatre alternatives convergent sur un mécanisme : routez avant de récupérer. Le contexte long route par taille de corpus. La compression de mémoire route par budget. La récupération structurée route par type de requête. Le basé sur graphes route par structure relationnelle. Chacune est une décision de routage prise avant que le mécanisme de récupération s'exécute, et chacune garantit sa propriété parce que le routage correspond à la forme réelle de la requête.
Le « the space is the router » d'Everythink est le même mécanisme, un domaine en amont. La topologie network→community→room route une question vers le bon contexte délimité avant que quoi que ce soit réponde. Une question posée dans une salle sur la logique de relance des paiements est déjà routée vers la communauté des paiements, le réseau d'ingénierie, la portée de document pertinente — avant que quelque Sister rédige, avant que l'Oracle fusionne, avant que quelque récupération s'exécute. Le routage est structurel, non calculé au moment de la requête. La propriété pertinence est garantie par la topologie, non en diffusant la question à travers tout le réseau et en filtrant les réponses. Production ✅ pour la forme (le HAI Engine opère ce routage en production depuis 2016) ; Partial ⚠️ pour l'affirmation transverse.
Le Honest Architect ne prétend pas que « the space is the router » est un système de récupération. Everythink est une plateforme de prévision, pas un fournisseur de RAG. L'affirmation est structurelle : le mécanisme absent dans les pipelines RAG échoués est le routage explicite avant la récupération, et ce mécanisme a un analogue éprouvé en production dans la topologie d'Everythink. Le pipeline Sisters-to-Oracle est l'analogue en aval du map-reduce de l'article : chaque Sister rédige en parallèle (l'étape map), l'Oracle les fusionne en un Ensemble normalisé avec entropie à chaque fusion (l'étape reduce), et la propriété prévision-calibrée est garantie par le mécanisme, non par un modèle produisant toute la prévision. Partial ⚠️ (même forme — rédaction-en-parallèle-plus-fusion-mesurée — domaines séparés).
Foire aux questions
Le RAG est-il inutile, comme le dit le titre ?
Non, et l'article ne l'argumente pas. Il argumente que le RAG est un défaut raisonnable qui échoue de façons prévisibles — irrelevance de récupération, empoisonnement du contexte, le conflit de taille de fragment — et que la correction est de router par type de requête, non de sur-ingénierier les embeddings. Le mécanisme doit correspondre à la propriété. Production ✅ pour le diagnostic ; le cadrage « inutile » est éditorial.
Pourquoi ajouter des dimensions d'embedding ne corrige-t-il pas l'irrelevance de récupération ?
Parce que les dimensions d'embedding implémentent la similarité, non la pertinence. L'irrelevance de récupération est une défaillance de routage absent : la requête renvoie des correspondances de vocabulaire qui ne répondent pas à la question. Mettre à l'échelle le mauvais mécanisme accumule le coût sans produire la propriété. Theorem 3: la pertinence-factuelle est garantie en routant avant de récupérer, non par similarité plus fine. Production ✅.
Quel est le mécanisme de routage qui manque au RAG ?
La classification explicite avant la récupération. Self-Route classifie si une requête a besoin de contexte complet ou de récupération focalisée avant que quelque récupération s'exécute. La propriété bonne-stratégie-par-requête est garantie par classifier-puis-récupérer, non en s'engageant sur une stratégie à la construction. Production ✅ pour la forme.
Comment « the space is the router » se rapporte-t-il ?
C'est la même forme, un domaine en amont. La topologie network→community→room d'Everythink route une question vers le bon contexte délimité avant que quelque modèle s'exécute, comme Self-Route route une requête vers la bonne stratégie de récupération avant que la récupération s'exécute. Les deux implémentent la pertinence en routant avant de répondre. Partial ⚠️ (même forme — router-avant-de-répondre — domaines séparés). Everythink est une plateforme de prévision, pas un fournisseur de RAG.
Everythink appuie-t-il GraphRAG ou un outil de récupération quelconque ?
Non. Everythink est une plateforme de prévision. Les chiffres de l'article sont Partial ⚠️. Les parallèles transverses sont des illustrations, non des appuis. La portée est civile/défensive. Aucun résultat de token, wallet ni community-credit n'est promis ; ceux-ci sont Roadmap 🔵, révision Howey en attente.
Sources
- Nate Rosidi, KDnuggets, « Your RAG Pipeline Is Probably Useless. Here's a Better Alternative », publié 2026-06-29, consulté 2026-08-23, https://www.kdnuggets.com/your-rag-pipeline-is-probably-useless-heres-a-better-alternative
Si votre équipe est prête à router avant de récupérer — à classifier la requête avant que quelque embedding s'exécute, comme the space is the router classe la question avant que quelque Sister rédige — lisez the 21 papers ou réservez une démo. Le HAI Engine opère ce mécanisme de routage en production depuis 2016 ; les Sisters rédigent en parallèle, l'Oracle fusionne avec entropie à chaque exécution, et Theorem 3 tient : la propriété est garantie exactement lorsque son mécanisme est implémenté et mesure.

Le test sur le résultat est le mécanisme, pas l'étiquette
Devavrat Shah du MIT a construit un modèle de données tabulaires qui confronte les prévisions aux résultats réels. Le mécanisme est la boucle mesurée — Theorem 3 —, pas l'étiquette world model.
→ →
Le red teaming doit mesurer le mécanisme, pas la démo
Un rapport de l'OWASP qualifie les démos de jailbreak de security theater. La surface de risque réelle est le mécanisme — usage abusif d'outils, escalade multi-agents, fuite RAG. C'est Theorem 3 en costume de sécurité.
→ →
La planification par gradient route par la voie mesurée
GRASP fonctionne en routant le signal d'optimisation par le gradient d'action densément entraîné et en isolant le gradient d'état adversarial. La même discipline de routage soutient Theorem 3 et the space is the router.
→ →Construisez votre monde sur un moteur qui prouve ce qu'il affirme.
Créez votre propre réseau sur le moteur qui tourne depuis 2016 — ou parlez à l'équipe derrière les 21 articles.
