GBrain — 不丟連結給你、直接合成答案的開源 AI 第二大腦

先別管它能拿來做什麼。先看你丟一段筆記進去的那一刻，它背地裡做了哪件事。

你寫了一行字進去：「Alice 在 Acme 當 CTO，這家是 Sequoia 投的。」一般的筆記工具到這裡就結束了——它存下這串文字，等你哪天搜尋「Alice」再把這行吐回來。GBrain 不一樣。在你按下儲存的同一瞬間，它把這句話拆成三個節點（Alice、Acme、Sequoia）跟兩條有型別的關係線（Alice works_at Acme、Sequoia invested_in Acme），接到它腦袋裡那張一直在長大的網上。下次你問「Alice 背後有哪些投資人」，它不用再去翻那行字——它沿著線走兩步就到了。

關鍵在這裡：這一步抽節點、連關係，完全沒呼叫任何大模型。 純 regex 加一組啟發式規則做掉的。零 token、零成本、零延遲。

你以為讓檢索變強的是模型，其實不是

這就是整顆大腦最反直覺的地方，也是我覺得最值得抄走的設計判斷。

2026 年的反射動作是這樣的：檢索不夠準？換更大的 embedding。答案不夠好？接更貴的模型。什麼問題都先想「丟給 LLM」。GBrain 的 benchmark 把這個直覺戳破了——光是把那張純規則織出來的知識圖譜接進檢索管線，P@5（前五筆結果的精準度）就從只靠向量搜尋的大約 18%，跳到 49.1%。多出來的 31 個百分點，沒有一分是靠更強的模型換來的，全是那層不花錢的關係網貢獻的。

換句話說，真正讓它「會回答關聯型問題」的本事，藏在最便宜的那一層。這件事一旦想通，你看很多 AI 產品的眼光會變——它們堆了一堆貴鬆鬆的模型呼叫，但真正缺的，往往是一層願意動手把結構先抽出來的笨功夫。

跟你做過的 RAG 差在哪

如果你串過 RAG，這套流程閉著眼睛都背得出來：query 進來 → 向量搜尋撈出最像的幾段 → 塞進 prompt → 模型生成。它只會做一件事——找文字上相似的東西。

問題是，很多真正想問的問題，跟「相似」沒關係。「Alice 投資過哪幾家、後來這些公司誰還活著」——這不是找相似段落能解的，這是要沿著關係一路串下去的。純向量搜尋碰到這種就抓瞎，因為「投資」「離職」「創辦」這些動作不是寫在某一段文字裡等你撈，而是散在十幾份筆記之間的連線。

打個比方。傳統 RAG 像 Google 搜尋，你丟關鍵字，它回你十條藍色連結，剩下自己讀。GBrain 比較像一個讀完你所有筆記、還順手把人脈關係圖畫好的助理——你問問題它直接給答案，答不出來它也會老實跟你講「這段我不知道」。

那個「老實講不知道」也是它故意做的功能，叫 gap analysis。一般 RAG 撈不到資料會硬掰一個看似合理的答案出來，這在做決策時是會出人命的。GBrain 會明說「4/22 之後就沒這個人的紀錄了」，把知識的邊界畫給你看。能告訴你「我不知道什麼」的系統，比假裝什麼都知道的系統可信得多。

底層管線：四段檢索 + 一次重排

把答案合成出來之前，一個 query 會走過這幾關：

query
  ├─ 1. 向量搜尋    (pgvector 上的 HNSW，找語意相似)
  ├─ 2. BM25 關鍵字 (找精確的名稱／片語／程式識別字)
  ├─ 3. RRF 融合     (把上面兩種排名合併，不用手調全域權重)
  └─ 4. 圖譜走訪    (沿著有型別的關係線走，回答關聯型問題)
        ↓
  ZeroEntropy reranker  (cross-encoder 重排，p50 約 150ms)
        ↓
  合成答案 + 引用來源 + 知識缺口

值得停一下看的是第三步那個 RRF（Reciprocal Rank Fusion）。向量搜尋擅長抓語意、BM25 擅長抓精確字串，你要嘛調權重把兩邊揉在一起——那是個沒完沒了的玄學——要嘛用 RRF：它不管兩邊的分數，只看各自的排名，用排名倒數加起來重排。簡單、不用調參、效果還穩。又是一個「用便宜的確定性方法，取代昂貴的調校」的選擇。

連「判斷你這個問題是在問人、問時間、還是問事件」這步，GBrain 都是用確定性規則分類的，不花一次模型呼叫。整條管線的設計哲學一致到有點固執：能不用 LLM 的地方，一概不用。

資料是你的，不是它的

架構上還有一個我很喜歡的決定：你的資料真正的家是一個 Git repo，裡面就是一堆 markdown 檔。Postgres 只是從那個 repo 同步過來、專門加速查詢的一層。

這意味著什麼？你在 Git 裡刪一個檔，資料庫跟著軟刪除；你想搬家、想自己讀、想用別的工具改，全都行，因為底層就是看得到改得動的純文字。資料主權完完整整在你手上，沒有被鎖進某個專有格式的資料庫裡。對一個要塞進你所有筆記、人脈、會議紀錄的東西來說，這個信任基礎比什麼功能都重要。

跑起來也不囉嗦。個人用的 brain 直接用 PGLite——把 Postgres 17 編譯成 WebAssembly 跑在你本機，不用裝 server、不用 Docker，gbrain init --pglite 兩秒搞定。規模大到企業共享，再換成 Postgres 加 pgvector，但兩種引擎實作的是同一個介面，個人版練熟了直接搬。

掛上去之後

它對外是 MCP server，一行就接進 Claude Code：

1	claude mcp add gbrain -- gbrain serve

Cursor、Windsurf 或任何吃 stdio 的 MCP client，設定也就 { "command": "gbrain", "args": ["serve"] } 這麼長。要接 Claude Desktop 或 ChatGPT 這種只吃 remote MCP 的，加個 --http 開 HTTP 模式，內建 OAuth 2.1、權限分級、rate limiting，拿來當團隊共享後端夠用。

掛上去後它會暴露 130 幾個 MCP tools，乍看嚇人，但分群之後其實好懂。最能代表它精神的是 think——它不只回你幾段相關片段，而是跨頁合成一段帶引用來源的散文式答案，最後再補一段知識缺口。另外那組 code_def、code_callers、code_blast 也很實用，剛接手一份陌生 codebase 時，追一個函式的定義、誰呼叫它、改了會炸到哪些地方，比自己 grep 半天快。

要不要現在就上

說回現實面。這是個還在快速演進的早期專案，版本還停在 v0.41.x，GitHub 上開著七百多個 issue，社群 PR 是一波一波批次合併的。功能很猛，但別期待它像成熟產品一樣穩，升級前先掃一眼 release notes。成本也得先想清楚——它有 conservative / balanced / tokenmax 三種搜尋模式，最貴跟最便宜差到 25 倍，裝完第一件事就是先決定要用哪一檔。

還有幾個會讓人卡住的小地方：預設分支是 master 不是 main，你照網路上習慣抓 main 路徑的 raw README 會 404；個人 brain 最低要 2GB RAM；capture 功能預設是關的。

回到開頭那句話。GBrain 真正教我的，不是「又一個筆記工具」，而是那個藏在最底層、完全沒用到 LLM 卻撐起一半精準度的知識圖譜。下次你想替某個檢索問題接上更大的模型之前，值得先問一句：我缺的真的是更聰明的模型，還是我根本還沒把資料裡的結構，老老實實抽出來連成一張網？