編輯｜Sia

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

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

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

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

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

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

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

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

為啥嘞？

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

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

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

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

對(duì) Agent 來說，這就很要命。

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

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

有研究發(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 為代表的方案，算是對(duì)傳統(tǒng) RAG 局限的一次重要修正。

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

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

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

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

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

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

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

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

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

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

不久之后，另一條強(qiáng)路線 HippoRAG 2 登場(chǎng)了。

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

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

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

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

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

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

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

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

這套方法在 benchmark 規(guī)模下很強(qiáng)，一旦到了真實(shí) Agent 場(chǎng)景，全局圖的維護(hù)和排序就會(huì)變得很重。

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

那有沒有一種辦法：

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

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

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

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

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

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

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

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

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

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

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

SAG 改成：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第二條路，是語義路徑。

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

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

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

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

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

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

RAG 新 SOTA 到了

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

HotpotQA、2WikiMultiHopQA、MuSiQue。

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

對(duì)手 HippoRAG 2 ，也絕對(duì)不是軟柿子。

結(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 個(gè)百分點(diǎn)。越早命中，后面的 token 越省，延遲越低，推理鏈也越不容易跑偏。

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

SAG 的 Recall@5 是 80.0%，HippoRAG 2 是 65.1%，差了將近 15 個(gè)百分點(diǎn)。

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

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

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

論文還驗(yàn)證了 SAG 對(duì) embedding 模型不敏感。

換成更強(qiáng)的 NV-Embed-v2 后：

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

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

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

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

刷新 SOTA，還能如此規(guī)?；涞氐?RAG，估計(jì)也就 SAG 了。

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

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

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

SAG 也比 GraphRAG 更扛增長(zhǎng)。

因?yàn)?，chunk 是天然的并發(fā)單元，每個(gè) chunk 都可以獨(dú)立處理。

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

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

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

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

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

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

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

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

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

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

為了讓用戶更直觀地體驗(yàn)這套機(jī)制，Zleap AI 還做了一個(gè) Wikipedia 搜索 demo。我們也簡(jiǎn)單問了個(gè)問題：

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

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

體驗(yàn)地址：https://wiki.zleap.com/search

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

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

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

最有意思的是 View Graph。

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

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

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

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

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

不止是知識(shí)，還有記憶

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

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

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

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

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

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

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

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

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

1、開源項(xiàng)目地址：

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