RAG-Systeme scheitern an drei Stellen — keine davon ist das Modell
Warum Chunking, Retrieval und ein Eval-Set über die Qualität Ihrer RAG-Pipeline entscheiden, und warum ein Modellwechsel selten hilft.
90% aller RAG-Projekte, die ich sehe, optimieren das falsche Ding. Sie tauschen GPT-4 gegen Claude, dann gegen Gemini, und wundern sich, warum die Antworten weiter Müll sind. Das Problem liegt fast nie am LLM.
1. Chunking
Naives 512-Token-Chunking zerschneidet Tabellen, Code-Blöcke und Listen mitten durch. Das Embedding-Modell sieht dann einen halben Datensatz und gibt einen mittelmäßigen Vector zurück.
Fix: Semantisches Chunking auf Dokument-Struktur. Markdown-Headings, HTML-DOM, oder LLM-basierter Splitter. Kosten +20%, Quality +50%.
2. Retrieval
Pure Vector-Search ist für Production zu unscharf. Sie brauchen Hybrid-Search (BM25 + Embedding) plus einen Re-Ranker (Cohere Rerank, oder eigenes Cross-Encoder-Modell).
3. Eval
Wenn Sie kein goldenes Eval-Set haben, fliegen Sie blind. 200 Fragen mit verifizierten Antworten reichen. Bei jedem Modell-Update durchlaufen. Quality-Regressionen sehen Sie sofort, statt sie nach 3 Wochen vom Kunden gemeldet zu bekommen.
Häufige Fragen
- Woran scheitern RAG-Systeme am häufigsten?
- An drei Stellen — und keine davon ist das Sprachmodell: Chunking (schlechte Textsegmentierung), Retrieval (die falschen Abschnitte landen oben) und fehlende Evaluation (niemand misst, ob die Antworten stimmen). Wer diese drei Stellen nicht sauber baut, bekommt falsche Antworten trotz starkem Modell.