RAG-System für KMU: So bauen Sie Ihre eigene KI-Wissensdatenbank

Wissen ist in den meisten KMU nicht das Problem. Das Problem ist, wo es steckt: in PDFs, die niemand mehr findet, in SharePoint-Ordnern, die seit Jahren nicht aufgeräumt wurden, und in den Köpfen von Mitarbeitenden, die bald in Rente gehen. Ein RAG-System ändert das grundlegend – ohne IT-Abteilung, ohne Entwicklerteam und ohne monatelange Projekte.

RAG steht für Retrieval Augmented Generation. Ein solches System gibt Ihrer Wissensdatenbank eine Suchfunktion, die tatsächlich Antworten liefert. Keine Trefferlisten, keine zehn Dokumente zum Durchklicken. Stattdessen eine präzise Antwort mit Quellenangabe.

Was RAG im KMU wirklich löst (und was nicht)

RAG funktioniert im Kern einfach: Statt dem KI-Modell alles im Voraus beizubringen, holen Sie bei jeder Anfrage die relevanten Dokumente heraus und geben sie dem Modell als Kontext mit. Das Modell antwortet dann auf Basis dieser Stellen, nicht auf Basis von allgemeinem Internet-Wissen.

Praxisbeispiel: Ein Spenglereibetrieb mit 18 Mitarbeitenden hatte ein klassisches Problem. Neue Mitarbeitende fragten ständig nach Wartungsanleitungen, Aufmaßformularen und Lieferantenkonditionen. Die Antworten lagen irgendwo, aber „irgendwo“ ist keine hilfreiche Adresse. Nach dem Aufbau eines RAG-Systems beantwortet ein internes Chat-Tool diese Fragen in Sekunden – mit Quellenangabe. Das Team fragt, die Antwort kommt, Arbeit erledigt.

Was RAG nicht löst: Unstrukturiertes Chaos. Wenn Ihre Dokumente inhaltlich veraltet, widersprüchlich oder nur als unlesbare Scan-PDFs vorhanden sind, hilft kein System der Welt. Gute Dokumentaufbereitung kommt vor gutem Retrieval – das ist die wichtigste Erkenntnis.

Die Architektur: 2 Workflows, eine Datenbank

Das Zielbild ist überschaubar. Sie brauchen keine komplexe IT-Infrastruktur. Zwei Workflows in n8n und eine Datenbank in Supabase reichen für den Start.

Workflow 1 – Ingestion: Dokumente einlesen, aufbereiten, in Vektoren umwandeln und in Supabase speichern. Dieser Workflow läuft entweder einmalig oder bei jeder Änderung im Quellsystem (Ordner, SharePoint, DMS).

Workflow 2 – Q&A: Der Nutzer stellt eine Frage, der Workflow sucht die passenden Textstellen in Supabase, gibt sie dem Sprachmodell als Kontext mit, und die Antwort kommt zurück – inklusive Quellen.

Ein Holzbau-Unternehmer mit einem Team von 22 Personen hat genau diese Struktur umgesetzt. Er hat den Ingestion-Workflow an sein Google-Drive-Verzeichnis mit Werkplänen und Lieferantenlisten angebunden. Das System läuft seit Monaten ohne nennenswerte Wartung.

Datenquellen anbinden: Wo Ihr Wissen heute steckt

Für den Start reicht ein Ordner. Ein lokaler Ordner oder ein Google Drive mit den wichtigsten 20 bis 50 Dokumenten ist ein legitimer Ausgangspunkt.

Für die Skalierung kommen SharePoint, ein DMS oder strukturierte Ordnerhierarchien dazu. n8n hat native Konnektoren für all diese Systeme. Der wichtige Punkt: Sie brauchen einen Weg, Änderungen zu erkennen. Entweder per Zeitplan („prüfe täglich auf neue Dateien“) oder event-getrieben („sobald eine Datei geändert wird, aktualisiere den Index“). Für den KMU-Einstieg reicht der Zeitplan-Ansatz völlig aus.

Dokumentaufbereitung: Der unterschätzte Hebel

Hier verlieren die meisten das Spiel. Nicht beim Modell, nicht beim Retrieval – bei der Dokumentaufbereitung.

Extraktion

PDFs mit Textebene sind einfach. Gescannte PDFs brauchen OCR. DOCX-Dateien sind unkritisch. E-Mails haben oft viel Rauschen (Signaturen, Weiterleitungsketten), das herausgefiltert werden sollte. Tabellen in PDFs sind tückisch – sie werden oft als unstrukturiertes Zeichenketten-Chaos extrahiert.

Cleaning

Automatische Kopfzeilen-Erkennung ist in n8n nicht nativ vorhanden, lässt sich aber mit Regex lösen. Wichtiger sind Duplikate: Wenn dasselbe Dokument in zwei Versionen existiert, muss das System wissen, welche gilt. Stabile Dokument-IDs helfen dabei.

Metadaten: Pflichtfelder von Anfang an

Empfohlener Minimal-Standard: mandant, abteilung, docType, gueltigVon, gueltigBis, quelleUrl. Diese Felder erlauben es, Suchanfragen gezielt zu filtern – beispielsweise: „Zeig mir nur Dokumente der Abteilung Montage, die noch gültig sind.“ Das ist der Unterschied zwischen einem Spielzeug und einem Produktivsystem.

Chunking: Texte sinnvoll aufteilen

Ein Dokument wird nicht als Ganzes gespeichert. Es wird in Abschnitte – sogenannte Chunks – aufgeteilt, die einzeln indexiert werden.

Empfohlene Startwerte

Für den Einstieg: Chunk-Größe 512 bis 800 Token, Overlap 10 bis 20 Prozent. Benachbarte Chunks überlappen sich leicht, damit Sinnzusammenhänge nicht an Chunk-Grenzen abreißen.

• Zu kleine Chunks (unter 100 Token) erzeugen Retrieval-Rauschen – viele kurze Fragmente ohne ausreichend Kontext.
• Zu große Chunks (über 1500 Token) verwässern die Relevanz, weil das Embedding ein Mischmasch aus mehreren Themen repräsentiert.

Struktur-bewusst chunken

Die beste Chunk-Grenze ist eine Überschrift oder ein Abschnittswechsel. SOPs und Checklisten haben meist klare Schritte, die gute natürliche Grenzen ergeben. Tabellen sollten als eigenständiger Chunk behandelt werden, mit Beschreibungszeile davor.

Embeddings: Kosten, Qualität und DSGVO

Ein Embedding ist eine Zahlenrepräsentation eines Textstücks. So sucht das System nicht nach Keywords, sondern nach Bedeutung.

Welches Modell?

OpenAI bietet zwei relevante Modelle: text-embedding-3-small (Standard: 1536 Dimensionen) und text-embedding-3-large (Standard: 3072 Dimensionen). Der dimensions-Parameter erlaubt es, die Vektorgröße zu reduzieren – das spart Speicher und beschleunigt Abfragen, kostet aber etwas Qualität.

Für den KMU-Einstieg ist text-embedding-3-small mit 1536 Dimensionen ein guter Kompromiss. Wenn die Retrieval-Qualität nicht ausreicht, kann auf text-embedding-3-large gewechselt werden.

Zur DSGVO: OpenAI stellt ein Data Processing Addendum (DPA) zur Verfügung, das als Teil der Auftragsverarbeitungs-Dokumentation benötigt wird. Allein reicht es nicht, ist aber ein wichtiges Artefakt.

Supabase als Vektordatenbank

Supabase mit pgvector ist die pragmatischste Wahl für KMU ohne eigenes Datenbankteam: Managed Service, gute n8n-Integration und solide Dokumentation.

Das Tabellenmodell

Die Chunk-Tabelle braucht mindestens: id, content (Textinhalt), embedding (Vektor), metadata (JSONB für Pflichtfelder), document_id (Fremdschlüssel zum Quelldokument), created_at.

Index-Wahl: HNSW

pgvector bietet zwei Index-Typen. HNSW liefert bessere Query-Performance als IVFFlat – kürzere Antwortzeiten und ein besseres Recall/Speed-Verhältnis. Der Nachteil: mehr Speicher und längere Build-Zeiten beim Index-Aufbau. Für KMU-Datenmengen (unter 100.000 Chunks) ist das kein Problem.

Die Retrieval-Pipeline: Von der Frage zur Antwort

Pre-Filter und Top-K

Zuerst filtern Sie nach Metadaten – zum Beispiel: nur Dokumente der Abteilung Montage, nur gültige Versionen. Dann folgt eine Vektorsuche auf diesem gefilterten Subset, die die Top-K ähnlichsten Chunks liefert (typisch: 5 bis 20).

Re-Ranking: Der größte Qualitätsbooster

Nach dem Retrieval kommt Re-Ranking. Cohere Rerank v4.0 ist multilingual, verarbeitet bis zu 32.000 Token Kontext und eignet sich gut für deutsche Dokumente und gemischte Formate. Prinzip: Erst schnell Top-K per Vektor holen, dann die relevantesten Treffer per Reranker neu sortieren, bevor das Sprachmodell antwortet. In der Praxis ist das oft der Schritt, der ein mittelmäßiges System zu einem guten macht.

Antwort-Template mit Quellen

Das Sprachmodell soll ausschließlich auf Basis der gelieferten Chunks antworten – nicht auf Basis von Allgemeinwissen. Das erreichen Sie über einen klaren System-Prompt:

Beantworte die Frage ausschließlich auf Basis der folgenden Dokumente. Zitiere immer die Quelle. Wenn keine relevante Information vorhanden ist, antworte: ‚Dazu habe ich keine gesicherte Information in der Wissensdatenbank.‘

Der zweite Satz ist nicht optional. Er verhindert Halluzinationen und macht das System vertrauenswürdig.

Rechte und Governance: RLS in Supabase

Row Level Security (RLS) in Supabase ist der praktikabelste Weg, Zugriffsrechte auf Chunk-Ebene durchzusetzen. Policies wirken wie implizite WHERE-Klauseln – ein Nutzer sieht nur, was seine Policy erlaubt. Trotz RLS sollten explizite Filter in den Abfragen gesetzt werden. Supabase empfiehlt das Wrapping von auth.uid() als (select auth.uid()) für deutlich bessere Query-Pläne.

Audit-Logging – wer hat wann was gefragt – ist für KMU zunächst optional, aber für Compliance-sensible Branchen früh einzuplanen.

Evaluation: Funktioniert das System?

Ein Golden Set aus 10 bis 30 Fragen mit bekannten richtigen Antworten ist der Maßstab. Fragen Sie das System, vergleichen Sie die Antworten und klassifizieren Sie Fehler in drei Kategorien:

• Retrieval-Fehler: Falsches Dokument geholt
• Ranking-Fehler: Richtiges Dokument geholt, aber nicht priorisiert
• Halluzination: Antwort ohne Basis im Dokument

Für KMU-Systeme reichen zwei Stunden und eine Tabelle. Aber ohne diesen Schritt wissen Sie nicht, ob Ihr System gut ist oder nur gut aussieht.

Typische Fehler und schnelle Fixes

• Zu kleine Chunks mit zu viel Overlap: Retrieval-Rauschen, schlechte Antworten. Fix: Chunks auf 400 bis 800 Token vergrößern.
• Metadaten nicht strukturiert: Nachträglich alles neu indexieren ist mühsam. Fix: Metadaten-Standard vor dem ersten Ingestion-Lauf festlegen.
• System-Prompt zu offen: Das Modell halluziniert. Fix: Explizit auf Quellenbasierung einschränken.
• RLS vergessen oder falsch konfiguriert: Datenschutzproblem. Fix: Policies vor Go-Live testen, explizite Filter in allen Queries.

DSGVO und EU AI Act: Was KMU wissen müssen

Für den Betrieb eines RAG-Systems mit Drittanbieter-Modellen (OpenAI, Cohere) brauchen Sie Auftragsverarbeitungsverträge (AVV/DPA). OpenAI und Cohere bieten entsprechende Verträge an.

Zum EU AI Act: In Kraft seit August 2024, vollständig anwendbar ab August 2026. Für KMU relevant: AI-Literacy-Pflichten gelten seit Februar 2025, GPAI-Pflichten ab August 2025. Ein internes Wissenssystem für Mitarbeitende wird typischerweise nicht als Hochrisiko-System eingestuft – aber Dokumentation und Transparenz gegenüber den Nutzern des Systems sind trotzdem sinnvoll.

Häufig gestellte Fragen

Was ist ein RAG-System und wozu brauche ich es als KMU?

RAG (Retrieval Augmented Generation) ist eine Methode, bei der ein KI-Modell Antworten auf Basis Ihrer eigenen Dokumente gibt – nicht auf Basis von allgemeinem Internet-Wissen. Mitarbeitende können natürlichsprachlich nach Anleitungen, Prozessen und Lieferanteninformationen fragen und bekommen sofort eine Antwort mit Quellenangabe.

Brauche ich Programmierkenntnisse?

Nein. Mit n8n als Workflow-Tool und Supabase als Datenbank lässt sich ein funktionsfähiges RAG-System ohne Code aufbauen. n8n bietet fertige Workflow-Templates, die an eigene Quellen und Anforderungen angepasst werden können.

Wie lange dauert die Einrichtung?

Für einen funktionierenden Prototyp mit einem Dokumentenordner als Quelle reichen bei vorbereiteten Dokumenten ein bis zwei Tage. Ein produktionsreifes System mit Rechteverwaltung, Metadaten-Standard und Evaluation-Prozess ist in zwei bis vier Wochen realisierbar.

Was kostet der Betrieb?

Für ein typisches KMU-Setup mit OpenAI-Embeddings, Supabase Free/Pro und n8n Cloud liegen die laufenden Kosten oft im niedrigen zweistelligen Euro-Bereich pro Monat. Der Aufwand für Einrichtung und initiale Dokumentaufbereitung ist der größere Kostenfaktor.

Quellenverweise

• OpenAI Embedding-Modelle - Informationen zu text-embedding-3-small und text-embedding-3-large
• OpenAI Data Processing Addendum (DPA) - Auftragsverarbeitungsvertrag für DSGVO-Konformität
• pgvector GitHub - Vektordatenbank-Erweiterung für PostgreSQL
• Supabase RLS Dokumentation - Row Level Security in Supabase
• Cohere Rerank - Multilinguales Re-Ranking-Modell
• EU AI Act - Regulatorischer Rahmen der EU für künstliche Intelligenz
• n8n Company Knowledge Base Agent (RAG) - Workflow-Template für RAG in n8n