RAG (Retrieval Augmented Generation) ist die zuverlässigste Methode, ein LLM mit Ihrem Unternehmenswissen zu verbinden. Statt Wissen ins Modell zu trainieren, holen wir es zur Laufzeit aus einer durchsuchbaren Quelle und reichen es als Kontext an.
01Die RAG-Pipeline in vier Schritten
Eine produktionsreife RAG-Pipeline folgt fast immer dem gleichen Muster:
- Ingest: Dokumente werden in semantische Chunks zerlegt.
- Embed: Jeder Chunk wird in einen Vektor umgewandelt.
- Retrieve: Zur Laufzeit holen wir die relevantesten Chunks zur Nutzerfrage.
- Generate: Das LLM beantwortet die Frage auf Basis der gefundenen Chunks.
02Chunking ist Königsdisziplin
Zu kleine Chunks verlieren Kontext, zu große verwässern die Relevanz. Bewährt haben sich semantische Chunker mit 300–800 Tokens und 10–20% Overlap. Bei strukturierten Dokumenten (PDFs, Tabellen) lohnt sich ein Parser, der Sektionen erhält.
03Vektor-DB auswählen
Für die meisten Projekte unter 10 Mio. Chunks ist pgvector in Postgres die richtige Wahl — keine zusätzliche Infrastruktur, transaktional, SQL-fähig. Erst darüber lohnen sich Qdrant oder Weaviate.
sqlcreate extension if not exists vector; create table docs ( id uuid primary key default gen_random_uuid(), content text not null, embedding vector(1536) ); create index on docs using hnsw (embedding vector_cosine_ops);
04Re-Ranking
Pure Vektor-Suche reicht selten. Ein Re-Ranker (z. B. Cohere Rerank oder BGE Reranker) hebt die Trefferqualität spürbar an, indem er die Top-50 Kandidaten neu sortiert, bevor sie ans LLM gehen.
Key Takeaways
- →RAG schlägt Fine-Tuning für Wissensaufgaben fast immer.
- →Investieren Sie in Chunking und Re-Ranking, nicht in das größte Modell.
- →pgvector reicht für 95% der Projekte aus.