公司大腦真正缺的是檢索層¶

「記憶只是原料，檢索才是真正的操作層。」——Eric Siu

📌 核心論點¶

公司大腦的瓶頸不是記憶不夠，而是 Retrieval（檢索）沒做好。多數人建 AI 大腦的第一個動作是「餵更多資料」，結果只建了一個儲藏室，不是大腦。

╔══════════════════════════════════════════════╗
║          常見誤區 vs 正確思路                   ║
╠══════════════════════════════════════════════╣
║  ❌ 更多資料 → 更聰明的 AI                    ║
║  ✅ 更好的檢索 → 更精準的 AI                   ║
╠══════════════════════════════════════════════╣
║  記憶（Memory）  = 原料                        ║
║  檢索（Retrieval） = 操作層                     ║
╚══════════════════════════════════════════════╝

記憶 vs 檢索：本質差異¶

維度	記憶（Memory）	檢索（Retrieval）
角色	儲存原料	按需調度
增長方式	線性堆積	結構化提煉
成本	Context Window 膨脹	計算與索引設計
效果	資訊多≠用得上	精準匹配當前任務
失敗模式	噪音淹沒信號	檢索不到或檢索錯

🧠 公司大腦散落在哪裡¶

公司的大腦散落在 Slack、Gong 通話記錄、HubSpot CRM，還有某個今天請假的人身上。真正的優勢不是知識量，而是坐在這堆 Context（語境）和實際工作之間的那層 Intelligence（智慧）。

這對一人工作室也成立——你的素材也散在筆記軟體、聊天記錄和自己的記憶裡，差別只是規模。

公司知識分佈示意
─────────────────────────────────────────
  Slack          ─→ 非正式決策、即時溝通
  Gong 記錄      ─→ 客戶對話、反對意見
  HubSpot CRM    ─→ 交易數據、客戶資料
  SOP 文件       ─→ 流程規範
  週報           ─→ 進度摘要
  ⚡ 某個請假的人 ─→ tacit knowledge
─────────────────────────────────────────
        ↓
  [ Intelligence Layer ] ← 缺的這層
        ↓
     實際任務輸出

不同規模的知識散落對比¶

企業規模	知識散落點	共通問題
大型公司	Slack / CRM / 通話記錄 / SOP / 週報	部門牆阻斷 context 流動
中型團隊	Notion / Drive / 口頭傳達	同步依賴會議與人際網絡
一人工作室	筆記軟體 / 聊天記錄 / 自己的記憶	全靠個人記憶做 routing

❌ 「給 AI 更多記憶」的失敗案例¶

Single Grain 一開始的做法：給每個 Agent 更多 Context，存筆記、通話逐字稿。

有效三週後撞牆
持久記憶檔案吃掉約 40% 的 Context Window（自述數字）
Agent 資訊變多，但不一定拉到對的資訊
人類變成了 Router

壞迴圈示意¶

通話逐字稿 ──→ 隨手筆記 ──→ 靠人類記得 ──→ 下個 Agent 冷啟動
     ↑                                              │
     └────────────── 人類再解釋一遍 ←─────────────────┘

結果：人類 = Router，Agent = 被動執行者

持久記憶膨脹的代價¶

Context Window 分配（失敗案例）

┌──────────────────────────────────────────────────────┐
│████████████████████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░│
│◄──── 持久記憶 ~40% ────►◄──── 可用推理空間 ~60% ────►│
└──────────────────────────────────────────────────────┘

問題：記憶越多 → 推理空間越小 → 輸出品質下降

最佳實踐：不要把所有記憶都塞進 Context Window，用 Retrieval 層按需調取相關片段。

♻️ 數據回收：一通電話變六種東西¶

規模數字（自述）： - 500K+ 持久記憶 Token - 90+ 每日排程任務 - 數千通 Sales Call - 2,862 通 Gong 通話逐字稿被轉成可操作 Playbook - 某次匯入：15 通電話 → 390 條 Insight、470 條 Fact、125 個 Framework

一通電話的六種回收用途¶

                    一通 Sales Call
                          │
          ┌───────┬───────┼───────┬───────┬───────┐
          ▼       ▼       ▼       ▼       ▼       ▼
       Insight   Fact  Framework Playbook  SOP   風險
        洞察     事實     框架     操作手冊  更新   訊號

例如：客戶說「預算 Q3 才撥下來」
  → Insight: 客戶決策週期與財年綁定
  → Fact:   該客戶預算確認時間為 Q3
  → Framework: 決策週期對齊框架
  → Playbook: 預算延遲跟進步驟
  → SOP 更新: 報價流程加入預算時程確認
  → 風險訊號: Q3 前不應預期成交

增強對比：有回收 vs 無回收¶

階段	無回收系統	有回收系統
通話結束	記憶留在腦中或聊天記錄	自動拆解為六種結構化資產
下次類似情境	從頭摸索或翻聊天紀錄	Agent 即時調用相關 Playbook
知識累積	線性（一通 = 一通）	指數（一通 = 六種可複用資產）
離職風險	人走知識走	知識沉澱在系統中

🏗️ 五層架構¶

╔═══════════════════════════════════════════════════════╗
║  Layer 5  Feedback（回饋迴圈）                        ║
║  ───────────────────────────────────────────────────  ║
║  Layer 4  Permission（權限控制）                       ║
║  ───────────────────────────────────────────────────  ║
║  Layer 3  Source Truth（來源真相）                     ║
║  ───────────────────────────────────────────────────  ║
║  Layer 2  Retrieval（檢索）  ← 多數人死在這層          ║
║  ───────────────────────────────────────────────────  ║
║  Layer 1  Capture（擷取）                             ║
╚═══════════════════════════════════════════════════════╝

Layer 1：Capture（擷取）¶

錄會議、轉逐字稿、存 Slack、向量資料庫。這只是儲藏室，不是大腦。

原料不會自己排優先序
不知道哪條 Fact 過期、哪條敏感
兩份文件打架時不知道聽誰的

⚠️ 常見陷阱：把 Capture 當成全部，以為有了向量資料庫就等於有了「大腦」。實際上這只是最底層的基础设施（Infrastructure）。

Layer 2：Retrieval（檢索）⭐ 核心層¶

Agent 不需要公司全部歷史，只需要眼前任務真正用到的幾塊 Context。

範例——寫開發信時需要的 Context： - ICP（Ideal Customer Profile，理想客戶畫像） - Offer（產品方案） - 常見反對意見 - 過往活動成效 - 品牌語氣 - 當前活動目標

很多 AI 系統死在這層：Demo 聰明（人工餵 Context），正式環境崩（沒有檢索層）。

Retrieval 層的決策邏輯

任務：寫開發信
  │
  ├─ 需要什麼？→ ICP + Offer + 反對意見 + 品牌語氣
  │
  ├─ 從哪裡拉？→ 向量 DB + 結構化 KB + 當前活動配置
  │
  ├─ 拉多少？  → 只拉相關度 Top-K，不拉全量
  │
  └─ 怎麼驗？  → 輸出是否引用了正確來源、語氣是否一致

最佳實踐：Retrieval 的品質決定了整個 AI 系統的上限。投資在這裡的 ROI 遠高於投資在更多資料上。

Layer 3：Source Truth（來源真相）¶

同一事多個來源衝突：Sales Call、CRM、Slack 更正、舊 SOP、週報、創辦人語音——聽誰的？

不回答這題，Agent 變成「格式更好的自信騙子」。

Single Grain 把來源當營運設計問題：

來源類型	定位	範例
即時真相	最優先，覆蓋一切	CRM 中最新的成交狀態
歷史 Context	參考用，不覆蓋即時	上季的活動成效數據
靈感素材	僅供參考，不當事實	創辦人隨口說的想法
禁止公開	不應出現在對外內容	客戶敏感資訊

Layer 4：Permission（權限）¶

每個 Agent 都能看到所有東西 → 情報危險。需要 Workflow 級別的權限。

權限矩陣示例

              CRM數據  HR記錄  財務報表  客戶對話  內部策略
─────────────────────────────────────────────────────────
Sales Agent    ✅      ❌      ❌       ✅        ✅
Marketing      ✅      ❌      ❌       ❌        ✅
Content Agent  ❌      ❌      ❌       ✅        ❌
HR Agent       ❌      ✅      ✅       ❌        ❌
Finance Agent  ✅      ✅      ✅       ❌        ❌

代理商與服務業特別注意：客戶資料、內部策略、潛在客戶、財務數據全擠在一起，沒有權限分層就是災難。

Layer 5：Feedback（回饋迴圈）¶

每次人類糾正 Agent，該糾正都該變成未來的行為。

人類糾正 → 規則更新 → 系統行為改變
    │
    ├─ 語氣太硬     → 語氣規則更新
    ├─ 引用不安全   → 來源規則更新
    └─ 漏掉風險訊號 → Pipeline 掃描更新

沒有回饋迴圈 = babysit 軟體（每次都要手動介入）
有了回饋迴圈 = 每次糾正 = 整套系統的訓練

五層架構總覽對比¶

層級	功能	缺失後果	建設優先級
Capture	收集原料	無資料可用	高（基礎）
Retrieval	按需調度	Agent 用不到對的資訊	最高
Source Truth	解決衝突	Agent 成為自信騙子	中高
Permission	權限分層	情報洩漏風險	中
Feedback	持續進化	永遠需要 babysit	中（可漸進）

❓ 自動化前先問的六個問題¶

挑一個浪費時間的固定流程（週報、Pipeline Review、內容草稿、業務跟進、客戶 Onboarding、寫提案），然後問：

╔══════════════════════════════════════════════════════════╗
║                                                          ║
║   Q1 ── 輸入是什麼？（數據源在哪）                        ║
║   Q2 ── 輸出是什麼？（產出長什麼樣）                      ║
║   Q3 ── 花多少時間？（基線）                              ║
║   Q4 ── 人類判斷點在哪？（不能自動化的部分）               ║
║   Q5 ── 出錯怎麼處理？（容錯機制）                        ║
║   Q6 ── 修正怎麼變規則？（複利迴圈）  ← 最關鍵            ║
║                                                          ║
╚══════════════════════════════════════════════════════════╝

如果答不出這六題，還沒準備好自動化，硬上只會「把混亂跑得更快」。

以「週報生成」為例的六題審計¶

問題	回答範例
Q1 輸入	Slack 本週對話摘要、Jira 進度、GitHub commits
Q2 輸出	按專案分類的 Markdown 週報，含進度 / 阻礙 / 下週計畫
Q3 基線	每週約 45 分鐘手動整理
Q4 人類判斷	確認哪些阻礙需要升級、哪些成就值得強調
Q5 容錯	人工審核後發送，錯誤可修正再發
Q6 複利	「這類風險不該出現在對外週報」→ 更新篩選規則

報告場景的效果對比¶

舊流程：
  拉資料 25min ──→ 整理跟進 數小時 ──→ 完成
  │                                        │
  └──────── Decision Latency：數小時 ───────┘

新流程（有對的 Context + Retrieval）：
  自動檢索 ──→ 60 秒內回來
  │
  └──────── Decision Latency：~1 分鐘

更大的贏 = Decision Latency 變短

決策延遲（Decision Latency）是很多組織的隱形成本。自動化的真正價值不只是省時間，而是讓決策速度跟上資訊速度。

⚖️ 批判性評估¶

認同的部分¶

✅ Retrieval > Memory 的觀念反轉——切中要害
✅ 六個審計問題——尤其第 6 題「一次修正怎麼變成規則」是大多數人忽略的
✅ 五層架構提供了可操作的思考框架

需要注意的部分¶

⚠️ Eric Siu 有很強商業動機，推自家產品 Single Brain
⚠️ 所有營運數字都是單方陳述，無第三方驗證
⚠️ 肯定觀念 ≠ 背書數字或產品

信息可信度速查¶

                觀念框架        具體數據        產品推薦
              ──────────    ──────────    ──────────
可信度          高 ✅         中 ⚠️         低 ❌
原因         邏輯自洽       單方自述      商業利益
建議         可直接應用     僅供參考      獨立評估

💎 收尾金句¶

「真正靠 AI 贏的公司，不會是 Prompt Library 最大的那間，而是 Intelligence Layer 最乾淨的那間。」

核心啟示：贏在結構，不贏在堆量。 把精力放在檢索層的設計，而不是無止境地餵資料。

📚 延伸思考¶

個人知識管理 vs 公司大腦

個人 PKM                    公司大腦
────────────                ────────────
Obsidian / Notion           Slack / CRM / Gong
個人標籤體系                 五層架構
手動連結                     Retrieval 自動調度
一人受益                     組織規模複利
    │                            │
    └── 核心共通 ──► 檢索能力 > 儲存量 ──┘

這套架構不只適用於公司，也適用於個人的 AI 工作流：你的筆記庫就是 Capture，你的檢索 Prompt 就是 Retrieval，你的來源取捨就是 Source Truth，你的知識保密習慣就是 Permission，你從錯誤中學到的規則就是 Feedback。