RAG для бизнеса: практическое руководство по внедрению
Компания покупает подписку на ChatGPT, сотрудники месяц носят туда вопросы, а потом возвращаются к поиску по папкам: модель уверенно отвечает по общим знаниям и не знает ни ваших цен, ни условий договоров.…
Компания покупает подписку на ChatGPT, сотрудники месяц носят туда вопросы, а потом возвращаются к поиску по папкам: модель уверенно отвечает по общим знаниям и не знает ни ваших цен, ни условий договоров. Разрыв закрывает RAG — подход, при котором языковая модель не вспоминает, а ищет ответ в ваших документах и цитирует источник. ИИ для разработки таких контуров сегодня занимает больше половины проектов в нашей практике: заказчикам нужен не «умный чат», а сотрудник, который знает регламенты.
В 2026 году технология перестала быть экзотикой: векторный поиск, гибридные ранжировщики и переранжирование доступны в готовых библиотеках. Дорого и долго делает не сам поиск, а подготовка документов и приёмка качества. Ниже — как устроен контур, где он окупается, сколько стоит и какие грабли ждут на четвёртой неделе проекта. Ии для разработки такого контура нужен не столько программист, сколько человек, умеющий разговаривать с бизнесом.
Ключевые выводы
- RAG отвечает по вашим документам с ссылкой на источник: доля ответов с корректной цитатой в промышленных системах — 88–95%.
- Пилот на одном наборе документов занимает 4–6 недель и стоит 350–700 тыс. ₽; корпоративная база знаний с правами доступа — 1,2–3,2 млн ₽.
- Эксплуатация обходится в 25–80 тыс. ₽ в месяц: векторная база, токены, переиндексация и работа инженера над качеством.
- База знаний из 1 000 документов собирается 2–4 недели; если документы в сканах без текстового слоя, добавьте ещё 150–350 тыс. ₽ на OCR и разметку.
- RAG дешевле дообучения в 5–15 раз на старте и обновляется за часы: поменяли прайс — переиндексировали один раздел, модель не переобучали.
- Контур не спасает от плохих документов: если в регламентах три противоречащие версии, система честно процитирует все три.
Что такое RAG и почему без него модель врёт
RAG (Retrieval-Augmented Generation) — это схема, в которой модель сначала ищет релевантные фрагменты в базе знаний, а затем формирует ответ только по ним, со ссылками на источник. Она не хранит ваши данные в весах и не «запоминает» их: каждый ответ собирается заново из найденных кусков. Чем этот путь отличается от дообучения модели, разобрано в материале LLM-разработка.
Конвейер выглядит так: документы разбираются на фрагменты по 300–800 токенов с перекрытием, каждый фрагмент превращается в вектор и попадает в базу (PostgreSQL с расширением pgvector, Qdrant или Milvus). При вопросе система ищет 20–50 ближайших фрагментов, переранжирует их и отдаёт в модель 3–7 лучших. Модель пишет ответ и обязана сослаться на конкретный документ и страницу.
Два режима поиска почти всегда работают вместе: векторный ловит смысл («как вернуть товар», даже если в документе написано «порядок возврата»), полнотекстовый — точные артикулы, номера приказов и аббревиатуры. Гибридный вариант даёт прирост точности на 8–15 процентных пунктов относительно чистого векторного поиска.
Отдельно стоит вопрос, где живёт модель. YandexGPT и GigaChat удобны юридически и быстро подключаются, открытые модели на своих серверах (Qwen, Llama-класс) дают контроль над данными и предсказуемую стоимость при большом объёме. Разработка ии решений начинается с выбора модели — не религия, а расчёт: при 30 тыс. запросов в месяц разница в цене между облаком и своим GPU-сервером составляет 40–90 тыс. ₽. Создание ии модели с нуля под эту задачу почти никогда не требуется — тонкая настройка готовой модели решает те же задачи дешевле на порядок.
Где RAG окупается, а где нет
Прямой ответ: контур окупается там, где сотрудники или клиенты регулярно ищут ответ в большом объёме текста, а ошибка стоит денег. Три сценария с самой быстрой отдачей.
- Поддержка клиентов по продуктовой документации. Агент отвечает на 60–75% вопросов, операторы занимаются только исключениями. При 2 500 обращений в месяц экономия — 120–180 тыс. ₽.
- Внутренняя база знаний. Регламенты, инструкции, кадровые положения. Высвобождает 3–5 часов в неделю на сотрудника, при штате 30 человек это 0,7–1,2 ставки.
- Работа с договорами и тендерной документацией. Поиск условий, сроков, штрафов по 200-страничному договору — минуты вместо часа. Юрист приносит больше пользы на переговорах, чем на поиске.
Не сработает RAG в трёх случаях. Первый: документов меньше 20 и они умещаются в промпт — тогда дешевле положить их целиком. Второй: знания живут в головах и не записаны, строить нечего. Третий: нужен не поиск, а расчёт — если ответ вычисляется по формулам в 1С, RAG не поможет, нужна интеграция с учётной системой.
Есть и смежный сценарий, где контур приносит пользу разработчикам: индексация внутренних стандартов разработки 1С и документации по типовым конфигурациям. Новичок в команде находит ответ за минуту, а не идёт с вопросом к ведущему программисту.
Как устроен проект: этапы и состав работ
Прямой ответ: проект идёт четырьмя этапами — аудит данных, подготовка корпуса, сборка поиска, приёмка на эталонных вопросах. Пропуск любого из них возвращает вас на исходную через месяц.
| Этап | Срок | Стоимость | Результат |
|---|---|---|---|
| Аудит документов и сценариев | 1–2 недели | 80–180 тыс. ₽ | Карта источников, 50–100 эталонных вопросов |
| Подготовка корпуса, разбиение, OCR | 2–4 недели | 150–400 тыс. ₽ | Чистый индексируемый массив, версионирование |
| Сборка поиска и генерации | 3–5 недель | 250–600 тыс. ₽ | Работающий контур, метрики точности |
| Интеграции и права доступа | 2–4 недели | 200–700 тыс. ₽ | Роли, разграничение, вход через корпоративный аккаунт |
| Эксплуатация | ежемесячно | 25–80 тыс. ₽ | Переиндексация, мониторинг, доработка |
Команда: архитектор ИИ-решений (0,3 ставки), backend-разработчик (0,5–1), инженер по данным (0,5–1), тестировщик (0,3). На стороне заказчика нужен владелец базы знаний — человек, который отвечает за актуальность документов. Без него через три месяца в индексе окажется устаревший прайс.
Если контур нужен для клиентского сайта, работа идёт в связке с разработкой сайта: виджет, история диалога, передача в CRM. Тогда сборка приложения и контура планируется одним проектом — так дешевле, чем двумя отдельными. Ии для разработки сайта здесь решает конкретную задачу: отвечает по каталогу, условиям доставки и гарантии, не путая артикулы. Корпоративный портал или сайт класса разработки с ИИ-поиском по документации обходится на 200–400 тыс. ₽ дороже обычного. Сайт разработки приложений для внутренних задач устроен похоже: тот же поиск, но с разграничением прав, но снимает до половины обращений в поддержку.
Проще всего стартовать там, где уже есть текстовый корпус: инструкции для менеджеров, регламенты техподдержки, стандарты разработки 1С, коммерческие предложения за три года.
Что делать с документами до индексации
Три правила, которые экономят недели. Уберите дубли: пять копий одного регламента с разными датами — главный источник противоречивых ответов. Проставьте владельца и дату у каждого документа: система должна уметь отвечать, какая версия актуальна. И сохраняйте структуру заголовков — фрагмент без заголовка теряет контекст, и модель отвечает неточно.
Качество и приёмка: как понять, что контур работает
Прямой ответ: контур принимается по трём метрикам — точность поиска, доля ответов с корректной ссылкой и доля отказов. Ощущения заказчика здесь не аргумент, нужны цифры до и после.
| Метрика | Что показывает | Норма для приёмки |
|---|---|---|
| Recall@10 | Доля вопросов, где нужный фрагмент попал в топ-10 | 90% и выше |
| Точность ответа | Доля ответов, не противоречащих источнику | 92% и выше |
| Доля цитат | Ответы со ссылкой на реальный документ | 95% и выше |
| Честный отказ | Ответы «в документах нет данных» вместо выдумки | 100% на тесте из 30 ловушек |
| Время ответа | От вопроса до первого токена | до 3 секунд |
На приёмке отдельно проверяют, как контур ведёт себя там, где знаний нет. Полный порядок приёмки с примерами разметки описан в материале как оценить качество ИИ-бота. Внедрение ии агентов в клиентскую поддержку почти всегда начинается с этого теста: 30 вопросов, ответов на которые в базе нет. Хороший контур отказывается отвечать, плохой — сочиняет. Именно на этом тесте чаще всего всплывают галлюцинации, и лечится это не сменой модели, а настройкой порога релевантности.
Ошибки, которые стоят дороже разработки
Первая и самая дорогая — индексировать всё подряд. Папка «Разное» на 4 000 файлов со старыми презентациями снижает точность поиска: релевантный фрагмент тонет в шуме. Начните с 100–300 документов по одному домену.
Вторая — экономить на переранжировании. Дешёвый поиск по векторам отдаёт в топ фрагменты с похожими словами, но другим смыслом. Переранжировщик добавляет 3–7 тыс. ₽ в месяц и снимает большую часть таких ошибок.
Третья — не вести журнал диалогов. Без него вы не узнаете, что 20% вопросов сотрудников вообще не покрыты документами. Журнал — источник задач для развития базы знаний, а не отчётность.
Четвёртая — забыть про права доступа. Если в общий индекс попадут зарплатные ведомости, инцидент будет стоить дороже всего проекта. Разграничение прав проектируется до индексации, а не после.
Частые вопросы
Чем RAG отличается от дообучения модели?
RAG подставляет нужные фрагменты в контекст при каждом запросе, дообучение меняет сами веса модели. RAG обновляется за часы и даёт ссылки на источник, но требует качественной базы знаний. Дообучение полезно для стиля и формата ответов, а факты всё равно лучше держать в поиске.
Сколько документов нужно для запуска?
Рабочий минимум — 50–100 документов по одному домену, лучше 200–300. На меньшем объёме контур отвечает, но экономия не оправдывает эксплуатацию. Если документов тысячи, начинайте с одного отдела и расширяйте индекс итерациями.
Можно ли сделать RAG на своих серверах?
Да, и для работы с персональными данными это предпочтительный вариант. Открытые модели на своём GPU-сервере снимают вопрос передачи данных третьим лицам, но требуют администрирования и стоят от 90 тыс. ₽ в месяц за инфраструктуру с запасом по нагрузке.
Насколько точными получаются ответы?
На подготовленном корпусе — 90–95% корректных ответов при доле цитат выше 95%. Остаток приходится на вопросы, где документы противоречат друг другу или данных нет. Этот остаток виден в журнале и закрывается правками регламентов, а не настройками модели.
Что делать, если документы только в сканах?
Нужен OCR с сохранением структуры: 150–350 тыс. ₽ на массив из 1 000–2 000 страниц плюс ручная вычитка сложных таблиц. Без этого шага индекс получит мусор, и точность упадёт ниже 70%. Сканы договоров с печатями обычно требуют ручной проверки ключевых полей.
Нужен ли RAG, если у нас уже есть поиск по сайту?
Штатный поиск находит страницы по словам, но не отвечает на вопрос и не учитывает формулировки клиента. RAG добавляет генерацию ответа со ссылкой, поэтому работает поверх существующего поиска. Для каталога товаров достаточно улучшенного поиска, для инструкций и регламентов — RAG.
Что делать дальше
Соберите инвентаризацию знаний: сколько документов, в каком они формате, кто владелец и когда обновлялись последний раз. Возьмите 30 реальных вопросов от сотрудников или клиентов и проверьте, отвечает ли на них ваша текущая база за минуту. Если да — RAG вам не нужен. Если на половину вопросов уходит по 15 минут поиска, экономия уже посчитана.
Дальше запускайте пилот на одном домене: 4–6 недель, 350–700 тыс. ₽, с приёмкой по метрикам точности и честного отказа. Посмотрите, как устроены такие проекты у нас в разделе ИИ-агенты и чат-боты. Если источники знаний размазаны по десяткам папок и почтовых ящиков, до старта придётся навести порядок в документах — иначе контур будет уверенно цитировать устаревшие версии.
Частые вопросы
Чем RAG отличается от дообучения модели?
Сколько документов нужно для запуска?
Можно ли сделать RAG на своих серверах?
Насколько точными получаются ответы?
Что делать, если документы только в сканах?
Нужен ли RAG, если у нас уже есть поиск по сайту?
Статья основана на практике проектов НейроДела и данных Яндекс Вордстата по кластеру «ИИ-агенты и ИИ-боты». Основной запрос материала — «ии для разработки» (4 230 показов в месяц). Если у вас другая ситуация — напишите, разберём.
