Agent dał dobrą odpowiedź.
Ale czy doszedł do niej właściwą drogą?
Artykuł 9 serii postawił pytanie: czy agent robi to co powinien? I dał narzędzia do mierzenia tego — task completion, tool call accuracy, faithfulness, efficiency. To jest fundament, i jeśli go nie masz, zacznij tam.
Ten wpis zaczyna się w miejscu, gdzie tamten się kończy. Bo jest jeden problem, którego cztery metryki nie łapią: agent może osiągnąć dobry wynik złą drogą. I zła droga kosztuje — w tokenach, w latencji, w ryzyku. A przede wszystkim: jeśli agent doszedł do dobrej odpowiedzi przez przypadek, nie przez rozumowanie, to przy następnym, odrobinę innym pytaniu — zawiedzie.
Co to jest trajektoria
Gdy agent myśli w pętli ReAct — percepcja → plan → akcja → ocena → następny krok — każdy obrót tej pętli zostawia ślad. Trajektoria to właśnie ten ślad: pełna sekwencja kroków agenta od otrzymania zadania do odpowiedzi.
Trajektoria zawiera:
- Co agent zaplanował w każdym kroku
- Które narzędzia wywołał i z jakimi parametrami
- Co zwróciły te narzędzia
- Jak agent to zinterpretował
- Co zdecydował zrobić dalej
To jest nieporównywalnie bogatszy sygnał niż sam wynik końcowy. Wynik mówi „doszedł”. Trajektoria mówi „jak”.
Dlaczego wynik to za mało — trzy scenariusze
Scenariusz 1: Dobra odpowiedź, zła droga. Agent ma sprawdzić status zamówienia #45678. Wywołuje get_order_status — ale z parametrem order_id="456" (obciął numer). Narzędzie zwraca błąd. Agent próbuje ponownie z order_id="45678" — tym razem trafia. Odpowiedź użytkownikowi: poprawna. Task completion: 100%. Ale trajektoria ujawnia, że agent zgadywał parametry — i przy zamówieniu #4 zawiedzie.
Scenariusz 2: Dobry wynik, 3x za dużo kroków. Agent ma wygenerować podsumowanie dokumentu. Zamiast wywołać jedno narzędzie do odczytu i podsumować, wywołuje je trzykrotnie (raz w całości, dwa razy fragmentami), porównuje wyniki, decyduje że pierwsza wersja była najlepsza. Wynik: dobry. Efficiency metric: niska. Koszt: 3x wyższy niż powinien. Przy 1000 wywołań dziennie — problem widoczny na rachunku.
Scenariusz 3: Pętla którą wynik ukrył. Agent ma umówić spotkanie. Nie może znaleźć dostępnego terminu, więc pyta o dostępność raz, drugi, trzeci — z coraz szerszym zakresem dat, bo nie rozumie że trzeba zapytać konkretną osobę, nie ogólny kalendarz. W końcu trafia na termin. Task completion: 100%. Ale agent się pętlił — i pętla ukrywa systematyczny błąd w rozumieniu narzędzia, który odtworzy się przy każdym podobnym zadaniu.
Trzy wymiary oceny trajektorii
1. Trafność kroków
Czy agent szedł właściwą ścieżką? Przy danym zadaniu istnieje optymalna sekwencja kroków — nie musi być jedyna, ale można ją zdefiniować z góry jako referencję.
Porównujesz: expected_trajectory (co agent powinien był zrobić) vs actual_trajectory (co faktycznie zrobił). Podobieństwo mierzysz jako procent kroków z expected które pojawiły się w actual, we właściwej kolejności.
Format rozszerzonego testu (wychodzi z formatu z art. 9):
{
"id": "test_042",
"input": "Jaki jest status zamówienia #45678?",
"expected_tools": ["get_order_status"],
"expected_tool_params": {"order_id": "45678"},
"expected_trajectory": [
{"step": 1, "action": "tool_call", "tool": "get_order_status", "params": {"order_id": "45678"}},
{"step": 2, "action": "respond", "contains": ["status", "data dostawy"]}
],
"max_steps": 3,
"success_criteria": "Odpowiedź zawiera status i datę dostawy",
"category": "typical"
}max_steps to kluczowe pole — definiuje ile kroków maksymalnie akceptujesz dla tego zadania.
2. Efektywność
Stosunek kroków wykonanych do kroków minimalnych. Agent który wykonał 6 kroków na zadanie wymagające 2 kroków ma efficiency = 33%.
def trajectory_efficiency(actual_steps: int, min_steps: int) -> float:
return min(1.0, min_steps / actual_steps)
# Agent wykonał 6 kroków, minimalne były 2
efficiency = trajectory_efficiency(6, 2) # → 0.33Efficiency poniżej 0.5 to sygnał do zbadania — agent albo się pętli, albo nie rozumie narzędzi, albo system prompt generuje niepotrzebne kroki walidacji.
3. Jakość parametrów narzędzi
Czy agent wydedukował parametry z kontekstu, czy je zgadł lub zhalucynował?
To najtrudniejszy do automatycznego mierzenia wymiar — bo wymagasz dostępu do kroków pośrednich (chain-of-thought), nie tylko wywołań. Mierzysz go przez:
- Porównanie parametrów z expected (czy
order_idbył poprawny od pierwszego wywołania) - Liczbę retry — agent który wywołuje to samo narzędzie kilkukrotnie z różnymi parametrami prawdopodobnie zgaduje
- LLM-as-judge dla rozumowania (patrz niżej)
LLM-as-judge dla trajektorii
Klasyczny LLM-as-judge z art. 9 oceniał końcową odpowiedź. Sędzia trajektorii ocenia sekwencję kroków:
def trajectory_judge(task: str, trajectory: list[dict], expected: list[dict]) -> dict:
trajectory_text = "\n".join([
f"Krok {i+1}: {step['action']} "
f"{'→ ' + step['tool'] if 'tool' in step else ''} "
f"{'Params: ' + str(step.get('params', {})) if 'params' in step else ''}"
for i, step in enumerate(trajectory)
])
expected_text = "\n".join([
f"Krok {i+1}: {step['action']} "
f"{'→ ' + step['tool'] if 'tool' in step else ''}"
for i, step in enumerate(expected)
])
prompt = f"""
Oceń trajektorię agenta wykonującego zadanie.
ZADANIE: {task}
OCZEKIWANA TRAJEKTORIA:
{expected_text}
FAKTYCZNA TRAJEKTORIA:
{trajectory_text}
Oceń na skali 1-5:
1 = Całkowicie błędna ścieżka
3 = Właściwy kierunek, zbędne kroki lub drobne błędy
5 = Optymalna trajektoria
Zwróć JSON:
{{
"score": X,
"efficient": true/false,
"issues": ["lista problemów jeśli są"],
"reasoning": "krótkie uzasadnienie"
}}
"""
return json.loads(call_model(prompt, model="claude-haiku-4-5"))Kluczowe: sędzia trajektorii musi dostać oba — expected i actual. Bez referencji nie ma podstawy do oceny.
Sygnały złej trajektorii — co szukać w logach
Zanim zbudujesz pełną ewaluację trajektorii, warto znać sygnały których szukać w logach. Każdy z nich to kandydat do zbadania:
Retry loop — to samo narzędzie wywołane 2+ razy z różnymi parametrami w jednym zadaniu. Niemal zawsze oznacza że agent zgadywał albo nie rozumiał zwróconego błędu.
Backtracking — agent wraca do wcześniejszego narzędzia po tym jak przeszedł do następnego. Np. sprawdza status zamówienia, potem sprawdza klienta, potem wraca do zamówienia. Może być uzasadnione, ale często sygnał niespójnego planu.
Step count > 2× expected — jeśli zadanie powinno być na 3 kroki a zajęło 8, coś poszło nie tak. Nawet jeśli wynik jest poprawny.
Narzędzie wywołane z pustymi parametrami lub null — agent nie miał skąd wziąć wartości i podstawił placeholder. Niemal zawsze halucynacja parametru.
Brak wywołania narzędzia które powinno być wywołane — agent „wiedział” odpowiedź bez sięgania do danych. W agencie RAG to red flag.
Trajektoria wymaga logowania kroków
Tu jest warunek który odkładam celowo na koniec, bo jest oczywisty — ale bez niego cała ewaluacja trajektorii jest niemożliwa: musisz logować kroki pośrednie, nie tylko wynik końcowy.
Standardowe logowanie agenta zapisuje: input → output. To wystarczy do metryki task completion. Nie wystarczy do ewaluacji trajektorii.
Rozszerzone logowanie zapisuje każdy obrt pętli: plan agenta, wywołane narzędzie i parametry, wynik narzędzia, decyzja o następnym kroku. W n8n to console.log przy każdym węźle agenta przekazany do zewnętrznego serwisu albo arkusza. W kodzie — middleware który przechwytuje każde wywołanie.
Dokładnie o tym — jak logować i co robić z tymi logami w produkcji — jest następny wpis tego wątku: observability po deploymencie. Tu ewaluacja trajektorii jest narzędziem na etapie testowania, tam jest narzędziem na etapie produkcji.
Co z tego wynika
Ewaluacja trajektorii odpowiada na pytanie które wynik końcowy nie zadaje: jak agent tam doszedł. Trzy wymiary — trafność kroków, efektywność, jakość parametrów — razem z LLM-as-judge dla sekwencji kroków dają pełny obraz tego, czy agent rozumuje właściwie, czy tylko trafia przez przypadek.
Praktyczna zasada: agent który regularnie daje dobry wynik złą drogą jest agentem który zawiedzie przy pierwszym odchyleniu od testowanych scenariuszy. Ewaluacja trajektorii łapie go zanim to zrobi — pod warunkiem że logujesz kroki.
Pojęcia ze słownika: Agent ewaluacja · Ewaluacja trajektorii · LLM-as-judge · Tool use · Chain-of-thought · Agent observability
