RAG 检索结果为空怎么办：查询改写、分块粒度与召回验证

知识库里明明有答案，RAG 却返回“没有找到相关内容”，通常不是模型突然失忆，而是检索链路在进入生成模型前就丢了证据。先把问题拆成四段：用户问题是否被改写成可检索表达，文档是否切成了能独立命中的片段，召回阈值是否过严，以及日志里到底有没有返回正确的 chunk。

先判断：是没有召回，还是召回后被过滤

排查第一步不要看最终回答，直接打印一次检索函数的结构化结果。至少保留 query、top_k、每个片段的 score、文档标识和片段正文前 120 个字符。这样能把“向量库没有命中”和“命中了但被业务过滤”区分开。

result = retriever.search(question, top_k=5)
print({
    "query": result.query,
    "hits": [
        {"id": x.doc_id, "score": round(x.score, 4), "text": x.text[:120]}
        for x in result.items
    ]
})

如果 hits 为空，先不要调整回答提示词。如果有结果但都来自无关章节，则继续看查询表达和分块边界；如果结果相关却在拼接上下文前消失，问题多半落在过滤规则或上下文长度限制。

查询改写要解决歧义，不是把问题写长

用户问“这个配置为什么不生效”，检索器很难知道“这个”指哪个文件。查询改写应补齐实体、动作和约束，例如把它改成“服务配置文件中的 timeout 字段未生效，如何确认读取路径与单位”。改写结果需要记录下来，否则线上只能看到一条模糊的原问。

建议保留两个检索分支：原始问题用于保留用户语境，改写问题用于补全关键词。两支各取少量结果后合并去重，避免改写模型误删了原问题中的专有名词。改写不应偷偷加入文档里没有的结论，也不应把多个问题合并成一条长句。

分块粒度决定“答案”能不能独立命中

块太大，向量表示会被目录、背景和多个小节稀释；块太小，标题、条件和例外被拆开，检索命中后又缺少可用上下文。一个实用起点是按小节切分，保留标题路径，并让相邻块有少量重叠：

chunk = {
    "text": "缓存刷新配置 / timeout 单位 / 修改后需要重启 worker ...",
    "metadata": {
        "source": "ops-guide.md",
        "heading_path": ["缓存刷新配置", "timeout 单位"]
    }
}

不要只比较字符数。对一组真实问题做离线样本，分别记录“正确片段是否进入 top-5”和“命中片段是否包含完整条件”。如果标题和正文经常分离，可以把标题路径拼到每个 chunk 的前面，但不要把整篇文档重复塞进每个向量。

阈值和 top-k 要一起看

相似度分数没有跨模型、跨索引的统一含义。固定写死“低于 0.8 就丢弃”很容易把真正答案过滤掉。先固定一批问题，输出 top-10 的分数分布，再观察正确片段通常排在第几位。若正确片段在第 7 位，调低阈值并不能替代改进切分；若正确片段稳定在第 1 位却最终为空，应去查后置过滤。

工程上可以把检索阶段和过滤阶段分开记录：retrieved_count 表示向量库返回几条，kept_count 表示业务规则留下几条。两者一旦出现明显落差，就有了明确的修复入口。对敏感字段、租户 ID、文档状态等过滤条件，也要记录“条件存在”而不是直接打印用户数据。

一套十分钟的最小验证流程

1. 从真实失败问题中挑三条，保存原始问题和应该命中的文档片段。
2. 只调用检索器，分别测试原始问题与改写问题，比较 top-5 的文档标识和分数。
3. 固定查询，轮换两种 chunk 大小与 overlap，检查正确片段是否从候选集中消失。
4. 固定检索结果，暂时关闭业务过滤，确认是召回问题还是过滤问题。
5. 最后才把通过检索测试的上下文交给生成模型，核对回答是否引用了正确条件。

这组测试最好成为一个小型回归集。每次换 embedding 模型、重建索引或调整切分器时自动跑一遍，记录命中率、空召回率和错误片段比例。只看最终回答的“像不像正确答案”，很难定位是哪一段退化。

常见问题

为什么把 top-k 从 3 调到 20 仍然没有答案？

如果正确片段根本没有进入前 20，问题在查询或分块；如果进入了却被丢掉，问题在过滤和上下文拼接。top-k 只是扩大候选，不会修复索引内容。

查询改写是不是越详细越好？

不是。改写应补齐实体和约束，保留关键原词；过长的改写会混入多个意图，让相似度被无关词稀释。

什么时候应该重建向量索引？

当文档正文、分块规则或 embedding 模型发生变化时重建；如果只是过滤条件或 top-k 改动，先用现有索引做对照测试，避免把多个变量同时换掉。

把“空结果”变成可解释的工程信号

RAG 的空回答不应只记录成一条“模型回答失败”。保留查询、分块版本、召回数量、过滤数量和最终上下文摘要，才能在下一次故障时判断该改查询、改切分还是改过滤。先让证据链可见，再谈生成质量，排查会快很多。