Недетерминированный ИИ — кратчайший путь к потере денег и клиентов

Агент сверки платежей работал шесть недель, когда неправильно распределил $340 000 по семнадцати клиентским счетам. Задача агента была простой: сопоставлять входящие банковские переводы с неоплаченными счетами, извлекая номера из описаний платежей и вызывая API бухгалтерской системы для распределения средств. Во вторник клиент отправил оплату трёх счетов одним переводом с описанием: «INV-2024-0892, INV-2024-0894, INV-2024-0901 — частичная оплата по 0901». Агент интерпретировал «частичная оплата» как относящееся ко всем трём счетам и распределил средства пропорционально. На самом деле нужно было полностью закрыть первые два счёта, а остаток направить на третий. Баланс клиента перестал сходиться с его данными, автоматически сработала кредитная блокировка, и следующая отгрузка простояла на складе девять дней, пока бухгалтерия разбиралась с ошибкой.

Именно этот паттерн сбоев убивает внедрения агентов. Не ошибки форматирования и не простые проблемы парсинга — их ловят в первую неделю. Разрушительные сбои происходят, когда агенты обрабатывают сложные финансовые сообщения с множеством сущностей, условной логикой и неявными бизнес-правилами, которые люди считывают неосознанно, а языковые модели интерпретируют вероятностно. Описание перевода «Оплата услуг за Q3 минус $12 400 спорной суммы по звонку с Ириной от 15.10» требует от агента извлечь полную сумму, определить вычет, понять, что $12 400 не должны распределяться, и поставить флаг на спорную сумму для дальнейшей работы. Агент может справиться с этим правильно девяносто семь раз. На девяносто восьмой он распределит полную сумму и закроет счёт, похоронив живой спор, который всплывёт через три месяца как списание.

Ошибки при вызове инструментов множатся экспоненциально, когда агент передаёт извлечённые данные в системы, которые доверяют входным данным. Агент закупок, обрабатывающий предложения поставщиков, извлекал позиции из PDF-коммерческих предложений и вызывал ERP-систему для создания заказов на закупку. С большинством предложений агент справлялся корректно, но когда поставщик прислал предложение со сноской о том, что цены действительны только для заказов от 500 единиц, агент создал заказ на 200 единиц по оптовой цене. Поставщик отклонил заказ. Производственная линия четыре дня ждала материалы, которые никогда не придут по этой цене, а срочная доставка для спасения графика обошлась дороже, чем агент сэкономил за квартал.

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

У провала тестирования есть конкретная причина: всестороннее тестирование поведения агента стоит дорого. Каждый тестовый сценарий требует реальных данных, фактических вызовов API и человеческой верификации результата. Команды, которые никогда не выпустили бы традиционный софт с двенадцатью тест-кейсами, выпускают агентов именно с таким покрытием, потому что стоимость тщательного тестирования кажется несоразмерной. Расчёт неверен. Цена недостаточного тестирования платится не на этапе разработки — она выплачивается клиентскими компенсациями, бухгалтерскими корректировками и операционным тушением пожаров через три месяца после запуска.

Смена фокуса должна быть такой: надёжность агента — это не проблема модели и не проблема промпт-инжиниринга. Это проблема покрытия тестами, замаскированная под проблему ИИ. Та же организация, которая требует 80% покрытия кода для биллинговой системы, запустит агента, работающего с теми же биллинговыми данными, вообще без формальных критериев приёмки. К агенту предъявляют заниженные требования именно потому, что он кажется более сложным, тогда как на самом деле ему нужны более высокие стандарты, поскольку его режимы отказа менее предсказуемы.

Команды, которые успешно используют агентов в финансовых процессах, не имеют лучших моделей или лучших промптов. У них есть тестовые наборы с сотнями сценариев, построенные на реальных продакшен-данных и еженедельно пополняемые новыми случаями сбоев. Они рассматривают каждую ошибку агента как недостающий тест, а не как случайность. Это рутинная, неблагодарная работа, которую никто не хочет финансировать на этапе разработки. Но это единственное, что отличает агентов, работающих надёжно, от агентов, создающих дорогостоящие проблемы в непредсказуемые моменты.