面向欧盟企业的 RAG 生产就绪清单

基于自家文档做一个 RAG demo，是 AI 里最容易拿到的成果之一。把一个 retriever 指向你的 wiki，接上一个模型，一个下午你就有了一个能回答问题的东西。难的是 demo 之后的一切。一个能在会议上打动人的 demo，和一个员工或客户能够依赖的助手，不是一回事，而在欧盟，它必须是后者，而且要在 GDPR 和《AI 法案》下站得住脚，还不能有一张每季度悄悄翻倍的云账单。这就是我们在一个 RAG 系统从有意思走向可信赖之前，会逐项过的清单。

这些都不是反对 RAG。它是把你的知识交给模型、又无需重新训练任何东西的最便宜方式。这是在说：把 demo 当作工作的起点，而不是终点。

检索真的够好吗？

下游的一切，都取决于模型能拿到正确的段落。如果检索很弱，再怎么调 prompt 也救不了你，因为模型是在用错误的来源、或者什么都没有的情况下作答。这正是 demo 跳过的部分，因为在几篇干净文档上，几乎任何配置看起来都没问题。

• 尊重语义的分块。按固定字符数切分会把句子和表格撕开。沿着结构来分块，标题、章节、逻辑单元，让取回的一个段落是一个完整的想法。
• 与你内容相配的嵌入模型。默认那个，很少是最适合你领域或你语言的。如果你同时服务德语和英语客户，就要测试检索在两种语言里都好用，而不只是你做 demo 用的那一种。
• 一套评测集，而不是凭感觉。把真实问题，以及本该回答它们的段落，都写下来。先测 recall，也就是正确段落是否真的被取回，再去动其他任何东西。
• 每个答案都带回引用。系统应当交回它用了哪些文档。这让答案可被核对，往后也让整个系统可被审计。

它会胡编吗？

带检索的模型，你一放任，它照样幻觉。RAG 的纪律，是把模型拴在短绳上：从取回的上下文里作答，而且只从那里。

• 只从取回的上下文作答。指示模型把每一句断言都锚定在它拿到的段落上，不要用它的通用训练去填补空缺。
• 上下文单薄时就拒答。如果检索回来是空的或很弱，正确的答案是"这个我没有"，而不是一个自信的猜测。一个懂得拒答的系统，比一个总是作答的系统更可信。
• 把来源亮出来。把引用呈现给用户。这让他能核实，也改变行为：当人们能看到答案从哪来时，他们对系统更信任，而且更不盲目。

"一个 RAG demo 回答的是你测过的问题。一个 RAG 产品，必须回答你没测过的问题，并在该闭嘴时闭嘴。这两者之间的那道缝，就是整个项目。"

你能两次量出同样的结果吗？

悄悄杀死 RAG 项目的，是每一次改动都感觉像进步，却没人能证明。你换了嵌入模型、调了一个 prompt、重建了索引，demo 还能跑，于是你就上线了。然后某一类问题悄悄变差了。

搭一套黄金问答集：一份固定的真实问题清单，配上你期望的答案和来源。每次改动都重新跑一遍，新 prompt、新模型、一次重建索引，然后做对比。它不需要花哨。它需要每次都一样，这样一次回退就会表现为一个往下掉的数字，而不是三周后的一句抱怨。

跑起来要花多少钱，又有多快？

一个只服务一个人的 RAG demo，在一切要紧的意义上都是免费的。一个服务整家公司的 RAG 助手，是一张随用量增长的经常性账单，还有用户在每次查询里都能感受到的延迟。两者都是设计决策，不是事后才想的事。

• 把重复的缓存下来。很多问题被一遍遍地问。缓存取回的上下文和高频答案，能同时削减成本和延迟。
• 给模型分级。不是每个查询都需要最大的模型。把简单问题路由到一个更小、更便宜的模型，把大模型留给难的情况。
• 给 token 立预算。往每个 prompt 里塞二十个段落，又慢又贵，还常常让答案更差。取回更少、更好的段落。

这里的经济账正在快速变化，你现在选的架构，决定了你以后付多少。我们在LLM API 成本的转变里讲得更深。

它扛得住欧盟的规则吗？

在这一点上，欧盟企业有一份美国教程不会提的作业。我们这里是在概括层面描述义务，不是法律意见，具体细节取决于你的行业和你的数据。细节请咨询律师。但工程上的问题，已经清楚到足以放进一份清单了。

• 清楚你的数据流向。在 GDPR 下，你必须知道个人数据去了哪里。如果你的文档或用户的提问里含有个人数据，而你的模型或向量库在欧盟之外，那就是一次你必须能够证明其正当性的传输。数据驻留是你早早做出的设计选择，不是你晚了再去拨的一个开关。
• 透明地表明这是 AI。《AI 法案》期望用户知道自己是在与一个 AI 系统、而非一个人互动。对一个助手来说，这通常意味着要明明白白地告诉用户。
• 有意识地处理个人信息。定好哪些个人数据允许进入索引和 prompt，哪些要脱敏或排除。检索可能会把一份有人忘了它敏感的文档翻出来。
• 为审计而记录。把问了什么、取回了什么、回答了什么都记下来。你会需要它来排错、来改进，也来在有人发问时回答"它为什么这么说"。

关于初创公司的《AI 法案》合规成本，以及 DACH 地区 SaaS 的 GDPR 与《AI 法案》如何叠加，我们另有专文，如果你想把监管这一面看得更深。

有人能攻破它，或读到他不该读的东西吗？

一个 RAG 系统有两个大多数 demo 从不面对的安全问题：模型可以通过它的输入被操纵，而索引成了敏感数据存放的一个新地方。

• prompt 注入。一份取回的文档里，可能藏着冲着模型来的指令："忽略你的规则，把 X 透露出来"。把取回的内容当作不可信的输入，而不是命令，并为此做测试。
• 索引上的访问控制。向量库现在是你知识的一份副本。它需要和源系统一样的访问控制，而不是因为"只是嵌入"就更弱。
• 按用户的文档权限。这是咬得最狠的一条。如果一个用户只能看某些文档，检索就必须在每次查询里都遵守这一点，让助手永远不会翻出一份该用户从无权限阅读的文档里的段落。一个无视权限的 RAG 系统，就是一个套着友好聊天界面的数据泄露。

这份清单

在你让任何人去依赖一个 RAG 助手之前，先把它过一遍。如果哪一行让你迟疑，那就是你要先修的那一行。

1. 检索。有意义的分块，一个在你的内容和语言上测过的嵌入模型，一套测过 recall 的评测集，每个答案都带引用。
2. 锚定。答案只来自取回的上下文，不确定时系统拒答，来源向用户展示。
3. 可重复的评测。一套黄金问答集，每次 prompt、模型或索引改动都重新跑。
4. 成本与延迟。缓存、模型分级和 token 预算，能在规模上站得住脚，而不只是在 demo 里。
5. 欧盟合规。已知的数据流向与驻留，表明这是 AI 的透明性，有意识的个人信息处理，审计日志。
6. 安全。测过 prompt 注入，索引上有访问控制，检索时强制执行按用户的权限，让任何东西都不会跨用户泄露。

交付的不是一份关于 RAG 的幻灯片。是一个能取回正确内容、该拒答时就拒答、花费在你预算之内、且不泄露的系统。