Vor zwei Jahren haben wir ein RAG-System für einen Fertigungsbetrieb eingeführt, der eine umfangreiche Bibliothek technischer Richtlinien und Servicehandbücher verwaltet. Das System antwortete flüssig, klang selbstsicher, und die Bediener gewöhnten sich schnell daran. Das Problem trat beim ersten internen Audit auf: Ein Sicherheitsingenieur fragte, aus welchem konkreten Dokument das Verfahren zum Abschalten der Linie stammt. Das System antwortete — aber niemand im Raum konnte überprüfen, ob das die Wahrheit war oder nur eine überzeugend klingende Halluzination. Das Audit endete mit der Empfehlung, das System vorübergehend außer Betrieb zu nehmen.
Dieses Szenario ist kein Einzelfall. Für jeden, der RAG in einem regulierten oder haftungsrelevanten Umfeld einsetzt — Fertigung, Energie, Bauwesen, Recht, Gesundheitswesen — ist Grounding (die Verankerung einer Antwort in konkreten Quellen) und Attribution (die Zuordnung einer Antwort zu einer zitierfähigen Quelle) genauso wichtig wie die Genauigkeit der Antwort selbst. Dieser Artikel erklärt, warum das so ist, welche Techniken es gibt und wo ihre Grenzen liegen.
Warum Zitierungen kein UX-Detail sind
Die meisten Teams kümmern sich um Zitierungen zu spät — als letzten Schritt vor dem Produktionsstart, wenn sich herausstellt, dass „irgendeine Referenz nötig ist". Das ist ein Fehler. Grounding und Attribution sind architektonische Entscheidungen, keine kosmetische Schicht.
Drei Gründe, warum das wichtig ist:
Compliance und Auditierbarkeit. In regulierten Branchen (ISO-Normen, REACH, Maschinenrichtlinie, Medizindokumentation) gilt: Jeder Ausgang, der eine Entscheidung beeinflusst, muss rückverfolgbar sein. Ein System, das „verfahren Sie gemäß Norm EN ISO 13849" sagt, ohne einen Link auf den konkreten Abschnitt und die Dokumentenversion anzugeben, erfüllt die Anforderungen eines Auditors nicht.
Vertrauen und Onboarding. Ein neuer Bediener, der die Zitierung „Sicherheitsrichtlinie BS-2024, Abschnitt 4.3, Seite 12" sieht, kann die Antwort überprüfen. Eine Antwort ohne Zitierung erfordert blindes Vertrauen in das System — und das lehnen die meisten Fachleute zu Recht ab.
Fehlerdiagnose. Wenn eine Antwort falsch ist, zeigt die Zitierung sofort, wo in der Pipeline das Problem aufgetreten ist: Das Retrieval hat das falsche Dokument geladen, oder die Generierung hat es nicht korrekt zitiert. Ohne Zitierung ist das Debuggen deutlich langsamer. (Mehr zur Pipeline-Diagnose in RAG evaluieren: RAGAS, Faithfulness, Context Precision.)
Was „Grounding" genau bedeutet
Grounding ist eine Eigenschaft der Antwort: Jede darin enthaltene Aussage ist durch eine konkrete Passage aus dem geladenen Kontext belegt. Das Gegenteil ist eine halluzinierte oder frei interpolierte Antwort, die das Modell aus seinem eigenen parametrischen Wissen generiert hat — statt aus den bereitgestellten Dokumenten.
Attribution ist die operative Umsetzung von Grounding: die Zuweisung eines konkreten Bezeichners (Dateiname, Dokument-ID, URL, Seitennummer, Abschnittsnummer) zu jeder Aussage oder zur gesamten Antwort.
Wichtige Unterscheidung: Grounding und Attribution sind verschieden von faktischer Korrektheit. Eine Antwort kann vollständig gegrounded sein — jede Aussage stammt aus dem bereitgestellten Kontext — und dennoch falsch sein, wenn das Retrieval ein falsches oder veraltetes Dokument geladen hat. Faithfulness (Konsistenz mit dem Kontext) ist nicht dasselbe wie Accuracy (faktische Richtigkeit). Auf diesen Unterschied weist auch das RAGAS-Framework ausdrücklich hin.
Techniken zur Erreichung von Grounding
1. System-Prompt mit explizitem Verbot
Die einfachste Technik: Im System-Prompt das Modell explizit anweisen, nicht aus eigenem Wissen zu antworten, und es zur Zitierung verpflichten.
Beispiel-System-Prompt:
Odpovedaj výhradne na základe poskytnutého kontextu.
Ak odpoveď v kontexte nie je, povedz: "Túto informáciu som v dostupných dokumentoch nenašiel."
Každé tvrdenie uvádzaj vo formáte: [Zdroj: {doc_id}, strana {page}].
Nevymýšľaj obsah, ktorý nie je v kontexte.Vorteile: einfach, schnell, null Infrastrukturkosten.
Grenzen: Modelle halten diese Regel nicht immer zuverlässig ein — insbesondere bei langen Kontexten, in denen die relevante Passage zwischen anderen Dokumenten verloren geht. Position Bias (das Modell bevorzugt den Anfang oder das Ende des Kontexts) ist ein reales Problem, das bei allen Frontier-Modellen dokumentiert ist.
2. Strukturierter Output mit Referenz pro Aussage
Statt freiem Text fordert man das Modell zu einem strukturierten Output auf (structured outputs / JSON-Modus), in dem jede Aussage eine Quellenreferenz enthält:
{
"answer": "Maximálna prevádzková teplota je 85 °C.",
"citations": [
{
"claim": "Maximálna prevádzková teplota je 85 °C.",
"source_id": "manual-v3.2.pdf",
"page": 47,
"section": "4.2 Teplotné limity",
"quote": "Operating temperature must not exceed 85 °C under continuous load."
}
]
}Dieser Ansatz ermöglicht automatische Verifikation: Nach der Generierung kann man programmgesteuert prüfen, ob das zitierte quote tatsächlich auf der angegebenen Seite im Dokument existiert. Wenn nicht, markiert man die Antwort als nicht verifizierbar.
Vorteile: Die Zitierung ist maschinenlesbar und automatisch verifizierbar.
Grenzen: Erhöht die Ausgabelänge und die Anforderungen an das Context Window; bei manchen Modellen nimmt die Zitierpräzision bei komplexeren Fragen ab.
3. Post-Generierungs-Verifikation (Grounding-Check)
Ein robusterer Ansatz trennt Generierung und Verifikation. Nach der Generierung der Antwort startet man einen zweiten LLM-Call, der sowohl den ursprünglichen Kontext als auch die generierte Antwort erhält und jede Aussage überprüft:
Pre každé tvrdenie v odpovedi uveď:
- claim: citát tvrdenia
- supported: true/false
- evidence: pasáž z kontextu, ktorá tvrdenie podporuje (alebo null)Das Ergebnis nutzt man zum Filtern: Aussagen, die als supported: false markiert sind, werden entweder entfernt oder in der UI mit einem roten Flag versehen.
Dies ist der konzeptuelle Kern der Faithfulness-Metrik in RAGAS — gemessen wird, welcher Anteil der Aussagen in einer Antwort durch den geladenen Kontext gestützt wird.
Vorteile: Zitierungen werden unabhängig verifiziert, nicht nur vom Modell generiert; reduziert die Rate nicht verifizierbarer Aussagen erheblich.
Grenzen: Doppelte LLM-Kosten pro Antwort; die Latenz steigt. Für Echtzeit-Anwendungen ist ein Kompromiss sinnvoll: Online-Generierung, asynchrone Verifikation mit Flagging im Log.
4. Multi-Vector-Retrieval und Grounding auf Passage-Ebene
Fortgeschrittene Technik: Statt ganzer Dokumente gibt das Retrieval konkrete Passagen mit ihren Bezeichnern zurück. Das Modell erhält nicht nur den Text, sondern auch die Metadaten jedes Chunks:
[DOC: safety-manual-v2.pdf | SEC: 4.3 | PAGE: 31 | CHUNK_ID: sm-v2-431]
Zariadenie nesmie byť spustené pri teplote pod -10 °C...
[DOC: iso-13849-2023.pdf | SEC: 6.1.2 | PAGE: 88 | CHUNK_ID: iso-13849-612]
Kategória bezpečnostnej funkcie sa určuje podľa...Das Modell hat die Bezeichner direkt im Kontext und hat eine deutlich einfachere Aufgabe: Beim Antworten verweist es nur auf die CHUNK_ID, die die betreffende Information enthält. Das Backend übersetzt die CHUNK_ID dann in einen vollständigen Verweis.
Vorteile: Grounding ist inhärent einfacher, weil das Modell Bezeichner zitiert, statt den Weg zum Dokument zu rekonstruieren.
Grenzen: Erfordert sorgfältige Metadatenanreicherung in der Ingestion-Pipeline; bei schlechtem Chunking kann eine CHUNK_ID irreführend sein. Mehr zu Ingestion und Chunking in RAG-Pipeline — 3 Qualitätseinstellungen.
Wo Grounding trotz RAG versagt
RAG reduziert Halluzinationen erheblich, eliminiert sie aber nicht. In der Praxis sehen wir vier Fehlermuster, die auch bei korrekt konfiguriertem Grounding auftreten:
Position Bias. Modelle schenken dem Anfang und Ende des Kontextfensters mehr Aufmerksamkeit. Eine relevante Passage in der Mitte zwischen Dutzenden anderer Dokumente kann ignoriert werden, auch wenn das Retrieval sie korrekt geladen hat. Lösung: Ein Reranker verschiebt die relevantesten Chunks an den Anfang des Kontexts.
Token-Level-Interpolation. Das Modell verschmilzt manchmal Informationen aus mehreren Passagen und erzeugt eine Aussage, die wörtlich in keiner von ihnen steht — auch wenn jede Hälfte der Aussage aus einem anderen Dokument stammt. Dies ist eine subtile Form der Halluzination, die ein Grounding-Check nur aufdeckt, wenn er wirklich granular ist.
Zitierung einer existierenden, aber irrelevanten Quelle. Das Modell kann ein Dokument zitieren, das im Kontext vorhanden ist, die betreffende Information aber nicht enthält. Wenn man nur eine oberflächliche Prüfung macht (existiert die Quelle im Kontext?), wird das nicht auffallen. Eine tiefere Verifikation muss prüfen, ob das zitierte quote tatsächlich im Dokument vorhanden ist.
Veraltetes Dokument in der Knowledge Base. Grounding ist konsistent mit dem Kontext — aber wenn die Knowledge Base nicht aktuell ist, wird die Antwort gegrounded und gleichzeitig faktisch falsch sein. Das ist kein Fehler des Modells oder der Pipeline — es ist ein Problem der Knowledge-Base-Verwaltung. Lösung: Dokumente müssen Versionen und Gültigkeitsdaten haben; beim Suchen nach Aktualität filtern.
Grounding in regulierten Branchen
Für Unternehmen, in denen die Ausgaben von KI-Systemen bei Entscheidungen mit sicherheits- oder rechtlichem Bezug eingesetzt werden, reicht technisches Grounding nicht aus — ein auditierbarer Nachweis ist erforderlich.
In der Praxis bedeutet das:
- Jede Antwort wird mit vollständiger Zitierspur gespeichert (Dokument-ID, Dokumentversion, Seitennummer, Zeitstempel).
- Die Knowledge Base hat versionierte Einträge — man kann sagen, welche Version einer Norm an dem Tag aktiv war, als das System die Antwort generiert hat.
- Eine Dokumentänderung in der Knowledge Base invalidiert abhängige gecachte Antworten — neues Dokument, neue Antwort.
- Abgelehnte Antworten werden geloggt — wenn das System sagt „Ich habe die Information nicht gefunden", werden die Frage und der Ablehnungsgrund protokolliert.
Der EU AI Act verlangt im Kontext von Hochrisiko-KI-Systemen (z. B. Systeme im industriellen Sicherheitsbereich) Logging, Traceability und die Möglichkeit menschlicher Aufsicht. Die Zitierspur ist eine der konkreten Methoden, diese Anforderungen zu erfüllen. Mehr zu den Unternehmenspflichten in EU AI Act — Pflichten des Unternehmens.
Praktische Implementierung — wo anfangen
Wenn Sie ein RAG-System von Grund auf aufbauen oder ein bestehendes refaktorieren, empfehlen wir eine dreistufige Vorgehensweise:
- 1.Beginnen Sie mit Metadaten bei der Ingestion. Jedes Dokument erhält beim Upload eine
doc_id,version,valid_from,section_path. Ohne das sind spätere Zitierungen nur vollständige Dateinamen ohne Struktur.
- 1.Bauen Sie Bezeichner in die Prompt-Vorlage ein. Das Retrieval gibt Chunks mit Metadaten zurück; die Prompt-Vorlage formatiert sie in den für das Modell sichtbaren Kontext. Das Modell hat die Bezeichner damit direkt verfügbar.
- 1.Fügen Sie einen asynchronen Grounding-Check hinzu. In der ersten Iteration muss er nicht synchron sein — eine asynchrone Verifikation nach der Generierung genügt, das Ergebnis loggen und im Monitoring-Dashboard flaggen. Einen synchronen Grounding-Check ergänzt man, wenn Compliance das explizit erfordert.
Werkzeuge, die wir in der Praxis einsetzen: LlamaIndex für die Retrieval-Pipeline mit Metadatenanreicherung, Qdrant als Vektordatenbank mit Payload-Filtern (was das Filtern nach Dokumentversion oder Gültigkeitsdatum ermöglicht), RAGAS für regelmäßige Offline-Messung der Faithfulness. Für die Orchestrierung mehrstufiger Verifikation: LangGraph.
Häufige Fragen
Ist Grounding dasselbe wie die faktische Korrektheit einer Antwort?
Nein. Grounding bedeutet, dass die Antwort konsistent mit dem geladenen Kontext ist — jede Aussage stammt aus den bereitgestellten Dokumenten. Faktische Korrektheit hängt auch von der Qualität der Knowledge Base selbst ab. Wenn sich in der Knowledge Base ein veraltetes oder falsches Dokument befindet, kann eine Antwort vollständig gegrounded und gleichzeitig faktisch fehlerhaft sein. Deshalb ist die Knowledge-Base-Verwaltung (Versionen, Gültigkeitsdaten, Aktualisierungen) genauso wichtig wie die RAG-Pipeline selbst.
Welches Modell hält sich am besten an Zitieranweisungen?
Frontier-Modelle (Claude 4 Sonnet/Opus, GPT-4.1, Gemini 2.5 Pro) haben deutlich besseres Instruction-Following als kleinere Modelle. Bei Open-Weight-Modellen (Llama, Qwen3, Mistral) ist die Zuverlässigkeit bei der Einhaltung von Zitieranweisungen geringer, insbesondere bei langen Kontexten. Für Produktionssysteme mit Compliance-Anforderungen empfehlen wir eine Kombination: kleineres Modell für die Generierung + Post-Generierungs-Verifikations-Call. Mehr zur Modellauswahl in Wie man 2026 ein LLM-Modell auswählt.
Verlangsamt der Post-Generierungs-Grounding-Check die Systemantwortzeit?
Ja — ein synchroner Verifikations-Call verdoppelt die Generierungslatenz. Für Echtzeit-UIs ist der Standardkompromiss eine asynchrone Verifikation: Die Antwort wird sofort angezeigt, die Verifikation läuft im Hintergrund, und das Ergebnis wird als „verifiziert / nicht verifiziert"-Badge angezeigt oder für das Audit geloggt. Für Batch-Verarbeitung oder Reporting-Systeme (wo Latenz nicht kritisch ist) ist der synchrone Grounding-Check die bevorzugte Option.
Wie lässt sich die Faithfulness unseres RAG-Systems messen?
Die einfachste Methode: Erstellen Sie ein Golden Set — eine Sammlung von Fragen mit Referenzantworten und Dokumenten — und führen Sie eine RAGAS-Evaluierung durch. Der Faithfulness-Score zeigt, welcher Anteil der Aussagen in den Antworten konsistent mit dem geladenen Kontext ist. Für kontinuierliches Monitoring in der Produktion ermöglicht die Integration mit Langfuse oder LangSmith die Messung der Faithfulness an einer Stichprobe realer Anfragen. Detailliertes Vorgehen in RAG evaluieren: RAGAS, Faithfulness, Context Precision.
Muss jeder Chunk zitiert werden, oder reicht eine Quelle pro Antwort?
Das hängt vom Use-Case ab. Bei einfachen Faktenfragen (eine Antwort stammt aus einer Stelle) reicht eine Quelle. Bei komplexen Fragen, bei denen die Antwort mehrere Passagen aus verschiedenen Dokumenten synthetisiert, ist granulare Zitierung pro Aussage präziser und auditierbarer. Systeme für regulierte Umgebungen sollten standardmäßig auf Aussage-Ebene zitieren — auch wenn das die Ausgabe vergrößert.
*Wenn Sie ein RAG-System betreiben, bei dem Sie nicht nur wissen müssen, was das Modell geantwortet hat, sondern auch woher es das weiß, schauen wir uns gerne Ihre konkrete Situation an. Grounding und Zitierarchitektur sind Bestandteil jedes Einsatzes, den wir bei MP Industrial Solutions durchführen — kontaktieren Sie uns für eine erste Einschätzung.*