RAG для бизнеса: гайд по базе знаний, векторному поиску и чат-боту

RAG (retrieval augmented generation, «генерация с подкреплением поиском») — способ подключить к нейросети ваши документы: сначала система находит релевантные фрагменты, потом модель формулирует ответ на их основе.

В 2026 году разговоры «RAG умер, хватит длинного контекста» не выдержали проверки практикой. Окна контекста у LLM выросли, но бизнесу по-прежнему нужны актуальность (документ обновился вчера), права доступа (юрист видит договоры, стажёр — нет), аудит (откуда взялась цифра) и предсказуемая стоимость запросов. По обзору инженеров OTUS на Habr, современный RAG — это не «векторная база + top-k», а цепочка: переформулировка запроса → поиск → реранкинг → упаковка доказательств → ответ с цитатами → оценка качества поиска.

Коротко: что такое RAG в одном абзаце

• Поиск по индексу ваших документов (векторный, лексический или оба).
• Отбор 5–8 лучших фрагментов с метаданными (отдел, дата, тип файла).
• Генерация ответа LLM строго в рамках найденного контекста.
• Цитирование — ссылка на PDF, раздел, страницу.
• Контроль — логи запросов, метрики, обновление индекса при смене регламента.

Чем RAG отличается от файлов в промпте и fine-tuning

Fine-tuning имеет смысл для тона бренда; создание базы знаний с живыми регламентами почти всегда делают через RAG.

Типовые задачи: HR, юристы, поддержка, продажи, операционка

• HR: отпуска, ДМС, командировки — бот по внутренним политикам; снижение нагрузки на HR на 30–50% в типовых пилотах.
• Поддержка: ответ из FAQ и инструкций по продукту вместо «подождите оператора».
• Юристы / закупки: поиск пунктов в договорах и шаблонах; точность растёт при правильном retrieval, а не при «самой умной» модели.
• Продажи: актуальные прайсы, условия акций, скрипты — без риска выдуманной скидки.
• Операционка: техкарты, чек-листы, регламенты склада — «как оформить возврат по пункту 4.2».

Архитектура RAG-системы в production — конвейер из семи этапов. Пропуск любого звена даёт «умный, но неправильный» бот.

Ingestion → чанкинг → эмбеддинги → индекс → retrieval → generation

Схема для команды:

PDF/регламент → парсер → чанки + метаданные → embedding → vector DB
         ↓
    Вопрос пользователя → hybrid search → reranker → prompt → LLM → ответ + источник

Где ставить фильтры по отделам и правам доступа

Фильтры — до отправки чанков в LLM:

1. В метаданных чанка: department, role, doc_class, valid_until.
2. При запросе: JWT/SSO определяет роль → в поиск уходит фильтр role IN (...).
3. После retrieval: повторная проверка ACL на каждый документ (паттерн крупных интеграций Confluence + GitLab).

Так вы не платите токены за фрагменты, которые пользователю всё равно нельзя показывать.

Эмбеддинги переводят текст в числовой вектор. Похожие по смыслу фрагменты оказываются «близко» в векторной базе данных — так работает семантический векторный поиск.

Для русского домена часто лучше multilingual-модели (multilingual-e5-large, jina-embeddings-v3), чем универсальные англоязычные embedding-модели на узкой лексике (внутренние замеры на корпоративных текстах это подтверждают).

Выбор embedding-модели для русского языка

Критерии:

• Качество на ваших 50 тестовых вопросах важнее бенчмарка на Wikipedia.
• Размерность вектора влияет на память индекса, не на «ум» напрямую.
• Одна и та же модель — на индексации и на поиске (иначе векторы несопоставимы).

Метрики качества retrieval на своих данных

Минимум для MVP — 20–50 пар «вопрос → эталонный фрагмент/ответ». Считайте:

• Hit-rate@k — попал ли нужный чанк в top-k.
• Context Recall — насколько полно найденный контекст покрывает эталон (методика RAGAS).
• Faithfulness — не придумала ли модель лишнего поверх цитаты.

Ранний симптом деградации: ответы стали длиннее и «водянистее» — модель компенсирует слабый поиск общими фразами.

Векторная база данных — сердце RAG. Два практичных пути для малого и среднего бизнеса: отдельный Qdrant или расширение PostgreSQL через pgvector.

Qdrant — отдельный векторный движок

Плюсы: встроенный гибридный поиск и RRF, сильная фильтрация по payload, низкая задержка под нагрузкой, удобное масштабирование. Sweet spot — от ~5 млн векторов и сложные метаданные. Документация и обзор возможностей — на qdrant.tech.

pgvector — всё в PostgreSQL

Плюсы: один стек с CRM/аналитикой, ACID, SQL-фильтры и JOIN. Оптимален при до 1–5 млн векторов и умеренной частоте запросов, если Postgres уже есть. Путь «сначала pgvector → потом Qdrant» снижает риск на старте.

Сравнительная таблица

Большинство корпоративных RAG в реальности — меньше 5 млн документов/чанков. Не усложняйте выбор: начните с того, что уже крутится в инфраструктуре.

Ручная перезаливка PDF раз в месяц убивает доверие к RAG. Нужен контент-завод для корпоративной памяти: новый файл → индексация → уведомление → проверка качества.

Сценарий: новый PDF → индексация → уведомление в Telegram

1. Триггер: папка Google Drive / SharePoint / почта юристов.
2. Парсинг и чанкинг (скрипт или n8n).
3. Embeddings → upsert в Qdrant/pgvector.
4. Сообщение в Telegram: «Обновлён регламент X, переиндексировано 142 чанка».
5. Раз в неделю — прогон 20 контрольных вопросов (eval).

MCP-сервер к Qdrant/pgvector из Cursor

MCP (Model Context Protocol) подключает внешние инструменты к Cursor и Claude Code. Официальный mcp-server-qdrant даёт операции поиска и записи в коллекцию — удобно для «памяти проекта» и разработки RAG без постоянного переключения в админку.

Make.com для оркестрации без кода

Make (как и n8n) собирает цепочку: триггер → embeddings → vector store → LLM. Для маркетолога без бэкенда это вход в n8n rag / no-code RAG. Если хотите пройти такие сценарии шаг за шагом с разборами Make, n8n и Cursor — смотрите обучение по автоматизации и вайбкодингу на kv-ai.ru. Гибридный поиск и rerank в чистом no-code чаще дополняют HTTP-модулями к вашему API — закладывайте тонкий backend-слой на этапе роста.

Семь шагов «минимальный RAG за выходные»

1. Собрать 30–50 PDF/FAQ для пилота.
2. Почистить дубликаты, проставить даты в именах файлов.
3. Поднять Postgres + pgvector или Docker Qdrant.
4. Прогнать чанкинг 512 токенов / overlap 15%.
5. Индексировать multilingual-e5 (или аналог).
6. Сделать hybrid + bge-reranker на 30 тестовых вопросах.
7. Обернуть в Telegram-бота или внутренний веб-чат с цитатами.

Плохой чанкинг, устаревший индекс, слабый retrieval

Перегруз контекста и дорогие токены

Не кладите в prompt 30 чанков «на всякий случай». После rerank — 5–8 фрагментов. Следите за суммарной длиной: длинный контекст бьёт по цене и не всегда по качеству (эффект «потерянной середины»).

Безопасны ли RAG-системы? — Да, если ACL на retrieval, логирование, защита от prompt injection и выбор контура данных согласован с юристами. RAG не безопасен «по умолчанию», если в индекс попали все Google Drive без фильтров.

Что проверяли по источникам: инженерные разборы RAG 2026 на Habr (OTUS, Alpina Digital); документация Qdrant; метрики RAGAS; production-кейсы с hybrid search и bge-reranker; рыночные оценки стоимости пилотов в РФ.

Итог. RAG для бизнеса — это не модная аббревиатура, а создание базы знаний, которую можно измерять: чистые документы, грамотный чанкинг, векторный поиск плюс гибридный поиск и реранкинг, выбор Qdrant или pgvector под ваш стек, чат-бот по документам с цитатами и автоматизация через MCP, n8n или Make. Начните с пилота на 50–200 файлах и 30 вопросах — и вы получите не «ещё одну нейросеть», а рабочую корпоративную память с понятным ROI.