Как настроить гибридный поиск Typesense: текст, embeddings и alpha

В официальной документации авто-embedding поле можно поставить в query_by вместе с обычным текстовым. Typesense применяет rank fusion; по умолчанию вес текстовой ветви 0.7, векторной 0.3. alpha внутри vector_query меняет вес векторного компонента, например 0.8. Параметр rerank_hybrid_matches:true рассчитывает дополнительные оценки и для документов, найденных только одной из ветвей, но увеличивает вычислительную работу.

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

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

Вход: Запросы «E509», «хлорид кальция для пищевого производства» и «как вернуть деньги» с ручной разметкой релевантных document id.

Ожидаемый результат: Три отчёта keyword/semantic/hybrid по одним и тем же запросам; выбранное alpha удерживает точный код E509 и улучшает перефразировки, если это подтверждено nDCG@10.

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

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

1. Создайте две независимые контрольные выборки: коды и смысловые перефразы.
2. Индексируйте текстовое и auto-embedding поля в одной коллекции.
3. Укажите оба поля в query_by; проведите базовый запрос с default весами.
4. Прогоните несколько значений alpha при одинаковых документах и k.
5. Сравните nDCG@10, долю найденных кодов и p95; оставьте минимальную сложность, достигающую порогов.

После каждого этапа сохраняйте 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":"help_auto_v1","q":"возврат E509","query_by":"title,embedding","vector_query":"embedding:([], alpha: 0.8)","exclude_fields":"embedding","rerank_hybrid_matches":true}]}' 

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

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

Для externally generated embeddings официальная документация разрешает передавать числовой запрос в vector_query, а текстовое поле оставить в query_by: это другой вариант той же идеи, но не используйте пустой [] без авто-генерации. Проводите два отдельных отчёта: релевантность векторов и качество объединения, иначе проблема энкодера маскируется настройкой alpha. При длинных запросах документация рекомендует рассмотреть drop_tokens_threshold:0, чтобы избежать лишних внутренних keyword-поисков; это настройка нагрузки, а не универсальное улучшение качества. Возвращайте пользователю цитируемый текст и id, не сырые embedding числа. Оцените распределение результатов: высокий alpha может вытеснить точный код соседним по смыслу, а низкий — упустить разговорный запрос.

Таблица для решения по сценариям полезнее одной средней цифры: если бизнес-критичны номера товаров, держите критерий «точный код в top-3» отдельно от среднего nDCG по обычным фразам. Победа на агрегате не оправдывает потерю критически важного класса запросов.

Сравнение по сценариям

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