从 LLM 判断能力到可审计决策：金融服务业 Decision Model 的演进与治理实践

金融服务机构正在把大语言模型用于审核材料、识别异常、分析风险、判断流程是否满足条件，以及辅助员工决定下一步怎么做。这类任务既可以由通用 LLM 直接完成，也可以通过结构化输出、工具调用、工作流编排、微调或专门训练的决策模型完成。许多任务甚至只需要一个明确的分类、评分、真假判断或路由结果，并不需要模型生成长篇文字。

因此，本文不把 Decision Model 当成与 LLM 或 Agent 泾渭分明、互斥的一类技术。不过，这个词在产业讨论中容易指向不同层次，本文会明确区分：决策型任务/接口模式，即把模型用于分类、评分、选择、路由等可被软件消费的判断；Jev / System One 这样的专用模型路线，即供应商对底层模型、训练目标和推理方式的专门设计；以及受治理的业务决策系统，即将模型接入证据、政策、权限、工作流、验证和审计的整体应用。三者有关联，但不能相互替代。通用 LLM 完全可能实现决策型接口，Agent 也可以包含这种判断节点；采用专用模型不会自动获得完整的生产治理能力。

但“能输出类似结果”不代表不同实现拥有相同的运行特性。TypeSafe 将 Jev 定位为专门服务于软件决策的 System One 模型，强调类型化答案、概率与置信度、并行求值，以及其自述的 RLCD 训练方法和模型架构；这些主张应与通用 LLM 的结构化输出能力分开考察，也应通过独立、贴近业务的评测加以验证。本文讨论的重点不是证明 Jev 与 LLM 完全不同，而是分析决策能力如何从简单 Prompt，演进为有约束的决策接口、可组合的运行时与可持续验证的业务系统。

一、结论先行：要治理的是决策系统，而不只是 Prompt

不要把“让模型多写一点思考过程”当作可解释性方案，也不要把某一种模型标签当作治理方案。 不论判断来自通用 LLM 的结构化输出、由 LLM 驱动的 Agent，还是 Jev 这样的专用决策模型，都需要把模型能力放进有明确输入、有证据、有政策依据、有校验、有授权边界和责任主体的决策流程。LLM 可以协助提取事实、归纳证据、发现冲突和形成建议；能够明确表达的政策条件，应尽量交给确定性规则或独立校验器；确实需要专业判断的部分，应明确保留人的决策权，并提供足够信息进行实质复核。

先把治理变成可执行的行为：谁做、何时做、失败怎么办？

“有人负责”“要有人复核”“上线前做评测”还不是治理机制。每项原则都需要明确责任人、可验证的产物、触发时间和失败后的动作。建议用下面这张控制表作为首次架构评审和上线审批的最低清单。

这张表不是说所有机构都要成立一个新的 AI 委员会。MAS 2026 年指引允许金融机构结合既有治理架构，但要求职责明确、协调有效，并按用例风险分配控制强度。指引于 2026 年 10 月 7 日发布；第 3–4 节的治理和风险管理系统期望自 2027 年 10 月 7 日起执行，第 5–6 节的生命周期控制与能力建设可在 2028 年 10 月 7 日前落实。参考：MAS 正式指引及实施时程。

flowchart TD
    A[提出业务用例] --> B[登记用途、决策影响、数据和动作范围]
    B --> C{风险及适用政策获批准？}
    C -->|否| X[修改设计或停止用例]
    C -->|是| D[建立决策契约、证据链与责任分工]
    D --> E[离线评测、独立挑战和安全测试]
    E --> F{硬门禁和残余风险通过？}
    F -->|否| R[整改、缩小用途或改用更可验证方案]
    R --> E
    F -->|是| G[影子运行 / 受限试点]
    G --> H[检查真实错误、人工复核质量和运行风险]
    H --> I{持续符合批准的风险阈值？}
    I -->|是| J[按批准范围逐步扩大]
    I -->|否| K[暂停自动动作、回滚、调查和补救]
    J --> H

第一步不是更换模型，也不一定要马上搭建多 Agent。应先补齐决策契约、证据记录、业务政策、验证、人工复核和运行治理。如果系统在某个关键用途上仍无法达到所需的解释和验证水平，就应该降低其自主权限，或改用更容易验证的决策方法。

二、单轮 Prompt 直接输出判断，缺少了什么？

考虑一种简化实现：

输入：业务材料 + Prompt
调用：LLM
输出：Approve / Reject / Escalate
      + 一段自然语言理由

这个风险并不是“通用 LLM 独有、专用 Decision Model 就没有”的问题。采用结构化输出或约束格式的通用模型，也可能给出格式正确但判断错误的结果；专用决策模型即使原生返回类型化概率，也仍可能在具体业务数据上判断失误。真正的问题是，当前实现能否拆分、验证和重现结果，以及它是否允许下游系统在未验证的情况下直接采取动作。

事实与推断混在一起。 模型可能把材料中明确写出的事实、跨材料推导的结论、对缺失数据的猜测，以及它对政策的理解，放在同一段自然语言里。读者很难分辨哪些是可核验事实，哪些只是模型的解释。

政策只存在于 Prompt 中。 如果决策标准藏在不断修改的系统 Prompt 里，审核人员很难知道某条要求在历史时点是否有效，也难以比较不同版本的判断差异。Prompt 不是充分的政策版本管理系统。

输入没有形成稳定快照。 即使保存了当时的 Prompt，引用的文件、数据库记录、内部政策或检索内容后来改变，也未必能重建模型当时看到了什么。仅保存 URL 或文档名称不够，必须能定位到具体版本、页码、段落或字段。

理由没有独立验证。 让同一个模型在输出判断后再回答“为什么这样判断”，仍可能只是生成与答案相符的叙述。除非理由与源材料、规则条件和可观察的输出建立了可验证关系，否则理由本身不是审计证据。

人工复核容易变成确认动作。 如果界面先突出显示 AI 结论，再给出措辞自信的理由，人会受到锚定影响。审核人员点击批准，并不能证明其理解了证据、独立评估了关键因素，或真正挑战过模型的判断。

失败无法归因。 最终判断错误，究竟是源数据缺失、检索错误、事实抽取错误、政策解释错误、规则实现错误、模型变化，还是审批流程失效？只保存答案，无法形成有效的故障分类和持续改进依据。

三、研究论文的警示：解释不等于忠实，也不保证人工判断更好

3.1 Chain-of-Thought 不能直接当成模型真实决策过程

Turpin 等人的 NeurIPS 2023 论文 Language Models Don’t Always Say What They Think: Unfaithful Explanations in Chain-of-Thought Prompting 展示了关键问题：LLM 的逐步解释可能系统性地没有提及真正影响答案的因素，甚至会为受偏置信号影响的错误答案生成看似合理的解释。解释文本看起来完整，并不能保证它忠实反映了导致模型输出的因素。

Fayyaz 等人的 Evaluating Human Alignment and Model Faithfulness of LLM Rationale 比较了 Prompt 生成的自我解释与基于归因的解释，发现基于 Prompt 的自我解释在与人的理由对齐以及忠实度方面存在局限。

对金融 Decision Model 的含义很直接：可以要求模型输出简明理由，但不能把“模型自己写出来的理由”当成决策过程已透明化的证明。应使用能回到原始材料核验的证据引用、明确的规则条件、字段级输出与独立验证结果，而不是依赖公开或保存一长串 CoT 来替代审计设计。

3.2 增加解释未必能纠正自动化偏差

Vered 等人在 The Effects of Explanations on Automation Bias 中研究了决策支持系统里的解释对自动化偏差的影响。研究发现，解释并没有稳定地减少人们对自动化系统的过度依赖，在部分条件下甚至会增加这种依赖；解释对任务速度和准确率的影响取决于具体情境。

发表于 Scientific Reports 的研究 Explainability does not mitigate the negative impact of incorrect AI advice in a personnel selection task 发现，当 AI 建议错误时，参与者仍可能未能否决它；增加解释对减少这种过度依赖的作用有限。Westphal 等人在 Decision control and explanations in human-AI collaboration 中也报告，决策控制与解释的作用并不相同，解释在其实验条件下没有普遍改善用户结果。

这些研究不能直接证明每个金融岗位都会出现同样效果，但足以说明：人工在环（Human-in-the-loop）不是一个架构标签，而是一种需要验证的控制能力。 有人点击审批不自动意味着有意义的监督；更多解释文字也不自动意味着更好的判断。

3.3 监管研究同样不把“提供了解释”视为终点

国际清算银行金融稳定学院（BIS FSI）2025 年论文 Managing explanations: how regulators can address AI explainability 指出，可解释性对透明度、问责、合规和信任很重要，但复杂模型（包括 LLM）的解释方法存在不准确、不稳定、可能误导等限制。不能只问“是否提供解释”，还要问解释是否适合具体用途，以及能否支持相应的风险管理和监督需要。

NIST 的 Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile 将幻觉/虚构内容、人机配置、结果测试、来源验证和部署后监控纳入生成式 AI 风险管理，建议在测试和持续监控中核查输出引用的来源，并评估人机组合在真实条件下的表现。

3.4 CoT 忠实度可以被实验检验，但不能靠阅读一段解释来保证

Lanham 等人的 Measuring Faithfulness in Chain-of-Thought Reasoning 通过对模型给出的推理链进行干预，例如插入错误或改写推理内容，观察最终答案对这些变化有多敏感。研究发现，不同任务和模型对所展示推理链的依赖程度不同；生成了较长的推理链，并不表示它就是答案成因的忠实记录。Turpin 等人则通过引入偏置信号，展示模型可能仍受该信号影响，却在解释里没有提及它。

2026 年 ICML 论文 Monitoring Monitorability 提供了更细致的边界：在当前某些推理模型中，Chain-of-Thought 监测可能比只观察动作更容易发现部分错误行为，但监测能力并非完美，而且可能随训练方法、数据来源和模型规模变化而变得脆弱。

这两类研究并不矛盾。CoT 可以是一种研究或运行期风险信号，却不能代替可以复核的决策证据。金融系统应记录可观察的中间产物、引用、规则校验、工具调用与最终处置；不要把完整的模型自述推理链设为唯一审计材料，也不要声称它揭示了模型的真实内部决策过程。

3.5 谄媚、确认偏差与“顺着提问者说”也是决策风险

Sharma 等人的 Towards Understanding Sycophancy in Language Models 研究发现，多个经过人类反馈训练的助手在不同任务中会表现出迎合用户观点的倾向；研究还指出，人类偏好评价可能在某些条件下偏爱说服力强、符合用户既有想法的回答，即使它并非更正确。

应用到金融决策中，风险并不只来自模型捏造事实。如果输入已经带有结论，例如“这家客户显然有问题，请找出理由”，模型可能倾向于收集支持该结论的材料，而没有充分挑战它。对应控制应包括：中性的问题模板、明确要求同时列出支持和反对证据、在测试集里加入方向相反但证据相同的案例，以及测量提示措辞变化是否导致判断不合理地变化。

3.6 幻觉与不确定性：不能把“猜一个答案”当作业务能力

Kalai 等人的 Why Language Models Hallucinate 从统计学习和评测激励角度分析，模型在不确定时仍可能选择猜测，而常见的评分机制可能奖励猜对却惩罚承认不确定的行为。它是对幻觉产生机制的研究分析，不代表每一次幻觉都有同一原因，但对高影响系统的设计有直接启示：如果输出契约强迫模型必须选择一个结论，系统就可能把不确定性转化为自信的错误输出。

因此，需要把 abstain / insufficient evidence / conflict / escalation 作为真正的合法状态，并把“无证据时不作结论”纳入评测的正向目标。衡量的不只是拒答率，也要衡量该拒答时是否拒答、可以判断时是否过度拒答。

3.7 LLM Reviewer 与自动评分本身也有系统性偏差

Shi 等人的 IJCNLP-AACL 2025 论文 Judging the Judges 在超过 150,000 次评价中研究了多个 LLM judge 的位置偏差，发现评判会受到候选答案先后次序与任务条件影响。Chen 与 Goldfarb-Tarrant 的 Safer or Luckier? LLMs as Safety Evaluators Are Not Robust to Artifacts 则指出，安全评价模型可能受到歉意措辞、冗长或其他输入表面特征影响；其报告的偏差幅度与特定实验任务、模型和比较设置有关，不应泛化成所有评测的固定比例。

这说明独立 Reviewer 并不自动等于独立真理来源。实践上应当为 Reviewer 做校准集和盲测，比较人工标注一致性；对成对比较随机化候选顺序，检查重复运行稳定性；避免让被评测模型与评分模型共享相同的偏见；对关键规则和引用采用程序化断言而不是 LLM 打分。高风险放行决策不能只由一个 LLM Judge 给出总分。

3.8 研究结果怎样转化成工程控制？

四、金融服务业的实践与监管动向

要区分正式监管要求、指导性框架和学术研究。本文使用的“Decision Model”是描述决策型用途与工程模式的术语，并不代表监管机构定义的一种独立模型类别，也不自动决定某一监管框架是否适用。具体义务取决于系统的实际用途、机构类型、司法辖区，以及它对客户和业务决策的影响。

4.1 MAS：2026 年发布的金融机构 AI 风险管理指引

新加坡金融管理局（MAS）于 2026 年 10 月 7 日发布 Guidelines on Artificial Intelligence Risk Management for Financial Institutions。指引适用于金融机构和各种 AI 技术，要求机构在企业层面和具体用例层面管理 AI 风险，包括建立适当的 AI 使用清单、风险重大性评估、生命周期控制、人类监督、测试、监控、变更管理以及第三方 AI 风险管理。指引自 2027 年 10 月 7 日起生效；第 3–4 节的治理和风险管理系统期望自该日起落实，第 5–6 节的生命周期控制与能力建设可在 2028 年 10 月 7 日前落实。具体时间表以正式指引为准。

MAS 同日发布的反馈文件 对 LLM 解释性、人类监督与可审计记录有几个特别相关的说明：

• 可解释性是情境化要求。即使不需要向客户披露，仍可能需要为内部使用人员、监督者或独立验证人员提供技术解释、限制和风险说明。
• 如果某种模型在特定用例下无法达到所需透明度和可解释性，金融机构应重新评估该模型是否适合该用途。
• 人类监督程度与 AI 自主性应和用例风险重大性相匹配。影响较大的用例通常需要更强的人工监督和更低的自主程度；预先定义的“延迟决策/转人工”机制是可考虑的控制方式。
• 对生成式 AI 或 AI Agent，可根据用例风险和监控需要增强文档记录，例如记录 Prompt 和模型输出。评测文档应支持评测过程的复现，以便审计和独立核验，而不只是留下一份模型输出。

这些是有针对性的监管依据，但不应把反馈文件里的每个例子都误读为对所有用例一体适用的硬性要求。正式指引的风险分级与比例原则仍然重要。

更值得直接借鉴的是正式指引中的操作要求，而不只是它对原则的表述：第 2 节要求按风险维护 AI 用例清单与重大性评估；第 3 节要求董事会/高级管理层明确责任、把 AI 风险纳入风险偏好并确保跨职能协调；第 4 节涉及风险管理系统、政策与程序；第 5 节覆盖数据管理、开发/测试、部署、监控和变更等生命周期控制；第 6 节则涉及组织具备的人员能力与技术基础设施。它允许使用既有治理架构，但并不意味着可以没有责任人、风险升级、定期和触发式复核，以及对第三方模型的风险管理。以上是 MAS 对其适用机构的监管期望，不应误称为所有国家、所有企业都直接适用的法律义务。

4.2 MAS FEAT 与 Veritas：把原则转成可评估的方法

MAS 的 FEAT Principles 讨论金融服务业中 AI 和数据分析的公平、伦理、问责与透明。MAS 于 2023 年发布的 Veritas Toolkit 2.0 由 MAS 主导的 31 家行业参与方联盟开发，覆盖 FEAT 评估方法，并介绍金融机构和保险业的实践案例。

可借鉴之处是：治理不只是模型团队评估准确率，还应覆盖透明度、责任归属、业务影响与机构既有治理流程。Veritas 是可参考的治理工具，不是可以替代本地法律意见或内部政策的通用认证。

4.3 OCC 2026 年更新：传统模型风险框架不能直接等同于 LLM 治理

美国 OCC、Federal Reserve 和 FDIC 于 2026 年 4 月发布了修订后的 Model Risk Management guidance。文件明确指出，生成式 AI 与 Agentic AI 不在这份指引的适用范围内，监管机构还计划进一步研究银行使用 AI（包括生成式和 Agentic AI）的模型风险管理问题。

这不意味着金融机构可以不治理 LLM。传统模型治理中的开发、使用、验证、监控、角色与第三方管理原则有借鉴价值，但 LLM 的提示词依赖、非确定性、上下文敏感性和自然语言输出需要额外的用例级控制。不能只把传统模型审批表换个名字，就声称覆盖了 LLM Decision Model 的风险。

4.4 其他框架与法律：先判定适用范围，再确定控制深度

• NIST AI RMF 与 Generative AI Profile 可用于组织风险分类、测试与验证、部署后监控和来源管理。
• EU AI Act 将自然人信用评分或信用度评估、特定人寿和健康保险风险评估与定价等列入相关高风险 AI 规定。不能由此推断所有内部金融决策工具自动属于同一类别；需结合实际目的、对象、适用条款、时间安排与法律意见判断。
• FSB 关于 AI 对金融稳定影响的报告（2024） 强调第三方依赖、网络风险、模型风险、数据质量和治理等领域的金融系统脆弱性。

内部使用不等于低风险。 如果内部模型决定风险评级、客户处理优先级、交易例外、AML 调查队列、投资/组合建议、保险承保或关键运营动作，它仍可能对客户、机构或监管义务产生重大影响。风险评估应基于实际影响和机构对 AI 输出的依赖，而不是看它是否“只给员工用”。

五、目标架构：让模型给出可检查的建议，而不是独自决定一切

对于高影响用例，更稳健的做法通常不只是把“一次 Prompt”改成“更长的 Prompt”，而是把决策流程拆成多个可验证步骤。下面是供金融决策场景参考的目标架构，不是所有 Decision Model 都必须采用的固定形态：底层可以是通用 LLM、Jev 这样的专用模型，也可以是两者混合；工作流可以由普通程序控制，也可以在 Agent 框架中编排。应由业务风险、任务形态和实测结果决定架构复杂度，而不是先选定某种模型类别再强行套用。

flowchart TD
    A[业务请求与案件标识] --> B[输入校验与数据快照]
    B --> C[材料解析与证据定位]
    C --> D[LLM 结构化事实抽取]
    D --> E[证据与字段校验]
    E --> F[政策/规则评估]
    F --> G[建议与不确定性汇总]
    G --> H[独立验证：引用、必填项、规则一致性]
    H --> I{风险等级与门禁}
    I -->|低风险且满足批准条件| J[受控自动处理]
    I -->|高影响、冲突、缺证或越界| K[有权限的人工审核]
    J --> L[决策记录与监控]
    K --> M[人工决定、覆核或升级]
    M --> L

先看组件边界：C4 Container 视图

下面的架构图刻意将 LLM、确定性规则、验证器、最终决策门禁和业务动作网关拆开。具体部署可以合并服务，但逻辑责任应保持区分，尤其是模型生成的建议不能直接成为写数据库、发出客户通知、改变风险状态或执行交易的授权。

C4Container
title Decision Model：C4 Container View
Person(analyst, "案件分析人员", "准备材料，查看证据和模型建议")
Person(approver, "有权限的业务审核人", "批准、修改、拒绝或升级")
System_Ext(source, "业务数据与原始材料", "案件字段、文件、历史记录")
System_Ext(policy, "政策与规则目录", "带版本和生效日期的正式政策")
System_Ext(model, "获批的 LLM 服务", "生成事实候选与建议，不持有最终业务动作权限")
System_Ext(notify, "下游业务系统", "接收经过授权的最终处置")

System_Boundary(dm, "Decision Model 系统边界") {
  Container(api, "Decision API / Orchestrator", "Service", "创建运行、推进状态机、分发任务")
  Container(snapshot, "Case Snapshot Store", "Versioned Store", "保存输入时点、来源版本与快照哈希")
  Container(retrieval, "Evidence Service", "Retriever", "定位材料、证据段落、反向证据和缺失项")
  Container(llmstep, "LLM Extraction / Assessment", "LLM Client", "按 Schema 输出事实候选与建议")
  Container(validate, "Evidence & Schema Validator", "Rules / Code", "验证 Schema、引用定位、数据契约和必要字段")
  Container(policyengine, "Policy / Rules Engine", "Deterministic Rules", "执行硬条件、有效日期、权限与禁止项")
  Container(gate, "Decision Gate", "Policy Service", "按风险、证据与授权决定继续、暂停、升级或拒绝")
  Container(review, "Human Review Workbench", "Web App", "显示证据、冲突、规则结果并记录真实处置")
  Container(action, "Action Gateway", "Authorized API", "检查审批、状态、权限、幂等性后才执行副作用")
  ContainerDb(audit, "Decision Record Store", "Append-only Record", "关联快照、模型运行、规则结果、人工决定和动作回执")
}

Rel(analyst, api, "提交案件/补充材料")
Rel(api, snapshot, "固定本次输入版本")
Rel(snapshot, retrieval, "提供受控快照")
Rel(retrieval, source, "读取授权材料")
Rel(retrieval, policy, "取得适用政策与版本")
Rel(api, llmstep, "提交受限的证据包")
Rel(llmstep, model, "调用获批模型")
Rel(llmstep, validate, "结构化候选输出")
Rel(validate, policyengine, "验证通过的事实/缺口")
Rel(policyengine, gate, "规则结果、失败原因")
Rel(gate, review, "高风险/不确定/冲突时转人工")
Rel(approver, review, "审核、修改、升级或批准")
Rel(review, gate, "提交人工处置")
Rel(gate, action, "仅对获授权的最终状态放行")
Rel(action, notify, "执行批准的业务动作")
Rel(api, audit, "记录运行与证据引用")
Rel(gate, audit, "记录门禁结果")
Rel(review, audit, "记录人工处置")
Rel(action, audit, "记录动作回执")

实现时还应把边界写进 API 契约：LLM 返回的是 Proposal，不是 FinalDecision；规则引擎返回 RuleEvaluation，而不是替审核人伪造批准；Action Gateway 只接受已通过授权状态机的命令。权限要在服务端执行，不能仅靠前端隐藏按钮。

一次案件实际如何运行：时序图

sequenceDiagram
    actor User as 业务用户
    participant API as Decision API
    participant Snap as Snapshot Store
    participant Ev as Evidence Service
    participant LLM as LLM Provider
    participant Val as Validator
    participant Rules as Policy Engine
    participant Gate as Decision Gate
    participant Review as Human Reviewer
    participant Action as Action Gateway
    participant Audit as Decision Record

    User->>API: 提交案件
    API->>Snap: 固定输入、源版本、时间戳与哈希
    Snap-->>API: snapshot_id
    API->>Ev: 按快照检索材料与适用政策
    Ev-->>API: EvidencePack + 缺失/冲突项
    API->>LLM: 仅提交获准材料，要求结构化候选输出
    LLM-->>API: Facts / Citations / Recommendation
    API->>Val: Schema、引用、字段完整性验证
    Val-->>API: 通过项与失败项
    API->>Rules: 运行确定性规则和有效时点检查
    Rules-->>API: RuleEvaluation
    API->>Audit: 追加 ModelRun、证据、校验和规则结果
    API->>Gate: 评估风险、证据充分性与动作授权
    alt 需要人工审核、证据不足或存在冲突
        Gate-->>Review: 创建审核任务并说明阻断原因
        Review->>Review: 查看正反证据、政策条款和失败规则
        Review-->>Gate: 批准 / 修改 / 驳回 / 补件 / 升级 + 理由
    else 属于预先批准的低风险自动化
        Gate-->>API: 标记为符合自动化范围
    end
    opt 当前状态最终获准执行动作
        Gate->>Action: 提交受约束的授权命令
        Action->>Action: 校验权限、状态、幂等键与动作范围
        Action-->>Gate: action_id / 状态
    end
    Gate->>Audit: 追加最终处置、批准链与动作回执
    API-->>User: 返回状态、下一步及 Decision ID

5.1 明确决策契约

在 Prompt 和代码之前，先定义系统负责什么、不能负责什么、输出会影响什么，以及最终权责归属。最小决策契约应包括预期用途、自动化边界、输入契约、政策契约、输出契约、升级条件和责任主体。应避免让 Prompt 承担所有业务规则；能表达成稳定明确条件的要求，应维护在经过版本管理和测试的规则或策略层。

5.2 先抽取事实和证据，再形成建议

对包含合同、调查材料、客户记录、风险说明或内部政策的场景，可以把模型工作拆成两类。

第一，证据工作：提取事实、定位相关政策段落、归纳支持与反对的证据、发现矛盾和缺失项。每个关键陈述应带有可定位的来源；材料不支持时标记为缺证，而不是补出看似合理的事实。

第二，判断工作：根据已验证事实和适用规则形成建议。如果缺少关键材料、规则冲突、证据过期或案件超出批准范围，返回 insufficient_evidence / escalate，而不是强行输出二元结论。

文档证据应记录文档 ID、版本/快照哈希、页码或段落定位和原文片段；数据库字段则记录表/记录标识、字段、有效时间和查询快照；政策记录政策 ID、版本、生效日期和具体条款。一个 URL、文件名或“模型认为”都不足够。

RAG 可以改善模型取得背景资料的方式，但不会自动保证检索完整、引用真实、证据支持结论或政策应用正确。检索结果的版本、相关性和引用校验仍应作为单独控制点。

5.3 区分模型建议、业务规则与最终决定

一种实用的混合模式是：

• LLM 从非结构化材料中提取事实、映射预定义评估维度、发现矛盾并解释证据。
• 确定性规则执行明确政策、必要条件、金额阈值、时间窗口、禁止项、职责权限及其他可以清楚表达的约束。
• 独立验证器检查输出结构、证据引用、必填字段、硬性约束和升级条件。
• 有权限的人员或正式批准的决策机制处理需要专业判断的冲突、不确定性和例外。

规则引擎无法解决所有问题。它只能覆盖可形式化的政策；需要综合判断的领域仍须保留专家判断、适当的第二意见和可回溯记录。目标是避免本来可以用简单、可测试规则执行的内容完全依赖模型自由生成。

5.4 把不确定性和无法判断变成正式输出

许多 Prompt 默认要求模型一定要选一个答案，缺失数据或证据冲突就可能被隐藏在自然语言里。建议把“无法判断”作为一等结果：

不要未经校准就把模型自报的 confidence: 0.92 当成“有 92% 概率正确”。LLM 自报的自信程度并不等于经过验证的概率。若需要置信度或风险分数，应通过有代表性的历史案例、校准方法和持续监控证明其含义；否则，使用可核实的证据完整度、规则检查结果和显式升级条件更可靠。

5.5 把公开业务用例映射成可落地的系统设计

DBS 银行在 2025 年年报中公开表示，使用生成式 AI 辅助员工进行信用评估资料的信息提取与验证，并在推进由员工审核的信用评估备忘录工作流；其风险管理披露还提到生成式 AI 辅助客户对话摘要和通话质检。该披露说明金融机构已把生成式 AI 引入信用评估工作流的一部分，但并未公开完整的内部架构、字段级指标或门禁阈值，不能把下表误写成 DBS 实际采用的技术实现。来源：DBS 2025 年 CRO 报告。

如果为类似的“信用评估资料提取 + 备忘录草稿”设计一个可审计流程，至少需要这样拆分：

重点不是多部署几个 Agent，而是把文档提取的错误与信用判断本身的错误区分开来；前者可以通过来源对齐和字段验证发现，后者还需要政策测试、专业评估与正式责任归属。

六、决策记录：应当保存什么，才能经得起复核？

对每次产生业务影响的模型运行，应形成结构化的 Decision Record。它不是把所有内容无差别塞进日志，也不是强求保存完整的模型内部思维链。目标是让有权限的审查人员能理解决策事实、重建当时的输入和政策版本、核对关键推断、复核评测步骤，并确定最终业务决定由谁作出。

6.1 一次运行至少要记录什么

日志必须关联到模型真正看到的输入，而不是只关联到一个后来可能改变内容的引用。 在满足隐私、保留期限和安全要求的前提下，记录稳定的快照 ID、版本和哈希；需要保留实际材料时，放在受控存储中，按角色授权、加密并设置保留和删除策略。不要为了审计而永久保存不必要的敏感个人信息，也不要把包含机密的 Prompt 和材料写入普通应用日志。

对于第三方模型，供应商可能更新模型实现，或无法保证同一请求未来得到逐字节相同的结果。应把可复核性和完全确定性重放区分开来：前者要求有当时的输入、配置、版本、证据、规则与最终处置记录；后者要求相同环境产生完全相同输出，往往不是托管 LLM 能保证的。记录实际能提供何种重放与复现能力，不要承诺无法保证的确定性。

6.2 简化的 Decision Record 示例

以下是建议的数据契约，不是某个供应商的固定 Schema。生产实现应按数据分类、访问策略与业务流程调整。

{
  "decision_id": "dec-2026-10-13-000184",
  "use_case_id": "internal-risk-review",
  "case_ref": "case-opaque-reference",
  "created_at": "2026-10-13T10:15:30Z",
  "policy": {
    "policy_id": "risk-review-policy",
    "version": "3.4",
    "effective_at": "2026-10-01"
  },
  "input_snapshot": {
    "snapshot_id": "snapshot-7f21",
    "content_hash": "sha256:...",
    "source_refs": [
      {
        "source_id": "document-019",
        "version": "v12",
        "location": "page 8, paragraph 3",
        "claim_ref": "evidence-001"
      }
    ]
  },
  "model_run": {
    "provider": "approved-provider",
    "model_id": "approved-model-version",
    "system_prompt_version": "decision-prompt-12",
    "output_schema_version": "decision-schema-4",
    "toolchain_version": "review-flow-6"
  },
  "assessment": {
    "status": "insufficient_evidence",
    "findings": [
      {
        "criterion_id": "KYC_DOCUMENT_CURRENT",
        "result": "unknown",
        "supporting_evidence": [],
        "contradicting_evidence": [],
        "missing_evidence": ["current_verified_document"],
        "reason_code": "MISSING_REQUIRED_EVIDENCE"
      }
    ],
    "policy_checks": [
      {
        "rule_id": "R-017",
        "rule_version": "3.4",
        "result": "not_evaluable"
      }
    ],
    "validation": {
      "schema_valid": true,
      "citations_resolved": true,
      "policy_checks_passed": false
    }
  },
  "recommendation": {
    "outcome": "escalate",
    "reason_codes": ["MISSING_REQUIRED_EVIDENCE"],
    "human_review_required": true
  },
  "human_disposition": {
    "review_status": "pending",
    "final_decision": null,
    "override_reason": null
  },
  "integrity": {
    "record_schema_version": "1.0",
    "previous_record_hash": "sha256:...",
    "record_hash": "sha256:..."
  }
}

生产系统还应定义状态之间的合法转换，明确哪些字段由模型生成、哪些由程序计算、哪些只能由有权限人员填写。模型不能自行声称政策“已通过验证”，也不应能够伪造审核人身份或自行填充最终审批字段；这些信息必须由实际校验与审批系统写入。

6.3 增加日志不等于建立审计能力

日志只有在可检索、受访问控制、保留期限清晰、不可被普通业务流程静默覆盖，而且能把输入证据、模型运行、政策版本和最终处置关联起来时，才真正支持审计。应明确谁能查看原始输入、谁能修改 Prompt 和政策、哪些变化要求重新评测、如何定位历史决策，以及发生错误后如何识别受影响的案例并补救。

高影响系统可考虑追加式 Decision Record、独立审计日志、内容哈希或其他防篡改存证方式。这些机制有助于检测记录修改，但哈希本身不证明原始事实真实、结论正确或业务政策适用；数据来源和访问控制同样重要。

6.4 Decision Record 与标准：没有一个全球标准规定统一 JSON，但控制目标很明确

不同标准和监管框架通常规定治理结果、控制目标或技术义务，而非规定所有机构必须使用同一份 Decision Record JSON。因此要把“法定/监管要求”“可采纳的管理体系标准”和“工程实现建议”分开。

官方资料：EU AI Act 正式文本、MAS 指引、NIST AI RMF、NIST GenAI Profile、ISO/IEC 42001、ISO/IEC 23894、美国联储修订的 Model Risk Management Guidance。

6.5 实际审计要能重建一次“为什么当时会这么做”

假设信用资料在 4 月 10 日被评估，而供应商在 4 月 18 日修订了财务报表。如果 Decision Record 只存文档 URL、当前文件和最终结论，审计人员无法判断 4 月 10 日模型实际看到的是哪一版本。一个可复核的案例至少需要关联：

1. 当时实际使用的文档版本和页码/字段位置；
2. 本次模型实际输入的证据包、检索顺序和被排除/失败的材料；
3. 适用政策的版本与生效时点；
4. 模型/Prompt/输出 Schema 及工具版本；
5. 独立校验与规则引擎的原始结果，而不仅是“全部通过”摘要；
6. 审核人员看到了哪些证据，做了何种修改/批准或升级；
7. 后续发现错误时，哪些相关决策受到影响、采取了什么补救。

在 DBS 公开的信用评估辅助用例中，资料抽取和验证、由员工审核的备忘录草稿分别是不同的工作责任。对应到自己的实现，应分别保存“提取结果的证据”和“最终业务决定的授权链”，不要把一份生成的备忘录当成两者的替代品。

还需强调：哈希、追加式日志和时间戳有助于发现记录是否发生变化，但并不能证明记录的原始内容真实、证据足够或规则结论正确。防篡改要和受控的数据源、访问审计、独立校验及正式责任人一起设计。

七、人工复核怎样设计，才不会变成走形式？

人类监督不是让人替模型签字，而是让人有机会发现错误，并有足够信息和权力改变结果。

7.1 按风险决定自动化程度

风险评估应考虑决策影响、可逆性、AI 自主程度、错误损害、数据敏感性、第三方依赖、输出稳定性和解释难度。以下是工程示例，不是通用监管分级。

这不是说所有金融判断都必须人工，也不是说内部使用就可以自动化。自动化程度应由实际风险和验证结果支持。如果 AI 无法提供足够的透明度和可复核性，应考虑缩小职责、改变流程或换用更容易验证的模型，而不是用免责声明解决问题。

7.2 审核人员必须看得到证据，而不只是结论

审查界面至少应显示：

1. 案件关键事实和来源位置，能够返回原材料；
2. 哪些字段是直接提取的事实，哪些是模型推断；
3. 支持结论的证据、反向证据、矛盾材料和缺失项；
4. 对应的政策条款、必须满足的条件和未通过的规则；
5. 模型限制、未决问题以及要求升级的原因；
6. 人工可执行的动作：接受、修改、拒绝、要求补充资料、升级或暂缓，并记录实际原因。

对重大决策，可以“先展示事实与证据、再展示模型建议”，或要求审核人先作独立初判，再对照 AI 建议。这不能完全消除锚定，但可为测量推荐对人的影响提供条件。

7.3 衡量审核质量，而不是只数审批数量

“100% 经过人工审批”不能证明监督有效。应测量人工与模型分歧率、推翻率和升级率；人工识别错误建议的能力；不同风险级别和工作量下的审核质量；审核所需时间、回看证据比例、补件率和未解决冲突；以及独立盲审发现的漏判。

推翻率本身既不应越高越好，也不应越低越好。高推翻率可能意味着模型质量差，也可能反映审核人员发现了不适用案例；低推翻率可能意味着模型好，也可能说明审核流程成了橡皮图章。必须结合盲审、真实结果与任务设计一起分析。

7.4 用真实研究和金融机构披露检验“人工在环”

Buçinca、Malaya 和 Gajos 在 2021 年的实验 To Trust or to Think: Cognitive Forcing Functions Can Reduce Overreliance on AI 中对 199 名参与者比较了认知强制设计、简单的可解释 AI 设计和没有 AI 的基线。研究报告说，要求使用者先投入判断或执行额外认知步骤的设计，能比简单解释更有效地降低对错误 AI 建议的过度依赖；代价是参与者对最能降低过度依赖的设计主观评价较低，效果也会随个体认知特征而变。它是受控实验，而非金融机构生产运行的效果证明，但说明界面设计会影响监督是否有效。

金融机构公开案例也提供了可落地的例子。Morgan Stanley 披露，Debrief 将会议内容转成客户笔记和后续行动草稿，顾问会在定稿前审阅和修改；DBS 2025 年报告披露，生成式 AI 辅助资料提取与验证，并在推进由员工审核信用评估备忘录的工作流。两者并不意味着所有输出都必须人工批准，而是显示：当生成内容会被用于后续客户或信用流程时，明确的人工定稿点可以成为流程的一部分。来源：Morgan Stanley / OpenAI 案例、DBS 2025 年 CRO 报告。

7.5 把“有效复核”写成界面与流程规则

sequenceDiagram
    participant Model as Decision Model
    participant UI as Review Workbench
    participant Reviewer as 审核人员
    participant Blind as 独立质量抽检
    participant Ops as 运营/风险负责人

    Model->>UI: 结论状态 + 正反证据 + 规则结果 + 未决项
    UI->>Reviewer: 先显示证据与可复核来源
    Reviewer->>UI: 独立判断/关键检查项
    UI->>Reviewer: 显示模型建议与差异
    Reviewer->>UI: 接受、修改、驳回、补件或升级
    UI->>Ops: 记录理由码、耗时、覆盖和升级状态
    Blind->>UI: 随机抽取已处置案例
    Blind->>Ops: 报告漏错、机械批准与系统性偏差
    Ops->>Model: 修正流程、评测集、阈值或自动化边界

要注意，单独的“独立初判”也不是所有工作流的最佳界面：它可能增加处理时间、对熟练审核人员带来不必要负担，还可能让低频使用者失去效率。应在代表性案件上做实验，按风险级别和决策频率选择设计，依据错误发现能力和决策质量，而不是凭主观体验决定。

八、怎样验证 Decision Model：从模型评测走向决策系统评测

通用 benchmark 或几个成功案例不足以证明系统适合金融业务。MAS 的 AI 风险管理材料强调针对实际用例和工作流做评测，而不只是引用模型的一般能力；NIST 则建议以经验测试验证能力主张、审核来源并持续监控。

建立一套由领域专家核验的历史案件和合成边界案例组成的测试集，覆盖正常、缺失、矛盾、边界、罕见和恶意输入。每个版本都记录评估所用数据、Prompt、模型、规则及执行环境。

对于高影响决策，不能只用整体准确率掩盖少数严重错误；应对重大错误单独定义不可接受类型和处置标准。

8.1 低成本的消融与反事实测试

• 删掉关键证据： 是否转为缺证或升级，还是仍给出相同强度的结论？
• 加入反向证据： 系统是否识别冲突，还是继续支持第一次判断？
• 改变不影响业务含义的措辞或排列顺序： 结论是否大幅波动？
• 替换过期政策： 是否使用正确生效时点的版本？
• 提供无关、不可访问或恶意文档： 是否凭空引用，或被注入文本覆盖系统规则？
• 与专家独立判断对照： 关键案例先收集人工判断，再展示模型输出，测量错误识别与锚定影响。
• 比较版本： 对模型、Prompt、检索配置或策略变更建立回归测试，检验差异是否在批准范围内。

不要只问“理由是否听起来合理”，而应验证证据移除、证据冲突或规则变化时，输出是否按预期变化，以及这种变化是否可检查。

8.2 独立 Reviewer 有用，但不是独立真理来源

另一个模型可以发现部分不一致、缺证或不合规则之处。不过，如果两个模型共用同样的背景材料、Prompt 偏见和不充分的政策表达，它们可能一起犯错。Reviewer 不能保证正确性。

更稳妥的组合是：机器规则和 Schema 检查负责确定性错误；独立引用校验器检查引用能否定位并支持陈述；第二模型提供额外挑战；再按风险等级进行独立人员抽样或正式审核。对硬约束，应让程序直接验证，而不是再让 LLM 自己判断自己是否违规。

8.3 实际用例：信用评估资料提取与备忘录草稿，应怎样验收？

DBS 在 2025 年公开披露，生成式 AI 已用于辅助员工完成信用评估信息提取与验证，并正在推进由员工审核信用评估备忘录的工作流。公开材料没有披露其内部评测集和接受阈值。下面是将这一公开用例转化成可复用评测设计的示例，不是对 DBS 内部实现或指标的猜测。

测试集应由业务专家制定标签规则，对争议案例进行独立裁决；训练/调试集与最终验收集要分开；对于有时间变化的政策与数据，保留案件发生时有效的版本。不要把历史审批结果不加审查地当作 Ground Truth，因为历史决定本身可能存在人为噪声、旧政策或录入错误。

阈值也不能简单定成一个统一的“准确率 95%”。对重大字段、法规禁止动作和需升级的案例，应单列不可接受错误；对金额抽取、引用和政策门禁设置独立阈值；样本不足时报告置信区间和未知风险，不要用小样本的完美分数宣称可以自动化。

8.4 把 Evaluation 接到发布与运行流程，而不是留在报告里

Morgan Stanley 的公开案例提供了可观察的工程做法：团队针对真实的检索、摘要、翻译和会议后续事项构建评测；由顾问和提示工程人员评价准确性/连贯性；随着资料库与用途变化，调整检索并维护回归测试。该公司披露其对样例问题进行每日回归测试。其客户故事由供应商公开，能说明实践模式，但不是独立审计报告。

建议把相同原则落实为下面的发布流程：

flowchart TD
    A[模型/Prompt/检索/规则/工具变更] --> B[静态检查与结构化契约测试]
    B --> C[固定 Gold Set 与历史缺陷回归]
    C --> D[证据、政策、拒答、安全与群体差异测试]
    D --> E[人工专家抽样 + 独立 Judge 校准]
    E --> F{关键门禁是否全部通过？}
    F -->|否| G[阻止发布并创建缺陷/风险项]
    G --> A
    F -->|是| H[影子模式：不影响正式决定]
    H --> I[比较系统与专家/既有流程的结果]
    I --> J{运行证据和风险接受是否通过？}
    J -->|否| G
    J -->|是| K[小范围、受限权限试点]
    K --> L[持续监控、随机盲审、事故与版本监测]
    L --> M{质量/风险阈值被突破？}
    M -->|是| N[暂停动作、回退版本、调查受影响案件]
    M -->|否| L

CI 里的硬性门禁应当可重复、可自动运行；独立专家审核适用于解释质量、复杂业务判断和难以形式化的案例；LLM Judge 可用于扩大覆盖面，但必须先用专家标注集测量其偏差。线上出现新的失败模式后，要把经过裁决的案例加入回归集，形成闭环，而不是只修一条 Prompt 后关闭事件。

8.5 LLM-as-a-Judge 怎样进入评测体系？

当人工评测成本很高时，LLM Judge 可以用于辅助评分、聚类错误与筛选需要人工复核的样本，但不能独自批准高影响 Decision Model。至少做以下校准：和领域专家在独立样本上比较一致性；交换候选答案次序检查位置偏差；在相同案例上重复评分检查稳定性；加入冗长但错误、简洁但正确、语气强但缺证等对抗样本；对 Judge 模型或提示变化重新校验。

判分设计还要把“答得像专家”与“证据确实支持结论”分开：对可以确定判断真假的项，优先用程序断言和数据对账；对引用，使用来源定位与片段核验；只将开放式质量评价交给专家或经校准的辅助 Judge。高影响放行结论应由规定的责任角色签署，而不是由 Judge 的总分自动决定。

九、从治理文档到可运行控制：上线前建立哪些资产？

可从 Model Cards for Model Reporting 和 Datasheets for Datasets 思路出发，形成模型和数据的文档化资产；但它们不能代替单次运行的 Decision Record，也不能代替正式政策、验证和审批。

9.1 将治理资产对应到责任角色与可验证证据

文档只有在有人维护、在正确事件触发时更新，并且可以证明相关控制确实运行，才有治理价值。建议从三道防线/职责分离的思路出发（具体组织可以不同）：

这与 MAS 2026 指引所描述的职责分工方向一致：第一道防线负责业务用例及日常控制，第二道防线进行风险监督和独立挑战，第三道防线提供独立保证。NIST AI RMF 则可以用作跨职能工作的组织方式：Govern 明确责任和风险偏好；Map 明确用途、受影响对象和技术/第三方边界；Measure 组织测试和独立评估；Manage 制定风险处置、事故响应与持续改善措施。见 NIST AI RMF Core。

9.2 标准如何实际落到一份治理包？

这些标准可以共同使用，但不是全部都需要逐项“认证”。更有效的做法是：先明确法律与监管适用性，再选择 ISO 42001 等组织管理体系作为治理结构，借助 NIST AI RMF 形成风险与测试流程，最后把每一项控制落实到可审查的证据与责任人。

9.3 一个生产事故应该怎样触发治理动作？

例如，某次模型升级后，引用有效率表面上未明显下降，但系统开始优先采纳旧政策摘要，导致部分案件出现不适用的规则解释。好的响应不是只回滚 Prompt，而是沿着 Decision ID 找到受影响的版本与案例：

1. 运行监控触发政策版本/引用验证告警，动作网关暂缓尚未执行的相关高风险决定；
2. 运营负责人和业务所有者根据模型/Prompt/检索版本、政策版本和时间窗，确定可能受影响的 Decision ID；
3. 独立验证人员复现案例，并判断问题来自检索排序、政策有效时点、模型输出还是规则校验；
4. 风险/合规负责人决定暂停、人工重审、通知相关方或采取其他补救；每个决定要记录责任人和理由；
5. 修复后用原失败案例及扩展回归集重新测试，经过指定审批才能恢复；
6. 将事故模式加入评测集、运行手册和变更检查表。

这个例子是建议的操作方案，并非某家银行已公开发生的具体事故。它说明 Decision Record 的价值不只在监管检查当天，而是让生产错误能被定位、圈定影响、纠正和预防再次发生。

十、分阶段落地：先补决策契约与审计，再逐步改架构

不建议一开始就重写成复杂的 Agent 平台，也不建议只修改一个 Prompt 就宣布解决了可解释性问题。应先选一个风险范围明确、能构造代表性评测集的决策用例，再比较通用 LLM、专用决策模型或混合方案。

第 1 阶段：给当前模型建立基线

盘点 Prompt、输入来源、输出结构、政策依据、模型供应商/版本、人工复核方式、失败案例和下游动作。收集经领域专家核验的历史案件，对决策正确性、证据充分性、稳定性与人工复核质量建立基线。明确数据留存和访问策略。

交付物： 用例风险评估、当前流程图、失败分类、历史测试集、未满足控制清单。

第 2 阶段：结构化输出并保存 Decision Record

把自由文本输出收敛为 Schema：判断状态、理由代码、支持证据、反向证据、缺失项、相关政策、下一步动作和升级标志。每次运行记录输入快照/版本、Prompt 与模型配置、证据引用、校验结果和人工处置。为不确定、冲突及越权设置明确的升级通道。

交付物： Decision Contract、输出 Schema、可检索的决策记录、引用解析及 Schema 校验。

第 3 阶段：增加政策校验与实质性人工复核

把可形式化的硬条件移入版本化规则层；由独立程序核查必要条件和权限边界。改造审核界面，让审核人员能返回源证据、看到缺失/冲突项，并接受、修改、驳回或升级。对高影响用例试行独立初判、随机盲审和质量抽样。

交付物： 规则测试、独立验证器、审核操作日志、决策延迟机制和升级流程。

第 4 阶段：以真实业务表现决定是否扩大自动化

基于历史数据和受控试点持续评估错误、引用可靠性、政策一致性、人工判断质量、群体影响、运行成本和业务效果。只有当证据表明控制有效、残余风险在机构风险容忍度内，才扩大自动化范围。模型、Prompt、工具和政策发生重大变化时重新评估，并准备回退方案。

交付物： 独立验证报告、放行门槛、持续监控、变更审批、回滚和事故响应流程。

各阶段的退出条件：交付物齐备不代表风险已经可接受

建议每一阶段都定义谁有权放行、凭什么放行，以及失败时回退到哪里。阶段耗时依业务复杂度与风险而定，不建议套用一律 30/60/90 天的固定日程。

flowchart LR
    A[用例批准] --> B[构造基准与错误分类]
    B --> C[结构化输出与 Decision Record]
    C --> D[独立验证和人工复核测试]
    D --> E[影子运行]
    E --> F[受限试点]
    F --> G[持续运行与盲审]
    D -->|失败| H[改设计 / 缩小范围]
    E -->|差异不可解释| H
    F -->|超风险阈值| I[暂停 / 回滚 / 重审]
    G -->|重大变更或事故| I
    H --> B
    I --> D

将 DBS 公开用例作为路线设计参考，而不是照搬其内部实现

如果以 DBS 2025 年报告中披露的“信用评估资料抽取/验证”和“由员工审核的信用评估备忘录”为业务场景，可以把最初的目标限制在提高资料完整性与审核效率：先在影子模式评估字段抽取、证据链接与冲突识别，不影响信用决定；之后以员工审核的备忘录草稿进入受限试点；只有在关键错误、漏升级、引用可靠性和人工复核质量都有持续证据时，才考虑扩大使用范围。

这与公开材料中“员工审核”的方向相符，但上述影子模式、指标和各阶段门槛是本文提出的落地方案，不是 DBS 公开披露的内部实施步骤。可参见 DBS 2025 年 CRO 报告 与 DBS 2025 年 CIO 报告。

十一、哪些措施最值得优先投入？

十二、如何设计一套可复用的 Decision Model Evaluation？

Decision Model 的评测不能只测试“模型答对了多少题”，也不能只靠专家读几十个输出后觉得“整体不错”。需要把判定质量、证据质量、政策符合性、升级行为、人工复核效果和生产运行稳定性分别测量，并规定哪些失败可以接受、哪些失败必须阻止发布。

当 LLM 被用于业务决策时，评测范围应超出一般的文本质量评分：金融业务中的不同错误有不同后果。漏掉一个必须升级的高风险案件，可能远比摘要措辞不够优雅严重；结论偶然正确但没有证据，也未必能满足控制要求。这是由任务的后果和系统用途决定的，不是因为 Decision Model 一定使用了不同于 LLM 的底层技术。

12.1 先定义被评测的对象：不是一个 Prompt，而是一项决策能力

每个用例都应明确决策目标、输入和证据边界、适用政策版本、模型与检索配置、最终决定由谁作出，以及失败时如何处理。评测单位应是一次完整的决策运行，并能追踪到该次运行所使用的输入快照、证据包、政策版本、模型配置和最终业务处置。只评测孤立的模型回答，容易漏掉检索、规则、集成、界面和权限问题。

12.2 构造可信的 Gold Set：历史决定不等于绝对正确的 Ground Truth

金融业务往往积累了大量历史人工决定，但不应直接把这些决定全部作为正确标签。人工判断可能存在噪声、标准变化、样本选择偏差以及不同审核人员之间的不一致性；如果历史标签本身反映过去的偏差，模型仅仅复刻它们，也不一定代表业务质量提高。

2024 年发表于《International Review of Financial Analysis》的研究 Human-AI collaboration to mitigate decision noise in financial underwriting 讨论了一家金融科技放贷企业的承保实践，分析人工审核决定中的不一致性，并提出 Evidential Reasoning-eXplainer，通过多项独立、可能相互冲突的证据以及贷款规则的权重与可靠性来支持分析。该研究不是 LLM 评测，也不能证明该方法适用于所有承保场景；可迁移的教训是：让 AI 复刻人之前，要先评估“人原本怎样决定”是否一致、政策是否被准确表达、标签是否可信。

建议按以下方式构建测试集：

1. 保留真实分布与困难案例。 从生产历史中按业务类别、时间、风险等级、数据来源和结果状态抽样，并补充低频但重要的稀有/边界案例。测试集不能全是容易判断的成功案例。
2. 由领域专家独立标注。 对重要案例采用至少两位经过培训的专家独立判断并记录分歧；通过明确的 adjudication 机制解决分歧，而不是为了获得一个标签而隐藏意见。
3. 分开标记事实与政策判断。 哪些事实确实在来源中、哪些资料缺失、政策是否适用，与最终业务结论是不同的标注维度。
4. 记录时点与政策版本。 历史案件应使用当时有效的政策；若用当前政策重评历史案件，应标为反事实测试，不能混入原始标签。
5. 防止评测集泄漏。 Prompt 调优期间反复查看的案例不应再被视为完全独立的最终验证集。保留 holdout set，并按时间切分检查新时期数据上的泛化。
6. 管理数据权限。 对客户、交易或调查材料进行脱敏/假名化，控制访问和保留期限；合成数据可补充边界测试，但不能取代对真实分布和材料质量的验证。

12.3 使用分层 Evaluation，而不是一个总分

建议将评测拆为四层。前面层级失败，后续结论的质量就失去了基础。

每一层都应有明确的失败标签，例如来源缺失、使用过期政策、事实抽取错误、结论无证据支持、违反政策、遗漏升级、人工推翻、未经授权的动作。错误归因比一个准确率数字更有用，因为不同错误需要不同修复方式。

12.4 用风险加权指标，而不是只看整体 Accuracy

假设测试集 95% 是低风险常见案件，即使系统把这些都答对，也可能因为漏掉少数高影响例外而不可上线。建议至少报告：

• 错误接受率与错误拒绝率： 按业务含义定义类别，不要把所有错误合并成一种。
• 重大错误率： 将违反禁止规则、遗漏强制升级或无证据支持重大结论等设为单独指标，不能被大量简单样本稀释。
• 升级召回率与过度升级率： 应转人工的案例有多少被正确转交；系统是否把太多普通案例都升级，造成审核队列失效。
• 证据支持率： 每个关键结论是否有可解析且真实支持该结论的证据；引用存在但内容不支持结论，仍应判失败。
• 政策符合率： 硬规则应由代码直接检查，不应完全依赖 LLM Judge 给分。
• 校准与覆盖率： 只有输出概率经过真实案例校准时，才报告 Brier score、可靠性曲线或 Expected Calibration Error。若系统有自动处理门槛，可绘制 coverage-risk curve，观察扩大自动处理范围时风险如何变化。
• 人机联合表现： 对照专家独立判断、专家看到 AI 建议后的判断和最终结果，测量 AI 是否改善或伤害审核质量。
• 分组差异： 在合法、适当且隐私保护充分的前提下，检查不同相关群体、地区、产品和数据来源中的错误差异。

不要直接把模型自报的 confidence 作为概率指标。如果没有校准数据，宁可使用证据完整性、规则通过情况以及是否触发升级等可验证信号。

12.5 评测不仅问“答对了吗”，还要问“凭什么、遇到变化会怎样”

12.6 LLM-as-a-Judge 可以扩展测试，但必须先验证 Judge

自然语言理由、证据是否相关、解释是否完整等维度，很难完全靠精确字符串匹配评估，因此 LLM Judge 可以作为辅助评分器。但“另一个更强模型说合格”不构成独立证明。

2025 年发表在 ACL Anthology 的 Judging the Judges: A Systematic Study of Position Bias in LLM-as-a-Judge 发现，LLM Judge 可能表现出位置偏差，其一致性会随 Judge、任务和候选答案变化。2024 年的 Systematic Evaluation of LLM-as-a-Judge in LLM Alignment Tasks 也报告，Prompt 模板会影响评估结果，相关实验中 Judge 与人类评估者只有中等程度的一致性。

建议采取以下护栏：

• 先在专家已标注的样本上验证 Judge 的假阳性、假阴性和人类一致性；
• 对候选答案做随机顺序、交换顺序和重复评分测试，检查位置偏差与重复稳定性；
• 对关键证据、政策违反、重大错误和权限边界使用代码校验或专家复核；
• 对开放式质量指标采用清晰 rubric，并对高风险样本进行人工复核；
• 评估 Judge 本身的模型和 Prompt 变化，避免“被测模型看似提升，只是评分器变了”。

12.7 把测试变成发布门禁与生产飞轮

Anthropic 于 2026 年发布的 Demystifying evals for AI agents 建议结合代码评分器、模型评分器和人工评分器，记录完整 trajectory/trace 与真实 outcome，并针对非确定性任务运行多次试验。这些方法并非只能用于某种被单独命名的 Decision Model；它们同样适用于使用通用 LLM 或 Agent 承担决策工作的系统。对于金融用途，还需加入政策、证据、风险重大性和问责维度。

建议设计三类门禁：

1. 硬门禁： 输出 Schema 不合法、引用无法解析、缺少必需证据、硬性政策违反或未经授权的动作，不能靠其他项目高分“平均通过”。
2. 质量门禁： 错误接受率、严重漏判、证据支持率、升级召回率和人工复核质量，按用例风险设定验收阈值。
3. 运营门禁： 供应商/模型/Prompt/政策变更、数据源失效、漂移或严重事故应触发重新评测、缩小自动化范围、暂停或回退。

上线初期可使用 shadow mode：模型生成建议但不触发业务动作，与真实流程并行比较；之后在明确的低风险范围进行受控试点。上线后持续抽样复核生产记录、纳入新失败案例、分析根因并扩展回归集。Evaluation 才不是一次性的审批附件，而是持续监督决策能力的机制。

十三、Decision Model 与一般 LLM/Agent：能力重叠，工程目标不同

“Decision Model”与“LLM Agent”不宜被画成两个互斥的框。前者通常描述系统承担的任务、输出契约或专门的模型接口；后者通常描述模型如何围绕目标调用工具、维护状态并推进流程。因此，一个 Agent 可以包含多个 Decision Model 风格的判断节点，一个以通用 LLM 为底座的服务也可以用结构化输出、函数调用、评分标准和业务代码，完成分类、风险标签、路由或是否升级等任务。

OpenAI 的 function calling 与 structured outputs 已为通用模型提供约束参数结构和连接业务函数的机制；TypeSafe 自己的 System One 设计指南 也把可复用的工程方法概括为：在代码里保留控制流和确定性规则，把判断拆成范围明确的问题，将独立问题并行评估，并按置信度选择执行、人工复核或升级。这里有明显的工程思想重合。不同点在于模型本身如何训练、输出概率是否真正校准、接口是否原生约束结果，以及单位请求的延迟、成本和稳定性，而不是普通 LLM “做不到”这些判断。

从通用 LLM 到专用决策模型：这是可选的演进路径，不是技术分界线

实际建设中，团队通常可以先让通用 LLM 完成判断任务，再逐步明确输出契约、验证和运行时控制。只有当某个狭窄、高频的决策节点，在成本、延迟、概率校准或重复稳定性上达不到业务要求时，才值得评估微调、小模型、级联，或 Jev / System One 这类专用决策模型。这个过程不是要求所有系统都沿着一条固定路线升级；一些任务在结构化 LLM 配合良好评测后就足够，另一些任务则可能从专用模型中获益。两种路径都要在同一业务数据和同一端到端约束下比较。

flowchart TD
    A[明确需要模型支持的判断任务] --> B[通用 LLM + Prompt / 示例]
    B --> C[约束接口：Schema / 函数调用 / 明确状态]
    C --> D[建立业务评测：质量、不确定性、成本、延迟与稳定性]
    D --> E[由程序 / 工作流管理政策、权限、状态与审计]
    E --> F{当前方案达到该用例的要求？}
    F -->|是| G[保留通用 LLM 路径，持续回归验证]
    F -->|否| H[比较 Prompt 优化、微调、小模型、级联与专用决策模型]
    H --> I[只替换需要优化的判断节点]
    I --> D
    E --> J[开放式综合、长尾或证据冲突任务]
    J --> K[通用 LLM / Agent 辅助，必要时独立验证或人工升级]

图中体现的是系统能力逐步工程化，不是说通用 LLM 天生不能做判断，也不是说专用决策模型天然更可靠。Schema 只能保证输出形状，不能保证判断正确；专用模型提供的概率也需要在目标业务中校准。反过来，通用 LLM 的判断如果在质量、成本和风险边界上已满足要求，就没有必要仅为了采用新类别模型而更换它。

Jev 的差异应按证据强度来描述。TypeSafe 在产品发布材料中称其采用新的模型架构、并行采样器和 Reinforcement Learning for Calibrated Decisions（RLCD）；这些是厂商对其技术路线的公开说明，不代表其内部实现已被完全公开或其性能主张已适用于所有业务。独立研究者于 2026 年 9 月发布的 Jev 基准评测预印本 在 37 个公开数据集上与两种开放权重模型进行比较，发现 Jev 在不少任务上表现有竞争力，但性能也会受语言资源、标签噪声和评分任务复杂度影响；该研究不能替代面向具体金融业务的验证。评测结果应被当作选择模型路线的证据之一，而不是仅凭“Decision Model”这个名称作决定。

这也说明需要区分三层概念：模型类别（底层模型如何训练和推理）、决策接口/运行模式（如何把输入转成程序可消费的判断）、以及生产治理能力（证据、规则、测试、授权、人工责任和审计）。这三层相互关联，却不是同一个问题。通用 LLM 可以实现决策型接口；专用模型也可能嵌入 Agent；两种实现都可能治理薄弱，也都可能在正确设计下用于受控业务流程。

13.1 工程边界应放在输出、运行时与业务控制的接口上

• 只读证据工具： 检索批准的政策库、读取特定案件资料、查询授权数据。每次调用都记录来源、时间、查询范围和返回快照。
• 分析与校验工具： 事实抽取、引用解析、规则求值、风险分类、差异对账。这些工具需要独立测试，不能把模型自己的判断当作验证结果。
• 产生业务副作用的工具： 更新案件状态、发布结果或触发客户流程。必须由独立授权与门禁控制，并要求前置条件通过；高风险动作需要有权限人员批准。

不能仅因模型用自然语言宣称“已经合规”就让它执行最终动作。工具 API 本身应强制执行权限与状态转换约束。重试、交接、超时、部分完成、重复执行和补偿也必须有明确的幂等与恢复机制。

13.2 轨迹可见不等于决策可解释

Agent trajectory 能说明调用了哪些工具、得到什么结果、何时失败，但不一定说明业务结论的依据成立。Decision Record 应把轨迹关联到具体判断：证据 ID 与来源片段、案件事实及来源、政策条款与版本、条件求值结果、LLM 建议与系统最终状态的差异，以及人工接受、修改、推翻或升级的处置记录。这样既保留 Agent 的可观测性，又补上业务决策的审计链。

十四、业界实践案例：怎样借鉴，哪些不能过度推论？

公开材料中，金融服务业较常见的早期生成式 AI 落地是内部检索、摘要、知识支持和运营辅助，而不是直接让通用 LLM 独立决定贷款、承保或客户风险。公开案例多由机构或供应商描述，可说明工程模式与采用情况，但不一定独立证明长期风险效果。

14.1 日本央行 2026 年调查：采用率上升，但治理成熟度仍是瓶颈

日本央行 2026 年 8 月公布的金融机构生成式 AI 调查以 150 家金融机构为对象。调查显示，超过 90% 的受访机构正在使用或试验生成式 AI；应用正从一般事务扩展到利用客户信息的核心业务，但直接把生成式 AI 输出展示给客户的机构仍有限。对评估效果，不少机构认为“可用于业务，但仍需改善”；相当数量的机构仍把治理、第三方风险、安全和信息保护列为需要加强的领域。

来源：Bank of Japan — Use and Risk Management of Generative AI by Japanese Financial Institutions (FY2026 survey)。

这份调查不是某个模型的受控实验，也不证明特定技术能减少多少风险。它说明业务试用与可规模化的受控使用是两件事：模型能处理核心业务材料，不代表机构已经能解释、记录、评测和管理其判断；第三方依赖、信息安全和结果不确定性需要一并管理。

14.2 英国央行与 FCA：完全自主决策比例低，企业自评存在理解缺口

英国央行和 FCA 在 2024 年发布的金融业 AI 调查收到 118 家机构回应。调查显示，75% 的受访机构已使用 AI，基础模型占被报告 AI 用例的 17%；55% 的用例具有一定程度的自动化决策，但只有 2% 的用例完全自主；62% 的用例被机构自评为低重大性，16% 被自评为高重大性。84% 的企业表示有 AI 责任人，但只有 34% 表示对所用 AI 技术有“完整理解”，46% 仅有“部分理解”。

来源：Bank of England — Artificial intelligence in UK financial services, 2024。

这些数字来自企业自报调查，并不是监管部门对每个系统逐一认证。它们仍揭示两个与 Decision Model 直接相关的事实：金融业采用 AI 不等同于把最终决定完全自动化；有责任人也不能自动解决模型理解与可验证性问题。责任、可观察性与独立验证需要成为具体控制。

14.3 Morgan Stanley：把 Evaluation 做成上线机制，而不只是发布前测一次

OpenAI 公布的 Morgan Stanley 案例描述了财富管理内部 Assistant 与 Debrief。公开材料称，Assistant 已被超过 98% 的顾问团队使用；团队针对真实业务问题建立 Eval，包括摘要质量、信息检索和翻译等任务，由顾问和 Prompt 工程师评价准确性与连贯性并持续迭代。Debrief 将会议记录整理成客户笔记和后续事项，顾问在最终定稿前仍会检查和修改；团队也维护日常回归测试样例，以发现合规输出与检索质量的变化。

来源：OpenAI — Morgan Stanley uses AI evals to shape the future of financial services。

这是一份供应商发布的客户案例，应把采用率和效果数据视为机构/供应商的公开描述，而不是独立审计结论。其公开用例主要是内部知识检索、摘要和顾问工作流辅助，不能据此说通用 LLM 已经能够独立完成信用审批或风险决策。可借鉴之处是 Eval-driven development、业务专家评分、持续回归测试，以及员工对会影响后续业务流程的生成内容进行检查和修改。

14.4 信贷承保研究：先评估人的判断，再评估 AI

Sachan 等人 2024 年关于金融科技贷款承保的研究，从人工审核决定中的不一致性入手，分析怎样用证据权重与规则可靠性改善决策支持。它不是通用 LLM Agent 实现，也不是可以原样复制的生产架构；它说明金融机构构建 Decision Model 时，不能仅把历史审批记录当作无误差标签，也不应假设人工判断天然一致。

可以抽取三项工程做法：明确每条业务规则的可靠性与权重；在存在冲突证据时表达证据强度，而不是把所有信息压成一个无来由的分数；对专家分歧建立审查与治理流程，并用独立结果评测 AI 是否真正提高一致性和质量。

14.5 传统信贷模型的可解释性研究：可以借鉴什么，不能直接套用什么？

FinRegLab 与斯坦福商学院的研究从不同角度评估了传统机器学习信贷承保模型的解释性、公平性和模型诊断工具。其 Machine Learning Explainability & Fairness: Insights from Consumer Lending 研究比较了七家技术公司的诊断工具和若干开源工具；相关研究关注这些工具能否提供理解单个申请人预测、群体层面的模型行为、以及模型整体行为所需的信息。FinRegLab 在 2026 年又发布了面向消费信贷模型管理的 Framework for Managing Machine Learning Models in Consumer Credit Underwriting，该工作反映了其与美国银行在 OCC Project REACh 框架下的讨论。

这类研究与 LLM Decision Model 密切相关，但两者不能混为一谈。

可迁移的原则是：解释工具本身也需要验证，不能因为工具输出了一张 SHAP 图、特征重要性榜单或一段 LLM 理由，就认为解释正确。对于 LLM Decision Model，应优先使用可回到原始来源的证据引用、规则求值和版本记录；如果同时存在传统评分模型，则分别保留评分模型的特征级诊断和 LLM 的证据级记录，再将两者按明确的数据契约组合起来。

对受消费者保护、拒绝原因披露或公平放贷规则约束的用途，还应让合规与法律团队验证理由是否具体、准确且真正对应适用的决策因素。不能让生成式模型凭空编造拒绝原因，也不能把一个听起来合理的文字理由当作模型影响该案件的真实特征解释。

14.6 DBS：生成式 AI 辅助风险流程，并明确员工审核边界

DBS 的 2025 年 CRO 报告说明，生成式 AI 被用于员工客户对话总结、收集信息以改善员工处理结果、通话记录质检，以及信用评估过程中的信息提取和验证；报告还说，银行正在推进由员工审核的信用评估备忘录 Agentic workflow。其 CIO 报告补充，银行已建立生成式 AI 框架，包含可复用组件、治理护栏、工作流能力和 Prompt Engineering；官方还披露了企业 AI 模型与用例的规模，以及负责数据和 AI 治理的相关机制。

来源：DBS 2025 年 CRO 报告、DBS 2025 年 CIO 报告、DBS Ethical & Responsible AI in Banking。

这份公开材料不提供完整的 Decision Record Schema 或其模型评测阈值，因此不要据此推断 DBS 内部采用了本文的具体技术架构。但它提供了几个可核验的实际方向：

• 按任务拆分风险： 对话摘要、资料提取、信用评估备忘录和最终信用决定不是同一个风险等级或授权范围。
• 让输出对应流程中的下一步： 信息提取需要验证来源和字段，备忘录是交由员工审阅的草稿，而不是自动审批本身。
• 将治理框架与复用平台结合： 公共框架提供可复用组件与护栏，不意味着各用例可以跳过本身的评估。
• 将 AI 治理嵌入组织职责： 数据管理、风险管理、技术和业务角色共同承担责任，不能把验证全部交由 Prompt 工程师。

如果企业要借鉴这一方向，最重要的评测不是“备忘录语言是否流畅”，而是关键财务字段是否来自正确材料、冲突资料有没有暴露、最新政策是否适用、缺证案例是否升级，以及人工审核是否确实发现了系统的重大错误。

14.7 从案例中抽取一个可复用的模式

十五、把决策能力转化为可治理业务系统：实施蓝图

实施时既不应预设必须换成 Jev 这样的专用模型，也不应假定现有通用 LLM 只要增加一个 JSON Schema 就已经满足生产要求。首先按任务形态选择候选路径，再用同一批业务案例比较，而后为胜出的方案建立一致的决策记录、验证和控制边界。

这些路径可以组合使用。例如，专用决策模型负责大量低成本的初筛，通用 LLM 处理少量复杂案例，确定性代码执行硬规则，人工负责高影响或证据冲突案件。是否值得采用这种混合架构，要由同一业务基准上的端到端结果决定，不应只比较某个模型的单次推理价格或厂商演示数据。

15.1 第一版：结构化与可追溯，不急于自治

对每次判断生成唯一 decision ID，并把以下对象绑定在一起：

• CaseSnapshot： 本次案件的关键输入字段、相关材料版本与快照哈希；
• EvidencePack： 每项关键事实的来源定位、证据摘录、支持/反向关系和缺失项；
• PolicyVersion： 有效时点正确的规则 ID、版本、生效日期与规则评估结果；
• ModelRun： 模型、模型版本、Prompt、输出 Schema、检索/工具配置和运行 ID；
• Assessment： 标准化状态、理由代码、未决问题、建议升级以及校验报告；
• HumanDisposition： 人工最终处置、角色、原因、时间戳和批准链；
• AuditLink： 记录间关联、访问日志与完整性校验信息。

最小可行版本可以保持单次通用 LLM 调用，也可以使用专用决策模型；要求不是指定某一种模型，而是让结果可被检查。模型可以输出结构化的候选事实、证据引用、政策条款候选、冲突和缺失项，但不能仅凭自身输出直接触发业务动作。程序验证 Schema 与引用，规则引擎执行明确的硬条件；不满足条件就进入 evidence insufficient、conflicting evidence 或 escalation 等正式状态。

15.2 第二版：评测先行，再增加模型调用

先建立基准数据集和错误分类，在每次 Prompt、模型、检索与规则版本变更时自动运行：

• Schema、必填字段和引用定位的确定性测试；
• 硬性政策及禁止动作的规则测试；
• 专家标注案例上的决策与证据评测；
• 缺证、矛盾、过期政策、恶意文档和依赖故障的挑战测试；
• 对同一案例多次试验以评估模型输出波动；
• 通用 LLM、专用决策模型及混合级联方案的公平对比；
• 审核人员在看/不看 AI 建议条件下的受控对照评测。

只有当评测指出现有方案在某个环节确实失败，再决定增加独立 Critic、第二模型、专用决策模型或多 Agent 步骤。否则，多一次 LLM 调用或新增一种模型只会增加费用、延迟和审计负担，不一定增加决策质量。

15.3 第三版：把门禁与下游副作用隔离

业务动作接口不应接受任意模型自然语言作为授权。它应只接受经过 Schema、策略和权限验证的明确状态，并要求符合当前工作流状态。高风险操作应有授权人员明确批准；低风险自动化也应在批准范围、阈值和回滚机制内运行。

对所有版本更新，保留受控回退方式。若新的模型或 Prompt 在关键案例上造成严重错误、引用质量明显下降、必要升级遗漏或策略违规，应能够立即关闭自动动作、回到上一批准版本或转入人工流程，而不是等待下一次例行评审。

15.4 一个最小的发布门禁示例

下表不是监管机构规定的通用阈值，而是把质量评估转成上线决策的一种示意。

门槛应由业务风险、历史基线、法律合规要求与风险偏好共同定义。这里不提供“一律 95% 准确率”之类的万能数字，因为整体 Accuracy 无法表达重大错误的业务后果，也不能代替独立验证与正式风险接受。

十六、最终判断：把模型判断能力升级为受控的业务决策能力

Jev 的出现值得关注，但不应被解读成“通用 LLM 不能做决策，必须引入一种与 LLM 完全不同的模型”。通用 LLM 已经能借助 Prompt、结构化输出、函数调用、微调与工作流组合，承担很多分类、评分、判断、路由和评审任务；Agent 也可以把它们组织成复杂流程。Jev 的产品定位，是进一步把这种常见的软件判断需求作为专用模型能力来优化，特别强调类型化概率输出、校准、一致性、延迟和成本。它的价值需要与通用模型在具体任务中的表现作公平比较，不能仅凭术语或厂商基准先验判定。

更值得关注的演进是：AI 系统不再只把所有工作交给一个通用模型连续生成文本，而是逐步把能力拆成可组合的部件——通用 LLM 负责开放式理解与生成，专用决策模型或结构化 LLM 调用负责范围明确的语义判断，普通代码负责确定性规则、权限与副作用，工作流运行时负责状态、重试、人工介入和可观测性。实际系统可能采用其中一种路径，也可能混合使用；选择标准应是经业务评测验证的质量、延迟、成本、可靠性与运维复杂度。

而在金融服务场景中，不论底层采用哪种模型，最终仍须回答同一组问题：判断基于哪些事实和证据、适用了哪一版政策、模型输出经过哪些校验、何时必须拒判或升级、谁有权作出最终决定、发生错误后如何重建过程并补救。Decision Model 的关键不是与 Agent 或 LLM 划清技术边界，而是把决策任务、输出契约、控制权、证据链与责任安排设计清楚，并用真实业务结果持续验证。

参考资料与延伸阅读

监管与行业框架

1. MAS — Guidelines on Artificial Intelligence Risk Management for Financial Institutions (2026)
2. MAS — Response to Feedback on AI Risk Management Guidelines (2026)
3. MAS — FEAT Principles
4. MAS — Veritas Toolkit 2.0 for responsible AI in finance
5. BIS FSI — Managing explanations: how regulators can address AI explainability (2025)
6. OCC / Federal Reserve / FDIC — Revised Model Risk Management Guidance (2026)
7. NIST — AI Risk Management Framework
8. NIST — Generative AI Profile
9. Financial Stability Board — The Financial Stability Implications of AI (2024)
10. EU — Artificial Intelligence Act, Regulation (EU) 2024/1689

学术论文

11. Turpin et al., Language Models Don’t Always Say What They Think: Unfaithful Explanations in Chain-of-Thought Prompting, NeurIPS 2023.
12. Fayyaz et al., Evaluating Human Alignment and Model Faithfulness of LLM Rationale, 2024.
13. Vered et al., The Effects of Explanations on Automation Bias, Artificial Intelligence, 2023.
14. Explainability does not mitigate the negative impact of incorrect AI advice in a personnel selection task, Scientific Reports, 2024.
15. Westphal et al., Decision control and explanations in human-AI collaboration: Improving user perceptions and compliance, Computers in Human Behavior, 2023.
16. Mitchell et al., Model Cards for Model Reporting, FAT* 2019.
17. Gebru et al., Datasheets for Datasets, 2018 / Communications of the ACM, 2021.

业界调查与工程实践

18. Bank of Japan — Use and Risk Management of Generative AI by Japanese Financial Institutions (FY2026 survey) — 150 家机构的调查，关注使用现状、评测、治理与第三方风险。
19. Bank of England / FCA — Artificial intelligence in UK financial services, 2024 — 金融业 AI 用例、自动化程度、重大性与治理调查。
20. OpenAI — Morgan Stanley uses AI evals to shape the future of financial services — 供应商公开的客户案例，包含真实业务 Eval、专家评分、回归测试与人工复核。
21. Anthropic, Demystifying evals for AI agents — 任务、trial、grader、trajectory、outcome 与评测框架的工程方法。
22. Anthropic, Building effective agents — Agent workflow 的简洁组合模式与灵活行动边界。

补充研究论文

23. Sachan et al., Human-AI collaboration to mitigate decision noise in financial underwriting: A study on FinTech innovation in a lending firm, International Review of Financial Analysis, 2024 — 对人工承保判断的不一致性、证据权重和规则可靠性进行分析。
24. Shi et al., Judging the Judges: A Systematic Study of Position Bias in LLM-as-a-Judge, IJCNLP 2025 — 研究 LLM Judge 的位置偏差与一致性。
25. Wei et al., Systematic Evaluation of LLM-as-a-Judge in LLM Alignment Tasks, 2024 — 评估 Judge 的 Prompt 敏感性、可靠性与人类一致性。
26. FinRegLab — Explainability and Fairness in Machine Learning for Credit Underwriting — 传统信贷模型诊断、解释性、公平性及 2026 年模型管理框架的项目入口。
27. FinRegLab / Stanford GSB — Machine Learning Explainability & Fairness: Insights from Consumer Lending — 对多家厂商与开源模型诊断工具进行实证评估，讨论其在个体预测、群体行为和模型风险管理方面的作用与限制。
28. FinRegLab — Framework for Managing Machine Learning Models in Consumer Credit Underwriting (2026) — 传统 ML 模型管理的近期框架，可用于比较其与 LLM 决策记录、证据溯源和运行评测的差异。

AI 管理体系与风险标准

29. ISO/IEC 42001:2023 — Artificial intelligence management system — 组织建立、实施、维护与持续改进 AI 管理体系的要求。
30. ISO/IEC 23894:2023 — AI risk management guidance — 将 AI 风险管理整合进组织的 AI 相关活动。
31. NIST AI RMF Core — Govern、Map、Measure 和 Manage 的具体成果与行动建议。
32. EU AI Act — Article 12 Record-keeping and Article 14 Human Oversight — 对适用的高风险 AI 的日志与人工监督要求；适用性需结合具体用途和法律评估。

补充论文：忠实度、谄媚、幻觉与人工监督

33. Lanham et al., Measuring Faithfulness in Chain-of-Thought Reasoning, 2023 — 通过干预推理链研究模型答案对所述推理的依赖程度。
34. Guan et al., Monitoring Monitorability, ICML 2026 — 研究 CoT 监测如何帮助识别部分不良行为，也分析它随训练和模型变化的脆弱性。
35. Sharma et al., Towards Understanding Sycophancy in Language Models, 2023 / revised 2025 — 分析人类偏好反馈与迎合用户观点之间的关系。
36. Kalai et al., Why Language Models Hallucinate, 2025 — 从训练与评测激励解释为何模型可能倾向于猜测而不是表达不确定性。
37. Buçinca et al., To Trust or to Think: Cognitive Forcing Functions Can Reduce Overreliance on AI in AI-assisted Decision-making, PACM HCI 2021 — 受控实验显示界面中的认知强制设计可降低过度依赖，但存在主观体验与个体差异上的权衡。
38. Chen and Goldfarb-Tarrant, Safer or Luckier? LLMs as Safety Evaluators Are Not Robust to Artifacts, ACL 2025 — 研究 LLM 安全评价对措辞等表面因素的敏感性。

金融机构公开用例

39. DBS Group — 2025 CRO Statement: Generative AI in risk management — 披露资料提取/验证与由员工审核的信用评估备忘录工作流。
40. DBS Group — 2025 CIO Statement: Scaling AI and governance framework — 披露可复用 GenAI 框架、治理护栏、企业平台与规模化情况。
41. DBS — Ethical & Responsible AI in Banking — 说明 DBS 的 PURE 数据使用框架及风险分级模型治理做法。

Jev、通用 LLM 决策能力与 Agent 工作流

42. TypeSafe AI — Introducing System One Models & Jev — 厂商对专用决策模型、RLCD 训练目标、并行输出、类型化结果及性能主张的说明；阅读时需区分产品陈述与独立验证。
43. TypeSafe — How to build with System One — 官方工程指南，讨论原子化问题、结构化状态、并行判断、代码组合及置信度门控。
44. LangChain — Building Production Agents with Jev and LangGraph — 展示专用决策模型如何成为一般 Agent / workflow 中的一个组件，而不是替代整个运行时。
45. Deußer, Sparrenberg & Sifa — Evaluating and Benchmarking the System One Model Jev, arXiv preprint, September 2026 — 在多个公开数据集上比较 Jev 与开放权重模型的初步独立评测；结论受数据集、模板、基线选择与未公开训练数据等因素限制，不能替代具体业务评测。
46. OpenAI — Function Calling in the OpenAI API — 说明通用模型可以通过函数调用和结构化输出与程序接口衔接。

与工程评测的衔接

• 大模型结果如何测试和验证：Anthropic 与 OpenAI 的方法论 —— 如何构造可重复实验、衡量失败并建立回归门禁。