Bevor souveränes RAG gebaut wird: ein Readiness-Audit

Der Reflex, wenn man sich daranmacht, ein RAG-System auf sensiblen Daten zu bauen, ist, mit den sichtbaren Entscheidungen zu beginnen: welches Modell, wie viele GPUs, welche Cloud-Region. Das sind die Teile, die man kauft. Sie verbessern sich auf der Roadmap eines anderen, und sie sind fast nie der Grund, warum das Projekt scheitert.

Projekte scheitern an den zwei Teilen, die einem tatsächlich gehören. Der erste ist die Wissensbasis: ein Korpus, der für einen Menschen wie Dokumentation aussieht, kann für ein Embedding-Modell semantisch flach sein, und keine Modellqualität rettet eine Passage, die nie abrufbar war. Der zweite ist der Datenpfad: die Route, die eine einzelne Anfrage und ihr abgerufener Kontext durch das System nehmen, und ob die Daten sie überhaupt nehmen dürfen. Beide werden vor dem Modell entschieden, und beide sind in einer Demo unsichtbar.

Also vor dem Bau: ein Readiness-Audit durchführen. Kein Compliance-Fragebogen — ein Engineering-Pre-Flight, der zwei Fragen mit Evidenz beantwortet: Kann dieser Korpus zu guten abrufbaren Chunks werden, und dürfen die Daten rechtlich den Pfad nehmen, der gleich vorgegeben wird. Die gute Nachricht ist, dass beides billig zu prüfen ist. Die schlechte ist, dass die Antwort meist „noch nicht" lautet, und die teuersten Überraschungen sich dort verstecken, wo niemand hinschaut — im Test-Set, nicht im Modell.

Das Audit hat zwei Achsen, und sie zu verwechseln ist der erste Fehler. Retrievability-Readiness fragt, ob der Korpus zu guten Chunks werden kann — und ob sich das ehrlich messen lässt. Sovereignty-Readiness fragt, in wessen Jurisdiktion jeder Abschnitt des Datenpfads sitzt. Sie sind orthogonal: Ein Korpus kann wunderbar abrufbar und völlig exponiert sein, oder fest in der eigenen Jurisdiktion eingeschlossen und unmöglich abzurufen.

Beide gaten das Projekt. Starkes Retrieval auf einem exponierten Pfad ist ein Compliance-Vorfall, der nur darauf wartet zu passieren; perfekte Souveränität über einen Korpus, den niemand abfragen kann, ist ein teures Archiv. Beide müssen bestehen, und beide müssen getrennt bewertet werden, weil die Arbeit, eines zu beheben, für das andere nichts tut.

Am Anfang steht eine Inventur, und dabei sind zwei Dinge zu trennen, die oft vermengt werden: die logische Quelle — ein Wissensbestand, eine Crawl-Wurzel — und der physische Store, in dem sie zufällig liegt. Eine Quelle kann sich über mehrere Stores erstrecken; ein Store kann mehrere Quellen halten. Dieses Mapping muss explizit sein, und für jede Quelle leitet man einen Typ ab, statt ihn von Hand zu pflegen: ein Referenzkorpus, ein prozeduraler und ein Q&A-Export brauchen flussabwärts unterschiedliche Behandlung, und der Typ ist es, der sie routet.

Dann der Teil, der alles entscheidet: Struktur. Ein Chunk ist die Einheit des Retrievals, also begrenzen seine Grenzen die Retrieval-Qualität, und Struktur ist das, was Grenzen sinnvoll macht. Der Haken ist, dass Struktur oft nicht dort liegt, wo ein naiver Parser schaut — sie steckt in UI-Widgets, in Fett-als-Überschrift-Konventionen, im Layout statt in echten Überschriften-Tags. Ich habe einen Korpus von einstelliger auf rund zwei Drittel Überschriften-Dichte gehen sehen, allein indem diese implizite Struktur wiederhergestellt wurde, bevor der Splitter lief — derselbe Inhalt, das Signal wurde schlicht weggeworfen. Chunking muss dann content-type-bewusst sein — eine Prozedur, eine Referenztabelle und eine Definitionsseite wollen unterschiedliche Grenzen.

Eine konkrete Falle gehört ins Audit: prüfen, ob die Plattform die Chunks neu chunkt. Eine gemanagte Wissensbasis mit einem Fixed-Size-Chunking-Default schneidet fröhlich quer durch die sorgfältig gebauten Grenzen, und die Einstellung ist leicht zu übersehen, weil ihr Default vernünftig aussieht. Und wo eine Quelle strukturell hoffnungslos ist — ein winziger Stub, eine Wand aus Jargon-Tabellenzellen, eine Index-Seite nahezu identischer Einträge — markiert man sie und entscheidet bewusst, statt sie blind zu ingestieren und die Zahlen herunterziehen zu lassen.

Hier ist das Finding, das das ganze Audit neu ordnet: Die meisten Retrieval-„Fehler" sind keine Retrieval-Fehler. In einer Diagnose eines Systems, das schwer danebenzuliegen schien, stellten sich sechzehn von achtzehn Misses als falsche Labels im Test-Set heraus — die richtige Seite wurde abgerufen, und die Ground Truth bestand schlicht darauf, dass eine andere Seite korrekt sei. Bevor man einer einzigen Recall-Zahl vertraut, auditiert man das, wogegen gemessen wird.

Der billigste erste Zug kostet einen Nachmittag und keine Inferenz: die praktische Obergrenze berechnen — den Anteil der erwarteten Antwortseiten, die im indexierten Korpus überhaupt existieren. Wenn ein Zehntel der gelabelten Antworten auf Seiten zeigt, die nicht da sind, ist der Recall bei neunzig Prozent gedeckelt, bevor das Retrieval irgendetwas tut, und den letzten Punkten nachzujagen heißt, Rauschen nachzujagen. Als Nächstes: die Query-Sets nach Zweck trennen — ein eingefrorener Benchmark für das Urteil, ein append-only Regression-Set, ein generiertes diagnostisches Set — und nie vermischen lassen; die volle Mechanik hinter dieser Trennung erzählt „Retrieval-Qualität wird gegated, nicht behauptet". Ein Haufen, der drei Zwecken dient, fabriziert falsche Miss-Raten und versteckt echte.

Und wenn sich eine Metrik bewegt, wird sie nach Subset aufgebrochen, bevor man reagiert. Eine aggregierte Zahl ist ein Durchschnitt über Schichten, die sich in entgegengesetzte Richtungen verschieben können; optimiert man gegen das falsche Aggregat, rollt man fröhlich Änderungen zurück, die dem Subset halfen, das tatsächlich wichtig ist. Nichts davon ist exotisch — Retrieval ist einer der wenigen Teile eines LLM-Systems mit ehrlichen, klassischen Metriken wie Recall@k und MRR — aber die Metriken sind nur so ehrlich wie die Ground Truth darunter. Die wird zuerst auditiert.

Souveränität ist eine Eigenschaft des Datenpfads, nicht eines Rechenzentrums. Eine EU-Region zu wählen ist die beruhigende Zeile in der Architektur und die, die am wenigsten schützt, weil was bindet die Jurisdiktion des Betreibers ist, nicht der Standort des Servers. Also geht man den Pfad ab, den eine echte Anfrage nimmt — Query, Embedding, Retrieval, Generierung — und markiert jeden Abschnitt, den ein Betreiber unter fremder Jurisdiktion kontrolliert. Jede Markierung ist eine Exponierung, was auch immer das Regions-Dropdown sagt.

Was entscheidet, wie streng man sein muss, ist der Schutzbedarf der Daten — wie es deutsche Teams im öffentlichen Sektor nennen. Und die entscheidende Feinheit ist, dass die Klassifikation den Pfad und den Anbieter beurteilt, nicht die Abstammung des Modells. Open Weights, die man herunterlädt und auf der eigenen EU-Infrastruktur betreibt, senden nichts nach Hause; eine gemanagte API eines fremden Anbieters sieht den geschützten Kontext bei jedem Aufruf. „Ist dieses Modell amerikanisch" ist also die falsche Frage. „Wer betreibt es, und was kann von ihm verlangt werden herauszugeben" ist die richtige.

Zwei praktische Hinweise, die viele erwischen. Regionen sind asymmetrisch in dem, was sie anbieten — ein Reranker oder ein benötigtes Modell existiert vielleicht nur in einer Region — sodass Compliance-Constraint und reine Verfügbarkeit gemeinsam festlegen, wo man laufen kann, und die beiden können gegeneinander ziehen. Und Datenpfade lecken aus Versehen: ein Deploy kann still in eine fremde Region greifen, weil ein CDN oder ein gemanagter Dienst es leise verlangt. Es sollte Regel sein, dass jede Infrastruktur-Aktion vor ihrem Lauf eine klartextliche Liste der Regionen und Accounts ausgibt, die sie berühren wird. Die Exponierung, die man nicht sieht, ist die, die wehtut.

Legt man die zwei Achsen zusammen, wird das Audit zu einer Scorecard, die sich in Stunden laufen lässt, nicht in Wochen. Es braucht nicht jede Zeile grün, um zu starten — es braucht das Wissen, welche Zeilen rot sind, und die bewusste Entscheidung, dass man damit leben kann. Hier ist die Form davon:

Das Audit ist nicht umsonst, aber es ist billig im Verhältnis zu dem, was es spart. Für öffentliche Inhalte bei geringem Einsatz reicht ein schneller Gut-Check, und ein vollständiges Audit ist Over-Engineering. Für personenbezogene, öffentliche oder Gesundheitsdaten — wo der Schutzbedarf real ist und der Regulierer ohnehin erwartet, dass der Fluss kontrolliert wird — ist es nicht optional, und ein hier verbrachter Nachmittag ist die billigste Versicherung, die das Projekt kaufen wird.

Die Systeme, die es überspringen, scheitern nicht laut beim Launch. Sie scheitern leise, vor dem Modell, genau an dem Ort, an dem die nächste Person, die sie debuggt, zuletzt schauen wird.