RAG 不是向量数据库，而是在给大模型建立证据链

zavoryn
33 阅读9分钟

cover.png

如果你把 RAG 理解成“把文档切块，存进向量库，查询时捞几段塞给大模型”，那只能做出一个能跑的 Demo。

真正可用的 RAG，不是一个向量库，而是一条证据链：

问题从哪里来，证据从哪里找，为什么选中这些证据，证据之间有没有冲突，最终答案的每一句话能不能回到来源。

很多 RAG 项目第一版都长得差不多：PDF/Word/网页入库，切 Chunk，算 Embedding，存向量库，用户提问时取 Top-K，再拼进 Prompt。这个流程没错，但它只覆盖了“能检索”，没有覆盖“证据可信”。

坏 RAG 的问题通常不是模型不会回答，而是证据链在中间断了：

  • 文档解析把表格拆坏了，答案需要的字段根本没进库；
  • Chunk 切得太碎，“它增长了 3%”这种句子失去了公司、年份、季度；
  • 纯向量检索召回了语义像、但事实不对的片段；
  • Top-K 太大，把噪声也塞进上下文；
  • Prompt 没有要求“资料不足时拒答”，模型开始补脑；
  • 没有评测集，系统上线后只能靠用户投诉发现问题。

blackbox-vs-chain.png

一、RAG 的本质：参数记忆 + 非参数记忆

RAG 这个方向最早在 2020 年的论文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》中系统提出。它的核心思想是：大模型自身的参数是一种“参数记忆”，外部可检索知识库是一种“非参数记忆”。

翻译成开发者语言就是：

  • 模型参数负责语言理解、推理和组织表达；
  • 外部检索系统负责提供最新、私有、可追溯的事实；
  • 生成结果必须受到检索证据约束。

SFT 更像是改变模型的行为习惯和任务能力；RAG 更像是在回答前打开资料库。企业内部知识、产品文档、制度手册、代码仓库、客服 FAQ，这些东西变化快、长尾多、需要引用来源，不适合全部塞进模型参数里。

一句话概括：

SFT 解决“模型会不会这样做”，RAG 解决“模型有没有可靠资料可查”。

二、一条完整的 RAG 证据链

我更建议把 RAG 拆成两条链路看：离线索引链路和在线回答链路。

离线链路负责“证据入库”：数据接入、文档解析、数据清洗、Chunk 切分、元数据绑定、向量化与关键词索引、入库。

在线链路负责“证据使用”：Query 理解、初筛召回、融合排序、Rerank、Context Packing、Grounded Generation、Citation、Evaluation。

system-cutaway.png

这条链路里，向量数据库只是第 6 步附近的一个组件。把它等同于 RAG，就像把数据库等同于整个后端系统。

三、Chunk 不是切饼，而是在保留语义现场

RAG 最容易被低估的地方是 Chunk。

太小的问题是语义断裂：“同比增长 18%。”这句话如果离开公司名、指标名、年份、地区，几乎没有任何证据价值。

太大的问题是噪声过多：一个 2000 token 的 Chunk 里只有 80 token 与问题相关，其余内容都会挤占上下文窗口，还可能干扰模型判断。

比较稳的工程策略是：

  • FAQ：一个问答对就是一个 Chunk；
  • 技术文档：按标题层级、段落和代码块切；
  • 长报告：用父子文档策略，小块用于检索，大块用于生成；
  • PDF 表格：优先保留行列关系，不要只抽纯文本；
  • 代码 RAG：按函数、类、模块和调用关系切，不能按字符硬切；
  • 权限场景：每个 Chunk 必须绑定租户、用户组、文档级权限。

Anthropic 在 Contextual Retrieval 里指出，传统 RAG 把文档切成小块时会丢掉上下文。他们的做法是在每个 Chunk 前加一段简短的上下文说明，再做 Embedding 和 BM25 索引。这个思路很有启发：Chunk 不只是文本片段，它应该知道自己来自哪份文档、哪一节、讨论哪个对象。

chunk-lab.png

四、为什么生产里很少只用纯向量检索？

向量检索擅长“语义相似”，但它不总是擅长“精确命中”。

比如用户问：TS-999 报错怎么处理？

纯向量检索可能召回很多“报错处理”“故障排查”“错误码说明”的内容，但错过唯一包含 TS-999 的文档。

生产 RAG 通常会走 Hybrid Search：

  • Dense Retrieval：向量检索，负责语义相似；
  • Sparse Retrieval：BM25/关键词检索，负责精确词、编号、术语；
  • Metadata Filter：先按租户、权限、产品、时间过滤；
  • RRF 或融合排序：合并多路结果；
  • Rerank：把“看起来相关”的结果变成“真的适合回答”的证据。

Elastic 官方文档建议用 RRF 做混合检索排序；Azure AI Search 文档也详细解释了 RRF 如何把多路排序结果融合成一个统一排序。这背后的工程判断很朴素：不要相信单一路径能覆盖所有问题。

retrieval-console.png

五、Rerank 是把“召回结果”变成“可用证据”的关键层

Embedding 检索通常是 Bi-Encoder：Query 编一次，文档编一次，然后算相似度。它快，适合大规模召回，但判断不够细。

Rerank 通常更像 Cross-Encoder：把 Query 和候选 Chunk 放在一起判断相关性。它慢一些，但更准。

常见组合是：

向量/BM25 初筛 Top 50
        ↓
Rerank 精排 Top 5-10
        ↓
拼入上下文窗口
        ↓
模型基于证据回答

这里有个取舍：召回越大，覆盖率越高，但延迟和成本上升；Top-K 越大，资料越多，但噪声也越多。不要拍脑袋调参数，应该拿评测集跑。

六、RAG 的 Prompt 不是“请根据资料回答”这么简单

生产里的 RAG Prompt 至少要管住四件事：

  1. 证据边界：只能使用检索资料，不要把常识和猜测混进去；
  2. 冲突处理：当资料冲突时，按时间、版本、权威来源排序；
  3. 引用格式：每个关键结论都要能回到文档、章节或链接；
  4. 拒答策略：资料不足时明确说明缺少什么，而不是编一个答案。

还要注意一个安全问题：检索出来的文档和系统 Prompt 共享同一个上下文窗口。如果文档里出现“忽略之前指令”这类内容，模型可能被间接 Prompt Injection 影响。LangChain 的 RAG 文档专门提醒了这个问题，建议把检索内容明确标记为数据，而不是指令。

七、RAG 怎么评估？不要只看答案“像不像”

RAG 如果没有评测，很容易陷入玄学调参。

维度看什么常用指标
检索召回正确证据有没有被找回来Recall@K、MRR、nDCG
检索精度找回来的内容是不是噪声太多Context Precision
生成忠实度回答是否被证据支持Faithfulness / Groundedness
答案相关性是否真正回答了问题Answer Relevance
工程指标是否可上线延迟、成本、失败率、缓存命中率

LangSmith 的 RAG 评估教程把检索质量、回答质量、Groundedness 分开评估；Google Cloud 的 RAG 文章也强调，不做透明评估会导致“静默失败”：系统看起来能回答，但错误长期没人发现。

eval-center.png

八、从开源项目和大厂实践里看 RAG 的演进

看开源项目和大厂博客，会发现一个趋势：RAG 正在从“向量检索 Demo”变成“上下文基础设施”。

LangChain 把 RAG 放进 Agent/Chain 编排里，强调索引和检索生成是两段流程，同时提醒间接 Prompt Injection 风险。

LlamaIndex 更像数据框架，围绕 Document、Node、Index、Query Engine 建抽象。

Haystack 强调 Pipeline：Document Store、Retriever、Ranker、Generator 都是可替换组件。

RAGFlow 把重点放在 deep document understanding，强调复杂格式文档、可解释 Chunk、引用溯源。

Microsoft GraphRAG 用图结构承载实体关系，适合全局总结、多跳关系、复杂数据发现。

Uber 的 Enhanced Agentic RAG 很值得看。他们的内部 on-call Copilot 从传统 RAG 演进到 Agentic RAG，引入 LLM-powered agents 做前置和后置步骤，公开文章里提到可接受答案比例相对提升 27%，错误建议相对降低 60%。

九、一个最小可落地的 RAG 方案

如果今天从零做一个内部知识库问答，我不会一开始就上 GraphRAG、多 Agent、复杂工作流。

我会先做一个足够扎实的最小闭环：

  1. 选一个明确场景，比如“内部制度问答”或“产品 FAQ”；
  2. 整理 50-100 个真实问题，人工标注期望答案和来源文档；
  3. 文档解析先保守，确保标题、段落、表格和页码不丢；
  4. Chunk 使用递归切分 + 元数据，FAQ 用 Q-A 对作为 Chunk；
  5. 检索使用 Hybrid Search：向量 + BM25 + metadata filter；
  6. 初筛 Top 30-50，再 Rerank 到 Top 5-10；
  7. Prompt 强制引用来源，资料不足必须拒答；
  8. 做一个评测脚本，持续看 Recall@K、Groundedness、答案相关性；
  9. 记录 bad case：没召回、召回错、证据冲突、模型编造；
  10. 每次只改一个变量：Chunk、Embedding、Top-K、Rerank、Prompt。

十、最后总结

RAG 不是向量数据库。

向量数据库只是证据仓库的一种实现，RAG 真正要解决的是：

  • 如何把外部知识变成可检索的证据；
  • 如何从海量证据里找出正确片段；
  • 如何让模型只基于证据回答；
  • 如何在资料不足或冲突时不胡说；
  • 如何用评测持续证明系统真的变好了。

如果说 Tool Use 是在给 Agent 设计权限边界，Context Engineering 是在管理注意力预算，那么 RAG 就是在给大模型建立证据链。

没有证据链的 RAG，只是把资料塞给模型。

有证据链的 RAG，才是可以上线、可以追责、可以持续优化的知识系统。

参考资料

avatar
文章
阅读
粉丝