RAG-та ACL: құжат деңгейінде қолжетімділікті қалай жабуға болады

Неліктен кәдімгі RAG артық ақпаратты өткізіп жібереді

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

Мәселе іздеу кезеңінің өзінде басталады. Векторлық индекс сұраныстың мағынасын түсінеді, бірақ адамның лауазымын, бөлімін немесе рұқсат деңгейін білмейді. Егер ACL-ді алдын ала қоспасаңыз, колл-орталық қызметкерінің сұранысы ұқсас тіркестердің кесірінен заңгерлердің немесе HR бөлімінің ішкі құжатын оңай шығарып алуы мүмкін.

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

Реранкер қосымша қауіп тудырады. Ол жай embedding-ке негізделген іздеуге қарағанда мәтінді тереңірек оқиды және сұраққа жақсырақ жауап берсе, жабық үзіндіні ашықтан жоғары көтеріп жіберуі мүмкін. Жүйе өзі бөтен құжаттың конвейерден әрі өтуіне көмектеседі.

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

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

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

Тізбектің қай жерінде ақпарат ағып кетеді

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

Индекстеу файлдарды бұлттағы қалталардан, CRM-нен, wiki мен поштадан алады. Егер конвейер мәтінді сақтап, ал қолжетімділік ережелерін жартылай ғана көшірсе, ескі топ бойынша немесе тек қалта деңгейінде ғана қалдырса, индекстің өзінде артық ақпарат бар болып қояды. Одан кейін векторлық іздеу ең ұқсас үзінділерді таңдайды, ал құқық фильтрі кейінірек қолданылады. Бұл жылдам, бірақ жабық бөліктер кандидаттар жиынына әлдеқашан кіріп кеткен.

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

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

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

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

Құжатпен бірге құқықтарды қалай сақтау керек

Егер ACL тек бастапқы файлдың өзінде тұрса, RAG көбіне үзінділер деңгейінде бұзылады. Индекс құжаттың өзін емес, мәтін бөліктерін іздейді. Демек, әр үзінді өз құқықтарымен бірге сақталуы керек.

Индекстегі әр үзіндіде қысқа, бірақ толық метадеректер жиыны болғаны дұрыс. Әдетте document_id мен chunk_id үзіндіні бастапқы дереккөзбен байланыстыруға жеткілікті, acl_version мен content_version ескі және жаңа құқықтарды шатастырмауға көмектеседі, ал read, search, quote сияқты рұқсат етілген әрекеттер тізімі де керек.

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

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

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

ACL-ді мазмұннан бөлек версиялаңыз. Мәтін жаңарса, content_version өзгереді. Құқықтар өзгерсе, мәтін сол күйінде қалса да, acl_version өзгереді.

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

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

ACL-ді іздеуге қалай енгізу керек

Егер RAG-та ACL іздеуден кейін тексерілсе, жүйе артық нәрсені көріп үлгерді деген сөз. Дұрыс рет басқаша: қосымша алдымен сұрауды кім жасап жатқанын анықтайды, одан қолжетімділік сүзгісін құрастырады, содан кейін ғана индексқа жібереді. Реранкер, кэш және модель рұқсат етілген жиынның ішінде ғана жұмыс істейді.

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

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

Бірдей сүзгі іздеудің барлық режимінде жұмыс істеуі керек. Лексикалық, векторлық және гибридті іздеу қолжетімділіктің бірдей шекарасын көруі тиіс. Егер векторлық база кандидаттарды бермей тұрып сүзгілей алмаса, кең top-k алып, оны кейін кодта қысқартуға болмайды. Ол кезде тым кеш болады.

Реранкерге тек ACL-ден өткен кандидаттар ғана түсуі керек. Дәл осы ереже контекст жинауға да қатысты. Үзінді құжаттан құқықты мұраға алуы мүмкін, не өзіне одан да қатаң ереже алуы мүмкін, мысалы келісімшартқа қосымшада немесе жасырын бөлімде. Prompt-қа тек екі тексерістен де өткен үзінділер ғана кіруі тиіс.

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

Кэш тек сұраныс мәтінін емес, қолжетімділік құқықтарының ізін де ескеруі керек. Логтар мен трассировкаларды шикі мәтін бөлігісіз, тек құжат ID-лері, бағалар және қызметтік белгілермен сақтау жақсы. Егер модель шақырулары AI Router арқылы жүрсе, бұл инфрақұрылымның көрші қабатында көмектесуі мүмкін: сервис аудит-логтарды, PII маскировкасын және деректерді Қазақстан ішінде сақтауды қолдайды. Бірақ retrieval ішіндегі ACL бәрібір өз индексіңізде құрылуы керек.

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

Рөлдер мен бөлімдер бойынша мысал

Бір корпоративтік білім базасын елестетіңіз. Онда қолдау нұсқаулықтары, келісімшарт үлгілері, HR регламенттері және клиент шағымдарын ішкі талдау құжаттары бар. Іздеу бәріне ортақ, бірақ жауаптар бәріне бірдей болмауы керек.

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

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

HR-мен де ұқсас жағдай. Айталық, HR маманы «қызметкер шағымы» деп іздейді. Векторлық индексте клиенттік қолдаудан ұқсас бөліктер табылуы мүмкін, өйткені ол жерде де «шағым» сөзі жиі кездеседі. Егер қолжетімділік құқықтары дұрыс енгізілсе, жүйе бұл үзінділерді ranking-ке дейін және модельге бермей тұрып-ақ алып тастайды. HR тек кадрлық регламенттерді, өтініш формаларын және эскалация нұсқауларын алады.

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

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

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

Артық ақпаратты ашатын қателер

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

Ең жиі қате зиянсыз көрінеді. Команда алдымен индекстен top-k нәтижелерді алады, содан кейін тыйым салынған құжаттарды алып тастайды да, бәрі дұрыс деп ойлайды. Бірақ артық мәтін әлдеқашан ranking-ке, кэшке, логтарға немесе келесі қадамның контекстіне түсіп үлгерген. Сүзгі кандидаттар сыртқа шықпай тұрып жұмыс істеуі керек.

Тағы бір мәселе құқықтар файл деңгейінде сақталып, ал файлдың өзі кейін ережелер мұрагерлігінсіз үзінділерге бөлінгенде пайда болады. Сөйтіп бір PDF сату бөлімі үшін жабық, бірақ оның бөліктері индексте ACL-і жоқ кәдімгі жазбалар ретінде тұрады. Іздеу осындай үзіндіні жақсы сәйкестікпен табады, ал модель пайдаланушы көруге тиіс емес абзацты алады.

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

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

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

Жылдам өзін-өзі тексеруге бес сұрақ жеткілікті. ACL кандидаттарды іздеуге дейін қолданыла ма? Құқықтар тек файлға емес, әр үзіндіге де мұраға беріле ме? Кэш пайдаланушыға, рөлге және құқық версиясына байланған ба? Тесттік деректер production-нан бөлек пе? Отладкалық дамптардың өмір сүру мерзімі қысқа ма? Егер осы сұрақтардың біріне де сенімсіз жауап берілсе, қауіп бар деген сөз.

Релиз алдындағы тексерістер

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

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

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

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

Одан кейін бір құжаттың құқықтарын өзгертіп, уақытты белгілеңіз. ACL ауысқаннан кейін индекс, retrieval-кэш, prompt-кэш және сақталған кандидаттар жиынының бәрі жаңаруы керек. Мұнда анық мерзім қажет: бірден немесе бірнеше минут ішінде. «Түнгі тапсырмадан кейін» деген нұсқа тым әлсіз.

Соңында аудит логты ашып, нақты бір сұрауды табыңыз. Онда actor id, tenant, рөл, іске қосылған сүзгілер жиыны, сүзуге дейінгі және сүзуден кейінгі үзінді ID-лері, сондай-ақ болса, бас тарту себебі болуы керек. Егер модельдерді шақыру үшін бөлек шлюз қолдансаңыз, осы іздің іздеу, саясаттар және LLM шақыруының арасында жоғалмайтынын тексерген пайдалы.

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

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

Іске қосқаннан кейін не істеу керек

Іске қосқаннан кейін барлық дереккөзді бірден қоспаңыз. Бір ғана дереккөзден бастаңыз және ережелерін қолмен тексеру оңай болатын қарапайым рөлдер матрицасын алыңыз. Мысалы, түсінікті шекаралары бар бірнеше рөлді қалдырыңыз: HR кадрлық құжаттарды көреді, заңгерлер келісімшарттарды көреді, қалғандары оларды мүлде көрмейді. Осындай тар старт RAG-та ACL-дің қай жерде адал жұмыс істейтінін, ал қай жерде іздеудің әлі де артық нәрсені тартып тұрғанын тез көрсетеді.

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

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

Алғашқы апталарда бір жалпы графикке емес, үш метрикаға бөлек қараған пайдалы: ACL-ден кейінгі recall, кідіріс және бас тартулар саны. Егер сүзгілерді қосқаннан кейін іздеу релевантты үзінділерді әлдеқайда аз қайтара бастаса, сіз құқықтарды тым дөрекі алып тастаған болуыңыз мүмкін. Егер кідіріс өссе, сүзуді нақты қай жерде жасайтыныңызды тексеріңіз: векторлық іздеуге дейін бе, одан кейін бе, әлде екі кезеңде ме. Егер бас тартулар саны күрт өссе, көбіне пайдаланушының рөлі мен құжат атрибуттары арасындағы байланыс бұзылады.

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

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

Модельдерді шақыруға арналған инфрақұрылым қабатын да іздеудегі ACL логикасынан бөлек ұстаған жөн. Егер командаға деректерді Қазақстан ішінде сақтайтын, PII-ді маскилейтін және аудит-логтары бар бірыңғай OpenAI-үйлесімді шлюз керек болса, airouter.kz сайтындағы AI Router-ды бөлек бағалап көрген дұрыс. Ол сіздің индексіңіздегі құжаттарды сүзуді алмастырмайды, бірақ көрші тәуекелді жабады: модельдерге сұраныстарды кім, қайда және қандай деректермен жібереді.

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