Kontroler jakości AI nie sprawdza, czy odpowiedź „brzmi dobrze”. Sprawdza, czy nadaje się do konkretnego użycia, czy twierdzenia mają dowody, jakie są skutki błędu i kto bierze odpowiedzialność za publikację. Ta rola naturalnie pasuje do analityka, bo łączy rozumienie celu biznesowego, źródeł, zależności i odbiorcy artefaktu.
Definicja jakości zależy od zastosowania
Streszczenie spotkania, wymaganie dotyczące płatności i interpretacja regulacji nie mogą przechodzić tego samego przeglądu. Najpierw ustala się jednostkę oceny: twierdzenie, wymaganie, krok procesu albo cały dokument. Następnie definiuje się tolerancję błędu, metodę dowodzenia oraz osobę uprawnioną do akceptacji. Bez tego recenzja staje się uznaniowa.
| Kryterium | Pytanie kontrolne | Dowód |
|---|---|---|
| Wierność | Czy wynik nie zmienia znaczenia źródła? | Porównanie twierdzenie–fragment źródłowy |
| Kompletność | Czy ujęto wszystkie obowiązkowe warunki i wyjątki? | Checklista domenowa i przejście scenariuszy |
| Spójność | Czy termin, reguła i identyfikator zgadzają się z repozytorium? | Słownik, macierz śledzenia, walidatory |
| Użyteczność | Czy odbiorca wykona na tej podstawie zadanie? | Przegląd odbiorcy lub próba wykonania |
| Bezpieczeństwo | Czy ujawniono dane albo wygenerowano niedozwoloną poradę? | Klasyfikacja danych i polityka użycia |
Cztery bramki jakości
Bramka 1: dopuszczalność wejścia
Przed generowaniem sprawdza się klasyfikację danych, zgodę na użycie narzędzia, aktualność źródeł i zakres. Jeżeli model otrzymał sprzeczne wersje procedury bez dat, późniejsza kontrola tekstu nie naprawi błędnego wejścia. Wynik tej bramki to zatwierdzony manifest źródeł.
Bramka 2: kontrola strukturalna
Tu można użyć automatycznych reguł: wymagane pola, poprawne identyfikatory, brak niedozwolonych danych, obecność odwołania do źródła i zgodność z formatem. Walidator wykryje brak pola „właściciel”, lecz nie stwierdzi, czy wskazana osoba faktycznie ma mandat.
Bramka 3: przegląd merytoryczny
Recenzent wraca do źródeł, ocenia kontekst, wyszukuje nieuprawnione wnioski oraz uruchamia scenariusze negatywne. Przy wysokim ryzyku stosuje zasadę dwóch par oczu: analityk sprawdza spójność, a ekspert domenowy — prawidłowość reguły.
Bramka 4: zatwierdzenie do użycia
Osoba odpowiedzialna podejmuje decyzję: przyjąć, poprawić, odrzucić albo ograniczyć zastosowanie wyniku. Zapis obejmuje wersję modelu, prompt lub wzorzec zadania, źródła, recenzenta, wykryte błędy i finalny artefakt. Pozwala to później wyjaśnić, dlaczego wynik uznano za wystarczający.
Przypadek: AI klasyfikuje zgłoszenia do zmian systemu
Zespół chciał automatycznie oznaczać zgłoszenia jako błąd, zmiana, pytanie lub incydent bezpieczeństwa. Na próbce 200 historycznych spraw ogólna trafność wyniosła 91%. Wynik wyglądał bardzo dobrze, dopóki analityk nie rozbił go według klas. Model trafnie rozpoznawał pytania, które stanowiły większość, ale przeoczył 4 z 11 incydentów bezpieczeństwa. Średnia ukrywała krytyczne ryzyko.
Zmieniono więc cel: AI nie zamyka klasyfikacji, lecz proponuje etykietę i uzasadnienie. Zgłoszenia z symptomami bezpieczeństwa zawsze trafiają do ręcznej kolejki, a niska pewność blokuje automatyczne przekazanie. Próg wdrożenia ustalono osobno dla każdej klasy.
| Klasa | Znaczenie błędu | Kontrola | Kryterium przyjęcia |
|---|---|---|---|
| Pytanie | Opóźnienie odpowiedzi | Losowa próbka 10% | Min. 90% poprawnych etykiet |
| Zmiana | Błędny backlog | Akceptacja właściciela produktu | Źródło i wskazany obszar wpływu |
| Błąd | Niewłaściwy priorytet naprawy | Przegląd osoby dyżurnej | Opis obserwacji bez wymyślania przyczyny |
| Bezpieczeństwo | Ryzyko niewykrycia incydentu | 100% ręcznej weryfikacji | Wysoka czułość; brak automatycznego zamknięcia |
Próbkowanie i rejestr błędów
Próbka powinna obejmować nie tylko typowe wyniki, ale też wartości graniczne, rzadkie klasy, długie wejścia i przypadki spoza rozkładu testowego. Błędy warto kodować: brak źródła, zmiana znaczenia, pominięcie wyjątku, błędna klasyfikacja, ujawnienie danych, niezgodność formatu. Sam procent poprawek nie wystarczy — dwa błędy mogą mieć zupełnie inny skutek.
Rejestr błędów służy do poprawy procesu. Jeżeli powtarza się mylenie nazw ról, być może trzeba poprawić słownik wejściowy. Jeżeli recenzenci różnie oceniają wynik, brakuje jednoznacznych kryteriów. Jeżeli jakość spada po zmianie modelu, zestaw regresyjny pozwala to zauważyć przed publikacją.
Checklista kontrolera jakości
- Czy zadanie ma określony cel, odbiorcę i skutek błędnej odpowiedzi?
- Czy źródła są aktualne, dopuszczone i jednoznacznie oznaczone?
- Czy sprawdzono każdą informację krytyczną, a nie tylko losową średnią?
- Czy próbka obejmuje wyjątki, klasy rzadkie i przypadki negatywne?
- Czy wynik można odrzucić lub skierować do człowieka bez presji automatyzacji?
- Czy decyzja i wykryte błędy zasilają rejestr oraz testy regresyjne?
Podział ról w kontroli
Autor zastosowania odpowiada za instrukcję i testy, recenzent domenowy za prawidłowość faktów, właściciel procesu za dopuszczenie wyniku do użycia, a bezpieczeństwo informacji za warunki przetwarzania danych. Jedna osoba może pełnić kilka ról w małym zespole, lecz decyzje powinny pozostać rozróżnione. Autor promptu nie powinien samodzielnie zatwierdzać zastosowania wysokiego ryzyka bez niezależnego kontrprzykładu.
Przy sporze nie rozstrzyga „większa pewność” modelu. Recenzenci wracają do źródła i kryterium. Jeśli źródło nie pozwala wybrać odpowiedzi, rezultat brzmi „brak danych”, a nie kompromisowe zdanie. Liczbę takich przypadków warto mierzyć, ponieważ może wskazywać, że problem leży w jakości materiału wejściowego, a nie w generowaniu.
Decyzja warunkowa jest pełnoprawnym wynikiem bramki: materiał można wykorzystać do wewnętrznego szkicu, ale nie do komunikacji z klientem; klasyfikacja może proponować kolejkę, ale nie zamykać zgłoszenia. Takie ograniczenie powinno być widoczne w interfejsie i instrukcji operacyjnej. Inaczej użytkownik łatwo rozszerzy zastosowanie poza zakres, dla którego przeprowadzono testy.
Analityk nie powinien stawać się ręcznym filtrem naprawiającym nieograniczoną liczbę słabych odpowiedzi. Jeśli kontrola stale wykrywa ten sam błąd, trzeba zmienić wejście, zadanie, model albo zrezygnować z zastosowania. Katalog przyczyn opisuje materiał ograniczenia AI i kontrola jakości, a zasady pracy z wersjami rozwija AI w dokumentacji analitycznej.
