TL;DR

Ewaluacja zastąpiła prompt engineering jako główne wyzwanie w budowaniu agentów AI
Ground truth wymaga współpracy z ekspertami domenowymi – bez tego nie zbudujesz niezawodnego systemu
Praktyczny przykład: agent do analizy kontraktów potrzebuje prawników do określenia poprawnych odpowiedzi
Accuracy, precision i recall to podstawowe metryki, jednak benchmarki ewoluują wraz z rozwojem modeli
Klienci skarżą się dopiero gdy system nie działa – systematyczna ewaluacja zapobiega takim sytuacjom
Product managerowie muszą inwestować w domenową ekspertyzę już na etapie budowania ewaluacji
Branżowe standardy różnią się znacząco, dlatego wymagają ciągłego dostosowywania

Dlaczego teraz wszyscy mówią o ewaluacji

Prowadzący sesję zwrócił uwagę na istotną zmianę w branży AI. YC niedawno stwierdziło, że koroną aplikacji AI nie są już prompty, ale ewaluacje. To jednak radykalna zmiana myślenia w całej branży.

Główne wyzwanie? Ustanawianie North Star metrics i quarterly goals dla systemów non-deterministycznych, których nie można zmierzyć prostym „tak/nie”. Prowadzący wspomniał również o auto evaluators – koncepcji „AI oceniającego AI” – choć ten temat miał być rozwinięty później w sesji.

Historia znajomego z San Francisco doskonale ilustruje problem. 20-letni weteran Microsoftu zbudował agenta, który analizuje 1 terabajt danych firmowych. Wszystko działało świetnie do momentu, gdy klient się poskarżył.

„Twój agent nie działa” – usłyszał od klienta. Dopiero wtedy poprosił o pokazanie oczekiwanych odpowiedzi, w rezultacie klient musiał stać się jego ewaluatorem. Po otrzymaniu feedback’u siedział z Cursorem i naprawiał system, myśląc że to „magiczne” rozwiązanie.

To klasyczny problem „aha moment” – product manager myśli, że rozwiązał całą kwestię po naprawieniu jednej skargi klienta. Tymczasem ktoś, kto zatrudnia PM z odpowiednim podejściem, tworzy systematyczne ground truth od początku.

Praktyczny przykład: agent do analizowania kontraktów

Prowadzący przedstawił konkretny case study. Agent analizuje kontrakty prawne, następnie automatycznie wyciąga kluczowe warunki:

Klauzule odnowienia – terminy i warunki przedłużania umów
Terminy wypowiedzenia – okresy notice wymagane do rozwiązania
Ograniczenia odpowiedzialności – maksymalne kwoty i wyłączenia
Warunki indemnifikacji – kto za co odpowiada w przypadku roszczeń

System pokazuje nie tylko wyniki, ale też wskazuje miejsca w dokumencie, z których pochodzi informacja. Cały proces zajmuje 4 minuty zamiast godzin pracy prawnika. Agent automatycznie kategoryzuje typ kontraktu przed analizą, a także pozwala na dostosowanie listy poszukiwanych warunków.

Prowadzący podkreślił: „Prosta aplikacja. Każdy może zapamiętać ten przykład”. To „wystarczająco dobry agent” – system rozwiązujący konkretny problem biznesowy.

Kluczowe pytanie pozostaje jednak niezmienne: jak sprawdzić, czy agent działa poprawnie?

Jak ustalić ground truth dla Twojego agenta

Jedna z uczestniczek sesji zaproponowała rozwiązanie: porównanie z branżowymi standardami. Prowadzący rozwinął jednak tę myśl, zwracając uwagę na fundamentalny problem: „nie ma standardowych benchmarków na wysokim poziomie” dla większości przypadków użycia AI.

W przypadku analizy kontraktów ground truth oznacza współpracę z prawnikami na każdym etapie. Eksperci muszą określić, które warunki są kluczowe dla każdego typu umowy, a także jakie są poprawne wartości dla każdego warunku.

Prowadzący był jednoznaczny: „Bez ekspertyzy domenowej nie zbudujesz agentów. Nie możesz zbudować ewaluacji bez domenowej wiedzy.”

Checklist: jak ustalić ground truth (na podstawie wskazówek z sesji)

□ Zidentyfikuj ekspertów domenowych w Twojej branży
□ Zbierz reprezentatywne przykłady dokumentów do analizy
□ Wspólnie określ kluczowe elementy do ekstrakcji
□ Ustal poprawne odpowiedzi dla każdego przykładu
□ Zdokumentuj źródła i uzasadnienia
□ Zaplanuj proces aktualizacji standardów

Product manager musi zatrudnić prawników lub pozyskać benchmarki już na etapie projektowania systemu. W przeciwnym razie czeka go reactive approach zamiast proactive.

Metryki które faktycznie mają sens

Podstawowe metryki ewaluacji agentów AI to accuracy, precision i recall. Prowadzący wyjaśnił ich praktyczne zastosowanie podczas sesji.

Accuracy pokazuje, ile razy agent podał poprawną odpowiedź względem ground truth. Precision określa natomiast, ile znalezionych elementów było rzeczywiście poprawnych. Recall mierzy z kolei, ile wszystkich istotnych elementów agent faktycznie znalazł.

Praktyczny przykład: jeśli agent znalazł 10 klauzul, a 8 było poprawnych → precision = 80%. Jeśli jednak w dokumencie było 12 klauzul, a agent znalazł 8 → recall = 67%.

Jedna z uczestniczek zwróciła uwagę na ważny aspekt: „Benchmarki ewoluują wraz z modelami AI i zawsze się zmieniają.”

Wyzwania z benchmarkami branżowymi

Każda branża ma własne standardy. To co działa w finansach, nie sprawdzi się w healthcare czy legal tech. Prowadzący zgodził się z obserwacją uczestniczki o ewolucji benchmarków.

Standardy zmieniają się wraz z rozwojem modeli AI, zmianami w przepisach branżowych, a także nowymi wymaganiami klientów. Dostępność lepszych danych także wpływa na jakość ground truth, dlatego proces wymaga ciągłego monitorowania.

Ewaluacja to proces ciągły, nie jednorazowe zadanie. Jak zauważyła jedna z uczestniczek – „to running metric, który zawsze musimy mierzyć względem tego, co chcemy zmierzyć”.

Narzędzia wspierające ewaluację

Prowadzący wspomniał o różnych możliwościach dostępnych na rynku. Copilot Studio nie wspiera ewaluacji, jednak Foundry ma wbudowaną funkcjonalność AI evaluation. Azure SDK również oferuje odpowiednie narzędzia do tego celu.

Co robić jako product manager

Kluczowe wnioski z sesji dla product managerów koncentrują się wokół trzech głównych obszarów: proaktywności, ekspertyzy domenowej oraz systematyczności.

Zatrudnij ekspertów domenowych już na etapie planowania. W przykładzie z kontraktami to prawnicy, w finansach – analitycy, w medycynie – lekarze. Bez tej ekspertyzy nie zdefiniujesz jednak poprawnego ground truth.

Stwórz systematyczny proces ewaluacji zanim klienci zaczną się skarżyć. Historia znajomego z SFO pokazuje dokładnie, co się dzieje gdy tego nie zrobisz – reactive zamiast proactive approach.

Pamiętaj o ciągłej aktualizacji benchmarków. To co było standardem rok temu, może już nie wystarczać, w związku z tym regularne przeglądy i aktualizacje to konieczność, nie opcja.

Pierwsze kroki (na podstawie rekomendacji z sesji)

Zdefiniuj kluczowe metryki dla Twojego przypadku użycia
Ustal ground truth przed rozpoczęciem rozwoju
Ustaw automatyczne alerty przy spadku jakości
Przygotuj feedback loop z rzeczywistymi użytkownikami

Prowadzący podkreślił, że ewaluacja to obecnie większe wyzwanie niż prompt engineering. Firmy które zrozumieją pierwszeństwo systematycznej ewaluacji nad sztukami prompt engineeringowymi, będą miały przewagę konkurencyjną.

Kluczowy insight

Klient jako ewaluator

Standardowo myślimy: Testujemy system wewnętrznie, naprawiamy błędy, a dopiero potem wypuszczamy do klientów.

W praktyce okazuje się, że: Klient staje się naszym głównym ewaluatorem – mówi nam co nie działa i jakie powinny być poprawne odpowiedzi.

Dlaczego to jest istotne: Historia znajomego z SFO pokazuje, że nawet doświadczeni twórcy AI polegają na feedback’u klientów zamiast na systematycznej ewaluacji. To oznacza, że nie my kontrolujemy jakość – kontrolują ją użytkownicy końcowi.

Test na jutro: Następnym razem gdy planujesz wypuszczenie agenta AI, zamiast skupiać się tylko na funkcjonalnościach spróbuj najpierw ustalić ground truth z ekspertami domenowymi i sprawdź czy potrafisz przewidzieć skargi klientów zanim się pojawią.

Ten wpis jest częścią mojej kolekcji notatek z ciekawych prezentacji, webinarów i podcastów, które uważam za wartościowe i do których sam chcę wracać. Wszystkie przemyślenia i obserwacje pochodzą od oryginalnych autorów – ja jedynie uporządkowałem treść dla lepszej czytelności. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je tutaj: https://www.linkedin.com/events/7335631880551051264/about/

Tag: Benchmarki Systemow Ai

Dlaczego ewaluacja agentów AI jest ważniejsza od prompt engineeringu #EN146