Как фильтровать векторный поиск Typesense по tenant без утечки документов

Vector Search API показывает совместное использование filter_by и vector_query, в частности при фильтрации категории перед flat search. Collections API позволяет объявить строковое поле с facet:true; поиск использует фильтры по полям схемы. Тип tenant и условия доступа должны отражать ваши реальные правила, а значение tenant обязано приходить из доверенной серверной identity, не из поля запроса браузера.

Обязательно запишите версию Typesense, имя коллекции, схему, id и версию embedding-модели, способ генерации запросов и правило доступа. Четырёхмерные массивы ниже используются только как демонстрационные данные. В настоящем retrieval все векторы документов и запросов должны иметь длину вашей модели и создаваться по одному зафиксированному контракту. Секрет TYPESENSE_API_KEY храните на сервере или в секретном хранилище, не помещайте его в опубликованную страницу.

Контрольный пример: вход и ожидаемый результат

Вход: Самый близкий по embedding документ принадлежит tenant beta; пять менее близких — acme. Авторизованный пользователь принадлежит acme.

Ожидаемый результат: Каждый hit относится к acme; ближайший beta отсутствует, а проверка выполняется до передачи результатов модели генерации.

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

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

1. Добавьте индексируемое поле tenant при создании схемы.
2. Загружайте tenant из проверенного источника, не из произвольного текста документа.
3. На backend получите tenant из сессии и сформируйте фильтр Typesense.
4. Выполните query с filter_by и vector_query в одном запросе.
5. Проведите отрицательный тест с максимально похожим чужим документом.

После каждого этапа сохраняйте HTTP-статус, тело ошибки без секретов, schema JSON и найденные id. Отдельно проверяйте состояние самого документа после импорта: в Typesense пакетная загрузка может частично провалиться даже при транспортном HTTP 200. Не принимайте запуск кода за доказательство качества поиска; испытайте полученный индекс на наборе заранее размеченных вопросов и измерьте долю полезных ответов.

Готовый шаблон запроса

curl -G http://localhost:8108/collections/articles_vec_v1/documents/search \
 -H "X-TYPESENSE-API-KEY: $TYPESENSE_API_KEY" \
 --data-urlencode 'q=*' \
 --data-urlencode 'filter_by=tenant:=acme' \
 --data-urlencode 'vector_query=embedding:([0.7,0.1,0.1,0.2], k:10)' \
 --data-urlencode 'exclude_fields=embedding' 

Параметры примера заменяйте реальным названием коллекции, размерностью и вектором. Для вызывающего из браузера приложения создайте серверный слой с ограниченными правами; не вставляйте администраторский ключ в клиентский JavaScript. Если программа ожидает JSON-ответ, проверяйте не только факт получения hits, но и идентификаторы, поля и условия видимости каждого результата.

Что важно именно в этом сценарии

Даже если поисковый движок корректно фильтрует, права на сам API-ключ и вызов должны быть ограничены: клиент не должен иметь возможности убрать фильтр, отправив собственный запрос с администраторским ключом. На сервере исключайте пользовательское значение из составления ACL. Не вставляйте специальный синтаксис фильтров из произвольной строки без валидации — источник допустимых tenant IDs должен быть заранее определён. В тестах проверяйте каждый id выдачи, а не только первый. Если для арендатора документов нет, возвращайте пустой результат и не повторяйте запрос без фильтра. Для RAG дополнительно исключайте документы с истёкшим доступом до формирования prompt context.

Метрика Recall@10 по tenant должна вычисляться относительно допустимых документов того же tenant. Сравнение с глобальным top-10 ошибочно: в глобальном эталоне законно присутствуют чужие id. Для контроля качества держите один кейс с минимальным числом разрешённых документов и один, где ближайший глобальный сосед заведомо запрещён.

Критерии приёмки

• tenant берётся из серверной сессии
• чужой ближайший hit исключён
• все hits проходят ACL
• пустой набор не запускает global fallback
• Есть положительный и отрицательный тест, а не только скриншот удачного запроса.
• Сохранены исходная версия схемы, модель, corpus и выборка запросов.
• Разрешённый контекст отделён от служебных и скрытых документов.