Как AI-агентам работать с неполными входными данными

AI-агент редко получает идеально подготовленную задачу. В реальном бизнес-процессе в заявке может не хватать документа, часть полей оказывается пустой, источник временно недоступен, а пользователь предполагает, что агент и так знает недостающую информацию.

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

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

Отсутствие данных само по себе ещё не означает, что задачу нужно останавливать.

Представим, что агент готовит коммерческое предложение. Если не указан дополнительный комментарий клиента, работу можно продолжить: обязательные параметры уже есть, а комментарий влияет только на формулировку финального текста.

Но если отсутствует валюта сделки, сумма может оказаться рассчитана неверно. Здесь продолжение процесса без уточнения уже создаёт реальный риск.

Поэтому системе нужно различать критичные и некритичные пропуски.

Для каждой задачи стоит определить минимальный набор входных данных, без которого выполнение невозможно или небезопасно.

Это могут быть:

· идентификатор клиента;

· сумма операции;

· дата;

· тип заявки;

· документ-основание;

· параметры товара или услуги;

· разрешение на выполнение действия.

При этом обязательность должна определяться не удобством модели, а логикой конкретного процесса.

Если поле не влияет на решение, превращать его в обязательное только ради формальной полноты не имеет смысла.

Одна из самых опасных привычек AI-систем — пытаться выполнить задачу любой ценой.

Если не хватает информации, модель может предположить наиболее вероятное значение. В обычном тексте это иногда выглядит вполне убедительно. В операционном процессе такое поведение способно привести к ошибочному заказу, неверному расчёту или неправильному решению по клиенту.

Поэтому у агента должно быть право сказать: для продолжения не хватает конкретного условия.

Это не признак слабой автоматизации. Наоборот, способность вовремя остановиться часто является частью качественной работы.

Сообщение «недостаточно информации» практически бесполезно.

Пользователь должен понимать, что именно требуется и зачем.

Например, вместо общего запроса агент может сообщить, что для оформления заказа нужен артикул товара, потому что без него система не сможет определить актуальную цену и остаток.

Такой подход сокращает количество дополнительных сообщений и быстрее возвращает задачу в рабочее состояние.

Есть и другая крайность: агент обнаруживает один пропуск и отправляет пользователю длинный список из десяти вопросов.

Часть этих вопросов может оказаться ненужной, потому что ответы на первые два уже изменят дальнейший сценарий.

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

Так диалог остаётся коротким, а workflow не превращается в анкету.

Не вся информация одинаково надёжна.

Одно значение пришло из корпоративной системы, другое пользователь написал в чате, третье агент вывел самостоятельно на основе нескольких документов.

Если для критичного действия система не различает эти источники, ей сложно оценить, достаточно ли надёжны входные данные.

Поэтому полезно хранить не только само значение, но и его происхождение: откуда оно получено, когда обновлялось и каким способом было сформировано.

Иногда агент действительно может продолжить работу на основании предположения.

Например, пользователь не указал формат отчёта, а в компании для такого типа задач всегда используется один стандарт.

В этом случае система может применить стандартное значение, если соответствующее правило заранее определено.

Но предположение не должно незаметно превращаться в факт. Внутри процесса должно быть понятно, какие данные получены напрямую, а какие были выведены или подставлены по правилу.

Значения по умолчанию помогают не останавливать процесс из-за каждого необязательного поля.

Например, если клиент не указал способ получения документа, система может использовать стандартный вариант.

Однако такие правила должны быть частью бизнес-логики, а не случайным решением модели.

Если агент сам решает, какое значение считать стандартным, поведение системы становится непредсказуемым. Сегодня он выберет один вариант, завтра — другой.

Это особенно критично для числовых и идентификационных параметров.

Если в заявке отсутствует количество товара, агент не должен самостоятельно выводить его из контекста только потому, что такое количество кажется наиболее вероятным.

Вероятность — не подтверждение.

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

Один и тот же уровень неполноты данных не должен одинаково обрабатываться во всех задачах.

Можно выделить как минимум три сценария.

Продолжить автоматически. Недостающая информация не влияет на результат или может быть безопасно заменена заранее определённым значением.

Продолжить с пометкой. Агент может выполнить работу, но должен обозначить, какие данные были предположены или получены с ограничениями.

Остановиться и запросить уточнение. Без информации нельзя надёжно выполнить следующий этап.

Такое разделение гораздо практичнее, чем универсальное правило «если чего-то не хватает — спрашивай пользователя».

Не каждый пропуск требует возвращения к человеку.

Если у агента есть разрешённый доступ к корпоративной системе, он может самостоятельно найти недостающий номер заказа, актуальную цену или статус клиента.

Но здесь возникает важный вопрос: имеет ли агент право использовать этот источник и насколько свежими должны быть полученные данные.

Самостоятельный поиск должен быть частью предусмотренного workflow, а не свободным поиском информации без ограничений.

Бывает, что данные существуют, но агент не может получить их прямо сейчас.

Например, CRM временно недоступна или внешний сервис не отвечает.

Это не то же самое, что отсутствие данных.

В первом случае информация потенциально существует, и задачу можно поставить на ожидание или повторить запрос позже. Во втором действительно требуется получить новые сведения от пользователя или другого источника.

Разделение этих ситуаций помогает избежать ненужных запросов к сотрудникам.

Даже если исходная задача заполнена полностью, проблема может возникнуть на следующем этапе.

Агент передал запрос другому сервису и получил только часть ответа. Или документ оказался повреждённым. Или один из источников содержит данные только за предыдущий период.

Поэтому проверять полноту нужно не только в момент создания задачи.

Каждый этап, который получает новые входные данные, должен понимать, достаточно ли их для продолжения.

Иногда следующий агент как раз и отвечает за получение недостающей информации.

Например, один агент определяет, какие документы нужны для проверки, а другой занимается их поиском.

В такой архитектуре первый агент не обязан выполнять работу второго. Но он должен передать не просто сообщение «данных не хватает», а структурированное состояние задачи: чего именно нет и какое условие блокирует следующий этап.

Это позволяет другому исполнителю быстро понять, что от него требуется.

Если workflow остановился из-за отсутствия информации, это состояние стоит фиксировать отдельно.

Например:

· ожидается документ;

· требуется уточнение клиента;

· ожидается ответ внешней системы;

· обнаружены противоречивые данные;

· недостаточно обязательных параметров.

Так система понимает, почему работа не движется.

Без отдельного статуса остановленная задача легко потеряется среди обычных процессов.

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

Если этот цикл ничем не ограничен, пользователь окажется в бесконечном диалоге с системой.

Поэтому полезно контролировать количество циклов уточнения и определять момент, когда задача передаётся человеку или возвращается на ручную обработку.

Особенно это актуально для сложных заявок, где исходные данные поступают из нескольких источников.

Иногда информации не просто не хватает, а она расходится.

Например, в CRM указано одно название компании, а в загруженном договоре — другое. Или две системы содержат разные суммы.

В такой ситуации нельзя просто выбрать одно значение как «более вероятное».

Система должна понимать приоритет источников или иметь отдельный сценарий разрешения конфликта. Иначе агент фактически принимает бизнес-решение без соответствующего правила.

Для каждого агентного процесса полезно заранее определить:

1. Какие входные данные обязательны.

2. Какие параметры можно не запрашивать.

3. Какие значения допускают значения по умолчанию.

4. В каких случаях агент может сделать предположение.

5. Как помечаются предположения.

6. Какие источники можно использовать для самостоятельного поиска.

7. Что происходит при временной недоступности источника.

8. Как обрабатываются противоречивые сведения.

9. Когда задача должна остановиться.

10. Когда она передаётся человеку.

Эти правила позволяют превратить работу с неполными данными из импровизации модели в управляемую часть процесса.

Неполные входные данные особенно характерны для процессов, где информация поступает постепенно.

Это:

· клиентские заявки;

· обработка документов;

· закупки;

· финансовые операции;

· продажи;

· кадровые процессы;

· аналитика;

· поддержка клиентов;

· согласование договоров.

В таких сценариях ожидать идеального входа на старте просто нереалистично.

Надёжный AI-агент должен уметь работать не только с полной информацией, но и с её отсутствием.

При этом задача не сводится к тому, чтобы научить модель чаще задавать вопросы. Гораздо важнее определить, какие данные действительно необходимы, какие можно получить самостоятельно, где допустимо значение по умолчанию, а в какой момент процесс обязан остановиться.

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

Именно это отличает автономный workflow от модели, которая просто старается выдать ответ при любых обстоятельствах.