RAG-Systeme

Warum ein Sprachmodell allein die Firmenfragen nicht beantwortet

Ein Sprachmodell kennt die Firma nicht. Es kennt weder die Preisliste noch die Wartungsintervalle noch den Vertrag mit Kunde Meyer. Fragt man trotzdem, entsteht eine plausibel klingende Antwort — nur eben erfunden. Retrieval-Augmented Generation, kurz RAG, löst das anders herum: Erst wird in den eigenen Dokumenten gesucht, dann formuliert das Modell ausschließlich auf Basis der gefundenen Stellen und nennt die Quelle dazu.

Damit verlagert sich die entscheidende Frage von „welches Modell" auf „wie gut findet die Suche". Und genau dort scheitern die meisten Projekte, nicht am Modell.

Vier Architekturen — und wann welche trägt

• Vector RAG: Dokumente werden in Abschnitte zerlegt, semantisch eingebettet und nach Bedeutungsähnlichkeit gefunden. Stark bei sinngemäßen Fragen in Fließtext. Schwach, sobald exakte Kennungen zählen.
• Hybrid RAG mit Reranking: Semantische und klassische Stichwortsuche laufen parallel, die Trefferlisten werden zusammengeführt und ein Reranker sortiert gegen die Originalfrage neu. Der Standardfall, sobald Artikelnummern, Normen oder Produktnamen im Spiel sind.
• Knowledge Graph und GraphRAG: Entitäten und ihre Beziehungen werden explizit modelliert. Nötig, wenn Antworten über mehrere Stationen führen — „welcher Mitarbeiter betreute das Projekt des Kunden, dessen Vertrag Klausel X enthält".
• SQL-Agent und SQL + RAG: Kennzahlen werden berechnet, nicht aus ähnlich klingenden Textstellen geschätzt. Für Fragen, die Zahlen und erklärende Dokumente gleichzeitig brauchen, kombiniert ein Router beide Wege.

Reine Vektorsuche verfehlt Artikelnummern zuverlässig. Wenn eine falsche Kennung geschäftskritisch ist, führt an einem lexikalischen Suchpfad kein Weg vorbei.

Die unsichtbaren Erfolgsfaktoren

Was über Qualität entscheidet, sieht man der fertigen Oberfläche nicht an. Beim Chunking geht es darum, Dokumente entlang ihrer fachlichen Struktur zu teilen statt nach Zeichenzahl — eine Definition, die von ihrem Wert getrennt wird, ist danach unauffindbar. Metadaten führen Quelle, Version, Bereich und Berechtigung mit, damit vor jeder Suche gefiltert werden kann. Und die Zitationsschicht bindet jede Aussage an eine konkrete Fundstelle, samt der Möglichkeit, ehrlich „dazu finde ich nichts" zu antworten.

Letzteres ist der unterschätzte Punkt. Ein System, das nicht schweigen darf, wird raten.

Erst messen, dann urteilen

Retrieval und Antwortqualität werden getrennt gemessen. Zuerst die Frage: Liefert die Suche die relevante Stelle überhaupt unter die ersten Treffer? Erst danach: Formuliert das Modell daraus eine korrekte Antwort? Wer beides vermischt, optimiert am falschen Ende. Dafür braucht es ein Goldset aus typischen, schwierigen, veralteten und bewusst unbeantwortbaren Fragen — vor dem Bau eingefroren und fachlich abgenommen.

Wofür das nichts ist

• Die Ablage „wie sie ist" in einen Index kippen.
• Die Hoffnung, ein größeres Modell ersetze Chunking, Rechtefilter und Messung.
• Antworten ohne Fundstelle und ohne Erlaubnis zu schweigen.

Was nach der Arbeit in der Hand liegt

• Dateninventar plus Stichprobe, bevor die Architektur festliegt.
• Begründete Architekturempfehlung — der Readiness-Check bleibt die Fünf-Minuten-Voreinordnung.
• Pipeline bis zur Zitationsschicht; Goldset und Harness, Retrieval und Antwortqualität getrennt.

Wie wir dabei unterstützen

• Dateninventar und Stichprobenprüfung, bevor eine Architektur festgelegt wird.
• Architekturempfehlung mit Begründung — unser KI-Readiness-Check liefert dafür in fünf Minuten eine erste Einordnung.
• Aufbau der Pipeline von Parsing und Chunking über Index und Reranking bis zur Zitationsschicht.
• Evaluations-Harness mit Goldset und Rechte-Negativtests, damit Qualität nachweisbar bleibt statt gefühlt.