retrieval для коротких русских запросов: где поиск ломается

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

Поиск любит контекст. Когда человек вводит одно слово, системе не хватает сигнала, чтобы понять смысл. Слово есть, а намерение почти не видно.

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

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

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

Есть и вторая проблема. Человек вводит одно слово, но ждет не список совпадений, а ответ под свой сценарий. Запрос "отпуск" в HR-базе, в правовой базе и в поддержке зарплатного проекта означает разное. Пользователь это знает, а поиск нет.

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

Обычно сбой происходит в нескольких местах:

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

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

Какие однословные намерения встречаются чаще

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

На практике такие запросы чаще всего попадают в четыре группы:

• навигационные: "тариф", "акт", "оферта";
• запросы-действия: "оплатить", "отменить", "подключить";
• запросы-сущности: "паспорт", "ИНН", "НДС";
• симптомы и коды: "500", "блок", "лимит".

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

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

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

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

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

Как склонения сбивают поиск

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

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

Множественное число добавляет еще один перекос. Запрос "договора" нередко уводит в список всех договоров, хотя человеку нужен типовой бланк. То же происходит со словами "акт" и "акты", "счет" и "счета". Для человека связь очевидна, а поиск может разнести эти формы по разным кластерам документов.

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

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

Хороший тест простой. Возьмите 20-30 частых однословных запросов из логов и прогоните формы вроде "договор", "договора", "договором". Если топ выдачи заметно меняется без смены намерения, матчинг уже дрейфует.

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

Как разбирать аббревиатуры и короткие формы

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

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

Что хранить в словаре

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

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

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

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

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

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

Как настроить retrieval шаг за шагом

Настройку лучше начинать не с модели и не с индекса, а с логов. Если вам нужен хороший retrieval для коротких русских запросов, соберите 100-200 реальных примеров длиной в одно-два слова. Не придумывайте их сами. Пользователи пишут "тариф", "отпуск", "КБК", "снилс", и именно такие формы чаще всего ломают выдачу.

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

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

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

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

Смотрите не только на среднюю метрику по всей системе. Сравнивайте hit@k, MRR и долю промахов именно на коротких запросах. Если общий результат вырос, а запросы вроде "инн" или "доверенность" все еще ведут не туда, пользователи заметят это сразу.

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

Пример из базы знаний банка

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

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

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

Что обычно правят

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

• "овер" - "овердрафт";
• "ДБО" - "дистанционное банковское обслуживание", "интернет-банк";
• "карта" рядом со словами "ПИН", "лимит", "перевыпуск" - банковская карта;
• "карта" рядом со словами "процесса", "схема", "маршрут" - внутренний документ.

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

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

В банке такой набор правок обычно занимает несколько дней, а не месяцы. Если смотреть не на общую метрику, а на 50-100 самых частых коротких запросов, результат виден почти сразу.

Где команды ошибаются чаще всего

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

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

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

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

Не меньше вреда дает привычка смотреть только на top-1. Для коротких запросов это слишком узкий взгляд. Если нужный документ стабильно держится в top-3 или top-5, система уже может работать хорошо после легкой настройки reranker, словаря и правил переписывания запроса. А если его нет даже в top-5, проблема почти всегда глубже: плохие синонимы, неверная нормализация или пустые поля в индексе.

Самая полезная проверка тут очень приземленная: взять 100-200 коротких запросов из продакшена, разметить ожидаемые документы вручную, сравнить выдачу без нормализации и с ней, а потом отдельно посмотреть top-1, top-3 и top-5. Такой тест быстро отрезвляет. Часто оказывается, что новую модель учить рано. Сначала нужно привести в порядок словарь, формы слов и сокращения.

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

Перед запуском retrieval стоит сделать короткую ручную проверку. Она занимает меньше часа и ловит сбои, которые большой офлайн-тест часто пропускает. Особенно это заметно на русских однословных запросах: пользователь пишет "отпуск", "дмс" или "рко", а поиск тащит не тот документ или вообще молчит.

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

Аббревиатуры тоже лучше проверить руками. Не стоит надеяться только на эмбеддинги. "ДМС", "РКО", "КЭП", "СБП" и десятки похожих форм живут по своим правилам. Для каждой частой формы задайте канон и свяжите его с синонимами, нижним регистром и полной расшифровкой. Иначе "дмс" найдет одно, а "добровольное медицинское страхование" - другое.

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

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

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

Что делать после первых правок

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

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

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

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

Минимум, который обычно работает, выглядит так:

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

Если вы запускаете поиск в продакшене в РФ, заранее решите, что именно попадает в логи и кто видит сырые запросы. В коротких фразах часто мелькают номера договоров, телефоны, ФИО и другие чувствительные данные. Маскирование PII и аудит лучше вшить в контур сразу. Например, RU LLM на rullm.com закрывает эту инфраструктурную часть через OpenAI-совместимый API: логи и бэкапы хранятся в РФ, а маскирование PII и аудит-трейлы встроены в каждый запрос.

Хороший признак зрелой команды простой: она не спорит о модели по общим графикам, а быстро отвечает, почему поиск снова ошибся на слове "мир".