Le chunking est la décision de récupération que tout le monde prend par accident

Il y a un moment au début de chaque projet de récupération où quelqu'un tape un nombre. Cinq cents jetons. Mille. Quel que soit le tutoriel utilisé. Le pipeline fonctionne, la démo répond aux questions et ce numéro n'est plus jamais examiné.

Cela mérite plus d’attention qu’il n’en reçoit, car le chunking n’est pas un détail de prétraitement. C'est la décision qui détermine quels faits peuvent un jour être récupérés ensemble, et aucun classement intelligent en aval ne peut restaurer une relation détruite par le regroupement.

Ce qui ne va pas, concrètement

Des morceaux trop petits fragmentent une seule idée en plusieurs morceaux. La réponse existe dans votre corpus, mais aucun morceau individuel n'en contient suffisamment pour paraître pertinent, donc rien n'obtient un score élevé et l'agent répond à la place à partir de ses propres hypothèses.

Les morceaux trop gros entraînent des matériaux sans rapport avec la pièce qui correspond. La récupération semble réussie, la fenêtre contextuelle se remplit de bruit et l'agent produit quelque chose qui concerne subtilement le mauvais paragraphe. Cet échec est pire que le premier, car il produit une production confiante plutôt qu’un écart évident.

De l’extérieur, les deux échecs semblent identiques : l’agent donne une réponse fausse d’une manière que personne ne peut expliquer immédiatement.

La structure bat la taille

Le changement le plus utile que nous voyons les équipes apporter est d’arrêter de penser au nombre de jetons et de commencer à penser à la structure des documents.

Un document de politique comporte des sections. Une archive de support a un problème par ticket. Une référence API a un point de terminaison par entrée. Ces limites ont été fixées par une personne pour la même raison que vous en avez besoin : elles marquent l'endroit où une idée s'arrête et où une autre commence. Le fractionnement sur eux, avec un plafond de taille comme solution de repli plutôt que la règle principale, surpasse systématiquement le fractionnement sur la seule longueur.

Lorsque les documents n’ont pas de structure utilisable, le chevauchement constitue une atténuation peu coûteuse. Carrying a sentence or two across the boundary costs storage and very little else, and it rescues the specific case where the key sentence lands one token past a split.

Les métadonnées sont sous-estimées

Un morceau n'est pas seulement du texte. Il s'agit d'un texte plus tout ce que vous savez sur son origine : le document auquel il appartient, le titre de la section au-dessus, la date à laquelle il a été rédigé, l'équipe qui le possède, s'il a été remplacé.

Ces métadonnées permettent à un agent de filtrer avant de se classer, ce qui représente généralement un gain de précision plus important que n'importe quel changement d'intégration. "Rechercher la version actuelle du manuel de conformité" est un problème fondamentalement plus simple que "rechercher tout et espérer que la version actuelle obtienne les meilleurs résultats".

Cela vous donne également une réponse à la question qui suit chaque sortie erronée : d'où cela vient-il. Un morceau qui porte sa provenance transforme le débogage de l'archéologie en une recherche.

Évaluez-le, n’en discutez pas

La stratégie de fragmentation est le genre de sujet qui génère de longues opinions et de courtes preuves. La solution est la même que partout ailleurs dans le travail d’agent : rédigez d’abord l’évaluation.

Rassemblez trente ou quarante vraies questions que les gens posent réellement à votre système, avec le passage qui doit répondre à chacune. Mesurez ensuite si ce passage est récupéré. Pas si la réponse finale se lit bien, ce qui confond récupération et génération, mais si le bon matériel a atteint le modèle.

Une fois cela en place, le découpage devient une expérience plutôt qu’un débat. Changez de stratégie, réexécutez l'ensemble, conservez la version qui récupère le plus. Les équipes qui construisent ce harnais dès le début ont tendance à cesser complètement d'avoir des disputes fragmentées, car il existe désormais un moyen peu coûteux de les régler.

Comment cela se connecte aux agents en cours d'exécution

La qualité de la récupération n'est pas une préoccupation distincte du fonctionnement de l'agent. Un changement de récupération qui ajoute deux cents jetons à chaque appel est un changement de coût, et un changement de récupération qui améliore le rappel est un changement de qualité. Les deux appartiennent à la même boucle d’évaluation que tout ce que fait l’agent.

C'est pourquoi les évaluations d'Oran évaluent ensemble les critères comportementaux, structurels, de latence et de coût, et pourquoi l'Optimizer mesure ses propres changements par rapport à ces mêmes évaluations. Réduire le contexte pour économiser de l'argent n'est une économie que si la récupération trouve toujours ce dont elle a besoin.

Par où commencer

Si vous disposez déjà d'un système de récupération en production et d'aucun ensemble d'évaluation, créez d'abord l'ensemble d'évaluation, même rudimentaire. Il vous en dira plus en une après-midi qu'en un mois de réglage. La documentation du développeur couvre les mécanismes et les pages du système d'orchestration d'agent expliquent comment les couches d'évaluation et de coûts s'y adaptent.