Jeden model wygrywa ranking, drugi ma lepszy wykres, trzeci jest tańszy. Na twoim dokumencie pierwszy myli NIP, drugi gubi tabelę, a trzeci odpowiada poprawnie. Ranking nie kłamie; po prostu mierzy inne zadanie. Twoja księgowość nie jest zestawem pytań z internetu.
Porównanie powinno odpowiadać na konkretny proces. Potrzebujesz własnych przypadków, stałej rubryki i kosztu odbioru. Model wybierasz do pracy, nie do prezentacji możliwości.
Zdefiniuj jedno zadanie na raz
Nie porównuj „który model jest lepszy” bez kontekstu. Wybierz ekstrakcję pól, odpowiedź z cytatem, klasyfikację lub redakcję. Każde zadanie ma inne błędy i koszty. Zwycięzca jednego może przegrać drugie.
Zapisz wejście, oczekiwany wynik i skutek błędu. Przy fakturze błędna kwota jest krytyczna, przy propozycji nagłówka drobna różnica stylu może nie mieć znaczenia. Rubryka powinna to odzwierciedlać.
Ogranicz liczbę modeli do realnych kandydatów. Testowanie wszystkich nowości zwiększa koszt i czas, ale niekoniecznie poprawia decyzję. Wybierz wariant bazowy, alternatywę i proces bez AI.
Przy wyborze kandydatów sprawdź, czy możesz użyć danych testowych zgodnie z warunkami dostawców oraz zasadami dostępu, zanim wyślesz pierwszy dokument.
Przygotuj warstwowy zestaw danych
Dodaj typowe, trudne, błędne i nietypowe przypadki. Nie wybieraj tylko dokumentów, na których obecny proces działa. Nowy model ma pokazać, czy radzi sobie z rzeczywistym zakresem pracy.
Oddziel zestaw do strojenia od zestawu oceny końcowej. Jeżeli zmieniasz prompt na tych samych przypadkach, możesz dopasować się do ich cech i przecenić wynik. Zachowaj osobną próbkę kontrolną.
Zapisz źródła, wersje i braki. Nie czyść danych tak, by każdy dokument był idealny. Prawdziwa praca zawiera polskie znaki, złe skany, sprzeczne wersje i pola bez odpowiedzi. Metody opisuje przewodnik o OCR polskich dokumentów.
Rubryka przed pierwszym wynikiem
Zapisz kryteria i błędy krytyczne przed uruchomieniem. Dla ekstrakcji: poprawność pola, brak zgadywania, struktura, odwołanie. Dla tekstu: fakt, ton, format, skutek. Nie twórz jednej średniej dla wszystkiego.
Jeżeli błąd krytyczny dyskwalifikuje wynik, zapisz to. Nie pozwól, by dobra stylizacja przykryła wymyśloną datę. Przy porównaniu procesów biznesowych ważny jest koszt błędu, nie tylko estetyka odpowiedzi.
Przy subiektywnych cechach przygotuj przykłady. Naturalny język nie jest jedną rzeczą dla każdego. Rubryka ma ograniczać różnice ocen, nie udawać pełnej obiektywności.
Ustaw ten sam proces
Użyj tych samych źródeł, formatu i narzędzi, o ile to możliwe. Różnice w kontekście mogą wpływać bardziej niż model. Jeżeli jeden wymaga innego schematu, zapisz konieczną zmianę i jej koszt.
Nie zmieniaj promptu na korzyść jednego kandydata bez odnotowania. Możesz mieć etap optymalizacji dla każdego, ale potrzebny jest wspólny baseline i osobny wynik po dostrojeniu. Inaczej porównujesz pracę zespołu, nie tylko modele.
Zapisz parametry i wersje. Nie zakładaj zgodności temperatury między dostawcami. Zasady konfiguracji opisuje przewodnik o ustawieniach modelu AI.
Mierz koszt całkowity
Zapisz koszt wejścia, wyjścia, ponowień, czasu i odbioru. Model zwracający długie odpowiedzi może kosztować więcej nawet przy podobnej jakości. Pętla poprawiająca zwiększa cenę zadania.
Dolicz przygotowanie i integrację. Jeżeli dostawca wymaga osobnego formatu lub przetwarzania, to jest praca. Przy migracji dodaj testy i rollback. Cena za milion tokenów nie pokazuje całego rachunku.
Porównaj koszt na zaakceptowany wynik, nie na żądanie. Tańszy model z większą liczbą odrzuceń może być droższy w praktyce. Szczegóły opisuje przewodnik o całkowitym koszcie AI.
Nie wybieraj najlepszego przykładu
Uruchom każdy wariant kilka razy, jeżeli zmienność ma znaczenie. Zapisz wszystkie wyniki, nie tylko ulubiony. Prezentowanie najlepszej próby tworzy fałszywy obraz stabilności.
Przy błędzie bezpieczeństwa jedna próba wystarcza, by go odnotować. Nie znika dlatego, że cztery kolejne są poprawne. Raport powinien pokazywać częstość i skutek, nie tylko średnią.
Jeżeli wynik zależy od daty i obciążenia, zapisz warunki. Test wykonany w spokojnym momencie nie opisuje szczytu. Nie musisz mierzyć wszystkiego, ale musisz oznaczyć ograniczenia.
Analizuj błędy według typu
Pogrupuj błędy: fakt, brak źródła, format, zgodność z instrukcją, prywatność, skutek. Jeden model może być lepszy w strukturze, drugi w znaczeniu. Wybór zależy od kosztu każdego typu.
Sprawdź, czy błędy tworzą wspólny wzorzec. Może problem dotyczy jednego formatu dokumentu i wymaga preprocessing, nie zmiany modelu. Nie dokładaj złożoności, jeżeli źródło jest główną przyczyną.
Przy konflikcie rubryki zapisz go. Może oczekiwany wynik był niejasny i wymaga decyzji właściciela. Nie zmieniaj go automatycznie pod najbliższą odpowiedź modelu.
Przykład: prosty i trudny dokument
W hipotetycznym przykładzie na standardowym formularzu wszystkie porównywane modele odczytują pola dobrze. Na dokumencie z wariantem dwie odpowiedzi przypisują akcesoria z pakietu do wersji podstawowej. Ta różnica jest ważniejsza niż drobne różnice stylu.
Wybór może prowadzić do routingu: proste przypadki do tańszego modelu, trudne do dokładniejszego. Reguła powinna być testowana osobno. Nie zakładaj, że zawsze potrzebny jest najdroższy wariant.
Przy katalogu produktów łączy się to z zasadami z artykułu o porządkowaniu danych produktowych. Jakość źródła nadal decyduje o granicach wyniku.
Odbiór bez informacji o modelu
Jeżeli to możliwe, ukryj nazwy kandydatów przed oceniającymi. Daj wyniki w losowej kolejności z tą samą rubryką. To ogranicza sympatię do marki i oczekiwania, że droższy musi być lepszy.
Nie ukrywaj jednak informacji potrzebnych do oceny: wersja źródła, format, braki. Osoba oceniająca powinna widzieć wymagany kontekst, nie zgadywać proces. Po ocenie możesz odkryć konfiguracje i koszt.
Porównaj różnice między oceniającymi. Jeżeli są duże, popraw rubrykę lub przypadki. Głosowanie nie zastępuje definicji jakości.
Kiedy wynik jest zbyt bliski
Jeżeli modele dają podobną jakość, wybierz prostszy proces, niższy koszt lub lepsze warunki wyjścia. Nie dodawaj nowych kryteriów tylko po to, by udowodnić wcześniejszego faworyta.
Zapisz remis i ograniczenia pomiaru. Być może zestaw jest za mały dla drobnej różnicy, ale wystarczający do decyzji o podobnej jakości. Nie musisz udawać precyzji, której nie ma.
Przy zmianie wolumenu lub typu dokumentów zaplanuj nowy test. Decyzja dotyczy obecnego procesu, nie wiecznego rankingu modeli.
Migracja po wyborze
Nie przełączaj całego ruchu od razu. Wybierz mały wolumen i porównaj rzeczywisty wynik z poprzednim procesem. Sprawdź uprawnienia, logi, koszt i zachowanie przy awarii.
Przygotuj rollback z wersją konfiguracji i danych. Zmiana modelu może zmienić format lub skutek. Test powinien obejmować krytyczne przypadki oraz jeden kontrolny.
Po wdrożeniu zbieraj nowe błędy i dodawaj je do zestawu. Model może zostać zaktualizowany przez dostawcę, więc przegląd musi być powtarzalny.
Rekomendacja po porównaniu modeli
Zapisz zadanie, kandydatów, zakres, rubrykę, wyniki krytyczne, koszt, ograniczenia i rekomendację. Nie przepisuj wszystkich odpowiedzi. Dodaj identyfikatory oraz przykłady różnic.
Rekomendacja powinna mówić, kiedy wybrać wariant i kiedy zmienić decyzję. Może zawierać prosty routing. Nie kończ na „model A jest lepszy” bez kontekstu pracy.
Jak uniknąć przecieku zestawu testowego do promptu
Nie wklejaj odpowiedzi referencyjnych do instrukcji modelu, jeżeli mają oceniać zdolność rozwiązywania nowych przypadków. Przykłady w promptu powinny być osobnymi materiałami dydaktycznymi. Inaczej test może mierzyć kopiowanie, a nie właściwą pracę.
Przechowuj zestaw wersjonowany i ogranicz dostęp zgodnie z danymi. Przy zmianie promptu nie dodawaj przypadków kontrolnych jako przykładów, chyba że jawnie projektujesz proces few-shot. Wtedy zachowaj osobną próbkę końcową.
Jeżeli dojdzie do przypadkowego użycia danych, oznacz je i przygotuj nowe kontrolne. Nie raportuj wyniku jako niezależnego. To jest problem metody, nie drobny szczegół techniczny.
Mały zestaw przy ograniczonym budżecie
Przy ograniczonym budżecie możesz zacząć od przykładowych dwunastu przypadków: czterech typowych, czterech trudnych i czterech z błędami lub brakami. Opisz ryzyko każdego i dobierz dalszy zakres do skutków błędu. Taka liczba nie jest uniwersalnym minimum ani dowodem pełnego pokrycia.
Nie uogólniaj wyniku na każdy przyszły dokument. Zapisz zakres i dodawaj przypadki z produkcji. Mały zestaw nie jest ostatecznym dowodem, ale pozwala odrzucić złe dopasowanie przed kosztowną migracją.
Przy błędzie krytycznym zwiększ liczbę przypadków właśnie w tym obszarze. Nie powiększaj całości losowo. Decyzja zależy od rodzaju ryzyka i kosztu testu.
Pytania dla dostawcy po teście
Zapisz, które różnice wymagają odpowiedzi: wersja modelu, retencja, limity, eksport, region, plan i wsparcie. Nie pytaj tylko o obietnicę jakości. Przywołaj konkretny przypadek i zachowanie.
Jeżeli dostawca odpowiada nową wersją lub konfiguracją, powtórz ten sam zestaw. Nie zamieniaj odpowiedzi marketingowej w dowód. Zapisz datę i źródło rozstrzygnięcia.
Przy wyborze modelu do danych wrażliwych oceń najpierw warunki dopuszczenia. Nawet najlepszy wynik nie pomaga, jeżeli źródła nie wolno przetwarzać w danym kanale. Warunek powinien działać jako dyskwalifikacja, a nie mała uwaga pod tabelą punktów.
Porównaj także zachowanie przy awarii i limicie. Proces musi wiedzieć, kiedy zatrzymać się lub przełączyć bez zgadywania. Fallback testuj na tych samych przypadkach, bo inna konfiguracja może zmieniać sens odpowiedzi.
Po teście zachowaj próbkę niezależną od narzędzia użytego do porównania. Jeżeli automatyczny raport różni się od oceny człowieka, sprawdź rubrykę i parser. Nie uznawaj samej liczby z dashboardu za ostateczny dowód.
Przy porównywaniu czasu zapisz pełny proces z odbiorem i ponowieniami. Sam czas odpowiedzi API nie opisuje pracy użytkownika. Jeżeli jeden model wymaga dłuższego myślenia, ale mniej poprawek, może być lepszy dla zadania. Mierz skutek, nie parametr w izolacji.
Po kilku tygodniach porównaj nowe przypadki z testem. Model mógł zmienić zachowanie lub proces źródła. Nie traktuj decyzji jako stałej. Zapisz termin ponownej oceny i właściciela, a przy ważniejszej zmianie dostawcy uruchom przypadki kontrolne.
Przy archiwizacji ogranicz dostęp do wyników zawierających dane klientów. Raport może opisywać błędy bez pełnych treści. Zachowaj identyfikatory i wersje zamiast kolejnych eksportów źródłowych.
Nie przedstawiaj wyniku jako certyfikatu modelu. Jest to dowód dla jednego procesu i okresu. Przy nowym zadaniu przygotuj osobną rubrykę i przypadki zamiast przenosić ogólny werdykt.
Aeneia Audit pomaga przygotować przypadki i policzyć proces. Przy pilotażu pomocne są kryteria oceny Aeneia Signal.
Wynik porównania przypisz do zestawu przypadków, wersji modeli i czasu testu. Nowe zadanie może wymagać innych kryteriów. Przed ponownym wyborem sprawdź także koszt ręcznego odbioru odpowiedzi. Zachowaj również przypadki, których żaden wariant nie obsłużył.
Sprawdź nas. To zdrowe.
Temat zmienia się szybko. Linki prowadzą do źródeł pierwotnych i stron, na których możesz zweryfikować kontekst.
