По мере того как поисковые системы и рекомендательные механизмы становятся всё более сложными, на смену старым понятиям классической оптимизации приходит инженерия релевантности. Cовременный поиск строится на пересечении информационного поиска, пользовательского опыта, искусственного интеллекта, контент‑стратегии и цифрового PR. Это направление превращает работу с видимостью в инженерную задачу, где важны не только клики, но и соответствие намерения пользователя, а также точное измерение того, насколько удачно система удовлетворяет потребность.
Специалист отвечает за поисковую, автодополнительную и рекомендательную подсистемы продукта. Он сочетает проверенные алгоритмы (BM25, лексический поиск) с векторными методами и LLM, следит за латентностью и доступностью, управляет схемами данных и бизнес‑правилами.
Релевантность измеряется количественно: документы и запросы размещаются в векторном пространстве, а близость оценивается метриками (NDCG, MRR, CTR, dwell‑time). В инженерии релевантности используются обучающие выборки (judgment lists) и модели ранжирования, которые обучаются на кликовых сигналах и эталонных оценках.
Работа включает нормализацию запросов, извлечение кандидатов (лексическое, векторное, гибридное), ранжирование (LTR, переранжирование), персонализацию и защиту, соблюдение латентности и кэширование. Зрелый процесс поддерживает отладку, мониторинг и A/B‑эксперименты. Важны как офлайн‑метрики (NDCG, MRR, MAP), так и онлайн‑показатели (CTR, конверсия, доля запросов без результатов – ZRR, dwell‑time). Инженер выстраивает компромисс между качеством выдачи, выручкой и скоростью ответа.
Кому нужен инженер по релевантности
Релевантность больше не определяется только позициями в результатах. Концепция relevance engineering представлена как «искусство и наука улучшения видимости» — роль объединяет информационный поиск, UX, искусственный интеллект и контент. В материалах Майка Бертрама описывается специалист, который оптимизирует смысл: он не просто доводит пользователя до страницы, он гарантирует, что страница отвечает на вопрос, быстро загружается, правильно структурирована и масштабируемо работает. Он владеет поисковой, автодополнительной и рекомендательной подсистемами, использует проверенные методы (BM25, модели на основе ключевых слов) и продвинутые подходы (LLM, гибридный поиск), следит за real‑time‑показателями и работает на пересечении технических и контентных команд.
Инженер по релевантности отличается от классического SEO‑специалиста тем, что ориентирован на измеримое улучшение качества поиска и рекомендаций, а не на отдельные тактические фразы и обратные ссылки. В отличие от ML‑инженера, который фокусируется на моделях и инфраструктуре в целом, relevance engineer живёт в сфере поиска и юзер‑опыта, строя решения под конкретный домен и бизнес. Это специалист, который понимает механику поиска, знает, как извлекать кандидаты из индекса, как их ранжировать и как согласовать скорость, качество и выручку.
Как работа распределяется в команде
Позиция инженера по релевантности предполагает активное взаимодействие с несколькими направлениями. Он тесно сотрудничает с продукт‑менеджерами, определяя цели для разных типов запросов — например, навигационных, информационных или коммерческих. Партнёрство с MLOps и платформой данных обеспечивает доступ к логам, фичестору и инструментам для обучения и развертывания моделей. Бэкенд‑команда поддерживает индексацию, хранение и маршрутизацию запросов, следит за латентностью и масштабируемостью. Фронтенд‑разработчики помогают представить результаты пользователю и собирают сигналы о поведении: клики, прокрутки, время просмотра. Аналитики и дата‑учёные проектируют эксперименты, интерпретируют метрики. Такой кросс‑функциональный характер роли позволяет быстро реагировать на изменения в данных и требованиях бизнеса.
Процесс работы: от запроса до ответа
Работа со спросом пользователя разбита на несколько последовательных этапов. Первым шагом является нормализация запроса: приводятся к единому регистру, удаляются стоп‑слова, применяется морфологический анализ, определяется язык. Технологии орфокоррекции генерируют кандидаты для опечаток, а модели определения интента классифицируют запрос как информационный, навигационный или транзакционный. На этом этапе важно понять, чего именно хочет пользователь и какие поля индекса следует использовать.
Далее система извлекает набор кандидатов. Традиционный лексический поиск (например, BM25) находит документы по точным и близким совпадениям. Семантический поиск использует эмбеддинги запросов и документов, чтобы найти ближайших соседей в векторном пространстве. На практике часто применяется гибрид: результаты лексического поиска объединяются с семантическими, чтобы обеспечить и точность, и разнообразие.
Полученные кандидаты подвергаются ранжированию. Модели Learning‑to‑Rank принимают список документов и контекст запроса и на основе набора признаков вычисляют релевантность; это функции, обученные на так называемых judgment list – наборах запросов и документов с оценками человека или генерируемыми по сигналам поведения. Для второй стадии ранжирования применяются нейросетевые cross‑encoder, которые точнее сопоставляют запрос и документ, обрабатывая их совместно, но только на небольшой выборке кандидатов из первых стадий. После машинного ранжирования применяются бизнес‑правила: бустирование определённых категорий или свежих товаров, фильтрация нежелательного контента, диверсификация результатов для разных типов пользователей.
В финале учитывается персонализация: история пользователя, предпочтения, сегментация по регионам и устройствам. Также действуют защитные механизмы (guardrails): фильтры токсичности и неприемлемого контента, проверка прав доступа. Выданный набор документов кэшируется для ускорения повторных запросов; дополнительно отслеживаются p95/p99 латентности, чтобы система не превышала допустимый бюджет времени на ответ. Диаграмма ниже иллюстрирует общий поток данных: запрос проходит нормализацию, затем по двум путям – лексическому и векторному – формируется список кандидатов, который объединяется, проходит LTR, переранжирование, применение правил и персонализации, после чего возвращается пользователю. Собранные клики и другие сигналы поступают обратно для обучения моделей.
flowchart LR
Q[Запрос пользователя] --> N[Нормализация и интент]
N --> L[Лексическое извлечение]
N --> V[Векторное извлечение]
L --> S[Слияние кандидатов]
V --> S
S --> R[Learning-to-Rank]
R --> C[Cross-encoder]
C --> B[Бизнес‑правила]
B --> P[Персонализация/Фильтры]
P --> Out[Выдача]
Out --> T[Телеметрия для обучения]
Качественная ранжировочная модель строится на большом количестве сигналов. В первую очередь это логи кликов и поведенческие данные: сколько раз каждый результат был показан и кликнут, как долго пользователь находился на странице (dwell‑time) и сделал ли он целевое действие. Эти данные коррелируют с положительным опытом, но требуют корректировки: позиционный bias приводит к тому, что верхние позиции получают больше кликов вне зависимости от качества, а платные слоты и новизна влияют на восприятие. Для корректного обучения применяются методы дебайасинга, а также interleaving-тесты, когда два ранжировщика одновременно показывают смешанный результат, и клики позволяют быстро понять, какой из них лучше.
Наряду с позитивными примерами нужны и негативные: это документы, которые пользователь явно игнорировал или выбрал вместо них другую ссылку. Контрфактические методы позволяют оценить влияние изменений без полного запуска A/B‑теста. Все эти сигналы превращаются в признаки, которые хранятся в фичесторе — системе, обеспечивающей一точность данных между обучением и инференсом. Кроме того, команда следит за дрейфом данных и признаков: изменение распределения запросов или пользовательского поведения приводит к ухудшению качества модели, и тогда требуется переобучение или корректировка признаков.
Оценка качества и метрики
Чтобы систематически улучшать поиск, нужен понятный набор метрик. В офлайн‑оценке популярна нормированная накопленная выгода (NDCG). Эта метрика сравнивает фактический порядок документов с идеальным: каждая позиция имеет вес, и оценка нормализуется, чтобы не зависеть от количества релевантных документов. Показатель Mean Reciprocal Rank (MRR) берёт среднее значение обратного ранга первой релевантной ссылки: если релевантный документ находится на третьей позиции, его вклад равен 1/3. Для задач, где важно оценить первые k результатов, применяются Precision@k и Recall@k; первая показывает долю релевантных документов в верхних k, а вторая — какую часть всех возможных релевантных результатов мы нашли. Mean Average Precision (MAP) усредняет точность на позициях всех релевантных документов по всем запросам.
Офлайн‑метрики должны соотноситься с реальным поведением пользователей. Онлайн‑метрики включают click‑through rate (CTR) — отношение кликов к показам, конверсию (CVR) — долю сессий, завершённых покупкой или подпиской, и показатель zero results rate (ZRR) — долю запросов, не нашедших результатов. Другое важное измерение — dwell‑time: это время, которое пользователь проводит на странице после перехода из поиска, прежде чем вернуться на результат; длинное время может указывать на полезность контента. Инженер по релевантности балансирует эти показатели: повышение NDCG не должно приводить к росту латентности или уменьшению конверсии, а снижение ZRR не должно ухудшать точность.
| Метрика | Формула / определение | Когда применять | Подводные камни |
|---|---|---|---|
| NDCG@k | DCG@kIDCG@k\frac{DCG@k}{IDCG@k}IDCG@kDCG@k, где DCG@k=∑i=1k2reli−1log2(i+1)DCG@k=\sum_{i=1}^{k}\frac{2^{rel_i}-1}{\log_2(i+1)}DCG@k=∑i=1klog2(i+1)2reli−1 | Для оценки упорядочивания по нескольким градациям релевантности | Требует качественного эталона; чувствительна к ошибкам разметки |
| MRR | Среднее значение 1/rank1/rank1/rank первого релевантного документа | Для навигационных запросов, где важен быстрый ответ | Игнорирует документы после первого релевантного; не применим для информационных запросов |
| Precision@k | rel@k/k\text{rel}@k/krel@k/k | Когда важно качество топ‑k позиций | Не учитывает полноту; зависит от k |
| Recall@k | rel@k/total rel\text{rel}@k/\text{total rel}rel@k/total rel | Для задач с большим числом релевантных документов | Может завышать значение при широком извлечении |
| MAP | Среднее AP по всем запросам, где AP = средняя точность на позициях релевантных документов | Для общего сравнения моделей в многоцелевых поисках | Требует полных списков релевантных документов; чувствителен к хвосту |
| CTR | клики/показы\text{клики}/\text{показы}клики/показы | Онлайновая оценка привлекательности результатов | Сильное позиционное смещение; зависит от UI |
| Dwell‑time | Время между кликом и возвращением на SERP | Оценка качества контента и соответствия интенту | Может быть высоким на сложных задачах (чтение длинной статьи) без фактической удовлетворённости |
| ZRR | Доля запросов без результатов | Контроль полноты и корректности извлечения | Инфляция из‑за ботов или фильтров; важно исключать стоп‑запросы |
Как проводить эксперименты
Базовым инструментом оценки изменений являются A/B‑тесты. Трафик делится на контрольную и тестовую группы; важно обеспечить стратификацию, чтобы распределить разных пользователей равномерно, и применять коррекции, такие как CUPED, чтобы уменьшить дисперсию и быстрее выявить эффект. Минимально обнаружимый эффект (MDE) помогает понять, какой размер выборки требуется для выявления значимого улучшения.
Когда трафик ограничен или различия между ранжировщиками невелики, используется интерливинг: выдача строится из чередования результатов двух алгоритмов. Клики автоматически атрибутируются к тому или иному кандидату, что позволяет определить лучший вариант, собрав меньше данных. При этом постоянно отслеживаются guardrails: p95/p99 латентности, доля ошибок 4xx/5xx, токсичность контента. Если эксперимент приводит к ухудшению этих ограничителей, его останавливают и переключают систему на стабильную конфигурацию.
Технологический стек
В основе поисковой системы лежит движок, который хранит и индексирует документы. В большинстве продуктов используются Elasticsearch или его форк OpenSearch. Эти системы обеспечивают лексический поиск с использованием BM25 и дают возможность подключить внешнюю модель Learning‑to‑Rank, которая получает список кандидатов и контекст запроса и возвращает упорядоченный результат. Для обучения LTR требуется judgement list — набор запросов с оценками релевантности; он может формироваться вручную или автоматически из пользовательских сигналов.
Векторные базы данных, такие как Milvus, Weaviate или Pinecone, предоставляют эффективный поиск ближайших соседей в многомерном пространстве. Они используются для семантического поиска и рекоммендаций. Для масштабирования и обработки потоков событий применяются Kafka и Flink или Spark Streaming; эти системы собирают логи кликов, строят фичи и передают их в фичестор. Оркестраторы Airflow или Argo управляют батчевыми задачами, включая обучение моделей. Инструменты MLflow и Eland отслеживают эксперименты и облегчают интеграцию моделей с Elasticsearch.
Модели ранжирования используют как классические ML‑алгоритмы (градиентный бустинг по деревьям, например LightGBM и XGBoost), так и нейронные сети на основе Transformers. Bi‑encoder кодируют запрос и документ раздельно, что позволяет использовать библиотеки типа FAISS для быстрого поиска; cross‑encoder обрабатывают пару вместе и дают более точный сигнал, но их применяют только на небольшом наборе кандидатов, чтобы не выйти за пределы бюджетов латентности.
| Инструмент | Задача | Плюсы | Минусы | Примеры применения |
|---|---|---|---|---|
| Elasticsearch | Лексический поиск, агрегирование | Экосистема, масштабируемость, LTR‑плагин | Настройка JVM, стоимость на пиках | E‑commerce, каталог товаров |
| Solr | Лексический поиск, богатые схемы | Гибкость, зрелость, поддержка LTR | Меньше облачных сервисов | Корпоративный поиск, библиотеки |
| Vespa | Сложные графы, векторный поиск | Высокая масштабируемость, встроенные модели | Сложнее в развертывании | Медиа, рекомендательные сервисы |
| FAISS / HNSW | ANN‑поиск в эмбеддингах | Быстрый поиск, GPU‑ускорение (FAISS) | Требует памяти, тюнинг параметров | Семантический поиск, рекомендации |
| Milvus / Weaviate / Pinecone | Векторные БД | Масштабирование, API, фильтры | Стоимость, зависимость от облака | RAG‑системы, чат‑боты |
Примеры применения
Представим крупный маркетплейс, где хвостовые запросы (редкие товары или опечатки) часто возвращали пустую выдачу. Инженер по релевантности проанализировал запросы и заметил, что пользователи часто делают орфографические ошибки. Внедрение модуля орфокоррекции, гибридного поиска (совмещение BM25 и ANN) и fallback‑сценария по категориям позволило за шесть недель снизить долю запросов без результатов примерно на тридцать процентов, а CTR вырос. Это стало возможным благодаря точной настройке семантического слоя и контролю p95 латентности, которая увеличилась лишь незначительно.
Другой пример — медиаплатформа с каталогом видео, где по популярным запросам CTR был низким. Команда внедрила переранжирование на основе cross‑encoder: для каждого запроса выбрали топ‑50 кандидатов по BM25, затем нейросеть пересортировала их с учётом контекста. Чтобы уложиться в бюджет времени, сделали батч‑обработку на GPU и кэшировали результаты. Через несколько недель CTR и sCTR выросли примерно на 8–10 %, при этом 95‑перцентиль задержки остался ниже 200 мс.
В корпоративном поиске ситуация иная: документы могут быть на нескольких языках и иметь ограничения по доступу. Инженер по релевантности настроил морфологические анализаторы для русского и английского языков, обучил двуязычные эмбеддинги и добавил фильтры контроля доступа в запросы. Благодаря этому recall улучшился, а жалобы на утечку данных исчезли. Эти примеры показывают, что подходы варьируются в зависимости от домена, но принципы — гибридный поиск, качественные сигналы, строгий контроль метрик — остаются общими.
Чем инженер по релевантности отличается от других ролей
В компаниях, где есть Data Scientist или ML‑инженер, часто возникает путаница. Data Scientist фокусируется на исследовании данных, проверке гипотез и создании моделей, но редко отвечает за работу в продакшене. ML‑инженер занимается деплоем моделей и обеспечением стабильности инфраструктуры. SEO/ASO‑специалист оптимизирует внешний поиск и магазины приложений, заботится о ключевых словах, ссылках и мета‑данных. Инженер по релевантности живёт внутри продукта: его зона ответственности — поиск, рекомендации и интент пользователя; он строит гибридные пайплайны, внедряет LTR, контролирует latency и обеспечивает корреляцию офлайн и онлайн‑метрик. Этот специалист понимает бизнес‑показатели и владеет инструментами ранжирования, но не ограничивается моделями или внешней оптимизацией.
Развитие карьеры и компетенции
На начальном уровне инженер ведёт отдельную вертикаль, например поиск по каталогу. Он знает базовые алгоритмы поиска, владеет Elasticsearch или Solr, умеет обучать простые LTR‑модели и запускать A/B‑тесты. На уровне senior специалист проектирует гибридные пайплайны, внедряет нейросетевые переранжировщики, управляет дорожной картой экспериментов и взаимодействует с продуктовой командой. Опыт уровня staff или principal предполагает стратегию релевантности для всей компании, создание платформы для экспериментов, наставничество и участие в продуктовых решениях.
Процесс найма обычно включает несколько этапов: скрининг резюме на предмет опыта с поисковыми движками и экспериментами, техническое интервью по IR‑алгоритмам, метрикам и системному дизайну, затем практическое задание — улучшить выдачу на заданном наборе данных. Завершающее интервью (bar‑raiser) оценивает культурные и лидерские качества. Вакансии требуют знания Python или Java, систем потоковой обработки данных и опыт взаимодействия с продуктом.
| Уровень | IR/NLP/ML | Эксперименты | Работа с продуктом и стейкхолдерами | Надёжность и операции |
|---|---|---|---|---|
| Middle | Реализует отдельные вертикали (например, поиск по каталогу), владеет Elasticsearch/Solr, обучает базовые LTR | Проводит A/B‑тесты, анализирует результаты | Взаимодействует с PM и разработчиками, обосновывает решения | Отслеживает p95, умеет откатывать изменения |
| Senior | Проектирует гибридные пайплайны, внедряет cross‑encoder, оптимизирует фичи | Планирует дорожную карту экспериментов, внедряет interleaving | Управляет ожиданиями, оценивает ROI, наставничает | Создаёт стандарты мониторинга, борется с регрессиями |
| Staff/Principal | Формирует стратегию релевантности, строит платформу, влияет на выбор стека | Разрабатывает платформу экспериментов, добивается автоматизации | Влияет на продуктовую стратегию, управляет командой | Обеспечивает устойчивость, соблюдение комплаенса |
Типичные ошибки и как их избежать
Одной из распространённых ошибок является чрезмерная увлечённость векторным поиском без анализа запросов и контента. Семантический слой полезен, но без правильной нормализации и лексической базы приводит только к увеличению задержек. Второй риск — переобучение на кликах: без дебайасинга позиционный bias заставляет модель завышать популярные позиции. Третий сценарий — несогласованность офлайн‑оценок и реального поведения; если лейблы попали в признаки или эталоны устарели, корреляция метрик нарушается. Наконец, многие забывают про бюджет латентности: использование тяжёлых моделей и отсутствие кэширования может убить даже самую точную систему. Эти ошибки требуют дисциплины: пошагового внедрения, регулярных проверок и контроля guardrails.
Этические и правовые аспекты
Инженер по релевантности должен соблюдать законы о защите данных (например, GDPR и российский ФЗ‑152) — хранить только необходимые данные, анонимизировать пользователей и обеспечивать их безопасность. Важно избегать дискриминации: модели могут усиливать предвзятости, поэтому необходимо проводить аудит fairness, анализируя выдачу по разным группам пользователей и корректировать признаки. Прозрачность тоже набирает значение: объяснимость результатов помогает пользователям доверять системе. Контроль нежелательного контента — ещё один аспект: фильтры NSFW, токсичности и жалоб пользователей являются частью guardrails.
Что следует проверить до и после запуска
Перед внедрением новой модели команда проверяет покрытие эталонных наборов для разных типов запросов, сравнивает офлайн‑и онлайн‑метрики на ретроспективных данных, измеряет задержку p95/p99 в тестовой среде и настраивает fallback. Подготавливаются планы отката и алёрты, проверяется сквозная запись и обработка логов. После запуска постоянно мониторятся CTR, sCTR, ZRR, latency, конверсия, доли ошибок и жалоб. Проводятся регулярные ревью запросов с низкой удовлетворённостью и обновляется таксономия. Также отслеживается дрейф признаков: если распределения меняются, нужно переобучить модель или скорректировать признаки.
Заключение
Роль инженера по релевантности становится критически важной, поскольку традиционный подход не гарантирует видимость и конверсию в мире AI‑поиска. Этот специалист обеспечивает системный подход к поиску и рекомендациям: от нормализации запросов и гибридного извлечения до обучения моделей и A/B‑экспериментов. В отличие от Data Scientist или ML‑инженера он фокусируется на сопоставлении интента и контента, следит за латентностью, безопасностью и бизнес‑метриками, и тесно сотрудничает с продуктовой и инфраструктурной командами. Введение этой роли оправдано, когда рост бизнеса ограничивает качество поиска: растёт ZRR, снижается CTR, пользователи уходят. Зрелая инженерия релевантности трансформирует поиск в управляемый продукт: вместо догадок – данные и эксперименты, вместо хаотичных исправлений – воспроизводимая технология.
