很多团队第一次做 RAG，会把注意力放在向量数据库上。
选 Milvus，还是 pgvector？
用 HNSW，还是 IVFFLAT？
Embedding 模型换哪个？
这些问题当然重要。但如果一个 RAG 系统答非所问，真正的问题常常不在向量库。
更常见的是：文档没处理好，Chunk 切坏了，元数据缺失，召回链路单薄，重排没有做，旧版本还在索引里，评测只能靠感觉。
这篇文章想讲的就是：
RAG 最难的不是向量库，而是知识链路。
RAG 最难的不是向量库，而是知识链路先看一个很普通的场景。
公司做了一个内部知识库问答。
第一版很快上线：把文档切块，做 Embedding，写入向量库，用户提问时召回 Top-K，再把结果塞给大模型。
Demo 里效果不错。
但一到真实使用，问题就来了：
• 用户问制度条款，模型引用了旧版本 • 用户问接口字段，召回了一段语义相近但业务无关的说明 • 用户问 Excel 里的限制条件，答案漏掉了旁边那一列 • 用户问“退款失败怎么办”，系统只召回了“退款申请流程” • 文档已经删除，但几周后还能被召回 • 每次调 Top-K，好像有时好一点，有时又更差
这时候很多人的第一反应是换模型、换向量库、换 Embedding。
但更应该先问一句：
这条知识链路到底哪一段断了？
一、RAG 不是“把文档丢进向量库”
RAG 的概念并不复杂。
模型不知道你的私有知识，所以先从外部知识库里检索相关内容，再把这些内容放进上下文，让模型基于证据回答。
这就是 Retrieval-Augmented Generation。
但工程上，RAG 不是三步：
上传文档，写入向量库，调用模型。
真正的链路更长：
文档进入系统。
解析和清洗。
切分成 Chunk。
生成 Embedding。
写入向量索引和全文索引。
查询时做 Query Rewrite。
向量检索和关键词检索一起召回。
用 Metadata 过滤权限、业务线、版本。
Rerank 候选片段。
压缩和组织上下文。
让模型基于证据回答。
最后还要评测、观测、更新、回滚。
任何一段出问题，最后看起来都像“模型答错了”。
但模型只是最后一个出声的人。
前面如果给它的是残缺、过期、混乱、无关的上下文，它再会说话，也很难稳定答对。
所以学 RAG，第一件事不是背向量数据库列表，而是建立一条知识链路的心智模型。
二、文档处理决定 RAG 的上限
很多 RAG 项目最早翻车，不是在检索算法上，而是在文档进入系统的第一天。
PDF 是双栏排版，解析后阅读顺序乱了。
Word 里有标题层级，切分后全丢了。
Excel 里真正重要的信息在“字段名、取值、约束、备注”的横向关系里，结果被当成普通文本切碎。
扫描件 OCR 把 0 识别成 O。
图片里的流程图没有文字描述。
表格下方那句“仅适用于企业客户”没有和表格一起进入 Chunk。
这些问题不会在向量库控制台里显得很严重。
但它们会直接决定召回质量。
因为检索器只能检索它看见的东西。
如果文档解析阶段已经丢了结构，后面的 Embedding、Hybrid Search、Rerank 都是在残缺材料上补救。
AIGuide 的 RAG 专题里有一个很重要的提醒：RAG 效果上限经常卡在文档处理。
这句话我很认同。
很多团队会花很久比较 Milvus、Qdrant、pgvector，却没有认真看一眼自己的 Chunk 长什么样。
一个最小检查动作是：随机抽 20 个 Chunk，像 code review 一样看。
它有没有标题？
有没有来源？
有没有业务路径？
有没有把条件和结论切开？
有没有把表格行列关系打散？
有没有把一个完整规则拆成两半？
如果这些问题存在，先别急着调模型。
先把知识入口修好。
三、Chunking 不是切字数，而是保留语义边界
Chunking 最容易被低估。
很多实现会先设一个数字，比如 500 tokens，重叠 50 tokens，然后就开始切。
这不是不能用。
固定长度切分是一个够快的 baseline。
但它不理解文档结构。
真实知识不是均匀分布的。
一个 API 字段说明，可能 120 tokens 就是完整单元。
一个制度条款，可能 800 tokens 才能说清适用范围、例外情况和审批路径。
如果只按长度切，很容易出现两类问题。
第一类是切碎。
问题问的是“什么情况下可以退款”，召回到的 Chunk 只有“退款流程第一步”，没有前置条件。
第二类是切脏。
一个 Chunk 里混了三个主题，Embedding 表示变得模糊，召回时什么都像，什么都不准。
更好的策略通常要结合文档结构。
标题、段落、列表、表格、章节路径，都应该参与切分。
对有层级的文档，可以用递归字符切分或按结构切分。
对需要短召回长阅读的内容，可以用 Parent-Child Chunk：小 Chunk 负责召回，父级段落负责提供完整上下文。
对边界容易丢信息的内容，可以做适度 overlap。
但 overlap 不是越大越好。
重叠太多，会制造重复证据，也会增加上下文噪声。
所以 Chunking 的本质不是“切成多大”。
而是保留知识单元的语义边界。
四、向量检索有用，但别只靠向量相似度
向量检索解决的是语义相似。
用户说“报销被拒怎么办”，文档里写“费用申请未通过的处理方式”，向量检索能帮你把它们连起来。
这是 RAG 的核心优势。
但企业知识库里还有大量问题不是纯语义问题。
接口字段名。
错误码。
产品型号。
制度编号。
客户名称。
数据库表名。
这些内容常常需要关键词匹配。
如果只靠向量相似度，系统可能会召回一段语义很像但编号不对的材料。
用户问的是 ERR_20417，你召回了另一个退款错误码的说明。
看起来相关，实际上错了。
这就是为什么 Hybrid Search 很重要。
向量检索负责语义召回。
关键词检索负责精确匹配。
Metadata 负责业务过滤。
Rerank 负责把“相关”重新排成“可回答”。
生产里的 RAG 很少应该只是一条向量检索链。
更稳的形态是多路召回：
• 向量检索找语义相近 • BM25 / 全文检索找关键词、编号、字段名 • Metadata 过滤租户、权限、版本、业务线 • Query Rewrite 把口语问题改写成可检索问题 • Rerank 按问题与证据的可回答性重排
这里有一个判断标准：
如果正确证据没有进入候选池，问题在召回。
如果正确证据进入候选池，但没进入上下文，问题在重排或 Top-K。
如果上下文里有正确证据，但答案仍然错，问题才更可能在 Prompt、模型或生成约束。
这个拆法比“感觉不准，所以换模型”有效得多。
五、知识库更新是 RAG 进入生产后的分水岭
很多 RAG demo 默认知识库是静态的。
文档一次性导入，然后就开始问答。
但真实系统不是这样。
制度会更新。
接口会变更。
权限会调整。
文档会删除。
Embedding 模型会升级。
Chunk 策略会重做。
业务线会合并。
如果知识库更新链路没设计好，RAG 会出现很隐蔽的问题。
最典型的是旧版本继续被召回。
用户看到的文档已经改了，但向量库里还躺着旧 Chunk。
模型基于旧 Chunk 回答，语气还很确定。
这比直接答不上来更危险。
因为它给了一个过期但像真的答案。
所以每个 Chunk 都应该有元数据。
至少包括：
• doc_id• chunk_id• content_hash• version_id• section_path• acl• embedding_model• embedding_dimension• chunk_strategy• updated_at• is_deleted
这些字段不是为了好看。
它们决定你能不能判断内容有没有变化，能不能跳过未变化 Chunk，能不能删除旧版本，能不能按权限过滤，能不能在 Embedding 模型升级时重建索引，能不能在新策略翻车时回滚。
知识库更新不是“同步一下文档”。
它是 RAG 的数据治理系统。
如果这个系统没有版本、去重、幂等、死信、灰度和回滚，RAG 迟早会在生产里变成一堆难以解释的旧答案。
六、RAG 评测要能定位失败层
不做评测，RAG 优化就是玄学。
今天调大 Top-K，感觉好了。
明天换一个 Embedding，感觉又好了。
后天加 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。
