Вопрос пользователя: Мы понимаем, что LLM-агент нужен для нестандартных случаев. Но где именно проходит граница: что он может решить сам, а что обязательно должно уходить человеку?
Суть проблемы
Гибридная автоматизация ломается не на happy path. Она ломается на исключениях. Пока всё типовое, и обычный робот, и гибридный контур выглядят прилично. Настоящая разница проявляется тогда, когда вход неполный, противоречивый, подозрительно похожий на дубль, не соответствует регламенту или затрагивает значимое бизнес-решение.
Если в такой точке у архитектуры нет карты полномочий, проект начинает либо чрезмерно эскалировать всё подряд на человека, либо, наоборот, слишком смело автоматизировать то, что следовало бы остановить и проверить.
Главный принцип
Нужно проектировать не только основной сценарий, но и матрицу исключений. Для каждого типа исключения должно быть заранее понятно:
- кто его обнаруживает;
- кто его интерпретирует;
- кто принимает решение;
- кто исполняет решение;
- что журналируется;
- куда уходит эскалация.
Четыре класса исключений
Для 1С ERP удобно делить исключения на четыре класса.
Класс 1. Технические исключения
Это зона классического RPA и среды исполнения. Кейс не про смысл, а про механику выполнения. Не открылся браузер, не найден UI-элемент, изменился XPath, не сработала авторизация, истек тайм-аут ожидания, не создалась папка, не прочитался файл, не записался журнал.
Здесь LLM-агент чаще всего не нужен. Его подключение не усилит контур, а только запутает. Технические исключения должны решаться стандартными механизмами: retries, ожиданиями, тайм-аутами, fallback-ветками, инцидентами, логами и корректной оркестрацией.
Класс 2. Структурные исключения
Это уже промежуточная зона. Смысл кейса в целом понятен, но структура входа нарушена. Не хватает обязательного поля, колонка в Excel названа иначе, файл вложения не читается полностью, единица измерения извлечена, но без кода, строка есть, а артикул пустой, таблица прайса содержит пропуски.
Здесь LLM может быть полезен как помощник по доизвлечению, нормализации и объяснению проблемы. Но окончательный переход к исполнению должен происходить только после валидации. Если структура не соответствует требованиям, робот не должен молча идти дальше.
Класс 3. Смысловые исключения
Вот здесь начинается настоящая зона LLM-агента. Письмо противоречиво. В прайсе одно название, в приложении другое. Товар похож на существующую номенклатуру, но не совпадает однозначно. Производитель указан неявно. Единица измерения и упаковка выглядят как взаимозаменяемые, но это надо оценить. В тексте поставщика нет формального признака, что это новая карточка, но по контексту похоже именно на это.
Это те случаи, которые обычное дерево условий переживает плохо. Здесь агент действительно полезен, потому что он может сравнивать, объяснять, выделять признаки неопределенности, формировать список кандидатов и рекомендовать маршрут.
Но даже здесь надо помнить: понимание не равно полномочию на окончательное действие.
Класс 4. Ответственные исключения
Это самый важный слой. Сюда попадают кейсы, где ошибка агентного решения может привести к серьезным последствиям: создание дубля контрагента или номенклатуры, изменение финансово значимого реквизита, нарушение регламента, создание объекта без обязательного основания, спорные налоговые признаки, конфликт договорных условий, ситуация с повышенным риском для учета.
Здесь даже хороший LLM-агент не должен быть последней инстанцией. Он может подготовить объяснение, собрать кандидатов, предложить вариант, но решение должно уходить человеку.
Как строить карту полномочий
Практически полезно ввести четыре уровня доверия к агенту.
Уровень 1. Информирует. Агент только помогает понять кейс, но не влияет на выполнение.
Уровень 2. Рекомендует. Агент предлагает ветку, но окончательное решение принимает человек.
Уровень 3. Подготавливает. Агент формирует структурированный набор данных для робота, но при наличии красных флагов процесс уходит в эскалацию.
Уровень 4. Решает в узком коридоре. Агент может автономно выбрать ветку только там, где рамка решений строго ограничена и цена ошибки приемлема.
На практике для 1С ERP чаще всего рабочими оказываются уровни 2 и 3. Полный уровень 4 допустим только на очень узких и хорошо защищенных участках.
Как определить признаки обязательной эскалации
Нужно заранее зафиксировать конкретные признаки, при которых кейс нельзя проводить автоматически. Например:
- не заполнено хотя бы одно обязательное поле;
- найдено более одного вероятного совпадения;
- уровень уверенности агента ниже порога;
- найдено противоречие между письмом и вложением;
- новый объект влияет на учетную или налоговую логику;
- нарушение типового регламента;
- отклонение от словаря допустимых значений;
- попытка создать объект без минимального набора оснований.
Чем точнее эти признаки определены, тем меньше соблазн делать опасные «разумные допущения».
Пример на 1С ERP
Возьмем сценарий создания новой номенклатуры. Агент видит строку поставщика: «Пленка ПЭТ 500мм, рулон 25 кг». В системе уже есть несколько похожих карточек: «Пленка ПЭТ 500 мм», «Пленка ПЭТ рулон 25кг», «ПЭТ пленка 500мм». Агент может вполне грамотно предложить, что это, вероятно, уже существующая номенклатура. Но если в проекте не определено, при каких условиях можно признать совпадение достаточным, автоматическое решение будет рискованным.
Правильная архитектура здесь такова: агент формирует список кандидатов, дает пояснение и уровень уверенности. Если уверенность ниже порога или кандидатов больше одного, кейс идет на человека. Если совпадение однозначное по заранее заданным признакам, робот просто записывает статус «уже существует» и не создает дубль.
Почему эскалация — это не слабость, а зрелость архитектуры
Есть опасное заблуждение, будто хорошая автоматизация — это та, где человек вообще больше не нужен. Для учетных и ERP-процессов это неверно. Хорошая автоматизация — это та, где человек исключен из рутины, но сохранен в точках ответственности.
Эскалация нужна не потому, что агент плохой. Она нужна потому, что бизнес-ответственность нельзя растворить внутри вероятностной модели. Это особенно верно там, где решение может повлиять на учет, отчетность, договорные обязательства или производственный контур.
Решение и рекомендации
Первое. Обязательно делите исключения на технические, структурные, смысловые и ответственные. Тогда роль каждого контура становится ясной.
Второе. Для каждого исключения заранее определяйте, кто обнаруживает, кто решает, кто исполняет и кто уведомляется.
Третье. Не давайте агенту автономию там, где цена ошибки выше стоимости ручной проверки.
Четвертое. Формализуйте пороги уверенности и признаки обязательной эскалации.
Пятое. В журналах фиксируйте не только факт ошибки, но и тип исключения. Это резко упрощает сопровождение и развитие архитектуры.
Итог простыми словами
Хороший LLM-агент не тот, который никогда не спрашивает человека. Хороший агент — это тот, который точно знает, когда без человека дальше идти нельзя. А хорошая RPA-архитектура — это та, которая умеет вовремя остановиться, корректно передать кейс и сохранить управляемость процесса.
Типичный сценарий правильного использования
Агент обнаруживает, что новая строка прайса похожа сразу на две существующие карточки номенклатуры. Он не делает вид, что всё однозначно. Он возвращает список кандидатов, признаки совпадения, уровень уверенности и отправляет кейс на ручную проверку. Робот фиксирует это в результатах и не создает дубль.
Типичный сценарий опасного использования
Агент видит похожее название и автоматически привязывает строку к одной из существующих карточек, потому что «она кажется наиболее вероятной». Робот проходит дальше и использует эту карточку в последующих процессах. Ошибка обнаруживается позже, когда уже испорчены учетные данные и нарушена аналитика. Формально автоматизация отработала без ошибок. По сути — создала скрытый дефект.