Команда задаёт один вопрос в чатах, а ответы расходятся: кто-то цитирует старый регламент, кто-то догадывается. Обычный чат с нейросетью не знает ваших PDF. RAG-база знаний (Retrieval-Augmented Generation) перед ответом ищет фрагменты в документах и цитирует источник. Ниже – workflow пилота за 2–4 недели. Вы проведёте аудит, соберёте pipeline с гибридным поиском, протестируете 20–30 вопросами и подключите чат с эскалацией к человеку.
TL;DR / Быстрый инсайт: RAG – конвейер «найти фрагмент → передать модели → ответить с источником». Качество на ~70% зависит от retrieval и нарезки, не от выбора GPT. Пилот: 50–200 файлов, чанки 256–512 токенов, ChromaDB или Qdrant, hybrid search + rerank, golden dataset 20–30 вопросов. «rag база знаний» – 419 показов/мес, «rag система» – 2125 (Вордстат, июнь 2026).
RAG – архитектура, при которой языковая модель перед генерацией получает релевантные куски из корпоративной базы. Представьте сотрудника с папкой регламентов: он сначала листает нужную страницу, потом формулирует ответ. Embedding – числовой «отпечаток» смысла текста; vector store (векторная база) хранит отпечатки и находит похожие фрагменты за миллисекунды. LLM (языковая модель) только формулирует ответ – знания лежат в документах.
Типичная ошибка – выбрать GPT, не собрав документы. По чек-листам pre-project, RAG стартует с источников, прав доступа и критериев качества – embeddings приходят позже. Запросы «rag как настроить» (53 показа/мес) и «база знаний для ии агента» (47) растут вместе с интересом к корпоративным чат-ботам – но без workflow это остаётся набором разрозненных статей про векторные БД.
Схема pipeline:
Документы → Парсинг → Чанкинг → Embed → Vector DB → [Запрос → Hybrid search → Rerank → Top-K] → Prompt + LLM → Ответ с цитатами → Log → Re-index
1. Проведите аудит источников: что индексировать и кому видно
Выберите один сценарий: FAQ поддержки, HR-регламенты или продуктовый справочник. Не индексируйте всю компанию сразу – multi-domain RAG на старте ломает eval. Соберите 50–200 актуальных документов и назначьте владельца базы – человека, который подтверждает актуальность файла.
- Шаг 1: Список источников: PDF, DOCX, Confluence, Notion, wiki.
- Шаг 2: Исключите дубли, черновики, архив без даты valid_until.
- Шаг 3: Метки ACL: отдел, роль, уровень (hr_only, support_all).
- Шаг 4: Зафиксируйте вопросы, которые сценарий должен закрывать.
Делайте: фильтруйте права в query vector DB, не только в промпте. Не делайте: класть зарплатные ведомости в общий индекс без разметки.
2. Подготовьте корпус: очистка, чанкинг 256–512 токенов и метаданные
Парсинг переводит PDF и DOCX в markdown: убираете колонтитулы, битые таблицы, мусор OCR. Дедупликация – удаление копий одного регламента в разных папках. Чанкинг – нарезка на куски, которые модель «проглотит» за раз. Ориентир для русского корпоративного текста: 256–512 токенов, overlap 10–20% (50–100 токенов). По Novacom, ~60% качества RAG – от нарезки; Yandex Cloud для RU рекомендует проверять 700/300 на своих данных – не копируйте слепо.
Пример LangChain: chunk_size=800, overlap=150 – стартовая точка, но для FAQ режьте мельче. Метаданные на каждый чанк: file_name, section, updated_at, acl, doc_type. Без них не отфильтруете устаревший прайс и не покажете ссылку на источник в ответе пользователю.
Делайте: semantic chunking по разделам регламента. Не делайте: один чанк на 50 страниц.
3. Выберите стек: векторная БД, embeddings и LLM под compliance
Embedding-модель и LLM – разные компоненты. Смена embedding = полная переиндексация. Зафиксируйте модель до первого embed.
| Компонент | PoC | Prod |
|---|---|---|
| Vector DB | ChromaDB (~1000 док.) | Qdrant или pgvector |
| Embeddings | text-embedding-3-small или BGE | Та же модель + регламент |
| LLM | GPT-4o-mini для тестов | 152-ФЗ: YandexGPT / GigaChat |
| Срок | 2–3 недели | 4–6 недель |
PoC на LangChain + Chroma собирают за 2–3 недели; prod с ACL и rerank – 4–6. text-embedding-3-small – порядка $0.02 за 1M токенов, если облако допустимо политикой компании. Self-hosted (свой сервер) – когда данные не должны уходить наружу: Docker с Qdrant + локальные embeddings.
Делайте: pgvector, если PostgreSQL уже есть – меньше сервисов в контуре. Не делайте: менять embedding посреди пилота без плана полной re-index.
4. Соберите RAG-pipeline: hybrid search, rerank и промпт «только по контексту»
Embed чанки → vector store → cron при смене файла. Hybrid search: семантика + BM25 (+5–10% на корп. формулировках). Top-20 → reranker → top-3–5 в LLM. Rerank даёт +10–25% к retrieval; без него часто 70–80% на сложных вопросах, с rerank – ориентир 85–95% на своём eval.
- Шаг 1: Scheduled re-index (cron, n8n или Make).
- Шаг 2: Hybrid vector + BM25.
- Шаг 3: Reranker (Cohere, bge-reranker).
- Шаг 4: ACL-фильтр в query до генерации.
- Шаг 5: Промпт: «Только по контексту. Нет данных – скажи. Цитируй источник.»
Отсекайте cosine similarity ниже ~0.7 – иначе модель получит шум и начнёт додумывать. Логируйте каждый fallback «не нашёл»: это список пробелов в базе, а не повод для галлюцинации. Пять шагов пайплайна по Yandex Cloud: индексация → поиск → промпт → генерация → проверка – последний шаг часто забывают, а он ловит выдумки.
Делайте: подключите RAG как tool в ИИ-агенте n8n. Не делайте: multi-agent на первом этапе.
5. Протестируйте на 20–30 реальных вопросах и настройте пороги
Golden dataset – таблица пар «вопрос → эталонный ответ + источник». Пилот – 20–30 вопросов из реальной поддержки или HR; prod – 50–100. Без датасета вы не отличите плохой чанкинг от плохой модели. Метрики: faithfulness (ответ не врёт сверх контекста), context precision (найденные чанки по делу). KPI после rerank: Recall@10 ≥ 90%, Precision@3 ≥ 70% – целевые ориентиры AGmind, не гарантия вендора. Прогоняйте eval после каждого изменения chunk_size или top-K.
Делайте: каверзные вопросы, синонимы, запросы вне базы. Не делайте: тест только на «привет».
6. Подключите канал: Telegram, веб-чат, Slack и эскалация к человеку
Telegram, виджет на сайте или Slack: запрос → RAG → ответ с цитатой. Добавьте оценку «полезно / не полезно» и кнопку «позвать оператора».
Human-in-the-loop обязателен на компенсациях, увольнениях, юридических темах. Менее 2,5% сложных неструктурированных задач завершаются полностью без человека – закладывайте эскалацию, а не «бот заменит отдел». Триггеры: низкая confidence retrieval, пустой контекст, стоп-слова (суд, штраф, персональные данные). Оператор получает диалог и найденные фрагменты – не начинает с нуля.
Делайте: показывайте ссылку на документ. Не делайте: выдавать RAG за юриста без проверки.
7. Пройдите чек-лист prod: индексация, логи, мониторинг галлюцинаций
- Re-index по расписанию и при загрузке файла
- Owner базы с SLA на актуализацию
- Логи: latency, доля «нет данных», топ промахов
- Drift eval раз в спринт на golden dataset
- Алерт при росте негативных оценок
- Версия embedding и индекса задокументирована
RAG обновляет знания через re-index при загрузке нового файла; fine-tuning – через переобучение модели. Для меняющихся прайсов и регламентов RAG дешевле и прозрачнее: видно, из какого PDF взята цитата. Если в корпус входит публичный контент сайта, сверьте структуру с GEO-оптимизацией под нейропоиск – retrieval найдёт актуальные формулировки.
Что делать дальше
- Один сценарий, 50 документов с ACL.
- PoC Chroma + embeddings за выходные.
- 25 вопросов golden dataset из реальных обращений.
- Hybrid + rerank, прогон eval.
- Канал с эскалацией; в курсе по Make.com – RAG и агенты на no-code.
Материал проверен: эксперт Артур Хорошев (CEO Maya AI, практик AI-агентов).
Достоверность данных: чанкинг, метрики retrieval и фразы Вордстат – по Novacom, Yandex Cloud, AGmind, июнь 2026.
Частые вопросы
RAG как настроить с нуля для компании?
Аудит документов → чанкинг → vector DB → индексация → hybrid retrieval → тест 20–30 вопросами → канал с эскалацией. Не начинайте с GPT.
Чем RAG отличается от fine-tuning?
Fine-tuning переучивает модель; RAG подставляет актуальные фрагменты в каждый запрос. Для меняющихся регламентов – re-index, не переобучение.
Какая векторная БД лучше: Qdrant, pgvector или Chroma?
Chroma – PoC до ~1000 док. Qdrant – prod с ACL. pgvector – если PostgreSQL уже есть.
Сколько документов для первого пилота?
50–200 файлов на один сценарий. Лучше 80 выверенных регламентов, чем 2000 с дублями.
Нужен ли reranker и hybrid search?
На корп. формулировках – да, если baseline промахивается. Сначала eval без них, потом добавляйте.
Как проверить, что RAG не галлюцинирует?
Golden dataset, промпт «нет данных – скажи», порог similarity ~0.7, цитаты источника, ручная выборка 10 ответов в неделю.
Можно ли RAG локально и соблюсти 152-ФЗ?
Да: локальные embeddings, своя vector DB, YandexGPT или GigaChat, ACL на query. Персональные данные – только с правовым основанием.
