你无法验证权重:供应商 LLM 的输出验证之道

向你的 LLM 供应商索要模型权重，你会得到一个礼貌的拒绝。索要训练数据、架构细节、微调语料，你会得到同样的答复，只不过是用一份保密协议包装起来的。而你的模型风险团队本应去验证的那个东西，按合同规定，是一个密封的黑箱。可与此同时，这个模型产出的数字最终会出现在董事会材料里、信贷备忘录里、监管申报文件里。

正是这个落差让验证官员感到不安，这种不安是合理的。传统的做法，即打开模型、检查数学运算、确认假设在概念上是否站得住脚，前提是你能看到模型内部。而对于一个前沿供应商 LLM,你看不到。于是问题就不再是“这个模型是否正确？”,而变成了“我能否在从不窥探内部的情况下，反复证明这些输出是正确的？”

为什么检查权重从来不是唯一的路径

SR 11-7 以及围绕它成长起来的各种框架，从一开始就建立在两条腿上，而不是一条。概念稳健性，即模型的设计是否合理，是大家都会引用的那一条腿。第二条腿是结果分析:模型的输出是否与实际发生的情况相符，或者是否与一个可信的参考基准相符。几十年来，银行在无法完全打开供应商评分卡和定价模型的情况下，靠的正是大力依赖这第二条腿来完成验证。它们把输出与已知结果进行对标。

供应商模型一直都受制于这条规则。监管指引一贯坚持，从第三方购买的模型要按照与自建模型相同的原则接受验证，流程可以为约束条件而调整，但标准不会因此降低。专有的内部结构不能让你免于验证，只会让你在结果测试上承担更重的举证责任。

LLM 只是把这个逻辑推到了极致。没有评分卡可以窥探，没有回归系数可以做常理性检查。你有的只是输入的一段提示词，和输出的一段文本。而这恰恰正是结果分析生来就是为了应对的情形。目前在模型风险实践中日益显现，而且审查人员也越来越可能会接受用于一级供应商 LLM 的做法是:针对一套已标注的基准测试集所进行的输出验证，可以替代对你本来就永远拿不到的内部结构进行检查。

输出验证究竟需要什么

输出验证说起来简单，做起来却相当残酷。你需要一组输入、每一项输入对应的已知正确答案，以及一种能够大规模地、把模型的响应与该答案进行评分比对的方法。三个组成部分，而第二个恰恰是大多数项目折戟的地方。

这套基准测试集必须是已标注的。对于一个财务领域的 LLM 来说,“已标注”意味着测试集中的每一个问题都有一个你足够信任、可以据以评分的真值数字答案。第三季度的毛利率是多少？十二月结账后的流动比率是多少？如果十二月的数字让我们的十三周现金跑道增长 6%,那对契约缓冲空间意味着什么？每一个问题都需要一个唯一正确的答案，而且这个答案必须站得住脚，不是“分析师的最佳猜测”,而是一个能与总账核对一致的数字。

这正是没人愿意明说的那个陷阱。你无法用一套你自己都无法为之辩护的数字去对一个 LLM 做输出验证。一个建立在对不上账的电子表格之上的基准测试集，只会把错误洗白后送进你的验证证据里。垃圾真值进去，虚假的信心出来。

基准测试集是一个已对账模型，而不是一份小测验

这里有一个能让问题变得可解的重新框定方式。验证一个财务 LLM 最难的部分不在于 LLM 本身，而在于产出一个你能站得住脚的真值。

一个已对账的财务模型，一个能够精确核对到总账分毫不差的唯一真相来源，恰恰就是这样一个真值。如果你的数字来自一个与 QuickBooks、Xero、NetSuite、Sage 或你的数据仓库核对一致的模型，那么其中的每一个数字都是一个预先标注好的基准测试答案。毛利率、现金跑道、分部贡献、契约计算，所有这些都有一个已知正确的数值，因为承载它们的模型是已对账、可追溯、可审计的。

这正是 Rexfin 构建的架构，值得明确说明一下，这些组成部分是如何与一套验证项目对应起来的:

• 已标注的测试集是天然获得的。 已对账模型中的每一项指标，都是一个附带站得住脚答案的问题。你的基准测试集不是一个额外项目，而是对你的真相来源发起的一次查询。
• 数学运算不经过 LLM。 计算在一个确定性引擎中执行。模型负责检索数字和组织答案的措辞，而不负责做算术运算。这就把一整类失败模式，即 LLM 自信地编造一个数字，收敛成了一个你可以测试并捕获的问题。
• 每一项输出都能追溯到来源。 当模型返回“现金跑道为 11 个月”时，你可以顺着这个数字，沿着计算过程一路追溯到它所依赖的已对账余额。可追溯性正是让一项验证发现从一场争论变成一个可以闭环的事项的关键。

当基准测试集是一个已对账模型，而不是一份静态答案表时，季度输出验证就不再是一个特别项目。你在每次结账之后，重新对当前模型运行这套已标注的测试集，给 LLM 的响应打分，并记录差异。同一套测试工具，每季度都有新鲜的真值。

这解决不了什么

输出验证是必要的，但不是充分的，一个可信的项目会大方地说出这一点。

一套基准测试集只覆盖它所包含的那些问题。真实用户会问一些你从未标注过的问题，用你从未预料到的措辞，而一个在你的测试集上表现完美的模型，在长尾问题上依然可能给出误导性的答案。覆盖率是一个永久存在的开放问题，你不断扩充测试集，抽样检查生产环境中的真实流量，并接受某些风险始终存在于基准测试之外这一事实。

输出验证也无法告诉你一个错误答案是如何产生的。供应商可能会悄悄换用一个更小或经过量化压缩的模型变体来削减成本，而在你意识到原因之前，你的评分可能已经开始漂移。这就是为什么输出验证要与持续监控搭配使用，而不是取代它。你按季度进行验证，同时持续观察，因为那个你打不开的黑箱，也可能在不告诉你的情况下发生变化。

而且这一切都没有涉及检索环节。如果模型从正确的来源中提取了错误的数字，或者从一个已过时的来源中提取了正确的数字，这属于数据层面的失败，你的输出基准测试集能否捕捉到，取决于你标注了什么。对模型的验证和对数据的管控，是两项不同的工作。

结论

你永远无法验证供应商 LLM 的权重，也应该停止设计一套假装你能做到这一点的项目。站得住脚的路径是针对一套已标注的基准测试集进行输出验证，而基准测试集正是决定你的证据是否真实可信的那部分。用能够核对到总账的数字来构建它，让数学运算以确定性方式执行，使模型无法凭空捏造，让每一个答案都能追溯到来源，这样季度验证就会变成一件你可以坦然地展示给审查人员、而不会心虚的日常工作。

如果你正在为一个财务 LLM 搭建验证项目，而基准测试集正是缺失的那一块拼图，那个已对账的真值层正是我们所构建的东西。预约演示,我们会带你走一遍基准测试集是如何从模型中自然产出的。

关于更大的图景,治理财务领域的 AI这个支柱页面涵盖了这一切如何融入更广泛的管控框架，包括2026 年模型风险框架带来的变化,以及支撑起这一切的AI 管控技术栈参考架构。