技術分享
AI Agent 工作流編排：任務拆解、角色定義與交接設計
多個 AI Agent 一起工作時，最常出事的不是誰不夠聰明，而是工作沒拆對、角色沒定清、交接沒設計。本文以柏克萊 MAST 失敗研究與 Anthropic、MetaGPT、OpenAI Agents SDK 的實務為據，提出一套工作流編排方法論：把目標拆成可驗收的工作單元、用單一職責定義角色與邊界，並把每個交接點設計成帶驗收條件的產出契約。
為什麼 RAG 上線半年後，答案開始悄悄變錯
不少企業把內部文件做成向量資料庫、接上 LLM，上線第一個月效果驚豔，半年後卻陸續收到抱怨：AI 引用了已作廢的報價單、回答舊版請款流程、把去年的休假政策當成現行規定。問題通常不在檢索技術，而在於這套知識庫是「一次性建好」的靜態快照——現實世界的文件天天在變，向量索引卻停在建置那一天。產業社群 RAGaboutit 的分析指出，約六成企業 RAG 專案的失敗不是敗在檢索或幻覺，而是敗在「無法在規模化後維持資料新鮮度」；當文件量從一千份長到十萬份，同一套架構的更新延遲會從「不到一小時」惡化到「十二小時」，到百萬份時甚至拖成好幾天。
更棘手的是，向量檢索天生分不出新舊。語意相似度和資料新鮮度並不相關——一份描述舊版 API 或舊報價的文件，會和最新版本一樣容易被檢索到，而且只要它在索引裡待得夠久，信心分數反而更高。一則被引用的案例是：某企業開發者入口網站持續回覆十四個月前就已淘汰的登入設定，標準的 RAGAS 評測仍照樣通過——因為評測集本身正是用同期的舊文件校準的。RAG 解決的是「怎麼把資料查出來」，卻沒人負責「查出來的還準不準」。
知識為什麼會腐化：文件生命週期的四種失效事件
知識庫不會一夕崩壞，而是沿著文件的生命週期，一點一點失效。把失效拆開來看，幾乎都落在四種事件上：
| 失效事件 | 發生了什麼 | 沒處理的後果 |
|---|---|---|
| 更新（版本衝突） | 文件被改，但舊向量還沒被替換 | 新舊兩版在「更新空窗期」並存，答案時對時錯 |
| 刪除（幽靈向量） | 來源文件被下架，向量卻留著 | 已不存在的知識持續被檢索、被引用 |
| 取代（版本碰撞） | 同一主題多個版本同時在庫 | 檢索靠語意雜訊挑版本，可能挑到舊的那份 |
| 靜默過期（信心懸崖） | 沒人動文件，但內容已不適用（報價、法規、市場數據） | 表面合法有效、實則全錯，最難察覺 |
這四種事件裡，靜默過期最危險，因為它沒有任何編輯事件可以觸發更新——沒人動那份文件，它就靜靜地待在庫裡繼續被檢索、被引用。這也是為什麼「文件一改就更新」的被動式管線並不夠：真正的知識維運管線，必須同時能「聽見」文件變動，也能「主動巡檢」那些明明沒被動、卻早已過期的內容。
保鮮期分級：不是每種知識都要即時更新
把整個知識庫用同一個頻率更新，既浪費又危險——即時性文件更新不夠快會出錯，永久性文件天天重算則純屬燒錢。務實的第一步是替每份知識標上「保鮮期」，依內容穩定度分級，決定它多久該被複檢或重建：
| 保鮮期分級 | 穩定週期（參考值） | 典型內容 |
|---|---|---|
| 永久 | 約 730 天 | 核心價值、系統架構文件 |
| 年度 | 365 天 | 年報、法律文件 |
| 季度 | 90 天 | 產品藍圖、定價 |
| 月度 | 30 天 | API 文件、整合指南 |
| 週度 | 7 天 | 版本說明、變更日誌 |
| 即時 | 0 天 | 市場行情、系統狀態 |
有了分級，就能把過期程度量化成一個可監控的數字：把「距上次更新的天數」除以「可接受的更新週期」，得到一個過期指數（例如保鮮期七天的安全規範放了五天即為 0.71），逼近上限就自動列入待審。實務上建議把 indexed_at、expires_at、content_hash、shelf_life 這幾個欄位一起寫進每份知識的中繼資料，後續的偵測、更新與稽核都以此為據。
三種更新架構怎麼選：批次、增量、串流
知道要更新什麼之後，接著是「用多快、多貴的方式更新」。主流有三種架構，差別在新鮮度空窗與成本結構，只有配不配你變動率的問題：
| 更新架構 | 新鮮度空窗 | 成本結構 | 適用情境 |
|---|---|---|---|
| 全量批次重建（原子換版） | 12～24 小時 | 每晚全庫重算，與變動量無關 | 文件少於十萬份、可容忍隔夜延遲 |
| 增量雜湊比對 upsert | 1～4 小時 | 只重算變動部分，成本隨變動率而非庫大小 | 每日變動率低於 5% |
| 串流 CDC 管線 | 數秒～數分鐘 | 需維運串流基礎設施 | 要求近即時、且有工程量能 |
成本差距很具體：假設庫裡有五萬份、每份約兩千字的文件，一次全量重建約需五萬次 Embedding 呼叫；若排每晚重跑，等於每天都替那些「根本沒改的文件」再付一次錢（Embedding 依 OpenAI／Voyage 公開價，約每千萬 token 0.2～1.8 美元）。增量架構改用 SHA-256 內容雜湊比對，只有雜湊變了才重算那一小塊，成本自然只隨真正的變動率成長。2026 年串流方案已大幅降低門檻——例如 RisingWave 可直接掛上 PostgreSQL 的 WAL 做變更資料擷取（CDC），並用內建的 openai_embedding() 在文件一改就自動重算，把空窗壓到數秒到數分鐘，不必再自架 Kafka 與 Debezium。（以上為公開案例與參考價，實依規模與供應商而異。）
失效偵測與版本治理：主動淘汰，還要能稽核
被動等文件變動還不夠，管線要能主動找出「沒被動、卻已過期」的知識。常見的偵測訊號有四種：到期日已過（有時效性的報價、促銷、年度政策預先標上期限）、來源已消失（原始文件下架但向量還在，即幽靈向量，須連帶淘汰）、答案互相矛盾（同一問題檢索到兩份說法不同，至少一份已過期）、長期零引用或低信心（列入定期人工複核）。實務上可設過期比例告警：受監管資料的過期占比超過 5%、或一般知識超過 10%，就該觸發重建；也有團隊改用綜合新鮮度分數，低於 85% 告警、低於 70% 進入降級模式。
另一半是版本治理。當 AI 給了錯答案，企業第一個問題永遠是「它到底根據哪份、哪個版本回答的」。若知識庫只留最新狀態，這題無解。做法是為每次更新保留版本、時間戳與來源，並在中繼資料放一個 valid_from 生效時間，檢索時只回傳 valid_from 早於當下的版本，就能讓新舊版在空窗期乾淨切換、必要時把單份文件回滾而不動全庫。這層稽核不只是維運方便：對金融、醫療、法遵產業，版本與稽核紀錄是合規硬需求，不是加分項。
讓管線自己顧自己：監控、金標資料集與 2026 的自主更新
知識庫是會「在你腳下移動」的——文件被重新切分、重新 Embedding、輪替，同一個問題這個月和上個月可能命中完全不同的段落，這叫檢索語料漂移（retrieval-corpus drift）。要及早察覺，靠的是一組金標資料集：先用 30～50 題真實或擬真的常見問題當回歸測試，再從中挑 50～200 題當「金絲雀集」，每天或每週自動重跑，答案品質一掉就報警。往前看，2026 年的知識維運正從「排程重建」走向「自主更新」：串流 RAG 用 CDC 把新鮮度做到近即時；自我反思式的 Self-RAG 讓模型自己決定何時該重新檢索、並在回答前先批判自己的輸出；時序型 GraphRAG 更把「時間」當成一等公民，讓知識圖譜的每條邊帶上有效區間，再由專責代理在回答前先剪掉過期的分支。工具在進化，但底層邏輯不變：知識庫不是一次性專案，而是要持續運轉、被監控的活系統。
恩梯科技如何協助
恩梯科技協助企業把「一次性建好的知識庫」升級為「會自己保鮮的知識系統」：從盤點來源系統、替每類文件標定保鮮期，到選對更新架構（批次／增量／串流）、建立失效偵測規則與版本稽核機制，並掛上金標資料集持續監控答案品質。企業 AI 的價值不在上線那一天達到高峰，而在上線之後能不能持續被信任——讓知識不過期，正是這份信任的基礎。當你的 AI 助手開始出現「答案越來越舊」的徵兆，歡迎與恩梯科技聊聊，如何替它接上一條持續運轉、可監控、可稽核的知識更新管線。
參考資料
- RAGaboutit，《The Knowledge Decay Problem: How to Build RAG Systems That Stay Fresh at Scale》，2025。來源連結
- Ranjan Kumar，《Why Your RAG Knowledge Base Is Lying About What It Knows》，2026。來源連結
- Voyage AI，《Pricing》，2026。來源連結
- OpenAI，《API Pricing》，2026。來源連結
- RisingWave，《Build a Continuous RAG Pipeline with Streaming SQL》，2026。來源連結
- RisingWave Docs，《Change Data Capture》，2026。來源連結
