Чанкинг пен эмбеддингтер RAG үшін: регламенттердегі галлюцинацияларды азайту

Құжаттардағы «галлюцинациялар» қайдан шығады

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

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

Пайдалы түрде екі түрдегі қателерді ажыратыңыз:

• Іздеу қатесі: жүйе дұрыс үзінді таппады немесе ұқсас, бірақ басқа нәрсені тапты.
• Генерация қатесі: қажетті үзінді бар болса да, модель оны бұрмалап айтып жіберді немесе артық ақпарат қосты.

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

Чанкинг жайынан қарапайым тілде: неге жауап сапасы соған тәуелді

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

Чанктер тым кішкентай болса, онда контекст жетіспейді. Мысалы, «басшыға келісу» деген фраза табылуы мүмкін, бірақ қандай жағдайларда, қандай мерзімдермен, қандай исключениямен екенінсіз. Жауап сенімді, бірақ толық емес немесе қате жалпылама болады.

Чанктер тым үлкен болса, іздеу «құжат шолуын» береді, қажетті пункт ұқсас формулировкалардың арасында жоғалып кетуі мүмкін. Модель жақын абзацты айтып, қадам нөмірін шатастырып немесе жалпы бөлімді нақты талаптың орнына ала алады.

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

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

Нарезка стратегиялары: нұсқаулықтар мен саясаттар үшін не таңдау керек

Регламенттер үшін әдетте бөлімдер мен подпункттар бойынша кесу жақсы нәтиже береді. Осылайша мағыналық шекаралар сақталады: мысалы, п. 3.2.1 бүтін күйінде қалады, көрші фрагменттерге тарап кетпейді. Егер сіз Чанкинг и эмбеддинги для RAG орнатып жатсаңыз және іздеу нақты пунктке түсуін қаласаңыз, осындай тәсіл маңызды.

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

Абзац бойынша кесу логикалық көрінуі мүмкін, бірақ нұсқаулықтарда жиі қадамдар тізімі үзіліп қалуы мүмкін. «1-қадам» пен «2-қадам» жеке болса, мағынасы тез жоғалады. Әдетте процедура өзгергенге дейін қадамдар қатарын бір чанкке біріктіру тиімдірек.

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

«Анықтамалар», «исключения», «жауапты тұлғалар» сияқты бөлімдерді бөлек чанктерге шығарып, типін белгілеу ыңғайлы. Сонда «кім бекітеді» деген сұрақ процедура сипаттамасында жоғалмайды.

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

Чанк өлшемі мен overlap: кездейсоқ емес таңдау

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

Практикалық ереже: мағыналық шекаралардан (тақырыптар, нөмірленген пункттер, подпункттер) бастаңыз, ал өлшемді құжат стиліне сай таңдаңыз. Қысқа пункттері бар нұсқаулықтарда әдетте 1–2 пункт бір чанкке (шамамен 120–220 сөз) жетеді. Ұзын сипаттамалары бар регламенттер үшін 250–450 сөз жеткілікті: ережемен бірге түсініктеме де орнығады.

Overlap көршілес екі пункттің екеуіне сүйену қажет болғанда пайдалы (мысалы, бірінде «кім келіседі», келесісінде — «мерзімдер»). Мұндай кезде 10–20% шамасымен бастаңыз: бұл жиі шекараны қамтуға жеткілікті және чанктерді дерлік бірдей қылмайды.

Пара қарапайым сигналдар, параметрлер жарамсыз екенін көрсетеді:

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

Мини‑тест: 10 типтік сұрақ алыңыз және көріңіз — қажетті пункт топ-3 нәтижесінде бар ма. «Жақын, бірақ емес» жиі болса — чанкты кішірейтіңіз. «Бар, бірақ шарттарсыз» болса — чанкты үлкейтіңіз немесе overlap қосыңыз.

Эмбеддинг параметрлері: қажетті пунктке түсуге не әсер етеді

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

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

Техникалық нәрселер өте жеңіл байқалмай «бұзылуы» мүмкін. Мысалы, модельді немесе размерді ауыстырдыңыз, ал индекс ескі қалды — сапа күрт төмендейді.

Эмбеддинг баптауларында тексеретіндер

Тексеріңіз:

• Құжаттар мен сұраулар үшін бір модель қолданыла ма (немесе query мен doc үшін дұрыс жұпталған схема).
• Вектор нормализациясы барлық жерде бірдей қосылған (көбінесе cosine similarity үшін L2-нормализация талап етіледі).
• Размердік сәйкестік: индекс сақтаған өлшеммен бірдей ме (модельді ауысырсаңыз, индекс қайта құрастырылуы тиіс).
• Модель шынымен де орыс тіліндегі канцелярит пен сіздің формулировкаларға жарамды ма.
• Кіріс ұзындығы: маңызды сөйлемдердің аяқтары токен лимитпен қиылып қалмай ма.

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

Егер сіз Чанкинг и эмбеддинги для RAG баптап жатсаңыз, қарапайымнан бастаңыз: 20 нақты сұрақ алыңыз, әрқайсысы үшін топ-5 табылған фрагментті қарап, ішінде нақты регламент пункті бар-жоғын белгілеңіз. Бұл тез көрсетеді — мәселе эмбеддингтерде ме, әлде нарезка мен іздеуде ме.

Іздеу баптаулары: top-k, порогтар және метадеректер

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

Top-k — контекстке қанша фрагмент салатыныңыз. Көп болғаны әрқашан жақсы емес. Егер регламент ұзын және пункттер ұқсас болса (мысалы, әр түрлі процедураларда «согласование мерзімі»), артық фрагменттер шуды тудырады және модель ең сенімді көрінгенді емес, дұрыс емесін таңдайды. Әдетте 3–5‑тен бастаңыз және сұрақ нақты бірнеше пункт талап еткен жағдайда ғана ұлғайтыңыз.

Ұқсастық бойынша порог (similarity threshold) — болжам жасауға тосқауыл. Егер ең жақсы үзінді порогтан төмен болса, нақтырақ сұрау немесе «жауап беруге негіз жоқ» деп айту дұрырақ. Регламенттер үшін бұл өте маңызды: бір ғана цифр немесе шарт мағынаны өзгертеді.

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

Метадеректер қателерді ойлағаннан да көп азайтады. Көбіне пайдалы фильтрлер:

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

Сонымен қатар аралас іздеу (кілттік сөздер + эмбеддингтер) терминдер, кодтар және пункт нөмірлері үшін жақсы жұмыс істейді: «ISO 9001», «п. 4.2.1», «S200», ішкі кодтар. Эмбеддингтер мәнді тауып, ал кілттік сөздер нақты сәйкес келуді береді.

Сапаны тексеру: «жақсарды» деген сезімнің орнына қарапайым тесттер

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

Нақты өмірден алынған сұрақтардың кіші жинағын жинаңыз: қолдау сұраулары, дау тудыратын жағдайлар, жиі қойылатын «ал егер...» сұрақтары. Әр сұрақ үшін қай нақты регламент пункттері дұрыс опора болатынын (1–3 үзінді) белгілеп қойыңыз — бұл эталон болады.

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

Retrieval‑ды генерациядан бөлек бағалаңыз:

• қажетті пункт top-k ішінде бар ма
• қай позицияда
• нәтижеде қанша «ұқсас, бірақ басқа» үзінді бар
• кейде қажетті пункт мүлде табыла ма

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

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

Қадам бойынша: Чанкинг пен эмбеддингті RAG үшін қалай баптау керек

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

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

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

3. Эмбеддингтер есептеп, индекс жасаңыз. Әр түрлі құжаттардың бірдей фразалары «жабысып» кетпеуін тексеріңіз (мысалы бірдей тақырыптар болғанда).

4. Контекст шығарылымын баптаңыз: қанша чанк алатыныңыз және қашан «жауап бермеу». Бастапқыда шағын top-k пен ұқсастық порогын қосыңыз. Егер жиі ұқсас пункттер шатасып жатса, реранкингті қосу орынды.

5. Тесттерді жүргізіп, циклды қайталаңыз. 20–30 типтік сұрақ алыңыз (мысалы «кім демалысты келіседі», «сұрауға жауап мерзімі»), және тексеріңіз: дұрыс пункт табылды ма, ескерту жоғалып кетпеді ме, нұсқалар араласпады ма.

Егер retrieval дәлдігі өссе, жауаптар көбіне модельді өзгертпестен жақсарады.

Күрделі жерлер: PDF, кестелер, нумерация мен нұсқалар

Көп қателер RAG‑та модельден емес, регламентті қалай мәтінге айналдырғаннан туындайды. Бұл әсіресе PDF, кестелер және қатты нумерациясы бар құжаттарда анық көрінеді.

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

Нумерация мен подпункттер (мысалы 2.3.1) мәтіннен кем емес маңызды. Егер кескен кезде нөмірлер жойылса немесе тақырып чанкте болмағанда мағына жоғалады. Жақсы тәжірибе — пункт нөмірін және тақырыптарды чанкте мәтіннің бөлігі ретінде сақтау, тек метадеректерге ғана салмау.

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

Кестелер: табылуын қалай жақсарту

Көбіне көмектеседі:

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

Нұсқалар (версионность) регламенттер үшін критикалық: ескі редакция бойынша жауаптар «галлюцинация» сияқты көрінеді. Метадеректерге дата, нұсқа нөмірі, статус (қолданыста/архивте) қосып, әдепкі бойынша «қолданыста» бойынша сүзгілеу жасаңыз.

Қысқа командалар («Басыңыз», «Ашып көріңіз», «Тексеріңіз») оңай араласады, егер чанк әртүрлі процедуралардан қадамдар ұстап қалса. Процедура шекараларына қарай кесіп, әр қадамға процедура атауын және қолдану шарттарын қосыңыз, осылайша қадам контексттен ажырап қалмайды.

Жиі кездесетін қателер және тұзақтар

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

Типтік мәселелер:

• «1000 символ бойынша кесіп тастаған»: тақырып бір чанкке, подпункттар басқа чанкке кетіп мағына бұзылады.
• Overlap тым үлкен: жүйе дерлік бірдей чанктер алады, және модель көрші формулировкаларды араластырады.
• Әртүрлі құжаттарды бір чанкке жабыстыру немесе метадеректерді (атау, нұсқа, бөлім) сақтамау: жауап басқа саясаттан алынған болуы мүмкін.
• Жауап жоқ деген режимді орнатпаған: ештеңе табылмаса да жүйе сенімді түрде қиялдайды.
• Тесті «әдемі» сұрақтармен өткізу: пайдаланушылар шын мәнінде қысқаша, тұрмыстық тілмен жазады, және retrieval соған сәйкес келмеуі мүмкін.

Қарапайым мысал: нұсқаулықта «Командировка» бөлімі мен «Суточные» подпункті бар. Егер тақырып қиылып қалса, суточные цифрлары басқа бөлімнен ұқсас сандармен сәйкес келіп қате жауап беруі мүмкін.

Жедел шаралар: құрылымды бойынша кесу (тақырып + подпункттар), overlap‑ты орташалау, метадеректерді фильтр ретінде сақтау, «өзек жоқ — жауап жоқ» қағидатын қосу және нақты чат/тикет формулировкаларымен тестілеу.

Пилот алдындағы тез чек-лист

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

Басты тексеретіндер:

• Нарезка құжат құрылымын қайталайды: бөлімдер, пункттер, подпункттер.
• Әр чанк тексеру үшін қажетті минимумды қамтиды: пункт нөмірі, тақырып және қысқа контекст.
• Мәтін индексацияда да, сұраныс өңдеуде де бірдей тазаланатын ережелермен өңделеді.
• Іздеу мұқият бапталған: топ‑k таңдалған, ұқсастық порогы және «негіз жоқ» режимі бар.
• Әр өзгертуден кейін іске қосылатын 15–30 сұрақтан тұратын тест жинағы бар.

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

Практикалық мысал: бір регламент, екі нарезка тәсілі

Мәселе: қызметкер чат‑ботқа белгілі бір сомадағы сатып алуды қалай келісуге болатынын және исключениялар бар ма дегенді сұрайды (мысалы, шұғыл бұзылыс немесе бір жеткізушіден ғана сатып алу). Регламент бір, бірақ жалпы ереже басында және исключения одан әріде жеке подпунктте тұр.

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

Не өзгерттік:

• құжатты подпункттар бойынша кесіп, нумерацияны сақтадық (мысалы 3.2.1, 3.2.2)
• анықтамалар мен исключенияларды жеке чанктерге шығардық, тіпті олар қысқа болса да
• чанкке бөлім атауының қысқа «шапкасын» қостық, контекст жоғалмасын деп

Тексеру практикалық болды: генерациядан бұрын «жедел сатып алу кезінде исключения бар ма» сияқты сұрақтар бойынша исключение туралы подпункт топ‑3‑ке түсетінін қарадық.

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

Келесі қадамдар: баптауларды жұмыс процесіне қалай енгізу

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

Кіші пилот жасаңыз және табыс критерийін алдын ала келісіңіз. Сондай‑ақ, қабыл алмайтын қателерді анықтап қойыңыз (мысалы, қауіпсіздік талаптарын шатастыру) — оларды іске қоспаңыз.

2–3 апталық жоспар қарапайым болуы мүмкін:

• бір регламент пен бір сұрақтар типін таңдаңыз
• 30–50 сұрақтан тұратын тест жиынтығын жинаңыз с эталонными пунктами
• метрикаларды бекітіңіз: top-k ішіне қажетті пункттің түсуі, «білемін» жауаптардың үлесі, жалған сілтемелер саны
• сапа үшін жауапты белгілеңіз: кім нарезка, эмбеддинг және іздеуді қабылдайды

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

Егер «ключ‑тапсырыс» қажет болса, жүйелік интеграторды қосу жиі жеңіл болады: корпоративтік талаптар (құқықтар, аудит, деректер сақтау) бар жобалар үшін.

On‑prem үшін инфрақұрылым және 24/7 қызмет сияқты мүмкіндіктер GSE.kz (gse.kz) негізінде ұсынылады, бірақ домен атауы өзгеріссіз қалдыру керек.