Гайд · TNWS AI
Как загрузить embeddings в Vespa через JSONL feed без дублей
Формат put-операций Vespa CLI, стабильные ID, проверка source_id и безопасная повторная загрузка embeddings.
Какую задачу решаем и где применимо
Русскоязычный поисковый запрос: «как загрузить embeddings в Vespa через JSONL». Материал проверен по официальной документации Vespa, актуальной на 19 сентября 2026 года. Применимо к Vespa CLI и приложению с уже развернутой схемой article, в которой embedding — tensor<float>(x[3]). Сначала получите векторы официальным интерфейсом выбранной embedding-модели: Vespa CLI не генерирует их из произвольного JSONL автоматически.
vespa feed отправляет операции из файла в Vespa, а не принимает просто массив объектов произвольной формы. У операции put есть документный ID и объект fields; один JSON-объект занимает одну строку. Для обновления документа важно сохранять один и тот же ID, иначе повторная доставка создаст новый объект с другим адресом. Ответы каждого действия анализируйте, а не выводите успех из нулевого exit code всего пайплайна.
До начала эксперимента подготовьте маленький набор документов с известными source_id и один отрицательный пример. Сохраните версию schema, embedding-модели, набор входных вопросов и ожидаемые IDs: так результат можно воспроизвести после обновления системы, а не оценивать по одному удачному ответу. Все значения для маленького tensor в шаблоне — иллюстрация контрактов, не показатели качества модели.
Пошаговое выполнение
- Нормализуйте source_id, закрепите versioned model_id и checksum исходного текста до вычисления вектора.
- Проверьте, что вектора — массивы конечных чисел длины 3 и что ID уникальны внутри batch.
- Сформируйте JSONL: по одной полной
put-операции в строке; не заворачивайте их в JSON-массив. - Запустите
vespa feed articles.jsonlпротив настроенного target Vespa CLI и соберите число успешных и ошибочных документов. - Повторите маленькую часть файла и получите документ по ID через
/document/v1, убедившись, что объект не дублировался.
Эти шаги предполагают доступ к собственному тестовому приложению Vespa. Для Vespa Cloud и самостоятельной установки способы деплоя отличаются; не угадывайте имена кнопок консоли. Используйте показанный интерфейс schema, YQL или CLI, сверяя конкретное окружение и permissions с документацией. При деплое сохраняйте предыдущее определение, чтобы сопоставить результаты и откатить неудачное изменение без смешения двух причин.
Готовый шаблон
{"put":"id:article:article::refund-1","fields":{"source_id":"refund:1","text":"Возврат в течение 14 дней","embedding":[0.10,0.20,0.30]}}
{"put":"id:article:article::shipping-1","fields":{"source_id":"shipping:1","text":"Доставка после оплаты","embedding":[0.70,0.00,0.20]}}
vespa feed articles.jsonl
Шаблон адаптируйте к своей размерности и именам документов. Если он содержит ручной трёхмерный вектор, он полезен для smoke-теста схемы и синтаксиса, но не заменяет настоящий embedding вопроса. Секреты провайдера, токены Vespa и данные закрытых клиентов не вставляйте ни в публичный prompt, ни в статью, ни в логи запроса.
Конкретный вход и ожидаемый выход
Вход — два фрагмента FAQ с ID refund-1 и shipping-1, один и тот же модельный вектор длины 3 на каждом повторе. Ожидается ровно два документа после первого и повторного feed; GET refund-1 возвращает source_id=refund:1, нужный текст и согласованное tensor-поле. Это проверка идемпотентности адреса, а не семантической точности.
Разделяйте транспортные ошибки и ошибки данных. Первые могут требовать bounded retry, вторые — карантина строки и исправления модели/схемы. Возвращённый статус по документу важнее общего вывода консоли. На больших партиях заранее сохраните manifest, где отмечены идентификаторы, версия модели и контрольные суммы; тогда частичную неудачу можно безопасно переиграть. Никогда не генерируйте случайный ID на каждом retry и не перезаписывайте более свежую редакцию текста устаревшим embedding. При замене модели используйте новое поле, полный backfill и сравнение. Документный ID Vespa и source_id внутри материала решают разные задачи: первый адресует запись, второй помогает читателю проверить цитату в RAG.
Проверка результата
- Каждая строка является самостоятельным JSON-объектом с
putиfields. - Длина и конечность чисел проверены до feed.
- Число уникальных ID стабильно после повторной доставки.
- Несовместимые строки перечислены отдельно от сетевых сбоев.
Успех означает прохождение всех перечисленных пунктов на положительных и отрицательных кейсах. Снимите фактические IDs, число hits и latency до и после изменения; если есть LLM-ответ, проверьте цитаты вручную. Пустой результат из-за ошибки типов, времени ожидания, прав доступа или отсутствующей записи нельзя выдавать за низкую релевантность. Удобно хранить отдельный отчёт по каждым case_id, иначе невозможно обнаружить регрессию на редких формулировках.
Типичные ошибки: чего не делать
- Складывать операции в один JSON-массив вместо JSONL.
- Использовать новый случайный документный ID для каждого повтора.
- Игнорировать неуспешные операции в общей партии.
Не исправляйте нерелевантную выдачу произвольным повышением top-k: сперва отделите ошибку модели, схемы, фильтра и ранжирования. Не отключайте проверку tenant ради красивого теста. Не делайте вывод о производительности на крошечном демонстрационном корпусе; проверяйте рабочий объём, конкурентную нагрузку и p95, а также расход памяти/скорость обновлений там, где они существенно меняются.
FAQ
Можно ли повторно выполнить put?
Да, при сохранении одного документного ID; проверьте актуальность версии данных.
Можно ли отправить текст вместо tensor?
Только если схема специально задаёт embedding-преобразование; здесь подаётся готовый vector.
Где смотреть отдельные ошибки?
В ответах операций feed и диагностике CLI.
Официальные источники
Частые вопросы
Можно ли повторно выполнить put?
Да, при сохранении одного документного ID; проверьте актуальность версии данных.
Можно ли отправить текст вместо tensor?
Только если схема специально задаёт embedding-преобразование; здесь подаётся готовый vector.
Где смотреть отдельные ошибки?
В ответах операций feed и диагностике CLI.
Читайте также
Как фильтровать векторный поиск 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.
Комментарии
Пока тихо. Скажите первое слово