Chunking : découper intelligemment
Un règlement de 40 pages ne se cherche pas d'un bloc. On le découpe en petits morceaux — les chunks — et toute la difficulté tient en une question : où couper ?
Pourquoi découper ?
Rappelez-vous l'objectif final : quand un employé demande « Combien de jours de télétravail par semaine ? », on veut fournir à l'IA le passage qui répond — pas le règlement entier. Deux raisons à cela :
- La précision de la recherche. Plus un texte est long, plus il mélange de sujets (congés, télétravail, frais…). Un document entier « ressemble un peu à tout », donc la recherche ne sait plus le distinguer. Un paragraphe ciblé, lui, parle d'une seule chose.
- La place disponible. Le message qu'on envoie à l'IA a une taille limitée (et facturée). On ne peut y glisser que quelques extraits — autant qu'ils soient courts et denses en information utile.
Pensez à des fiches de révision. Recopier tout le manuel sur une seule fiche ne sert à rien ; découper le manuel en fiches d'une idée chacune, si. Le chunking fabrique exactement cela : une pile de fiches à partir de vos documents.
La bonne taille : un compromis
Il n'y a pas de taille magique, mais il y a deux excès faciles à comprendre :
- Trop grand (plusieurs pages) : le chunk mélange les sujets, la recherche devient floue, et il gaspille la place dans le message envoyé à l'IA.
- Trop petit (une phrase isolée) : le morceau perd son contexte. « Elle est limitée à deux jours par semaine » — de quoi parle-t-on ? Sans la phrase précédente, l'extrait est inutilisable.
En pratique, on démarre souvent autour de 500 à 1 000 caractères par chunk (grosso modo un ou deux paragraphes), puis on ajuste en observant la qualité des réponses. Les textes très structurés (FAQ, articles de loi) supportent des chunks courts ; les textes argumentatifs préfèrent des chunks plus longs.
Le chevauchement (overlap) : ne jamais couper une idée en deux
Où qu'on coupe, on risque de tomber au milieu d'une idée : la règle des deux jours de télétravail commence à la fin du chunk 1 et se termine au début du chunk 2 — et aucun des deux morceaux ne contient l'information complète.
La parade est simple : faire se chevaucher les chunks. On répète les dernières lignes d'un chunk au début du suivant — typiquement 10 à 20 % de sa taille. Ainsi, toute phrase coupée par une frontière existe entière dans au moins un des deux morceaux. Le coût : un peu de stockage en double. Le gain : plus aucune idée perdue à la découpe.
Trois façons de couper
Toutes les découpes ne se valent pas. Les trois grandes familles, de la plus simple à la plus fine :
| Stratégie | Principe | Pour qui ? |
|---|---|---|
| Taille fixe | On coupe tous les N caractères, sans regarder le contenu. Simple et prévisible, mais coupe parfois au milieu d'une phrase (d'où l'overlap). | Le point de départ par défaut, suffisant dans beaucoup de cas. |
| Par structure | On coupe aux frontières naturelles du document : titres, sections, paragraphes, questions d'une FAQ. Chaque chunk correspond à une unité de sens voulue par l'auteur. | Documents bien structurés : règlements, documentation, contrats. |
| Sémantique | Un algorithme détecte les endroits où le sujet change, et coupe là. Plus coûteux à calculer, mais donne les morceaux les plus cohérents. | Textes longs et peu structurés : transcriptions, e-mails, comptes-rendus. |
Conseil pratique : commencez simple — découpage par paragraphes, ~800 caractères, overlap de 15 %. Testez avec de vraies questions, regardez quels chunks ressortent, et n'affinez que si les réponses le justifient. Le chunking parfait n'existe pas ; le chunking « suffisant pour vos questions », si.
Sur notre exemple
Le règlement intérieur de notre PME (40 pages) devient environ 120 chunks d'un paragraphe chacun. L'un d'eux contient exactement ceci :
C'est ce chunk — court, autonome, étiqueté — que la recherche devra retrouver au chapitre 4. Mais pour qu'une machine puisse le « retrouver », il faut d'abord le traduire dans son langage : des nombres. C'est l'objet du prochain chapitre.