AI orchestration qatı modelin sahib olmadığı altı şeyə sahibdir: sorğuya hansı modelin baxdığı, hansı alətləri çağıra biləcəyi, növbələr arasında nəyi yadda saxladığı, əməliyyat icra olunmazdan əvvəl hansı siyasətin tətbiq edildiyi, nəyin jurnala yazıldığı və nəsə sınanda nə baş verdiyi. Model mətn yaradır. Onu korporativ sistemə çevirən hər şey ətrafdakı qatda yaşayır.

Orchestration-a yapışdırıcı kod kimi baxan komandalar aşağıdakı komponentləri onsuz da kəşf edir — istehsalatda, bir insident sonra bir dənə.

Orchestration qatı əslində nəyə sahibdir?

Sərhədi görməyin ən aydın yolu qat olmasa nəyin sınacağını soruşmaqdır.

Marşrutlaşdırma olmasa, hər sorğu bir modelə gedir — sadə təsnifat mürəkkəb mühakimə ilə eyni qiymətə başa gəlir və bir modelin kəsintisi hər şeyi dayandırır. Alət sərhədi olmasa, modelin girişi tətbiqin əlindəki hər hansı kimlik məlumatıdır. Vəziyyət idarəsi olmasa, hər növbə sıfırdan başlayır. Siyasət qapıları olmasa, geri ödəniş etməyə qərar verən agent onu edir. Observability olmasa, səhv nəticəni sonradan izah etmək mümkün olmur.

Bunların hər biri komponentdir və hər biri aşağıda təsvir olunub. Daha yüksək səviyyəli çərçivə — modelə API çağırışının niyə korporativ AI sistemi olmadığı — AI orchestration nədir məqaləsindədir.

Control plane

Sorğunu qəbul edən və onunla nə olacağını qərara alan komponent. Dörd məsuliyyəti var.

Kimliyin müəyyən edilməsi. Kim soruşur, hansı rolda, kimin adından. Aşağıdakı hər şeyi bu müəyyən edir — hansı data çəkilə bilər, hansı alətlər əlçatandır, hansı əməliyyatlar təsdiq tələb edir. İstifadəçinin kim olduğunu bilməyən orchestration qatı heç nə tətbiq edə bilmir, kimliyi sonradan əlavə etmək isə demək olar yenidən yazmaqdır.

Model marşrutlaşdırması. Bu sorğuya hansı model baxır. Davamlı olan şablon tapşırıq sinfinə görə marşrutlaşdırmadır: təsnifat, çıxarış və marşrutlaşdırmanın özü üçün ucuz və sürətli modellər; mühakimə, sintez və yaratma üçün böyük modellər; domen tələb edəndə isə ixtisaslaşmış modellər.

Xərcdən başqa praktiki fayda əvəzlənə bilənlikdir. Marşrutlaşdırma sərt kodlanmış müştəri yox, control plane qərarı olanda modeli dəyişmək konfiqurasiya dəyişikliyidir. Model mənzərəsinin nə qədər sürətlə dəyişdiyini nəzərə alsaq, modeli dəyişə bilməyən arxitektura son istifadə tarixi olan arxitekturadır.

Sorğunun həyat dövrü. Taymautlar, təkrar cəhdlər, ləğv və aşağıdakı komponent əlçatmaz olanda nə baş verməsi. Adi görünür və demo ilə sistem arasındakı fərqdir.

Büdcə və sürət nəzarəti. İstifadəçi, kirayəçi və iş axını üzrə. On-premise-də bu, xərc yox, GPU tutumudur, amma nəzarət eynidir: nəzarətdən çıxmış agent dövrü klasteri yeməməlidir.

Alətlər və alət sərhədi

Alətlər modelə sadəcə danışmaq yox, nəsə etmək imkanı verən şeydir — bazanı sorğulamaq, sənəd oxumaq, tapşırıq yaratmaq, mesaj göndərmək. Alət sərhədi arxitekturanın təhlükəsizlik baxımından ən vacib hissəsidir.

Etibar sərhədi model yox, alətlərdir. Model təklif edir; icra edib-etməyəcəyinə alət qatı qərar verir. Modeldən gələn hər parametr etibarsız girişdir və veb formadan gələn giriş kimi doğrulanır. Modelin verdiyi sətri sorğuya yerləşdirən alət SQL injection ilə eyni zəiflik sinfidir — sadəcə hücumçusu daha az proqnozlaşdırıla biləndir.

Alətlər sistemin yox, istifadəçinin kimliyi altında işləyir. Alət qatı geniş kimlik məlumatları saxlayırsa, uğurlu prompt injection onları miras alır. Hər alət çağırışını sorğu verən istifadəçinin səlahiyyətlərinə daraltmaq assistentin imtiyaz artırma yoluna çevrilməsinin qarşısını alır — mexanikası təhlükəsiz AI iş axınları qurmaq məqaləsindədir.

Standartlaşdırılmış alət interfeysləri qəbul edilməyə dəyər. Model Context Protocol alətləri və data mənbələrini modellərə açmağın ümumi yoluna çevrilib; əsas platformalar boyu qəbul olunub və konnektor ekosistemi böyüyür. Praktiki dəyər budur ki, bir dəfə yazılmış inteqrasiya hər çərçivə üçün yenidən yazılmaq əvəzinə modellər və tətbiqlər arasında təkrar işlədilə bilir.

Oxuma və yazma alətləri fərqli yanaşma tələb edir. Oxumaları retrieval əhatəsi idarə edir. Yazmalar dünyanı dəyişir və aşağıda müzakirə olunan siyasət qapılarının arxasına aiddir.

Yaddaş və vəziyyət

Komandaların ən çox az qiymətləndirdiyi komponent, çünki demoya lazım olmur.

Tez-tez qarışdırılan üç fərqli vəziyyət növü:

Söhbət vəziyyəti — cari sessiyanın növbələri. Məhdud, keçici və əsasən kontekst pəncərəsinin idarəsi məsələsidir: nəyi hərfi saxlamaq, nəyi ümumiləşdirmək, nəyi atmaq.

İş vəziyyəti — çoxaddımlı tapşırığın gedişi. Hansı addımlar bitib, nə qaytarıb, nə qalıb. Uzunmüddətli tapşırığı sınmadan sonra davam etdirilə bilən edən budur və o, yaddaşda yox, davamlı anbarda saxlanmalıdır, əks halda yenidən başlatma işi itirir.

Uzunmüddətli yaddaş — sessiyalar arasında qalan: istifadəçi seçimləri, əvvəlki qərarlar, yığılmış kontekst. Ən dəyərli və iki səbəbə görə ən təhlükəli olan.

Birincisi, yaddaş data qorunması səthidir. Şəxs haqqında yadda saxlanan hər şey şəxsi məlumatdır və istənilən digər qeyd kimi saxlama, giriş və silinmə tələblərinə tabedir. «Bu şəxs haqqında nə saxlayırsınız» sualına cavab verib onu silə bilməyən yaddaş anbarı funksiya yox, uyğunluq boşluğudur.

İkincisi, yaddaşın zəhərlənməsi real hücumdur. Sistemin qəbul etdiyi məzmun uzunmüddətli yaddaşa yaza bilirsə, hücumçu sessiyalar boyu qalan təlimatlar əkə bilər. Yaddaşa yazmalara alət çağırışları ilə eyni diqqət lazımdır.

Bunların çoxundan yayındıran dizayn qaydası budur: yaddaş əhatəli və atributludur. Saxlanan hər element kimə aid olduğunu, nə vaxt yazıldığını, hansı qarşılıqlı əlaqədən gəldiyini və nə vaxt bitəcəyini qeyd edir.

Siyasətin tətbiqi və təsdiq qapıları

Orchestration qatının infrastruktur olmaqdan çıxıb governance olmağa başladığı yer.

Əməliyyatları vaciblik yox, geri qaytarıla bilənlik üzrə təsnifləndirin. Oxuma pulsuzdur. Geri qaytarıla bilən yazma — qaralama, daxili qeyd — davam edə bilər. Geri qaytarıla bilməyən və ya kənara görünən əməliyyat — müştəriyə mesaj göndərmək, pul köçürmək, konfiqurasiyanı dəyişmək — təsdiq qapısı tələb edir. Bu təsnifat agent sistemində ən faydalı dizayn artefaktıdır və hər hansı agentə yazma aləti verilməzdən əvvəl mövcud olmalıdır.

Təsdiq dialoq pəncərəsi yox, iş axınıdır. Təsdiqləyənə təklif olunan əməliyyat, onun girişləri, mühakimə və qərar vermək üçün kifayət qədər kontekst lazımdır — və təsdiq qeydə alınmalıdır. Qurumda bu qeyd müfəttişin istədiyi sübutdur.

Siyasət icra vaxtı, real parametrlər üzərində qiymətləndirilir. Dizayn vaxtı alət tərifi üzərində yox. Hədddən aşağı geri ödəniş etməyə icazəsi olan agent üçün həmin hədd real məbləğə qarşı yoxlanmalıdır.

Bağlı vəziyyətdə sının. Siyasət xidməti əlçatmaz olanda əməliyyatlar icra olunmur. Əks defolt insidentlərin baş vermə üsuludur.

Observability və audit izi

Bir pipeline-ı paylaşan iki fərqli tələb.

Əməliyyat observability-si — gecikmə, xəta nisbətləri, token və ya GPU sərfi, alət uğursuzluğu nisbətləri, retrieval uğur nisbətləri. Sistemi işlətmək üçün lazım olan.

Audit izi — konkret nəticə üçün: hansı model və versiya, hansı prompt, hansı sənədlər çəkildi, hansı alətlər hansı parametrlərlə işlədi, hansı siyasətlər qiymətləndirildi, kim nəyi təsdiqlədi və kim nəticənin əsasında hərəkət etdi. Sistemi izah etmək üçün lazım olan.

Audit izi jurnal funksiyası yox, arxitektura tələbidir və əvvəldən dizayn olunmalıdır. ISO/IEC 42001 auditinin görmək istədiyi budur və «AI səhv etdi» ilə konkret, düzəldilə bilən defekt arasındakı fərq də elə budur.

İstehsalatda öyrənilmiş bir dizayn qeydi: yalnız prompt-u yox, çəkilmiş konteksti də jurnala yazın. Cavab səhv olanda sual demək olar həmişə modelə nə verildiyidir; prompt şablonu olan, çəkilmiş sənədləri olmayan jurnal isə buna cavab verə bilmir.

Bu necə sınır?

Göründükləri sıra ilə beş uğursuzluq forması.

Dövrələr. Agent sınan aləti sonsuz təkrar edir, ya da iki agent işi bir-birinə ötürür. Addım sayına, real vaxta və tapşırıq başına xərcə sərt limitlər lazımdır — prompt-dakı yumşaq tövsiyə yox.

Səssiz pisləşmə. Mənbə dəyişikliyindən sonra retrieval daha pis nəticələr qaytarmağa başlayır, sistem isə inamla cavab verməkdə davam edir. Bunu yalnız retrieval keyfiyyətinin monitorinqi tutur; istifadəçi şikayətləri xeyli sonra gəlir.

Kontekstin daşması. Uzun söhbət və ya böyük retrieval dəsti pəncərəni aşır və ən erkən təlimatlar — çox vaxt təhlükəsizliyə aid olanlar — ilk kəsilənlər olur. Azaldıcı tədbir təlimatların yerləşdirilməsi və açıq kontekst büdcələridir.

Alət xətalarının data kimi qəbulu. Alət xəta mətni qaytarır, model bunu nəticə sayır və onun əsasında mühakimə yürüdür. Alət cavablarına tipli uğur və uğursuzluq yolları lazımdır.

Agentlər arasında zəncirvari sınma. Çoxagentli dizaynlarda bir agentin səhv nəticəsi digərinin girişi olur və xətalar bir-birini söndürmək əvəzinə qatlanır. Agent qrafiklərini dayaz saxlamağın və hər ötürmədə yoxlamağın əsas arqumenti budur.

Bu problemlərin sahə səviyyəsindəki əksi analitik gözləntilərində görünür: Gartner 2027-ci ilin sonuna qədər agentic AI layihələrinin 40 faizdən çoxunun ləğv olunacağını proqnozlaşdırır və səbəb kimi xərci, aydın olmayan dəyəri və yetərsiz risk nəzarətlərini göstərir. Sağ qalan layihələri yuxarıdakı nəzarətlər ayırır.

On-premise-də bu necə görünür?

Buradakı nəzarət altındakı qurumlar üçün hər komponent perimetrin içində işləyir: modellər, orchestration qatı, alət tətbiqləri, yaddaş anbarı, vektor indeksi və jurnallar.

İki praktiki nəticə.

Model marşrutlaşdırması daha az yox, daha çox əhəmiyyət daşıyır. Elastik bulud yox, məhdud GPU tutumu olanda ucuz tapşırıqları kiçik modellərə yönləndirmək tutum qərarıdır. Ölçülmə və xərc mühakiməsi LLM-lərin on-premise tətbiqi məqaləsindədir.

Jurnallar da içəridə qalır. İnferensi lokal saxlayan, amma observability datasını xarici SaaS platformasına göndərən sistem problemi həll etməyib, yerini dəyişib — çünki prompt-lar və çəkilmiş kontekst müntəzəm olaraq şəxsi məlumat daşıyır; bu, Azərbaycanda data rezidentliyi və şəxsi məlumat qanunu məqaləsində açılıb.

Yukon Labs bunun üçün HAVAA-nı quraşdırır — tamamilə müştərinin perimetri daxilində işləyən, control plane, alət sərhədi, siyasət qapıları və audit izi tətbiq kodu yox, birinci dərəcəli komponentlər olan qat.

Əsas məqamlar

  • Orchestration qatı marşrutlaşdırmaya, alətlərə, vəziyyətə, siyasətə, observability-yə və sınmaların idarəsinə sahibdir. Model yalnız yaradır.
  • Control plane əvvəlcə kimliyi müəyyən etməlidir; retrieval əhatəsi, alət əlçatanlığı və təsdiq tələbləri ondan çıxır.
  • Tapşırıq sinfinə görə marşrutlaşdırın. Modellərin dəyişmə sürətini nəzərə alsaq, əvəzlənə bilənlik xərc qədər vacibdir.
  • Etibar sərhədi alətlərdir. Modeldən gələn hər parametri doğrulayın və sistemin yox, istifadəçinin kimliyi altında icra edin.
  • Söhbət vəziyyətini, iş vəziyyətini və uzunmüddətli yaddaşı ayırın. Uzunmüddətli yaddaş həm şəxsi məlumatdır, həm hücum səthidir.
  • Əməliyyatları geri qaytarıla bilənliyə görə təsnifləndirin və geri qaytarılmayanlara təsdiq qapısı qoyun. Siyasəti icra vaxtı qiymətləndirin və bağlı vəziyyətdə sının.
  • Yalnız prompt-ları yox, çəkilmiş konteksti də jurnala yazın. Audit izi jurnal funksiyası yox, arxitektura tələbidir.
  • Dövrələrdən, retrieval-ın səssiz pisləşməsindən, kontekst daşmasından, alət xətalarının data kimi oxunmasından və çoxagentli zəncirvari sınmadan qorunun.

Yukon Labs HAVAA-nı Azərbaycanda on-premise quraşdırır; retrieval isə OvalEdge və Starburst vasitəsilə idarə olunan data üzərində əsaslandırılır. Bu arxitekturanın altındakı anlayışlar üçün AI orchestration nədir məqaləsindən başlayın.