Korporativ AI layihələri nadir hallarda modelin zəifliyinə görə uğursuz olur. Onlar on təkrarlanan tətbiq səhvinə görə sınır: modeldən başlamaq, baza ölçüsünün olmaması, buna İT layihəsi kimi baxmaq, kölgə rejimini atlamaq, təhlükəsizliyi hər layihədə yenidən qurmaq, kimliyi sona saxlamaq, faktları fine-tuning etmək, retrieval-ı qiymətləndirməmək, ingiliscə performansın ötürüldüyünü güman etmək və sistemi kimin işlədəcəyini heç vaxt qərara almamaq.

Hər birindən yayınmaq olar və yayınılmayanda hər biri təxminən bir rübə başa gəlir.

Layihələr pilotla istehsalat arasında niyə dayanır?

Çünki pilot və istehsalat sistemi fərqli meyarlarla qiymətləndirilir. Pilot cavabların təsirli olub-olmaması ilə qiymətləndirilir. İstehsalat sistemi isə işlədilə, audit edilə, qorunа və yaxşılaşdırıla bilməsi ilə — bunların heç biri demoda görünmür.

Fərq sahə 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 artan xərcləri, aydın olmayan biznes dəyərini və yetərsiz risk nəzarətlərini göstərir. Bu üç başlıq aşağıdakı səhvlərə demək olar dəqiq oturur.

Səhv 1 — modeldən başlamaq

Ən çox rast gəlinən açılış gedişi: model seçmək, sonra onunla nə etmək olacağını axtarmaq.

Bu, ardıcıllığı tərsinə çevirir. Model korporativ AI sisteminin ən az fərqləndirici komponentidir — hamının müqayisə oluna bilən modellərə çıxışı var — nəticələri isə əslində retrieval keyfiyyəti, dataya giriş və prosesə uyğunluq müəyyən edir. Model seçimi ətrafında qurulmuş layihə ilk həftələrini ən az əhəmiyyət daşıyan qərara sərf edir.

Əvəzinə: əvvəlcə prosesi seçin — sahələr üzrə AI agent ssenariləri məqaləsindəki meyarlarla — sonra ona hansı datanın lazım olduğunu müəyyən edin, sonra öhdəlik yox, konfiqurasiya kimi model seçin.

Səhv 2 — baza ölçüsünün olmaması

Layihə assistentin yaxşı cavab verdiyini bildirir. Prosesin sürətlənib-sürətlənmədiyini isə heç kim deyə bilmir, çünki əvvəlini heç kim ölçməyib.

Bu, mövcud ən bahalı inzibati uğursuzluqdur, çünki geriyə dönük düzəldilə bilmir. Sistem işə düşəndən sonra tətbiqdən əvvəlki rəqəm yox olur.

Əvəzinə: hər şey qurulmazdan əvvəl dövr müddətini və insan toxunma vaxtını, həmçinin istisna və ya eskalasiya nisbətini ölçün. İki günlük ölçmə bütün biznes arqumentini qoruyur.

Səhv 3 — buna İT layihəsi kimi baxmaq

Layihəni mühəndislər aparır, İT sponsorluq edir, biznes isə yalnız demolara cəlb olunur. Nəticədə texniki cəhətdən sağlam, amma heç kimin mənimsəmədiyi sistem alınır, çünki güman etdiyi iş axını mövcud iş axını deyil.

Əvəzinə: prosesin sahibi layihənin həmsahibidir, işi görən adamlar birinci həftədən nəticələrə həftəlik baxır və uğur metriki biznesin onsuz da izlədiyi rəqəmdir.

Səhv 4 — kölgə rejimini atlamaq

Sistem kurasiya olunmuş data üzərindəki pilotdan birbaşa canlı istifadəyə keçir və ilk real dəqiqlik ölçüsü layihənin etibarına ehtiyacı olan adamların gözü qarşısında alınır.

Kölgə rejimi — agent real halları emal edir, nəticəsi qeyd olunur və işlədilmir — təqvim vaxtından başqa heç nəyə başa gəlmir və işə salınmadan əvvəl mövcud yeganə dürüst dəqiqlik rəqəmini verir. Onu atlamaq layihənin birinci həftədə istifadəçi etibarını itirməsinin ən çox rast gəlinən səbəbidir, erkən itirilmiş etibarı geri qazanmaq isə bahadır.

Əvəzinə: iki-dörd həftə kölgə, sonra köməkçi rejim, sonra nəzarətli avtomatlaşdırma. Ardıcıllıq AI agentləri biznes proseslərini necə avtomatlaşdırır məqaləsindədir.

Səhv 5 — təhlükəsizliyi hər layihədə yenidən qurmaq

Hər komanda öz sürət limitlərini, kill switch-lərini, redaksiyasını, injection müdafiəsini və təsdiq axınlarını son tarixinin imkan verdiyi keyfiyyətdə qurur. Üç layihə üç təsdiq mexanizmi verir və biri qapısız çıxır.

Üç uğurlu pilotu qurum miqyaslı risk səthinə çevirən şablon budur və platforma səviyyəli təhlükəsizliyin göründüyündən qiymətli olmasının səbəbi də elə budur — arqument HAVAA korporativ AI transformasiyasını necə mümkün edir məqaləsində açılıb.

Əvəzinə: təhlükəsizliyi, təsdiqləri və auditi platforma qatında bir dəfə qurun, layihələr isə onları miras alsın.

Səhv 6 — kimliyi sona saxlamaq

Prototip ən sürətli yol olduğu üçün geniş girişli xidmət hesabı altında işləyir. Təhlükəsizlik baxışı istifadəçi üzrə səlahiyyətlərin necə tətbiq olunduğunu soruşur və cavab arxitekturanın yenidən qurulmasını tələb edir.

Kimliyin ötürülməsi əlavə ediləcək funksiya deyil; arxitekturanın ya olan, ya olmayan xüsusiyyətidir. Onu gec əlavə etmək demək olar yenidən yazmaqdır və uğurlu pilotun istehsalata çatmamasının ən çox rast gəlinən səbəblərindən biridir.

Əvəzinə: istifadəçi kimliyini ilk prototipdən etibarən hər retrieval-a və hər alət çağırışına ötürün — prototipin bir istifadəçisi olsa belə. Mühakimə təhlükəsiz AI iş axınları qurmaq məqaləsindədir.

Səhv 7 — faktları fine-tuning etmək

Komanda modeli daxili sənədlər üzərində fine-tuning edir ki, o, təşkilatı «bilsin». Altı ay sonra faktlar dəyişib, model yox; heç bir cavab mənbə göstərə bilmir və faktı silmək yenidən təlim deməkdir.

Fine-tuning forma üçün effektivdir — üslub, nəticə quruluşu, təsnifat tapşırığı. Faktlar üçün zəif mexanizmdir və üstəlik data qorunması problemi yaradır, çünki model çəkilərinə qarşı silinmə sorğusu silmə əməliyyatı deyil.

Əvəzinə: faktları retrieval ilə əsaslandırın, fine-tuning-i isə forma üçün saxlayın — korporativ AI-da kontekst niyə vacibdir məqaləsində açılıb.

Səhv 8 — retrieval-ın qiymətləndirilməməsi

Keyfiyyət epizodik qiymətləndirilir. Kimsə pis cavab alır, komanda prompt-u və ya modeli dəyişir və heç kim nəyinsə yaxşılaşıb-yaxşılaşmadığını deyə bilmir.

Qiymətləndirmə dəsti olmadan sistem yaxınlaşmır, çünki düzəlişi dəyişiklikdən ayırmağın yolu yoxdur.

Əvəzinə: düzgün mənbələri məlum olan yüz real sual, retrieval generasiyadan ayrı ölçülməklə, hər dəyişiklikdə və sonra ayda bir yenidən işlədilir. Domen mütəxəssisi ilə bir həftə çəkir və layihədəki ən gəlirli həftədir.

Səhv 9 — ingiliscə performansın ötürüldüyünü güman etmək

Pilot ingiliscə sənədlərdə yaxşı işləyir. İstehsalat korpusu isə əsasən azərbaycancadır və keyfiyyət nəzərəçarpacaq dərəcədə düşür — amma heç kim dil üzrə ölçmədiyi üçün düşüş «modelin» üstünə yazılır və kömək etməyən model dəyişikliyi ilə cavablandırılır.

Azərbaycan dili ümumi təyinatlı modellərdə və embedding-lərdə ingilis və ya rus dilindən nəzərəçarpacaq dərəcədə az təmsil olunur. Bu, qeyd yox, ölçülə bilən mühəndislik məhdudiyyətidir və buradakı qurumların qarışıq dilli reallığı ilə birləşir — azərbaycanca siyasət, ingiliscə texniki sənədləşmə, rusca köhnə prosedurlar.

Əvəzinə: əvvəldən dil üzrə qiymətləndirin, sorğuları business glossary ilə genişləndirin və indeksdə diakritikanı birləşdirin. Metadata tərəfi bir catalog-da AZ/EN/RU metadata-nın idarə olunması məqaləsindədir.

Səhv 10 — sistemi kimin işlədəcəyini qərara almamaq

Layihə komandası sistemi qurur, təhvil verir və dağılır. Altı ay sonra korpus köhnəlib, retrieval keyfiyyəti sürüşüb, istisna jurnalına heç kim baxmayıb və istifadə səssizcə sıfıra enib.

AI sistemləri sınmır, pisləşir. Sahibi olmadan pisləşmə istifadəçilər artıq etibarı itirənə qədər görünmür.

Əvəzinə: istismara verməzdən əvvəl sistemi məqsədlərinə yazılmış sahib təyin edin və iş ritmini müəyyən edin: aylıq retrieval qiymətləndirməsi, aylıq istisna jurnalı baxışı, rüblük korpus aktuallığı yoxlaması.

Onunun hamısından yayınan ardıcıllıq nədir?

Layihələr boyu işləmiş ardıcıllıq, konkret şəkildə.

1–2-ci həftələr — prosesi seçin və bazanı götürün. Tapşırıq həcmləri, dövr müddəti, toxunma vaxtı, istisna nisbəti. Korpusun mövcud və aktual olduğunu, datanın isə istifadəçi üzrə səlahiyyətlərlə əlçatan olduğunu təsdiqləyin.

3–4-cü həftələr — qiymətləndirmə dəstini qurun. Düzgün mənbələri göstərilmiş yüz real sual, təşkilatın işlədiyi hər dildə.

5–8-ci həftələr — kimlik, siyasət və auditlə birinci commit-dən qurun. Sonradan əlavə edilmədən. Retrieval keyfiyyəti həftəlik olaraq qiymətləndirmə dəstinə qarşı ölçülür.

9–12-ci həftələr — real hallar üzərində kölgə rejimi. Dəqiqlik ölçülür, uğursuzluq formaları təsnifləndirilir, retrieval yaxşılaşdırılır.

13–16-cı həftələr — köməkçi rejimdə tətbiq. Nəticə işi görən adamlara göstərilir; qəbul nisbəti izlənilir; redaktələr yaxşılaşdırma siqnalı kimi işlədilir.

Sonra — nəzarətli avtomatlaşdırma, ardınca seçmə baxış. İmkan işə salma qərarı kimi yox, sübutlar yığıldıqca verilir.

Şablon budur: governance, kimlik və ölçmə əvvəl gəlir və o vaxt ucuz olur; hər biri sonradan geydiriləndə bahadır və uyğunluq baxışının soruşacağı ən azı biri məhz onlardır.

Açıq deməyə dəyən digər ilkin şərt: ssenariyə lazım olan data idarə olunmursa, təsniflənməyibsə və ya əlçatmazdırsa, layihə AI etiketi geymiş data layihəsidir. Bunu erkən tanımaq uğursuz AI layihəsini uğurlu governance layihəsinə çevirir — Azərbaycanda korporativ AI məqaləsindəki təkrarlanan mövzu da budur.

Əsas məqamlar

  • Model ən az fərqləndirici komponentdir. Onu birinci seçmək erkən səyi ən az əhəmiyyət daşıyan qərara sərf edir.
  • Qurmazdan əvvəl dövr müddətini, toxunma vaxtını və istisna nisbətini ölçün. Baza geriyə dönük götürülə bilmir.
  • Layihəyə yalnız mühəndisləri yox, prosesin sahibini də qoyun və nəticələrə real istifadəçilərlə həftəlik baxın.
  • Kölgə rejimi işlədin. Bu, işə salınmadan əvvəl mövcud yeganə dürüst dəqiqlik rəqəmidir və istifadəçi etibarını qoruyur.
  • Təhlükəsizliyi, təsdiqləri və auditi platforma qatında bir dəfə qurun; layihə üzrə təhlükəsizlik bir-birindən ayrılan nəzarətlər doğurur.
  • İstifadəçi kimliyini ilk prototipdən ötürün. Sonradan əlavə etmək demək olar yenidən yazmaqdır.
  • Faktları retrieval ilə əsaslandırın, fine-tuning-i yalnız forma üçün işlədin. Çəkilərdəki faktlar yenilənə, göstərilə və silinə bilmir.
  • Dil üzrə qiymətləndirin. Azərbaycandilli performans ingiliscə performansdan çıxmır.
  • İstismara verməzdən əvvəl əməliyyat sahibi təyin edin. AI sistemləri gurultu ilə sınmır, səssizcə pisləşir.

Yukon Labs bu ardıcıllığı HAVAA-nın on-premise tətbiqi ilə aparır və onu OvalEdge və Starburst vasitəsilə idarə olunan data üzərində əsaslandırır. Hazırlıq qiymətləndirməsi bazanı müəyyən edir və ssenariyə lazım olan datanın həqiqətən əlçatan olub-olmadığını təsdiqləyir. Platforma seçimi üçün korporativ AI platforması seçmək məqaləsinə baxın.