RAG verbessern: Das Problem ist selten das Modell

Der «Chat mit unseren Dokumenten» ist live, die Demo hat überzeugt, und drei Monate später lautet das Urteil im Team: Die Antworten sind nur okay. Der erste Verdächtige ist fast immer das Modell, und fast immer ist er unschuldig. Wer sein RAG verbessern will (Retrieval-Augmented Generation: erst passende Textstellen suchen, dann das Sprachmodell damit antworten lassen), findet die teuersten Fehler selten beim Antworten selbst. Fehleranalysen benennen die Retrieval-Stufe, also das Suchen, als häufigsten und schädlichsten Fehlerpunkt naiver RAG-Systeme, weil fehlende oder verrauschte Treffer alles Nachgelagerte vergiften.

Zwischen der Frage und dem Modell liegt nämlich eine Kette von Entscheidungen: Welches Suchprogramm für welchen Fragetyp? Welcher Text für welchen Suchkanal, und gegen welches Vektorfeld? Wie gross der Kandidaten-Pool? Was darf vor dem Reranker aussortieren, was darf nur boosten? Wer darf welche Dokumente sehen, wie viel Kontext bekommt jeder nachgelagerte Schritt, und was darf am Ende zitiert werden? Die meisten RAG-Systeme treffen diese Entscheidungen implizit: ein String, ein Suchaufruf, Defaults. Produktionsreifes RAG trifft sie explizit.

Dass ich das so bestimmt sagen kann, liegt nicht an fremden Benchmarks, sondern am eigenen Code. In meinem System füttert derselbe Suchtext die Stichwortsuche, die vektorbasierte Bedeutungssuche und den semantischen Reranker: drei Stufen, drei verschiedene Bedürfnisse, ein Kompromisstext. Also habe ich mein Retrieval systematisch verhört, mit dem wörtlichen Auftrag am Anfang des Audits: «I am sure I have a quite misconfigured setup … turn every stone.» Dieser Artikel geht die Kette entlang, Station für Station, von der Frage bis zum Zitat. Und weil Relevanz allein noch kein Produktionssystem macht, gehören zwei weitere Pfeiler dazu, die am Schluss ihren Platz bekommen: Berechtigungen und Messbarkeit.

Retrieval ist ein Entscheidungssystem

Retrieval als Entscheidungssystem heisst: Das System klassifiziert zuerst die Absicht der Frage (Fakt, Definition, Verifikation, Vergleich, Sammlung) und wählt dann ein passendes Suchprogramm mit eigenen Parametern, statt jede Frage durch denselben Hybrid-Suchaufruf zu schicken. Eine Verifikationsfrage braucht Gegenbelege, eine Faktenfrage einen zitierfähigen Beleg; ein einzelner Vektor-Suchaufruf liefert beides nicht zuverlässig.

So sieht das konkret aus: Fragt eine Sachbearbeiterin «Welche Kündigungsfrist steht im Rahmenvertrag mit der Muster AG?», braucht sie einen präzisen, zitierfähigen Satz samt Fundstelle. Fragt sie «Was wissen wir insgesamt über die Muster AG?», braucht sie diverse Dokumente statt fünf Varianten desselben Absatzes. Und «Stimmt es, dass der Vertrag ausgelaufen ist?» verlangt aktiv nach Belegen für beide Antworten.

Die Programme arbeiten über einen dreistufigen Index: Zuerst das richtige Dokument finden (Parent-Ebene), dann den relevanten Abschnitt eingrenzen (Section-Ebene), zuletzt den zitierfähigen Beleg holen (Evidence-Ebene mit Seitenzahl und Position). Dieser Aufbau ist kein Sonderweg: «Retrieve small, return big», also kleine Einheiten suchen und grössere Elterneinheiten zurückgeben, ist ein bewährtes Produktionsmuster für Chunking, die Zerlegung Ihrer Dokumente in durchsuchbare Häppchen. Chunking gehört dabei an den Anfang jeder Diagnose: Was die Zerlegung zerstört hat, kann kein Parameter danach wiederfinden. Auch das Routing selbst ist gut belegt; aktuelle Benchmark-Arbeiten zeigen, dass komplexitätsbewusste Router die Qualität teurer Always-Multi-Hop-Pipelines zu geringeren Kosten erreichen, und Microsofts eigene RAG-Architektur-Guidance beschreibt exakt diese Pipeline: Query umformen und zerlegen, mehrere Suchpfade fahren, reranken.

Wie viel Routing ist genug? Meine eigene Antwort hat sich geändert, und die Änderung ist die eigentliche Lektion. Die erste Ausbaustufe meines Systems hatte fünf ausgewachsene Intent-Programme, eines pro Fragetyp, mit je eigenem Ablauf, eigenen Kandidaten-Limits und eigenen Ranking-Regeln. Heute existiert keines davon mehr als eigener Codepfad. Eine einzige Triage-Klassifikation entscheidet stattdessen, ob eine Frage direkt beantwortet wird, ob eines von drei deterministischen Retrieval-Templates reicht (Fakt, Definition, Verifikation) oder ob ein Planner einen mehrstufigen Ablauf baut. Die drei Index-Ebenen haben jede Umbau-Runde unverändert überlebt; die Programme darüber wurden zusammengelegt. Verallgemeinert: Das Routing ist richtig, aber jede Verzweigung muss ihren Unterhalt verdienen — in Klassifikations-Latenz, in Code-Pfaden, in Testaufwand. Fünf Programme waren Architektur-Stolz; eine Triage plus drei Templates plus ein Planner ist Betrieb.

Inzwischen verkauft Microsoft das Entscheidungssystem sogar als Produkt: Agentic Retrieval in Azure AI Search plant Teilfragen, sucht parallel und rerankt nativ; das extraktive Retrieval ist per REST-API 2026-04-01 allgemein verfügbar, während Antwort-Synthese und Teile der Planungs-Features weiter als Preview laufen. Ob Sie kaufen oder bauen, entscheidet Ihr Fall; die Abwägung gehört in den Artikel zu Foundry IQ.

Wann betrifft Sie das alles überhaupt? Drei Fälle, ehrlich unterschieden:

• Interner FAQ- oder Richtlinien-Bot über homogene Dokumente: Ein sauber konfiguriertes Hybrid-Programm, gutes Chunking, Citations und eine kleine Messlatte reichen. Routing wäre Theater.
• Gemischter Wissensassistent (Verträge, Handbücher, Tickets, mehrere Sprachen und Fragetypen): Routing, Rewrites, Reranking und Berechtigungs-Trimming werden relevant. Das ist der Kern dieses Artikels.
• Regulierter Assistent (HR, Finanzen, Kundendossiers): Sicherheits-Trimming, Auditierbarkeit und Messlatte sind nicht verhandelbar — noch bevor irgendein Relevanz-Tuning zählt.

Für die Fälle zwei und drei folgt jetzt die Kette im Detail. Sie beginnt bei der kleinsten und unscheinbarsten Einheit: dem Suchtext selbst.

Der Bug in einem String

Eine Hybrid-Suche in Azure AI Search kombiniert drei Stufen mit drei verschiedenen Vorlieben. Die klassische Stichwortsuche (BM25) will wenige präzise Keywords. Die Vektorsuche, die nach Bedeutung statt nach Wortlaut sucht, will eine ausformulierte Frage, weil ein paar dürre Stichworte zu wenig Bedeutung transportieren. Und der Semantic Reranker, das Sprachmodell, das die gefundenen Treffer am Schluss neu nach Relevanz ordnet, will natürliche Sprache. Alle drei bekommen in den meisten RAG-Systemen denselben Text, meines eingeschlossen: Das geshippte Prompt-Modul meiner Schreib-Pipeline instruiert das Modell wörtlich, «The query text you write is the SOLE input to ALL THREE stages», und verordnet einen Kompromiss von fünf bis zwölf Wörtern. Der Chat-Pfad hat keine solche Zeile im Prompt — strukturell macht er dasselbe, derselbe Text wandert in jede Vektor-Query. Ein String, der drei Kanäle gleichzeitig bedienen soll, bedient alle drei suboptimal.

Zur Illustration, wie die drei idealen Formen derselben Frage aussehen (konstruiertes Beispiel, kein Kundenfall):

Mein zweites Selbst-Audit benennt den Fehler gegen den eigenen Code, mit Datei und Zeile: Jede Stufe bevorzugt eine andere Form. Es fand dabei noch eine Verschärfung: Im selben Prompt-Stack verlangt eine Regel zwei bis sieben Wörter, eine andere fünf bis zwölf — zwei widersprüchliche Stimmen, die niemandem auffielen, bis das Audit sie nebeneinanderlegte. Der vorgeschlagene Fix sind getrennte Suchtexte pro Kanal, danach clientseitig zu einer Liste verrechnet (das Standardverfahren heisst RRF, Reciprocal Rank Fusion). Diagnostiziert, nicht geshippt; das Prompt lehrt den Bug bis heute. Ihn zu benennen war der erste Fix.

Zwei externe Befunde schärfen das Bild. Erstens kann automatisches Umformulieren, inklusive HyDE (suchen mit einer hypothetischen Modell-Antwort statt mit der Frage), die Originalfrage in bestimmten Szenarien unterbieten; die wörtliche Nutzerfrage sollte deshalb immer als eigener Suchkanal erhalten bleiben. Zweitens eine präzise Azure-Eigenheit: Mit serverseitigen queryRewrites müssen Suchtext und Vektor-Text im selben Request übereinstimmen; echtes Entkoppeln geht nur über separate Queries plus clientseitiges RRF.

Der Text ist aber nur die halbe Entscheidung. Die andere Hälfte ist, wo dieser Text sucht.

Nicht nur welcher Text, auch welcher Vektor

Ein Index muss nicht ein einziges Embedding pro Inhalt tragen. In meinem System hat die Dokument-Ebene einen eigenen Vektor über Titel und Zusammenfassung, die Abschnitts- und Beleg-Ebenen tragen Vektoren über die Abschnitts-Zusammenfassung, und den Volltext-Vektor gibt es überall. Interessant wird das erst durch die zweite Hälfte: Die Suchprofile wählen pro Fragetyp aus, gegen welche dieser Repräsentationen gesucht wird — und mit welchem Gewicht.

Das ist die konkrete Einlösung von «jede Frage braucht ihr Programm» — nicht als Philosophie, sondern als Feldliste. Die übertragbare Regel: Indexieren Sie mehrere Repräsentationen desselben Inhalts (Titel-Zusammenfassung, Abschnitts-Zusammenfassung, Volltext) und lassen Sie den Fragetyp entscheiden, welche davon zählt. Eine Überblicksfrage, die gegen Volltext-Embeddings sucht, findet fünf Formulierungs-Varianten desselben Absatzes; eine Zitat-Frage, die gegen Zusammenfassungen sucht, findet das Thema, aber nie die Stelle.

Welche Form und welches Feld der Suchtext auch trifft — am Ende landet alles in einem Pool mit einer harten Grenze. Die kennen die wenigsten.

Verhungern Sie Ihren Reranker nicht: die 50er-Regel

Der Semantic Reranker in Azure AI Search bewertet nur die obersten 50 Ergebnisse des fusionierten Suchpools neu; er kann den Index nicht erneut durchsuchen. Microsoft empfiehlt deshalb, k und maxTextRecallSize so zu setzen, dass sie zusammen mindestens 50 ergeben. Was der Nutzer sieht, steuern Sie danach über top.

Auf Deutsch: Die beiden Suchwege liefern zusammen einen Kandidaten-Pool ab, und k (Treffer der Vektorsuche) plus maxTextRecallSize (Treffer der Stichwortsuche) bestimmen, wie gut dieser Pool gefüllt ist. Ein zu dünner Pool deckelt die Qualität, egal wie gut das Modell dahinter ist.

Die Top-50-Grenze ist dokumentiert, nicht Folklore, und die Summenregel ist wörtlich Microsofts Best Practice. Eine Präzisierung, die oft untergeht: maxTextRecallSize steht per Default auf 1'000. Ein kleines k ist also nicht automatisch fatal; verhungern tut der Reranker vor allem auf vektorlastigen Queries mit knappem k — oder wenn Post-Filter den Pool nachträglich unter 50 drücken.

Genau da stand ich. Meine Strategie-Spezifikation setzte das Vektor-k für Definitionsfragen auf 20 (auf deren vektorlastigen Queries ein reales Verhungerungs-Risiko) und für Überblicksfragen auf 100 (verschwendet Latenz und Kosten), dazu auf zwei Intent-Pfaden exhaustive:true — Durchkämmen des ganzen Index bei jeder Query, vorbei am mühsam konfigurierten HNSW-Graphen (der Abkürzungsstruktur, die Vektorsuche schnell macht). Die Profile-Schicht hat das korrigiert: k=50 als Default, exhaustive standardmässig aus, maxTextRecallSize pro Profil bewusst auf 250 bis 500 gesenkt — ein Latenz-Kompromiss, der weit über dem Floor bleibt. Ehrlich ist auch: Ein älterer Template-Pfad meiner Wissensdatenbank schickt bis heute exhaustive:true — genau die Sorte Restbestand, um die es zwei Abschnitte weiter geht. Warum exhaustive und unnötige Round-Trips ganze Sekunden kosten, zeigt der Artikel zur Latenz-Architektur.

Ein Caveat gehört dazu: Sind die Vektor-Treffer bereits exzellent und die Textfelder dünn, kann der Reranker Ergebnisse sogar verschlechtern. Ob er bei Ihnen hilft, ist eine Messfrage, keine Glaubensfrage; dazu am Schluss mehr.

Die Poolgrösse ist aber nur die halbe Miete. Schlimmer als ein knapper Pool ist, was den Pool nie erreicht.

Confidence ist keine Relevanz

Mein teuerster Einzelfehler war ein Filter, der solide aussah: confidence_score ≥ 0.85, angewendet bevor der Reranker die Kandidaten sah. Der Wert stammt aber aus der Dokumentverarbeitung beim Indexieren; er misst, wie sauber ein Textabschnitt aus dem PDF extrahiert wurde, nicht, wie gut er zur aktuellen Frage passt. Hochrelevante Treffer mit mittelmässigem Extraktions-Score erreichten den Reranker nie. Und weil danach oft zu wenig übrig blieb, verwaltete eine Fallback-Kaskade das Problem teuer, statt es zu lösen: erst dieselbe Suche mit gelockertem Themen-Filter, immer noch bei 0.85, dann ungefiltert bei 0.80 — mehrere Suchdurchläufe für ein Loch, das der Filter selbst gegraben hatte. Bezeichnend ist die Reihenfolge: Gelockert wurde zuerst der Filter-Umfang, die Schwelle erst zuletzt. So plausibel fühlte sich die falsche Achse an.

Das Prinzip dahinter ist unbequem und allgemein: Stufe 1 soll breit einsammeln (Recall), der Reranker in Stufe 2 fein sortieren (Präzision). Was vor dem Reranker gefiltert wird, ist unwiederbringlich weg; kein Reranker kann Kontext retten, den die erste Stufe nie geliefert hat.

Der Fix hat zwei Hälften, und der Stand ist lehrreicher als jeder Erfolgsbericht. Die erste Hälfte läuft: Mein neues Index-Schema ist heute der Live-Default, und dort ist confidence_score ein sanfter Ranking-Bonus (eine magnitude-Scoring-Funktion) statt eines Ausschlusskriteriums. Die zweite Hälfte ist das Gegenteil von erledigt, und zwar auf aufschlussreiche Weise: Der Template-Pfad der Wissensdatenbank filtert weiterhin hart auf 0.85 — der agentische Suchpfad daneben filtert gar nicht. Zwei Retrieval-Pfade im selben System beantworten dieselbe Grundsatzfrage entgegengesetzt, und im Betrieb merkt es niemand.

Dieser Widerspruch ist kein Ausrutscher. Er ist ein Strukturproblem, und er führt zur vielleicht übertragbarsten Lektion des ganzen Umbaus.

Retrieval-Policy gehört an eine Stelle

Wenn Query-Konstruktion über fünfzehn Aufruf-Stellen verstreut ist, driften die Stellen auseinander: Ein Pfad bekommt den neuen Filter, der andere nicht; ein Pfad stellt exhaustive ab, der andere vergisst es; ein Refactoring später widersprechen sich zwei Suchwege in einer Grundsatzfrage — exakt die beiden Restbestände aus den letzten zwei Abschnitten. Die architektonische Antwort in meinem System ist ein einziger Engpass, durch den jeder Suchaufruf muss: eine Profil-Funktion, die aus einem benannten Profil den vollständigen Request baut. Elf solcher Profile gibt es, und jedes bündelt sämtliche Entscheidungen dieses Artikels an einer Stelle: semantische Konfiguration, Scoring-Profil, Suchfelder, Vektorfeld-Auswahl samt Gewichten, queryLanguage aus der Nutzer-Locale, maxTextRecallSize, Captions und Answers.

Erst diese Schicht macht die «langweiligen Parameter» beherrschbar, die sonst niemand konsistent setzt:

• Scoring-Funktionen statt Feldgewichte. Scoring-Profile sind Ihre Ranking-Regeln im Index («Titel zählt doppelt», «Neueres zuerst»). Sobald der Semantic Reranker läuft, überschreibt er die Wirkung reiner Feldgewichte; nur Funktions-Boosts überleben ins finale Ranking — freshness (neuer ist besser), magnitude (höherer Zahlenwert ist besser), tag (passendes Schlagwort ist besser). Das ist bei mir keine Theorie: Mein Beleg-Index shippt eine Freshness-Funktion auf dem Anreicherungsdatum, Magnitude-Funktionen auf Extraktionsqualität und Struktur-Boost sowie Tag-Funktionen auf Entitäts-Schlüsseln, die zur Query-Zeit als Scoring-Parameter mitgegeben werden. Diese Integration ist jung; vor etwa Mai 2025 wurden Profile vom Reranker rettungslos überschrieben, was viele veraltete Ratschläge im Netz erklärt.
• queryRewrites mit Schutzschalter. Azure formuliert die Nutzerfrage automatisch in Varianten um und sucht mit allen: ein billiger Recall-Gewinn bei unpräzisen Fragen. Microsofts eigene Doku nennt den Caveat: Bei Artikelnummern, IDs und wörtlichen Zitaten können Rewrites exakte Terme verlieren. In meiner Profil-Schicht schaltet eine Exact-Value-Erkennung die Rewrites für solche Queries automatisch ab — zentral, nicht pro Aufruf-Stelle.
• Auf IDs filtern, nicht auf Strings. Entitäts-Filter («nur Dokumente zur Muster AG») laufen bei mir über kanonische, normalisierte Entitäts-Schlüssel und die eingebaute Funktion search.in() statt über handgebaute Oder-Ketten aus Rohtext. Das ist schneller, robust gegen Sonderzeichen und injection-resistent. Die Kurzform: Filtere auf IDs, nicht auf Strings.
• Tabellen als eigener Fragetyp. Enterprise-Korpora sind voller Tabellen, und «Wie hoch war der Umsatz 2024?» sucht eine Zelle, keinen Fliesstext. Bei mir tragen Tabellen-Chunks eigene Felder (is_table, Tabellen-Markdown), ein eigenes Profil boostet strukturierte Inhalte, und eine Heuristik erkennt tabellarisch klingende Fragen und schaltet den Boost zu.

Nichts davon ist einzeln spektakulär. Der Punkt ist, wo es steht: an einer Stelle, typisiert, testbar — statt in verstreuten Query-Bodies, die bei jedem Refactoring neu auseinanderlaufen. Die Regel gilt auf jedem Stack, nicht nur auf Azure: Retrieval-Policy ist Konfiguration, kein Code-Folklore. Wer sie nicht zentralisiert, produziert mit jedem Release einen neuen 0.85-Filter.

Bis hierhin ging es darum, die richtigen Treffer zu bekommen. Die zweite Hälfte der Kette entscheidet, was mit ihnen passiert — und dort verlieren viele Systeme still, was das Retrieval mühsam gewonnen hat.

Nach dem Treffer: Kontext ist ein Budget, Zitieren ein Vertrag

Retrieval endet nicht mit der Suchantwort. In jeder mehrstufigen Pipeline — ob Agent oder fester Ablauf — konsumieren nachgelagerte Schritte den gefundenen Kontext, und das naive Muster ist auch hier ein Einheitsbrei: alles an alle. Das kostet Tokens, verwässert die Aufmerksamkeit des Modells und pflanzt Fehler fort.

In meinem System bekommt deshalb nicht jeder Verarbeitungsschritt denselben Kontext, sondern eine abgestufte Sicht: nur Metadaten, Struktur oder Volltext — je nachdem, was der Schritt tatsächlich entscheidet. Der Planner, der den Ablauf entwirft, erhält rund 2'000 Tokens Dokument-Kontext; ein einzelner Retrieval-Ausführungsschritt gerade einmal 30. Nicht jeder Knoten verdient den ganzen Kontext.

Synthese-Schritte deklarieren ihre Grenzen als typisierten Vertrag statt als Ad-hoc-Kürzung: höchstens 50 Quellen, 4'000 Zeichen pro Quelle, 80'000 Zeichen total, plus eine Prioritätsstrategie, welche Quellen zuerst weichen. Und zwischen den Schritten gilt eine Regel, die wörtlich so in meiner Architektur-Doku steht: Fakten fliessen, Inhalte nicht. Nachgelagerte Schritte erhalten extrahierte Aussagen mit Quellenreferenz, nicht den Rohtext — der volle Wortlaut wird erst dort wieder eingeblendet, wo er zitiert wird.

Am Ende der Kette erzwingt eine Quellen-Registry, was überhaupt zitiert werden darf. Die beiden oberen Index-Ebenen — Dokument und Abschnitt — sind darin als nicht zitierfähig markiert; sie dienen der Navigation. Zitieren darf nur die Beleg-Ebene, blockgenau, bis hinunter zur Markierung auf der PDF-Seite. Das erzwingt die Datenschicht, nicht ein Prompt. Und das ist der Unterschied zwischen «das Modell soll bitte belegen» und «das Modell kann gar nicht anders». Wohin diese Belege fliessen und warum sie Halluzinationen den Boden entziehen, vertieft der Artikel über belegbare Antworten mit Citations.

Verallgemeinert: Behandeln Sie Kontext wie ein Budget mit Verträgen und Zitierbarkeit wie eine Eigenschaft der Datenschicht. Beides kostet wenig, und beides verhindert die zwei teuersten Downstream-Fehler — zugemüllte Kontexte und schöne, unbelegte Antworten.

Dieselben drei Siebe, zwei Programme

Wie stabil diese Schicht ist, zeigt sich daran, was sich darauf bauen lässt. In meinem System laufen heute zwei völlig verschiedene Orchestrierungen über dieselben drei Index-Ebenen, dieselben Profile und dieselbe Registry.

Der Chat-Agent arbeitet agentisch: Er bekommt die drei Ebenen als Werkzeuge (Dokumente und Abschnitte finden, zitierfähige Belege holen, Kontext um eine Fundstelle herum erweitern) und entscheidet im Dialog selbst, was er als Nächstes braucht. Die Schreib-Seite arbeitet deterministisch: Ein fester Ablauf entscheidet pro Frage-Modus, welche Ebenen überhaupt betreten werden — eine Nachschlage-Frage überspringt die Dokument-Ebene komplett, eine Recherche-Frage durchläuft alle drei mit Drilldown von den Top-Dokumenten über Abschnitte zu Belegen. Ampel-Gates auf Basis der Reranker-Scores entscheiden, ob die Abdeckung reicht, und pro Wissensdatenbank-Frage ist höchstens ein einziger LLM-Aufruf erlaubt.

Die Lektion daraus ist die Investitions-Entscheidung, die dieser Artikel begründen soll: Der Wert steckt in der stabilen Retrieval-Schicht — Index-Ebenen, Profile, Registry —, nicht in der Orchestrierung darüber. Agentisch, wo Dialog und Unvorhersehbarkeit regieren; deterministisch, wo Reproduzierbarkeit, Latenz und Kosten zählen. Wer die Schicht sauber baut, kann beides fahren, ohne sie anzufassen. Wer stattdessen die Orchestrierung raffiniert und die Schicht vernachlässigt, poliert das Dach eines Hauses ohne Fundament.

Sicherheit gehört in den Index

Ein einziges falsch geteiltes Dokument in einer Antwort kann ein Compliance-Review auslösen und den Rollout stoppen. Berechtigungs-Trimming ist deshalb keine Feinheit für später, sondern der zweite Pfeiler der Produktionsreife: Die auditierbare Kontrolle sitzt im Suchdienst, nicht in der Hoffnung, dass der Agent schon nichts Falsches zeigt.

Meine eigene Migration zeichnet die Industrie-Entwicklung nach. Die erste Architektur hängte an jede Suchanfrage einen handgebauten Filterausdruck an («zeige nur Dokumente, deren Berechtigungsliste diesen Nutzer enthält»); damals die einzige Option. Mit der API-Version 2025-05-01-preview kam native Document-Level-Security nach Azure AI Search: Der Suchdienst kennt die Berechtigungen pro Dokument (permissionFilter) und setzt sie selbst durch. Heute laufen in meinem System fünf Index-Schemata mit zwei Berechtigungsmodellen nebeneinander: Die drei Unternehmens-Ebenen nutzen natives Trimming, und jede Suchanfrage läuft per On-Behalf-Of-Token mit den Rechten des fragenden Nutzers — nicht mit einem allmächtigen Service-Konto. Die zwei Indexe für persönliche Dokumente laufen dagegen über eine Service-Identität mit einem Besitzer-Filter, leichtgewichtiger, weil dort genau eine Person lesen darf. Zwei Modelle in einem System sind kein Makel, sondern die ehrliche Abbildung zweier Datenräume. Entscheidend ist, dass beide im Suchdienst durchgesetzt werden: Was der Index nicht hergibt, kann der Agent nicht ausplaudern.

Die Nuance: Handgebaute Filter sind nicht obsolet. Für Firmen mit eigenem Berechtigungsmodell ausserhalb von Microsoft Entra bleiben sie Microsofts empfohlener Weg, und die native Variante ist Preview mit scharfen Limits, etwa maximal fünf verschiedene Berechtigungsbereiche (rbacScope) pro Index. Die ganze Berechtigungs-Schicht, inklusive der Frage, was der Agent sehen darf, wenn der Nutzer es nicht darf, gehört in den Artikel zum ACL-Trimming.

Bleibt der dritte Pfeiler — und die unbequemste Frage des ganzen Umbaus: Woher wissen Sie eigentlich, dass all das etwas gebracht hat?

Die Messlatte zuerst

Hier kommt das ehrlichste Eingeständnis dieses Artikels, mit einer Präzisierung, die es noch unbequemer macht. Laufzeit-Kontrollen habe ich: Jede Suche protokolliert Treffer und Zitate samt Reranker-Scores in die Datenbank, die Schreib-Pipeline erzwingt Abdeckungs-Ampeln und einen Zitat-Audit mit dokumentiertem 95-Prozent-Ziel. Was trotz zweier detaillierter Selbst-Audits, eines neuen Index-Schemas und elf Query-Profilen bis heute fehlt, ist das Offline-Goldset: gelabelte Testfragen mit bekannter richtiger Fundstelle, gegen die sich jede Änderung vorher/nachher durchmessen liesse. Der Unterschied ist fundamental: Laufzeit-Gates sagen «diese Antwort war belegt» — nur das Goldset sagt «das System ist besser geworden». Mein eigenes Audit-Dokument hält es ungeschminkt fest: «You don't have a baseline today, which means every change is invisible.» Jede Verbesserung, die dieser Artikel beschreibt, stützt sich auf dokumentierte Mechanismen und Microsofts publizierte Werte, nicht auf eigene Messungen.

Das Problem ist kein Einzelfall, sondern feldweit benannt: Produktions-RAG ohne Baseline ist «the guessing game», und eine standardisierte, reproduzierbare Methode für solche Testfragen-Sets fehlt der Branche bis heute.

Der Weg heraus ist unspektakulär und liegt auf dem Microsoft-Stack bereit: 30 bis 50 echte Fragen pro Frage-Typ aus Ihrem Korpus, jede mit der markierten richtigen Fundstelle. Darüber laufen Standard-Suchmetriken (Trefferquote, Vollständigkeit, Rangqualität), und ein umschaltbarer Index-Alias erlaubt den A/B-Vergleich zweier Schema-Versionen. Azure liefert dafür den DocumentRetrievalEvaluator im azure-ai-evaluation-SDK. Meine Einschätzung: Das Labeln ist ein Nachmittag Arbeit mit den richtigen Fachleuten, und es macht aus «gefühlt besser» einen Zahlenvergleich. Wie das Eval-Ökosystem drumherum aussieht, behandelt der Artikel über Tracing und Evals.

Für Sie als Entscheider hat die Messlatte noch einen zweiten Wert: Sie macht Anbieter-Versprechen prüfbar. Wer Ihnen «+30 Prozent Relevanz» offeriert, bekommt ab jetzt eine Gegenfrage: gemessen woran?

Die Prüfliste für Ihr bestehendes RAG

Alles Vorherige verdichtet sich zu einer Prüfreihenfolge, die Sie diese Woche auf Ihr eigenes System anwenden können, ohne etwas zu kaufen. Vorab das Prinzip, das alle zehn Punkte rahmt: Ziel ist nicht das raffinierteste Retrieval, sondern die einfachste Architektur, die messbar, sicher und gut genug ist. Reranking, Routing und Rewrites kosten Latenz und Geld; jede Stufe muss sich auf Ihrer Messlatte verdienen.

1. 1@search.rerankerScore der Top-Treffer lesen: konstant tiefe Werte signalisieren ein Content- oder Konfigurationsproblem, keinen Ranking-Bug.
2. 2Erreicht der fusionierte Pool rund 50 Kandidaten (k + maxTextRecallSize), auch nach allen Filtern?
3. 3Filtert etwas vor dem Reranker auf einer Nicht-Relevanz-Achse (Confidence, Datum, Quelle)?
4. 4Füttert ein einziger Suchtext Stichwortsuche, Vektorsuche und Reranker — und sucht jede Frage im passenden Vektorfeld?
5. 5Chunking geprüft? Kleine Einheiten suchen, grössere zurückgeben (Parent-Child).
6. 6Werden Frage-Typen geroutet — und verdient jede Verzweigung ihren Unterhalt, oder ist sie Architektur-Stolz?
7. 7Steht die Retrieval-Policy an einer Stelle im Code, oder in fünfzehn Aufruf-Stellen, die auseinanderdriften können?
8. 8Bekommt jeder nachgelagerte Schritt ein Kontext-Budget, und ist Zitierbarkeit in der Datenschicht erzwungen statt im Prompt erbeten?
9. 9Trimmt der Suchdienst Berechtigungen selbst (permissionFilter oder konsequente Filter), und läuft die Suche mit den Rechten des Nutzers?
10. 10Existiert eine Messlatte (Testfragen mit bekannter Fundstelle)? Ohne sie ist jede Antwort auf 1 bis 9 Glaube.

Bricht stattdessen die Indexierungs-Pipeline selbst, ist das ein anderes Krankheitsbild; dafür gibt es die Indexer-Diagnose. Dieselbe Retrieval-Disziplin trägt auch evidenzbasiertes KI-Schreiben unter der Recherche.

Wer diese Liste durchgeht, behandelt Retrieval als das, was es ist: eine Kette expliziter Entscheidungen — Frage klassifizieren, Programm wählen, Pool füllen, Achsen trennen, Policy bündeln, Kontext budgetieren, Zitieren erzwingen, Rechte trimmen, messen. Beim nächsten enttäuschenden Antwort-Batch verdächtigen Sie nicht mehr zuerst das Modell, sondern lesen zuerst die Reranker-Scores. Das ist der ganze Unterschied zwischen Tuning als Glaube und Tuning als Engineering.

Diese Prüfliste ist die Kurzform dessen, was ein unabhängiges RAG- und Grounding-Review von PowerLeap systematisch tut: Indexe, Query-Konstruktion, Berechtigungen und Messbarkeit gegen genau diese Fallen prüfen, bevor weiteres Budget ins Tuning fliesst. Wer die Disziplin lieber im eigenen Team aufbaut, findet Retrieval, Evaluation und Tracing im Foundry-Agent-Service-Training wieder.