Как объединить BM25 и векторный поиск в Azure AI Search через RRF

Hybrid query одновременно содержит search для полнотекстового поиска и vectorQueries для векторов; списки результатов объединяются алгоритмом Reciprocal Rank Fusion. k задаёт размер списка векторных кандидатов, top — размер итогового ответа. Нельзя трактовать RRF @search.score как обычную вероятность или напрямую сравнивать с одним векторным score.

Это не обещание одинакового ранжирования для любого русского корпуса. Результат embedding зависит от deployment, подготовки текста, chunking, обновлений модели и состава индекса. Доступность предварительных функций и ограничения сверяйте с документацией и настройками собственного сервиса; цена и длительность операций здесь намеренно не указаны, потому что они не следуют из поискового ответа. Отделяйте успешный HTTP-запрос от оценки полезности найденного фрагмента.

Пошаговое выполнение

1. Подготовьте пару документов: один с точным SKU AB-417, второй с формулировкой синонимами без SKU.
2. Сравните отдельно текстовый поиск по search и vector-only kind:text, сохраните IDs.
3. Соберите в одном Search - POST search и vectorQueries; укажите top отдельно от k.
4. Проверьте выдачу на коротком точном запросе и на длинном вопросе о возврате; оцените оба сценария.
5. При ухудшении выясните, какая ветка пропустила документ; не повышайте произвольно weight без эксперимента.

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

Готовый REST-шаблон

POST /indexes/ru-kb/docs/search?api-version=2026-04-01
{"search":"возврат SKU AB-417","select":"id,title,content",
 "top":5,"vectorQueries":[{"kind":"text",
 "text":"как вернуть товар AB-417","fields":"contentVector","k":20}]}

Подставьте своё имя сервиса в https://<service>.search.windows.net, передайте Content-Type: application/json и авторизацию выбранным поддерживаемым способом. Демонстрационный массив из трёх чисел или строка <embedding массива> — только описание формы; они не являются реальным embedding для поля с 1536 измерениями. Перед отправкой проверьте JSON, размерность и отсутствие ключа в клиентском коде.

Входные данные и ожидаемый результат

Вход: a-417 содержит точный артикул AB-417 и условия возврата; policy-syn описывает те же условия фразой «отмена заказа» без артикула. Ожидается, что гибридный топ-5 сохраняет a-417 для точного запроса, а тестовая перефразировка приводит хотя бы один релевантный policy документ. Позиции и score зависят от корпуса.

Ожидаемый ID — проверяемая гипотеза на подготовленном тестовом наборе. При другом корпусе и другом embedding нельзя честно обещать конкретный score и порядок результатов. Сохраняйте как входное содержимое, так и текст возвращённого фрагмента: найденный ID без исходного подтверждения не годится для публикации ответа от имени компании.

Разбор и границы применения

Гибридный поиск полезен потому, что разные запросы несут разные признаки. SKU, номера счетов и имена собственные требуют буквального совпадения; разговорная формулировка «как отменить покупку» может лучше совпадать по смыслу. Но объединение не гарантирует улучшения каждой метрики: если одна ветка засоряет top нерелевантными кандидатами, итоговая выдача тоже ухудшится. Храните три набора результатов для сравнения: lexical-only, vector-only и hybrid. Помечайте тип вопроса, ожидаемые IDs и отрицательные совпадения. Не устанавливайте top равным k механически: первый ограничивает выдачу API, второй контролирует объём векторного recall перед fusion. Для больших индексов специализированный maxTextRecallSize находится в preview API на момент проверки документации; не переносите его в стабильный 2026-04-01. Не делайте вывод об эффективности RRF по одному запросу: оцените Recall@5 и качество первых цитат на тестовом наборе с буквальными и семантическими вопросами. Для RAG передавайте языковой модели исходный content вместе с ID и отфильтровывайте документы по доступу до формирования контекста.

Практический контроль именно этой задачи

При тестировании разделите корпус на три типа документов: номерные инструкции со строгим SKU, описательные справки с несколькими перефразировками и шумные тексты с большим количеством общих слов. Для каждого запроса заранее запишите не только правильный документ, но и опасный ложный результат, например соседний артикул AB-418. Сравните top-5 трёх режимов по тем же данным. Если RRF поднимает шумный документ, выясните, из какой ветки пришёл высокий ранг: изменение размера кандидатного списка k может повлиять сильнее, чем переформулировка запроса. При обновлении словаря товаров пересчитывайте embeddings документов, если меняется их текст; однако не надо обещать, что semantic ветка поймёт новый SKU без буквального search. Параметр search можно задавать не равным text при осмысленной стратегии, но для первого теста держите намерение одинаковым. Публикуйте пользователю вывод с подлинным номером источника и запрещайте генератору переносить срок возврата из другого товара.

Сопоставление вариантов