RAG үшін құжаттарды бөлу: оны тест арқылы қалай тексеруге болады

Неліктен бөлу туралы дау уақытты созады

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

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

Мұнда интуиция жиі жаңылыстырады. «Логикалық» мәтін бөлігі оңай табылуы керек сияқты көрінеді. Шын мәнінде іздеу адам сияқты оқымайды. Ол embedding-ті, көрші тіркестерді, қайталануларды, қызметтік шуды және сұрақтың нақты емес тұжырымын көреді. Сондықтан жиналыстағы әдемі түсіндіру шынайы тестте жеңіліп қалуы мүмкін.

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

Дау әдетте бәрі бірдей сұрақтар жиыны мен бірдей құжат корпусына қараған кезде ғана тоқтайды. Сонда қай нұсқа қажетті фрагментті жиірек табатыны, қай жерде іздеу қателесетіні және reranking көмектесе ме — бәрі көрінеді. Мұндай әңгіме бір сағатқа жетеді. Онсыз командалар нәтижеге емес, талғамға қатысты апталап дауласа береді.

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

Жақсы нәтиже қандай болу керек

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

Әдетте төрт метрика жеткілікті:

• hit@k — қажетті фрагмент top-k нәтижесіне кірді ме
• жауап дәлдігі — пайплайн сұраққа дұрыс жауап берді ме
• кідіріс — сұрау қанша уақыт алады, median мен p95-ке қараған жақсы
• құны — бір прогонның немесе 1000 сұрақтың бағасы

Алдымен іздеуге, содан кейін жауаптың өзіне қараңыз. Бұл маңызды. Егер қажетті фрагмент top-k-қа кірмесе, мәселе көбіне бөлу, индекстеу немесе reranking-те болады. Егер фрагмент кіріп тұрса, бірақ жауап бәрібір нашар болса, онда prompt-ты, модельді немесе контекст пішімін талдауға болады.

Іздеуді тексеру үшін қарапайым критерий керек: әр сұраққа сізде эталон фрагмент немесе ең кемі жауап жатқан құжат болуы тиіс. Осыдан кейін сол фрагмент қанша жағдайда, мысалы, top-3 немесе top-5-ке кіргенін санауға болады. Фрагменттеу тесті үшін көбіне осының өзі жеткілікті. Егер нұсқа қажетті мәтін бөлігін жоғарыға көтермесе, екі-үш сәтті мысалдағы әдемі жауап ештеңені дәлелдемейді.

Шекті мәнді алдын ала қойған дұрыс. Мысалы, нұсқа мына шарттарға сай болса, тесттен өтеді:

• hit@5 85%-дан төмен түспейді
• p95 сіздің SLA аясында қалады
• баға лимитіне сыйады
• базалық нұсқамен салыстырғанда жауап дәлдігін түсірмейді

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

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

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

Бір сұрақтар жиынын жинаңыз

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

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

Қиялдан алынған мысалдардан гөрі, жұмыстағы тірі сұрауларды алған дұрыс: білім базасын іздеуден келген сұрақтар, support ticket-тер, пайдаланушылармен хат алмасу, ішкі нұсқаулықтарға қызметкерлердің сұраулары, onboarding, сату немесе compliance бойынша жиі қойылатын сұрақтар.

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

Жақсы тест жиыны сирек жинақы көрінеді. Және бұл жақсы. Егер онда тек бір стильдегі тегіс сұрақтар болса, тест тым жұмсақ болып кетеді. Нақты жұмыста адамдар қысқаша жазады, терминдерді шатастырады, детальдарды өткізіп жібереді және бір хабарламада бірнеше шартты араластырады.

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

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

Жиындық дайын болса — оны салыстыру аяқталғанша бекітіп қойыңыз. Алғашқы нәтижеден кейін ыңғайсыз сұрақтарды өшірмеңіз және жаңаларын қоспаңыз. Әйтпесе сіз фрагмент өлшемін, қабаттасуды немесе reranking-ті емес, аралық сандарға берген реакцияңызды тесттеп жатырсыз.

Бөлу нұсқаларын дайындаңыз

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

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

Тәжірибеде бірдей құжаттар жиынын алып, индекстің бірнеше нұсқасын жинау ыңғайлы:

• қабаттасусыз 300–400 токен
• 10–15% қабаттасумен 300–400 токен
• қабаттасусыз 700–900 токен
• 10–20% қабаттасумен 700–900 токен

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

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

Бұл embedding-терге де қатысты. Осы кезеңде embedding моделін қозғамаған дұрыс. Әйтпесе сіз бөлу схемаларын емес, екі фактордың қоспасын салыстырасыз.

Шатаспау үшін әр нұсқаға қысқа ат беріп, оны тест кестесіне енгізіңіз. S350-O0, S350-O40, S800-O0, S800-O80 сияқты белгілеулер жарайды, мұнда S — фрагмент өлшемі, ал O — қабаттасу. Қасында тағы үш өріс болсын: қандай құжаттар индекске кірді, қандай тазалау қолданылды және қай embedding моделі пайдаланылды.

Reranking-ті бөлек тексеріңіз

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

Алдымен барлық бөлу нұсқаларын reranking-сыз өткізіңіз. Embedding, top-k, сұрақтар жиыны және бағалау тәсілі бірдей болсын. Сонда фрагменттердің таза әсері көрінеді: қай нұсқа қажетті абзацты кандидаттар тізіміне жиірек шығарады.

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

Тек соңғы жауапқа емес, оған жеткен жолға да қараңыз:

• қажетті фрагмент reranker-ге дейін top-k-қа кірді ме
• reranker оны жоғары көтерді ме
• қажетті абзацтың рангі жақсарды ма
• сөздері ұқсас, бірақ жалған фрагменттер жоғалды ма

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

Нақты қателерді талдау пайдалы. Мысалы, ереже бір абзацта, ал ерекшелік келесі абзацта тұрсын. Тым ұсақ фрагменттерде іздеу көбіне ережені табады да, ерекшелікті жоғалтады. Мұнда reranker дәрменсіз, егер екінші бөлік кандидаттар арасында болмаса. Ал орташалау қабаттасу кезінде екі фрагмент те нәтижеге түседі, сонда reranker қажеттісін жоғары көтере алады.

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

Тестті қадамдап өткізу жолы

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

1. Әр бөлу нұсқасы үшін бөлек индекс жасаңыз. Мысалы, бірі — 400 токендік, қабаттасусыз фрагменттерге, екіншісі — 800 токендік, 100 токен қабаттасуы бар фрагменттерге, үшіншісі — 1200 токендік, 200 токен қабаттасуы бар нұсқаға. Оларды бір сақтау орнында араластырмаңыз.

2. Прогон шарттарын бекітіңіз. Сұрақтар жиыны, top-k, embedding моделі, reranker немесе оның жоқтығы барлық нұсқа үшін бірдей болуы керек.

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

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

5. Дәл осындай прогонды қалған нұсқалар үшін қайталап, нәтижелерді бір кестеге түсіріңіз. Әр жол — бір конфигурация: фрагмент өлшемі, қабаттасу, reranking қосулы ма, жоқ па. Бағандарда hit@k, дұрыс фрагмент табылған сұрақтар үлесі, уақыт және баға болсын.

Мұндай кестеден кейін дау әдетте күрт қысқарады. «Маған 1000 токен жақсы сияқты» дегеннің орнына нақты сурет пайда болады. Мысалы, 800/100 1200/200 сияқты іздеуді береді, бірақ тезірек жауап береді және арзанырақ шығады. Бұл бір-екі көшбасшыны таңдап, келесі тестке толық RAG жауабымен жіберуге жеткілікті.

Ішкі білім базасындағы мысал

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

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

Бірдей құжаттар жиынында кемінде екі бөлу нұсқасын жасаңыз. Мысалы, 250–350 токендік қысқа фрагменттерді аздап қабаттастырып және 700–1000 токендік ұзын фрагменттерді бірдей embedding-пен салыстырыңыз. Top-k те, сұрақтар жиыны да бірдей болуы керек.

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

Одан кейін reranking-ті қосып, сол кейсті қайталаңыз. Жақсы reranker «Қайтару саясаты» деген бөлімді тұтас көтеріп қоймай, нақты мына нәрсе айтылған абзацты жоғары шығарады: расталған ақау болса, 14 күндік мерзім қолданылмайды немесе басқаша есептеледі. Егер reranking-тен кейін де үстінде жалпы бөлім тұрса, ал нақты абзац төменде қалса — мәселе шешілген жоқ.

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

Қорытындыны бұзатын қателер

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

Ең жиі қате — фрагмент өлшемімен бірге embedding, prompt, top-k немесе тіпті жауап моделін де өзгерту. Сонда жаңа бөлудің көмектескенін не басқа retriever ұтқанын айту мүмкін болмай қалады. Бір тест — бір айнымалы.

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

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

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

Жылдам сүзгі мынадай:

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

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

Тіпті 50–100 сұрақтың өзі шағын демо-жиыннан әлдеқайда әділ нәтиже береді. Мұндай тестке көбірек уақыт кетеді, бірақ кейін біреудің әсеріне қарай фрагмент өлшемін апта сайын өзгерте бермейсіз.

Таңдау алдында тез тексеру

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

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

Таңдау алдында мына төрт пунктті тексерген жөн:

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

Қабаттасу кезінде көбіне бірдей қателік жасалады: «сақтық үшін» оны үлкейте береді, кейін индекс ауырлап, жауаптардағы айырмашылық мардымсыз болып шығады. Егер 10–15% қабаттасу 30% деңгейімен бірдей нәтиже берсе, артық көлемнің керегі жоқ. Мағына тек фрагмент шекарасы бір ойды жиі қақ бөліп жіберетін жерде бар.

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

Тағы бір сүзгі. Команда неліктен дәл сол нұсқа жеңгенін түсінуі керек. Жай ғана «метрика жоғары болғандықтан» емес, мысалы, «фрагмент кесте мен түсіндірмені толық сақтайды» немесе «reranker ұқсас регламенттерді жақсы ажыратады» дегендей. Сонда бір айдан кейін жаңа деректермен тестті қайталап, бүкіл дауды қайта бастамайсыз.

Тесттен кейін не істеу керек

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

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

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

Содан кейін бірнеше ереже жеткілікті:

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

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

Егер сіз бірнеше модель мен reranker-ді салыстырып жатсаңыз, экспериментті бірдей ортада ұстаған пайдалы. Қазақстандағы командалар үшін бұл жұмысты жиі жеңілдетеді: мысалы, AI Router on airouter.kz бір OpenAI-үйлесімді endpoint береді, сондықтан провайдерлер мен модельдерді SDK-ны, кодты және prompt-тарды қайта жазбай-ақ ауыстыруға болады. Деректер сезімтал болса, тапсырманың басқа жағын да тексеру маңызды: ел ішінде сақтау, PII маскалау және аудит журналдары hit@k немесе кідіріс сияқты мұқият тексерілуі керек.

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