别只盯着向量库，RAG的成败在于知识链路的完整构建。这篇文章为你揭示从文档处理到召回重排的工程实践核心。
核心内容：
1. 文档解析、切分与元数据处理的常见陷阱
2. 向量检索与关键词检索相结合的召回链路设计
3. 通过Rerank、上下文压缩与持续评测保障系统稳定

一个最小 RAG 评测集不需要一开始就很大。

可以从 30 到 50 个真实失败样本开始。

每个样本至少记录：

• • 用户问题
• • 标准答案或可接受答案
• • 正确证据位置
• • 当前召回结果
• • 最终上下文
• • 模型答案
• • 失败分类

关键是把检索指标和生成指标分开。

检索层看：正确证据有没有进 Top-K？有没有进 rerank 后的上下文？召回片段是否越权？是否过期？

生成层看：答案是否忠于证据？有没有幻觉？有没有拒答？引用是否正确？

这样你才能知道下一步该改哪里。

如果正确证据根本没召回，去改 Prompt 没意义。

如果正确证据已经在上下文里，模型还乱说，那才需要收紧 Prompt、答案格式、证据边界，或者换模型。

如果旧版本反复出现，就该查更新链路，而不是调相似度阈值。

评测的价值不是打一个漂亮分数。

它的价值是让团队知道失败发生在哪一层。

七、GraphRAG 不是第一步，而是关系型失败的解法

GraphRAG 很吸引人。

它听起来比普通 RAG 更高级：实体、关系、知识图谱、社区发现、全局检索、多跳推理。

但我不建议一开始就把 GraphRAG 当默认方案。

因为它解决的是特定问题，也带来特定成本。

普通向量 RAG 的弱点是 Chunk 像信息孤岛。

它不擅长回答需要跨文档、多实体、多关系的问题。

比如：

哪些系统共同影响退款链路？

某个供应商和哪些产品线有关？

一个政策变化会波及哪些业务流程？

这类问题不是找一段相似文本就够了。

你需要实体、关系、路径和全局结构。

GraphRAG 在这里有价值。

但它也会引入新的工程难点：

实体可能抽重、抽错、抽太碎。

关系方向一错，答案会系统性跑偏。

社区摘要需要维护。

更新一篇文档，可能牵动一片图。

权限过滤不能只停留在文档级。

所以更稳的路线是：

先做好向量 RAG 基线。

再收集关系型失败案例。

如果失败确实集中在多跳、全局、关系推理，再从轻量图谱开始。

不要为了显得高级，把第一版 RAG 做成一个维护成本很高的图谱工程。

八、这和 Personal Knowledge OS 有什么关系

写到这里，其实也能解释我为什么一直维护这个 Personal Knowledge OS。

RAG 是查询时合成。

用户问一个问题，系统临时检索材料，临时拼上下文，临时生成答案。

回答结束后，这次合成通常不会沉淀下来。

而这个知识库更像摄入时合成。

每次读材料，不只是把原文丢进索引，而是转成 source note，更新 wiki 页，建立链接，写变更记录。

它慢一点。

但会复利。

所以二者不是谁替代谁。

如果材料很多、变化快、问题覆盖面广，RAG 很有价值。

如果某个主题你要长期研究、反复输出、形成自己的判断，摄入时合成更重要。

更好的组合是：

先把重要材料整理成 wiki。

再在 wiki 上做 RAG。

这样检索目标不是一堆原始文档碎片，而是已经被清洗、压缩、交叉链接过的知识页面。

这也是我从 AIGuide RAG 专题里得到的一个延伸判断：

RAG 不只是一个问答功能。

它逼你重新审视知识是如何进入系统、如何被组织、如何被更新、如何被验证的。

九、开发者学 RAG，应该先抓住这条链

如果把这一篇压缩成一张检查表，我会这样写：

第一，看文档入口。

文档解析对不对？结构保留了吗？表格、图片、OCR 怎么处理？

第二，看 Chunk。

它是不是完整知识单元？有没有标题、路径、来源、权限和版本？

第三，看召回。

是否只有向量检索？关键词、Metadata、Query Rewrite、Hybrid Search 有没有补上？

第四，看重排和上下文。

正确证据是否进了最终上下文？上下文是否太长、太乱、太重复？

第五，看更新。

旧版本会不会继续被召回？删除和权限变更是否同步？Embedding 模型升级怎么灰度？

第六，看评测。

失败样本有没有分类？每次策略调整有没有回放？指标能不能定位到具体层？

这条链走通以后，再谈向量库选型、GraphRAG、Rerank 模型、上下文压缩，才有意义。

否则你调的不是系统。

你调的是运气。

结尾

我越来越觉得，RAG 是 AI 应用开发里特别适合训练工程判断力的一环。

因为它表面上是一个 AI 问题。

但真正做起来，里面全是工程问题：

数据清洗、索引、版本、权限、灰度、回滚、评测、观测、成本和用户体验。

向量数据库当然重要。

但它只是知识链路中的一站。

真正能把 RAG 做稳的人，不是只会问“用哪个向量库”的人。

而是能沿着文档、Chunk、召回、重排、上下文、更新、评测一路追下去的人。

下一篇 AIGuide，我会继续写 Agent。

也就是：一个系统什么时候才从 LLM 应用变成 Agent。

来源说明

本文内容主要基于 Snailclimb / JavaGuide 的 AIGuide RAG 专题整理，并结合我自己的阅读理解做了重写和串联。原项目与在线阅读地址如下：

• • https://github.com/Snailclimb/AIGuide
• • https://github.com/Snailclimb/JavaGuide/tree/main/docs/ai/rag
• • https://javaguide.cn/ai/

来源

• • [[Source - Snailclimb - AIGuide RAG Topic - 2026-06-23]]
• • [[Concept - RAG]]
• • [[Method - RAG Engineering]]
• • [[Project - AIGuide]]