Chunker de vrais documents d'entreprise : ce qui a cassé, et pourquoi
Tous les tutoriels RAG sont d'accord : découper les documents sur les titres, viser des chunks de 500 à 800 tokens, attacher des métadonnées. Ça fonctionne à merveille sur de la documentation écrite par des gens qui utilisent des titres. Puis j'ai pointé le pipeline vers notre véritable espace Notion.
À quoi ressemblent les vrais documents
Trois choses ont cassé immédiatement.
Les tableaux géants. Notre équipe ops maintient une page Notion qui n'est qu'un unique tableau énorme — des centaines de lignes de données fournisseurs. Le découpage par titres a vu un seul bloc et produit un chunk très au-delà de la limite de tokens, ensuite tronqué au milieu d'une ligne. Le retrieval renvoyait avec assurance le premier tiers d'un tableau, et rien d'autre.
Les pages qui ne sont que des puces. Les ingénieurs écrivent leurs comptes rendus de réunion en listes à puces plates, sans aucun titre. Le splitter retombait alors sur un chunk par page : une question sur une décision prise en réunion récupérait la réunion entière — ou la ratait, parce que la puce pertinente était noyée parmi quarante autres sans rapport.
Le français et l'anglais mélangés. Nous sommes une entreprise française ; les documents changent de langue au milieu d'une page, parfois au milieu d'une phrase. Les chunks à cheval sur une frontière de langue produisaient des embeddings étranges et étaient moins bien récupérés que dans l'une ou l'autre langue seule.
Ce que j'ai essayé
Trois stratégies, dans l'ordre :
- Fenêtres fixes (512 tokens, 15 % de chevauchement). La baseline bête. Jamais catastrophique, jamais bonne — elle coupe joyeusement les tableaux et les phrases n'importe où.
- Par titres, ~600 tokens, avec métadonnées. Découper sur les titres quand ils existent, subdiviser les sections trop grosses, et préfixer chaque chunk du titre de la page et du chemin de section. Les tableaux sont aplatis ligne par ligne avec l'en-tête répété. Cela a complètement corrigé l'échec des tableaux tronqués.
- Chunking par fil de discussion pour le contenu conversationnel. Les notes de réunion et tout ce qui ressemble à du chat sont chunkés par fil thématique plutôt que par titre, en gardant chaque décision avec son contexte.
Comment je l'ai mesuré
J'ai construit un jeu d'évaluation de 30 questions à partir de vraies questions posées par des collègues, chacune étiquetée avec le document qui contient la réponse. La métrique est un simple hit-rate : le bon document figure-t-il dans les cinq premiers chunks récupérés. Il tourne en CI ; tout changement du pipeline qui fait baisser le hit-rate bloque le merge, exactement comme un test unitaire qui échoue.
Les fenêtres fixes : 60 %. Par titres avec métadonnées : 83 %. En ajoutant le chunking par fil pour les notes : 90 %.
La conclusion honnête
J'ai passé un week-end à évaluer des modèles d'embedding avant tout cela. Changer de modèle déplaçait le hit-rate de deux ou trois points. La stratégie de chunking l'a déplacé de trente. Si votre retrieval est mauvais, regardez ce que vous donnez à l'embedder avant d'aller chercher un meilleur modèle.