给自己的 RAG 做了一轮很小的离线测试，总共 16 个问题。词法检索做对了 9 个，向量检索和混合检索各做对了 12 个。数字本身不算好看，但真正让我在意的，是涉及证据不足和资料冲突的时候，系统仍然存在明显问题。
这轮测试让我重新认识了 RAG。很多人认为，只要大模型的答案后面带着引用链接，就已经解决了幻觉。但实际上，一个答案可以带着真实来源，同时依然是错的。
举个例子。企业知识库里有一份真实的产品说明，写着某个型号支持一种功能。用户问的是另一款相近型号，系统因为关键词相似，把前者检索出来，然后引用这份说明回答。这时候链接是真的，原文也确实存在，但结论没有被正确的证据支持。
还有更隐蔽的情况。一段原文只支持答案中的前半部分，后半部分是模型根据经验补出来的。最终系统把整段话都挂到同一个引用下面，读者可能根本意识不到，哪些内容没有证据。
所以现在研究 RAG，我会更关注检索证据和最终回答之间的关系。首先要能找到相关资料，然后判断资料是否真正适用于当前问题。接下来还要检查回答里的关键结论，是否都能在检索结果中找到支持。如果资料没有覆盖，就应该明确说明；如果两个来源互相矛盾，也应该把冲突交代出来，而不是硬选一个答案。
这里还牵涉到 Chunk 的设计。一张表格原本有型号、版本、适用场景、价格四列，如果切块时丢失了表头，后面检索出来的数据就可能缺少原来的约束条件。
所以 RAG 的质量问题，不能全部推给生成模型。有时候问题出在解析，有时候出在检索，有时候出在重排，也可能出在最终回答没有忠实使用证据。
接下来我想做的，就是把这些环节分别评估，而不是只看最后的答案像不像一个专业人士写的。16 道测试题当然说明不了整个系统的真实水平，但它至少让我知道，哪里还需要继续验证。
正文完