提示词注入与检索偏差:SR 11-7 从未覆盖的风险

SR 11-7 写于 2011 年，那时距离金融行业第一次有人在 ChatGPT 里打出一个问题、并得到一个看起来像答案的数字，还有十二年。美联储和 OCC 的这份指引定义了整整一代人的模型风险管理方式，它假定模型是你构建、记录并用留存数据验证的东西:有输入，有公式，有可复现的输出。把同样的数据跑两遍，得到同样的结果。这个假设支撑了信用评分卡、VaR 引擎和定价模型十多年。

它不适用于大语言模型。而 SR 11-7 所治理的对象与 LLM 实际的运作方式之间的落差，正是新的失败模式滋生之处。

旧框架从未需要命名的三种失败

传统模型风险始终有两大类:模型本质上是错的，或者模型被用错了。这两类依然成立。但一个接入金融工作流的 LLM 引入了三种在 2011 年的验证手册里找不到干净对应的失败模式。

幻觉。 一个缺乏数据的传统模型会返回一个错误或空值。而 LLM 面对空缺时，依然会给出一个自信、流畅、看似合理的数字。OWASP 2025 年发布的 LLM 应用十大风险将这一点列为“错误信息”(LLM09),并直言不讳:输出听起来权威，无论它是否真的建立在任何真实依据之上。在信用模型里，一个缺失的字段会抛出异常;在 LLM 里，一个缺失的字段会被悄悄地用编造的内容填补。

提示词注入。 这是最能打破资深从业者直觉的一种风险。OWASP 将提示词注入列为 LLM 头号风险(LLM01),而其中危险的变体是间接注入:指令藏在模型读取的数据里，而不是用户提出的问题里。模型不是一个你只验证一次的静态产物，它是一个解释器，会从任何触及它的文本中接受指令，包括一份上传 PDF 里的一条脚注、一张表格里的一条注释，或是从你的 ERP 中拉取出的一个描述字段。数据本身就是攻击面。

检索偏差。 大多数金融领域的 LLM 系统使用检索增强生成:拉取相关文档，交给模型，让它作答。答案的质量完全受制于检索器找到了什么。OWASP 将其背后的弱点称为“向量与嵌入弱点”(LLM08)。如果检索器抓来的是上一季度的材料而不是本季度的结账数据，或者只返回了三条看涨的分析师笔记而零条谨慎提示，模型会忠实地基于一个有偏样本进行推理，得出一个自信、错误、却看起来言之有据的结论。没有人注入任何东西，偏差就在于抓取到了什么。

以上都不是“模型校准不准”的问题。它们不是靠对留出集做回测就能发现的问题。这正是一个为评分卡设计的验证框架无法预见它们的原因。

每一种失败都对应一项控制措施，而不是一句免责声明

偷懒的应对方式是挂一个横幅写着“AI 可能出错”。那不是控制措施，那是把责任转嫁给读者。这三种失败中的每一种都对应着某个可以实际构建出来的东西，而修复的思路在每种情况下都是一致的:不再让语言模型接触工作流中那些它本不该被信任的部分。

针对幻觉,控制措施是彻底禁止模型自行生成数字。LLM 的职责是理解问题并进行路由，数字应来自记录系统本身。如果底层数据中不存在该数字，正确的输出应是由数据层返回“不可用”,而不是模型合成出的一个流畅猜测。你要通过把“检索一个数值”与“生成关于它的语言”彻底分离来强制执行这一点。

针对提示词注入,控制措施是把模型能读到的内容和模型能执行的操作隔离开来。把所有检索到的内容都当作不可信输入对待，就像 web 应用对待用户表单数据那样。从文档中提取的文本可以为答案提供信息，但绝不能改变运行哪个计算，或作用在哪个科目上。指令集由你的代码固定，不受写在供应商发票里的任何内容左右。

针对检索偏差,控制措施是可追溯性加确定性。AI 呈现的每一个数字都应带有指向已对账模型中具体源行的引用，让审阅者不仅能核对数字本身，也能核对它所来自的样本。而基于这些数字之上的计算，增长率、利润率、现金跑道、契约比率，都应通过一个每次都得出相同答案的确定性引擎运行，而不是依赖会因措辞不同而产生不同答案的 token 预测。

架构层面的关键一步:检索与计算是两份不同的工作

贯穿这三项控制措施的核心思想是分离。检索是一个搜索问题，计算是一个数学问题，语言是一个呈现问题。SR 11-7 从来不需要区分这三者，因为旧式模型对三者都是确定性处理的。LLM 把三者压缩进一个概率性的整体，而这种压缩正是风险的聚集之处。

这正是 Rexfin 所依据的设计原则。连接你的会计与财务数据平台,QuickBooks、Xero、NetSuite、Sage、SAP、Oracle、一个数据仓库，或直接上传报表，平台会构建一个与总账核对一致的、统一的财务模型。这个模型就是唯一的真相来源。当 AI 提出一个问题时，它是从这个模型中检索数字，而不是凭空捏造。计算通过一个确定性引擎运行，而不是通过 LLM,因此同一个问题永远返回同一个数字。而每一项输出都能追溯到源行，这正是把一个自信的答案变成一个可验证的答案的关键。

具体来说:一条藏在上传 PDF 中的提示词注入指令无法改写契约计算，因为该计算是代码，而不是模型可以自由选择遵循与否的建议。一次有偏检索无法悄悄抬高增长率，因为该比率是从已对账数字中确定性计算出来的，而引用会准确显示是哪些数字。一个被幻觉出来的数字无法出现在董事会材料里，因为模型本身并不是生成数字的那个环节。

这解决不了什么

对局限性的诚实本身也是控制措施的一部分。把计算与检索隔离并不能让你的检索变得完美;如果已对账模型本身是错的，可追溯的答案就是“可追溯地错”,这依然比默默地错要好，但不等同于对。确定性并不验证底层数据，它只是阻止模型在其上再叠加新的错误。而任何架构都无法免除对重大决策进行人工复核的必要性。它真正做到的，是把 LLM 的爆炸半径从“它说的任何内容都可能是一个财务数字”缩小到“它帮你找到并组织语言，来表达一个确定性系统已经担保过的数字”。这是一个小得多、也容易验证得多的治理范围。

一位持怀疑态度的 CFO 不应接受“这个 AI 很谨慎”这样的说法。谨慎不是控制措施。对任何 AI 金融工具应该提出的问题更窄、也更难回答:*从机制上讲，究竟是什么阻止了一个模型编造的数字，或一份被污染的文档诱导模型生成的数字，进入一项决策?*如果答案是一个置信度分数或一句免责声明，那答案就等于什么都没有。

关于这些控制措施如何共同构成更完整图景，请见 AI 金融治理枢纽页面、AI 控制堆栈的参考架构,以及为什么验证供应商的 LLM 必须在输出端进行，而不是在权重层面。

如果你想在自己的总账上亲眼看看检索、确定性计算和端到端可追溯性是如何协同运作的,预约演示,带上一个你一直不敢完全信任的数字。