RAG mit Microsoft Foundry: Azure AI Search und Foundry IQ einordnen

Microsoft Foundry RAG verbindet generative Modelle mit unternehmenseigenem Wissen. Der Nutzen entsteht jedoch nicht durch das bloße Anschließen eines Suchindex. Datenqualität, Berechtigungen, Aufteilung der Inhalte, Suchverfahren und Evaluation bestimmen, ob Antworten belegt und aktuell sind.

Der Ratgeber ordnet klassisches Retrieval mit Azure AI Search und agentische Ansätze rund um Foundry IQ ein. Er zeigt, welche Architekturentscheidungen vor dem ersten Index fallen sollten und wie ein Team Antwortqualität sowie Zugriffsgrenzen dauerhaft kontrolliert.

Microsoft Foundry RAG beginnt mit einer fachlichen Frage

Ein RAG-System braucht einen klaren Informationsauftrag. Soll es Servicetechniker durch Handbücher führen, Vertragsklauseln auffinden oder interne Richtlinien erklären? Daraus folgen zulässige Quellen, benötigte Metadaten, Aktualitätsziele und die Art des Quellenbelegs. „Alle Unternehmensdaten durchsuchen“ ist weder ein prüfbarer noch ein sicherer Auftrag.

Definiert werden auch Fälle, in denen keine Antwort erfolgen darf. Fehlt eine freigegebene Quelle, widersprechen sich Dokumente oder ist der Berechtigungskontext unklar, sollte das System Unsicherheit melden. Diese Regel verhindert, dass sprachliche Plausibilität mit fachlicher Gewissheit verwechselt wird.

Was Retrieval Augmented Generation leistet

Beim Retrieval sucht die Anwendung passende Informationsabschnitte und übergibt sie zusammen mit der Frage an das Modell. Das Modell formuliert daraus eine Antwort. Der Ansatz kann Wissen aktualisieren und Quellen sichtbar machen, ohne das Basismodell für jede Dokumentänderung neu zu trainieren.

RAG garantiert dennoch keine richtige Antwort. Die Suche kann ungeeignete Abschnitte liefern, relevante Inhalte übersehen oder veraltete Versionen bevorzugen. Das Modell kann Kontext falsch gewichten. Deshalb sind Retrieval und Generierung getrennt zu messen. Nur so lässt sich erkennen, ob ein Fehler aus Index, Suchabfrage oder Antwortbildung stammt.

Klassisches und agentisches Retrieval unterscheiden

Klassisches Retrieval folgt einem weitgehend vorgegebenen Ablauf: Frage aufbereiten, Suche ausführen, Treffer auswählen und Antwort erzeugen. Der Ablauf ist gut kontrollierbar und für viele Wissensanwendungen ausreichend. Filter, Trefferzahl und Kombination aus Volltext- und Vektorsuche lassen sich gezielt testen.

Agentisches Retrieval zerlegt komplexere Fragen, plant mehrere Suchschritte oder kombiniert Quellen. Das kann bei mehrteiligen Aufgaben bessere Ergebnisse liefern, erhöht jedoch Laufzeit, Verbrauch und Varianz. Foundry IQ ist in diesem Umfeld als Wissens- und Retrievalschicht einzuordnen. Seine Eignung hängt vom konkreten Dienststatus, der Region und den Betriebsanforderungen zum Einführungszeitpunkt ab.

Azure AI Search als kontrollierbare Suchschicht

Azure AI Search stellt Index, Volltextsuche, Vektorsuche, semantische Funktionen und Filter bereit. Für Unternehmens-RAG ist besonders wichtig, dass Metadaten und Berechtigungsmerkmale im Index modelliert werden können. Der Suchdienst bleibt eine eigene Architekturkomponente mit Kapazität, Netzwerk, Skalierung und Kosten.

Die Suchkonfiguration sollte nicht im Prompt versteckt werden. Indexschema, Suchprofil, Filter, Top-k und Gewichtung werden versioniert und anhand eines Referenzdatensatzes getestet. Die Foundry-Architektur zeigt, wie Projekt, Modelle, Datenzugriffe und Betriebsdienste zusammenspielen.

Datenaufnahme mit Eigentum und Aktualität planen

Vor der technischen Aufnahme wird für jede Quelle ein Eigentümer benannt. Er verantwortet Inhalt, Freigabe, Aufbewahrung und Aktualität. Ohne diese Rolle indexiert das System zwar Dateien, kann aber widersprüchliche oder veraltete Aussagen nicht fachlich klären.

Die Pipeline benötigt Regeln für neue, geänderte und gelöschte Inhalte. Löschungen sind besonders wichtig: Ein entferntes Dokument darf nicht als verwaister Indexeintrag weiter Antworten beeinflussen. Für jede Quelle werden erwartete Aktualisierungszeit, Fehlerbehandlung und ein Abgleich zwischen Ursprung und Index festgelegt.

Dokumente sinnvoll aufteilen

Chunking zerlegt Dokumente in suchbare Abschnitte. Zu kleine Chunks verlieren Zusammenhang, zu große verwässern das relevante Signal und verbrauchen Kontext. Überschriften, Tabellen, Kapitelgrenzen und Dokumenttyp sollten die Aufteilung beeinflussen. Eine starre Zeichenlänge ist nur ein Startwert.

Jeder Chunk braucht stabile Metadaten: Dokument-ID, Version, Abschnitt, Quelle, Gültigkeit, Sprache und Berechtigungsmerkmale. Überlappung kann Kontext erhalten, erzeugt aber Duplikate. Die passende Strategie wird mit echten Fragen bewertet, nicht allein mit technischen Kennzahlen.

Indexschema und Metadaten bewusst entwerfen

Ein Index enthält mehr als Text und Vektor. Filterbare Felder ermöglichen Einschränkungen nach Mandant, Bereich, Dokumentstatus oder Gültigkeitsdatum. Suchbare Titel, Synonyme und fachliche Kennzeichen erhöhen die Treffergenauigkeit. Unkontrolliert wachsende Metadaten machen Aufnahme und Abfrage dagegen unnötig komplex.

Schemaänderungen benötigen einen Migrationsweg. Manche Änderungen erfordern einen neuen Index und eine kontrollierte Umschaltung. Ein Alias oder eine Konfiguration außerhalb des Anwendungscodes erleichtert den Wechsel. Vorher wird geprüft, ob neue und alte Version dieselben Berechtigungs- und Qualitätsanforderungen erfüllen.

Berechtigungen bis zum Treffer durchsetzen

Ein RAG-System darf keine Inhalte abrufen, die der anfragende Benutzer nicht sehen darf. Das Berechtigungsmodell muss deshalb vor der Suche in einen verlässlichen Filter übersetzt werden. Eine spätere Anweisung an das Modell, vertrauliche Treffer nicht zu nennen, ist kein Zugriffsschutz.

Je nach Quelle werden Benutzer-, Gruppen- oder attributbasierte Merkmale in den Index übernommen und zur Anfragezeit angewendet. Änderungen in Entra oder dem Ursprungssystem müssen rechtzeitig wirksam werden. Testkonten mit unterschiedlichen Rollen prüfen positive und negative Zugriffe. Besonders kritische Sammlungen können in getrennten Indizes oder Diensten liegen.

Hybrid Search, Vektoren und Re-Ranking einordnen

Vektorsuche findet semantisch ähnliche Inhalte, während Volltextsuche exakte Begriffe, Artikelnummern oder Rechtsverweise zuverlässig trifft. Hybrid Search kombiniert beide Signale. Ein Re-Ranker kann anschließend die Reihenfolge verbessern. Mehr Stufen bedeuten aber nicht automatisch bessere Antworten.

Tests sollten unterschiedliche Fragetypen enthalten: natürliche Umschreibungen, genaue Produktcodes, mehrdeutige Begriffe und Fragen mit fehlender Antwort. Bewertet wird, ob relevante Abschnitte in den ersten Treffern liegen. Erst dann wird untersucht, ob das Modell daraus korrekt formuliert.

Quellenbezug als Produktanforderung behandeln

Eine Quellenangabe muss auf das tatsächlich verwendete Dokument und möglichst auf den betreffenden Abschnitt führen. Vom Modell frei erzeugte Literaturhinweise sind ungeeignet. Die Anwendung übergibt stabile Quelleninformationen aus dem Retrieval und rendert sie getrennt von der generierten Antwort.

Benutzer sollten erkennen können, wie aktuell eine Quelle ist und ob mehrere Dokumente herangezogen wurden. Bei widersprüchlichen Quellen darf das System den Konflikt nicht glätten. Es benennt die Abweichung und verweist auf die zuständigen Eigentümer oder den manuellen Klärungsweg.

Foundry IQ anhand des Einsatzes bewerten

Foundry IQ zielt auf eine verwaltete Wissensschicht für Agents und Anwendungen. Für Teams kann das die wiederverwendbare Bereitstellung von Wissensquellen und agentischem Retrieval vereinfachen. Die Entscheidung sollte trotzdem von benötigten Datenquellen, Berechtigungsmodell, regionaler Verfügbarkeit, Schnittstellen und Lebenszyklus abhängen.

Wer bereits einen kontrollierten Azure-AI-Search-Aufbau betreibt, sollte den Migrationsnutzen konkret messen. Wer neu startet, vergleicht Entwicklungsaufwand, Transparenz, Betriebsmodell und Produktreife. Preview-Funktionen gehören nicht ungeprüft in kritische Prozesse; ihr Status wird vor Architekturfreigabe und Livegang erneut kontrolliert.

RAG-Evaluation in zwei Ebenen aufbauen

Die Retrieval-Ebene misst, ob erwartete Quellen gefunden und passend gerankt werden. Kennzahlen wie Trefferabdeckung oder Rangposition benötigen einen fachlich kuratierten Referenzsatz. Die Generierungsebene bewertet Belegtreue, Vollständigkeit, Verständlichkeit und das Verhalten bei fehlender Evidenz.

Automatische Evaluatoren beschleunigen Vergleiche, ersetzen aber keine fachliche Stichprobe. Für besonders riskante Antworten gelten harte Regeln, etwa keine Aussage ohne Quelle oder keine Vermischung von Mandanten. Der Aufbau eines Foundry-Agenten sollte diese Qualitätsgrenzen bereits im Tooldesign berücksichtigen.

Betrieb, Kosten und Fehlerdiagnose verbinden

Zu beobachten sind Aufnahmefehler, Indexalter, Suchlatenz, leere Treffer, verwendete Quellen, Tokenverbrauch und Antwortabbrüche. Ein Trace verbindet Frage, Suchparameter, Treffer-IDs und Modellaufruf. Sensible Inhalte werden minimiert oder maskiert, damit Diagnose nicht selbst zum Datenrisiko wird.

Kosten entstehen durch Datenaufnahme, Embeddings, Suchkapazität, Modelle und Monitoring. Caches können Verbrauch senken, müssen aber Berechtigungen und Aktualität beachten. Eine Antwort aus einem alten Cache darf keine inzwischen entzogene Freigabe umgehen.

Einführung in kontrollierten Stufen

Die erste Stufe umfasst wenige hochwertige Quellen und einen repräsentativen Fragenkatalog. Nach bestandenen Berechtigungs- und Qualitätstests folgt eine begrenzte Nutzergruppe. Neue Quellen werden einzeln aufgenommen und gegen dieselben Prüfungen geführt. So bleibt erkennbar, welche Änderung einen Qualitätsverlust verursacht.

RAG unterstützt die Skalierung einer KI-Transformation, wenn Wissensprodukte mit Eigentum, Qualitätszielen und Betrieb aufgebaut werden. Der tragfähige Kern ist kein möglichst großer Index, sondern eine überprüfbare Kette von freigegebener Quelle bis belegter Antwort.

Goldenset nach Fragetypen aufbauen

Der Referenzsatz enthält exakte Begriffe, semantische Umschreibungen, mehrteilige Fragen, veraltete Dokumente, widersprüchliche Quellen und Fälle ohne zulässige Antwort. Für jeden Fall werden erwartete Dokumente und unerwünschte Treffer hinterlegt. Damit kann das Team Retrievaländerungen objektiv vergleichen.

Fragen stammen aus realen Arbeitsaufgaben und werden von Quellenverantwortlichen geprüft. Neue Inhalte oder Suchprofile laufen gegen denselben Kern. Ein gesonderter Sicherheitsteil prüft Benutzerrollen und manipulierte Dokumente, damit Qualitätsgewinn keine Zugriffsgrenze aufweicht.

Indexwechsel ohne Wissensausfall organisieren

Größere Schema-, Chunking- oder Embeddingänderungen werden in einem neuen Index aufgebaut. Datenvollständigkeit, Berechtigungsfilter und Goldenset-Ergebnisse werden geprüft, bevor die Anwendung umschaltet. Die bisherige Version bleibt für einen definierten Rückfallzeitraum verfügbar.

Ein Alias oder eine zentrale Konfiguration verhindert fest codierte Indexnamen in mehreren Anwendungen. Nach der Umschaltung beobachtet das Team leere Treffer, Latenz und Quellenverteilung. Erst nach stabiler Phase wird der alte Index kontrolliert stillgelegt.

Berechtigungsänderungen als eigenes Serviceziel behandeln

Qualität und Aktualität beziehen sich nicht nur auf Dokumenttext. Wird ein Benutzer aus einer Gruppe entfernt oder eine externe Freigabe beendet, muss die Suchschicht diese Änderung innerhalb einer definierten Zeit berücksichtigen. Das Team misst deshalb die Verzögerung vom Ursprungssystem über Datenaufnahme und Index bis zum gefilterten Treffer.

Negative Testfälle laufen regelmäßig mit verschiedenen Rollen. Ein entzogenes Dokument darf weder als Antwortbeleg noch als indirekter Hinweis erscheinen. Überschreitet die Pipeline das Serviceziel, werden betroffene Quellen eingeschränkt oder der Agent wechselt in einen sicheren Modus. Diese Kontrolle ist besonders wichtig, wenn mehrere Datenquellen unterschiedliche Synchronisationswege und Berechtigungsmodelle besitzen.