Гайд · TNWS AI
Как выбрать angular или euclidean distance для embeddings в Vespa
Привязка метрики Vespa к embedding-модели, сравнение angular и euclidean и проверка совместимости индекса.
Какую задачу решаем и где применимо
Русскоязычный поисковый запрос: «как выбрать distance metric Vespa angular euclidean». Материал проверен по официальной документации Vespa, актуальной на 19 сентября 2026 года. Для tensor-поля Vespa и embedding-модели с известным режимом обучения. Сначала читайте инструкцию производителя самой модели: она определяет, нужны ли нормализация и специфические query/document-префиксы. Эта статья не объявляет одну метрику лучшей для всех моделей.
Метрику поля задают в attribute { distance-metric: ... }; Vespa документирует в частности angular и euclidean. Ранжирование closeness(field, embedding) связано с конфигурацией расстояния. Замена метрики меняет смысл близости, поэтому сравнение чисел score из двух разных конфигураций некорректно без собственной калибровки.
До начала эксперимента подготовьте маленький набор документов с известными source_id и один отрицательный пример. Сохраните версию schema, embedding-модели, набор входных вопросов и ожидаемые IDs: так результат можно воспроизвести после обновления системы, а не оценивать по одному удачному ответу. Все значения для маленького tensor в шаблоне — иллюстрация контрактов, не показатели качества модели.
Пошаговое выполнение
- Из документации embedding-модели выпишите рекомендованную similarity и правило нормализации.
- Сохраните одни и те же векторы и gold set вопросов с размеченными релевантными документами.
- Разверните два изолированных индекса или приложения с различающейся только distance-metric.
- Проверьте сначала toy case с известными векторами, затем Recall@10 и nDCG@10 на реальных вопросах.
- Выберите конфигурацию по качеству и p95, задокументировав модель, предобработку и результат.
Эти шаги предполагают доступ к собственному тестовому приложению Vespa. Для Vespa Cloud и самостоятельной установки способы деплоя отличаются; не угадывайте имена кнопок консоли. Используйте показанный интерфейс schema, YQL или CLI, сверяя конкретное окружение и permissions с документацией. При деплое сохраняйте предыдущее определение, чтобы сопоставить результаты и откатить неудачное изменение без смешения двух причин.
Готовый шаблон
# Вариант A — angular
field embedding type tensor<float>(x[3]) {
indexing: attribute | index
attribute { distance-metric: angular }
}
# Вариант B в отдельном тестовом приложении:
attribute { distance-metric: euclidean }
Шаблон адаптируйте к своей размерности и именам документов. Если он содержит ручной трёхмерный вектор, он полезен для smoke-теста схемы и синтаксиса, но не заменяет настоящий embedding вопроса. Секреты провайдера, токены Vespa и данные закрытых клиентов не вставляйте ни в публичный prompt, ни в статью, ни в логи запроса.
Конкретный вход и ожидаемый выход
Вход: модели создали [1,0,0], [2,0,0] и query [1,0,0]. Эти игрушечные vectors напоминают, что направление и модуль — разные свойства; ожидайте различий ранжирования или расстояния в зависимости от метрики. Не выводите из игрушки, что выбранная конфигурация лучше отвечает на реальные вопросы.
Если модель нормализует выходы, различия метрик могут быть меньше в конкретном датасете, но это проверяемая гипотеза, а не разрешение менять настройку вслепую. Частая ловушка — сравнивать запрос, созданный после смены модели, с документами старой модели: размерность может случайно совпасть, но координатное пространство уже другое. Другая ловушка — перенос порога closeness из angular в euclidean; такой порог требует отдельной калибровки на размеченных положительных и отрицательных парах. При смене метрики делайте версионированный релиз, сохраняйте исходный индекс для отката и перепроверяйте использование HNSW. В отчёте храните не только средний recall, но и ошибки на коротких, длинных, русскоязычных и смешанных запросах.
Сравнение сценариев
| Метрика | Что сравнивает | Практический выбор |
|---|---|---|
| angular | направление векторов | когда модель ориентирована на cosine/angular |
| euclidean | геометрическое расстояние с учётом масштаба | когда это соответствует инструкции модели |
Вывод: сопоставляйте эти варианты на своих вопросах и зафиксированном корпусе. Изменение конфигурации имеет смысл только если оно улучшает оговорённую метрику и укладывается в допустимую задержку.
Проверка результата
- Выбор согласован с официальной рекомендацией embedding-модели.
- Модель и корпус одинаковы в двух экспериментах.
- Порог score откалиброван заново.
- На эталонных запросах проверено качество по IDs.
Успех означает прохождение всех перечисленных пунктов на положительных и отрицательных кейсах. Снимите фактические IDs, число hits и latency до и после изменения; если есть LLM-ответ, проверьте цитаты вручную. Пустой результат из-за ошибки типов, времени ожидания, прав доступа или отсутствующей записи нельзя выдавать за низкую релевантность. Удобно хранить отдельный отчёт по каждым case_id, иначе невозможно обнаружить регрессию на редких формулировках.
Типичные ошибки: чего не делать
- Объявлять angular всегда лучше без теста.
- Использовать старый порог после изменения метрики.
- Смешивать embeddings разных моделей одинаковой размерности.
Не исправляйте нерелевантную выдачу произвольным повышением top-k: сперва отделите ошибку модели, схемы, фильтра и ранжирования. Не отключайте проверку tenant ради красивого теста. Не делайте вывод о производительности на крошечном демонстрационном корпусе; проверяйте рабочий объём, конкурентную нагрузку и p95, а также расход памяти/скорость обновлений там, где они существенно меняются.
FAQ
Где задают distance metric?
В attribute индексируемого tensor-поля.
Можно ли сравнивать raw scores разных метрик?
Не напрямую: они имеют разные шкалы.
Нужно ли учитывать нормализацию модели?
Да, это часть совместимости векторов и метрики.
Официальные источники
Частые вопросы
Где задают distance metric?
В `attribute` индексируемого tensor-поля.
Можно ли сравнивать raw scores разных метрик?
Не напрямую: они имеют разные шкалы.
Нужно ли учитывать нормализацию модели?
Да, это часть совместимости векторов и метрики.
Читайте также
Как фильтровать векторный поиск Vespa по tenant без утечки в RAG
YQL-фильтр вместе с nearestNeighbor, серверный tenant, pre-filtering, отрицательный ACL-тест и проверка полного top-k.
Как хранить chunks для RAG в Vespa с проверяемыми source_id
Схема chunk-документов, parent ID, versioned embeddings, готовый prompt и тест цитат по исходным фрагментам.
Как измерить Recall@10 ANN-поиска Vespa через exact baseline
Два сопоставимых nearestNeighbor-запроса с approximate:false, формула Recall@10 и ограничения exact baseline.
Комментарии
Пока тихо. Скажите первое слово