第一个 RAG 演示总是能成功。
你上传一份干净的 PDF，问一个显而易见的问题，模型找到对应的段落，然后用资金充裕的顾问那种口吻给出回答。
然后，用户用了一个错误的缩写来提问，政策在三周前刚更新过，答案分散在两份文档里，系统引用了一段听起来相关、但实际上并不支持结论的段落。
这时，产品才真正开始。
检索是第一个产品决策
RAG 的质量在模型看到任何内容之前就已经决定了。
检索层决定了模型被允许知道什么。如果返回的片段不对，答案就已经被破坏了。更好的提示词或许能掩盖问题，但无法修复它。
我用几个平淡无奇的问题来评估检索：
- 正确的文档出现在靠前的结果里了吗？
- 正确的章节出现了吗，而不仅仅是正确的文件？
- 更新的材料排名比旧材料高吗？
- 用真实用户会用的措辞来提问，查询能正常工作吗？
- 当诚实的答案是什么都没有时，系统返回空结果了吗？
最后一点很重要。一个总是返回结果的搜索系统，会教会模型总是说点什么。
引用的忠实度比答案的置信度更重要
答案本身是不够的。
对于任何知识系统，我都想知道被引用的来源是否真的支持了所声称的句子。
这意味着要在声明层面进行评估，而不仅仅是响应层面。如果答案有四个声明，但只有两个有来源支持，那么这个答案就不是“大致正确”。它是一种看起来很精致、但实际上很危险的东西。
一个简单的评估标准就够了：
- 支持：引用直接证明了声明。
- 部分支持：引用与声明相关，但未完全证明。
- 不支持：引用无法证明声明。
- 矛盾：引用表达了相反的意思。
你不需要一个复杂的基准测试来开始。你需要 30 个真实的问题，以及诚实标记错误的纪律。
拒绝回答是一项功能
RAG 系统需要知道什么时候不该回答。
这意味着要测试那些语料库中没有答案的问题。也意味着要测试那些答案敏感、过时，或者依赖于用户未提供的上下文的问题。
好的拒绝回答听起来像这样：
“我在现有资料中没有找到相关内容。最接近的文档是 X，但它并没有直接回答这个问题。”
糟糕的拒绝回答听起来像这样：
“根据现有信息，似乎……”
这个短语就是幻觉穿上西装的样子。
有用的评分卡
对于一个内部 RAG 系统，我更愿意追踪五个接地气的指标，而不是一个令人印象深刻的基准测试分数：
- 检索命中率：正确的来源出现了吗？
- 引用忠实度：来源支持答案吗？
- 拒绝准确率：它拒绝了没有依据的问题吗？
- 答案有用性：用户能据此采取下一步行动吗？
- 编辑距离：人类需要修改多少内容？
最后一个指标是最诚实的。如果用户一直在重写答案，那么这个系统并没有为他们节省时间。它只是在制造一个需要他们监督的、礼貌的初稿。
从小处着手，以便能够衡量
正确的第一个 RAG 系统通常不是“公司大脑”。
它是一个语料库、一个工作流、一种用户类型，以及答案之后的一个清晰行动。支持宏、销售赋能、政策查询、内部工程文档、合同条款搜索。
狭窄的范围让评估成为可能。
评估让信任成为可能。
信任让扩展成为可能。
这个顺序很重要。
