Correspondances entre affirmations et sources

Dans un système de recherche multi-agent, le coordinateur agrège les résultats de sous-agents qui ont chacun extrait des faits de documents différents. La réponse agrégée n'est fiable que si chaque affirmation peut être retracée jusqu'à son origine.

Une correspondance entre affirmation et source associe chaque énoncé factuel à son origine : l'URL, le nom du document, la citation exacte et la date de publication. Sans cette association, vous avez une affirmation qu'aucun réviseur humain ne peut vérifier et qu'aucun agent en aval ne peut auditer.

Pour l'examen d'Architecte, la traçabilité relève du domaine 4 (ingénierie des prompts et sortie structurée) et réapparaît dans le scénario 3 (recherche multi-agent) ainsi que dans le scénario 6 (extraction de données structurées).

Une correspondance de source doit toujours comporter quatre points d'ancrage afin qu'un humain ou un autre agent puisse retrouver et vérifier à nouveau les éléments probants :

• URL — l'emplacement du document (ou un identifiant stable).
• Nom du document — un titre compréhensible par un humain.
• Citation — le texte exact qui étaye l'affirmation, et non une paraphrase.
• Date de publication — la date à laquelle la source a été publiée ou mise à jour pour la dernière fois.

La citation exacte permet au réviseur de confirmer que le modèle n'a rien inventé ni exagéré. La date permet de résoudre les conflits ultérieurement, comme nous le verrons.

Ne demandez pas au modèle d'intégrer les citations dans un texte suivi où elles peuvent facilement être omises. Forcez plutôt une structure au moyen d'un schéma JSON via un outil. L'association de tool_use à un schéma élimine les erreurs de syntaxe et garantit la présence des champs obligatoires.

Chaque affirmation devient un objet qui contient ses propres points d'ancrage de source. C'est le fondement d'un relevé de traçabilité vérifiable.

Une règle subtile mais essentielle pour l'examen : marquez un champ comme obligatoire uniquement s'il est toujours présent dans la source. Si vous rendez obligatoire un champ qui peut être absent, le modèle fabriquera une valeur pour satisfaire le schéma.

Un billet de blog peut ne comporter aucune publication_date formelle ; un PDF interne peut ne comporter aucune source_url. Ainsi, claim, quote et document_name sont obligatoires (vous les avez toujours), tandis que source_url et publication_date restent facultatifs. Une date vide est honnête ; une date inventée constitue un échec de traçabilité.

Pour garantir que vous récupérez l'objet de traçabilité plutôt qu'un texte libre, contraignez le modèle avec tool_choice. La définition de {"type": "tool", "name": "record_claims"} force l'utilisation de cet outil précis, de sorte que chaque réponse arrive sous forme de JSON validé par le schéma.

Utiliser "any" garantirait qu'un outil quelconque est appelé ; forcer l'outil nommé constitue la garantie la plus stricte lorsque vous ne disposez que d'un seul outil d'extraction.

Exiger une citation exacte (et non une paraphrase) est un levier de fiabilité, pas une simple formalité. Lorsque le modèle doit recopier le texte justificatif exact, il lui est beaucoup plus difficile d'affirmer quelque chose que la source n'a jamais dit.

Renforcez cette consigne avec des critères explicites dans le prompt et 2 à 4 exemples en apprentissage par exemples. Ces exemples sont particulièrement efficaces pour le format de sortie, les cas limites et la réduction des hallucinations — le modèle généralise le schéma au lieu de simplement répéter vos exemples.

Dans un système de recherche en étoile, les sous-agents n'héritent pas de l'historique de conversation du coordinateur. Chaque sous-agent doit renvoyer ses résultats avec les correspondances de sources associées, car le coordinateur n'a aucun autre moyen de savoir d'où provient un fait.

Le coordinateur agrège ensuite ces objets d'affirmation autonomes. Si un sous-agent renvoie une simple phrase sans citation ni nom de document, ce fait devient invérifiable dès qu'il quitte le contexte du sous-agent — considérez-le comme dépourvu de traçabilité, et non comme un résultat valide.

Lorsque deux sources ne concordent pas sur une statistique, choisir silencieusement l'une d'elles est la mauvaise approche. La bonne approche consiste à signaler le conflit et à présenter les deux affirmations avec leurs sources.

Souvent, la date de publication résout la contradiction apparente : un chiffre de 2021 et un chiffre de 2024 ne sont pas contradictoires — ils constituent une série chronologique. C'est précisément pourquoi la date mérite sa place dans chaque correspondance. Conservez les deux chiffres, étiquetez-les et laissez un humain (ou une règle tenant compte des dates) trancher.

L'autocorrection consiste à extraire deux valeurs que vous pouvez comparer. Pour la traçabilité, demandez au modèle d'émettre chaque affirmation avec un indicateur précisant si une citation justificative a effectivement été trouvée, puis validez par programmation que chaque affirmation en comporte une.

Cela détecte l'échec silencieux d'une phrase assurée envoyée sans aucun élément probant. Ici, la validation est structurelle — ce qui convient parfaitement à une boucle de nouvelle tentative.

Si la validation détecte une lacune structurelle (citation manquante, date mal formée), utilisez une nouvelle tentative avec retour d'information : envoyez au modèle le document original, sa propre sortie incorrecte et l'erreur exacte de validation. Cette méthode corrige de manière fiable les erreurs de format et de structure.

Limite essentielle : une nouvelle tentative n'est pas utile lorsque l'information est simplement absente de la source. Si le document ne comporte réellement aucune date de publication, aucune nouvelle tentative ne la fera apparaître — et vous ne devez pas le permettre. Laissez le champ vide et continuez plutôt que de boucler indéfiniment.

Une fois les affirmations mises en correspondance, présentez-les dans le format adapté au contenu. Présentez les données financières sous forme de tableaux, les actualités sous forme de texte suivi et les résultats techniques sous forme de listes — avec leurs points d'ancrage de source visibles.

Pour la supervision humaine, une note de bas de page ou une colonne finale contenant le nom du document, la date et un lien permet une vérification immédiate plutôt qu'une enquête. Une traçabilité invisible est une traçabilité que personne ne vérifiera.

Points essentiels pour l'examen et les systèmes en production :

• Associez chaque affirmation à quatre points d'ancrage : URL, nom du document, citation exacte, date de publication.
• Imposez la structure avec tool_use + schéma JSON et forcez-la via tool_choice.
• Ne rendez un champ obligatoire que s'il est toujours présent — ne rendez jamais obligatoire un champ potentiellement absent, sinon le modèle le fabriquera.
• Les sous-agents n'héritent pas de l'historique ; chacun doit donc renvoyer des affirmations autonomes et traçables.
• Signalez les conflits ; laissez les dates résoudre les contradictions apparentes au lieu de choisir arbitrairement.
• Utilisez une nouvelle tentative avec retour d'information pour les lacunes structurelles — mais acceptez qu'une nouvelle tentative ne puisse pas fournir une information absente de la source.
• Présentez les informations selon leur type de contenu (tableaux/texte suivi/listes), avec les sources visibles pour la supervision humaine.