RAG 为什么不是“向量库 + 提示词”？一条检索链路到底经过什么

你给面试官展示一个 RAG Demo：上传 PDF，提问，模型回答，答案下面还带了引用链接。

面试官看了一眼，问得很平静：

“如果答案错了，你怎么知道是文档没切好、向量没召回、重排把正确片段挤掉，还是模型看到了证据却没有用？”

很多人会重新解释一遍 Embedding。可这道题真正考的是：你能不能把 RAG 当成一条可诊断的工程链路，而不是三个热门名词的拼盘。

先给一个能复述的答案

RAG 是把外部知识接入生成模型的一套检索与生成流程。离线阶段先清洗文档、按语义和结构分块、生成向量并建立索引；在线阶段把用户问题改写成适合检索的查询，经过关键词或向量召回、元数据过滤和重排序，选出有限的高质量证据，最后把证据和问题一起交给模型生成回答。真正可靠的 RAG 还要分别评测数据、召回、排序、引用和最终答案，不能只看“模型说得像不像”。

图 1：RAG 不是一个向量数据库调用，而是离线链路和在线链路的汇合。

一、离线阶段：先把“能被检索的知识”做出来

1. 文档清洗比换 Embedding 更容易被忽略

原始资料通常不是干净的连续文本。PDF 可能把双栏顺序打乱，网页会混入导航和广告，表格被 OCR 拆成一行行孤立数字，飞书文档还可能带有折叠块、图片和附件。

如果这些噪声直接进入索引，后面的检索器只能在坏数据上努力。它不是没学会，而是仓库里根本没有一份可用的证据。

我会在入库前至少保留四类信息：正文、标题层级、来源定位、更新时间。标题和路径不能被清洗掉，因为它们既帮助分块，也帮助回答时生成可点击引用。对于表格和代码，要保留结构化表示，不要把所有换行抹平。

2. 分块不是按字符数切蛋糕

Chunk 太大，一个片段里混进多个主题，召回时相似度被平均；Chunk 太小，答案需要的前提被拆散，模型只拿到半句话。

更稳妥的起点是先沿标题、段落、列表和表格边界切，再用 token 上限做兜底。对于长章节，可以建立父子块：子块负责精确召回，父块负责补上下文。重叠窗口可以减少边界损失，但重叠不是越大越好，重复内容太多会浪费上下文预算。

分块策略要用问题集验证。拿真实问题回放，观察“答案所需的最小证据是否完整”以及“召回片段是否包含无关章节”，比单独讨论 256 还是 512 更有意义。

图 2：Chunk 大小不是一个脱离任务的常数，而是三种约束的折中。

二、在线阶段：召回不是最后一步

1. 先问清楚“这个问题该怎么搜”

用户问题常常不是检索问题。比如“为什么最近接口变慢”，里面可能缺少产品名、时间范围和指标；“这个功能怎么开”，可能需要把代词解析成上一轮提到的功能。

在线检索可以先做轻量改写：补充实体、拆分多意图问题、生成几个查询变体，或者把对话历史里的指代还原。改写不能偷偷改变原问题，最好把原查询和改写后的查询一起记录，出了问题才知道是用户问错、改写错，还是召回错。

2. 混合检索通常比单一路径更稳

向量检索擅长找语义相近的表达，关键词检索擅长命中版本号、错误码、类名和专有名词。企业知识库里两类问题都会出现：有人问“怎么处理登录失败”，有人直接问“ERR_AUTH_403 是什么”。

因此可以用向量召回和 BM25 等关键词召回并行，再做去重和融合。融合不是把两边结果简单拼接，而是要处理分数不可比、重复片段、不同来源优先级和权限过滤。

场景	向量检索的优势	关键词检索的优势	建议
同义表达	能找到意思相近的段落	可能完全不命中	保留向量召回
错误码/版本号	可能被语义稀释	精确命中	保留关键词召回
多租户知识库	需要额外过滤	需要额外过滤	先做权限与租户过滤
长问题	可能只抓到局部语义	词项过多导致噪声	查询拆分后多路召回

一个简单的融合策略是先对各路结果做归一化，再按来源权重合并，最后去重。权重不是写死后永远不动：错误码密集的知识库可能更依赖关键词，产品问答则可能更依赖语义召回。上线前要用同一批问题比较“只用向量、只用关键词、混合检索”三组结果，报告召回率、重复率和时延，而不是只展示几个成功案例。

3. 召回多一点，交给重排决定谁先进上下文

初排适合快速从大规模索引里找候选，重排适合用更昂贵的交互模型比较“问题和候选片段是否真的匹配”。常见做法是先取 top 20 或 top 50，再重排后选 top 3–8 进入上下文，具体数量由模型窗口、片段长度和任务验证决定。

重排不是万能过滤器。候选集里没有正确证据时，重排只能把错误片段排得更整齐；正确片段被父子块拆散时，重排也可能偏爱一段看起来更像答案、但缺少前提的文字。

三、模型看到了证据，为什么仍然会答错

RAG 失败至少有五个位置：数据没有进来，召回没找到，重排顺序不对，生成没有遵守证据，评测没有测到真正问题。

图 2：答案错误只是症状，定位链路后才知道该改哪一层。

有一个很实用的排查顺序：先把最终答案拿掉，只看 top-k 是否包含支持答案的证据；如果不包含，检查数据、分块和召回；如果包含，再看重排后是否仍在上下文；如果在上下文，再检查模型是否引用了正确片段；最后才讨论提示词和模型能力。

举个常见故障：知识库里明明有“退款到账时间”的说明，用户问“昨天申请退款，今天为什么还没到账”，检索却只返回“退款入口在哪里”。这时不能直接说模型答非所问。可能是问题里的时间条件没有被改写，可能是“到账时间”与“处理时效”被切在两个块里，也可能是重排偏爱“入口”这个高频词。把每一层的输入输出留下来，定位通常比盯着最终回答快得多。

这条顺序能避免一个常见浪费：明明检索阶段就没有拿到证据，团队却连续改“请严格基于资料回答”的提示词。模型不是不听话，它只是没有资料可用。

四、评测要拆开，否则所有问题都会变成一个分数

完整评测至少需要四层：

1. 数据层：文档是否完整、是否过期、权限和来源是否正确。
2. 检索层：Recall@k、MRR、NDCG 等指标，回答需要的证据是否进入候选集。
3. 生成层：答案是否被证据支持，是否出现与证据冲突的内容，引用是否指向正确片段。
4. 系统层：时延、成本、缓存命中率、失败率和不同租户的隔离情况。

评测集不要只放“答案在文档里”的简单问题，还要有不可回答问题、多跳问题、版本冲突、相似标题、权限不可见和资料过期。否则系统只会在最舒服的题型上报喜。

图 3：四层指标分别回答“资料是否可靠、证据是否找到、答案是否有依据、系统是否能上线”。

六、上线前的最小检查清单

• 抽样 20 份文档，人工确认标题、段落、表格和来源定位没有被解析器破坏。
• 用真实问题集检查 top-k 是否包含“足以回答”的证据，而不是只看相似度分数。
• 对混合检索、重排和上下文数量做离线对比，记录准确率、重复率、token 和 P95 时延。
• 单独测试不可回答问题：没有证据时，系统应该明确说不知道，而不是拼接一段看似合理的话。
• 每次文档更新保留版本和更新时间，旧答案出现时可以追溯到当时使用的知识快照。
• 对权限不可见的文档做反向测试，确认模型不会通过缓存、引用或摘要泄露内容。

五、一个可落地的 RAG 回放记录

为了让问题可复盘，我会给每次请求记录一条结构化 trace：

{
  "query": "原始问题",
  "rewritten_queries": ["检索改写后的问题"],
  "retrieval": {"hybrid": true, "top_k": 20},
  "reranked_chunks": ["chunk_id_1", "chunk_id_2"],
  "context_budget": {"tokens": 3200, "used": 2870},
  "citations": ["doc_12#section_3"],
  "evaluation": {"retrieval_hit": true, "citation_supported": true}
}

这份记录不需要保存用户隐私原文，但必须足够回答四个问题：召回了什么、为什么选它、模型引用了什么、这次失败应该归到哪一层。没有 trace，RAG 优化很容易变成“换个模型再试试”。

60 秒面试回答

RAG 是一条从知识准备到检索生成的完整链路。离线阶段清洗文档、按结构分块、生成 Embedding 并建索引；在线阶段对问题做必要改写，通过关键词和向量混合召回，再用重排模型选出有限的证据，和问题一起交给大模型。工程上我会把数据、召回、重排、生成和系统指标分开评测。答案错时先检查 top-k 有没有证据，再判断是排序、上下文组装还是模型引用问题，而不是先改提示词。这样 RAG 才是可诊断、可回放、可持续优化的系统。

面试追问清单

• 如果 top-k 没有正确片段，你先改分块、Embedding 还是召回数量？为什么？
• 关键词检索和向量检索的分数不可比，结果如何融合？
• 为什么重排后反而变差？如何判断是模型问题还是候选集问题？
• 如何评测“引用真的支持答案”，而不是只看答案关键词命中？
• 知识库有权限隔离时，过滤应该发生在召回前还是召回后？

本篇总结

• RAG 的核心不是“把知识放进向量库”，而是让证据从数据一路可追溯地到达答案。
• 分块、Embedding、召回、重排分别解决不同问题，不能互相替代。
• 混合检索适合同时处理语义问题和错误码、版本号等精确问题。
• 评测必须拆成检索、生成、引用、成本和安全，不要只看最终回答像不像。
• 先建立 trace 和回放，再做模型或参数优化。

参考资料

1. AgentAlpha《Agent 岗面试宝典 v3》第 1 章：RAG（检索、Embedding、分块、向量数据库、重排与评测）。
2. Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks（2020）。
3. Robertson & Zaragoza, The Probabilistic Relevance Framework: BM25 and Beyond（2009）。

下一篇：Embedding 到底把什么变成了向量？