RAG ohne Halluzinationen: Enterprise Knowledge Layer Schritt für Schritt¶

RAG ist der praktischste Weg, KI sicher in eine Unternehmensumgebung zu bringen. Wenn Sie Ergebnisse ohne Halluzinationen und mit Nachvollziehbarkeit wollen, bauen Sie die Knowledge Layer als Produkt — nicht als Nebeneffekt eines Chatbots.

1 Wissens-Inventar¶

Bevor Sie mit der Indexierung beginnen, müssen Sie wissen, was Sie haben. Wo sind die Dokumente? Wem gehören sie? Wie erkennen Sie, ob ein Dokument gültig ist — und nicht eine veraltete Version von 2019?

Ein Inventar ist kein technischer Schritt — es ist ein organisatorischer. Sprechen Sie mit den Menschen, die Dokumente erstellen und nutzen. Finden Sie heraus, wo die autoritativen Quellen sind und wo die Kopien von Kopien.

• Quellen kartieren: SharePoint, Confluence, Git, internes Wiki, E-Mails, Tickets
• Eigentümer identifizieren: wer erstellt das Dokument, wer genehmigt, wer aktualisiert
• Gültigkeitskriterien definieren: Datum, Version, Status (Entwurf/Genehmigt/Archiviert)
• Entscheiden, was in RAG gehört und was nicht — nicht jedes Dokument ist geeignet

2 Klassifizierung und Zugriffsrechte¶

Jedes Dokument braucht Metadaten. Ohne sie ist die Knowledge Base nur ein Textberg, aus dem das Modell ohne Kontext schöpft — und das ist ein Rezept für Halluzinationen und Sicherheitsvorfälle.

Metadaten ermöglichen Retrieval-Filterung: ein Nutzer aus Abteilung A darf keine Antworten aus Dokumenten der Abteilung B erhalten. Sensitivität, Abteilung, Gültigkeit und Sprache sind das Minimum.

• Sensitivität: öffentlich, intern, vertraulich, streng vertraulich
• Abteilung: HR, Finanzen, Recht, Produkt, Engineering
• Gültigkeit: aktuell, archiviert, Entwurf
• Sprache: CS, EN, DE — Retrieval muss den Sprachkontext respektieren
• Zugriffsrechte im RAG müssen den Zugriffsrechten im Quellsystem entsprechen

3 Chunking und Kontext¶

Schlechtes Chunking ist die häufigste Ursache für schlechte Antworten. Ein Dokument in 500-Token-Stücke zu teilen ohne Rücksicht auf die Struktur ist wie ein Buch mit der Schere zu zerschneiden und zu hoffen, dass die Ausschnitte Sinn ergeben.

Ein guter Chunk ist eigenständig — er ergibt auch ohne umgebenden Text Sinn. Gleichzeitig braucht er Kontext: aus welchem Dokument er stammt, welches Kapitel, was darüber und darunter steht.

• Nach Dokumentstruktur teilen: Überschriften, Abschnitte, Absätze — kein fixer Token-Count
• Jeder Chunk muss allein verständlich sein
• Umgebungskontext hinzufügen: Dokumenttitel, übergeordneter Abschnitt, Datum
• Überlappende Chunks: 10–20 % Overlap verhindert Kontextverlust an Grenzen
• Testen: Chunks anzeigen und fragen — „Ergibt das ohne Kontext Sinn?”

4 Indexierung und Retrieval-Strategie¶

Vektoren allein reichen nicht. Vektorsuche ist stark bei semantischer Ähnlichkeit, aber schwach bei exakten Begriffen, Zahlen und spezifischen Namen. Deshalb brauchen Sie einen hybriden Ansatz.

Eine Kombination aus Vektorsuche und Volltextsuche mit Metadatenfiltern ist der Standard. Die Gewichtung zwischen ihnen stimmen Sie anhand der Abfragetypen Ihrer Nutzer ab.

• Vektorsuche: semantische Ähnlichkeit, gut für „Wie”- und „Warum”-Fragen
• Volltextsuche: exakte Begriffe, Produktnamen, Vertragsnummern, Codes
• Metadatenfilter: Abteilung, Sprache, Gültigkeit — grenzen den Retrieval-Scope ein
• Re-Ranking: Cross-Encoder oder LLM-basiertes Re-Ranking der Top-K-Ergebnisse
• Recall und Precision verfolgen — nicht nur „hat es etwas zurückgegeben”

5 Quellenangaben und „Ich weiß nicht”¶

Jede Antwort muss eine Quelle haben. Der Nutzer muss sehen, aus welchem Dokument die KI geschöpft hat — und die Möglichkeit haben, es zu überprüfen. Eine Antwort ohne Quellenangabe ist eine Behauptung ohne Beweis.

Und wenn das Retrieval keine relevanten Ergebnisse liefert? Der Agent muss „Ich weiß nicht” oder „Ich habe nicht genügend Informationen” sagen. Halluzinationen entstehen, wenn das Modell auch ohne Grundlage antwortet — und genau das wollen Sie verhindern.

• Jede Antwort = Text + Quellenangabe (Dokumentname, Abschnitt, Link)
• Konfidenz-Score: bei niedrigen Retrieval-Scores nicht antworten
• Fallback: „Zu dieser Frage habe ich nicht genügend Informationen. Versuchen Sie, [Abteilung] zu kontaktieren.”
• Niemals aus dem „Allgemeinwissen” des Modells antworten — nur aus Quellen in der Knowledge Base

6 Evals¶

Sie haben zwei Arten von Evals: Retrieval-Tests und Antwort-Tests. Sie brauchen beide. Retrieval-Eval misst, ob das System die richtigen Dokumente zurückgibt. Antwort-Eval misst, ob das Modell daraus die richtige Antwort generiert.

Ein Golden Dataset ist die Grundlage: Fragen → erwartete Quelldokumente → erwartete Antworten. Ohne es wissen Sie nicht, ob sich das System verbessert oder verschlechtert.

• Retrieval-Evals: „Für diese Abfrage muss es diese Dokumente zurückgeben” (Precision, Recall, MRR)
• Antwort-Evals: „Die Antwort muss diese Informationen enthalten” (Faithfulness, Relevanz)
• Golden Dataset: 50–200 Paare, die Schlüsselszenarien abdecken
• Evals nach jeder Änderung ausführen: neues Dokument, Chunking-Änderung, Modell-Upgrade
• Automatisieren: Evals in der CI/CD-Pipeline, kein manuelles Testen

7 Betrieb¶

Die Knowledge Layer ist ein Produkt. Und Produkte werden betrieben: Monitoring, Wartung, Optimierung. RAG deployen und „laufen lassen” ist der Weg zur schrittweisen Qualitätsverschlechterung.

Verfolgen Sie, wonach Nutzer fragen. Identifizieren Sie Top-Abfragen (um sie zu optimieren), erfolglose Abfragen (um Quellen hinzuzufügen) und Kosten (um das Budget zu steuern).

• Monitoring: Antwortzeit, Retrieval-Qualitätsscore, Fehlerrate
• Top-Abfragen: was Nutzer am häufigsten fragen — optimieren Sie diese Pfade
• Erfolglose Abfragen: wo der Agent „Ich weiß nicht” sagt — fehlende Dokumente oder schlechtes Retrieval?
• Kosten: Embedding-Kosten, LLM-Aufrufe, Speicher — pro Request und insgesamt
• Versionierung: die Knowledge Base hat einen Release-Zyklus wie Software
• Regelmäßige Überprüfung: sind Dokumente aktuell? Gibt es neue Quellen?

Fazit¶

RAG ohne Halluzinationen bedeutet nicht ein besseres Modell. Es bedeutet ein besseres System um das Modell herum: saubere Quellen, korrekte Metadaten, gutes Chunking, hybrides Retrieval, verpflichtende Quellenangaben und kontinuierliche Evals. Bauen Sie die Knowledge Layer als Produkt — mit eigenem Team, Metriken und Release-Prozess.