基准测试不等于验证：金融大语言模型应用的系统级视角

# 基准测试并非验证：金融 LLM 应用的系统级视角
来源：https://arxiv.org/html/2607.28840
İrem DemirtaşSimona Scalaİrem Demirtaş&Elena Ferretti Prometeia S\.p\.A\. \{burak\.payzun, irem\.demirtas, simona\.scala, elena\.ferretti, secil\.arslan\}@prometeia\.com

###### 摘要

大型语言模型越来越多地部署在金融应用中，这些应用结合了检索、专有数据、工具调用、编排逻辑、监控和人工升级。然而，评估往往仍以模型为中心：基准分数、任务准确率或一次性的定性审查被视为就绪的证据。在金融场景中，这并不充分。我们的立场是，金融 LLM 系统不应仅基于基准测试表现就获准投入生产。它们需要跨越整个应用栈的系统级验证证据：数据、模型设计、检索与生成性能、智能体行为、治理和实现。借鉴我们在金融机构中验证生成式 AI 应用的行业经验，我们勾勒出一个多层验证视图，并解释为何混合评估是必要的。我们讨论了 LLM 作为评判者的方法在哪些方面有用，以及为何它们需要诸如多重评判者、评分标准、一致性和可审计性检查等控制措施。我们还强调了静态基准测试难以捕捉的失败模式，包括检索失败、不忠实的生成、工具误用、升级错误和运行不稳定。我们的立场是，金融 LLM 验证应当是一项持续的系统性纪律，而非一次性的模型评分工作。验证应产生可供决策的证据，而不仅仅是分数。最后，我们提出了一个研究议程，涵盖系统感知基准测试、智能体轨迹验证、评判者对齐协议和生命周期验证标准。

## 1 引言

金融 LLM 评估发展迅速。FinBen 等基准测试覆盖金融信息提取、文本分析、问答、生成、风险管理、预测和决策制定Xieet al\.\(2024 (https://arxiv.org/html/2607.28840#bib.bib29)\)。更早的数据集如 FinQA 和 ConvFinQA 表明，金融问答通常需要对金融文档进行数值和多步对话推理Chenet al\.\(2021 (https://arxiv.org/html/2607.28840#bib.bib21),2022 (https://arxiv.org/html/2607.28840#bib.bib22)\)。这些基准测试使模型比较更加系统化，并暴露了通用评估可能遗漏的弱点，但它们并未解决金融机构面临的验证问题。

金融机构正在从实验转向实际工作流。LLM 系统现在用于总结文档、回答客户或分析师的问题、为信贷和贷款流程提取信息、支持合规审查以及辅助内部决策。许多系统已不再是简单的提示-响应系统；它们结合了检索增强生成、专有知识库、提示编排、外部工具、API、用户界面、监控层，有时还包括多智能体工作流。

这种转变改变了验证的含义。基准分数几乎无法说明一个已部署系统是否检索到正确的文档、保持事实依据、遵守护栏、处理敏感数据、升级不确定案例、抵御提示注入、安全调用工具，或在第三方模型或 API 变更后保持稳定。在金融领域，这些并非次要问题：它们决定了系统是否可靠、可审计且适合其用途。

银行业监管进一步提高了验证标准。验证和审计职能日益被期望不仅评估传统模型，还要评估基于 LLM 的应用和 AI 驱动的工作流。诸如模型风险管理 \(MRM\) 指南和欧盟 AI 法案等监管框架，强化了在整个生命周期中进行治理、可追溯性、可解释性和持续监督的必要性。

现有的评估方法只覆盖了部分问题。经典 NLP 指标对受限任务有用，但往往依赖于参考答案和表面相似性。人工评估有价值，但规模化成本高昂。LLM 作为评判者的方法灵活且快速，可以在某些开放式场景中接近人类偏好Zhenget al\.\(2023 (https://arxiv.org/html/2607.28840#bib.bib30)\); Liuet al\.\(2023 (https://arxiv.org/html/2607.28840#bib.bib26)\)；然而，它们引入了提示敏感性、评判者偏见、可复现性问题和过度自信。没有单一方法足以应对。

数据验证模型性能IT架构与实现模型设计模型使用与治理定量评估指标、阈值、检索/生成分数、评判者一致性、延迟和负载测试结果定性评估专家审查、文档审查、治理和风险判断验证证据包：定量结果、定性发现、失败模式、补救措施和生命周期控制，支持批准、有条件批准或拒绝。图1：金融 LLM 应用系统级验证的五支柱视图。数据、性能、IT架构与实现主要属于定量评估支柱；模型设计和模型使用与治理主要属于定性评估支柱。这些支柱是独立的评估维度，而非流水线。因此，机构需要反映其文档、工作流、用户、风险和监管约束的系统特定测试集、场景和验收标准。这在实践中很困难：历史数据可能有限，可接受行为可能不明确，标注成本高昂，合成案例可能引入偏见。对于缺乏生产轨迹或已知失败的新系统，基准性能与系统就绪证据之间的差距尤其大。

我们的立场是，金融 LLM 系统不应仅基于基准测试表现就获准投入生产。它们需要跨越完整应用栈的系统级验证证据：数据、模型设计、检索和生成行为、智能体决策逻辑、治理流程和 IT 实现，并根据用例风险校准人工监督。验证要求也因用例而异。低风险内部助手、基于 RAG 的知识搜索系统、面向客户的聊天机器人以及支持信用评估的系统，具有不同的风险概况和验证预期。

我们围绕五个独立支柱来组织这一验证视图：数据、模型设计、性能、模型使用与治理，以及 IT 架构与实现。这些支柱并非流水线或层级；它们是互补的评估维度。验证证据还应区分定量评估（主要支持数据、性能和 IT 实现）与定性评估（主要支持模型设计和治理）。两种形式的证据都汇入结构化的验证证据包，以支持批准、有条件批准或拒绝。图1 (https://arxiv.org/html/2607.28840#S1.F1)总结了这一视图。

本文做出三项贡献。首先，阐明了为何以基准测试为中心的评估不足以支撑已部署的金融 LLM 系统。其次，提出了一个系统级验证视图，涵盖数据、模型设计、性能、智能体行为、治理和实现。第三，指出了金融 LLM 验证的研究方向，包括轨迹级智能体评估、可审计的 LLM 作为评判者协议，以及生命周期验证标准。

## 2 相关工作

金融基准测试套件在广泛的任务族上评估 LLM，如信息提取、问答、预测、风险管理和决策制定Xieet al\.\(2024 (https://arxiv.org/html/2607.28840#bib.bib29)\)，但基准测试覆盖并不等于部署验证。

关于金融基础模型的综述，系统梳理了语言、时间序列和视觉-语言模型在开放性挑战、合规性、幻觉、非平稳性和部署成本方面的问题Chenet al\.\(2025 (https://arxiv.org/html/2607.28840#bib.bib31)\)。在金融问答上对 DeepSeek-R1 进行基准测试显示出较高的准确率，但小规模单选题数据集、监管场景下持续的幻觉以及多模态能力的缺失，仍然造成了部署差距Liuet al\.\(2025a (https://arxiv.org/html/2607.28840#bib.bib32)\)。这些工作都将问题框架为模型层面的关切；我们则将其视为系统级验证需求。

RAG 评估通过分离检索质量、上下文相关性、答案相关性和忠实度，超越了最终答案评分；例如，RAGAS 为这些模块化流水线提供了无参考指标Eset al\.\(2024 (https://arxiv.org/html/2607.28840#bib.bib24)\)。这在金融领域尤为重要，因为基于内部文档集合构建的应用使事实依据失败成为重大风险。

LLM 作为评判者的方法可以在开放式场景中接近人类偏好Zhenget al\.\(2023 (https://arxiv.org/html/2607.28840#bib.bib30)\)，并在选定的 NLG 任务上提高与人类判断的相关性Liuet al\.\(2023 (https://arxiv.org/html/2607.28840#bib.bib26)\)，但它们表现出位置、冗长、权威和自我偏好偏见 \(表1 (https://arxiv.org/html/2607.28840#S2.T1)\)Zhenget al\.\(2023 (https://arxiv.org/html/2607.28840#bib.bib30)\); Chenet al\.\(2024 (https://arxiv.org/html/2607.28840#bib.bib23)\)。评判者小组或陪审团可以减少对单一模型的依赖Vergaet al\.\(2024 (https://arxiv.org/html/2607.28840#bib.bib28)\)，但仍然需要可审计性和一致性检查。

表 1：LLM 作为评判者评估在实践中常见的陷阱和缺陷。尽管 LLM 评判者提供了可扩展的定性评估，它们仍然容易受到系统性偏见、不稳定性和评估者特定失败模式的影响。智能体评估是另一个新兴研究方向。AgentBench 在交互式环境中将 LLM 作为智能体进行评估，并指出长期推理、决策制定和指令遵循是核心障碍Liuet al\.\(2025b (https://arxiv.org/html/2607.28840#bib.bib14)\)。StableToolBench 关注当 LLM 与外部工具和 API 交互时，稳定工具使用评估的难度Guoet al\.\(2025 (https://arxiv.org/html/2607.28840#bib.bib13)\)。AgentDiagnose 认为最终任务成功使智能体决策过程不透明，并提出了轨迹级诊断Ouet al\.\(2025a (https://arxiv.org/html/2607.28840#bib.bib15)\)。这对金融领域很重要，因为工具选择、参数传递、权限或升级中的错误可能比最终响应的流畅性更重要。

表 2：智能体验证应结合黑盒、灰盒、白盒和消融式证据。当金融 LLM 系统能够检索、路由、调用工具或执行工作流时，最终答案的正确性是必要的，但还不够。一个有用的区分是白盒、黑盒和灰盒评估方法，如表2 (https://arxiv.org/html/2607.28840#S2.T2)所示：

- • 白盒评估：使用轨迹、元数据或内部输出来评估中间行为，如工具选择、参数正确性、证据使用、推理轨迹或任务分解。这在检查过程而非仅检查最终答案的诊断数据集和基准测试中有所体现Mialonet al\.\(2023b (https://arxiv.org/html/2607.28840#bib.bib10)\); Wanget al\.\(2022 (https://arxiv.org/html/2607.28840#bib.bib11)\); Wolfsonet al\.\(2020 (https://arxiv.org/html/2607.28840#bib.bib12)\)。
- • 黑盒评估：仅评估用户输入和最终输出。典型检查包括结果正确性、对提示变换的鲁棒性、重复运行一致性、安全性和拒绝行为。
- • 灰盒评估：将结果评估与部分内部信息相结合，例如检索到的段落、置信度信号、工具调用摘要或升级日志。当评估系统是否识别出缺失、冲突或不安全的条件时，这种方法很有用。

这一区分在金融领域很重要，因为一个看起来正确的最终答案可能掩盖不安全的中间行为、政策违规或不正确的工具使用。

因此，差距很明显：现有工作提供了有用的评估组件，但金融机构需要一个整合的验证视图，将基准测试性能、RAG 评估、评判者可靠性、智能体轨迹、治理、安全性和生产实现连接起来。

## 3 以基准测试为中心的评估的局限性

基准测试对于可比较性、报告和模型选择很有用，但金融 LLM 系统失败的方式，基准分数无法捕捉。

首先，基准测试通常孤立地评估模型或任务。已部署的金融应用还包括摄取、分块、嵌入、检索、提示构建、生成、后处理、日志记录、反馈收集和升级。即使底层模型很强，任何组件的失败都可能产生不正确或不安全的输出。

其次，金融任务具有上下文特异性。公开基准测试可能无法反映机构自身的文档、产品、监管环境、语言组合、风险偏好或运营约束。一个在通用金融问答上表现良好的模型，仍可能在内部政策、本地银行术语或特定报告模板上失败。

第三，即使金融专用基准测试也受限于任务格式、源材料、标注策略、答案类型和评估协议。FinBen 覆盖广泛的金融任务，FinanceBench 提供对公司 filings 的开放式问答Xieet al\.\(2024 (https://arxiv.org/html/2607.28840#bib.bib29)\); Islamet al\.\(2023 (https://arxiv.org/html/2607.28840#bib.bib16)\)；然而，两者仍将金融工作转化为固定测试项、参考答案和简化的验收条件。部署则更为广泛：系统必须在专有分类体系、不断变化的产品定义、多语言文档、模糊请求、不完整证据和下游业务流程上运行。

因此，基准测试应被视为采样工具，而非完整的验证环境。它们可以展示在已知任务族上的表现，但不能说明某个特定机构的应用程序是否已针对其运营范围、控制环境和风险偏好进行了验证。

第四，智能体系统引入了顺序性失败模式。一旦 LLM 能够调用工具、路由请求、调用 API、决定是否升级或与其他智能体协调，验证就必须覆盖轨迹和决策序列。提示级准确率并不能保证系统的安全行为。

第五，快速更换模型可能使先前的验证失效。较新的模型可能提高基准准确率，同时改变拒绝行为、引用风格、工具使用可靠性、延迟、成本、校准或提示敏感性。在金融领域，迁移到新的基础模型、嵌入模型、检索器、提示模板、工具模式、护栏或编排层，都应被视为受控变更，并触发针对已接受案例、已知失败和高风险场景的针对性回归测试。

RAG 系统也需要组件级评估。检索质量、上下文相关性和生成行为应分别评估，因为上游错误会传播到最终输出。

出于这些原因，以基准测试为中心的评估应作为验证的输入，而非验证本身。

## 4 金融 LLM 验证的系统级视图

以下是