AI 知识库检索不到答案排查：从分块到重排的 RAG 修复流程

做 AI 知识库时，一个很常见的尴尬场景是：资料库里明明有答案，用户一问，机器人却回复“没有找到相关信息”。这时很多人第一反应是改提示词，但真正的问题往往藏在检索链路里。

这篇文章按一次排查过程展开：先看现象，再打印 query、topK 和命中片段，最后通过重切分、补元数据、混合召回和结果重排，把 RAG 回答拉回到可验证的上下文上。

问题现场：RAG 明明有资料却答不上来

假设我们维护了一个客服知识库，用户问：“如何修改订单的收货地址？”文档里确实写了步骤，但机器人返回的是：

抱歉，我不确定，当前没有找到可以回答这个问题的资料。

表面上看，模型像是“不够聪明”；从 RAG 流程看，更可能是没有把正确片段送到模型上下文里。整个故障链路通常是：用户提问进入向量检索，检索没有命中包含答案的 chunk，模型拿到空上下文或低相关上下文，只能保守回答。

注意这里的关键点：资料存在，不代表检索一定命中；检索命中，也不代表命中的片段足够支撑最终答案。

初步判断：先别急着改提示词

我们先把问题拆成三层：

• 入库层：文档是否被正确切分、生成向量并保存。
• 检索层：用户问题是否召回了包含答案的片段。
• 生成层：模型拿到的上下文是否足以组织回答。

如果直接改提示词，最多只能让模型“更努力地回答”。但它没有拿到资料时，再好的提示词也只能产生不稳定的猜测。先确认上下文，再调整提示词，排查顺序会清楚很多。

动手验证：打印 query、topK 和命中片段

排查第一步不是看最终回答，而是把检索日志打出来。至少记录原始问题、改写后的 query、topK 分数、chunk 标识、来源文档和命中片段。

def log_search_result(query, results):
    print("query =", query)
    for item in results:
        print({
            "chunk_id": item["chunk_id"],
            "score": round(item["score"], 3),
            "source": item["source"],
            "title": item.get("title", ""),
            "text": item["text"][:120]
        })

query = "如何修改订单的收货地址"
results = search_chunks(query, top_k=5)
log_search_result(query, results)

如果日志里命中的都是“订单状态说明”“物流异常处理”之类的片段，而不是“修改收货地址”的操作步骤，就说明问题在召回阶段。此时继续调模型参数没有意义，应该回头看切分、索引和排序。

定位原因：分块过大、元数据缺失和召回偏离

我们接着看三个最常见原因。

1. 分块过大，答案被噪声稀释

一个 chunk 同时包含安装、登录、下单、售后等内容，向量会被多种语义混在一起。用户只问“修改地址”，这个 chunk 的相似度可能反而输给更短但不含答案的片段。

2. 元数据缺失，过滤和引用都做不了

如果入库时只保存正文，不保存文档标题、章节名、页码、业务线、版本号，后面就很难做范围过滤，也很难给出可信引用。

3. 只用向量召回，关键词强匹配被忽略

向量检索擅长语义相近，但对一些产品名、菜单名、错误码、配置项并不总是稳定。像“收货地址”“订单详情”“修改地址”这种词，关键词召回往往能补上向量召回的盲区。

修复方案：重切分、混合召回和重排

定位到问题后，可以按下面的顺序修。不要一上来就换模型，先把资料送准。

1. 重新切分文档

推荐按章节标题、列表步骤和语义段落切分，保证每个 chunk 有一个清晰主题。过短会丢上下文，过长会混入太多噪声，可以从 400 到 800 个中文字符左右试起，再结合命中率调整。

def build_chunks(section):
    chunks = []
    for block in split_by_heading_and_steps(section):
        chunks.append({
            "text": block.text,
            "title": section.title,
            "doc_id": section.doc_id,
            "page": block.page,
            "biz": section.biz
        })
    return chunks

2. 给每个片段补元数据

至少保存文档编号、标题、章节、页码、更新时间和业务分类。后续检索时可以先按业务分类或版本过滤，回答时也能带出来源。

{
  "chunk_id": "order_guide_032",
  "doc_id": "order_manual",
  "title": "订单使用手册",
  "heading": "3.2 修改收货地址",
  "page": 12,
  "biz": "order"
}

3. 使用混合召回

把关键词召回和向量召回合并，再去重。关键词召回负责抓住菜单名、错误码、专有名词；向量召回负责匹配同义问法。

def hybrid_search(query):
    keyword_hits = bm25_search(query, top_k=8)
    vector_hits = vector_search(query, top_k=8)
    merged = merge_by_chunk_id(keyword_hits + vector_hits)
    return merged[:12]

4. 对候选结果重排

混合召回会带来更多候选片段，所以需要再按问题和片段的匹配度重排。最终只把高质量 topK 放进模型上下文，避免无关片段干扰回答。

def rerank_top(query, candidates, limit=4):
    scored = []
    for item in candidates:
        score = rank_score(query, item["text"], item.get("title", ""))
        scored.append((score, item))
    scored.sort(key=lambda pair: pair[0], reverse=True)
    return [item for _, item in scored[:limit]]

验证结果：引用片段能支撑答案

修完后再次提问，不要只看“回答看起来对不对”，还要检查引用片段是否能支撑回答。一个较好的结果应该像这样：

命中片段：
chunk_id=order_guide_032 score=0.91 source=订单使用手册 page=12

回答：
进入“我的订单”，选择需要修改的订单，点击“修改地址”，保存新的收货信息即可。
来源：订单使用手册，第 12 页，3.2 修改收货地址。

如果答案正确，但引用片段不相关，仍然不算修好。RAG 的可靠性不只来自模型输出，还来自“答案能被资料证明”。

总结清单

• 资料存在但答不上来，先查检索链路，不要先改提示词。
• 打印 query、topK、score、chunk_id、source 和片段正文。
• chunk 太大时，优先按标题、步骤和语义段落重切分。
• 给 chunk 补充标题、章节、页码、业务线、版本等元数据。
• 向量召回配合关键词召回，覆盖同义表达和精确术语。
• 候选片段需要重排，只把最相关上下文交给模型。
• 最终验证要看引用片段是否真的支撑答案。