RAG im Mittelstand: Wann sich eine eigene KI-Wissensdatenbank lohnt.

Generische KI-Modelle wissen alles — nur nicht das, was in Ihrem Unternehmen gilt. Nicht Ihren Produktkatalog, nicht Ihre Vertrags­konditionen, nicht die internen Prozesse, die Ihr Servicetechniker täglich braucht. Genau hier setzt RAG an: Retrieval-Augmented Generation ist kein Hype-Begriff — es ist ein konkretes Architektur­muster, das LLMs mit Ihren eigenen Daten verknüpft. V1 hat RAG-Systeme für Portfolio­unternehmen und Mittelstands-Mandate aufgebaut. Was dabei wirklich zählt, ist selten die Technologie — es ist der Zustand der Daten davor.

Was RAG ist — in 60 Sekunden erklärt

Das Grundprinzip

RAG funktioniert in drei Schritten. Erstens: Ihre Dokumente werden in kleine Abschnitte zerlegt und als mathematische Vektoren in einer Datenbank gespeichert. Zweitens: Wenn ein Nutzer eine Frage stellt, sucht das System semantisch — nicht mit Stichworten, sondern nach Bedeutung — die relevantesten Abschnitte heraus. Drittens: Diese Abschnitte werden dem KI-Modell als Kontext mitgegeben, das daraus eine Antwort in natürlicher Sprache formuliert. Das Modell erfindet nichts — es fasst zusammen, was Ihre Dokumente enthalten.

Was RAG nicht ist

RAG ist kein Fine-Tuning, kein Training, kein „der KI Ihr Unternehmen beibringen". Das Modell selbst wird nicht verändert. Es lernt nichts dauerhaft. Wer RAG mit Modell-Training verwechselt, plant am falschen Ende — und landet bei sechsstelligen Budgets für ein Problem, das mit einem Bruchteil lösbar wäre.

RAG ist keine KI-Schulung — es ist eine sehr schnelle, sehr intelligente Suchfunktion, die Ergebnisse in Sprache formuliert.

Wann RAG sich lohnt — und wann nicht

Gute RAG-Kandidaten

RAG funktioniert überall dort gut, wo es viel Text gibt, häufige und ähnliche Fragen gestellt werden, und die Inhalte einigermaßen stabil sind. Klassische Kandidaten im Mittelstand: technische Handbücher und Servicedokumentation, Produktkataloge mit Spezifikationen, interne FAQ-Datenbanken, Vertragssammlungen für den Einkauf, Compliance-Richtlinien, und Prozess-Wikis für Außendienst und Fertigung. Drei Fälle, die in Mandaten funktioniert haben: ein Support-Wissens­system, das L1-Anfragen ohne Eskalation beantwortet; ein Einkaufs-Compliance-Checker, der Vertrags­klauseln gegen interne Richtlinien prüft; und ein internes Handbuch für Servicetechniker, das vor Ort auf dem Tablet läuft.

Schlechte RAG-Kandidaten

Sehr kleine Dokumentenmengen unter 50 Seiten rechtfertigen den Aufwand nicht — dort reicht eine strukturierte Suche. Hochdynamische Daten, die sich stündlich ändern, wie Live-Lagerbestände oder Echtzeit-Preise, gehören in eine echte Datenbank mit API-Zugriff, nicht in ein RAG-System. Und stark strukturierte, numerische Daten — Buchhaltung, ERP-Auswertungen — werden von einem RAG-System schlechter verarbeitet als von einer klassischen Datenbankabfrage.

Die drei echten Hürden in der Praxis

Hürde 1 — Datenchaos

Die häufigste Überraschung in RAG-Projekten: Die Dokumente existieren, aber in fünf verschiedenen Formaten, drei verschiedenen Systemen, mit inkonsistenter Benennung und ohne klare Versions­kontrolle. Garbage in, garbage out gilt nirgends so hart wie bei RAG — weil das System die Qualität seiner Quellen nicht erkennt, sondern nur reproduziert. Bevor die erste Zeile Code geschrieben wird, braucht es eine ehrliche Bestands­aufnahme der Dokument­landschaft.

Hürde 2 — Chunking und Retrieval-Qualität

Wie Dokumente in Abschnitte zerlegt werden, entscheidet über die Antwort­qualität mehr als die Wahl des KI-Modells. Zu große Abschnitte verwässern den Kontext. Zu kleine verlieren den Zusammenhang. Abschnitte, die mitten in einer Tabelle oder einem Aufzählungs­punkt enden, produzieren inkohärente Antworten. Out-of-the-box-Lösungen mit Standard-Chunk-Größen funktionieren bei einfachen Texten — scheitern aber regelmäßig an technischen Dokumenten, tabellarischen Inhalten und mehrsprachigem Material.

Hürde 3 — Pflege und Aktualität

RAG ist kein einmaliges Projekt. Die Vektor-Datenbank muss mit den tatsächlichen Dokumenten synchron bleiben. Veraltete Preise, geänderte Prozesse, zurückgezogene Produktversionen — wenn das System solche Inhalte als Quelle nutzt, gibt es falsche Antworten mit hoher Sicherheit. Das ist aktiv schädlich, nicht neutral.

Ein RAG-System, das veraltete Preise oder geänderte Prozesse zurückgibt, schadet mehr als es nützt — weil es sicher klingt.

Was eine RAG-Implementierung wirklich kostet

Setup-Kosten liegen je nach Dokumenten­volumen und Integrations­komplexität zwischen 3.000 und 15.000 Euro — für Konzeption, Daten­aufbereitung, Chunking-Strategie, Retrieval-Tuning und Anbindung an bestehende Systeme. Die laufenden Kosten setzen sich zusammen aus der Vektor-Datenbank (Pinecone oder Weaviate: 50–300 Euro/Monat, oder self-hosted auf Hetzner: rund 30 Euro/Monat), der Embedding-API (OpenAI: 20–100 Euro/Monat je nach Volumen) und der LLM-API für die Antwort­generierung (Claude oder GPT: 50–300 Euro/Monat). Hinzu kommen 2–4 Stunden pro Monat für Dokument-Updates und Pflege.

Wann der ROI positiv ist

Die Rechnung ist einfach: Wenn das System 50 oder mehr Anfragen pro Woche beantwortet, die bisher qualifizierte Mitarbeiter­zeit gebunden haben, amortisiert sich die Investition in der Regel innerhalb von drei bis sechs Monaten. Entscheidend ist dabei nicht das reine Volumen, sondern die Qualität der Alternativ­kosten — was eine Stunde Servicetechniker, Einkäufer oder Support-Mitarbeiter tatsächlich kostet.

V1-Empfehlung: Pilot vor Plattform

Kein Mittelständler braucht im ersten Jahr eine RAG-Plattform. Was es braucht: einen Use-Case, einen Dokument-Corpus, vier Wochen Pilot. Messbar über drei Kennzahlen — Antwort­genauigkeit (Spot-Check mit 20 repräsentativen Fragen), Nutzer-Adoption innerhalb des Teams, und tatsächlich eingesparte Zeit pro Woche. Wenn alle drei Werte in die richtige Richtung zeigen, skaliert man. Wenn nicht, hat man vier Wochen und einen überschaubaren Betrag investiert — und weiß, warum es nicht funktioniert hat. Das ist wertvoller als jede Machbarkeits­studie.

Viele Anbieter verkaufen RAG als Plattform­entscheidung: Vektor-Datenbank wählen, Embedding-Modell evaluieren, Enterprise-Lizenz abschließen. Das ist der falsche Einstieg. Die Plattform­frage stellt sich, wenn der Use-Case bewiesen ist — nicht vorher.