Procedura • Wdrożenie i governance

Obserwowalność i audyt

Jak mierzyć i audytować system LLM: trace jako standard, metryki jakości i kosztu, redakcja logów oraz odtwarzalność decyzji.

Powiązane: Dane i prywatność Powiązane: Koszt i SLO

Obserwowalność: co musi być widoczne

W systemach z LLM „debugowanie z pamięci” nie działa. Potrzebujesz artefaktów: trace, policy_version, doc@ver, tool_contract_version oraz pełnego łańcucha decyzji (bramki, fallbacki, retry).

Dziennik zdarzeń (proponowany zakres)

  • Input: intencja, parametry, kanał, język, ryzyko (klasyfikacja).
  • Context: źródła, wersje, budżet tokenów, odrzucenia (ACL, deduplikacja).
  • Tools: wywołania, statusy, latency, retry, idempotency.
  • Gates: decyzje (allow/deny/review) i uzasadnienia.
  • Output: format, cytowania, policy_version, ewentualne ostrzeżenia.

Audyt: pytania, które musisz umieć odpowiedzieć

  • Dlaczego ta odpowiedź wygląda tak, a nie inaczej?
  • Z jakich źródeł skorzystano (doc@ver + span)?
  • Jakie polityki były aktywne (policy_version)?
  • Czy użyto narzędzi – jakich i z jakim skutkiem?
  • Czy był wyjątek/eskalacja – kto zatwierdził?
Klasyczny standard: log musi być użyteczny i bezpieczny. Dane wrażliwe redaguj. Wersje i identyfikatory zostaw – one są paliwem dla audytu.

Retencja i prywatność

  • retencja logów dostosowana do ryzyka i wymogów prawnych,
  • oddzielne przechowywanie surowych payloadów (jeśli w ogóle),
  • kontrola dostępu do logów (RBAC/ABAC),
  • rejestr zapytań audytowych (kto, po co, kiedy).
W skrócie
  • Trace to nie log tekstu — to model zdarzeń (spany) z wersjami i decyzjami.
  • Audyt wymaga odtwarzalności: prompt@ver, policy@ver, index@ver.
  • Prywatność: redakcja przed logami; wrażliwe treści tylko w trybach debug, czasowo.
  • SLO: jakość (coverage, citations) i koszt (tokeny, retrieval) muszą być mierzone.

Obserwowalność systemu LLM to połączenie telemetry (metadane), jakości (testy + metryki) oraz audytu (odtwarzalność decyzji). Bez tego wdrożenie jest „black boxem”.

1. Co mierzymy

  • Produkt: czy użytkownik dostaje właściwą odpowiedź w właściwym czasie?
  • Jakość: coverage/attribution/faithfulness, eskalacje, no‑answer.
  • Koszt: tokeny, latencja, retrieval top‑k, cache hit.
  • Bezpieczeństwo: DLP hits, próby injection, naruszenia scopes.

2. Trace jako standard

Trace to identyfikator transakcji (np. jedna odpowiedź w helpdesku) oraz zestaw spanów. Każdy span powinien zawierać wersje artefaktów: policy@ver, prompt@ver, index@ver, a także decyzje bramek.

Demonstrator: trace (spany)
Kliknij krok — zobacz przykładowy payload zdarzenia.
Wejście
Policy
Retrieval
Compose
Wyjście
Opis kroku
Payload (przykład)

3. Audyt i odtwarzalność

Audyt jest możliwy tylko wtedy, gdy da się odtworzyć warunki: wersję promptu, polityki, indeksu i modelu. W praktyce oznacza to:

  • artefakty mają identyfikatory i wersje,
  • zmiany są w rejestrze (changelog),
  • wyjątki są w rejestrze wyjątków (czasowe).

4. Prywatność w telemetry

Nie ma obserwowalności bez danych, ale nie ma zgodności bez redakcji. Standard:

  • logujemy metadane (czas, wersje, wyniki bramek),
  • surowe treści tylko w trybach debug i tylko czasowo,
  • PII/sekrety: zawsze redakcja przed logami.

5. Dashboardy i alerty

  • latencja p95/p99 dla całości i dla retrieval,
  • odsetek NO_ANSWER i eskalacji,
  • coverage/attribution (na golden set i w produkcji),
  • DLP hits i próby prompt injection.

6. Checklist

  • Trace ma spany i wersje: policy/prompt/index/model.
  • Jest replay trudnych przypadków (bez danych wrażliwych).
  • Telemetry jest zdefiniowana przed rolloutem.
  • Redakcja danych obejmuje również logi.
Powiązane
Na tej stronie
Spis
    Nawigacja
    ← Poprzedni Następny →
    Status merytoryczny
    Metryka (wersja, owner, terminy przeglądu) jest wypełniana automatycznie na podstawie manifestu.