При построении RAG-системы часто сталкиваются с дилеммой: dense-поиск отлично находит смысловые соответствия, но проваливается на точных совпадениях — артикулах, номерах заказов, датах. Sparse-поиск (BM25) даёт обратный эффект. Клиенты хотят production-ready решение без компромиссов. За 5 лет мы реализовали 30+ RAG-проектов и знаем, как объединить оба подхода. Предлагаем разработку RAG с Qdrant — векторной БД на Rust с нативной поддержкой гибридного поиска и богатой фильтрацией. Qdrant в 1.5 раза быстрее конкурентов при равной точности, что подтверждают независимые бенчмарки (официальная документация Qdrant).
Какие бизнес-задачи решает RAG на Qdrant?
RAG на Qdrant подходит для сценариев, где требуется быстрый и точный ответ на основе собственной базы знаний. Это может быть корпоративный поиск по документации, ассистент техподдержки, аналитический инструмент извлечения данных из отчётов. Qdrant позволяет выполнять семантический поиск с фильтрацией по метаданным (дата, категория, автор), что критично для enterprise-разработки.
Какие проблемы решаем?
Низкая точность на редких терминах. Dense-эмбеддинги — 1536-мерные вектора — не всегда улавливают точное совпадение: ORDER-12345 и ORDER-12346 могут быть близки семантически, но это разные сущности. Sparse-представление (SPLADE) фиксирует конкретные токены. Гибрид с RRF даёт +13% MRR@5 в наших кейсах.
Медленная фильтрация по сотням тысяч документов. Без индексации payload-поля поиск с условиями doc_type, date или department тормозит до 500 мс на запрос. Qdrant позволяет создавать payload-индексы (KEYWORD, DATETIME, INTEGER), снижая latency до 20 мс.
Масштабирование до миллионов векторов. Одноузловая конфигурация Qdrant выдерживает до 10M векторов на 64 ГБ RAM. При росте данных — шардирование и репликация без даунтайма.
Как мы это делаем
Стек: Qdrant (self-hosted или Cloud), sentence-transformers/paraphrase-multilingual-mpnet-base-v2 для dense, prithivida/Splade_PP_en_v1 для sparse, GPT-4o-mini для генерации ответов. Развёртывание — через Docker Compose или Kubernetes.
Вот типичный конфиг коллекции:
from qdrant_client import QdrantClient from qdrant_client.models import Distance, VectorParams, SparseVectorParams, SparseIndexParams, HnswConfigDiff client = QdrantClient(url="http://localhost:6333") client.create_collection( collection_name="documents", vectors_config={ "dense": VectorParams(size=1536, distance=Distance.COSINE, hnsw_config=HnswConfigDiff(m=16, ef_construct=200)) }, sparse_vectors_config={ "sparse": SparseVectorParams(index=SparseIndexParams(on_disk=False)) } ) Из нашей практики. У клиента — мультиязычный e-commerce ассистент (рус/eng) с 85 000 чанков: FAQ, политики возврата, описания товаров. Мы развернули Qdrant на одном сервере (16 vCPU, 64 GB RAM). Dense-only давал MRR@5 = 0.71, гибрид с RRF — 0.84, улучшив точность по артикулам на 30%. Faithfulness ответов выросла с 0.82 до 0.91. Полный pipeline собрали за 2.5 недели.
Как гибридный поиск повышает точность?
Гибридный поиск объединяет две стратегии: semantic search (dense) и keyword matching (sparse). Qdrant выполняет prefetch по каждому типу, затем применяет RRF (Reciprocal Rank Fusion) — финальный ранг вычисляется как сумма обратных рангов. Это даёт стабильный прирост в сценариях, где важны и смысл, и точные сущности.
Сравним с dense-only:
| Метрика | Dense only | Hybrid (RRF) | Улучшение |
|---|---|---|---|
| MRR@5 | 0.71 | 0.84 | +18% |
| NDCG@5 | 0.68 | 0.81 | +19% |
| Faithfulness | 0.82 | 0.91 | +11% |
Наши тесты показывают: Hybrid search даёт от 10% до 18% прироста метрик. Для Qdrant это бесплатно — не нужно поднимать отдельный Elasticsearch.
Сравнение конфигураций для разных объёмов данных
| Объём данных | Рекомендуемая конфигурация Qdrant | Ожидаемый latency p99 |
|---|---|---|
| до 10M векторов | 1 узел, 64 GB RAM, 8 vCPU | < 30 мс |
| 10-100M векторов | 3 узла, 128 GB RAM, 16 vCPU | < 50 мс |
| > 100M векторов | 6+ узлов, 256 GB RAM, 32 vCPU | < 100 мс |
Процесс работы
- Аналитика. Оцениваем данные: объём, типы, частоту обновления. Определяем, нужны ли sparse-вектора и payload-индексы.
- Проектирование. Схема коллекции, выбор эмбеддеров, pipeline индексации.
- Реализация. Написание ingestion-пайплайна (на Python или Rust), hybrid search endpoint, интеграция с LLM.
- Тест. Оценка MRR, NDCG, faithfulness, latency p99. A/B-тест на реальных запросах.
- Деплой. Docker/K8s, мониторинг (Prometheus + Grafana), алертинг по дрейфу метрик.
Что входит в работу
- Документация: описание архитектуры, инструкция по обновлению эмбеддеров, руководство по эксплуатации.
- Доступы: Git-репозиторий с кодом, credentials к инфраструктуре.
- Обучение: 2 воркшопа для вашей команды (администрирование Qdrant, дообучение pipeline).
- Поддержка: 2 недели после запуска — исправление багов, ответы на вопросы.
Сроки ориентировочно
- Настройка Qdrant + схема коллекции: 1–2 дня.
- Ingestion pipeline (dense + sparse): 3–7 дней.
- Hybrid search + фильтрация: 3–5 дней.
- Оценка и оптимизация: 1–2 недели.
- Итого: от 2 до 4 недель.
Стоимость рассчитывается индивидуально — зависит от объёма данных, сложности фильтрации и необходимой кастомизации LLM. Оценим ваш проект за один день. Закажите консультацию по RAG-решению — обсудим детали и подберём оптимальный подход под ваши задачи.
Свяжитесь с нами, чтобы обсудить детали и получить предварительную оценку.