Le découpage en chunks de la base de connaissances, c'est là que meurt la qualité de votre RAG
La plupart des mauvaises réponses RAG sont un problème de récupération, pas de modèle. Le découpage détermine la qualité des Bedrock Knowledge Bases.

Quand un système RAG donne une réponse fausse ou à moitié correcte, le modèle n'en est généralement pas la cause. C'est le découpage en chunks. Si le passage qui contient la réponse n'arrive jamais dans le contexte récupéré, aucun modèle ne peut répondre à partir de lui, et aucun réglage de prompt n'y changera rien. Le découpage en chunks détermine ce qui peut être récupéré, ce qui en fait la première chose à inspecter et la dernière que la plupart des équipes examinent.
Amazon Bedrock Knowledge Bases vous permet de choisir une stratégie de découpage lors de la création d'une source de données. Ce seul choix fixe silencieusement le plafond de la qualité de votre récupération. Faites une erreur et vous passerez des semaines à blâmer le modèle d'embedding, le reranker, ou le LLM pour un problème qui réside dans la façon dont vous découpez les documents.
Pourquoi le découpage en chunks est la décision structurante
La récupération fonctionne sur des chunks, pas sur des documents. Chaque chunk est transformé en vecteur, et au moment de la requête, vous récupérez les k chunks les plus proches de la question. Deux modes de défaillance découlent directement de la taille des chunks.
Les chunks trop grands diluent l'embedding. Un chunk de 2000 tokens couvrant quatre sous-thèmes produit un vecteur qui est la moyenne des quatre, si bien qu'il correspond faiblement à tout et fortement à rien. Le bon chunk se retrouve enseveli sous des correspondances approximatives. Les chunks trop petits coupent le contexte. Une définition séparée de son exemple, ou une étape séparée de son avertissement, se récupère proprement mais arrive sans le texte environnant qui la rendait utile. La réponse est techniquement présente et pratiquement incomplète.
Le travail d'une stratégie de découpage est de couper sur des frontières significatives afin que chaque chunk soit une idée cohérente, suffisamment autonome pour répondre et suffisamment spécifique pour bien se classer.
Les trois stratégies que propose Bedrock
Découpage à taille fixe
Découpe toutes les N tokens avec un certain chevauchement. C'est l'option par défaut et la moins chère, et elle convient pour un contenu uniforme, riche en prose, où les changements de sujet sont progressifs. Elle est franchement mauvaise pour les documents structurés, parce qu'elle coupe où le compteur de tokens tombe : au milieu d'un tableau, au milieu d'une liste, entre un titre et le paragraphe qu'il introduit. Le chevauchement atténue les dégâts mais ne les élimine pas. Choisissez le découpage à taille fixe quand votre corpus est homogène et que vous voulez une référence de base, pas parce que c'est l'option par défaut.
Découpage sémantique
Découpe selon le sens. Le découpage sémantique mesure la similarité d'embedding entre phrases adjacentes et commence un nouveau chunk là où le sujet change, de sorte que les frontières tombent entre les idées plutôt qu'à un nombre de tokens fixe. C'est le bon choix par défaut pour un contenu mixte : FAQ, articles de connaissance, prose mixte où chaque réponse ou concept doit rester entier. Cela coûte plus cher à construire dans l'index parce qu'il fait des embeddings pendant qu'il découpe, mais la différence de qualité de récupération sur des corpus hétérogènes justifie ce coût.
Découpage hiérarchique
Construit des chunks parents et enfants. Les petits chunks enfants sont transformés en embeddings et mis en correspondance pour une récupération précise, mais c'est le chunk parent, plus grand, qui est renvoyé au modèle, si bien que vous classez sur la spécificité et répondez avec le contexte. Cela convient aux documents ayant une vraie structure, manuels techniques, contrats juridiques, tout ce qui a des sections et des sous-sections, où une requête touche une clause étroite mais le modèle a besoin de la section environnante pour l'utiliser correctement. C'est le plus complexe à raisonner et le meilleur choix quand vos documents ont une hiérarchie réelle à exploiter.
Évaluez la récupération avant de blâmer le modèle
L'habitude la plus utile est de séparer la question de récupération de la question de génération. Avant de toucher au prompt ou de changer de modèle, posez-vous une seule question : pour un ensemble de questions réelles, le chunk contenant la réponse est-il apparu dans le contexte récupéré ?
- Construisez un petit ensemble d'évaluation : 30 à 50 questions réelles, chacune avec le passage source qui y répond.
- Exécutez uniquement la récupération. Pour chaque question, vérifiez si le passage correct apparaît dans les k premiers résultats. Ce taux de réussite est votre plafond de récupération.
- Si le passage correct n'est pas récupéré, la qualité de la génération n'a aucune importance. Le correctif se trouve dans le découpage, les embeddings, ou le top-k, pas dans le modèle.
- Ce n'est que lorsque la récupération fait remonter fiablement le bon passage qu'il devient pertinent de travailler sur la façon dont le modèle l'utilise.
La plupart des équipes sautent cette étape et se jettent directement sur l'ingénierie de prompt, ce qui explique pourquoi elles passent tant de temps sur un problème qu'une mesure du taux de réussite de récupération aurait localisé en un après-midi. Si la récupération manque la réponse une fois sur deux, vous avez un problème de découpage déguisé en problème de modèle.
Un point de départ pratique
Commencez par le découpage sémantique pour le contenu de connaissance générale, passez au découpage hiérarchique quand vos documents ont une structure de sections claire et que les réponses dépendent du contexte environnant, et gardez le découpage à taille fixe uniquement pour de la prose volumineuse et uniforme où vous voulez de la rapidité et de la simplicité. Mesurez ensuite le taux de réussite de récupération, changez une variable, et mesurez à nouveau. Le découpage n'est pas une valeur de configuration qu'on règle une fois pour toutes. C'est le levier qui a le plus d'influence sur la qualité réelle de votre système RAG.
Ce qu'il faut retenir
La qualité du RAG se joue avant même que le modèle ne tourne, au moment où vous découpez vos documents en chunks. Le découpage à taille fixe est une référence de base, le découpage sémantique est le choix par défaut sensé pour un contenu mixte, et le découpage hiérarchique l'emporte quand la structure compte. Mesurez d'abord le taux de réussite de récupération sur un ensemble de questions réelles, parce que si la réponse n'entre jamais dans le contexte, le modèle n'a jamais été le problème.
À lire ensuite
- Bedrock Guardrails Won't Save You From Prompt Injection, sur un autre endroit où le modèle est blâmé pour un problème d'architecture.
- Cutting Amazon Bedrock Knowledge Base Costs by ~90%, sur le magasin de vecteurs sous la même Knowledge Base.
Pour le volet stockage et infrastructure de la recherche vectorielle à grande échelle, les notes de terrain cloud se trouvent sur ercan.cloud, et le hub est sur ercanermis.com.
Plus d'Ercan
Deux autres sites, même auteur, terrain différent.
Cloud, AWS, EKS, Terraform, plateforme.
Notes de terrain de systèmes de production. EKS, IAM, Terraform à l'échelle organisation, observabilité, optimisation des coûts.
Visiter ercan.cloud →Le hub. À propos, conseil, contact.
Hub personnel pour les deux pistes d'écriture. Qui je suis, comment fonctionne le conseil, comment me joindre.
Visiter ercanermis.com →