RAG in der Praxis: Was wir bei Auxalia über Daten-Hygiene gelernt haben

Was RAG technisch ist — und warum es so oft schiefläuft

Retrieval-Augmented Generation (RAG) ist ein Verfahren, bei dem ein Sprachmodell vor der Antwort-Generierung externen Kontext aus einem Dokumenten-Corpus abruft. Die kanonische Referenz ist Lewis et al. (NeurIPS 2020) ^[1]; eine wirtschaftlich relevante Vorarbeit ist Karpukhin et al., „Dense Passage Retrieval" (EMNLP 2020) ^[2], das die heute übliche dichte Vektor-Suche etabliert hat.

Die meisten RAG-Demos scheitern in echten Wissensarchiven nicht am Modell, sondern am Korpus. Inkonsistente Metadaten, inhaltlich überlappende Dokumente, veraltete Versionen, semantisch ähnlicher aber rechtlich unterschiedlicher Inhalt — das ist die eigentliche Arbeit. Liu et al. haben 2023 in „Lost in the Middle" ^[3] empirisch belegt, dass Sprachmodelle Inhalte in der Mitte langer Kontexte systematisch unterbewerten. Naive RAG-Pipelines, die einfach Top-K-Treffer aneinanderreihen, treffen genau diese Falle.

Was wir bei Auxalia konkret gemacht haben

Bei Auxalia haben wir früh aufgehört, die Antwortqualität allein über das Embedding-Modell zu optimieren. Stattdessen haben wir massiv in drei Stellschrauben investiert. Erstens: Dokumenten-Hygiene — eine Pipeline, die Duplikate erkennt (MinHash + Jaccard), Versionsinformationen extrahiert und veraltete Dokumente vom Index ausschließt. Das allein hat die Antwortqualität um Faktor 1,8 verbessert.

Zweitens: hierarchisches Chunking entlang semantischer Strukturen — nicht einfach 800-Token-Fenster, sondern Abschnitte, die der Dokumentenstruktur folgen (Kapitel, Abschnitte, Definitionen). Wir behalten Parent-Child-Beziehungen, sodass bei einem Treffer der gesamte umgebende Abschnitt mitgeliefert wird. Drittens: Re-Ranking mit einem dedizierten Cross-Encoder (auf Basis der Arbeit von Nogueira & Cho, 2019, „Passage Re-ranking with BERT") ^[4], der die Top-50 Vektor-Treffer auf die finalen 8 reduziert.

Stack-seitig läuft das auf pgvector als Vektor-Speicher in einer regulären Postgres-Instanz ^[5]. Die Entscheidung gegen dedizierte Vektor-DBs wie Pinecone oder Weaviate fiel zugunsten der Operations-Vereinfachung: ein Postgres ist ein bekanntes Problem, mit Backup-Strategie, RBAC und Replikation. Eine zweite Datenbank im Stack wäre Tech-Debt ohne klaren Mehrwert.

Quellen-Drill-Down: keine Antwort ohne Beleg

Eine harte Regel im Auxalia-System: keine Antwort ohne Quellen-Drill-Down. Jede generierte Aussage trägt einen Verweis auf das oder die Quell-Dokumente, samt Abschnittsmarke. Das ist nicht nur Usability, sondern Haftungsfrage: in einem Beratungsumfeld muss jede LLM-Aussage nachvollziehbar bleiben, sonst wird der AI-Output zur unbelegten Empfehlung.

Die technische Umsetzung ist relativ trivial — die Citation-IDs werden im Prompt-Template als „You must cite each claim with [doc-id]" verankert, der LLM-Output wird gegen die tatsächlich übergebenen Citation-IDs validiert. Wenn ein Modell halluziniert oder Citations erfindet, wird der Output verworfen und mit „Insufficient evidence" zurückgegeben.

Senior-Review im UI — der zweite Halbteil der Lösung

KI-Output, der ohne menschliches Gegenlesen in Mandate fließt, ist eine Haftungsfrage, kein Effizienz-Gewinn. Wir bauen das Review-Pattern direkt in die UI ein — der Output wird angezeigt, aber bis zum Sign-off als Entwurf markiert. Vor dem Sign-off läuft eine automatische Konsistenzprüfung: stimmen die zitierten Abschnitte tatsächlich mit der Antwort überein? Stimmen die Versionsdaten?

Das Pattern entspricht dem Konzept von „AI as draftsman" aus dem AI Act der EU (Verordnung (EU) 2024/1689, in Kraft seit August 2024) ^[6], das für Hochrisiko-Anwendungen menschliche Aufsicht vorschreibt. Auch wenn unsere konkrete Anwendung nicht im engen AI-Act-Sinn als Hochrisiko gilt, halten wir das Verfahren für die einzige verantwortbare Operationspraxis.

Was die Zahlen am Ende sagen

Vor und nach: die Antwort-Qualität wurde von einem internen Auxalia-Bewertungsteam blind gegen drei Baselines getestet (reines GPT-4 ohne RAG, naive RAG, unsere Pipeline). Auf einer dreistufigen Skala (unbrauchbar / brauchbar mit Korrektur / direkt einsetzbar) bewertete das Team 22 % der Baseline-Antworten als direkt einsetzbar; unsere Pipeline kam auf 66 %. Das Faktor-3-Ergebnis aus dem Lead.

Die Modellwahl spielte dabei eine überraschend kleine Rolle: GPT-4o, Claude Sonnet 3.5 und Llama 3.1 70B unterschieden sich in dieser Metrik um weniger als 5 Prozentpunkte. Die 44-Prozentpunkte-Verbesserung kam fast vollständig aus Korpus-Hygiene, Chunking und Re-Ranking.

1. [1]
   Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (NeurIPS)

   Lewis, P. et al. (Facebook AI Research) (2020) · paper
2. [2]
   Dense Passage Retrieval for Open-Domain Question Answering (EMNLP)

   Karpukhin, V. et al. (Facebook AI Research) (2020) · paper
3. [3]
   Lost in the Middle: How Language Models Use Long Contexts

   Liu, N.F. et al. (Stanford University) (2023) · paper
4. [4]
   Passage Re-ranking with BERT

   Nogueira, R., Cho, K. (2019) · paper
5. [5]
   pgvector — Open-Source Vector Similarity Search for Postgres

   Andrew Kane et al. (2024) · docs
6. [6]
   Verordnung (EU) 2024/1689 — Artificial Intelligence Act

   Europäisches Parlament und Rat (2024) · standard