← AI Engineering 研究前線：30 天系列導讀：查看系列篇目索引
Day 21 回頭檢查了工具呼叫流程：模型提出操作，Python 驗證參數，再決定要不要執行。今天改用 Kubernetes 官方文件，取代原本五份虛構文件，作為知識庫的新語料。
原本的 harbor-api 是五份自行撰寫的虛構文件。它們很適合檢查索引和工具流程，問題也有明確答案；拿來看知識庫面對較多文件、不同概念與相似術語時會不會找錯，範圍就太小了。Kubernetes 文件裡同時有物件模型、工作負載、網路、儲存與安全設定，足以先整理一組有來源可回查的問題。
先把「Kubernetes 文件」定義清楚
我選的是 Kubernetes 官方網站的英文文件原始碼，範圍限於 content/en/docs/ 裡的 Markdown 格式文件，不含圖片或網站其他內容。官方文件版本頁在 2026 年 10 月 5 日列出 v1.37 為目前版本；我也記下來源儲存庫的 commit（提交版本），避免日後文件更新後，題目和答案對不上同一份內容。
這次鎖定的版本是 kubernetes/website commit 77db41e9c776b614fdb31de4cc6c8e9a70673817。盤點這個目錄裡的 Markdown，共有 1,720 個檔案、16,198,192 位元組，約 15.45 MiB。這是原始 Markdown 的大小，還沒經過專案的文件轉換、分塊（chunking）或建立搜尋索引。
官方來源儲存庫的 LICENSE 標示 Creative Commons Attribution 4.0 International（姓名標示 4.0 國際授權條款，CC BY 4.0）。因此題目會保留文件路徑和章節，回答用自己的話整理；這次沒有把 Kubernetes 文件全文複製進專案。實際使用資料時，仍要保留來源與授權資訊。
十題先測哪些問題？
我先寫了 10 題起始題目，每題都附上支援答案的文件和章節，放在 data/benchmark.jsonl。題目涵蓋 Kubernetes 物件的 spec（期望設定）和 status（目前狀態）、Deployment（部署控制器）更新、Service（服務）如何找到 Pod（容器執行單位）、readiness probe（就緒探針）失敗後的影響、ConfigMap（非機密設定資料）和 Secret（敏感資料）的界線、StatefulSet（有狀態應用程式控制器）、PersistentVolume（PV，持久磁碟區）和 PersistentVolumeClaim（PVC，持久磁碟區申請）、scheduler（排程器）的節點篩選，以及 RBAC（角色型存取控制）最小權限。
其中一題問：readiness probe（就緒探針）失敗時會發生什麼事？答案不能只寫「Pod 不健康」。文件說明，EndpointSlice 控制器會把該 Pod 的 IP 從對應 Service 的端點清單（EndpointSlices）移除。這種題目可以檢查檢索結果有沒有帶回機制細節，以及找到的段落是否足以支持答案。
另一題把 ConfigMap 和 Secret 放在一起問。ConfigMap 不提供保密或加密；Secret 用來存放敏感資料，但 Kubernetes 預設不會加密 etcd（Kubernetes 使用的鍵值資料庫）裡保存的 Secret 資料。因此題目同時檢查用途和預設儲存限制，之後可以看回答有沒有漏掉加密設定。
今天先把語料和測試題備好
1,720 篇文件讓後續測試有了固定範圍和版本。今天完成官方來源選擇、授權記錄、檔案數與原始容量盤點，以及第一批附證據位置的問題。這批文件還沒有匯入 knowledge/，也沒有跑過檢索、Qwen 模型作答或準確率評估。
這天的成果是把語料換成可追溯的 Kubernetes 官方文件，固定版本來源，並整理出 10 題附原文出處的問答，作為後續檢索測試的起點。五份虛構文件仍留著，繼續當快速、可預期的開發檢查。下一步是匯入 Kubernetes 文件、跑完這十題，記錄每題是否找到支援答案的段落，再評估回答品質。