Орысша және қазақша іздеу: эмбеддингтер мен нормализация

Неге аралас сұрау жиі нашар нәтиже береді

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

Мысалы, қызметкер: "Как открыть счет для ИП, если клиент уже тіркелген?" деп сұрайды. Орысша бөлігі тақырыпты береді, қазақша сөз контекстті өзгертеді, ал "ИП" термині нақтылау енгізеді. Егер индекс пен нормализация бұған дайын болмаса, жүйе таныс бөліктерге жабысып, жалпы мағынаны жоғалтады.

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

Әдетте ақау былай көрінеді: іздеу ұқсас сөзді ұстайды, бірақ дұрыс сценарийді емес; орысша термин орысша құжатты табады, ал сұрақтың қазақша бөлігі еленбей қалады; "schet ashu" сияқты транслит матчингтен түсіп қалады; сөйлесу формасы сұрауды жиі кездесетін, бірақ пайдасыз жауаптарға бұрып жібереді.

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

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

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

Модель таңдауға дейін білім базасында нені тексеру керек

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

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

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

Құжаттардың құрылымын да тексеріңіз. Кестелер, скандар, OCR-дан өткен PDF және ескі CMS мәтінді көзге көрінгеннен де қатты бұзады. Таза HTML-дегі және қате танылған PDF-дегі бірдей сөйлем — индекстегі екі бөлек объект. Осы шуды алдын ала алып тастамасаңыз, модель таңдаудың пайдасы аз болады.

Екі тілге арналған эмбеддингті қалай таңдау керек

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

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

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

Бірден үш көрсеткішке қараңыз: алғашқы 5 нәтижеге дәл түсу үлесі, индекстеу мен қайта индекстеу құны және жаппай іздеу кезіндегі кідіріс. Топ-5 көбіне топ-1-ден маңыздырақ. Пайдаланушы бәрібір бірнеше кандидат көреді, кейін оларды reranker немесе LLM толықтырады. Егер бір модель топ-5-те 78% дәлдік берсе, ал екіншісі 72% болса, айырмашылық сезіледі. Бірақ бірінші нұсқа үш есе қымбат әрі айтарлықтай баяу болса, таңдау сонша анық емес.

Кіші базаға он нұсқаны сынаудың қажеті жоқ. Әдетте 2–3 кандидат жеткілікті: бір мықты мультиязиялы модель, бір арзандау нұсқа және егер сіз үшін деректердің Қазақстан ішінде сақталуы маңызды болса, ыңғайлы орналастыруы бар бір модель. Осындай жиын модельдің аралас сұрауларды шынымен түсінетінін немесе тек демода жақсы көрінетінін тез көрсетеді.

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

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

Мәтінді артық шығынсыз қалай нормализациялауға болады

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

Алдымен барлық құжат пен сұрауға бір регистр формасын таңдаңыз. Әдетте кіші әріп жеткілікті. Осылайша "Кредит", "кредит" және "КРЕДИТ" арасындағы артық айырманы алып тастайсыз, бірақ мағынаны өзгертпейсіз.

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

Нені бұзбаған дұрыс

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

Жұмыс істейтін ымыра әдетте мынадай:

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

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

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

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

Іздеуді қадамдап қалай баптау керек

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

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

Келесі жұмыс реті пайдалы:

1. Базалық іздеуді жаңа ережелерсіз іске қосып, нәтижені сақтаңыз.
2. Әр сұрау үшін дұрыс құжат алғашқы 3 және алғашқы 10 нәтиженің ішінде бар ма, соны белгілеңіз.
3. Бір нормализация ережесін қосыңыз, мысалы регистрді теңестіру немесе қазақ сөздеріндегі әртүрлі апострофтарды біріздендіру.
4. Іздеуді сол сұрақтар жинағында қайта өткізіңіз.
5. Top-3 пен Top-10-да не өзгергенін салыстырыңыз.

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

Тек нәтижелер санын емес, қателердің сипатын да қараңыз. Кейде керек құжат Top-10 ішінде қалады, бірақ 2-орыннан 9-орынға түседі. Пайдаланушы үшін бұл іс жүзінде промахқа тең. Сондықтан сапаны екі қырынан бағалаған дұрыс: адам бірден не көреді және жүйе жалпы не тапты.

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

Білім базасынан мысал

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

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

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

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

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

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

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

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

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

Командалар жиі қай жерде қателеседі

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

Нәтижені бұзатын нәрселер

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

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

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

Сандар, қысқартулар және өнім атаулары бөлек зардап шегеді. Іздеу "лимит по карте"-ні жақсы түсініп, бірақ "лимит по Gold", "IBAN", "KZT", "3DS" немесе тарифтің ішкі атауында қиналуы мүмкін. Банк, телеком немесе SaaS үшін бұл — қалыпты сұрау түрі. Мұндай токендерді нұсқалар сөздігіне жинап, бөлек тексерген дұрыс.

Эксперименттегі қате

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

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

Іске қоспас бұрын жылдам тексеру

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

Тазартылған мысалдарды емес, чаттардан, тикеттен және хаттардан алынған тірі формулировкаларды алыңыз. Пайдаланушы сирек мінсіз жазады. Ол "лимит по карте в тенге", "кредитті мерзімінен бұрын жабу" деп сұрауы немесе екі тілді бір фразада араластыруы мүмкін.

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

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

Іске қосар алдында мына нәрселерді тексеру ыңғайлы:

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

Барлығын бір ортақ санға жинамаңыз. Жалпы Recall@5 немесе MRR қалыпты көрінуі мүмкін, бірақ аралас сұраулар құлап жатса. Метрикаларды әр топ бойынша бөлек қараған дұрыс. Егер орысша 82%, қазақша 79%, ал аралас сұраулар 54% болса, мәселе анық көрінеді.

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

Жақсы іске қосу жалықтырарлық көрінеді: түсінікті тест, қарапайым ережелер, қателерді автоматты жинау. Осы болмаса, іздеу демода емес, жұмыс чатында-ақ бұзылады.

Пилоттан кейін не істеу керек

Пилоттан кейін бірден барлық құжат пен барлық команданы қоспаған дұрыс. Алдымен уақыт жағынан қымбат қателік беретін бір тірі сценарийді таңдаңыз: клиенттік FAQ, қолдау базасы немесе қызметкерлерге арналған ішкі ережелер.

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

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

2-3 аптадан кейін мұндай тізім қайталанатын ақауларды міндетті түрде көрсетеді. Әдетте бұл — бір сұрақта тілдердің араласуы, бір терминнің әртүрлі формалары, мәтінді артық тазалау немесе білім базасындағы қазақша формулировкалардың әлсіз қамтылуы.

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

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

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

Егер команда қатарынан бірнеше LLM-ді RAG-жауаптар үшін салыстырып, деректерді Қазақстанда сақтағысы келсе, мұндай тестілерге бір OpenAI-compatible API қабаты ретінде AI Router-ды бөлек қолдануға болады. Ол нашар нормализацияны да, әлсіз эмбеддингтерді де түземейді, бірақ модельдерді бір эндпоинт арқылы салыстыруды жеңілдетеді және әр провайдерге интеграцияны қайта жазудан сақтайды.

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