Hét hónappal ezelőtt eldöntöttük, hogy szükségünk van egy dedikált evaluator csapatra. Nem QA — a QA azt teszteli, amit megírtál. Az evaluator csapat azt teszteli, amit a motor csinál, akkor is, ha azt te magad sem tudod, mit csinál pontosan. Ez egy poszt arról, hogy ki van benne, mit mérnek, és miért 96% a megfogott regressziók aránya, nem 100%.
A csapat
Három mérnök, egy product, nulla manager. A három mérnök közül kettő ML-háttérrel jött (ranking, gépi tanulás-mérés), egy klasszikus backend-mérnök, aki a tooling-ot építi. A product azt csinálja, amit a product szokott: ügyfél-prioritást fordít eval-prioritássá. A nulla manager nem ideológia — a csapat 4 fő, egy negyedéves OKR-ral és egy heti szinkronnal. Egy ötödik ember manager-szerepe csak overhead lenne.
A KPI
Egyetlen szám: a production-ba kerülő regresszió-bug-ok közül hányat fogtak meg az eval-suite-ban a release előtt. Cél: 100%. Elért: 96% (7 hónapos gördülő ablakon). Ami nem stimmel az utolsó 4%-ban: az új ügyfél-üzeneti minták (out-of-distribution input), amiket az eval-fixtures még nem fednek. Erre folyamatos „production traffic replay”-jel reagálunk.
Az eval-suite alakja
412 fixture jelenleg, 14 doménre osztva (sales, support, billing, voice, kódolás, vizualizáció, klasszifikáció, stb.). Minden fixture egy bemenet + egy elvárt-tulajdonság leírás, NEM egy elvárt karakter-pontos kimenet. Példa: „A válasz nem tartalmazhatja a »garantáljuk« szót.” VAGY „A válasz formátuma JSON, és tartalmaz confidence mezőt 0 és 1 között.” VAGY „Ha a felhasználó kódot kér, a válaszban legyen legalább egy code fence.” Az evaluator a tulajdonságokat ellenőrzi LLM-as-judge mintával (külön, ellenőrzött modell) és deterministic checkerekkel ahol lehet.
A scoring egy súlyozott átlag a 412 fixture-en. A regression-gate akkor billen, ha a score legalább 2 százalékpontot esik egyetlen doménen. Doménenként, nem aggregáltan — mert egy 50%-os esés egy doménen sose mutatkozik meg a teljes átlag 0.5%-os csökkenésében.
Production traffic replay — a péntek esti rituálé
Minden péntek este egy worker leveszi az elmúlt heti production trace-ek 0.5%-át (deidentifikálva), és lefuttatja az aktuális motor-konfiguráción. Az eredményt összeveti az eredeti production-válasszal egy LLM-as-judge segítségével: „Ez a két válasz funkcionálisan egyenértékű? Ha nem, melyik jobb?” A különbségek bekerülnek egy hétfői review-pad ülésre, ahol a csapat eldönti: ez bug, ez improvement, ez nem szignifikáns. A bug-ok új fixture-ré válnak, a improvementeket dokumentáljuk, a nem-szignifikánsakat eldobjuk.
A replay-nek köszönhetően az elmúlt négy hónap legnagyobb regresszióját négy nappal a production-into kerülése ELŐTT fogtuk meg. A motor-config változás (egy router-szabály finomhangolás) a péntek esti replay-en 17%-os hangnem-drift-et mutatott egy support-domén-fixture csoporton; visszadobtuk a változást, újrahangoltuk, hétfőn újra replay, ezúttal tiszta. Hétfő délután ment csak prod-ra.
Amit nem tudunk megfogni
A modell-szolgáltató oldali viselkedés-drift. Amikor egy LLM-szolgáltató csendben módosítja a modellt (ami megtörténik, gyakran a verziószám megváltoztatása nélkül), a viselkedés egyik napról a másikra változhat. Erre csak a folyamatos production-monitorozás ad választ, és a quick rollback. Ez nem evaluator-probléma — ez ipari realitás. Erről egy következő poszt.
A kulturális rész
Az első hónapban egyetlen dolog nem működött: az, hogy az eval-eredményt egy pass/fail kapunak kezeltük, ami valaki más PR-jében landolt. Egy mérnök shipelt egy router-változtatást, a kapu billent, és egy Slack-szál bontakozott ki órákon át arról, hogy a fixture rossz-e vagy a változtatás. Erre váltottunk: bármelyik mérnök, aki a routerhez vagy a prompt chain-hez nyúl, 9 perc alatt lefuttathatja az egész suite-ot lokálisan, és az eredmény a PR-leírás része. Az evaluator csapat birtokolja a fixture-eket, de minden mérnök birtokolja a futtatást. A Slack-szál viták két hét alatt eltűntek.
A per-tenant subset a másik bevált igazítás. Egy változtatás, ami globálisan 1%-ot javít, de egy tenant doménjén 7%-ot ront, az regresszió annak a tenantnek, pont. A per-tenant scoring boardok minden tenant Grafana mappájában ki vannak tűzve, és az on-call-rotáció ugyanolyan figyelmesen nézi őket, mint a latenciát. Az evaluator csapat negyedéves OKR-je tartalmaz egy „nulla tenant-szintű regresszió a production-ben 24 óránál hosszabb ideig” célt — három negyedév telt el, a sorozat él.