过去一年，你如果折腾过RAG（检索增强生成）系统，大概率撞过这堵墙：大模型自信满满地扔出一个错误答案，引用着向量库里根本不存在的资料；或者，那些本该躺在数据库里的关键信息，怎么都搜不出来。

问题不在你的嵌入模型，也不在向量数据库。大多数RAG方案，都把“上下文”当成了关键词匹配问题——可它本质上是意义问题。传统RAG流程是这样：切分文档成块，给每块生成嵌入向量，查询时找“最相似”的块，喂给大模型。但一旦块脱离了周边文本，一句“它提高了40%”就彻底废了——谁知道“它”指什么，又是什么时候的事。

打开网易新闻 查看精彩图片

这背后是三层上下文的集体崩塌。

第一层，块上下文。就是你切出来的那个段落周围的文本。缺了它，所有指代都变成哑谜。比如你拿到的块写着“此举把延迟砍掉了60%”，却没提到“此举”指的是从EBS切换到本地NVMe——这个解释在两段之前，属于另一个块，就这么丢了。

第二层，文档上下文。块属于哪份文档、什么章节、内容类型（API文档还是博客）、面向谁、目的何在。这些元数据一旦无视，就会出现灾难：用户想看2026年的最佳实践，你却抓回一份2023年的弃用通知。内容曾经有效，但时间维度的上下文让它变得极度危险。

第三层，语义上下文。是整个知识库里概念之间的关系网络——这个块和其他块，哪怕跨文档，在语义上如何关联。比如用户问“怎么优化冷启动”，系统从函数块里召回一堆Lambda的资料，却漏掉了VPC配置、预留并发、SnapStart这些关键点，只因它们分散在不同文档里，又缺少共享关键词。

大多数RAG方案能应付第一层就算不错了。上下文检索系统则要同时解决这三层。传统方案的朴素切分法——比如固定每512个token一块，重叠50个token，对每个块做嵌入，存进向量库，查询时找最近邻返回top-k结果——碰上指代断裂、时间错位、概念分散时，都会反复摔跤。

把这些层都数清楚，你就不难明白：挡在你和大模型可靠答案之间的，不是缺数据，而是数据之间那根断掉的弦。