Checklist

Checklisty jakości (review)

Dobrze zrobiona checklista jest krótka, egzekwowalna i ma jedno zadanie: zatrzymać słaby materiał zanim trafi do użytkownika lub na produkcję. Poniżej jest zestaw, który nadaje się zarówno do rozdziałów Compendium, jak i do promptów, RAG oraz integracji narzędzi.

Rozszerzenie praktyczne

Operacyjny skrót

Ten rozdział należy do rodziny Jakość i ewaluacja i ma formę Checklist. 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
  • Blokuj, gdy brak źródeł / brak kontraktu / niejasna odpowiedzialność.
  • Ostrzegaj, gdy forma jest niespójna, a wynik „płynie”.
  • Mierz: checklista bez metryk zamienia się w „opinię”.

1. Zasady checklist (żeby działały)

Jednoznaczność
Każdy punkt ma wynik: tak / nie / nie dotyczy. Bez „wydaje mi się”.
Egzekwowalność
Zdefiniuj, które punkty blokują publikację, a które są tylko ostrzeżeniem.
Powiązanie z audytem
Jeśli nie potrafimy pokazać dowodu w logu/trace — punkt jest „na oko”.
Praktyka: checklista to bramka jakości, a nie recenzja literacka. Ma zatrzymać ryzyko, nie ocenić styl.

2. Szybki review (narzędzie)

Poniższy panel jest po to, żeby dało się zrobić przegląd „na jednym ekranie”. Jest świadomie konserwatywny — lepiej zatrzymać materiał o jeden raz za dużo niż przepuścić błąd.

Bramka: publikacja / wdrożenie
Wersja minimalna. 12 punktów.
0/12 0%
Wskazówka: jeśli wynik jest < 80%, traktuj to jako blokadę dla publikacji/produkcji.

3. Checklist promptu i polityki

  • Precedence: czy jasno opisano hierarchię instrukcji i co jest „niezmienne”?
  • Delimitacja: czy dane wejściowe są oddzielone od instrukcji (np. cytaty, bloki)?
  • Format: czy wynik jest walidowalny (JSON, tabela, szablon)?
  • Odmowa/eskalacja: czy system wie, kiedy przestać zgadywać?

4. Checklist źródeł i cytowań (RAG)

  • Jakość źródła: czy dokument ma ownera, wersję i datę aktualizacji?
  • Wiązanie twierdzeń: czy odpowiedź potrafi wskazać, z czego wynika?
  • Konflikty: czy opisano, co robić, gdy źródła się rozchodzą?
  • Sanityzacja: czy treści z RAG są traktowane jako dane (nie jako instrukcje)?

5. Checklist narzędzi (Tool Gateway)

  • Allowlist + RBAC: model nie „wymyśla” narzędzi i nie omija uprawnień.
  • Kontrakt: schemat wejścia i wyjścia jest walidowany.
  • Idempotency + limity: brak lawiny akcji na retrach, brak niekontrolowanych kosztów.
  • Audit: każde wywołanie ma trace_id, parametry po redakcji i wynik.

6. Checklist regresji (po zmianie)

  • Porównanie: wynik w kontrolowanych scenariuszach nie pogarsza się w metrykach.
  • Drift: monitorowanie „po cichu” w tle (sampling + analiza błędów).
  • Rollback: jest plan cofnięcia oraz kryteria uruchomienia.

7. Powiązane

Jak tego używać

W praktyce najlepiej działa rytuał: autor przechodzi checklistę, potem robi to recenzent. Rozbieżności oznaczają punkt do doprecyzowania, a nie „remis”.

Następny krok

Jeśli checklista ma działać, potrzebuje governance.

Przejdź do Governance polityk