Как выполнить nearestNeighbor-поиск Vespa через YQL и rank-profile

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

1. Получите embedding вопроса той же моделью и тем же протоколом предварительной обработки.
2. Проверьте размерность и конечность всех чисел до HTTP-запроса.
3. Укажите YQL с nearestNeighbor, totalTargetHits и имя документного поля.
4. Передайте input.query(q) и ranking=semantic; hits задайте отдельно от размера пула кандидатов.
5. Проверьте source_id и текст каждого hit на небольшой вручную размеченной выборке.

Эти шаги предполагают доступ к собственному тестовому приложению Vespa. Для Vespa Cloud и самостоятельной установки способы деплоя отличаются; не угадывайте имена кнопок консоли. Используйте показанный интерфейс schema, YQL или CLI, сверяя конкретное окружение и permissions с документацией. При деплое сохраняйте предыдущее определение, чтобы сопоставить результаты и откатить неудачное изменение без смешения двух причин.

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

vespa query   'yql=select source_id,text from article where {totalTargetHits:10}nearestNeighbor(embedding,q)'   'input.query(q)=[0.10,0.20,0.30]'   'ranking=semantic' 'hits=3'

Шаблон адаптируйте к своей размерности и именам документов. Если он содержит ручной трёхмерный вектор, он полезен для smoke-теста схемы и синтаксиса, но не заменяет настоящий embedding вопроса. Секреты провайдера, токены Vespa и данные закрытых клиентов не вставляйте ни в публичный prompt, ни в статью, ни в логи запроса.

Конкретный вход и ожидаемый выход

Вход: вопрос Как оформить возврат? преобразован в трёхмерный canary vector, в корпусе есть запись refund:1 о возврате и shipping:1 о доставке. Ожидается не фиксированный искусственный score, а возврат source_id и текста без самого embedding и включение релевантной записи в top-3 на настоящем embedding-тесте.

Для реального теста подготовьте десять вопросов и ручную разметку допустимых source_id. Рассчитывайте Recall@3 и сравнивайте порядок с устойчивой контрольной версией. Если выдача пуста, диагностируйте документный ID, наличие вектора, совпадение schema/rank-profile и формат input.query(q); бессмысленно повышать hits, когда оператор не получает совместимого tensor. Если документ найден, но ответ LLM ошибается, разделите retrieval и generation: сначала проверьте фактический фрагмент, затем prompt. Не считайте closeness вероятностью того, что документ прав: это функция близости в конкретной конфигурации расстояния и набора данных. Для production не возвращайте массив embeddings клиенту без практической необходимости.

Проверка результата

• Имя tensor-поля в YQL совпадает со схемой.
• Имя q и его тип совпадают с inputs профиля.
• totalTargetHits не смешан с размером ответа hits.
• На размеченных вопросах считается доля найденных source_id.

Успех означает прохождение всех перечисленных пунктов на положительных и отрицательных кейсах. Снимите фактические IDs, число hits и latency до и после изменения; если есть LLM-ответ, проверьте цитаты вручную. Пустой результат из-за ошибки типов, времени ожидания, прав доступа или отсутствующей записи нельзя выдавать за низкую релевантность. Удобно хранить отдельный отчёт по каждым case_id, иначе невозможно обнаружить регрессию на редких формулировках.