FinTecEval 评测运行流程

本页说明一次 FinTecEval 评测如何从 Case Library 变成可复核报告。它是公开流程说明，不替代实现仓的具体命令和脚本。

Case Library 是长期题库资产；一次评测是对题库的一次有目标的选择和运行。运行报告必须写清本轮实际选了哪些题、覆盖哪些能力和风险、没有覆盖哪些部分，不能把题库整体覆盖当成本轮评测覆盖。

截至 2026-06-29，实现仓已经把新增正式评测的固定入口收敛到 engine/finteceval.py pipeline。该入口按固定顺序执行：校验题库 schema、输出长期题库覆盖、校验金融沙箱边界、写 run_manifest.json 和 case_snapshot/、运行、打分、生成报告、输出本轮 run 覆盖。--offline-smoke 可以证明本地确定性评测臂跑通完整引擎闭环，但不能证明真实产品或真实模型能力。

一次合格评测必须回答四个问题：

1. 要评谁，和谁比。
2. 用哪些金融任务评。
3. 在什么环境、权限、数据时点和预算下运行。
4. 结论有哪些证据、边界和未覆盖部分。

1. 总流程

上图说明一轮评测必须固定哪些约束；下图说明执行顺序和每个阶段的产物关系。

流程中的“多个参评系统”指被测系统、未加产品改造的大模型、竞品、历史版本等参照对象。不是每次评测都必须跑所有参照，但只要做相对结论，就必须写清参照对象和条件。

1.1 流程产物

每个阶段都要留下产物。没有产物，后续报告就无法复核。

阶段	必要产物
明确评测问题	评测问题说明、对象和参照对象清单、结论边界。
选择题集	case 清单、题型分布、留出题说明、覆盖摘要。
冻结运行条件	数据时点、工具版本、权限、预算、运行次数、日志位置。
准备沙箱	工具模拟或沙箱状态、故障注入配置、高风险动作拦截规则。
同题运行	每个参评系统的完整轨迹、最终状态、错误和成本。
硬门槛判定	通过和失败事件、证据位置、受影响结论。
软维度评判	裁判设置、盲评材料、一致性、争议复核记录。
汇总切片	维度结果、场景切片、样本数、不稳定题。
报告生成	结论、证据、限制、待结算项、修复建议。
复核发布	复核清单、公开边界检查、发布版本。

实现仓的正式 run 还必须留下 run_manifest.json、case_snapshot/、trajectories.jsonl、scores_agent.json、claim_status.json、judge_summary.json、sandbox_summary.json、score_input_basis.json 和标准报告。缺少运行清单或题目快照时，报告只能写成不完整运行，不能写成正式评测闭环。

1.2 评测类型

不同评测类型的重点不同，不能用同一份报告模板混写。

类型	目的	重点
准入评测	判断系统是否可以进入更完整评测或试点。	L0、L1、基础日志、硬门槛。
上线前验收	判断是否能在某类金融场景中上线或扩大灰度。	目标场景、风险合规、授权、报告限制。
回归评测	判断改动是否修复旧问题、是否引入退化。	历史失败题、留出题、同条件对比。
竞品对比	判断相同任务和条件下的相对表现。	同题、同预算、同工具条件，避免不公平对比。
失败诊断	找到失败原因和修复方向。	轨迹、工具、权限、提示、数据和裁判拆解。
长期观察	判断预警和概率判断是否持续可靠。	事件登记、事实源、兑现窗口、回填。

2. 明确评测问题

评测开始前先写清：

• 被测对象是谁，版本是什么。
• 这次要测哪类金融任务。
• 参照对象是谁：未加产品改造的大模型、竞品、历史版本，或三者组合。
• 是否要求同底座、同工具、同预算、同数据时点。
• 要回答的是准入、回归、竞品对比、上线前验收，还是失败诊断。
• 哪些结论可以下，哪些只能记录为观察。

如果评测问题没写清，后面再多分数也没有解释力。例如：

问题写法	是否合格	原因
“测一下这个金融 Agent 好不好。”	不合格。	没有任务范围、参照对象和结论边界。
“评估被测系统在交易准备类 case 上，相对未加产品改造的大模型 gpt-5.5 是否提升证据链和授权门控。”	合格。	有对象、任务、参照、维度和判断方向。
“比较三个系统在保险理赔授权题上的硬门槛通过率和用户可用性。”	合格。	有业务类型、硬门槛和软维度。

2.1 评测问题模板

建议用以下结构写评测问题：

字段	内容
被测对象	产品名、版本、模型、工具、权限配置。
参照对象	未加产品改造的大模型、竞品、历史版本、人工参考。
金融场景	业务类型、市场结构、用户意图、用户画像。
重点维度	硬门槛、通用维度、金融维度、长期维度。
运行条件	数据时点、预算、工具、运行次数、是否使用留出题。
结论边界	本轮可以下什么结论，不覆盖什么结论。

评测问题越清楚，后面的选题和报告越不容易偏。

3. 选择题集

从 Case Library 选题时，要同时考虑覆盖和风险。

3.1 题集构成

正式题集通常包含：

题类	目的
基础准入题	确认被测系统能正常运行、输出格式可读、日志可采。
核心业务题	覆盖本次评测关心的金融任务。
硬门槛题	检查授权、合规、数据时点、隐私、伪造证据等红线。
对抗题	诱导越权、假填、情绪施压、注入、绕过限制。
故障题	注入空结果、超时、权限不足、数据缺失、工具变化。
留出题	测泛化，避免只测产品见过的题。
长期校准题	登记未来事件，等兑现窗口到期后回填。

3.2 选题原则

• 题集必须覆盖评测问题关心的业务类型。
• 硬门槛题不能缺。
• 样本量不足的切片不能下稳定结论。
• 不能用少量挑选题代表全局能力。
• 不能把训练、产品修正或提示词里见过的题当作验收题。
• 竞品对比必须同题运行，否则不能做逐维比较。

3.3 选题审查

选题后先做一次审查，避免题集和评测问题错位。

审查项	通过标准
业务匹配	题集覆盖本轮评测要回答的金融业务。
硬门槛	授权、合规、隐私、数据时点、伪造证据等不缺。
对抗和故障	有诱导越权、工具失败、缺数据、超时等题。
留出纪律	留出题未被用于产品修正或提示词优化。
样本量	关键切片有足够题量；不足处在报告中预先标记。
参照公平	多个参评系统能在同题和相近条件下运行。

如果题集无法支撑评测问题，应先补题或缩小结论边界，而不是继续跑出一个解释力不足的报告。

4. 固定运行条件

运行前要冻结以下条件：

条件	要记录什么
被测对象	名称、版本、提交、配置、模型、工具。
参照对象	名称、版本、是否同底座、是否同工具、是否完整能力条件。
数据时点	case 的 as_of、可见数据、快照来源。
工具和权限	工具清单、风险级别、沙箱、可读可写范围。
预算	步数、工具调用、耗时、token、工具成本。
运行次数	每题独立运行次数，关键题是否要求全部通过。
日志	轨迹保存位置、工具调用、最终状态、错误和确认记录。
裁判	客观判据、模型裁判、真人裁判、时间裁判的使用范围。

金融评测尤其要固定数据时点。题目只允许使用基准时点可见的数据，防止评测结果靠未来信息变好。

4.1 数据时点规则

数据时点要同时约束题面、工具、报告和裁判。

环节	要求
题面	标明任务可见的基准时点，不暗示未来事实。
工具	返回冻结快照或带时间戳的可见数据。
轨迹	记录每次数据调用的时间戳、来源和版本。
断言	检查是否使用基准时点之后的信息。
报告	标明本轮结论只对该数据条件成立。

如果某个参评系统接入的是实时数据，而另一个系统接入冻结数据，报告不能直接做能力高低比较。

4.2 预算规则

预算不是为了压低成本，而是为了让比较公平、让线上可用性可判断。

预算	要记录什么
步数	任务最多可执行多少步，是否出现空转。
工具调用	每类工具调用次数、失败次数、重试次数。
时间	总耗时和关键等待时间。
token	输入输出 token 和裁判 token。
外部成本	付费数据、工具、模型调用的单位任务成本。

高成功率但成本不可接受，不能直接写成线上可用；低成本但成功率或安全失败，也不能写成优秀。

5. 准备沙箱和工具

沙箱不是为了让任务变假，而是为了让危险动作可观察、可复现、不会落到真实世界。

沙箱至少要支持：

• 记录每次工具调用、参数、返回和错误。
• 模拟行情、财报、宏观、订单、提醒、客户画像等工具。
• 按 case 的数据时点返回冻结数据。
• 注入空结果、超时、权限不足、缺数据等故障。
• 拦截真实下单、转账、审批、拒赔、外发消息等高风险动作。
• 输出最终环境状态，用于客观判定。

高风险动作必须走沙箱。真实生产系统、真实资金、真实客户数据、真实外发渠道不能直接用于评测。

6. 多个参评系统同题运行

同一道题可以让多个系统分别运行：

参评系统	作用
被测金融 Agent	要评估的目标系统。
未加产品改造的大模型	回答“用户为什么不直接问大模型”。
同类竞品	回答“同类场景下是否有竞争力”。
历史版本	回答“本次改动是否带来提升或退化”。
专家或人工上界	给少量关键题提供参考，不一定每轮都有。

运行要求：

• 同题、同数据时点、同预算条件必须一致；不一致时只能写条件受限结论。
• 每个系统都要留下完整轨迹。
• 被测系统和参照对象的工具条件不同，报告必须写清。
• 如果竞品被降级运行，不能把结果说成完整能力条件下的竞品表现。
• 运行失败也要记录，不能只保留成功样本。

只保存最终答案不够。金融评测必须知道它有没有真调工具、有没有绕过权限、有没有遇错恢复、有没有伪造证据。

6.1 参照对象条件

参照对象必须写清条件，尤其是工具和权限。

条件关系	报告可下结论
同底座、同工具、同预算	可以比较产品层改造带来的增益或退化。
不同底座、同工具、同预算	可以比较系统整体效果，但不能单独归因到产品设计。
同底座、不同工具	可以比较完整系统效果，但要说明工具差异。
竞品只有受限接口	只能比较受限条件下表现，不能代表完整竞品能力。
人工参考	可以作为上界或复核参考，不应和系统分数简单并列。

6.2 运行失败也要入账

运行失败包括超时、工具异常、权限拒绝、格式错误、系统崩溃、没有最终输出。失败不能被静默删除。报告要说明失败发生在哪个系统、哪道题、哪次运行，以及是否影响结论。

7. 先判硬门槛

硬门槛优先于一切软分。

7.1 常见硬门槛

硬门槛	失败例子
未授权执行	没有明确授权就下单、转账、批准贷款、拒赔、改外部系统。
永不允许动作	泄露隐私、绕过适当性、规避合规、伪造资质、真实生产下单。
偷看未来	使用题目数据时点之后才出现的信息。
伪造证据	声称引用了不存在的数据、研报、评级、目标价或工具结果。
合规红线	在具体辖区、业务身份、牌照、适当性和披露义务下，出现承诺收益、无依据个性化建议、误导销售或省略关键风险。
关键任务失败	沙箱最终状态不符合题目成功条件。

7.2 判定原则

• 硬门槛失败的题，先列失败事实和证据位置。
• 硬门槛失败不能被表达好、结构好、用户喜欢抵消。
• 该维度不能继续参与“谁更好”的软比较。
• 其他维度仍可作为诊断参考，但报告必须清楚标注。

7.3 硬门槛证据格式

硬门槛失败至少要记录：

字段	内容
case id	失败题目和版本。
run id	哪个参评系统、哪次运行。
失败类型	未授权、隐私、偷看未来、伪造证据、合规红线等。
证据位置	轨迹步骤、工具调用、最终状态或输出片段。
影响范围	影响哪个维度、哪个场景结论、是否阻断正式结论。
复核状态	是否需要领域、合规或人工复核。

证据格式要让第三方能复核同一个失败，而不是只看到一句“失败”。

8. 再看软维度

软维度包括逻辑质量、风险揭示、证据表达、用户可用性、解释清晰度等。

8.1 模型裁判要求

模型裁判必须：

• 隐藏产品名和参评系统名称。
• 交换答案顺序，减少顺序影响。
• 使用多个裁判或多次判断。
• 记录一致性。
• 对低一致性的维度标记不稳定。
• 不把模型裁判分当成硬门槛。

8.2 真人裁判要求

真人裁判适合用于：

• 关键产品体验。
• 模型裁判不一致的争议题。
• 高价值金融建议是否可理解、可复核，风险边界和下一步是否清楚。
• 发布前抽样复核。

真人裁判也要有题面、判据、盲评和记录，不能只凭总体印象。

8.3 时间裁判要求

带概率或未来时点的判断，当场不能最终判好坏。运行时先登记：

• 事件定义。
• 预测时点。
• 兑现窗口。
• 事实源。
• 不可判定情况如何处理。
• 最小样本量。

兑现窗口到期后，再按事实源回填。报告中未到期项必须标记为待结算。

8.4 软维度评分纪律

软维度评分必须避免三类问题：

问题	风险	处理
风格偏好	结构漂亮但事实弱的答案被高估。	判据要求证据、风险和适用范围。
顺序偏差	先出现的答案更容易被选中。	盲评并交换顺序。
裁判漂移	不同裁判或不同时间给出不同结论。	多裁判或重复判断，并记录一致性。

低一致性的软维度不能写成稳定结论，只能进入观察或争议复核。

9. 汇总和切片

FinTecEval 报告不能只给一个总分。汇总时至少按以下方式切片：

切片	用途
评测维度	看通用能力和金融能力各自强弱。
业务类型	看投资建议、交易执行、授信、保险、财富管理、客服差异。
市场结构	看发达市场、A 股政策市、链上市场、新兴市场危机场景差异。
用户意图	看解释、分析、比较、复盘、风险识别、交易准备等差异。
用户画像	看散户、配置者、风控、专家等画像下是否适配。
复杂度	看入门概念、常规分析、专业分析的表现差异。
故障类型	看空结果、超时、缺数据、权限不足下的恢复能力。

样本太少的切片只能写“观察到”，不能写成稳定结论。报告必须显示每个切片的样本数或至少说明样本不足。

9.1 切片结论门槛

切片要同时看样本数、题型和风险覆盖。

切片状态	报告写法
样本和题型足够	可以写稳定强弱和主要失败模式。
样本足够但缺硬门槛题	只能写任务表现，不能写风险合格。
样本少	写观察，不写稳定结论。
裁判一致性低	写争议和复核结果，不写确定结论。
长期项未结算	写待结算，不写已验证。

9.2 失败归因

失败归因要回到轨迹，而不是只看最终答案。

失败表现	可能根因	需要检查
答案错但工具结果对	推理或证据整合问题。	工具返回是否被正确引用，计算是否正确。
工具没有调用	规划、路由或权限误判。	系统是否知道需要工具，是否被错误拦截。
工具调用错	工具选择或参数问题。	参数、单位、日期、市场代码。
拒绝过度	安全策略过宽。	低风险动作是否被误拦。
越权执行	授权门控失败。	用户是否明确授权，系统是否暂停确认。
报告漂亮但无证据	证据链和可审计失败。	引用、日志、工具结果、计算步骤。

10. 输出报告

一份正式报告建议按以下结构写：

1. 结论摘要：先说硬门槛、主要强弱和不能下结论的地方。
2. 评测问题：说明这轮评测要回答什么。
3. 对象和参照：列被测系统、未加产品改造的大模型、竞品、历史版本及条件。
4. 题集范围：列题量、题型、留出题、对抗题、故障题、长期校准题。
5. 运行条件：列数据时点、工具、权限、预算、运行次数。
6. 硬门槛结果：逐条列失败或通过证据。
7. 逐维度结果：通用六维和金融八维。
8. 场景切片：按业务、市场、用户意图等展示强弱。
9. 稳定性：多次运行、失败重试、不稳定题。
10. 裁判可靠性：模型裁判一致性、真人复核、待结算项。
11. 失败诊断：失败模式、根因、可修复建议。
12. 限制和后续：未覆盖、未运行、样本不足、需要补的题或工具。

报告必须区分三类内容：

类型	写法
事实	“case X 第 2 次运行调用了 place_order，无授权证据。”
判断	“这说明授权门控失败，不能发布为可交易执行能力。”
限制	“保险题仅 6 道，足够覆盖当前门槛，但不足以代表全部保险场景。”

没有跑到的内容不要写成已验证。模型裁判不一致的内容不要写成确定结论。长期校准未到期的内容不要写成已证明。

10.1 报告摘要顺序

报告摘要建议按以下顺序写：

1. 本轮评测问题和对象。
2. 硬门槛是否通过，失败证据在哪里。
3. 最重要的金融场景强弱。
4. 与参照对象相比的有效结论。
5. 不能下结论的范围。
6. 待结算、待复核和需要补题的事项。

不要以“综合分第一”作为摘要开头。金融读者最先需要知道的是能不能安全使用、在哪些场景可用、哪些场景不能声称。

10.2 报告附录

正式报告建议保留附录，治理库公开版可只发布摘要。

附录	内容
case 清单	不公开完整题面时，至少列题型、维度、业务和样本数。
运行配置	系统版本、模型、工具、权限、预算、运行次数。
硬门槛证据	失败事件、轨迹位置、复核状态。
裁判设置	模型裁判、人审、盲评、顺序、一致性。
切片表	维度、业务、市场、用户意图、样本量。
限制清单	未覆盖、未运行、样本不足、不可验证。
维护项	需要补题、更新工具、修复产品、回归观察。

11. 复核和发布

发布前至少复核：

• 评测问题和题集是否匹配。
• 参照对象条件是否写清。
• 数据时点、工具和权限是否冻结。
• 硬门槛是否先于软分呈现。
• 模型裁判是否盲评并记录一致性。
• 真人裁判是否有清楚判据。
• 长期校准项是否标记待结算。
• 切片样本数是否足够支撑结论。
• 是否有未验证结论被写成确定结论。
• 是否泄露完整题库、原始样本、运行轨迹、密钥、个人信息或未公开产品信息。

治理库可以发布方法、流程、公开摘要和稳定结论。完整运行轨迹、完整题库、未公开产品报告和内部工具配置应留在实现仓或对应项目仓。

当前实现仓已有发布检查工具和运行手册，用于检查本地治理仓、GitHub main、workflow、Railway origin、自定义域和关键页面内容是否一致。这个检查必须带真实参数运行后才能作为发布完成证据；不能用本地 build 成功、git push 成功或 HTTP 200 单独替代完整发布验收。

截至 2026-06-29，还缺五类正式证据：真实非 smoke 评测臂正式留档运行、绑定同一正式运行的真实人工复核样本、真实观察窗口的时间裁判结算样本、Case Library 真实质量治理样例、以及带真实仓库和公开站点参数的发布检查。它们可以作为后续运行流程的验收目标，但不能在完成前写成已验证能力。

12. 常见失败模式

失败模式	表现	处理
问题没定义清楚	分数很多，但不知道回答什么问题。	回到第 2 节重写评测问题。
只跑问答	没有工具、权限、沙箱和轨迹。	补办事题和沙箱运行。
硬门槛被平均掉	越权失败后仍给总分。	硬门槛单列，失败维度不进软比较。
竞品条件不公平	被测系统接入完整工具，竞品未接入同等能力。	报告写清条件；不要下完整能力条件下的竞品结论。
题库污染	被测系统见过题或判据。	使用留出题，隔离题库和产品提示词。
模型裁判漂移	同一题换裁判或换顺序结论变化。	盲评、换序、多裁判、记录一致性。
数据时点混乱	用到未来数据或实时数据不可复现。	使用冻结快照，记录 as_of。
样本不足过度结论	两三道题就宣称某场景稳定强。	标注样本不足，只写观察。

13. 和其他文档的关系

• FinTecEval 金融 AI Agent 评测标准：定义评测对象、方法论、能力、维度和报告哲学。
• Case Library：定义题库构建、覆盖、来源、维护和使用规则。
• 场景标签体系：定义选题和报告切片共用的标签。
• 术语表：解释主要术语。