Kā novērtēt MI aģentus: testu kopas, vērtētāji un regresijas pārbaudes

Aiz katra izcila mākslīgā intelekta produkta slēpjas spēcīgs MI aģentu novērtēšanas process, ko dēvē par novērtējumiem jeb evals, kas laikus atklāj kļūdas un nodrošina pareizu aģenta darbību. Novērtējumi ir īpaši svarīgi MI aģentiem, kas kāda vārdā veic augsta riska darbības, piemēram, naudas atmaksu.

Šāda procesa izveidei nepieciešamas zināmas tehniskās zināšanas un datu analīzes prasmes. Taču tas nebūt nav tik biedējoši vai nepieejami, kā varētu šķist. Lai palīdzētu jums sākt, esam apkopojuši sešus praktiskus soļus MI aģentu novērtēšanai, kā arī izplatītus maldīgus priekšstatus, kas šo procesu izjauc.

Ko nozīmē novērtēt MI aģentu?

MI aģenta novērtēšana nozīmē izvērtēt, cik pareizi tas izpilda uzdevumus un vai tā lēmumi atbilst organizācijas prasībām. Praktiski MI aģentu novērtējumi jeb evals ir konkrēti rādītāji, kas palīdz organizācijām noteikt, vai aģents darbojas pietiekami uzticami paredzētajai lomai.

Iedomājieties MI iepirkumu aģentu ražotnē, kas pārbauda rezerves daļu krājumus un sagatavo papildināšanas pieprasījumus. Ja apstiprināta detaļa nav pieejama vai piegādātāja informācija ir novecojusi, vai aģents ziņos par problēmu vai ieteiks neapstiprinātu aizstājēju?

Un, ja mainīsiet tā sistēmas uzvedni, lai novērstu šo problēmu, kā zināsiet, ka neesat radījuši jaunu?

Bez novērtēšanas produktu vadītājiem būtībā atliek tikai minēt. Tāpēc novērtējumi sniedz atgriezenisko saiti, ar kuras palīdzību var mērīt veiktspēju, pamanīt atkārtotas problēmas un ar lielāku pārliecību testēt izmaiņas.

Jāpiebilst, ka aģenta novērtēšana var aptvert vairākus izpildes aspektus:

• Gala rezultāta kvalitāte
• Aģenta izmantotā informācija
• Rīki, ko tas izsauca
• Vai tas ievēroja noteikumus, kas regulē tā darbību

Izplatītākie MI aģentu novērtēšanas rādītāji

Novērtējumos izmanto kvalitatīvus un kvantitatīvus datus. Kvalitatīvā novērtēšana palīdz saprast, kas notiek un kāpēc, tostarp manuāli pārskatot aģenta lēmumus. Kvantitatīvā novērtēšana pārvērš šos novērojumus izmērāmos signālos, piemēram, saskaitot konkrētu kļūmju veidu biežumu vai aprēķinot uzdevumu sekmīgas izpildes rādītājus.

Šeit ir galveno MI aģentu novērtēšanas rādītāju saraksts:

• Uzdevuma sekmīgums mēra, vai aģents sasniedza paredzēto iznākumu; parasti to izsaka kā procentuālo daļu no izpildēm, kas sniedz derīgus rezultātus.
• Darbību pareizība mēra, vai aģents izmantoja rīkus atbilstoši, izvēlējās derīgus argumentus un ievēroja atļaujas.
• Atbildes kvalitāte novērtē, vai gala rezultāts ir precīzs, pilnīgs un noderīgs. Tā var ietvert faktu pareizību, norādījumu ievērošanu un to, vai aģents pamato savus lēmumus ar pieejamo informāciju.
• Uzticamība mēra konsekvenci atkārtotos mēģinājumos, ar dažādiem ievaddatiem un robežgadījumos.
• Izmaksas un aizture mēra resursus, kas nepieciešami veiksmīga rezultāta sasniegšanai, tostarp izpildes laiku, tokenu patēriņu un rīku izsaukumus.

Atkarībā no tā, ko mērāt, novērtējumi var izvērtēt aģenta pilna cikla veiktspēju, tā izpildes trajektoriju vai atsevišķus komponentus, piemēram, rīku izsaukumus un informācijas izgūšanas soļus.

1. solis: nosakiet, kā izskatās veiksmīga aģenta izpilde

Vispirms skaidri aprakstiet, kas aģentam jāpaveic, – produkta prasības. Izklausās pašsaprotami, taču tas var būt pārsteidzoši grūti. Šai parādībai pat ir nosaukums: specifikācijas plaisa.

Lūk, kā tam pieiet, iesaka mūsu vecākais datu zinātnieks Andrey Khomutov:

„Sāciet ar diviem jautājumiem: „Kas tiktu uzskatīts par uzdevuma izpildi?” un „Kas padarītu šķietami veiksmīgu izpildi par nepieņemamu?”

Aģentu gadījumā no tehniskā viedokļa tas nozīmē pārbaudīt gan rezultātu, gan to, kā aģenti pie tā nonāca.”

Aģents var sniegt pareizo atbildi, piekļūstot noplūdušai atbilžu atslēgai, vai uzdevuma izpildes laikā veikt neatļautas darbības. Khomutov norāda, ka atbilžu noplūde un nedrošas darbības novērtēšanas laikā ir konkrēti iemesli, kāpēc nevajadzētu spriest tikai pēc gala atbildes.

„Es sagaidu, ka trajektorijas pārbaude kļūs par aģentu novērtēšanas komplektu standarta sastāvdaļu, nevis būs kaut kas, ko darām tikai tad, kad rezultāts šķiet aizdomīgs,” viņš piebilst.

Pēc tam iesaistiet jomas ekspertu, lai apstiprinātu jūsu veiksmes kritērijus. Cilvēki ar praktiskām zināšanām konkrētajā jomā var pateikt, vai MI aģentam izvirzītie nosacījumi atspoguļo veiksmīgu iznākumu.

2. solis. Izveidojiet testu kopu no reāliem uzdevumiem un kļūmēm

Izpētiet aģenta faktisko uzvedību, lai saprastu, kā izskatās laba un slikta veiktspēja. Nepadodieties kārdinājumam sākt, ģenerējot desmitiem testu, kas balstīti tikai uz jūsu pieņēmumiem par to, kas varētu noiet greizi.

Hamel Husain, Parlance Lab ML inženieris, un Shreya Shankar, ML sistēmu un lietišķo MI novērtējumu pētniece, iesaka sākt ar kļūdu analīzi — paņēmienu, kas aizgūts no mašīnmācīšanās un datu zinātnes. Process sākas ar aģenta izpildes izsekojumu kvalitatīvu analīzi; izsekojumi ir ieraksti, kuros redzami lietotāja ievaddati, rīku izsaukumi, izgūtā informācija un aģenta izvaddati.

1. Pārskatiet atsevišķus izsekojumus un anotējiet kļūdas (atvērtā kodēšana). Uzdodiet jomas ekspertam pārbaudīt aģenta izpildes un īsi pierakstīt novērojumus par to, kas nogāja greizi. Koncentrējieties uz pirmo būtisko kļūdu.
2. Grupējiet novērojumus pēc kļūmju veidiem (aksiālā kodēšana). Kad piezīmju ir pietiekami daudz, izmantojiet LLM, lai tas ieteiktu kategorijas līdzīgām kļūdām. Tās var ietvert nesaderīgu detaļu ieteikumus, neprecīzu krājumu datu izgūšanu un neizdevušos nodošanu cilvēkam.
3. Saskaitiet gadījumus. Piesaistiet katru novērojumu kādai kategorijai, pēc tam izmantojiet izklājlapu vai rakurstabulu, lai aprēķinātu, cik bieži parādās katrs kļūmes veids.
4. Nosakiet, ko risināt vispirms, ņemot vērā gan biežumu, gan nopietnību.
5. Pārvērtiet būtiskas kļūmes testa gadījumos. Saglabājiet attiecīgos ievaddatus, sākuma nosacījumus, sagaidāmo iznākumu un vērtēšanas kritērijus, lai aģentu varētu atkārtoti testēt tajā pašā scenārijā.

Cik izsekojumu jāizpēta? Aptuveni 100, taču maģiska skaitļa nav. Apstājieties agrāk, tiklīdz sasniedzat teorētisko piesātinājumu: brīdi, kad papildu izsekojumu pārskatīšana vairs neatklāj būtiskus jaunus kļūmju modeļus.

Lietotne vēl nav palaista? Sākotnējo testu kopu palīdzēs izveidot sintētiski piemēri, taču, tiklīdz kļūst pieejami reāli lietotāju dati, tie jāizmanto tās pilnveidošanai.

Etalontestu izmantošana MI aģentu novērtēšanā

Papildus saviem testa gadījumiem aģenta spēju novērtēšanai varat izmantot esošus standartizētu novērtēšanas uzdevumu krājumus, ko dēvē par etalontestiem.

Taču etalontesti nav nekļūdīgi. SWE-bench auditi, Epoch AI etalontestu pārskati un TheoPhysEval sākotnēji noraidītās pareizās atbildes ilustrē, kā kļūdaini uzdevumi vai sagaidāmās atbildes var izkropļot novērtēšanas rezultātus.

Khomutov iesaka izvēlēties aktuālus, jūsu jomai atbilstošus etalontestus un izpētīt pārsteidzošus panākumus vai neveiksmes, pirms uzskatīt rezultātus par ticamu aģenta veiktspējas pierādījumu.

3. solis. Darbiniet aģentu atkārtojamā testa vidē

Atkārtojama testa vide ir kontrolēta konfigurācija, kurā varat darbināt MI aģentu ar tiem pašiem testa gadījumiem tādos pašos sākuma apstākļos un salīdzināt rezultātus. Tā ietver testa gadījumu mapi, Python skriptu, kas palaiž aģentu, vai pārbaužu kopu, kas izvērtē rezultātus.

Varat sākt, saglabājot reprezentatīvus ievaddatus JSON failos un izmantojot Python skriptu, lai izpildītu aģenta darbplūsmu un pārbaudītu tā izvaddatus ar apgalvojumiem (assertions). Mūsu ražotnes krājumu aģentam atkārtojama testa vide varētu izskatīties šādi:

Izvērst

Lai izveidotu atkārtojamu testa vidi, veiciet šādas darbības:

1. Saglabājiet reprezentatīvus ievaddatus. Glabājiet faktiskos notikumus vai testa gadījumus tādā pašā struktūrā, kādā tos saņem jūsu lietotne produkcijas vidē. Mūsu scenārijā jūs kā JSON failu saglabātu tehniskās apkopes pieprasījumu ar iekārtas ID, nepieciešamo rezerves daļu un apkopes datumu, kopā ar krājumu un apstiprināto detaļu datu momentuzņēmumu.
2. Izpildiet darbplūsmu. Apstrādājiet katru ievadi ar aģentu, ieskaitot tā informācijas izgūšanas soļus, rīku izsaukumus un atbildes ģenerēšanu.
3. Ierakstiet rezultātu un izsekojumu. Saglabājiet gala izvaddatus un būtiskās starpdarbības (piemēram, krājumu uzmeklēšanu), lai redzētu ne tikai to, vai aģents kļūdījās, bet arī kur.
4. Atkārtojiet gadījumus atkarībā no kļūmes nopietnības, biežuma un problēmas novēršanas sarežģītības. LLM lietotnes ir nedeterministiskas (no identiskiem ievaddatiem tās var radīt atšķirīgus rezultātus), tāpēc viena veiksmīga izpilde negarantē, ka arī nākamā būs veiksmīga. Norādiet veiksmīgo mēģinājumu īpatsvaru un izpētiet kļūmes.

Attiecībā uz to Khomutov iesaka mērīt pass@1 (cik bieži aģents gūst panākumus ar vienu mēģinājumu) un pass@k (varbūtību vismaz vienreiz gūt panākumus noteiktā mēģinājumu skaitā). Ja ziņojat par pass@k, norādiet mēģinājumu skaitu, jo viena pareiza atbilde starp vairākām nenozīmē, ka aģents zina, kuru no tām izvēlēties.

Lietotnei augot, izmantojiet testēšanas ietvaru, piemēram, pytest, lai organizētu un palaistu testus, un apsveriet iespēju lielas testu datu kopas un rezultātus glabāt datubāzē.

4. solis. Izvēlieties katrai pārbaudei piemērotu vērtētāju

Vērtētājs (bieži saukts arī par novērtētāju) ir mehānisms — koda fragments, LLM, ko vada vērtēšanas rubrika, vai cilvēks pārskatītājs —, kas pārbauda aģenta izvaddatus vai darbību pēc noteikta kritērija. Vērtētājs atgriež spriedumu „izturēts/neizturēts” un skaidrojumu, kas norāda uz attiecīgajiem pierādījumiem.

Informācija: Vērtēšanas rubrika ir kritēriju un norādījumu kopa, kas nosaka, kas uzskatāms par pareizu vai pieņemamu rezultātu.

Piemērotais vērtētāja veids ir atkarīgs no tā, ko vēlaties pārbaudīt. Lūk, kā salīdzināmas visas trīs pieejas:

Dažkārt dažādiem vienas izpildes aspektiem var būt nepieciešamas atšķirīgas novērtēšanas metodes, tāpēc vērtētājus var nākties kombinēt.

Kā kombinēt vērtētājus?

Uzdodiet sev jautājumu: „Vai rezultātu var pārbaudīt pēc zināma noteikuma vai sagaidāmās vērtības, vai arī tam nepieciešams cilvēkam līdzīgs spriedums?”

• Ja rezultātu var pārbaudīt precīzi, sāciet ar uz koda balstītu vērtētāju. Uz koda balstīti vērtētāji var pārbaudīt arī strukturētus izvaddatus, lauku vērtību derīgumu, rīku argumentus vai datubāzes gala stāvokli.
• Ja pārbaudei nepieciešama konteksta interpretācija, izmantojiet pieeju LLM kā tiesnesis.
• Jomai specifiskiem vai strīdīgiem lēmumiem izmantojiet cilvēkus pārskatītājus.

Svarīgi! LLM vērtētājs var nepareizi interpretēt pierādījumus vai kļūdaini piemērot rubriku. Tāpēc nepieciešams papildu novērtēšanas solis: kalibrēšana pret cilvēku spriedumiem.

Kalibrējiet LLM vērtētāju pret cilvēku spriedumiem.

Būtībā kalibrēšanai nepieciešams, lai jomas eksperts novērtētu faktiskas aģenta izpildes. Pēc tam eksperts salīdzina savus spriedumus ar LLM spriedumiem un, balstoties uz atšķirībām, pilnveido vērtēšanas rubriku.

Lūk, piecu soļu vērtētāja kalibrēšanas process:

1. Savāciet aģenta ievaddatu, izvaddatu un attiecīgo izsekojumu piemērus.
2. Uzdodiet jomas ekspertam neatkarīgi novērtēt, vai katrs piemērs atbilst novērtēšanas kritērijam.
3. Palaidiet LLM vērtētāju ar šiem piemēriem.
4. Salīdziniet cilvēka un modeļa spriedumus.
5. Izpētiet atšķirības un pilnveidojiet vērtētāja rubriku, pirms to testējat ar jauniem piemēriem.

Khomutov uzsver arī to, cik svarīgi ir atsevišķi pārbaudīt LLM vērtētāja konsekvenci:

„Iedodiet tam vairākas reizes vienu un to pašu saglabāto izpildi un failus, nepalaižot aģentu atkārtoti. Tā varat nodalīt aģenta darba atšķirības no vērtēšanas atšķirībām.”

Ja viens un tas pats izvads saņem atšķirīgus spriedumus, nepieņemiet, ka katra vērtējuma izmaiņa ir aģenta radīta. Tā vietā izpētiet kļūdu matricu, kas parāda, kad vērtētājs pareizi identificēja kļūdas, kad tās palaida garām un kad kļūdaini atzīmēja pieņemamus izvaddatus.

Cilvēka veikta pārskatīšana joprojām ir būtiska, lai noteiktu atsauces spriedumus, atrisinātu strīdīgus gadījumus un atklātu jaunus kļūmju veidus, kuru noteikšanai esošie vērtētāji nav paredzēti.

5. solis. Salīdziniet versijas un veiciet regresijas pārbaudes

Pieņemsim, ka kļūdu analīze atklāj, ka jūsu krājumu aģents bieži iesaka neapstiprinātas rezerves daļas. Jūs maināt tā sistēmas uzvedni, pieprasot skaidru saderības pārbaudi. Sākotnēji neizturētais gadījums tagad ir izturēts. Taču kā zināt, ka izmaiņas nav ietekmējušas citus uzdevumus?

Tieši šeit noder regresijas testēšana.

Regresijas testēšana nozīmē iepriekš veiksmīgu testa gadījumu atkārtotu palaišanu pēc aģenta uzvednes, modeļa vai darbplūsmas maiņas, lai pārliecinātos, ka izmaiņas nav radījušas jaunas kļūmes.

1. Atveidojiet sākotnējo kļūmi, izmantojot saglabātus ievaddatus no testu kopas.
2. Veiciet mērķtiecīgas izmaiņas uzvednē, modelī vai darbplūsmā.
3. Atkārtoti palaidiet neizturēto testu, lai pārbaudītu, vai problēma ir novērsta.
4. Palaidiet pārējos testus, lai pārliecinātos, ka izmaiņas nav sabojājušas iepriekš veiksmīgi strādājošo funkcionalitāti.
5. Pārbaudiet rezultātus un izpētiet visas jaunās kļūmes.

Lai iegūtu precīzus rezultātus, salīdziniet bāzes versiju un atjaunināto aģentu, izmantojot tos pašus testa gadījumus un vērtēšanas kritērijus.

6. solis: uzraugiet MI aģenta veiktspēju ražošanas vidē

Aģenta novērtēšana nebeidzas pēc lietojumprogrammas izvietošanas. Kā skaidro Husain un Shankar, tos pašus vērtētājus, ko izmantojat izstrādes laikā, var palaist arī ar reāliem ražošanas vides datiem, lai mērītu, kā jūsu aģents darbojas laika gaitā.

To sauc par tiešsaistes novērtēšanu, un tā ir daļa no plašāka ražošanas vides uzraudzības procesa, kas palīdz atklāt atkārtotas un iepriekš nezināmas kļūmes.

Process ir iteratīvs un ietver četras savstarpēji papildinošas darbības:

• Izmantojiet kalibrētus LLM tiesnešus ražošanas vides izpildes pierakstu vērtēšanai. Atlasiet reālu aģenta mijiedarbību paraugus un piemērojiet vērtētājus, kurus jau esat validējuši, salīdzinot ar cilvēku vērtējumiem.
• Sekojiet līdzi kļūmju biežumam laika gaitā. Izmantojiet kļūdu analīzes laikā noteiktās kļūmju kategorijas, lai kvantitatīvi novērtētu atkārtotās problēmas.
• Turpiniet manuāli pārskatīt izpildes pierakstus. Automatizētie vērtētāji atklāj tikai tās problēmas, kuru noteikšanai tie ir izstrādāti. Manuāli pārbaudiet reālu aģenta mijiedarbību paraugus, lai atklātu jaunas kļūdas vai neparastus lietotāju pieprasījumus.
• Izmantojiet A/B testēšanu, lai mērītu biznesa rezultātus (tikai tad, ja tas ir lietderīgi). Salīdziniet dažādas uzvednes, modeļus vai darbplūsmas, izmantojot tādus rādītājus kā uzdevumu izpilde, lietotāju apmierinātība un problēmas atrisināšanas laiks. Šis process palīdz noteikt, vai izmaiņas uzlabo faktisko produkta pieredzi, ne tikai to, vai tiek izturēti atsevišķi testi.

Viena svarīga piezīme: novērtējumiem nav jābūt noslīpētiem līdz pilnībai. Tiem vienkārši jābūt pietiekami labiem, lai uzlabotu jūsu produktu.

Izplatīti maldīgi priekšstati par MI aģentu novērtēšanu

• Novērtējumi ir tikai vienībtesti. Tā nav — vienībtesti ir nelielas, automatizētas pārbaudes, kas ir tikai viena no novērtēšanas daļām. Novērtējumi ietver arī kvalitatīvu kļūdu analīzi, cilvēku vērtējumus, ražošanas vides uzraudzību un eksperimentus, lai mērītu lietojumprogrammas kvalitāti.
• Novērtēšanas platforma var visu izdarīt jūsu vietā. Gatavi rīki var automatizēt dažas pārbaudes, taču tie nevar noteikt, kuri kļūmju veidi (kļūdu tipi vai nevēlama aģenta uzvedība) ir svarīgi jūsu produktam.
• Visu novērtēšanu var uzticēt LLM. Tā ir liela maldīšanās. Cilvēku vadīta kļūdu analīze un vērtētāju kalibrēšana joprojām ir būtiskas, jo LLM trūkst biznesa konteksta, kas nepieciešams, lai atklātu visas problēmas.
• A/B testēšana vai vienkārši aģenta lietošana aizstāj novērtējumus. Nepareizi. A/B testi var parādīt, kura versija darbojas labāk pēc izvēlētajiem rādītājiem, taču paši par sevi tie nevar izskaidrot pamatā esošās problēmas.

Bieži uzdotie jautājumi par MI aģentu novērtēšanu

1. Kāda ir atšķirība starp MI aģentu novērtēšanu un LLM novērtēšanu?

LLM novērtēšana mēra, cik labi valodas modelis veic konkrētu uzdevumu, piemēram, atbild uz jautājumu, apkopo dokumentu vai izgūst informāciju. MI aģentu novērtēšana izvērtē sistēmu, kas patstāvīgi izpilda vairākus soļus, lai paveiktu uzdevumu.

Atšķirībā no tipiskas LLM novērtēšanas aģenta novērtēšana pārbauda gan gala rezultātu, gan tā sasniegšanai veikto darbību secību, tostarp rīku izsaukumus, lēmumus un iepriekš noteiktu noteikumu ievērošanu.

2. Galvenie MI aģentu novērtēšanas rādītāji

MI aģentu novērtēšanas rādītāji iedalāmi divās plašās kategorijās:

• Tehniskās veiktspējas rādītāji: uzdevumu sekmīgas izpildes īpatsvars, darbību pareizība, atbilžu kvalitāte, uzticamība (pass@1 un pass@k), latentums, marķieru patēriņš un izmaksas par katru sekmīgi izpildītu uzdevumu.
• Biznesa un lietotāju pieredzes rādītāji: klientu apmierinātība (CSAT), problēmu atrisināšanas līmenis, eskalāciju līmenis, konversijas līmenis, uzdevumu izpildes laiks un citi aģenta lomai specifiski rezultāti.

Piemēram, klientu atbalsta aģentu varētu vērtēt pēc sekmīgas problēmu atrisināšanas un klientu apmierinātības, savukārt MI iepirkumu aģentu — pēc krājumu papildināšanas pieprasījumu precizitātes, apstiprināšanas rādītājiem un iepirkuma cikla ilguma.

Piemērotajiem rādītājiem jāatspoguļo gan tas, cik uzticami aģents darbojas, gan tas, vai tā darbs uzlabo biznesa rezultātus.

3. Kādi ir labākie rīki MI aģentu novērtēšanai?

Bieži izmantotie risinājumi:

• Testēšanas ietvari: Python apgalvojumi (assert) un pytest ir noderīgi, lai palaistu atkārtojamus testa gadījumus un pārbaudītu precīzus nosacījumus, piemēram, vai aģents izvēlējās pareizo rīku vai atgrieza derīgu detaļas ID.
• MI aģentu novērtēšanas ietvari: DeepEval un Google agent-eval rīkkopa atbalsta sarežģītākus novērtējumus, tostarp izpildes pierakstu analīzi, uz LLM balstītus vērtētājus un automatizētu regresijas testēšanu.
• Novērtēšanas un novērojamības platformas: LangSmith, Arize Phoenix un MLflow palīdz komandām pārbaudīt aģentu uzvedību, pārvaldīt novērtēšanas datu kopas, salīdzināt aģentu versijas un uzraudzīt veiktspēju ražošanas vidē.

4. Kā automatizēt MI aģentu novērtēšanu?

MI aģentu novērtēšanu var automatizēt, izveidojot atkārtojamus testus, izmantojot automatizētus vērtētājus un integrējot šīs pārbaudes izstrādes un ražošanas darbplūsmās:

1. Izveidojiet novērtēšanas datu kopu: apkopojiet reprezentatīvus lietotāju uzdevumus, sagaidāmos rezultātus, zināmās kļūmes un aģenta izpildes pierakstus. Iekļaujiet robežgadījumus, piemēram, neizdevušos rīku izsaukumus, trūkstošu informāciju un neatļautas darbības.
2. Automatizējiet testu izpildi un vērtēšanu: izmantojiet tādus ietvarus kā pytest vai DeepEval, lai palaistu testa gadījumus un piemērotu uz kodu balstītas pārbaudes vai LLM vērtētājus. Pirms paļaujaties uz LLM vērtētāju piešķirtajiem rezultātiem, validējiet šos vērtētājus, salīdzinot ar cilvēku vērtējumiem.
3. Integrējiet novērtējumus CI/CD procesā: automātiski atkārtoti palaidiet regresijas testus, kad izstrādātāji atjaunina aģenta uzvednes, modeļus, rīkus vai darbplūsmu. Salīdziniet rezultātus ar bāzes versiju un nosakiet kvalitātes sliekšņus, kas bloķē laidienus, ja kritiskās pārbaudes neizdodas.
4. Piemērojiet kalibrētus vērtētājus ražošanas vides izpildes pierakstu paraugiem, sekojiet līdzi kļūmju biežumam un citiem veiktspējas rādītājiem un izpētiet jaunas kļūdas, veicot manuālu pārskatīšanu.