Как найти похожие документы Typesense по id без нового embedding

Документация Vector Search задаёт форму embedding:([], id: foobar) в теле /multi_search. Пустой массив здесь означает не пустой вектор для сравнения, а команду использовать сохранённый embedding документа с данным id. Официальная страница явно отмечает, что исходный документ сам в результаты не входит. Нужен существующий id и правильно проиндексированное векторное поле.

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

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

Вход: Документ a1 описывает возврат; a2 — обмен покупки, a3 — постороннюю тему. a1 уже проиндексирован.

Ожидаемый результат: Запрос возвращает близкие ID, например a2 на тестовом наборе после проверки векторов; сам a1 исключён. Релевантность a2 не гарантируется без разметки.

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

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

1. Убедитесь, что исходный id существует и принадлежит разрешённому tenant.
2. Запишите embedding исходной записи в ожидаемое векторное поле.
3. Передайте vector_query с пустым массивом и параметром id.
4. Включите k и ограничение выдачи подходящим сценарию значением.
5. Проверьте отсутствие исходной карточки и запрещённых объектов в результатах.

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

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

curl -X POST http://localhost:8108/multi_search \
 -H "X-TYPESENSE-API-KEY: $TYPESENSE_API_KEY" -H 'Content-Type: application/json' \
 -d '{"searches":[{"collection":"articles_vec_v1","q":"*","vector_query":"embedding:([], id: a1, k: 5)","exclude_fields":"embedding"}]}' 

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

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

Для рекомендаций полезно заранее решить, что считать аналогом: та же категория, похожий смысл, другой SKU либо продолжение инструкции. Простое математическое соседство может вернуть устаревший или закрытый документ. Если рекомендации строятся для нескольких арендаторов, не доверяйте id, полученному только из браузера: backend должен подтвердить права на исходную запись и наложить такой же фильтр на выдачу. Проводите отрицательный тест с чужим id и отдельный тест с удалённой записью. Не логируйте полные приватные тексты и не расширяйте permissions только ради красивого блока рекомендаций. Сравните выдачу с ручным эталоном, где для каждой карточки есть хотя бы несколько подходящих продолжений.

Если исходная запись лишена embedding или создана другой моделью, не подменяйте её случайной «похожей» строкой. Возвращайте контролируемое отсутствие рекомендаций и отправляйте id в очередь переиндексации. Это честнее, чем показывать пользователю нерелевантный список.

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

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