Evidence-Family-Abfrage: Sicherstellung, dass der RAG-Kontext jeden Teil einer Frage abdeckt.

Fünf relevante Abschnitte können einem RAG-System immer noch das fehlen lassen, was die gesamte Frage erfordert. Das Paradoxon verschwindet, sobald sich herausstellt, dass eine Frage Nachweise verschiedener Arten benötigt. Stellen Sie sich vor, jemand fragt, wie App-Einstellungen, Geheimnisse sowie den Workloads gewährte Berechtigungen als einheitliche Konfiguration behandelt werden sollten. Ein Retriever könnte fünf hervorragende Passagen zur Konfiguration zurückgeben. Alle sind relevant, doch der Kontext bleibt unvollständig, wenn er nichts über Zugangsdaten oder Berechtigungen sagt.

Das ist eine inhärente Schwäche der einfachen top-k-Abfrage: Das Einzelbewerten der Abschnitte sagt nichts darüber aus, ob alle für die Antwort notwendigen Konzepte vorhanden sind.

Relevanz bedeutet nicht Vollständigkeit

Eine herkömmliche Pipeline ordnet die Blöcke nach Rangfolge und behält die ersten k bei. Das ist in Ordnung, wenn eine Art von Beweismittel die Frage klärt, aber problematisch, wenn für die Beantwortung eine Vergleich, Synthese oder mehrere Quellen erforderlich sind. Angenommen, die fünf besten Blöcke beziehen sich alle auf Geheimnisse, doch die Antwort benötigt außerdem die Identität eines ServiceAccounts sowie RBAC-Autorisierungen. Die Rangfolge ist lokal sinnvoll, global jedoch unvollständig.

Die Erhöhung von top_k könnte helfen, ist aber nicht zuverlässig. Ein größerer Kontext kann Duplikate, Störungen, Verzögerungen und Kosten mit sich bringen, ohne dass garantiert ist, dass das fehlende Konzept auftaucht. Zudem kann eine bestimmte Quellenfamilie allein bereits die ersten 20 Positionen einnehmen. Das Ziel erfordert daher eine Abdeckungskonstraint:

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

Die Beweisfamilien-Auswertung fügt diese Einschränkung hinzu, während die übliche Relevanzrangliste beibehalten wird.

Was zählt als Familie

Bereiten Sie die Beweise vor der endgültigen Auswahl vor

Für erkannte komposite Frageformen verwendet das Projekt einen deterministischen Beweisplaner. Konzeptionell besteht seine Ausgabe aus einer Reihe von (source_pattern, rescue_query)-Paaren, wobei für jede Familie, die die Frage benötigt, ein Eintrag vorhanden ist:

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

Der Umfang ist absichtlich bescheiden und weist erheblich auf eine offene, autonome Planung zurück. Für als wichtig erkannte Fragen gelten vorhersehbare Abdeckungsregeln, während alles Weitere über herkömmliche Abrufverfahren abgewickelt wird. Entscheidend ist dabei die Inspektierbarkeit: Ein Plan kann überprüft und getestet werden, sodass ein Team, das eine fehlende Familie entdeckt, den Fehler auf die Frageerkennung, Klassifizierung der Quellen, Abruf potenzieller Lösungen, Neubewertung, Filtern oder die endgültige Kürzung zurückverfolgen kann.

Mitgliedschaft erkennen

In der Fallstudie ergibt sich die Familienmitgliedschaft aus dem Abgleich einer regulären Ausdrucksregel mit dem Quellnamen des Datensatzes:

pattern.search(str(chunk.source))

Es handelt sich um einen deterministischen Quellvertrag, nicht um semantisches Clustering. Der Vorteil besteht in Präzision und Nachvollziehbarkeit: Ein Dokument passt entweder zur deklarierten Kategorie oder nicht. Der Nachteil ist die notwendige Wartung, da umbenannte Dateien sowie neue Sammlungen eine Aktualisierung der Zuordnungen erfordern. Eine wiederverwendbare Plattform sollte explizite Metadaten vor Dateinammernmustern bevorzugen:

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

Die Mitgliedschaft wird dann auf eine Abfrage reduziert: chunk.metadata[„evidence_family“] == required_family.

Rettung fehlender Familien

Nach der ersten Durchlaufabfrage zählt das Pipeline die passenden Kandidaten für jede geplante Familie. Wenn eine Familie weniger Elemente aufweist als gewünscht, wird eine gezielte, spärliche Suche mit der Rettungsabfrage für diese Familie gestartet:

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)
        )

Die Rettungsaktion findet nur für vermisste Familien statt, wobei eine gezielte Abfrage unter Verwendung des Vertrags der Familie genutzt wird. Dabei werden mehrere Kandidaten zurückgebracht, damit der Neubewertungsmechanismus den stärksten auswählen kann, anstatt sich mit dem ersten verfügbaren Ergebnis zufriedenzugeben.

Die Neubewertung wählt Ergebnisse aus, nicht Familien

Die Planung entscheidet, welche Familien vertreten werden müssen, während die Neubewertung festlegt, welche verfügbaren Ergebnisse die Frage am besten beantworten. Beides ergänzt sich gegenseitig. Der Neubewertungsmechanismus des Projekts kombiniert eine gewichtete Mischung aus verschiedenen Signalen:

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

Sobald die Kandidaten bewertet sind, reserviert die familienorientierte Auswahl den am höchsten eingestuften passenden Kandidaten für jede erforderliche Familie und füllt die verbleibenden Plätze anschließend nach der globalen Rangfolge auf:

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

Warum Blöcke aus einer Quelle zusammenbleiben müssen

In einer frühen Version der quellenbewussten Auswahl wurde ein Fehler gemacht, indem nach dem Dateinamen duplizierte Inhalte entfernt wurden. Stellen Sie sich ein NetworkPolicy-Dokument vor, das getrennte Abschnitte zu dem Verhalten bei Standard-Ablehnung, Eingangsregeln und Ausgangsregeln enthält – alle sind für eine zusammenhängende Frage notwendig. Wenn die Auswahl nur einen Block pro Dateinamen zulässt, verschwinden zwei erforderliche Abschnitte. Die richtige Doppelungsbeseitigungsstrategie hängt von der Beweispflicht ab: Sie sollte Redundanzen beseitigen, ohne die Abdeckung zu beeinträchtigen, und eine Quelle darf berechtigt mehrere ergänzende Abschnitte liefern, sofern jeder einen anderen Anforderungen erfüllt.

Autorität versus Relevanz

Ein lauter Forschungsartikel kann semantisch einer Produktionsfrage ähneln, und ein allgemeines Dashboard-Leitfaden kann viele Abfrageschlüssel teilen. Keiner von beiden sollte ein genehmigtes Betriebshandbuch veröffentlichen, das die Frage direkt beantwortet. Drei Aspekte sollten klar voneinander getrennt bleiben:

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

Eine einzige Bewertung sollte nicht einfach stellvertretend für alle drei dienen. Autoritative Metadaten müssen außerdem der Aufnahme, dem Abruf, der Fusion, der Neubewertung, dem Caching sowie der API-Serialisierung standhalten – sie dürfen nicht einfach nur in der Vektordatenbank liegen.

Korrigierendes RAG ohne Verlust der Abdeckung

Korrigierendes RAG bewertet die abgerufenen Abschnitte und kann bei schwachen Beweisen erneut suchen. Dadurch wird die Genauigkeit verbessert, doch es kann mit der Beweisplanung in Konflikt geraten, denn ein eng gefasster Abschnitt, der für sich genommen nur teilweise relevant erscheint, kann für eine Synthese aus mehreren Dokumenten entscheidend sein. Wenn CRAG ihn ausschließt, fehlt eine notwendige Information in der Antwort. Um dies zu verhindern, betrachtet die Implementierung einen validierten Plan als Domänenrichtlinie: Nach dem Filtern durch CRAG führt sie eine neue, umfassende Suche für jede geplante Gruppe durch und wählt den stärksten, autoritativen Abschnitt aus. Die Reihenfolge spielt eine Rolle:

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

Ein ausgereiftes Design kann mehrere Planungsebenen verwenden, die je nach Grad des Verständnisses der Fragestruktur gewählt werden. Deterministische Regeln eignen sich für hochriskante oder regulierte Frageformen, bei denen eine vollständige Nachvollziehbarkeit wichtig ist, während flexiblere Ebenen breitere Bereiche sowie neuartige kombinierte Fragen abdecken – immer unter Berücksichtigung einer kontrollierten Taxonomie. Das Muster ist zudem übertragbar: Wenn ein Finanzassistent fragt, ob eine Überweisung erlaubt ist und welche Genehmigung erforderlich ist, können fünf gute Richtlinienabschnitte keine fehlenden Kontodaten ausgleichen, und die Familienplanung macht diese Verpflichtungen explizit.

Abdeckungsgrad messen

Allein die Relevanz der Teilbereiche reicht nicht aus, um einen auf Familienbedürfnisse ausgelegten Suchmechanismus zu validieren. Eine einfache Metrik zur Erinnerung an Familienmitglieder zeigt die Lücke auf:

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

Testsuite sollten die Rettung einer fehlenden Familie, das Überleben durch Neubewertung sowie durch CRAG, gültige alternative Quellen, ergänzende Abschnitte aus einem einzigen Dokument, eine Autoritätsfilterung, ein Top-k-Wert, der unter der Anzahl der erforderlichen Familien liegt, sowie Fragen beinhalten, die keinesfalls einen Plan auslösen dürfen.

Fehlermöglichkeiten

• Ein Planer, der allzu weitreichend reagiert, weil ein generisches Schlüsselwort einen nicht verwandten Plan aktiviert. Verwenden Sie Phrasenkombinationen und negative Fälle.
• Ein unvollständiger Plan, bei dem zwar die deklarierten Familien abgerufen werden, die Frage dennoch nicht beantwortet werden kann. Das fehlende Konzept gehört sowohl in den Plan als auch in die Regressionstests.
• Quellennamenänderungen, die dazu führen, dass die Regex-Übereinstimmung stillschweigend eingestellt wird. Corpus-Vertragsprüfungen sollten bestätigen, dass die geplanten Familien auf echte Quellen verweisen.

Rettungsanfragen überanpassen sich an die Bewertungsfragen. Formulieren Sie sie umgehend im Kontext von Domänekonzepten und überprüfen Sie sie mit Paraphrasen sowie versiegelten Ausreißern.

Reservierungen, die schwache Beweise schützen. Holen Sie mehrere Kandidaten pro Familie ab und ordnen Sie diese erneut nach Priorität, bevor Sie reservieren – wobei weiterhin Autoritäts- und Mindestrelevanzprüfungen angewandt werden.

Zu viele Familien für das Kontextbudget, was bedeutet, dass der Planer Prioritäten setzen, kompatible Beweise zusammenfassen oder um Klarstellungen bitten muss.

Ein Modell, das einen Teil der Beweise ignoriert. Eine vollständige Abfrage garantiert keine vollständige Synthese, daher sollten Anfragen und Treueprüfungen dem Plan entsprechen.

Nächste Verbesserungen

Mehrere Verbesserungen sind als Nächstes sinnvoll. Legen Sie die Familienidentität in versionierte Metadatenblöcke statt in Dateinamen fest. Erstellen Sie eine Taxonomie für Domänenbelege, die Eigentümer sowie Autoritätsregeln benennt. Für ungewöhnliche, zusammengesetzte Fragen fügen Sie einen strukturierten Planer mit strengen Einschränkungen hinzu und passen Sie die Mindestrelevanzschwelle für jede Familie separat an. Die Auswahl kann Relevanz, Abdeckung, Redundanz sowie das Tokenbudget gemeinsam berücksichtigen. Die Nachverfolgung sollte den Plan sowie die Abdeckung der Familie offenlegen. Neben der Erinnerungsfähigkeit sollte gemessen werden, wie präzise der Planer ist, automatisch auf Korpusverschiebungen sowie umbenannte Quellen getestet werden, und Planer auf Basis von Regeln, Klassifikatoren sowie großen Sprachmodellen an abgeschlossenen Testdatensätzen verglichen werden. Schließlich sollte das System offen angeben, wenn eine erforderliche Familie nicht gefunden werden kann.

Ziel ist es nicht, die Abfrageverarbeitung für jede Anfrage zu verkomplizieren. Es sollen nur zusätzliche Anstrengungen unternommen werden, wenn eine Frage tatsächlich verschiedene Arten von Belegen erfordert. Top-k bestimmt, welche Abschnitte am relevantesten erscheinen, und die Evidence-Family-Verfahrenstellung stellt eine weitere Frage: Enthält der endgültige Kontext alle Arten von Belegen, die eine vollständige Antwort erfordern? Relevanz zeigt an, ob ein Abschnitt nützlich ist, Autorität gibt an, ob man ihm vertrauen kann, und Abdeckung zeigt an, ob die Antwort vollständig sein kann. Für die praktische Anwendung von RAG sind alle drei Aspekte notwendig.