End-to-end ishlab chiqarish: tekshirish, monitoring va axloq — API, xarajat va integratsiya

Daromadlar:

G'oyadan ishlab chiqarishgacha LLM xususiyatini oladigan, oxirigacha arxitekturani loyihalashi mumkin
Tekshirishni amalga oshirish, odamlar tomonidan tasdiqlash va kuzatuv qatlamlarini o'rnatadi (ro'yxatga olish/ko'rsatkichlar)
Chegaralar etika va maxfiylik tamoyillarini ishlab chiqarish qarorlariga aylantiradi

Oldingi o'nta bo'limda biz qismlarni birma-bir o'rgandik: so'rov tuzilishi, token iqtisodiyoti, oqim, tizim taklifi, model tanlash, kesh, partiya, xatolarni boshqarish, xavfsiz kalit va avtomatlashtirish. Ushbu oxirgi bo'limda biz qismlarni birlashtiramiz va LLM xususiyatini g'oyadan ishlab chiqarishgacha olib boradigan yaxlit arxitekturani o'rnatamiz. Ishlab chiqarish "ishchi demo" dan farq qiladi: tekshirish majburiydir, chiqish nazorat qilinishi kerak, chegaralar va axloqiy tamoyillar qarorlarga kiritilishi kerak. Ushbu birlik modulning tashuvchi ustunidir; Oldingilarning hammasi shu yerda birlashadi.

Ishlab chiqarish arxitekturasining qatlamlari

Qattiq LLM malakasi taxminan besh qatlamdan iborat:

Kirish qatlami: ma'lumotlarni to'plang, tozalang, nozik joylarni maskalang, faqat kerakli narsalarni uzating.
Model qatlami: To'g'ri modelni tanlang (5-birlik), tizim so'rovi va parametrlarini o'rnating (4-birlik), kesh (6-birlik).
Tasdiqlash qatlami: Chiqarishni sxema/qoida, manba va agar kerak bo'lsa, inson ma'qullashiga muvofiq tekshiring.
Harakat qatlami: tasdiqlangan chiqish bilan amalni bajaring; Yuqori ta'sirli harakatlarni suratga oling.
Monitoring qatlami: Har bir qo'ng'iroq, narx, xato va sifatni yozib oling va o'lchang.

Bu qatlamlar quvur liniyasi; har biri oldingisining chiqishini tekshiradi.

Tasdiqlash nima uchun talab qilinadi?

LLMlar ravon, lekin ba'zan noto'g'ri natijalarni berishi mumkin. Bu gallyutsinatsiya deb ataladi: model haqiqatga o'xshab ko'rinadigan, ammo noto'g'ri bo'lgan ma'lumotlarni ishlab chiqishi mumkin. Suhbat o'yinida bunga chidash mumkin; ishlab chiqarish tizimida (hisob-faktura, sog'liqni saqlash, yuridik, moliya) toqat qilib bo'lmaydi. Shunday qilib, ko'r-ko'rona ishonchsiz bo'lib chiqdi; tasdiqlanadi.

Tekshiruv qatlamlari (ta'sir bilan ortib boradi):

Format/sxemani tekshirish: Chiqish kutilgan JSON sxemasiga mos keladimi? (Tuzilgan chiqish asosan buni kafolatlaydi.)
Qoidalar/mantiqiy tekshirish: qiymatlar oqilonami? (Miqdor manfiymi, sana kelajakdami, toifa haqiqiymi?)
Manbani tekshirish: da'vo taqdim etilgan hujjatlarga asoslanganmi? Model hujjatda bo'lmagan narsani aytadimi?
Insonning roziligi: Mutaxassis yuqori ta'sirli yoki noaniq qarorlarni ko'rib chiqadi.

Diqqat: "Model juda yaxshi, qo'shimcha tekshirish kerak emas" - bu eng xavfli ishlab chiqarish xatosi. Model qanchalik yaxshi bo'lmasin, tekshirish qatlami yuqori ta'sirli qarorlar qabul qilishda xavfsizlik tarmog'idir. Hatto bitta noto'g'ri avtomatik qaror ham tejalgan vaqtni olib qo'yishi mumkin.

In-the-Loop

Har bir qaror to'liq avtomatik bo'lishi shart emas. “Inson-in-the-loop” yondashuvida model ishni tezlashtiradi va inson buni ma’qullaydi. To'g'ri muvozanat qarorning ta'siriga va modelning ushbu vazifaga ishonchliligiga bog'liq.

Qarorning ta'siri

Yondashuv

Past (yorliq taklifi, qoralama)

To'liq avtomatlashtirish; xato arzon va qaytarilishi mumkin

O'rta (marshrutlash, ustuvorlik)

Avtomatlashtirish + namuna olish nazorati

Yuqori (pul, shartnoma, sog'liq, o'chirish)

Inson roziligi majburiydir; model faqat taklif qiladi

Monitoring: Siz ko'rmaydigan narsalarni boshqara olmaysiz

Ishlab chiqarishda siz har bir qo'ng'iroqni kuzatishingiz kerak. Monitoringsiz siz narxni, sifatni yaxshilay olmaysiz yoki muammoni erta hal qila olmaysiz. Ro'yxatga olish uchun asosiy ko'rsatkichlar:

Foydalanish/xarajat: har bir so'rov va umumiy tokenlar, model taqsimoti, kunlik xarajatlar.
Kechikish: o'rtacha va eng yomon javob vaqti.
Xato darajasi: 429/500 stavkalari, qayta urinishlar, voz kechish.
Sifat: tekshirish darajasida rad etilgan chiqish tezligi, inson ma'qullashidagi tuzatish tezligi, foydalanuvchining fikr-mulohazasi.

Maslahat: Kuzatuv jurnallariga nozik maʼlumotlarni (shaxsiy maʼlumotlar, kalitlar) yozmang. Maxfiylik doirasidagi jurnallarni ko'rib chiqing; agar kerak bo'lsa niqoblash orqali yozib oling (9-birlik).

Etika va chegaralar

Axloqiy javobgarlik texnik aniqlik kabi ishlab chiqarish qarorining bir qismidir:

Shaffoflik: foydalanuvchi sun'iy intellekt yoki odam bilan gaplashayotganini bilishi kerak.
Adolat va tarafkashlik: Model o'zi o'qitilgan ma'lumotlardan noto'g'ri ma'lumotga ega bo'lishi mumkin; Yuqori ta'sirli qarorlarda (yollash, kredit) kamsituvchi oqibatlarni kuzatib boring.
Mas'uliyat: Agar avtomatlashtirilgan qaror zarar keltirsa, siz javobgarsiz; "Model shunday dedi" - bu himoya emas.
Limitlarni qabul qilish: Model ba'zi vazifalarni ishonchli bajara olmaydi; ularni avtomatlashtirmaslik ham dizayn qaroridir.

Nusxalanadigan shablonlar

# Tekshiruv ro'yxati (chiqish ishlab chiqarilgandan keyin) 1) Sxema to'g'rimi? (Tuzilgan chiqishni tekshirish) 2) Qiymatlar mantiqiymi? (qoida tekshiruvi: diapazon, sana, raqam)3) Da'vo manbaga asoslanganmi? (hujjatda bo'lmasa, rad eting)4) Ta'sir yuqorimi? → inson roziligiga yuboring5) Agar hammasi o'tib ketgan bo'lsa → harakatga ruxsat bering, saqlang

# Tizim faqat taqdim etilgan hujjatdagi ma'lumotlarga tayanadigan manbaga tayanishga majbur qiladi. Hujjatda bo'lmagan narsalarni qo'shmang. Agar ma'lumot hujjatda bo'lmasa, "Hujjatda topilmadi" deb yozing. Hech qachon narsalarni taxmin qilmang yoki uydirmang.

# Inson maʼqullash chegarasi (qaror qabul qilish qoidasi)Agar qaror_turi [pul, shartnoma, oʻchirish, sogʻliq] → inson tomonidan tasdiqlangan boʻlsa, model_ishonch darajasi < pol YOKI tasdiqlash “noaniq” boʻlsa → odam roziligiga topshiring. → avtomatik qoʻllash + namuna olish nazorati

# Kuzatuv jurnali shabloni (sezgir ma'lumotlarni yozish){ "vaqt":"...", "model":"...", "input_token":..., "output_token":..., "delay_ms":..., "stop_reason":"...", "autentifikatsiya":"o'tdi|rad etilgan|shaxsiy ma'lumotlar", "yangi ma'lumotlar" //_} yoziladi.

Zaif tezkor / Kuchli tezkor (ishlab chiqarish ishonchliligi)

# ZAF (tasdiqlanmagan, manba yo'q, avtomatik ravishda qo'llaniladi) Ushbu so'rovni baholang, to'lovni qaytarish to'g'risida qaror qabul qiling va ariza bering.

# KUCHLI (manbaga asoslangan, tavsiyalar ishlab chiqaradi, odamlarning roziligiga qoldiradi) Bu qaytarish soʻrovini faqat qaytarish siyosati hujjati asosida baholang. Qarorni asosli ravishda tavsiya qiling, lekin bajarmang: {"tavsiya":"tasdiqlash|rad etish","sabab":"...","policy_clause":"..."}.Agar siyosat hujjatida aniq asos bo'lmasa, "noaniq" deb bering. Vakil yakuniy qarorni tasdiqlaydi.

Kuchli versiya; U qarorni manbaga bog'laydi, modelni "bajaruvchi" emas, balki "taklif qiluvchi" sifatida joylashtiradi va yuqori ta'sirli qadamni inson ma'qullashiga qo'yadi. Bu ishlab chiqarish ishonchliligining mohiyatidir.

Uchta mini korpus

1-holat - tekshirish qatlami saqlangan kun. Fintechda tranzaktsiya tavsiflarini tasniflash va avtomatik buxgalteriya yozuvlarini yaratish modeli mavjud edi. Ular qoidani tekshirishni qo'shdilar: model summani noto'g'ri chiqargandan so'ng (hujjatdagi 1250 o'rniga 12500), "summa hujjatga mos kelmaydi" qoidasi chiqishni rad etdi va rekord odamga tushdi. Agar tekshirish bo'lmasa, noto'g'ri yozuv tizimga jimgina kiradi.

2-holat - Qochqin kuzatuv tomonidan ushlandi. SaaS jamoasi monitoring panelini o'rnatgan; Bir kuni ertalab kunlik xarajat uch baravar oshdi. Jurnallardan ko'rinib turibdiki, mijoz tsiklga kirgan va bir xil so'rovni minglab marta yuborgan. Ular kvota va dublikatsiyani qo'shdilar; Muammo bir necha soat ichida hal qilindi. Kuzatmasdan, hisob oyning oxirida kutilmagan bo'ladi.

3-holat - Limitni qabul qilish. Sog'liqni saqlash sohasidagi startap to'liq avtomatik ravishda tashxis qo'yish bo'yicha tavsiyalar berishni va uni bemorga ko'rsatishni rejalashtirgan. Etika va mas'uliyatni tekshirishda ular buni taqiqlangan deb qaror qilishdi: model faqat xulosa va shifokorga mumkin bo'lgan fikrlarni beradi, shifokor tashxis qo'yadi. Ishni avtomatlashtirmaslik ham etuk dizayn qaroridir.

Umumiy xatolar

Tasdiqlashni o'tkazib yuborish: "model yaxshi" deb ko'r-ko'rona chiqishni qo'llash.
Yuqori ta'sirli qarorni avtomatlashtirish: Pul/sog'liq/qonun sohasida insonning roziligi muhim ahamiyatga ega.
Nazorat qilmaslik: Narx va sifat muammolari kech aniqlanadi.
Jurnallarga nozik ma'lumotlarni yozish: Maxfiylik buzilishi; Uni niqoblash orqali saqlang.
Manbaga tayanmaslik: Model hujjatda bo'lmagan narsalarni yaratishi mumkin.
Cheklovlarga e'tibor bermaslik: ba'zi vazifalarni avtomatlashtirmaslik to'g'ri qaror; Shaffoflik va javobgarlik sizniki.

Chuqurroq: relizlarni boshqarish, orqaga qaytarish va qo'shimcha joylashtirish

LLM xususiyatini ishlab chiqarishga kiritish uni o'rnatish va uni unutish emas; vaqt o'tishi bilan jonli tizimni xavfsiz tarzda o'zgartirishdir. Uning uchta ustuni bor.

Versiyalash. Tizim so'rovi, model tanlash va tekshirish qoidalari vaqt o'tishi bilan o'zgaradi. Versiyaning har bir muhim o'zgarishi va qaysi versiya jonli ekanligini yozib oling. Bir kuni sifat tushib qolsa, "nimani o'zgartirdik?" Bir necha daqiqada savolga javob berishingiz kerak. Versiyasiz tizimda regressiyaning asosiy sababini topish bir necha kun davom etadi.

Orqaga qaytarish. Agar yangi taklif yoki model jonli efirda kutilganidan yomonroq harakat qilsa, siz tezda oldingi, taniqli versiyaga qaytishingiz kerak. Orqaga qaytarish rejasisiz o'zgarish jonli xavfni ko'r-ko'rona qabul qiladi. "Men biror narsani o'zgartirdim, yomonlashdi, orqaga qaytolmayman" - bu eng qimmat ishlab chiqarish stsenariysi.

Sekin-asta tarqatish. Bir vaqtning o'zida barcha trafikga o'zgartirish kiritish o'rniga, avval uni kichik foizga (masalan, 5%) aylantirasiz va ko'rsatkichlarni (sifat, narx, xatolar) kuzatasiz. Agar u yaxshi bo'lsa, siz foizni oshirasiz; Agar u yomon bo'lsa, uni faqat kichik bir qismi ta'sirlangan holda qaytarib olasiz. Bu xavfni sezilarli darajada cheklaydi.

Ushbu uchta amaliyot barcha oldingi birliklarning texnikasini birlashtiradi: baholash (5-birlik) o'zgarishlarni oldindan o'lchaydi, monitoring (ushbu birlik) tarqalish vaqtida erta ogohlantirish beradi, tekshirish qatlami xato natijalarni ular amalda bo'lishidan oldin ushlaydi. Ishlab chiqarish bitta to'g'ri o'rnatish emas; Bu doimiy intizom bo'lib, u o'lchaydi, nazorat qiladi va ishonch bilan o'zgarishi mumkin. Butun modul siz ushbu intizomni o'rnatishingiz uchun mo'ljallangan.

Xulosa

Ishlab chiqarish - bu ishlaydigan demodan ko'proq narsa: bu kirish, model, tekshirish, harakat va monitoring qatlamlarining quvur liniyasi. Chiqish tekshiruvisiz ishonchsizdir; yuqori ta'sirli qarorlar inson roziligi bilan bog'liq; Har bir qo'ng'iroq narxi, xatolar va sifat uchun nazorat qilinadi. Etika, shaffoflik, tarafkashlik nazorati, hisobdorlik va cheklovlarni qabul qilish texnik qarorlar uchun ajralmas hisoblanadi. Ushbu modulda o'rganilgan har bir qism ushbu yaxlit dizaynda birlashadi.

Ilova vazifasi

LLM xususiyatini oxirigacha loyihalash. (1) Muayyan vazifangiz uchun beshta qatlamni (kirish, model, tekshirish, harakat, monitoring) to'ldiring. (2) Qaysi qarorlar inson roziligini talab qilishini ta'siriga qarab belgilang. (3) Kamida uchta tekshirish tekshiruvini yozing (sxema, qoida, manba). (4) Siz kuzatadigan asosiy ko'rsatkichlarni va nimalarni kirmasligingizni aniqlang. (5) Ushbu xususiyatda siz qabul qiladigan chegara va axloqiy tamoyilni yozing.

nazorat ro'yxati

[ ] Men ishlab chiqarish quvurining beshta qatlamini loyihalashtira olaman.
[ ] Chiqishni sxema, qoida va manbaga nisbatan tasdiqlay olaman.
[ ] Qarorning taʼsiridan kelib chiqib, insonning maʼqullash chegarasini belgilashim mumkin.
[ ] Men xarajat, xato va sifatni kuzataman va muhim maʼlumotlarni jurnallarga yozmaslikni mashq qilaman.
[ ] Men axloq, mas'uliyat va chegaralarni ishlab chiqarish qarorlariga aylantira olaman.

Modul imtihoni

1. LLM chat API’da “tizim” roli nima qiladi?

A) Modelga butun suhbat davomida qo'llaniladigan doimiy ko'rsatmalar va xatti-harakatlar qoidalarini beradi ✔
B) Foydalanuvchi tomonidan yozilgan oxirgi savolni saqlaydi
C) Model tomonidan ishlab chiqarilgan javobni saqlaydi
D) API kalitini shifrlaydi

Tavsif: Tizim roli modelga butun suhbat davomida qo'llaniladigan doimiy ko'rsatmalar, shaxsiyat va qoidalarni beradi; Bu foydalanuvchi xabarlaridan alohida, yuqori darajadagi qayta yo'naltirishdir.

2. Nima uchun suhbatlar tarixi (oldingi xabarlar) har safar API so'rovida qayta yuboriladi?

A) Server tarixni o'chirib tashlaganligi sababli zaxira nusxasini yaratish kerak
B) API chaqiruvlari fuqaroligi yo‘q; ✔ Kontekst har bir soʻrovda qayta yuboriladi, chunki model tarixni eslamaydi
C) Faqat hisob-faktura uchun talab qilinadi, modelga ta'sir qilmaydi
D) Javobni sekinlashtirmaslik uchun tarixni yuborish majburiydir

Izoh: LLM API qo'ng'iroqlari fuqaroligi yo'q; Model oldingi turlarni eslamaydi, shuning uchun barcha tegishli tarix kontekstni saqlab qolish uchun har bir so'rovda qayta ko'rib chiqiladi.

3. LLM bahosidagi “token” nima?

A) API ga kirish uchun foydalaniladigan bir martalik parol
B) Har bir so‘rov bo‘yicha to‘lanadigan belgilangan to‘lov
C) Model matnni qayta ishlovchi eng kichik birlik; odatda ✔ so'z qismiga mos keladi
D) Faqat chiqish uzunligini o'lchaydigan birlik

Tavsif: Token - bu model matnni qayta ishlaydigan eng kichik birlik; Odatda so'zning bir qismiga to'g'ri keladi va kirish va chiqish tokenlar soniga qarab to'lanadi.

4. Nima uchun ko'pchilik LLM provayderlarida chiqish tokenlari kirish tokenlaridan qimmatroq?

A) Chiqish tokenlari har doim kirishdan uzunroq
B) Kirish tokenlari bepul
C) Chiqish tokenlari internet orqali ikki marta yuboriladi
D) Birlik tannarxi yuqori, chunki mahsulot ishlab chiqarish har bir token uchun qo'shimcha hisob-kitoblarni talab qiladi ✔

Tavsif: Har bir chiqish tokeni modelni bosqichma-bosqich yaratishni (hisoblashni) talab qiladi; Ushbu ishlab chiqarish qiymati bir vaqtning o'zida kirishni qayta ishlashdan yuqori, shuning uchun chiqish birligi narxi odatda yuqori bo'ladi.

5. Qaysi vaziyatda strimingdan foydalanish eng foydali?

A) Uzoq javoblarda; Qabul qilingan kechikishni kamaytiradi va vaqt tugashining oldini oladi ✔
B) Faqat juda qisqa, bir so‘zli javoblarda
C) Xarajatlarni nolga tushirish uchun
D) API kalitini yashirish uchun

Tavsif: Uzoq javoblarda oqim birinchi so'zlarni darhol paydo bo'lishi orqali qabul qilingan kechikishni kamaytiradi va katta max_tokens qiymatlarida HTTP kutish vaqtining oldini oladi.

6. Zamonaviy modellarda "harakat" parametrini oshirish umuman nimaga ta'sir qiladi?

A) Har doim javobni qisqartiring
B) API kalitini avtomatik ravishda aylantiradi
C) U faqat kirish tokeni narxini pasaytiradi
D) Fikrlash chuqurligi va token sarfini oshiradi; Bu sifatni yaxshilashi mumkin, lekin kechikish va xarajatlarni ham oshiradi ✔

Tavsif: Harakat parametri modelning vazifa haqida qanchalik chuqur o'ylashini va qancha token sarflashini sozlaydi; Yangilash sifatni yaxshilashi mumkin, lekin u kechikish va xarajatlarni ham oshiradi. Oddiy vazifalar uchun kam harakat etarli.

7. Oddiy, katta hajmli tasniflash vazifasini bajarishda, odatda, eng tejamkor yondashuv qaysi?

A) Har doim eng qimmat va eng kuchli modeldan foydalaning
B) Har bir so'rov uchun barcha modellarni bir vaqtning o'zida chaqirish
C) Vazifani bajaradigan eng engil/eng arzon modelni tanlash, uni biroz baholash bilan tekshirish ✔
D) max_tokens qiymatini keraksiz darajada yuqori ushlab turish

Tushuntirish: Agar vazifa murakkab bo'lmasa, eng qimmat va kuchli modelni ishlatish o'rniga vazifani osonlikcha bajaradigan tezroq va arzonroq modelni tanlash (masalan, Xayku sinfi) xarajatlarni sezilarli darajada kamaytiradi.

8. Qaysi stsenariyda tezkor keshlash xarajatlarni ko'proq kamaytiradi?

A) Katta va qatʼiy kontekst koʻp soʻrovlar boʻyicha qayta-qayta ishlatilsa ✔
B) Har bir so'rov bilan butunlay boshqa matn yuborilganda
C) Faqat bitta so'rov berilganda
D) Chiqarish tokenlarini kamaytirish uchun

Tavsif: keshlash - bu prefiksga mos keladi; Katta, o'zgarmas kontekst (tizim so'rovi, hujjatlar) ko'plab so'rovlar bo'yicha qayta ishlatilsa, keshdan o'qish to'liq narxning kichik qismini (~0,1x) tashkil qiladi.

9. So'rov keshiga tegishi uchun so'rovni qanday tahrirlashim kerak?

A) O‘zgaruvchan tarkibni boshiga, sobit tarkibni esa oxiriga qo‘yish
B) Har bir so'rov uchun joriy sana va vaqtni tizim taklifiga kiriting
C) Ruxsat etilgan tarkibni (tizim taklifi, hujjatlar) boshida va o'zgaruvchan tarkibni oxiriga qo'yish ✔
D) Har bir so'rov bilan asboblar ro'yxati tartibini o'zgartirish

Izoh: Kesh prefiksga mos kelganligi sababli, o'zgarmas/o'zgarmas tarkib (tizim taklifi, hujjatlar) ishga tushiriladi; o'zgaruvchan tarkib (sana, foydalanuvchi savoli, so'rov identifikatori) oxirida qo'yiladi. Hatto boshida o'zgartirilgan bitta bayt ham keshni bekor qiladi.

10. Ish yukining qaysi turi uchun paketli ishlov berish eng mos keladi?

A) Foydalanuvchi ekranda bir zumda javob kutayotgan jonli chat
B) Bitta qisqa savol
C) API kalitini yaratish
D) Kechiktiriladigan, katta hajmli va darhol natija talab qilmaydigan ishlar ✔

Tavsif: Partiyani qayta ishlash zudlik bilan javob berishni talab qilmaydigan va kechikishga toqat qiladigan katta hajmdagi ishlarga mos keladi; natijalar bir muncha vaqt o'tgach beriladi, lekin birlik narxi odatda past bo'ladi.

11. Natijalar partiyada qaysi so'rovga tegishli ekanligini ishonchli tarzda moslashtirish uchun nimadan foydalaniladi?

A) So'rovlarni yuborish tartibi (pozitsiyasi).
B) Javoblar uzunligi
C) API kalitining oxirgi 4 ta raqami
D) Har bir so'rovga berilgan noyob custom_id ✔

Izoh: Ommaviy natijalar topshirish tartibidan boshqacha tartibda qaytarilishi mumkin; shuning uchun natijalarni joylashuvga emas, balki ID bo'yicha, har bir so'rovga berilgan noyob custom_id bilan moslashtirish kerak.

12. APIdan 429 (stavka chegarasi) xatoligini olganingizda tavsiya etilgan xatti-harakatlar qanday?

A) Bir vaqtning o'zida yana ko'plab so'rovlarni yuborish orqali majburlash
B) Qayta urinish-so'ng sarlavhasidan keyin eksponensial orqaga qaytish bilan qayta urinib ko'rish ✔
C) So'rovni to'liq bekor qiling va foydalanuvchiga xatoni avariya sifatida ko'rsating
D) API kalitini o'zgartirish

Izoh: 429 - qayta urinib ko'rish mumkin bo'lgan xato; To'g'ri yondashuv - bu "qayta urinishdan keyin" sarlavhasiga rioya qilgan holda, eksponensial orqaga qaytish bilan qayta urinib ko'rishdir. Ko'pgina rasmiy SDKlar buni avtomatik ravishda bajaradi.

13. Quyidagi HTTP xato kodlaridan qaysi biri odatda qayta sinash mumkin deb hisoblanadi?

A) 400 (noto'g'ri so'rov)
B) 401 (autentifikatsiya xatosi)
C) 529 (server haddan tashqari yuklangan) ✔
D) 404 (topilmadi)

Izoh: 429 (tezlik chegarasi), 500 (server xatosi) va 529 (haddan tashqari yuk) vaqtinchalik xatolar bo'lib, ularni orqaga qaytarish orqali qayta urinib ko'rish mumkin. 400 va 401 kabi xatolar so'rov/identifikatsiya muammolari; Qayta urinish bilan hal bo'lmaydi.

14. Quyidagilardan qaysi biri API kalitlarini boshqarishning xavfsiz usuli hisoblanadi?

A) Atrof-muhit o'zgaruvchisi/yashirin menejerda saqlash, uni kodga kiritmaslik va muntazam ravishda aylantirish ✔
B) Kalitni to'g'ridan-to'g'ri manba kodiga yozing va uni omborga yuboring
C) Kalitni mijoz tomoniga (brauzer) JavaScript-ga qo'yish
D) Elektron pochta orqali butun jamoa bilan bitta kalit almashish

Tavsif: Kalitlar hech qachon manba kodi yoki omborga yozilmaydi; U atrof-muhit o'zgaruvchisida yoki yashirin boshqaruv vositasida saqlanadi, minimal imtiyozlar beriladi va muntazam ravishda aylantiriladi.

15. Maxfiylik nuqtai nazaridan avtomatlashtirish vositasi (n8n, Zapier, Make) bilan LLM integratsiyasining eng yaxshi yondashuvi qanday?

A) Zarur bo'lmasa ham, barcha xom ma'lumotlarni modelga yuborish
B) Oqim bosqichida API kalitini oddiy matnda yozish
C) Maxfiy ma'lumotlarni minimallashtirish va maskalash va kalitni maxfiy hisob ma'lumotlari sifatida saqlash ✔
D) Shaxsiy ma'lumotlarni doimiy ravishda oqim tarixida saqlash

Tavsif: Ma'lumotlarni kiritishni avtomatlashtirish uchinchi tomon tizimlari va modeli orqali o'tayotganda, nozik/shaxsiy ma'lumotlarni minimallashtirish, maskalash va faqat kerakli maydonlarni yuborish kerak; API kaliti, shuningdek, asbob ichida maxfiy hisob ma'lumotlari sifatida saqlanadi.

16. Nima uchun LLM asosidagi ishlab chiqarish xususiyatida mahsulotni tekshirish majburiy?

A) Faqat formatlash talab qilinadi, chunki model hech qachon xato qilmaydi
B) Model suyuq, lekin ba'zan noto'g'ri ishlab chiqarishi mumkinligi uchun; Sxema/qoida resurs va inson roziligi bilan tekshirilishi kerak ✔
C) Validatsiyadan qochish kerak, chunki u faqat xarajatlarni oshiradi
D) Tekshirish faqat tokenlar sonini kamaytirish uchun

Tavsif: LLMlar ravon, lekin ba'zan noto'g'ri (gallyutsinatsiyali) chiqishlarni ishlab chiqishi mumkin; shuning uchun u yuqori ta'sirli qarorlarda chiqdi; U sxema/qoidalarni tekshirish, manbani tekshirish va kerak bo'lganda inson tomonidan tasdiqlash orqali tekshirilishi kerak.