Pourquoi je n'ai jamais vectorisé ma doc

Chez le client, ma façon de préparer le terrain pour l'IA est toujours la même : je sors l'information dans un format plus petit, filtré, organisé à la main — pas une base vectorielle, pas d'indexation automatique. Ça marche, et plutôt bien. Le problème, c'est que je fais ça un peu à contre-courant : autour de moi, la conversation part vite sur les bases vectorielles, les graphes de connaissances, les frameworks d'agents, comme si ne pas les utiliser relevait du retard plutôt que d'un choix. Je me suis demandé si mon instinct de data engineer tenait vraiment la route, ou si je me racontais une histoire. J'ai creusé quatre fils précis pour trancher.

Le premier m'a surpris par sa source. Anthropic elle-même a abandonné le RAG plus base vectorielle pour Claude Code, au profit de la recherche agentique — grep, ls, cat, en boucle, un peu comme un développeur explore un repo à la main. Boris Cherny, qui dirige Claude Code, l'a écrit noir sur blanc : les premières versions utilisaient RAG et une base vectorielle locale, "mais on a vite découvert que la recherche agentique fonctionne généralement mieux". Les raisons données ne sont pas cosmétiques : un index vectoriel devient obsolète dès que le code ou la doc bouge, la recherche sémantique retourne des "snippets similaires" là où il faut des références exactes, et la recherche agentique évite toute la complexité opérationnelle de maintenir un index à jour — plus simple, plus sûr aussi côté confidentialité. Fabio Akita est arrivé au même endroit par un chemin différent, en partant des capacités de contexte des modèles actuels plutôt que du choix d'architecture d'Anthropic : un bon grep plus une fenêtre de contexte généreuse bat, dans la plupart des cas, une pile RAG complète. Deux angles distincts, une même conclusion. La contrepartie honnête existe : mal cadrée, une recherche agentique peut explorer trop et consommer plus de tokens qu'un lookup vectoriel bien réglé — mais c'est un problème de cadrage, pas un argument pour revenir à la vectorisation par défaut.

Deuxième fil, plus terre-à-terre mais probablement le plus rentable des quatre : avant même de se poser la question du retrieval, convertir un document en markdown réduit sa taille en tokens de 65 à 90%, selon le format de départ. Un exemple parlant : un article de 500 mots pèse autour de 700 tokens une fois converti en markdown, et peut dépasser 8000 tokens dans son HTML brut d'origine — la faute aux balises, aux attributs, à tout ce qui sert l'affichage et rien à la compréhension. Les DOCX et les PDF texte tirent aussi leur épingle du jeu, dans des proportions un peu moindres. Des outils font ce travail sans qu'on ait à y penser : MarkItDown, l'outil open source de Microsoft — qui tourne en local, y compris comme serveur MCP directement dans Claude Code —, Pandoc, Marker. C'est le levier le plus simple à activer, et il agit avant même d'avoir choisi une stratégie de recherche.

Troisième fil : les graphes de connaissances façon GraphRAG, présentés comme l'étape d'après pour qui veut un vrai "cerveau" documentaire. Le coût d'indexation, historiquement, est aberrant — environ 1544$ par million de tokens pour construire un graphe complet, contre environ 1,45$ par million de tokens pour un RAG vectoriel classique, un facteur qui tourne autour de mille. Un cas concret, documenté sur le dépôt officiel de Microsoft GraphRAG : indexer un seul dossier juridique de 5 Go de texte revenait, avec GPT-4o-mini, à environ 33 000$. Une variante publiée par Microsoft Research fin 2024, LazyGraphRAG, a fait tomber ce coût au niveau d'un RAG vectoriel classique en repoussant l'essentiel du travail LLM au moment de la requête plutôt qu'à l'indexation — et cette baisse tient toujours en 2026, elle n'a rien d'un correctif ponctuel. Mais faire baisser le prix ne répond pas à la vraie question, celle qui a justifié tout un papier de recherche à elle seule en 2026 : un graphe ne vaut son coût que sur des questions vraiment transversales à tout un corpus — comparaisons, motifs qui traversent plusieurs documents — jamais sur du lookup simple, qui reste mon usage dominant. Et il garde un risque propre, symétrique à la vectorisation à l'aveugle : l'extraction du graphe se fait elle aussi par un LLM, qui peut très bien relier deux entités par une relation qui ne tient pas vraiment dans le texte source.

Le quatrième fil est celui qui m'a le plus servi à comprendre ce que je fais déjà sans le nommer ainsi : mon wiki personnel, à la Obsidian, n'est pas un GraphRAG déguisé, même si les deux finissent par produire un graphe qu'on peut visualiser. La mécanique est différente à la racine. Chaque nœud est un fichier markdown, chaque arête est un lien que j'écris moi-même, après avoir compris le contenu — pas un LLM qui infère une relation depuis un texte qu'il vient de lire une fois. Coût d'extraction nul, risque d'hallucination nul, parce que la compréhension précède le lien plutôt que l'inverse. Les plugins qui promettent de découvrir des liens "cachés" par embeddings, comme InfraNodus sur Obsidian, réintroduisent à mes yeux le même risque que GraphRAG, juste déplacé du serveur vers le plugin. Andrej Karpathy a formalisé cette approche en avril 2026, dans un texte qu'il présente explicitement comme une alternative à la vectorisation et au contexte long : une mémoire d'agent persistante sur disque, en markdown et wikilinks, chargée au fur et à mesure que l'agent navigue plutôt que toute entière en contexte. Une implémentation communautaire de ce patron tourne à 100% en local via Ollama — la preuve que ça ne suppose pas un modèle frontier, seulement un agent bien réglé pour savoir quel lien suivre et quand s'arrêter.

Un aparté qui n'est pas le sujet de ce billet, mais qui l'illustre bien : mon CV décrivait cette pratique comme "RAG (passif)". Un screening IA que j'ai fait tourner sur mon propre site — je raconte le protocole complet ici — a lu ce mot comme un aveu de faiblesse plutôt que comme de la précision honnête, et ça m'a coûté des points de score. J'avais choisi de garder le mot tel quel à l'époque, en toute connaissance de cause. Mais cette session de recherche m'a donné de quoi trancher autrement : "RAG (markdown-based)" décrit exactement la même pratique, sans ce risque de lecture, alors j'ai changé le mot sur mon CV. La pratique n'a pas bougé d'un pouce ; c'est le vocabulaire autour qui a vieilli plus vite qu'elle.

Ces quatre fils ne prouvent pas que le markdown gagne partout : la recherche agentique a ses limites de cadrage, LazyGraphRAG a sa place quand le corpus le justifie vraiment, InfraNodus rend un vrai service tant qu'on sait ce qu'il fait sous le capot. Ce qu'ils confirment, plus précisément, c'est que mon réflexe de data engineer — sortir l'info dans un format plus petit, curé à la main, versionnable — tient debout point par point, sur les quatre fils que j'ai vérifiés. Il reste, pour l'instant, le point de départ le plus rentable avant même de se demander si on a vraiment besoin de vectoriser quoi que ce soit.

Références

• Boris Cherny (X) — citation d'origine sur l'abandon de RAG + vector DB pour Claude Code
• Robert H. Eubanks — Anthropic Replaced Their RAG Pipeline with Agentic Search
• Fabio Akita — RAG is dead, long context wins
• MindStudio — How to Convert Files to Markdown to Reduce AI Token Usage by Up to 90%
• Microsoft — MarkItDown (dépôt officiel)
• GraphRAG vs Vector RAG: When the Knowledge Graph Pays for Itself — chiffres de coût d'indexation ($1544/M tokens vs $1,45/M tokens)
• Microsoft GraphRAG (discussion officielle) — le cas des 33 000$ pour indexer 5 Go de documents légaux
• Microsoft Research — LazyGraphRAG: Setting a new standard for quality and cost
• arXiv — When Is Graph Structure Worth Its Cost? The Case for Structure Pricing in Retrieval-Augmented Generation
• InfraNodus — Visualize Knowledge Graphs for Personal Knowledge Management
• Andrej Karpathy — LLM Wiki (gist d'origine, avril 2026)
• kytmanov/obsidian-llm-wiki-local — implémentation 100% locale via Ollama