Zum Hauptinhalt springen
Dominik Weyhw3yh.xyzKontakt
OpenClaw

w3yh://systems/rag-review

RAG Review

Retrieval-Qualität messbar machen, statt aus dem Bauch heraus zu vertrauen.

was ist das hier

Ein festes Testset aus realistischen Fragen, das gegen den Gedächtnisspeicher des Systems laufen kann. Ergebnis: eine reproduzierbare Karte davon, wo die Wissensschicht zu einem bestimmten Messzeitpunkt trägt — und wo sie schweigt oder rauscht.

Warum das überhaupt nötig ist

Jedes KI-Setup, das "mitdenkt", hängt irgendwann an einer Wissensschicht: vergangene Notizen, abgelegte Erkenntnisse, dokumentierte Entscheidungen. Man fragt die Maschine etwas, und sie soll sich an den richtigen Teil erinnern. Nur: ob sie das wirklich tut, bleibt ohne Messung Bauchgefühl.

Das eigentliche Problem ist dabei nicht "keine Antwort". Das eigentliche Problem ist die plausible falsche Antwort — eine, die gut klingt, aber an der falschen Stelle im Speicher gezogen hat.

Die gefährlichste Retrieval-Antwort ist nicht "weiß nicht". Sie ist "sieht nach Wissen aus, ist aber Rauschen".

Wie der Review arbeitet

  1. 1

    Typische Fragen definieren

    Fragen aus dem echten Alltag: "Was haben wir an Projekt X zuletzt entschieden?", "Welche Operationen laufen nachts?", "Wie hängt Y mit Z zusammen?"

  2. 2

    Wissensschicht abfragen

    Jede Frage läuft durch die normale Retrieval-Pipeline — so, wie sie auch ein Agent stellen würde. Kein Sonderweg, kein Tuning pro Frage.

  3. 3

    Antwort bewerten

    Jeder Treffer wird nach erwarteten Quellen geprüft. Passt das Ergebnis? Oder wurden generische Schnipsel gezogen, die zufällig ähnlich aussehen?

  4. 4

    Warnungen festhalten

    PASS/FAIL allein reicht nicht. Halbe Treffer und verdächtige Quellen werden markiert, um Regressionen früh zu sehen.

Mess-Snapshot vom 24. April 2026

messung vom 2026-04-24

Sechs von sechs Kernfragen sind grün. Konkrete technische Episoden werden zuverlässig wiedergefunden. Gleichzeitig ziehen zwei breitere, generische Fragen immer noch Tweet-Fragmente in den Kernkontext — also Inhalte, die eigentlich als Zusatzmaterial getrennt laufen sollten.

ohne Review

  • Retrieval-Qualität ist reines Bauchgefühl.
  • Rauschquellen fallen erst beim Streiten mit dem Agenten auf.
  • Eine Änderung am Index wirkt — oder auch nicht, keiner weiß es.

mit Review

  • Ein reproduzierbares Ergebnis pro Fragengruppe.
  • Rauschquellen sind als Warnungen benannt.
  • Eine Änderung am Index erzeugt ein sichtbares Delta.

Was die Messung ehrlich macht

Der damalige Review zeigte nicht nur, dass etwas funktionierte, sondern wo die Pipeline am 24. April noch riet. Zwei breite Ops- und Security-Fragen zogen Inhalte aus einem Nebenkanal in den Kernkontext. Das war kein Totalausfall — aber Rauschen, das entweder im Index oder im Prompt getrennt werden musste.

Gerade solche halbverrauschten Treffer sind wertvoller als eindeutiges Versagen. Sie zeigen, dass der Speicher nicht kategorisch defekt ist, sondern an einer klaren Kante falsch adressiert. Das ist eine Kante, die man verschieben kann.

was ich mitnehme

PASS/FAIL reicht nicht. Halb-erfolgreiche Treffer sind die interessantesten Fundstellen — sie zeigen genau, wo die Indexierung sauberer werden muss, ohne dass ein komplettes System umgebaut werden müsste.

Was noch kommt

  • Warnungen sollen als echte Regressionen gespeichert werden, nicht nur gezählt.
  • Tweet-Metadaten sollen als strukturierte Zusatzebene ausgewertet werden, nicht als Textbeilage im Core-Kontext.
  • Einzelne Themen, z.B. Portfolio-Ticker-Abdeckung, bekommen eigene Messreihen statt in der Allgemeinheit mitzulaufen.

Public Cut

Diese Seite zeigt die Fragenklassen, die Messweise und einen klar datierten Qualitäts-Snapshot. Sie zeigt keine konkreten Memory-Inhalte, keine Roh-Embeddings, keine vollständigen Antworttexte und keine privaten Ablagepfade. Der Review ist ein Produkt der Messung, nicht ein Dump des Speichers.

weitere module

Mehr aus dem OpenClaw-Setup

alle module →