LLMOps 與向量資料庫
Dify 1.17.1 收窄知識庫金鑰權限，但內建 Weaviate 必須跨 12 版逐級升級
Dify 新版加入資料集層級 API 金鑰、明確資料庫 session，並縮短代理事件保留時間以控制 Redis 成長。既有內建 Weaviate 部署不能直接更新映像，否則物件仍可讀取時，向量召回可能已永久受損。
Dify 1.17.1 為知識庫 Service API 加入資料集層級金鑰。過去一把金鑰可以讀寫同一 workspace 的所有知識庫；新版可在建立時綁定單一資料集，對其他資料集、文件、檢索及不含 dataset ID 的全域列表端點一律回傳 `403`。既有金鑰仍維持 workspace-wide 權限，因此升級本身不會自動落實最小權限，管理者仍須重發並替換憑證。
後端也移除多個 ORM model 對全域 `db.session` 的包裝，改由呼叫端明確傳入 session，以降低高負載下的跨請求狀態滲漏及 `DetachedInstanceError`。三項資料庫 migration 會正規化帳號電郵、將舊 model type 自動轉換成新格式，並建立 API token 與 dataset 的多對多綁定；其中 model type migration 沒有可逆的 downgrade，執行前必須備份。
最大的部署風險來自內建 Weaviate：映像由 1.27.0 一次改為 1.39.2。Dify 明確要求既有資料卷依序經過 1.28 至 1.38 的最新 patch，最後才進入 1.39.2，每一步都須正常停止及驗證。這與 Weaviate 官方建議每次只跨一個 minor version 一致。Dify 的測試亦顯示，強制終止可能讓物件數量、BM25 與依 ID 讀取看似正常，`near_vector` 卻只能召回 700 個物件中的 680 個；單看健康端點不足以證明 HNSW 索引完整。
新版另把代理執行紀錄與事件串流的預設保留期由三天降至兩小時，以抑制 Redis 無界成長，依賴長期除錯資料的團隊須顯式設定 `DIFY_AGENT_RUN_RETENTION_SECONDS`。升級驗收應包含真實知識庫向量查詢、模型供應商載入及大型工作流同步測試；使用外部 Weaviate、其他向量庫或全新資料卷者不受逐級遷移要求影響。