Корпоративный ИИ: RAG, дообучение или агент — что выбрать первым
Под словом «корпоративный ИИ» часто скрываются три совершенно разные задачи. В одном отделе нужно отвечать по актуальным регламентам, в другом — выдерживать единый формат классификации, в третьем — создавать заявки в CRM. Для первой задачи подходит поиск по документам (RAG), для второй может пригодиться дообучение, для третьей нужен агент с инструментами. Ошибка выбора стоит дорого: компания месяц настраивает модель, которая не решает исходную проблему.
Сравним подходы не по обещаниям поставщиков, а по тому, что именно меняется в системе. В сравнении чата и поиска по документам уже разобран базовый выбор для ответов; здесь добавим дообучение и агентный слой, а затем проверим, в каком порядке их разумно запускать.
Сначала определите, что должно меняться
Задайте команде три вопроса:
- Факты обновляются каждую неделю или остаются стабильными?
- Нужно изменить знания модели или только форму ответа?
- Результат должен быть текстом или действием во внешней системе?
Если меняются факты — смотрите в сторону RAG. Если повторяется формат и есть хороший набор примеров — рассматривайте fine-tuning. Если ответ должен вызвать API, создать заявку или изменить запись — появляется агент. Смешивать эти уровни в одном пилоте не стоит: иначе непонятно, какой слой дал ошибку.
RAG: актуальные документы без переобучения
RAG (retrieval-augmented generation) сначала ищет подходящие фрагменты во внутреннем индексе, затем передаёт их модели для ответа. Когда обновился прайс или регламент, достаточно заменить файл и переиндексировать его. Это главное преимущество для поддержки, HR, закупок и юридических команд, где содержание меняется чаще, чем стиль ответа.
Цена гибкости — качество базы. Дубликаты, плохие заголовки и неверные права доступа приводят к тому, что система находит устаревшую версию или смешивает два документа. Разбивайте файлы по смысловым разделам, храните дату редакции и показывайте пользователю источник. Фильтр доступа должен сработать до вызова модели, а не после того, как закрытый фрагмент уже попал в контекст.
RAG не учит модель новым фактам навсегда и не исправляет противоречивые инструкции. Если в двух документах разные лимиты, система может выбрать не тот, даже честно процитировав источник. Поэтому тестируйте вопросы с устаревшей, отсутствующей и конфликтующей информацией.
Fine-tuning: устойчивый формат, а не живая база
Дообучение меняет поведение модели на примерах. Оно полезно, когда нужно стабильно классифицировать обращения, выдерживать внутреннюю схему полей или писать короткие ответы определённого типа. Хороший набор примеров снижает количество ручных исправлений и делает формат предсказуемее.
Но факты из обучающей выборки быстро устаревают. Чтобы добавить новый тариф или правило, придётся готовить данные, запускать обучение и снова проверять модель. Ошибка в примерах масштабируется на все запросы, а происхождение конкретного утверждения сложнее показать пользователю. Для регламентов fine-tuning обычно дополняют RAG, а не используют вместо него.
До запуска очистите примеры от персональных данных и противоречий. Разделите выборку на обучение и проверку, иначе модель может запомнить формулировки и создать ложное ощущение качества. Оцените не только совпадение метки, но и то, как система сообщает о неуверенности.
Агент: модель получает право действовать
Агентный подход добавляет инструменты и цикл действий. Модель может найти клиента, проверить остаток, подготовить заявку и передать её оператору. Польза появляется там, где ручная работа состоит из нескольких повторяющихся шагов, а не в красивом разговоре.
Риски здесь выше. Ошибка в тексте обычно требует исправления, ошибка в API может изменить заказ, отправить письмо или раскрыть данные. Ограничьте белый список инструментов, права каждой роли, число вызовов и сумму операций. Для удаления, оплаты, отправки клиенту и изменения карточки требуйте явное подтверждение. Карточка Astra Guarded показывает, как проверять режимы с ограничением действий; этот принцип одинаково важен и для других моделей.
Агент нуждается в наблюдаемости: журнале шагов, идентификаторе запроса, понятной причине отказа и кнопке аварийной остановки. Без этих элементов расследование ошибки превращается в поиск по разрозненным логам.
Сводная матрица
| Подход | Что меняется | Сильная сторона | Основная цена | Когда не брать первым |
|---|---|---|---|---|
| RAG | Контекст запроса | Актуальные источники | Индекс, права, переиндексация | Если база хаотична и неразмечена |
| Fine-tuning | Поведение и формат | Стабильные ответы по примерам | Подготовка данных и повторное обучение | Если факты меняются часто |
| Агент | Действия через API | Сквозной процесс | Интеграции, мониторинг, откат | Если ещё не измерена точность поиска |
Таблица не означает, что один слой исключает другой. Частая последовательность выглядит так: RAG возвращает подтверждённые фрагменты, дообученная модель приводит их к нужной схеме, агент передаёт результат в систему после подтверждения. Каждый шаг должен иметь собственный журнал и критерий остановки.
Как провести пилот за две недели
Начните с тридцати обезличенных запросов и одной роли пользователя. В первый день зафиксируйте правильные ответы, допустимое время и случаи, когда система обязана отказаться. Затем протестируйте чистый чат, RAG и, если задача действительно требует действия, отдельный агент. Не запускайте все три режима одновременно на всей компании.
Считайте полный маршрут: время до принятого результата, число правок, долю ответов с проверяемой ссылкой, стоимость вызовов и количество эскалаций к человеку. Для RAG добавьте ошибки поиска и устаревшие документы; для fine-tuning — устойчивость к изменённому порядку входа; для агента — несанкционированные действия и корректность отката.
Если RAG не находит нужный документ, сначала исправьте структуру базы. Если fine-tuning даёт разные форматы, проверьте примеры и схему полей. Если агент ошибается на простом шаге, не добавляйте ему новые права — упростите цепочку и верните подтверждение человеку.
Вердикт по сценариям
Для регулярно меняющихся инструкций начинайте с RAG и прозрачных цитат. Для повторяющейся классификации и строгой формы ответа рассматривайте небольшое дообучение поверх проверенного контекста. Агент подключайте последним, когда точность и права уже измерены, а опасные операции можно отменить.
Экономия возникает не от самой сложной архитектуры, а от соответствия задаче. Разнесите расходы на индекс, подготовку примеров, интеграции и поддержку по месяцу пилота. Если некому обновлять документы или смотреть журнал действий, даже впечатляющая демонстрация не станет рабочей системой.