Assemblage du contexte et budgets de preuve

Regarder la vidéo

1 · La compétence

Prenez q30 ou q63 et suivez-la de bout en bout — des sources trouvées par la récupération jusqu’à l’assemblage du contexte et au budget du prompt.

• Assemblage du contexte : l’étape qui transforme les résultats du backend en texte réellement lu par le modèle qui répond. Dans ce système, cette étape s’exécute sur quatre canaux — résumé, vecteur, plein texte et graphe — et build_context() accorde à chaque canal alimenté une part équitable max-min d’un budget exprimé en caractères. Il écarte autant que possible les éléments récupérés entiers, indique ce qui a survécu et évite qu’un canal soit privé de budget tant qu’un autre dispose encore d’une marge. Chaque élément de résumé, vectoriel et plein texte est plafonné à 1 200 caractères ; le contexte du graphe à 6 000 ; et le budget combiné max_context_chars est de 32 000 caractères par défaut (configurable de 1 000 à 50 000).
• Taille des chunks et budget de contexte : la découverte précédente sur l’indexation est distincte : l’indexeur unifié utilise des chunks de 500 tokens pour Qdrant/Meilisearch/résumé et des chunks de 1 200 tokens pour LightRAG. Ce sont des tailles en tokens définies lors de l’indexation, pas le budget en caractères du modèle de réponse. Passer de 500 à 800 nécessiterait de réindexer les documents ; cela ne modifierait pas à lui seul la limite de contexte de réponse de build_context().
• Budget de preuves : la limite de contexte que vous pouvez vous permettre, fixée par le nombre de caractères, les tokens, la latence ou le coût.
• Survie de la source : la preuve réellement nécessaire à la réponse est-elle encore présente après le formatage et la troncature ? Le commentaire du code qui décrit l’approche remplacée le dit sans détour : l’ancienne concaténation à ordre fixe signifiait que « la position, pas la pertinence » décidait de ce qui atteignait le modèle — le bloc du graphe était toujours en dernier, donc toujours le premier perdu.
• Ce n’est pas le même chemin que les leçons 5 à 8 : ces leçons utilisent --mode retrieval, qui appelle /api/v1/search — sans aucune fusion, une simple concaténation. Cette leçon utilise --mode answer, qui appelle /api/v1/qa et applique une véritable allocation équitable par canal. Ne transposez pas ici le « pas de fusion » appris à la leçon 8 — il ne s’applique pas.

Lecture principale : Contextual Retrieval d’Anthropic

2 · Exécuter la boucle de preuve

cd demo
python3 eval.py run --mode answer --workspace meridian_demo --category multi_hop --tag lesson-09-context

Pour chaque source, examinez ces champs dans le rapport par question plutôt que de deviner à partir de la réponse affichée :

• results[].answer.stats.context_chars_by_index — combien de caractères de chaque canal (summary/vector/fulltext/graph) sont réellement entrés dans le prompt.
• results[].answer.stats.max_context_chars — le budget combiné configuré en caractères ; l’API actuelle utilise 32000 par défaut, et non la taille des chunks d’indexation.
• results[].answer.stats.context_items_included et .context_items_dropped — la seconde clé n’apparaît que si quelque chose a été écarté ; les éléments sont ventilés par canal.
• results[].answer.stats.context_hard_truncated — devrait être absente ou à false ; si elle vaut true, le filet de sécurité de l’allocation équitable a dû trancher en plein milieu d’une chaîne, ce que la conception est censée rendre impossible.
• results[].answer.sources et .source_hit.all — les citations qui ont réellement survécu, et si elles couvrent toutes les sources attendues.

Si la troncature coupe une source avant la génération, le modèle ne la voit jamais : l’avoir trouvée pendant la récupération ne compte plus. Pour une question multi-étapes en particulier, vérifiez d’abord context_chars_by_index.graph et si graph apparaît dans context_items_dropped — cela indique si la preuve de connexion a même survécu jusque dans le prompt, avant de conclure que le modèle a mal raisonné sur des preuves qu’il possédait pourtant déjà.

3 · Fiche de décision

4 · Exercice de récupération

5 · Livrable et prochaine action

1. Enregistrez la sortie de commande ou un rapport de synthèse.
2. Complétez la fiche de décision.
3. Notez un cas d’échec et ce que vous vérifierez ensuite.

Une carte de survie des preuves pour une réponse multi-étapes, accompagnée d’une recommandation de budget de contexte délimitée et défendable.

Prochaine étape : leçon 10 — prompts qui répondent uniquement à partir des preuves.

Posez-moi vos questions sur les preuves, l’indicateur, le cas d’échec ou l’expérience que vous souhaitez tenter ensuite. Je suis votre enseignant pour cette formation.