Choisir les limites de segmentation RAG et le chevauchement pour préserver le contexte des sections

Choisir l'unité qui préserve la réponse

L'objectif principal du découpage est de garantir que chaque segment contient suffisamment de contexte pour répondre de manière indépendante aux requêtes potentielles. Comme indiqué dans le guide RAG de Microsoft, des segments trop petits et dépourvus de contexte suffisant conduisent à de mauvais résultats. Dans notre exemple hypothétique de note de support - « Retour : les articles non ouverts peuvent être retournés dans un délai de 14 jours. Garantie : les défauts de fabrication sont couverts pendant 12 mois. » - une requête sur l'éligibilité au retour dépend à la fois de la condition (non ouvert) et du délai (14 jours). Si une frontière de segmentation divise « dans » et « 14 jours », la récupération pourrait manquer la condition complète.

Choisissez une unité qui conserve ensemble la condition pertinente et sa durée, tout en respectant la limite réelle d'entrée du modèle d'embedding. La structure du document et le nombre de tokens comptent tous deux : une longue section peut encore nécessiter une division. Une règle courte et complète constitue un point de départ utile, sans garantir que le moteur de recherche la retrouvera.

Conserver les titres avec leurs passages

Les titres de section fournissent un contexte essentiel pour interpréter le contenu. Lorsqu'un passage comme « les articles non ouverts peuvent être retournés dans un délai de 14 jours » apparaît sans le titre « Retour », sa signification devient ambiguë. La documentation RAG de Microsoft insiste sur la préservation du contenu sémantiquement pertinent, ce qui inclut l'association des titres avec leurs blocs de texte respectifs.

Associez le titre de la section à son passage. Stocker le titre uniquement comme métadonnée ne garantit pas son inclusion dans l'embedding ni sa présentation au modèle de langage. Si ce titre apporte un contexte nécessaire, incluez-le dans le texte utilisé pour l'embedding et dans le contexte transmis au générateur de réponse. Le dictionnaire ci-dessous illustre un segment stocké ; ce n'est pas une configuration complète d'index Azure.

chunk = {
  "text": "Returns: unopened items may be returned within 14 days.",
  "metadata": {"section": "Returns"}
}

Comparer deux frontières illustratives

Considérons deux segmentations illustratives de la note de support. D'abord, supposons qu'une frontière basée sur le caractère coupe la note au milieu d'un mot :

Segment 1 : « Retour : articles non ouverts peuvent être retournés aveci » Segment 2 : « n 14 jours. Garantie : les défauts de fabrication » Segment 3 : « sont couverts pendant 12 mois. »

Ici, la politique de retour est divisée entre les segments, risquant une récupération incomplète. Comparez maintenant une approche sensible au document qui utilise « Garantie : » comme frontière :

Segment A : « Retour : articles non ouverts peuvent être retournés dans un délai de 14 jours. » Segment B : « Garantie : les défauts de fabrication sont couverts pendant 12 mois. »

Cette version préserve intactes les deux politiques. Alors que la première méthode repose uniquement sur la taille, la seconde respecte la structure sémantique - un avantage clé souligné dans la guidance d'Azure sur le découpage variable et sémantique.

Choisir une taille initiale et un chevauchement

Azure AI Search recommande de commencer avec 512 tokens (~2000 caractères) et un chevauchement de 25 % (128 tokens) lors de l'utilisation du découpage fixe. Cela équilibre la continuité du contexte contre la redondance. Le chevauchement permet aux phrases coupées entre deux segments d'apparaître intégralement dans au moins un résultat.

Pour notre exemple, définir une taille de segment de 60 caractères avec un chevauchement de 15 caractères pourrait aider à faire le lien entre « dans » et « 14 jours ». Cependant, le chevauchement seul ne peut garantir la préservation de l'intention si l'unité logique s'étend sur plus d'un segment. Ainsi, bien que le chevauchement améliore la robustesse, il ne remplace pas la conscience structurelle.

Prendre en compte le contexte répété

Le chevauchement introduit du texte dupliqué, augmentant les coûts de stockage et d'indexation. Comme noté dans l'article RAG de Microsoft, certaines approches entraînent des coûts financiers et temporels plus élevés. Répéter les titres de section dans plusieurs segments ajoute également de la redondance mais améliore l'interprétabilité.

Dans notre cas, répéter « Retour : » au début de chaque segment sous cette section garantit la clarté, même si cela augmente l'utilisation de tokens. Le compromis privilégie la précision à l'efficacité lorsque la réponse correcte dépend du contexte.

Inspecter les réponses près des frontières

Après le découpage, tester des requêtes ciblant des informations proches des points de division probables. Par exemple, demander « Combien de temps puis-je retourner un article non ouvert ? » et vérifier si le segment récupéré inclut à la fois le sujet et la durée.

Puisqu'il s'agit d'un exemple hypothétique, aucun système de récupération réel n'est testé. Mais dans les implémentations concrètes, il est crucial d'inspecter les résultats autour des transitions structurelles - comme après les titres ou lors de divisions en milieu de phrase - pour valider la qualité du découpage, comme conseillé dans la documentation de découpage RAG.

Changer un seul paramètre à la fois

Lors de l'optimisation du découpage, ne modifier qu'une variable par itération - taille, chevauchement ou méthode d'analyse - pour isoler son effet. Par exemple, tester d'abord des segments fixes à 500 vs 1000 caractères, puis ajuster le chevauchement de 10 % à 25 %, en conservant les autres paramètres constants.

Cette approche systématique facilite une évaluation fiable, conformément à la recommandation de Microsoft d'expérimenter avec diverses permutations de découpage et d'observer les compromis avant de finaliser une stratégie.

Savoir ce qu'une vérification de découpage ne peut pas prouver

Visualiser les segments ou vérifier le chevauchement ne garantit pas l'efficacité de la récupération. Les frontières sémantiques n'impliquent pas automatiquement la pertinence, et aucune analyse statique ne prouve qu'un segment sera récupéré pour une requête donnée. Comme le note le guide Microsoft, votre approche de découpage est semi-permanente et influence les processus en aval, donc les hypothèses doivent être validées empiriquement.

Garder « Retour » avec sa politique facilite l'interprétation du passage, mais le récupérateur doit toujours le sélectionner et l'outil doit l'utiliser correctement. Inspectez les preuves récupérées et examinez les réponses générées pour plusieurs requêtes représentatives. Un bon résultat pour une requête ne garantit pas la fiabilité ; comparez plusieurs cas limites, y compris des questions dont les réponses sont absentes du document.