不用一個超長對話，也能整理多年的 ChatGPT 紀錄

一份檔案真正有用，是因為它能分別回答三個問題：當時說了甚麼？現在仍然成立的是甚麼？它為甚麼改變？

把多年的內容放進一個「總部對話」，很難穩定回答這三個問題。即使舊訊息仍看得見，有用細節仍會在有限的工作上下文中互相競爭。更可靠的做法並不神奇：保存證據，另外維護一小層經人工確認的目前狀態，需要時再重建搜尋索引。

原始匯出檔保持不變

先從你已經控制的帳戶匯出檔開始。把下載的封存檔原封不動放在私密且有備份的位置，記錄取得時間，並在任何轉換之前計算雜湊：

sha256sum chat-export.zip > chat-export.zip.sha256

雜湊不能證明檔案內每句話都是真的；它證明日後處理的仍是今天保存的同一份檔案。

解壓一份工作副本，為每段對話和每則訊息設定穩定識別碼，保留原始順序、時間、角色、文字、附件參照與來源檔名。Markdown 方便閱讀，JSON 或 SQLite 方便查詢；兩者都不應取代原始匯出檔。

OpenAI 現行的 ChatGPT 使用指南提到，資料匯出可以作為檔案加入，用於比較、擷取和重新整理；同時也建議把重要結論與原始來源核對。這正是適合此工作的分工：軟件可以提出結構，檔案則要保留足以查核的證據。

把證據與目前狀態分開

不要讓一份摘要同時扮演歷史和真相。使用兩種互相連結的紀錄。

證據紀錄只描述某段對話出現了甚麼：

{
  "id": "ev-2024-0612-0042",
  "conversation_id": "chat-2024-0612",
  "message_id": "msg-0042",
  "observed_at": "2024-06-12T09:14:00Z",
  "kind": "user_statement",
  "text": "專案正在等待修訂報價。",
  "review": "confirmed"
}

目前狀態紀錄則描述現在應視為有效的內容，並指回支持它的證據：

{
  "id": "state-project-orchid-status",
  "subject": "project-orchid",
  "field": "status",
  "value": "等待修訂報價",
  "effective_at": "2024-06-12",
  "evidence": ["ev-2024-0612-0042"],
  "reviewed_at": "2024-06-13",
  "supersedes": "state-project-orchid-status-v1"
}

這個小小的分隔同時解決幾個難題：舊事實仍可用來建立時間線，目前任務保持精簡，後來的修正不會抹去早期紀錄，新答案也能說明某個狀態為何仍然有效。

敏感的健康相關內容應保存為有日期的個人陳述，而不是診斷。更普遍的規則也是一樣：只記錄來源真正支持的內容，不採用模型能想出的最強解讀。

讓 AI 建議有自己的狀態

只要把建議與事實放在同一個清單，建議就很容易在日後變成假事實。建立一個簡短的主張台帳，明確使用幾種狀態：

  • proposed：已擷取或提出，但尚未審閱；
  • confirmed：已由擁有人接受，且有可查證的證據；
  • rejected：檢查後確認不適合或不正確；
  • superseded：曾經有效，但已被較新的確認紀錄取代；
  • uncertain：值得保留，但不能安全地當作目前狀態。

新對話可以產生建議更新，但不應悄悄改寫目前狀態。審閱時可以接受、修改、拒絕或合併每項建議；把決定與時間另存為事件，不覆蓋原始證據。

這比全盤接受自動摘要慢一點，卻遠快於幾個月後才發現一個放棄的念頭已變成現行計畫，或模型猜測已寫進個人歷史。

讓索引可以隨時丟棄重建

來源紀錄和審閱決定才是長久的系統；搜尋索引只是可以替換的檢視。

先做中繼資料與全文搜尋，索引對話識別碼、日期、人物或專案標籤、紀錄類型、審閱狀態和文字。只有當真實查詢因不同用詞而失敗時，才加入向量。無論採用哪種搜尋，都要保存片段到訊息的對應，讓每個結果能重新開啟原始上下文。

不同問題走不同路徑：

  • 「現在有甚麼在進行？」先讀目前狀態；
  • 「事情如何改變？」讀有日期的證據與取代關係；
  • 「這從哪裡來？」開啟確切來源訊息與附近上下文；
  • 「我可能忘了甚麼？」搜尋已確認與不確定證據，但不把它自動提升為目前狀態。

資料庫或向量庫壞掉時，應能從紀錄重建。如果紀錄只存在索引裡，索引其實已悄悄變成另一個脆弱的總部對話。

分批完成並留下檢查點

不要把數百段對話塞進一次審閱。每次處理有限批次，完成後才開始下一批：

  1. 正規化來源對話，不先解讀內容。
  2. 擷取候選證據，附上確切訊息參照。
  3. 只審閱可能改變目前狀態、時間線或保留專案紀錄的候選項。
  4. 寫入已接受的狀態變更和拒絕決定。
  5. 執行一組已知答案的問題，逐一開啟引用來源。
  6. 儲存檢查點清單，包括數量、雜湊、例外和最後處理的來源識別碼。

下一批從耐久檔案與檢查點開始，不依賴上一次模型對話。即使對話失敗或用盡上下文，已完成的工作仍然存在。

使用一眼就能理解的目錄

簡單的配置已經足夠：

archive/
├── raw/                 # 原始匯出檔與雜湊
├── conversations/       # 有穩定識別碼的正規化訊息
├── evidence/            # 有來源的事實、決定、任務與事件
├── state/               # 精簡且經審閱的目前狀態
├── reviews/             # 接受、拒絕與被取代的建議
├── indexes/             # 可重建的全文或向量索引
└── manifests/           # 檢查點、版本與驗證結果

耐久資料夾與索引要分開備份。私密檔案應加密保存，不要只是為了測試架構，就把整個收藏上傳到另一項服務。

正式信任之前，先寫十個你已知道答案的問題：一項目前任務、一個過時計畫、一個改變過的日期、一項決定、一個矛盾，以及幾個確切來源查詢。只有當系統給出正確狀態，並能開啟支持它的來源，測試才算通過。

查看一個小型可運作模式

我製作了一個從來源到決定的小型範例：原始逐字稿保持不變，經審閱的段落變成分類紀錄，一次修正則保存為取代事件。可下載的 JSON 展示了證據與狀態模式，不需要超長上下文。Local Knowledge Terminal 是這項來源追溯工作的公開專案。

範例使用專案自寫的會議內容，還不是完整的 ChatGPT 匯入工具。真正可重用的是它的契約：來源不移動，目前狀態經過審閱，修訂仍然可見，索引可以重建。

如果你的私密檔案能放在一部現有電腦上，250 美元 Local Knowledge Terminal 收藏適合度測試可以先用最多 12 個有代表性的來源單元與 20 個真實問題，測試較大型建置是否值得進行。流程先從免費適合度確認開始；確立範圍前不需要上傳檔案或付款。

目標不是讓一個模型記住一切，而是讓遺忘可以被找回。

Leave a Reply