Ocena agentów i benchmarking SWE-bench

1. Przegląd koncepcji i problem systemowy

Największym zagrożeniem przy tworzeniu systemów agentowych w 2026 roku jest tak zwana «degradacja zachowań» (Behavioral Regression):

• Zmieniasz jedno zdanie w prompcie systemowym, aby agent lepiej formatował Markdown, ale niespodziewanie przestaje on wywoływać narzędzie do odczytu plików.
• Migrujesz z modelu v1.2 na v1.3, a agent zaczyna generować dwukrotnie więcej błędnych komend shell.
• Bez automatycznych testów projekty agentowe stają się «szamanizmem», gdzie deweloperzy oceniają jakość systemu za pomocą dwóch-trzech ręcznych zapytań w czacie.

Agent Evals to dyscyplina inżynieryjna przenosząca klasyczne zasady TDD oraz CI/CD do świata niedeterministycznych agentów językowych. Pozwala ona ilościowo mierzyć skuteczność (Pass Rate), koszt w tokenach (Cost per Task) oraz czas wykonania (Latency).

2. Taksonomia architektoniczna i model mentalny

┌─────────────────────────────────────────────────────────────┐
│                 TAKSONOMIA OCENY AGENTÓW                    │
├─────────────────────────────────────────────────────────────┤
│ 1. Oceny oparte na stanie (Stan końcowy środowiska):        │
│    • Testy jednostkowe / integracyjne zaliczone             │
│      (pytest, vitest == 0)                                  │
│    • Weryfikacja różnic w systemie plików                   │
│      (czy utworzono wymagane pliki?)                        │
├─────────────────────────────────────────────────────────────┤
│ 2. Oceny oparte na trajektorii                              │
│    (Ocena ścieżki rozumowania):                             │
│    • Dokładność wywołań narzędzi                            │
│      (czy wywołano właściwe narzędzie?)                     │
│    • Efektywność kroków                                     │
│      (w ilu krokach osiągnięto cel?)                        │
│    • Kara za redundantne działania                           │
│      (kary za powtórzenia)                                  │
├─────────────────────────────────────────────────────────────┤
│ 3. Oceny LLM-as-a-Judge                                     │
│    (Semantyczna weryfikacja przez sędziego):                │
│    • Ton odpowiedzi i zgodność z przewodnikami stylu       │
│    • Kompletność i zgodność z wymogami bezpieczeństwa       │
├─────────────────────────────────────────────────────────────┤
│ 4. Oceny zasobów i ekonomiczne:                             │
│    • Zużycie tokenów na rozwiązany problem                  │
│    • Rzeczywisty czas wykonania (wall-clock time)           │
└─────────────────────────────────────────────────────────────┘

3. Pipeline techniczny i mechanika wewnętrzna

Typowy framework do oceny agentów (np. Inspect AI, Braintrust lub własny Docker Harness) działa według następującego cyklu:

1. Test Environment Reset: Uruchomienie izolowanego kontenera Docker z początkowym commitem kodu źródłowego, w którym występuje badany błąd.
2. Task Provisioning: Agent otrzymuje wyłącznie opis problemu (issue.md).
3. Agent Trajectory Recording: Agent wykonuje komendy, czyta pliki i wprowadza zmiany. Wszystkie kroki są zapisywane w formacie OpenTelemetry / JSONL (trajektoria działań).
4. Harness Evaluation:
   • Orkiestrator pobiera wygenerowany git diff.
   • Uruchamiane są ukryte testy weryfikacyjne (testy Fail-to-Pass).
   • Rejestrowany jest status: RESOLVED, FAILED, TIMEOUT lub OUT_OF_BUDGET.
5. Metric Aggregation: Obliczany jest ogólny odsetek rozwiązanych zadań (Resolve Rate) dla danej wersji release agenta.

4. Praktyczne scenariusze inżynieryjne w środowisku produkcyjnym

01. Bramka CI/CD dla aktualizacji promptów agentowych

Przed scaleniem zmian w pliku .cursorrules lub prompcie systemowym w repozytorium uruchamiana jest akcja GitHub z 30 syntetycznymi testami. Jeśli agent rozwiązuje mniej niż 90% zadań, pull request jest automatycznie blokowany.

02. Wybór dostawcy modeli kryterium ROI

Zespół ocenia: czy warto płacić $15 za milion tokenów za topowy model, czy wystarczy nowy otwartoźródłowy model za $0.50? Uruchomienie ewaluacji na własnych 100 zadaniach pokazuje precyzyjne dane: topowy model rozwiązuje 78% zadań, tani – 74%, ale jest 20 razy tańszy.

5. Pułapki, typowe błędy i bezpieczeństwo

• Contamination (Zanieczyszczenie danych treningowych): Publiczne benchmarki (np. bazowy HumanEval) trafiają do danych treningowych świeżych modeli, przez co model «pamięta» poprawną odpowiedź, ale nie potrafi rozumować. Korzystaj wyłącznie z własnych zamkniętych zestawów ewaluacyjnych lub SWE-bench Verified z ciągle aktualizowanymi zadaniami.
• Flaky Evals (Niesterowne testy): Niedeterminizm wynikający z temperatury modelu może dawać 80% sukcesu w jednym przebiegu i 65% w innym. Konieczne jest przeprowadzenie co najmniej 3–5 przebiegów.
• Overfitting do benchmarków: Optymalizacja agenta pod kątem konkretnego zestawu testowego prowadzi do utraty zdolności generalizacji w rzeczywistych scenariuszach biznesowych.