跳到主要内容

AnoLLM:针对金融数据表格式异常检测的 LLM 微调

· 阅读需 7 分钟
Mike Thrift
Mike Thrift
Marketing Manager

我两天前读到的那篇关于零样本 LLM 异常检测的论文 (arXiv:2406.16308) 表明,GPT-4 无需任何训练就能识别表格式离群值,在 ODDS 基准测试上达到了 ECOD 等经典基线的水平。但它有一个明显的弱点:要求模型输出异常行索引列表是非常脆弱的 —— 开源模型经常会幻觉产生索引、超出范围,或者将每一行都标记为可疑。由亚马逊的 Che-Ping Tsai、Ganyu Teng、Phillip Wallis 和 Wei Ding 在 ICLR 2025 上发表的 AnoLLM 修复了这种脆弱性,同时也进军了纯数值基线开始感到吃力的混合类型数据集。

论文内容

2026-06-24-anollm-llm-fine-tuning-tabular-anomaly-detection

AnoLLM 将表格式异常检测重新构想为语言模型密度估计,而非提示分类。作者不是让 LLM 指出哪些行看起来可疑,而是在序列化的分布内(正常)训练行上微调预训练语言模型,然后根据学习到的分布下的负对数似然 (NLL) 为每个测试行评分。与训练分布完全不符的行会获得较高的 NLL —— 这就是异常评分。没有索引格式,没有输出解析,也没有脆弱的正则提取。

序列化过程将每个表格行转换为包含特征名称和值的自然语言字符串。对于文本值列,NLL 按列进行归一化以避免长度偏差,否则较长的描述会机械地积累更高的概率成本。对于数值和分类列,原始 Token 级别的 NLL 会在字段内累加。该模型在半监督设置下进行微调 —— 只有标记为正常的行进入训练 —— 使用分布式 GPU 训练,最多进行 2,000 步。

核心观点

  • 输出格式问题: 先前的索引预测方法要求 LLM 能够可靠地从批次中输出异常行索引。Llama 系列模型经常将错误的索引与数值配对,生成超出批次大小的索引,或者干脆将所有内容列为异常。NLL 完全绕过了这一点。
  • AnoLLM 在六个具有混合特征类型的基准数据集上实现了最佳性能,包括来自 Kaggle 的汽车保险欺诈检测和电子商务欺诈数据集。
  • 在 30 个以数值为主的 ODDS 基准数据集上,AnoLLM 的表现与顶级经典基线持平 —— 虽然没有明显更好,但具有竞争力。
  • 文本特征的“每列 NLL 归一化”是一个虽小但关键的工程决策:如果没有它,包含三十个 Token 的交易描述会在评分中压倒两位数的金额,这是一种错误的归一化偏置。
  • 训练基线背景: 零样本 GPT-4 方法 (arXiv:2406.16308) 在 ODDS 上的平均 AUROC 为 74.1,与 ECOD (75.5) 和 KNN (70.7) 相当。AnoLLM 的优势具体体现在文本和分类特征承载有意义异常信号的数据集上。

哪些站得住脚,哪些站不住脚

NLL 的核心思想是可靠的。将微调后的语言模型用作序列化行上的密度估计器是符合原理的,并且它能自然地同时处理所有列的联合分布 —— 这是逐列应用经典无监督检测器无法干净利落完成的事情。对索引预测的修复确实有用,且与零样本基线的比较也是公平的。

令我困扰的是论文中未充分报告的成本效益差距。AnoLLM 需要微调并部署一个 LLM 进行推理 —— 与在 CPU 上几秒钟内拟合 ECOD 或孤立森林 (IsolationForest) 相比,这是一项巨大的基础设施投入。在 ODDS 基准(纯数值)上,AnoLLM 仅是“持平”,而非更优。因此,AnoLLM 的论据完全在于混合类型领域,而评估的六个数据集均来自 Kaggle 上的欺诈检测。对于一个强有力的推荐来说,六个数据集的经验基础显得单薄,尤其是考虑到来自 Kaggle 的基准数据集往往具有整洁的模式、固定的列语义和已知的地面真值 —— 这些都是生产环境账本数据通常缺乏的。

列排序问题也悬而未决。CausalTAD (arXiv:2602.07798) 立即发现了这一差距:AnoLLM 以任意顺序序列化列,忽略了字段之间的因果关系。对于具有已知因果链的结构化数据 —— 例如账户类型影响有效的交易范围,进而影响预期的交易对手 —— 这是一个真正的局限。CausalTAD 将重新排序视为线性排序问题,并报告称在 30 多个数据集上相比 AnoLLM 有持续的改进。这个差距的存在且能被如此迅速地发现,表明 AnoLLM 的序列化设计并未经过充分考虑。

还有一个论文未提及的规模问题:正常训练样本达到多大数量级时,微调 LLM 的价值才会超过直接在数值特征上训练的表格式深度学习模型?对于只有几千条分录的个人 Beancount 账本,计算成本可能轻易抵消任何精度提升。

为什么这对金融 AI 很重要

Beancount 账本分录正是 AnoLLM 针对的那种混合类型数据:金额(数值)、账户名称(结构化文本)、收款人/摘要(自由文本)、标签(分类)、日期(结构化)。像 2024-03-15 * "AWS" "Cloud invoice" Assets:Checking -$2,400 这样的一行数据同时编码了跨越所有这些类型的信息。经典异常检测器在这里会很吃力,因为它们需要为每种列类型分别处理,并且会丢失它们之间的相关性 —— 即“AWS”发票应该在特定范围内并对应特定账户的联合模式。

AnoLLM 的 NLL 方法原则上可以从历史正常分录中学习这些联合模式,并标记任何列组合中的偏差。这可能比基于规则的 JETs 或单列统计测试更有用。

尽管如此,复式记账约束是 AnoLLM 无法仅从序列化行中学习到的结构化知识 —— 借贷必须相等,账户层级必须被遵守。这些领域不变性是硬约束,而非统计规律,如果训练数据包含任何异常或舍入伪影,无论对历史行进行多少 LLM 微调,都无法可靠地强制执行它们。正确的架构可能是将 AnoLLM 的语义异常 NLL 评分与结构化异常的显式规则检查相结合。

延伸阅读

  • CausalTAD (arXiv:2602.07798) —— 通过引入因果列排序直接改进了 AnoLLM;这是最值得评估的直接后续研究。
  • AD-LLM: Benchmarking Large Language Models for Anomaly Detection (arXiv:2412.11142, ACL Findings 2025) —— 提供了个人方法论文中缺失的系统性多范式评估。
  • "Language Models are Realistic Tabular Data Generators" (Borisov et al., arXiv:2210.06280, ICLR 2023) —— AnoLLM 用作基线的 BE-GREAT 模型;了解它可以阐明 AnoLLM 在索引预测之外究竟改进了什么。