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.
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.