Un set de evaluare AI care vă ajută să luați decizia de lansare

Porniți de la decizia pe care trebuie să o susțină evaluarea

Numiți schimbarea propusă înainte să strângeți un set mare de date. Înlocuiți un model, extindeți accesul la unelte, treceți la alt grup de utilizatori sau treceți de la răspunsuri schițate la acțiuni automate? Fiecare schimbare cere alte dovezi. Un scor general de benchmark nu îi poate spune unei afaceri dacă propria limită de aprobare ar trebui mutată.

Pentru un asistent de cunoștințe ilustrativ, prima întrebare ar putea fi dacă pilotul răspunde la întrebările obișnuite despre politici din documentele în vigoare și refuză întrebările pe care nu le poate susține. Evaluarea trebuie deci să includă întrebări la care se poate răspunde, dovezi lipsă, versiuni contradictorii și cereri din afara accesului utilizatorului.

SWE-bench construiește sarcini de software din probleme reale ale unor repository-uri și evaluează modificările propuse în acel context. Ideea relevantă aici este designul sarcinii: o evaluare utilă ar trebui să semene cu munca pe care pretinde că o măsoară. Un benchmark nu dovedește totuși că un flux de lucru fără legătură cu el, dintr-o companie, e gata de lansare.

Construiți setul împreună cu oamenii care cunosc munca

Strângeți un set de pornire modest din exemple reale aprobate. Păstrați destul context cât să explicați rezultatul așteptat, dar eliminați datele personale inutile. Rugați-i pe cel care răspunde de proces și pe utilizatorii din prima linie să identifice greșelile costisitoare și cazurile neobișnuite, dar legitime. Țineți deoparte un set separat pentru verificarea schimbărilor, ca echipa să nu optimizeze mereu pe aceleași exemple.

Pentru fiecare caz, notați ce face un răspuns acceptabil și ce îl face să eșueze. „Util” e prea larg dacă doi evaluatori îl pot interpreta, pe bună dreptate, diferit. „Citează politica în vigoare, include excepția ei și nu dezvăluie materiale restricționate” le dă evaluatorilor ceva de verificat.

Evaluați riscurile după consecințe, nu doar după frecvență. O acțiune neautorizată, chiar rară, nu ar trebui ascunsă de un scor mediu bun. Raportați separat categoriile importante și numărul de exemple din fiecare.

Folosiți mai multe tipuri de dovezi

Verificările deterministe sunt utile pentru câmpuri structurate, acțiuni interzise și forme obligatorii ale rezultatului. Evaluatorii din domeniu sunt utili pentru corectitudinea care depinde de contextul afacerii. Un evaluator bazat pe model poate ajuta la scalarea verificării, dar și el trebuie calibrat față de judecata umană, iar dezacordurile trebuie inspectate.

Îndrumările Anthropic despre evaluare fac distincția între sarcină, încercare, evaluator, transcriere și rezultat. În special, o conversație care pare reușită nu e o dovadă suficientă că un agent a făcut modificările cerute în sistem. Inspectați starea finală a sistemului testat acolo unde sarcina cere o acțiune.

Rulați mai multe încercări pentru cazurile în care variația rezultatului contează. Păstrați alături de rezultat versiunile modelului, ale promptului, ale configurației de regăsire și ale uneltelor. Altfel, o schimbare de comportament e greu de reprodus, iar cine citește raportul nu poate spune ce versiune descrie.

RAGAS oferă evaluare pe componente pentru generarea augmentată prin regăsire, inclusiv pentru contextul regăsit și pentru cât de bine e susținut răspunsul. Astfel de măsuri pot ajuta la localizarea unei erori. Ele trebuie totuși interpretate în raport cu sarcina, mai ales când un răspuns plauzibil e greșit într-un mod pe care afacerea îl consideră costisitor.

Transformați rezultatele într-o decizie

Un raport util spune ce categorii s-au îmbunătățit, care au regresat și dacă limitele importante au rezistat. Includeți latența, costul de operare și cantitatea de verificare umană necesară. Atașați eșecuri reprezentative, ca cel care răspunde de produs să înțeleagă ce înseamnă cifrele agregate.

Când un rezultat pică, clasificați cauza înainte să rescrieți promptul. Sursa poate lipsi, regăsirea poate să fi ales pasajul greșit, contractul uneltei poate fi ambiguu sau chiar răspunsul așteptat poate fi disputat. Fiecare cere altă corectură.

După lansare, aduceți exemple aprobate din eșecurile reale în următoarea evaluare. Păstrați verificările originale ținute deoparte, întrețineți politica din spatele răspunsurilor așteptate și faceți din setul de test o parte a responsabilității continue pentru produs.

Păstrați dezacordul în raport

Doi evaluatori nu sunt de acord asupra unui răspuns. Nu le mediați imediat notele. Întrebați-vă dacă sursa e ambiguă, dacă grila a omis o condiție sau dacă unul dintre ei știe ceva ce sistemul nu poate vedea. Dezacordul poate scoate la iveală o cerință de produs.

Notați o explicație scurtă lângă rezultat și actualizați regula doar după ce responsabilul ei este de acord. Păstrați istoricul versiunilor pentru criteriile de evaluare, la fel ca pentru prompt.