Ihr RAG-Chatbot indexiert interne Dokumente, und einige Nutzer sehen plötzlich Daten, die sie nicht sehen dürften. Was ist die Ursache und die Lösung?
Kurzantwort
Wenn der Abruf jedes indexierte Dokument liefert, egal wer fragt, gibt das Modell getreu Daten preis, die der Nutzer nicht sehen sollte — das ist ein Autorisierungsfehler, keine Halluzination. Erzwingen Sie die dokumentbezogenen Berechtigungen des Nutzers zum Zeitpunkt des Abrufs, sodass nur autorisierte Fragmente in den Kontext gelangen. Ein längerer System-Prompt ist umgehbar und implementiert keine Zugriffskontrolle, die Temperatur ist irrelevant, und ein anderes Modell hat dieselbe Lücke.
Ein Nutzer stellt dem Chatbot eine Frage und erhält den Inhalt eines Dokuments, auf das er nie hätte zugreifen dürfen — eine Gehaltsliste, die Roadmap eines anderen Teams, eine Personalakte. Der erste Impuls ist, das Modell verantwortlich zu machen. Das ist der falsche Impuls.
Warum es um Autorisierung geht, nicht um Halluzination
Das Modell tut genau, was ihm aufgetragen wurde: Es erhielt dieses Dokument in seinem Kontextfenster und fasste es korrekt zusammen. Der Fehler geschah vor der Generierung, im Abrufschritt. Wenn Ihr Retriever eine Ähnlichkeitssuche über den gesamten Index ausführt und die Top-k-Fragmente liefert, ohne zu berücksichtigen, wer fragt, dann ist jedes hinreichend relevante geheime Dokument Freiwild. Das Modell kann keine Berechtigung durchsetzen, die es nie erhalten hat.
Das ist die klassische fehlerhafte Zugriffskontrolle im KI-Gewand. RAG verwandelt Ihr gesamtes Dokumentenkorpus klammheimlich in eine abfragbare Oberfläche, und eine Oberfläche, die den Link zu einer Datei verbirgt, nützt nichts, wenn der Abruf deren Text trotzdem in den Prompt zieht.
Die Lösung: beim Abruf autorisieren
Erzwingen Sie die dokumentbezogenen Berechtigungen des Nutzers zum Abfragezeitpunkt, sodass nur Fragmente, auf die er Anspruch hat, in den Kontext gelangen. Konkret:
- Hängen Sie bei der Ingestion an jedes Fragment Eigentums-/ACL-Metadaten an.
- Übergeben Sie die authentifizierte Identität des Nutzers und seine Gruppenzugehörigkeiten an den Retriever und filtern Sie, bevor die Ähnlichkeitssuche Ergebnisse liefert, nicht danach.
- Prüfen Sie Berechtigungen zum Antwortzeitpunkt für alles Sensible erneut, und reindexieren bzw. invalidieren Sie Dokumente, wenn sich ihre ACLs ändern.
Warum die Distraktoren gefährlich sind
- Temperatur erhöhen / Halluzination: Die Temperatur ändert die Zufälligkeit, nicht, welche Daten abrufbar sind. Die Daten sind echt und korrekt abgerufen — genau das ist das Problem.
- Längerer System-Prompt: Ein Prompt, der das Modell zu „Vorsicht" auffordert, ist ein weiches, umgehbares Geländer über bereits durchgesickertem Kontext. Eine Prompt-Injection oder eine geschickte Frage hebelt es aus. Zugriffskontrolle muss eine harte Prüfung im Code sein.
- Modell wechseln: Jedes Modell gibt das preis, was Sie in seinen Kontext legen. Ein anderes Modell erbt dieselbe Abruf-Lücke.
Was Interviewer hören wollen
Dass Sie den Fehler in der Abruf-/Autorisierungsschicht verorten, Least Privilege pro Nutzer erzwingen und sich nie auf den Fließtext des Modells verlassen, um eine Zugriffskontrollentscheidung zu ersetzen, die die Anwendung treffen sollte.
Wahrscheinliche Anschlussfragen
- Wie würden Sie eine nutzerbezogene Filterung in einer Vektordatenbank umsetzen, die nur Ähnlichkeitssuche kann?
- Warum ist das Filtern der Antwort nach der Generierung schlechter als das Filtern beim Abruf?
- Wie behandeln Sie Dokumente, deren Berechtigungen sich nach der Indexierung ändern?