Как настроить semantic ranker Azure AI Search для RAG с k=50

Semantic ranker повторно сортирует до 50 предварительно найденных результатов по тексту. Для hybrid с vectors Microsoft рекомендует k=50. Semantic captions и answers извлекают текст дословно из индекса, а не генерируют новые факты. Поля title, keywords и content в semantic configuration имеют приоритет и ограничения длины.

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

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

1. Определите semanticConfiguration для осмысленных searchable текстовых полей заголовка и content; не выбирайте embedding как текст.
2. Обеспечьте предварительный recall: hybrid search с search и vectorQueries k=50.
3. Отправьте queryType=semantic и semanticConfiguration в запросе, задайте select для ID и исходных текстов.
4. Проверьте rerankerScore и исходные цитаты для нескольких контрольных вопросов.
5. Сравните без и с reranking на одинаковой candidate выборке; если нужный документ не был в первых 50, улучшайте retrieval.

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

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

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

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

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

Вход: вопрос о возврате, policy-2026-01 содержит явный ответ «14 дней», запись marketing-2 говорит лишь об удобстве покупок. Ожидаемый результат теста: документ с ответом остаётся в кандидатах и после ранжирования находится выше маркетингового текста. Если запись policy отсутствовала в top-50 до semantic ranker, результат не может появиться магически.

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

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

Два разных компонента отвечают на два разных вопроса: retrieval решает, какие фрагменты вообще станут кандидатами, reranker — какие из этих фрагментов важнее. Поэтому плохой recall нельзя лечить только включением queryType=semantic. Убедитесь, что выбранные текстовые поля реально содержат ответ и связаны с тем же ID, что embedding; неправильно построенные chunks могут ранжироваться по заголовку другой страницы. Проверяйте число кандидатов до и после, а также долю случаев, когда нужный документ вообще доступен для сортировки. Captions полезны как короткая цитата, но если исходник изменился, переиндексируйте материал; извлечённый текст не является проверкой актуальности политики. В чувствительных сценариях сравните цитату с каноническим документом. Semantic ranking — отдельная платная возможность с лимитами, которые следует сверять с вашим аккаунтом, а не обещать фиксированную цену. Если rerankerScore меняется при обновлении внутренних моделей, не ставьте предельно тонкие пороги без калибровки. При отсутствии подходящего passage отсутствие answer лучше ложной уверенности LLM. Логи сохраняют ID источника и статус возможности, но не пользовательские персональные данные без нужды.

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

Постройте два набора: вопросы, где искомый документ входит в первоначальные 50, и вопросы, где он отсутствует. Во второй группе никакая перемена semanticConfiguration не создаст отсутствующего кандидата; эта группа измеряет retrieval, не reranking. В первой сравнивайте позицию полезного фрагмента до и после вторичной сортировки. Учитывайте приоритет text fields: если важное исключение находится в конце длинного content, часть текста может быть отброшена при подготовке к semantic ranking. Лучшее исправление часто состоит в более осмысленном chunking, а не в простом удвоении длины поля. Если вы показываете semantic answer как готовый ответ на сайте, укажите исходный документ и дату политики; это извлечённая цитата, а не юридически подтверждённая истина. Для сравнения версий храните два показателя отдельно: долю правильных документов в top-50 и долю правильных первых цитат после rerank. Так становятся заметны ошибки каждого этапа.