公司大腦 (2/4)：事實記憶，不能只是企業版搜尋引擎 (Company Brain: Factual Memory)

原始來源與檔名：20260512_2026-05-05T093832+0800-Company Brain, Part 2 Factual Memory.md

來源：[[@ashwingop]] (Sentra Founder) / X (Twitter) — 2026-05-01 原始檔名：2026-05-05T093832+0800-Company Brain, Part 2 Factual Memory.md

NAPKIN | 餐巾紙

餐巾紙公式

Bad Factual Memory = Central Wiki / RAG over everything = Wait for queries + List of links. Good Factual Memory = Semantic File System + Provenance + Proactive Surfacing + Personalization. Artifact Value = Content + Relationships (Account -> Ticket -> Decision -> Owner).

公司大腦的底層是「事實記憶 (Factual Memory)」。很多人誤以為這只是把所有內部文件做成 RAG (檢索增強生成)，然後給員工一個對話框。作者警告，這樣做註定失敗，因為員工的工作場景分散在 Slack、GitHub 和各種工具中，不會主動去中央資料庫查詢。真正有效的事實記憶必須是「語義檔案系統」：它不僅知道文件內容，還知道文件的來源、權限、過期與否，並且能根據使用者的身份（CEO 或工程師）主動在工作當下推送關聯上下文。

一句話

這是《公司大腦》系列第二篇。探討如何建構正確的「事實記憶」。作者指出，單純的企業搜尋 (Enterprise Search) 只是把文字碎片撈出來，但缺乏權限控制與版本朔源。真正的公司大腦必須是一個「語義檔案系統 (Semantic File System)」，保存數據與數據之間的關聯圖譜。更重要的是，它不該是被動等待查詢的機器，而應該主動參與工作——例如當你在寫一份報價單時，它主動跳出來提示你該客戶先前的客訴紀錄與特殊折扣承諾。

餐巾紙草圖

[ Reactive Search vs Proactive Memory ]

Enterprise Search (Reactive):
User types "Onboarding blockers".
System returns 10 disjointed Google Doc links.

Company Brain (Proactive & Personalized):
CEO types "Onboarding blockers".
System: "Here is the strategy impact and customer churn risk."
IC types "Onboarding blockers".
System: "Here is the broken API spec and who owns the fix."

ROUND 1: SKELETON | 骨架掃描

“這篇文章在說什麼”

定義事實記憶: 不是共享硬碟或 Wiki，而是公司回答「發生了什麼、來源在哪、誰負責、何時改變」的能力。
中央儲存庫的失敗: 人們不會在 Repository 裡工作。記憶系統必須從個人工作流（Slack, Email, Docs）邊緣向外生長，自然湧現成團隊記憶。
個體邊界與歸屬 (Provenance): 系統必須區分「私人草稿」與「官方決策」，並保有明確的權限與出處追蹤（誰修改的？過期了嗎？）。
超越單純的 RAG: 僅靠語義相似度擷取片段是不夠的。需要建立「語義檔案系統」，保留實體間的關係（客訴 -> 工單 -> 產品領域 -> 負責人）。
主動參與 (Proactive): 記憶不能只躲在搜尋框裡。它應該在你開啟一份文件或指派一個工單時，主動跳出相關的歷史防呆提示。
千人千面 (Personalization): 同一個問題，給工程師看的是實作細節與 Blockers，給 CEO 看的是戰略影響與客戶輪廓。

ROUND 2: DISSECTION | 血肉解剖

“憑什麼這麼說”

核心論證鏈

工作習慣不可逆: 強迫員工去更新 Wiki 注定失敗，因為那違背了人類最小阻力路徑。真正的系統必須能默默「監聽」現有工具（Slack、Jira），讓記憶在日常交流中被動產生（Emergence）。
信任源自於溯源 (Provenance): 大語言模型最大的缺點就是一本正經地胡說八道。在企業場景中，「這句話是誰在什麼時候說的」往往比「這句話是什麼」更重要。沒有溯源機制的事實記憶，無法被用於正式的商業決策。

關鍵證據

實例對比：當被問到「計費整合怎麼了？」時，一個劣質系統給出十個文件連結；而好的系統會說：「這是最新的規格，這是以前卡住的工單，這是目前的負責人。」這種 Synthesis (合成) 能力才是記憶的價值。

邊界條件

「主動推送記憶」與「職場監控 (Surveillance)」只有一線之隔。如果系統不斷打斷使用者的工作，或者讓員工覺得自己的私下閒聊被 AI 記錄並向上呈報，將會引發嚴重的企業文化反彈與信任危機。

ROUND 3: SOUL | 靈魂提取

“還能怎么用”

知識連結: 此文所倡導的 Semantic File System 與 Graph 結構，完全呼應了《Build Agents that never forget》中 Cognee 引擎的設計理念（圖資料庫與向量庫的結合，注重 Provenance）。兩篇文章在技術底層邏輯上達成了驚人的一致。
深層洞見: “A knowledge base waits. Memory participates.” 知識庫是被動的字典，記憶是主動的神經反射。當你的手碰到熱水壺時，你的記憶不會等你輸入搜尋指令，它會立刻讓你的手縮回來。企業工具也該如此。
行動呼籲: 檢視你們公司的內部問答機器人（如果有建置的話）。如果在回答中無法提供來源連結 (Source)，或無法明確區分這份文件的時效性 (是否已經過期)，請立刻推動升級，因為這個機器人正在用過時的假記憶污染團隊決策。