Jak wiedzieć że agent robi to co powinien — ewaluacja, LLM-as-judge i CI/CD

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.85

check_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ą:

1. Uruchom ewaluację na aktualnej wersji — masz baseline
2. Zidentyfikuj najsłabsze kategorie — gdzie agent najczęściej zawodzi
3. Zmień system prompt lub konfigurację pod kątem tych kategorii
4. Uruchom ewaluację ponownie — czy poprawa nastąpiła bez regresji w innych kategoriach
5. 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