Chunking et base vectorielle

Imaginez que vous cherchiez une recette de crêpes et qu'on vous tende toute la bibliothèque municipale en disant "c'est quelque part là-dedans". Techniquement, l'information est bien présente. En pratique, vous n'êtes pas plus avancé.

C'est exactement le problème qu'on rencontre avec un RAG sur 100 000 documents. On ne peut pas tout envoyer au modèle : ça ne rentrerait pas dans sa mémoire de travail, ça coûterait une fortune, et noyer la bonne information dans des milliers de pages inutiles dégrade la réponse.

Même à l'échelle d'un seul document, le problème reste entier. Un PDF de 80 pages qui parle d'architecture, de sécurité et de facturation, c'est un seul point sur la carte du sens, placé quelque part au milieu de tous ces sujets. Si la question porte sur la facturation, ce point "moyen" ne sera pas forcément le plus proche.

La solution : on découpe. Chaque document est coupé en morceaux, les fameux chunks, de quelques paragraphes chacun :

Document
├── chunk 1
├── chunk 2
├── chunk 3
└── ...

Chaque chunk reçoit son propre embedding, et tous ces vecteurs sont rangés dans une base vectorielle, une base de données spécialisée pour retrouver très vite les points les plus proches d'un point donné. Quand une question arrive, on calcule son embedding, on demande à la base les cinq ou dix chunks les plus proches, et seuls ceux-là partent vers le modèle.

Sur le papier, c'est simple. Dans la vraie vie, la façon de découper est l'un des réglages qui influencent le plus la qualité d'un RAG. Des chunks trop petits, et vous récupérez une phrase sans son contexte ("la valeur doit être inférieure à 30"... 30 quoi ? de quoi ?). Des chunks trop gros, et vous retombez sur le problème du PDF entier : beaucoup de bruit autour de l'information utile. Et un découpage aveugle, tous les 1 000 caractères par exemple, finira fatalement par couper un tableau en deux ou séparer un titre de son paragraphe.

C'est pour ça qu'on découpe de préférence en suivant la structure du document (titres, sections, paragraphes), souvent avec un léger chevauchement entre deux chunks. Et on ajoute des métadonnées à chaque morceau : document d'origine, date, auteur, projet, droits d'accès. Elles permettent de filtrer ("uniquement la doc du projet X, version actuelle") et de ne jamais montrer à quelqu'un un passage qu'il n'a pas le droit de lire.

Trouver les bons morceaux améliore énormément les réponses, mais ça ne garantit toujours pas que le modèle dira vrai. Pourquoi une IA peut-elle encore inventer quelque chose alors qu'on vient de lui donner les bons documents ? Pour répondre, il faut d'abord comprendre pourquoi elle hallucine, et c'est le sujet du prochain post.