Глоссарий для доменного поиска: часто полезнее модели

В чем проблема без общего словаря

Без общего словаря поиск быстро теряет смысл запроса. В одной компании один и тот же объект называют по-разному: "договор", "контракт", "соглашение", "форма на подпись". Для человека это почти одно и то же. Для системы поиска - разные слова и разные пути к документам.

Из-за этого сотрудник часто находит не лучший материал, а тот, где случайно совпала формулировка. В базе знаний отдел продаж пишет "лид", юристы - "потенциальный клиент", поддержка - "новый аккаунт". Смысл рядом, но выдача получается неровной: один человек получает точный ответ, другой спрашивает почти о том же и не находит ничего полезного.

Отдельная проблема - аббревиатуры. Внутри компании они живут своей жизнью. Один отдел пишет полное название, другой давно сократил его до трех букв, третий использует старую версию. Поиск и модель не знают, что "ДМС", "добровольное медстрахование" и внутренний тег в HR-системе у вас значат одно и то же.

То же самое происходит с кодами, ролями и названиями продуктов. Для модели "P-214", "Кредит 2.0" или "роль куратор точки" - просто набор символов, если вы заранее не объяснили их смысл. Она достраивает значение по общим шаблонам языка. Для внутренней работы этого обычно мало.

Отсюда появляется эффект, который команды замечают не сразу: на один и тот же вопрос сотрудники получают разные ответы. Один спрашивает "лимит по SME", другой пишет "условия для МСБ", третий ищет по названию внутренней программы. Намерение одно, формулировки разные, а результаты расходятся.

Без словаря система выглядит умной только на простых запросах. Как только в ход идут внутренний жаргон, старые аббревиатуры или коды продуктов, качество RAG проседает. И дело обычно не в слабой модели. Чаще ей просто не дали словарь компании, на котором держится повседневная работа.

Что должно быть в корпоративном глоссарии

Хороший корпоративный словарь терминов - это не витрина "правильных слов" из презентации. Это карта того, как люди действительно пишут в письмах, заявках, регламентах, чатах и старых документах. Его задача проста: помочь поиску понять, где один смысл, а где разные сущности.

Одна запись обычно включает:

• основной термин;
• рабочие варианты, которые используют команды;
• сокращения и разговорные формы;
• коды, номера форм, тарифов, услуг и документов;
• короткую пометку, где термин уместен и с чем его не стоит смешивать.

Без этого поиск по внутренним данным быстро теряет точность. Сотрудник вводит "анкета KYC", в базе лежит "форма идентификации клиента", а в переписке кто-то пишет просто "опросник". Человек легко видит связь. Поиск без словаря - нет.

Особенно заметна польза там, где смешаны русский, английский и внутренний жаргон. В одной команде говорят "витрина", в другой "каталог", в третьей "product feed". Если это один объект, словарь должен связать их. Если это разные вещи, он должен развести их и коротко объяснить разницу.

Коды тоже нельзя игнорировать. Люди часто ищут не название, а "Ф-12", "ТП-3", "тариф 451" или старый номер приказа. Такие метки дают хороший прирост качества, потому что постоянно встречаются в Excel, шаблонах, сканах и тикетах.

Полезно отдельно хранить устаревшие и нежелательные формулировки. Старое название продукта, старый код формы или сленг одной команды все еще живут в архивах. Удалять их не надо. Лучше пометить, что искать по ним можно, но в ответе и в выдаче выше поднимать актуальный термин.

И еще один момент, который часто недооценивают: короткое пояснение. Буквально одна строка иногда спасает больше, чем тонкая настройка модели. Например, "лимит по карте" и "кредитный лимит" звучат похоже, но в конкретной компании это могут быть разные вещи.

Если запись нельзя показать новому сотруднику и он не поймет, когда использовать этот термин, запись еще не готова.

Почему словарь часто полезнее смены модели

Модель получает запрос слишком поздно. Если человек ищет "КДП", а в документах везде написано "кадровое делопроизводство", ошибка начинается еще до генерации ответа. Словарь снимает эту неоднозначность заранее: он приводит запрос и документы к одному языку.

Новая модель может писать аккуратнее, лучше держать контекст и реже путать общий смысл. Но внутренний язык компании она не угадает. Она не знает, что "пластик" в банке может значить банковскую карту, что "витрина" в ритейле - это не полка, а таблица в хранилище, а старую систему сотрудники до сих пор называют именем проекта пятилетней давности.

Поэтому смена модели часто дает скромный прирост, а словарь чинит сам источник путаницы. Когда поиск понимает, что "ДМС", "добровольное медстрахование" и внутренний код услуги означают одно и то же, он чаще находит нужные документы. RAG, то есть ответы на основе найденных документов, получает более точный контекст. Чат-бот реже задает лишние уточнения и меньше ошибается в терминах.

Один список терминов помогает сразу в нескольких местах: расширяет запрос с учетом синонимов и аббревиатур, нормализует названия в индексах и документах, подсказывает системе, какие фрагменты близки по смыслу, и делает ответы более единообразными.

У словаря есть еще одно практичное преимущество: его проще измерять. Команда добавила 40 терминов и через неделю посмотрела, стало ли меньше пустых результатов, выросла ли точность в первых ответах, сократилось ли число ручных уточнений. При смене модели картина обычно мутнее: на результат одновременно влияют промпты, формат контекста, температура и сама тестовая выборка.

По деньгам словарь тоже часто выигрывает. Поддерживать список терминов дешевле, чем постоянно мигрировать между моделями, повторять тесты и платить за лишние токены. Для банка, телекома, SaaS или внутренней базы знаний это довольно земной вывод: сначала договоритесь о словах, потом спорьте о модели.

Где словарь дает самый заметный эффект

Самый заметный прирост появляется там, где язык людей не совпадает с языком документов. Сотрудник пишет коротко и по-простому, а система хранит длинные официальные формулировки, старые названия и внутренние коды. Без словаря поиск промахивается уже на первом шаге.

Обычно это хорошо видно в базе знаний, инструкциях и регламентах. Человек ищет "отгул", а в документе написано "дополнительный день отдыха". Ищет "удаленку", а правило оформлено как "дистанционный режим работы". Смысл один, формулировки разные.

Вторая частая зона - продукты, тарифы и внутренние обозначения. В банке, телекоме или SaaS-команде сотрудники редко помнят точное имя услуги. Они пишут "старый премиум тариф для бизнеса" или вводят код, знакомый только части команды. Если словарь знает, что "B2B Pro 2024", "премиум для юрлиц" и код продукта относятся к одному объекту, система находит нужный документ быстрее.

Отдельно стоит эффект после переименований. После ребрендинга, слияния отделов или замены системы старые термины живут годами. Сотрудник ищет "CRM-2", хотя в новых документах продукт уже называется иначе. Или вводит старое имя отдела, которое исчезло из оргструктуры, но осталось в письмах и тикетах. Словарь склеивает такие версии в одну сущность и убирает лишний шум.

Хорошо словарь работает и там, где люди смешивают бытовые и официальные слова. Это обычная история в HR, финансах, закупках и поддержке. Врач пишет "история болезни", юрист - "медицинская документация", оператор ищет "карточку пациента". Иногда все трое имеют в виду один и тот же набор документов.

Есть простой способ быстро найти такие зоны. Если сотрудники часто переспрашивают название документа, если у одного продукта два или три рабочих имени, если в запросах полно нераскрытых аббревиатур и старых слов, значит словарь даст быстрый эффект.

Именно здесь качество RAG растет заметнее всего. Если поиск достал не тот фрагмент, даже сильная модель обычно просто увереннее перескажет ошибку.

Как собрать первую версию

Первая версия словаря не должна быть большой. Если пытаться сразу описать весь язык компании, работа встанет. Для старта лучше брать не абстрактные термины, а живые следы работы.

Начните с запросов, которые люди уже вводят. Выгрузите частые формулировки из внутреннего поиска, бота поддержки, корпоративных чатов и сервис-деска. Там быстро всплывают реальные сокращения, разговорные названия, старые коды продуктов, опечатки и местные привычки команд.

Потом доберите термины из документов, где язык уже закреплен: из инструкций, шаблонов писем, карточек CRM, названий полей в формах, регламентов и базы знаний. Так видно разницу между официальной формой и тем, как сотрудники ищут эту сущность в жизни.

Дальше сведите все в одну простую таблицу. Для каждой записи обычно хватает пяти полей:

1. основной термин;
2. синонимы и сокращения;
3. частые ошибочные варианты;
4. отдел или процесс, где слово используется;
5. короткое пояснение, если термин двусмысленный.

На этом этапе почти всегда всплывают дубли. В одной команде пишут "ДМС", в другой - "добровольное медстрахование", в документах стоит полное название. Для поиска это не три разных сущности, а одна запись с несколькими вариантами.

Спорные слова лучше не разбирать в одиночку. Отправьте короткий список владельцам процессов: продажам, поддержке, юристам, финансам, ИТ. Пусть они быстро пометят, какие термины равны, а какие смешивать нельзя. Один такой просмотр часто убирает ошибки, которые потом неделями портят поиск.

Первую итерацию не стоит растягивать. Обычно хватает 100-200 записей, если взять самые частые и самые болезненные случаи. После запуска смотрите, что люди ищут без результата, и раз в месяц обновляйте таблицу. Звучит скучно, но именно так словарь начинает приносить пользу.

Простой пример из компании

В банке сотрудник открывает внутренний поиск и пишет: "лимит по карте". Ему нужен точный ответ для клиента: где проходит граница по расходам, кто ее меняет и какие есть исключения. Но в регламенте нужный параметр давно записан как "кредитный порог", потому что так он назывался в старой системе.

Поиск без общего словаря часто не видит связь между этими словами. Он ищет почти буквальное совпадение и поднимает новости, памятки для колл-центра или общие инструкции по продукту. Нужный документ есть, но сотрудник до него не добирается. Дальше он тратит время на вопросы коллегам или отвечает клиенту по памяти. Это уже риск.

Словарь чинит ситуацию довольно просто. В нем фиксируют, что "лимит по карте" и "кредитный порог" в этой компании значат одно и то же. После этого поиск связывает оба выражения и поднимает нужный документ выше. Менять модель ради такого случая часто не нужно.

Тот же механизм помогает чат-боту. Сотрудник спрашивает: "Какой лимит по карте можно поднять без ручного согласования?" Бот ищет по внутренним данным, находит раздел про "кредитный порог" и отвечает по регламенту, а не по догадке. Ответ получается короче, точнее и спокойнее.

На практике таких пар много: старый термин из учетной системы, привычное слово бизнеса, разговорное название у сотрудников. Корпоративный словарь убирает этот разрыв. Иногда один такой слой дает больший эффект, чем переход на новую модель, потому что он исправляет не стиль ответа, а путь к нужному документу.

Как встроить словарь в поиск

Словарь должен работать на входе. Сначала система приводит запрос к принятой форме и только потом запускает полнотекстовый поиск, векторный поиск или RAG. Если нормализовать слова после ответа, нужные документы уже могли не попасть в выборку.

Пример простой: сотрудник пишет "ДБО для юрлиц", а в документах везде стоит "дистанционное банковское обслуживание". Если поиск увидит только исходную аббревиатуру, он пропустит часть подходящих фрагментов. Если сначала развернуть сокращение и добавить принятую форму, шанс найти нужный текст заметно выше.

Обычно процесс выглядит так: система принимает исходный запрос, заменяет сокращения, опечатки и локальные названия на канонические формы, добавляет близкие синонимы с разным весом и только потом отправляет нормализованный запрос в поиск.

Важно, что не все синонимы равны. Один вариант почти точно совпадает со смыслом, другой лишь частично. Поэтому словарь лучше хранить не как простой список, а как набор соответствий с весами. Тогда "ЭЦП" и "электронная цифровая подпись" можно считать почти полным совпадением, а более широкие или разговорные формы ослаблять, чтобы они не уводили выдачу в сторону.

Что передавать дальше

Нормализованный запрос должен идти в тот же контур, где вы строите ответ и считаете метрики. Если RAG получает одну формулировку, а отчеты по качеству смотрят на другую, команда видит искаженную картину.

Полезно сохранять обе версии запроса: исходную и нормализованную. Исходная показывает, как люди реально пишут. Нормализованная помогает понять, какой эффект дал словарь и какие замены работают плохо.

Для команд, которые параллельно проверяют несколько моделей, это особенно важно. Модель можно сменить быстро, но если поиск не поднял нужный контекст, сильная LLM не исправит пропуск.

Ошибки, которые ломают результат

Плохой поиск чаще ломает не модель, а сам словарь. Команда меняет промпт, крутит rerank, тестирует новую LLM, а документы по-прежнему находятся мимо запроса. Ответ выглядит гладким, но опирается не на те источники.

Первая частая ошибка - собирать термины без владельца и даты обновления. Тогда в словаре месяцами живут старые названия продуктов, отмененные аббревиатуры и локальные сокращения одной команды. Через полгода уже никто не помнит, зачем запись добавили, а поиск тащит лишние документы.

Вторая ошибка - смешивать название продукта и обычное слово в одной записи. Если внутренний сервис называется "Витрина", нельзя приравнивать его ко всем бытовым случаям слова "витрина". Иначе выдача начнет подмешивать документы не про сервис, а про отчеты, интерфейсы и описания экранов.

Третья ошибка - добавлять слишком много равных синонимов. На бумаге это выглядит аккуратно, но в работе разные слова часто означают соседние, а не одинаковые вещи. Если без оговорок приравнять "карточку клиента", "профиль клиента" и "анкету клиента", система начнет расширять запросы слишком широко.

Еще одна проблема - игнорировать опечатки, формы слов и привычку писать по-разному. Пользователь вводит аббревиатуру, старое название, множественное число или слово без одной буквы. Если словарь знает только идеальную форму, поиск пропускает нужный документ.

И самая дорогая ошибка - пытаться чинить ответ моделью, а не данными поиска. Если retriever не нашел нужный документ, сильная модель не угадает внутренний термин из воздуха.

Чтобы словарь жил дольше и меньше шумел, в каждой записи полезно держать пять вещей: основной термин, допустимые варианты и аббревиатуры, конфликтные значения или слова-исключения, владельца записи и дату последней проверки.

Проверки перед запуском

Перед запуском лучше прогнать поиск на реальных запросах из чатов, тикетов и почты. Не на красивых примерах, а на том, как люди пишут каждый день.

Если словарь собран нормально, это видно сразу. Пользователь вводит привычный запрос и находит нужный документ без второй попытки. Если ему приходится переписывать фразу, раскрывать аббревиатуру или угадывать официальное название, словарь еще сырой.

Хватает нескольких простых проверок. Возьмите 20 частых запросов и посмотрите, открывается ли нужный документ сразу. Сравните выдачу по аббревиатуре и по полному названию. Проверьте старые названия продуктов, команд и процессов. Разберите спорные слова с двумя смыслами. И попросите двух-трех коллег добавить новый термин без вашей помощи: если они не понимают, куда писать и кто это утверждает, словарь быстро устареет.

Полезно смотреть не только на успех, но и на тип ошибки. Если поиск выдает почти правильный документ, часто хватает одного синонима. Если промах полный, значит термин привязан не туда или в словаре нет старого имени.

Такого мини-теста обычно достаточно, чтобы поймать самые дорогие сбои до релиза. Один вечер проверки часто дает больше пользы, чем еще одна неделя споров о модели.

Что делать дальше

После первой версии не пытайтесь охватить всю компанию сразу. Возьмите один процесс, где поиск влияет на работу каждый день: ответы поддержки, поиск по регламентам, закупки или внутреннюю базу знаний.

Дальше проверьте систему на живых запросах. Соберите 30-50 формулировок от сотрудников, которые реально ищут документы, инструкции или карточки клиентов. В такой выборке быстро всплывают старые названия, внутренние сокращения и слова, которые люди пишут по-разному.

Дальше все довольно приземленно: зафиксируйте текущий результат, добавьте термины и нежелательные замены, прогоните ту же выборку еще раз и сравните. Смотрите на простые метрики: сколько запросов нашли нужный документ, появился ли правильный ответ в топ-3, стало ли меньше пустых выдач и странных совпадений.

Потом нужен короткий регламент. Достаточно трех правил: кто может предлагать новый термин, кто его утверждает и как часто команда пересматривает спорные замены. Если слово меняет смысл в разных отделах, не склеивайте его насильно. Лучше хранить два варианта с пометкой контекста.

Рабочий ритм тоже простой: раз в неделю разбирать новые запросы без результата и раз в месяц чистить дубли. Это занимает немного времени, но держит поиск в рабочем состоянии.

Если команда параллельно тестирует несколько LLM, удобно держать маршрутизацию и проверку качества в одном слое. Например, AI Router на airouter.kz дает единый OpenAI-совместимый эндпоинт, поэтому одну и ту же выборку можно прогонять через разные модели без переписывания SDK, кода и промптов. Но даже в таком сценарии словарь остается базой: если поиск не нашел нужный контекст, менять модель уже поздно.

Если после этого словарь все еще не помогает, проблема часто не в терминах, а в самих данных: в плохих названиях документов, лишних копиях, битых полях или слабой разбивке на чанки. Тогда чинить нужно уже индекс и контент, а не список слов.