RAG ohne Cloud — was in der Praxis wirklich weh tut
Vektorsuche ist der einfachste Teil. Die Arbeit steckt im Chunking, in der Rechteverwaltung und darin, Qualität messbar zu machen.
Jede Anleitung zu Retrieval Augmented Generation endet nach dem Einfügen der Embeddings. Genau dort fängt die eigentliche Arbeit an.
Chunking ist kein gelöstes Problem
„512 Token mit 50 Token Überlappung" ist keine Strategie, sondern ein Standardwert. Ein Vertrag, ein Wiki-Artikel und ein Support-Ticket haben völlig verschiedene Struktur. Was funktioniert hat:
- Aufteilen an semantischen Grenzen (Überschriften, Absätze), nicht an fixer Länge
- Jedem Chunk seinen Kontextpfad mitgeben (
Dokument › Kapitel › Abschnitt) - Tabellen komplett halten — ein zerschnittener Tabellenkopf macht die Zeilen wertlos
Rechteverwaltung gehört in die Abfrage
Nachträglich filtern ist ein Datenleck mit Verzögerung. Der Mandantenfilter gehört in dieselbe SQL-Abfrage wie die Ähnlichkeitssuche:
SELECT id, content, 1 - (embedding <=> $1) AS score
FROM chunks
WHERE tenant_id = $2
AND document_id = ANY($3) -- vorab geprüfte Leserechte
ORDER BY embedding <=> $1
LIMIT 20;Der Index (ivfflat oder hnsw) arbeitet dann bereits auf der erlaubten Menge.
Qualität braucht einen Testdatensatz
Ohne feste Fragen-Antwort-Paare ist jede Verbesserung Bauchgefühl. 50 handgeprüfte Paare aus dem echten Bestand reichen für den Anfang und decken mehr auf als jedes Leaderboard.
Fazit
Die Bibliothek für Vektorsuche ist austauschbar. Chunking-Strategie, Rechtemodell und Testdatensatz sind es nicht — dort entscheidet sich, ob das System benutzbar ist.