我跑了一晚 RAG ，发现问题不在检索层

你是不是也遇过这种事：

你给 AI 喂了一堆资料，问它一个明明资料里写得清清楚楚的问题，它却跟你说——

"无法从已提供资料中判断。"

昨天晚上我跑了一整晚的 RAG （让 AI 读你自己的文档再回答问题的技术），结果发现：

问题根本不在"AI 找不找得到资料"——它找到了。

问题出在"找到之后，我自己把它的嘴捂住了"。

如果你正在做 AI 应用，或者准备做，这个坑你迟早会踩到。往下看，我帮你先踩一遍。

先把检索这事做扎实

先花 30 秒说个背景：RAG 要让 AI 从你的资料里找答案，第一步是"检索"——从一堆文档碎片里，把最相关的几段捞出来。

目前主流有两条路：

• 向量检索：看语义。"到货延迟"和"交付受影响"，字面不一样，但它知道是一回事。
• BM25 检索：看关键词。文档里有"VFD-F17"，你问"VFD-F17"，它秒匹配。

问题是，这两条路各有盲区。向量可能漏掉精确编号，BM25 碰到换个说法就傻了。

所以我用了一个叫 RRF （ Reciprocal Rank Fusion ） 的融合方法——不看两路各自打多少分，只看它们各自把谁排在前面，然后综合排名。逻辑很简单，核心代码就这么几行：

def rrf(rankings: list[list[NodeWithScore]], k: int = 60) -> list[NodeWithScore]:
    """Reciprocal Rank Fusion: 多路检索 rank 融合"""
    scores: dict[str, float] = {}
    nodes: dict[str, NodeWithScore] = {}
    for ranking in rankings:
        for rank, node in enumerate(ranking):
            node_id = node.node.node_id
            scores[node_id] = scores.get(node_id, 0) + 1 / (k + rank + 1)
            nodes[node_id] = node
    fused = sorted(nodes.values(), key=lambda n: -scores[n.node.node_id])
    for node in fused:
        node.score = scores[node.node.node_id]
    return fused

管线搭起来，跑通了。然后我加了一份 16KB 的中文测试语料，问了 4 个问题。

结果有点意外。

我以为是检索的锅，数据告诉我不是

这份测试语料模拟的是一家制造企业的内部档案，里面有设备报警码、事故记录、供应商交期、项目复盘，什么都有。

然后我问了 4 个问题，检索 + 生成的结果是这样的：

看到没？检索 4/4 全部命中了正确的资料片段。生成却 2/4 拒绝回答。

AI 明明把正确答案摆在面前了，却跟我说"我不知道"。

为什么？因为几天前我被另一个问题坑过——AI 拿到资料后瞎编、乱补充。当时我的解决方案是给它加了一条严格指令：**"凡是资料中没有直接出现的内容，一律回答不知道。"**

那条指令确实治好了瞎编的毛病。但现在它反过来咬我了——原文写的是"故障现象"，我问的是"事故"；原文写的是"到货窗口后移"，我问的是"影响交付"。字面没有完全对上，AI 就老老实实地拒答了。

这让我意识到一件事：

RAG 不是写一条 prompt 就能搞定所有场景的。事实题需要宽松一点让 AI 敢回答，主观题需要严格一点不让它乱编。这两件事，应该分开处理。

但怎么分？让 AI 自己判断这是事实题还是主观题？还是在检索阶段就打标签？又或者干脆准备两套回答模板，按场景切换？

说实话，我现在还没有答案。 但我已经开始拆这个问题了。等我跑通了，下一篇写给你看。

顺带说一个我跑这套时差点崩心态的事：单文档语料下，BM25 的分数会全部归零。一开始我以为是代码写错了，调了半天发现是 BM25 的数学就这么定的——这件事的原理，后面单独写一篇讲。

这篇写给谁

如果你正在做 RAG ，或者准备做，记住一件事：检索对了不代表回答对了。 下次 AI 跟你说"无法判断"的时候，先别急着换模型——看看是不是你自己给它的规则太紧了。