Pinecone前天官宣了知识引擎Nexus，总裁大笔一挥：RAG时代结束了，现在是知识编译（KC）的时代。
这可能是2026年大模型领域最有争议的一句话。毕竟过去四年里，我们80万开发者都在Pinecone的基础设施上学的RAG——chunk怎么切、embedding选什么模型、检索策略怎么搭。现在Pinecone站出来说“兄弟你学的这套方法过时了”，这感觉就像你刚把一套C++书读完，Bjarne Stroustrup告诉你“其实我后来发明了Rust”。
但我转念一想，又觉得Pinecone说得没那么简单。
上周我们团队复盘了一个企业知识库项目。领导要求内网AI助手上线，先把5000份电力规程、故障处理手册喂进去，员工自然语言提问就行。我们自信满满切了chunk，算了embedding，上线两周后一测数据——有效回答率68%。听起来还行，但领导不满意：“还有个30%的回答答非所问。”
我们看了两周的bad case，发现了三个真相。这些真相跟Pinecone说的“RAG时代终结”其实指向同一个问题。
第一个真相：文档解析这层不解决，检索质量根本起不来。
我们用的那套切分逻辑是RecursiveCharacterTextSplitter，按照固定长度切。10kV线路故障和35kV线路故障，在规程文档里经常同时出现。当我们问“10kV线路接地故障处置”，向量检索返回的结果里，35kV线路的相关文档占了42%——因为它们在语义上相似，逻辑上不同。
这套切分方式还干了一件事：它把电力规程文档里“第3.2.1条”的上下文切成两半，导致跨章节的术语解释断了。
后来我们改了方案：按标题层级切，支持10+种行业特定标题格式，表格转Markdown，公式用LaTeX保留。改了之后，文档解析准确率从60%爬到78%。
第二个真相：大部分用户说“答得不对”，其实跟检索没关系。
我拉过20条用户反馈，统计了一下：
8条说“找不到文档”但实际是没有权限；
5条是跨系统聚合的问题，Naive RAG压根做不到；
4条是信息过时，增量同步延迟了14小时；
真正检索质量相关的只有3条。
换句话说，我们团队过去两个月把85%的精力调embedding模型、调reranker，实际能解决的只是那15%的问题。
第三个真相：知识库的“知识过期”问题，比模型不准更致命。
某朋友的公司做过一个知识库，上线后不久发现AI引用的版本是已经作废的旧版，财务按照这条信息算错了数据。同一份制度三个版本共存，系统根本不知道该信谁。这不是RAG能解决的，是知识生命周期治理的问题。
两个实测对比，看看差距在哪
前两天我把某电商平台的运营知识库拿出来做了一个对比。先跑两个测试维度。
第一维度：文档解析
用固定长度切分：电力规程场景检索准确率58%，召回率也是偏低。
改用标题层级解析：准确率拉到78%，召回率大概73%。提升维度主要是语义断层和引用失效这两个缺陷被修了。
第二维度：问题定位
拉100个用户反馈，分类定性。之前没用这种分类方法的时候，我们继续调搜索逻辑，但线上15%的bad case可能都没改善。
做了分类之后，团队直接切入权限治理、延迟治理、数据接入工程这三块。原本90%的用户不满相关的问题，两三周后降到了40%左右。
知识库的准确率不是调embedding调出来的。
文档解析颗粒度对不对，权限管控有没有漏，数据同步延迟不延迟——这些工程问题堆在一起，决定了知识库是“能用”还是“垃圾”。
Pinecone这次“做空”RAG，核心是说推理不应该发生在检索时，应该发生在编译时。但我们的企业知识库落地，大概率还没走到需要纠结知识编译的阶段。先把文档解析搞对，把数据治理搞顺，把多版本控制搞清。
这是我在三个知识库项目中反复踩的坑。上个月我去客户那里，看到他们的知识库项目花了大半年时间，还是卡在“AI明明数据库里有这个文档却说找不到”这种初级问题上。我问他们文档分块策略怎么写的，他们说用的默认方案。
默认方案？那一个知识库项目的生命周期里，默认方案能把多少坑带进来，你猜。
文末讨论问题
你们公司的企业知识库落地最大的坑在哪个环节——文档解析、权限治理、多版本同步，还是别的？评论区说说。
知识编译（KC）和RAG的关系，你认为未来5年是替代关系还是互补关系？
