Wie viel Plattform braucht ein belastbares Wissenssystem?
RAG-Plattform vs. Custom-Stack vs. Managed-RAG
Wer ein RAG-System einführen will, steht vor einer Build-vs-Buy-Entscheidung mit drei realistischen Optionen: RAG-Plattform (Open-Source-Komplettsystem): RAGFlow, AnythingLLM, Verba — eine Lösung mit
Kurz eingeordnet.
Die passende Architektur hängt weniger vom bevorzugten Werkzeug ab als von Quellenstruktur, Kontrollbedarf und Betriebsverantwortung.
Inhalt 6 Kapitel
RAG-Plattform vs. Custom-Stack vs. Managed-RAG
Worum es geht
Wer ein RAG-System einführen will, steht vor einer Build-vs-Buy-Entscheidung mit drei realistischen Optionen:
- RAG-Plattform (Open-Source-Komplettsystem): RAGFlow, AnythingLLM, Verba — eine Lösung mit UI, API, Ingestion, Vector-Store und Agents in einem Docker/K8s-Stack.
- Custom-RAG-Stack (selbst zusammengesetzt): Vector-DB (Qdrant, Chroma, pgvector) + Embedding-Provider (Jina, OpenAI, Cohere) + Reranker + LLM-API + eigener Service-Layer. Beispiel: der go4ai-Eigenstack.
- Managed-RAG (Cloud-Dienst): Azure AI Search, AWS Kendra, Google Vertex AI Search — vollständig betreibbar als Service, mit Enterprise-SLA.
Diese Karte ordnet, welche Option zu welcher Ausgangslage passt – und warum die tragfähige Entscheidung vom ersten Wunsch (“wir wollen Cloud” / “wir wollen selbst hosten”) abweichen kann.
Vergleich
| Dimension | RAG-Plattform (z.B. RAGFlow) | Custom-Stack (z.B. go4ai-Backend) | Managed-RAG (z.B. Azure AI Search) |
|---|---|---|---|
| Setup-Zeit | Tage (Docker-Compose) | Wochen bis Monate | Stunden bis Tage (Azure-Tenant nötig) |
| Setup-Kosten | gering bis mittel (Self-Hosting) | hoch (Engineering) | gering (Service-Fee, schneller Start) |
| Laufende Kosten | Hosting + ggf. K8s | Hosting + Embedding-API + LLM-API | nutzungsabhängig, kann teuer skalieren |
| Multi-Format-Ingestion (PDF, Office, Scans) | stark (Template-Parsing) | schwach bis null (meist Markdown/Text) | stark (Cloud-Parser) |
| Chunking-Kontrolle | Templates, teils opaque | volle Kontrolle (kann Section-aware, Late-Chunking, etc.) | Defaults, eingeschränkt anpassbar |
| Citations / Traceability | eingebaut | muss selbst implementiert werden | eingebaut |
| DSGVO / EU-Hosting | machbar (Self-Hosting in EU) | machbar | nur mit Azure-EU-Region + DPA-Prüfung |
| Vendor-Lock-in | gering (Open Source) | sehr gering | hoch (Cloud-API) |
| Multi-Tenant-Fähigkeit | nativ (RAGFlow ab v0.x) | muss selbst gebaut werden | nativ |
| Audit-Tauglichkeit | mittel (eigene Logs nötig) | hoch (volle Kontrolle) | hoch (Cloud-Compliance-Reports) |
| Spielraum für eigene Methodik | gering (Plattform gibt viel vor) | hoch (Architektur frei gestaltbar) | gering (Dienst gibt viel vor) |
| Typischer Pflege-Aufwand | mittel (Updates, Parser-Probleme) | hoch (Eigenentwicklung) | gering (Service) |
Praktische Heuristik
Drei Ausgangslagen als Entscheidungsraster:
- Chaotischer, unstrukturierter Dokumentenbestand (Fileshare, SharePoint, viele PDFs/Office, kein CMS): → RAG-Plattform (RAGFlow), Pflicht-Schritt 0 ist eine PDF-Parser-Evaluation mit repräsentativen Echtdaten. Begründung: Multi-Format-Ingestion ist der Hebel, Custom wäre teurer und langsamer.
- Strukturierter Content (Confluence, Notion, Markdown, gepflegte Wissensbasis): → Custom-Stack. Begründung: Strukturierter Content erlaubt feine Chunking-Strategien (Section-aware, Frontmatter-Filter), die Plattformen nicht ausspielen können. Datentrennung und Zugriffslogik lassen sich gezielter steuern.
- Konzern mit Audit- und SLA-Pflichten (BaFin, ISO 27001, ISMS): → Managed-RAG (Azure AI Search / Vertex AI Search). Begründung: Compliance-Reports aus dem Cloud-Konsum, kein Self-Hosting-Aufwand, klare Verantwortlichkeiten. Self-Hosting nur, wenn Datenklassifikation Cloud verbietet.
Anti-Muster:
- Einen Custom-Stack für einen reinen PDF-Bestand ohne kuratierbaren Content bauen – hoher Aufwand bei oft schwächerem Parsing.
- Eine RAG-Plattform über einen bereits gut strukturierten Confluence-Bestand legen – die vorhandene Struktur wird durch generische Templates verflacht.
- Managed-RAG ohne bestehende Cloud-Strategie oder Tenant wählen – der Setup-Overhead frisst den Vorteil.
Entscheidungssatz
- Wenn die Quelle Multi-Format und ungeordnet ist → RAG-Plattform.
- Wenn die Quelle strukturiert und kuratierbar ist → Custom-Stack mit größerem methodischem Spielraum.
- Wenn Compliance und SLA dominieren → Managed-RAG.
Im Wiki
go4ai nutzt selbst den Custom-Stack-Pfad (RAG-Systemarchitektur). Diese Vergleichsnote hält bewusst fest, warum der eigene Weg nicht automatisch die passende Wahl für jede Ausgangslage ist. Nachvollziehbare Build-vs-Buy-Kriterien sind wichtiger als Stack-Loyalität.
Verwandte Seiten
- RAG (Retrieval-Augmented Generation) — RAG-Grundlagen, Business Case, Kosten
- RAGFlow — Entity-Profil der konkreten Plattform
- LightRAG — Bibliotheks-Alternative mit Graph-Fokus
- RAG & DSGVO — DSGVO-Anforderungen quer über alle Optionen
- RAG-Systemarchitektur — Architektur-Bausteine (Chunking, Embeddings, Reranking)
- KI-Einführung in KMU — Einstiegs-Pfad in dem die RAG-Wahl steckt