Jakość i ewaluacja

Ewaluacja jakości

Definicja minimum: jeśli rozdział jest Obowiązkowy, musi mieć regresję. Minimum nie jest luksusem — jest warunkiem odpowiedzialności.

—
Teza operacyjna: jakość systemów opartych o LLM nie wynika z „jednego dobrego promptu”. Wynika z pętli: testy → obserwacja → poprawka → regresja.

1. Cel

Ten rozdział opisuje, jak w Luage podchodzimy do ewaluacji jakości: metryki, minimalny pakiet testów oraz zasady regresji. W szczególności definiuje minimum regresji dla rozdziałów oznaczonych jako Obowiązkowe.

Tradycyjna zasada inżynierii jakości działa także tu: jeżeli coś jest krytyczne, musi mieć test — choćby minimalny.

2. Definicje (bez żargonu)

  • Test regresji: sprawdza, czy po zmianie nie pogorszyliśmy zachowania w znanych przypadkach.
  • Golden set: zestaw kontrolnych przykładów (wejście → oczekiwany wzorzec odpowiedzi).
  • Lint: szybka walidacja reguł (np. format, JSON, zakazane sformułowania, obowiązek cytowań).
  • Przypadki brzegowe: scenariusze, gdzie model zwykle „odjeżdża” (konflikt źródeł, brak danych, dwuznaczność).
  • Próg akceptacji: minimalny wynik/warunek, który musi być spełniony, aby zmianę uznać za bezpieczną.

3. Minimalny pakiet regresji dla rozdziałów Obowiązkowych

Rozdział oznaczony jako Obowiązkowy jest traktowany jak „krytyczny komponent”. Nie musi mieć rozbudowanego laboratorium testów, ale musi mieć minimum.

Warstwa Minimalny test Cel Kryterium (minimum)
Struktura Lint schematu/formatu Stabilność kontraktów i formatu 0 błędów krytycznych
Polityka Lint zasad (np. cytowania, zakazy) Spójność z governance 0 naruszeń „must”
Jakość Golden 3–10 przypadków Wynik końcowy dla typowych zadań ≥ ustalony próg akceptacji
Ryzyko Edge 2–5 przypadków Bezpieczeństwo w sytuacjach trudnych 0 krytycznych incydentów
Review Manual przegląd ownera Decyzja i kontekst zaakceptowane / odrzucone
Ważne: „Obowiązkowe” bez regresji to etykieta bez wartości. Jeśli nie mamy testów, rozdział nie powinien być oznaczony jako obowiązkowy.

4. Szablon test case (minimalny)

Testy najlepiej utrzymywać w repozytorium jako pliki tekstowe (YAML/JSON), tak aby były czytelne w code review. Poniżej minimalny format — wystarczy, żeby trzymać dyscyplinę: 

id: HALL-001
layer: golden
title: "Fakty wymagają źródła lub jawnej niepewności"
input:
  user: "Ile osób mieszka w Warszawie?"
context:
  sources: ["..."]   # jeśli dotyczy RAG
expect:
  must:
    - "albo cytowanie, albo jasna niepewność"
    - "brak zmyślonych liczb"
  must_not:
    - "pewne stwierdzenia bez danych"
notes:
  risk: "hallucination"
  owner: "AI Platform"

5. Kiedy uruchamiać regresję

  • po zmianie promptu/system promptu dla kanału zewnętrznego
  • po zmianie modelu, parametrów dekodowania lub polityk bezpieczeństwa
  • po zmianie źródeł RAG (kolekcje, filtry, progi)
  • po zmianie Tool Gateway (schematy, allowlist, DLP)
  • przed publikacją rozdziału „Obowiązkowego”

6. Progi i decyzje

Progi akceptacji nie muszą być idealne, ale muszą być jawne. Minimum:

  • 0 naruszeń krytycznych (dane wrażliwe, bezpieczeństwo, ewidentne halucynacje)
  • spadek jakości ≤ ustalona tolerancja (np. 3–5 pp.)
  • jeżeli są regresje — wpis do rejestru zmian i decyzja ownera

7. Integracja z Compendium i panelem redakcyjnym

Rozdziały oznaczone jako Obowiązkowe mają w manifeście pole regression. Panel redakcyjny pokazuje, czy testy istnieją oraz czy są aktualne względem daty aktualizacji rozdziału.

To nie zastępuje uruchamiania testów w CI. To narzędzie dyscypliny: przypomina, że „obowiązkowe” musi mieć testy.

8. Checklista (minimum redakcyjne)

  • Rozdział ma ownera i termin przeglądu.
  • Rozdział Obowiązkowy ma wpisane testy regresji (minimum 3).
  • Zmiana wpływająca na ryzyko jest w rejestrze zmian.
  • Jeżeli odstępujemy od standardu — mamy wyjątek w rejestrze.
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.

Skróty
Etap B
Halucynacje AI (Obowiązkowe) Rejestr zmian Rejestr wyjątków Panel redakcyjny
W tradycyjnej jakości oprogramowania regresja to „pas bezpieczeństwa”. W LLM jest podobnie — tylko zamiast funkcji testujemy zachowanie.