RAG 答非所问怎么排查：从切块、向量到召回上下文

RAG 应用上线后，最常见的抱怨不是“模型不会回答”，而是“资料明明在知识库里，回答却像没读到”。这类问题通常不能只调 prompt。RAG 的答案质量取决于文档切块、向量化、检索召回、排序、上下文拼接和模型生成，每一层都可能丢信息。

本文按排查现场来走：先复现答非所问，再拆开检索链路，确认问题到底出在切块、向量、top-k、混合检索还是上下文过长。

问题现场：资料存在，回答却偏题

假设我们做了一个企业制度问答助手，用户问：

远程办公员工转正后，设备补贴能报销多少？

知识库里确实有制度文档，但助手回答成了“入职设备领取流程”。这说明生成模型不是完全乱答，而是拿到了相邻但不够精确的材料。现在要验证的是：检索层有没有把“远程办公”“转正后”“设备补贴”“报销金额”这些关键语义召回。

初步判断：先拆开 RAG 链路

不要直接改系统提示词。先把 RAG 拆成五段：用户问题、问题向量、向量/关键词召回、上下文拼接、模型回答。只要能打印每段输入输出，就能知道偏差从哪里开始。

一个最小排查日志应该包含这些字段：

{
  "question": "远程办公员工转正后，设备补贴能报销多少？",
  "top_k": 5,
  "hits": [
    {
      "score": 0.82,
      "source": "入职设备流程.md",
      "chunk_id": "doc-12-03",
      "text": "新员工入职后可领取电脑和显示器..."
    }
  ]
}

如果 top 结果里完全没有“转正”“补贴”“报销金额”，就先查检索，不要急着责怪模型。

动手验证：打印召回片段和分数

下面是一段简化的排查伪代码。重点不是具体向量库，而是把问题、分数、来源、片段内容都打印出来。

def debug_rag(question: str) -> None:
    query_vector = embed(question)
    hits = vector_store.search(query_vector, top_k=5)

    print("QUESTION:", question)
    for index, hit in enumerate(hits, start=1):
        print("RANK:", index)
        print("SCORE:", round(hit.score, 4))
        print("SOURCE:", hit.source)
        print("CHUNK:", hit.chunk_id)
        print("TEXT:", hit.text[:180].replace("\\n", " "))
        print("-" * 40)

跑完后先回答三个问题：

• 正确文档有没有出现在 top-k 里？
• 正确片段是否被切断，关键数字是否不在同一块里？
• 错误片段的分数为什么更高，是词面匹配、语义相近，还是元数据过滤漏了？

定位原因：切块、向量和排序分别怎么看

切块过大：片段里噪声太多

如果一个片段同时包含入职、转正、离职、报销四个主题，向量会被多种语义混合。用户问补贴金额时，系统可能召回了这个大块，但上下文里有太多不相关内容，模型容易抓错重点。

切块过小：答案被拆散

如果“远程办公员工”和“报销金额 800 元”被切成两个片段，单个片段都不足以回答问题。此时要增加 overlap，或者按标题/表格行来切，保证条件和答案留在相邻上下文里。

只用向量：关键词数字容易丢

Embedding 适合语义相似，但金额、编号、日期、产品型号这类精确条件经常需要关键词或过滤条件配合。官方文档也强调，RAG 质量依赖内容准备、向量化、查询逻辑和相关性控制，很多场景会把向量检索与关键词检索结合。

只看分数：没有看片段是否可回答

高分片段不一定可回答问题。排查时不要只保存 score，还要保存 source、chunk_id、title、section 和原文。只有能定位来源，才知道该调切块还是调查询。

修复方案：让正确片段进入上下文

修复可以按从轻到重推进：

第一步：重切关键文档

制度、FAQ、接口文档、表格说明不要只按固定字数切。可以优先按标题、段落、列表项、表格行切，再设置适度 overlap，让条件和结论留在同一段或相邻段。

第二步：补充元数据

给每个 chunk 加上 source、title、section、updated_at、department 等字段。检索时可以用元数据过滤范围，回答时也能提供更清楚的引用来源。

第三步：增加混合检索

如果问题里有金额、日期、编号、专业术语，建议把关键词检索和向量检索合并，再做排序。这样“远程办公”“转正”“补贴”这些词不会完全依赖向量相似度。

第四步：控制上下文拼接

不要把 top-k 全部原样塞进 prompt。可以先去重、按来源聚合、保留标题和片段，再限制总 token。上下文里最好包含“片段来源 + 原文片段”，而不是只拼接正文。

验证结果：用固定问题集复查

修复后不要只试一个问题。准备一组固定问题，每个问题都记录期望命中的文档和关键片段：

[
  {
    "question": "远程办公员工转正后设备补贴能报销多少？",
    "expected_source": "远程办公与设备补贴制度.md",
    "must_include": ["转正后", "设备补贴", "800元"]
  },
  {
    "question": "试用期员工可以申请显示器吗？",
    "expected_source": "入职设备流程.md",
    "must_include": ["试用期", "显示器", "审批"]
  }
]

每次调切块、top-k、混合检索或重排规则，都跑同一组问题。只要正确片段稳定进入上下文，生成回答通常会明显收敛。

总结：一张排查清单

• 先打印 top-k 召回片段，不先改 prompt。
• 检查正确文档是否进入 top-k，正确答案是否被切断。
• 对数字、日期、编号类问题加入关键词或过滤条件。
• 给 chunk 补 source、title、section、updated_at 等元数据。
• 上下文拼接时去重、保留来源、控制 token。
• 用固定问题集验证修复前后变化。

RAG 答非所问时，真正要查的是“正确证据有没有被带到模型面前”。把切块、Embedding、召回、排序、上下文拼接逐段拆开，问题通常会比直接调提示词更快定位。