Үздік өндіріс: тексеру, мониторинг және этика

Табыстар:

• LLM мүмкіндігін идеядан өндіріске дейін қабылдайтын түпкілікті архитектураны жобалай алады
• Тексеруді орындау, адам мақұлдау және бақылау деңгейлерін орнатады (тіркеу/метрика)
• Шекаралар этика мен құпиялылық принциптерін өндірістік шешімдерге айналдырады

Алдыңғы он бөлімде біз бөліктерді бір-бірлеп үйрендік: сұраныс құрылымы, таңбалауыш экономикасы, ағын, жүйе шақыруы, үлгі таңдау, кэш, пакет, қателерді басқару, қауіпсіз кілт және автоматтандыру. Осы соңғы бөлімде біз бөліктерді біріктіріп, идеядан өндіріске дейін LLM мүмкіндігін беретін тұтас архитектураны орнатамыз. Өндіріс «жұмыстық демонстрациядан» ерекшеленеді: тексеру міндетті, өнім қадағалануы керек, шекаралар мен этикалық принциптер шешімдерге енгізілуі керек. Бұл блок модульдің тасымалдаушы бағанасы болып табылады; Бұрынғылардың бәрі осында жиналады.

Өндіріс архитектурасының қабаттары

Қатты LLM біліктілігі шамамен бес қабаттан тұрады:

1. Енгізу қабаты: деректерді жинаңыз, тазалаңыз, сезімтал аймақтарды бүркеңіз, тек қажет нәрсені жіберіңіз.
2. Үлгі қабаты: Дұрыс үлгіні таңдаңыз (5 блок), жүйе шақыруын және параметрлерді (4 блок), кэшті (6 блок) орнатыңыз.
3. Тексеру деңгейі: шығуды схемаға/ережеге, көзге және қажет болса, адамның мақұлдауына сәйкес тексеріңіз.
4. Әрекет деңгейі: расталған нәтижемен әрекетті орындау; Жоғары әсер ету әрекеттерін түсіріңіз.
5. Бақылау деңгейі: әрбір қоңырауды, бағаны, қатені және сапаны жазып алыңыз және өлшеңіз.

Бұл қабаттар құбыр болып табылады; әрқайсысы алдыңғысының шығысын тексереді.

Неліктен растау қажет?

LLMлер еркін, бірақ кейде дәл емес нәтиже бере алады. Бұл галлюцинация деп аталады: модель шынайы болып көрінетін, бірақ шындыққа сәйкес келмейтін ақпаратты ойлап табуы мүмкін. Сөйлесу ойынында бұған жол беруге болады; өндірістік жүйеде (шот-фактура, денсаулық сақтау, заң, қаржы) жол беруге болмайды. Сөйтіп, соқыр сенімсіз болып шықты; расталады.

Тексеру қабаттары (әсері бойынша арту):

• Пішім/схеманы тексеру: шығыс күтілетін JSON схемасына сәйкес келе ме? (Құрылымдық өнім негізінен бұған кепілдік береді.)
• Ереже/логикалық тексеру: мәндер орынды ма? (Сома теріс пе, күн болашақта ма, санат жарамды ма?)
• Дереккөзді тексеру: Шағым ұсынылған құжаттамаға негізделген бе? Үлгі құжатта жоқ нәрсені айтады ма?
• Адамның мақұлдауы: сарапшы жоғары әсер ететін немесе анық емес шешімдерді қарастырады.

Абайлаңыз: «Модель өте жақсы, қосымша тексеру қажет емес» - бұл өндірістегі ең қауіпті қате. Модель қаншалықты жақсы болса да, тексеру деңгейі жоғары әсер ететін шешімдерде қауіпсіздік желісі болып табылады. Тіпті бір қате автоматты шешім барлық үнемделген уақытты алып тастауы мүмкін.

Циклдегі адам

Әрбір шешім толығымен автоматты болуы керек емес. Циклдегі адам тәсілінде модель жұмысты жылдамдатады және адам оны мақұлдайды. Дұрыс тепе-теңдік шешімнің әсеріне және модельдің осы тапсырмаға сенімділігіне байланысты.

Шешімнің әсері

Тәсіл

Төмен (белгі ұсынысы, нобай)

Толық автоматтандыру; қате арзан және қайтымды

Орта (бағыттау, басымдық беру)

Автоматтандыру + сынама алуды басқару

Жоғары (ақша, келісім-шарт, денсаулық, жою)

Адамның келісімі міндетті; үлгі тек ұсынады

Бақылау: Сіз көрмеген нәрсені басқара алмайсыз

Өндірісте сіз әрбір қоңырауды бақылауыңыз керек. Бақылаусыз сіз шығынды, сапаны жақсарта алмайсыз немесе мәселені ерте анықтай алмайсыз. Жазу үшін негізгі көрсеткіштер:

• Қолдану/құны: сұрау бойынша және жалпы белгілер, үлгіні тарату, күнделікті шығындар.
• Кідіріс: орташа және ең нашар жағдайда жауап беру уақыты.
• Қате деңгейі: 429/500 ставкалар, қайталау, бас тарту.
• Сапа: тексеру деңгейінде қабылданбаған шығыс жылдамдығы, адам мақұлдауындағы түзету жылдамдығы, пайдаланушының кері байланысы.

Кеңес: Бақылау журналдарына құпия деректерді (жеке ақпарат, кілттер) жазбаңыз. Құпиялылық аясында журналдарды қарастыру; қажет болған жағдайда бетперде арқылы жазу (9 блок).

Этика және шекаралар

Этикалық жауапкершілік техникалық дәлдік сияқты өндірістік шешімнің бөлігі болып табылады:

• Мөлдірлік: пайдаланушы жасанды интеллектпен немесе адаммен сөйлесіп жатқанын білуі керек.
• Әділдік және бейтараптық: Модель оқытылатын деректерден ауытқу болуы мүмкін; Жоғары әсер ететін шешімдерде (жалдау, несие) кемсітушілік салдарын бақылаңыз.
• Жауапкершілік: Егер автоматтандырылған шешім зиян келтірсе, сіз жауаптысыз; «Модель солай айтты» - бұл қорғаныс емес.
• Лимиттерді қабылдау: Модель кейбір тапсырмаларды сенімді орындай алмайды; оларды автоматтандыру да жобалық шешім болып табылады.

Көшіретін үлгілер

# Тексеруді тексеру парағы (шығаруды жасағаннан кейін)1) Схема жарамды ма? (құрылымдық шығысты тексеру) 2) Мәндердің мағынасы бар ма? (ережені тексеру: диапазон, күн, санау)3) Шағым көзге негізделген бе? (құжатта жоқ болса, қабылдамау)4) Әсері жоғары ма? → адамның мақұлдауына жіберу5) Егер бәрі орындалса → әрекетке рұқсат етіңіз, сақтаңыз

# Берілген құжаттағы ақпаратқа ғана сенетін дереккөзге сенетін жүйе шақыруы. Құжатта жоқ ештеңені қоспаңыз. Егер құжатта ақпарат жоқ болса, «Құжаттан табылмады» деп жазыңыз. Ешқашан бір нәрсені болжамаңыз немесе ойлап таппаңыз.

# Адамның мақұлдау шегі (шешім қабылдау ережесі)Егер шешім_түрі [ақша, келісім-шарт, жою, денсаулық] → адамның мақұлдауы міндетті болсаIf model_trust < шек НЕМЕСЕ валидация "белгісіз" → адамның мақұлдауына жіберу басқа → автоматты қолдану + іріктеуді бақылау

# Бақылау журналының үлгісі (сезімтал деректерді жазу){ "уақыт":"...", "модель":"...", "енгізу_таңбалауышы":..., "шығару_таңбалауышы":..., "кідіріс_мс":..., "тоқтату_себебі":"...", "аутентификация":"өтті|қабылданбады|адам", "өтіп кетті|қабылданбады|жеке деректер бізге жазылды": //_}

Әлсіз жедел / Күшті жедел (өндіріс сенімділігі)

# ӘЛСІЗ (тексеру жоқ, дереккөз жоқ, автоматты түрде қолданылады) Осы сұрауды бағалаңыз, ақшаны қайтару туралы шешім қабылдап, өтініш беріңіз.

# КҮШТІ (көзге негізделген, ұсыныс жасайды, адамның мақұлдауына қалдырады) Бұл қайтару сұрауын тек қайтару саясаты құжаты негізінде бағалаңыз. Шешімді негіздеумен ұсыныңыз, бірақ орындамаңыз: {"ұсыным":"бекіту|қабылдамау","себеп":"...","саясат_тармақ":"..."}.Басқармалық құжатта нақты негіз болмаса, "түсініксіз" деп беріңіз. Соңғы шешімді өкіл бекітеді.

Күшті нұсқасы; Ол шешімді дереккөзге жатқызады, модельді «орындаушы» емес, «ұсынушы» ретінде орналастырады және адамның мақұлдауының артына жоғары әсер ететін қадамды қояды. Бұл өндіріс сенімділігінің мәні.

Үш шағын корпус

1-жағдай - Тексеру қабаты сақталған күн. Финтек транзакция сипаттамаларын жіктейтін және автоматты есеп жазбаларын жасайтын модельге ие болды. Олар ережені тексеруді қосты: үлгі соманы қате шығарған кезде (құжаттағы 1250 орнына 12500), "сома құжатқа сәйкес келмейді" ережесі шығысты қабылдамады және жазба адамға түседі. Егер тексеру болмаса, қате жазба жүйеге үнсіз кіреді.

2-жағдай — Қашқын бақылауға түсті. SaaS тобы бақылау тақтасын орнатты; Бір күні таңертең күнделікті шығын үш есе өсті. Журналдардан клиент циклге кіріп, сол сұрауды мыңдаған рет жібергені көрінді. Олар квота мен қайталануды қосты; Мәселе бірнеше сағат ішінде шешілді. Бақылаусыз есеп айдың соңында күтпеген жағдай болар еді.

3-жағдай — шектеуді қабылдау. Денсаулық сақтау саласының стартапы диагнозды толығымен автоматты түрде жасап, оны пациентке көрсетуді жоспарлаған. Этика мен жауапкершілікті шолу кезінде олар бұл шектеусіз деп шешті: модель дәрігерге қысқаша мәлімет пен ықтимал ұпайларды ғана береді, дәрігер диагнозды қояды. Жұмысты автоматтандырмау да жетілген дизайн шешімі болып табылады.

Жалпы қателер

• Тексеруді өткізіп жіберу: «Үлгі жақсы» деп шығысты соқыр қолдану.
• Жоғары әсер ететін шешімді автоматтандыру: ақша/денсаулық/заң саласында адамның мақұлдауы маңызды.
• Бақылау емес: Құн мен сапа мәселелері кеш анықталады.
• Журналдарға құпия деректерді жазу: Құпиялылықты бұзу; Оны маска арқылы сақтаңыз.
• Дереккөзге сенуге тырыспау: Үлгі құжатта жоқ нәрсені құрауы мүмкін.
• Шектерді елемеу: Кейбір тапсырмаларды автоматтандыру дұрыс шешім; Ашықтық пен жауапкершілік сіздікі.

Тереңірек: шығарылымды басқару, кері қайтару және қосымша орналастыру

LLM мүмкіндігін өндіріске енгізу оны орнату және бұл туралы ұмыту емес; уақыт өте келе тірі жүйені қауіпсіз өзгерту болып табылады. Оның үш тірегі бар.

Нұсқа жасау. Жүйе нұсқауы, үлгі таңдау және тексеру ережелері уақыт өте өзгереді. Нұсқаның әрбір маңызды өзгерісі және қай нұсқаның тірі екенін жазыңыз. Бір күні сапасы төмендеп кетсе, "не өзгердік?" Сіз бірнеше минут ішінде сұраққа жауап бере аласыз. Нұсқасыз жүйеде регрессияның негізгі себебін табу бірнеше күнді алады.

Кері қайтару. Жаңа шақыру немесе модель тікелей эфирде күтілгеннен нашар әрекет етсе, алдыңғы, белгілі нұсқаға жылдам оралуыңыз керек. Қайтару жоспарынсыз өзгерту тірі тәуекелді соқыр қабылдайды. «Мен бірдеңені өзгерттім, ол нашар болды, мен қайта алмаймын» - ең қымбат өндіріс сценарийі.

Біртіндеп шығару. Өзгерісті барлық трафикке бірден қолданудың орнына, алдымен оны шағын пайызға (мысалы, 5%) шығарып, көрсеткіштерді (сапа, құн, қателер) бақылайсыз. Жақсы болса, пайызды көбейтесіз; Егер ол нашар болса, оны тек кішкене бөлігі ғана зақымданған кезде қайтарып аласыз. Бұл тәуекелді айтарлықтай шектейді.

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

Қысқаша айтқанда

Өндіріс жұмыс істейтін демонстрациядан да көп: бұл кіріс, модель, тексеру, әрекет және бақылау қабаттарының құбыры. Тексерусіз шығарылым сенімсіз; жоғары әсерлі шешімдер адамның мақұлдауымен байланысты; Әрбір қоңырау құны, қателері және сапасы үшін бақыланады. Этика, ашықтық, біржақты бақылау, есеп беру және шектеулерді қабылдау техникалық шешімдердің ажырамас бөлігі болып табылады. Осы модульде үйренген әрбір бөлік осы тұтас дизайнда біріктіріледі.

Қолданбалы тапсырма

LLM мүмкіндігін соңына дейін жобалаңыз. (1) Нақты тапсырма үшін бес қабатты (енгізу, үлгі, тексеру, әрекет, бақылау) толтырыңыз. (2) Қандай шешімдер адамның мақұлдауын қажет ететінін әсер ету арқылы белгілеңіз. (3) Кемінде үш валидация тексеруін жазыңыз (схема, ереже, дереккөз). (4) Бақылайтын негізгі көрсеткіштерді және нені тіркемейтінін анықтаңыз. (5) Осы мүмкіндікте қабылдайтын шектеу мен этикалық принципті жазыңыз.

бақылау парағы

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

Модуль емтиханы

1. LLM сөйлесу API-де "жүйе" рөлі не істейді?

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

Сипаттама: Жүйе рөлі модельге бүкіл сөйлесу барысында қолданылатын тұрақты нұсқауларды, тұлғаны және ережелерді береді; Бұл пайдаланушы хабарламаларынан бөлек жоғары деңгейлі қайта бағыттау.

2. Неліктен сөйлесу тарихы (алдыңғы хабарлар) API сұрауында қайта жіберіледі?

• A) Сервер тарихты жоятындықтан сақтық көшірме жасау қажет
• B) API шақырулары азаматтығы жоқ; ✔ Мәтінмән әрбір сұрау бойынша қайта жіберіледі, себебі үлгі тарихты есте сақтамайды
• C) Тек шот-фактура үшін қажет, үлгіге әсер етпейді
• D) Жауапты баяулатпау үшін тарихты жіберу міндетті

Түсініктеме: LLM API қоңыраулары азаматтығы жоқ; Модель алдыңғы раундтарды есіне түсірмейді, сондықтан барлық сәйкес тарих мәтінмәнді сақтау үшін әрбір сұрауға қайта жіберіледі.

3. LLM баға белгілеуіндегі «токен» дегеніміз не?

• A) API жүйесіне кіру үшін қолданылатын бір реттік құпия сөз
• B) Әрбір сұраныс бойынша төленетін тұрақты төлем
• C) Модель мәтінді өңдейтін ең кіші бірлік; әдетте сөз бөлігіне сәйкес келеді ✔
• D) Шығарылымның ұзындығын ғана өлшейтін бірлік

Сипаттама: Токен – модель мәтінді өңдейтін ең кіші бірлік; Ол әдетте сөздің фрагментіне сәйкес келеді және кіріс те, шығыс те таңбалауыштардың санына қарай зарядталады.

4. Неліктен LLM провайдерлерінің көпшілігінде шығыс таңбалауыштары кіріс таңбалауыштарына қарағанда қымбатырақ?

• A) Шығару таңбалауыштары әрқашан енгізуге қарағанда ұзағырақ болады
• B) Енгізу токендері тегін
• C) Шығару токендері интернет арқылы екі рет жіберіледі
• D) Өнім бірлігінің құны жоғары, себебі өнімді өндіру әрбір таңбалауыш үшін қосымша есептеулерді қажет етеді ✔

Сипаттама: Әрбір шығыс таңбалауышы модельден қадамдық генерацияны (есептеуді) орындауды талап етеді; Бұл өндіріс құны кірісті бірден өңдеуге қарағанда жоғары, сондықтан өнім бірлігінің бағасы әдетте жоғары болады.

5. Қандай жағдайда ағынды пайдалану ең тиімді?

• A) Ұзақ жауаптарда; Қабылданатын кідірістерді азайтады және күту уақытын болдырмайды ✔
• B) Тек өте қысқа, бір сөзден тұратын жауаптарда
• C) Шығынды нөлге дейін төмендету үшін
• D) API кілтін жасыру үшін

Сипаттама: Ұзақ жауаптарда ағын бірінші сөздерді бірден көрсету арқылы қабылданатын кідірісті азайтады және үлкен max_tokens мәндерінде HTTP күту уақытын болдырмайды.

6. Заманауи үлгілердегі «күш» параметрін арттыру жалпы алғанда не әсер етеді?

• A) Жауапты әрқашан қысқартыңыз
• B) API кілтін автоматты түрде айналдырады
• C) Ол тек кіріс белгісінің бағасын төмендетеді
• D) Ойлау тереңдігі мен таңбаны жұмсауды арттырады; Бұл сапаны жақсартуы мүмкін, бірақ сонымен бірге кідіріс пен шығынды арттырады ✔

Сипаттама: Күш параметрі модельдің тапсырма туралы қаншалықты терең ойлайтынын және қанша таңбалауыш жұмсайтынын реттейді; Жаңарту сапаны жақсартуы мүмкін, бірақ кідіріс пен шығынды арттырады. Қарапайым тапсырмалар үшін аз күш жұмсау жеткілікті.

7. Қарапайым, үлкен көлемді жіктеу тапсырмасын орындаудың ең үнемді тәсілі қандай?

• A) Әрқашан ең қымбат және ең күшті үлгіні пайдаланыңыз
• B) Әрбір сұраныс үшін барлық модельдерді бір уақытта шақыру
• C) Тапсырманы орындайтын ең жеңіл/ең арзан үлгіні таңдау, оны аздап бағалау арқылы тексеру ✔
• D) max_tokens мәнін қажетсіз тым жоғары ұстау

Түсініктеме: Егер тапсырма күрделі болмаса, ең қымбат және қуатты үлгіні пайдаланудың орнына тапсырманы оңай орындайтын жылдамырақ және арзанырақ үлгіні таңдау (мысалы, Хайку класы) шығындарды айтарлықтай төмендетеді.

8. Қай сценарийде жедел кэштеу шығынды барынша азайтады?

• A) Үлкен және бекітілген контекст көптеген сұраулар бойынша қайта-қайта пайдаланылғанда ✔
• B) Әрбір сұраныспен мүлдем басқа мәтін жіберілгенде
• C) Бір ғана сұраныс жасалғанда
• D) Шығару белгілерін азайту үшін

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

9. Сұрау кэшіне тиетіндей сұрауды қалай өңдеу керек?

• A) Айнымалы мазмұнды басына және тұрақты мазмұнды соңына қою
• B) Ағымдағы күн мен уақытты әрбір сұрау үшін жүйе шақыруына ендіру
• C) Тұрақты мазмұнды (жүйелік кеңес, құжаттар) басына және айнымалы мазмұнды соңына қою ✔
• D) Әрбір сұраныспен құралдар тізімінің ретін өзгерту

Түсініктеме: Кэш префикс сәйкестігі болғандықтан, бекітілген/өзгермейтін мазмұн (жүйе шақыруы, құжаттар) инициализацияланады; айнымалы мазмұн (күн, пайдаланушы сұрағы, сұрау идентификаторы) соңында қойылады. Тіпті басында өзгертілген бір байт кэшті жарамсыз етеді.

10. Пакеттік өңдеу жұмыс жүктемесінің қай түріне ең қолайлы?

• A) Пайдаланушы экранда лезде жауап күтетін тікелей чат
• B) Бір ғана қысқа сұрақ
• C) API кілтін жасау
• D) Кешіктіруге төзімді, көлемі үлкен және бірден нәтижені қажет етпейтін жұмыстар ✔

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

11. Нәтижелер пакетте қандай сұранысқа жататынын сенімді сәйкестендіру үшін не қолданылады?

• A) Сұраныстарды жіберу тәртібі (позициясы).
• B) Жауаптардың ұзақтығы
• C) API кілтінің соңғы 4 саны
• D) Әрбір сұрауға берілген бірегей теңшелетін_идентификатор ✔

Ескертпе: Жаппай нәтижелер жіберу тәртібінен басқа тәртіпте қайтарылуы мүмкін; сондықтан нәтижелерді әр сұрауға берілген бірегей custom_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) Тексеру тек токендердің санын азайтуға арналған

Сипаттама: LLM-тер еркін, бірақ кейде дәл емес (галлюцинаторлық) нәтиже бере алады; сондықтан ол жоғары әсерлі шешімдерде шықты; Ол схема/ережелерді тексеру, дереккөзді тексеру және қажет болған жағдайда адамның мақұлдауымен тексерілуі керек.