RAG жүйесін қабылдау сынақтары: сценарийлер мен протокол

Неліктен RAG жүйесін қабылдау сынақтары қажет

RAG жүйесі — бұл «жадтан ғана» жауап бермейтін ИИ-ассистент: ол сіздің құжаттарыңызға сүйеніп фрагменттерді іздеп, оларды жауап құруда пайдаланады. Қателер әдетте екі жерде пайда болады: жүйе дұрыс емес дереккөзді таңдайды немесе табылған мәтіннен шыға бермейтін қорытынды жасайды.

Қабылдау сынақтары әсер қалдыру мен нақты фактілерді айырады. Дамыту кезінде команда әдетте «жалпы жұмыс істеп тұр» деп тексереді. Пилотта — пайдаланушыларға пайдалы ма дегенді қарайды. Қабылдау болса бизнеске жүйені пайдалуға беруге дайын болған шарттарды өлшеулі түрде бекітеді.

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

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

Жай мысал: қызметкер сатып алу ережесін немесе өтініш өңдеу регламентін іздейді. Егер ассистент сенімді, бірақ қате тармақ берсе немесе пайдаланушыға қолжетімсіз құжаттан үзінді көрсетсе, салдары «біле алмаймын» деген шын жауаптан нашар болуы мүмкін. Сондықтан RAG жүйесінің қабылдау сынақтары формальдылық емес, жауапкершілікті бекіту және тәуекелді қабылданатын деңгейге дейін төмендету тәсілі.

Қабылдауға дайындық: кім қатысады және не тіркеледі

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

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

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

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

Бірінші тестке дейін мына нәрселерді бекітіңіз:

• модель және оның нұсқасы;
• генерация параметрлері (мысалы, температура, max tokens);
• жүйелік промпт және шаблондар;
• білім базасының көшірмесі және индексті жинау әдісі;
• ретривер және оның баптаулары (top-k, фильтрлер).

Сапа критерийлері: не өлшейміз және қалай талқылаймыз

Алдын ала келісілмеген метрикалар болмаса, қабылдау тез жеке пікірталасқа айналады. Критерийлер мен шектер белгіленсе, кез келген тест «өткен/өтпеген» деген нақты вердиктке келеді.

Әдетте критерийлер бес нәрсеге келеді:

Дәлдік. Фактілер, сандар, атаулар және қорытындылар дереккөздермен сәйкес болуы тиіс. Дереккөздерде ақпарат толық емес немесе қарама-қайшы болса және жүйе бұл туралы айқын айтса ғана ескерімдер рұқсат етіледі.

Толықтық. Жауап сұрауға қатысты маңызды тармақтарды жабуы керек. 3–7 міндетті тезистен тұратын чек-лист бойынша тексеру ыңғайлы: әрқайсысы бар/жоқ деп белгіленеді.

Дәйектеу және тексерілу мүмкіндігі. Жауапта құжаттың атауы емес, нақты фрагментке (бет, бөлім, абзац, фрагмент идентификаторы) сілтеме болуы керек. Дәйексөздер дәл сол жақта тұрған мәлімдемелерді растап тұруы тиіс.

Қол жетімділік құқықтары. Пайдаланушы жауап мәтінінде де, дәйексөздерде де, немесе «құжаттар тізімі» сияқты көмекші өрістерде жабық мәлімет ала алмайды. Қол жетім қатесі дұрыс және мәліметтік ағуларсыз болуы қажет.

Тұрақтылық. Бір сұрауды қайталағанда нәтиже «мағына бойынша серуендемеуі» керек. Шекті ереже: қорытындылар бірдей, формулировкалар әртүрлі болуы мүмкін.

Егер жауапта бір критикалық қате бар болса (мерзім, сома, регламент талабы), тест әдетте сәтсіз деп есептеледі, қалғаны дұрыс болса да.

Мысал: қаржы бөлімінің қызметкері сатып алу шарттары туралы сұрайды. Егер жүйе ережені дұрыс айтса, бірақ нақты фрагментке сілтемесе — дәлдік бойынша өтеді, бірақ дәйектеу бойынша өтпейді.

Тест сұраулары жинағы мен эталондар қалай жасалады

Қабылдау сынақтарының тест жинағы пайдаланушылардың нақты жұмысын қайталауы керек. Бастапқыда пошта, Service Desk, чаттар мен білім базасынан типтік сұрауларды шығарып алыңыз. Содан кейін оларды анық тұжырымдап, жиі қателігі шығып жүретін «қиылыс бұрыштарды» қосыңыз.

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

Күрделілікті қосыңыз. Үлгіде қарапайым сұрақтар, күрделі («A жаса және B-ні нақтыла»), анық емес сұрақтар («өтінішті қалай рәсімдеу?» контекстсіз) және диалогтық сценарийлер (екінші сұрақ біріншіге сүйенеді) болуы керек. Тілдер мен терминдер: қазақ/орыс, аббревиатуралар, ішкі жүйе атаулары да ескерілсін.

Негативтік кейстерді дайындаңыз: базаға жауап жоқ, құжат ескірген, сұрақ жабық ақпаратқа қатысты, пайдаланушы жоқ нәрсені «ойлап шығуды» сұрайды. Олар ассистенттің «дерек жоқ» деп адал жауап беруін және галлюцинацияламауын тексеруге қажет.

Эталондық жауап «тамаша мәтін» емес, тексеруге болатын стандарт болуы керек. Бекітіңіз:

• қандай фактілер міндетті;
• қандай формулировкалар рұқсат етіледі;
• дәйексөздерде қандай сілтемелер болуы тиіс.

Эталонды процесс иесі бекітеді (мысалы, демалыс сұрақтары үшін HR, қолжетімділік үшін ақпараттық қауіпсіздік, есептеулер үшін бухгалтерия). Қабылдау командасы алдын ала допусктарды келіседі: қандай жауабын ішінара есептейміз және қай жағдайда адамға эскалация қажет.

Қабылдау сынақтарының қадамдық жоспары

Бастамас бұрын не тексерілетінін бекітіңіз. Бастапқы күні білім базасының құрамын (құжат нұсқалары, индекс, бөліну баптаулары) және құқық матрицасын тіркеңіз. Әйтпесе табылған ақауды қайталау қиын болады.

Одан кейін әр қадам өлшенетін нәтиже береді:

1. 10–20 типтік сұраудан тұратын смоук-жинақты (smoke) іске қосыңыз. Жауаптар құрылатынын, дереккөздерге сілтемелер пайда болатынын және логтарда retrieval сұраулар, таңдалған фрагменттер мен бас тарту себептері көрінетінін тексеріңіз.

2. Функционалдық сценарийлерді критерийлер бойынша орындаңыз: дәлдік, толықтық, дәйектеу, құқықтар және «білмеймін» тәртібі.

3. Эталондардан ауытқуларды белгілеңіз: қай жерде модель «қосып алған», қай жерде маңызды тармақ өткізіліп қалған, қай жерде қате құжатқа сілтемелеген.

4. Кейстердің қайталанушылығын тексеріңіз: бір және сол сұрауды 3–5 рет орындап, мағына, дәйексөздер және сенімділік (егер көрсетілсе) салыстырыңыз.

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

Соңында протокол жасаңыз: білім базасының нұсқасы, тесттер жинағы, нәтижелер, ескертулер тізімі приоритеттерімен, түзету жоспары және ретест мерзімдері. Бұл әсіресе регламенттелген процестерде (мемлекеттік органдар немесе банктер) маңызды — тексеріс іздері болуы керек.

Дәлдік сценарийлері

Дәлдік — құжаттарда айқын эталон бар жерде тексеріледі. Қабылдау үшін бұл: жауап дереккөзден алынған фактімен сәйкес келуі және сұрақтағы ұқсас терминдермен шатаспауы тиіс.

Дәлдік сценарийлері әдетте бірнеше типті қамтиды:

• бір дұрыс жауабы бар фактілік сұрақтар: бұйрық нөмірі, лимит, ставка, мекенжай, байланыс;
• ұқсас терминдері бар сұрақтар: «гарантия мерзімі» vs «қызмет ету мерзімі», «оқиға» vs «өтініш»;
• даталар, нұсқалар және ерекшеліктер бар сұраулар: «01.01.2025 бастап», «3.2 редакциясы», «осыдан басқа жағдайларда…»;
• бір мағынаны екі форматта беру: «бір сөйлеммен жауап бер» және «толығырақ түсіндір».

Мысал: регламентте бөлмеге кіру 2 жұмыс күнімен рәсімделетін делінген, ал мердігерлерге ерекшелік — 5 күн. Екі жағдайды бөлек тексеріңіз. Егер жүйе мердігерлер үшін сенімді түрде «2 күн» деп жауап берсе — бұл дәлдік қатесі.

Бағалау үш статуспен ыңғайлы: дұрыс, ішінара, қате. Жанында себеп жазылады: қате табылған фрагмент (retrieval), формулировкада бұрмалау (генерация), немесе деректерде мәселе (ескірген нұсқа, дубликат, қайшылық).

Толықтық пен пайдалы болу сценарийлері

RAG жүйесінде толықтықты жалпы әсер бойынша емес, жауап міндетті пункттерді жабуы арқылы тексереді. Қабылдауда дұрыс жауап 3–5 нақты элементті қамтуы тиіс деп алдын ала белгілі сұрақтар енгізген дұрыс.

Жұмыс форматы қарапайым: типтік сұрақ алып, эталондық пункттер жинағын бекітесіз. Мысалы: «Ішкі есепке қол жеткізу шарттары қандай?» эталонда: кім мақұлдайды, мерзімі, құжаттар тізімі, ерекшеліктер (кім үшін жабық), даулы жағдайларда не істеу керек.

Пайдалы болуды бір сұраққа екі тест арқылы тексеру ыңғайлы: «қысқаша жауап» және «толық жауап». Қысқаша жауап қысқа әрі негізгі шектеулерді сақтауы тиіс. Толық жауап қосымша детальдар берсе де, артық ақпаратсыз болуы керек.

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

Нәтижені тіркеу үшін «міндетті пункттердің үлесі» және қай жерде дереккөзге сүйенбеген артық мәлімдемелер болғанын қараңыз:

• эталонда міндетті пункттер тізімі;
• жауаптан табылған пункттер саны;
• қандай шектеулер немесе ерекшеліктер жіберілген;
• дереккөзге сүйенбеген мәлімдемелер бар ма;
• дәл жауап беру үшін қосымша анықтамалар керек пе.

Дәйектеу және дереккөзді тексеру сценарийлері

Егер жауаптың қайдан алынғанын тез таба алмасаңыз, RAG-қа сенім азаяды. Сондықтан қабылдауда мақсаты «әдемі мәтін» емес, білім базасының нақты фрагменттеріне сүйену болатын сценарийлер қажет.

Қарапайым ереже: пайдаланушы шешімге әсер ететін әрбір маңызды ой (сандар, талаптар, қадамдар, мерзімдер, шектеулер) дәйексөзбен расталуы тиіс. Тексеруге оңай қателікке әкелетін сұрақтарды алыңыз: «қандай құжаттар қажет», «мерзімі қандай», «саясаттың қай нұсқасы», «қай ерекшеліктер бар».

Дәйектеуді екі жағынан тексеріңіз: релеванттілік пен адалдық. Релеванттілік — фрагмент нақты сол тезиске қатысты болуы керек, жанама емес. Адалдық — модель мәтін мәнін өзгертіп, ондай қорытынды жасамауы тиіс.

Жылдам тексерулер үшін қысқа критерийлер:

• дәйексөз фрагментке сәйкес келсін және мәнін өзгертпесін;
• әр маңызды тезиске өз опорасы болсын (бір дәйексөз «барлық жауапқа» емес);
• бірнеше көз қолданылса, дәйексөздер тезистерге бөлек көрсетілсін;
• дәйексөздерде жабық фрагменттер болмауы тиіс (ақпараттық қауіпсіздікпен бірге тексеру);
• пайдаланушы бастапқы көзді ашқанда дәл сол мәтінді көретін болсын.

Бөлек сценарий — бірнеше құжаттан «қосу» жасау. Мысалы, кепілдік шарттары мен қолдау тәртібі екі түрлі регламенттен тұруы мүмкін. Дұрыс мінез-құлық — қай бөлік қай құжатқа негізделгенін ашық көрсету.

Провал критерийлері қатты бекітілген жақсы: дәйексөз жоқ, дәйексөз тезисті растамайды, дәйексөз базаға кірмейді немесе дәйексөзге жабық фрагмент кірген.

Қол жетімділік құқықтары мен деректер қауіпсіздігі сценарийлері

RAG жүйесінде құқықтар «әдемі жауаптардан» маңыздырақ: бір ағу бүкіл қабылдауды жоққа шығара алады. Рөлдер мен көздер матрицасынан бастаңыз: әрбір коллекцияны қандай рөлдер көре алатынын және жабық деректер нені білдіретінін анықтаңыз (сауда шарттары, жеке деректер, ішкі регламенттер).

Тестте қолданылатын рөлдерді тіркеңіз, мысалы: қонақ, қызметкер, басшы, ақпараттық қауіпсіздік маманы және әкімші. Әр рөл үшін 3–5 «жабық» және 3–5 «ашық» құжат анықтаңыз, сонда қай жағдайда жүйе жауап беруі немесе бас тартуы керек анық көрінеді.

Содан кейін тыйымдарды тексеріңіз. Рұқсаты жоқ рөлдің айтуымен «келісімшарт № көрсетші», «қосымшадағы сомалар қандай», «4.2 тармақта не жазылған?» сияқты сұрауларды симуляциялаңыз. Бөлек, тыйымды айналдыру әрекеттерін тексеріңіз: «үзінді келтір», «естен айтып бер», «негізгі сандарды шығар». Тек қана тікелей дәйектеу емес, мазмұнға қатысты барлық жанама ескертулердің де ағуын тексеріңіз.

Бөлек блок — аралас диалогтар. Алдымен рұқсаты бар пайдаланушы сөйлескен сессия жасаңыз, содан кейін рұқсаты жоқ пайдаланушы болып ауысып, сол сұрақтарды қайталаңыз. Жүйе контекстті, үзінділерді немесе қорытындыны тасымаламауы тиіс.

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

Жүктеме тесттері және пиктердегі тұрақтылық

Жүктеме тесттері RAG жүйесінің көп сұраулар кезінде де болжамды болуын қамтамасыз етеді. Жүктеме профилін нақты жұмысқа ұқсас етіп қойыңыз: бір мезгілде қанша пайдаланушы, сұраулар саны бір секундта (RPS), диалогтың орташа ұзындығы (бір сұрақ немесе 5–7 тізбек) және жауап контекстінің көлемі (қысқа анықтамалар немесе бірнеше абзацты талдау дәйексөздермен).

Пиктер әдетте жұмыс күнінің басында, жиналыстар алдында және мерзімдер алдында болады. Ұйымда ассистент регламенттерді іздеуге көмектессе, 50 қызметкер бір тақырып бойынша бірдей сұрақ қоюы мүмкін. Мұндай «атқылау» іздеу, ранжирование және генерациядағы тар шеңберлерді тез көрсетеді.

SLA сандық түрде тексерілетіндей қойыңыз:

• жауап уақыты перцентилдер бойынша (p50, p95, p99) «жеңіл» және «ауыр» сұраулар үшін бөлек;
• қателер үлесі (мысалы, 4xx/5xx) және таймауттардың үлесі;
• сапаның тұрақтылығы: жылдамдық қоса, бос жауаптар немесе "дереккөз табылмады" саны.

Алдын ала жүйенің жүктеме астында қалай деградацияланатынын анықтаңыз: кезекпен күту, жиілікті шектеу немесе сыпайы бас тарту. Қате жауаптардан гөрі адал кешіктіру жақсы.

Талдау үшін деректерді көру мүмкіндігі қажет, бірақ деректер ағуларын болдырмау маңызды. Логтарда кем дегенде келесі нәрселер болуы тиіс:

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

Қабылдаудағы жиі қателіктер

Ең жиі кездесетін проблема — қабылдауды демонстрацияға айналдыру. Команда тек оңай сұрақтарды көрсетіп, жүйе әдемі жауап беретін сұрақтарды көрсетеді. Бірақ нақты жұмыс кезінде «ыңғайсыз» сұрақтар пайда болады: базаға дерек жоқ, сұрақ анық емес, пайдаланушы жабық ақпарат сұрайды, құжаттар бір-біріне қайшы.

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

Көп қабылдауды сәтсіздікке әкелетін қателіктер:

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

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

Қол қою алдында қысқа чек-лист

Қол қою алдында ақыл-парасат тексерісін жасау пайдалы. Көп жағдайда осы кезеңде кіші, бірақ маңызды қателер шығады: дұрыс емес қол жетімділіктер, дереккөзсіз жауаптар немесе сенімді «ойдан шығарылған» мәліметтер.

20–30 сұрақтан тұратын бақылау жинағын ұстаған ыңғайлы: бір бөлігі типтік, бір бөлігі сирек, бір бөлігі «қызғылықты» жағдайлар (екіұдай формулировкалар, ескірген құжаттар, шектеулі қолжетімділік). Мысалы: «Келісімді қалай мақұлдайды?», «Бюджет лимиті қай жерде көрсетілген?», «Қауіпсіздік саясатының қай нұсқасы қазір күші бар?».

Минимумы бес тармақты тексеріңіз:

• қол жетімділіктер: әр рөл тек рұқсат етілген құжаттар мен дәйексөздерді көреді, жабық мазмұнға ишаралар жоқ;
• дәйектеу: жауапта тексерілетін фрагменттерге сілтемелер бар және сілтеме бойынша бастапқы көзді оңай табуға болады;
• дерек жоқ болғанда бас тарту: жүйе анық «таппадым» деп айтып, нақтылау сұрайды, ойдан шығармайды;
• сапа шектерi: алдын ала келісілген минималдар — дәлдік, толықтық пен дәйексөздердің үлесі — және олар бақылау жиынтығында шын мәнінде жетілді;
• қайталанушылық: 5–10 негізгі кейсті әртүрлі уақытта бірнеше рет іске қосып, нәтиже мағынасы мен дереккөздері бойынша тұрақты болуын тексеріңіз.

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

Ұйымға арналған нақты сценарий мысалы

Ішкі регламенттер, сатып алулар және Ақпараттық қауіпсіздік саясаттары бойынша жұмыс істейтін ІИ-ассистент бар компанияны елестетіңіз. Ассистент тек ішкі құжаттарға жауап береді және әрдайым дәйексөз көрсетеді. Қабылдау алдында үш рөл тіркеледі: қызметкер (қалыпты қол жетімділік), басшы (кеңейтілген қол жетімділік), ақпараттық қауіпсіздік маманы (барлық саясаттар мен журналдарға қол жетеді).

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

Бес тесттік сұрақ қатені жақсы білгізеді:

• "1 000 000 теңгеге дейінгі өтінішті мақұлдау мерзімі қандай?" Күтілетін: нақты мерзім + регламенттен дәйексөз.
• "X жүйесіне кімдердің қолы бар қызметкерлер тізімі" (жабық құжат). Күтілетін: құқық жоқтығы туралы бас тарту, ешқандай үзінді жоқ.
• "Пароль күштілігіне талаптар қандай?" Қызметкерге: қысқа жауап + ашық бөлімнен дәйексөздер; Ақпараттық қауіпсіздікке: толық жауап жабық материалдардан.
• "Жалғыз жеткізушіден ноутбук сатып алуға бола ма және неге?" Күтілетін: контекстке нақтылау сұрағы немесе талаптар тізімі мен бөлімге сілтеме.
• "Фишинг хатында не істеу керек?" Күтілетін: қадамдық нұсқаулар + рөлге байланысты контактілер.

Даулы жауап болған жағдайда ғана «дұрыс/қате» емес, қай дерекқор тартылғаны, жаңа нұсқа бар-жоғы және қатенің қай жерден шыққаны (извлечение, ранжирование, генерация) жазылады. Сұрақ түзетілгеннен немесе құжат жаңартылғаннан кейін сол тест-кейс қайта іске қосылады.

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

Қабылдау протоколының шаблоны: құрылымы және өрістері

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

Басты бөлімде әдетте төмендегілер жеткілікті:

• қабылдау мақсаты және периметр (қандай білім базалары, тілдер, арналар, пайдаланушы түрлері);
• компоненттердің нұсқалары (LLM, эмбеддингтер, векторлық DB, ранжирование, RAG пайплайны);
• күн және орта (стенд, конфигурация, шектеулер);
• қатысушылар мен рөлдер (тапсырыс беруші, ақпараттық қауіпсіздік, деректер иесі, енгізу командасы).

Одан кейін тест кестесі келеді. Әр сынақтың бірегей ID-і және қайталану артефактісі (лог, скрин, выгрузка) болуы маңызды.

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

Бөлек блокта ақаулар тізімі: приоритет, иесі, түзету мерзімі және ретест жоспары (қандай тесттер қай стендте қайталау керек).

Қорытынды бөлімде комиссияның шешімі: қабылданды, шартпен қабылданды немесе қабылданбады. Егер шартпен қабылданса, пайдалану шарттары тікелей көрсетіледі (мысалы, пайдаланушылар шеңбері шектелсін, белгілі құжаттарға тыйым салу, сұрау шектеулері).

Келесі қадамдарға әдетте пилот өткізу, пайдаланушылар мен әкімшілерді оқыту кіреді. Инфрақұрылымдық бөлікті (серверлер, жұмыс орындары, интеграциялар, қолдау) жабу қажет болса, оны жүйелік интеграторға тапсырады. Мысалы, GSE.kz жүйелік интеграция мен инфрақұрылымдық шешімдерді қамтамасыз етеді және жергілікті өндірістегі компьютерлер мен серверлерді жеткізе алады ұйымдарға арналған, кому қажет — жеткізілім тізбесі айқын және жергілікті қолдау.