編輯｜Sia

前陣子，Claude Code 意外泄露了 512,000 行 TypeScript 源碼。

好家伙，Anthropic 這波莫不是把 Claude Code 的「底褲」都露出來了？

AI 圈扒完之后發(fā)現(xiàn)，最有意思的地方不是模型，而是 Claude Code 這個 Coding Agent 外面那層運行系統(tǒng)。

泄露的大部分代碼，都在處理這些事：什么時候讀文件，什么時候調(diào)用工具，什么時候壓縮上下文，什么時候繼續(xù)下一步。

也就是今天越來越火的 Agent Harness。

一次意外，也算給行業(yè)提了個醒。

Agent 時代，真正重要的不只是模型智商，還有模型外面那套上下文組織、工具調(diào)用和任務(wù)循環(huán)系統(tǒng)。

這套系統(tǒng)里，連接「模型」和「外部知識世界」的基礎(chǔ)設(shè)施——RAG，也必須跟著進化。

為啥嘞？

如果有人想知道「某條產(chǎn)品路線到底受誰影響？」，答案可能藏在這樣一條鏈里：

A 公司收購了 B 公司、B 公司的 CTO 后來加入了 C 項目、 C 項目又影響了某條產(chǎn)品路線。

三件事分開看，未必都和用戶的問題特別相似；只有把它們串起來，才是真正的答案。

傳統(tǒng) RAG 可以迅速在資料庫里找到幾段「看起來最像」的文本，但未必擰得清它們之間是啥關(guān)系。

對 Agent 來說，這就很要命。

因為， Agent 不只是問答，它還要基于檢索結(jié)果繼續(xù)推理、調(diào)用工具、做下一步?jīng)Q策。第一步檢索錯了，后面就會一路跑偏。

結(jié)果會有多離譜呢？

有研究發(fā)現(xiàn)，在醫(yī)學(xué)臨床文本生成中，傳統(tǒng) RAG 技術(shù)反而讓大模型幻覺率，從基線狀態(tài)的 5.0% 飆升至 43.6%。

原因就是，它只是找到了「看起來相關(guān)」的資料，而不是循證的證據(jù)。

這也是為什么，it’s time to 重新思考 RAG。

不預(yù)則廢？Graph 也不是銀彈啊

以微軟 GraphRAG 為代表的方案，算是對傳統(tǒng) RAG 局限的一次重要修正。

還是上面那個問題：某條產(chǎn)品路線到底受誰影響？

GraphRAG 會先把 A 公司、B 公司、CTO、C 項目、產(chǎn)品路線這些實體，以及它們之間的關(guān)系抽出來，做成一張知識圖譜。

再沿著「誰和誰有關(guān)」、「哪些事件屬于同一個主題」、「哪些信息共同指向一個結(jié)論」去組織答案。

這一步很重要。它讓 RAG 從簡單的向量相似度匹配，向結(jié)構(gòu)化關(guān)系推理邁出了一大步。

尤其是在全局理解和主題總結(jié)上，GraphRAG 確實很管用。

引入知識圖譜像是給 RAG 修了一座知識宮殿，漂亮也更有結(jié)構(gòu)，但構(gòu)建和維護起來卻不堪重負(fù)。

抽三元組、合并實體、歸一關(guān)系、建全局圖、做社區(qū)摘要……每一步都很貴，每一步都可能出錯。

更尷尬的是，好不容易蓋好了，一旦真正查詢時，很多系統(tǒng)并沒有充分「沿著圖里的關(guān)系去找答案」，最后還是退回到「找?guī)讉€相似節(jié)點 / 相似摘要」老一套。

最要命的是，世界總在變。今天項目負(fù)責(zé)人換了、明天客戶需求變了、后天某條產(chǎn)品路線又被推翻了……

預(yù)制的圖譜，總不能每天推倒重建吧？

不久之后，另一條強路線 HippoRAG 2 登場了。

受海馬體記憶啟發(fā)，它希望系統(tǒng)像人腦回憶一樣：從一個線索出發(fā)，沿著圖里的關(guān)系擴散，激活更多相關(guān)記憶。

如果用戶想知道，某條產(chǎn)品路線到底受誰影響？

HippoRAG 2 會先識別關(guān)鍵實體和線索，比如 A 公司、B 公司、CTO。然后在圖譜里激活相關(guān)節(jié)點。

接著用 Personalized PageRank 這類圖排序算法，沿著關(guān)系繼續(xù)擴散：從 B 公司找到 CTO、張三、 C 項目，直到產(chǎn)品路線。最后，再把這些線索交給LLM 生成答案。

通過把 RAG 繼續(xù)推向「結(jié)構(gòu)化記憶」和「多跳檢索」，HippoRAG 2 確實有效解決了傳統(tǒng) RAG 在多跳推理和長期記憶上的一部分問題。

但也同樣留下了巨大的工程挑戰(zhàn)。

和 GraphRAG 一樣，HippoRAG 2 也離不開一張離線構(gòu)建的全局圖。

而且，查詢時還要在 graph 上跑 PageRank / Personalized PageRank 這類排序算法。

這套方法在 benchmark 規(guī)模下很強，一旦到了真實 Agent 場景，全局圖的維護和排序就會變得很重。

腦補一下：每天都要持續(xù)寫入新文檔、新實體、新別名、新關(guān)系......

那有沒有一種辦法：

既要結(jié)構(gòu)，又不要一上來就修一座知識宮殿；

既要多跳，又不要每次都在全局圖上跑一遍復(fù)雜排序；

既要支持 Agent 長期使用，又不能每來一批新數(shù)據(jù)，就把整張圖推倒重建；

現(xiàn)在，輪到廣州智躍深空人工智能科技有限公司 Zleap AI 提出的 SAG（SQL-Retrieval Augmented Generation） 出場了。

SAG：用超邊結(jié)構(gòu)重構(gòu) Agent 數(shù)據(jù)底座

其實，名字已經(jīng)點題了——不是 Graph、Hippo，而是 SQL-Retrieval。

它的核心想法是在離線階段，SAG 先把原始文本先整理成「事項 + 實體」的數(shù)據(jù)庫結(jié)構(gòu)。等查詢來了，再圍繞當(dāng)前問題，用 SQL 動態(tài)串出一張局部線索網(wǎng)。

例如，一些討論《給阿嬤的情書》的原始 chunk 如下。

傳統(tǒng)三元組會把這段完整事件鏈，拆成很多條 「主體 - 關(guān)系 – 客體」：

• 僑批 — 具有 — 家書屬性
• 僑批 — 具有 — 匯款憑證屬性
• 深圳企業(yè) — 投資 — 《給阿嬤的情書》
• 影片 — 使用 — 方言

但一段話常常不是一個簡單關(guān)系，而是一件完整的事。強行拆成很多三元組，就像把一篇新聞剪成碎紙條，關(guān)系詞抽錯一點，整條線索就斷了。

SAG 改成：

也就是說，一個 chunk 對應(yīng)一個完整的 event。一個 event 可以連接多個 entity。

反過來，一個 entity 也可能出現(xiàn)在多個 event 里。

一個 event，把多個 entities 綁在了一起，在圖結(jié)構(gòu)上，這更像「超邊（many-to-many hyperedge）」。

這些都會被寫進 SQL 和向量索引里。查詢時，系統(tǒng)通過共享實體把相關(guān)事項臨時連起來。

SAG結(jié)構(gòu)示意圖，離線寫入。

當(dāng)用戶想知道，為什么會有人投資《給阿嬤的情書》？

SAG 會先讓 LLM 從查詢中識別實體，比如投資方、深圳企業(yè)、資金來源、投資決策。然后，兵分兩路。

第一條路，是結(jié)構(gòu)路徑。

系統(tǒng)會去 SQL 中查詢：哪些事項卡和這些實體有關(guān)？它可能首先找到「深圳企業(yè)投資《給阿嬤的情書》」這張事項卡（ event )。

這張卡能解釋投資方看中了影片的社會傳播和市場擴散潛力，但還不能完整回答「為什么值得投」。

于是，SAG 會繼續(xù)讀取 event 里的 entities。例如：深圳企業(yè)、潮汕、僑鄉(xiāng)經(jīng)濟、華人情感、家庭觀影、社會傳播，再通過 SQL 反查其他包含這些 entities 的 event 。

這樣，系統(tǒng)會進一步找到「僑批題材帶來文化價值」這張卡（ event ）；再沿著僑批、地域文化、海外華人、公共文化價值等 entities，找到「主創(chuàng)經(jīng)驗和中小成本制作降低投資風(fēng)險」這張卡（ event ) 。

整個過程本質(zhì)上是 SQL join，不是全局圖推理。最終，原本分散在不同 chunk 里的信息被串成一條鏈。

SAG結(jié)構(gòu)示意圖，在線檢索。

第二條路，是語義路徑。

SAG 也不會完全放棄傳統(tǒng)向量檢索，它會同時用 query 的 embedding，直接去 chunk 索引里找語義上最相似的文本。

所以，SAG 最后拿到其實是兩批候選。

系統(tǒng)此時會做一輪相似度過濾，再讓 LLM 在更小的候選集里挑出最關(guān)鍵的 event。

最后，再把這些 event 映射回原始 chunk，和直接向量召回的 chunk 合并，形成最終給 LLM 看的證據(jù)。

最后你得到的答案，可能是這樣：

投資人之所以愿意投資《給阿嬤的情書》，并不是因為它一開始就具備傳統(tǒng)商業(yè)大片的外觀。相反，這個項目表面上有不少風(fēng)險，比如方言表達(dá)、非流量演員、弱商業(yè)類型。但也有幾個優(yōu)勢，投資人投《給阿嬤的情書》，本質(zhì)上是在投一個文化辨識度強、成本風(fēng)險可控、情感共鳴有擴散潛力的電影項目。

RAG 新 SOTA 到了

說了這么多，SAG 到底有沒有用？ Zleap AI 拿了三個經(jīng)典多跳問答數(shù)據(jù)集來測：

HotpotQA、2WikiMultiHopQA、MuSiQue。

它們都在考系統(tǒng)會不會「順藤摸瓜」。尤其是 MuSiQue，最多要做 4 跳推理，基本就是 RAG 里的硬骨頭。

對手 HippoRAG 2 ，也絕對不是軟柿子。

結(jié)果，在統(tǒng)一配置下：

• SAG 的平均 Recall@2 / Recall@5 達(dá)到：79.3% / 88.2%。
• HippoRAG 2 是：68.2% / 83.3%。

SAG 在前 2 條結(jié)果里命中關(guān)鍵證據(jù)的能力，直接領(lǐng)先了 11.1 個百分點。越早命中，后面的 token 越省，延遲越低，推理鏈也越不容易跑偏。

最難的 MuSiQue，也很能說明問題。

SAG 的 Recall@5 是 80.0%，HippoRAG 2 是 65.1%，差了將近 15 個百分點。

可見，在越需要多跳推理的場景里，SAG 的「事項 + 實體 + SQL 擴展」越能發(fā)揮作用。

消融實驗進一步支持了提升來自結(jié)構(gòu)本身的判斷。

• MuSiQue測試集，三元組版 SAG 的 Recall@5 是 77.1%，超邊版是 80.0%；
• 關(guān)閉查詢時擴展后，Recall@5 從 80.0% 降到 69.4%；
• 用輕量 reranker 替代 Qwen3.6-Flash 做最終選擇，Recall@5 從 80.0% 降到 62.2%。

論文還驗證了 SAG 對 embedding 模型不敏感。

換成更強的 NV-Embed-v2 后：

• SAG 在 MuSiQue 上 Recall@5 從 80.0% 到 81.7%，變化不大。
• HippoRAG 2 對 embedding 更敏感，從 BGE 配置下的 65.1% 到 NV-Embed-v2 下的 74.6%。

真正起作用的，是底層結(jié)構(gòu)變了，而不是堆更強 embedding 。

新 SOTA，還能工業(yè)落地，也就它了

據(jù) Zleap AI 透露，SAG 已經(jīng)在約5 億條數(shù)據(jù)規(guī)模的生產(chǎn)環(huán)境中部署，且數(shù)據(jù)規(guī)模還在持續(xù)增長，在線檢索延遲保持在秒級以內(nèi)

刷新 SOTA，還能如此規(guī)模化落地的 RAG，估計也就 SAG 了。

SAG 能在大規(guī)模數(shù)據(jù)下維持低延遲，關(guān)鍵在于分工。

慢活兒，離線做。用 LLM 做結(jié)構(gòu)化抽取，把 chunk 變成 event 和entity；

快活兒，在線做。用 SQL、向量索引和全文索引快速召回。只讓 LLM 判斷很小的候選集。

SAG 也比 GraphRAG 更扛增長。

因為，chunk 是天然的并發(fā)單元，每個 chunk 都可以獨立處理。

每當(dāng)新網(wǎng)頁、新文檔、新項目進來，不用重新計算全局關(guān)系，直接把新增內(nèi)容變成新的 event 和 entity 并入索引體系即可。

它不是一張每天都要重修的知識圖譜，更像一套能持續(xù)生長的線索檔案庫，這使得增量處理和持續(xù)擴展，都成了自己的優(yōu)勢。

當(dāng)然，很多人會問實體越來越多，合并會不會很復(fù)雜？

會復(fù)雜，但SAG 沒有把「完美實體合并」放在主鏈路里這點也和 GraphRAG 很不一樣。

GraphRAG 把實體當(dāng)成圖里的核心節(jié)點，實體合并錯了，整張圖都會被污染。不合并，路徑又會斷掉。所以，必須認(rèn)真做實體消歧，工程量也會越來越大。

但 SAG 可以接受一定程度的「不完美合并」。

因為 entity 不是答案本身，更像是「路標(biāo)」；event 才是那張寫清楚事情經(jīng)過的卡片。

比如，同一家公司被寫成幾個不同名字，系統(tǒng)不一定要在入庫時立刻判斷它們是不是同一個實體。

SAG 可以先保守處理：入庫前做簡單字符串歸一和 SQL 查詢，在同一個 source 下，如果同類型、同名字的實體已經(jīng)存在，就直接復(fù)用。沒有，就插入為新實體。

后續(xù)查詢時，再通過向量檢索、全文檢索和 LLM 重排把相關(guān)線索補回來。

為了讓用戶更直觀地體驗這套機制，Zleap AI 還做了一個 Wikipedia 搜索 demo。我們也簡單問了個問題：

與《給阿嫲的情書》主題相似的電影，還有哪些呢？

很快，它就放出一段基于十幾條結(jié)果的總結(jié)。下面是被召回的證據(jù)卡片，比如《親愛的奶奶》、《阿嬤的夢中情人》、《情書》。

體驗地址：https://wiki.zleap.com/search

點開《親愛的奶奶》，右側(cè)還能看到這條結(jié)果為什么被召回，以及它對應(yīng)的原始證據(jù)。

左邊返回了《親愛的奶奶》《阿嬤的夢中情人》《情書》這些結(jié)果，而是右邊展示了每條結(jié)果為什么被召回。

這就是 SAG 的可追溯性。Agent 不只是要拿到答案，還要知道答案從哪來；不只是要回答當(dāng)前問題，還要知道下一步該沿著哪條線索繼續(xù)查。

最有意思的是 View Graph。

它不是一張?zhí)崆敖ê玫闹R圖譜，而是 SAG 針對這一次問題，臨時展開的一張局部線索網(wǎng)。

圖里的節(jié)點，就是系統(tǒng)圍繞當(dāng)前問題召回出來的一批事項卡（ event ）。用戶問親情電影，系統(tǒng)就圍繞親情、書信、家庭、回憶這些線索擴展

如果問「收購 Instagram 的公司，其創(chuàng)始人上過哪所大學(xué)」，系統(tǒng)又會圍繞 Instagram、Facebook、創(chuàng)始人、大學(xué)這些實體和關(guān)系重新擴展。

也就是說，SAG 不是提前把全世界的關(guān)系都算好，再等用戶來查。它是在問題發(fā)生時，只激活當(dāng)前問題需要的局部關(guān)系。

這正是它能適應(yīng)大規(guī)模 RAG、并與傳統(tǒng) RAG、GraphRAG 拉開差距的關(guān)鍵。

不止是知識，還有記憶

對 Agent 來說，真正的數(shù)據(jù)底座，其實還要能承載記憶。

除了知道外部世界發(fā)生了什么，Agent 還需要知道：用戶偏好什么表達(dá)方式，某個項目推進到了哪一步，上一次任務(wù)查到了什么結(jié)論，哪個舊判斷后來又被新信息推翻。

這些內(nèi)容如果只按普通 RAG 的方式存成文本塊，系統(tǒng)就只能找回一段相似聊天記錄，卻未必知道哪條是歷史背景，哪條是當(dāng)前狀態(tài)，哪條已經(jīng)失效。

SAG 剛好提供了一個更自然的組織方式。

每條記憶都可以被寫成一個 event：誰，在什么時候，對什么對象，做了什么事，產(chǎn)生了什么狀態(tài)變化；相關(guān)的人、項目、任務(wù)、偏好，可作為 entity 連接起來。

這樣一來，Agent 的記憶就不再是一堆松散的歷史對話，而是一套可以持續(xù)寫入、按線索找回、隨問題動態(tài)展開的事項檔案。

當(dāng)然，論文也提到，真正面向長期 Agent Memory，還需要進一步加入版本化和時間感知能力。但這也是它作為 Agent 數(shù)據(jù)底座最值得期待的地方。

從這個角度看，SAG 真正指向的是一種新的數(shù)據(jù)組織范式：知識可以被持續(xù)寫入，記憶可以被沿線索找回，狀態(tài)變化也有機會被長期追蹤。

這或許也是下一代 Agent 數(shù)據(jù)基座真正需要補上的一課。

1、開源項目地址：

https://github.com/Zleap-AI/SAG

2、論文地址：

https://arxiv.org/abs/2606.15971

3、有關(guān)醫(yī)療AI幻覺的論文：

Representation Before Retrieval: Structured Patient Artifacts Reduce Hallucination in Clinical AI Systems

https://www.medrxiv.org/content/10.64898/2026.02.13.26346256v1.full.pdf