Engineering
RAG-Pipelines in Produktion: Lessons Learned aus Vergabepilot.AI

Daniel Holderbaum · Mitgründer und CTO
29. Juli 2026 · 7 Min. Lesezeit
Retrieval-Augmented Generation ist auf Konferenzfolien ein gelöstes Problem: Dokumente rein, Vektordatenbank, LLM, fertig. In Produktion ist es das nicht. Vergabepilot.AI, unsere semantische Suche für öffentliche Ausschreibungen, verarbeitet Daten aus über 300 Vergabeportalen und beantwortet täglich die Suchanfragen von über 13.000 Unternehmen. Hier sind die fünf Lektionen aus diesem Betrieb, die wir gern vorher gewusst hätten.
Lektion 1: Die Datenqualität entscheidet, nicht das Modell
Die unbequeme Wahrheit zuerst: Der größte Qualitätshebel unserer Pipeline war nie das Sprachmodell, sondern die Aufbereitung der Quelldaten. Vergabedaten kommen in jedem denkbaren Format, von sauberen Schnittstellen bis zu eingescannten PDFs mit dreispaltigem Layout. Ein Modellwechsel brachte uns typischerweise wenige Prozentpunkte Verbesserung, eine bessere Extraktions- und Normalisierungsschicht dagegen spürbare Sprünge. Wer ein RAG-Projekt plant, sollte den Großteil des Aufwands vor dem Embedding einplanen: Struktur erkennen, Redundanzen entfernen, Metadaten sauber setzen. Alles, was hier schiefgeht, kann keine nachgelagerte Stufe mehr reparieren.
Lektion 2: Chunking ist eine Fachentscheidung, keine technische
Die Standardantwort, Dokumente in Blöcke fester Länge zu schneiden, funktioniert für Ausschreibungen nicht. Eine Losaufteilung, die von ihrer Leistungsbeschreibung getrennt wird, ist wertlos, eine Frist ohne den zugehörigen Verfahrenskontext irreführend. Wir schneiden deshalb entlang der fachlichen Struktur der Dokumente und reichern jeden Block mit dem Kontext an, den er zum Alleinstehen braucht. Die Konsequenz für jedes RAG-Projekt: Ohne jemanden, der die Dokumentart fachlich versteht, wird das Chunking zur Lotterie.
Lektion 3: Ohne eigene Evaluation fliegst du blind
Die schwierigste Frage im Betrieb ist nicht, ob die Pipeline läuft, sondern ob sie gute Antworten gibt. Dafür gibt es keinen fertigen Maßstab, wir mussten unseren eigenen bauen: einen Evaluationsdatensatz aus echten Nutzeranfragen mit bekannten richtigen Treffern, der bei jeder Änderung an Prompt, Modell oder Retrieval automatisch durchläuft. Erst dieser Datensatz machte aus Bauchgefühl Messbarkeit. Jede Änderung, die die Trefferqualität verschlechtert, fällt heute in der Pipeline auf, nicht beim Kunden. Das ist dasselbe Prinzip wie bei unseren automatisierten Code-Checks, nur auf Modellverhalten angewandt.
Lektion 4: Halluzinationen bekämpfst du mit Architektur, nicht mit Prompts
Die Bitte im Prompt, nicht zu halluzinieren, ist ungefähr so wirksam wie ein Schild gegen Regen. Was wirkt, sind architektonische Grenzen: Das Modell darf nur aus den tatsächlich abgerufenen Quelldokumenten antworten, jede Aussage ist auf ihre Quelle zurückführbar, und wo die Quellen keine Antwort hergeben, sagt das System genau das, statt zu improvisieren. Bei Ausschreibungen, wo eine erfundene Frist echten wirtschaftlichen Schaden anrichtet, ist diese Nachvollziehbarkeit keine Kür, sondern die Grundbedingung für Vertrauen.
Lektion 5: Kosten und Latenz sind Designentscheidungen des ersten Tages
Eine RAG-Pipeline, die pro Anfrage das größte verfügbare Modell mit maximalem Kontext befragt, liefert beeindruckende Demos und unbezahlbare Rechnungen. In Produktion arbeitet bei uns ein abgestuftes System: kleine, schnelle Modelle für Klassifikation und Vorfilterung, das große Modell nur dort, wo seine Fähigkeiten den Unterschied machen, plus Caching für wiederkehrende Muster. So bleibt die Antwortzeit im Rahmen, den Nutzer von einer Suche erwarten, und die Kosten skalieren nicht linear mit dem Wachstum. Wer diese Struktur erst nachträglich einzieht, baut die halbe Pipeline neu.
Was das für dein Projekt bedeutet
RAG in Produktion ist Ingenieursarbeit: Datenaufbereitung, fachliches Chunking, eigene Evaluation, Quellenbindung, Kostenarchitektur. Nichts davon ist unlösbar, aber nichts davon steht im Schnellstart-Tutorial. Wenn du ein KI-Produkt mit deinen eigenen Daten planst, ob interne Wissenssuche, Dokumentenanalyse oder ein Datenprodukt für deine Kunden, bauen wir dir den ersten funktionierenden Teilbereich kostenlos.

Daniel Holderbaum
Mitgründer und CTO
Software-Architekt und DevOps-Kopf hinter allen Ciconia-Systemen. Er hat die Verifikations-Guardrails entworfen, durch die jede Zeile KI-generierter Code muss, bevor sie in Produktion geht.