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
Dodaj komentarz
Musisz się zalogować, aby móc dodać komentarz.