让一个AI应用回答问题很爽。让它意识到“文档里根本没这个答案”，才是真正有意思的挑战。
这是AI挑战的第一天，起点是一个很小的问题：怎么让RAG应用在资料撑不住的时候，干脆别答？
问题长什么样
设想你上传了一份公司的休假政策，然后问：“员工每年有多少天年假？”
如果政策里写了，应用应该回答，并把支撑答案的那段原文贴出来。
再问一句：“公司报销国际差旅吗？”
如果文档里压根没提差旅，应用应该说：在提供的材料里找不到答案。
一个自信满满的猜测，很容易被当成公司政策。这就是麻烦所在。
光靠RAG解决不了这件事
检索增强生成（RAG）的逻辑是：先检索相关内容，再交给语言模型去组织答案。
但最相似的那段文字，不一定就是能回答问题的文字。
检索系统即使在没有所需信息的时候，也能返回点什么。所以检索是个有用的起点，但它不保证答案有支撑。
第一天的做法
第一版刻意做小：
兜底可以很简单：“我在提供的文档里找不到这条信息。”
关键是把这句话当成一个合法结果，而不是失败。
要测的三类问题
测试集分三种：
- 可回答：文档里直接有答案；
- 相关但无支撑：问题和文档主题沾边，但答案缺失；
- 不相关：问题超出文档范围。
中间那类最有意思。一段文字看起来相关，却依然撑不起一个答案。
每一条回复都要检查：答案对不对？引用的段落真的支撑它吗？证据缺失时应用有没有拒答？它有没有把本来能答的问题也拒了？
这样才能同时暴露两种毛病：没有支撑的乱答，和过度谨慎的乱拒。
一个容易踩的坑
引用ID合法，不等于答案正确。它只能证明被引的那段文字存在。
至于那段文字是否支撑结论，还得自己看。
同样，不能随便定一个检索分数阈值就假设它到处管用。任何截断值，都得拿真实文档和真实检索方法去测。
今天的目标就是：搭一个小基线，看它在哪儿翻车，把结果记下来，再谈加复杂度。
从这儿起步，是因为“知道什么时候该闭嘴”，看起来是文档类AI应用一个挺有用的地基。
如果你也在做RAG应用，不妨问它一个听起来很相关、但答案被故意从文档里拿掉的问题。
你的应用，发现了吗？
热门跟贴