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

Ортақ сөздік болмаса қандай мәселе туады
Ортақ сөздік болмаса, іздеу сұраныстың мәнін тез жоғалтады. Бір компанияда бір объектіні әртүрлі атайды: «договор», «контракт», «келісім», «қол қоюға арналған форма». Адам үшін бұлар бір нәрсеге жақын. Ал іздеу жүйесі үшін — әртүрлі сөз және құжатқа апаратын әртүрлі жол.
Осының салдарынан қызметкер көбіне ең жақсы материалды емес, кездейсоқ формулировкасы сәйкес келген құжатты табады. Білім базасында сату бөлімі «лид» деп жазады, заңгерлер — «әлеуетті клиент», қолдау қызметі — «жаңа аккаунт» дейді. Мағынасы жақын, бірақ нәтиже біркелкі шықпайды: бір адам дәл жауап алады, ал екіншісі соған ұқсас сұрақ қойып, пайдалы ештеңе таппайды.
Жеке мәселе — қысқартулар. Компания ішінде олар өз өмірімен жүреді. Бір бөлім толық атауын жазады, екіншісі оны үш әріпке дейін қысқартып қойған, үшіншісі ескі нұсқаны қолданады. Іздеу де, модель де «ДМС», «еркін медициналық сақтандыру» және HR жүйесіндегі ішкі тег сізде бір мағынаны білдіретінін білмейді.
Сол сияқты кодтармен, рөлдермен және өнім атауларымен де болады. Модель үшін «P-214», «Кредит 2.0» немесе «нүкте кураторы» рөлі — егер сіз олардың мәнін алдын ала түсіндірмесеңіз, жай ғана таңбалар жиыны. Ол мағынаны тілдің жалпы үлгілері арқылы толықтырады. Ішкі жұмыс үшін бұл көбіне жеткіліксіз.
Содан бір әсер пайда болады, оны командалар бірден байқамайды: бір сұраққа қызметкерлер әртүрлі жауап алады. Біреу «SME лимиті» деп сұрайды, біреу «ШОБ шарттары» деп жазады, үшіншісі ішкі бағдарламаның атымен іздейді. Ниет бір, формулировкалар әртүрлі, ал нәтиже шашыраңқы.
Сөздік болмаса, жүйе тек қарапайым сұраныстарда ғана ақылды көрінеді. Ішкі жаргон, ескі қысқартулар немесе өнім кодтары қосылған сәтте RAG сапасы төмендейді. Көбіне мәселе модельдің әлсіздігінде емес. Оған күнделікті жұмыстың негізі болатын компания сөздігі берілмеген.
Корпоративтік глоссарийде не болуы керек
Жақсы корпоративтік терминдер сөздігі — презентациядағы «дұрыс сөздердің» көрмесі емес. Бұл адамдардың хаттарда, өтінімдерде, регламенттерде, чаттарда және ескі құжаттарда шын мәнінде қалай жазатынын көрсететін карта. Оның міндеті қарапайым: іздеуге бір мағына қай жерде, ал қай жерде бөлек нысандар бар екенін түсінуге көмектесу.
Бір жазбада әдетте мыналар болады:
- негізгі термин;
- командалар қолданатын жұмыс нұсқалары;
- қысқартулар мен сөйлеу тіліндегі формалар;
- кодтар, форма, тариф, қызмет және құжат нөмірлері;
- термин қай жерде орынды және немен шатастырмау керек екені туралы қысқа белгі.
Бұларсыз ішкі деректер бойынша іздеу тез-ақ дәлдігін жоғалтады. Қызметкер «KYC анкетасы» деп енгізеді, база ішінде «клиентті сәйкестендіру формасы» жатыр, ал хат алмасуда біреу жай ғана «сауалнама» деп жазады. Адам байланысын бірден көреді. Ал сөздіксіз іздеу — жоқ.
Әсіресе орысша, ағылшынша және ішкі жаргон араласқан жерде пайдасы анық көрінеді. Бір команда «витрина» дейді, екіншісі «каталог», үшіншісі product feed дейді. Егер бұл бір нысан болса, сөздік оларды байланыстыруы керек. Егер бөлек нәрсе болса, керісінше ажыратып, қысқаша айырмасын түсіндіруі керек.
Кодтарды да елемеуге болмайды. Адамдар жиі атауды емес, «Ф-12», «ТП-3», «тариф 451» немесе бұған дейінгі бұйрық нөмірін іздейді. Мұндай белгілер сапаны жақсы көтереді, өйткені олар Excel-де, шаблондарда, скандарда және тикеттерде жиі кездеседі.
Ескірген және қолданбаған формулировкаларды бөлек сақтау пайдалы. Өнімнің ескі атауы, форманың ескі коды немесе бір команданың сленгі архивтерде әлі де өмір сүріп жатады. Оларды өшірудің қажеті жоқ. «Іздеуге болады, бірақ жауапта және нәтижеде негізгі термин жоғарырақ шығуы керек» деп белгілеген дұрыс.
Тағы бір жиі бағаланбайтын нәрсе — қысқа түсіндірме. Бір-ақ жол кейде модельді нәзік баптаудан да көп көмектеседі. Мысалы, «карта лимиті» мен «несие лимиті» ұқсас естіледі, бірақ нақты компанияда олар бөлек нәрсе болуы мүмкін.
Жазбаны жаңа қызметкерге көрсеткенде ол бұл терминді қашан қолдану керегін түсінбесе, жазба әлі дайын емес.
Неге сөздік модельді ауыстырғаннан пайдалырақ болады
Модель сұранысты тым кеш алады. Егер адам «КДП» деп іздесе, ал құжаттарда бәрі «кадрлық іс жүргізу» деп жазылса, қате жауап қалыптасудан бұрын басталады. Сөздік бұл екіұштылықты алдын ала алып тастайды: ол сұраныс пен құжаттарды бір тілге келтіреді.
Жаңа модель анағұрлым ұқыпты жаза алады, контексті жақсы ұстайды және жалпы мағынаны сирек шатастырады. Бірақ компанияның ішкі тілін ол өздігінен таба алмайды. Ол банк ішінде «пластик» банктік карта дегенді білдіретінін, ритейлдегі «витрина» сөзі сөре емес, деректер қоймасындағы кесте екенін, ал ескі жүйені қызметкерлер бес жыл бұрынғы жобаның атымен атай беретінін білмейді.
Сондықтан модельді ауыстыру жиі аз ғана өсім береді, ал сөздік шатасудың түпкі себебін жөндейді. Іздеу «ДМС», «еркін медициналық сақтандыру» және қызметтің ішкі коды бір нәрсе екенін түсінгенде, керекті құжаттарды жиірек табады. RAG, яғни табылған құжаттарға сүйенетін жауаптар, анағұрлым дәл контекст алады. Чат-бот артық нақтылауды аз сұрайды және терминдерді аз шатастырады.
Бір терминдер тізімі бірнеше жерде бірден көмектеседі: сұранысты синонимдер мен қысқартуларды ескере отырып кеңейтеді, индекстер мен құжаттардағы атауларды қалыпқа келтіреді, жүйеге қай бөліктер мағына жағынан жақын екенін ескертеді және жауаптарды бірізді етеді.
Сөздіктің тағы бір практикалық артықшылығы бар: оны өлшеу жеңіл. Команда 40 термин қосты да, бір аптадан соң бос нәтижелер азайды ма, алғашқы жауаптардағы дәлдік өсті ме, қолмен нақтылау саны қысқарды ма — соны қарап шығады. Модельді ауыстырғанда сурет бұлыңғырлау болады: нәтижеге бір уақытта prompt-тар, контекст форматы, температура және тест үлгісінің өзі әсер етеді.
Ақша жағынан да сөздік жиі ұтады. Терминдер тізімін қолдап отыру модельдер арасында қайта-қайта көшу, тестті қайталау және артық token үшін төлеуден арзанырақ. Банк, телеком, SaaS немесе ішкі білім базасы үшін бұл өте қарапайым тұжырым: алдымен сөзге келісіп алыңыз, содан кейін модель туралы таласыңыз.
Сөздік ең күшті әсерді қай жерде береді
Ең үлкен өсім адамдардың тілі құжаттар тілімен сәйкес келмейтін жерде байқалады. Қызметкер қысқа әрі жеңіл жазады, ал жүйе ұзақ ресми формулировкаларды, ескі атауларды және ішкі кодтарды сақтайды. Сөздіксіз іздеу бірінші қадамда-ақ қателеседі.
Бұл көбіне білім базасында, нұсқаулықтарда және регламенттерде жақсы көрінеді. Адам «отгул» деп іздейді, ал құжатта «қосымша демалыс күні» деп жазылған. «Удаленка» деп сұрайды, ал ереже «қашықтан жұмыс режимі» деп рәсімделген. Мағына бір, формулировка бөлек.
Екінші жиі аймақ — өнімдер, тарифтер және ішкі белгілеулер. Банк, телеком немесе SaaS-командада қызметкерлер қызметтің дәл атын сирек есінде ұстайды. Олар «бизнеске арналған ескі премиум тариф» деп жазады немесе команданың бір бөлігі ғана білетін кодты енгізеді. Егер сөздік «B2B Pro 2024», «заңды тұлғаларға арналған премиум» және өнім коды бір объектіге қатысты екенін білсе, жүйе керек құжатты тез табады.
Атау өзгергеннен кейінгі әсерді де бөлек айту керек. Ребрендингтен, бөлімдердің қосылуынан немесе жүйені ауыстырудан кейін ескі терминдер жылдар бойы өмір сүре береді. Қызметкер «CRM-2» деп іздейді, ал жаңа құжаттарда өнім басқаша аталады. Немесе оргқұрылымнан кеткен бөлімнің ескі атын енгізеді, бірақ ол хаттар мен тикеттерде әлі сақталған. Сөздік мұндай нұсқаларды бір нысанға біріктіріп, артық шуды алып тастайды.
Сөздік адамдар тұрмыстық және ресми сөздерді араластырған жерде де жақсы жұмыс істейді. Бұл HR, қаржы, сатып алу және қолдау саласында жиі болады. Дәрігер «ауру тарихы» дейді, заңгер — «медициналық құжаттама», оператор «пациент картасы» деп іздейді. Кейде үшеуі де бір құжаттар жиынтығын меңзейді.
Мұндай аймақтарды табудың қарапайым жолы бар. Егер қызметкерлер құжат атауын жиі қайта сұрай берсе, егер бір өнімнің екі не үш жұмыс атауы болса, егер сұраныстарда ашылмаған қысқартулар мен ескі сөздер көп болса, демек сөздік тез нәтиже береді.
RAG сапасы дәл осы жерде ерекше өседі. Егер іздеу дұрыс емес үзіндіні алып келсе, күшті модель де көбіне қатені сенімдірек баяндап қояды.
Алғашқы нұсқаны қалай жинау керек
Сөздіктің бірінші нұсқасы үлкен болмауы керек. Егер бірден компания тілінің бәрін сипаттауға тырыссаңыз, жұмыс тұрып қалады. Бастау үшін абстрактілі терминдерді емес, жұмыстың тірі іздерін алу дұрыс.
Алдымен адамдар енгізіп жүрген сұраныстардан бастаңыз. Ішкі іздеуден, қолдау ботынан, корпоративтік чаттардан және service desk-тен жиі кездесетін формулировкаларды шығарып алыңыз. Сол жерден шынайы қысқартулар, ауызекі атаулар, ескі өнім кодтары, қателер және командалардың жергілікті әдеттері тез көрінеді.
Сосын тілі бекіп қалған құжаттардан терминдерді қосыңыз: нұсқаулықтардан, хат үлгілерінен, CRM карточкаларынан, формалардағы өріс атауларынан, регламенттерден және білім базасынан. Осылайша ресми форма мен қызметкерлер күнделікті іздейтін нысанның айырмасы көрінеді.
Кейін бәрін бір қарапайым кестеге жинаңыз. Әр жазба үшін әдетте бес өріс жеткілікті:
- негізгі термин;
- синонимдер мен қысқартулар;
- жиі қате жазылатын нұсқалар;
- сөз қолданылатын бөлім немесе процесс;
- егер термин екіұшты болса, қысқа түсініктеме.
Осы кезеңде дубликаттар әдетте көп шығады. Бір команда «ДМС» деп жазады, екіншісі — «еркін медициналық сақтандыру», құжаттарда толық атауы тұрады. Іздеу үшін бұлар үш бөлек нысан емес, бірнеше нұсқасы бар бір жазба.
Даулы сөздерді жеке отырып шешпеген дұрыс. Қысқа тізімді процесс иелеріне жіберіңіз: сату, қолдау, заң, қаржы, IT. Олар қай терминдер тең, ал қайсысын араластыруға болмайтынын тез белгілесін. Осындай бір шолу кейін апталап іздеуді бұзатын қатені жиі жояды.
Алғашқы итерацияны соза берудің қажеті жоқ. Әдетте ең жиі және ең ауыр жағдайларды алсаңыз, 100-200 жазбаның өзі жеткілікті. Іске қосқаннан кейін адамдар нәтижесіз не іздеп жүргенін қарап, айына бір рет кестені жаңартып отырыңыз. Естілгенімен іш пыстырарлық, бірақ сөздік дәл осылай пайда әкеледі.
Компаниядан алынған қарапайым мысал
Банк ішінде қызметкер ішкі іздеуді ашып, «карта лимиті» деп жазады. Оған клиентке нақты жауап керек: шығындардың шегі қайда, оны кім өзгертеді және қандай ерекшеліктер бар. Бірақ регламентте қажет параметр баяғыдан «несиелік шек» деп жазылған, өйткені ол ескі жүйеде солай аталған.
Ортақ сөздігі жоқ іздеу бұл сөздердің байланысын жиі көрмейді. Ол дерлік тура сәйкестікті іздеп, жаңалықтарды, колл-орталыққа арналған жадынамаларды немесе өнім бойынша жалпы нұсқаулықтарды шығарады. Керек құжат бар, бірақ қызметкер соған жетпейді. Сосын ол әріптестерінен сұрап уақыт жоғалтады немесе клиентке есте сақтауына сүйеніп жауап береді. Бұл — тәуекел.
Сөздік бұл жағдайды қарапайым шешеді. Онда «карта лимиті» мен «несиелік шек» осы компанияда бір нәрсені білдіретіні бекітіледі. Содан кейін іздеу екі тіркесті байланыстырып, керекті құжатты жоғарырақ шығарады. Мұндай жағдай үшін модельді ауыстыру көбіне қажет емес.
Дәл сол механизм чат-ботқа да көмектеседі. Қызметкер: «Қай карта лимитін қолмен келісімсіз көтеруге болады?» — деп сұрайды. Бот ішкі деректерден іздеп, «несиелік шек» туралы бөлімді табады да, болжаммен емес, регламент бойынша жауап береді. Жауап қысқарақ, дәлірек және сенімдірек болады.
Тәжірибеде мұндай жұптар көп: есеп жүйесінен қалған ескі термин, бизнестің үйреншікті сөзі, қызметкерлер арасындағы ауызекі атау. Корпоративтік сөздік осы аралықты жояды. Кейде осындай бір ғана қабат жаңа модельге өтуден де көбірек әсер береді, өйткені ол жауап стилін емес, керекті құжатқа апарар жолды түзетеді.
Сөздікті іздеуге қалай енгізу керек
Сөздік кіріс жағында жұмыс істеуі керек. Алдымен жүйе сұранысты қабылданған формаға келтіреді, содан кейін ғана толықмәтінді іздеуді, векторлық іздеуді немесе RAG-ті іске қосады. Егер сөздерді жауаптан кейін қалыпқа келтірсеңіз, керекті құжаттар таңдауға мүлде түспей қалуы мүмкін.
Қарапайым мысал: қызметкер «ДБО для юрлиц» деп жазады, ал құжаттарда бәрі «қашықтан банктік қызмет көрсету» деп тұр. Егер іздеу тек бастапқы қысқартуды көрсе, сәйкес үзінділердің бір бөлігін жіберіп алады. Егер алдымен қысқартуды ашып, қабылданған форманы қоссаңыз, керекті мәтінді табу ықтималдығы әлдеқайда жоғары.
Әдетте процесс былай көрінеді: жүйе бастапқы сұранысты қабылдайды, қысқартуларды, қателерді және жергілікті атауларды канондық формаға ауыстырады, жақын синонимдерді әртүрлі салмақпен қосады да, содан кейін ғана нормаланған сұранысты іздеуге жібереді.
Маңыздысы — барлық синоним бірдей емес. Бір нұсқа мағынамен дерлік толық сәйкеседі, екіншісі тек ішінара жақын. Сондықтан сөздікті жай тізім ретінде емес, салмақтары бар сәйкестіктер жиыны ретінде сақтау жақсы. Сонда «ЭЦП» мен «электрондық цифрлық қолтаңба» толық дерлік сәйкестік ретінде қаралады, ал кеңірек немесе ауызекі формалар нәтижені артық бұрмаламайтындай әлсіретіледі.
Кейін не жіберу керек
Нормаланған сұраныс жауап құрастырылатын және метрика есептелетін сол бір контурға түсуі керек. Егер RAG бір формулировка алып, ал сапа есептері басқа форманы қарап отырса, команда бұрмаланған көрініс көреді.
Сұраныстың екі нұсқасын да сақтаған пайдалы: бастапқысын және нормаланғанын. Бастапқысы адамдардың шын мәнінде қалай жазатынын көрсетеді. Нормаланғаны сөздіктің қандай әсер бергенін және қай ауыстырулардың нашар жұмыс істейтінін түсінуге көмектеседі.
Бірнеше модельді қатар тексеретін командалар үшін бұл әсіресе маңызды. Модельді тез ауыстыруға болады, бірақ іздеу керек контексті көтеріп алмаса, күшті LLM ол олқылықты толтырмайды.
Нәтижені бұзатын қателер
Нашар іздеуді көбіне модель емес, сөздіктің өзі бұзады. Команда prompt-ты өзгертеді, rerank-ті бұрайды, жаңа LLM сынайды, ал құжаттар бәрібір сұранысқа дәл түспей қалады. Жауап жылтыр көрінеді, бірақ ол дұрыс дереккөзге сүйенбейді.
Бірінші жиі қате — терминдерді иесіз және жаңарту күнінсіз жинау. Сонда сөздікте айлар бойы өнімдердің ескі атаулары, күшін жойған қысқартулар және бір команданың жергілікті қысқартулары жата береді. Алты айдан кейін бұл жазбаның не үшін қосылғанын ешкім есіне түсірмейді, ал іздеу артық құжаттарды тарта береді.
Екінші қате — өнім атауы мен кәдімгі сөзді бір жазбада араластыру. Егер ішкі сервистің аты «Витрина» болса, оны «витрина» сөзінің барлық тұрмыстық жағдайымен теңестіруге болмайды. Әйтпесе нәтижеге сервиске қатысы жоқ құжаттар, есептер, интерфейстер және экран сипаттамалары араласа бастайды.
Үшінші қате — тым көп тең синоним қосу. Қағаз жүзінде бұл ұқыпты көрінеді, бірақ іс жүзінде әртүрлі сөздер көбіне дәл бірдей емес, көрші мағынаны білдіреді. Егер ескертусіз «клиент картасы», «клиент профилі» және «клиент анкетасы» теңестірілсе, жүйе сұранысты тым кеңейтіп жібереді.
Тағы бір мәселе — қате жазуларды, сөз тұлғаларын және әртүрлі жазу әдетін елемеу. Пайдаланушы қысқартуды, ескі атауды, көпше түрді немесе бір әрпі түсіп қалған сөзді енгізуі мүмкін. Егер сөздік тек мінсіз форманы білсе, іздеу керекті құжатты өткізіп алады.
Ең қымбат қате — жауапты модельмен емес, іздеу деректерімен түзетудің орнына модельге үміт арту. Егер retriever керекті құжатты таппаса, күшті LLM ішкі терминді ауада ойлап таба алмайды.
Сөздік ұзақ өмір сүруі және аз шу шығаруы үшін әр жазбада бес нәрсе болғаны жақсы: негізгі термин, рұқсат етілген нұсқалар мен қысқартулар, қайшылықты мағыналар немесе ерекшелік сөздер, жазбаның иесі және соңғы тексеру күні.
Іске қоспас бұрын тексерулер
Іске қоспас бұрын іздеуді чаттардан, тикеттерден және поштадан алынған шынайы сұраныстарда сынап көрген дұрыс. Әдемі мысалдарға емес, адамдар күнде қалай жазатынына қарап тексеріңіз.
Егер сөздік дұрыс жиналса, ол бірден көрінеді. Пайдаланушы үйреншікті сұранысты енгізеді де, керекті құжатты екінші ретсіз-ақ табады. Егер оған сөйлемді қайта жазу, қысқартуды ашу немесе ресми атауды болжау керек болса, сөздік әлі шикі.
Бірнеше қарапайым тексеріс жеткілікті. 20 жиі сұранысты алып, керекті құжат бірден ашыла ма, соны қараңыз. Қысқартумен және толық атаумен берілген нәтижені салыстырыңыз. Өнімдердің, командалардың және процестердің ескі атауларын тексеріңіз. Екі мағыналы даулы сөздерді талдаңыз. Және екі-үш әріптеске сіздің көмегіңізсіз жаңа термин қосуды сұраңыз: егер олар қайда жазу керек екенін және оны кім бекітетінін түсінбесе, сөздік тез ескіреді.
Тек сәттілікке емес, қате түріне де қараған пайдалы. Егер іздеу дерлік дұрыс құжатты берсе, көбіне бір синоним жетеді. Егер мүлде мүлт кетсе, термин қате жерге байланған немесе сөздікте ескі атау жоқ деген сөз.
Мұндай шағын тест релизге дейін ең қымбат бұзылыстарды ұстап қалуға әдетте жеткілікті. Бір кештік тексеріс модель туралы тағы бір апта таласқаннан да пайдалырақ болуы мүмкін.
Әрі қарай не істеу керек
Алғашқы нұсқадан кейін компанияны бірден түгел қамтуға тырыспаңыз. Күнде іздеу жұмысқа әсер ететін бір процесті алыңыз: қолдау жауаптары, регламент іздеу, сатып алу немесе ішкі білім базасы.
Содан кейін жүйені тірі сұраныстарда тексеріңіз. Құжаттарды, нұсқаулықтарды немесе клиент карточкаларын шынымен іздейтін қызметкерлерден 30-50 формулировка жинаңыз. Осындай таңдауда ескі атаулар, ішкі қысқартулар және адамдар әртүрлі жазатын сөздер тез шығады.
Одан әрі бәрі қарапайым: қазіргі нәтижені бекітіңіз, терминдер мен қажетсіз ауыстыруларды қосыңыз, сол таңдауды қайта өткізіп, салыстырыңыз. Қарапайым метрикаларға қараңыз: қанша сұраныс керекті құжатты тапты, дұрыс жауап алғашқы үштікке кірді ме, бос нәтижелер мен оғаш сәйкестіктер азайды ма.
Содан кейін қысқа регламент керек. Үш ереже жеткілікті: жаңа терминді кім ұсына алады, оны кім бекітеді және команда даулы ауыстыруларды қаншалық жиі қайта қарайды. Егер сөз әр бөлімде мағынаны өзгертсе, оны күшпен біріктірмеңіз. Оның орнына контекст белгісімен екі нұсқаны сақтаған дұрыс.
Жұмыс ырғағы да қарапайым: апта сайын нәтижесіз шыққан жаңа сұраныстарды талдап, ай сайын дубликаттарды тазалау. Бұл көп уақыт алмайды, бірақ іздеуді жұмыс күйінде ұстайды.
Егер команда қатарынан бірнеше LLM сынап жүрсе, маршрутизация мен сапа тексеруді бір қабатта ұстаған ыңғайлы. Мысалы, AI Router-дегі airouter.kz бір ғана OpenAI-үйлесімді endpoint береді, сондықтан бірдей таңдауды түрлі модельдерден SDK-ны, кодты және prompt-тарды қайта жазбай-ақ өткізуге болады. Бірақ мұндай сценарийде де сөздік база болып қала береді: іздеу керек контексті таппаса, модельді ауыстыру кеш болады.
Егер осыдан кейін де сөздік көмектеспесе, мәселе көбіне терминдерде емес, деректердің өзінде: құжат атаулары нашар, көшірмелер көп, өрістер бұзылған немесе chunk-тарға бөлу әлсіз. Онда енді сөздер тізімін емес, индекс пен контентті түзету керек.