ИИ-агенты и ИИ-боты

RAG для бизнеса: практическое руководство по внедрению

Компания покупает подписку на ChatGPT, сотрудники месяц носят туда вопросы, а потом возвращаются к поиску по папкам: модель уверенно отвечает по общим знаниям и не знает ни ваших цен, ни условий договоров.…

, Архитектор ИИ-решений Обновлено 25.08.2026 10 минут чтения 860 просмотров 26 лайков

Компания покупает подписку на 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 окупается, а где нет

Прямой ответ: контур окупается там, где сотрудники или клиенты регулярно ищут ответ в большом объёме текста, а ошибка стоит денег. Три сценария с самой быстрой отдачей.

  1. Поддержка клиентов по продуктовой документации. Агент отвечает на 60–75% вопросов, операторы занимаются только исключениями. При 2 500 обращений в месяц экономия — 120–180 тыс. ₽.
  2. Внутренняя база знаний. Регламенты, инструкции, кадровые положения. Высвобождает 3–5 часов в неделю на сотрудника, при штате 30 человек это 0,7–1,2 ставки.
  3. Работа с договорами и тендерной документацией. Поиск условий, сроков, штрафов по 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 обновляется за часы и даёт ссылки на источник, но требует качественной базы знаний. Дообучение полезно для стиля и формата ответов, а факты всё равно лучше держать в поиске.
Сколько документов нужно для запуска?
Рабочий минимум — 50–100 документов по одному домену, лучше 200–300. На меньшем объёме контур отвечает, но экономия не оправдывает эксплуатацию. Если документов тысячи, начинайте с одного отдела и расширяйте индекс итерациями.
Можно ли сделать RAG на своих серверах?
Да, и для работы с персональными данными это предпочтительный вариант. Открытые модели на своём GPU-сервере снимают вопрос передачи данных третьим лицам, но требуют администрирования и стоят от 90 тыс. ₽ в месяц за инфраструктуру с запасом по нагрузке.
Насколько точными получаются ответы?
На подготовленном корпусе — 90–95% корректных ответов при доле цитат выше 95%. Остаток приходится на вопросы, где документы противоречат друг другу или данных нет. Этот остаток виден в журнале и закрывается правками регламентов, а не настройками модели.
Что делать, если документы только в сканах?
Нужен OCR с сохранением структуры: 150–350 тыс. ₽ на массив из 1 000–2 000 страниц плюс ручная вычитка сложных таблиц. Без этого шага индекс получит мусор, и точность упадёт ниже 70%. Сканы договоров с печатями обычно требуют ручной проверки ключевых полей.
Нужен ли RAG, если у нас уже есть поиск по сайту?
Штатный поиск находит страницы по словам, но не отвечает на вопрос и не учитывает формулировки клиента. RAG добавляет генерацию ответа со ссылкой, поэтому работает поверх существующего поиска. Для каталога товаров достаточно улучшенного поиска, для инструкций и регламентов — RAG.
860 просмотров 1661 слов
Дмитрий Хромов Архитектор ИИ-решений · автор НейроДела

Статья основана на практике проектов НейроДела и данных Яндекс Вордстата по кластеру «ИИ-агенты и ИИ-боты». Основной запрос материала — «ии для разработки» (4 230 показов в месяц). Если у вас другая ситуация — напишите, разберём.

Обсудим вашу задачу?

Разберём процесс, посчитаем экономику и покажем, что реально автоматизировать за первые две недели. Без презентаций на 40 слайдов.