Semi-Brain Session Deduplication

概念概覽

去重的兩個層次

核心知識

去重的兩個層次

知識庫去重需分兩層處理：

1. Session 層去重：以 session_id 為主鍵，識別「同一次對話的多次觸發」
2. 內容層去重：以 hash 為主鍵，識別「不同 session 的相同內容」

純 hash-based 去重只能處理第 2 層，無法應對 Stop hook 在同 session 多次觸發的情況。

融合更新 vs 跳過

策略	優點	缺點
跳過（舊）	實作簡單、效率高	遺失後續討論的知識增量
覆蓋	保留最新狀態	丟失早期討論的視角
融合更新（新）	知識累積，保留演進脈絡	需要 LLM 參與，較耗資源

融合更新：偵測到相同 session_id 的已有文檔時，根據新舊對話內容合併更新，而非跳過或覆蓋。

Ledger 三態語義

pending   → 尚未處理
failed    → 處理失敗，允許 retry
processed → 真正完成，才是去重邊界

failed **不應**等同已處理，否則失敗項目永遠無法重試。需搭配 lock 防止併發重複處理。

session_id 進入 frontmatter

將 session_id 寫入文檔 frontmatter，讓 _resolve_filepath() 的同 session 重複判斷能在正式模板下成立，是讓整個去重機制閉環的關鍵步驟。

經驗教訓

• 「已有文檔則跳過」在 Stop hook 多次觸發場景下過於粗暴，會遺失知識增量

• session_id 必須寫入 frontmatter 才能讓 session 層去重真正生效

• ledger 的 failed 狀態需允許 retry，與 processed 嚴格分開

常見陷阱

• 只用 hash 去重 → 同 session 多次觸發產生重複文檔

• failed 等同 processed → 失敗項目無法 retry

• session_id 未進 frontmatter → _resolve_filepath 去重判斷無法成立

最佳實踐

• 以 session_id 為 session 層去重主鍵，hash 為內容層去重主鍵，兩者分開處理

• 融合更新時基於新舊對話的實際內容演進，而非簡單合併字串

• ledger 操作需加 lock 防止併發衝突

相關概念

• Claude Code Stop Hook
• Semi-Brain Knowledge Management System

相關視角

以下頁面與本概念共享主題，但從不同角度切入。保留獨立視角同時提供交叉參考：

• Knowledge Consolidation Pass — 共享：deduplication, knowledge-management, semi-brain / 獨特：consolidation
• Knowledge Consolidation — 共享：deduplication, knowledge-management, semi-brain / 獨特：consolidation, content-quality

來源 Sessions

日期	Session	貢獻摘要

| 2026-03-18 | b0b2a293-9dc3-4b1b-a41f-7ab423a8fd45 | 建立「融合更新」取代「跳過」的去重策略，並確立 ledger 三態語義（processed/failed/pending）與 session_id 導向的去重主鍵設計 |

---

本概念頁面由 Semi-Brain Wiki 系統自動維護

最後更新: 2026-03-18