Evals i quality gates

Gdzie definiujemy evals

Najprościej: obok agenta.

engineering-agents/
└── implementer/
    ├── agent.py
    ├── workflow.py
    └── evals/
        ├── cases.yaml
        ├── rubrics.yaml
        └── datasets/

Tak samo jak kod ma tests/, agent może mieć evals/.

Kiedy uruchamiamy evals

Nie tylko przy zmianie wersji modelu.

Evals warto traktować jak testy regresyjne zachowania agenta.

1. Przy zmianie modelu

GPT X -> GPT Y
Claude X -> Claude Y

Ten sam prompt i te same tools mogą zacząć dawać inne zachowanie.

To najbardziej oczywisty przypadek.

2. Przy zmianie system promptu lub instrukcji agenta

Zmiana kilku zdań może zmienić:

• kolejność działań,
• wybór tools,
• skłonność do używania RAG,
• sposób interpretacji ticketu.

Dlatego prompt jest częścią wersjonowanej konfiguracji agenta.

3. Przy zmianie toola albo jego opisu

Jeżeli zmienimy:

github.create_pr

albo nawet tylko jego description, model może zacząć wybierać go w innych sytuacjach.

To również wymaga regresji.

4. Przy zmianie RAG

Na przykład:

• nowy indeks,
• nowy embedding model,
• inne chunking,
• inne top-k,
• nowe źródło dokumentów,
• zmienione permissions.

Kod agenta się nie zmienił, ale context, który dostaje, już tak.

5. Przy zmianie workflow agenta

Na przykład:

wcześniej:
implement -> test -> PR

teraz:
plan -> implement -> test -> self-review -> PR

To oczywisty kandydat do pełnego eval suite.

6. Przed releasem nowej wersji agenta

Najprostsza zasada organizacyjna:

PR / release agenta
|
v
eval suite
|
v
porównanie z baseline
|
v
quality gate
|
v
deploy

Nie każda zmiana musi uruchamiać cały kosztowny dataset.

Można mieć:

small eval suite
-> każdy PR

full regression
-> release / większa zmiana

7. Cyklicznie, nawet gdy nic nie zmieniliśmy

To ważne, bo zmienić może się coś poza repo agenta:

• model provider może zaktualizować backend,
• RAG może dostać nowe dokumenty,
• Jira / GitHub tool może zwracać trochę inne dane,
• charakter realnych tasków może się zmienić.

Dlatego warto okresowo uruchamiać regression suite, np.:

daily / weekly

w zależności od krytyczności i kosztu.

Nie ma jednej poprawnej częstotliwości.

Dla coding agenta sensowny start to:

mały zestaw -> każdy PR
pełny zestaw -> przed release
production sample -> codziennie lub co tydzień

8. Na realnych taskach produkcyjnych

Observability daje traces rzeczywistych wykonań.

Możemy pobrać np. próbkę:

5% zakończonych tasków

i automatycznie ocenić:

• task completion,
• adherence,
• tool use,
• groundedness.

To pozwala wykryć regresję, której nie było w testowym datasecie.

Przykładowy eval case

name: retry-policy

task:
  issue: PAY-123
  repository: test/payments-service

expected:
  tests_pass: true
  pull_request_created: true
  public_api_changed: false

rubric:
  - uses_company_retry_standard
  - adds_tests
  - uses_correct_rag_source

Co mierzymy deterministycznie

Normalnym kodem:

czy testy przeszły?
czy PR powstał?
czy zmieniono zabroniony plik?
czy agent użył właściwego repo?
czy wywołał niedozwolony tool?

Co może oceniać evaluator AI

Rzeczy trudniejsze do zapisania jako assert:

• czy task został rzeczywiście wykonany,
• czy agent przestrzegał instrukcji,
• czy użył właściwych tools,
• czy poprawnie wykorzystał RAG,
• czy nie wykonał zbędnych kroków,
• czy finalny output jest zgodny z oczekiwaniem.

Przykładowe metryki

Jak często naprawdę?

Nie ma sensu oceniać 100% wszystkiego zawsze.

Praktyczny model:

Evals w CI

Flow może wyglądać znajomo:

PR do repo agenta
|
v
CI
|
v
run eval dataset
|
v
compare with baseline
|
v
quality gate

Przykład:

Nowa wersja jest jakościowo lepsza, ale droższa i wolniejsza.

To pozwala podjąć świadomą decyzję.

Narzędzia na rynku

Co standaryzuje organizacja

Nie każdy agent musi mieć identyczny dataset.

Wspólne mogą być:

• minimalne wymagane metryki,
• sposób uruchamiania evals,
• standardowy mały i pełny suite,
• progi jakości,
• evaluator/judge,
• sampling produkcyjnych traces,
• dashboard,
• wymaganie przejścia quality gate przed rolloutem.

Zespół nadal definiuje przypadki specyficzne dla swojej roli.

Materiały

• Anthropic: Demystifying evals for AI agents
• Hamel Husain: Your AI product needs evals
• Microsoft Foundry: agent evaluators
• Amazon Bedrock AgentCore Evaluations
• Gen AI evaluation service