Гайд · TNWS AI

Как скрыть embeddings из ответа Vespa через document-summary

4 мин—

Отдельный document-summary для RAG: source_id и text вместо vector payload, запрос presentation.summary и проверка ответа.

Какую задачу решаем и где применимо

Русскоязычный поисковый запрос: «как не возвращать embeddings Vespa document summary». Материал проверен по официальной документации Vespa, актуальной на 19 сентября 2026 года. Для Vespa со схемой article, где source_id и text нужны клиенту, а embedding используется только для retrieval. Настройка document-summary не является заменой ACL: она сокращает и контролирует видимый набор полей, но права доступа нужно применять отдельно.

В схеме можно объявить document-summary с явно перечисленными summary fields. Query-параметр presentation.summary выбирает эту summary class. Одно лишь ограничение select в YQL не всегда предотвращает загрузку полного summary с content nodes, поэтому настройки schema и представления нужны вместе, если важны производительность и объём ответа.

До начала эксперимента подготовьте маленький набор документов с известными source_id и один отрицательный пример. Сохраните версию schema, embedding-модели, набор входных вопросов и ожидаемые IDs: так результат можно воспроизвести после обновления системы, а не оценивать по одному удачному ответу. Все значения для маленького tensor в шаблоне — иллюстрация контрактов, не показатели качества модели.

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

  1. Определите минимальные поля для ответа: source_id, текст фрагмента и при необходимости заголовок.
  2. В schema задайте отдельную document-summary class, не включая tensor embedding.
  3. Разверните изменение в тестовом окружении и вызовите тот же nearestNeighbor-запрос с presentation.summary.
  4. Сравните keys каждого hit и размер JSON с прежним ответом; убедитесь, что source_id не потерян.
  5. Запустите отрицательный тест для закрытого документа: summary не должен показываться без ACL-фильтра.

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

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

document-summary rag-snippet {
  summary source_id {}
  summary text {}
}

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' 'presentation.summary=rag-snippet' 'hits=3'

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

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

Вход: документ с source_id=refund:1, коротким правилом возврата и vector из трёх чисел. Ожидается, что hit содержит source_id и текст, а embedding отсутствует. Сравните фактический размер ответа до и после на десяти hits, не обещая фиксированную экономию для чужого корпуса.

Сокращение ответа важно не только из-за сети: чем меньше служебных данных отправлено генератору, тем меньше риск засорить контекст числовыми vectors или пересечь ограничение окна. При этом удаление источника разрушит возможность проверить утверждение LLM. Для некоторых задач summary из атрибутов может быть сформирован без чтения с диска, но это зависит от хранения конкретных полей и не следует автоматически из названия class. Отдельно проверьте, что logging и tracing не включают tensor по умолчанию в соседних операциях. Для RAG храните короткий разрешённый текст и исходный URL/ID; поля персональных данных не выдавайте клиенту даже если исходные документы присутствуют в индексе.

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

  • В каждом hit есть source_id и проверяемый текст.
  • Tensor embedding отсутствует в публичном JSON.
  • presentation.summary совпадает с именем class.
  • ACL по-прежнему работает до сборки summary.

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

Типичные ошибки: чего не делать

  • Полагаться только на YQL select для предотвращения полной загрузки summary.
  • Удалять source_id вместе с embedding.
  • Принимать ограниченный summary за механизм авторизации.

Не исправляйте нерелевантную выдачу произвольным повышением top-k: сперва отделите ошибку модели, схемы, фильтра и ранжирования. Не отключайте проверку tenant ради красивого теста. Не делайте вывод о производительности на крошечном демонстрационном корпусе; проверяйте рабочий объём, конкурентную нагрузку и p95, а также расход памяти/скорость обновлений там, где они существенно меняются.

FAQ

Как выбрать summary class?

Указать presentation.summary в запросе.

Уменьшит ли select стоимость чтения автоматически?

Не обязательно; настройте document-summary.

Можно ли summary заменить ACL?

Нет, доступ фильтруется отдельно.

Официальные источники

Частые вопросы

Как выбрать summary class?

Указать `presentation.summary` в запросе.

Уменьшит ли select стоимость чтения автоматически?

Не обязательно; настройте document-summary.

Можно ли summary заменить ACL?

Нет, доступ фильтруется отдельно.

Читайте также

Комментарии

Пока тихо. Скажите первое слово