End-to-End Production: Текшерүү, Мониторинг жана Этика

Пайдалар:

• Идеядан өндүрүшкө чейин LLM өзгөчөлүгүн алган аягына чейин архитектураны долбоорлой алат
• Текшерүүнүн, адамдардын жактыруусунан жана көзөмөлдөө катмарларын түзөт (логдоштуруу/метрика)
• Чек аралар этика жана купуялык принциптерин өндүрүштүк чечимдерге айлантат

Мурунку он бөлүмдө биз бөлүктөрдү бир-бирден үйрөндүк: суроо-талаптын түзүмү, токендердин экономикасы, агым, системанын ыкчамдыгы, моделди тандоо, кэш, партия, каталарды башкаруу, коопсуз ачкыч жана автоматташтыруу. Бул акыркы бөлүмдө биз бөлүктөрдү бириктирип, идеядан өндүрүшкө чейин LLM өзгөчөлүгүн алып жүргөн бирдиктүү архитектураны түзөбүз. Өндүрүш “жумушчу демодон” айырмаланат: текшерүү милдеттүү, өндүрүшкө мониторинг жүргүзүлүшү керек, чек аралар жана этикалык принциптер чечимдерге киргизилиши керек. Бул бирдик модулдун алып жүрүүчү мамычасы болуп саналат; Мурункулардын баары ушул жерге чогулат.

Өндүрүш архитектурасынын катмарлары

Катуу LLM квалификациясы болжол менен беш катмардан турат:

1. Киргизүү катмары: Маалыматтарды чогултуңуз, тазалаңыз, сезимтал жерлерди маскаңыз, керектүү нерселерди гана өткөрүңүз.
2. Модель катмары: Туура моделди тандаңыз (5-бирдик), системанын чакыруусун жана параметрлерин (4-бирдик), кэшти (6-бирдик) орнотуңуз.
3. Текшерүү катмары: Чыгарууну схемага/эрежеге, булакка жана керек болсо адамдын жактыруусуна каршы текшериңиз.
4. Иш-аракет катмары: Текшерилген чыгаруу менен иш-аракетти аткаруу; Жогорку таасирдүү аракеттерди тартыңыз.
5. Мониторинг катмары: Ар бир чалууну, чыгымды, катаны жана сапатты жазып алыңыз жана өлчөңүз.

Бул катмарлар түтүк болуп саналат; ар бири мурункусунун жыйынтыгын текшерет.

Эмне үчүн текшерүү талап кылынат?

LLMs эркин, бирок кээде так эмес чыгарылышы мүмкүн. Бул галлюцинация деп аталат: модель чындыкка окшош, бирок чындыкка дал келбеген маалыматты ойлоп чыгарышы мүмкүн. Чат оюнунда буга чыдаса болот; өндүрүш системасында (эсеп-фактура, ден соолук, юридикалык, каржы) жол берилбейт. Ошентип, ал сокур ишенимсиз болуп чыкты; тастыкталат.

Текшерүү катмарлары (таасир боюнча көбөйүүдө):

• Формат/схеманы текшерүү: Чыгуу күтүлгөн JSON схемасына туура келеби? (Структураланган чыгаруу негизинен буга кепилдик берет.)
• Эреже/логикалык текшерүү: баалуулуктар акылга сыярлыкпы? (Сумма терс, келечектеги датабы, категория жарактуубу?)
• Булакты текшерүү: Доомат берилген документтерге негизделгенби? Модель документте жок нерсени айтып жатабы?
• Адамдын жактыруусу: Эксперт таасири жогору же түшүнүксүз чечимдерди карап чыгат.

Абайлаңыз: "Модель абдан жакшы, мындан ары текшерүүнүн кереги жок" - бул эң коркунучтуу өндүрүштүк жаңылыштык. Модел канчалык жакшы болбосун, текшерүү катмары жогорку таасирдүү чечимдерди кабыл алууда коопсуздук тору болуп саналат. Атүгүл бир туура эмес автоматтык чечим үнөмдөлгөн бардык убакытты алып салышы мүмкүн.

Адам-ин-the-Loop

Ар бир чечим толугу менен автоматтык болушу керек эмес. Адамдын айлампасында модель ишти тездетет жана адам аны жактырат. Туура тең салмактуулук чечимдин таасиринен жана ошол тапшырмага моделдин ишенимдүүлүгүнөн көз каранды.

Чечимдин таасири

мамиле

Төмөн (энбелги сунушу, долбоор)

Толук автоматташтыруу; ката арзан жана кайра кайтарылат

Орто (багыттоо, артыкчылыктуу)

Автоматташтыруу + үлгүлөрдү башкаруу

Жогорку (акча, келишим, ден соолук, өчүрүү)

Адамдын макулдугу милдеттүү; модели гана сунуш кылат

Мониторинг: Сиз көрбөгөн нерсени башкара албайсыз

Өндүрүштө ар бир чалууну көзөмөлдөө керек. Мониторингсиз баасын, сапатын жакшырта албайсыз же көйгөйдү эрте чече албайсыз. Жазылуу үчүн негизги көрсөткүчтөр:

• Колдонуу/баасы: суроо-талабы жана жалпы белгилери, моделди бөлүштүрүү, күнүмдүк чыгым.
• Кечирүү: Орточо жана эң начар жооп берүү убактысы.
• Ката көрсөткүчү: 429/500 чен, кайра аракет кылуу, баш тартуу.
• Сапат: Текшерүү катмарында четке кагылган чыгаруу ылдамдыгы, адамдын жактыруусунда оңдоо ылдамдыгы, колдонуучунун пикири.

Кеңеш: Мониторинг журналдарына купуя маалыматтарды (жеке маалымат, ачкычтар) жазбаңыз. Жашыруундуулуктун алкагында журналдарды карап чыгуу; зарыл болсо, маска менен жазыңыз (9-блок).

Этика жана чек аралар

Этикалык жоопкерчилик техникалык тактык сыяктуу эле өндүрүштүк чечимдин бир бөлүгү болуп саналат:

• Ачыктык: Колдонуучу жасалма интеллект менен же адам менен сүйлөшүп жатканын билиши керек.
• Адилеттүүлүк жана калыстык: Модель даярдалган маалыматтардан бир жактуу болушу мүмкүн; Жогорку таасирдүү чечимдерде (жалдоо, кредит) дискриминациялык кесепеттерге мониторинг жүргүзүү.
• Жоопкерчилик: Эгер автоматташтырылган чечим зыян келтирсе, сиз жооптуусуз; "Модель ушинтип айтты" - бул коргонуу эмес.
• Лимиттерди кабыл алуу: Модель кээ бир тапшырмаларды ишенимдүү аткара албайт; аларды автоматташтырбоо да долбоорлоо чечими болуп саналат.

Көчүрмө калыптар

# Валидация текшерүү тизмеси (чыгарууну чыгаргандан кийин) 1) Схема жарактуубу? (структураланган чыгарууну текшерүү) 2) Маанилердин мааниси барбы? (эреже текшерүү: диапазон, дата, энум)3) Доомат булакка негизделгенби? (документте жок болсо четке кагыла)4) Таасири жогорубу? → адамдын жактыруусуна жөнөтүү5) Эгер баары өтүп кетсе → аракетке уруксат бериңиз, сактаңыз

# Булакка таянган системанын эскертүүсү берилген документтеги маалыматка гана таянат. Документте жок нерсени кошпоңуз. Эгерде документте маалымат жок болсо, "Документте табылган жок" деп жазыңыз. Эч качан бир нерселерди ойлоп чыгарбаңыз.

# Адамдын жактыруу босогосу (чечим кабыл алуу эрежеси)Эгер чечим_түрү [акча, келишим, жок кылуу, ден соолук] → адамдын жактыруусу милдеттүү болсоЭгер модель_trust < босого ЖЕ валидация "белгисиз" → адамдын жактыруусуна тапшыруу OTHER → автоматтык түрдө колдонуу + үлгүлөрдү башкаруу

# Trace log үлгүсү (купуя маалыматтарды жазуу){ "убакыт":"...", "модел":"...", "input_token":..., "output_token":..., "delay_ms":..., "stop_reason":"...", "аныктыгын текшерүү":"өттү|четке кагылды|адамдык", "өтүп кетти|башкакычкы|жеке маалыматтар бизге жазылды": //_}

Алсыз тез / Күчтүү ыкчам (өндүрүш ишенимдүүлүгү)

# АЛСЫЗ (текшерүү жок, булак жок, автоматтык түрдө колдонулат) Бул өтүнүчтү баалаңыз, акчаны кайтаруу чечимин кабыл алыңыз жана кайрылыңыз.

# КҮЧТҮҮ (булакка негизделген, сунушту жаратат, адамдын жактыруусуна калтырат) Кайтаруу өтүнүчүн кайтаруу саясатынын документинин негизинде гана баалаңыз. Чечимди негиздөө менен сунуштаңыз, бирок аткарбаңыз: {"сунуш":"кабыл алуу|четке кагуу","себеп":"...","policy_clause":"..."}.Эгер программалык документте так негиз жок болсо, "түшүнүксүз" деп бериңиз. Акыркы чечимди өкүл бекитет.

Күчтүү версия; Ал чечимди булакка байланыштырып, моделди "аткаруучу" эмес, "сунуш берүүчү" катары позициялайт жана адамдын жактыруусунан артта калган жогорку таасирдүү кадамды коёт. Бул өндүрүштүн ишенимдүүлүгүнүн маңызы.

Үч мини Case

1-жагдай - Текшерүү катмары сакталган күн. Финтехте транзакциянын сүрөттөмөлөрүн классификациялоо жана автоматтык эсеп жазууларын түзүү модели бар болчу. Алар эреженин валидациясын кошушту: модель сумманы туура эмес чыгаргандан кийин (документтеги 1250 эмес 12500), "сумма документке дал келбейт" эрежеси чыгарууну четке кагып, рекорд адамга түшүп калган. Эгерде текшерүү болбосо, туура эмес жазуу системага унчукпай кирмек.

2-жагдай — Качкан адам көзөмөлгө алынган. SaaS командасы мониторинг панелин орноткон; Бир күнү эртең менен күнүмдүк чыгым үч эсеге көбөйдү. Журналдардан кардар циклге кирип, бир эле суроону миңдеген жолу жөнөткөнү көрүндү. Алар квотаны жана көчүрмөнү кошушту; Маселе бир нече сааттын ичинде чечилди. Көз салуу болбосо, мыйзам долбоору айдын аягында күтүлбөгөн нерсе болмок.

3-жагдай - Лимитти кабыл алуу. Саламаттыкты сактоо стартапы диагностика боюнча сунушту толугу менен автоматтык түрдө жасап, аны пациентке көрсөтүүнү пландап жаткан. Этика жана жоопкерчиликти карап чыгууда, алар муну чектөө деп чечишти: модель дарыгерге кыскача маалымат жана мүмкүн болгон упайларды гана берет, дарыгер диагноз коёт. Жумушту автоматташтырбоо да жетилген долбоорлоо чечими болуп саналат.

Жалпы каталар

• Текшерүүнү өткөрүп жиберүү: "Модел жакшы" деп, жыйынтыкты сокур колдонуу.
• Жогорку таасирдүү чечимди автоматташтыруу: Адамдын макулдугу акча/ден соолук/мыйзамда маанилүү.
• Мониторинг эмес: Баа жана сапат көйгөйлөрү кеч аныкталат.
• Журналдарга купуя маалыматтарды жазуу: Купуялыктын бузулушу; Аны маска менен сактаңыз.
• Булакка таянууга аракет кылбоо: модель документте жок нерсени түзүшү мүмкүн.
• Чектерди четке кагуу: Кээ бир тапшырмаларды автоматташтырбоо туура чечим; Ачыктык жана жоопкерчилик сизде.

Тереңирээк: Release Management, Rellback жана Incremental Deployment

LLM өзгөчөлүгүн өндүрүшкө алуу аны орнотуу жана аны унутуу эмес; убакыттын өтүшү менен тирүү системаны коопсуз өзгөртүү болуп саналат. Анын үч түркүгү бар.

Версиялоо. Системаңыздын сунушу, моделди тандоо жана текшерүү эрежелери убакыттын өтүшү менен өзгөрөт. Ар бир олуттуу өзгөрүү версиясы жана кайсы версия жандуу экенин жазыңыз. Бир күнү сапаты түшүп калса, "биз эмнени өзгөрттүк?" Сиз бир нече мүнөттүн ичинде суроого жооп бере алышыңыз керек. Версиясыз системада регрессиянын түпкү себебин табуу бир нече күндү талап кылат.

Артка кайтаруу. Эгер жаңы эскертүү же модель түз эфирде күтүлгөндөн начарраак болсо, сиз мурунку, жалпыга белгилүү версияга тез кайрыла аласыз. Артка кайтаруу планы жок өзгөртүү коркунучту сокур кабыл алуу болуп саналат. "Мен бир нерсени өзгөрттүм, ал жаман болуп калды, мен артка кайта албайм" - эң кымбат өндүрүш сценарийи.

Акырындык менен жайылтуу. Бардык трафикке бир эле учурда өзгөртүү киргизүүнүн ордуна, сиз аны биринчи аз пайызга (мисалы, 5%) чыгарып, көрсөткүчтөрдү (сапат, нарк, каталар) көзөмөлдөйсүз. Жакшы болсо, пайызды көбөйтөсүз; Эгер ал начар болсо, анын кичинекей бөлүгү гана жабыркап, аны кайтарып аласыз. Бул коркунучту абдан чектейт.

Бул үч тажрыйба мурунку бардык бөлүмдөрдүн ыкмаларын бириктирет: баалоо (5-бирдик) өзгөрүүнү алдын ала өлчөйт, мониторинг (бул бирдик) жайылтуу учурунда эрте эскертүү берет, текшерүү катмары жаңылыш жыйынтыктарды алар ишке жарай электе кармап калат. Өндүрүш бир туура орнотуу эмес; Бул ченеп, көзөмөлдөп, ишеним менен өзгөртө турган үзгүлтүксүз дисциплина. Бүт модуль бул дисциплинаны орнотуу үчүн.

Кыскача айтканда

Өндүрүш жумушчу демо эмес: бул киргизүү, модель, текшерүү, иш-аракет жана мониторинг катмарларынын түтүгү. Текшербестен чыгаруу ишенимсиз; жогорку таасирдүү чечимдер адамдын жактыруусуна байланган; Ар бир чалуу баасы, каталары жана сапаты боюнча көзөмөлдөнөт. Этика, ачык-айкындуулук, бир тараптуу контролдоо, отчеттуулук жана лимиттерди кабыл алуу техникалык чечимдердин ажырагыс бөлүгү болуп саналат. Бул модулда үйрөнгөн ар бир бөлүгү бул бүтүндөй долбоордо чогулат.

Колдонмо тапшырмасы

LLM өзгөчөлүгүн аягына чейин иштеп чыгуу. (1) Белгилүү тапшырмаңыз үчүн беш катмарды (киргизүү, модель, текшерүү, аракет, мониторинг) толтуруңуз. (2) Кандай чечимдер адамдын жактыруусун талап кыларын таасири боюнча белгилеңиз. (3) Жок дегенде үч валидация текшерүүсүн жазыңыз (схема, эреже, булак). (4) Көзөмөл кыла турган негизги көрсөткүчтөрдү жана эмнени киргизбей турганыңызды аныктаңыз. (5) Бул функцияда сиз кабыл алган чекти жана этикалык принципти жазыңыз.

текшерүү тизмеси

• [ ] Мен өндүрүш түтүгүнүн беш катмарын долбоорлой алам.
• [ ] Мен схемага, эрежеге жана булакка каршы чыгарууну текшере алам.
• [ ] Чечимдин таасирине жараша адамдын жактыруу босогосун кое алам.
• [ ] Мен чыгымдарды, каталарды жана сапатты көзөмөлдөйм жана журналдарга купуя маалыматтарды жазбай турамын.
• [ ] Мен этиканы, жоопкерчиликти жана чектерди өндүрүштүк чечимдерге айланта алам.

Модуль экзамени

1. LLM чат API'синде "системанын" ролу эмне кылат?

• A) Үлгүгө бардык сүйлөшүүдө колдонулуучу туруктуу көрсөтмөлөрдү жана жүрүм-турум эрежелерин берет ✔
• B) Колдонуучу жазган акыркы суроону сактайт
• C) Модель чыгарган жоопту сактайт
• D) API ачкычын шифрлейт

Сүрөттөмө: Системанын ролу моделге бүт баарлашууда колдонулуучу туруктуу көрсөтмөлөрдү, инсандыкты жана эрежелерди берет; Бул колдонуучунун билдирүүлөрүнөн өзүнчө, жогорку деңгээлдеги багыттоо.

2. Эмне үчүн сүйлөшүү таржымалы (мурунку билдирүүлөр) API сурамында кайра жөнөтүлөт?

• A) Сервер тарыхты жок кылгандыктан, резервдик көчүрүү керек
• B) API чалуулары жарандыгы жок; ✔ Ар бир суроо боюнча контекст кайра жөнөтүлөт, анткени модель тарыхты эстебейт
• В) Фактурага гана керек, моделге эч кандай таасири жок
• D) Жоопту жайлатпоо үчүн тарыхты жөнөтүү милдеттүү

Түшүндүрмө: LLM API чалуулары жарандыгы жок; Модель мурунку раунддарды эстебейт, ошондуктан бардык тиешелүү тарых контекстти сактоо үчүн ар бир өтүнүч боюнча нааразы болот.

3. LLM баалоосунда "токен" деген эмне?

• A) API'ге кирүү үчүн колдонулган бир жолку сырсөз
• B) Ар бир суроо-талап боюнча төлөнүүчү белгиленген алым
• C) Модель текстти иштеткен эң кичине бирдик; адатта ✔ сөз бөлүгүнө туура келет
• D) Чыгаруунун узундугун гана өлчөгөн бирдик

Сүрөттөмө: Токен – бул модель текстти иштеткен эң кичине бирдик; Ал, адатта, сөздүн фрагментине туура келет жана киргизүү да, чыгаруу да токендердин санына жараша алынат.

4. Эмне үчүн чыгаруу токендери көпчүлүк LLM провайдерлеринде киргизүү токендерине караганда кымбатыраак?

• A) Чыгуу токендери дайыма киргизүүгө караганда узунураак
• B) Киргизүү токендери бекер
• C) Чыгуу токендери интернет аркылуу эки жолу жөнөтүлөт
• D) Бирдиктин баасы жогору, анткени өндүрүштү өндүрүү ар бир белги үчүн кошумча эсептөөлөрдү талап кылат ✔

Сүрөттөмө: Ар бир чыгуу токендери моделден этап-этабы менен генерациялоону (эсептөө) талап кылат; Бул өндүрүштүн наркы бир эле учурда киргизүүнү кайра иштетүүгө караганда жогору, ошондуктан чыгаруу бирдигинин баасы адатта жогору болот.

5. Кайсы жагдайда агымды колдонуу эң пайдалуу?

• А) Узун жооптордо; Кабыл алынган кечиктирүүнү азайтат жана күтүү убактысын алдын алат ✔
• Б) Өтө кыска, бир сөздөн турган жооптордо гана
• C) Өздүк наркын нөлгө чейин төмөндөтүү
• D) API ачкычын жашыруу үчүн

Сүрөттөмө: Узак жооптордо агым биринчи сөздөрдү дароо пайда кылуу менен кабыл алынган кечиктирүүнү азайтат жана чоң max_tokens маанилеринде HTTP таймаутунун алдын алат.

6. Заманбап моделдердеги "аракет" параметрин жогорулатуу жалпысынан эмнеге таасир этет?

• А) Дайыма жоопту кыскартыңыз
• B) API ачкычын автоматтык түрдө айлантат
• C) Бул киргизүү белгисинин баасын гана төмөндөтөт
• D) Ой жүгүртүүнүн тереңдигин жана сарптоолорду жогорулатат; Бул сапатты жакшыртышы мүмкүн, бирок ошондой эле күтүү убактысын жана баасын жогорулатат ✔

Сүрөттөмө: Аракет параметри моделдин тапшырма жөнүндө канчалык терең ойлонорун жана ал канча токендерди короторун тууралайт; Жаңыртуу сапатты жакшыртышы мүмкүн, бирок кечиктирүүнү жана баасын жогорулатат. Жөнөкөй тапшырмалар үчүн аз аракет жетиштүү.

7. Жөнөкөй, чоң көлөмдөгү классификация тапшырмасына эң үнөмдүү ыкма кайсы?

• A) Ар дайым эң кымбат жана эң күчтүү моделди колдонуңуз
• B) Ар бир суроо үчүн бир эле учурда бардык моделдерди чакыруу
• C) Бир аз баа берүү менен аны текшерүү аркылуу тапшырманы аткарган эң жеңил/эң арзан моделди тандоо ✔
• D) max_tokens маанисин өтө жогору сактоо

Түшүндүрмө: Эгер тапшырма татаал болбосо, эң кымбат жана күчтүү моделди колдонуунун ордуна тапшырманы оңой аткара турган тезирээк жана арзаныраак моделди тандоо (мисалы, Хайку классы) бааны бир топ төмөндөтөт.

8. Кайсы сценарийде оперативдүү кэштөө чыгымдарды көбүрөөк азайтат?

• A) Чоң жана туруктуу контекст көптөгөн сурамдарда кайра-кайра колдонулганда ✔
• B) Ар бир суроо менен такыр башка текст жөнөтүлгөндө
• В) Бир гана өтүнүч берилгенде
• D) Чыгаруу токендерин азайтуу үчүн

Сүрөттөмө: Кэштөө префикс дал келет; Көптөгөн суроо-талаптарда чоң, өзгөрүлбөс контекст (системанын сунушу, документтер) кайра колдонулган учурларда, кэштен окуу толук баанын кичинекей бөлүгүн (~0,1x) түзөт.

9. Ыкчам кэш тийип тургандай, эскертүүнү кантип түзөтүшүм керек?

• A) Өзгөрмө мазмунду башына, туруктуу мазмунду аягына коюу
• B) Ар бир суроо үчүн системанын сунушуна учурдагы күндү жана убакытты кыстарыңыз
• C) Башына туруктуу мазмунду (системанын сунушу, документтер) жана акырына өзгөрүлмө мазмунду коюу ✔
• D) Ар бир суроо менен инструменттердин тизмесинин тартибин өзгөртүү

Түшүндүрмө: Кэш префикс менен дал келгендиктен, туруктуу/өзгөрбөс мазмун (системанын сунушу, документтер) инициализацияланат; өзгөрмө мазмун (датасы, колдонуучунун суроосу, суроо ID) аягында коюлат. Башында өзгөртүлгөн бир байт да кэшти жараксыз кылат.

10. Иш жүгүнүн кайсы түрү үчүн партияларды иштетүү эң ылайыктуу?

• A) Колдонуучу экранда заматта жооп күткөн жандуу баарлашуу
• Б) Бир гана кыска суроо
• C) API ачкычын түзүү
• D) Кечигүүгө чыдамдуу, көлөмү чоң жана дароо жыйынтыкты талап кылбаган жумуштар ✔

Сүрөттөмө: Партиялык кайра иштетүү дароо жооп берүүнү талап кылбаган жана кечиктирүүгө чыдамдуу чоң көлөмдөгү жумуштар үчүн ылайыктуу; натыйжалар бир нече убакыт өткөндөн кийин берилет, бирок бирдигинин баасы, адатта, төмөн болот.

11. Натыйжалар партияда кайсы суроо-талапка тиешелүү экендигин ишенимдүү дал келтирүү үчүн эмне колдонулат?

• A) Өтүнмөлөрдү жөнөтүү тартиби (позициясы).
• B) Жооптордун узундугу
• C) API ачкычынын акыркы 4 саны
• D) Ар бир суроого берилген уникалдуу custom_id ✔

Эскертүү: жапырт жыйынтыктар тапшыруу тартибине караганда башка тартипте кайтарылышы мүмкүн; ошондуктан ар бир суроо-талапка берилген уникалдуу custom_id менен жайгашкан жери эмес, ID боюнча жыйынтыктарды дал келтирүү керек.

12. APIден 429 (чен чеги) катасын алганыңызда сунушталган жүрүм-турум кандай?

• A) Бир эле учурда дагы көптөгөн суроо-талаптарды жөнөтүү аркылуу мажбурлоо
• B) Экспоненциалдык артка кайтаруу менен кайра аракет кылуу, кайра аракет кылуу-кийин деген рубрикадан кийин ✔
• C) Сурамды толугу менен жокко чыгарып, катаны колдонуучуга ката катары көрсөтүү
• D) API ачкычын өзгөртүү

Түшүндүрмө: 429 - кайра аракет кылынуучу ката; Туура ыкма - кайра аракет кылуунун башын урматтоо менен экспоненциалдык артка кайтаруу менен кайра аракет кылуу. Көпчүлүк расмий SDK муну автоматтык түрдө аткарат.

13. Төмөнкү HTTP ката коддорунун кайсынысы жалпысынан кайра аракет кылынуучу болуп эсептелет?

• A) 400 (жараксыз суроо)
• B) 401 (аныктыгын текшерүү катасы)
• C) 529 (сервер ашыкча жүктөлгөн) ✔
• D) 404 (табылган жок)

Түшүндүрмө: 429 (ылдамдык чектөө), 500 (сервер катасы) жана 529 (ашыкча жүктөө) убактылуу каталар жана кайра өчүрүү менен кайра аракет кылса болот. 400 жана 401 сыяктуу каталар суроо-талап/иденттикти аныктоо маселелери; Кайра аракет кылуу аны чечпейт.

14. Төмөнкүлөрдүн кайсынысы API ачкычтарын башкаруунун коопсуз жолу болуп саналат?

• A) Айлана чөйрөдөгү өзгөрмө/жашыруун менеджерде сактоо, аны кодго киргизбөө жана үзгүлтүксүз айлануу ✔
• B) Ачкычты түз баштапкы кодго жазыңыз жана аны репозиторийге жөнөтүңүз
• C) Ачкычты кардар тарапка (браузер) JavaScript коюу
• D) электрондук почта аркылуу бүт команда менен бир ачкычты бөлүшүү

Сүрөттөмө: Ачкычтар эч качан баштапкы кодго же репозиторийге жазылбайт; Ал чөйрө өзгөрмөсүндө же жашыруун башкаруу куралында сакталып, минималдуу артыкчылыктарга ээ жана үзгүлтүксүз айланып турат.

15. Купуялык жагынан автоматташтыруу куралы (n8n, Zapier, Make) менен LLM интеграциясынын эң жакшы ыкмасы кайсы?

• A) Зарыл болбосо да, бардык чийки маалыматтарды моделге жөнөтүү
• B) Агым кадамынын ичинде API ачкычын жөнөкөй текстте жазуу
• C) Жашыруун маалыматтарды азайтуу жана маскалоо жана ачкычты жашыруун эсептик маалыматтар катары сактоо ✔
• D) Жеке маалыматтарды агымдын тарыхында туруктуу сактоо

Сүрөттөмө: Маалыматтарды киргизүүнү автоматташтыруу үчүнчү тараптын тутумдары жана модели аркылуу өткөндүктөн, купуя/жеке маалыматтар кичирейтилиши, маскаланышы жана талап кылынган талаалар гана жөнөтүлүшү керек; API ачкычы ошондой эле куралдын ичинде жашыруун эсептик дайындар катары сакталат.

16. Эмне үчүн LLM негизиндеги өндүрүш өзгөчөлүгүндө чыгарууну валидациялоо милдеттүү?

• A) Форматтоо гана талап кылынат, анткени модель эч качан ката кетирбейт
• B) Модель суюк, бирок кээде туура эмес чыгара алгандыктан; Схема/эреже ресурстун жана адамдардын макулдугу менен текшерилиши керек ✔
• C) Валидациядан качуу керек, анткени ал бааны гана жогорулатат
• D) Текшерүү токендердин санын азайтуу үчүн гана

Сүрөттөмө: LLMs эркин, бирок кээде так эмес (галлюцинатордук) чыгара алат; ошондуктан ал жогорку таасирдүү чечимдерде чыкты; Ал схема/эрежелерди текшерүү, булагын текшерүү жана зарыл болгон учурда адамдын макулдугу менен текшерилиши керек.