RAG (Retrieval-Augmented Generation) — технология, которая позволяет AI-модели отвечать на вопросы по корпоративным документам. Сотрудник задаёт вопрос на естественном языке, система находит ответ в регламентах, инструкциях, отчётах и переписке за секунды. Без RAG эти знания разбросаны по десяткам папок, почтовых ящиков и Google Docs, и найти нужную информацию бывает невозможно.
AIAI.BY внедрила RAG-системы для 12 белорусских компаний за последний год — от IT-аутсорсинга на 300 человек до производственного предприятия с 50-летним архивом технической документации. Главный урок: RAG работает, но 80% успеха определяется подготовкой данных, а не выбором модели. В этом руководстве расскажем, как пройти весь путь от чистого листа до работающей системы, основываясь на реальных внедрениях.
Архитектура RAG-системы: из чего она состоит
RAG-система для корпоративной базы знаний включает четыре ключевых компонента. Первый — хранилище документов: папки с PDF, DOCX, TXT, HTML, Confluence-страницы, Google Docs. Второй — конвейер индексации: скрипт, который читает документы, разбивает на фрагменты (chunks), генерирует для каждого фрагмента числовой вектор (embedding) и сохраняет в векторную базу данных. Третий — поисковый движок: при запросе пользователя система генерирует embedding запроса и ищет в базе наиболее похожие фрагменты документов. Четвёртый — генератор ответа: LLM (GPT-5 или Claude) получает найденные фрагменты и формулирует ответ со ссылками на источники.
Для малых и средних компаний (до 50 000 документов) мы рекомендуем использовать облачную векторную базу данных — это снижает затраты на инфраструктуру. Через AIAI.BY доступны модели для embeddings (Text Embedding 3 Large), а векторную базу можно развернуть в Pinecone, Qdrant Cloud или Weaviate. Для компаний, которым критична локализация данных, Qdrant можно запустить on-premise на белорусских серверах.
Типичная архитектура обрабатывает запрос за 2–5 секунд: 200 мс на генерацию embedding запроса через AIAI.BY, 100–500 мс на поиск в векторной базе, 1–3 секунды на генерацию ответа с помощью LLM. Для сравнения: ручной поиск ответа в корпоративных документах занимает 10–30 минут. По нашему опыту, после внедрения RAG количество обращений к коллегам с вопросами «а где найти...» снижается на 40–60%.
Подготовка документов: 80% успеха RAG
Качество RAG-системы на 80% определяется качеством подготовки документов. «Мусор на входе — мусор на выходе» — это правило работает и здесь. Три ключевых этапа подготовки: аудит, очистка и chunking (разбивка на фрагменты).
Аудит: соберите все источники знаний — папки на сервере, Confluence, Google Drive, SharePoint, Notion. Определите, какие документы актуальны, а какие устарели. Удалите дубликаты и устаревшие версии. Типичная ошибка — загрузить «всё подряд», включая черновики и документы 5-летней давности. Это засоряет базу и снижает точность ответов. При одном из наших внедрений компания хотела загрузить 80 000 файлов с файлового сервера. После аудита оказалось, что актуальных документов — 12 000. Остальные — дубликаты, черновики и устаревшие версии. Точность RAG с очищенной базой оказалась на 23% выше, чем с «полной».
Очистка: приведите документы к единообразному формату. PDF с отсканированными страницами нужно пропустить через OCR (Tesseract или ABBYY для русского языка). Таблицы в Excel конвертируйте в структурированный текст. Презентации PowerPoint — извлеките текст со слайдов и заметки докладчика. Для каждого документа сохраните метаданные: дату создания, автора, отдел, тип документа. Без метаданных не получится фильтровать результаты и давать ссылки на источники.
Chunking — разбивка документов на фрагменты — самый критичный этап. Оптимальный размер фрагмента: 500–1000 токенов (1–2 абзаца). Слишком маленькие фрагменты теряют контекст, слишком большие снижают точность поиска. Используйте перекрытие (overlap) в 100–200 токенов между соседними фрагментами, чтобы не потерять информацию на стыках. Для структурированных документов (инструкции с заголовками) разбивайте по секциям, а не по фиксированному количеству символов.
Выбор модели для embeddings и генерации
Для embeddings (векторного представления текста) мы рекомендуем Text Embedding 3 Large от OpenAI — доступен через AIAI.BY. Модель генерирует вектор размерностью 3072, что обеспечивает высокую точность поиска на русском языке. Стоимость: 0.44 BYN за 1M токенов. Для базы из 50 000 фрагментов (средняя корпоративная база) одноразовая индексация обойдётся в 15–25 BYN. Переиндексация при обновлении документов — 1–3 BYN/месяц.
Альтернатива: если бюджет ограничен или нужна локальная обработка, можно использовать open-source модели BGE-M3 или E5-Large-V2. Качество на русском языке на 8–12% ниже, чем у Text Embedding 3 Large, но стоимость — нулевая (запускается на вашем сервере). Для компаний с требованиями по локализации данных это может быть единственный вариант.
Для генерации ответов оптимальный выбор зависит от задачи. Claude Sonnet 4.5 лучше всего следует инструкциям и реже «галлюцинирует» — выдумывает информацию, которой нет в предоставленных фрагментах. GPT-5 быстрее и дешевле, подходит для систем с высоким трафиком запросов. DeepSeek V3.2 — бюджетный вариант для внутренних баз знаний с невысокими требованиями к точности. По замерам AIAI.BY (Q1 2026), Claude Sonnet 4.5 на задаче «ответ по корпоративным документам» даёт точный ответ в 93% случаев, GPT-5 — в 89%, DeepSeek V3.2 — в 82%. Все модели доступны через единый API AIAI.BY.
Пошаговая реализация через AIAI.BY
Шаг 1: Подготовьте документы. Сконвертируйте всё в текстовый формат — для PDF используйте библиотеки PyMuPDF или pdfplumber (Python), для DOCX — python-docx. Разбейте на фрагменты с помощью библиотеки LangChain (RecursiveCharacterTextSplitter с chunk_size=800, chunk_overlap=150). Для каждого фрагмента сохраните метаданные: название документа, дату, раздел.
Шаг 2: Создайте embeddings через API AIAI.BY. Отправьте каждый фрагмент в endpoint /embeddings с моделью text-embedding-3-large. Пример: response = client.embeddings.create(model="text-embedding-3-large", input="текст фрагмента"). Сохраните полученные векторы и метаданные в векторную базу данных. Для 10 000 документов (примерно 50 000 фрагментов) индексация занимает 1–2 часа и стоит около 30–50 BYN.
Шаг 3: Реализуйте поиск и генерацию. При запросе пользователя: (1) создайте embedding запроса, (2) найдите 5–10 наиболее похожих фрагментов в векторной базе, (3) отправьте их в LLM вместе с вопросом. Промпт для генерации: «Ты — ассистент компании [Название]. Ответь на вопрос сотрудника, используя ТОЛЬКО информацию из предоставленных фрагментов документов. Если ответа нет в документах — скажи об этом прямо. Укажи источник ответа.» Для LLM рекомендуем Claude Sonnet 4.5 (точнее следует инструкциям) или GPT-5 (быстрее и дешевле).
Шаг 4: Разверните интерфейс. Для внутреннего использования подойдёт Telegram-бот или Slack-интеграция — сотрудники задают вопрос в чат и получают ответ за 3–5 секунд. Для более сложных сценариев — веб-интерфейс с историей вопросов, возможностью оценки ответов и ссылками на исходные документы. Мы рекомендуем начать с Telegram-бота: это быстрее всего в разработке (2–3 дня) и привычно для белорусских пользователей.
Реальные кейсы RAG-внедрений в Беларуси
Кейс 1: IT-компания, 300 сотрудников. Проблема: новые разработчики тратили 2–3 недели на изучение внутренней документации — архитектурных решений, стандартов кода, процессов деплоя. Решение: RAG-система на базе Confluence-документации (4 500 страниц) + Slack-бот. Результат: время онбординга сократилось до 5 дней. Бот обрабатывает 120 вопросов в день, 87% ответов — корректные без привлечения человека. Стоимость эксплуатации: 65 BYN/месяц (embeddings + GPT-5 для генерации).
Кейс 2: Производственное предприятие, 800 сотрудников. Проблема: 50 лет технической документации (ГОСТы, техрегламенты, инструкции по эксплуатации) на бумаге и в сканах. Инженеры тратили часы на поиск нужной спецификации. Решение: оцифровка через ABBYY FineReader, RAG-система с фильтрацией по типу документа и году. Результат: время поиска спецификации — 15 секунд вместо 30–60 минут. Индексировано 23 000 документов, 67 000 фрагментов. Стоимость индексации: 45 BYN (одноразово), эксплуатация: 40 BYN/месяц.
Кейс 3: Юридическая компания, 45 юристов. Проблема: поиск прецедентов и формулировок в базе из 8 000 договоров. Решение: RAG с гибридным поиском (vector + keyword) и метаданными (тип договора, отрасль, дата). Модель — Claude Sonnet 4.5 для максимальной точности. Результат: юристы экономят 6–8 часов в неделю на поиске. Система находит релевантные прецеденты с точностью 91%. Стоимость: 120 BYN/месяц.
Типичные ошибки при внедрении RAG
Ошибка 1: загрузить всё без фильтрации. Компании часто хотят «загрузить всё и пусть AI разберётся». Результат — низкая точность, много нерелевантных ответов. RAG-система не умеет определять актуальность документа. Если в базе есть инструкция 2019 года и инструкция 2025 года на одну тему, система может выдать устаревшую версию. Решение: обязательный аудит и дедупликация перед индексацией.
Ошибка 2: неправильный размер чанков. Слишком маленькие фрагменты (100–200 токенов) теряют контекст. Вопрос «какие документы нужны для заключения договора?» может получить ответ из фрагмента, где перечислены документы, но без указания типа договора. Слишком большие фрагменты (2000+ токенов) снижают точность поиска — релевантная информация разбавлена нерелевантным текстом. Оптимум — 500–1000 токенов.
Ошибка 3: отсутствие метаданных. Без метаданных (дата, автор, отдел, тип документа) невозможно фильтровать результаты и давать ссылки на источники. Сотрудник получает ответ, но не знает, откуда он взят и насколько актуален. Метаданные также позволяют ограничить поиск конкретным отделом или типом документа — это критически важно для компаний с разными уровнями доступа.
Ошибка 4: не тестировать и не измерять. Запустили RAG, сотрудники пользуются, но никто не знает, в скольких процентах случаев ответы корректны. Без метрик невозможно улучшать систему. Создайте тестовый набор из 50–100 реальных вопросов сотрудников с эталонными ответами и прогоняйте его после каждого изменения.
Измерение качества и оптимизация
Три ключевые метрики RAG-системы. Precision@K: какая доля из K найденных фрагментов действительно релевантна вопросу. Если K=5 и 3 из 5 фрагментов полезны — Precision@5 = 60%. Целевой показатель: 70%+. Recall: находит ли система все релевантные фрагменты. Если в базе есть 4 подходящих фрагмента и система нашла 3 из них — Recall = 75%. Целевой показатель: 80%+. Answer Quality: процент корректных и полных ответов LLM по оценке экспертов. Целевой показатель: 85%+.
Типичные проблемы и решения. Система не находит нужный фрагмент: увеличьте K с 5 до 10, пересмотрите chunking, добавьте гибридный поиск (vector + keyword через BM25). Ответ LLM неточен: уточните системный промпт, добавьте few-shot примеры, попробуйте Claude вместо GPT. Слишком много нерелевантных результатов: добавьте фильтрацию по метаданным, настройте порог similarity score (рекомендуем отсекать результаты с cosine similarity ниже 0.7).
По опыту 12 внедрений AIAI.BY, первая версия RAG-системы выдаёт точные ответы в 70–75% случаев. После двух-трёх итераций оптимизации (улучшение chunking, настройка промптов, добавление метаданных) точность достигает 90–95%. Это занимает 2–4 недели работы одного разработчика. Если застряли на этапе оптимизации — напишите нам в AIAI.BY, поможем разобраться.
Стоимость RAG-системы для белорусской компании
Разобьём расходы на три категории. Одноразовые: оцифровка документов (если бумажные) — от 500 BYN за 10 000 страниц при использовании ABBYY, бесплатно если уже в электронном виде. Индексация (embeddings) — 15–50 BYN для базы из 10 000–50 000 документов. Разработка бота/интерфейса — от 2 000 BYN (Telegram-бот) до 8 000 BYN (веб-интерфейс с авторизацией).
Ежемесячные: API AIAI.BY для embeddings и генерации — от 30 BYN (малая компания, 200 запросов/день) до 200 BYN (средняя компания, 1000 запросов/день). Векторная база данных — от 0 BYN (Qdrant self-hosted) до 50 BYN (облачные сервисы). Переиндексация при обновлении документов — 1–5 BYN/месяц.
ROI: по нашим кейсам, RAG-система окупается за 1–3 месяца. Основная экономия — время сотрудников на поиск информации. В компании из 100 человек, где каждый сотрудник тратит 30 минут в день на поиск в документах, RAG экономит 2 500 человеко-часов в год. При средней стоимости часа работы 15 BYN — это 37 500 BYN/год экономии при расходах на RAG в 1 500–3 000 BYN/год.