RAG as a Service: Was es ist und wann es sich lohnt

RAG as a Service bezeichnet einen gehosteten, über API oder Web-Oberfläche nutzbaren Dienst, der Dokumente automatisch indexiert und Fragen dazu mit belegten Antworten beantwortet, ohne dass Sie selbst eine Vektordatenbank, Chunking-Logik oder Embedding-Pipeline betreiben müssen. Statt Wochen in den Aufbau einer eigenen Retrieval-Infrastruktur zu investieren, laden Sie Dokumente hoch und stellen sofort Anfragen. Dieser Artikel vergleicht Eigenbau, klassische Managed-RAG-APIs und Wissensdatenbank-Marktplätze wie Kopik, damit Sie die richtige Wahl für Ihr Projekt treffen.

Was ist RAG as a Service genau?

Retrieval Augmented Generation (RAG) kombiniert eine Suche über eigene Dokumente mit einem Sprachmodell, das aus den gefundenen Passagen eine Antwort formuliert. Das Modell erfindet nichts frei, sondern stützt sich auf tatsächlich vorhandenen Text, inklusive Quellenangabe. „As a Service" bedeutet, dass die gesamte Infrastruktur dahinter (Dokumentenverarbeitung, Indexierung, hybride Suche aus Volltext und semantischer Erweiterung, Abfrage-Endpunkte) von einem Anbieter betrieben wird. Sie müssen keine Server, keine Vektordatenbank und keine Update-Logik für Embeddings selbst verwalten.

Der Begriff wird in der Praxis für drei recht unterschiedliche Angebotsformen verwendet: reine Infrastruktur-APIs, bei denen Sie weiterhin viel selbst konfigurieren; vollständig gehostete RAG-Plattformen mit festen Workflows; und Marktplätze für fertige Wissensdatenbanken, bei denen Sie entweder eine eigene Basis anlegen oder bereits existierende, öffentlich geteilte Basen abfragen. Genau diese Unterscheidung ist entscheidend für die Kostenrechnung und den Zeitaufwand.

So funktioniert eine RAG-Pipeline technisch

Unabhängig davon, wer sie betreibt, durchläuft jede RAG-Pipeline dieselben Schritte. Das Verständnis dieser Kette hilft, die Angebote später realistisch zu vergleichen.

1. Dokumente einspielen: PDF, Word, Text oder Markdown werden hochgeladen und der reine Text extrahiert.
2. Chunking: Lange Dokumente werden in sinnvolle, überlappende Abschnitte zerlegt, damit Kontext erhalten bleibt.
3. Indexierung: Jeder Abschnitt wird für Volltextsuche und semantische Suche (Keyword-Erweiterung, Synonyme, Bedeutungsnähe) aufbereitet.
4. Hybride Suche: Bei einer Frage werden relevante Abschnitte über beide Suchverfahren kombiniert ermittelt, nicht nur über reine Stichwortsuche.
5. Antwortgenerierung: Ein Sprachmodell formuliert aus den gefundenen Passagen eine Antwort und zitiert die Quellstellen, oder liefert im „Passagen"-Modus nur die Rohtreffer.

Wer diese Kette selbst baut, muss jeden einzelnen Schritt technisch entscheiden und warten. RAG as a Service nimmt Ihnen genau diese Entscheidungen ab, in unterschiedlichem Ausmaß, je nach Angebot.

Drei Wege zu RAG: Eigenbau, Managed Service, Wissensdatenbank-Marktplatz

In der Praxis stehen drei Modelle zur Auswahl, die sich in Zeitaufwand, Kontrolle und laufenden Kosten deutlich unterscheiden.

Eigene RAG-Pipeline bauen

Der Eigenbau bietet maximale Kontrolle: eigenes Chunking-Verfahren, eigene Vektordatenbank, eigene Hosting-Region. Das lohnt sich, wenn Sie sehr spezifische Anforderungen haben, etwa eigene Modelle einsetzen wollen oder Datenresidenz bis ins letzte Detail selbst steuern müssen. Der Preis dafür sind Entwicklerzeit, laufender Betrieb und die Notwendigkeit, bei jedem neuen Dokumenttyp oder jeder Qualitätsschwäche selbst nachzubessern.

Managed-RAG-API

Eine Managed-RAG-API übernimmt Indexierung und Suche, lässt Ihnen aber oft Wahlfreiheit bei Modellen, Chunk-Größen oder Suchparametern. Das ist ein guter Mittelweg für Entwicklerteams, die RAG in ein größeres Produkt integrieren, aber nicht jede Infrastrukturkomponente selbst betreiben wollen. Integration erfolgt typischerweise über REST-Endpunkte oder SDKs.

Wissensdatenbank-Marktplatz

Ein Marktplatz wie Kopik geht einen Schritt weiter: Sie laden Dokumente hoch, die Basis wird automatisch extrahiert, in Chunks zerlegt und für hybride Suche indexiert. Sie ist sofort abfragbar über Web-Oberfläche, REST-API mit API-Keys oder einen MCP-Server, der direkt aus Cursor, ChatGPT oder anderen MCP-Clients heraus funktioniert. Basen können privat bleiben, sodass nur Sie und Ihre API-Keys darauf zugreifen, oder öffentlich im Katalog gelistet werden, wobei Ersteller pro Frage bezahlt werden und 70 % der Einnahmen behalten. Dieser Ansatz eignet sich besonders, wenn Sie schnell starten wollen, ohne eigenes ML-Team.

Kosten im Vergleich

Die Kostenstruktur unterscheidet sich fundamental zwischen den drei Modellen. Beim Eigenbau zahlen Sie vor allem für Entwicklerzeit, Hosting der Vektordatenbank und laufende Modellaufrufe: Kosten, die auch bei geringer Nutzung anfallen, weil Infrastruktur und Wartung weiterlaufen. Bei Managed-RAG-APIs verschiebt sich ein Teil der Fixkosten in nutzungsabhängige Gebühren, die technische Wartung entfällt weitgehend. Bei einem Marktplatz wie Kopik entfallen Infrastrukturkosten komplett: Sie zahlen entweder vorausbezahlte Credits pro gestellter Frage oder ein Chat-Abonnement ab 12 € pro Monat mit einer Nutzungsanzeige, die den Verbrauch transparent macht.

Für Teams, die eine öffentliche Wissensdatenbank erstellen und Fragen dazu kostenpflichtig anbieten möchten, kehrt sich die Kostenlogik sogar um: Statt Kosten entstehen potenzielle Einnahmen, da der Ersteller den Preis pro Frage selbst festlegt.

Wann lohnt sich welcher Ansatz?

Die Entscheidung hängt weniger von der Unternehmensgröße als von konkreten Anforderungen ab. Folgende Checkliste hilft bei der Einordnung.

• Sehr spezifische Compliance- oder Hosting-Vorgaben, die über Standardkonfigurationen hinausgehen → eigene Pipeline erwägen.
• Bestehendes Produkt, das RAG als eine Komponente unter vielen braucht und ein Entwicklerteam vorhanden ist → Managed-RAG-API.
• Schnelle Validierung einer Idee, interner Chatbot für Handbücher, FAQ oder Vertragsdokumente → Wissensdatenbank-Marktplatz.
• Wissen, das auch anderen nützen könnte (Normen, Vereinsrecht, Fachliteratur) und das sich monetarisieren lässt → öffentliche Basis auf einem Marktplatz.
• Anbindung an bestehende KI-Tools wie Cursor oder ChatGPT gewünscht, ohne eigene Integrationsarbeit → Marktplatz mit MCP-Unterstützung.

In den meisten Mittelstandsszenarien (interne Wissensdatenbank für Support, Onboarding-Dokumentation, technische Handbücher) überwiegt der Zeitvorteil eines Marktplatzes deutlich den Kontrollverlust gegenüber einem Eigenbau. Wer unter /dashboard/bases/new eine erste Basis anlegt, kann das in der Praxis in wenigen Minuten testen, bevor eine größere Investitionsentscheidung ansteht.

Sicherheit, Kontrolle und DSGVO

Bei jeder RAG-Lösung mit personenbezogenen oder vertraulichen Daten stellt sich die Frage der Verantwortlichkeit. Private Wissensdatenbanken, die nur über eigene API-Keys abrufbar sind, entsprechen in der Logik einem klassischen SaaS-Auftragsverarbeiter: Sie bleiben verantwortliche Stelle im Sinne der DSGVO, der Anbieter verarbeitet Daten in Ihrem Auftrag. Es lohnt sich, vor dem Hochladen sensibler Dokumente zu prüfen, ob eine Basis privat bleibt oder versehentlich öffentlich gelistet wird, und API-Keys wie andere Zugangsdaten zu behandeln, also nicht im Frontend-Code oder in öffentlichen Repositories zu speichern.

Mit Blick auf den EU AI Act sind reine Retrieval-Systeme in der Regel kein Hochrisiko-Anwendungsfall, doch Transparenzpflichten gegenüber Nutzern (etwa die Kennzeichnung von KI-generierten Antworten) bleiben relevant, sobald Endkunden mit einem RAG-System interagieren. Unternehmen, die sich an Vorgaben des BSI orientieren, sollten zudem prüfen, wie Zugriffskontrollen auf Basis- und API-Key-Ebene granular genug sind, um das Need-to-know-Prinzip umzusetzen.

In der Praxis starten

Der schnellste Weg, RAG as a Service selbst zu beurteilen, ist ein konkreter Test mit echten Dokumenten. Laden Sie ein Handbuch, eine Vertragsvorlage oder eine Sammlung interner Richtlinien hoch, stellen Sie Testfragen und vergleichen Sie die zitierten Passagen mit dem Original. So lässt sich die Antwortqualität objektiv einschätzen, bevor größere Datenmengen migriert werden. Entwicklerteams finden unter /developers die Dokumentation für REST-API und MCP-Integration, falls RAG direkt in bestehende Tools oder Agenten eingebunden werden soll.