Un article pratique paru cette semaine sur Towards Data Science, signé Priyansh Bhardwaj, explique pourquoi la plupart des pannes de RAG en production sont des pannes de chunking, pas des pannes de récupération ou de génération. L'insight qui ancre le texte est facile à citer : « Le LLM, c'est pas le goulot. Le goulot, c'est la décision sur où un chunk se termine pis où le suivant commence. » Le papier dépasse l'argument abstrait avec quatre modes de panne concrets pis des améliorations mesurées à partir d'une stratégie de chunking qui tient compte du type de document. Pour quiconque a livré un système RAG pis l'a vu retourner des réponses techniquement plausibles mais subtilement fausses, les modes de panne vont avoir l'air familiers.

Les quatre patterns que Bhardwaj pointe sont tous courants pis tous coûteux à déboguer. La coupure aux frontières logiques, c'est le pire : un chunk se termine avec « les sous-traitants suivent le processus d'intégration standard tel que décrit à la section 4 » pis le suivant commence avec « à moins d'être engagés sur un projet classé sous l'annexe B », produisant deux fragments, chacun faux en isolation, dont la combinaison risque jamais d'être reconstituée par le récupérateur. Les fenêtres de taille fixe en tokens (le 512 tokens avec 50 tokens de chevauchement qui traîne encore dans trop de stacks) coupent joyeusement des exceptions de trois paragraphes pis des listes numérotées en plein milieu, parce qu'elles sont aveugles à la structure. L'aplatissement des tableaux transforme des grilles en longues séquences de valeurs orphelines, détachées de leurs en-têtes. L'extraction PDF sans conscience du layout empile tout ça, parce que le flux de texte sous-jacent correspond plus à la structure visuelle sur laquelle l'auteur comptait.

Le remède recommandé est pas excitant pis exactement juste. Routez selon le type de document. Les documents structurés avec une hiérarchie claire (specs, runbooks) veulent du chunking hiérarchique pis AutoMergingRetriever. Le contenu narratif (politiques, guides, prose explicative) veut SentenceWindowNodeParser avec une fenêtre de contexte de 3 phrases. Le contenu mixte pis non structuré veut du chunking sémantique, avec la mise en garde honnête sur le coût en latence. Les PDFs pis les diapos ont besoin d'un prétraitement conscient du layout via PyMuPDF ou pdfplumber avant tout chunking. Le benchmark de Bhardwaj sur le basculement vers du contenu narratif est peu glamour mais réel : le rappel contextuel est passé de 0,72 à 0,88 pis la précision contextuelle de 0,71 à 0,83 juste en adaptant le découpeur à la forme du document. C'est le genre de chiffres que t'obtiens quand t'arrêtes de traiter RAG comme un problème de modèle pis que tu commences à le traiter comme un problème d'ingénierie de contenu.

Si ton système RAG est en production pis que t'as jamais instrumenté le chunking comme source de panne, c'est là que tu devrais regarder en premier. Gestes concrets : échantillonne 50 requêtes récentes où la réponse était fausse ou maigre, lis les chunks récupérés à la main, pis compte combien sont voués à l'échec seulement à cause des frontières de chunk, peu importe quel modèle génère à partir d'eux. Ce chiffre est presque toujours plus gros que ce que les équipes pensent. Le deuxième geste, c'est d'arrêter de traiter ton corpus comme homogène ; route par type de document, parce que le découpeur qui marche pour un PDF de 200 pages de politique marchera pas pour un catalogue de SKUs plein de tableaux. Ça va de pair avec le papier sur memweave d'hier. Les deux font le même point plus large sous deux angles. Les choix d'infrastructure qui ont l'air les plus excitants (bases vectorielles plus grosses, modèles plus récents, contextes plus longs) sont en général pas là où vivent tes problèmes de qualité. Les choix plates sur la façon dont tes données sont découpées pis indexées, eux, oui.