Procedura

Monitoring Retrieval i GraphRAG

Jak utrzymać system wiedzy w stanie przewidywalnym: sygnały, progi, reakcja i regresje. Dokument opisuje minimalny standard monitoringu dla RAG i GraphRAG — bez mistyki, z dyscypliną operacyjną.

Czas czytania: ~10 min Aktualizacja: 2026-01-10
Minimalny standard SLO
  • Retrieval success ≥ 98% (≥1 dopuszczony dowód).
  • Evidence coverage ≥ 95% dla faktów lub tryb no‑answer.
  • Path validity ≥ 97% (provenance dla krawędzi).
  • p95 latency ≤ 6 s end‑to‑end (warstwowo).
Sygnały operacyjne: od trace i evidence coverage do bramek i regresji.
Sygnały operacyjne: od trace i evidence coverage do bramek i regresji.
Zasada operacyjna: w systemach opartych o wiedzę nie „wierzymy w model”. Wierzymy w ślady i dowody. Jeśli system nie potrafi pokazać, na czym oparł odpowiedź — powinien wejść w tryb no‑answer lub eskalacji.

1. Zakres i definicje

Ten rozdział dotyczy obserwowalności dla systemów typu RAG oraz GraphRAG: od zasilania baz wiedzy (SSOT), przez retrieval i traversale grafu, aż po bramki polityk (ACL/DLP/cytowania) i finalną odpowiedź.

  • Trace — zapis decyzji: query, filtry, wyniki, odrzucone elementy i powód odrzucenia.
  • Evidence set — zestaw dowodów dopuszczonych do odpowiedzi (doc@ver, chunk_id, edge_provenance).
  • Coverage — procent twierdzeń w odpowiedzi, które mają dowód (cytowanie) zgodny z kontraktem.

2. Metryki i SLO

Metryki dzielimy na pięć warstw. Dobrą praktyką jest publikacja SLO na warstwę, a nie „jednego SLO na wszystko”.

Warstwa Metryka Sugerowane SLO Notatka operacyjna
Retrieval Retrieval success rate ≥ 98% „Sukces” = ≥1 dowód dopuszczony przez politykę.
Evidence Evidence coverage (fact claims) ≥ 95% Jeśli spada, włącz no‑answer dla faktów.
Graph Path validity rate ≥ 97% Ścieżka ważna = wszystkie krawędzie mają provenance.
Gates Policy denial rate monitoruj trend Skok = zmiana ACL/DLP lub błąd mapowania atrybutów.
Performance End‑to‑end latency (p95) ≤ 6 s Rozdziel na: retrieval, graf, LLM, narzędzia.
Uwaga: SLO są zależne od domeny. W Luage rekomendujemy zacząć od progów „obronnych”, a potem je doprecyzować na podstawie danych z produkcji i golden setów.

3. Dashboards: co musi być widoczne

  • Overview: SLO per warstwa + trend 7/30 dni + rozkład latency.
  • Evidence: coverage per typ twierdzenia, top kategorie braków (brak źródeł, konflikt, gating).
  • Graph: skuteczność entity linking, odsetek krawędzi bez provenance, najczęstsze typy relacji w ścieżkach.
  • SSOT: świeżość dokumentów, reindeksacje, wersje, „tombstones”.

4. Alerting: progi i eskalacja

Alerty powinny być kontraktowe: odnoszą się do naruszenia SLO, a nie do „dziwnego feelingu”. Przykładowe reguły:

  • P1: evidence coverage spada poniżej progu przez 15 min (fakty) → on‑call + blok publikacji.
  • P2: retrieval success spada poniżej 97% → sprawdź indeks, filtry i polityki.
  • P3: rośnie denial rate po zmianie ACL → weryfikuj mapowanie atrybutów.

5. Triage w 5 krokach

  1. Potwierdź naruszenie na dashboardzie (trend, nie pojedynczy punkt).
  2. Złap przykłady: 5–10 trace_id z ostatnich 30 minut.
  3. Klasyfikuj: retrieval / graph / gates / LLM.
  4. Odtwórz przypadek (replay) na tej samej wersji indeksu i polityk.
  5. Wybierz akcję i przygotuj minimalną zmianę (patrz następny rozdział).

6. Akcje naprawcze: minimalna zmiana

Najczęstsze scenariusze i bezpieczne działania:

  • Spadek recall → sprawdź chunking, embedding model, filtry; rozważ reindeksację canary.
  • Konflikt źródeł → zastosuj procedurę kanoniczności i dopisz notę w SSOT.
  • Brak provenance w grafie → wstrzymaj traversale bez dowodu; napraw ekstrakcję relacji.
  • Skok denial rate → porównaj ACL/ABAC między wersjami; w razie potrzeby użyj wyjątku czasowego.
{
  "trace_id": "trc_01H...",
  "hint": "GraphRAG",
  "retrieval": {"top_k": 12, "eligible": 3, "filtered_out": 9},
  "graph": {"paths": 2, "invalid_edges": 1, "missing_provenance": true},
  "gates": {"acl": "pass", "dlp": "pass", "citations": "fail"},
  "decision": "no_answer"
}

7. Regresje i wydanie

Każda poprawka, która dotyka SSOT, indeksu, ontologii lub bramek, musi przejść przez: golden set, próg akceptacji oraz wpis do Rejestru zmian.

8. Checklista zamknięcia incydentu

  • Zidentyfikowano klasę awarii i zapisano 5–10 trace_id.
  • Wprowadzono minimalną zmianę i uruchomiono golden set.
  • Wdrożono canary / blue‑green z rollback planem.
  • Dodano wpis do rejestru zmian + krótką notę operacyjną.
Skrót wykonawczy
  • Monitoruj warstwami, nie „jednym KPI”.
  • Trace to dowód — bez niego nie ma diagnostyki.
  • Alerty są kontraktowe (SLO), nie emocjonalne.