Профи.ру встроил LLM поверх Elasticsearch: 150 000 запросов в час без замены движка

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

Что понадобится

• Elasticsearch (полнотекстовый поисковый движок, который хранит каталог и выполняет базовый поиск по совпадениям)
• Языковая модель (LLM), развёрнутая как отдельный сервис, не вместо, а рядом с Elasticsearch
• Redis (быстрое хранилище для кеширования коротких и частотных запросов)
• Нормализатор запросов: модуль, который приводит слова к базовой форме, исправляет раскладку и снимает опечатки до отправки в поисковый индекс
• Мониторинг: Zabbix, Metabase или аналоги для отслеживания времени ответа и ошибок
• Каталог услуг с синонимами и частотностью, обновляемый через админку

Три режима поиска, которые должна покрывать архитектура

Прежде чем встраивать LLM, полезно понять, какие задачи поиск решает в Профи.ру. Их три, и каждая предъявляет свои требования.

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

Найти конкретного специалиста. Клиент вводит имя или фамилию и ищет профиль. Здесь работает прямой поиск по индексу.

Распознать запрос вне каталога. Некоторые услуги Профи.ру не оказывает. Поиск должен вовремя это понять и не вести клиента по стандартному сценарию оформления заказа.

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

Как устроен базовый поиск до LLM?

Архитектура выглядит так: веб, мобильный веб и приложения отправляют запрос через GraphQL-контур (корпоративную шину данных). Через шлюз он попадает в сервис поиска, а оттуда идёт обращение к Elasticsearch.

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

До отправки в Elasticsearch запрос проходит нормализацию:

• Слова приводятся к базовой форме
• Порядок слов учитывается для финального скоринга (оценки релевантности), но не является жёстким ограничением
• Исправляется неверная раскладка клавиатуры
• Игнорируется часть опечаток
• Подставляются синонимы и альтернативные написания услуг
• Запрос сравнивается с формулировками из каталога

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

Если запрос неоднозначный (например, просто «репетитор»), в выдачу попадают разные направления. Тогда, помимо текстового соответствия, система учитывает частотность услуги: при прочих равных более востребованные варианты оказываются выше.

Цель: больше 90% выборов клиентов должны приходиться на первые пять результатов, а в идеале на первые три.

Почему Elasticsearch LLM, а не вместо?

Базовый поиск отвечает примерно за 150 миллисекунд. Порог, после которого команда считает, что с сервисом что-то не так: 250 миллисекунд на 95-м перцентиле (то есть 95 из 100 запросов должны уложиться быстрее). Ошибки отслеживаются с нулевой терпимостью: одна ошибка создаёт предупреждение, десять отправляют алерт в команду.

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

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

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

Что делать с этим прямо сейчас, по ролям

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

Маркетологу. Связка Elasticsearch LLM показывает, как снизить процент «нулевых» поисковых сессий (когда клиент ничего не нашёл и ушёл). Если ваш продукт теряет конверсию на этапе поиска, гибридная схема дешевле полной замены движка.

Предпринимателю в РФ. Опыт Профи.ру показывает, что для российского продукта с русскоязычными запросами не обязательно разворачивать дорогую инфраструктуру с нуля. Elasticsearch остаётся основой, LLM подключается точечно. Из доступных в РФ языковых моделей для слоя нормализации можно рассматривать YandexGPT и GigaChat, хотя выбор зависит от задачи и бюджета.

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