Транслитерация в поиске: как учесть три варианта термина

Почему один термин превращается в несколько вариантов

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

Это начинается с обычного поведения. Пользователь не сразу переключает раскладку, забывает официальное написание или вообще его не знает. Он может искать "OpenRouter", "опенроутер" или "open router" и быть уверенным, что это один и тот же запрос.

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

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

Даже короткие названия быстро расползаются. "AI Router" в заметках может стать "аи роутер", "AI роутер" или "эйай роутер". Для человека разница небольшая. Для поиска по базе знаний это уже разные строки.

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

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

Где поиск теряет нужный ответ

Сбой обычно начинается не в статье, а в совпадении слов. В базе знаний материал может называться "OpenRouter API", а человек ищет "оупенроутер", "open router" или "опен роутер". Если поиск смотрит только на точное написание, он не понимает, что речь об одном и том же термине.

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

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

Старые статьи тоже создают шум. Раньше редакторы могли писать "Chat GPT", потом перейти на "ChatGPT", а в старых инструкциях оставить "чат гпт". В итоге один термин распадается на несколько изолированных вариантов, и каждая статья живет со своим написанием.

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

Для пользователя все выглядит просто. Он вводит знакомое слово, получает ноль результатов и закрывает вкладку. Он не думает про индекс, токены и нормализацию. Он видит пустую выдачу и решает, что база знаний слабая.

Это особенно неприятно в рабочих системах, где люди ищут ответ на ходу. Если инженер ищет статью по модели Qwen и пишет привычный для команды вариант, а поиск молчит, он не станет перебирать еще пять написаний. Он пойдет в чат, спросит коллегу или пропустит нужную инструкцию. Так один неучтенный вариант термина превращается в лишние вопросы и потерянное время.

Какие варианты стоит собирать заранее

Транслитерация в поиске редко сводится к паре вроде "router" и "роутер". Люди вводят термин так, как видели его в чате, в интерфейсе, в старой инструкции или в переписке с коллегой. Поэтому один и тот же смысл быстро распадается на несколько форм.

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

• разные алфавиты: "router" и "роутер", "API" и "апи";
• слитное и раздельное написание: "файнтюнинг", "файн тюнинг", "fine tuning";
• частые опечатки и пропуски букв, если они повторяются в реальных запросах;
• аббревиатуры и полные формы: "LLM" и "large language model", "база знаний" и "БЗ";
• старые и новые названия, если раздел или функция уже переименованы.

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

Если в базе знаний есть статья про маскирование PII, часть людей введет "PII", часть - "персональные данные", а кто-то напишет просто "пд". Для них это один смысл. Для индекса без нормализации это три разных запроса.

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

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

Как собрать словарь вариантов

Словарь лучше строить не из догадок, а из реальных запросов. Возьмите логи поиска за последний месяц и выберите частые запросы, которые относятся к одному термину, но выглядят по-разному. Обычно там быстро всплывают пары вроде "OpenRouter", "open router" и "оупенроутер" или "Qwen", "квен" и "qwen 3". Этого уже хватает, чтобы увидеть масштаб проблемы.

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

Что хранить в карточке

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

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

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

Как не дать словарю расползтись

Раз в квартал словарь полезно чистить. Удаляйте формы, которыми никто не пользуется, объединяйте дубли карточек и проверяйте, не появились ли новые официальные названия. Если термин устарел, не стирайте его сразу. Оставьте его как старую форму, чтобы поиск продолжал находить нужный материал.

Такой словарь редко бывает большим. Зато он быстро закрывает самые заметные промахи поиска и снижает число запросов, где пользователь "почти попал", но не дошел до ответа.

Как учесть варианты в индексе

Если пользователь ищет "Qwen 3", "Квен 3" или "qwen3", поиск должен вести к одной и той же статье. Для этого не нужно переписывать сам текст. Лучше держать отдельный слой нормализации и отдельные поля индекса.

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

Потом задайте понятные правила для кириллицы и латиницы. Не пытайтесь угадывать все на лету. Намного надежнее хранить таблицу соответствий для частых случаев: "q" -> "к", "w" -> "в" или "у" по вашему правилу, "xai" -> "икс аи", "llama" -> "лама". Такая схема работает лучше, когда правила простые и одинаковые для всех документов.

У термина лучше хранить две вещи: основное название и дополнительные варианты. Основная форма нужна для порядка в индексе, дополнительные варианты нужны для реальных запросов. Например, для "Qwen 3" можно хранить варианты "qwen3", "квен 3", "квен3" и тот способ написания, который живет внутри вашей команды.

На практике полезно индексировать материал хотя бы по четырем полям: display_title для исходного заголовка, term_canonical для основной нормализованной формы, term_aliases для списка вариантов и body для текста статьи. Тогда поиск находит документ и по основной форме, и по вариантам, а пользователь все равно видит нормальный заголовок без искусственной правки.

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

Это особенно заметно в системах, где рядом живут десятки и сотни названий моделей. В AI Router команды работают с большим набором моделей и провайдеров через один API, поэтому формы вроде Qwen, Llama, DeepSeek или xAI быстро расползаются по документации, чатам и тикетам. Без нормализации и алиасов поиск начинает понимать только "официальный" язык, а не тот, которым люди реально пользуются.

Пример на одной статье

Хорошо видно, как это работает, на одной простой записи. В базе знаний лежит статья с названием "Настройка QazTech Pay". Для редактора все ясно: бренд написан латиницей, заголовок аккуратный, термин единый.

Для пользователей картина другая. Один человек вводит "QazTech Pay" как в интерфейсе продукта. Другой пишет "Казтех пэй", потому что так проще на слух. Третий набирает "qaz tech pay" с пробелом посередине, потому что не помнит точное написание. Смысл у всех запросов один, но строка каждый раз разная.

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

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

Это можно представить так:

title: Настройка QazTech Pay
aliases: [QazTech Pay, Казтех пэй, qaz tech pay]
normalized_terms: [qaztechpay, казтехпэй]

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

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

Ошибки, которые ломают поиск

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

Первая частая ошибка - переводить термин, который пользователи обычно не переводят. Если человек ищет "OpenRouter" или "ОпенРоутер", а индекс хранит только слово "маршрутизатор" как перевод слова router, поиск теряет смысл. Названия продуктов, библиотек и брендов почти всегда лучше хранить как набор вариантов, а не как один "правильный" перевод.

Вторая ошибка - надеяться на одну жесткую таблицу замены букв. На схеме это выглядит аккуратно: q = к, w = в, x = кс. В жизни так не работает. "Qwen" пишут как "квен", "куэн" и просто Qwen. "xAI" могут набрать латиницей, кириллицей или через пробел. Если прогонять все слова через одну схему, вы потеряете формы, которые люди вводят на самом деле.

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

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

Самая неприятная ошибка - исправлять запрос так агрессивно, что меняется смысл. Человек ищет "Gemma", а система решает, что имелась в виду "gamma". Или вводит "RAG", а поиск уводит его к общим статьям про обычное слово rag. Безопаснее не подменять исходный запрос, а расширять его: сохранить оригинал, добавить варианты и ставить точное совпадение выше любой догадки.

Если после правок поиск находит меньше, чем раньше, проблема обычно не в индексе как таковом. Чаще команда слишком рано решила, как пользователь "должен" писать термин.

Быстрые проверки перед запуском

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

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

Минимальный набор проверок выглядит так:

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

Отдельно проверьте переименования. Это частая поломка после миграций и обновления документации. Человек ищет привычный термин, а поиск молчит, хотя нужная статья уже есть под новым именем.

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

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

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

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

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

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

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