Retrieval-Augmented-Generation-Dienstleister: Build, Buy oder Hybrid?

Kurzurteil: Der richtige RAG-Dienstleister ist nicht der Anbieter mit den meisten Framework-Logos, sondern derjenige, der Zweck, Daten, Rechte, Tests, Betrieb und Exit vor dem Build beweisbar macht. Vergleichen Sie Build, Buy und Hybrid mit demselben Testset. Kaufen Sie keine Demo, sondern einen abnehmbaren Systemumfang mit geklärter Verantwortung.

„Retrieval-Augmented-Generation-Dienstleister“ kann eine Strategieberatung, eine Softwareagentur, eine fertige Plattform, einen Cloud-Integrator oder einen Managed-Service-Anbieter bezeichnen. Manche Anbieter bearbeiten nur Daten und Wissensquellen, andere entwickeln die gesamte Anwendung. Wieder andere verkaufen eine Oberfläche, deren Datenhaltung, Modellkosten und Betriebsgrenzen erst im Kleingedruckten sichtbar werden.

Diese Unterschiede sind wichtiger als die Frage, welcher Vector Store oder welches Sprachmodell in einer Präsentation genannt wird. Dieser Leitfaden hilft Einkauf, IT, Produkt, Fachbereich, Datenschutz und Informationssicherheit, Angebote deutschlandweit auf einer gemeinsamen Grundlage zu prüfen. Die RAG-Dienstleister-Due-Diligence-Matrix hält Anforderung, Anbieterbeleg, internes Urteil, Risiko und Exit-Folge getrennt fest.

Erst die Anbieterart bestimmen, dann Angebote vergleichen

Nicht jeder RAG-Anbieter verkauft dasselbe Ergebnis. Ordnen Sie Kandidaten vor einer Shortlist einer oder mehreren Rollen zu:

Ein Anbieter kann mehrere Rollen übernehmen. Das Angebot muss dennoch sichtbar machen, welche Verantwortung bei ihm, bei einer Plattform, bei Unterauftragnehmern und bei Ihrem Unternehmen liegt. Der Satz „End-to-End“ ist keine Rollenmatrix.

RAG kurz erklärt: Kontextzugriff statt eingebauter Unternehmenswahrheit

Das ursprüngliche RAG-Paper von Lewis et al. verbindet parametrisches Modellwissen mit abrufbarer, nicht-parametrischer Erinnerung. In einer Unternehmensanwendung bedeutet das typischerweise: Eine Nutzerfrage wird verarbeitet, passende Inhalte werden aus einem Index gesucht und dem generierenden Modell als Kontext übergeben.

Damit kann ein System auf freigegebene Unternehmensquellen zugreifen, ohne das Basismodell für jede Dokumentänderung neu zu trainieren. RAG garantiert aber weder die richtige Quelle noch die richtige Antwort. Fehler können an mehreren Stellen entstehen:

• Die benötigte Quelle fehlt oder ist veraltet.
• Parsing oder OCR zerstören Tabellen, Überschriften oder Versionshinweise.
• Chunking trennt Aussage und Einschränkung voneinander.
• Der Retriever findet plausible, aber unpassende Passagen.
• Metadaten oder Rechtefilter greifen falsch.
• Das Modell ignoriert, vermischt oder überinterpretiert den Kontext.
• Eine manipulierte Quelle beeinflusst Antwort oder Tool-Aufruf.
• Die Oberfläche zeigt eine Antwort ohne angemessene Unsicherheit oder Eskalation.

Deshalb ist „RAG eingebaut“ kein Qualitätsmerkmal. Entscheidend ist, wie der konkrete Systempfad mit realen Daten, Nutzern und Fehlerfolgen geprüft wird.

Build, Buy oder Hybrid: drei legitime Beschaffungsmodelle

Build: eigenes System mit externer Unterstützung

Beim Build besitzt Ihr Unternehmen wesentliche Teile von Anwendung, Datenmodell, Integrationen, Tests und Betrieb. Ein Dienstleister kann Discovery, Architektur oder Implementierung übernehmen, aber die technische und produktbezogene Fähigkeit soll intern verbleiben.

Build ist eher plausibel, wenn die Retrieval- oder Prozesslogik geschäftlich differenziert, tiefe Systemintegration nötig und ein dauerhaftes Engineering- und Betriebsteam vorhanden ist. Es schafft nicht automatisch Unabhängigkeit: Modelle, Cloud, Bibliotheken und externe Datenquellen können weiterhin Abhängigkeiten erzeugen.

Vor der Entscheidung klären:

• Welche Komponenten und Rechte gehen nach der Abnahme vollständig über?
• Kann Ihr Team Build, Deployment, Index und Evals ohne den Dienstleister reproduzieren?
• Wer pflegt Konnektoren, Sicherheitsupdates und Modellmigrationen?
• Welche Plattform- oder Lizenzabhängigkeiten bleiben bestehen?

Buy: Plattform oder standardisierter Managed Service

Beim Buy beziehen Sie eine vorhandene Plattform oder einen geregelten Service. Das kann sinnvoll sein, wenn der Use Case standardnah ist, interne Engineering-Kapazität begrenzt bleibt und Time-to-Learning wichtiger ist als eigene Spezialarchitektur.

Die zentrale Prüfung verschiebt sich: weniger Code-Ownership, dafür mehr Fokus auf Funktionsgrenzen, Tenant-Isolation, Unterauftragnehmer, Datenexport, Preislogik, Modellwahl, Updatekontrolle und Exit. Ein schneller Setup-Prozess ist nur dann wertvoll, wenn Qualität, Rechte und Betrieb für Ihren Datenbestand nachweisbar sind.

Vor der Entscheidung klären:

• Welche Daten und Metadaten können vollständig exportiert werden?
• Kann das Unternehmen Modell, Region, Aufbewahrung und Protokollierung steuern?
• Wie werden Plattformänderungen angekündigt und Regressionen getestet?
• Welche variablen Kosten entstehen bei Ingestion, Suche, Generierung und Monitoring?

Hybrid: eingekaufte Basis, eigene Kontrolle über kritische Schichten

Hybrid ist häufig kein Kompromiss, sondern eine bewusste Arbeitsteilung: Eine Plattform liefert Ingestion, Retrieval oder Modellzugang; das Unternehmen behält Datenfreigabe, Rechte, Testset, Produktregeln und fachliche Abnahme. Ein Integrator verbindet beide Seiten.

Das Modell funktioniert nur mit einer expliziten Schnittstellen- und Verantwortungsmatrix. Sonst werden Fehler zwischen Plattform, Dienstleister und internem Team weitergereicht. Jede kritische Funktion braucht genau einen operativen Owner und einen definierten Eskalationsweg.

Es gibt keinen universellen Gewinner. Die Due Diligence soll sichtbar machen, welches Modell für Ihren Use Case die geringste unkontrollierte Abhängigkeit erzeugt.

Acht Prüfblöcke für einen RAG-Dienstleister

1. Einsatzzweck und Systemgrenze

Der Anbieter muss den vorgesehenen Nutzer, die unterstützte Entscheidung, erlaubte Daten, ausgeschlossene Fälle und Fehlerfolgen verstehen. „Unternehmenswissen zugänglich machen“ ist zu breit für Architektur oder Abnahme.

Ein belastbarer Scope beantwortet:

• Welche Nutzergruppen stellen welche Aufgaben?
• Darf das System nur suchen, zusammenfassen oder auch Aktionen auslösen?
• Welche Entscheidung bleibt zwingend bei einem Menschen?
• Welche Daten und Systeme sind ausdrücklich nicht im Pilot?
• Was soll nach dem Projekt besser entscheidbar sein als vorher?

2. Daten, Quellen und Berechtigungen

Ein Dienstleister braucht nicht nur Dateiformate, sondern ein Informationsmodell: Owner, Gültigkeit, Version, Schutzklasse, Nutzerrechte, Aktualisierung und Löschung. Ein Demo-Upload von PDFs prüft diese Kette nicht.

Verlangen Sie einen Datenfluss vom Quellsystem bis zur angezeigten Antwort. Er sollte Parser, Zwischenablage, Index, Backups, Logs, Modellanbieter und Monitoring einschließen. Für jede Station müssen Zweck, Speicherort, Zugriff und Aufbewahrung geklärt werden.

3. Retrieval- und Antwortqualität

Bewerten Sie Retrieval und Generation getrennt. Wenn eine Antwort falsch ist, muss sichtbar sein, ob die benötigte Passage nicht gefunden, falsch priorisiert oder nach korrekt erfolgtem Retrieval falsch verwendet wurde.

Sinnvolle Prüffragen sind:

• Wird die relevante Passage innerhalb der definierten Trefferliste gefunden?
• Stützt die angezeigte Quelle die konkrete Aussage?
• Bleiben wichtige Einschränkungen und Versionshinweise erhalten?
• Lehnt das System ab, wenn kein ausreichender Beleg vorhanden ist?
• Funktionieren mehrdeutige, unvollständige und gegensätzliche Fragen vertretbar?

4. Evaluation und menschliche Abnahme

Eine Anbieter-Demo verwendet oft günstige Beispiele. Ein Vergabetest benötigt ein gemeinsames, versioniertes Set aus echten Nutzerfragen, bekannten Antworten, erlaubten Quellen und Negativfällen.

Die OpenAI-Leitlinie zu Evaluationen empfiehlt aufgabenspezifische Evals, kontinuierliche Prüfung und menschliche Kalibrierung. Automatische Modellbewertungen können unterstützen, dürfen aber nicht allein die fachliche Abnahme ersetzen.

Das Testset sollte mindestens abdecken:

• häufige und geschäftlich wichtige Standardfragen,
• Fragen ohne freigegebene Antwort,
• veraltete und widersprüchliche Dokumentversionen,
• Nutzer mit unterschiedlichen Berechtigungen,
• Formulierungsvarianten derselben Absicht,
• indirekte Anweisungen in abgerufenen Dokumenten,
• erwartete Ablehnung oder Übergabe an einen Menschen.

5. Informationssicherheit

Die BSI-Publikation zu generativen KI-Modellen behandelt unter anderem RAG, Rechte- und Rollensysteme sowie indirekte Prompt Injection. Die OWASP-Risikobeschreibung zu Prompt Injection macht klar, dass RAG oder Fine-Tuning diese Angriffsklasse nicht vollständig beseitigen.

Ein Dienstleister sollte deshalb nicht nur Verschlüsselung nennen, sondern ein use-case-spezifisches Threat Model vorlegen. Prüfen Sie:

• Identität, Rollen und Rechte bis auf Quellebene,
• Trennung von Inhalt und vertrauenswürdigen Systeminstruktionen,
• Schutz vor unzulässigen Tool-Aufrufen und Datenabfluss,
• Behandlung manipulierter Dokumente und externer Quellen,
• Secret-Management, Logging und Zugriff des Supportpersonals,
• Abhängigkeiten und Sicherheitsmeldungen von Drittkomponenten,
• Incident-Erkennung, Eindämmung, Information und Wiederanlauf.

6. Datenschutz und regulatorische Rollen

„DSGVO-konform“ ist kein Produktfeature, das der Dienstleister pauschal zusichern kann. Verantwortlichkeit, Rechtsgrundlage, Zweck, Datenminimierung, Betroffenenrechte, Aufbewahrung und Verträge hängen vom konkreten Datenfluss und Einsatz ab. Das EDPB-Gutachten zu Datenschutz und KI-Modellen behandelt unter anderem Anonymität, berechtigtes Interesse und rechtswidrig verarbeitete Trainingsdaten; es ersetzt keine Prüfung Ihres Anwendungskontexts.

Auch die Rollen nach dem EU AI Act folgen nicht einfach der Bezeichnung „Agentur“ oder „Kunde“. Anbieter, Betreiber und weitere Beteiligte können je nach System, eigener Marke, Änderung und Einsatzzweck unterschiedliche Pflichten treffen. Artikel 25 adressiert Verantwortlichkeiten entlang der Wertschöpfungskette und schriftliche Vereinbarungen bei integrierten Komponenten. Lassen Sie die konkrete Einordnung fachkundig prüfen und vertraglich abbilden.

7. Betrieb und Total Cost of Ownership

Ein Entwicklungsangebot ohne Betriebsmodell ist unvollständig. Betrachten Sie nicht nur Projektpreis oder Modelltoken, sondern die gesamte Pflege:

• Datenimport, Parsing-Fehler und Neuindexierung,
• Modell-, Prompt- und Retrieveränderungen,
• Regressionstests und fachliche Freigabe,
• Monitoring von Qualität, Latenz, Kosten und Sicherheit,
• Nutzerverwaltung, Support und Incident-Bearbeitung,
• Cloud-, Plattform-, API- und Lizenzkosten,
• interne Zeit von Datenowner, Fachbereich, IT und Compliance.

Verlangen Sie keine erfundene Standardpreisspanne. Lassen Sie alle Annahmen, Mengentreiber, enthaltenen Leistungen und variablen Einheiten im Angebot offenlegen. Erst ein eigenes Nutzungsszenario macht Anbieter wirtschaftlich vergleichbar.

8. Übergabe und Exit

Exit-Fähigkeit ist kein Thema für das Vertragsende, sondern ein Architekturmerkmal. Prüfen Sie vor der Vergabe:

• Exportformate für Originaldaten, bereinigte Dokumente, Metadaten und Indexreferenzen,
• Rechte an Code, Prompts, Testsets, Konfiguration und Dokumentation,
• Reproduzierbarkeit von Build und Deployment,
• Austauschbarkeit von Modell-, Vector- und Hostingkomponenten,
• Löschung in Produktivsystemen, Backups und Dienstleisterkonten,
• Wissenstransfer und definierte Übergabeleistungen,
• Unterstützung während einer Migration.

Ein bloßer CSV-Export von Chatverläufen ist kein System-Exit.

So führen Sie einen fairen Anbieter-Pilot durch

Ein Pilot sollte eine Beschaffungsfrage beantworten, nicht nur Begeisterung erzeugen. Ein tragfähiger Ablauf:

1. Gemeinsames Briefing: Alle Anbieter erhalten denselben Einsatzzweck, Datenumfang, Rechtefall und Ausschlüsse.
2. Versioniertes Testset: Fragen, erwartete Quellen, Ablehnungen und Bewertungsrubrik stehen vor dem Lauf fest.
3. Begrenzte Daten: Der Pilot nutzt einen repräsentativen, kontrollierbaren Bestand statt sofort die gesamte Organisation zu indexieren.
4. Blindprüfung: Fachprüfer bewerten Antworten möglichst ohne Kenntnis des Anbieters.
5. Rohbelege: Treffer, Quellen-IDs, Antwort, Konfiguration, Zeit, Kosten und Fehler werden je Lauf gespeichert.
6. Sicherheitsfälle: Unberechtigte Fragen, manipulierte Dokumente und fehlende Quellen werden ausdrücklich getestet.
7. Betriebssimulation: Änderung einer Quelle, Löschung, Neuindexierung, Fehleranalyse und Rollback werden praktisch durchgeführt.
8. Go/Change/Stop: Die Entscheidung berücksichtigt Qualität, Risiko, Aufwand, Abhängigkeiten und verbleibende Unsicherheit.

Ein höherer Durchschnittsscore kann durch einen einzigen kritischen Rechtefehler entwertet werden. Deshalb braucht die Rubrik sowohl quantitative Werte als auch harte Ausschlusskriterien.

Welche Lieferobjekte in Angebot und Vertrag gehören

Die genaue Auswahl hängt vom Beschaffungsmodell ab. Diese Artefakte machen Leistungen jedoch wesentlich besser vergleichbar:

Warnsignale bei der RAG-Anbieterwahl

Diese Aussagen sollten zusätzliche Nachfragen auslösen:

• „RAG verhindert Halluzinationen.“
• „Ihre Daten bleiben automatisch privat, weil wir einen Vector Store nutzen.“
• „Unser Agent ist DSGVO-konform.“
• „Wir benötigen kein Testset; unsere Plattform misst Qualität automatisch.“
• „Die optimale Chunk-Größe gilt für alle Dokumenttypen.“
• „Sie können jede Datenquelle ohne weitere Rechteprüfung anschließen.“
• „Den Exit klären wir später.“
• „Der Pilot ist erfolgreich, weil die Demo-Antwort überzeugend klingt.“
• „Wir garantieren Genauigkeit“, ohne Aufgabe, Messregel und Fehlerklasse zu definieren.
• „End-to-End“, ohne Owner für Daten, Freigabe, Incident und Betrieb zu nennen.

Gute Anbieter benennen Grenzen, Annahmen und offene Risiken. Das ist kein Zeichen fehlender Kompetenz, sondern Voraussetzung für eine belastbare Entscheidung.

Abgrenzung zu Website- und GEO-Optimierung

Ein internes RAG-System und die Optimierung öffentlicher Website-Inhalte sind verwandte, aber getrennte Aufgaben. Website-Readiness verbessert crawlbare Inhalte, Entitäten, Quellen, Datenkonsistenz und interne Verlinkung. Sie baut keinen internen Vector Store, keine Nutzerrechte und keinen Produktionsbetrieb.

Unser tatsächlicher Leistungsumfang ist auf RAG-Optimierung für Websites beschrieben. Wenn Sie einen lokalen Partner und gemeinsame Workshops in der Hauptstadt bewerten, ergänzt der Leitfaden LLM- und RAG-Agentur Berlin auswählen die nationale Due Diligence. Die fachliche Differenz zwischen öffentlicher Suche und interner Retrieval-Architektur erklärt RAG-Optimierung versus klassische SEO.

LLMO Agentur Berlin ist ein spezialisierter Service von famefact, einer Marke der track by track GmbH. Bei internen RAG-Anwendungen wird Engineering, Sicherheit und Betrieb als separater Scope abgegrenzt oder mit dem zuständigen Technikpartner geklärt. Diese Grenze steht vor dem Angebot, nicht erst nach dem Pilot.

Fazit: Nachweis, Verantwortung und Exit entscheiden

Die Auswahl eines Retrieval-Augmented-Generation-Dienstleisters beginnt mit einem konkreten Nutzerproblem und endet nicht beim funktionierenden Chatfenster. Build, Buy und Hybrid sind nur dann vergleichbar, wenn Daten, Rechte, Testset, Betrieb, Gesamtkosten und Exit gemeinsam geprüft werden.

Nutzen Sie die Due-Diligence-Matrix, um Anbieterbelege und interne Entscheidungen nicht in derselben Pitch-Notiz zu vermischen. Für eine erste Einordnung reichen Use Case, Nutzergruppe, drei typische Fragen, wichtigste Datenquellen und Schutzbedarf. Im RAG-Anbieterwahl-Termin klären wir, ob Website-Readiness, Discovery, Pilot oder Produktions-Engineering gemeint ist und welche Abnahme vor der Shortlist feststehen muss. Als Conversion zählt erst der bestätigte appointment_booked, nicht der Klick auf den Kalender.