Главная → Блог → RAG для базы знаний RAG для корпоративной базы знаний: от концепции до production Михаил Кадочников · 12 августа 2026 · 12 мин чтения 01 Почему обычный ChatGPT не решает задачу внутренней базы знаний Проблема простой: ты говоришь ChatGPT "ответь на вопрос про нашу компанию" — он не может. Его обучили на данных до April 2024, а ваша внутренняя политика, процессы, документы он не знает. Нужно либо добавить всю информацию в промпт (но контекстное окно конечно), либо... использовать RAG. RAG — это Retrieval-Augmented Generation. На человеческом: это система, которая находит релевантные документы из вашей базы и подает их в LLM как контекст. LLM читает контекст и дает ответ на основе вашей информации, а не общего знания. Пример: "Какая у нас политика по отпускам?" ChatGPT один не знает. RAG находит в вашей базе документ "Политика_отпусков.pdf", передает его в промпт, ChatGPT читает и отвечает точно, с ссылкой на документ. Из 50+ проектов за 20+ лет: RAG — это инструмент №1 для компаний, которые хотят внутренний AI-ассистент. Простая реализация (2-8 недель), сразу видны результаты (сотрудники начинают использовать, хотя бы потому что это удобнее чем искать документ в Confluence). 02 Архитектура RAG: как это работает изнутри Типичная RAG система состоит из 4 компонентов: 1. Embedding Model (модель векторизации) Берет текст (документ, вопрос) и превращает его в вектор чисел (768-4096 чисел, зависит от модели). Семантически похожие тексты получают похожие векторы. Примеры моделей: multilingual-e5-large (Hugging Face) — хорошо работает с русским, 1024 размерности, free text-embedding-3-large (OpenAI) — лучшее качество, $0.13 за 1M токенов GigaChat embeddings (Яндекс) — локальное решение для 152-ФЗ, хорошее качество Рекомендация: Для MVP стартуй с multilingual-e5-large (бесплатная, хороший результат). Потом, если нужна точность, переходи на OpenAI embeddings. 2. Vector Database (хранилище векторов) Хранит все векторы ваших документов с индексированием для быстрого поиска. При запросе за O(1) находит топ-k самых похожих векторов. Главные DB: ChromaDB — локальный, простой, идеален для <200K документов Qdrant — более мощный, масштабируется до миллионов, можно деплоить self-hosted Pinecone — облачный, абсолютно не нужно управлять, но платный Weaviate — гибридный поиск (семантический + keyword), хорош для сложных кейсов 3. Retriever (поисковик) Берет вопрос пользователя, векторизует его той же embedding моделью, ищет в vector DB топ-k (обычно 3-5) самых похожих документов. Это происходит за 50-500ms в зависимости от размера базы. 4. LLM (языковая модель) Получает вопрос + найденные документы как контекст, генерирует ответ. Может быть ChatGPT, GigaChat, Claude или любая другая. Качество ответа зависит и от качества найденных документов (garbage in — garbage out). Поток запроса: Пользователь: "Как оформить отпуск?" → Embedding: вопрос превращается в вектор → Retriever: находит 3 документа из базы знаний → LLM: читает контекст, генерирует точный ответ с ссылками → Пользователь получает ответ за 1-2 секунды. Полная архитектура на картинке (ASCII) ┌─────────────────────────────────────────────────────────────────┐ │ RAG Pipeline │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ User Input: "Какая политика по отпускам?" │ │ ↓ │ │ Embedding Model (e5-large) │ │ ↓ [вектор 1024 чисел] │ │ Vector DB (Qdrant/ChromaDB) │ │ ↓ [поиск топ-3 похожих] │ │ Retrieved Docs: │ │ 1. Политика_отпусков.pdf (similarity: 0.89) │ │ 2. HR_Manual.docx (similarity: 0.76) │ │ 3. Benefits.md (similarity: 0.71) │ │ ↓ │ │ LLM Prompt: │ │ "На основе следующих документов ответь на вопрос: │ │ [полный текст 3 документов] │ │ Вопрос: [исходный вопрос]" │ │ ↓ │ │ Response: "Согласно нашей политике (Политика_отпусков.pdf), │ │ базовый отпуск 28 дней + 7 дней за выслугу лет..." │ │ │ └─────────────────────────────────────────────────────────────────┘ 03 Пошагово: как внедрить RAG на вашу базу знаний за 4-8 недель Этап 1 (Неделя 1): Сбор и подготовка документов Собираешь все документы базы знаний: PDF, DOCX, PPTX, Markdown из Confluence/Notion Формат: обычно 100-500 документов, размер 500KB-100MB всего Очищаешь от шума (невидимые символы, мусорные странички) Структурируешь: добавляешь метаданные (тип документа, дата, раздел) Выход: папка /docs с чистыми, структурированными документами Этап 2 (Неделя 2-3): Настройка чанкинга и embedding Разбиваешь документы на чанки (512-1024 токена, overlap 100-200 токенов) Выбираешь embedding модель (рекомендую multilingual-e5-large для MVP) Запускаешь embedding на всю базу (2-4 часа даже на большую базу) Загружаешь векторы в vector DB (ChromaDB для простоты на этом этапе) Выход: vector DB с 500K-5M векторов, готовая к поиску Этап 3 (Неделя 4-5): Разработка RAG система Пишешь retriever: функцию поиска в vector DB по вопросу Интегрируешь LLM (ChatGPT, GigaChat или локально Llama) Пишешь промпт с инструкцией для LLM (как читать контекст, как форматировать ответ) Тестируешь на примерах: 10-20 типовых вопросов из фактических запросов сотрудников Выход: рабочая RAG система (Python скрипт или REST API) Этап 6 (Неделя 6-7): Интеграция и развертывание Оборачиваешь RAG в Telegram-бот, Slack-интеграцию или веб-интерфейс Тестируешь с пилот-группой сотрудников (5-10 человек) Собираешь фидбек: что работает, что нет Доработка промптов и стратегии чанкинга по фидбеку Выход: готовое решение, которое используют реальные люди Этап 8 (Неделя 8): Мониторинг и оптимизация Логируешь все запросы и ответы (важно для анализа) Анализируешь: на какие вопросы система отвечает хорошо, на какие плохо Итерируешь: улучшаешь промпты, чанкинг, добавляешь новые документы Выход: оптимизированная система с 85-92% accuracy на типовых вопросах Совет из практики: Не тесть в вакууме. На неделе 4-5 уже запускай бета с 10 сотрудниками. Фидбек реальных людей стоит больше, чем ваше мнение о качестве. 04 Выбор vector database: ChromaDB vs Qdrant vs Pinecone ChromaDB Самый простой вариант для старта. Локальная база, встраивается прямо в Python приложение. Минусы: медленнее на больших объемах (100K+ документов), нет встроенного масштабирования Плюсы: нулевая настройка, работает локально (важно для 152-ФЗ), бесплатно Рекомендую для: MVP, компании до 200 сотрудников, стартапы на бюджете Стоимость: 0 рублей/месяц Qdrant Профессиональный vector database. Можно деплоить self-hosted или использовать облако. Плюсы: быстро даже на 10M+ векторов, фильтрация по метаданным, скалируется, есть UI Минусы: нужна настройка DevOps (если self-hosted), платить за облако если use cloud Рекомендую для: компании с 500+ сотрудников, большие базы знаний (>500K документов), серьезные требования к производительности Стоимость (self-hosted): 0 рублей (но DevOps время на настройку). Облако: $0.12-0.99 за 1GB/месяц Pinecone Облачное решение, ничего не нужно администрировать. Плюсы: абсолютно управляемое, быстро, масштабируется автоматически, хороший UI Минусы: платное, привязка к облаку, потенциальные проблемы с 152-ФЗ (данные в США) Рекомендую для: компании, которым некогда заниматься DevOps, готовы платить за удобство Стоимость: $0.25 за 1M vector units/месяц + $1 за индекс/месяц = примерно 5-10K рублей/месяц для среднего use case Мой выбор для вашей компании: Если сотрудников < 200 и нет требований 152-ФЗ: Pinecone (самый быстрый path to value) Если требуется 152-ФЗ compliance: Qdrant self-hosted на своем сервере Если бюджет критичен: ChromaDB (потом мигрируешь на Qdrant) Кейс из практики: Компания с 500 сотрудников внедрила RAG на ChromaDB (экономили бюджет). За месяц трафик вырос до уровня, где ChromaDB начала быть медленная (ответы 3-5 секунд). Мигрировали на Qdrant за 3 дня, результат: ответы 200-500ms. Стоимость Qdrant облака: 200 рублей/месяц, но экономия на сниженной нагрузке на серверы была 5000+ рублей/месяц. 05 Стратегии чанкинга: как разбивать документы для лучшего поиска Наивный подход (плохо): просто разбиваешь текст по 1024 символам. Результат: может разбить предложение посередине, потеряется контекст. Правильный подход: 1. Разбивка по семантическим границам Разбиваешь по параграфам, не посередине текста Хранишь заголовок документа с каждым чанком (контекст) Размер чанка: 512-1024 токена (не превышай, иначе embedding будет урезать) 2. Overlap между чанками Добавляешь 10-20% overlap (последние 50-100 слов предыдущего чанка повторяются в начале следующего) Результат: не потеряешь информацию на границе чанков 3. Метаданные Сохраняй с каждым чанком: исходный документ, раздел, дату последнего обновления Используй метаданные для фильтрации при поиске (например, "только из актуальных документов за 2026 год") Пример правильного чанкинга (PDF документ "Политика_отпусков.pdf"): Документ: "Политика_отпусков.pdf" Раздел: "2. Виды отпусков" Чанк 1: "Заголовок: Политика_отпусков.pdf / 2. Виды отпусков Текст: Основной оплачиваемый отпуск предоставляется работникам в объеме 28 календарных дней в год в соответствии с ТК РФ. Дополнительный отпуск предоставляется в зависимости от категории работника... [последние 50 слов чанка 1 для overlap]" Метаданные: - doc_name: "Политика_отпусков.pdf" - section: "2. Виды отпусков" - updated: "2026-03-01" - source_page: 2 Инструмент для автоматизации чанкинга: Используй LangChain (Python) или Llama-Index. Они автоматически делают семантический чанкинг. Команда: 5-10 строк кода, результат куда лучше, чем ручной чанкинг. 06 Метрики качества: как измерить, что RAG работает хорошо Нельзя просто запустить и забыть. Нужны метрики, чтобы отслеживать качество. Recall (полнота) Из всех релевантных документов, сколько retriever нашел? Рассчитываешь вручную на тестовом наборе (50-100 вопросов). Пример: на вопрос "Какой отпуск в компании?" релевантные документы: Политика_отпусков.pdf, HR_Manual.pdf (всего 2). Retriever нашел 1 из 2 = Recall 50%. Целевое значение: 80-95% (если ниже 70%, это плохо). Precision (точность) Из найденных retriever'ом документов, сколько реально релевантны? Пример: retriever нашел 5 документов, из них 4 релевантны = Precision 80%. Целевое значение: 70-90%. Faithfulness (достоверность) LLM не выдумывает информацию, которой нет в найденных документах? Проверяешь вручную. Пример: вопрос "Какой максимальный отпуск?", документ говорит "28 дней", LLM ответил "28 дней" = faithfulness 100%. Если LLM добавил "и еще 7 дней за выслугу" (которого в документе нет) = faithfulness 0%. Целевое значение: 90-99%. User Satisfaction Опрашиваешь пользователей: помогла ли система найти ответ? Обычно 1-5 звезд. Целевое значение: 4.0+ из 5 звезд. Реальная метрика: На одном проекте (компания 150 сотрудников, 300 документов базе знаний) внедрили RAG. За первый месяц: Recall 87%, Precision 82%, Faithfulness 94%, User Satisfaction 4.2/5. На 2 месяце, после оптимизации: Recall 92%, Precision 88%, Faithfulness 97%, User Satisfaction 4.5/5. 07 Case study: как компания сэкономила 15 часов в неделю на ответах на вопросы Компания: SaaS стартап, 50 сотрудников, есть внутренняя база знаний (Confluence с 200 статьями). Проблема: Каждый день в Slack переписка: "Как оформить отпуск?", "Какой у нас процесс найма?", "Как работает реимбурс?". На ответы HR и Team Lead тратят 2-3 часа в день. Люди вроде знают информацию, просто лень искать в Confluence. Решение: RAG на базе знаний + Slack-интеграция. Сотрудник пишет в приватный Slack-чат бот: "@KnowledgeBot как оформить отпуск?" — бот находит в базе документ "Оффер_отпусков.md", пропускает через ChatGPT, отвечает за 2-3 секунды. Внедрение: Неделя 1: сбор документов из Confluence (2 часа работы) Неделя 2-3: настройка RAG + Slack бот (40 часов разработчика) Неделя 4: тестирование и доработка (20 часов) Всего: 62 часа разработки ≈ 150K рублей Результаты за первые 3 месяца: Объем вопросов в Slack от сотрудников: -80% (люди просто спрашивают бота) Часов в неделю, которые HR/Lead экономят: 15 часов (3 часа × 5 дней) Стоимость зарплаты этих 15 часов: 150K рублей/месяц (на среднюю зарплату 200K/месяц = 25 часов/неделю = 10K/час) Экономия за 3 месяца: 450K рублей ROI: 450K / 150K = 3x за 3 месяца Дополнительный бонус: сотрудники стали довольнее (не нужно ждать ответ у HR), документы всегда актуальные (обновляешь в Confluence → RAG тут же видит новую версию). Вывод из кейса: RAG окупается за 1-3 месяца в компаниях от 50+ сотрудников с развитой базой знаний (100+ документов). Инвестиция 100-300K, возврат 400K-1M в год. FAQ Часто задаваемые вопросы Чем RAG отличается от простого LLM? LLM работает только с информацией, которая была в его обучающих данных. RAG добавляет к LLM систему поиска (embedding + vector DB), которая находит релевантные документы из вашей базы и передает их в промпт. Результат: LLM дает ответы, основанные на вашей информации, а не на общем знании. Какой vector database выбрать: Qdrant, Pinecone или ChromaDB? ChromaDB — самый простой для старта (локальный, легко деплоится), подходит для 50K-200K документов. Qdrant — лучше по скорости и масштабируемости, рекомендую для 500K+ документов. Pinecone — облачное решение, самое простое в поддержке, но требует платежей ($0.25 за 1M vector units/месяц). Как правильно разбивать документы на чанки? Оптимальный размер чанка: 512-1024 токена (для embedding). Стратегия: разбиваешь по параграфам (не посередине предложения), добавляешь контекст (заголовок, параграф до/после). Overlap между чанками: 10-20% для лучшей связности. Тестируй на своих данных — не всегда универсальный подход работает. Можно ли обновлять базу знаний в режиме real-time? Да, все современные vector DB поддерживают добавление/удаление векторов на лету. Но нужно учитывать: embedding новых документов занимает время (1K документов × 1-2 сек = 15-30 минут). Для real-time обновлений обычно используют queue (Celery, RabbitMQ) и фоновые worker'ы. Требуется ли обучение команде при внедрении RAG? Если это Slack-интеграция или веб-интерфейс — минимально (просто "напиши вопрос боту"). Если сложная интеграция в систему — то да, 30-60 минут обучения по работе с новым инструментом. Готов обсудить вашу задачу Отвечу в течение 2 часов. Бесплатная оценка проекта за 24 часа. Написать в Telegram WhatsApp mk@cybergroup.su +7 (963) 275-29-83