MI aģenta testi: viens veiksmīgs mēģinājums vēl nepierāda uzticamību

Lai pārbaudītu MI aģentu pirms ieviešanas, katram uzdevumam nosaki novērojamu gala stāvokli, izpildi uzdevumu vairākos neatkarīgos mēģinājumos un saglabā katras izpildes pēdu. Rezultātu, rīku izvēli un drošības robežu ievērošanu vērtē atsevišķi. OpenAI aģentu vērtēšanas vadlīnijas iesaka atkļūdošanu sākt ar izpildes pēdām, bet atkārtojamai pārbaudei pāriet uz datu kopām un vērtēšanas izpildēm.

Viens veiksmīgs mēģinājums rāda, ka aģents šoreiz spēja izpildīt uzdevumu; tas neparāda, cik stabili viņš to paveiks atkārtoti. Anthropic skaidrojums par aģentu testiem iesaka vienu uzdevumu izpildīt vairākos mēģinājumos, jo modeļa darbība var atšķirties, un pārbaudīt faktisko gala stāvokli, nevis tikai aģenta paziņojumu. Lidojuma rezervēšanas piemērā izšķirošais ir tas, vai rezervācija tiešām pastāv datubāzē.

Nosaki gala stāvokli pirms testa

Testa uzdevumā apraksti lietotāja pieprasījumu, sākotnējos datus un to, kas pēc izpildes būs pārbaudāms. Ar prasību pareizi apstrādāt pieprasījumu nepietiek: vērtētājam jāzina, kurš ieraksts drīkst mainīties, kādai jābūt jaunajai vērtībai un kam jāpaliek neskartam. Ja aģents tikai sagatavo atbildi, nosaki pārbaudāmās satura prasības un faktus, uz kuriem tai jābalstās.

Nosacīts piemērs: atbalsta aģents saņem lūgumu slēgt konkrētu pieteikumu. Veiksmīgs gala stāvoklis ir šā pieteikuma statuss «slēgts», ja pieprasītāja identitāte ir pārbaudīta un slēgšana ir atļauta; pārējie pieteikumi paliek nemainīgi. Pārī ar to vajadzīgs gadījums, kurā identitātes pārbaude neizdodas. Tad pareizais rezultāts ir nemainīts statuss, nevis darbība, ko aģents veiksmīgi izpildījis neatļautos apstākļos.

Pirms testu pievieno kopai, pārbaudi, vai prasības pieļauj skaidru spriedumu par rezultātu. Ja divi komandas locekļi vienu un to pašu pieļaujamo atbildi vērtētu atšķirīgi, precizē uzdevumu vai vērtēšanas noteikumus. Noder arī zināms, derīgs risinājums: tam jāiztur pārbaude, lai būtu skaidrs, ka uzdevums vispār ir izpildāms.

Atkārto uzdevumu no tīra sākuma stāvokļa

Katru mēģinājumu sāc ar to pašu uzdevuma tekstu, datiem, pieejamajiem rīkiem un atļaujām. Atjauno vidi pirms nākamās izpildes: iepriekš slēgts pieteikums, saglabāta saruna vai kešatmiņa var mainīt aģenta rīcību un padarīt mēģinājumus nesalīdzināmus. Pieraksti arī modeļa un aģenta konfigurāciju, lai vēlāk varētu atšķirt darbplūsmas izmaiņu no mainītiem testa apstākļiem.

Katram mēģinājumam saglabā atsevišķu izpildes pēdu ar ievadi, rīku izsaukumiem un atbildēm, kļūdām, aģenta gala atbildi un vides stāvokli pēc izpildes. Ja vienā mēģinājumā rezultāts ir pareizs, bet citā nav, pēda palīdz atrast vietu, kur aģents izvēlējās citu rīku, nodeva nepareizu parametru vai turpināja pēc kļūdas. Fiksē iznākumu katram uzdevumam un mēģinājumam, nevis piešķir visai kopai vienu atzīmi.

Atdali rezultātu no ceļa līdz tam

Gala stāvokļa vērtētājs pārbauda faktisko ierakstu, failu vai citu izmaiņas pazīmi. Rīku vērtētājs pārbauda, vai izmantoti pieļaujami rīki un parametri un vai nav izlaista obligāta darbība, piemēram, identitātes pārbaude. Drošības vērtētājs atzīmē darbības ārpus piešķirtajām atļaujām vai uzdevuma robežām. Šāds sadalījums ļauj redzēt, vai kļūda ir rezultātā, darbplūsmā vai atļauju ievērošanā.

Pareiza gala atbilde lietotājam vēl nenozīmē, ka mainīts pareizais ieraksts. Arī pareizs ieraksta statuss neattaisno neatļautu piekļuvi pa ceļam. Vienlaikus vērtētājam nevajag uzspiest precīzu rīku izsaukumu secību, ja vairāki atļauti ceļi dod vienu un to pašu derīgo rezultātu. Prasi tikai tos starpposmus, kuri uzdevuma izpildei vai drošībai patiešām ir obligāti; citādi tests var noraidīt labu risinājumu.

Īsa testa veidne mazai komandai

Vienu testa gadījumu var glabāt kā strukturētu ierakstu neatkarīgi no izmantotās platformas. Tam vajadzīgi šādi lauki:

1. Uzdevums. Lietotāja pieprasījums, sākotnējie dati, pieejamie rīki un aģenta atļaujas. Formulē arī apstākļus, kuros darbība ir pieļaujama.
2. Sagaidāmais gala stāvoklis. Nosauc pārbaudāmo izmaiņu, datus, kuriem jāpaliek nemainīgiem, un prasības gala atbildei. Aizliegta darbība var nozīmēt nemainītu stāvokli.
3. Mēģinājumi un pēdas. Katru mēģinājumu sāc atjaunotā vidē. Glabā konfigurāciju, izpildes pēdu, faktisko gala stāvokli un vērtējumu.
4. Atsevišķi vērtētāji. Rezultātam, rīku lietojumam un drošības robežām pieraksti konkrētus izturēšanas nosacījumus. Subjektīvam vērtējumam pievieno skaidru skalu un strīdīgu gadījumu pārbaudi pie cilvēka.
5. Atsauces risinājums. Saglabā zināmu derīgu izpildes variantu, kas iztur vērtētājus. Tas palīdz atklāt prasības, kuras testā ir neskaidras vai nav izpildāmas.

Nosacītajā atbalsta pieteikuma piemērā veidnē iekļauj gan pārbaudītu pieprasītāju, kura pieteikumu drīkst slēgt, gan nepārbaudītu pieprasītāju, kura pieteikuma statuss nedrīkst mainīties. Abi gadījumi pārbauda vienu darbplūsmu, bet sagaidāmais gala stāvoklis atšķiras. Tā var pamanīt aģentu, kurš prot izdarīt izmaiņu, taču neievēro nosacījumu, kas to atļauj.

Atšķir regresiju no kļūdaina testa

Pēc izmaiņas aģentā atkārto to pašu uzdevumu kopu ar tiem pašiem vērtēšanas noteikumiem un salīdzini rezultātus pa uzdevumiem. LangSmith dokumentācija apraksta regresijas testus kā veidu, kā salīdzināt lietotnes versijas un pamanīt kvalitātes kritumu gadījumos, kurus iepriekšējā versija atrisināja. Ja rezultāts pasliktinās, atver attiecīgās izpildes pēdu un faktisko gala stāvokli.

Pirms kļūdu piedēvē jaunajai versijai, pārbaudi pašu testu:

• Uzdevums pieļauj vairākas saprātīgas interpretācijas, bet vērtētājs pieņem tikai vienu.
• Vērtētājs paļaujas uz aģenta solījumu, lai gan izmaiņu var pārbaudīt vidē.
• Mēģinājumi manto iepriekšējās izpildes datus vai kešatmiņu.
• Tests prasa vienu rīku secību, lai gan iespējams cits atļauts risinājums.
• Kopā ir tikai gadījumi, kuros aģentam jārīkojas, un nav gadījumu, kuros izmaiņa jāattur.

Ja atklājas šāda problēma, izlabo uzdevumu vai vērtētāju un atkārtoti palaid arī iepriekšējo aģenta versiju. Salīdzinājums ir derīgs tikai tad, ja abas versijas vērtē pēc vienādiem, pārbaudītiem noteikumiem.

Lasiet arī:

• OpenAI aģentu spieti skāra ārējas datubāzes — robežas vēl nav skaidras
• ECB grib testēt MI aģentus ar digitālo eiro — emisija vēl nav izlemta
• ChatGPT vai Gemini izpētei: vairāk avotu vēl nenozīmē precīzāku atbildi