Dokumentqualität
Sind Parsing, Tabellen, Chunks, Metadaten und Versionen so gut, dass Retrieval überhaupt eine Chance hat?
Praxis · Retrieval bewerten
Evaluation und Observability zeigen, welcher Pipeline-Schritt Qualität verbessert oder Fehler verursacht: Dokument, Retrieval, Graph, Antwort, Tool oder Feedback.
Wie misst man RAG-, Retrieval-, Graph- und Agentenqualität?
Ohne Messung bleibt unklar, ob GraphRAG wirklich besser ist oder nur komplexer. Observability zeigt, wo Fehler entstehen: Dokument, Retrieval, Graph, Prompt, Tool oder Antwort.
Die wichtigsten Prinzipien dieses Themas auf einen Blick.
RAG-Qualität braucht mehr als Antwortbewertung: Dokumente, Retrieval, Kontext und Quellen müssen getrennt sichtbar sein.
Graphqualität misst Knoten, Kanten, Provenance, Aktualität und Pfadnützlichkeit.
Agentenqualität umfasst Tool-Erfolg, Übergaben, Abbrüche, Kosten und Korrekturen.
Produktive Systeme brauchen Traces, Kosten-/Latenzwerte, Fehlerklassen und Feedback-Schleifen.
Diese Fragen machen das Thema praktisch prüfbar. Hak sie ab – sie eignen sich als Einstieg für Workshops, Pilotvorhaben oder Architekturreviews.
Evaluation beantwortet: Wird das System wirklich besser? Observability beantwortet: Warum passiert etwas im System? Für GraphRAG reicht es nicht, nur die finale Antwort zu bewerten. Du musst sehen können, welche Dokumente verarbeitet wurden, welche Treffer geladen wurden, welche Graphpfade genutzt wurden, welche Tools liefen und wo Kosten, Latenz oder Fehler entstehen.
Gute Evaluation trennt die Pipeline-Schritte. Sonst wirkt jedes Problem wie ein LLM-Problem.
Sind Parsing, Tabellen, Chunks, Metadaten und Versionen so gut, dass Retrieval überhaupt eine Chance hat?
Findet das System die richtigen Quellen, sortiert sie brauchbar und baut ein gutes Kontextpaket?
Sind Entitäten, Kanten, Pfade, Provenance und Aktualität belastbar genug für Antworten?
Ist die Antwort korrekt, belegt, vollständig, verständlich und ehrlich über Unsicherheit?
Wählt der Agent die richtigen Tools, stoppt er rechtzeitig und bleibt er innerhalb seiner Grenzen?
Hilft das System im echten Workflow schneller, sicherer oder nachvollziehbarer als die bisherige Arbeitsweise?
Ein Trace ist die nachvollziehbare Spur eines Laufs. Er hilft, einen Fehler später wirklich zu rekonstruieren.
Observability ist praktisch, wenn du Fehler siehst und lokalisieren kannst.
Schwach
Nur die LLM-Antwort bewerten und am Prompt drehen.
Besser
Trace prüfen: falscher Chunk gefunden, richtige Quelle nicht unter Top 10. Problem liegt im Retrieval, nicht im Prompt.
Schwach
GraphRAG pauschal als schlechter als RAG bewerten.
Besser
Messen, ob Entitäten erkannt wurden, ob der Pfad existiert und ob die Graphabfrage ihn überhaupt geladen hat.
Schwach
Toolbeschreibung länger machen und hoffen.
Besser
Tool-Auswahl loggen, Fehlaufrufe klassifizieren und mit Testfragen prüfen, wann welches Tool gewählt werden soll.
Baue für jeden kritischen Use Case zuerst eine kleine Baseline: manuelle Recherche oder einfaches RAG. Danach misst du nur Änderungen, die gegen diese Baseline besser werden: bessere Quellen, weniger Rauschen, bessere Belege, geringere Latenz oder weniger manuelle Nacharbeit.
Evaluation wird oft zu spät eingeführt. Dann ist das System komplex, aber niemand weiß, ob es besser geworden ist.