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

在RAG（检索增强生成）系统的开发过程中，许多团队习惯性地将注意力集中在向量数据库的选型上——是选Milvus还是pgvector？用HNSW还是IVFFLAT？Embedding模型换哪个？这些问题固然值得思考，但一个残酷的现实是：当RAG系统频繁出现答非所问的情况时，真正的问题往往不在向量库本身。文档解析失败、Chunk切分不当、元数据缺失、召回链路单薄、重排机制缺失、版本管理混乱——这些才是导致RAG效果不佳的核心症结。

RAG不是“把文档丢进向量库”

很多团队第一次构建RAG系统时，会快速上线第一版：把文档切块、做Embedding、写入向量库，用户提问时召回Top-K结果，再将结果塞给大模型。Demo演示时效果往往不错，但一进入真实使用场景，问题就接踵而至：用户问制度条款，模型引用了旧版本；用户问接口字段，召回了语义相近但业务无关的说明；文档已经删除，但几周后仍能被召回。这些现象的根源在于：知识链路的某个环节出现了断裂。

文档处理决定RAG的上限

从工程角度看，RAG的知识链路远比“上传文档-写入向量库-调用模型”三步曲复杂得多。完整的链路包括：文档进入系统后的解析与清洗、按语义边界切分成Chunk、生成Embedding后写入向量索引和全文索引；查询时需要做Query Rewrite、向量检索与关键词检索协同召回、通过Metadata过滤权限和版本、最后进行Rerank重排与上下文压缩。在这条链路中，模型只是最后一个出声的人。如果前端给它的是残缺、过期、混乱、无关的上下文，再强大的模型也难以稳定输出正确答案。因此，建立一条完整的知识链路心智模型，比单纯比较向量数据库更为重要。

Chunking的本质是保留语义边界

很多RAG项目最早的翻车点，往往不在检索算法，而在文档进入系统的第一天。PDF双栏排版解析后阅读顺序混乱、Word标题层级在切分后丢失、Excel中横向关联的字段关系被打散、扫描件OCR将0识别成O……这些细节问题在向量库控制台中不会显得很严重，但会直接决定召回质量。检索器只能检索它看见的东西，如果文档解析阶段已经丢失了结构，后续的Embedding、混合搜索、Rerank都是在残缺材料上补救。一个最小检查动作是：随机抽取20个Chunk进行Code Review，检查是否存在标题丢失、来源缺失、条件与结论被切开、表格行列关系被打散等问题。在优化模型之前，先把知识入口修好，才是提升RAG效果的正道。

向量检索之外：混合召回策略

Chunking策略是最容易被低估的环节。许多实现会设定一个固定数字（如500 tokens、重叠50 tokens）就开始切分，这不是不能用，但它不理解文档结构。真实知识并非均匀分布的——一个API字段说明可能120 tokens就是完整单元，一个制度条款可能需要800 tokens才能说清适用范围、例外情况和审批路径。固定长度切分容易导致两类问题：切碎（召回片段只有流程步骤，缺少前置条件）或切脏（一个Chunk混入多个主题，Embedding表示模糊）。更优的策略是结合文档结构进行切分：对有层级的文档使用递归字符切分或按结构切分；对需要短召回长阅读的内容采用Parent-Child Chunk（小Chunk负责召回，父级段落提供完整上下文）；对边界容易丢失信息的内容做适度overlap。Chunking的本质不是“切成多大”，而是保留知识单元的语义边界。

如有侵权，请联系删除。