Индийский NPCI проверил ИИ-агентов банка: до 12% «успехов» с пропущенными шагами

National Payments Corporation of India (NPCI) — организация, которая управляет национальной платёжной инфраструктурой страны, — опубликовала бенчмарк TauIndianBankBench. Это набор из 1000 задач, где языковая модель работает ассистентом розничного банка. Она общается с клиентом, которого играет другая модель, и вызывает инструменты: блокирует карту, закрывает вклад, смотрит график платежей. Главный вывод авторов: если проверять только итоговое состояние базы данных, как делают большинство подобных тестов, то у всех моделей 6,5–12,0% «успешных» сессий на деле содержат нарушение процедуры.

Почему итоговой базы мало

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

Проблема в том, что многие обязательные шаги правил ничего не записывают в базу. Примеры из работы:

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

Агент, который всё это пропустил, оставит в базе ровно те же записи. Проверка по итоговому состоянию его пропустит, но клиент не получит информацию, ради которой шаги и предусмотрены. В Индии многие такие шаги закреплены регуляторикой: периодическое обновление KYC (проверки личности клиента), удержание налога у источника (TDS) с формами освобождения, законные условия участия в государственных сберегательных схемах.

Две проверки вместо одной

Каждая сессия получает два вердикта «прошла/не прошла»:

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

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

Из чего собран бенчмарк

• Синтетический банк на 944 клиента: счета, карты, вклады, кредиты, постоянные поручения, статус KYC, история операций. • 34 инструмента: 33 сервисных и один для передачи клиента живому сотруднику. Из сервисных 20 только читают данные, 13 относятся к записи (11 меняют записи, два оформляют заказ чековой книжки или дубликата выписки).

• 24 документа базы знаний: лимиты платежей, обновление KYC, страхование вкладов, налог на проценты, сроки возврата платежей, госсхемы. • 50 семейств задач в четырёх категориях: зависимые многошаговые, задачи с условием, которое нужно заметить до действия (например, клиент не подходит под условия), редкие операции и простые контрольные. Цепочка вызовов в среднем состоит из 3,54 вызова, от одного до шести.

• Из 1000 задач 962 требуют хотя бы одного вызова на чтение, 114 не требуют ни одной записи.

Есть срезы: полный набор в 1000 задач, облегчённый на 200 (по четыре из каждого семейства) и его разбиение на обучающую и тестовую части, чтобы дообучать модель и честно мерить результат.

Человек не писал задачи с нуля: их набросала языковая модель, а допускались они через четыре фильтра. Первые сообщения клиента должны различаться: не больше 40% задач семейства могут начинаться одинаково, и нужно минимум восемь вариантов. Для сложных задач цепочка должна быть не короче трёх вызовов. Задача не может попасть сразу в обучающую и тестовую части. Эталонная цепочка обязана проходить обе проверки.

Что показали шесть моделей

Авторы протестировали шесть открытых моделей, пять из них из семейства Gemma 4. Результаты:

• у каждой модели 6,5–12,0% сессий проходят проверку по итоговому состоянию, хотя агент пропустил обязательный вызов или внёс лишнее изменение; • у трёх сильнейших моделей большинство сессий, проваливших ровно одну проверку, — нарушения процедуры, которые видит только проверка действий; • у самой слабой модели картина обратная: она делает все нужные вызовы, но заканчивает с неверными записями, и это ловит только проверка итогового состояния; • скриптовые агенты-пустышки не проходят ни одной задачи; • на контрольных задачах результат не зависит от размера модели, а три категории посложнее модели различают.

Для проверки честности самого сравнения реализацию оценщика сверили с независимой на 600 записанных сессиях, вердикты совпали везде. Пакет перед выпуском пересчитал 5000 сессий и воспроизвёл все оценки. Рейтинг моделей повторился и на другой установке для запуска моделей.

Что это значит для банков и разработчиков

Кто выбирает или дообучает модель для банкинга, не может смотреть только на итоговое состояние данных: часть «успешных» сессий на самом деле нарушила регламент, а клиент не получил обязательных сведений. Код, данные и эталонные результаты опубликованы на GitHub и Hugging Face. Ограничения тоже понятны: банк синтетический, клиента изображает модель, а испытывали только открытые модели.