审稿接受率95%说明审核者已停止阅读

在将生成式模型引入审核工作流时，有一个数字需要追踪：审核人员有多少次原样采纳了草稿。

超过 95% 就说明他们已经停止阅读了。这就是自动化偏见，它在你所有的仪表盘上看起来都像成功。这个人的工作从做事变成了批准，这是另一份工作，有着不同的失效模式，而主要的失效模式就是批准了他们本应发现的问题。

这就是整个问题的形态。原型证明了模型能产出这个产物。生产环境问的是：六个月后，你能否向监管者展示为什么产生了某个特定输出，客户能否对此提出质疑。这些在成为工程问题之前首先是设计问题。

集成工作大约 20% 在模型，80% 在其他所有东西：数据管道、评估、审计日志、人工审核路径，以及向用户展示模型做了什么的前端界面。

输出具有概率性时会改变三件事。同一个输入明天可能产生不同的产物。建立在确定性假设上的界面会悄无声息地出问题。固定 temperature 和 seed，否则你无法复现一个决策。审计面扩大了。每次推理都成为一条你可能需要重建的记录。人的角色从产出变为批准，带来了上面提到的采纳率问题。生成式和预测式是戴着同一张面孔的不同产品。

返回违约概率的信用模型是预测式的。起草后续拒绝通知的助手是生成式的。供应商模糊了这一点，买家继承了这种模糊——一个平台卖"贷款 AI"，你实际上在同一份合同下买了两个不相关的风险画像。

Predictive  Generative

输出 分数、类别、排名 文本、文档、摘要 评估 精度、召回率、相较标签的 AUC 忠实度、 groundedness、人类偏好 失效模式 对某一群体的系统性偏见 自信的编造，每次一个输出 发现方式 聚合分析 逐条审核 可复现性 给定版本即确定 除非固定参数否则会变化 成本特征 训练重、推理轻 训练轻、推理重

生成式功能需要一条审核路径。预测式功能需要一个挑战者模型。把一个当另一个来构建和治理，是这个类别里最昂贵的错误，因为这通常是在审查中被发现的，而不是在冲刺中。

RAG 坐落在两者之间让事情更加混乱。把检索当作数据访问控制来治理，把生成当作内容控制来治理。把它当作一个组件会让两边都更难辩护。

四个前提条件，每个都有通过/失败测试

在第一周、在纸面上运行这些，在任何人写 prompt 之前：

数据——你能不经过手动导出就拉取 200 个带有正确标注结果的真实案例吗？如果这需要超过两天，数据问题就是你的项目问题。团队——合规审核者是在冲刺中被提名了，还是只在分发列表里？基线——有没有一个当前指标，旁边写着今天的数字？发起人——有没有一个高管书面认领了结果和预算？

数据测试最常失败，而且是在第五周失败，那时候模型工作已经排上日程了。这会把上线时间推迟一个季度。

在选模型之前写评估套件

团队实际运行的顺序：第一周选模型因为那是有趣的决策，围绕它产生的内容设计界面，在第十周把整个东西交给合规。颠倒这个顺序是六周构建和六个月构建的主要区别所在。

这个不能移动的依赖顺序：

你无法用你没有写过的评估来验证模型。你无法在不知道正确输出在 workflow 里长什么样的情况下来写评估。所以今天做这个工作的领域专家必须在选模型之前就在场，对 100 到 300 个真实案例进行评分。

成本、延迟、数据驻留和供应商保留策略比基准分数更快地缩小范围。而且要对受保护特征上的差异结果进行测试，即使输出是草稿而不是决策——给某一群体写更友好信件的起草助手是戴着不同帽子的公平贷款问题。

在设计客户界面之前先设计审核者的界面

审核界面决定了审核者是发现错误还是橡皮图章，而这个单一行为比模型质量更决定功能真正的错误率。这是工作中永远不会出现在作品集里的那部分。

除了采纳率，还有两件事有帮助：把检索到的记录放在生成的草稿旁边让 grounding 可见，以及把已知有问题的案例混入队列来检查人们是否仍在发现它们。

在客户侧，三个模式承担信任负荷：

自信披露要陈述依据，而不是一个数字。"根据您三月的对账单和两起之前的争议起草"比"87% 自信"告诉用户更多信息，而且更难被误读。可逆操作。任何模型发起的操作都要有撤销功能并标明时间窗口。对于无法撤销的情况——已发出的付款——要在事前确认而不是事后解释。一条可见的人工路径。只需一次点击，按钮上标明预期响应时间。

当欺诈拦截落在一笔合法交易上时，客户不想要模型的解释。他们想要解除拦截，而且想知道需要多久。金融产品中的信任主要是可恢复性的函数。用户信任他们能撤销的东西胜过他们能读懂的东西。

两个反模式：对任何重要事项不经确认就行动，以及装饰性的可解释性——一个"为什么我看到这条"的链接返回通用文本。弱的解释比没有更糟糕，因为它表明团队知道答案重要但选择不给出。

在 prompt 之前写审计日志

这是人们建设不足的产物。它必须存储 prompt、检索到的上下文、模型版本、参数、输出和审核者的决定——用键关联起来，这样一个案例可以在被要求时重建。

审查者的第一个问题很少关于模型。是谁批准的，他们批准时看到了什么，你现在能拿出那条记录吗。把合规当作构建之后才写的文档的团队发现，那个文档必须描述没有人写下来的决策。

第一周低成本构建。后期改造昂贵，而且在那期间功能处于闲置状态。

成本几何，花在哪里

受监管金融科技工作流中的第一个生产功能：客服风格助手大约 11 万到 22 万美元，交易监控 32 万到 110 万美元，跨越三到六个月。运行成本每月 2000 到 25000 美元，取决于体量。

模型是便宜的部分——在范围良好的工作流上做推理在试点体量下经常低于每月 2000 美元。差异来自数据准备情况和监管层级，而不是模型选择。粗略拆分：数据准备 25-35%，模型集成和评估 15-20%，界面和审核设计 20-25%，审计日志 10-15%，验证和文档 10-20%。

让构建超过范围上限的几乎总是同一件事：工作流没有锁定在一个队列上，在第一个用例上线之前就长出了第二个和第三个用例。

这个方法没有解决的一个权衡。从第一步开始并行运行合规让第一个功能比跳过合规的团队更慢——可衡量地，通常慢四到六周。回报落在第二个和第三个功能上，因为控制框架是可复用的。如果你的组织仅凭速度来评判第一个项目，在项目开始之前就协商好衡量标准，而不是削减治理工作。

锁定一个工作流并附上数字。在代码之前写好终止条件。

完整指南——七步流程、监管表格以及构建与购买：见完整指南

作者：Bohdan Varshchuk，Teamvoy CTO。更多工程写作见 teamvoy.com/blog。