Jak profesjonalnie testować systemy AI – kompleksowy przewodnik po ewaluacji #EN176

TL;DR

• Ewaluacja AI to konieczność, nie opcja – nawet najlepsze LLM mają problemy z niestabilną wydajnością i halucynacjami
• Trzy filary skutecznej ewaluacji: zadanie (task do przetestowania), zbiór danych (przypadki testowe), wyniki (logika oceniania 0-1)
• Ewaluacja offline służy do testowania w fazie developmentu, ewaluacja online monitoruje ruch produkcyjny w czasie rzeczywistym
• BrainTrust oferuje dwa tryby pracy: Playground do szybkich iteracji i Experiments do długoterminowej analizy
• Monitoring produkcji wymaga logowania interakcji i oceniania online z konfigurowalnymi alertami regresji
• Człowiek w pętli jest kluczowy dla weryfikacji jakości i budowania punktu odniesienia
• Zaczynaj małymi krokami – lepiej mieć 10 przypadków testowych niż czekać na idealny zbiór danych

Wprowadzenie

Poniższe notatki powstały na podstawie warsztatów BrainTrust pt. „Mastering AI Evaluation: From Playground to Production”, które prowadzili Doug i Carlos Esteban z zespołu inżynierów rozwiązań. Wszystkie przedstawione przemyślenia, obserwacje i wnioski pochodzą od prelegentów, którzy prezentowali praktyczne podejście do ewaluacji systemów AI – od pierwszych testów po monitoring produkcji.

Warsztat odbył się podczas AI World Fair jako pierwszy z dwóch planowanych tego dnia. Doug, pracujący wtedy trzeci tydzień w BrainTrust, oraz Carlos (sześć tygodni doświadczenia w firmie) połączyli teorię z ćwiczeniami praktycznymi. Obaj inżynierowie dołączyli do zespołu z innych firm technologicznych – Doug z obszaru danych i finansów, Carlos z infrastruktury (HashiCorp, Terraform, Vault).

Dlaczego ewaluacja AI to nie opcja, ale konieczność

Prowadzący podkreślali fundamentalny problem współczesnych systemów AI. Najlepsze LLM nie gwarantują stabilnej wydajności, mimo że mogą wydawać się niezawodne podczas pierwszych testów. Halucynacje występują w wysokim stopniu, a wydajność degraduje się wraz ze zmianami w systemie.

Szczególnie problematyczne jest to, że zmiana promptu – nawet jeśli wydaje się poprawą – może w rzeczywistości pogorszyć funkcjonowanie całego systemu. Dlatego zespoły potrzebują naukowego, empirycznego sposobu testowania wprowadzanych zmian.

Korzyści biznesowe systematycznej ewaluacji

Według prezentujących, właściwie wdrożona ewaluacja AI przynosi wymierne korzyści biznesowe. Przede wszystkim skraca czas developmentu i pozwala szybciej wprowadzać zmiany do produkcji. Jednocześnie redukuje koszty dzięki automatyzacji zastępującej czasochłonny przegląd ręczny.

System ewaluacji umożliwia również szybsze iteracje i wdrożenia. Pozwala zoptymalizować wybór modelu pod kątem stosunku jakości do ceny, co ma bezpośredni wpływ na budżet projektu.

BrainTrust prezentował wyniki swoich klientów, którzy dzięki platformie zwiększyli produktywność zespołów i jakość produktów AI. Prowadzący zwracali uwagę na dodatkową korzyść – ewaluacja pozwala skalować zespoły, umożliwiając zarówno nietechnicznym jak i technicznym użytkownikom współudział w wyborze promptów, modeli i ogólnym zarządzaniu wydajnością.

Trzy fundamentalne składniki ewaluacji AI

Carlos Esteban wyjaśniał, że skuteczna ewaluacja wymaga trzech kluczowych elementów, które muszą współpracować ze sobą jako spójny system.

Zadanie – definicja tego, co testujemy

Zadanie to kod lub prompt, który zespół chce ocenić. Może być to pojedyncze wywołanie LLM lub złożony przepływ pracy agenta. Jedynym wymogiem technicznym jest obecność jasno zdefiniowanych danych wejściowych i wyjściowych.

Platforma BrainTrust umożliwia tworzenie prostych promptów z dynamicznym templatingiem wykorzystującym składnię mustache. Jednak możliwości są znacznie szersze – system obsługuje konwersacje wieloetapowe z całymi łańcuchami wiadomości, wywołania narzędzi do symulacji połączeń z zewnętrznymi usługami oraz łączenie promptów w chains.

Carlos podkreślał, że BrainTrust radzi sobie z zaawansowanymi przypadkami, takimi jak RAG (Retrieval-Augmented Generation) czy systemy agentów. Można łączyć prompty w łańcuchy, gdzie dane wyjściowe pierwszego stają się danymi wejściowymi następnego. W przypadku bardziej złożonych scenariuszy z różnymi rolami użytkowników, platforma oferuje większą elastyczność przez SDK.

Zbiór danych – fundament testowania

Zbiór danych składa się z trzech pól, z których wymagane są tylko dane wejściowe:

• Dane wejściowe – konkretny przypadek użycia podany przez użytkownika
• Oczekiwane wyniki (opcjonalne) – idealna odpowiedź dla danego przypadku
• Metadane (opcjonalne) – dodatkowe informacje kontekstowe

Carlos radził pragmatyczne podejście: „Zacznij małymi krokami i iteruj. Nie musi to być największy zbiór danych wszech czasów”. Na początku można używać danych syntetycznych, stopniowo włączając prawdziwe interakcje użytkowników.

System oceniania – mierzenie jakości

Dostępne są dwa główne typy oceniania, każdy z własnymi zastosowaniami. LLM as a judge sprawdza się doskonale w przypadku subiektywnej, kontekstowej oceny. Prowadzący rekomendowali używanie lepszego, droższego modelu do oceny wyników tańszego modelu, skupienie się na jednym konkretnym kryterium oraz wyraźne wyjaśnienie kroków myślowych dla LLM.

Alternatywą są wyniki oparte na kodzie – deterministyczne oceny dla dokładnych lub binarnych warunków. Oba typy muszą zwracać wynik w skali od 0 do 1, co umożliwia spójne porównywanie.

Wyzwania związane z niestabilnością automatycznej oceny

Podczas warsztatów pojawiło się istotne pytanie o determinizm LLM as a judge. Carlos wyjaśniał: „Tak, może być pewna zmienność. To co widzimy u naszych klientów, to trial evals – uruchamiasz to może pięć razy i bierzesz średnią”.

Prelegenci przedstawili kilka strategii radzenia sobie z niestabilnością:

• Używanie lepszych modeli do oceny (np. GPT-4 do oceny GPT-3.5)
• Uruchamianie wielokrotnych testów i obliczanie średniej
• Skupienie się na punktach odniesienia i trendach zamiast wartości absolutnych
• Regularny przegląd uzasadnień stojących za ocenami LLM

Dwie komplementarne strategie ewaluacji

Ewaluacja offline – testowanie przed wdrożeniem

Ewaluacja offline to strukturalne testowanie systemów AI przed ich udostępnieniem użytkownikom końcowym. Służy do proaktywnego identyfikowania problemów i słabych punktów. W ekosystemie BrainTrust proces ten odbywa się głównie w środowisku Playground oraz przez SDK.

Ewaluacja online – monitoring w produkcji

Z kolei ewaluacja online polega na przechwytywaniu i ocenianiu prawdziwego ruchu w czasie rzeczywistym. Pozwala to diagnozować problemy, monitorować wydajność i zbierać opinie użytkowników bezpośrednio z działającego systemu.

Narzędzia do iteracyjnego rozwoju

Doug wyjaśniał różnice między dwoma głównymi trybami pracy w BrainTrust. Playground służy do szybkich iteracji nad promptami, wynikami i zbiorami danych. Jest idealny do testów A/B promptów i modeli, jednocześnie umożliwiając zapisanie migawki do widoku Experiments.

Experiments to narzędzie do porównań długoterminowych. Agreguje wszystkie prace zespołu wykonane zarówno przez interfejs użytkownika jak i SDK, pozwalając analizować zmiany wyników na przestrzeni tygodni i miesięcy.

Implementacja przez SDK dla programistów

Prowadzący demonstrowali, że wszystkie zasoby można definiować w kodzie. Obejmuje to prompty z kontrolą wersji i dynamicznym templatingiem, wyniki (zarówno LLM as judge jak i oparte na kodzie), zbiory danych z metadanymi oraz kompletne definicje ewaluacji.

SDK szczególnie przydaje się, gdy zespół potrzebuje wersjonowania promptów, chce zapewnić spójność między różnymi środowiskami, planuje wykorzystać ocenianie online lub pracuje z większymi, bardziej złożonymi przepływami pracy.

Elastyczność w wyborze dostawców AI

Doug podkreślał, że BrainTrust nie ogranicza się do jednego dostawcy. Platforma obsługuje wielu dostawców AI, w tym dostawców chmurowych jak AWS Bedrock, a nawet niestandardowych dostawców. Można również uruchamiać ewaluacje lokalnie z lokalnymi modelami – platforma oferuje funkcję „remote evals” dla bardziej zaawansowanych zastosowań.

Praktyczne aspekty monitoringu produkcyjnego

Implementacja logowania jedną linią kodu

Doug demonstruował, jak drastycznie uprościć proces logowania. Najprostsze opcje to:

• wrap OpenAI – opakowuje klienta LLM i automatycznie loguje wszystkie interakcje
• Vercel AI SDK wrapper – dedykowany dla projektów wykorzystujących Vercel AI
• Integracja OpenTelemetry – dla zespołów już korzystających z Otel

Funkcja wrap OpenAI automatycznie rejestruje wszystkie prompty i odpowiedzi, kluczowe metryki (liczba tokenów, opóźnienie), błędy i wyjątki oraz metadane wywołań. Dla bardziej zaawansowanych przypadków dostępne są trace decorators dla konkretnych funkcji i span logs dla dodatkowych metadanych.

Monitorowanie kosztów i metryk biznesowych

Doug zwracał uwagę na dodatkową wartość automatycznego logowania. System dostarcza nie tylko informacji technicznych, ale także szacowane koszty wywołań. „To staje się naprawdę pomocne gdy zaczynasz monitorować w czasie – ile tokenów używa się w czasie, jak wyglądają koszty w czasie gdy zmieniasz modele”.

Praktyka „dogfooding” w BrainTrust

Interesującym przykładem była praktyka stosowana przez samą firmę BrainTrust. Carlos wyjaśniał: „Pytanie brzmiało, jak ewaluujemy nasze funkcje AI? I oczywiście musimy używać BrainTrust. Naprawdę fajnie jest patrzeć na projekt i widzieć wszystkie dzienniki wchodzące i patrzeć na wyniki, które wybraliśmy”.

Ankur, CEO BrainTrust, przez miesiące prowadził systematyczne testy porównawcze nowych modeli, czekając aż osiągną wymagany poziom wydajności. Dopiero w ostatnim miesiącu przed warsztatami model osiągnął oczekiwany standard – co pokazuje, jak wymagający jest proces rozwoju profesjonalnych narzędzi AI.

Konfiguracja oceniania online

Ocenianie online umożliwia mierzenie jakości ruchu na żywo z pełną kontrolą nad procesem. Administratorzy mogą skonfigurować procent dzienników przeznaczonych do ewaluacji (od 1% do 100% całego ruchu), wybrać konkretne span’y zamiast standardowego root span oraz targetować określone typy interakcji.

System oferuje wczesne alerty regresji przy spadku poniżej ustalonego progu oraz powiadomienia w czasie rzeczywistym dla zespołu. Carlos podkreślał: „Możesz ustawić alerty regresji – jeśli zacznie spadać poniżej 70%, 60%, zależy od wyniku i ustalonego punktu odniesienia”.

Dodatkowo platforma umożliwia prowadzenie testów A/B przez tagowanie różnych promptów w produkcji i automatyczne zbieranie metryk dla każdego wariantu.

Zaawansowane funkcje dostrajania

Na pytanie o możliwość wymuszenia 100% oceniania dla konkretnych danych wejściowych, Carlos wyjaśniał zaawansowaną funkcjonalność: „Sposób, w jaki byś to robił, to zmieniając span, który jest targetowany. Zamiast aplikować do root span, wskazałbyś span, który pojawia się tylko gdy konkretne kryterium jest spełnione”.

Istotne było też pytanie dotyczące aplikacji zmieniających się w cyklu sprintów. Carlos radził skupić się na solidnych wynikach mierzących podstawową jakość, nawet gdy liczba kroków procesu się zmienia. „Gdy pisze się ewaluacje, można dynamicznie wywoływać zadanie. Więc nawet gdy pracujesz nad aplikacją i ona się zmienia, nadal wskazujesz na zmieniającą się aplikację”.

Widoki zespołowe i współpraca

Platforma pozwala tworzyć widoki niestandardowe z filtrami, sortowaniem i wybranymi kolumnami. Zespoły mogą zapisywać widoki takie jak „dzienniki poniżej 50%” i udostępniać je wszystkim członkom zespołu.

Doug pokazywał praktyczną funkcję dodawania danych: „Znajdujesz tę rzecz, która rzeczywiście doda dużo wartości w tym procesie ewaluacji offline. Kliknij to. Teraz masz zupełnie nowy wiersz w tym zbiorze danych”.

Tworzy to „efekt koła zamachowego” – ewaluacja offline prowadzi do produkcji, stamtąd do logowania, następnie do przeglądu ludzkiego, dodania do zbioru danych i wreszcie do lepszej ewaluacji offline.

Rola człowieka w procesie ewaluacji

Znaczenie przeglądu ludzkiego

Doug wyjaśniał fundamentalne znaczenie ludzkiej weryfikacji: „To krytyczne dla jakości i niezawodności. Automatyzacja może przegapić niuanse. Chcemy zastosować ludzki typ recenzji do tego, co robimy po stronie AI”.

Dostępne są dwa typy integracji człowieka w proces. Przegląd ludzki obejmuje ręczne labelowanie, ocenianie i auditowanie interakcji bezpośrednio w platformie BrainTrust. Opinie użytkowników to natomiast komentarze w czasie rzeczywistym, takie jak oceny kciuk w górę/w dół implementowane w aplikacji.

Te podejścia można skutecznie łączyć. Na przykład, można utworzyć widok filtrujący wszystkie opinie użytkowników równe 0 (kciuk w dół) i następnie ręcznie sprawdzić, czy rzeczywiście wskazują na problemy z jakością.

Proces walidacji automatycznych ocen

Carlos podkreślał dodatkową wartość przeglądu ludzkiego: „To naprawdę pomocne do ewaluacji samego LLM as judge. Często widzimy, jak klienci używają tego procesu do dostarczenia punktu odniesienia dla swoich zbiorów danych i dla LLM as judge”.

Proces weryfikacji obejmuje zespół ekspertów przedmiotu przeprowadzających oceny kciuk w górę/w dół na różnych kryteriach, wprowadzanie tych danych do playground gdzie prompt stanowi LLM as judge, a następnie testowanie zgodności między promptem LLM as judge a oceną ludzką.

Organizacja ekspertów w wyspecjalizowanych branżach

Na pytanie o zarządzanie ekspertami przedmiotu, Carlos przyznawał: „Nie używamy żadnych ekspertów w tym momencie – nie jesteśmy firmą healthcare ani legal tech, gdzie mocno polegamy na wyspecjalizowanej wiedzy”.

Jednak klienci BrainTrust w wyspecjalizowanych branżach stosują różne podejścia. Zatrudniają zewnętrzne usługi adnotacji, wprowadzają ekspertów do platformy z określonymi rolami, tworzą dedykowane widoki wyłącznie do adnotacji oraz wykorzystują lekarzy, prawników i innych specjalistów do przeglądu wyników.

Praktyczna matryca decyzyjna

Carlos przedstawiał systematyczne podejście do diagnozowania problemów z ewaluacją:

• Dobry wynik + wysoki score = potwierdzenie wysokiej jakości systemu
• Dobry wynik + niski score = konieczność poprawy ewaluacji – score nie odzwierciedla ludzkiej oceny
• Zły wynik + wysoki score = konieczność poprawy ewaluacji – brak zgodności z oceną ludzką
• Zły wynik + niski score = prawidłowe funkcjonowanie ewaluacji, potrzeba poprawy aplikacji AI

Wskazówki implementacyjne od praktyków

Strategia budowania zbiorów danych

Doug przedstawiał pragmatyczne podejście do rozpoczęcia pracy ze zbiorami danych. Można zacząć od danych syntetycznych dla szybkiego startu, zbierania danych z testów wewnętrznych oraz utworzenia minimalnego viable zbioru danych – wystarczających już 5-10 przypadków.

Kluczowe jest unikanie pułapki oczekiwania na „idealny” zbiór danych zawierający 100-200 przypadków oraz próby pokrycia wszystkich możliwych scenariuszy od początku. Doug przestrzegał: „Nie robić tego, co nie trzeba – czekać aż będzie się miało 100, 200 przypadków, ten złoty zbiór danych”.

Implementacja few-shot prompting

Carlos wyjaśniał praktyczną funkcjonalność: „W kolumnie metadane w zbiorze danych możesz dostarczyć przykłady few-shot, które chcesz dla każdego wiersza. Gdy uruchamiasz ewaluację lub bawisz się w playground, będzie odnosić się do few shots w metadanych”.

Jednak dla ruchu na żywo sytuacja wygląda inaczej. Obecnie BrainTrust nie oferuje natywnego wsparcia dla automatycznego wykorzystywania przykładów ze zbiorów danych w czasie rzeczywistym, choć można to zaimplementować poprzez własną logikę w SDK.

Migracja istniejących projektów

Doug potwierdzał łatwość implementacji w istniejących systemach: „To właściwie to samo co Langsmith – masz kod do opakowywania klienta LLM lub decoratory na funkcje. Dokładnie to samo po stronie BrainTrust”.

Proces migracji obejmuje dodanie wrapper’ów do istniejących wywołań LLM, automatyczne logowanie bez konieczności zmian w logice aplikacji, łatwe tworzenie zbiorów danych z istniejących dzienników oraz mapowanie struktury dzienników do struktury zbiorów danych.

Równowaga między automatyzacją a oceną ludzką

Prowadzący obserwowali podział klientów na dwa główne obozy. Obóz pełnej automatyzacji preferuje wyłącznie deterministyczne ocenianie bez korzystania z LLM as judge. Obóz LLM as judge polega głównie na automatycznej ocenie przez AI.

Jednak rekomendowanym podejściem jest strategia hybrydowa łącząca deterministyczne ocenianie dla obiektywnych kryteriów z LLM as judge dla subiektywnych aspektów jakości. Carlos komentował: „Powód tego podziału to to, że oba podejścia działają. Nie wiem, jak to się ostatecznie ułoży – czy spotkamy się w środku drogi, czy determinizm wygra”.

Rola tradycyjnych modeli uczenia maszynowego

Na pytanie o miejsce dla tradycyjnych modeli ML (klasyfikacja intencji, rozpoznawanie encji, analiza sentymentu) jako „środka drogi” między deterministycznym kodem a LLM as judge, Carlos odpowiadał dyplomatycznie: „Nie mam świetnej odpowiedzi. Myślę, że używając BrainTrust masz możliwość skonfigurowania obu – LLM as judge i scorer”.

Praktyczne podejście zakłada eksperymentowanie z różnymi typami wyników, wykorzystywanie przeglądu ludzkiego do walidacji różnych podejść, wybieranie najlepiej działających rozwiązań dla konkretnego przypadku użycia oraz świadomość, że nie ma uniwersalnego rozwiązania.

Filozofia iteracyjnego rozwoju

Carlos podkreślał kluczową zasadę: „Jeśli masz jeden lub dwa wyniki i 10 wierszy w zbiorze danych, będzie to tremendously helpful. A potem to wszystko o iteracji”.

Doug wspominał o różnorodności klientów BrainTrust – od standardowych aplikacji biznesowych po wyspecjalizowane dziedziny. „Mamy lekarzy przychodzących na platformę i faktycznie oceniających część tego materiału” – co pokazuje szerokie zastosowanie przeglądu ludzkiego w krytycznych domenach.

Cykl ciągłej poprawy obejmuje testowanie z minimalną konfiguracją, wdrażanie do produkcji z podstawowym monitoringiem, zbieranie prawdziwych danych użytkowników, włączanie przeglądu ludzkiego dla krytycznych przypadków, dodawanie odkryć do zbiorów danych oraz iterowanie nad wynikami i zadaniami.

Czas potrzebny na uzyskanie wartości

Na kluczowe pytanie o balans między czasem ewaluacji offline a online, Carlos dawał pragmatyczną odpowiedź: „Powiedziałbym drugie – nie chcesz być obsesyjny na punkcie tworzenia złotego zbioru danych lub 20 wyników. Jeśli masz jeden lub dwa wyniki i 10 wierszy w zbiorze danych, będzie to tremendously helpful”.

Kluczowe zasady obejmują: nie czekanie na perfekcyjną konfigurację przy rozpoczynaniu z minimum viable, świadomość że wartość pojawia się już przy 1-2 wynikach i 10 przypadkach testowych, priorytet iteracji nad perfekcją na starcie oraz przekonanie, że lepiej szybko zacząć i poprawiać niż czekać na idealne warunki.

Checklist implementacyjny

Przygotowanie podstaw

• Zdefiniuj zadanie – określ co chcesz testować (prompt, przepływ pracy, czy cały system)
• Stwórz mały zbiór danych – zacznij od 5-10 przypadków testowych, nie czekaj na perfekcyjny zbiór
• Wybierz 1-2 wyniki – lepiej mieć proste, działające oceny niż skomplikowane, które nie działają
• Przetestuj w Playground – sprawdź czy wszystko działa przed automatyzacją

Implementacja w produkcji

• Dodaj logowanie – użyj wrap OpenAI lub podobnego jednoliniowego rozwiązania
• Skonfiguruj ocenianie online – zacznij od niskiego współczynnika próbkowania (1-5%)
• Ustaw alerty regresji – określ punkt odniesienia i progi dla powiadomień
• Stwórz widoki niestandardowe – przygotuj widoki dla różnych członków zespołu

Optymalizacja i skalowanie

• Włącz przegląd ludzki – dodaj możliwość ręcznej weryfikacji przez ekspertów
• Implementuj opinie użytkowników – kciuk w górę/w dół w aplikacji dla użytkowników
• Iteruj nad zbiorami danych – dodawaj prawdziwe przypadki z produkcji
• Optymalizuj wyniki – używaj matrycy decyzyjnej do określania, co poprawiać
• Zautomatyzuj w CI/CD – włącz ewaluacje do potoku wdrożeniowego

Monitoring i konserwacja

• Regularnie przeglądaj dzienniki – sprawdzaj widoki niestandardowe i alerty
• Aktualizuj zbiory danych – dodawaj nowe przypadki brzegowe z produkcji
• Testuj LLM as judge – weryfikuj czy automatyczne oceny pasują do ludzkich
• Śledź metryki biznesowe – mierz wpływ na koszty, czas developmentu, jakość

Perspektywy rozwoju

Carlos wspominał o nadchodzącym narzędziu „Loop”: „Jeden do dwóch tygodni od wypuszczenia pierwszej wersji. Będzie robiło dokładnie to, co mówisz – pomoże optymalizować prompty i poprawić ewaluacje”.

Loop będzie miał dostęp do poprzednich wyników podczas optymalizacji, dzięki czemu będzie rozumiał, kiedy zmiana jest lepsza niż poprzednia. To przepływ pracy agenta z dostępem do narzędzi, jednak potrafiący iterować nad promptem i przeprowadzać eksperymenty.

Rzeczywistość czasowa rozwoju narzędzi AI

Carlos przedstawiał ciekawy wgląd w proces rozwoju samego BrainTrust: „Ankur, nasz CEO, mówił o procesie dojścia do punktu, gdzie byliśmy podekscytowani wypuścić coś takiego. Wcześniej modele nie działały na poziomie, którego potrzebowaliśmy. Co kilka miesięcy uruchamiał nowy test porównawczy na tym konkretnym przypadku użycia. I nie było to do zeszłego miesiąca, że model w końcu osiągnął to oczekiwanie”.

Ta obserwacja pokazuje kilka kluczowych aspektów rzeczywistości developmentu AI: nawet doświadczeni zespoły czekają miesiącami na odpowiednią jakość modeli, regularne testy porównawcze są niezbędne, nie każdy model lub funkcja jest gotowa od razu, a systematyczne testowanie pomaga określić właściwy moment wdrożenia do produkcji.

Kluczowy insight

Słaby AI czy słabe ewaluacje?

Standardowo myślimy: Gdy otrzymujemy niski score z naszego systemu AI, problem leży w modelu, promptach lub danych treningowych – trzeba poprawić „AI”.

W praktyce okazuje się, że: Często problem tkwi w samym systemie oceniania. Jak wyjaśniał Carlos w matrycy decyzyjnej: „Jeśli myślisz, że to dobry wynik, ale ma niski score, to sygnał, że musisz poprawić swoje ewaluacje. Jeśli to zły wynik, ale wysoki score – to samo, nie pasuje do tego, co człowiek by pomyślał”.

Dlaczego to jest istotne: Zespoły tracą tygodnie na dostrajanie modeli i promptów, podczas gdy prawdziwym problemem są źle skonfigurowane metryki oceny. Doug podkreślał: „To nie jest ocena na wyczucie. To nie jest 'tak, myślę, że to wygląda dobrze’. To są dane za tym”.

Test na jutro: Następnym razem gdy Twój system AI dostanie niski score, zamiast od razu poprawiać prompt lub model, spróbuj przejść przez matrycę decyzyjną – zapytaj człowieka czy wynik rzeczywiście jest zły, i sprawdź czy problem nie leży w samym systemie oceniania.