Поиск — это не просто строка ввода

В предыдущей части мы разобрали рекомендательные системы — алгоритмы, которые решают, что показать пользователю без его запроса. Теперь поговорим о другой стороне: что происходит, когда пользователь сам ищет что-то.

Большинство компаний относятся к поиску как к утилите: есть строка ввода, есть индекс, есть результаты. Но персонализированный поиск — это совершенно другой продукт. Один и тот же запрос «рок» для подростка и для 45-летнего меломана должен давать разные результаты. И оба должны быть релевантными.

В Звуке поиск обрабатывал 2–3 миллиона запросов в день. Когда мы начали персонализировать его, CTR вырос на 18%, а конверсия в прослушивание — на 23%. Это были одни из самых «дешёвых» улучшений: относительно небольшие изменения в ранжировании дали значительный эффект.

Персонализированный поиск vs обычный

Обычный поиск ранжирует результаты по релевантности к запросу: текстовое совпадение, TF-IDF, BM25. Все пользователи получают одинаковую выдачу.

Персонализированный поиск добавляет второй фактор — релевантность к пользователю. Финальный скор = f(relevancetoquery, relevancetouser). Два человека, набравшие одно и то же, видят разные результаты.

Как это работает на практике:

Запрос «рок» для пользователя, который слушает Metallica и Slayer → выдача начинается с thrash metal и heavy metal. Тот же запрос для пользователя, слушающего Radiohead и Muse → альтернативный рок и инди.

Запрос «новинки» для пользователя, предпочитающего русский рэп → свежие релизы русских рэп-исполнителей. Для слушателя классической музыки → новые записи симфонических оркестров.

Технически это реализуется через re-ranking: базовый поисковый движок возвращает кандидатов, а персонализированная модель переранжирует их с учётом профиля пользователя.

Ранжирование: как учитывать предпочтения

Модель ранжирования принимает на вход три группы фичей:

Query features

  • Токены запроса и их эмбеддинги
  • Тип запроса (navigational / exploratory / informational)
  • Длина запроса, наличие фильтров

Document features

  • Атрибуты контента (жанр, исполнитель, год, настроение)
  • Эмбеддинги контента
  • Популярность (глобальная и в сегменте)
  • Свежесть (для discovery важно показывать новинки)

User features

  • Профиль предпочтений (вектор из части 2)
  • История поиска и прослушиваний
  • Контекст: время суток, устройство, текущая сессия
  • Сегмент (для пользователей с малой историей)

Мы использовали Learning to Rank (LTR) — подход, при котором модель обучается ранжировать результаты на основе исторических сигналов. В качестве таргета — клики, прослушивания, добавления в плейлист. Модель — LambdaMART на первом этапе, позже перешли на нейросетевой ранкер с cross-attention между запросом, документом и пользователем.

Важный нюанс: персонализация поиска не должна быть абсолютной. Если пользователь явно ищет «классическая музыка», а он обычно слушает рэп — нужно показать классику. Intent запроса важнее исторических предпочтений. Баланс между персонализацией и intent — одна из самых сложных задач.

Intent detection: понять, что ищет пользователь

Не все поисковые запросы одинаковы. Мы выделили три типа intent:

Navigational intent

Пользователь знает, что ищет: конкретный трек, исполнитель, альбом. «Metallica Nothing Else Matters» — здесь персонализация минимальна, нужно просто найти правильный результат. Точность поиска > персонализация.

Exploratory intent

Пользователь хочет исследовать: «рок 80-х», «музыка для бега», «похожее на Radiohead». Здесь персонализация критична — из тысяч результатов нужно выбрать те, что понравятся именно этому пользователю.

Mood/context intent

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

Для классификации intent мы обучили BERT-модель на размеченных запросах. Accuracy — 89% на трёх классах. Классификатор работал в real-time и определял, насколько агрессивно персонализировать выдачу.

Как поиск и рекомендации дополняют друг друга

Поиск и рекомендации — не конкурирующие продукты, а две стороны одной медали:

  • Рекомендации = push-модель. Система предлагает контент, пользователь пассивен.
  • Поиск = pull-модель. Пользователь выражает намерение, система отвечает.

На практике они обогащают друг друга:

Поисковые данные улучшают рекомендации. Если пользователь ищет «jazz», но его история прослушивания — только поп, поисковый запрос — более сильный сигнал намерения. Мы передавали поисковые запросы как фичи в рекомендательные модели, и это давало +5% relevance в офлайн-тестах.

Рекомендации улучшают поиск. Если рекомендательная модель знает, что пользователь предпочитает acoustic-версии, это знание используется при ранжировании поисковой выдачи. Общий профиль пользователя — это shared asset.

Поиск как fallback. Когда рекомендации промахиваются (а это случается — ни одна модель не идеальна), поиск — это способ пользователя «поправить» систему. Анализ поисковых запросов после плохих рекомендаций — ценный источник информации о качестве RecSys.

Discovery: помочь найти неизвестное

Discovery — это то, что отличает хороший продукт от великого. Рекомендации отвечают на вопрос «что ещё тебе понравится?». Discovery отвечает на вопрос «что ты ещё не знаешь, но полюбишь?».

В Звуке мы реализовали несколько discovery-механик:

Exploration slots. В каждой персональной ленте 10–15% позиций отдавались контенту вне привычного вкусового профиля, но с высоким predicted score. Мы использовали epsilon-greedy стратегию: с вероятностью epsilon показываем «неожиданный» контент.

Taste breakers. Специальный плейлист «Расширь горизонт» — алгоритм подбирал треки, которые нравились пользователям с частично похожим вкусом. Если ты слушаешь инди-рок и электронику, а похожие пользователи ещё и джаз — вот тебе джаз.

Trending in your segment. Что популярно среди похожих на тебя пользователей прямо сейчас. Это сочетание персонализации и социального доказательства — мощный драйвер discovery.

Результаты: пользователи, которые активно взаимодействовали с discovery-контентом, показывали +35% retention через 30 дней. Discovery расширял вкусовой профиль, и система получала больше сигналов — позитивный feedback loop.

Метрики поисковой персонализации

Как измерять успех персонализированного поиска:

Метрика Что измеряет Наш бенчмарк
pCTR Персонализированный CTR на позиции 1–5 +18% vs baseline
MRR Mean Reciprocal Rank — позиция первого клика 0.72 → 0.81
nDCG@10 Качество ранжирования топ-10 0.65 → 0.74
Zero-result rate Доля запросов без результатов 8% → 4%
Search-to-listen rate Конверсия из поиска в прослушивание +23%
Discovery rate Доля нового контента в потреблении 15% → 28%

Совет: не оптимизируйте только CTR. Пользователь может кликнуть и уйти через 5 секунд. Измеряйте downstream-метрики: прослушивание, добавление в избранное, retention. Именно они отражают реальную ценность.

Что дальше

В следующей части мы разберём CVM и путь клиента — как персонализация выходит за рамки контента и начинает управлять всем опытом: пушами, офферами, UI.

Хотите персонализировать поиск и discovery в вашем продукте? Запишитесь на консультацию — разберём ваш кейс и определим точки роста.