Zestaw ewaluacyjny buduje się przed funkcją

Projekty AI mają kształt, który łatwo rozpoznać, gdy zobaczy się go dwa razy. Pierwszy miesiąc idzie szybko. Drugi też. Około trzeciego zmiany zaczynają trwać dłużej, a przy czwartym nikt nie chce dotykać promptu, który działa — bo dotknięcie może coś zepsuć, a nie ma sposobu, żeby się dowiedzieć, poza wypuszczeniem na produkcję.

Projekt nie natrafił na trudny problem. Skończyła mu się zdolność do stwierdzenia, czy zmiana poprawiła sprawę.

Dlaczego klasyczne testowanie tu nie działa

To samo wejście nie daje tego samego wyjścia, więc asercje równości są bezużyteczne. Wyjściem zwykle jest tekst, więc nie ma czystego zdał albo nie zdał. A porażki, które mają znaczenie, nie są awariami: to odpowiedzi wyglądające dobrze i błędne w sposób wymagający wiedzy dziedzinowej, żeby to zauważyć.

Zespoły wracają więc do oceny na wyczucie. Ktoś po każdej zmianie próbuje kilku przykładów i wyrabia sobie wrażenie. Działa to jakieś sześć tygodni, a potem po cichu przestaje — bo wrażenia się nie kumulują i nikt nie pamięta, jak system zachowywał się wcześniej.

Czym naprawdę jest zestaw ewaluacyjny

Mniej, niż brzmi. W użytecznym minimum:

Zbiór prawdziwych przypadków. Pięćdziesiąt do dwustu wejść z rzeczywistego użycia, łącznie z niewygodnymi — dwuznaczne zapytanie, źle zeskanowany dokument, klient z dwoma kontami.

Znana dobra odpowiedź dla każdego. Albo, tam gdzie nie ma jednej poprawnej, kryterium, które oceniający potrafi stosować spójnie.

Automatyczne ocenianie. Dokładne dopasowanie tam, gdzie pasuje, porównanie pól tam, gdzie wyjście jest ustrukturyzowane, i sędzia modelowy ze spisanym kryterium tam, gdzie to proza. Każde ma ograniczenia; różnicę robi posiadanie któregokolwiek.

Liczba, która się rusza. Jedna ocena łączna plus podział na kategorie, uruchamiana przy każdej zmianie i zapisywana — żeby regresja była faktem, a nie odczuciem.

Dyscyplina, która sprawia, że to działa

Zbudujcie to przed funkcją. Gdy system już żyje, złożenie czystego zestawu jest znacznie trudniejsze i zawsze schodzi na dalszy plan wobec kolejnej rzeczy.

Zachowujcie niewygodne przypadki. Każdy incydent staje się przypadkiem. Tak zestaw wyrasta na najbardziej wartościowy artefakt w kodzie i nic nie kosztuje utrzymywanie go w ten sposób.

Oceniajcie wyszukiwanie osobno. W systemach z wyszukiwaniem kontekstu większość złych odpowiedzi to porażki wyszukiwania, a jedna ocena od końca do końca ukrywa, która połowa systemu zawiniła.

Nigdy nie pozwólcie, żeby zestaw pisał ten sam prompt. Jeśli ewaluacja i implementacja dzielą model, prompt albo założenie, zestaw zaakceptuje wszystko, co system akurat robi.

Publikujcie liczbę. Również wtedy, gdy spada. Metryka jakości pojawiająca się tylko wtedy, gdy zespołowi schlebia, nie jest metryką.

Co to daje

Zmiany stają się bezpieczne. Aktualizacja modelu staje się mierzalną decyzją, a nie skokiem. Optymalizacja kosztu staje się możliwa, bo można przenieść pracę do mniejszego modelu i zobaczyć dokładnie, ile kosztowało to w jakości. A incydent staje się przypadkiem, a nie sporem.

To tydzień pracy na starcie projektu i różnica między kodem, który z czasem przyspiesza, a takim, który się zaciera. To pierwsza rzecz, którą budujemy przy inżynierii aplikacji AI-native — łącznie, a nawet zwłaszcza, wtedy, gdy przejmujemy cudzy system.