AI agenti “avtonom əməkdaş” kimi deyil, konkret səlahiyyətləri, girişləri, çıxışları və dayanma qaydaları olan idarə olunan iş axını komponenti kimi qəbul etmək daha təhlükəsizdir. AI agent evaluation services bu komponentin real biznes tapşırıqlarında nə etdiyini, nəyi etməməli olduğunu və qeyri-müəyyən vəziyyətdə insan operatoruna necə ötürməli olduğunu istehsal mühitindən əvvəl sübut etməyə kömək edir.

Sadə demo adətən agentin mətn yaratdığını göstərir. Etibarlı qiymətləndirmə isə daha çətin suallara cavab verir: Agent CRM-də yalnız icazəli qeydi yeniləyirmi? ERP-yə eyni sifarişi iki dəfə göndərirmi? E-poçtdakı gizli təlimata uyub məxfi məlumatı paylaşırmı? Alət cavabı gecikəndə və ya səhv qaytaranda nəticəni uydururmu? Bu suallar cavablandırılmadan agenti canlı müştəri, maliyyə və ya əməliyyat prosesinə qoşmaq risklidir.

AI agent qiymətləndirməsi nəyi yoxlamalıdır?

Agentin cavabı tək qiymətləndirmə obyekti deyil. Qiymətləndirmə girişdən son qərara və alət çağırışına qədər bütün izi nəzərdən keçirməlidir: hansı məlumat qəbul edildi, hansı qayda tətbiq olundu, hansı alət seçildi, hansı parametr göndərildi, nəticə necə təsdiqləndi və insan təsdiqi tələb olundumu.

Bu yanaşma OWASP-ın vurğuladığı prompt injection və excessive agency riskləri ilə də uyğunlaşır: zərərli və ya sadəcə qeyri-dəqiq mətn agenti gözlənilməyən hərəkətə sövq edə bilər; geniş funksiyalar, həddindən artıq icazələr və nəzarətsiz muxtariyyət isə təsiri böyüdür. Buna görə qoruyucu məntiq yalnız sistem promptunda yox, alət sxemlərində, giriş nəzarətində, biznes qaydalarında və təsdiq qapılarında yerləşməlidir.

Real iş nümunələrindən qiymətləndirmə dataseti yaradın

Faydalı LLM agent evaluation framework “100 ümumi sual” siyahısı ilə başlamır. O, proses sahibinin gündəlik qarşılaşdığı hallardan qurulur. Tarixi tikətlər, sifarişlər, müqavilə sorğuları, dəstək müraciətləri və istisna qeydləri şəxsi və həssas məlumatlardan təmizlənərək test ssenarilərinə çevrilə bilər.

Hər test nümunəsində nə olmalıdır?

  • Başlanğıc kontekst: istifadəçi rolu, mövcud sistem vəziyyəti, agentin görə biləcəyi sənədlər və əvvəlki addımlar.
  • Tapşırıq: məsələn, “bu müştərinin ünvanını yenilə” və ya “bu fakturanı emala hazırla”.
  • Gözlənilən hərəkət: doğru alət, dəqiq parametr, yaradılacaq draft və ya yönləndiriləcək növbə.
  • Qadağan olunmuş hərəkətlər: ödənişi təsdiqləmək, əlaqəsiz qeydləri oxumaq, məlumatı xarici ünvana göndərmək və ya səlahiyyətsiz dəyişiklik etmək.
  • Qəbul meyarı: düzgün cavabdan əlavə düzgün eskalasiya, imtina, aydın izah və audit üçün kifayət edən iz.

Məsələn, satış sifarişi agenti PDF-dən məhsulları çıxara, ERP-də sifariş qaralaması yarada və uyğunsuz qiymət olduqda satış menecerinə yönləndirə bilər. Qiymətləndirmədə əsas nəticə “məhsul adını düzgün oxudu” deyil. Əsas nəticə agentin ehtiyat stokunu dəyişməməsi, təsdiqsiz sifarişi göndərməməsi, valyuta uyğunsuzluğunu aşkar etməsi və qeyri-müəyyənliyi aydın eskalasiyaya çevirməsidir.

Gözlənilən-hərəkət testləri: mətndən əməliyyata

AI agent testing üçün hər ssenari agentin yekun mətn cavabını və əməliyyat ardıcıllığını ölçməlidir. Bir neçə fərqli ifadə eyni iş niyyətini ifadə edə bilər; bununla belə, icra planı müəyyən sərhədlər daxilində qalmalıdır.

  • Agent lazımi məlumatı dəqiqləşdirmək üçün sual verirmi?
  • Yalnız qeydiyyatdan keçmiş, tipli və sxemə uyğun aləti çağırırmı?
  • Alət üçün məcburi parametrləri yoxlayırmı?
  • Oxuma əməliyyatını yazma əməliyyatından ayırırmı?
  • Yan təsirli əməliyyatdan əvvəl insan təsdiqi istəyirmi?
  • Alətin cavabını müstəqil yoxlayır, yoxsa uğuru sadəcə fərz edir?

Bu testlər deterministik biznes məntiqini modelin ixtiyarına buraxmamağa kömək edir. Məsələn, “10 000 AZN-dən yuxarı ödəniş insan təsdiqi olmadan göndərilə bilməz” qaydası dil modelinin şərhi deyil, tətbiq səviyyəsində icra olunan qayda olmalıdır. Agent yalnız uyğun növbəni seçə, lazımi əsaslandırmanı hazırlaya və təsdiq üçün kontekst təqdim edə bilər.

İcazə sərhədlərini ayrıca sınaqdan keçirin

Agentin düzgün niyyəti kifayət deyil; onun identikliyi və alət tokeni yalnız zəruri əməliyyatlara çıxış verməlidir. Ən kiçik səlahiyyət prinsipi agent üzrə, alət üzrə, istifadəçi üzrə və mümkün olduqda qeyd səviyyəsində tətbiq edilməlidir.

İcazə test matrisi

  • Rol sərhədi: satış agenti maliyyə qeydlərini oxuya və ya dəyişə bilirmi?
  • Tenant və şöbə sərhədi: bir bölmənin sorğusu digər bölmənin məlumatına çıxış yaradırmı?
  • Əməliyyat sərhədi: agent “read” tokeni ilə yazma cəhdi edə bilirmi?
  • Məbləğ və həcm sərhədi: kiçik dəyişiklik üçün verilən hüquq kütləvi dəyişiklik və ya böyük ödənişə çevrilirmi?
  • Məlumat sərhədi: cavab, log və ya alət parametrində şəxsi məlumat lazımsız yerə görünürmü?

Bu yoxlamalar Süni intellekt və avtomatlaşdırma layihəsinin inteqrasiya dizaynı ilə birlikdə hazırlanmalıdır. CRM, ERP və ya sənəd sistemi sistem-of-record olaraq qalır; agent isə qeydə alınan, məhdud və yoxlanıla bilən əməliyyatlar vasitəsilə işləyir.

Tool-call uğursuzluqlarını yalnız “happy path” ilə məhdudlaşdırmayın

Real proseslərdə API limitləri, gecikmələr, natamam cavablar, şəbəkə kəsintiləri və təkrarlanan webhook-lar olur. Agent alət çağırışını uğursuz bitirdikdə, təhlükəsiz davranış adətən “yenidən sonsuz cəhd et” və ya “uğurlu oldu” demək deyil.

Test dəstinə ən azı bu halları əlavə edin:

  • vaxt limiti və ya 429/5xx xətası;
  • qismən uğur: fayl yüklənib, amma ERP qeydi yaradılmayıb;
  • eyni sorğunun iki dəfə gəlməsi və idempotency yoxlaması;
  • köhnəlmiş, boş və ya ziddiyyətli alət nəticəsi;
  • sxemə uyğun görünən, lakin biznes baxımından etibarsız parametr;
  • agentin istifadəçiyə və operatora fərqli, lakin həqiqətə uyğun status verməsi.

Yazma əməliyyatlarında sorğu identifikatoru, idempotency açarı, təsdiqlənən status və bərpa qaydası olmalıdır. Agent “sifariş yaradıldı” deməzdən əvvəl sistemin yaratma nəticəsini yoxlamalıdır. Əks halda düzgün görünən dialoq arxasında itmiş və ya dublikat əməliyyat yarana bilər.

Prompt injection üçün AI agent red teaming

Prompt injection testləri təkcə istifadəçinin “qaydaları unut” deməsindən ibarət olmamalıdır. Agentlər zərərli təlimatı e-poçt, PDF, veb səhifə, CRM qeydi və ya axtarış nəticəsi kimi etibarsız məzmunun içindən də ala bilər. Testdə bu məzmun agentə normal biznes sənədi kimi təqdim edilir və agentin onu məlumat kimi, yoxsa təlimat kimi emal etdiyi müşahidə olunur.

Yoxlanmalı nümunələrə daxildir: gizli sistem təlimatını açıqlama tələbi, alıcı hesabının dəyişdirilməsi, əlaqəsiz sənədlərin axtarılması, xarici URL-ə məlumat ötürülməsi, təsdiq qapısından yan keçmək və alət parametrini manipulyasiya etmək. Uğurlu nəticə sadəcə zərərli mətni rədd etmək deyil; agentin zəruri işi davam etdirməsi, riskli hissəni qeydə alması və lazım olduqda insan rəyinə yönəlməsidir.

İnsan təsdiqi və eskalasiya qaydalarını əvvəlcədən müəyyən edin

“Aşağı etibarda insan yoxlaması” faydalıdır, amma tək meyar olmamalıdır. Modelin etibar balı hər zaman biznes riskini əks etdirmir. Eskalasiya şərtləri həm riskə, həm də qeyri-müəyyənliyə bağlı olmalıdır.

İnsan təsdiqi tələb edən nümunələr

  • geri qaytarılması çətin maliyyə, hüquqi və ya müqavilə əməliyyatları;
  • yeni bank rekviziti, ödəniş statusu və ya tədarükçü məlumatı dəyişiklikləri;
  • şəxsi məlumatın ixracı və ya yüksək həssas sənədə giriş;
  • ziddiyyətli mənbələr, çatışmayan sübut və ya qeyri-standart istisna;
  • yeni alət, yeni səlahiyyət və ya prosedurdan kənar sorğu.

Təsdiq ekranında operatorun qərar verməsi üçün kifayət qədər kontekst olmalıdır: ilkin sorğu, agentin təklif etdiyi dəyişiklik, istifadə olunan mənbələr, alət parametrləri, risk səbəbi və geri qaytarma yolu. Bu əməliyyat ekranlarını UI/UX və məhsul dizaynı işinin bir hissəsi kimi dizayn etmək təsdiqi formal klikdən real nəzarətə çevirir.

Model, prompt və ya iş axını dəyişdikdə regression testing edin

Model versiyası, system prompt, alət sxemi, retrieval mənbəyi, icazə siyasəti və ya CRM API-si dəyişirsə, agent dəyişib. Buna görə istehsal buraxılışından əvvəl sabit test dəsti yenidən işlədilməli, əvvəlki nəticə ilə müqayisə edilməli və kritik ssenarilər üzrə bloklayıcı meyarlar tətbiq olunmalıdır.

Regression testinin nəticəsi yalnız ümumi “dəqiqlik faizi” olmamalıdır. Dəyişiklik hansı niyyətlərdə yanlış alət seçiminə, icazə pozuntusuna, daha çox eskalasiyaya, daha az əsaslandırılmış imtinaya və ya daha uzun gecikməyə səbəb olduğunu göstərməlidir. Bu buraxılış intizamı Texniki dəstək və konsaltinq çərçivəsində CI/CD, müşahidəolunma və rollback planı ilə birləşdirilə bilər.

İstehsal qərarı üçün əməliyyat scorecard-ı

İstehsala keçid qərarı üçün vahid bal əvəzinə risk sinfinə görə scorecard hazırlayın:

  • gözlənilən hərəkət və düzgün alət seçimi faizi;
  • qadağan olunmuş əməliyyatların sayı — hədəf kritik sinifdə sıfır olmalıdır;
  • icazəsiz giriş və məlumat sızması cəhdlərinə qarşı dayanma faizi;
  • düzgün eskalasiya və düzgün imtina faizi;
  • alət xətalarından sonra düzgün bərpa və idempotency nəticələri;
  • əməliyyat gecikməsi, xərc limiti və insan növbəsinə düşən yük;
  • tam trace, audit qeydi və test sübutunun mövcudluğu.

NIST-in generativ AI üzrə risk idarəetmə yanaşması da etibarlılıq risklərinin AI həyat dövrü boyunca idarə edilməsini vurğulayır. Praktik nəticə budur: agentin canlıya buraxılması bir dəfəlik demo qərarı deyil, ölçülə bilən sübut, nəzarətli buraxılış və davamlı yenidən qiymətləndirmə prosesidir.

POLADO ilə agent qiymətləndirməsini necə başlamaq olar

POLADO biznes prosesinizi, sistem-of-record inteqrasiyalarınızı və riskli qərar nöqtələrini xəritələşdirərək qiymətləndirmə planı hazırlaya bilər. İşə real hallar əsasında test dataseti, tool-call müqavilələri, icazə matrisi, approval qaydaları, adversarial ssenarilər, regression suite və əməliyyat dashboard-u daxil edilə bilər. Məqsəd agenti daha “azad” etmək deyil; onun faydalı işi etibarlı sərhədlər daxilində yerinə yetirməsini sübut etməkdir.

CRM, ERP, dəstək və ya sənəd axınında agent planlaşdırırsınızsa, POLADO ilə əlaqə saxlayın. Mövcud arxitekturanı və yüksək riskli hərəkətləri qiymətləndirərək istehsal üçün uyğun AI agent testing planı hazırlayaq.