TL;DR

Data flywheel jest kluczem – po wdrożeniu zaczyna się prawdziwa praca: zbieranie informacji zwrotnej, analiza błędów, budowanie evals
Instrumentuj kod kompleksowo – loguj wywołania narzędzi, błędy, przetwarzanie wstępne i końcowe, nie tylko completion calls
Ukryta informacja zwrotna przewyższa jawną – użytkownicy rzadko klikają przyciski oceny, jednak ich zachowania przekazują cenne sygnały
Hierarchia evals przypomina piramidę testów – unit tests u podstawy, trajectory evals w środku, testy A/B na szczycie
Reasoning models potrafią wyjaśniać porażki – świetnie analizują przyczyny błędów na podstawie śladów wykonania
Wskaźniki to nie cel sam w sobie – optymalizacja powinna koncentrować się na satysfakcji użytkowników, nie na wynikach laboratoryjnych
Nie stosuj mocków w środowisku evals – zamiast tego stwórz syntetyczną kopię rzeczywistych warunków użytkownika

Poniższe notatki powstały na podstawie prezentacji Rafała Willińskiego i Vitora Balocco z Zapier, którzy prezentowali swoje dwuletnie doświadczenie w budowaniu platformy AI agents. Wszystkie przemyślenia, obserwacje i wnioski pochodzą od prelegentów.

Zapier Agents – ewolucja automatyzacji

Zapier Agents stanowi ewolucję klasycznej automatyzacji. Zamiast budować przepływ pracy za pomocą schematów i strzałek, użytkownik opisuje swój cel. System proponuje odpowiednie narzędzia i wyzwalacze, które po aktywacji teoretycznie automatyzują całe procesy biznesowe.

Willinski podkreślił kluczową lekcję z dwuletniego rozwoju projektu. Budowanie dobrych AI agents jest trudne, ale stworzenie dobrej platformy dla użytkowników nietechnicznych okazuje się jeszcze trudniejsze. Sztuczna inteligencja charakteryzuje się nieprzewidywalnością, jednak użytkownicy są jeszcze bardziej nieprzewidywalni w swoich działaniach.

Pułapka szybkiego prototypowania

Wielu deweloperów wyobraża sobie sukces w podobny sposób. Pobierają LangChain, dostosowują prompt, dodają kilka narzędzi i testują rozwiązanie w trybie czatu. Gdy system wydaje się działać, wdrażają go i oczekują zysków.

Willinski ostrzegł przed takim podejściem. Rzeczywistość zawiera zaskakująco dużo szczegółów, dlatego budowanie probabilistycznego oprogramowania różni się od tradycyjnego rozwoju. Prototyp stanowi jedynie punkt wyjścia, a nie zakończenie procesu.

Po wdrożeniu produktu odpowiedzialność przesuwa się na konstrukcję pętli danych (data flywheel).

Data flywheel – mechanizm ciągłego doskonalenia

Balocco wyjaśnił mechanizm, który stał się fundamentem ich strategii:

Użytkownicy rozpoczynają korzystanie z produktu
Zespół zbiera informacje zwrotne i analizuje wzorce użytkowania
Tworzy dodatkowe evals i identyfikuje tryby awarii
Rozwija nowe funkcje, co prowadzi do poprawy produktu
Przybywa więcej użytkowników, co generuje kolejne awarie i potrzebę nowych funkcji
Cykl się powtarza

Ta zmiana myślenia ma fundamentalne znaczenie. Po wdrożeniu nie można oczekiwać zysków – należy systematycznie uczyć się z każdej interakcji użytkowników.

Instrumentacja kodu – fundament zrozumienia systemu

Pierwszy krok wymaga odpowiedniej instrumentacji. Większość zespołów rejestruje jedynie wywołania completion – to jednak niewystarczające podejście.

Balocco zalecił rejestrowanie znacznie szerszego zakresu danych:

Completion calls (podstawa, którą większość już stosuje)
Wywołania narzędzi – wszystkie wywołania tools
Błędy z wywołań narzędzi – przyczyny niepowodzeń
Kroki przetwarzania wstępnego – transformacje danych wejściowych
Kroki przetwarzania końcowego – transformacje wyników
Dane w formacie runtime – dokładnie tak, jak pojawiają się podczas działania

Cel polega na zapewnieniu powtarzalności uruchomienia dla celów ewaluacji. Jeśli dane są rejestrowane w tej samej formie co podczas działania, łatwiej później przekształcić ślad w uruchomienie eval.

Jawna versus ukryta informacja zwrotna

Klasyczne przyciski pozytywnej i negatywnej oceny charakteryzują się wysokim sygnałem, jednak niewielu użytkowników z nich korzysta. Balocco podzielił się odkryciem zespołu Zapier: należy prosić o informację zwrotną we właściwym kontekście.

Przykład z praktyki: po zakończeniu działania agenta (nawet testowego) pokazują wezwanie do działania w prawym dolnym rogu z pytaniem „Czy to uruchomienie zrobiło to, czego oczekiwałeś?” Ta niewielka zmiana znacząco zwiększyła liczbę przekazywanych opinii.

Ukryta informacja zwrotna w zachowaniach użytkowników

Ponieważ jawna informacja zwrotna pozostaje rzadkością, konieczne jest głębsze poszukiwanie sygnałów. Balocco wymienił łatwo dostępne możliwości:

Pozytywne sygnały:

Włączenie agenta po testowaniu – silny pozytywny sygnał
Skopiowanie odpowiedzi modelu (nawet OpenAI monitoruje to w ChatGPT)
Zakończenie działania bez dodatkowych pytań

Negatywne sygnały:

Wyrażenia frustracji jak „przestań się obijać” i inne
Ponowne zadanie tego samego pytania różnymi słowami
Dodatkowe wiadomości powtarzające poprzednie pytanie
Zaskakująco częste przekleństwa w danych

Zespół Zapier eksperymentuje z modelami językowymi do wykrywania i grupowania frustracji użytkowników w cotygodniowych raportach. Wymaga to jednak znacznego dostrojenia, aby model rozumiał frustrację w kontekście konkretnego produktu.

Tradycyjne wskaźniki użytkowników

Balocco przypomniał o często pomijanym aspekcie: nie należy zapominać o tradycyjnych wskaźnikach użytkowników. Konieczne jest znalezienie wskaźników istotnych dla biznesu i nauka ich śledzenia.

Praktyczny przykład: przegląd klientów, którzy odeszli w ostatnich siedmiu dniach, oraz analiza ich ostatniej interakcji z produktem przed odejściem. To prawdopodobne źródło cennych sygnałów o przyczynach problemów.

Narzędzia LLMOps i własne rozwiązania

Willinski zalecił kupowanie lub budowanie oprogramowania LLMOps. Pojedyncze uruchomienie agenta składa się z kaskadowych interakcji: wywołań LLM, zapytań do bazy danych, wywołań narzędzi i wywołań REST. Każdy element może stanowić źródło awarii.

Zapier stosuje oba podejścia: kupuje gotowe rozwiązania i buduje własne narzędzia wewnętrzne. Budowanie własnych narzędzi przy użyciu Cursor i Claude przynosi masywne korzyści:

Kontekst specyficzny dla domeny – lepsze zrozumienie danych w kontekście produktu
Tworzenie eval jednym klikiem – każdy interesujący przypadek natychmiast staje się evalem
Szybkość rozwoju – dzisiejsze narzędzia AI sprawiają, że budowanie własnych rozwiązań jest łatwiejsze

Kluczowa zmiana myślenia: jak podkreślił Willinski, tworzenie evals z ciekawych przypadków powinno stać się instynktem. Po zauważeniu czegoś interesującego wystarczy jeden klik, aby utworzyć eval.

Klastrowanie trybów awarii i automatyczna mapa drogowa

Po zrozumieniu pojedynczych uruchomień nadchodzi czas na analizę w skali. Agregacje, klastrowanie i kategoryzowanie trybów awarii oraz interakcji pozwalają dostrzec szerszy obraz.

Zaczyna się ujawniać, które narzędzia zawodzą najczęściej i które interakcje są najbardziej problematyczne. To tworzy automatyczną mapę drogową – staje się jasne, gdzie aplikować czas i wysiłek dla maksymalnej poprawy.

Zapier eksperymentuje z reasoning models do wyjaśniania błędów. Po dostarczeniu im śladu wykonania, danych wejściowych i instrukcji okazują się całkiem skuteczne w znajdowaniu podstawowej przyczyny. Nawet jeśli nie znajdą bezpośredniej przyczyny, skierują uwagę na coś naprawdę interesującego, co może pomóc w znalezieniu źródła problemu.

Hierarchia evals – piramida testów dla AI

Unit test evals – podstawa systemu

Prognozują stan N+1 z bieżącego stanu. Sprawdzają, czy następny stan to konkretne wywołanie narzędzia, czy parametry wywołania są poprawne, czy odpowiedź zawiera określone słowo kluczowe.

Świetnie nadają się na początek – są łatwe do dodania i pomagają wypracować nawyk patrzenia na dane. Balocco ostrzegł jednak: nie należy przekształcać każdej pozytywnej informacji zwrotnej w eval. Powinny służyć do wspinaczki wzgórza konkretnych trybów awarii.

Trajectory evals – ocena złożonych scenariuszy

Pozwalają agentowi działać do końcowego stanu z oceną wszystkich wywołań narzędzi i artefaktów generowanych po drodze. Można je łączyć z LLM as judge.

Wyzwania: trudniejsze do konfiguracji, wolniejsze (do godziny), wymagają syntetycznej kopii środowiska użytkownika. Zapier świadomie nie stosuje mocków środowiska – w przeciwnym razie otrzymuje się dane, które nie odzwierciedlają rzeczywistości.

Testy A/B – ostateczna weryfikacja

Pięć procent ruchu kieruje się do nowego modelu lub promptu, podczas gdy monitoruje się informacje zwrotne, aktywację i utrzymanie użytkowników. Ostatecznym sędzią są użytkownicy, nie wskaźniki laboratoryjne.

Pułapka overfittingu w unit tests

Zapier odkrył problem z nadmiernym poleganiem na unit test evals. Nowe, obiektywnie silniejsze modele działały gorzej w ich wewnętrznych benchmarkach.

Willinski wyjaśnił przyczynę: unit tests są szczegółowe, przez co trudno za szczegółami dostrzec całość. Różne modele mają różne sposoby osiągania tego samego celu, a unit tests karzą alternatywne ścieżki.

Przykład z analizy: Claude to „zdecydowany wykonawca”, podczas gdy Gemini „dużo gada” – zadaje dodatkowe pytania, potrzebuje pozytywnych potwierdzeń, a czasem halucynuje nieprawidłowe struktury JSON. Reasoning model pomógł Zapier automatycznie zrozumieć te różnice – przy użyciu narzędzi takich jak BrainTrust z MCP (Model Context Protocol) można zadać pytanie: „spójrz na to uruchomienie, spójrz na to uruchomienie i powiedz mi, co faktycznie różni nowy model”.

LLM as judge – scoring oparty na rubrikach

LLM as judge kusi łatwością, jednak Balocco ostrzegł: należy upewnić się, że sędzia ocenia poprawnie. Można wprowadzić subtelne uprzedzenia przez małe rzeczy, które łatwo przeoczyć – nawet drobne szczegóły w promptach lub danych mogą wpłynąć na oceny.

Zapier eksperymentuje ze scoring opartym na rubrikach. Każdy wiersz w zbiorze danych ma ręcznie wykonane rubryki opisane w języku naturalnym. Przykład: „Czy agent zareagował na nieoczekiwany błąd z Calendar API i spróbował ponownie?”

Kiedy używać:

Przegląd wysokopoziomowy możliwości systemu
Benchmarking nowych modeli
Złożone kryteria trudne do zakodowania w sprawdzenia binarne

Wskaźniki to nie cel – użytkownik jest celem

Willinski zakończył kluczową myślą: nie należy obsesyjnie koncentrować się na wskaźnikach. Gdy dobry wskaźnik staje się celem, przestaje być dobrym wskaźnikiem.

Zbliżanie się do 100% wyników w zbiorze danych eval nie oznacza dobrej pracy. Oznacza, że zbiór danych przestał być wymagający. Nie posiadamy jeszcze AGI.

Zapier dzieli zbiór danych na dwa pule:

Zbiór regresji – zapewnienie, że zmiany nie niszczą istniejących przypadków użycia
Zbiór aspiracyjny – niezwykle trudne rzeczy, jak wykonanie 200 wywołań narzędzi z rzędu

Kluczowy insight

Paradoks wysokich wyników

Standardowo myślimy: Im wyższe wyniki w evals, tym lepszy system AI i bliżej sukcesu.

W praktyce okazuje się, że: Wysokie wyniki w evals często oznaczają overfitting do konkretnego modelu i gorszą wydajność w rzeczywistych warunkach. Zapier odkrył, że obiektywnie silniejsze modele działały gorzej w ich benchmarkach – ponieważ evals były zahardkodowane na jeden sposób myślenia.

Dlaczego to jest istotne: Większość zespołów próbuje maksymalizować wskaźniki, nie zdając sobie sprawy, że zbliżanie się do 100% może oznaczać, że zbiór danych przestał być wymagający. Różne modele osiągają te same cele różnymi ścieżkami, a sztywne evals penalizują tę różnorodność.

Test na jutro: Następnym razem podczas wdrażania nowego modelu, zamiast szukać wyższych wyników w istniejących evals, przetestuj go z prawdziwymi użytkownikami na małej próbie i sprawdź, czy satysfakcja użytkowników wzrasta mimo potencjalnie gorszych wyników w testach.

Ten wpis powstał na podstawie prezentacji „Turning Fails into Features: Zapier’s Hard-Won Eval Lessons” dostępnej pod adresem: https://www.youtube.com/watch?v=blrovBxxN9o&t=3s

Tag: Evals

Od porażek do funkcji – lekcje Zapier z budowania AI agents #EN183