Citations vérifiées et abstention en RAG

Un système RAG incapable de dire 'je ne sais pas' est un risque, pas une fonctionnalité. Dans un fonds de private equity immobilier américain gérant environ 3 Md$ d'actifs, j'en ai livré un qui vérifie chaque citation et s'abstient quand la preuve est mince, car une réponse fausse et confiante près des comptes coûte plus cher qu'une réponse lente.

La leçon est tombée le jour où une démo a halluciné devant une responsable conformité. L'assistant a répondu à une question sur un document du fonds, a cité une source, et semblait totalement sûr de lui. La citation était réelle. Elle ne disait simplement pas ce que la réponse prétendait.

Le silence s'est fait dans la salle, et la personne dont le métier est d'attraper exactement ce genre d'erreur venait de voir une machine la produire sans sourciller. J'ai donc arrêté d'optimiser la couverture pour optimiser quelque chose de plus étroit et de plus dur : ne jamais avoir tort avec assurance. Voici la conception qui en est sortie, et pourquoi je la referais à l'identique.

Ce qu'est vraiment une citation vérifiée

Commençons par le mot que tout le monde emploie à la légère. Dans la plupart des systèmes RAG, une citation est un lien que le modèle a placé à côté de sa réponse. Personne n'a vérifié que ce lien étaye l'affirmation. Ça ressemble à une preuve, ce qui est pire que pas de preuve, car ça gagne une confiance qui n'a pas été méritée.

Le pipeline : récupérer, citer, vérifier, s'abstenir

Le système exécute les mêmes quatre étapes sur chaque question, et la dernière est un embranchement, pas une ligne d'arrivée.

Cette couche servait de couche de réponse partagée sous la plateforme à 11 agents du fonds, si bien que chaque agent qui lisait un document héritait des mêmes contrôles de citation au lieu de les réinventer.

Quand le système a le droit de refuser

L'abstention est une politique, pas une impression. Le système ne refuse pas parce qu'il se sent incertain. Il refuse quand la preuve est dans un état précis, et ces états sont écrits noir sur blanc.

Voici la version honnête de ce que fait un bot de prestataire face à ce que fait un système autorisé près des comptes, selon l'état de la preuve.

Comment on vérifie une citation, au lieu de juste l'attacher

Attacher une citation est facile. La vérifier, c'est le vrai travail, et c'est deux contrôles, pas un.

Le premier est l'implication, ou NLI : étant donné l'affirmation et l'extrait cité, l'extrait étaye-t-il l'affirmation, la contredit-il, ou ni l'un ni l'autre ? Un 'ni l'un ni l'autre' ne suffit pas. Neutre veut dire non étayé, et non étayé mène à l'abstention.

Le second, ce sont les chiffres. Les modèles de langage sont fluides avec les chiffres et faux avec eux. Si une affirmation énonce un montant, une date ou un décompte, il doit correspondre exactement à la source, pas 'à peu près'. En finance, 'à peu près' est la façon d'enregistrer un chiffre faux avec assurance.

type Verdict = 'supported' | 'contradicted' | 'insufficient'

// A claim ships only if the cited span survives BOTH checks.
async function verifyClaim(claim: Claim, span: SourceSpan): Promise<Verdict> {
  // 1. Entailment (NLI): does the source actually support the
  //    sentence, or does it just sit near it and look relevant?
  const relation = await nliCheck(claim.text, span.text)
  if (relation === 'contradiction') return 'contradicted'
  if (relation === 'neutral') return 'insufficient'

  // 2. Numbers: a figure in the claim must match the source to the
  //    digit. "Close" is a fabrication with good manners.
  if (claim.hasNumber && !numbersMatch(claim, span)) {
    return 'contradicted'
  }

  return 'supported'
}

// One failing claim abstains the WHOLE answer. No partial credit.
function decide(verdicts: Verdict[]): 'answer' | 'abstain' {
  return verdicts.every((v) => v === 'supported') ? 'answer' : 'abstain'
}

Deux lignes portent toute la conception. L'appel d'implication est ce qui sépare une citation vérifiée d'une citation décorative. Le contrôle numérique est ce qui empêche un paragraphe fluide de changer discrètement un chiffre.

Et la fonction de décision est volontairement intraitable. Une seule affirmation non étayée fait s'abstenir la réponse entière. Pas de 'répondre à la partie facile et nuancer le reste', car une demi-réponse avec une erreur confiante est exactement l'échec que la responsable conformité était payée pour attraper.

Les modes d'échec qui subsistent, et comment on les a évalués

Rien de tout cela n'est fiable parce que je le dis. C'est fiable parce que ça a été évalué et red-teamé avant d'approcher une vraie question, et l'évaluation a noté ce qui échoue réellement.

Je ne vais pas vous citer un chiffre de précision unique, et vous devriez vous méfier de quiconque le fait. L'artefact utile, c'est la grille : ce qu'on a mesuré, et pourquoi chaque dimension conditionne une mise en production.

La version de cette grille qui décide si une release part, seuils compris, c'est la suite d'évals qui transforme l'abstention en verrou de mise en production. Ce post, c'est le mécanisme ; celui-là, c'est le verdict.

Pourquoi la finance régulée est le banc d'essai

Vous pourriez demander pourquoi s'embêter, alors que la plupart des assistants RAG répondent et passent à autre chose. La réponse est le contexte. La finance régulée est le banc d'essai précisément parce que le coût d'une réponse fausse et confiante n'est pas la gêne, c'est une observation dans un audit.

Cette contrainte est un cadeau. Elle force la version honnête du système, celle qui survivrait partout où le coût de l'erreur est réel.

Si vous devez prouver cette exactitude à un régulateur plutôt que l'affirmer, le journal d'abstention et les contrôles de citation sont la preuve, ce qui est le même argument que je défends à propos de prouver l'exactitude sous le règlement IA européen.

FAQ