我给售后 Agent 跑了一次三臂对比，结论有点打脸
同一个评测集、只改一个变量，跑了三组配置。Wiki 没我想象中那么神，快通道也没我想象中那么准。
rag-wiki 的售后 Agent 一直是 Wiki 加双通道在跑：常见问题走快通道直接答，答不了才走 RAG。我默认这套设计肯定比纯 RAG 好，但从来没验证过。这次用同一套 122 条评测用例跑了三臂对比：Wiki 加双通道、原始文档加双通道、Wiki 加纯 RAG，每组只改一个变量。
先看数据。基线组通过 86/122，MRR 0.9277，Top1 0.8889，幻觉率 0.0984；换成原始文档加双通道，通过 91/122；Wiki 加纯 RAG 是 89/122。三组的召回都是 1.0，一条不差。
打脸的地方在这里：三组通过率的差距其实落在噪声里。同一个配置重跑一遍，能有 7/122 条用例翻转，因为 embedding 向量没法逐位复现，每次跑出来的分数都有微小差别。所以结论一：Wiki 索引只改善了排序，没有改善召回，它不是我以为的“全面提升”。结论二：双通道真正的价值是省钱，慢通道的输入 token 从 276,232 降到 206,790，降了 25.1%。
还有一个更扎心的：快通道命中率 21.3%，看着不错，但命中的准确率只有 50%，26 次命中只答对了 13 条。接下来我打算收紧口子，快通道只对单一结论型的条目开放，别再让它什么都往外答。