Simplul fapt că obținem un răspuns de la un model AI nu înseamnă încă faptul că sistemul funcționează corect. În cazul software-ului clasic putem adesea verifica în mod clar dacă o funcție a returnat rezultatul așteptat. În sistemele AI, răspunsul poate fi fluent, logic și convingător, și totuși să conțină erori.
De aceea, odată cu dezvoltarea AI apare o nouă problemă de inginerie: cum măsurăm în mod sistematic calitatea unui sistem ale cărui răspunsuri nu sunt întotdeauna identice?
Acesta este exact domeniul AI evaluation, adică evaluarea sistemelor de inteligență artificială.
Și este mult mai larg decât verificarea dacă un chatbot „răspunde bine”.
Testarea software-ului clasic și testarea AI nu sunt același lucru
Să ne imaginăm o funcție simplă într-o aplicație.
Utilizatorul introduce: 2 + 2
Sistemul ar trebui să returneze: 4
Dacă returnează 5, avem o eroare clară.
Putem pregăti un test: expect(calculate("2 + 2")).toBe(4)
și de fiecare dată vom obține un rezultat clar: testul trece sau nu trece.
În sistemele AI, situația este diferită.
Utilizatorul poate întreba: „Scrie un răspuns scurt pentru un client care întreabă despre termenul de realizare a comenzii.”
Sistemul poate genera mai multe răspunsuri diferite. Toate pot fi corecte din punct de vedere lingvistic. Toate pot suna profesionist. Unul însă poate conține un termen fals, altul poate fi prea lung, al treilea poate omite o informație importantă, iar al patrulea poate fi ideal.
Așadar, nu este suficient să verificăm dacă răspunsul a fost generat tehnic.
Trebuie să verificăm, dacă îndeplinește criteriile de calitate stabilite.
Prima problemă: un răspuns bun nu este întotdeauna adevărat
Aceasta este una dintre cele mai caracteristice trăsături ale AI generative.
Modelul poate genera un răspuns care sună foarte convingător, dar nu are acoperire în datele sursă.
În cazul unui sistem care folosește RAG, problema este și mai interesantă. Sistemul poate primi o întrebare, poate căuta câteva fragmente din documentație și apoi poate genera un răspuns.
Atunci trebuie verificate cel puțin trei lucruri:
- Au fost găsite informațiile corecte? Mecanismul de căutare a preluat fragmente realmente legate de întrebare?
- Răspunsul folosește informațiile găsite? Modelul nu a adăugat ceva ce nu exista în surse?
- Răspunsul chiar răspunde la întrebare? Se poate avea un retrieval care funcționează corect, dar un răspuns final slab.
De aceea, evaluarea RAG separă, printre altele, aspecte precum relevanța contextului recuperat, completitudinea căutării, corectitudinea răspunsului și conformitatea lui cu sursele.
Este o schimbare importantă în modul de a gândi testarea.
Nu mai testăm doar: întrebare → răspuns
ci întregul lanț: întrebare → căutare → context → model → răspuns
Poți avea un model bun și un sistem AI prost
Acesta este un alt lucru ușor de uitat.
O companie poate alege un model lingvistic foarte bun și totuși să creeze un produs AI slab.
De ce? Pentru că calitatea sistemului final nu depinde doar de model.
Contează și:
- calitatea datelor,
- modul de pregătire a contextului,
- promptul,
- modul de căutare a informațiilor,
- parametrii modelului,
- instrumentele puse la dispoziția AI,
- logica aplicației,
- memoria,
- modul de gestionare a erorilor,
- măsurile de siguranță,
- modul de evaluare a răspunsurilor.
Asta înseamnă că întrebarea: „Care model este cel mai bun?”
este adesea mai puțin utilă decât: „Care model funcționează cel mai bine în cazul nostru concret de utilizare?”
Un model care se descurcă excelent la generarea de conținut de marketing nu trebuie neapărat să fie cea mai bună soluție pentru clasificarea documentelor, analiza datelor sau gestionarea proceselor de business.
De aceea, compararea modelelor ar trebui să aibă loc pe sarcinile reale pe care sistemul trebuie să le îndeplinească.
Mai întâi trebuie să creezi propriul set de teste
Nu poți evalua în mod rezonabil un sistem AI dacă nu știi ce aștepți de la el.
De aceea, unul dintre cele mai importante elemente ale evaluării este pregătirea unui dataset de test, adică un set de cazuri reale sau reprezentative.
De exemplu, o companie construiește un AI pentru departamentul de customer support.
În loc să verifici manual un singur răspuns după fiecare modificare a promptului, poți pregăti câteva sute de cazuri:
- întrebări simple,
- întrebări ambigue,
- întrebări care conțin presupuneri greșite,
- întrebări care necesită găsirea unui document,
- întrebări despre excepții,
- întrebări despre reclamații,
- întrebări care necesită refuz,
- întrebări care conțin date pe care AI nu ar trebui să le dezvăluie.
Fiecare schimbare a sistemului poate fi apoi rulată pe același set.
Și tocmai aici AI începe să semene cu software-ul clasic.
Nu mai testăm un singur răspuns. Testăm comportamentul sistemului pe întregul set de cazuri.
Promptul poate fi testat și el
Promptul este adesea tratat ca un text scris o dată și lăsat în producție.
În realitate, poate fi o componentă a logicii aplicației.
Schimbarea unei singure propoziții poate duce la:
- îmbunătățirea răspunsurilor într-un scenariu,
- înrăutățirea răspunsurilor în altul,
- o tendință mai mare de a refuza,
- mai multe halucinații,
- răspunsuri mai lungi,
- costuri mai mari,
- consum mai mare de tokeni.
De aceea, promptul ar trebui tratat similar cu codul.
Dacă modificăm promptul, merită să știm:
- ce s-a îmbunătățit?
- ce s-a înrăutățit?
- a apărut o regresie?
Tocmai de aceea, evaluarea automată capătă o importanță tot mai mare, nu evaluarea manuală a câtorva răspunsuri exemplu.
AI poate trece testul și totuși să fie un produs prost
Să presupunem că am pregătit 100 de cazuri de test.
Sistemul a răspuns corect la 95. Rezultatul arată excelent. Dar ce se întâmplă dacă cele cinci răspunsuri greșite privesc situații critice?
Dacă chatbotul răspunde la întrebări despre programul de lucru, cinci greșeli pot fi o problemă.
Dacă AI-ul ajută un angajat să analizeze documente financiare, medicale sau juridice, importanța acelor erori poate fi cu totul diferită.
De aceea, media simplă nu este suficientă.
Avem nevoie și de ponderarea cazurilor.
Putem considera că:
- o întrebare obișnuită are ponderea 1,
- o eroare importantă are ponderea 5
- o eroare de securitate are o pondere de 10,
- dezvăluirea unei informații confidențiale are o pondere de 100.
Atunci sistemul nu primește „95 la sută”. Primim o imagine mult mai utilă asupra riscului.
Nu totul poate fi măsurat cu un singur număr
Aceasta este una dintre cele mai importante probleme ale evaluării AI.
Putem avea mai multe metrici:
- Accuracy - răspunsul este corect?
- Relevance - răspunde la întrebare?
- Faithfulness / groundedness - se bazează pe sursele furnizate?
- Context precision - fragmentele căutate sunt relevante?
- Context recall - a găsit sistemul informațiile necesare?
- Safety - nu execută acțiuni nedorite?
- Latency - cât timp așteaptă utilizatorul?
- Cost - cât costă executarea sarcinii?
RAG poate avea astfel o calitate foarte bună a răspunsului, dar în același timp să preia o cantitate uriașă de context și să genereze un cost inacceptabil.
Un alt sistem poate fi foarte ieftin și rapid, dar să facă prea multe greșeli.
Prin urmare, nu există un singur număr universal care să stabilească dacă AI este „bun”. Calitatea trebuie definită în contextul unei utilizări concrete.
Și cum rămâne cu evaluarea AI de către alt AI?
Aici apare un alt mecanism interesant.
Una dintre modalitățile de a automatiza evaluarea este folosirea modelului ca judecător, adică LLM-as-a-judge.
De exemplu:
Modelul A generează un răspuns.
Modelul B primește întrebarea, răspunsul și criteriile stabilite.
Apoi evaluează:
- corectitudinea,
- conformitatea cu instrucțiunea,
- completitudinea,
- stilul,
- siguranța.
Instrumentele moderne de evaluare permit, de asemenea, combinarea unei astfel de evaluări cu comparații clasice de text, scripturi proprii sau evaluatori bazați pe reguli concrete.
Acest lucru crește enorm amploarea testării. Dar nu înseamnă că omul nu mai este necesar. Modelul care evaluează poate greși și el. De aceea, în sistemele cu o importanță business mai mare merită să combinăm evaluările automate cu o evaluare periodică de expert.
Cea mai mare problemă: regresia
Să ne imaginăm un sistem care funcționează foarte bine. Echipa schimbă modelul cu unul mai nou. Noua versiune este mai rapidă și mai ieftină. Așadar, pare că totul merge în direcția bună.
După implementare se dovedește însă că:
- răspunsurile sunt mai puțin precise,
- modelul refuză mai des să răspundă,
- folosește mai prost documentația,
- interpretează diferit instrucțiunile,
- în unele scenarii începe să ofere informații incorecte.
Asta este exact AI regression.
În software-ul clasic cunoaștem regresia de ani de zile. În AI trebuie, de asemenea, să o detectăm, dar problema este mai dificilă, deoarece comportamentul sistemului se poate schimba fără o „eroare” clasică. De aceea, orice schimbare majoră ar trebui comparată cu versiunea anterioară.
Modelul.
Promptul.
Embeddingul.
Retrieverul.
Documentația.
Logica agentului.
Parametrii.
Fiecare dintre aceste elemente poate influența rezultatul.
Nu este suficient să evaluezi agentul doar după răspunsul său final
Și mai dificil devine în cazul agenților AI.
Un chatbot clasic poate executa o singură sarcină: întrebare → răspuns.
Un agent poate funcționa cu totul altfel: scop → plan → instrument → rezultat → pas următor → decizie → acțiune → răspuns.
Dacă agentul nu a atins scopul, vrem să știm nu doar că a pierdut.
Vrem să știm: unde a greșit?
- A înțeles greșit sarcina?
- A ales instrumentul greșit?
- A transmis un parametru greșit?
- A preluat date greșite?
- A luat o decizie greșită după primirea rezultatului?
- A făcut prea mulți pași?
- S-a oprit prea devreme?
În cercetările privind evaluarea agenților se analizează tot mai des nu doar rezultatul final, ci și parcursul acțiunilor, utilizarea instrumentelor, planificarea, memoria, fiabilitatea și siguranța.
Asta înseamnă că viitorul testării AI va fi în mare măsură legat de analiza trace-urilor, adică a parcursului complet al funcționării sistemului.
AI are nevoie de ceva asemănător cu CI/CD
Dacă AI este parte din produs, nu poate fi testată doar înainte de prima implementare.
Sistemul se va schimba.
Se va schimba modelul.
Se va schimba promptul.
Se va schimba baza de cunoștințe.
Se va schimba modul de căutare.
Se va schimba configurația.
De aceea, evaluarea ar trebui să intre în procesul de development.
Schema poate arăta astfel: schimbare → teste → evaluare → comparație cu versiunea anterioară → decizie de implementare
Dacă noua versiune îmbunătățește calitatea într-o zonă, dar depășește pragul stabilit de erori în alta, deployment-ul poate fi oprit.
Este o filozofie foarte asemănătoare cu CI/CD-ul clasic, dar criteriile sunt altele.
În cazul aplicațiilor AI putem verifica simultan calitatea răspunsului, corectitudinea, siguranța, costul și latența. Există deja soluții de cercetare care combină evaluarea cu observability și porți de calitate în procesul de implementare a sistemelor LLM/RAG.
Deci putem testa AI la fel ca software-ul clasic?
Da, dar doar parțial.
Abordarea clasică rămâne necesară.
Testăm:
- API-ul,
- integrările,
- permisiunile,
- validarea datelor,
- erorile,
- timeout-urile,
- securitatea,
- performanța,
- logica aplicației.
Dar nu ne putem opri aici.
Apare un al doilea strat: evaluarea comportamentului AI.
- Răspunsul este corect?
- Este conform cu sursele?
- Modelul respectă instrucțiunile?
- Sistemul se comportă corect în situații neașteptate?
- Alege agentul instrumentele potrivite?
- Noua versiune nu a înrăutățit calitatea?
- Costul de funcționare rămâne acceptabil?
- Utilizatorul primește într-adevăr valoare?
Asta nu mai este un test unit clasic.
Cel mai bun test AI nu este întotdeauna un test de laborator
Mai există încă un element foarte important.
Sistemul poate arăta excelent pe un set de test pregătit, și totuși să aibă probleme în lumea reală. De aceea merită să observăm și interacțiunile reale. Nu pentru ca fiecare utilizator să fie tester. Ideea este ca sistemul să poată fi îmbunătățit continuu pe baza cazurilor reale:
- unde utilizatorii corectează AI-ul,
- unde cer repetarea răspunsului,
- unde întrerup conversația,
- unde escaladează cazul către un om,
- unde agentul nu își atinge scopul,
- unde apar întrebări neobișnuite.
În acest fel se creează o buclă continuă de evaluare: utilizator → acțiune AI → rezultat → analiză → nou caz de test → următoarea versiune a sistemului
Acesta este un model de dezvoltare complet diferit față de simplul „am implementat AI și funcționează”.
AI nu ar trebui evaluată prin întrebarea „funcționează?”
Asta este prea puțin.
Întrebările mai bune sunt:
- Cât de des funcționează corect?
- În ce situații greșește?
- Cât de grave sunt aceste erori?
- Este noua versiune mai bună decât cea anterioară?
- Sistemul este suficient de sigur?
- Răspunsurile se bazează pe datele potrivite?
- Cât costă obținerea unui rezultat concret?
Doar un astfel de set de întrebări permite să vorbim despre un sistem AI matur.
Cea mai importantă schimbare de mentalitate
Timp de ani de zile, în dezvoltarea software a existat o regulă simplă: codul trebuie să funcționeze.
În sistemele AI, această regulă trebuie extinsă: sistemul trebuie să funcționeze bine, previzibil și măsurabil.
Este o diferență uriașă. Pentru că AI nu este o funcție care returnează mereu același rezultat. Este un sistem probabilistic, al cărui comportament depinde de model, date, context, instrucțiuni și de întreaga arhitectură din jurul lui.
De aceea, o implementare profesională a AI nu se încheie în momentul în care modelul începe să răspundă.
Atunci abia începe întrebarea: de unde știm că putem avea încredere în el?
Iar la această întrebare ar trebui să răspundă o evaluare bine proiectată.
În viitor, testarea sistemelor AI va deveni probabil la fel de naturală în procesul de dezvoltare ca testele unitare, integrarea sau monitorizarea. Nu pentru că AI este „periculoasă prin definiție”. Pur și simplu pentru că un sistem al cărui rezultat nu este întotdeauna determinist necesită un alt mod de a măsura calitatea.
Iar cu cât AI trece mai mult de la generarea de text la gestionarea proceselor reale, utilizarea datelor, RAG și executarea acțiunilor prin agenți, cu atât devine mai important nu doar întrebarea „poate AI să facă asta?”, ci și: „putem dovedi că face asta suficient de bine?”
