BM25, эмбеддинги и реранкеры: как выбрать этапы поиска
Автоматический перевод
Эта статья была автоматически переведена с оригинальной английской версии.
BM25 ранжирует текст по совпадению слов запроса. Эмбеддинги находят кандидатов с похожим смыслом. Реранкер повторно оценивает найденных кандидатов, чтобы улучшить их порядок. Для инженеров, которые создают поиск или RAG, эти этапы решают разные проблемы, поэтому их нужно тестировать отдельно.
Начните с BM25 и применяйте права доступа к документам. Добавляйте эмбеддинги, когда релевантные фрагменты не находятся из-за других слов в запросе. Добавляйте реранкер, когда нужные фрагменты находятся, но оказываются слишком низко в списке. Оставляйте каждый этап только в том случае, если он улучшает результаты на размеченных данных в пределах бюджета времени и стоимости.
Например, запрос по ERR-42 требует корректной обработки идентификаторов. Вопрос об ошибке после выхода из спящего режима может требовать семантического сопоставления, если в руководстве написано «ошибка возобновления». Реранкинг помогает только после того, как нужный фрагмент попадёт в набор кандидатов.
Что делает каждый этап
| Этап | Метод | Задача |
|---|---|---|
| Фильтрация | Структурированные фильтры | Соблюдать ограничения по tenant, правам доступа, продукту, языку, времени и доступности. |
| Лексический retrieval | BM25 | Сопоставлять слова; сохранять ID и коды ошибок с помощью подходящих полей или анализаторов. |
| Dense retrieval | Эмбеддинги | Синонимы, перефразирования, неточные намерения и семантическая полнота поиска. |
| Объединение | Reciprocal Rank Fusion или взвешенная комбинация поисковых методов | Объединять кандидатов из разреженного и плотного поиска, не предполагая сопоставимость их оценок. |
| Реранкинг | Cross-encoder | Читать запрос вместе с каждым кандидатом, чтобы оценить короткий список. |
| Финальная точность | Реранкер на LLM или модель ответов | Уточнять нюансы релевантности только после сокращения списка. |
| Оценка | Recall@k, nDCG, MRR, метки кликов, ручная разметка | Проверять, улучшает ли каждый добавленный этап базовый результат. |
Начальные варианты для разных сценариев
| Продукт | Подход для проверки | Почему |
|---|---|---|
| Поиск по документации | BM25 плюс эмбеддинги плюс cross-encoder | Важны и точные имена API, и семантические вопросы. |
| Retrieval для RAG | Базовый BM25; сравнить гибридный retrieval и реранкинг | Оценивать покрытие доказательств, подтверждение ответов и латентность. |
| Поиск товаров | Лексические фильтры плюс гибридный retrieval плюс бизнес-признаки | Важны доступность, цена, популярность и точные фасеты. |
| Поиск для поддержки | Гибридный retrieval плюс актуальность и метаданные обращений | Важны и похожие формулировки, и действующие правила. |
| Внутренняя база знаний | Базовый BM25, затем dense retrieval по журналам запросов | Начните с измеримых результатов, прежде чем добавлять затраты на модели. |
| Поиск по юридическим материалам или требованиям соответствия | Базовый лексический поиск плюс строгие фильтры, затем осторожное семантическое расширение | И ложноположительные, и ложноотрицательные результаты обходятся дорого. |
Почему BM25 по-прежнему нужен в системе
Эмбеддинги находят текст с похожим смыслом, но не могут надёжно заменить точное сопоставление. Коды ошибок, имена функций, SKU продуктов, юридические формулировки и имена людей часто выражают намерение именно за счёт точного написания. BM25 полезен как базовый вариант, потому что повышает оценку при совпадении слов. Текстовый анализ может изменить эти слова: стандартный анализатор Elasticsearch разбивает текст и приводит его к нижнему регистру. Сохраняйте чувствительные к пунктуации ID, такие как ERR-42, с помощью подходящего анализатора или поля точного значения. Ранжирование BM25 не гарантирует точного равенства строк.
Dense retrieval может добавлять релевантные результаты, когда пользователи не знают терминологию документа. Проверяйте его вместе с BM25. Если оба поисковых метода находят полезные взаимодополняющие результаты, RRF может объединить их ранжированные списки. Он использует позиции результатов вместо сравнения исходных лексических оценок и оценок эмбеддингов.
Когда добавлять реранкер
Добавляйте cross-encoder, когда релевантные документы попадают в набор кандидатов, но занимают слишком низкие позиции. Cross-encoder читает запрос вместе с каждым документом-кандидатом. Для этого нужен отдельный проход модели для каждой пары, поэтому применяйте его к короткому списку. Выбирайте число кандидатов по измеренным полноте поиска и латентности; первые 50 — полезный эксперимент, а не универсальный порог.
Проверяйте реранкер на LLM, когда cross-encoder пропускает различия, важные для вашего приложения, например то, какая версия правил действует. Он добавляет вычисления модели, стоимость которых зависит от числа кандидатов и длины входных данных. Сравните качество, латентность и стоимость на одном и том же коротком списке, прежде чем оставлять его.
Recall@k измеряет, какая доля размеченного релевантного материала попадает в первые k результатов. MRR поощряет высокую позицию первого релевантного результата; nDCG оценивает порядок, когда метки задают разные уровни релевантности. Precision@1 проверяет, является ли первый результат релевантным.
Последовательность оценки
- Разметьте реальные запросы по важным намерениям, языкам, правам доступа и стоимости ошибок. Начните с малого, затем расширяйте выборку, пока отдельные группы и уровень неопределённости не позволят обосновать решение.
- Измерьте BM25 отдельно.
- Проверьте dense retrieval, если BM25 пропускает релевантные фрагменты.
- Если два набора результатов дополняют друг друга, проверьте объединение с помощью nDCG и Recall@k.
- Проверьте реранкинг cross-encoder, если релевантные кандидаты занимают слишком низкие позиции; измерьте Precision@1 и nDCG.
- Добавляйте реранкинг на LLM только в том случае, если он улучшает качество с учётом стоимости и латентности.
- Отслеживайте метрики в продакшене: долю запросов без результатов, долю переформулировок, долю кликов, исправления ответов, p95-латентность и стоимость.
Дополнительные материалы
- Статья Этапы ранжирования поиска содержит полное руководство по реализации.
- Статья Метрики оценки RAG объясняет оценку retrieval и цитирования.