Alltag, Failures, Evaluation

Bis hier wirkt RAG ziemlich aufgeräumt. Im Alltag ist es das nicht. Hier sind die Stolpersteine, die du fast garantiert triffst - und wie man rauskommt.

Tabellen, Headings, Listen, Code

Reine Prosa ist die einfache Disziplin. Echte Wissensbasen bestehen aus:

• Tabellen. Bei naivem Chunking landen Zeilen mitten zerschnitten in zwei Chunks - Spaltenüberschrift und Wert verlieren ihren Bezug.
• Headings. Steht „Anpassungen für die Antarktis" als H2 oben und drei Absätze später folgt der eigentliche Inhalt, geht der Heading-Bezug ohne strukturbewusstes Chunking verloren.
• Listen. Ein numerierter Schritt 7 ohne die Schritte 1-6 ist nicht hilfreich.
• Code. Char-basierter Schnitt zerlegt Code-Blöcke an beliebigen Stellen.
• Bildunterschriften. „Abb. 3: Verteilung in Mitteleuropa" steht oft im Dokument, aber das Bild selbst ist es nicht - der Caption-Text alleine sagt nichts.

Die Lösung heißt strukturbewusstes Chunking. Werkzeuge wie doclingExtern - Öffnet in neuem Tab parsen die Dokument-Struktur und chunken entlang davon: Tabellen bleiben zusammen, Headings werden in den Metadaten der Chunks verankert, Listen bleiben Listen.

In Lab 5 siehst du den direkten Vergleich „naive Fixed-Chunks" vs. „docling".

Wie misst man, ob das System gut ist?

Du brauchst ein Ground-Truth-Set: eine Liste von Fragen, zu denen du vorher festgelegt hast, welche Dokumente die richtige Antwort enthalten. Damit kannst du Retrieval-Konfigurationen objektiv vergleichen.

Zwei einfache Metriken reichen für den Anfang:

• Precision @ k - Anteil der Fragen, bei denen unter den Top-K Treffern mindestens ein erwartetes Dokument auftaucht. Praxisnah, weil das LLM danach ohnehin nur die Top-K sieht.
• Recall @ k - Anteil der erwarteten Dokumente, die unter den Top-K landen. Wichtig, wenn es pro Frage mehrere richtige Quellen gibt.

Die spannenden Fragen erkennt man oft daran, dass sie paraphrasiert sind, mehrere Dokumente brauchen, oder Tabellen-Werte fordern. Genau dafür baut man die Eval-Set-Kategorien.

Faustwerte aus diesem Tutorial-Setup:

(Genaue Zahlen hängen von deinem konkreten Korpus und Eval-Set ab.)

Kosten und Privacy - die unbequemen Achsen

RAG zahlt man in zwei Währungen:

• Geld - bei Cloud-Providern hauptsächlich Embedding- und LLM-Token-Kosten. Bei einem 50k-Token-Korpus mit 200 Chunks sind das pro Embedding-Lauf ein paar Cent. Pro Query kommt der LLM-Call dazu - wenige Cent bis Euro, je nach Modell und Antwortlänge.
• Privacy - wenn dein Korpus sensible Inhalte hat, ist jede Zeile, die zu einem Cloud-Embedder geschickt wird, ein Datenleck. Lokale Embeddings (Ollama) und ein lokales LLM heißen: 0 € Tokenkosten, aber Disk-Footprint und Kaltstart-Latenz.

Lab 5, Tab „Cost & Privacy", lässt dich Größenordnungen für deinen Korpus durchspielen.

Lab: Failures & Evaluation

Lab 5 hat drei Tabs:

1. Failure-Showcase - vier konkrete Beispiele, wo naïve Chunks scheitern und docling rettet.
2. Eval-Run - drei Konfigurationen (naïv, docling, docling+Rerank) automatisch durchs Eval-Set, mit Precision@1/3/5 als Balken.
3. Cost & Privacy - Slider für Korpus-Größe, gegenübergestellt: Cloud-Stack vs. dieser lokale Stack.