# RAG-Retrieval-Engine — Architektur Diese Sektion dokumentiert die **deterministische, regelbasierte Retrieval-Engine** des Compliance-SDK (`ai-compliance-sdk/internal/ucca/`). Sie beantwortet für jede Nutzerfrage: *Welche Norm/Quelle ist relevant — und warum?* > **Warum diese Doku existiert:** Die Engine trifft viele bewusste `+0.05 / +0.10`-Entscheidungen. Jede Konstante kodiert eine **gemessene** Entscheidung (Golden-Harness, Fehlerklasse) — nicht eine willkürliche Stellschraube. Ohne das *Warum* sind sie in sechs Monaten nicht mehr nachvollziehbar; diese Doku ist die Referenz für Wartung, Onboarding und Audit-/Investoren-Nachweis. ## Leitprinzip > **Nicht raten, nicht erzwingen, sondern relevante Quellenarten sichtbar machen.** Der LLM entscheidet **nicht**, was Recht ist — nur, wie eine bereits versionierte, zitierte Norm auf einen Sachverhalt gemappt wird. Wo möglich ist die Engine deterministisch (Marker, Gewichte, Schwellen), nicht modellbasiert. Nichts wird *gelöscht* — Re-Ranking ist reine Reihenfolge, alles bleibt auffindbar. ## Zwei orthogonale Achsen Der Kern des Modells: zwei unabhängige Achsen, die in der Literatur meist vermischt werden. | Achse | Frage | Wirkung | Doku | |------|-------|---------|------| | **`source_class`** (Rechtsnatur) | Wie bindend ist die Quelle? | bestimmt den **Rang** | [03](03-source-class.md) | | **`source_role`** (Funktion) | Was tut die Quelle im Dokument? | bestimmt die **Control-Pool-Zugehörigkeit** | [04](04-source-role.md) | Beispiel: NIST ist `technical_standard` (source_class) **und** `control_standard` (source_role). ENISA-Good-Practices sind `supervisory_guidance` **und** `implementation_guidance` — sie bleiben guidance, dürfen aber bei Umsetzungsfragen in den Control-Pool. ## Pipeline (Überblick) ``` Query │ bge-m3 Embedding ▼ Retrieval-Pool ── hybrid (RRF) + binding-Augmentation + control-Augmentation + (graph) → 01 ▼ Authority-Rerank ── source_class → Rang (bindendes Recht der passenden Jurisdiktion oben) → 02, 03 ▼ Control-Intent ── source_role → Control-Pool + Diversity (Quellenarten sichtbar machen) → 04, 05 ▼ Assessment ── PrimaryNorm · ConnectedNorms · WinnerMargin · CrossRegime → 06 ▼ Confidence/Explainability ── HumanReviewFlag · Zitate · Graph-Kanten · Supersede → 07, 08 ``` `framework_*` ([09](09-framework-layer.md)) ist die **Daten-Brücke** zur nächsten Stufe (Control → Evidence) — heute in der Qdrant-Payload, noch nicht im Retrieval-Code verdrahtet. ## Dokumente | # | Dokument | Inhalt | |---|----------|--------| | 01 | [Retrieval-Pipeline](01-retrieval.md) | Pool-Aufbau: hybrid + binding + control + graph | | 02 | [Authority-Re-Ranking](02-authority.md) | source_class → Rang, Bonus/Penalty-System | | 03 | [source_class](03-source-class.md) | Rechtsnatur, Gewichte, Marker, Standard-Name-Override | | 04 | [source_role](04-source-role.md) | 7 Rollen, Control-Pool, Klassifikation | | 05 | [Control-Intent + Diversity](05-control-intent.md) | Intent-Erkennung, Rollen-Bonus, Diversity-Regel | | 06 | [Assessment](06-assessment.md) | Auditierbare Begründungsschicht | | 07 | [Confidence](07-confidence.md) | WinnerMargin, HumanReviewFlag | | 08 | [Explainability + Supersede](08-explainability.md) | Zitate, Graph-Kanten, Supersede | | 09 | [framework_*-Layer](09-framework-layer.md) | Control-Mapping-Brücke (CRA Annex → OWASP V6.x) | > **Fehlerklassen-These:** Modell und Korpus sind austauschbar; die *Fehlerklassen + Hebel* sind das IP. Jede Konstante unten adressiert eine benannte Fehlerklasse (z.B. „Guidance verdrängt Gesetz", „Standard als guidance mistagged"). Die Kalibrierung ist sublinear: wenige Klassen, viele Module.