Что такое ИИ-агент и чем он отличается от чат-бота

Сценарный чат-бот идёт по дереву, которое написал человек: он отвечает ровно там, где ответ предусмотрели. Языковая модель сама по себе умеет говорить, но не знает вашей номенклатуры, не видит остатков и ничего не делает в системах. Агент соединяет одно с другим: модель формулирует, инструменты читают и записывают данные, а правила задают, что агент делает сам, а что отдаёт человеку.

Инструмент – это конкретное действие, которое агенту разрешено выполнить: найти клиента в CRM, посмотреть остаток по складу, прочитать договор, создать заказ, отправить сообщение. Модель не лезет в базу напрямую: она вызывает инструмент, получает результат и решает, что делать дальше. Список инструментов – это и есть граница полномочий агента, и задаётся он до запуска, а не по ходу работы.

RAG – это приём, при котором модель перед ответом ищет нужный фрагмент в ваших документах и отвечает, опираясь на найденное. Документы заранее режут на куски и складывают в поисковый индекс; на вопрос сначала подбираются подходящие куски, и только потом модель формулирует ответ и показывает, откуда взяла. Дообучать модель для этого не нужно: поменялся регламент – заменили документ в индексе.

Проверка – это отдельный шаг, а не свойство модели. Агент сверяет полученное с тем, что можно сверить: нашлась ли позиция в номенклатуре, сходится ли сумма с документом, попадает ли дата в допустимый диапазон, вернул ли инструмент ошибку. Если проверка не прошла, агент повторяет шаг иначе или останавливается и передаёт задачу человеку с тем, что успел собрать.

Агент окупается там, где действие повторяется, данные для него лежат в системе, а результат проверяем. Типовой набор: первое касание по входящей заявке с квалифицирующими вопросами, ответ на вопрос по вашим документам со ссылкой на источник, разбор входящей первички, подготовка черновика документа, ответ на вопрос к учётной базе обычными словами.

Не нужен там, где задача решается настройкой системы или обменом данными: если заявки теряются из-за того, что каналы не сведены в одно место, это работа интеграции, а не модели. Не нужен там, где цена ошибки высока, а проверить результат нечем: договорные условия, скидки, обязательства перед клиентом. И не нужен там, где данных в системе нет вовсе: придумывать их агент не должен.

Модель ошибается, и предсказать, в каком именно ответе, нельзя. Поэтому рабочий режим такой: агент готовит решение и показывает основание, человек утверждает. Всё, что создаёт обязательство перед клиентом или меняет деньги в документах, проходит через утверждение по умолчанию, а список того, что агент делает сам, расширяют постепенно – после того, как на живом потоке видно, где он ошибается.

Это не оговорка ради осторожности, а условие, при котором систему вообще можно запустить в работу: у ответственного должно быть место, где он видит и может остановить.

Мы собираем агента под один процесс: разбираем, как он идёт сейчас, определяем, какие данные и действия агенту нужны, ставим границы – что он делает сам, а что отдаёт человеку, – и запускаем на живом потоке рядом с сотрудником. Дальше смотрим, где он ошибается, и расширяем полномочия по результату, а не авансом.