RAG für KMU: Retrieval-Augmented-Generation richtig bauen

Einordnung

Abschnitt 01

Was RAG technisch ist

RAG ist eine Architektur in 4 Schritten: (1) Indizierung: Dokumente werden in Chunks (typisch 200-800 Tokens) zerlegt, jedes Chunk wird zu einem Embedding-Vektor codiert und in einer Vector-DB gespeichert. (2) Query-Verarbeitung: User-Frage wird ebenfalls als Embedding codiert. (3) Retrieval: die k ähnlichsten Chunks zur Frage werden aus der DB geholt (typisch k=10-50). (4) Generation: LLM erhält Frage + retrieved Chunks als Kontext und generiert die Antwort. Optional: Reranking zwischen Retrieval und Generation, um die wirklich relevantesten Chunks zu identifizieren.

Abschnitt 02

Vector-Store-Wahl pro Datenmenge

Empfehlungen je Datenmenge: 0-1 GB: Chroma (sehr einfach, läuft als Python-Library). Setup-Zeit 1 Tag. Mit FAISS-Index sehr performant. 1-50 GB: Qdrant (Rust-basiert, sehr robust, Open-Source). Setup-Zeit 2-3 Tage. Über 50 GB oder verteilte Setups: Weaviate oder Milvus. Setup-Aufwand höher (5-10 Tage), aber skaliert auf Mrd Vektoren. Für KMU-Setups ist Qdrant in 90% der Fälle die richtige Wahl: produktiv erprobt, gute Performance, einfach zu betreiben.

Abschnitt 03

Embedding-Modell-Wahl

Drei produktiv erprobte Optionen: nomic-embed-text (137M Parameter, 768d, MIT-Lizenz). Läuft lokal auf 0.9 GB VRAM. Performance auf MTEB DE: 0.62. Empfehlung für lokale Self-Hosting-Setups. BGE-large-en-v1.5 (335M, 1024d, MIT). Lokal auf 1.8 GB VRAM. Performance: 0.69 (besser auf Englisch). Cloud-Embedding (US-Anbieter, groß) (Cloud-only, 3072d, kostenpflichtig). Performance: 0.72. Bei DSGVO-/§203-Anforderungen alternativ Aleph Alpha luminous-base-embed (EU-Hosting). Wahl-Empfehlung: für lokale Setups nomic, für Cloud-tragbare Setups ein Cloud-Embedding mit DPF.

Abschnitt 04

Chunking-Strategie

Chunking ist der unterschätzte Erfolgs-Faktor. Empfehlung: für strukturierte Dokumente (Verträge, Anträge, BWA-Reports) ist Chunking nach logischer Sektion am besten — Header werden als Chunk-Boundary verwendet. Für unstrukturierte Texte (Wikipedia-artige Artikel) ist Fixed-Size-Chunking mit Overlap (z.B. 400 Tokens mit 50 Tokens Overlap) der Standard. Wichtig: jedes Chunk muss Metadata haben (Dokumenten-Titel, Sektion, Datum, Source-URL), die bei der Antwort als Quelle angegeben wird.

Abschnitt 05

Reranking als Stage-2

Standard-Retrieval mit top-k=10 gibt oft mittelmäßig relevante Chunks. Reranking als Stage-2 mit Cross-Encoder-Modell (BGE-Reranker, MIT-Lizenz) verbessert die Qualität deutlich. Workflow: top-50 retrieval mit Bi-Encoder → BGE-Reranker bewertet jedes der 50 Chunks gegen die Query → top-5 oder top-10 finalen Chunks werden an LLM weitergegeben. Reranking reduziert in unseren Tests Halluzinationen um 30-40%. Latenz-Overhead: rund 200-400 ms pro Query auf RTX 5080.

Abschnitt 06

Quellenangabe: zwingend

Jede RAG-Antwort sollte Quellen zitieren. Format: "Antwort... [Quelle: Dokument-Titel, Seite, Abschnitt]". Implementations-Aufwand: jedes Chunk wird mit eindeutiger Source-ID in der Vector-DB gespeichert. Bei Generation gibt das LLM nicht nur die Antwort, sondern auch die verwendeten Source-IDs zurück (via strukturiertes JSON-Output). Das Front-End rendert die Quellen klickbar mit Verlinkung zum Original-Dokument. Diese Funktion ist nicht "nice-to-have", sondern Pflicht — RAG ohne Quellen ist nicht vertrauenswürdig.

Abschnitt 07

Beispiel-Szenario: Anwaltskanzlei mit 8 GB Bestand

Beispiel-Szenario · kein realer Kunde · erfundener Vorgang zur Veranschaulichung. Alle Zahlen in diesem Abschnitt sind Rechenbeispiele, keine Kundendaten.

Angenommen ist eine Anwaltskanzlei (Beispiel) mit 8 GB internem Bestand (Schriftsätze, interne Kanzlei-Memos, Mandanten-spezifische Akten, alle anonymisiert für RAG-Indexierung). Setup: Qdrant lokal, nomic-embed-text für Embeddings, BGE-Reranker. Indexierungs-Zeit: rund 6 Stunden für initial-Index. Daily Delta-Update: 20-40 Minuten. Query-Latenz End-to-End (Retrieval + Reranking + Generation mit einem 14B-Modell): 2-4 Sekunden. Customer-Feedback: "wie ein Junior-Associate mit perfektem Gedächtnis". Hauptnutzen: schneller Zugriff auf interne Präzedenzfälle und Argumentations-Linien.

Abschnitt 08

Setup-Aufwand realistisch

Für ein 20 GB-Wissens-Setup: Architektur-Design 2 Tage. Chunking-Strategie pro Dokument-Typ 3 Tage. Vector-Store-Setup + Indexierung 4-6 Tage. UI/API-Integration 5 Tage. Test + Tuning 5 Tage. Gesamt: rund 22 Tage Beratungs-Leistung. Hardware-Kosten (eigene Server-Erweiterung für RAG): rund 1.500 €. Setup-Gesamt-Kosten: 18.000-26.000 €. Monatliches Hosting + Wartung: 240-380 €.

Abschnitt 09

Wann RAG nicht passt

Drei Konstellationen, in denen RAG nicht die richtige Wahl ist: (1) Statische FAQ-Daten mit klar definierten Antworten — hier ist einfache Keyword-Suche oft besser, weil deterministisch. (2) Numerische Datenbanken (Buchhaltung, BWA, Lager-Bestand) — RAG kann mit Zahlen nicht gut umgehen, hier ist SQL-Integration besser. (3) Multi-Hop-Reasoning, bei dem mehrere Dokumente miteinander verknüpft werden müssen ("Welche Mandanten hatten ähnliche Fälle wie X und welche Strategie haben wir damals gewählt?") — hier ist klassisches RAG zu schwach, Graph-RAG oder Multi-Agent-Setups sind besser.

Abschnitt 10

Hybrid-Search als Empfehlung

Best-Practice für Production: Hybrid-Search = Semantic-Search (Vector-DB) + BM25 (klassische Keyword-Suche) parallel, mit Score-Fusion am Ende. Bei Anwalts-Setups besonders wichtig: Aktenzeichen, Norm-Verweise, juristische Fachbegriffe werden von BM25 besser gefunden, semantische Konzepte vom Vector-Search. Hybrid kombiniert beide Stärken. Implementations-Overhead: rund 3 Tage zusätzlich zum Standard-RAG-Setup.