Руководство по vector DB / RAG — от наивного RAG к продакшену

Вы понимаете, что такое RAG. Но когда дело доходит до реальной сборки, многие упираются в стену: «вроде бы работает, но ключевой ответ мимо». Причина почти всегда одна и та же — это всё ещё «наивный RAG»: небрежно нарезать документ и сделать обычный векторный поиск.

Практический RAG в 2026 году явно ушёл дальше этого. Ключ — многоэтапный конвейер: «умный chunking → правильный embedding → гибридный поиск (ключевые слова + вектор) → reranking». Как практическое продолжение статьи 030, здесь разбирается конкретное «как именно» для каждого этапа, выбор vector DB (Chroma/pgvector/Qdrant/Pinecone/Weaviate/Milvus), фреймворки и даже вопрос «нужен ли вообще RAG в эпоху 1M токенов?» — суть более продвинутой реализации.

* Названия инструментов, методы и показатели бенчмарков основаны на официальных источниках и нескольких техническом изданиях (по состоянию на 2026 год). Эта область развивается быстро, и лучшие варианты меняются. Показатели бенчмарков взяты из источников и варьируются в зависимости от данных и условий. Прежде чем выбирать, оцените на собственных данных (см. ниже).

1. Повторение: пределы наивного RAG

Минимальный RAG — это «разбить документ → векторизовать через embeddings → сохранить в vector DB → векторизовать вопрос и достать ближайшие чанки → передать их LLM для ответа». Это основы RAG. Но у такого «наивного RAG» есть типичные слабые места.

• Небрежные чанки: разрез посреди предложения, что ломает смысл.
• Только векторный поиск: слабо работает с точными терминами, такими как названия продуктов или номера моделей (он цепляет/упускает то, что близко по смыслу, но различается лексически).
• Передача топ-N как есть: действительно самые релевантные элементы оказываются погребены.

Практический RAG в 2026 году разбивает эти три проблемы с помощью «умного разбиения», «гибридного поиска» и «reranking». Разберём по порядку.

2. Современный конвейер RAG в общих чертах

Поток данных в продакшен-RAG имеет два тракта: подготовка (indexing) и момент запроса (поиск и генерация).

Отличие от наивного RAG — в том, присутствуют ли «④ гибридный поиск» и «⑤ reranking». Эти два этапа поднимают точность поиска до практического уровня.

3. ① Chunking (самое важное)

Можно с полным основанием сказать, что chunking определяет половину качества RAG. Вот основные стратегии.

Если проблема в потере контекста на границах, помогают Contextual Retrieval (прикрепить к каждому чанку контекст всего документа) или Late Chunking. Anthropic сообщает, что Contextual Retrieval + reranking сократили число неудач извлечения по топ-20 вплоть до 67% (приводимый показатель). Реалистичный порядок: начать с «recursive 512» и добавлять semantic / parent-child / Contextual Retrieval, если точности не хватает.

4. ② Выбор модели embedding

Модель embedding превращает чанки в векторы — это фундамент точности поиска.

• Безопасный дефолт: OpenAI text-embedding-3-large. Хороший баланс качества извлечения и простоты интеграции.
• Другие варианты: Cohere, Voyage, embeddings от Gemini и различные OSS-модели.
• Важно: многих OSS-embeddings вполне достаточно для продакшена при сочетании с гибридным поиском + reranking. Не зацикливайтесь на одном лишь embedding.

Суть в том, чтобы относиться к «embedding как к одной из частей всего поискового конвейера». Вместо подмены на дорогой embedding добавление гибридного поиска и reranking зачастую выгоднее по затратам.

5. ③ Выбор vector DB (сравнение)

Vector DB хранит и ищет векторы. Вот лидеры 2026 года по их характеру.

Оси выбора: «масштаб, managed против self-hosted, существующий стек, бюджет». Если сомневаетесь — Chroma для прототипирования, pgvector если у вас есть Postgres, Qdrant/Pinecone для сбалансированного продакшена, Weaviate при упоре на гибрид. Для большинства RAG-нагрузок Pinecone / Weaviate / Qdrant считаются сильными вариантами.

6. ④ Гибридный поиск (BM25 + вектор)

То, что лечит самую большую слабость наивного RAG — плохую работу с точными терминами — это гибридный поиск. Он объединяет BM25 (поиск по ключевым словам/лексический) с плотным векторным поиском.

На практике проще всего использовать DB, которая возвращает гибридные результаты в одном запросе, как Weaviate. Хитрую подстройку оценок оставьте RRF (слияние на основе рангов) — и ничего не сломается. Результат: поиск, сильный и на точных терминах, и на перефразированиях.

7. ⑤ Reranking (retrieve-then-rerank)

Стандарт 2026 года — «два этапа: сначала извлечь широко → затем сузить (rerank)».

• Этап 1 (retrieve): быстро достать топ 50-100 с помощью bi-encoder (embeddings).
• Этап 2 (rerank): с помощью cross-encoder совместно оценить (вопрос, чанк) и сузить до действительно самых релевантных нескольких.

Популярные reranker'ы — Cohere Rerank 3.5, Voyage rerank-2.5, BGE reranker-v2, Jina Reranker v2. Reranking добавляет около 50-200ms задержки и затрат, но поскольку чанков, передаваемых LLM, становится отобранные единицы, он зачастую снижает потребление токенов LLM и уменьшает общую стоимость. И по точности, и по стоимости reranking становится этапом, у которого «нет причин его не добавить».

8. Фреймворки (LlamaIndex/LangChain)

Использовать фреймворк быстрее, чем писать всё самому. Вот разделение труда в 2026 году.

• LlamaIndex: фокус на извлечении. Силён в индексации документов, качестве поиска и быстрой итерации RAG.
• LangChain / LangGraph: сторона оркестрации (управления). Сложные рабочие процессы и координация агентов.
• Комбинированный паттерн: на практике многие используют LlamaIndex как слой извлечения, а LangGraph как слой управления.

Учтите, что в последнее время, со стандартизацией инструментов через MCP и подъёмом Agent SDK, наметился тренд, когда агенты строят конвейеры на лету без тяжеловесных LLM-фреймворков. Тем не менее, если вы оттачиваете качество поиска, семейство LlamaIndex остаётся сильным. Об общем построении агентов см. как собрать AI-агента.

9. RAG против длинного контекста

«С окном контекста в 1M токенов разве нельзя просто запихнуть всё и пропустить RAG?» — частый вопрос. Ответ: «нет, RAG не заменяется».

Ориентир: использовать длинный контекст для небольших корпусов и быстрой итерации, рано добавить prompt caching для стабильного повторяющегося контекста и добавлять RAG в тот момент, когда «свежесть, масштаб, происхождение» становятся требованиями. «Просто запихни в окно контекста» — это новое «просто добавь vector DB»: не панацея. Дополните это пониманием окна контекста.

10. Нюансы вывода в продакшн

• Сначала постройте eval: «вроде бы стало лучше» нельзя улучшать. Количественно измерьте точность извлечения на наборе репрезентативных вопросов × ожидаемых источников и сравнивайте по каждому изменению.
• Мониторинг: непрерывно следите за hit rate извлечения, релевантностью после rerank и обоснованностью ответов источниками.
• Проектирование затрат: счёт складывается из embeddings, reranking и LLM. Урезание токенов LLM через reranking — стандартный способ экономии. См. экономию токенов.
• Свежесть и происхождение: проектируйте под отражение обновлений данных (повторная индексация) и всегда прикрепляйте источник (какой документ) к ответам — это ключ к борьбе с галлюцинациями.
• Конфиденциальные данные: будьте осторожны при векторизации внутренних документов и размещении их вовне. См. корпоративные правила использования AI.

Итоги

Практический RAG эволюционировал от наивного «нарезать и сделать векторный поиск» в многоэтапный конвейер: «умный chunking → embedding → vector DB → гибридный поиск → reranking». Два самых больших выигрыша в точности — это гибридный поиск (слить BM25 + вектор через RRF) и reranking (retrieve-then-rerank): одно лишь добавление этих двух сильно лечит «ответ мимо».

Для vector DB: Chroma для прототипирования, pgvector если у вас есть Postgres, Qdrant/Pinecone для продакшена, Weaviate при упоре на гибрид. Для фреймворков: LlamaIndex для извлечения, LangChain/LangGraph для управления. И даже при 1M токенов RAG не заменяется — если нужны свежесть, масштаб и происхождение, это RAG. Последнее обязательное: «сначала постройте набор для eval». Нельзя улучшить то, что нельзя измерить. Соблюдайте это — и ваш RAG надёжно эволюционирует от «вроде бы работает» к «работает в продакшене».

По теме: что такое RAG (основы), что такое окно контекста, как собрать AI-агента, Claude Agent SDK и что такое MCP.

FAQ

Q. У моего RAG низкая точность. Что чинить в первую очередь?
A. Самое эффективное — добавить две вещи: «гибридный поиск» и «reranking». Один лишь обычный векторный поиск слаб на точных терминах вроде номеров моделей и имён собственных, а самые релевантные чанки оказываются погребены. Слияние с BM25 (через RRF) + rerank с cross-encoder поднимает качество поиска до практического уровня. Если и этого мало — пересмотрите ваш chunking.

Q. Какую vector DB выбрать?
A. Chroma для прототипирования, pgvector если у вас уже есть Postgres — простые старты. Для сбалансированного продакшена — Qdrant (низкая задержка) или Pinecone (полностью управляемая); для активного гибридного поиска — Weaviate; для очень большого масштаба — Milvus. Выбирайте по масштабу, предпочтениям по эксплуатации, существующему стеку и бюджету.

Q. Какой размер чанка хорош?
A. Около 512 токенов с recursive-разбиением — прагматичный дефолт (по бенчмаркам 2026 года отмечен близко к вершине). Для технических документов — semantic (разбиение по смыслу); для документации/кода — structural (учёт заголовков/кода); для точности плюс контекста — parent-child. Начните с 512 и подстраивайте, проводя оценку.

Q. С окном в 1M токенов разве RAG не лишний?
A. Он не становится лишним. Запихивание всего в контекст роняет качество из-за неэффективности по токенам, «lost in the middle» и отвлечения. Используйте длинный контекст для небольших корпусов и прототипов, а RAG — когда свежесть, масштаб и происхождение становятся требованиями: вот реалистичное разделение.

Q. LangChain или LlamaIndex — что использовать?
A. LlamaIndex, если вы оттачиваете качество поиска; LangChain/LangGraph для сложного управления и координации агентов. На практике многие их комбинируют — «LlamaIndex как слой извлечения, LangGraph как слой управления». В последнее время есть и тренд лёгкой сборки с помощью Agent SDK, так что выбирайте по своим требованиям.