Te notatki powstały na podstawie prezentacji „Evals 101” autorstwa Doug Guthrie, Solutions Engineer w BrainTrust. Wszystkie przedstawione przemyślenia, obserwacje i strategie pochodzą od prelegenta i jego zespołu.
TL;DR
- Evale to strukturalne testy sprawdzające jakość, niezawodność i poprawność systemów AI
- Trzy kluczowe komponenty: task (zadanie), zbiór danych i systemy oceniania
- Offline evale służą testowaniu przed produkcją, online evale monitorują działanie w czasie rzeczywistym
- Flywheel effect – połączenie danych z produkcji z testami offline tworzy samodoskonalący się cykl
- Human in the loop jest niezbędny dla jakości – łączy automatyzację z ludzką weryfikacją
- Rozpocznij od punktu wyjścia – nie czekaj na perfekcyjny zbiór danych, buduj iteracyjnie
Dlaczego evale są kluczowe dla rozwoju AI
Doug Guthrie (który przyznaje, że to jego trzeci tydzień w firmie jako solutions engineer) podkreśla fundamentalne znaczenie evalów w budowie aplikacji AI. Jednak najważniejsze pytanie brzmi: gdy zmieniasz model, prompt czy inne elementy aplikacji – jak sprawdzić, czy system stał się lepszy, czy gorszy?
Bez evalów rozwój aplikacji AI staje się procesem opartym na intuicji. Guthrie zauważa, że niedeterministyczne wyniki dużych modeli językowych tworzą wyzwanie. W rezultacie budowa niezawodnej aplikacji produkcyjnej bez strukturalnych testów staje się bardzo trudna.
Evale to nie tylko obrona – to atak. Ankur Goyal, CEO BrainTrust, opisuje je jako narzędzie ofensywne, które tworzy rygor wokół procesu rozwoju. Dlatego zapewnia, że budujemy rzeczy nadające się do produkcji.
BrainTrust to kompleksowa platforma developerska dla produktów AI. Ciekawy kontekst: Ankur w swoich dwóch poprzednich firmach budował BrainTrust od zera – tam znalazł pomysł na to, że ludzie naprawdę potrzebują takiego narzędzia. W rezultacie platforma już ma wielu klientów w produkcji, od startupów po duże korporacje.
Trzy filary evalów
Task – zadanie do oceny
Task to kod lub prompt, który chcemy ewaluować. Według Guthrie może to być prosty prompt lub złożony workflow agentowy z dostępem do narzędzi. Jedyne wymaganie to dane wejściowe i wyjściowe.
BrainTrust pozwala definiować prompty z dostępem do narzędzi, wykorzystywać mustache templating dla zmiennych i tworzyć multi-turn konwersacje. Najnowsza funkcja w beta umożliwia nawet łączenie promptów w workflow, gdzie wynik jednego staje się wejściem kolejnego.
Praktyczny przykład: Guthrie pokazuje aplikację generującą changelog z commitów GitHub. Aplikacja pobiera URL repozytorium, znajduje najnowsze commity i tworzy changelog. To idealny kandydat na eval – można testować różne modele, prompty i sprawdzać jakość generowanych changelogów.
Zbiór danych – rzeczywiste przykłady
To kolekcja przypadków testowych, na których uruchamiamy nasze zadanie. Guthrie radzi: „Po prostu zacznij i iteruj”. Nie musisz tworzyć idealnego zbioru danych na początku – buduj punkt wyjścia, który możesz później rozwijać.
Wymagane są tylko dane wejściowe, jednak możesz dodać oczekiwane wyniki dla deterministycznych porównań. Dodatkowo metadata dla filtrowania oraz struktura zgodna z logami produkcyjnymi okazują się bardzo pomocne.
Systemy oceniania – logika ewaluacji
Istnieją dwa główne typy systemów oceniania. LLM as a judge – model ocenia wynik na podstawie kryteriów. Code-based scores – bardziej heurystyczne, binarne sprawdzenia napisane w TypeScript lub Python.
Guthrie dzieli się kluczowymi wskazówkami klientów BrainTrust:
- Używaj lepszych modeli do scoringu, nawet jeśli aplikacja korzysta z tańszych
- Dziel scoring na konkretne obszary – zamiast jednego scorera dla „wszystkiego”, stwórz osobne dla accuracy, formatting, correctness
- Testuj swoje scory w playground przed użyciem
- Unikaj przeciążania scorera zbyt dużą ilością kontekstu
Auto Evals to gotowy pakiet scorów, który można zainstalować w projekcie. Zawiera zarówno LLM-as-judge jak i code-based scores, pozwalając na natychmiastowy start. Jak zauważa Guthrie, nawet prosty Levenshtein score może być dobrym punktem wyjścia – tworzy punkt odniesienia z minimalnym wysiłkiem deweloperskim.
Offline vs online evale
Offline evale – przed produkcją
To miejsce iteracji i rozwiązywania problemów przed wdrożeniem. Guthrie pokazuje, jak w BrainTrust Playground można szybko porównywać różne modele, prompty i konfiguracje na jednym ekranie.
Przełomowa funkcja Loop (właśnie wydana) wykorzystuje AI do optymalizacji promptów. System ma dostęp do wyników evalów i rozumie, kiedy zmiany poprawiają wydajność. Automatycznie modyfikuje prompt, uruchamia eval i sprawdza wyniki relatywnie do zdefiniowanych scorów. To jak mieć asystenta, który iteruje za Ciebie – interfejs podobny do cursor ale dla evalów.
Online evale – monitorowanie produkcji
Online scoring pozwala uruchamiać te same oceny na rzeczywistym ruchu. Możesz ustawić sampling rate, aplikować scory na konkretne spany zamiast tylko głównego trace’a i tworzyć alerty przy spadku jakości.
Kluczowe jest to, że te same scory działają offline i online. W rezultacie tworzysz spójny system oceny od developmentu do produkcji.
Flywheel effect – samodoskonalący się cykl
Guthrie wielokrotnie podkreśla „flywheel effect” jako kluczową wartość platformy. Ten mechanizm łączy wszystkie elementy w samodoskonalący się cykl:
- Logi z produkcji trafiają do BrainTrust z pełną instrumentacją
- Zespół przegląda problematyczne przypadki używając custom views
- Wybrane logi są dodawane do zbiorów danych offline jednym kliknięciem
- Ulepszone evale wpływają na następne iteracje developmentu
- Nowe wersje trafiają do produkcji z lepszą jakością
Ten cykl skraca czas developmentu i zwiększa jakość aplikacji. To różnica między chaotycznym rozwojem a systematycznym doskonaleniem.
Integracja z kodem
BrainTrust oferuje SDK w Python i TypeScript. Możesz definiować wszystkie komponenty w kodzie i pushować je do platformy, lub pracować hybrydowo – kod + UI.
# Prosty początek - wrap klienta
client = braintrust.wrap_openai(OpenAI())
# Zaawansowane - custom spany
@braintrust.trace
def my_function():
# Twoja logika z pełną instrumentacją
Wielu klientów uruchamia evale w procesie CI/CD. W dokumentacji BrainTrust znajdziesz przykład GitHub Action, który automatycznie sprawdza, czy zmiany poprawiają czy pogarszają wyniki.
Integracja z platformami ML: Wszystkie dane z BrainTrust są dostępne via SDK. Jeden z klientów zbudował własny UI na komponenty SDK, wyciągając eksperymenty i dane do własnych dashboardów. To pokazuje elastyczność platformy dla zespołów z istniejącą infrastrukturą ML.
Monitorowanie produkcji
Instrumentacja aplikacji
Rozpocznij od prostego wrappingu klienta LLM – od razu dostajesz metryki kosztów, tokenów i czasu odpowiedzi. Następnie dodaj trace decoratory na funkcje, a w końcu custom spany z dokładnym kontrolowaniem danych wejściowych i wyjściowych.
Przykład szczegółowej instrumentacji: W swojej changelog aplikacji Guthrie pokazuje, jak system loguje każdy krok – pobieranie commitów z GitHub, identyfikowanie najnowszego release’u, fetchowanie commitów od tego release’u, a potem generowanie changelog. Na każdym poziomie możesz dodać scorer – czy GitHub API zwróciło sensowne dane, czy release detection był prawidłowy, czy final changelog jest wysokiej jakości.
Online scoring i alerty
Platforma pozwala konfigurować automatyczne uruchamianie scorów na incoming logs z sampling rate dla optymalizacji kosztów. Early regression alerts powiadamiają gdy jakość spada poniżej progu.
Możesz grupować wyniki według modeli lub wersji i monitorować na poziomie individual spanów. To daje precyzyjną kontrolę nad jakością każdego komponentu.
Przykład zaawansowanego scoringu: Guthrie pokazuje aplikację conversational analytics, gdzie użytkownik zadaje pytanie i otrzymuje dane. Aplikacja przechodzi przez kilka kroków: rephrasing pytania użytkownika, wykrywanie intencji, generowanie odpowiedzi. Każdy krok można scorować osobno – jeśli LLM źle przeparafrazuje pytanie, wszystko dalej będzie złe. Dlatego scorer na poziomie rephrasing span może być kluczowy dla całej aplikacji.
Human in the loop
Guthrie dzieli się szczegółowymi spostrzeżeniami z warsztatu, gdzie Sarah z Notion opisywała ich organizację human review. W Notion stworzyli specjalną rolę – hybrydę product managera i LLM specialisty, która zajmuje się human review. To pokazuje, jak poważnie traktują jakość AI w production.
W mniejszych organizacjach podejście jest bardziej elastyczne – inżynierowie również uczestniczą w human review. Kluczowe jednak jest stworzenie rubryk dla oceniających, żeby różni ludzie nie scorowali zupełnie inaczej.
Human review to interfejs do przeglądania logów z możliwością dodawania ocen i szybkiego przełączania do trybu review. Informacja zwrotna użytkowników to thumbs up/down od końcowych użytkowników, które automatycznie trafiają do logów.
Praktyczne szczegóły: klawisz R otwiera human review mode z uproszczonym interfejsem. Możesz konfigurować niestandardowe ludkie scory recenzji i dodawać je do konkretnych logów. Wszystkie prompty w platformie są version controlled, więc masz pełną historię zmian.
Kluczowe jest tworzenie custom views – filtrów pozwalających skupić się na istotnych przypadkach. Gdy informacja zwrotna użytkownika = 0, chcesz szybko zobaczyć co poszło nie tak.
Praktyczne wyzwania i rozwiązania
Z sesji Q&A wynikają praktyczne wyzwania, które warto mieć na uwadze:
A/B testing w produkcji: Możesz uruchamiać różne modele jednocześnie i porównywać ich wydajność. BrainTrust pozwala grupować wyniki według modeli, co ułatwia analizę.
Evals na evals: Jak sprawdzić, czy LLM-as-judge rzeczywiście dobrze ocenia? Niektórzy klienci robią „evals on evals” – sprawdzają uzasadnienia za ocenami i tworzą meta-evals dla swoich systemów oceniania.
Zgodność z przepisami i zastosowania rządowe: Jeden z uczestników pracuje z rządem, który wymaga udokumentowanych poziomów accuracy przed wdrożeniem. Offline evale z tysiącami pytań od ekspertów merytorycznych są idealnym narzędziem do stworzenia takiej dokumentacji i budowania zaufania do systemu AI.
Praktyczne wskazówki
Jak zacząć
Stwórz punkt wyjścia zamiast czekać na perfekcyjny zbiór danych. Zacznij od prostego Levenshtein score, potem iteruj. Wykorzystaj Auto Evals – gotowe scory z BrainTrust, które pozwalają ruszyć od razu.
Matryca poprawy
Guthrie przedstawia prostą matrycę decyzyjną:
- Dobry wynik + niski score = popraw evale
- Zły wynik + wysoki score = popraw evale lub scoring
- Dobry wynik + wysoki score = wszystko działa
- Zły wynik + niski score = popraw aplikację
Współpraca zespołowa
Platforma umożliwia współpracę różnych ról. Developerzy tworzą w kodzie, PM-y iterują w UI, domain experts robią human review. Wszyscy pracują na tych samych danych i eksperimentach.
Checklist: Pierwszy projekt z evalami
📋 Fundamenty (Tydzień 1-2)
- Zdefiniuj jeden konkretny task do ewaluacji
- Stwórz zbiór danych z 15-30 przykładami (jakość > ilość)
- Wybierz 2-3 proste scory i przetestuj w playground
- Skonfiguruj podstawowe środowisko i logowanie
- Uruchom pierwszy offline eval i przeanalizuj wyniki
🔧 Produkcja (Tydzień 3-4)
- Dodaj instrumentację do aplikacji produkcyjnej
- Skonfiguruj online scoring z sensownym sampling
- Ustaw regression alerts dla kluczowych metryk
- Stwórz custom views dla problematycznych przypadków
- Włącz informację zwrotną użytkowników i human review process
🔄 Flywheel (Miesiąc 2+)
- Regularnie dodawaj production logs do zbiorów danych
- Iteruj na scorach bazując na real-world data
- Eksperymentuj z różnymi modelami i konfiguracjami
- Automatyzuj proces przez CI/CD integration
- Mierz długoterminowe trendy jakości i kosztów
Podsumowanie
Evale według Doug Guthrie to nie opcjonalne „nice-to-have”, ale konieczność dla każdej poważnej aplikacji AI. Kluczem jest rozpoczęcie od prostego punktu wyjścia i stopniowe doskonalenie przez flywheel effect łączący offline development z online monitoring.
Najważniejsze to po prostu zacząć. Jak podkreśla Guthrie – nie musisz mieć idealnego zbioru danych czy scorów na start. Zbuduj fundament, który pozwoli Ci iterować i doskonalić aplikację w oparciu o dane, a nie intuicję.
Kluczowy insight
Tani model do zadań, drogi do oceny
Standardowo myślimy: Jeśli budżet jest ograniczony, używaj wszędzie tańszego modelu. Jeśli jakość jest priorytetem, używaj wszędzie najdroższego modelu.
W praktyce okazuje się, że: Optymalna strategia to hybrid – tańszy model (np. GPT-3.5) do wykonywania zadań w aplikacji, ale droższy model (np. GPT-4) do scorowania i oceny jakości w evalach. Klienci BrainTrust masowo stosują tę praktykę.
Dlaczego to jest istotne: Scorowanie potrzebuje najwyższej jakości rozumowania, żeby prawidłowo ocenić wynik. Samo zadanie może być prostsze i wykonalne przez tańszy model, ale jego ocena wymaga sofistykowanego myślenia.
Test na jutro: Następnym razem gdy konfigurujesz evale, zamiast używać tego samego modelu do zadań i scorowania, spróbuj tańszego modelu do zadań i droższego do oceny, i sprawdź czy dostajesz lepszą relację jakość/koszt.
Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Materiał został opracowany na podstawie transkryptu prezentacji „Evals 101” Doug Guthrie z BrainTrust.
Dodaj komentarz
Musisz się zalogować, aby móc dodać komentarz.