iT邦幫忙

2026 iThome 鐵人賽

DAY 3
0
AI Engineering

用 Hermes Agent 變成企業同事的 30 天系列 第 14

D11 · 外部研究進知識庫:來源保留與 metadata

  • 分享至 

  • xImage
  •  

前幾天把 Hermes 的記憶、Company Brain 與 QMD 分層後,我遇到一個更實際的問題:網路上看到的文章、X 貼文、官方文件與 Google Drive 文件,怎麼進入公司知識庫,才不會變成一堆沒人敢用的複製貼上?

答案不是「看到好文章就存下來」,而是一條可追溯的 ingest 流程:先判斷來源,再查重、建關聯,最後才轉成可以執行的知識。

先把外部內容分成四類

我目前會先判斷來源類型,因為不同來源的可信度、保存方式與後續驗證方法不同。

來源 主要用途 必留資料
官方文件與產品文件 查 API、設定與限制 URL、文件標題、發布或更新日期
技術文章與研究報告 理解方法與設計取捨 作者、來源網站、原文連結、擷取日期
X、社群與討論串 發現問題、案例與趨勢 原始貼文 URL、作者、貼文日期、上下文
Google Drive 文件 公司內部規則與實際紀錄 文件 ID、公司帳號、權限範圍、讀取日期

這個分類的重點,不是替來源打分數,而是避免把「別人的推測」誤寫成「公司的正式制度」。外部內容通常是參考資料;只有經過公司內部確認與核准,才可以成為 SOP 或正式規則。

第一關:先保留來源,再處理內容

我不會一開始就把全文搬進 Obsidian。先建立最小 metadata,讓未來任何人都能回答三個問題:這段話從哪裡來?什麼時候讀到?當時為什麼值得保存?

最小欄位可以長這樣:

  • source:原始 URL 或 Google Drive 文件 ID
  • title:原始標題
  • author:作者或發布組織
  • published:原始發布日期;查不到就標示 unknown
  • retrieved:實際讀取日期
  • source_type:official、article、social 或 internal
  • status:raw、reviewed、actionable 或 archived
  • related:關聯的專案、產品、Skill 或既有筆記

其中 retrieved 不能省略。網頁會改版、貼文可能刪除、文件權限也可能改變;沒有讀取時間,就很難判斷筆記反映的是哪一個版本。

第二關:查重不是只比標題

同一個主題可能同時出現在官方文件、部落格文章與社群轉貼。只用標題查重,很容易留下三份看似不同、實際上重複的筆記。

我的查重順序是:先比原始 URL 或文件 ID,再比標題與作者,最後比內容摘要與關鍵實體。若是社群轉貼,保留原始貼文,不把轉貼內容當成第二個獨立證據。

查重的結果不一定是刪除。比較好的做法是保留多個來源,並在主筆記中標示它們的角色:哪一份是規格依據、哪一份是實作案例、哪一份只是觀察。這樣做比把所有內容揉成一篇「看起來完整」的文章更容易維護。

第三關:建立關聯,讓知識能被找到

一份孤立的文章摘要,即使內容正確,下一次遇到問題時也可能找不到。因此 ingest 的輸出不應該只有一個 Markdown 檔,還要建立它與現有知識的關聯。

例如一篇關於認證自動修復的文章,可以關聯到:

  • 對應的 Hermes Skill
  • 使用該認證的 cron job
  • 曾經發生過的錯誤紀錄
  • 驗證認證狀態的指令
  • 尚未核准的制度提案

這裡有一個重要界線:關聯是索引,不是授權。文章提到「建議每小時檢查一次」,不代表公司就已經採用這個頻率。筆記中要把現況、推論、建議與待核准分開寫。

第四關:從摘要轉成可執行知識

外部研究真正有價值的地方,不是保存了多少文字,而是能否轉成下一次可重複使用的判斷。

我會把內容整理成四段:

  1. 來源主張:原文實際說了什麼。
  2. 適用條件:它在哪些環境成立,限制是什麼。
  3. ZoneTech 判斷:與現有架構有何相同或衝突。
  4. 可執行動作:要新增檢查、修改 Skill,還是提出制度草案。

如果讀不到正文,就只保存可確認的 metadata 與缺口,不補寫內容。這個規則看似保守,卻能避免知識庫充滿模型「合理猜出來」的段落。

PDF 與敏感文件的特殊處理

PDF 先擷取文字層,再檢查頁碼、表格與圖片中的重要資訊。擷取失敗時要留下失敗狀態,而不是假裝已完成。對 Google Drive 或公司內部文件,保留文件 ID 與權限來源即可,不任意複製敏感全文到其他位置。

公司資料還要明確標示使用哪個帳號讀取。之前遇到過個人帳號讀取公司文件得到 403 的情況;這不只是登入問題,也是資料邊界問題。來源 metadata 寫清楚帳號與權限範圍,未來才不會把「目前讀不到」誤判成「文件不存在」。

今天的驗證清單

完成一筆 ingest 後,我至少會檢查:

  • 原始連結可以回到來源,或明確標記來源已失效。
  • 標題、作者、日期與擷取日期沒有混在一起。
  • 內容摘要沒有超出原文可證明的範圍。
  • 已連結到相關 Skill、專案或既有筆記。
  • 現況證據、推論、建議制度與待核准事項分開。
  • 若涉及敏感資料,只保存必要 metadata。

這套流程的產物不是「一篇漂亮摘要」,而是一筆之後查得到、驗得回、能繼續更新的知識。對 Agent 來說,來源保留與 metadata 就像資料庫的主鍵;沒有主鍵,再好的內容也會慢慢失去可信度。

下一篇會進一步談 Skills:如何把已經驗證過的工作流程保存成下次不用重想的能力。


上一篇
D10 · QMD 是衍生索引,不是第二套知識庫
下一篇
D12 · Skills:把做過的事變成「下次不用重想」
系列文
用 Hermes Agent 變成企業同事的 30 天20
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言