RAG 最难的不是向量库，而是知识链路

好的，请查收重写后的文章。 别只盯着向量库，RAG的成败在于知识链路的完整构建。这篇文章为你揭示从文档处理到召回重排的工程实践核心。 核心内容： 1. 文档解析、切分与元数据处理的常见陷阱 2. 向量检索与关键词检索相结合的召回链路设计 3. 通过Rerank、上下文压缩与持续评测保障系统稳定 很多团队第一次做RAG，会把注意力放在向量数据库上。选Milvus还是pgvector？用HNSW还是IVFFLAT？Embedding模型换哪个？这些都重要，但如果一个RAG系统答非所问，真正的问题常常不在向量库。 更常见的是：文档没处理好，Chunk切坏了，元数据缺失，召回链路单薄，重排没做，旧版本还在索引里，评测只能靠感觉。 这篇文章想讲的就是：RAG最难的不是向量库，而是知识链路。 ## 一、RAG不是“把文档丢进向量库” 先看一个很普通的场景。公司做了一个内部知识库问答，第一版很快上线：把文档切块，做Embedding，写入向量库，用户提问时召回Top-K，再把结果塞给大模型。Demo里效果不错。但一到真实使用，问题就来了： * 用户问制度条款，模型引用了旧版本 * 用户问接口字段，召回了一段语义相近但业务无关的说明 * 用户问Excel里的限制条件，答案漏掉了旁边那一列 * 用户问“退款失败怎么办”，系统只召回了“退款申请流程” * 文档已经删除，但几周后还能被召回 * 每次调Top-K，好像有时好一点，有时又更差 这时候很多人的第一反应是换模型、换向量库、换Embedding。但更应该先问一句：这条知识链路到底哪一段断了？ RAG的概念并不复杂。模型不知道你的私有知识，所以先从外部知识库里检索相关内容，再把这些内容放进上下文，让模型基于证据回答。 但工程上，RAG不是三步：上传文档，写入向量库，调用模型。真正的链路更长：文档进入系统；解析和清洗；切分成Chunk；生成Embedding；写入向量索引和全文索引；查询时做Query Rewrite；向量检索和关键词检索一起召回；用Metadata过滤权限、业务线、版本；Rerank候选片段；压缩和组织上下文；让模型基于证据回答；最后还要评测、观测、更新、回滚。 任何一段出问题，最后看起来都像“模型答错了”。但模型只是最后一个出声的。前面如果给它的是残缺、过期、混乱、无关的上下文，它再能说会道，也很难稳定答对。所以学RAG，第一件事不是背向量数据库列表，而是建立一条知识链路的心智模型。 ## 二、文档处理决定RAG的上限 很多RAG项目最早翻车，不是在检索算法上，而是在文档进入系统的第一天。 PDF是双栏排版，解析后阅读顺序乱了；Word里有标题层级，切分后全丢了；Excel里真正重要的信息在“字段名、取值、约束、备注”的横向关系里，结果被当成普通文本切碎；扫描件OCR把`0`识别成`O`；图片里的流程图没有文字描述；表格下方那句“仅适用于企业客户”没有和表格一起进入Chunk。 这些问题不会在向量库控制台里显得很严重，但它们会直接决定召回质量。因为检索器只能检索它看见的东西。如果文档解析阶段已经丢了结构，后面的Embedding、Hybrid Search、Rerank都是在残缺材料上补救。 一个最小检查动作是：随机抽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有什么关系 RAG是查询时合成。用户问一个问题，系统临时检索材料，临时拼上下文，临时生成答案。回答结束后，这次合成通常不会沉淀下来。 而这个知识库更像摄入时合成。每次读材料，不只是把原文丢进索引，而是转成source note，更新wiki页，建立链接，写变更记录。它慢一点，但会复利。 所以二者不是谁替代谁。如果材料很多、变化快、问题覆盖面广，RAG很有价值。如果某个主题你要长期研究、反复输出、形成自己的判断，摄入时合成更重要。更好的组合是：先把重要材料整理成wiki，再在wiki上做RAG。这样检索目标不是一堆原始文档碎片，而是已经被清洗、压缩、交叉链接过的知识页面。 RAG不只是一个问答功能，它逼你重新审视知识是如何进入系统、如何被组织、如何被更新、如何被验证的。 ## 九、开发者学RAG，应该先抓住这条链 如果把这一篇压缩成一张检查表，我会这样写： 第一，看文档入口。文档解析对不对？结构保留了吗？表格、图片、OCR怎么处理？ 第二，看Chunk。它是不是完整知识单元？有没有标题、路径、来源、权限和版本？ 第三，看召回。是否只有向量检索？关键词、Metadata、Query Rewrite、Hybrid Search有没有补上？ 第四，看重排和上下文。正确证据是否进了最终上下文？上下文是否太长、太乱、太重复？ 第五，看更新。旧版本会不会继续被召回？删除和权限变更是否同步？Embedding模型升级怎么灰度？ 第六，看评测。失败样本有没有分类？每次策略调整有没有回放？指标能不能定位到具体层？ 这条链走通以后，再谈向量库选型、GraphRAG、Rerank模型、上下文压缩，才有意义。否则你调的不是系统，你调的是运气。 ## 结尾 RAG是AI应用开发里特别适合训练工程判断力的一环。因为它表面上是一个AI问题，但真正做起来，里面全是工程问题：数据清洗、索引、版本、权限、灰度、回滚、评测、观测、成本和用户体验。 向量数据库当然重要，但它只是知识链路中的一站。真正能把RAG做稳的人，不是只会问“用哪个向量库”的人，而是能沿着文档、Chunk、召回、重排、上下文、更新、评测一路追下去的人。