Diviser les documents en parties selon les éléments de preuve nécessaires à une réponse

Imaginez demander à un manuel de déploiement quand un service doit être ramené en arrière. La recherche renvoie l’instruction de rollback, mais l’exception se trouve dans le chunk suivant : cette instruction n’est applicable qu’après échec d’un contrôle de santé particulier. Le texte obtenu est pertinent, mais la réponse peut néanmoins être fausse.

C’est là le problème central du chunking. L’unité facile à indexer peut différer de l’unité suffisante pour expliquer quelque chose.

Au préalable de mettre au point un modèle d’embedding, examinez ce que vos chunks permettent au modèle de voir.

Commencez par la structure que vous avez réellement

Pour un article technique, un titre et ses paragraphes constituent un point de départ logique. Un exemple de code doit être accompagné de l’explication de ses hypothèses. Une table nécessite suffisamment d’étiquettes pour interpréter les valeurs. Une exception doit être placée près de la règle qu’elle modifie.

Cela dépend de la récupération d’un texte source fiable. Si votre analyseur a déjà transformé un tableau en une séquence ambiguë, de plus petits fragments ne feront qu’augmenter cette ambiguïté.

Une première approche pratique consiste à diviser le texte aux limites des sections, à regrouper les paragraphes adjacents dans un cadre de taille défini, et à séparer les sections trop volumineuses aux limites des phrases. Les blocs de code et les tableaux nécessitent un traitement spécial lorsqu’ils dépassent cette limite ; il faut préserver leur structure et répéter les étiquettes nécessaires à l’interprétation de chaque partie.

Ce n’est qu’un schéma de base, pas l’optimum universel. Un glossaire et un rapport d’incident organisent les éléments de manière différente.

Utilisez la superposition pour une raison précise

L’overlap peut permettre de conserver une phrase qui, sinon, dépasserait une limite. Il introduit également du texte répété. Avec un overlap suffisant, plusieurs résultats de premier plan peuvent contenir pratiquement le même paragraphe, épuisant ainsi le budget de contexte sans ajouter d’informations utiles.

Évaluez à la fois la couverture globale et la pertinence de chaque fragment. Si les cinq fragments récupérés expliquent tous le déclencheur de rollback mais qu’aucun ne mentionne l’exception, récupérer davantage du même texte ne résout pas le problème.

Après la récupération, identifiez les passages qui se chevauchent dans la même source et fusionnez-les ou supprimez les doublons avant de construire la requête. Conservez leurs emplacements d’origine afin que les citations restent traçables.

Récupérez de manière ciblée et étendez-vous délibérément

Un court passage peut constituer un bon objet de recherche, car il se concentre sur une seule idée. La section qui l’entoure peut offrir un meilleur contexte de génération, puisqu’elle fournit des définitions et des précisions.

Une approche consiste à attribuer à chaque petit fragment un identifiant de section parente. On recherche d’abord les unités plus petites, puis on développe les résultats sélectionnés dans leurs sections parentes lorsque la réponse nécessite plus de contexte. Cette expansion requiert néanmoins des ressources ; charger tout le document pour chaque résultat ne fait qu’ajourner le problème initial.

Pour le manuel de déploiement, un résultat de recherche peut indiquer la condition de rollback. La section parente peut alors fournir l’exception ainsi que les étapes de récupération. Ainsi, la réponse obtient une explication cohérente sans que le système de recherche ait à trier un énorme fragment de document.

Comparer les configurations présentant les mêmes questions

Créez des questions qui mettent en évidence les limites : une définition, une comparaison entre paragraphes, une recherche dans un tableau, ainsi qu’une règle avec une exception. Indiquez les éléments de preuve requis pour chaque réponse.

Comparez une version de base simple à taille fixe avec votre version tenant compte de la structure. Gardez le corpus, les questions et le budget de contexte final inchangés. Vérifiez si chaque configuration permet d’obtenir suffisamment de preuves, quel niveau de duplication elle introduit, et quelles réponses restent impossibles à partir du contexte fourni.

N’confondez pas les mots avec les tokens du modèle lors de la définition des budgets de production. Un séparateur de comptage de mots est pratique pour un prototype ; l’instruction finale doit correspondre au tokenizer et aux limites du modèle qui la traite.

Lorsque les unités de preuves sont fiables, la recherche hybride peut aider les utilisateurs à les trouver grâce tant à une terminologie précise qu’à un langage courant. Une meilleure récupération des informations est particulièrement utile lorsque les extraits retournés méritent déjà d’être lus.