Über Retrieval-Augmented Generation wird überall gesprochen, fast immer auf dieselbe Weise: Man nimmt ein Sprachmodell, „verbindet“ es mit den Unternehmensdokumenten, und von da an antwortet es mit Quellenangaben. Die Realität ist, wie so oft, interessanter als die Broschüre.
Wir wissen das, weil wir eine RAG-Plattform wirklich gebaut und in Betrieb genommen haben — vollständig on-premise, auf Hardware innerhalb unseres Perimeters, mit offenen Modellen. Heute ist sie die Grundlage von ACME ECMS IA & RAG Integration, und auf der zugehörigen Seite finden Sie die Schemata der Infrastruktur und eine Demo ihrer Funktionsweise. Hier erzählen wir stattdessen, was die Schemata nicht zeigen: die fünf Lektionen, die unsere Art, solche Systeme zu konzipieren, verändert haben.
1 · Die Qualität entscheidet sich im Retrieval, nicht im Modell
Die Versuchung am Anfang ist, sich auf das Modell zu konzentrieren: welches LLM, wie viele Parameter, welche Version. Das ist der falsche Teil des Problems. Wenn die Schritte, die die Dokumente abrufen, dem Modell den falschen Inhalt liefern, wird das stärkste Modell der Welt nur eines tun: das Falsche gut zusammenfassen.
Die eigentliche Arbeit liegt davor: wie die Dokumente zerlegt werden (das chunking), mit welchen Repräsentationen sie indexiert werden (die embeddings) und vor allem, wie viel Struktur die Wissensbasis erhält. In unserer Plattform lebt neben dem Vektorindex ein Knowledge Graph: aus den Dokumenten extrahierte Entitäten und Beziehungen, die es erlauben, auch Fragen zu beantworten, die mehrere Dokumente durchqueren — dort, wo semantische Ähnlichkeit allein nicht ausreicht.
2 · Hybrides Retrieval plus Re-Ranking: zwei Schritte, nicht einer
Ein einzelner Suchschritt muss sich zwischen zwei widerstreitenden Zielen entscheiden: nichts Relevantes zu verlieren und kein Rauschen durchzulassen. Die Lösung, die für uns funktioniert hat, ist, die beiden zu trennen.
Der erste Schritt ist breit und hybrid — Vektoren, Schlüsselwörter und Graph zusammen — und auf Trefferquote optimiert: lieber ein Kandidat zu viel als einer zu wenig. Der zweite Schritt ist ein Re-Ranker, ein dediziertes Modell, das die Kandidaten nach tatsächlicher Relevanz für die Frage neu ordnet und aussortiert, was ähnlich klingt, aber nicht antwortet. Es ist eine der Komponenten, die die wahrgenommene Qualität der Antworten am stärksten gehoben haben: Die zitierten Quellen sind nicht mehr bloß „nah am Thema“, sondern die richtigen.
3 · Nicht jede Frage verdient das RAG
Ein häufiger Fehler ist, jede Anfrage gleich zu behandeln: Was auch immer der Nutzer fragt, es wird die gesamte Pipeline gestartet — Suche, Re-Ranking, Generierung mit Kontext. Das Ergebnis sind langsame und teure Antworten, auch wenn nichts davon nötig gewesen wäre.
In unserer Architektur trifft die erste Entscheidung ein Planner: eine Komponente, die die Anfrage klassifiziert und den Weg wählt. Ein Gruß oder eine Allgemeinwissensfrage nimmt den direkten Weg, ohne die Dokumentenbasis zu berühren; eine Frage zu Verträgen, Verfahren oder Projekten aktiviert die vollständige Pipeline. Das klingt nach einem Detail: Im Betrieb ist es der Unterschied zwischen einem System, das „antwortet, wenn es kann“, und einem Dienst mit vorhersehbaren Latenzen und Verbräuchen.
4 · Ohne Metriken raten Sie nur
Sie wechseln das Embedding-Modell, und die Antworten „wirken“ besser. Sie überarbeiten das Chunking, und sie „wirken“ schlechter. Wirken — auf wen? Bei welchen Fragen? Das Gefühl der Entwickler ist keine Metrik, und bei einem System, das in natürlicher Sprache antwortet, gewöhnt sich das Auge schnell.
Deshalb umfasst die Plattform eine systematische Qualitätsbewertung (wir verwenden das Framework RAGAS, mit einem auf Italienisch aufgebauten Testset zu unseren Anwendungsfällen): Bei jeder Änderung messen wir, wie quellentreu die Antworten bleiben, wie relevant für die Frage sie sind und wie gut der abgerufene Kontext ist. Es ist dasselbe Prinzip wie in unserer Methode — messen, analysieren, verbessern, verifizieren — angewandt auf die KI: Jeder Eingriff beginnt mit einer Zahl und endet mit einer Zahl.
Die richtige Frage ist nicht „Antwortet die KI gut?“, sondern „Verglichen womit, gemessen wie, und besser oder schlechter als gestern?“.
5 · On-premise ist machbar — und manchmal der einzige Weg
Die vielleicht kontraintuitivste Lektion: Ein Unternehmens-RAG braucht keinen Hyperscaler. Offene Modelle auf GPUs, die auf den Anwendungsfall dimensioniert sind, innerhalb einer beherrschten Infrastruktur, decken die allermeisten realen Anforderungen ab — und bringen einen Vorteil, den keine entfernte API bieten kann: Die Daten verlassen den Perimeter nie.
Für ganze Branchen ist das keine Marotte, sondern eine Anforderung. Im Gesundheitswesen genießen Gesundheitsdaten den verstärkten Schutz nach Art. 9 GDPR (DSGVO); in der Öffentlichen Verwaltung wiegen Datensouveränität und Cloud-Vorgaben schwer. Eine On-Premise-Architektur (oder auf Private Cloud in Italien) löst das Problem an der Wurzel — und eliminiert mit offenen Modellen auch den Vendor-Lock-in.
Die andere Hälfte der Lektion: Ein solches System muss wie ein Dienst betrieben werden, nicht wie ein Experiment. Monitoring der Komponenten, Backup der Wissensbasis, kontrollierte Modell-Updates: Der „Betriebsteil“ zählt ebenso viel wie der Entwurf.
Womit anfangen
Müssten wir die fünf Lektionen in einen einzigen Rat verdichten: Starten Sie klein, aber starten Sie messend. Ein konkreter Anwendungsfall, ein definierter Dokumentenkorpus, Qualitätsmetriken vom ersten Tag an — und eine Architektur, die Sie nicht zwingt, zwischen Innovation und Daten am richtigen Ort zu wählen.
Wie unsere Plattform aufgebaut ist — Infrastrukturschemata, logischer Ablauf und eine animierte Demo des Lebenszyklus — zeigt die Seite KI, Agenten und RAG. Wenn Sie hingegen verstehen möchten, was sie mit Ihrem Dokumentenbestand leisten könnte, sprechen wir darüber.
