Vaš AI agent nema testove
Cijeli kod ima sigurnosnu mrežu osim onog dijela koji donosi odluke. Zašto se ne-deterministički agent ipak testira eval harnessom — golden set, provjerena svojstva, ocjena koja je gate u CI-ju — i zašto je to druga garancija od auditabilnog loga.
Svaki dio vašeg koda ima testove, osim onog koji donosi odluke. Prošli tjedan ste promijenili prompt i pustili ga u produkciju. Promijenili ste model provider da smanjite trošak. Podigli ste verziju jedne biblioteke. Je li nešto regrediralo? Na slučajevima koji su kupcu stvarno bitni — nagađate. To je normalno stanje većine agenata u produkciji: pušteni, promatrani u logovima, nikad testirani. Lako je kriviti tehnologiju — agent je ne-deterministički, pa se testiranje čini nemogućim. To je pogrešan zaključak, i skup je.
Ne-determinizam ne znači da se ne može testirati
Klasičan unit test provjerava točan output: za ovaj ulaz vrati točno to. S jezičnim modelom to ne možete, jer isti prompt svaki put može dati druge riječi. Ali "nema provjere točnog podudaranja" nije isto što i "nema provjere". I dalje možete provjeravati svojstva, a upravo tu žive pravi zahtjevi. Je li agent pozvao pravi tool, s argumentima u granicama? Je li output ostao unutar ugovora koji ste obećali pozivatelju — valjan JSON, polja koja vaš parser očekuje, ništa viška? Je li odbio zahtjev koji mora odbiti? Je li ocjena ušla u toleranciju na reprezentativnom skupu, a ne na jednom probranom primjeru? Ne-determinizam uklanja provjeru točnog podudaranja. Ne uklanja mogućnost da se testira ponašanje. Prelazi se s testiranja bajtova na testiranje invarijanti.
Eval harness
Dajmo ime dijelu koji nedostaje: eval harness, i tretirajmo ga kao svaki drugi test projekt u repozitoriju. Ima tri dijela. Prvo, golden set — fiksna, verzionirana zbirka reprezentativnih ulaza, koja namjerno uključuje ružne rubne slučajeve koji pucaju u produkciji, a ne samo sretan put iz demoa. Drugo, očekivana svojstva po slučaju: ne jedan blagoslovljen odgovor, nego invarijante koje moraju vrijediti. Treće, ocjena koja se pokreće automatski — na svaku promjenu prompta, svaki model bump, svaki update ovisnosti — unutar CI-ja, spojena kao gate koji ruši build kad broj padne. Ocjenjivanje mogu biti točne provjere gdje je output strukturiran, tvrdnje o obliku i o korištenju toolova, te LLM-as-judge za doista nejasne dijelove, uz pošteno upozorenje da je i sudac model koji treba kalibrirati i fiksirati. Bez toga, "poboljšali smo prompt" je osjećaj izrečen na sastanku. S tim, to je broj, a regresija postaje nešto što uhvatite na pull requestu umjesto na tiketu podrške.
Dvije garancije, ne jedna
Ovdje dolazimo do pitanja koje firma u regiji postavi prije nego što agent priđe novcu, predmetima ili podacima klijenata: možete li dokazati što je učinio, i možete li pokazati da je bio u pravu? To su dvije različite garancije, a spajanje se plaća. Nepromjenjiv, usidren decision log dokazuje što je agent učinio i kada — povijest otporna na manipulaciju, koju treća strana može provjeriti bez povjerenja u vašu bazu. Eval suite dokazuje nešto drugo: da je ponašanje ispravno, i da je ostalo ispravno nakon promjene. Jedno je odgovornost, drugo je kvaliteta. Revizor i strani partner ne traže obećanje da sustav radi — traže dokaz. Za sustav visokog rizika eval suite je upravo taj dokaz: ne obećanje, nego ponovljiva mjera koju možete pokazati na skupu koji stoji uz kod.
Ništa od ovoga nije glamurozno. To je ista disciplina koja je klasičan softver učinila sigurnim za mijenjanje, primijenjena na komponentu koja je slučajno ne-deterministička. Firme koje će za godinu dana mirno održavati agente su one koje harness grade sada, dok je agent još dovoljno malen da stane u jedan.
Kad vam noćas model provider izbaci tihi update, što puca u vašem agentu — i bi li vas išta na to upozorilo prije vaših korisnika?