--- title: "Retrieval-Audit" description: "Der Bereich Agents → Audit: wonach ein Agent gesucht und was er geöffnet hat, ob er fündig wurde und wo seine blinden Flecken liegen." --- # Retrieval-Audit Der Kontext-Builder entscheidet, was einem Agenten vorab geladen wird. Das Audit ist sein Gegenstück während der eigentlichen Arbeit: Es zeigt, wonach der Agent tatsächlich sucht (`search` / `recall`) und was er öffnet (`get_note`) — und ob er etwas gefunden hat. Das ist deshalb wichtig, weil der häufigste Ausfallmodus des Gedächtnisses nicht darin besteht, dass „der Fakt fehlt“, sondern in einem Retrieval-Fehler: Die gesuchte Notiz existiert, aber die Anfrage erreicht sie nie. Ohne Beobachtbarkeit wird das Pflegen des Gedächtnisses zum Ratespiel. Der Bereich befindet sich unter **Agents → Audit**. ## Was ins Protokoll wandert Jeder Aufruf eines lesenden Tools (`search`, `recall`, `get_note`) hängt eine Zeile an das Protokoll an: wonach gesucht wurde (query, scope, class) und was gefunden wurde (die Top-Treffer mit `noteId`, `title`, `score`, `class` sowie die Trefferzahl). Die Erfassung läuft im Hintergrund — sie beeinflusst weder die Latenz noch die Korrektheit der Antwort, die der Agent erhält. Schreibende Tools (`create_note`, `remember_*`, `edit_note`) werden **nicht ins Retrieval-Audit protokolliert** — ihre Provenienz lebt im [Revisionsprotokoll](/docs/concepts/versioning/). Beim Audit geht es ums Lesen. Jede Zeile merkt sich außerdem den **Namen des Agenten** — den sprechenden Namen des Tokens oder der App (zum Beispiel eine CLI oder Claude), erfasst, solange das Token gültig ist. So merkt sich die Zeile für immer, welcher Agent die Anfrage gestellt hat. ## Blinde Flecken Das Hauptsignal des Audits sind **wiederkehrende Suchanfragen, die leer ausgehen**. Eine einzelne leere Suche ist normal (der Agent hat eine Hypothese geprüft). Eine Anfrage aber, die **Mal für Mal** nichts findet, ist ein blinder Fleck: Der Agent braucht einen Fakt, der nicht im Gedächtnis steht — oder unter einem ungünstigen Titel abgelegt ist. Das ist ein direkter Hinweis darauf, was zu ergänzen oder wie umzuformulieren ist. Die Oberfläche verdichtet das zu zwei Panels: - **Blind spots** — wiederkehrende leere Anfragen (Schwelle: zwei oder mehr ohne Ergebnis), gelb/bernsteinfarben hervorgehoben. - **Frequent** — die häufigsten Anfragen. Dazu ein Verlaufs-Feed (Neuestes oben) mit Filter nach Tool (All / Search / Recall / Open): das Tool-Icon, die Anfrage selbst, der Name des Agenten, das Klassen-/Kategorie-Label, das Projekt (nur bei eingegrenztem Scope), die Trefferzahl und die Uhrzeit. Klappt man eine Zeile auf, erscheinen die gefundenen Treffer — sie sind anklickbar und führen direkt zu den Notizen. > [!note] Leere Ergebnisse > Das Audit erfasst genau den Fall des leeren Ergebnisses zuverlässig. Der Fall „etwas Relevantes existiert, hat es aber nicht in die Top-Treffer geschafft“ erfordert, die Anfrage gegen das Gedächtnis laufen zu lassen — das ist ein eigenes, subtileres Signal, das das Audit nicht sichtbar macht. ## Datenschutz und Reichweite Das Protokoll ist nur für den Eigentümer sichtbar: Du siehst das Retrieval deiner eigenen Agenten, verknüpft mit deinem Benutzernamen. Da der Betrachter der Eigentümer ist, wird der Name deines Agenten unredigiert angezeigt. Das Audit umfasst alle deine Spaces auf einmal — eine Zeile hat keinen einzelnen Heimat-Space. > [!info] Wann Retrieval nicht protokolliert wird > Das Audit wird in der Metadaten-Datenbank gespeichert. Ein Host ohne Metadaten-Datenbank (zum Beispiel der `none`-Modus ohne Datenbank) protokolliert kein Retrieval — der Bereich bleibt dann einfach leer, ohne Fehler. ## Weiter - [Kontext-Sets und Pins](/docs/agents/context-pins/) — was vorab geladen wird; das Audit zeigt, was auf Anfrage nachgezogen wird. - [Agenten-Gedächtnis](/docs/agents/memory/) — wonach `search` und `recall` genau suchen. - [Sicherheit und Sichtbarkeit](/docs/agents/security/) — warum Leseprotokolle nur für den Eigentümer sichtbar sind.