AI agentləri biznes proseslərini necə avtomatlaşdırır

AI agenti prosesi avtomatlaşdırmır. O, prosesin içindəki şərh addımlarını avtomatlaşdırır — sənəd oxumaq, müraciəti təsnifləndirmək, rəqəm çıxarmaq, cavab qaralaması hazırlamaq — deterministik addımlar kod olaraq qalır, nəticəli qərarlar isə insanda. Bütöv prosesi başdan-başa avtomatlaşdırmaq bu layihələrin uğursuz olduğu yerdir.

Deməli, iş model seçimi yox, prosesin parçalanmasıdır. Bu məqalə həmin parçalamanın necə aparılması haqqındadır.

Prosesin hansı hissəsini agent götürə bilər?

Hər biznes prosesi addımlar ardıcıllığıdır və hər addım üç kateqoriyadan birinə düşür.

Deterministik addımların verilmiş girişlərlə dəqiq bir düzgün nəticəsi var: haqqı hesablamaq, dəyəri hədlə tutuşdurmaq, qeyd yazmaq, bildiriş göndərmək. Bunlar kodun yeridir. Hesablama aparan agent hesablama aparan funksiyadan yavaş, baha və az etibarlıdır.

Şərh addımları strukturlaşmamış məzmunu oxuyub strukturlu məna çıxarmağı tələb edir: bu sənəd nədir, müştəri nə soruşur, bu bəndlərdən hansı tətbiq olunur, bu sərbəst mətn sahəsi nə deməkdir. Agentlərin həqiqətən yaxşı olduğu addımlar bunlardır və insanı dövrəyə mühakimə ilə heç bir əlaqəsi olmayan səbəblərə görə salan addımlar da elə bunlar idi.

Mühakimə addımları nəticələri ölçüb-biçməyi, mülahizə tətbiq etməyi və ya məsuliyyət götürməyi tələb edir: krediti təsdiqləmək, zərəri rədd etmək, hüquq şöbəsinə qaldırmaq. Bunlar insanlarda qalır — model cavab verə bilmədiyi üçün yox, təşkilata nəticəyə görə cavabdeh adam lazım olduğu üçün.

Parçalama məşqi sadəcə real prosesin hər addımını bu üçündən biri ilə işarələməkdir. Prosesə bir gün çəkir və agent layihəsindəki ən dəyərli saatdır, çünki məyus edən tətbiqlərin çoxunda ya deterministik addımlar modelə verilib, ya da mühakimə addımları heç kimə verilməyib.

Deterministik bölgü niyə bu qədər vacibdir?

İstehsalatda özünü göstərən üç səbəb.

Etibarlılıq. Deterministik funksiya hər dəfə eyni nəticəni verir. Model vermir və bu dəyişkənlik aradan qaldırıla bilmir. Dəqiq düzgün olmalı hər şey — hesablama, hədd yoxlaması, identifikator axtarışı — ehtimallı olmamalıdır.

Xərc və tutum. On-premise-də GPU tutumu məhduddur. Funksiyanın görə biləcəyi işi modelə yönləndirmək şərh addımlarına lazım olan tutumu yeyir — marşrutlaşdırmanın tətbiq yox, control plane məsələsi olmasının səbəbi də budur; AI orchestration arxitekturası məqaləsinə baxın.

İzah edilə bilənlik. Nəsə səhv gedəndə deterministik addımın izlənə bilən səbəbi var. Deterministik hissələri deterministik saxlamaq araşdırma səthini kiçik saxlayır.

Nəticədə alınan arxitektura kodun şərh üçün modeli çağırdığı və qalan hər şeyi özünün etdiyi iş axınıdır — prosesi icra etmək üçün alətlər çağıran model yox. Fərq incə səslənir və sistemin sazlana bilən olub-olmamasını məhz o həll edir.

İnsan harada qalır?

Mühakimə kimi təsnif olunan nöqtələrdə və insanların unutduğu bir yerdə də: istisna yolunda.

Nəticəli əməliyyatlarda təsdiq qapıları. Əməliyyatları geri qaytarıla bilənliyə görə təsnifləndirin. Oxumalar pulsuzdur, geri qaytarıla bilən yazmalar davam edə bilər, geri qaytarılmayan və ya kənara görünən əməliyyatlar təsdiq tələb edir. Təsdiqləyənə modelin öz mühakiməsi haqqında yazdığı xülasə yox, təklif olunan əməliyyat, onun girişləri və sübutlar lazımdır.

İstisnaların idarəsi. Agent addımı inamla tamamlaya bilmirsə, dayanır və konteksti yığıb insana yönləndirir. İnsanların sistemə etibar edib-etməyəcəyinə ən çox təsir edən dizayn qərarı budur: qeyri-müəyyənlikdə təxmin edən agent soruşan agentdən pisdir, çünki təxmin səhvi aşağı axına, tutulması daha çətin olan yerə ötürür.

İnamlı yolda da seçmə baxış. Tamamlanmış halların müəyyən faizinə insan tərəfindən fasiləsiz baxılır. Bu, başlanğıc mərhələsinin işi deyil — daimi nəzarətdir, çünki mənbə məzmunu dəyişdikcə keyfiyyət sürüşür və başqa cür heç kim bunu görmür.

Praktiki dizayn qaydası: agentin nəticəsi müəyyən edilmiş şərt onu yekunlaşdırana qədər təklifdir. Bəzən şərt insan təsdiqidir, bəzən deterministik doğrulamanın keçməsi, bəzən seçmə baxış rejimi ilə birləşdirilmiş inam həddi. Heç vaxt qəbul edilməyən hal isə şərtin ümumiyyətlə deyilməməsidir.

İstisnalar əslində necə idarə olunmalıdır?

Tətbiqin real həcmlə görüşdən sağ çıxıb-çıxmayacağını həll edən və demoların heç vaxt göstərmədiyi hissə.

İstisnaları uğursuzluq kimi yox, kontekstlə yönləndirin. İstisnanı alan adam sənədi, agentin nə çıxardığını, nəyi həll edə bilmədiyini və səbəbini almalıdır. «Əl ilə baxış tələb olunur» deyən istisna növbəsi ilkin işi yenidən yaradır və üstünə bir addım əlavə edir.

İstisna nisbətini əsas keyfiyyət metriki sayın. O, dəqiqlikdən daha məlumatlıdır, çünki etiketlənmiş data olmadan istehsalatda müşahidə oluna bilir. Artan istisna nisbəti mənbə məzmununun və ya yuxarı axındakı sistemlərin dəyişdiyinə dair ən erkən siqnaldır.

İstisnaları dizayna geri qaytarın. Eyni istisnanın əlli dəfə görünməsi ya əskik imkandır, ya da heç kimin nəzərə almadığı sənəd növüdür. İstisna jurnalına aylıq baxış statik tətbiqi inkişaf edən tətbiqə çevirir.

İstisnanın səssizcə təsdiqə çevrilməsinə heç vaxt imkan verməyin. Yük altında növbələr təmizlənir. Təsdiq interfeysi toplu təsdiqi asanlaşdırırsa, baş verəcək məhz toplu təsdiq olacaq və nəzarət bəzəyə çevriləcək.

İnteqrasiya səthi necə görünür?

Agentlər üç növ sistemə toxunur və inteqrasiya xarakteristikaları fərqlidir.

Oxuma inteqrasiyaları — sənəd anbarları, bazalar, tapşırıq sistemləri, e-poçt. Texniki iş sadədir; governance işi isə yox, çünki retrieval əhatəsi istifadəçi üzrə müəyyən edilməli və tətbiq olunmalıdır. Arxitekturası korporativ AI və RAG üçün lakehouse arxitekturası məqaləsindədir.

Yazma inteqrasiyaları — tapşırıq yaratmaq, qeyd yeniləmək, mesaj göndərmək. Bunlara idempotentlik lazımdır, çünki agentlər təkrar cəhd edir. Hər təkrar cəhddə dublikat tapşırıq yaradan agent dəstək insidenti generatorudur.

İnsana baxan səthlər — təsdiqlərin və istisnaların göründüyü yer. Bunun ayrıca interfeys, yoxsa komandanın onsuz da işlətdiyi alətə inteqrasiya olması real qərardır. Mövcud alətə inteqrasiya adətən adoption-da udur; ayrıca interfeys isə auditin tamlığında. Nəzarət altındakı qurumlarda adətən audit tələbi həlledicidir.

Standartlaşdırılmış alət interfeysləri inteqrasiya başına xərci nəzərəçarpacaq dərəcədə azaldır. Model Context Protocol ümumi yanaşmaya çevrilib və praktiki dəyəri budur: bir dəfə yazılmış inteqrasiya hər çərçivə üçün yenidən qurulmaq əvəzinə modellər və tətbiqlər arasında təkrar işlədilə bilir.

Nəticəni necə ölçmək olar?

Dörd metrik və ilk ikisinin bazası hər şey qurulmazdan əvvəl götürülməlidir.

Dövr müddəti. Halın gəlişindən həllinə qədər nə qədər çəkir. Rəhbərlərin diqqət etdiyi və ən asan manipulyasiya olunan rəqəm — onu yalnız uğurlu yol üzrə yox, istisna yolu da daxil olmaqla başdan-başa ölçün.

İnsan toxunma vaxtı. Hal başına insan diqqətinin dəqiqələri. Dürüst səmərəlilik ölçüsü budur, çünki agentin sürətli olduğu, insanın isə yenə hər şeyi oxuduğu proses yaxşılaşmayıb.

İstisna nisbəti. Agentin tamamlaya bilmədiyi halların payı. Zamanla izlənəndə keyfiyyət siqnalı budur.

Aşağı axındakı xəta nisbəti. Geri qayıdan hallar — düzəlişlər, şikayətlər, yenidən iş. Düzgünlüyün hesabına ötürməni optimallaşdıran sistemi tutan ölçü budur və ən çox buraxılan da elə odur.

Tətbiqlərdən bir qeyd: dövr müddəti toxunma vaxtından əvvəl yaxşılaşır. İlk versiya işi daha sürətli yönləndirir və yenə eyni qədər oxumaq tələb edir. Toxunma vaxtı istisna nisbəti düşəndə və baxıcılar inamlı yola etibar etməyə başlayanda yaxşılaşır — bu isə ikinci rübün nəticəsidir. Gözləntini buna uyğun qurmaq uğurlu layihənin altıncı həftədə uğursuz sayılmasının qarşısını alır.

Yayılma necə gedir?

Beş mərhələ və ardıcıllıq şüurludur.

Mərhələ 1 — kölgə rejimi. Agent real halları emal edir, nəticəsi qeyd olunur, amma işlədilmir. İnsanlar əvvəlki kimi işləyir. Bu, sintetik data üzərindəki heç bir pilotun verə bilmədiyi dəqiqlik ölçüsünü verir və vaxtdan başqa heç nəyə başa gəlmir.

Mərhələ 2 — köməkçi rejim. Agentin nəticəsi işi görən adama göstərilir, o isə qəbul edir, redaktə edir və ya nəzərə almır. İndi qəbul nisbəti canlı keyfiyyət metrikidir, redaktələr isə mövcud ən dəyərli təlim siqnalıdır.

Mərhələ 3 — nəzarətli avtomatlaşdırma. Agent halları tamamlayır, yekunlaşmadan əvvəl insan təsdiqləyir. Qəbul nisbəti sabitləşəndən sonra həcm bura keçir.

Mərhələ 4 — seçmə baxışla avtomatlaşdırma. İnamlı hallar fərdi təsdiq olmadan tamamlanır; müəyyən faizinə baxılır. Səmərəlilik qazancları məhz burada gəlir və bunun üçün əvvəlcə audit izinə etibar olunmalıdır.

Mərhələ 5 — genişlənmə. Qonşu proses addımları, əlavə sənəd növləri, daha çox həcm.

Təşkilatların çoxu 1–3-cü mərhələlərin bir rüb çəkəcəyini gözləməli və 1-ci mərhələni atlamamalıdır. Kölgə rejimi bütün layihədəki ən ucuz məlumatdır, onu atlamaq isə ilk real dəqiqlik ölçüsünün istifadəçilərin gözü qarşısında alınması deməkdir.

Əsas məqamlar

• Agentlər şərh addımlarını avtomatlaşdırır. Deterministik addımlar kodda, mühakimə addımları insanlarda qalır.
• Prosesi hər addımı deterministik, şərh və ya mühakimə kimi işarələməklə parçalayın. Bir gün çəkir və layihədəki ən dəyərli işdir.
• Kod şərh üçün modeli çağırmalıdır, model prosesi işlətmək üçün alətləri yox. Sistemi sazlana bilən edən bu quruluşdur.
• Agentin nəticəsi elan edilmiş şərt onu yekunlaşdırana qədər təklifdir. Şərt heç vaxt gizli qalmamalıdır.
• İstisnaları tam kontekstlə yönləndirin, istisna nisbətini əsas keyfiyyət metriki sayın və istisna jurnalına ayda bir baxın.
• Yazma inteqrasiyalarını idempotent edin; agentlər təkrar cəhd edir.
• Dövr müddətinin və insan toxunma vaxtının bazasını qurmadan əvvəl götürün, aşağı axındakı xəta nisbətini isə hər qiymətə ötürmə artımını tutmaq üçün izləyin.
• Kölgə rejimi, köməkçi rejim, nəzarətli avtomatlaşdırma, sonra seçmə baxış ardıcıllığı ilə yayın. Kölgə rejimini atlamayın.

Yukon Labs HAVAA-nı on-premise tətbiq edir və işə prosesin parçalanmasından başlayır, çünki kod, model və insan arasındakı bölgü tətbiqin davamlı olub-olmayacağını müəyyən edir. Namizəd proseslər üçün sahələr üzrə AI agent ssenariləri, bunun qaydaya əsaslanan avtomatlaşdırmadan fərqi üçün isə AI avtomatlaşdırması və ənənəvi avtomatlaşdırma məqaləsinə baxın.