Votre IA se trompe de référence — et ce n’est pas la faute du LLM

Pourquoi la recherche par « ressemblance » (Vecteurs) échoue là où le SQL et le BM25 triomphent.

Vous installez MxChat sur votre boutique WooCommerce. En quelques clics, votre catalogue de 3 000 références est ingéré, vectorisé via l’API OpenAI, stocké dans une base vectorielle embarquée. Le chatbot répond. Vous êtes satisfait. Vous n’avez jamais eu le choix du mécanisme de récupération — et personne ne vous a dit qu’il en existait d’autres.

C’est l’état de l’industrie en 2026 : les outils grand public ont standardisé la base vectorielle comme unique réponse au RAG, silencieusement, sans que la question soit jamais posée. NotebookLM, Claude Projects, Perplexity — même constat. Le vectoriel s’est imposé non pas parce qu’il est universellement supérieur, mais parce qu’il est apparu au même moment que les LLMs modernes et qu’il a hérité de leur aura.

Si vous avez suivi cette série depuis le guide complet du pipeline RAG et l’article sur le semantic collapse, vous connaissez déjà les limites du vectoriel à grande échelle. Cet article ouvre une question différente, en amont : est-ce que le vectoriel était le bon outil dès le départ ? Parce que sur un catalogue WooCommerce avec des SKUs, des codes produit et des prix, la réponse est probablement non.

BM25 et Elasticsearch : la revanche du bas-niveau dans le search

Il y a dans l’histoire du search un paradoxe que l’IA a rendu visible sans le résoudre : nous avons abandonné des outils capables d’indexer des milliards de documents au profit d’architectures qui s’effondrent à 50 000 chunks.

BM25 — Best Match 25 — est l’algorithme de ranking lexical qui alimente les moteurs de recherche depuis trente ans. Son principe est d’une clarté désarmante : pondérer les termes d’une requête par leur fréquence dans le document (TF) et leur rareté dans le corpus (IDF), puis classer les résultats en conséquence. Pas d’embedding, pas de GPU, pas de calcul de similarité cosinus à chaque requête. Un index inversé calculé une fois, interrogeable en quelques millisecondes sur n’importe quelle machine.

C’est la revanche du bas-niveau dans le search — exactement ce que C et Rust représentent dans le code par rapport à Python, comme je l’analysais dans l’article sur le vibe coding et la dette énergétique du code assisté par IA. L’étude Energy Efficiency Across Programming Languages menée par six chercheurs de trois universités portugaises a quantifié l’écart : Python consomme environ 75 fois plus d’énergie que C pour des tâches équivalentes. Le parallèle avec le retrieval est direct. Un index BM25 est calculé une fois et n’exige rien à l’exécution. Une base vectorielle consomme du compute à l’ingestion (calcul des embeddings), du stockage (vecteurs haute dimension), et du calcul à chaque requête (similarité cosinus approximative via HNSW). Sur un corpus de 100 000 documents avec 10 000 requêtes quotidiennes, cette différence n’est pas marginale — elle est structurelle. Un sujet que l’ADEME ferait bien d’intégrer dans ses études sur l’impact des datacenters plutôt que de confier ce travail à des consultants militants.

Mais l’argument énergétique, aussi réel soit-il, n’est pas le plus important. Le plus important est celui-ci : BM25 surpasse les embeddings sur les requêtes où la correspondance lexicale prime sur la proximité sémantique. C’est-à-dire partout où le vocabulaire est précis, stable et non ambigu.

Un technicien qui cherche « erreur ERR-4012 » ne veut pas les chunks sémantiquement proches de l’erreur 4012 — il veut le document qui contient exactement cette chaîne. Un juriste qui cherche « article L.442-6 du Code de commerce » ne veut pas les passages qui parlent vaguement de relations commerciales déséquilibrées. Un médecin qui cherche « metformine 850 mg » ne veut pas les chunks sur les antidiabétiques oraux en général. Dans ces cas, le vectoriel hallucine par généralisation là où BM25 répond par exactitude.

Elasticsearch et Solr sont les implémentations industrielles de cette logique. Des outils battle-tested depuis 15 ans, capables d’indexer des milliards de documents, avec un scoring configurable, des filtres complexes sur les métadonnées, et une infrastructure que des milliers d’entreprises font tourner en production — souvent sur des machines sans GPU. Ils n’ont pas disparu. Ils ont juste été éclipsés par l’engouement pour les embeddings, au point que la majorité des tutoriels RAG ne les mentionnent même plus.

La recherche hybride — BM25 + dense retrieval combinés — est la reconnaissance implicite de cette réalité. ChromaDB l’a intégrée nativement en 2025. Mais la présenter comme une « feature » de base vectorielle, c’est inverser la causalité : c’est BM25 qui comble les failles du vectoriel, pas l’inverse.

SQL et bases relationnelles : quand la question a une réponse exacte

La vis M4×20 et la vis M5×20 sont sémantiquement identiques. Même famille de produits, même usage, même contexte documentaire. Dans un espace vectoriel, leurs embeddings sont proches — peut-être indiscernables selon le modèle. Un client qui cherche « vis M4 20mm tête fraisée inox » et reçoit en réponse une vis M5 a un problème mécanique, pas un problème sémantique.

C’est l’argument WooCommerce dans toute sa brutalité. MxChat vectorise votre catalogue par défaut. La similarité cosinus devient votre mécanisme de récupération pour des données qui ont une clé primaire, un prix exact, un stock en temps réel, et un SKU qui ne tolère aucune approximation. Une requête SQL ne confond jamais une vis M4 et une vis M5. Elle ne peut pas — c’est sa nature.

Le pattern Text-to-SQL est la forme la plus directe du RAG structuré : le LLM transforme la question en langage naturel en une requête SQL, la base l’exécute, le résultat alimente la réponse. LangChain SQL Agent et LlamaIndex SQL Query Engine fournissent les briques. Le résultat est déterministe, reproductible, et auditable — trois propriétés que le vectoriel ne peut pas garantir.

L’auditabilité mérite qu’on s’y arrête. Un retrieval vectoriel est une boîte noire géométrique : vous ne pouvez pas expliquer pourquoi le chunk n°47 a été retourné plutôt que le chunk n°12. Les scores de similarité cosinus sont des nombres sans sémantique humaine — 0.83 ne signifie rien pour un responsable juridique qui veut comprendre pourquoi son assistant IA a cité le mauvais contrat. Une requête SQL, elle, est lisible, reproductible et contestable. Dans des contextes où la décision doit être justifiable — conformité, droit, médecine — cette opacité du vectoriel n’est pas un détail technique, c’est un risque métier. C’est le même problème de fond que celui que je soulevais dans l’article sur la transparence judiciaire : les systèmes opaques qui décident sans pouvoir être audités érodent la confiance, qu’ils soient institutionnels ou algorithmiques.

Les limites sont réelles et méritent d’être nommées : Text-to-SQL exige un schéma propre, des données normalisées, et un LLM capable de générer du SQL correct sans halluciner les noms de colonnes — une faille documentée des LLMs actuels. Ce n’est pas un outil universel. Mais sur un catalogue produit, un CRM, une base de jurisprudence normalisée, ou n’importe quelle donnée structurée avec des identifiants précis, il est diablement plus fiable que la similarité sémantique.

Bases de graphes et GraphRAG : les relations que le cosine ne voit pas

La recherche vectorielle répond à une question : ces deux textes sont-ils sémantiquement proches ? Elle ne répond pas à une autre : quelle est la relation entre ces deux entités ?

« Contrat de bail commercial » et « clause de résiliation anticipée » ne sont pas sémantiquement similaires. Ce sont des entités liées par une relation structurelle — l’une est une clause de l’autre. Le cosine ne voit pas ce lien. Un graphe de connaissances, si.

Neo4j et le pattern GraphRAG publié par Microsoft en 2024 formalisent cette approche : les entités (personnes, concepts, documents, organisations) sont des nœuds, les relations entre elles sont des arêtes typées. Quand un juriste demande « quelles sont les conditions de résiliation du contrat avec Dupont SA ? », le système ne cherche pas dans 30 000 contrats les chunks les plus proches de « résiliation » — il navigue depuis l’entité « Dupont SA » vers l’arête « contrat en cours », puis vers les nœuds « clauses de résiliation » de ce contrat précis. La recherche ne porte plus sur 30 000 documents. Elle porte sur un seul — le bon.

L’avantage est particulièrement net sur les requêtes multi-sauts : « quels fournisseurs de Dupont SA ont aussi des contrats avec nos concurrents directs ? » est une requête impossible à formuler efficacement en recherche vectorielle. Un graphe la résout en quelques arêtes.

Le coût d’entrée est réel et il faut être honnête à ce sujet. Construire et maintenir un graphe de connaissances demande une modélisation du domaine, des compétences spécifiques, et un investissement en ingénierie qui n’est pas à la portée d’un projet de trois semaines. C’est un outil pour les corpus où les relations entre entités sont la donnée critique — droit, médecine, compliance, knowledge management enterprise. Pas pour un blog ou une documentation produit généraliste.

APIs, fichiers et web : le RAG sans base

Le mécanisme de retrieval le plus efficace est parfois le plus simple : aller chercher le bon document à sa source.

Une documentation technique versionnée sur GitHub n’a pas besoin d’être vectorisée — elle a une URL, une structure, et une version. Un prix en temps réel ne peut pas être vectorisé — il change toutes les secondes et une base vectorielle sera obsolète avant d’avoir fini de s’indexer. Un règlement publié ce matin par une autorité financière n’existe pas dans vos embeddings calculés la semaine dernière.

Le pattern « function calling as retriever » est ici la clé architecturale. Le LLM ne cherche pas dans une base — il décide quelle API appeler selon la nature de la question, récupère les données en temps réel, et génère la réponse sur des données fraîches. C’est du RAG — retrieve, then generate — sans la moindre base de données. C’est un comportement, pas une infrastructure.

C’est aussi exactement ce que fait la recherche web activée dans ma stack IA 2026 : chaque réponse sourcée depuis le web est un pipeline RAG sans base vectorielle. L’article sur WebMCP prolonge cette logique : quand un site expose ses données via le protocole MCP, le RAG n’a plus besoin de crawler ni d’indexer — il interroge directement la source avec des données structurées et fraîches. Le RAG n’est plus une base de données. C’est un comportement — et le function calling en est l’expression la plus pure.

Pour des données temps réel (cours financiers, météo, stocks), des sources autoritatives versionnées (documentation officielle, réglementation), ou des systèmes existants avec leurs propres APIs (CRM, ERP, base interne), le function calling est souvent l’architecture la plus simple, la plus fiable, et la moins chère à maintenir. Les limites de la lecture web par les LLMs restent réelles — troncature, bruit HTML, coût en tokens — mais elles sont prévisibles et gérables, contrairement à la dérive silencieuse d’un index vectoriel qui vieillit.

Comment choisir : la matrice des trois axes

Avant de déployer une base vectorielle, une seule question devrait structurer la décision. Elle se pose en trois temps, dans l’ordre.

Déterminisme : la question admet-elle une réponse exacte et reproductible ? Si oui — prix, stock, identifiant, référence réglementaire, donnée temps réel — la réponse est SQL ou API. Aucune ambiguïté, aucun calcul de similarité. Le vectoriel est exclu d’office sur ce type de question.

Littéralité : la question porte-t-elle sur des termes précis, un vocabulaire stable, des identifiants ? Si oui — code erreur, référence produit, terme juridique normalisé, nom propre, acte législatif — la réponse est BM25 ou Elasticsearch. La correspondance lexicale exacte est plus fiable que la proximité sémantique approximative.

Concept : la question est-elle sémantique, ouverte, transversale ? Seulement si les deux premières réponses sont négatives — question de synthèse, recherche d’idées connexes, exploration d’un corpus non structuré — le vectoriel devient pertinent.

Le tableau ci-dessous synthétise les arbitrages :

Le coût énergétique relatif n’est pas une mesure précise — c’est un ordre de grandeur pour marquer les esprits, dans l’esprit des rapports de l’étude portugaise sur les langages. SQL et BM25 tournent sur du CPU standard sans calcul d’embedding. Le vectoriel exige des embeddings à l’ingestion, du stockage haute dimension, et du calcul de similarité approximatif à chaque requête. L’écart réel dépend du corpus et de l’infrastructure, mais l’ordre de grandeur tient.

La règle pratique : commencez par Déterminisme, descendez vers Littéralité, n’atteignez le Concept qu’en dernier recours. C’est l’inverse de ce que fait 95 % de l’industrie — et c’est précisément pour cette raison que tant de pipelines sur-ingénièrent des solutions vectorielles là où une requête SQL de dix lignes aurait suffi.

Le sens comme direction, ou le sens comme vérité

Il y a dans le vectoriel une limite philosophique que mon article sur la conscience des LLM comme illusion géométrique éclaire d’un angle inattendu. Un LLM traite le sens comme une direction dans un espace à plusieurs milliers de dimensions. Une base vectorielle fait de même pour vos documents. Ce n’est pas une critique — c’est la nature de ces systèmes, et ils excellent dans ce registre.

Le problème commence quand on applique cette logique à des questions qui appellent une vérité plutôt qu’une direction. « Quel est le prix de cette référence ? » n’est pas une question sémantique. « Ce contrat comporte-t-il une clause de résiliation unilatérale ? » non plus. Ces questions ont une réponse exacte, indépendante de la proximité géométrique dans un espace d’embeddings. Les soumettre à un retrieval vectoriel, c’est demander à un système conçu pour l’approximation de répondre à une question qui n’en tolère aucune.

Cette série a couvert le pipeline RAG dans son architecture canonique, puis ses limites de scaling. Elle s’arrête ici sur une question qui précède les deux autres : de quel outil avez-vous réellement besoin ? Quand MxChat vectorise votre catalogue WooCommerce sans vous demander votre avis, la compétence du builder sérieux, c’est de savoir que la question aurait dû être posée — et d’avoir les éléments pour y répondre.

La base vectorielle reste l’outil dominant pour les corpus hétérogènes et les questions ouvertes. Comme l’IA est une commodité et non une réponse universelle, le vectoriel est un outil parmi d’autres — qui mérite d’être choisi plutôt que subi.