Как измерить recall HNSW в Azure AI Search через exhaustive KNN

Опциональный vectorQueries.exhaustive вызывает exhaustive KNN на этапе запроса даже для HNSW-поля. HNSW предназначен для приближённого поиска; отличие списка ID от exact baseline измеримо. Качеством нельзя считать разницу @search.score между различными алгоритмами без проверки самих релевантных источников.

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

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

1. Подготовьте хотя бы набор независимых русских вопросов и один embedding на вопрос; не изменяйте корпус между двумя запросами.
2. Для каждого вопроса получите top-10 с exhaustive:true; сохраните IDs как точный baseline на заданном наборе данных.
3. Выполните тот же запрос без exhaustive, сохраняя k, fields, filter и select.
4. Посчитайте пересечение top-10 IDs / 10 для каждого вопроса и среднее по набору; отдельно замерьте p95 задержки.
5. Если recall низок, изучите параметры HNSW и фильтрацию, а затем повторите тест на новом индексе вместо тюнинга по одному примеру.

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

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

POST /indexes/ru-kb/docs/search?api-version=2026-04-01
{"select":"id,title","vectorQueries":[{"kind":"vector",
"vector":"<полный массив embedding>","fields":"contentVector",
"k":10,"exhaustive":true}]}

# В реальном JSON замените строку <...> массивом чисел;
# повторите запрос с exhaustive:false для HNSW baseline.

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

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

Вход: десять размеченных вопросов, по одному vector из 1536 чисел; для вопроса Q1 точный список A,B,C,D,E,F,G,H,I,J, ANN список A,B,C,D,E,F,G,H,X,Y. Ожидаемый Recall@10 этого вопроса по совпадению IDs — 8/10=0,8. Это показатель совпадения с точным kNN, а не доказательство, что сами документы отвечают человеку.

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

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

Формула по IDs проста, но интерпретировать её надо аккуратно. Exact nearest neighbors могут быть нерелевантны: если embedding-модель не понимает предметную область, высокий технический recall будет соседствовать с плохим пользовательским ответом. Дополните сравнение размеченными релевантными документами и ручной оценкой ответа. Разделяйте три метрики: ANN-vs-exact Recall@10, долю полезных документов по ручной разметке и latency. Две группы запросов — короткие точные артикулы и длинные разговорные вопросы — часто ведут себя по-разному, поэтому среднее без сегментов скрывает проблему. Если включён preFilter, одинаковое значение filter обязательно в обеих ветках, иначе точный поиск станет другой задачей. Не смешивайте score и rerankerScore, когда к запросу добавлен semantic ranker. Для p95 используйте многократные вызовы и одинаковый сервисный регион; единичный замер зависит от кэша и нагрузки. Механизм exhaustive может быть дорогим на большом корпусе, поэтому используйте его как проверку на контролируемой выборке, а не обещание всегда включать в production. Результаты эксперимента храните с датой, API-версией, ревизией индекса и embeddings.

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