RAG или ИИ-агент: что выбрать для базы знаний
RAG и ИИ-агент могут выглядеть как один чат, но решают разные задачи. RAG находит фрагменты в подготовленном индексе и помогает сформулировать ответ. Агент планирует цепочку, вызывает инструменты и может изменить состояние внешней системы. Ошибка выбора появляется, когда простой вопрос превращают в оркестрацию или агенту выдают права, которые не нужны для чтения документов.
Единая методика сравнения
Возьмём двадцать обезличенных материалов: инструкции, таблицу тарифов и письма с исключениями. Оба подхода получают одинаковые документы, формулировки и модель генерации. Проверим три сценария: найти точный пункт, свести несколько версий и создать задачу после найденного несоответствия.
Для каждого варианта измеряем точность цитаты, полноту, корректный отказ, задержку, стоимость принятого результата, сложность поддержки и объём прав. Ответ считается правильным только тогда, когда его можно сопоставить с исходным фрагментом и датой действия.
Сценарий 1. Найти один пункт
Вопрос «какой срок хранения записи?» естественен для RAG. Индекс возвращает несколько близких фрагментов, фильтрует роль и версию, а генератор показывает цитату и название файла. Если подходящий фрагмент отсутствует, система может честно сообщить об отсутствии основания.
Агент для такого запроса избыточен: ему нужно спланировать поиск, вызвать инструмент и оформить тот же ответ. Дополнительный шаг увеличивает задержку и число отказов. Агент оправдан лишь тогда, когда после поиска обязательно нужно выполнить безопасную операцию, например подготовить черновик.
Сценарий 2. Свести несколько версий
RAG способен вернуть фрагменты из разных документов, но не решает сам, какой регламент действует. Метаданные должны содержать дату, владельца и статус, а запрос — правило приоритета. Если эти поля не заполнены, модель может объединить старое исключение с новой редакцией.
Агент полезен для последовательности: найти действующую версию, сравнить её с предыдущей, перечислить изменения и попросить владельца подтвердить спорный пункт. Каждый этап должен сохранять результат и ссылку на источник. При отсутствии документа агент останавливается, а не переходит к следующему шагу с догадкой.
Сценарий 3. Создать задачу
RAG заканчивается ответом и цитатой. Он не должен знать, кому назначить задачу или можно ли менять статус в трекере. Это преимущество для безопасности: поиск не получает полномочий записи.
Агент может подготовить задачу, но финальное создание требует подтверждения. Сначала он показывает найденное противоречие, предлагает заголовок, исполнителя и срок. Человек проверяет поля и подтверждает одноразовый план. Удаление, публикация и изменение дедлайна не включаются в автоматический режим по умолчанию.
Сравнительная таблица
| Критерий | RAG | ИИ-агент |
|---|---|---|
| Один проверяемый факт | Быстро возвращает цитату | Лишние шаги для простого вопроса |
| Сравнение версий | Требует качественных метаданных | Может выполнить цепочку проверок |
| Внешнее действие | Обычно только читает | Вызывает инструмент после подтверждения |
| Стоимость поддержки | Индекс и обновления | Оркестрация, права и трасса шагов |
| Повторяемость | Выдача видна до ответа | Нужно хранить каждый переход |
| Риск изменения данных | Ограниченный | Растёт вместе с полномочиями |
Таблица не отменяет теста на собственной инфраструктуре. Один и тот же агент может вести себя по-разному при изменении инструмента, роли или длины контекста.
Цена и задержка
RAG требует очистки документов, построения индекса, контроля разбиения и регулярного обновления. Агент добавляет стоимость планирования, каждого вызова, повтора после ошибки и финального ответа. Считайте не токены одного запуска, а стоимость принятого результата с учётом ручной проверки.
Если агент трижды перезапрашивает источник и всё равно требует ручного поиска, простой RAG будет дешевле. Если сотрудник каждый раз вручную переносит найденное в трекер, агентный черновик может окупить дополнительные вызовы — при условии, что права и подтверждения настроены.
Приватность и наблюдаемость
В RAG фильтр доступа применяйте до передачи фрагмента генератору. Пользователь не должен узнать даже название закрытого файла, если политика скрывает факт существования. Версии и даты записывайте в журнал индекса.
У агента появляется дополнительный журнал: инструмент, параметры, результат, время и человек, подтвердивший действие. Не выдавайте универсальный токен администратора. Разделяйте чтение, подготовку и выполнение, а персональные данные маскируйте в логах.
Точка передачи человеку
Сравните системы не только по успешным ответам, но и по моменту, когда они должны остановиться. Для каждого сценария запишите триггер передачи: конфликт дат, отсутствие источника, закрытая роль или попытка изменить внешнюю запись. RAG может вернуть найденное с пометкой «нужна проверка», а агент — сохранить незавершённый план без вызова инструмента. Если интерфейс скрывает эту границу, оператор не понимает, где заканчивается автоматический результат.
На пилоте попросите двух сотрудников независимо оценить десять остановленных задач. Один смотрит только на текст ответа, другой — на журнал поиска и шаги агента. Сравните, одинаково ли они определяют причину остановки и знают следующий шаг. Расхождение означает, что системе не хватает объяснения или видимого источника, даже если итоговая точность выглядит высокой.
Заранее определите, что происходит с незавершённым планом: он удаляется, возвращается владельцу или ждёт подтверждения ограниченное время. Не оставляйте его навсегда в очереди, иначе изменившийся документ или отзыв доступа превратят старый план в опасную инструкцию. После обновления индекса и прав повторите проверку перед возобновлением.
Как выбрать архитектуру
Выбирайте RAG, если задача заканчивается ответом по документам и нужна прозрачная цитата. Агент оправдан, если после поиска есть последовательность действий, которую можно разбить на обратимые шаги и контролировать. В сложном процессе используйте связку: RAG находит основания, агент собирает черновик, человек подтверждает изменение.
Начните с RAG даже при планах на автоматизацию. Пока поиск не возвращает правильную версию и корректный отказ, агент только ускорит неправильное решение. Переход к инструментам должен быть отдельным этапом с тестом прав и журналом.
Пилот на пять дней
В первый день подготовьте документы и эталонные вопросы. Во второй сравните выдачу RAG с агентным планом. В третий проверьте вопрос без ответа и закрытую роль. В четвёртый протестируйте preview задачи и двойное подтверждение. В пятый сопоставьте задержку, стоимость и исправления с ручным маршрутом.
Итог
RAG — контролируемый слой поиска, агент — исполнитель цепочки. Выбирайте минимальную архитектуру, измеряйте одинаковые сценарии и добавляйте действия только после стабилизации источников и прав. Такой порядок упрощает отладку и не превращает базу знаний в непрозрачную автоматизацию.