AnoLLM: Ajuste Fino de LLMs para Detecção de Anomalias em Dados Tabulares Financeiros

O artigo sobre detecção de anomalias com LLM zero-shot que li há dois dias (arXiv:2406.16308) mostrou que o GPT-4 consegue identificar outliers tabulares sem qualquer treinamento, igualando-se a referências clássicas como o ECOD no benchmark ODDS. Mas ele tinha uma fraqueza óbvia: pedir ao modelo para gerar uma lista de índices de linhas anômalas é frágil — modelos de código aberto frequentemente alucinam índices, saem dos limites ou marcam todas as linhas como suspeitas. O AnoLLM, publicado no ICLR 2025 por Che-Ping Tsai, Ganyu Teng, Phillip Wallis e Wei Ding da Amazon, resolve essa fragilidade ao mesmo tempo em que avança em conjuntos de dados de tipos mistos, onde as referências puramente numéricas começam a ter dificuldades.

O artigo

O AnoLLM reformula a detecção de anomalias tabulares como estimativa de densidade de modelo de linguagem, em vez de classificação por prompts. Em vez de pedir à LLM para nomear quais linhas parecem suspeitas, os autores fazem o ajuste fino de um modelo de linguagem pré-treinado em linhas de treinamento serializadas dentro da distribuição (normais) e, em seguida, pontuam cada linha de teste por sua log-verossimilhança negativa (NLL) sob essa distribuição aprendida. Uma linha que não se parece em nada com a distribuição de treinamento recebe um NLL alto — essa é a pontuação de anomalia. Sem formato de índice, sem análise de saída, sem extração frágil por regex.

A serialização converte cada linha da tabela em uma string de linguagem natural com nomes e valores de recursos. Para colunas com valores de texto, a NLL é normalizada por coluna para evitar viés de comprimento, onde descrições mais longas, de outra forma, acumulariam mecanicamente custos de probabilidade mais altos. Para colunas numéricas e categóricas, a NLL bruta ao nível de token é somada em todo o campo. O modelo é ajustado em um cenário semissupervisionado — apenas linhas rotuladas como normais entram no treinamento — por até 2.000 etapas usando treinamento em GPU distribuída.

Ideias principais

• O problema do formato de saída: abordagens anteriores de previsão de índices exigem que as LLMs gerem de forma confiável os índices das linhas anômalas de um lote. Modelos da família Llama frequentemente associam índices errados a valores, geram índices além do tamanho do lote ou simplesmente listam tudo como anômalo. A NLL contorna isso inteiramente.
• O AnoLLM atinge o melhor desempenho em seis conjuntos de dados de benchmark com tipos de recursos mistos, incluindo detecção de fraude em seguros de veículos e conjuntos de dados de fraude de e-commerce do Kaggle.
• Nos 30 conjuntos de dados do benchmark ODDS, predominantemente numéricos, o AnoLLM tem um desempenho equivalente às melhores referências clássicas — não claramente melhor, apenas competitivo.
• A normalização da NLL por coluna para recursos de texto é uma decisão de engenharia pequena, mas fundamental: sem ela, uma descrição de transação com trinta tokens dominaria a pontuação sobre um valor de dois dígitos, o que é um viés indutivo incorreto.
• O contexto da linha de base de treinamento: a abordagem zero-shot do GPT-4 (arXiv:2406.16308) atinge um AUROC médio de 74,1 no ODDS, comparável ao ECOD (75,5) e KNN (70,7). A vantagem do AnoLLM aparece especificamente em conjuntos de dados onde recursos de texto e categóricos carregam sinais de anomalia significativos.

O que se sustenta — e o que não

A ideia central da NLL é sólida. Usar um modelo de linguagem com ajuste fino como estimador de densidade sobre linhas serializadas é fundamentado e lida naturalmente com a distribuição conjunta de todas as colunas simultaneamente — algo que detectores não supervisionados clássicos aplicados coluna por coluna não conseguem fazer de forma limpa. A correção para a previsão de índices é genuinamente útil e a comparação com a linha de base zero-shot é justa.

O que me incomoda é a lacuna de custo-benefício que o artigo subnotifica. O AnoLLM requer ajuste fino e a disponibilização de uma LLM para inferência — um compromisso substancial de infraestrutura em comparação com o ajuste de um ECOD ou IsolationForest em uma CPU em segundos. No benchmark ODDS (puramente numérico), o AnoLLM é apenas "equivalente", não melhor. Portanto, o caso de uso do AnoLLM está inteiramente no regime de tipos mistos, onde os seis conjuntos de dados avaliados são de detecção de fraude do Kaggle. Seis conjuntos de dados é uma base empírica rasa para uma recomendação forte, especialmente porque os conjuntos de dados de benchmark do Kaggle tendem a ter esquemas limpos, semântica de coluna fixa e verdades fundamentais conhecidas — todas as coisas que os dados de livros contábeis em produção costumam carecer.

O problema da ordenação das colunas também ficou em aberto. O CausalTAD (arXiv:2602.07798) identificou imediatamente essa lacuna: o AnoLLM serializa colunas em ordem arbitrária, ignorando as relações causais entre os campos. Para dados estruturados com cadeias causais conhecidas — o tipo de conta influencia os intervalos de transação válidos, que por sua vez influenciam a contraparte esperada — isso é uma limitação real. O CausalTAD enquadra a reordenação como um problema de ordenação linear e relata melhorias consistentes sobre o AnoLLM em mais de 30 conjuntos de dados. O fato de essa lacuna existir e ter sido encontrada tão rapidamente sugere que o design de serialização do AnoLLM não foi totalmente pensado.

Há também uma questão de escala que o artigo não aborda: com que volume de exemplos de treinamento normais o ajuste fino de uma LLM passa a valer a pena em relação a, digamos, um modelo de aprendizado profundo tabular treinado diretamente nos recursos numéricos? Para livros contábeis pessoais do Beancount com alguns milhares de lançamentos, o custo de computação pode facilmente ofuscar qualquer ganho de precisão.

Por que isso importa para a IA nas finanças

Os lançamentos do livro contábil do Beancount são exatamente o tipo de dados mistos que o AnoLLM visa: valores (numéricos), nomes de contas (texto estruturado), favorecido/narração (texto livre), tags (categóricos), datas (estruturadas). Uma única linha como 2024-03-15 * "AWS" "Fatura na nuvem" Assets:Checking -2400.00 codifica informações em todos esses tipos simultaneamente. Os detectores de anomalias clássicos têm dificuldade aqui porque precisam de tratamento separado para cada tipo de coluna e perdem as correlações entre elas — o padrão conjunto de que faturas da "AWS" devem estar em uma determinada faixa e atingir uma conta específica.

A abordagem NLL do AnoLLM aprenderia, em princípio, esses padrões conjuntos a partir de lançamentos históricos normais e sinalizaria desvios em qualquer combinação de colunas. Isso é potencialmente mais útil do que JETs baseados em regras ou testes estatísticos de coluna única.

Dito isso, a restrição da contabilidade de partidas dobradas é um conhecimento estrutural que o AnoLLM não pode aprender apenas com linhas serializadas — os débitos devem ser iguais aos créditos, as hierarquias de contas devem ser respeitadas. Esses invariantes de domínio são restrições rígidas, não regularidades estatísticas, e nenhum ajuste fino de LLM em linhas históricas os aplicará de forma confiável se os dados de treinamento contiverem exceções ou artefatos de arredondamento. A arquitetura correta provavelmente combina a pontuação NLL do AnoLLM para anomalias semânticas com verificações de regras explícitas para as estruturais.

O que ler a seguir

• CausalTAD (arXiv:2602.07798) — melhora diretamente o AnoLLM injetando ordenação causal de colunas; o acompanhamento mais imediato para avaliar.
• AD-LLM: Benchmarking Large Language Models for Anomaly Detection (arXiv:2412.11142, ACL Findings 2025) — fornece a avaliação sistemática multiparadigma que falta em artigos de métodos individuais.
• "Language Models are Realistic Tabular Data Generators" (Borisov et al., arXiv:2210.06280, ICLR 2023) — o modelo BE-GREAT que o AnoLLM usa como base; entendê-lo esclarece o que o AnoLLM realmente melhora além da previsão de índices.