# 策展 · X (Twitter) 🔥🔥 > 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt) > 作者：袋鼠帝 (@aikangarooking) · 平台：X (Twitter) · 日期：2026-06-24 > 原始來源：https://x.com/aikangarooking/status/2069325659105861926 ## 中文摘要 # 再見 RAG！AI 知識庫還是得用 SAG，又快又準～ 你好，我是袋鼠帝。 上週有客戶找我聊了一個需求，大意是想做一個本地的「小秘書」： 會議記錄、立項材料、批復文件，這些都要能透過 Agent 對話直接查詢，項目金額、開始時間這類確定的資訊也要能查，而且準確度要高，可用性要強。他自己有本地伺服器和大型語言模型，資料量大約不超過 1500 個文件。 ![這是一張通訊軟體對話截圖，內容關於開發一個能處理會議紀要、立項材料及查詢資料庫的 AI 小秘書專案。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/bb10b25d7f652cbd.jpg)
展開畫面重點
截圖顯示一段關於開發 AI 應用程式的對話紀錄： - 對方：「你好，我想跟您訂一個項目」 - 對方：「我想做一個小秘書，就是我們會有很多會議紀要 (word pdf)；立項材料 (ppt)；批復 (word,pdf)；其中會議紀要裡面會有很多塊的小事件」 - 對方：「然後還會有很多明確的信息，比如項目金額這種確定的信息寫在數據庫中讓大模型查詢數據庫返回答案」 - 對方：「然後通過對話方式來查詢知識庫來回答問題」 - 對方：「要求這個回復準確率要高」 - 對方：「一定可用性強」 - 對方：「看到時方便回一下哈😊😊😊」 - 我方：「需要查詢的數據量有多大呢」 - 對方：「小於 1000 個文檔，不會超過 1500」
![一段關於企業知識庫建構與本地大型語言模型應用規劃的對話截圖。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/c84a7a8bcd9cf19d.jpg)
展開畫面重點
圖片為即時通訊軟體的對話紀錄，內容涉及如何建立知識庫與檢索系統。對話內容轉錄如下： 對方訊息： 「就是還有就是我會把一些明確的信息存在數據庫中，比如項目信息，項目名字，項目多少錢，什麼時候開始的這種，然後問問題的時候先查數據庫，數據庫沒有的時候查這些文檔，查完文檔之後回答，再把相關文檔圖表展示出來，點一下就打開」 「我想的是項目的就立項材料 (ppt)，批復 (word)，會議紀要的一部分 (word/pdf)；事件就查會議紀要的一部分 (word/pdf)；這裡主要是會議紀要的分塊跟 ppt 的信息提取，要形成摘要保存在一級數據庫中，然後關聯相關文檔」 「您看看要是好的方法就按你的來，我是這麼想的」 「我自己有本地大模型」 畫面重點：該對話討論了一套結合結構化資料庫（儲存項目基本資訊）與非結構化文件（PPT、Word、PDF）的檢索增強生成（RAG）架構，並強調了使用本地大型語言模型進行處理的需求。
我當時第一反應是用 FastGPT 來上傳文件，打造知識庫。 2024 年時我接過不少類似需求，基本都是用 FastGPT 快速搭建的。 然後我找了一位好朋友一起看，仔細分析過後，感覺這件事沒那麼簡單。 ![一則關於企業級知識庫開發需求評估的對話截圖。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/b209b46875e37274.png)
展開畫面重點
圖片為一段對話內容，文字轉錄如下： 「你好，看了一下你這個需求，功能點很多，已經對標了一個企業級的知識庫服務了，並且有很多技術點難度高。當前預算肯定是做不到全部功能的。可以考慮把主要的功能抽一些出來做。首先是文檔解析，這裡涉及到多種文檔的解析，需要明確，是否只解析文字信息，如果圖片信息也要解析返回，複雜度還會增加。其次是檢索方面，每次的檢索到庫是否是固定的，如果涉及到多庫，多源的檢索，複雜度很高。」
知識庫最難的從來不是「搭建」，而是調優。 之前跟這位好朋友交流過知識庫調優這塊，她說她們公司本來想外購一個知識庫系統，但是大廠開價有點高。 然後就自己組了一個六人團隊做知識庫，搞了整整半年，才把回覆準確度調到一個相對滿意的狀態。 ![這是一張關於技術團隊在開發多源文檔解析與檢索系統時，針對開發週期與技術優化過程的對話截圖。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/ec3d2f41a7961c5c.jpg)
展開畫面重點
該圖片為即時通訊軟體的對話紀錄，內容討論了開發某項技術功能的時程與技術細節。對話文字轉錄如下： - 對方：「東西不是我們組做的，他們大概 5 個人力，做了半年，準確率才有效果」 - 我：「這麼久啊🤔」 - 對方：「嗯嗯，多源文檔解析做了一陣」 - 對方：「然後就是檢索調優」 - 對方：「文檔切分」 - 我：「這個確實慢」 - 引用回覆：「然後就是檢索調優」 - 我：「我 24 年的時候也幫人家調優，花不少時間」 - 對方：「他這個還是多源檢索」 對話重點在於討論「多源文檔解析」、「檢索調優」、「文檔切分」以及「多源檢索」等技術實作過程，並提到開發團隊規模（約 5 人）與開發週期（半年）對系統準確率的影響。
我覺得不是他們能力的問題，而是傳統 RAG 的調優本來就是這樣，是黑盒的、比較模糊的，你不知道改了哪裡會造成「按下葫蘆浮起瓢」。 有可能你調低了過濾的 score，獲取的資訊範圍是增大了，但可能又會出現很多雜訊。 更要命的是，這個客戶的需求裡肯定還有一個場景，普通 RAG 方案搭建的知識庫遇上基本都會 GG。 就是「多跳推理」。 舉個例子。假設他的知識庫裡有三份獨立文件： > 文件 1：「2023 年，A 公司全資收購了 B 公司。」 > 文件 2：「張三被任命為 A 公司的 CTO。」 > 文件 3：「2024 年，張三離職，加入了盤古大型語言模型項目。」 使用者問：「收購了 B 公司的企業，其 CTO 後來加入了哪個項目？」 傳統向量檢索或混合檢索（全文 + 向量 + 重排）拿著問題裡的關鍵字去庫裡搜尋，能找到文件 1 和文件 2，但絕對找不到文件 3。 原因很簡單：文件 3 裡根本沒出現「收購」、「B 公司」、「CTO」這幾個詞，字面和語意都毫無關聯，線索在這裡斷了。 最後只能給出：「抱歉，資料中未找到相關內容……」 會議記錄這種場景，這類多跳檢索需求一定是非常多的。 這中間我也想過用 GraphRAG，但我一直都覺得 GraphRAG 太重了： ![此圖展示了《冰與火之歌》角色關係網路圖，透過顏色區分出不同的社交社群，其中 Jon、Robb、Tyrion、Sansa、Daenerys、Arya 與 Bran 為各社群中連接度最高的關鍵核心節點。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/0d996f4a340e085a.png)
展開數據表
項目數值
藍色社群（守夜人與野人）：核心為 Jon，其餘包含 Samwell, Grenn, Eddison, Gilly, Craster, Qhorin, Ygritte, Rattleshirt, Mance, Styr, Orell, Alliser, Dalla, Val, Janos, Karl, Bowen。 紫色社群（臨冬城與奔流城）：核心為 Robb, Catelyn，其餘包含 Brynden, Edmure, Roslin, Lothar, Walder, Hoster, Jeyne, Rickard。 粉色社群（臨冬城幼子與塞外）：核心為 Bran，其餘包含 Hodor, Meera, Jojen, Ramsay, Rickon, Luwin, Nan, Melisandre, Theon。 黃色/橘色社群（君臨與拜拉席恩/蘭尼斯特）：核心為 Tyrion, Sansa, Robert, Tywin, Jaime，其餘包含 Joffrey, Cersei, Renly, Balon, Stannis, Eddard, Loras, Margaery, Myrcella, Tommen, Gregor, Meryn, Ilyn, Bronn, Lancel, Podrick, Kevan, Shae, Oberyn, Ellaria, Doran, Mace, Pycelle, Elia, Varys, Chataya, Amory。 綠色社群（坦格利安與厄索斯）：核心為 Daenerys，其餘包含 Jorah, Drogo, Daario, Irri, Missandei, Aegon, Kraznys, Worm, Rakharo, Viserys, Rhaegar, Barristan, Belwas, Illyrio。 紅色社群（艾莉亞與無旗兄弟會）：核心為 Arya，其餘包含 Gendry, Beric, Thoros, Anguy, Qyburn, Sandor, Olenna, Walton。 棕色社群（龍石島）：核心為 Davos，其餘包含 Shireen, Salladhor, Cressen。
它需要在文件入庫之前，大量呼叫大型語言模型去提取三元組（誰-做了什麼-對誰），然後把整個語料庫的知識圖譜在離線狀態下全部構建好。 光是索引成本，據我了解一個中等規模的資料集就能燒好幾萬塊錢。對於這個客戶的專案，有點殺雞用牛刀，而且圖譜構建好之後，只要有新文件進來，就可能要重新算一遍關係，維護成本極高。 所以我找了一圈，發現了一個前幾天剛開源的新東西：SAG。已經在 GitHub 斬獲 1.3K Star 了。 https://github.com/Zleap-AI/SAG ![這是一張展示名為「SAG」的開源專案在 GitHub 平台上的儲存庫頁面截圖。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/e844ab3073af82ed.jpg)
展開畫面重點
畫面為 GitHub 儲存庫頁面，主要資訊如下： - 專案擁有者：Zleap-AI - 專案名稱：SAG - 狀態：Public（公開） - 統計數據：Watch 0、Fork 34、Starred 1.3k（已標記紅框） - 檔案列表：包含 docs/assets、migrations、scripts、src、test 等資料夾，並顯示各項目的最後更新時間與提交訊息。 - 關於（About）：描述為「An document retrieval project built on SAG」，並附有連結 zleap.com。 - 標籤（Topics）：agent, ai, data-engineering, knowledge-graph, knowledge-base, sag, rag, vector-search, knowledge-graphs, llm, graphrag。 - 頁面導覽列：包含 Code, Issues, Pull requests 1, Actions, Projects, Security and quality, Insights。
我打開論文一看標題： "SQL-Retrieval Augmented Generation with Query-Time Dynamic Hyperedges"--基於查詢時動態超邊的 SQL 檢索增強生成 好傢伙，SQL 我特別熟悉，看到這個思路我一下子就來精神了🤔 SAG 到底是什麼？ SAG 是廣州智躍深空人工智慧科技有限公司 Zleap 提出的一套開源檢索架構。 它的核心思路，簡單來說就是把文件轉成「事項（event）-實體（entity）」索引存進 SQL 關聯式資料庫，查詢時用 SQL 動態組裝關聯關係，代替 GraphRAG 那種離線預構建的靜態知識圖譜。 ![這張圖表展示了一個結合 SQL 資料庫與向量搜尋技術的離線資料處理與線上檢索流程架構。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/70cc54da492ec1a8.jpg)
展開畫面重點
圖表分為兩個主要階段： (1) Upload (offline)： - Corpus（語料庫）經由 Extract（提取）處理。 - 建立 One-to-One Correspondence（一對一對應）：Chunk 1 到 Chunk k 對應 Event 1 到 Event k。 - 建立 Many-to-Many Hyperedge（多對多超邊）：連接多個 Event。 - 最終儲存至 Storage，包含 SQL 與 Vector（向量）資料庫。 (2) Search (online)： - Query（查詢）經由 LLM 處理進行 Entity recall（實體召回），以及 Event recall（事件召回）。 - SQL recall event 與 Similarity score > 0.9 的向量相似度計算共同組成 Event set（事件集）。 - 透過 SQL 進行 Join 操作，結合 Event 與 Entity。 - 進行 Similarity Threshold Filtering（相似度閾值過濾），選出 Top-100 的 Event。 - 透過 LLM 處理 Top-5 的 Chunk，並結合 Embedding 處理的 Top-5 Chunk，最後進行 Concat（串接）輸出 Top-10 的 Chunk。
這句話你可能沒搞懂，我換個更簡單的解釋，就好理解了。 你可以把傳統 RAG 想像成一個圖書館管理員：每次你問問題，比如，你想要醫學相關的書，他就拿著你的關鍵字在書架上找相關的醫學書籍，找到了遞給你。 這個方式在大多數情況下夠用，但如果你問的問題需要從三本書裡各抽一段看似沒有關聯的內容才能拼出答案，他就抓頭了，因為他是靠「字面意思匹配」找書的，沒有能力自動把三本書的線索串起來。 ![FastGPT 的功能架構圖，展示了從知識庫訓練到對話流程的技術處理路徑。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/b9da0e463f7253ff.jpg)
展開畫面重點
該圖表為「FastGPT Functional Architecture」，詳細說明了系統的運作架構： 1. **知識庫訓練流程**： - 包含「知識庫訓練」與「預處理數據」步驟。 - 數據進入「語言模型」區塊，支援的模型包括：Claude、GPT-3.5/GPT-4、文心一言、訊飛星火、通義千問、chatglm/chatglm2。 - 處理方式分為：QA 拆分（產生 QA 問答對）、文本分段（分段內容作為 Q）、手動輸入（檢索內容作為 Q）。 - 處理後的數據會進行「將 Q 向量化」並存入「PostgreSQL」資料庫。 2. **對話流程**： - 從「對話」開始，透過「Flow Controller 調用編排流程，將提問內容向量化」。 - 進入「向量模型」區塊，包含「OpenAI Embedding」與「M3E (Moka Massive Mixed Embedding)」。 - 執行「向量相似度搜索」，並與 PostgreSQL 資料庫進行比對。 - 系統會「根據搜索模式，決定前 n 條，以及處理方式」，並「將搜索到的內容發送給語言模型」。 - 流程中包含「如有上一個問題，也加入搜索範圍」。 3. **其他資訊**： - 網址：https://fastgpt.run
GraphRAG 的做法是在你把書放進圖書館之前，先花大量時間把整個圖書館的所有人名、公司名、事件，提前畫一張巨大的關係圖掛在牆上。 查詢的時候順著關係圖譜找，效果確實很好。但問題是畫這張圖非常耗時耗錢，而且每進來一本新書，就得重新畫。 SAG 走了第三條路：它不畫全域關係圖，而是在你上傳文件的時候，用 AI 把每個文件片段提煉成一張「事項卡片」（記錄發生了什麼事），同時提取出這件事涉及的「實體」（公司名、人名、項目名等），把這些存進一個普通的 SQL 資料庫和向量庫裡。 查詢時，用 SQL 的 JOIN 語句動態把有共同實體的事項拎出來，組成局部關係網，即時串聯多跳線索。 ![這是一張展示「SAG：文檔入庫與用戶提問回答全流程（優化版）」的技術架構流程圖。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/db4d8ef0de9034dd.jpg)
展開畫面重點
該圖表詳細說明了 SAG 系統處理文檔與回答用戶提問的兩個主要階段： 一、文檔入庫（離線）： 1. 接入原始文檔：處理 PDF、網頁、知識庫、業務記錄、消息、日誌等。 2. 解析並切塊：將文檔切分為文本塊（最小處理單元）。 3. LLM 並列抽取：利用大語言模型抽取「事項 Event」與「實體 Entity」。 4. 建立事項-實體關聯：建立事項與實體之間的關聯（如：A公司、B公司、張某、2023年、收購）。 5. 寫入 SQL 與檢索索引：將數據寫入 MySQL，建立實體索引、事項索引、原文索引及向量索引。 二、用戶提問與回答（線上）： 1. 理解用戶問題：例如「收購 B 公司的企業，其 CTO 後來加入了哪個項目？」。 2. 雙路種子召回： - 路徑 A：實體引導的結構化召回（透過實體量召回與 SQL 查詢）。 - 路徑 B：查詢向量直接召回事項（透過向量量召回）。 3. SQL 動態超邊擴展：從種子事項出發，透過 SQL Join 進行擴展，獲取相關的新事項與實體。 4. 候選壓縮與雙路選擇：進行相似度排序（Top 100），並透過 LLM 重排與向量檢索取回相關文本塊。 5. 證據合併並生成回答：進行兩路合併與去重，最終由答案生成模型產出回答（例如：「張某後來加入了 C 項目。」）。 關鍵理解：事項是「完整語義單元」，實體是「連接插頭」，SQL 在提問時把相關事項臨時拼成證據鏈。
比如，用剛才那個例子跑一遍： 知識庫裡有三份文件：文件 1 說「A 公司全資收購了 B 公司」，文件 2 說「張三被任命為 A 公司的 CTO」，文件 3 說「張三離職，加入了盤古大型語言模型項目」。 使用者問：「收購了 B 公司的企業，其 CTO 後來加入了哪個項目？」 SAG 拿到問題，兩件事同時在跑： 一邊用普通 RAG 一樣做向量語意搜尋，找意思最相關的段落； 另一邊從問題裡提取實體「B 公司」、「CTO」，去資料庫裡用 SQL 查哪些事項涉及了這兩個實體，最後命中了文件 1 和文件 2。 到這裡，SAG 做到了普通 RAG 很難做到的一步：掃描已命中的文件 1 和文件 2，從裡面發現了一個新實體「張三」。 這個名字在使用者原始問題裡根本沒出現過，但它是兩份文件之間的連接點。 於是資料庫自動觸發第二輪查詢：「哪些事項涉及了張三」，命中了文件 3。 三份文件全部到位，加上向量搜尋的結果，一起交給大型語言模型拼出最終答案。 普通 RAG 做完向量搜尋就停了，因為找到了文件 1 和文件 2，但不會從裡面挖出「張三」這個新線索繼續追，文件 3 對它來說可能是永遠的盲區。 SAG 在向量搜尋的基礎上多了實體關聯這條鏈，從已經找到的內容裡挖出新線索、接著往下查，讓多跳推理變成一件確定的事，而不是靠運氣。 和 FastGPT 混合檢索有什麼區別？ 其實我看完論文之後還有一個疑問，就是 SAG 和 FastGPT 自帶的混合檢索有啥區別？ ![此圖展示了某知識庫系統的「知識庫搜索配置」介面，提供語義檢索、全文檢索及混合檢索等多種搜索方式設定。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/d3bf0ab641a62067.jpg)
展開畫面重點
畫面為「知識庫搜索配置」設定視窗，包含以下選項與功能： 1. 頂部標籤頁：搜索方式、搜索過濾、問題優化。 2. 搜索方式選項： - 語義檢索：使用向量進行文本相關性查詢。 - 全文檢索：使用傳統的全文檢索，適合查找一些關鍵詞和主謂語特殊的數據。 - 混合檢索（目前選中）：使用向量檢索與全文檢索的綜合結果返回，使用 RRF 算法進行排序。下方設有滑桿可調整「語義檢索」與「全文檢索」的權重比例（目前設定為 0.5 : 0.5）。 3. 其他配置： - 結果重排：開關已開啟。 - 重排權重：設為 0.5。 - 重排模型：顯示為「gte-rerank-v2」。 4. 底部按鈕：關閉、完成。
FastGPT 裡的「全文檢索 + 向量檢索 + 重排序」，其實就是目前最成熟的工業標準 RAG 方案，它本身並沒有什麼問題，對絕大多數日常知識庫問答足夠好。 SAG 和它的區別，主要也是在 SQL 部分，對應具體的能力就是 SAG「多跳推理」更強。 日常的單文件問答，FastGPT 完全夠用，速度也快。 但涉及需要跨多個文件邏輯串聯的問題，FastGPT（本質上是扁平的相似度匹配）就觸到了物理上限，而 SAG 靠 SQL 結構兜底。 除此之外，SAG 還有幾個讓我覺得有意思的地方： * **可解釋性：** 傳統 RAG 檢索問題排查是黑盒，你可能只知道「相似度不夠」，要不是分塊沒弄好，要不是 Score 設定的有問題，大部分時候是去調試，但不知道具體是哪個環節出了問題。 SAG 的檢索鏈條是完全可追溯的 SQL 呼叫記錄：大型語言模型提取了什麼實體 -> 同義詞擴展命中了哪些 -> SQL 走通了哪條路徑。 哪裡斷了，工程師一眼就能定位去修。 這一條對調優來說是革命性的。傳統 RAG 調優有點像「煉丹」，你改切塊大小、改向量模型、改重排閾值，改完一個，可能又會出現另一個問題，永遠不知道瓶頸在哪。 SAG 的調優更像程式設計師們熟悉的「找 Bug 和修 Bug」，有問題，看日誌，找具體的問題點，能砍掉團隊 80% 像無頭蒼蠅一樣瞎摸索的時間。 * **入庫邏輯的轉變：** 傳統 RAG 的調優大量時間花在切塊、參數上：按 500 字切還是 1000 字一塊切？重疊的部分要不要？如果切塊切壞了，把「張三負責 A 項目」和「500 萬預算」切成兩段，線索就斷了。 SAG 把這個問題前移了：在文件入庫之前，用 AI 把內容提煉成完整的「事項卡片」，一件事就是一張卡，不用關心切塊的問題。入庫的資料是完整的，後續檢索準確度自然就會更高。 * **SAG 不挑模型：** 論文裡有一個很有意思的消融實驗： 研究員故意把 SAG 底層的向量模型換成了一個很普通的開源弱模型，結果其他高級 RAG 方案的準確度暴跌了將近 10%，SAG 幾乎沒什麼變化（依然穩定在 80% 左右）。 原因就在於：SAG 找線索的主幹力量是確定的 SQL 實體關聯，不是模糊的向量距離，換個弱模型不太能影響 SQL 找東西。 這對有行業黑話的企業場景更加重要：因為通常向量模型不認識你們公司內部的一些「黑話」，但只要 SQL 裡存了這個實體，就能查出來，不需要專門微調向量模型～ SAG 到底行不行？ Zleap 在三個多跳推理標準資料集（HotpotQA、2WikiMultiHop、MuSiQue）上跑了評測。 其中在 MuSiQue 上的 Recall@5 達到 80.04%，比 HippoRAG 2 的 65.13% 高出約 15 個百分點。 MuSiQue 是這三個測試集裡最難的，要求最多 4 跳的組合推理，且不允許跳過中間步驟，是公認的 RAG 裡面的「地獄難度」測試集。 ![在相同配置下，SAG 在各項指標上皆明顯領先 HippoRAG 2，其中在最難數據集 MuSiQue 的 Recall@2 提升幅度最為顯著，達到了 +29.3%。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/f7a4d4de259ef1f1.jpg)
展開數據表（1）Average Recall
Recall@2Recall@5
SAG79.30%88.18%
Hippo68.14%83.28%
Improvement+16.4%+5.9%
展開數據表（2）MuSiQue
Recall@2Recall@5
SAG64.05%80.04%
Hippo49.52%65.13%
Improvement+29.3%+22.9%
而 HippoRAG 2，是目前比較推崇的方案之一，靈感來自神經科學裡的「海馬體索引理論」，原理是把知識圖譜和 Personalized PageRank 演算法結合起來做多跳推理。簡單來說就是一種模仿人腦海馬體的 AI 檢索技術。 跟 SAG 相比，HippoRAG 2 在構建階段也需要離線預先建好知識圖譜，依賴圖結構的靜態全域關係；而 SAG 把圖的構建時機後推到查詢時，會用 SQL 動態啟用，避開了全域圖重建和維護的開銷。 PS：SQL 動態啟用就是 SAG 把圖的構建時機後推到了查詢時。也就是你提問的那一刻，SAG 才透過 SQL 把事項之間的關聯關係查詢出來，不是提前把全圖建好等著你來用。 另外，目前 SAG 已經在約 5 億條資料規模的生產環境裡完成了部署，線上檢索延遲保持在秒級以內。而一般的 RAG 在資料量上了百萬就 OOM（記憶體溢出）或者速度拉垮。這次，SAG 直接刷新了 SOTA。 ![這是一個名為「zlee」的搜尋介面，提供針對維基百科進行精確搜尋的功能。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/0ddd4bcfe359f814.jpg)
展開畫面重點
畫面中央顯示一個搜尋框，上方標題為「維基百科搜索」，並帶有「zlee」的標誌。搜尋框內輸入的文字為「蒂爾娜·戴維森隨美國隊贏得哪些冠軍？」。搜尋框左下方有「精確模式」的下拉選單選項，右下方則有一個黃色的箭頭按鈕。背景呈現淺色的網狀連結圖形，散佈著如「KADOKAWA」、「科學」、「政治」、「社會」、「Wiki」等標籤。
也可以本地 docker-compose 部署（我用 codex 幫我一鍵完成了部署）： ![一張顯示 AI 助手協助使用者完成 Docker 與 Docker Compose 專案部署的對話截圖。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/d371ac9e261f2a70.jpg)
展開畫面重點
圖片為一個 AI 對話介面的截圖，內容關於協助部署名為「Zleap-AI/SAG」的開源專案。 對話內容轉錄如下： - 標題：Docker部署SAG項目 - 使用者輸入：「Zleap-AI/SAG，幫我把這個開源項目用docker的方式部署起來」 - AI 回應：「不是，我是讓你用docker-compose的方式」 - AI 回應：「已經用 docker-compose 部署起來了，服務是 healthy。訪問地址：http://localhost:4173。我補了這些部署文件：Dockerfile、docker-compose.yml、$ docker-entrypoint.sh、.dockerignore。當前容器狀態：」 - 程式碼區塊內容： sag_lite_app healthy 0.0.0.0:4173->4173/tcp sag_lite_postgres healthy 0.0.0.0:55432->5432/tcp 畫面重點在於 AI 成功根據使用者的修正指令，使用 `docker-compose` 部署了包含應用程式與 PostgreSQL 資料庫的服務，並確認容器狀態為「healthy」。
我讓 codex 幫我造了一些資料丟進去，測試了一些問題，命中率比我預期的高～ ![一個 AI 對話介面，展示了針對「青川政務服務智能問答庫」的技術規格檢索結果。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/5d1a2033e2fda872.jpg)
展開畫面重點
畫面為一個 AI 對話視窗，左側為對話記錄，右側為「搜尋過程」面板。 對話內容如下： - 標題：「青川政務服務智能問答庫，部署在哪裡，」 - 模型名稱：「qwen3.6-flash · 76acc55b」 - 用戶提問：「青川政務服務智能問答庫，部署在哪裡，用的什麼本地大模型和向量模型？」 - 助手回答： 「根據檢索到的項目文檔信息： - 部署位置：政務雲本地專區 - 本地大模型：DeepSeek R1 Distill 32B - 向量模型：gte large zh 以上信息均項目於檢索到的項目文檔中的“技術約束”章節。」 - 引用原文：1, 2, 3, 4, 5 右側「搜尋過程」面板顯示： - 標題：「搜尋過程」、「搜尋鏈路與模型原始調用」 - 標籤：「搜尋過程」、「原始日誌」 - 步驟 1：「MCP 搜尋語句」、「完成」 - 查詢內容：「query: 青川政務服務智能問答庫 部署 本地大模型 向量模型」、「耗時: 2771 毫秒」 - JSON 數據： { "query": "青川政務服務智能問答庫 部署 本地大模型 向量模型", "strategy": "multi", "returnTrace": true }
回到這個客戶的需求：落地方案怎麼搞？ 我覺得 SAG 目前主要還是一套檢索架構。 如果你想純按 SAG 的思路從零做一個完整的知識庫產品，還是需要自己搭前端、做權限管理、寫文件解析引擎、搞部署維運，工程量很大，對一個預算有限的專案來說，爛尾風險很高。 而 FastGPT，對話介面完善、權限管理成熟、接微信/飛書都很快，能瞬間滿足客戶對「可用性」的要求。 所以對於這個客戶的專案，可以兩者結合： 在成熟的系統（如 FastGPT）之上，使用 SAG 作為知識庫的實現方案。 既能複用 FastGPT 的工程成熟度，同時用 SAG 的思想解決了「切塊破碎」和「結構化檢索」的問題。後續的調優也更加的方便快捷。 目前最簡單的方式應該是把 SAG 作為 MCP 工具，絲滑地接入 FastGPT。 ![此圖展示了某系統的 MCP（Model Context Protocol）配置介面，包含項目綁定資訊與 JSON 設定範例。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/8ca74eef7bf813d1.jpg)
展開畫面重點
畫面顯示一個名為「MCP」的設定頁面，主要內容如下： 1. 頂部標籤頁：對話、文檔、圖譜、MCP（當前選中）。 2. 當前項目：顯示「小秘書項目演示庫 2026-06-21T05-27-58 / 28fc5a72-62a1-4135-8b66-7476359bf5a2」。 3. 項目綁定說明：MCP server 啟動時讀取 SAG_MCP_SOURCE_ID，所有工具默認只訪問這個項目。 4. 工具超時：300000 毫秒。 5. JSON 配置區塊：提供了一段 JSON 格式的設定，其中環境變數 `SAG_MCP_SOURCE_ID` 被設定為 `__SAG_PROJECT_ID__`，並透過紅色箭頭指向當前項目 ID。 6. 可用工具列表： - sag_ingest_document：導入文檔並執行切片、事件抽取、實體抽取和向量化。 - sag_search：對 MCP server 配置綁定的項目執行 SAG 多路檢索，並返回內部檢索 trace。支持 searchMode=fast 使用實體全文匹配 + qwen3-rerank 極速檢索。 畫面重點在於展示如何透過 JSON 配置將 MCP Server 與特定項目 ID 進行綁定，並列出了兩個可用的工具及其功能描述。
當然，如果 FastGPT 或其他主流知識庫系統哪天把 SAG 的架構思想絲滑地融進官方工作流，那更好，拿來即用就行。 *PS：也可以透過 MCP，絲滑接入 Codex、Claude code 等本地 Agent 使用～* --- 「最後」 RAG 這幾年的演化路徑從最早的純向量檢索，到混合檢索，到 GraphRAG 引入知識圖譜，再到現在 SAG 把知識圖譜的構建時機從「離線」挪到「查詢時」，用 SQL 關聯式資料庫作為動態組織層。 每一步看起來都是在加複雜度，但感覺 SAG 這一步有點返璞歸真的意思。 SQL 關聯式資料庫大家用了幾十年，穩定、可解釋、可維護，把它拉進檢索架構，工程落地的難度反而降低了不少。 而且對於很多企業來說，開發團隊可能會天天寫 SQL，極熟，接起來也比較絲滑。 創新不一定是發明全新的東西，有時候是把已經被驗證過的工具，重新組合用在對的地方（站在巨人的肩膀上）。 然後我覺得 SAG 將成為 Agent 的資料底座： 因為 Agent 很多時候就是在完成多跳推理工作，先查 A，用 A 的結論決定去查 B，每一步輸出都是下一步的輸入。這正好也是 SAG 解決的問題。 傳統 RAG 給 Agent 的是「大概相關的幾段內容」，SAG 給的是更確定的結構化的事項和實體，拿到就能直接推理，不用再從相似的文字裡自己挖掘，出幻覺的機率也低很多。 並且有了精確且高效的查詢，能更好地發揮本地小模型的優勢。 這種私有知識庫的資料底座設計好了，本地 Agent 的能力也會更上一層樓。 我是袋鼠帝，一個致力於幫你把 AI 變成生產力的部落客。我們下期見～ ## 標籤 RAG, Agent, 教學資源