RAG-тағы метадеректер: қай сүзгілер шынымен жауапты жақсартады

Неге RAG сұраққа дәл түспей жауап береді

RAG-тың сұрақтан ауытқуы модельдің "ақымақ" болғанынан емес. Қате әдетте одан бұрын басталады: іздеу сұраққа сөз жағынан ұқсас үзінділерді табады, бірақ мағынасы жағынан емес. Адам қолданыстағы ереже туралы сұрайды, ал retriever дәл сол терминдер кездескен барлық құжаттарды әкеледі.

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

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

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

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

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

Индексте қандай метадеректер сақтау керек

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

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

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

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

Тағы бір пайдалы өріс - нұсқа статусы. Жоба, қолданыста, архив деген қарапайым көрінеді, бірақ дәл осы өріс көбіне күрделі ранжировщиктен де қатты әсер етеді. Индексте бір нұсқаулықтың үш редакциясы жатса, модель қайсысы жұмыс істейтінін, ал қайсысы тек тарих үшін керек екенін түсінуі тиіс.

Дерек көзі де маңызды, егер бір факт бірнеше жүйеде өмір сүрсе. Төлем мерзімі шартта, CRM-де және келісу тикетінде кездесуі мүмкін. source_system және source_id сақталса, дубликаттарды алып тастау, жауаптың қайдан шыққанын түсіну және кейін пайдаланушымен "іздеу солай тапты" деңгейінде дауласпау оңайырақ.

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

Дата қай кезде көмектеседі, қай кезде кедергі келтіреді

Дата жауап тез ескіретін жерде жақсы жұмыс істейді. Бұл тарифтер, лимиттер, дедлайндар, төлем ережелері, өтінім беру мерзімдері туралы сұрақтар. Адам "қазір қандай лимит қолданылады" немесе "есепті қай күнге дейін жіберуге болады" деп сұраса, ескі құжат көбіне тек кедергі.

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

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

Бұл үшін тек created_at жеткіліксіз. Жеке әрекет ету күні керек. Құжатты 12 наурызда жасап, 20 наурызда бекітіп, ал күшіне 1 сәуірде енгізуі мүмкін. Егер тек created_at-қа қарасақ, нәтиже біртүрлі болады.

Әдетте төрт өріс жеткілікті:

• status: active немесе archive
• valid_from: күшіне ену басталған күн
• valid_to: бар болса, аяқталу күні
• created_at: техникалық жасалған күні

Айырмашылықты қарапайым мысал жақсы көрсетеді. Қаржы бөлімі іссапар лимиттерін жаңартты, бірақ файлды жаңа ережелер басталардан бір апта бұрын жүйеге жүктеді. Пайдаланушы ертеңгі лимит туралы сұрайды. Жасалған күні бойынша құжат уже "жаңа", бірақ оған әлі сүйенуге болмайды. Ал әрекет ету күні бойынша - болады.

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

Дата индекске көбіне қажет. Бірақ оны қатаң сүзгі ретінде тек мерзім немесе лимит қателігі істің өзіне тікелей әсер ететін жерде ғана қолданған дұрыс.

Құжат түрі нәтижені қалай өзгертеді

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

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

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

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

Түрлер тізімі қысқа болғаны жақсы. Әдетте 5-8 түсінікті санат жеткілікті: саясат немесе регламент, нұсқаулық, тикет, лог немесе оқиға, қолдау хаттары. Санат тым көп болса, команда тез шатасады. Сонда бір файл бірде "регламентке", бірде "ереже"ге кіріп кетеді де, іздеу кездейсоқ әрекет ете бастайды. Мұндай жақын атаулардың зияны көп. Бір сөзді таңдап, оның нені білдіретініне келісіп алған дұрыс.

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

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

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

Қолданушының қолжетімділігін қалай ескеру керек

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

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

Файл деңгейіндегі тексеру жиі құтқармайды. Бір құжатты әртүрлі рөлдер әрқалай оқуы мүмкін: жалпы бөлігін бүкіл команда көреді, шарттың қосымшасын - тек заңгерлер, лимиттері бар кестені - тек басшылар. Ондайда құқықты тек файлдың өзіне емес, әр чанкке де сақтау керек. Әйтпесе іздеу "рұқсат етілген" файлды қайтарады, бірақ онымен бірге жабық үзіндіні де іліп әкеледі.

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

Логқа не жазу керек

Лог жай ғана белгі қою үшін керек емес. Онсыз жауап неге қысқа шыққанын немесе жүйе база ішінде бар құжатты неге "таппады" дегенді түсіну мүмкін емес.

Әдетте төрт өріс жеткілікті:

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

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

Егер команда мұндай көмекшіні AI Router арқылы іске қосса, audit-логтар кейін қандай құжаттар контекстке кіргенін және сүзгі нақты нені алып тастағанын тексеруге көмектеседі. Бұл даулы жауаптарды талдауды және қамту retriever-ден бе, әлде қолжетімділік құқықтарынан ба, соны анықтауды едәуір жеңілдетеді.

Сүзгілерді қадамдап қалай баптау керек

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

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

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

Сосын бір қадамнан бір қадамға өтіңіз:

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

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

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

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

Ішкі көмекшіге арналған мысал

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

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

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

Мұндай сценарийде әдетте үш сүзгі жеткілікті:

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

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

Фильтрге дейін модель ұзақ абзац бере алады, онда өткен жылғы лимит, хат алмасудағы дау және көрші командаға арналған жадынама араласып кетеді. Пайдаланушы ондай жауапты оқып, бәрібір қолмен қайта тексереді.

Үш сүзгіден кейін жауап әдетте қысқарақ әрі таза болады: "X өнімі үшін жаңа клиенттерге 3 млн теңге лимиті қолданылады. Негізі - 2025 жылғы 12 ақпандағы бұйрық". Бір факт, бір лайық құжат, артық қоқыс жоқ.

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

Қамту төмендейтін қателер

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

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

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

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

Әдетте қамту бес себептен төмендейді:

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

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

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

Жақсы сүзгі нәтижені жай ғана шектемейді. Ол шуды алып тастап, керек құжаттарды лақтырып тастамайды.

Іске қосар алдындағы жылдам тексеріс

Егер RAG тесттерде жаман жауап бермесе, іске қоспас бұрын демоның әсемдігін емес, ең қарапайым нәрселерді тексеру керек. Әдетте дәл солар адамға жаңа регламент пе, әлде ескі нұсқа ма, жабық құжат па, әлде бос жауап па - соны шешеді.

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

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

Іске қосар алдында қысқа тізімді өтіп шығыңыз:

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

Көбіне қолжетімділік бұзылады. Қызметкер шарт үлгісін сұрайды, қажет құжат база ішінде бар, бірақ қолжетімділік сүзгісі оны тым ерте кесіп тастайды. Сонда жүйе анағұрлым сәйкес келмейтін ашық файлды алып, сенімді түрде, бірақ мүлде басқа жауап береді. Мұндай қате ашықтан-ашық "таппадым" дегеннен де жаман.

Егер сіз ортақ API-шлюз қолданып, audit-логтарды сақтасаңыз, талдау әлдеқайда жеңілдейді. Мысалы, AI Router-де тек қорытынды жауапты емес, оған апарған жолды да тексеруге болады: қандай үзінділер іздеуге кірді, қайсысы алынып тасталды және қамту қай жерде төмендеді.

Соңғы тексеріс тіпті қарапайым: команда фильтрді қай кезде әлсіретуге болатынын, қай кезде болмайтынын білуі тиіс. Датаны кейде кеңейтуге болады. Пайдаланушының қолжетімділігін - жоқ.

Әрі қарай не істеу керек

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

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

Тек соңғы жауапқа қарамаңыз. Алдымен генерацияға дейінгі іздеудің өзін тексеріңіз. Бірдей сұрақтар жинағында сүзгісіз және сүзгімен іздеуді салыстыру пайдалы:

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

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

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

Егер бірдей сұрақтар жиынында бірнеше модельді салыстырсаңыз, AI Router сияқты бірыңғай шлюз де уақыт үнемдейді. Бір OpenAI-compatible endpoint арқылы бірдей сұрауларды жіберуге, интеграцияны қайта жазбауға және audit-логтарды дәл сол кейстер бойынша талдауға болады.

Кішіден бастаңыз, әр қадамды өлшеңіз және схеманы ерте күрделендірмеңіз. Үш өріс, бір сценарий, қысқа тест жиыны. Алғашқы цикл үшін осының өзі жеткілікті.