Workflow com LLM e SHAP para scores de fraude prova

Um modelo de fraude dá 0,92 a uma transação e 0,35 a outra que parece quase igual. Diante disso, o analista não quer saber o que o modelo pensa. Quer saber o que separa as duas. O trabalho de Hanqing Dou (Universidade da Califórnia em San Diego) e Zijia Cao (Universidade de Chicago), publicado no arXiv (abre em nova aba) em 10 de outubro e aceito para a ICECER 2026, marcada para 3 a 5 de dezembro, responde a essa pergunta com uma decisão de engenharia que considero correta: o LLM não produz evidência. Ele raciocina sobre evidência que outra parte do sistema calculou e que uma terceira parte confere. O problema está na avaliação, que mede sobretudo se o sistema obedeceu ao próprio procedimento. Isso demonstra disciplina, mas ainda não demonstra diagnóstico.

O que o workflow faz

O alvo é um score de fraude em pagamentos gerado por um modelo de árvores. Não se trata de crédito nem de AML, e o trabalho vem da academia, não de um banco. Os autores treinam um XGBoost com 15 variáveis sobre o conjunto simulado do Fraud Detection Handbook: 21 dias, 201.295 transações, 1.792 fraudulentas (0,89%). Depois da divisão e da filtragem, ficam 67.240 transações para treino (598 fraudes) e 58.264 para teste (385 fraudes). O modelo atinge ROC-AUC de 0,885 e average precision de 0,6347 no teste. É competente sem ser perfeito, e isso é adequado ao estudo, porque um modelo que erra é justamente o que precisa ser explicado.

O pipeline tem quatro peças:

1. Recuperação de referências. Para uma transação-alvo, o sistema busca vizinhas no espaço das variáveis de entrada padronizadas, por distância euclidiana. Exige uma diferença mínima de score δ = 0,2 e fica com as K = 10 candidatas mais próximas que cumprem o critério.
2. SHAP contrastivo. As atribuições do alvo são comparadas às das referências. O SHAP é calculado sobre a margem bruta do XGBoost, enquanto o score exibido é a probabilidade.
3. Raciocínio do LLM. O modelo de linguagem recebe esse material e redige o diagnóstico, citando os registros de evidência por identificador.
4. Validação determinística. Um validador confere a reconstrução do SHAP e verifica se cada afirmação aponta para evidência que a sustenta.

Tudo foi empacotado como uma Codex Skill, rodando sobre o modelo que os autores identificam como gpt-5.6-sol, no Codex 0.145.0-alpha.27.

O acerto: tirar a evidência das mãos do modelo de linguagem

A avaliação de ponta a ponta usou 300 transações separadas: 100 de score baixo (abaixo de 0,1), 100 médias (de 0,1 a menos de 0,8) e 100 altas (0,8 ou mais). Cada uma rodou três vezes, o que dá 900 execuções por condição. As duas condições terminaram todas as execuções com algum diagnóstico. A diferença está no que esse diagnóstico continha:

Conjunto de referências100%43,2% (389/900)Referências contrastivas válidas100%1,8% (16/900)Evidência SHAP100%52,8% (475/900)Comparação local–global100%0,8% (7/900)Afirmações ligadas a evidência100%0%Validação de evidênciaaprovada em 100%não aplicável

O dado mais revelador é a distância entre os 52,8% de uso de SHAP e os 1,8% de referências contrastivas válidas. Sozinho, o modelo recorre ao SHAP com frequência, porque é a ferramenta óbvia. Quase nunca, porém, constrói a comparação que dá sentido ao SHAP nesta pergunta. As atribuições de uma única transação dizem o que empurrou o score. Só o contraste com uma vizinha próxima de score diferente diz o que separa as duas. Escolher essa vizinha é um problema de busca com restrições explícitas, o tipo de tarefa que um modelo de linguagem executa mal e que poucas linhas de código determinístico executam bem. O paper mostra, em números, que a parte difícil da explicação não é a redação.

O que o validador garante, e o que ele não alcança

A primeira verificação é a reconstrução do SHAP. Nos três alvos de auditoria (scores de 0,0941, 0,5104 e 0,9231), o erro máximo foi de 4,6 × 10⁻⁶ na margem e de 3,77 × 10⁻⁷ na probabilidade, ambos abaixo da tolerância de 10⁻⁵. Para modelos de árvore, o TreeSHAP satisfaz a acurácia local por construção: soma das atribuições mais valor base é igual à margem. A checagem, portanto, não testa o SHAP. Testa o pipeline. O bug que ela pega é o mundano: confundir margem com probabilidade, explicar a linha errada, truncar valores, deixar o LLM reescrever um número. É uma proteção útil, e os autores fazem bem em conferir as duas unidades separadamente.

A segunda verificação é a das afirmações. O validador confrontou 39 enunciados diagnósticos com 72 registros de evidência citados e rejeitou os que não tinham sustentação. Ele confirma que uma frase como "a variável X elevou o score" corresponde a um registro em que o SHAP de X é positivo. Não confirma que a história montada com frases sustentadas seja a mais relevante, nem que aquilo que o LLM deixou de fora fosse dispensável. Um diagnóstico pode ser feito só de afirmações verdadeiras e citadas e ainda assim enganar pela seleção.

Há um limite mais fundo. O SHAP explica o modelo, não a fraude. Se o XGBoost aprendeu uma correlação espúria, o validador vai certificar, com erro de 10⁻⁷, uma explicação fiel da correlação espúria. O título do paper é honesto nesse ponto: fala em diagnóstico de diferenças de score. O perigo está em quem lê "validado" e entende "verdadeiro sobre o mundo".

Por fim, tudo depende da recuperação. Nos três alvos, as distâncias médias das referências escolhidas foram 0,6245 (alvo de score baixo), 0,3488 (médio) e 0,2737 (alto), entre 71,1% e 81,6% menores que as de conjuntos aleatórios. Nenhum de 3.000 conjuntos aleatórios ficou tão perto. A comparação com o acaso, porém, é uma barra baixa: prova que a busca não é arbitrária, não que as referências sejam boas.

O padrão das distâncias também tem uma lógica que preocupa. Para um alvo de 0,0941, a referência precisa ter score de pelo menos 0,2941. Numa base com 0,89% de fraudes, scores altos são raros, e a vizinha qualificada mais próxima fica mais longe. O caso de uma fraude que passou com score baixo, talvez a pergunta mais cara para uma operação, tende a receber as referências menos parecidas. Com só três alvos, isso é um indício, não um padrão medido.

Duas escolhas de projeto pesam aqui. A distância euclidiana padronizada trata as 15 variáveis como igualmente importantes, independentemente do peso que cada uma tem no modelo. E o δ é fixo, sem que os autores o apresentem como ótimo. O LLM raciocina sobre as referências que recebe, e o validador confere afirmações contra essas mesmas referências. Nenhum componente pergunta se eram as referências certas.

Por que a comparação com o LLM sem guia diz pouco

O validador foi "não aplicável" no LLM sem orientação porque as saídas não tinham o formato exigido nem os identificadores de evidência. Os 0% de afirmações ligadas a evidência são quase uma definição: uma condição recebeu um formato com IDs e a outra não. Equivale a avaliar se respostas seguem um gabarito comparando quem recebeu o gabarito com quem não recebeu. Os próprios autores reconhecem o alcance do experimento: um dataset simulado, um modelo de árvore, uma configuração de LLM. As três execuções mostram consistência procedimental, não generalização.

Para sustentar a palavra "diagnóstico", faltariam três comparações:

• O mesmo LLM com as mesmas ferramentas e o procedimento descrito no prompt, mas sem a trava determinística. Isso isolaria a contribuição do validador.
• Um template determinístico, sem LLM, listando as maiores diferenças contrastivas de SHAP. Isso isolaria o que o modelo de linguagem acrescenta.
• Analistas julgando se os diagnósticos ajudam a decidir um caso mais rápido ou melhor.

Nos resultados reportados, nada disso aparece, e o teste ocorreu sobre dados simulados, não em operação. A segunda comparação é a que mais me incomoda. Se a evidência é calculada e conferida deterministicamente, sobra ao LLM selecionar e narrar. A seleção é justamente o que o validador não verifica. A contribuição real do modelo de linguagem fica concentrada na parte menos verificada do sistema.

O melhor contraponto

Numa operação de fraude, o procedimento é o produto. Um auditor, uma equipe de compliance ou uma contestação não perguntam se a explicação é perspicaz. Perguntam de onde veio cada frase. Por esse critério, um LLM com 0% de afirmações rastreáveis é inutilizável, por mais inteligente que soe, e os 100% em 900 execuções são o único número que importa. Medir conformidade seria medir a coisa certa.

Concedo boa parte disso. Rastreabilidade é pré-condição, e o paper mostra que ela se obtém com engenharia comum, não com um prompt melhor. Mas pré-condição não é suficiência, e há um agravante. O selo de "validado" transfere autoridade. Um texto sem citações convida à desconfiança. Um texto com 39 afirmações citadas e aprovadas convida à confiança. Se a seleção for enviesada ou as referências forem ruins, o sistema produz algo pior que uma explicação inverificável: uma explicação errada com aparência de verificada.

O que levar para o seu pipeline

• Calcule a evidência fora do LLM, dê a cada registro um ID estável e exija que toda afirmação cite IDs.
• Verifique a aditividade do SHAP na unidade que você mostra ao usuário. Se o score é probabilidade e o SHAP está em margem, confira as duas, como o paper faz.
• Registre a seleção de referências com distância e diferença de score, compare com conjuntos aleatórios e monitore os alvos em que as referências ficam distantes.
• Escolha a métrica de distância de forma consciente. A euclidiana padronizada ignora a importância das variáveis.
• Antes de adotar o LLM, compare-o com um template. Se o template resolve quase tudo, o modelo de linguagem é custo e risco opcionais.
• Avalie com analistas, não só com checagens de formato.

O trabalho de Dou e Cao deve ser lido como um padrão de arquitetura, não como prova de que LLMs diagnosticam bem diferenças de score. Ele mostra que o lugar do modelo de linguagem num sistema de risco é a última etapa, cercada por cálculo e conferência. Falta mostrar que, nessa etapa, ele escolhe bem o que dizer. Até lá, o que o validador aprova é a contabilidade da explicação, não a sua verdade.

Fontes

• A Controlled LLM Workflow for Evidence-Grounded Diagnosis of Risk Score Differences · arxiv.org · 09/10/2026
• A Controlled LLM Workflow for Evidence-Grounded Diagnosis of Risk Score Differences (HTML) · arxiv.org · 09/10/2026