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