检索增强生成在过去三年成了企业落地大模型的标配：把公司文档切 chunk 存进向量库，提问时先检索再让模型基于检索内容回答。这个范式解决了幻觉和知识更新问题，但跑了几百个项目之后，大家开始摸到它的天花板——检索质量、chunk 粒度、时效维护，每一层都有硬约束。
检索质量为什么经常是整个系统的瓶颈？
用户的问题和文档里的原文，措辞往往不一样。向量相似度擅长找语义相近的句子，但不擅长找「虽然用词不同但逻辑上相关」的文档。更麻烦的是，真正答案可能分散在两三份文档里，任何一份单独检索都拼不出完整答案。于是工程团队花了大量精力做混合检索——向量加关键词加知识图谱——再重排序。RAG 项目里大约七成精力花在检索侧，模型反而是最省事的部分。
chunk 切分粒度为什么是一门玄学？
切得太粗，一段里混着多个主题，检索回来的内容噪声大；切得太细，单段缺乏上下文，模型看了也不理解。切分策略从按固定长度，到按语义边界，再到父子块、多级索引，演进了好几轮。但没有一种切法在所有文档类型上都最优，最终往往要针对每类文档单独调。这也是为什么 RAG 项目的边际成本很难压到很低——它本质上是一个需要持续人工调优的系统。
时效更新与知识陈旧怎么破？
企业知识库每天都在变，新产品上线、旧政策废止、人员调动，向量库里的 chunk 如果不及时更新，模型就会一本正经地引用过期信息。完美的更新需要文档级的版本追踪、增量索引、过期标记，这套流水线本身就是一个小型数据工程。很多团队做了 RAG 才发现，维护一个可信知识库的成本，比训练模型高得多。我们在 数据工程 的讨论里反复强调，RAG 的隐性成本在运维，不在搭建。
RAG 的天花板不是技术不够强，而是它假设「把相关文档塞进去就能答对」——这个假设在简单问答上成立，在需要跨文档推理、需要知道「该查什么」的复杂问题上，会系统性失效。
多跳推理为什么是 RAG 的硬伤？
单跳问题——比如「公司年假多少天」——检索一段文档就能答。但多跳问题——比如「年假政策和去年相比有什么变化，对刚入职的人意味着什么」——需要同时调出历史版本、当前版本、以及入职条款，再把三者交叉推理。传统 RAG 每次只取最相关的几段，拼不出这种跨文档的逻辑链。要补上这一环，需要查询改写、多轮检索、以及把中间结论显式写回上下文，这已经接近一个微型智能体的工作流，而不再是一次检索加生成。
去论坛讨论
前往 silicon-agi.com 论坛 参与讨论。