RAG 检索结果很多却答不准：从切块到重排逐层改进

RAG 检索结果很多却答不准，通常不是“再塞几个片段”就能解决。先看正确证据有没有进入候选集：没有，就是切块、查询表达或召回覆盖的问题；已经进入却没被使用，才轮到重排、去重、权限过滤和上下文预算。把这条边界分清，调参才不会变成盲人摸象。

实用的改进顺序是：先让一个 chunk 保持语义完整，再用关键词与向量混合召回扩大覆盖，接着用 metadata 过滤和 rerank 降噪，最后用固定评测集验证 top-k、上下文长度与答案引用。

先定位 RAG 到底错在召回还是上下文

我排查这类问题时，第一件事不是换 embedding 模型，而是保存一条完整记录：问题文本、命中文档、chunk 原文、章节位置、版本、权限标签、候选排名，以及最终送进模型的上下文。正确答案对应的片段不在候选集，属于召回失败；它在候选集但排名很后，属于排序问题；它排名靠前却未进上下文，则多半是去重、过滤或 token 预算造成的丢失。

把这六个对象记录下来，日志才真正能回答“错在哪一层”。只看最终回答里的相似度分数，往往会把召回缺失误判成生成模型能力不足。

切块先保住语义边界，再谈大小和重叠

固定按字符数切分很方便，却容易把“适用条件”和“例外说明”拆开。更稳的做法是先按标题、段落、列表、表格和代码块识别自然边界；遇到特别长的段落，再按 token 上限切成带少量 overlap 的子块，并给每块保留父文档标题、章节路径、版本和访问范围。

切完后抽样检查三件事：片段是否知道自己讨论的对象，结论前的条件是否还在，同一概念的定义和限制是否被拆到别处。若一个问题需要跨两个相邻 chunk 才能回答，可以在索引里保留 parent-child 关系，召回子块后补带父标题或邻近上下文；不要一开始就把整篇文档全部塞进 prompt。

混合召回扩大覆盖，metadata 过滤负责边界

向量召回擅长同义表达，但对版本号、函数名、错误码和精确数字不一定可靠。BM25 或其他关键词检索应保留这些硬匹配，再与向量候选做合并。合并后按租户、权限、文档状态、产品版本和发布日期过滤，顺序上要避免先召回了不该看的内容再交给模型“自己判断”。

def build_candidates(query, tenant, version):
    # 关键词保留错误码、版本号等精确实体，向量召回补足同义表达
    lexical = bm25_search(query, limit=20)
    semantic = vector_search(query, limit=20)
    merged = deduplicate(lexical + semantic)
    # 权限和版本是边界条件，必须在进入重排前过滤
    return [item for item in merged
            if item.tenant == tenant
            and item.version == version
            and item.accessible]

这里的 limit 只是候选上限，不是答案数量。关键实体、否定词、数字和版本号应各自准备测试问题，检查混合后是否仍能看到精确命中；没有真实评测集时，不要声称某种召回比例一定更高。

重排的作用是减少噪声，不是替代召回

重排模型更适合处理一个有限的候选集合：它同时看 query 和 document，重新估计相关性，再把真正回答问题的片段推到前面。Azure AI Search 的语义排序文档也明确说明，语义排序是在已有结果集上重排，并不能重新扫描整个语料库；这正是“召回很多但仍答不准”时必须守住的边界。

实践中可以先取较宽候选，再 rerank，最后去掉相邻重复片段，按“覆盖不同证据点”而不是只按分数取 top-k。上下文预算不足时，优先保留定义、条件、例外和结论依据；如果 top-k 太小，重排看起来更干净，却可能把关键限制一起删掉。

用固定评测集把调参变成可回归的检查

至少保存四类指标：正确证据是否命中、命中片段的排名、最终上下文是否包含必要条件、答案是否引用了正确证据。可以用下面的结构记录评测，不要只看最终回答是否“读起来像对的”。

def evaluate(sample, retriever, reranker):
    # 固定同一问题和标准证据，比较不同切块与 top-k 配置
    candidates = retriever.search(sample.query, limit=40)
    ranked = reranker.rank(sample.query, candidates)
    context = pack_context(ranked[:8], token_budget=3200)
    # 分开记录召回命中与上下文保留，避免把生成波动算成检索提升
    return {
        "hit": contains_evidence(candidates, sample.gold_ids),
        "rank": first_rank(ranked, sample.gold_ids),
        "context_has_boundary": contains_all(context, sample.required_facts)
    }

评测集要故意加入版本冲突、同义问法、否定条件、长文档和权限差异。一次只改一个变量，才能知道是切块、混合召回、重排还是上下文预算带来了变化；对没有证据的回答，还要把“检索不到”与“应该拒答”分开记录。

常见问题

候选越多，RAG 一定越准确吗？

不一定。候选变多只可能提高覆盖，也会带来重复、冲突和上下文污染；应先扩大召回，再用过滤、重排和证据覆盖控制进入 prompt 的内容。

重排模型能解决切块错误吗？

不能。切块把条件拆掉后，重排最多判断片段表面相关，无法凭空补回缺失语义；先修复语义边界，再比较重排效果。

什么时候应该优先改 embedding？

当精确词与同义问法都无法把正确片段召回，并且切块、元数据和关键词基线已经稳定时，再用固定评测集比较 embedding；不要用一两个样例直接更换模型。