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).
Rozszerzenie praktyczne

Operacyjny skrót

Ten rozdział należy do rodziny Jakość i ewaluacja i ma formę Procedura. Poniższe dopowiedzenie ma jeden cel: przełożyć treść na działania, które da się wdrożyć, zmierzyć i utrzymać.

Checklista

  • Zdefiniuj metryki jakości (dokładność, kompletność, styl, cytowania).
  • Zbuduj golden set (reprezentatywne przypadki) i test harness.
  • Rozdziel testy offline (regresje) i online (monitoring produkcji).
  • Wprowadź progi akceptacji i „quality gates” przed wdrożeniem.
  • Monitoruj dryft: dane, retrieval, modele, zachowanie użytkowników.
  • Raportuj i domykaj działania: poprawki, rollback, kompensacje.

Najczęstsze pułapki

  • Testowanie na „ładnych” przykładach – wynik nie skaluje się na produkcję.
  • Brak wersjonowania danych testowych – nie wiadomo, co zmieniło wynik.
  • Mierzenie jednego wskaźnika – optymalizacja psuje inne wymiary jakości.
  • Brak obserwowalności – problem widać dopiero w skargach klientów.

Artefakty w Luage

golden_set eval_harness quality_gate monitoring regression_report

Standard działa dopiero wtedy, gdy ma właściciela, wersję, ślad (trace) oraz test regresyjny.

Szablon do skopiowania

Definicja metryk (minimalny kontrakt)

quality:
  metrics:
    - id: factuality
      scale: 0..5
      requires_citations: true
    - id: style
      scale: 0..5
      policy: language.standard@0.9
  gates:
    - "factuality >= 4"
    - "style >= 4"

Najpierw metryki i golden set, potem „przyspieszanie” promptu. Inaczej optymalizujesz złudzenia.

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.