Başdan-başa İstehsal: Yoxlama, Monitorinq və Etika

Qazanclar:

• İdeyadan istehsala qədər LLM xüsusiyyətini götürən başdan sona arxitekturasını dizayn edə bilər
• Doğrulamanın tətbiqi, insan təsdiqi və izləmə səviyyələrini yaradır (giriş/metrikalar)
• Sərhədlər etika və məxfilik prinsiplərini istehsal qərarlarına çevirir

Əvvəlki on bölmədə biz hissələri bir-bir öyrəndik: sorğu strukturu, token iqtisadiyyatı, axın, sistem əmri, model seçimi, keş, toplu, səhvlərin idarə edilməsi, təhlükəsiz açar və avtomatlaşdırma. Bu sonuncu bölmədə biz hissələri birləşdiririk və ideyadan istehsala qədər LLM xüsusiyyətini daşıyan vahid arxitektura qururuq. İstehsal “işləyən nümayiş”dən fərqlidir: yoxlama məcburidir, məhsula nəzarət edilməlidir, sərhədlər və etik prinsiplər qərarlara daxil edilməlidir. Bu bölmə modulun daşıyıcı sütunudur; Əvvəlkilərin hamısı burada birləşir.

İstehsal arxitekturasının təbəqələri

Möhkəm LLM kvalifikasiyası təxminən beş təbəqədən ibarətdir:

1. Giriş qatı: Məlumat toplayın, təmizləyin, həssas sahələri maskalayın, yalnız lazım olanı ötürün.
2. Model təbəqəsi: Düzgün modeli seçin (vahid 5), sistem əmrini və parametrləri təyin edin (vahid 4), keş (vahid 6).
3. Təsdiqləmə qatı: Çıxışı sxem/qayda, mənbə və zəruri hallarda insan təsdiqi ilə yoxlayın.
4. Fəaliyyət səviyyəsi: Təsdiqlənmiş nəticə ilə hərəkəti yerinə yetirin; Yüksək təsirli hərəkətləri çəkin.
5. Monitorinq qatı: Hər zəngi, dəyəri, səhvi və keyfiyyəti qeyd edin və ölçün.

Bu təbəqələr boru kəməridir; hər biri əvvəlkinin çıxışını yoxlayır.

Doğrulama niyə tələb olunur?

LLM-lər səlis, lakin bəzən qeyri-dəqiq nəticə çıxara bilər. Buna hallüsinasiya deyilir: model həqiqət kimi görünən, lakin həqiqətə uyğun olmayan məlumatları uydura bilər. Söhbət oyununda buna dözmək olar; istehsal sistemində (qaimə-faktura, sağlamlıq, hüquq, maliyyə) yol verilə bilməz. Beləliklə, kor-koranə etibarsız olduğu ortaya çıxdı; təsdiqlənir.

Doğrulama təbəqələri (təsirlə artan):

• Format/şemanın təsdiqi: Çıxış gözlənilən JSON sxeminə uyğundurmu? (Strukturlaşdırılmış çıxış əsasən buna zəmanət verir.)
• Qayda/məntiq yoxlaması: Dəyərlər məqbuldurmu? (Məbləğ mənfidir, tarix gələcəkdir, kateqoriya etibarlıdırmı?)
• Mənbənin yoxlanılması: İddia təqdim edilmiş sənədlərə əsaslanırmı? Model sənəddə olmayan bir şeyi deyirmi?
• İnsanın təsdiqi: Ekspert yüksək təsirli və ya qeyri-müəyyən qərarları nəzərdən keçirir.

Diqqət: "Model çox yaxşıdır, əlavə yoxlamaya ehtiyac yoxdur" ən təhlükəli istehsal səhvidir. Modelin nə qədər yaxşı olmasından asılı olmayaraq, yoxlama təbəqəsi yüksək təsirli qərarlarda təhlükəsizlik şəbəkəsidir. Hətta bir səhv avtomatik qərar bütün qənaət olunan vaxtı əlimizdən ala bilər.

İnsan-in-the-Loop

Hər qərarın tam avtomatik olması lazım deyil. İnsan-in-the-loop yanaşmasında model işi sürətləndirir və insan bunu təsdiqləyir. Düzgün balans qərarın təsirindən və modelin həmin vəzifəyə etibarlılığından asılıdır.

Qərarın təsiri

yanaşma

Aşağı (etiket təklifi, qaralama)

Tam avtomatlaşdırma; səhv ucuzdur və geri qaytarıla bilər

Orta (marşrutlaşdırma, prioritetləşdirmə)

Avtomatlaşdırma + seçmə nəzarəti

Yüksək (pul, müqavilə, sağlamlıq, silinmə)

İnsanın razılığı məcburidir; model yalnız təklif edir

Monitorinq: Görmədiyiniz şeyi idarə edə bilməzsiniz

İstehsalda hər zəngə nəzarət etməlisiniz. Monitorinq olmadan siz dəyəri, keyfiyyəti yaxşılaşdıra və ya problemi erkən həll edə bilməzsiniz. Qeyd etmək üçün əsas göstəricilər:

• İstifadə/qiymət: İstək və ümumi ayələr, model paylanması, gündəlik xərclər.
• Gecikmə: Orta və ən pis halda cavab müddəti.
• Səhv dərəcəsi: 429/500 dərəcələr, təkrar cəhdlər, imtinalar.
• Keyfiyyət: Doğrulama səviyyəsində rədd edilmiş çıxış dərəcəsi, insan təsdiqində düzəliş dərəcəsi, istifadəçi rəyi.

İpucu: Monitorinq jurnallarına həssas məlumatları (şəxsi məlumatlar, açarlar) yazmayın. Məxfilik çərçivəsində qeydləri nəzərdən keçirin; zəruri hallarda maskalanaraq qeyd edin (9-cu vahid).

Etika və Sərhədlər

Etik məsuliyyət texniki dəqiqlik qədər istehsal qərarının bir hissəsidir:

• Şəffaflıq: İstifadəçi süni intellektlə və ya insanla danışdığını bilməlidir.
• Ədalətlilik və qərəzlilik: Model öyrədildiyi məlumatlardan qərəzli ola bilər; Yüksək təsirli qərarlarda (işə götürmə, kredit) ayrı-seçkilik nəticələrini izləyin.
• Məsuliyyət: Avtomatlaşdırılmış qərar zərərə səbəb olarsa, siz məsuliyyət daşıyırsınız; “Model belə dedi” müdafiə deyil.
• Limitlərin qəbulu: Model bəzi tapşırıqları etibarlı şəkildə yerinə yetirə bilmir; onları avtomatlaşdırmamaq da dizayn qərarıdır.

Kopyalana bilən şablonlar

# Doğrulama yoxlama siyahısı (çıxış yaradıldıqdan sonra)1) Sxem etibarlıdırmı? (strukturlaşdırılmış çıxışın təsdiqi)2) Dəyərlərin mənası varmı? (qayda yoxlanışı: diapazon, tarix, nömrə)3) İddia mənbəyə əsaslanırmı? (sənəddə yoxdursa, rədd edin)4) Təsir yüksəkdirmi? → insan təsdiqi üçün göndərin5) Əgər hamısı keçibsə → fəaliyyətə icazə verin, yadda saxlayın

# Mənbəyə güvənən qüvvələrin yalnız təqdim olunmuş sənəddəki məlumatlara güvəndiyini bildirən sistem. Sənəddə olmayan heç nə əlavə etməyin. Sənəddə məlumat yoxdursa, "Sənəddə tapılmadı" yazın. Heç vaxt bir şeyi təxmin etmə və ya uydurma.

# İnsanın təsdiq həddi (qərar vermə qaydası)Əgər qərar_növü [pul, müqavilə, silmə, sağlamlıq] → insan təsdiqi məcburidirƏG model_etibar < eşik həddi VEYA doğrulama "qeyri-müəyyən" → insan təsdiqinə təqdim edin. → avtomatik tətbiq + seçmə nəzarəti

# İzləmə jurnalı şablonu (həssas məlumatların yazılması){ "vaxt":"...", "model":"...", "input_token":..., "çıxış_tokeni":..., "gecikmə_ms":..., "stop_reason":"...", "autentifikasiya":"keçildi|reddedildi|insan", "məlumat VERİLİR" və //_}

Zəif tez / Güclü tez (istehsalın etibarlılığı)

# ZƏFİYYƏT (yoxlama yoxdur, mənbə yoxdur, avtomatik tətbiq olunur) Bu sorğunu qiymətləndirin, pulu geri qaytarma qərarı verin və müraciət edin.

# GÜÇLÜ (mənbəyə əsaslanan, tövsiyə yaradır, insanların təsdiqinə buraxır) Bu qaytarma sorğusunu yalnız geri qaytarma siyasəti sənədinə əsasən qiymətləndirin. Qərarı əsaslandırılaraq tövsiyə edin, lakin icra etməyin: {"tövsiyə":"təsdiqləyin|rədd edin","səbəb":"...","siyasət_bəndi":"..."}.Siyasət sənədində aydın əsas yoxdursa, "müəyyən deyil" ifadəsini verin. Yekun qərarı nümayəndə təsdiq edəcək.

Güclü versiya; O, qərarı mənbəyə aid edir, modeli “işləyən” deyil, “təklif edən” kimi yerləşdirir və yüksək təsirli addımı insanların təsdiqinin arxasına qoyur. İstehsalın etibarlılığının mahiyyəti budur.

Üç mini qutu

Case 1 - Doğrulama təbəqəsinin saxlandığı gün. Bir fintech, əməliyyat təsvirlərini təsnif edən və avtomatik mühasibat qeydləri yaratan modelə sahib idi. Onlar qayda təsdiqini əlavə etdilər: model məbləği səhv çıxardıqdan sonra (sənəddə 1250 əvəzinə 12500), “məbləğ sənədə uyğun gəlmir” qaydası çıxışı rədd etdi və rekord insana düşdü. Doğrulama olmasaydı, səhv qeyd sistemə səssizcə daxil olardı.

2-ci hal - Müşahidə tərəfindən tutulan qaçaq. SaaS komandası monitorinq paneli qurmuşdu; Bir səhər gündəlik xərc üç dəfə artdı. Jurnallardan göründü ki, müştəri bir dövrəyə daxil olub və eyni sorğunu minlərlə dəfə göndərib. Onlar kvota və təkmilləşdirmə əlavə etdilər; Problem bir neçə saat ərzində həll olundu. İzləmədən qanun layihəsi ayın sonunda sürpriz olardı.

3-cü hal - limiti qəbul etmək. Səhiyyə startapı tam avtomatik olaraq diaqnoz tövsiyəsi verməyi və onu xəstəyə göstərməyi planlaşdırırdı. Etika və öhdəliklərin nəzərdən keçirilməsində onlar bunun qeyri-məhdud olduğuna qərar verdilər: model yalnız bir xülasə və həkimə mümkün məqamları təqdim edir, həkim diaqnoz qoyur. Bir işi avtomatlaşdırmamaq da yetkin bir dizayn qərarıdır.

Ümumi səhvlər

• Təsdiqləmə keçmək: "model yaxşıdır" deyərək nəticəni kor-koranə tətbiq etmək.
• Yüksək təsirli qərarın avtomatlaşdırılması: Pul/sağlamlıq/hüquqda insanın razılığı vacibdir.
• Nəzarət edilməməsi: Xərc və keyfiyyət problemləri gec aşkar edilir.
• Jurnallara həssas məlumatların yazılması: Məxfiliyin pozulması; Onu maskalamaqla yadda saxlayın.
• Mənbəyə etibar etməyə çalışmayın: Model sənəddə olmayanı təşkil edə bilər.
• Məhdudiyyətlərə məhəl qoymamaq: Bəzi tapşırıqları avtomatlaşdırmamaq düzgün qərardır; Şəffaflıq və məsuliyyət sizindir.

Daha dərin: Relizlərin İdarə Edilməsi, Geri Qaytarma və Artan Yerləşdirmə

LLM funksiyasının istehsala daxil edilməsi onu qurmaq və unutmaq deyil; canlı sistemi zamanla təhlükəsiz şəkildə dəyişdirməkdir. Onun üç sütunu var.

Versiyalaşdırma. Sistem sorğunuz, model seçiminiz və yoxlama qaydaları zamanla dəyişir. Versiyada hər bir əhəmiyyətli dəyişiklik və hansı versiyanın canlı olduğunu qeyd edin. Bir gün keyfiyyət aşağı düşsə, "nəyi dəyişdik?" Suala bir neçə dəqiqə ərzində cavab verə bilməlisiniz. Versiyasız sistemdə reqressiyanın əsas səbəbini tapmaq günlər çəkir.

Geriyə qayıt. Əgər yeni göstəriş və ya model canlı yayımda gözləniləndən daha pis davranarsa, siz tez bir zamanda əvvəlki, tanınmış versiyaya qayıda bilməlisiniz. Geri qaytarma planı olmayan dəyişiklik canlı riski kor-koranə qəbul edir. “Bir şeyi dəyişdim, pis oldu, geri dönə bilmirəm” ən bahalı istehsal ssenarisidir.

Tədricən yayılma. Dəyişikliyi bir anda bütün trafikə tətbiq etmək əvəzinə, əvvəlcə onu kiçik bir faizə (məsələn, 5%) yayırsınız və ölçülərə (keyfiyyət, xərc, səhvlər) nəzarət edirsiniz. Yaxşı olarsa, faizi artırırsınız; Əgər pisdirsə, yalnız kiçik bir hissəyə təsir etməklə onu geri alacaqsınız. Bu, riski xeyli məhdudlaşdırır.

Bu üç təcrübə bütün əvvəlki bölmələrdən olan texnikaları birləşdirir: qiymətləndirmə (vahid 5) dəyişikliyi əvvəlcədən ölçür, monitorinq (bu bölmə) yayılma zamanı erkən xəbərdarlıq edir, yoxlama təbəqəsi səhv nəticələri hərəkətə keçməzdən əvvəl tutur. İstehsal tək bir düzgün quraşdırma deyil; Ölçən, nəzarət edən və inamla dəyişə bilən davamlı intizamdır. Bütün modul bu nizam-intizamı qurmağınız üçündür.

Xülasə

İstehsal işləyən demodan daha çox şeydir: bu, giriş, model, yoxlama, fəaliyyət və monitorinq təbəqələrinin boru kəməridir. Çıxış yoxlanılmadan etibarsızdır; yüksək təsirli qərarlar insanların razılığına bağlıdır; Hər bir zəng qiymət, səhv və keyfiyyət baxımından izlənilir. Etika, şəffaflıq, qərəzliliyə nəzarət, hesabatlılıq və məhdudiyyətlərin qəbulu texniki qərarların ayrılmaz hissəsidir. Bu modulda öyrənilən hər bir parça bu vahid dizaynda birləşir.

Tətbiq tapşırığı

LLM xüsusiyyətini başdan sona dizayn edin. (1) Xüsusi tapşırığınız üçün beş təbəqəni (giriş, model, yoxlama, fəaliyyət, monitorinq) doldurun. (2) Hansı qərarların insanların təsdiqini tələb edəcəyini təsirinə görə qeyd edin. (3) Ən azı üç doğrulama yoxlaması yazın (sxem, qayda, mənbə). (4) İzləyəcəyiniz əsas ölçüləri və nələri daxil etməyəcəyinizi müəyyənləşdirin. (5) Bu xüsusiyyətdə qəbul etdiyiniz hədd və etik prinsipi yazın.

yoxlama siyahısı

• [ ] Mən hasilat boru kəmərinin beş qatını layihələndirə bilərəm.
• [ ] Mən çıxışı sxem, qayda və mənbə ilə təsdiqləyə bilərəm.
• [ ] Qərarın təsirinə əsaslanaraq insanların təsdiq həddi təyin edə bilərəm.
• [ ] Mən dəyəri, səhvi və keyfiyyəti izləyirəm və həssas məlumatları jurnallara yazmamağa çalışıram.
• [ ] Mən etika, məsuliyyət və sərhədləri istehsal qərarlarına çevirə bilərəm.

Modul imtahanı

1. LLM chat API-də "sistem" rolu nə edir?

• A) Modelə bütün söhbət boyu tətbiq olunan daimi göstərişlər və davranış qaydaları verir ✔
• B) İstifadəçinin yazdığı sonuncu sualı saxlayır
• C) Modelin yaratdığı cavabı saxlayır
• D) API açarını şifrələyir

Təsvir: Sistem rolu modelə bütün söhbət boyu tətbiq olunan davamlı təlimatlar, şəxsiyyət və qaydalar verir; Bu, istifadəçi mesajlarından ayrı, yüksək səviyyəli yönləndirmədir.

2. Niyə danışıq tarixçəsi (əvvəlki mesajlar) API sorğusunda hər dəfə yenidən göndərilir?

• A) Server tarixçəni sildiyi üçün ehtiyat nüsxəsini çıxarmaq lazımdır
• B) API çağırışları vətəndaşlığı olmayandır; ✔ Kontekst hər sorğuda yenidən göndərilir, çünki model tarixi xatırlamır
• C) Yalnız hesab-faktura üçün tələb olunur, modelə heç bir təsiri yoxdur
• D) Cavabın sürətini azaltmamaq üçün tarixçənin göndərilməsi məcburidir

İzahat: LLM API zəngləri vətəndaşlığı olmayandır; Model əvvəlki raundları xatırlamır, ona görə də konteksti qorumaq üçün bütün müvafiq tarixlər hər sorğuya göndərilir.

3. LLM qiymətində “token” nədir?

• A) API-yə daxil olmaq üçün istifadə olunan birdəfəlik parol
• B) Hər sorğu üzrə ödənilən sabit haqq
• C) Modelin mətni emal etdiyi ən kiçik vahid; adətən söz hissəsinə uyğun gəlir ✔
• D) Yalnız çıxışın uzunluğunu ölçən vahid

Təsvir: Token modelin mətni emal etdiyi ən kiçik vahiddir; O, adətən sözün fraqmentinə uyğun gəlir və həm giriş, həm də çıxış işarələrin sayına əsasən hesablanır.

4. Nə üçün əksər LLM provayderlərində çıxış tokenləri giriş tokenlərindən daha bahadır?

• A) Çıxış işarələri həmişə girişdən uzun olur
• B) Daxiletmə nişanları pulsuzdur
• C) Çıxış tokenləri internet üzərindən iki dəfə göndərilir
• D) Məhsul vahidinin maya dəyəri daha yüksəkdir, çünki məhsul istehsalı hər bir işarə üçün əlavə hesablamalar tələb edir ✔

Təsvir: Çıxış tokenlərinin hər biri modeldən addım-addım generasiya (hesablama) yerinə yetirməyi tələb edir; Bu istehsal dəyəri birdən-birə girişi emal etməkdən daha yüksəkdir, buna görə də çıxış vahidinin qiyməti adətən daha yüksək olur.

5. Hansı vəziyyətdə yayımdan istifadə daha faydalıdır?

• A) Uzun cavablarda; Hiss olunan gecikməni azaldır və fasilənin qarşısını alır ✔
• B) Yalnız çox qısa, bir sözdən ibarət cavablarda
• C) Xərcləri sıfıra endirmək
• D) API açarını gizlətmək üçün

Təsvir: Uzun cavablarda axın ilk sözlərin dərhal görünməsi ilə qəbul edilən gecikməni azaldır və böyük max_tokens dəyərlərində HTTP fasilələrinin qarşısını alır.

6. Müasir modellərdə “səy” parametrinin artırılması ümumiyyətlə nəyə təsir edir?

• A) Həmişə cavabı qısaldın
• B) API açarını avtomatik fırladın
• C) Yalnız giriş tokeninin qiymətini azaldır
• D) Düşüncə dərinliyini və əlamətdar xərcləri artırır; Bu, keyfiyyəti yaxşılaşdıra bilər, lakin gecikmə və xərcləri də artırır ✔

Təsvir: Səy parametri modelin tapşırıq haqqında nə qədər dərindən düşünəcəyini və nə qədər token sərf edəcəyini tənzimləyir; Təkmilləşdirmə keyfiyyəti yaxşılaşdıra bilər, lakin gecikməni və xərcləri də artırır. Sadə tapşırıqlar üçün az səy kifayətdir.

7. Sadə, yüksək həcmli təsnifat tapşırığına ən sərfəli yanaşma hansıdır?

• A) Həmişə ən bahalı və ən güclü modeldən istifadə edin
• B) Hər sorğu üçün bütün modelləri eyni anda çağırmaq
• C) Bir az qiymətləndirmə ilə onu yoxlayaraq tapşırığı yerinə yetirən ən yüngül/ucuz modeli seçmək ✔
• D) max_tokens dəyərini lazımsız yerə çox yüksək saxlamaq

İzahat: Tapşırıq mürəkkəb deyilsə, ən bahalı və güclü modeldən istifadə etmək əvəzinə tapşırığı asanlıqla yerinə yetirən daha sürətli və daha ucuz modeli (məsələn, Haiku sinfi) seçmək maya dəyərini əhəmiyyətli dərəcədə azaldacaq.

8. Hansı ssenaridə operativ keşləmə xərcləri daha çox azaldır?

• A) Böyük və sabit kontekst bir çox sorğuda təkrar istifadə edildikdə ✔
• B) Hər sorğu ilə tamam fərqli mətn göndərildikdə
• C) Yalnız bir sorğu verildikdə
• D) Çıxış tokenlərini azaltmaq üçün

Təsvir: Keşləmə prefiks uyğunluğudur; Böyük, dəyişməz kontekstin (sistem əmri, sənədlər) bir çox sorğuda təkrar istifadə edildiyi hallarda, keşdən oxumaq tam qiymətin kiçik bir hissəsini (~0,1x) təşkil edir.

9. Mən sorğunu necə redaktə etməliyəm ki, sorğu keşi vurulsun?

• A) Dəyişən məzmunun başlanğıcda və sabit məzmunun sonunda qoyulması
• B) Hər sorğu üçün sistem sorğusunda cari tarix və vaxtı yerləşdirin
• C) Sabit məzmunun (sistem əmri, sənədlərin) əvvəlinə və dəyişən məzmunun sonuna qoyulması ✔
• D) Hər sorğu ilə alətlər siyahısının sırasının dəyişdirilməsi

İzahat: Keş prefiks uyğunluğu olduğundan, sabit/dəyişməyən məzmun (sistem sorğusu, sənədlər) işə salınır; dəyişən məzmun (tarix, istifadəçi sualı, sorğu ID) sonunda qoyulur. Başlanğıcda dəyişdirilən bir bayt belə keşi etibarsız edəcək.

10. Toplu emal hansı növ iş yükü üçün daha uyğundur?

• A) İstifadəçinin ekranda ani cavab gözlədiyi canlı söhbət
• B) Sadəcə bir qısa sual
• C) API açarının yaradılması
• D) Gecikməyə dözümlü, həcmi böyük olan və dərhal nəticə tələb etməyən işlər ✔

Təsvir: Toplu emal dərhal cavab tələb etməyən və gecikməyə dözümlü olan böyük həcmli işlərə uyğundur; nəticələr müəyyən müddətdən sonra çatdırılır, lakin vahid dəyəri adətən daha aşağı olur.

11. Nəticələrin topluda hansı sorğuya aid olduğunu əminliklə uyğunlaşdırmaq üçün nədən istifadə olunur?

• A) Sorğuların sifarişinin (vəzifəsinin) göndərilməsi
• B) Cavabların uzunluğu
• C) API açarının son 4 rəqəmi
• D) Hər sorğuya verilən unikal xüsusi_id ✔

Qeyd: Toplu nəticələr təqdim etmə sifarişindən fərqli qaydada qaytarıla bilər; buna görə də nəticələri hər sorğuya verilən unikal custom_id ilə yerə deyil, ID-yə görə uyğunlaşdırmaq lazımdır.

12. API-dən 429 (dərəcə limiti) xətası aldığınız zaman tövsiyə olunan davranış hansıdır?

• A) Eyni zamanda daha çox sorğu göndərməklə məcbur etmək
• B) Eksponensial geri çəkilmə ilə yenidən cəhd etmək, təkrar cəhddən sonra başlığı izləmək ✔
• C) Sorğunu tamamilə ləğv edin və səhvi istifadəçiyə qəza kimi göstərin
• D) API açarının dəyişdirilməsi

İzahat: 429 təkrar cəhd edilə bilən xətadır; Düzgün yanaşma, təkrar cəhddən sonra başlığa hörmət edərək, eksponensial geriləmə ilə yenidən cəhd etməkdir. Əksər rəsmi SDK bunu avtomatik edir.

13. Aşağıdakı HTTP xəta kodlarından hansı ümumiyyətlə təkrar sınana bilən hesab olunur?

• A) 400 (etibarsız sorğu)
• B) 401 (identifikasiya xətası)
• C) 529 (server həddən artıq yüklənib) ✔
• D) 404 (tapılmadı)

İzahat: 429 (sürət həddi), 500 (server xətası) və 529 (həddindən artıq yükləmə) müvəqqəti xətalardır və geri çəkilməklə yenidən cəhd edilə bilər. 400 və 401 kimi xətalar sorğu/identifikasiya məsələləridir; Yenidən cəhd bunu həll etməyəcək.

14. Aşağıdakılardan hansı API açarlarını idarə etməyin təhlükəsiz yoludur?

• A) Mühit dəyişəninin/gizli menecerin saxlanması, kodun içərisinə daxil edilməməsi və müntəzəm olaraq fırlanması ✔
• B) Açarı birbaşa mənbə koduna yazın və depoya göndərin
• C) Açarın müştəri tərəfində (brauzerdə) JavaScript-ə qoyulması
• D) E-poçt vasitəsilə bir açarın bütün komanda ilə paylaşılması

Təsvir: Açarlar heç vaxt mənbə koduna və ya depoya yazılmır; O, mühit dəyişkənində və ya gizli idarəetmə alətində saxlanılır, minimal imtiyazlarla verilir və müntəzəm olaraq fırlanır.

15. Məxfilik baxımından avtomatlaşdırma aləti (n8n, Zapier, Make) ilə LLM inteqrasiyasına ən yaxşı yanaşma hansıdır?

• A) Lazım olmasa belə, bütün xam verilənlərin modelə göndərilməsi
• B) API açarının axın addımı daxilində düz mətnlə yazılması
• C) Həssas məlumatların minimuma endirilməsi və maskalanması və açarın məxfi etimadnamələr kimi saxlanması ✔
• D) Fərdi məlumatların axın tarixində daimi saxlanılması

Təsvir: Avtomatlaşdırmaya daxil olan məlumat üçüncü tərəf sistemləri və modelindən keçdiyi üçün həssas/şəxsi məlumatlar minimuma endirilməli, maskalanmalı və yalnız tələb olunan sahələr göndərilməlidir; API açarı alət daxilində məxfi etimadnamələr kimi də saxlanılır.

16. Nə üçün LLM əsaslı istehsal xüsusiyyətində məhsulun yoxlanılması məcburidir?

• A) Yalnız formatlaşdırma tələb olunur, çünki model heç vaxt səhv etmir
• B) Model axıcı, lakin bəzən səhv istehsal edə bildiyi üçün; Sxem/qayda resurs və insan razılığı ilə yoxlanılmalıdır ✔
• C) Validasiyadan qaçmaq lazımdır, çünki bu, yalnız maya dəyərini artırır
• D) Doğrulama yalnız tokenlərin sayını azaltmaq üçündür

Təsvir: LLM-lər səlis, lakin bəzən qeyri-dəqiq (hallüsinasiyalı) çıxışlar yarada bilər; beləliklə, yüksək təsirli qərarlarda ortaya çıxdı; O, sxem/qaydaların yoxlanılması, mənbənin yoxlanılması və lazım gəldikdə insanların təsdiqi ilə yoxlanılmalıdır.