NPCI, da Índia, testa agentes de IA bancários: até 12% dos “sucessos” pularam etapas

A National Payments Corporation of India (NPCI), organização que gerencia a infraestrutura nacional de pagamentos do país, publicou o benchmark TauIndianBankBench. É um conjunto de 1000 tarefas em que um modelo de linguagem atua como assistente de um banco de varejo. Ele conversa com um cliente interpretado por outro modelo e aciona ferramentas: bloqueia um cartão, encerra um depósito, consulta o cronograma de pagamentos. A principal conclusão dos autores: se a avaliação olha apenas o estado final do banco de dados, como fazem a maioria dos testes do tipo, de 6,5% a 12,0% das sessões “bem-sucedidas” de todos os modelos, na prática, contêm uma violação de procedimento.

Por que o banco de dados final não basta

Hoje, os bancos indianos atendem os clientes por páginas de FAQ e chatbots roteirizados, com respostas fixas. Um modelo poderia responder mais rápido e lidar com perguntas que não estão no FAQ. Mas o banco só pode confiar essa tarefa a ele se o modelo passar informações corretas e seguir as regras internas: um erro atinge o cliente imediatamente.

O problema é que muitas etapas obrigatórias das regras não gravam nada no banco de dados. Exemplos do estudo:

• antes de encerrar um depósito, é preciso obter o cálculo do encerramento para que o cliente saiba o valor da multa; • antes de abrir um depósito de valor que talvez não caiba no saldo da conta, é preciso consultar a regra de saldo mínimo; • antes de bloquear um cartão, é preciso verificar o status dele.

Um agente que pulou tudo isso deixa no banco de dados exatamente os mesmos registros. A verificação pelo estado final o aprova, mas o cliente não recebe a informação para a qual essas etapas existem. Na Índia, muitas dessas etapas são exigidas por regulação: atualização periódica de KYC (verificação de identidade do cliente), retenção de imposto na fonte (TDS) com formulários de isenção e condições legais de participação em planos de poupança do governo.

Duas verificações em vez de uma

Cada sessão recebe dois veredictos de “aprovada/reprovada”:

• Verificação do estado final. A cadeia de chamadas de referência é executada em uma cópia idêntica do banco de dados, e depois os registros são comparados. Antes da comparação, são removidos os campos que mudam de uma execução para outra: números gerados, referências e anotações livres. • Verificação de ações. O agente precisa fazer todas as chamadas da cadeia de referência, inclusive as de leitura, em qualquer ordem. Qualquer alteração que o cliente não pediu reprova a sessão. Isso vale mesmo que o agente a tenha revertido depois: enquanto ela esteve em vigor, o cliente já foi prejudicado.

A sessão só é aprovada se passar nas duas verificações. Não há pontuação parcial: três chamadas de quatro valem zero, o mesmo que não fazer nada. A avaliação é totalmente determinística, sem modelo juiz, que pode ter viés a favor de respostas longas e do próprio estilo.

Como o benchmark é composto

• Um banco sintético com 944 clientes: contas, cartões, depósitos, empréstimos, ordens permanentes, status de KYC e histórico de operações. • 34 ferramentas: 33 de serviço e uma para transferir o cliente a um atendente humano. Das ferramentas de serviço, 20 só leem dados e 13 envolvem gravação (11 alteram registros e duas emitem o pedido de um talão de cheques ou da segunda via de um extrato).

• 24 documentos na base de conhecimento: limites de pagamento, atualização de KYC, seguro de depósitos, imposto sobre juros, prazos de devolução de pagamentos e planos do governo. • 50 famílias de tarefas em quatro categorias: tarefas dependentes de várias etapas, tarefas com uma condição que precisa ser notada antes da ação (por exemplo, o cliente não atende aos requisitos), operações raras e testes de controle simples. A cadeia de chamadas tem em média 3,54 chamadas, de uma a seis.

• Das 1000 tarefas, 962 exigem pelo menos uma chamada de leitura e 114 não exigem nenhuma gravação.

Há subconjuntos: o conjunto completo de 1000 tarefas, uma versão reduzida de 200 (quatro de cada família) e a divisão em partes de treino e de teste, para ajustar um modelo e medir o resultado de forma justa.

Nenhuma tarefa foi escrita do zero por uma pessoa: um modelo de linguagem fez os rascunhos, e elas só foram aceitas depois de passar por quatro filtros. As primeiras mensagens do cliente precisam ser diferentes entre si: no máximo 40% das tarefas de uma família podem começar da mesma forma, e são necessárias pelo menos oito variações. Para as tarefas complexas, a cadeia deve ter no mínimo três chamadas. Uma tarefa não pode estar ao mesmo tempo nas partes de treino e de teste. A cadeia de referência precisa passar nas duas verificações.

O que seis modelos mostraram

Os autores testaram seis modelos abertos, cinco deles da família Gemma 4. Resultados:

• em cada modelo, de 6,5% a 12,0% das sessões passam na verificação do estado final, embora o agente tenha pulado uma chamada obrigatória ou feito uma alteração indevida; • nos três modelos mais fortes, a maioria das sessões que falham em exatamente uma verificação são violações de procedimento que só a verificação de ações detecta; • no modelo mais fraco, o quadro é o inverso: ele faz todas as chamadas necessárias, mas termina com registros incorretos, e isso só a verificação do estado final detecta; • agentes de fachada baseados em scripts não passam em nenhuma tarefa; • nas tarefas de controle, o resultado não depende do tamanho do modelo, enquanto as três categorias mais difíceis diferenciam os modelos.

Para verificar a integridade da própria comparação, a implementação do avaliador foi confrontada com uma implementação independente em 600 sessões gravadas, e os veredictos coincidiram em todas. Antes do lançamento, o pacote reprocessou 5000 sessões e reproduziu todas as pontuações. O ranking dos modelos se repetiu também em outra configuração de execução dos modelos.

O que isso significa para bancos e desenvolvedores

Quem escolhe ou ajusta um modelo para o setor bancário não pode olhar apenas o estado final dos dados: parte das sessões “bem-sucedidas” violou o regulamento, e o cliente não recebeu as informações obrigatórias. O código, os dados e os resultados de referência estão publicados no GitHub e no Hugging Face. As limitações também são claras: o banco é sintético, o cliente é interpretado por um modelo e só foram testados modelos abertos.