Как выполнить vector query в Azure AI Search через REST

Стабильный Search - POST использует vectorQueries, kind:vector, vector, fields и k. Параметр select ограничивает возвращаемые retrievable поля. Vector search возвращает ближайшие k документов, если в доступном корпусе их достаточно, даже когда семантическое сходство невелико. @search.score не является вероятностью истинности ответа.

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

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

1. Получите embedding вопроса тем же deployment и с теми же dimensions, что использовали для корпуса.
2. Отправьте Search - POST с vectorQueries и select=id,title,content: это делает результат объяснимым без выдачи 1536 чисел.
3. Возьмите топ-5 IDs и тексты, сверяйте с контрольными релевантными источниками.
4. Если ответ пустой, проверьте количество документов, profile, fields и length массива до смены параметра k.
5. Показывайте пользователю исходный фрагмент и ссылку на источник; генератору запрещайте придумывать отсутствующие факты.

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

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

POST /indexes/ru-kb/docs/search?api-version=2026-04-01
{"select":"id,title,content","vectorQueries":[{"kind":"vector",
"vector":[0.1,0.2,0.3],"fields":"contentVector","k":5}]}
# Массив заменяется embedding запроса из 1536 чисел; пример из трёх
# компонентов не является исполнимым для описанного индекса.

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

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

Вход: вопрос «сколько дней на возврат», embedding той же модели и два документа: policy-2026-01 о 14 днях и shipment-2026-01 о доставке. Ожидаемый для подготовленного тестового корпуса результат: policy-2026-01 встречается в top-5, content содержит формулировку о сроке. Точная позиция и score зависят от модели, поэтому без живого аккаунта их не обещаем.

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

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

Для небольшого корпуса k=5 почти не различает хороший поиск от случайного: пять ближайших вернутся даже при отсутствии ответа. Добавьте отрицательные вопросы «можно ли вернуть подписку через год», для которых корректно не давать уверенного ответа по фрагменту о товаре. Если бизнес-логика требует порога релевантности, калибруйте его на размеченных запросах с учётом того, что опция vector threshold относится к preview API, а не к выбранной стабильной версии. Не переносите score между индексами с разными алгоритмами или моделями как абсолютную меру. Разделите проверку retrieval и генерации: сначала вручную убедитесь, что топ содержит нужный документ, потом вводите LLM. Для запроса с наименованием SKU добавьте буквальный поиск или отдельную стратегию hybrid: векторный поиск хорошо улавливает смысл, но не гарантирует точное совпадение артикула. Анализируйте случаи нулевой релевантности и статистику Recall@5 по русским вопросам, а не единичный удачный пример. Секреты Azure остаются на сервере; в браузер передавайте только разрешённые метаданные и текст.

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

Составьте контрольный набор из пяти положительных и пяти отрицательных вопросов. Положительный вопрос имеет заранее записанный id и фразу, которая служит доказательством ответа. Отрицательный либо вообще не освещён в базе, либо похож лексически, но описывает другой объект. Для каждого запроса записывайте top-5 ids, текстовый фрагмент, модель запроса и длину vector. Если контрольная фраза находится, но ответ генератора всё равно ошибочен, не меняйте поиск вслепую: дефект может быть в инструкции генератору или слишком большом контексте. Если нужного фрагмента нет даже в top-20, изучайте chunking, модель и качество документа. В интерфейсе показывайте не абстрактное число @search.score, а цитату и источник. Повторяйте тест после переиндексации, потому что изменение границ фрагментов меняет конкуренцию ближайших соседей. Так проверяется вся цепочка доказательств от вопроса до выбранного текста.