Was wir beim Aufbau produktiver RAG-Systeme für Enterprise-Kunden gelernt haben

Eine RAG-Demo ist einfach: einige Dokumente einbetten, die besten Treffer abrufen, in einen Prompt packen. Produktives RAG ist eine völlig andere Disziplin, und die meisten schwierigen Probleme liegen außerhalb des Modells.

Die Chunking-Strategie zählt mehr als die Modellwahl. Schlecht aufgeteilte Dokumente, mitten im Satz abgeschnitten, ohne Überschriften, ohne Metadaten, erzeugen selbstbewusst falsche Antworten, unabhängig davon, welches LLM dahinterliegt. Wir verbringen einen überproportionalen Teil der frühen Projektphase mit Dokumentstruktur und Metadaten, bevor wir die Retrieval-Pipeline überhaupt anfassen.

Evaluation muss aufgebaut werden, bevor das Feature live geht, nicht erst, wenn sich Nutzerinnen und Nutzer beschweren. Wir bauen früh in jedem Projekt ein kleines, gelabeltes Evaluationsset aus echten Anfragen auf und führen es bei jeder Prompt- oder Retrieval-Änderung erneut aus, damit Regressionen auffallen, bevor ein Kunde sie findet.

Reine Vektor-Ähnlichkeitssuche versagt bei Anfragen, die von einem exakten Begriff, einem Produktcode oder einem Namen abhängen, den das Embedding-Modell nicht stark gewichtet. Hybride Suche, die Vektor-Ähnlichkeit mit Keyword-/BM25-Abgleich kombiniert und die zusammengeführten Ergebnisse neu bewertet, schlägt beide Ansätze einzeln konsequent, sobald der Dokumentbestand groß oder die Anfragen spezifisch werden. Sie ist aufwendiger zu bauen und abzustimmen, und das lohnt sich für alles, was über eine kleine, homogene Wissensbasis hinausgeht.

Metadaten-Filterung ist es, was Retrieval im großen Maßstab vertrauenswürdig macht, nicht nur genau. Chunks mit Quelle, Datum, Zugriffsebene und Dokumenttyp zu markieren, erlaubt es, das Retrieval einzugrenzen, bevor die Ähnlichkeitssuche überhaupt läuft, was sowohl für die Antwortqualität wichtig ist (kein überholtes Richtliniendokument abrufen) als auch für die Zugriffskontrolle (kein Dokument abrufen, das diese Person nicht sehen darf, egal wie gut es zur Anfrage passt).

Schutzmechanismen und Vertrauenssignale sind genauso wichtig wie Genauigkeit. Ein System, das sagt „Ich bin mir nicht sicher, hier ist eine Ansprechperson", schneidet besser ab als eines, das selbstbewusst und falsch antwortet, besonders in Support- und compliance-nahen Anwendungsfällen, in denen eine falsche Antwort mehr kostet als eine langsame.

Observability muss von Tag eins an eingebaut werden, nicht erst, wenn etwas kaputtgeht. Wir protokollieren die abgerufenen Chunks zusammen mit der generierten Antwort bei jeder produktiven Anfrage, nicht nur das Endergebnis, denn wenn eine Antwort falsch ist, liegt der Fehler fast immer im Retrieval, und man kann nicht debuggen, was man nicht erfasst hat.

Kosten und Latenz sind Produktentscheidungen, keine nachrangigen Infrastrukturfragen. Welches Modell welche Anfrage bearbeitet, wann gecacht wird und wann ein kleineres Modell ausreicht, sind Entscheidungen, die wir bewusst treffen, weil sie die Unit Economics des Features verändern.