Il y a trois mois, on a construit un pipeline RAG.

Dans les règles de l’art. Découper les documents en chunks, générer les embeddings, stocker dans une base vectorielle, récupérer les fragments pertinents par similarité. Comme dans les slides de conférence. Comme dans les posts Medium. Comme dans les annonces de levée de fonds à 24 millions.

Deux semaines plus tard, on a arrêté.

Le poids du pipeline

Le problème que RAG résout est clair : trop de données pour tenir dans la fenêtre de contexte de l’IA. Donc on cherche. On extrait les fragments pertinents et on les injecte dans le prompt.

Le problème, c’est que ce « donc on cherche » n’est pas un système. C’en est cinq.

Le chunking — où découper. Par paragraphe ? Par titre ? Par nombre de tokens ? Par frontière sémantique ? Chaque découpage donne des résultats différents. La bonne réponse dépend du type de document. Un compte-rendu de réunion et une spécification technique n’ont pas le même chunk optimal. À elle seule, c’est déjà un problème d’ingénierie.

L’embedding — convertir le texte en vecteur. Quel modèle ? ada d’OpenAI ? embed de Cohere ? sentence-transformers en local ? Si le modèle change, il faut recalculer tous les vecteurs. Des milliers de documents, c’est quelques heures. Des dizaines de milliers, une journée.

Le stockage — il faut une base vectorielle. Pinecone ? Weaviate ? Chroma ? pgvector ? Chacune avec son coût opérationnel. Backups, scaling, monitoring. Une base de données de plus, c’est un point de défaillance de plus.

La recherche — vectoriser la requête, récupérer les chunks les plus proches. Mais « le plus proche » n’est pas « le plus pertinent ». La similarité vectorielle est une approximation de la proximité sémantique, pas une correspondance exacte. On cherche « procédure de déploiement » et on reçoit « incidents de déploiement ». Les mots sont proches. L’intention ne l’est pas.

La synchronisation — un document est mis à jour ? Redécouper, re-vectoriser, supprimer les anciens vecteurs, stocker les nouveaux. Il faut un pipeline automatisé. Le pipeline a besoin de monitoring. Le monitoring a besoin d’alertes.

Cinq systèmes. Chacun avec ses edge cases. Chacun à maintenir. Et tout ça pour résoudre un problème : lire un fichier.

Pourquoi on a arrêté

La documentation d’ourstack.dev n’est pas énorme. Quelques centaines de fichiers. Pas des dizaines de milliers.

En deux semaines avec le pipeline RAG, on a constaté trois choses.

Premièrement, les résultats étaient instables. La même question formulée différemment ramenait des chunks différents. « Comment configurer les permissions » et « comment gérer le contrôle d’accès » posent la même question mais renvoient des documents différents. Un système sensible à la formulation, ce n’est pas un moteur de recherche. C’est une machine à sous.

Deuxièmement, les frontières de chunks cassaient le contexte. La définition dans la première moitié du document, l’exemple d’utilisation dans la seconde. Le chunk renvoie la seconde sans la première. Donner à l’IA un texte dont la moitié du sens manque et lui demander de répondre, c’est comme photocopier le bas d’une page et dire « lis ça ».

Troisièmement, la boucle de correction ne finissait jamais. Ajuster la taille des chunks. Changer le modèle d’embedding. Ajouter du reranking. Mettre des filtres de métadonnées. Résoudre un problème en créait un autre. Le problème n’était pas les paramètres. C’était l’abstraction elle-même.

Les fichiers se lisent tels quels

Ce qu’on a fait après avoir abandonné RAG est d’une simplicité presque gênante.

On a rangé les documents.

L’information nécessaire dans des fichiers markdown structurés. Des noms de fichiers compréhensibles. Une arborescence logique. Et on a dit à l’IA : « lis ce répertoire ».

C’est tout.

Pas d’embeddings. Pas de base vectorielle. Pas de chunking. Pas de pipeline de synchronisation. Quand un fichier est mis à jour, la prochaine lecture reflète la mise à jour. Le problème de synchronisation n’existe pas — parce que le système de fichiers est la synchronisation.

« Mais si les données sont trop volumineuses ? »

La plupart du temps, elles ne le sont pas.

Toute la documentation de notre projet tient en quelques Mo. Pas besoin de tout charger dans le contexte. Il suffit de lire les fichiers pertinents. Si le chemin est connu — et que l’arborescence est logique — pas besoin de chercher. Naviguer suffit.

RAG devient nécessaire quand les données sont vraiment massives et qu’on ne sait pas où chercher. Des millions de documents. Des données non structurées. Des montagnes de logs. À cette échelle, la recherche est indispensable.

Mais d’après mon expérience, la plupart des équipes qui travaillent avec l’IA ne sont pas à cette échelle. Quelques dizaines à quelques centaines de documents. Un codebase conséquent, certes, mais l’information dont l’IA a besoin à un instant donné est limitée. Pour cette information limitée, on fait tourner cinq systèmes ?

Le problème des corrections

Il y a un autre problème avec RAG dont on parle rarement. La boucle de feedback.

L’IA donne une réponse fausse. L’utilisateur corrige. « Non, les permissions se configurent comme ça. »

Avec des fichiers structurés, on ouvre le fichier, on corrige. La prochaine fois que l’IA le lit, l’information est à jour. Du feedback à la correction : une édition.

Avec un pipeline RAG ? D’abord corriger le document source. Puis re-chunker. Re-vectoriser. Supprimer les anciens vecteurs. Stocker les nouveaux. Et prier pour que le bon chunk remonte en tête au prochain search — parce qu’il n’y a aucune garantie que le chunk corrigé sera le premier résultat.

Une correction, cinq étapes. Et la dernière est probabiliste.

C’est le problème fondamental de RAG. La recherche est probabiliste, donc la correction l’est aussi. Il y a un écart entre « c’est corrigé » et « la correction est reflétée ». Cet écart grandit avec la complexité du pipeline.

La bonne abstraction

Je ne dis pas que RAG a tort. RAG est la bonne solution pour un problème précis : trouver de l’information dans un volume vraiment massif de données non structurées.

Le problème, c’est que la plupart des équipes n’ont pas ce problème et déploient RAG quand même.

Un cabinet comptable veut que l’IA lise les dossiers clients. RAG nécessaire ? Quelques centaines de dossiers. On les met dans des dossiers et on laisse l’IA lire. Un cabinet d’avocats veut chercher dans la jurisprudence. Des dizaines de milliers de décisions. Là, RAG a du sens.

La distinction est simple. Si la navigation dans le système de fichiers suffit, RAG est excessif. Si la navigation ne suit plus, RAG est nécessaire.

On était dans le premier cas. La plupart des équipes aussi.

La complexité d’infrastructure a une inertie. Une fois construite, on hésite à la supprimer. « On l’a déjà fait » devient une raison de la garder. Mais le coût de maintenance dépasse largement celui de ranger ses fichiers.

Quatre scripts shell et des fichiers markdown ont battu une base vectorielle. La raison : la simplicité. Un système simple casse moins, se répare plus vite, se comprend plus facilement. Et pour l’IA — se lit mieux.

La meilleure infrastructure est celle qui n’existe pas.

— Max