Native BM25 и Full-Text Search

Вы поддерживаете Elasticsearch для keyword search и Qdrant для semantic search? Две базы, двойной деплой, постоянная синхронизация. С native BM25 в Qdrant - это один сервис.

• Замена Elasticsearch + vector DB на один Qdrant инстанс в RAG системе
• Autocomplete с prefix tokenizer без отдельного сервиса
• Multilingual search с unicode-aware tokenization для 100+ языков

Предварительные знания

• Sparse Vectors: BM42 and SPLADE
• Payload Indexes

Native BM25: Qdrant считает сам

В Qdrant v1.16+ появился **native BM25**: Qdrant сам вычисляет sparse BM25 векторы из текстового payload, без внешних библиотек типа FastEmbed или Elasticsearch. Достаточно создать `text` index на payload поле - и коллекция получает возможность lexical search.

Разница между **text filter** и **BM25 sparse index**: - `match: {text: 'query'}` - это фильтр (boolean: содержит или нет), без ранжирования - BM25 sparse vector - это ранжирование по TF-IDF весам с IDF-взвешиванием на уровне всей коллекции Оба механизма используют text index, но дают разный результат.

Full-text поиск и tokenization

После создания text index Qdrant поддерживает два типа текстового поиска: **filter-based** (через payload filter) и **BM25 ranking** (через sparse vector query). Рассмотрим оба и научимся их комбинировать.

**ASCII folding** и **stemming**: text tokenizer с `lowercase: true` автоматически нормализует регистр. Для ASCII folding (é → e, ñ → n) и stemming нужен tokenizer `multilingual`. Prefix tokenizer создаёт sub-tokens: слово `hello` → токены `h`, `he`, `hel`, `hell`, `hello` - это позволяет искать по началу слова без wildcard запросов.

Для autocomplete используйте `prefix` tokenizer с фильтром, а не BM25 поиск. Prefix filter работает быстрее и точнее для этого use case: `{key: 'title', match: {text: 'mach'}}` найдёт все документы, начинающиеся с 'mach'.

Полный hybrid search без Elasticsearch

Традиционная архитектура гибридного поиска: **Elasticsearch** (lexical) + **vector DB** (semantic). С native BM25 в Qdrant вся система укладывается в один сервис. Это упрощает деплой, снижает latency и устраняет проблему синхронизации двух баз.

**Native BM25 vs FastEmbed BM42**: при native BM25 не нужен external embedder для sparse части - Qdrant считает всё сам из payload. FastEmbed BM42 генерирует sparse векторы на клиенте (attention-weighted). Для большинства случаев native BM25 проще и достаточно качественен. BM42 даёт лучше качество, но требует отдельного embedder сервиса.

Итоги

• Native BM25 в Qdrant v1.16+: создайте text payload index — sparse вектор вычисляется автоматически
• Text filter (`match: {text}`) — boolean совпадение; BM25 query — ранжирование по TF-IDF
• 4 tokenizer'а: word (стандарт), whitespace (код), prefix (autocomplete), multilingual (Unicode)
• Full hybrid search = dense (semantic) + BM25 (lexical) + RRF fusion — всё в одном Qdrant
• Native BM25 проще FastEmbed BM42 в деплое; BM42 даёт лучшее качество ценой external embedder

Что дальше

Native BM25 закрывает lexical часть. Теперь добавим к этому advanced exploration.

• Discovery Search — Exploration поверх hybrid search: context-guided поиск
• FastEmbed BM42 — Альтернатива native BM25: attention-weighted sparse embeddings
• Payload Index — Основы: как устроены payload индексы в Qdrant

Вопросы для размышления

• В каком случае вы предпочли бы сохранить Elasticsearch рядом с Qdrant, а не заменять его?
• Как бы вы реализовали многоязычный autocomplete (EN + RU) с минимальными ресурсами?
• Что изменится в архитектуре вашей RAG системы, если перейти с Elasticsearch + Qdrant на один Qdrant с native BM25?

Связанные уроки

• alg-10-binary-search