北京
過去一年，你如果折騰過RAG（檢索增強生成）系統，大概率撞過這堵墻：大模型自信滿滿地扔出一個錯誤答案，引用著向量庫里根本不存在的資料；或者，那些本該躺在數據庫里的關鍵信息，怎么都搜不出來。
問題不在你的嵌入模型，也不在向量數據庫。大多數RAG方案，都把“上下文”當成了關鍵詞匹配問題——可它本質上是意義問題。傳統RAG流程是這樣：切分文檔成塊，給每塊生成嵌入向量，查詢時找“最相似”的塊，喂給大模型。但一旦塊脫離了周邊文本，一句“它提高了40%”就徹底廢了——誰知道“它”指什么，又是什么時候的事。
這背后是三層上下文的集體崩塌。
第一層，塊上下文。就是你切出來的那個段落周圍的文本。缺了它，所有指代都變成啞謎。比如你拿到的塊寫著“此舉把延遲砍掉了60%”，卻沒提到“此舉”指的是從EBS切換到本地NVMe——這個解釋在兩段之前，屬于另一個塊，就這么丟了。
第二層，文檔上下文。塊屬于哪份文檔、什么章節、內容類型（API文檔還是博客）、面向誰、目的何在。這些元數據一旦無視，就會出現災難：用戶想看2026年的最佳實踐，你卻抓回一份2023年的棄用通知。內容曾經有效，但時間維度的上下文讓它變得極度危險。
第三層，語義上下文。是整個知識庫里概念之間的關系網絡——這個塊和其他塊，哪怕跨文檔，在語義上如何關聯。比如用戶問“怎么優化冷啟動”，系統從函數塊里召回一堆Lambda的資料，卻漏掉了VPC配置、預留并發、SnapStart這些關鍵點，只因它們分散在不同文檔里，又缺少共享關鍵詞。
大多數RAG方案能應付第一層就算不錯了。上下文檢索系統則要同時解決這三層。傳統方案的樸素切分法——比如固定每512個token一塊，重疊50個token，對每個塊做嵌入，存進向量庫，查詢時找最近鄰返回top-k結果——碰上指代斷裂、時間錯位、概念分散時，都會反復摔跤。
把這些層都數清楚，你就不難明白：擋在你和大模型可靠答案之間的，不是缺數據，而是數據之間那根斷掉的弦。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
