Chunking : bien découper ses documents pour un RAG n8n

Quand un chatbot RAG répond à côté, le réflexe est d'accuser le modèle ou le prompt. Dans la pratique, la cause se situe très souvent un cran plus tôt : au moment où les documents ont été découpés en morceaux avant d'être vectorisés. Un chunk trop grand noie l'information utile dans du remplissage ; un chunk trop petit prive le modèle du contexte nécessaire pour comprendre ce qu'il lit. Ce chunking est l'étape la moins visible d'un pipeline RAG — et l'une de celles qui conditionnent le plus la qualité des réponses. Voici comment le régler proprement dans n8n, en complément de notre guide complet du RAG avec n8n et Supabase.

Pourquoi le découpage conditionne la qualité des réponses

Un pipeline RAG repose sur un principe simple, formalisé par le papier fondateur de Lewis et al. présenté à NeurIPS 2020 (« Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks » — Google Scholar) : plutôt que de compter uniquement sur la mémoire paramétrique du modèle, on récupère des passages pertinents dans une base documentaire et on les injecte dans le contexte au moment de générer la réponse. Toute la chaîne dépend donc de la qualité de ces passages — c'est-à-dire des chunks.

Deux mécanismes de dégradation, symétriques :

• Chunk trop grand : l'embedding d'un fragment de 3 000 caractères qui parle de quatre sujets différents est une moyenne floue — la recherche vectorielle le retrouve mal, et quand elle le retrouve, elle injecte dans le prompt beaucoup de texte hors sujet autour de la phrase utile. Le signal est dilué.
• Chunk trop petit : une phrase isolée comme « ce délai est porté à 30 jours » est parfaitement retrouvable, mais inutilisable sans savoir de quel délai, quel contrat et quelles conditions il s'agit. Le contexte est perdu.

L'intuition « donnons au modèle un maximum de contexte, il fera le tri » ne tient pas non plus. L'étude de Liu et al. publiée dans TACL (« Lost in the Middle: How Language Models Use Long Contexts » — Google Scholar) montre que les performances des LLM se dégradent nettement quand l'information pertinente se trouve au milieu d'un long contexte, avec une courbe en U : ce qui est au début et à la fin est bien exploité, ce qui est noyé au milieu l'est beaucoup moins. Remonter peu de chunks pertinents et concis vaut mieux qu'inonder le prompt de contexte massif.

Les text splitters disponibles dans n8n

Dans n8n, le découpage se configure sur un sub-node de type Text Splitter, attaché au Data Loader qui alimente le vector store — la mécanique complète est décrite dans notre workflow d'ingestion PDF vers Supabase pgvector. Trois splitters sont disponibles :

Character Text Splitter

Le plus simple : il coupe le texte sur un séparateur unique (par défaut le double saut de ligne) en visant une taille cible. Prévisible et rapide, mais rigide — si votre document ne contient pas le séparateur au bon endroit, les chunks peuvent être très irréguliers. À réserver aux textes dont vous maîtrisez le format.

Recursive Character Text Splitter

Le choix par défaut recommandé. Il essaie une liste de séparateurs dans l'ordre — d'abord les paragraphes, puis les sauts de ligne simples, puis les phrases, puis les mots — et ne descend au niveau inférieur que si le fragment dépasse encore la taille cible. Résultat : des chunks qui respectent autant que possible les frontières naturelles du texte, sans phrase coupée en plein milieu quand c'est évitable.

Token Splitter

Il mesure la taille en tokens plutôt qu'en caractères. C'est utile quand vous devez garantir que chaque chunk tient dans un budget précis — la limite d'entrée du modèle d'embedding, ou un budget de contexte que vous voulez maîtriser au token près. Le comptage en tokens est plus fidèle à ce que « voit » réellement le modèle qu'un comptage en caractères.

Chunk size et chunk overlap : les ordres de grandeur

Deux paramètres à régler sur chaque splitter :

• Chunk size : les valeurs usuelles tournent autour de 500 à 1 000 caractères (ou 256 à 512 tokens) pour des cas de questions-réponses précises, et montent au-delà pour des tâches de synthèse où le modèle a besoin de passages plus longs. Plus vos documents sont denses (contrats, documentation technique), plus des chunks courts et ciblés sont payants.
• Chunk overlap : le chevauchement entre la fin d'un chunk et le début du suivant, typiquement 10 à 20 % de la taille du chunk. Sans overlap, une idée à cheval sur la frontière entre deux chunks n'existe en entier dans aucun des deux — et devient introuvable. Un overlap excessif, à l'inverse, gonfle la base et fait remonter des quasi-doublons.

Ces valeurs sont des points de départ : le bon réglage se teste (voir la dernière section). Le vector store lui-même — par exemple Supabase pgvector, dont la connexion est détaillée dans notre guide n8n + Supabase — est indifférent à la taille des chunks ; c'est la recherche et la génération qui en subissent les conséquences.

Le cas des documents structurés : titres, tableaux, FAQ

Un splitter générique traite le texte comme un flux uniforme. Or beaucoup de documents réels ont une structure qui porte du sens :

• PDF avec hiérarchie de titres : un chunk qui commence au milieu d'une section, sans son titre, perd une information de contexte précieuse. Une approche robuste consiste à découper d'abord par section (en s'appuyant sur les titres extraits), puis à appliquer le splitter à l'intérieur de chaque section — et à reporter le titre de section dans les métadonnées du chunk.
• Tableaux : découpés ligne à ligne par un splitter naïf, ils deviennent illisibles (des cellules orphelines sans en-têtes). Mieux vaut les extraire à part et les convertir en texte explicite — « ligne : produit X, colonne prix : 42 € » — avant vectorisation. Notre article sur l'extraction de données de factures PDF avec l'IA montre comment transformer ce type de contenu semi-structuré en données exploitables, avec un Structured Output Parser pour fiabiliser la sortie.
• FAQ et glossaires : le découpage naturel est la paire question-réponse (ou terme-définition), jamais une taille arbitraire. Une FAQ bien découpée est d'ailleurs le contenu qui donne les meilleurs résultats en RAG : chaque chunk est autosuffisant par construction.

La règle générale : plus le document a de structure, moins le découpage doit être automatique — dix minutes de préparation en amont s'y retrouvent largement en aval.

Ajouter des métadonnées aux chunks pour les citations

Un chunk n'est pas seulement du texte : le Data Loader de n8n permet d'y attacher des métadonnées stockées à côté de l'embedding dans la base vectorielle. Les trois champs qui changent tout :

• source : le nom ou l'identifiant du document d'origine ;
• page : le numéro de page pour un PDF ;
• section : le titre de la section d'où provient le chunk.

Ces métadonnées servent à deux choses. D'abord filtrer la recherche (ne chercher que dans un document ou un type de document donné). Ensuite — et surtout — citer les sources : quand le chunk remonte, ses métadonnées remontent avec lui, et le modèle peut formuler « selon la section 4.2 du contrat cadre, page 12… ». C'est exactement le mécanisme du chatbot RAG avec citations : une réponse sourcée est vérifiable, ce qui change radicalement la confiance qu'une équipe accorde à l'outil.

Évaluer empiriquement son découpage

Le chunking ne se règle pas à l'intuition. La méthode qui fonctionne :

1. Constituez un jeu de questions de test — 20 à 30 questions réalistes dont vous connaissez la réponse et le passage du document qui la contient.
2. Inspectez les chunks remontés, pas seulement la réponse finale : pour chaque question, la recherche vectorielle a-t-elle ramené le bon passage dans le top 3-5 ? Si le bon chunk ne remonte pas, aucun prompt ne sauvera la réponse. Un endpoint comme notre API question-réponse RAG rend ce test facile à scripter.
3. Faites varier un paramètre à la fois : chunk size, puis overlap, puis stratégie de découpage. Réindexez, relancez le même jeu de questions, comparez.
4. Outillez la comparaison avec les fonctionnalités d'évaluation de n8n, décrites dans notre article sur les évaluations pour tester ses workflows IA : un jeu de test rejouable transforme un réglage subjectif en décision mesurée.

Ce protocole tient en une après-midi et évite le piège classique : changer trois paramètres à la fois, constater une amélioration sur deux questions, et ne jamais savoir ce qui a réellement aidé.

Ce qu'il faut retenir

• Le chunking conditionne la qualité du RAG plus que le choix du modèle de génération : signal dilué si trop grand, contexte perdu si trop petit.
• Le Recursive Character Text Splitter est le bon défaut ; le Token Splitter quand le budget en tokens doit être garanti.
• Overlap de 10 à 20 %, chunks courts pour la précision, plus longs pour la synthèse — puis validation sur un jeu de questions de test.
• Les documents structurés (titres, tableaux, FAQ) méritent un découpage qui respecte leur structure, pas une taille arbitraire.
• Les métadonnées (source, page, section) transforment un chatbot opaque en assistant qui cite ses sources.

Le Pack Assistant RAG (119 €) livre cette chaîne complète prête à l'emploi — ingestion avec découpage et métadonnées, base vectorielle Supabase pgvector, chatbot avec citations et API de questions-réponses — il ne reste qu'à ajuster chunk size et overlap à vos documents avec la méthode ci-dessus.