Artykuł 9 z serii Anatomia Agenta AI ← Ile kosztuje agent w produkcji
Tradycyjny software jest deterministyczny. Wywołujesz funkcję z inputem X, dostajesz output Y. Zawsze. Test który przeszedł dziś przejdzie jutro jeśli kod się nie zmienił.
Agent AI nie jest deterministyczny. Ten sam input może dać inne odpowiedzi w różnych uruchomieniach. Model zaktualizowany przez providera zmienia zachowanie bez Twojej wiedzy. System prompt który działał doskonale z Claude Sonnet 4.5 może zachowywać się inaczej z Claude Sonnet 4.6.
Jak testujesz coś co jest z natury niedeterministyczne? Jak wiesz że zmiana system promptu poprawiła agenta zamiast go pogorszyć? Jak blokujesz deployment który obniżył jakość?
To jest problem ewaluacji agentów. I ma rozwiązania — tyle że inne niż klasyczne unit testy.
Dlaczego „działa” to za mało
Najczęstszy błąd przy budowaniu agentów: testowanie przez użytkowanie. Budujesz, rozmawiasz z agentem, widzisz że „działa”, wdrażasz.
Problem 1: testujesz happy path. Pytasz o rzeczy które wiesz że agent powinien obsłużyć. Użytkownicy produkcyjni zadają pytania których nie przewidziałeś.
Problem 2: „działa” jest binarne, jakość jest ciągła. Agent który „działa” ale daje odpowiedzi przeciętnej jakości, zbyt ostrożnie eskaluje lub regularnie popełnia subtelne błędy — to nie jest dobry agent.
Problem 3: zmiany regresują jakość. Zmieniasz system prompt żeby poprawić obsługę jednego scenariusza, niechcący pogarszasz inny. Bez ewaluacji nie wiesz o tym dopóki użytkownik nie zgłosi problemu.
Ewaluacja to systematyczne odpowiedź na pytanie: o ile dobrze agent robi swoje zadanie? Nie tak/nie — na ile.
Cztery metryki które mają znaczenie
1. Task completion rate
Czy agent ukończył zadanie które miał wykonać?
Proste do zdefiniowania, trudne do mierzenia precyzyjnie. „Ukończył” to często kwestia oceny — czy odpowiedź na pytanie o status zamówienia „ukończyła” zadanie jeśli podała status ale nie tracking number?
Definicja sukcesu musi być explicite w zestawie testowym: dla każdego testu definiujesz co oznacza „ukończone”.
2. Tool call accuracy
Czy agent wywołał właściwe narzędzia z właściwymi parametrami?
To jest ważniejsza metryka niż task completion dla agentów operacyjnych.
Przykład: agent ma sprawdzić status zamówienia #12345. Wywołuje get_order_status(order_id="12345") — dobrze. Wywołuje cancel_order(order_id="12345") — task completion może wyglądać jak sukces (zwrócił jakiś wynik) ale tool call accuracy = 0. Agent zrobił coś zupełnie innego niż powinien.
Mierzenie: w zestawie testowym zapisujesz jakie narzędzia agent powinien wywołać. Porównujesz z tym co faktycznie wywołał.
3. Response faithfulness
Czy odpowiedź agenta jest zgodna ze źródłami z których korzystał?
Agent RAG który twierdzi że „cena produktu X to 399 zł” gdy w bazie jest 499 zł — nie jest ani pomocny, ani nie można powiedzieć że działa jak założono. Agent który cytuje warunki gwarancji inaczej niż są w dokumencie, tak samo — nie jest „faithful”.
Faithfulness mierzy czy agent halucynuje fakty z kontekstu którego ma dostęp. Różni się od „agent mówi prawdę” — agent może mówić coś prawdziwego ale nieopartego na dostarczonych danych.
4. Conversation efficiency
Ile kroków, wywołań narzędzi i tokenów agent potrzebował?
Agent który rozwiązuje zadanie w 3 krokach jest lepszy niż ten który potrzebuje 9 — przy porównywalnej jakości. Efficiency jest proxy dla kosztów i dla jakości rozumowania. Agent który „krąży” w pętli zamiast zmierzać do celu ma niską efficiency i prawdopodobnie słabszy system prompt.
Budowanie zestawu testowego
Minimalny zestaw testowy dla agenta produkcyjnego: 20-30 przykładów pokrywających:
- 40%: typowe przypadki (to co użytkownicy pytają najczęściej)
- 30%: edge cases (pytania na granicy zakresu, niejednoznaczne, niekompletne)
- 20%: przypadki błędów (co agent robi gdy narzędzie zwraca błąd, gdy dane są niekompletne)
- 10%: adversarial (próby prompt injection, pytania poza zakresem, „zapomnij instrukcje”)
Format każdego testu:
{
"id": "test_001",
"input": "Gdzie jest moje zamówienie #45678?",
"expected_tools": ["get_order_status"],
"expected_tool_params": {"order_id": "45678"},
"success_criteria": "Odpowiedź zawiera status zamówienia i datę dostawy",
"should_not_contain": ["cancel_order", "delete", "refund"],
"category": "typical"
}Kluczowe: zestaw testowy jest żywy — rośnie gdy odkrywasz nowe edge cases w produkcji. Każdy incydent to kandydat na nowy test.
LLM-as-judge — model ocenia model
Niektóre kryteria jakości są subiektywne: czy odpowiedź jest pomocna? Czy ton jest właściwy? Czy wyjaśnienie jest jasne?
Ręczna ocena wszystkich odpowiedzi nie skaluje się. Rozwiązanie: użyj drugiego modelu AI jako sędziego.
def llm_judge(question: str, answer: str, criteria: str) -> dict:
prompt = f"""
Oceń poniższą odpowiedź asystenta według kryterium: {criteria}
Pytanie użytkownika: {question}
Odpowiedź asystenta: {answer}
Oceń na skali 1-5 gdzie:
1 = Całkowicie nie spełnia kryterium
3 = Częściowo spełnia kryterium
5 = W pełni spełnia kryterium
Zwróć JSON: {{"score": X, "reasoning": "krótkie uzasadnienie"}}
Zwróć TYLKO JSON, bez dodatkowego tekstu.
"""
response = call_model(prompt) # tani model np. Haiku
return json.loads(response)
# Użycie
result = llm_judge(
question="Czy mogę zwrócić produkt?",
answer="Tak, mają Państwo 30 dni na zwrot...",
criteria="Odpowiedź jest zgodna z polityką firmy i kompletna"
)
# {"score": 4, "reasoning": "Odpowiedź poprawna, brakuje info o stanie produktu"}Trzy pułapki LLM-as-judge:
Modele preferują swoje własne odpowiedzi. Jeśli judge to Claude i agenta to Claude — oceny mogą być zawyżone. Używaj innego modelu jako sędziego niż model agenta.
Długie odpowiedzi dostają wyższe oceny nawet gdy jakość jest gorsza. Sprawdź czy Twój judge nie premiuje gadatliwości — dodaj explicite „zwięzłość jest wartością” do prompt sędziego.
Judge nie zastępuje prawdy. LLM-as-judge to przybliżenie ludzkiej oceny, nie jej substytut. Dla krytycznych przypadków — ręczna review przez człowieka jest niezastąpiona.
Hallucination detection przed nieodwracalnymi akcjami
Hallucination detection ma największą wartość tam gdzie błąd jest kosztowny — przed akcjami których nie można cofnąć.
Agent który analizuje dane i na ich podstawie inicjuje przelew. Agent który tworzy dokument prawny na podstawie wymagań klienta. Agent który wysyła komunikat do wszystkich klientów.
Przed taką akcją warto sprawdzić: czy fakty w odpowiedzi agenta mają oparcie w danych które agent miał dostępne?
Prosty groundedness check:
def check_groundedness(agent_answer: str, source_documents: list[str]) -> dict:
sources_text = "\n---\n".join(source_documents)
prompt = f"""
Poniżej jest odpowiedź asystenta i dokumenty źródłowe.
Sprawdź czy każde twierdzenie w odpowiedzi ma oparcie w dokumentach.
ODPOWIEDŹ ASYSTENTA:
{agent_answer}
DOKUMENTY ŹRÓDŁOWE:
{sources_text}
Oceń groundedness (0.0-1.0) i wymień twierdzenia bez oparcia w źródłach.
Zwróć JSON: {{"score": 0.X, "unsupported_claims": ["..."]}}
"""
return json.loads(call_model(prompt))
# Użycie w pipeline agenta
result = check_groundedness(agent_answer, retrieved_docs)
if result["score"] < 0.8:
# Nie wykonuj akcji — human-in-the-loop
flag_for_review(agent_answer, result["unsupported_claims"])
else:
# Bezpiecznie wykonaj akcję
execute_action(agent_answer)Wartość progu (0.8) zależy od kontekstu — dla transakcji finansowych wyższy, dla odpowiedzi informacyjnych niższy.
CI/CD dla agentów — automatyczne testy przed deploymentem
Każda zmiana agenta (nowy system prompt, zmiana modelu, nowe narzędzie) powinna przejść przez ewaluację zanim trafi do produkcji.
Prosty pipeline w GitHub Actions:
name: Agent Evaluation
on:
pull_request:
paths:
- 'agent/system_prompt.txt'
- 'agent/config.py'
- 'agent/tools/**'
jobs:
evaluate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Run evaluation suite
run: python evaluate.py --test-set tests/agent_tests.json
- name: Check quality gates
run: |
python check_gates.py \
--task-completion 0.90 \
--tool-accuracy 0.95 \
--faithfulness 0.85check_gates.py porównuje wyniki ewaluacji z progami i zwraca exit code 1 (blokuje merge) jeśli którykolwiek próg nie jest osiągnięty.
Trzy progi których warto pilnować:
- Task completion ≥ 90% — agent kończy zadania
- Tool call accuracy ≥ 95% — agent wywołuje właściwe narzędzia
- Faithfulness ≥ 85% — agent nie halucynuje z dostępnego kontekstu
Progi są parametrami — ustalasz je na podstawie baseline’u Twojego agenta, nie arbitralnie.
Pętla doskonalenia
Ewaluacja nie jest jednorazowa. Jest pętlą:
- Uruchom ewaluację na aktualnej wersji — masz baseline
- Zidentyfikuj najsłabsze kategorie — gdzie agent najczęściej zawodzi
- Zmień system prompt lub konfigurację pod kątem tych kategorii
- Uruchom ewaluację ponownie — czy poprawa nastąpiła bez regresji w innych kategoriach
- Wdróż jeśli wyniki lepsze — i zaktualizuj baseline
Ta pętla działa też w produkcji: logi konwersacji gdzie użytkownicy eskalowali lub wyrażali niezadowolenie są kandydatami do zestawu testowego. Każdy rzeczywisty incydent zasługuje na własny test który zapobiegnie jego powtórzeniu.
W ostatnim artykule serii: dziesięć artykułów, dziesięć warstw. Checklista agent-ready — co zrobić żeby Twoja strona i Twój agent były gotowe na to co nadchodzi.
Pojęcia ze słownika: Agent ewaluacja · Hallucination detection · Agent observability · Human-in-the-loop · Tool use · Chain-of-thought
