Si ta testosh një agjent AI para publikimit: udhëzues praktik për biznese
Një agjent AI që duket i shkëlqyer në demo mund të dështojë me klientët realë. Ja si ta testosh dhe vlerësosh para se ta lësh të prekë procese reale.
Shumica e agjentëve AI nuk dështojnë gjatë demos. Dështojnë në javën e dytë, kur një klient real pyet diçka pak të ndryshme, një API nuk përgjigjet në mes të një detyre, ose agjenti citon me siguri një politikë kthimi që nuk ekziston. Nëse dëshiron që testimi i agjentëve AI të parashikojë realisht sjelljen në prodhim, nuk mjafton “provuam dhjetë pyetje dhe dukej mirë”.
Ky udhëzues përshkruan procesin e vlerësimit që ndjekim kur ndërtojmë agjentë për sisteme biznesi. Është shkruar për pronarë, drejtues operacionesh dhe menaxherë teknikë që duhet të vendosin nëse një agjent është gati për publikim.
Pse testimi i agjentëve AI ndryshon nga softueri i zakonshëm
Softueri tradicional është deterministik: i njëjti input jep të njëjtin output, kështu që testi ose kalon ose dështon. Një agjent AI është probabilistik dhe me shumë hapa. Lexon një kërkesë, vendos cilat mjete të thërrasë (CRM, kalendar, databazë, API pagese), mban gjendje gjatë bisedës dhe vendos kur të ndalojë ose t’ia kalojë një njeriu. Së njëjtës pyetje mund t’i përgjigjet me rrugë të ndryshme në ditë të ndryshme.
Prandaj dështimet duken ndryshe nga gabimet e zakonshme:
- Agjenti zgjedh mjetin e gabuar, ose mjetin e duhur me parametra të gabuar.
- Shpik një përgjigje kur baza e njohurive nuk ka asgjë përkatëse.
- Bie në cikël, ose dorëzohet, kur një sistem i jashtëm kthen gabim.
- Ndjek udhëzime të fshehura brenda një email-i ose faqeje që iu kërkua ta lexonte.
- Përgjigjet saktë, por kryen një veprim për të cilin duhej të kërkonte leje.
Rreziku nuk është teorik. Gartner parashikoi në qershor 2025 se mbi 40% e projekteve të AI agjentike do të anulohen deri në fund të 2027, për shkak të kostove në rritje, vlerës së paqartë të biznesit dhe kontrolleve të pamjaftueshme të riskut. Testimi është vendi ku e zbulon problemin e tretë para klientëve.
Hapi 1: Përcakto çfarë do të thotë “mirë” para se të ndërtosh testin
Shkruaj, me njerëzit që zotërojnë procesin, çfarë duhet të bëjë agjenti, çfarë nuk duhet të bëjë kurrë dhe çfarë llogaritet dështim. Mbaje konkret:
- Suksesi i detyrës: një agjent mbështetjeje zgjidh pyetjen për dërgesën me të dhënat reale të porosisë, jo me hamendje.
- Rregulla sigurie: nuk kryen kurrë kthim parash mbi një shumë të caktuar pa miratim njerëzor.
- Eskalimi: ia kalon një personi kur besimi është i ulët ose klienti është i shqetësuar.
- Kosto dhe shpejtësi: përgjigje brenda kohës dhe kostos së pranueshme për bisedë.
Nëse ekipi nuk di të thotë çfarë do ta bllokonte një publikim, agjenti nuk është gati të prekë procese reale.
Hapi 2: Ndërto një set vlerësimi që i ngjan prodhimit
Seti i vlerësimit është një koleksion rastesh reale testimi, secili me një input dhe përshkrim të asaj që është rezultat i mirë. Mos përshkruaj fjalët e sakta; përshkruaj karakteristikat e një rezultati korrekt, sepse formulimi do të ndryshojë.
Nga vijnë rastet e testimit
- Biseda, email-e ose tiketa reale, të anonimizuara, nga muajt e fundit.
- Dhjetë pyetjet që ekipi yt u përgjigjet çdo ditë.
- Raste skajore: kërkesa të paqarta, informacion që mungon, dy gjuhë në një mesazh.
- Simulime dështimi: timeout, kërkim pa rezultat, klient i dyfishtë në sistem.
- Input kundërshtar: kërkesa që e shtyjnë agjentin jashtë rregullave.
Për një publikim të parë, 50 deri në 100 skenarë të zgjedhur mirë të mësojnë më shumë se mijëra të rastësishëm. Përfshi qëllimisht raste të vështira; një set vetëm me raste të lehta do të duket gjithmonë shkëlqyer.
Hapi 3: Kombino disa lloje vlerësuesish
Të duhet një mënyrë për të vlerësuar çdo ekzekutim. Asnjë metodë e vetme nuk mjafton, prandaj kombino tre:
- Kontrolle deterministe. A thirri mjetin e duhur? A përmbante përgjigjja një numër porosie të vlefshëm? A mbeti nën kufirin e kthimit? Janë të lira, të sakta dhe duhen ekzekutuar pas çdo ndryshimi.
- LLM si gjykatës. Një model i dytë vlerëson cilësi të vështira për t’u kodifikuar, si nëse përgjigjja bazohej te dokumenti i gjetur, ishte e sjellshme dhe e plotë. Kalibroje fillimisht me vlerësime njerëzore.
- Rishikim njerëzor. Një person nga biznesi lexon një mostër, sidomos rastet kufitare dhe me risk të lartë. Këtu njohuria e fushës kap atë që vlerësimi automatik e humb.
Hapi 4: Testimi i agjentëve AI në shtresa
Agjentët janë sisteme, dhe shumë dështime ndodhin në lidhjet mes pjesëve, jo brenda një thirrjeje modeli. Testo çdo shtresë:
- Teste komponentësh: a kthen kërkimi dokumentin e duhur (shih shkrimin tonë për RAG)? A zgjedh agjenti mjetin e saktë?
- Teste integrimi: a punon agjenti me API-të dhe formatet reale që do të has?
- Teste nga fillimi në fund: biseda të plota, përfshirë pyetje vijuese.
- Teste regresioni: sa herë ndryshon një prompt, model ose mjet, ekzekuto sërish gjithë setin, që një përmirësim në një vend të mos prishë diçka tjetër.
Hapi 5: Provo sigurinë me sulme të simuluara
Një agjent që lexon përmbajtje dhe kryen veprime mund të manipulohet përmes asaj përmbajtjeje. Para publikimit, përpiqu ta thyesh qëllimisht: fut udhëzime në një dokument ose email, kërko të zbulojë konfigurimin, kërko të veprojë mbi të dhënat e një klienti tjetër, shtyje përtej kufijve të miratimit. Çdo sulm i suksesshëm bëhet rast i përhershëm testimi. Parimet bazë: qasje me privilegje minimale, ndarje e të dhënave nga udhëzimet dhe miratim njerëzor për veprimet e rrezikshme.
Hapi 6: Vendos kritere “go/no-go”
Rezultatet ktheji në vendim publikimi me rregulla të miratuara paraprakisht:
- Pragje minimale sipas kategorive: cilësi, siguri, besueshmëri, kosto dhe shpejtësi.
- Rregulla bllokuese: çdo dështim serioz sigurie e ndalon publikimin, pavarësisht mesatares.
- Hapje graduale nëse rezultatet janë kufitare: fillimisht përdorues të brendshëm, pastaj një pjesë e vogël e trafikut real, me rishikim njerëzor.
Hapi 7: Monitoro pas nisjes dhe ushqe testet me dështimet reale
Testet para publikimit të tregojnë se agjenti ka gjasa të jetë gati; prodhimi të tregon të vërtetën. Ruaj gjurmët e plota të bisedave (mesazhe, thirrje mjetesh, rezultate), rishiko një mostër çdo javë dhe ktheje çdo dështim real në rast të ri testimi. Cikli është i njëjtë: vëzhgo, gjej dështimet, kthe në teste, testo para versionit të ardhshëm, përsërit. Kjo e bën testimin e agjentëve AI një proces të vazhdueshëm, jo një kontroll të vetëm.
Një shembull: agjent mbështetjeje për një dyqan online
Merr një agjent që përgjigjet “ku është porosia ime?” dhe përpunon kthime. Një vlerësim i arsyeshëm mund të ketë 80 skenarë: 40 pyetje të zakonshme porosish, 15 kërkesa kthimi (disa jashtë afatit), 10 mesazhe të paqarta, 10 raste dështimi sistemi (API e korrierit nuk punon) dhe 5 përpjekje manipulimi. Kontrollet deterministe verifikojnë mjetin dhe të dhënat; gjykatësi LLM vlerëson tonin dhe bazimin; një punonjës rishikon të gjitha dështimet plus 20 raste të rastësishme që kaluan. Rregulli: zero shkelje politikash dhe eskalim njerëzor në çdo mosmarrëveshje pagese. Vetëm atëherë agjenti merr 10% të bisedave reale.
Gabimet më të shpeshta
- Testimi vetëm i rasteve të lehta dhe konsiderimi i punës të përfunduar.
- Përdorimi i të njëjtave shembuj për të rregulluar dhe për të gjykuar agjentin.
- Besimi te një gjykatës LLM pa e krahasuar me vlerësime njerëzore.
- Anashkalimi i testeve pas “vetëm një ndryshimi të vogël prompt-i”.
- Publikimi për të gjithë menjëherë, pa plan kthimi pas.
Pyetje të shpeshta
Sa raste testimi më duhen para publikimit?
Për një agjent biznesi të fokusuar, 50 deri në 100 skenarë realë dhe të larmishëm janë pikënisje e mirë. Cilësia dhe mbulimi i rasteve skajore kanë rëndësi më shumë se numri, dhe seti duhet të rritet me çdo incident në prodhim.
A mund ta testoj agjentin vetëm manualisht?
Testimi manual ndihmon për eksplorim, por nuk shkallëzohet dhe nuk kap regresionet. Automatizo kontrollet e përsëritura dhe lëri njerëzit për rishikimin që kërkon gjykim.
Çfarë është “LLM si gjykatës”?
Është një model i dytë AI që vlerëson daljen e agjentit sipas kritereve që ti përcakton, si saktësia ose toni. Është i shpejtë dhe i lirë, por duhet validuar me vlerësime njerëzore para se t’i besosh.
Sa shpesh duhet ta ekzekutoj vlerësimin?
Sa herë ndryshon prompt, model, mjet ose burim të dhënash, dhe rregullisht në prodhim, sepse modelet dhe sistemet e jashtme ndryshojnë.
A nevojitet vlerësim edhe për një chatbot të thjeshtë?
Po, në formë më të lehtë. Edhe një chatbot AI për biznes ka nevojë për pyetje reale, kontroll bazimi dhe rregull të qartë eskalimi.
Të duhet një agjent AI që mund t’i besosh në prodhim?
Në Shkulaku projektojmë, ndërtojmë dhe vlerësojmë agjentë AI dhe sisteme RAG që lidhen me mjetet reale të biznesit, me testim dhe monitorim që nga dita e parë. Nëse po planifikon një agjent, ose ke një pilot që ende nuk është gati për klientët, kontakto ekipin tonë për të diskutuar idenë dhe për një plan praktik publikimi të sigurt.
Burimi i cituar: njoftimi i Gartner, “Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027”, 25 qershor 2025.
I take on a small number of projects at a time. Tell me what you are building and I will tell you honestly whether I am the right person for it.
Get in touch →