Ocena zachowania agenta: wyniki, trajektorie i informacje zwrotne dotyczące produkcji
Jak oceniać systemy agentowe poza końcową odpowiedzią: powiązać LangChain, LangGraph i LangSmith z rolami, ocenić trajektorie wyników oraz kontekst, a także uwzględnić błędy w produkcji podczas ocen.
Źródła: Building Better Agentic AI Systems: What I Learned About Deep Agents, LangSmith Engine & Evals
Użycie agenta AI w demonstracji zajmuje popołudnie przy obecnych modelach i frameworkach. Trudności zaczynają się, gdy agent trafia do rzeczywistego produktu: wybiera niewłaściwy narzędzie, otrzymuje ograniczony kontekst, obiera ścieżkę, której nikt nie zaplanował, lub zwraca odpowiedź, która brzmi poprawnie, ale tak naprawdę nie jest. Ten artykuł omawia cykl życiowy inżynierii, który sprawia, że takie systemy są niezawodne, skupiając się na ocenie: co mierzyć, na jakim poziomie oraz jak przekształcić każdą awarię w produkcji w kontrolę zapobiegającą jej ponownemu wystąpieniu. Przykłady opierają się na ekosystemie LangChain (LangChain, LangGraph, LangSmith i Deep Agents), ale te zasady odnoszą się do każdego innego zestawu narzędzi.
Bazową funkcję LLM łatwo sobie wyobrazić: przychodzi żądanie, następuje jedno wywołanie modelu i pojawia się odpowiedź.
User → Prompt → LLM → Response
Agent to zupełnie inna istota. Gdy ma przed sobą cel, może podzielić pracę na zadania, pobrać dokumenty, wywołać API, uruchomić narzędzia, przechowywać stan, przekazać część pracy innemu agentowi, przeanalizować tymczasowe wyniki, odzyskać się po błędach i następnie wybrać kolejny krok. Uproszczony zarys tego przepływu sterowania:
USER GOAL
│
▼
AGENT
│
PLAN
│
┌──────────────┼──────────────┐
│ │ │
▼ ▼ ▼
TOOLS MEMORY SUBAGENT
│ │ │
└──────────────┼──────────────┘
│
▼
DECIDE / ACT
│
More work needed?
↙ ↘
YES NO
│ │
└── LOOP ▼
RESULT
Zwróć uwagę na pętlę na dole: agent ciągle decyduje, czy potrzebna jest dodatkowa praca, a każda iteracja może dotyczyć narzędzi, pamięci lub podagentów. W tym momencie nie wysyłamy już odpowiedzi modelu – uruchamiamy system. Ma to znaczenie dla jakości, ponieważ ostateczna odpowiedź jest tak dobra, jak łańcuch decyzji, które ją stworzyły. Poprawny model z błędnym krokiem pobierania informacji lub dobry plan wykonywany przy użyciu niewłaściwego narzędzia nadal przynosi złe rezultaty.
Przypisywanie ról: LangChain, LangGraph i LangSmith
Pрактиcznym sposobem na łatwe rozróżnienie trzech głównych produktów LangChain jest powiązanie każdego z nich z pytaniem inżynieryjnym, na które odpowiada.
- LangChain zapewnia funkcjonalności związane z modelem: integracje modeli, narzędzia, funkcje wyszukiwania oraz połączenia z danymi zewnętrznymi. Jego pytanie brzmi: co musi umieć robić aplikacja?
- LangGraph zajmuje się orkiestracją procesów, gdy te stają się złożone, obejmując zarządzanie stanem, warunkowymi ścieżkami, pętlami, wywołaniami narzędzi, krokami zatwierdzania przez człowieka oraz koordynacją wielu agentów. Jego pytanie brzmi: jak powinien przebiegać proces?
- LangSmith analizuje to, co dzieje się po uruchomieniu systemu: jakie narzędzia zostały wywołane, jaki kontekst widział model, gdzie pojawiła się opóźniona reakcja, który krok zawiodł, dlaczego podjęto określoną decyzję oraz czy nowa wersja faktycznie jest lepsza od starej. Jego pytanie brzmi: co tak naprawdę się stało i czy to było dobre?
Gdy wszystko jest połączone, przepływ rozpoczyna się od celu biznesowego, przechodzi przez odpowiednie możliwości i mechanizmy koordynacji, aż do uzyskania rezultatu, który następnie jest obserwowany i oceniany, aby zespół mógł z niego czerpać wnioski.
BUSINESS GOAL
│
▼
LANGCHAIN
Models • Tools • Data
│
▼
LANGGRAPH
State • Flow • Decisions
│
▼
AGENT SYSTEM
│
▼
RESULT
│
▼
LANGSMITH
Observe • Trace • Eval
│
▼
LEARN
Ostatnia strzałka jest najważniejsza. Obserwacja nie stanowi końcowego etapu; służy do uczenia się. Jeśli rozróżnienie pomiędzy LangChain a LangGraph wciąż jest niejasne, nasze porównanie łańcuchów i grafów z stanem omawia to w szczegółach.
Wykorzystywanie agentów do udoskonalania innych agentów: silnik LangSmith
Ślady działania agenta precyzyjnie pokazują, co on zrobił, ale same w sobie nic nie naprawiają. Ktoś musi je przeczytać, ustalić, co poszło nie tak, sprawdzić, czy ten sam błąd występuje gdzie indziej, znaleźć przyczynę źródłową, zmienić system i potwierdzić, że ta zmiana nie uszkodziła czegoś innego. To jest do zarządzania przy niewielkiej liczbie prób, ale beznadziejne przy tysiącach śladów z produkcji.
LangSmith Engine, nowsza funkcja LangSmith w momencie pisania tego tekstu, wykorzystuje agenta do tej analizy. Skanuje ślady z produkcji w poszukiwaniu powtarzających się wzorców i błędów, grupuje powiązane problemy, pomaga w ich diagnozie i proponuje ulepszenia. Co najważniejsze, znalezione błędy mogą zostać przekazane do oceny, dzięki czemu problem odkryty dzisiaj staje się jawną sprawą do sprawdzenia jutro. Koncepcyjnie ta ścieżka wygląda następująco:
PRODUCTION AGENT
│
▼
TRACES
│
▼
LANGSMITH ENGINE
│
▼
Detect Patterns
│
▼
Diagnose Issues
│
▼
Suggest Improvement
│
▼
Add Evals
│
▼
Regression Testing
│
▼
Review / Deploy
│
└────────► Observe Again
Każdy etap coraz bardziej precyzuje problem: surowe zapisy stają się wzorcami, wzorce przekształcają się w diagnozy, a diagnozy w potencjalne rozwiązania. Rozwiązania te są sprawdzane za pomocą nowych testów oceny i testów regresji, zanim człowiek je przejrzy i wdroży. Następnie cykl rozpoczyna się od nowych zapisów.
Zmiana polega tu na sposobie traktowania tych zapisów. Zamiast być czymś, co otwiera się tylko podczas incydentu, stają się one surowcem ciągłego doskonalenia. Właśnie tak funkcjonuje już dojrzałe inżynierowanie jakości w tradycyjnym oprogramowaniu: błąd produkcyjny nie powinien kończyć się poprawką, lecz testem, który zapobiega ponownemu pojawieniu się tego samego typu błędu. Automatyczna diagnostyka nie eliminuje jednak potrzeby przeglądu – proponowane poprawki do promptów lub definicji narzędzi mogą mieć skutki uboczne, dlatego etapy przeglądu i testów regresji pozostają w tym procesie.
Agenci głębokie do zadań długoterminowych
Część zapytań kryje za sobą dużo pracy. Weźmy pod uwagę zapytanie dotyczące inżynierii jakości tego typu. Przy nowym wymogu produktowym agent musi przejrzeć odpowiednie dokumenty, zaznaczyć najbardziej ryzykowne ścieżki użytkownika, opracować dla nich scenariusze testowe, zgłębić kod realizujący te ścieżki oraz zapisać swoje ustalenia.
Aby to zrealizować, agent musi planować, czytać pliki, pozyskiwać wiedzę, wywoływać narzędzia, ewentualnie uruchamiać kod, przechowywać tymczasowe ustalenia, delegować specjalistyczne zadania oraz pamiętać to, czego już się nauczył. Struktura tej pracy:
Understand Goal
│
▼
Create Plan
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
Read Files Use Tools Search Knowledge
│ │ │
└─────────────┼─────────────┘
│
Delegate Work
│
▼
SUBAGENTS
│
▼
Combine Findings
│
▼
RESULT
Deep Agents to narzędzie od LangChain przeznaczone do tego rodzaju zadań długoterminowych. Łączy w sobie funkcje planowania, obsługi narzędzi, zarządzania plikami, kontekstem, umiejętnościami, pamięcią oraz podagentami, dzięki czemu nie musisz samodzielnie składać wszystkich tych elementów.
Ciekawe nie jest to, że agent może robić więcej, ale to, jak zorganizowana jest jego autonomia. Przekazanie agentowi dwudziestu narzędzi nie czyni go lepszym; często pogarsza to wybór narzędzi. Rozdzielenie każdego zadania na pięć podagentów również nie poprawia automatycznie architektury, ponieważ każda przenoszenie danych kosztuje tokeny i może prowadzić do utraty kontekstu. Im bardziej zdolne stają się elementy składowe, tym ważniejsze stają się decyzje projektowe dotyczące ich wykorzystania. Praktycznym rozwiązaniem domyślnym jest dodawanie podagenta tylko wtedy, gdy podzadanie wymaga izolowanego kontekstu lub innego zestawu narzędzi, oraz utrzymywanie listy narzędzi dla każdego agenta w tak małym zakresie, jaki pozwala na to zadanie.
Kierowanie agentami to odrębny problem: Zarządzane głębokie agenty
Budowa zdolnego agenta oraz jego niezawodne uruchamianie w środowisku produkcyjnym to dwa odrębne zadania inżynieryjne. Agent działający przez długi czas może potrzebować radzenia sobie z przerwami, zachowywania swojego stanu, pracy z plikami, bezpiecznego wykonywania kodu, przesyłania informacji o postępach do interfejsu użytkownika, przechowywania pamięci oraz generowania wystarczającej ilości danych telemetrycznych, aby inżynierowie mogli odtworzyć to, co się wydarzyło.
Managed Deep Agents, usługa hostowana w tym samym ekosystemie w momencie pisania tekstu, skupia się na tym warstwie operacyjnej. Związek między nimi można przedstawić jako zachowanie na górze i infrastrukturę czasu wykonywania poniżej:
DEEP AGENT
Planning • Tools • Files • Subagents
│
▼
Agent Behavior
│
▼
MANAGED DEEP AGENTS Durable Execution
Persistence
Sandboxes
Memory
Streaming
Identity
Tracing / Evaluation
Agent definiuje swoje zachowanie poprzez planowanie, narzędzia, pliki oraz podagenty. Warstwa zarządzana zapewnia trwałe wykonywanie, persistencję, środowiska testowe typu sandbox, pamięć, przepływ danych, identyfikację oraz śledzenie z możliwością oceny. Ta ogólna zasada obowiązuje niezależnie od tego, czy korzystasz z usługi zarządzanej, czy uruchamiasz własne rozwiązanie: inteligencja modelu jest jednym z elementów architektury sztucznej inteligencji w produkcji, a infrastruktura otaczająca ją wymaga równie dużej uwagi. Nasze porównanie narzędzi do obsługi runtime oraz frameworków składanych analizuje kompromis pomiędzy samodzielnym budowaniem a wykorzystywaniem gotowych rozwiązań.
Dlaczego agenci podważają tradycyjne testowanie
Tradycyjne testowanie opiera się na determinizmie – podajesz funkcji znany wprowadzenie, otrzymujesz wynik i sprawdzasz go.
Input → Function → Output → Assertion
Wywołanie API z ustalonym żądaniem umożliwia sprawdzenie kodu stanu, schematu odpowiedzi, treści danych, nagłówków oraz reguł biznesowych. Agenci nie pasują do tego wzorca. Poproś jednego z nich o zbadanie incydentu w środowisku produkcyjnym i znalezienie prawdopodobnej przyczyny. W jednym przypadku najpierw czyta logi, a następnie wysyła zapytanie do bazy danych; w innym sprawdza dokumentację, wywołuje API i dopiero potem czyta logi. Choć metody są różne, oba podejścia mogą doprowadzić do trafnych wniosków.
Możliwy jest również przypadek odwrotny, który jest bardziej niebezpieczny: ostateczna odpowiedź wydaje się poprawna, mimo że agent oparł się na niepewnym źródle, użył niewłaściwego narzędzia lub doszedł do właściwego wniosku z niewłaściwych powodów. Twierdzenie oparte na dokładnym dopasowaniu wyniku nie potrafi odróżnić tych przypadków. To właśnie lukę wypełniają oceny.
Co mierzy ocena
Praktyczna definicja: ocena pokazuje, jak dobrze system AI radzi sobie z standardami istotnymi dla konkretnej zadania. Kryteria pochodzą od samego zadań, a nie od ram roboczych.
Weźmy agenta, który generuje scenariusze testowe na podstawie wymagań. Fakt, że zwrócił dziesięć przypadków testowych w formacie ważnego JSON, niewiele nam mówi. Istotne są informacje dotyczące jakości:
GENERATED TESTS
│
▼
EVALUATE
│
┌────────────────┼────────────────┐
│ │ │
Coverage Correctness Relevance
│ │ │
├──────── Hallucination ──────────┤
│ │
└──────────── Duplication ─────────┘
│
▼
QUALITY SIGNAL
W praktyce te wymiary przekształcają się w konkretne pytania:
- Czy testy rzeczywiście obejmują wszystkie wymagania?
- Czy każdy z nich jest do nich istotny?
- Czy agent wymyślił zachowanie, którego produkt nie posiada?
- Czy pominął ważny scenariusz negatywny lub specjalny?
- Czy kilka z tych dziesięciu przypadków jest w rzeczywistości duplikatami?
Każde pytanie może służyć jako narzędzie oceny: niektóre są deterministyczne (wykrywanie duplikatów za pomocą znormalizowanego tekstu lub embeddingów), inne wymagają zestawu danych referencyjnych (sprawdzenie zgodności z已知ymi wymaganiami), a jeszcze inne zazwyczaj potrzebują LLM jako sędziego lub etykiet ludzkich (funkcjonalności wynikające z halucynacji). Sprawdzenia strukturalne, takie jak ważność schematu, nadal warto przeprowadzać, ale raczej jako punkt odniesienia niż jako definicja sukcesu.
Trzy aspekty oceny: odpowiedź, krok i trajektoria
Przy pracy z agentami nie musimy oceniać tylko końcowego wyniku. Istnieje co najmniej trzy przydatne kryteria:
- Końcowa odpowiedź: czy odpowiedź jest poprawna, kompletna i istotna?
- Jeden krok: na przykład, czy agent wybrał odpowiedni narzędzie do rozwiązania tego podproblemu, uzasadniając to sensownymi argumentami?
Oto typowa trajektoria dla agenta odpowiadającego na pytania:
User Goal
│
▼
Agent
│
├── Search Documentation
│
├── Query Database
│
├── Call API
│
└── Generate Answer
Ostateczna odpowiedź to po prostu ostatni węzeł. W wielu aplikacjach trasa ma takie samo znaczenie jak cel – na przykład to, czy agent skonsultował się z dokumentacją przed zapytaniem o dane produkcyjne, czy też wykonał żądanie API, którego nie miał powodu wysyłać. Ocena trajektorii staje się kluczowa, gdy agenci mogą zmieniać dane, otwierać zgłoszenia, uruchamiać kod, uruchamiać procesy lub działać w systemach korporacyjnych, ponieważ szkodliwa działanie pośrednie stanowi awarię, nawet jeśli ostateczna wiadomość jest poprawna. Sprawdzania trajektorii mogą być ścisłe (dokładna oczekiwana sekwencja), łagodne (niezbędne kroki muszą być obecne w dowolnej kolejności, a zakazane kroki nie mogą występować) lub oceniane przez model; biorąc pod uwagę opisane powyżej zróżnicowanie ścieżek, łagodne sprawdzania są zazwyczaj odpowiednim punktem wyjścia.
Oceny offline i online jako jeden pętla
Ocena naturalnie dzieli się na dwa tryby, które odpowiadają znanej praktyce programistycznej.
Offline: zwalnianie bram w znanych przypadkach
Ewaluacja offline odbywa się na przygotowanych zestawach danych i scenariuszach przed wydaniem nowej wersji. Wykonuje się reprezentatywne przypadki z użyciem kandydującej wersji agenta, ocenia je, porównuje z obecną wersją i decyduje o jej wydaniu.
Known Dataset
│
▼
Agent Version
│
▼
Run Evals
│
▼
Compare Results
│
▼
Release Decision
To odpowiednik zestawu testów regresji w CI dla agentów. Ponieważ wyniki modeli różnią się pomiędzy kolejnymi wykonywaniami, pomocne jest wykonanie każdego przypadku kilka razy i porównanie rozkładów ocen zamiast pojedynczych wyników.
Online: uczenie się na podstawie rzeczywistego ruchu
Ewaluacja online ocenia to, co dzieje się w środowisku produkcyjnym, a właśnie tam pojawiają się niespodzianki. Użytkownicy proszą o rzeczy, których nikt nie przewidział, zewnętrzne narzędzia zawodzą, kontekst przychodzi niekompletny, dane zmieniają się podczas pracy, a agenci obracają trajektoriami, których nie ma w żadnym zestawie danych. Ocena próbek żywych śladów ujawnia takie przypadki.
Zamknięcie pętli
Dwa te tryby stają się znacznie cenniejsze, gdy są połączone: każdy istotny błąd w produkcji znaleziony online jest dodawany do zestawu danych offline, dzięki czemu kolejna wersja jest testowana na jego podstawie.
OFFLINE EVALS
│
▼
BUILD
│
▼
DEPLOY
│
▼
PRODUCTION TRACES
│
▼
ONLINE EVALS
│
▼
DISCOVER FAILURE
│
▼
ADD FAILURE TO DATASET
│
└────────► OFFLINE EVALS
Z upływem czasu zestaw narzędzi offline przestaje odzwierciedlać to, co zespół wyobrażał sobie co do działań użytkowników, a zaczyna odzwierciedlać to, co oni faktycznie robią. Należy starannie dbać o prywatność podczas kopiowania danych z produkcji do zestawów danych; należy usunąć lub zmodyfikować dane wrażliwe, zanim staną się trwałymi danymi testowymi.
Zachowanie agenta jako nowy aspekt jakości
Nic z tego nie zastępuje tradycyjnych testów. Testy interfejsu użytkownika, API, integracji, walidacji danych, wydajności i bezpieczeństwa pozostają niezbędne dla każdego niezawodnego produktu. Systemy agentowe dodają kolejną warstwę: jakość zachowania agenta. Ta warstwa rodzi własne pytania:
- Czy narzędzie, które wybrał, było odpowiednie?
Zorganizowane jako model, te pytania wyglądają zupełnie inaczej niż klasyczna piramida testów:
AGENT QUALITY
│
┌─────────────────┼─────────────────┐
│ │ │
OUTCOME TRAJECTORY CONTEXT
QUALITY QUALITY QUALITY
│ │ │
▼ ▼ ▼
Correctness Tool Usage Groundedness
Relevance Decisions Relevance
Completeness Efficiency Freshness
│
┌────────┴────────┐
│ │
MEMORY RECOVERY
│ │
▼ ▼
Accuracy Failure Handling
Relevance Retry Behavior
Jakość wyniku obejmuje poprawność, trafność i kompletność. Jakość trajektorii dotyczy wykorzystania narzędzi, podejmowanych decyzji oraz efektywności, a dzieli się na aspekty związane z pamięcią (dokładność i trafność przypominanych informacji) oraz odzyskiwaniem (zarządzanie błędami i zachowanie przy ponownych próbach). Jakość kontekstu obejmuje uzasadnienie, trafność i aktualność informacji. Każdy element może być powiązany z jednym lub kilkoma narzędziami oceny, a razem dają one znacznie pełniejszy obraz niż prosty wynik „przeszedł/ nie przeszedł” dla ostatecznej odpowiedzi. Budowa takiego systemu wymaga nowych praktyk w zakresie testowania agentów, obserwowalności, oceny trajektorii, zestawów testów regresji w sztucznej inteligencji, oceny wydajności w środowisku produkcyjnym oraz ciągłego doskonalenia, co jest obszarem coraz większego przenikania się prac inżynierów jakości i inżynierów sztucznej inteligencji. Jeśli chodzi o aspekt bezpieczeństwa tego samego problemu, zapoznaj się z naszym przewodnikiem na temat zasad bezpieczeństwa i middleware w LangChain.
Praktyczne zmiany w projektach własnych agentów
Lekcją płynącą z tego wszystkiego jest to, by nie przyjmować każdej nowej funkcji. Raczej należy postępować odwrotnie: być bardziej świadomym w kwestii architektury.
- Określ kryteria oceny podczas projektowania agenta, a nie po jego wdrożeniu.
- Traktuj możliwość obserwacji jako część początkowej architektury, a nie dodatek wprowadzany później.
- Kieruj dane z produkcji do działu inżynieryjnego jako informacje zwrotne, a nie tylko jako dowody incydentów.
- Upewnij się, że każdy istotny błąd w produkcji zostanie objęty przyszłą oceną.
- Dostosuj stopień złożoności do problemu. Czasami wystarczy prosty agent; czasami uzasadniona jest orkiestracja za pomocą LangGraph; czasami zadanie naprawdę korzysta z podagentów, trwałego kontekstu lub pełnego narzędzia do zarządzania agentem.
Technologia powinna podążać za problemem, a nie odwrotnie.
Pętla doskonalenia
Frameworki przychodzą i odchodzą; trwałą ideą jest pętla.
LEARN
│
▼
BUILD
│
▼
OBSERVE
│
▼
EVALUATE
│
▼
IMPROVE
│
└──────────► LEARN AGAIN
Uczysz się jakiegoś koncepcji i budujesz na jej podstawie. Proces budowania ujawnia to, czego nie zrozumiałeś. Uruchomienie odkrywa problemy, których nie przewidziałeś. Ocena zastępuje założenia dowodami, a dowody napędzają doskonalenie, które zazwyczaj ujawnia kolejną rzecz do nauczenia się.
Główne wnioski
- Agent to system decyzji; oceniaj decyzje, a nie tylko ostateczny tekst.
- Przypisz każdemu narzędziu jasną rolę: LangChain do możliwości, LangGraph do orkiestracji, LangSmith do obserwacji i oceny.
- Oceniaj na trzech poziomach: odpowiedzi, kroków i trajektorii, preferując łagodniejsze sprawdzanie trajektorii, gdy istnieją różne poprawne ścieżki.
- Łącz oceny online i offline, aby błędy w produkcji stały się przypadkami regresji.
Modele, frameworki oraz produkty dostępne w tym obszarze zmieniają się szybko, dlatego sprawdź aktualną dokumentację pod kątem funkcji takich jak LangSmith Engine i Managed Deep Agents. Dyscyplina polegająca na obserwowaniu, mierzeniu oraz wprowadzaniu uzyskanych informacji z powrotem do systemu sprawi, że twoi agenci będą godni zaufania, mimo że wszystko wokół nich się rozwija.