先定義「新鮮」代表什麼
企業 AI 常見的風險，不是完全找不到資料，而是找到一份內容正確、時間卻已過期的文件。例如產品手冊可能以發布日期為準，庫存必須接近即時，合約則要依生效期間判斷。若所有來源都只保留一個 updated_at，系統很難分辨這個時間代表內容更新、檔案同步，還是資料重新匯入。
工程上應先為重要資料建立時間契約。至少要區分事件發生時間、來源系統更新時間、平台擷取時間，以及資料的有效起訖期間。若來源缺少可靠時間，也要明確標記時間未知，而不是用匯入時間假裝資料最新。這些欄位應與文件版本、來源識別碼、擁有者及狀態一起進入索引，讓檢索層可以過濾，回答層也能揭露依據。
依問題的時效需求選擇路徑
查詢路由器不應只做主題分類，還要判斷使用者需要哪一種時間尺度。像「請解釋請假流程」通常可查知識庫；「我今天還有多少假」則必須讀取人資系統。路由判斷可由規則與模型共同完成：規則處理明確詞彙、權限與高風險情境，模型則辨識較含蓄的意圖。建議至少區分下列路徑：
- 穩定知識：政策原則、操作說明與產品概念，可從經審核的文件索引檢索，但仍須套用版本與有效期間條件。
- 近期變動：價格表、排程、促銷內容或組織公告，優先查詢具有更新時間的結構化資料，並設定較短的快取期限。
- 即時交易：庫存、訂單狀態、設備告警與帳戶餘額，應直接呼叫 ERP、CRM、IoT 或其他權威 API，不應依賴向量資料庫中的舊快照。
- 跨時間分析：趨勢、差異與歷史原因需要指定時間範圍，並查詢可重現的資料倉儲或事件紀錄，而不是只取最新一筆。
若問題同時包含穩定知識與即時狀態，可以拆成子查詢。例如先從維修手冊找出判斷步驟，再向 IoT 平台讀取目前數值。合併答案時，系統要保留各部分的來源時間，避免用一個統一的「最新」標籤掩蓋不同資料的時效。
把時效控制放進檢索與回答流程
一個實用的流程會先抽取問題中的時間表達，例如「目前」、「上週」、「新版」或特定日期，再產生 freshness requirement。這個需求不必只有即時或非即時兩種狀態；它可以包含最大容許延遲、查詢時間範圍、是否允許快取，以及必須使用的權威來源。路由器據此選擇文件索引、SQL、內部 API 或事件平台，並在送給語言模型前完成權限檢查。
檢索時不要只用相似度排序。系統可先排除已失效、草稿或被取代的內容，再綜合相關性、來源可信度與時間適合度排序。當兩個來源互相衝突時，通常應依資料擁有權與版本規則決定，而不是讓較新的時間戳自動勝出；剛同步的副本不一定比稍早更新的主系統更可靠。快取鍵也應包含租戶、權限、時間範圍與版本，否則相同文字問題可能錯誤共用不同情境的答案。
讓系統在無法確認時效時安全退讓
可靠的企業 AI 必須能說「我無法確認這是最新資料」。當權威 API 無法連線、時間欄位缺漏，或目前時間超出資料有效期間時，系統應降低信心、顯示資料截至時間，並視風險選擇拒答、要求使用者確認，或提供查詢入口。對訂單、財務、設備控制等會影響決策或動作的問題，不應以過期快取靜默替代即時來源。
上線後應持續記錄使用者問題、推定的時效需求、實際路由、來源版本、資料時間與回答結果。測試案例除了問答正確性，也要涵蓋跨日切換、版本撤回、延遲同步、來源衝突及 API 故障。工程團隊可從最關鍵的幾類查詢開始，先建立清楚的時間契約與失敗策略，再逐步擴充來源；若需要整合多個既有系統，讓熟悉資料治理與 API 邊界的整合團隊共同設計，通常能減少後續返工。