Корпоративтік ЖИ‑платформаға техникалық тапсырма: талаптардың құрылымы

Неліктен ТЗ қажет және ол не жазып қалдыруы тиіс

Техникалық тапсырма формальдылық үшін емес, платформа қандай мәселені шешетінін, кім оны қолданатынын және қандай нәтиже жақсы саналатынын бекітіп алуға керек. Олай болмаған жағдайда команда әсерлі «демо» жасап шығаруы мүмкін, бірақ ол нақты жұмыста көмектеспейді.

Корпоративтік жүйеге кірісерде шекараны алдын ала келісу маңызды: қандай процестерге әсер етеді, қандай деректер қолдануға рұқсат етілген, ИИ қай жерде ұсыныс береді, ал қай жерде шешімді адам қабылдайды. Бір құрал әртүрлі бөлімдерде — қолдау, юристік, HR немесе өндірісте — әрқалай жұмыс істейді. ТЗ күтулерді араластырмауға және үш айдан кейін дау туындамауына көмектеседі.

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

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

ТЗ мақсаттарды, метрикаларды, шектеулер мен қабылдауды белгілейді. Жобаның орындаушылары әдетте нақты модельдерді, жеткізушілерді, орналастыру архитектурасын, мониторинг құралдарын және интеграция әдістерін өздерінің шешімінде көрсетеді.

Мақсаттар, шекаралар және пайдаланушылар

ТЗ‑да мақсаттар жұмыс нәтижесін адал қабылдау үшін өлшенетін түрде көрсетілуі тиіс: қандай сапа көрсеткіші қажет, жауапқа қанша уақыт рұқсат етіледі, бірінші релизте қандай пайдаланушылар мен процестер қамтылуы керек.

Мысалдар: «N тексеріс жағдайындағы бақылау жиынтығында кемінде 85% дәлдік», «95% сұраныстарға жауап 3 секундтан аспасын», «3 ай ішінде 2 бөлімше мен 5 типтік сценарийді қамту». Осылайша ТЗ тексерілетін және дау аз болады.

Келесі қадам — шекараларды бекіту. Қай сценарийлер қосылады (мысалы, ішкі құжаттар бойынша іздеу, өтініштерді жіктеу, операторға ұсыныс беру), ал қайсысы кірмейді (құқықтық қорытынды дайындау, қаржылық шешімді автоматты қабылдау, жеке деректермен жұмыс жеке контурсыз). Шекаралар маңызды, өйткені ИИ үміт арқылы «табысады» және көлемі ұлғая береді.

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

Соңында шектеулерді қосыңыз: мерзімдер мен бюджет, регуляторлар мен ішкі ИБ талаптары, қолдайтын тілдер (мысалы, орыс және қазақ), сондай‑ақ қай жерде адамның болуы міндетті (шешімді растау, сезімтал жауаптарды тексеру).

Рөлдер, жауапкершілік және өзгерістерді басқару

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

Арнайы кім негізгі шешімдерді бекітетіні көрсетілсін: кейстер мен метрикаларды таңдау, деректерді пайдалану допусталуы, пайдаланушы қолжетімі деңгейі, жеткізу моделі (on‑prem немесе бұлт), пилот пен өндірістік жұмысқа дайындық критерийлері.

Негізгі тапсырмалар бойынша RACI

Қарапайым RACI матрицасын жасаңыз (Responsible, Accountable, Consulted, Informed) — көбінесе келесі тақырыптарда қателіктер болады:

• Деректер (дереккөздерді қосу, сапа, құқықтар): R - деректер иесі, A - бизнес‑иеленуші, C - IT/ИБ, I - пайдаланушылар
• Қауіпсіздік және қолжетімдер: R - ИБ, A - CISO/ИБ жетекшісі, C - IT/заң бөлімі, I - бизнес
• Эксплуатация және SLA: R - IT/қолдау, A - IT директоры, C - мердігер, I - бизнес
• Модель сапасы және метрикалар: R - DS/ML командасы, A - өнім иесі, C - бизнес‑эксперттер, I - IT
• Өзгерістер және релиздер: R - өнім менеджері, A - өзгерістер комитеті, C - IT/ИБ, I - барлық әсерленген тараптар

Өзгерістерді басқару және версиялау

ТЗ‑дағы түзетулер тәртібін сипаттаңыз: өзгеріс сұранысы қалай түседі, кім әсерін бағалайды (мерзім, бюджет, тәуекел), кім бекітеді және құжаттың версиясы қалай жүреді. Базалық минимум: версия нөмірі, дата, автор, өзгерістер тізімі, статус (жоба/келісім/бекітілді).

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

Модельдерге және нәтижелер сапасына қойылатын талаптар

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

Сапаны өлшенетін түрде сипаттаңыз. Әр тапсырмаға метрикалар мен минималды шектерді, сондай‑ақ қате шығынын көрсетіңіз. Жіктеу үшін precision/recall және «сенімсіз» жауаптардың үлесі, іздеу үшін топ‑N ішіндегі релеванттық үлесі, ассистент үшін бақылау жиынтығы бойынша дұрыс жауаптың үлесі және галлюцинациялар жиілігі. Қателерді маңызды (мысалы, регламентке қате ұсыныс) және шартты түрде қабылданатын («түсініктеме қажет») деп бөліңіз.

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

Өнімділік пен есептеу шығындары сапа сияқты қатты бекітіледі. Әдетте ТЗ жауап уақытын (мысалы, чат пен іздеу үшін P95 X секундтан аспауы), шипа уақытының шекті жүктемесін, CPU/GPU шектеулерін және инференс бюджетін, тұрақтылық талаптарын (5xx қателер үлесі, шектеулі уақытта мінез‑құлық) және іздеуде деректер жаңартылу кешігуін белгілейді.

Жаңартулар саясаты да қажет: қаншалықты жиі қайта оқыту қажет, жаңа версия шығаруға қандай шарттар қойылады және кім релизді бекітеді. Жақсы тәжірибе — «сапа қақпалары»: жаңа модель тек тест жиынтығын өтсе, негізгі метрикаларды нашарлатпаса және откат жоспары болса ғана продукцияға өтеді. Сезімтал сценарийлерде (банк, мемлекеттік орган) релиз әдетте процесс иесі, қауіпсіздік бөлімі және эксплуатация командасы арқылы бекітіледі.

Деректер: көздер, сапа, разметка және сақтау

Деректер функционал сияқты дәл сипатталуы тиіс. Қайдан алынатынын, кім жауапты екенін және қандай форматта келетінін алдын ала анықтамасаңыз, модель сапасы ауытқиды, мерзімдер бұзылады.

Бастап дереккөздерді тізіп шығыңыз: CRM/ERP, документооборот, Service Desk, пошта, базалар, файлдар, сенсорлар, колл‑центр. Әр көз үшін иесін (қол жеткізуді кім береді және өрістер мәнін кім растайды), форматты (кесте, мәтін, PDF, аудио), көлем мен жаңарту жиілігін (онлайн, сағат сайын, тәулігіне) көрсетіңіз. Сонымен қатар тыйымдар: шығаруға болмайтын өрістер, «лапы» өрістер және эталондық справочниктер.

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

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

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

Егер жеке немесе сезімтал деректер қолданылса, минимизация принципін енгізіңіз (тек қажетті өрістер). Анонимдеу рәсімін (Тау/Тегі, телефон, ИИН маскирленуі), ИБ мен заң бөлімімен келісімдерді және тест орталарында осындай деректерді қолдануға тыйымды бекітіңіз.

Мысал: қолдау көмекшісі үшін Service Desk және база мәліметтерінен бастауға болады, бірақ ТЗ‑да телефон нөмірлері мен жеке деректер оқыту жиынына қосылмас бұрын жойылатынын және экспорттар жобалық топқа ғана қолжетімді екенін жазып қою керек.

Интеграциялар: ИИ процестерге қалай енеді

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

Бастап нақты қатысатын жүйелерді тізіңіз: ERP/CRM, электрондық документооборот, корпоративтік пошта мен күнтізбе, колл‑центр, өтініш порталы, файл сақтау, корпоративтік базалар. Әр жүйе үшін иесін, айналаны (тест немесе прод) және шектеулерді (ішкі контурдан ғана қолжетімді, прокси арқылы ғана) көрсетіңіз.

Қалай қосылу және қашан іске қосу

Негізгі және резервтік қосылу жолын таңдаңыз, сол арқылы ендіру кезеңінде «мүмкін болмай қалу» мәселесіне ұрынбайсыз. Әдетте онлайн сұраулар үшін API, асинхронды тапсырмалар үшін хабар кезегі және пакет алмасу жинақталған шешімдер біріктіріледі. Егер компанияда ESB болса немесе қосымшалардан оқиғалар кетсе, оларды да нұсқаңыз.

Содан кейін триггерлер мен оқиғаларды сипаттаңыз: не ИИ‑ны іске қосады (жаңа тикет, хат келуі, құжат статусының өзгеруі), қандай параметрлер өтеді және жауап қайда түсуі тиіс (CRM карточкасы өрісі, тикетте түсініктеме, документооборотқа қосымша, жауаптыға тапсырма).

Сенімділік, қателер және бақылау

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

Обмен форматтарын (JSON, XML, CSV), өріс схемаларын, кодтауды, версиялауды және сезімтал деректерді маскирлеуді сипаттаңыз. Лог жазуда нені тіркейміз: сұрау идентификаторы, дереккөз, уақыт, статус, модель версиясы, қате коды. Егер саясатқа қарсы болса, артық контентті (мысалы, толық хат мәтінін) сақтамаңыз.

Мысал: колл‑центрде «қоңырау аяқталды» оқиғасы метадеректер мен транскриптіні кезекке жібереді, ИИ категориялар мен тәуекел белгілерін CRM‑ге қайтарады, ал қате болғанда қолмен тексеру тапсырмасы жасалып, интеграция журналында себеп жазылады.

Қауіпсіздік және сәйкестік талаптары

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

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

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

Шифрлау екі күйде сипатталсын: сақтау және тасымалдау. Кім кілттерді басқаратынын, ротация қалай өтетінін және компрометацияда не істеу керектігін айтыңыз. Құпияларды тек мақұлданған қоймаларда сақтау талаптары болса, ТЗ‑да нақты көрсетіңіз.

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

Соңында сәйкестік талаптарын: ішкі ИБ саясаттары, регулятор талаптары, инциденттерге реакция рәсімдері және тұрақты тексерістер тәртібін қосыңыз.

Эксплуатация: MLOps, мониторинг, қолдау және SLA

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

Орталар және релиздер

Әдетте минимум үш орта қажет: дамыту, тест және продуктив. ТЗ‑да олардың айырмашылықтары: қолжетімділіктер, деректер жиынтығы (тестте анонимденген немесе синтетикалық), ресурс лимиттері және модельдер мен конфигурацияларды орталар арасында кім және қалай көшіреді — жазылсын.

Релиз процедурасын қарапайым қадамдармен сипаттаңыз: релизге дайындық критерийлері (тестілеу, сапа метрикалары, қауіпсіздік тексерістері), өзгеріс және келісу терезесі, откат жоспары, өзгерістер журналы.

Мониторинг, инциденттер және SLA

Мониторинг сервиске қолжетімділіктен бөлек сапаны да қадағалау керек. Міндетті метрикаларды бекітіңіз: бақылау жиынтығындағы дәлдік, деректер дрейфының индикаторлары, қателер үлесі, жауап уақыты және инфрақұрылым жүктемесі. Хабарландыру порогтарын, коммуникация арналарын және инцидентті кім растайтынын көрсетіңіз.

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

Резервтік көшіру және қалпына келтіру бөлек бекітілсін: не сақталады (деректер, модельдер, конфигурациялар), қаншалықты жиі, қайда сақталатындығы, RPO/RTO және жауапты тұлға.

Егер ИИ‑сервис ұйымның өз контурында (мысалы, дата‑орталықтағы стойкаларда) жұмыс істесе, алдын ала кім 24/7 жауап беретіні және қалпына келтіру қалай тексерілетіні анықталсын. Бұл жерде 24/7 процестер мен жүйелік интеграторлар сияқты серіктестер пайдалы болуы мүмкін (GSE.kz мысалындағыдай), бірақ талаптар ТЗ‑да нақты жазылуы тиіс.

ТЗ‑ның қадамдық құрылымы: талаптарды үзіліссіз жинау

Жақсы ТЗ‑ны кезеңдер бойынша жинаған оңай. Логика: алдымен адамдардың нақты жұмысын бекітіңіз, одан кейін деректерді тексеріп, кейін сапа туралы келісіп, соңында интеграциялар, қауіпсіздік және эксплуатацияны жауып шығу.

Практикалық тәртіп:

1. Сценарийлер мен нақты сұрауларды жинаңыз. Әр пайдаланушы типінен 10–20 нақты формулировка сұраңыз (хаттарда, чаттарда, өтініштерде қалай жазады). Қай жауап «дұрыс» екенін және қандай формат қажет екенін (мәтін, кесте, құжатқа сілтеме, қысқаша мазмұн) көрсетіңіз.

2. Деректерді сипаттап, көздердің қолжетімділігін тексеріңіз. Әр сценарийге жүйелер, деректер иесі, жаңарту жиілігі, өрістер, сапа және шығару шектеулерін көрсетіңіз. Көбіне қажетті деректер бар, бірақ олар техникалық немесе құқықтық себептермен қолжетімсіз болады.

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

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

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

Контакт‑центр мысалы: сценарийлер нақты диалогтарды береді, деректер Service Desk пен CRM‑дан тексеріледі, метрикалар жауап уақытын төмендетуді қадағалайды, интеграциялар оператор интерфейсіне жұмыс істейді, ал қауіпсіздік логтарда жеке деректердің көрінуіне тыйым салады. Бұл жол пилот алдында ТЗ‑ға не қосу керектігін тез көрсетеді.

Пайдаланушыларды оқыту және ИИ‑мен жұмыс ережелері

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

Міндетті оқыту пакеті

Әдетте әр рөлге 30–60 минуттық қысқа сессия және жұмыс кезінде ашылатын материалдар жеткілікті. ТЗ‑ға қосуға пайдалы минимум: типтік тапсырмалардың нұсқаулығы (5–10 жиі кездесетін сценарий), сұрау шаблондары мен жақсы формулировкалар мысалдары, «жауап сомнительді болса не істеу» анықтамасы және кімге эскалациялау керектігі, жаңа қызметкерлерге кіріспе курс (тестпен), модель немесе ережелер өзгерген сайын оқытуды жаңарту кестесі.

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

Қолдану ережелері және жауапкершілік

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

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

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

Сценарий мысалы: пилоттан өндірістік жұмысқа дейін

Пилот: ИИ‑ассистент бірінші сызық сервис‑дескке көмектесіп, жауап жобасын ұсынады, база мақалаcын табады және тикеттің өрістерін толтырады (категория, приоритет, бөлім). Бұл желіні чат емес, қадамдар тізбегі ретінде сипаттау маңызды.

Деректер үшін әдетте соңғы 6–24 ай тикеттер тарихы, база мақалалары, жауап шаблондары және справочниктер қажет. Қол жеткізу минималды принциппен шектеледі: ассистент тек жауап үшін қажетті тикет өрістерін көреді, жеке деректер (телефон, ИИН, адрес) жасырылады немесе маскирленеді. Сонымен қатар қай жерде деректер сақталатыны және кімге экспортқа рұқсат бар екенін жазып қойыңыз.

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

Қабылдау метрикаларын пилот және өндіріс режиміне бөлу орынды. Пилот (4–8 апта) үшін ұсынылған жауаптар үлесі, оператор қабылдаған жауаптар, орташа жауап уақытындағы төмендеу және жіктеу дәлдігі сияқты көрсеткіштерді қарайды. Өндірісте ай сайынғы тұрақтылық, SLA сақталуы, эскалациясыз өтетін қолданбалар үлесі, қателер мен қауіпсіздік инциденттерінің басқарылуы маңызды.

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

Қабылдау, жиі қателер, чек‑лист және келесі қадамдар

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

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

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

Жиі кездесетін қателер: метрикалар сөзбен жазылып, нақты сандар мен порогтар жоқ; деректер иелері мен сапа жауапкершілері тағайындалмаған; продтағы мониторинг жоспары болмаған (не қадағалаймыз, қалай жауап береміз, кім дежурлайды).

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

Черновиктен кейінгі қадамдар: инфрақұрылымды бағалау (қайда ИИ жұмыс істейді және қандай қуат қажет), қолдау моделі (ішкі күш пе әлде мердігер ме) және пилот жоспары мен даталарын жасау. Егер орналастыру on‑prem және корпоративтік контурға интеграция қажет болса, GSE.kz жүйелік интеграторы ретінде серверлер мен жұмыс станцияларын ұсынуда пайдалы болуы мүмкін.