Récupération familiale basée sur des preuves : faire en sorte que le contexte RAG couvre chaque partie d’une question.

Cinq extraits pertinents peuvent encore laisser un système RAG dépourvu de ce dont a besoin la question dans son ensemble. Le paradoxe disparaît lorsque la question exige des preuves de plusieurs types distincts. Imaginez quelqu’un qui demande comment gérer les paramètres d’une application, les secrets ainsi que les permissions accordées aux charges de travail en tant qu’éléments d’une même configuration. Un système de récupération peut retourner cinq passages excellents sur la configuration. Tous sont pertinents, mais le contexte reste incomplet s’il ne mentionne rien concernant les identifiants ou les permissions.

C’est une faiblesse inhérente à la méthode de récupération top-k classique : évaluer les extraits un par un ne permet pas de déterminer si tous les concepts nécessaires à la réponse sont bien présents.

La pertinence n’est pas l’exhaustivité

Un pipeline conventionnel classe les fragments et conserve les k premiers. Cela fonctionne bien lorsque un seul type de preuve suffit à trancher la question, mais devient fragile lorsqu’il est nécessaire de comparer des éléments, de les synthétiser ou d’utiliser plusieurs sources de vérité. Supposons que les cinq fragments les plus pertinents concernent tous des Secrets, mais que la réponse nécessite également l’identité ServiceAccount ainsi qu’une autorisation RBAC. La classification est pertinente au niveau local, mais incomplète à l’échelle globale.

Augmenter la valeur de top_k pourrait aider, mais pas de manière fiable. Un contexte plus large peut introduire des doublons, du bruit, de la latence et des coûts supplémentaires, sans garantie que le concept manquant apparaîtra ; de plus, si une famille de sources domine les candidats, elle peut occuper seule les 20 premières positions. L’objectif exige donc une contrainte de couverture :

Useful context = relevance + required-family coverage + trusted provenance - noise

La récupération par famille de preuves ajoute cette contrainte tout en conservant le classement normal par pertinence.

Qu’est-ce qu’une famille ?

Une famille de preuves est un ensemble de sources ou de passages capables de répondre à une exigence d’une question. Elle n’a pas nécessairement pour correspondance un seul fichier, une étiquette de sujet, un cluster d’embeddings, une stratégie de récupération ou un chunk. Prenons l’exemple d’une question portant sur la sécurisation d’une application : ses familles pourraient être le routage Ingress, la découverte de services et le comportement de disponibilité. Plusieurs documents peuvent faire partie de la famille « Service », et un document peut appartenir à plusieurs familles si ses métadonnées et son contenu le permettent.

Planifier les preuves avant la sélection finale

Pour les formes de questions composées reconnues, le projet utilise un planificateur de preuves déterministe. Conceptuellement, son résultat est un ensemble de paires (source_pattern, rescue_query), avec une entrée pour chaque famille nécessaire à la réponse à la question :

def evidence_plan(question: str):
    # Returns list of (family_pattern, rescue_query) tuples
    # for recognized composite question shapes
    if asks_about_workload_identity(question):
        return [
            (SECRET_SOURCE_PATTERN,      "Kubernetes Secret credentials Pod"),
            (SERVICE_ACCOUNT_PATTERN,    "Pod ServiceAccount workload identity"),
            (RBAC_SOURCE_PATTERN,        "RBAC least privilege RoleBinding"),
        ]
    return []  # unknown shapes continue through normal retrieval

La portée est délibérément modeste, loin d’une planification autonome sans limites. Les questions reconnues comme importantes bénéficient de règles de couverture prévisibles, tandis que tout le reste est géré par des méthodes de récupération ordinaires. La propriété clé est l’inspectabilité : un plan peut être examiné et testé, ce qui permet à une équipe qui découvre l’absence d’une famille d’identifier la cause dans la détection des questions, la classification des sources, la récupération des candidats, le réclassement, le filtrage ou le troncature finale.

Reconnaissance de l’appartenance

Dans l’étude de cas, l’appartenance à une famille est déterminée en comparant une expression régulière avec le nom de la source du fragment :

pattern.search(str(chunk.source))

Ceci est un contrat de source déterministe, et non un regroupement sémantique. Ce que vous gagnez, c’est la précision et la traçabilité : un document correspond ou non à la famille déclarée. Ce que vous payez, c’est l’entretien, car les fichiers renommés et les nouvelles collections nécessitent que leurs mappages soient mis à jour. Une plateforme réutilisable devrait privilégier des métadonnées explicites aux schémas de noms de fichiers :

{
  "source": "security-policy.pdf",
  "document_id": "doc-123",
  "chunk_index": 17,
  "evidence_family": "access-control",
  "authority_tier": "official",
  "version": "2026-07"
}

L’adhésion se réduit alors à une recherche : chunk.metadata[“evidence_family”] == required_family.

Récupération des familles manquantes

Après la première phase de récupération, le pipeline compte les candidats correspondants pour chaque famille prévue. Si une famille compte moins d’éléments que le nombre souhaité, une recherche ciblée est lancée avec la requête de sauvetage correspondante :

for family_pattern, rescue_query in plan:
    matches = [c for c in candidates if family_pattern.search(c.source)]

    if len(matches) < desired_candidate_count:
        # Targeted rescue — bounded, not an open retry loop
        rescued = sparse_search(rescue_query, top_k=wide_limit)
        candidates.extend(
            c for c in rescued if family_pattern.search(c.source)
        )

Le sauvetage ne s’applique qu’aux familles disparues, en utilisant une recherche ciblée liée au contrat de la famille, et il restitue plusieurs candidats afin que le réclassificateur puisse choisir le meilleur plutôt que de se contenter du premier passage disponible.

Le réclassificateur choisit les passages, pas les familles

La planification détermine quelles familles doivent être représentées, tandis que le réclassificateur choisit quels fragments disponibles répondent le mieux à la question. Les deux processus se complètent. Le réclassificateur du projet combine une série de signaux pondérés :

0.4 × normalized cross-encoder score
+ 0.3 × normalized retrieval score
+ 0.3 × lexical overlap
+ conditional exact-token bonus

Avec les candidats classés, le processus de sélection tenant compte des familles réserve le groupe correspondant le mieux classé pour chaque famille requise, puis remplit les places restantes en fonction du classement global :

selected = []

# Step 1: reserve best chunk per required family
for family in required_families:
    best_match = first_ranked_match(family, ranked_chunks)
    if best_match:
        selected.append(best_match)

# Step 2: fill remaining slots by global rank
selected.extend(c for c in ranked_chunks if c not in selected)

final_chunks = selected[:top_k]  # constrained top-k, not an alternative to ranking

Pourquoi les fragments provenant d’une même source doivent parfois rester ensemble

Une version initiale de la sélection tenant compte des familles a commis une erreur en effectuant une déduplication sur le nom de fichier. Imaginez un document NetworkPolicy contenant des sections distinctes concernant le comportement par défaut de refus, les règles d’entrée et les règles de sortie, nécessaires toutes pour une même question composite. Si la sélection ne permet qu’un seul fragment par nom de fichier, deux sections essentielles disparaissent. La politique de déduplication appropriée dépend des obligations en matière de preuves : elle doit éliminer la redondance sans nuire à la couverture, et une même source peut légitimement fournir plusieurs sections complémentaires lorsque chacune répond à une obligation différente.

Autorité versus pertinence

Un article de recherche bruyant peut ressembler sémantiquement à une question de production, et un guide de tableau de bord générique peut partager de nombreux termes de requête. Aucun des deux ne doit remplacer un manuel opérationnel approuvé qui répond directement à la question. Trois éléments doivent rester distincts :

Relevance:  Does this passage discuss the question?
Authority:  Is this an approved source of truth?
Coverage:   Which required evidence obligation does it satisfy?

Un score ne devrait pas remplacer silencieusement les trois autres. Les métadonnées d’autorité doivent également résister à l’ingestion, au retraitement, à la fusion, au réclassement, au stockage en cache et à la sérialisation via API, et non pas rester simplement dans la base de données vectorielle.

RAG correctif sans perte de couverture

Le RAG correctif évalue les extraits récupérés et peut réessayer lorsque les preuves semblent faibles. Il améliore la précision, mais peut entrer en conflit avec la planification des preuves, car un passage restreint qui semble seulement partiellement pertinent en soi peut s’avérer essentiel pour une synthèse à partir de plusieurs documents. Si le CRAG l’élimine, une famille nécessaire disparaît de la réponse. Pour éviter cela, l’implémentation considère un plan validé comme une politique de domaine : après le filtrage effectué par le CRAG, elle lance une nouvelle recherche approfondie pour chaque famille planifiée et sélectionne le passage d’autorité le plus solide. L’ordre est important :

Retrieve broadly
→ shape and rerank candidates
→ reserve family coverage
→ grade evidence (CRAG)
→ restore validated required families
→ build context

Un design mature peut faire appel à plusieurs niveaux de planification, choisis en fonction du degré de compréhension de la structure de la question. Les règles déterministes conviennent aux cas à haut risque ou réglementés où une traçabilité complète est essentielle, tandis que des niveaux plus flexibles couvrent des domaines plus larges et des questions composées innovantes, toujours validés à l’aide d’une taxonomie contrôlée. Ce modèle est également transposable. Le fait qu’un assistant financier demande s’une transfert est autorisé et quelles approbations il nécessite ne peut pas compenser l’absence de données sur le compte, même avec cinq passages pertinents des politiques en vigueur ; la planification familiale rend ces obligations explicites.

Évaluation de la couverture

La pertinence des éléments isolés ne suffit pas à valider un système de récupération prenant en compte les aspects familiaux. Une simple métrique de rappel familial révèle l’écart :

Evidence-family recall = covered required families / total required families

# Example: Secret + RBAC covered, ServiceAccount missing
Evidence-family recall = 2/3 = 0.67

# This failure is invisible to standard chunk-relevance metrics

Les suites de test doivent inclure le sauvetage d’une famille manquante, la survie grâce au réclassement et au CRAG, des sources alternatives valides, des fragments complémentaires provenant d’un même document, un filtrage par autorité, un top-k inférieur au nombre de familles requises, ainsi que des questions qui ne doivent déclencher aucun plan.

Modes de défaillance

• Un planificateur qui déclenche des actions de manière trop large, car un mot-clé générique active un plan non pertinent. Il convient d’utiliser des combinaisons de phrases et des cas négatifs.
• Un plan incomplet, où les familles déclarées sont retrouvées mais la question ne peut toujours pas être répondue. Le concept manquant doit figurer dans le plan ainsi que dans les tests de régression.
• Des renommages de sources qui font cesser silencieusement la correspondance avec les expressions régulières. Les tests de contrat de corpus doivent confirmer que les familles planifiées correspondent bien à des sources réelles.

Les requêtes de sauvetage surapprennent aux questions d’évaluation. Formulez-les en fonction des concepts du domaine et vérifiez-les à l’aide de paraphrases ainsi que d’échantillons réservés non utilisés.

Réservations qui protègent des preuves faibles. Récupérez plusieurs candidats par famille et réordonnez-les avant de procéder à la réservation, tout en appliquant toujours des vérifications d’autorité et de pertinence minimale.

Trop de familles pour le budget de contexte, ce qui oblige le planificateur à prioriser, à fusionner des preuves compatibles ou à demander des précisions.

Un modèle qui ignore une partie des preuves. Une récupération complète ne garantit pas une synthèse complète ; par conséquent, les prompts et les vérifications de fidélité doivent refléter le plan.

Prochaines améliorations

Diverses mises à niveau s’imposent. Il convient d’intégrer l’identité familiale dans les métadonnées par versions plutôt que dans les noms de fichiers. Il faut également élaborer une taxonomie des preuves par domaine qui indique les propriétaires et les règles d’autorité. Pour les questions complexes inhabituelles, ajouter un planificateur structuré avec des contraintes strictes, et ajuster séparément le seuil de pertinence minimal pour chaque famille. Le choix peut tenir compte en même temps de la pertinence, du couvert, de la redondance et du budget de tokens. Le suivi doit permettre de visualiser le plan ainsi que le couvert par famille. En plus du rappel, il est nécessaire de mesurer la précision du planificateur, de tester automatiquement en cas de dérive du corpus ou de renommage des sources, et de comparer les planificateurs basés sur des règles, des classifieurs et des LLM sur des ensembles de test isolés. Enfin, le système doit indiquer clairement lorsque une famille requise ne peut pas être trouvée.

L’objectif n’est pas de compliquer la récupération des informations pour chaque requête. Il s’agit d’investir un effort supplémentaire uniquement lorsque une question nécessite réellement plusieurs types de preuves. La méthode top-k sélectionne les fragments les plus pertinents, tandis que la récupération par famille de preuves pose une deuxième question : le contexte final contient-il tous les types de preuves requis pour une réponse complète ? La pertinence indique si un fragment est utile, l’autorité détermine s’il faut lui faire confiance, et la couverture montre si la réponse peut être complète. Le RAG de production a besoin des trois éléments.