Sparse Vectors: BM42 и SPLADE

Dense embeddings не находят 'PostgreSQL 15.2 JSONB GIN index'. Слишком специфично для семантики. Sparse vectors решают это - они кодируют конкретные слова с весами. Dense + Sparse = Hybrid Search. Это стандарт для серьёзных поисковых систем.

• **E-commerce:** поиск по артикулу 'SKU-ABC-12345' - только sparse точно найдёт этот товар
• **Юридический поиск:** статья 'ГК РФ 854' - конкретная ссылка, не семантика
• **Техническая документация:** 'kubectl apply --dry-run' - команды должны находиться точно

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

• First Search: Search API

Sparse vs Dense: два мира поиска

**Dense vectors** (как OpenAI embeddings) - плотные векторы, где большинство измерений ненулевые. Кодируют *семантику*: 'кот' и 'кошка' дают похожие векторы. **Sparse vectors** - разреженные, большинство измерений равны нулю. Кодируют *лексику*: важные слова из текста с их весами.

**Проблема dense-only поиска:** семантические модели иногда промахиваются по конкретным терминам. Запрос 'PostgreSQL JSONB index performance' может вернуть статьи про MongoDB или MySQL - они семантически похожи. Sparse vector точно найдёт документы где упоминается именно 'PostgreSQL JSONB'.

BM42: нейронный IDF от Qdrant

**BM42** - алгоритм от Qdrant, улучшение классического BM25. Разница: BM25 использует статистический IDF (частота слов в корпусе), BM42 использует **нейронный IDF** - transformer-модель определяет важность токена с учётом контекста.

**BM42 vs BM25 в Qdrant:** Qdrant официально рекомендует BM42 (через fastembed) как лучшую sparse-модель для большинства задач. BM25 тоже поддерживается но как встроенная функция (built-in sparse). BM42 даёт лучший recall за счёт нейронного IDF.

SPLADE: learned sparse representations

**SPLADE (SParse Lexical AnD Expansion)** - нейронная модель, обученная создавать разреженные векторы с **расширением запроса**. Если в документе написано 'автомобиль', SPLADE также активирует токены 'машина', 'транспорт', 'движение' - семантически связанные. Это делает sparse поиск значительно умнее BM25/BM42.

Настройка коллекции и поиск по sparse vectors

**Полный пример** коллекции с dense + sparse vectors, добавления данных и поиска. Sparse поиск можно использовать отдельно или комбинировать с dense для Hybrid Search.

**Практический совет:** для большинства production RAG-систем - используйте Hybrid Search (dense + sparse через RRF). Dense даёт семантику, sparse даёт точность на терминах. Recall hybrid поиска обычно на 5-15% выше чем dense-only, особенно на специализированных доменах (медицина, право, технический поиск).

Ключевые идеи

• **Sparse vectors** кодируют лексику: конкретные слова с IDF-весами. Большинство измерений = 0
• **BM42** (рекомендован Qdrant) - нейронный IDF через attention-веса трансформера. Быстро, хорошее качество
• **SPLADE** - учит расширение запросов. 'EV' → 'electric vehicle'. Лучшее качество, медленнее
• **Sparse vectors требуют Dot Product** - веса не нормализованы, масштаб важен
• **Hybrid Search** (dense + sparse + RRF fusion) - стабильно даёт recall на 5-15% выше чем dense-only

Что дальше

Sparse vectors увеличивают recall. Но коллекция с dense + sparse занимает значительно больше памяти. Квантизация решает эту проблему.

• Квантизация векторов — Сжатие dense векторов в 4-32x - важно когда есть ещё и sparse
• Payload индексы — Фильтрация работает и с sparse поиском
• HNSW: Как работает индекс — Dense часть hybrid search использует HNSW

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

• Почему SPLADE использует Dot Product, а не Cosine? Что произойдёт если создать sparse коллекцию с Cosine?
• На каких задачах sparse-only поиск лучше hybrid? Есть ли такие случаи?
• BM42 и SPLADE генерируются разными моделями. Если вы переходите с BM42 на SPLADE - нужно ли переиндексировать данные? Почему?

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

• la-02-dot-product