Day 28：綜合專題 — 企業知識助理的八週里程碑
前 27 天，我們一塊一塊地拆解了兩個職務的工作任務。今天要把它們組裝回一個完整的東西。
這也是我對每位讀者的建議：與其收藏 27 篇文章，不如做出一個作品。。
今天要解決的問題
「學了這麼多，但拼不起來。」
會這麼感受很自然，每天我們談的都是一個零件模組，而零件與系統之間隔著一件事——取捨與順序。
今天用一個具體 的專題，示範這些零件怎麼組裝、以什麼順序、每個階段驗收什麼。
📊 職缺訊號
「需求分析與系統架構」出現在 15.0% 的生成式 AI 職缺中。比例不高，但它是資深職缺的標配——因為它衡量的不是「會不會做」，而是「知不知道該做什麼、以什麼順序做」。今天這篇就是在練這件事。
一、現象：先定義成功，再開始寫程式
專題：企業內部知識助理——員工可以問公司政策、查詢自己的工單，並取得有來源引用的答案。
在寫任何程式碼之前，先回答四個問題（這一步就是 Day 06 說的「回頭 1」的預防）：
| 問題 | 這個專題的答案 |
|---|---|
| 誰用、解決什麼痛點 | 全公司員工；目前查政策要問 HR、查工單要開 IT 單，平均等 4 小時 |
| 成功長什麼樣（業務指標） | HR 與 IT 的例行詢問工單量下降 30%；使用者滿意度 ≥ 4/5 |
| 錯誤的代價 | 回答錯誤的政策 → 員工做錯事；洩漏他人薪資 → 嚴重，不可接受 |
| 不做什麼（範圍界線） | 不處理需要人工判斷的申請核准、不主動發起任何動作、不對外服務 |
第三列決定了整個架構。 「洩漏薪資不可接受」直接推導出：權限必須在檢索階段執行（Day 27）、必須強制引用來源（Day 20）、代理不得有對外傳輸能力（Day 25）。
📌 架構決策紀錄（ADR）
把每個重大決策寫成一頁：背景、選項、決定、理由、後果。例如「為什麼用 RAG 而非微調」「為什麼自建 vLLM 而非用 API」。
它的價值在半年後——當有人問「為什麼當初這樣做」時，你有答案；當情況改變時，你知道原本的假設是什麼、還成不成立。
二、原理：參考架構
圖 28-1：企業生成式 AI 平台的分層參考架構（示意架構）。觀測與治理是「橫切層」——它們不在請求路徑的主線上，卻掛在每一層旁邊。
對應到本系列的內容：
| 層 | 元件 | 對應 |
|---|---|---|
| 閘道層 | 認證、限流、路由、稽核入口 | Day 17、27 |
| 編排層 | 對話管理、工作流、agent 迴圈、工具執行 | Day 17、21–22 |
| 模型層 | vLLM 自建 ／ API、模型路由、快取 | Day 26 |
| 檢索層 | 向量庫、BM25、重排序、權限過濾 | Day 18–19、27 |
| 資料層 | 文件來源、索引管線、增量更新 | Day 09、18 |
| 觀測層（橫切） | trace、token 成本、延遲、評測結果 | Day 14、22、24、26 |
| 治理層（橫切） | RBAC、PII 遮罩、audit log、風險登錄 | Day 27 |
三、動手：八週里程碑
圖 28-2：綜合專題的八週里程碑排程（示意排程）。注意 M4 評測與 M3 開發並行——才能持續守住品質門檻。
M1（第 0–1 週）：需求與範圍界定
產出：一頁需求文件、成功指標定義、3–5 份 ADR、風險登錄表（Day 27 的風險矩陣）。 驗收：能用三句話說清楚「誰用、解決什麼、怎麼算成功」，且業務單位同意。
這一週不寫程式碼。 很多人受不了，但跳過這週的專案，通常在第六週才發現方向錯了。
M2（第 1–3 週）：資料管線與 RAG 骨幹
產出：文件載入與結構感知切塊、嵌入與索引、混合檢索、含來源引用的回答。 驗收：
- 50 份文件完成索引，metadata 含
source／dept／level／updated_at - 20 題手動測試，能給出帶引用的答案
- 引用可點回原文的正確位置
M3（第 2.5–4 週）：工具呼叫與 agent 迴圈
產出：工單查詢工具、ReAct 迴圈（含迭代與成本上限）、trace 紀錄。 驗收：
- 能正確處理「我上週開的那張單處理了嗎」（需查詢改寫 ＋ 工具呼叫）
- 迭代上限與成本上限有效（可用刻意的複雜問題驗證）
- trace 中能看到每一步的 reasoning 與工具參數
M4（第 3–5 週，與 M3 並行）：評測集與品質門檻
產出：50 題評測集（含 15% 拒答題）、自動化評測腳本、CI gate、κ 驗證報告。 驗收：
- Faithfulness ≥ 0.85、格式合規率 ≥ 0.98
- 注入測試全數通過（Day 25 的測試案例）
- 改提示後 CI 會自動跑評測，未達門檻無法合併
M4 與 M3 並行是刻意的設計。 如果等功能做完才建評測，你會為了「趕快上線」而降低標準。評測要與開發同時長出來。
M5（第 5–7 週）：部署與觀測
產出：docker compose 全套（app／向量庫／Langfuse／Prometheus／Grafana）、K8s 部署 YAML、儀表板。 驗收：
- 一個指令能 把整套環境跑起來
- 儀表板可看：QPS、TTFT P95、TPOT、每日 token 成本、拒答率
- 壓測報告：知道自己的容量上限在哪（Day 13、26）
# docker-compose.yml（節錄）——一個指令跑起整套
services:
app: { build: ., ports: ["8000:8000"], env_file: .env }
chroma: { image: chromadb/chroma, volumes: ["./data/chroma:/chroma"] }
langfuse: { image: langfuse/langfuse, ports: ["3000:3000"] }
prometheus: { image: prom/prometheus, volumes: ["./ops/prometheus.yml:/etc/prometheus/prometheus.yml"] }
grafana: { image: grafana/grafana, ports: ["3001:3000"] }
M6（第 6.5–8 週）：治理與上線
產出：RBAC 權限矩陣、PII 遮罩中介層、audit log、使用政策與 AI 揭露說明。 驗收：
- 權限測試：業務部門帳號查詢人資薪資文件，必須查無資料（而非「無權限」——不洩漏存在性）
- audit log 完整（含 reasoning）且個資已遮罩
- 有事件通報與回滾流程文件
三個發布關卡
| 關卡 | 時間 | 條件 |
|---|---|---|
| MVP 可示範 | 第 3 週 | 能問答 、有引用、內部 3–5 人試用 |
| Beta 內部試用 | 第 5 週 | 過品質門檻、有監控、開放一個部門 |
| GA 正式上線 | 第 8 週 | 治理齊備、壓測通過、有回滾機制 |
四、取捨：這個專題該做多大
如果你是為了作品集而做，我建議大幅精簡：
| 完整版 | 作品集版（1–2 週） | 為什麼可以砍 |
|---|---|---|
| 50 份企業文件 | 10 份公開文件（政府法規、開源專案文件） | 重點是流程不是規模 |
| vLLM 自建 | 用 API 或 Ollama | 除非你要展示 LLMOps 能力 |
| K8s 部署 | docker compose | 面試官看的是「有沒有容器化思維」 |
| 50 題評測集 | 20 題（含拒答題） | 這一項絕對不能砍 |
| RBAC 完整權限 | 兩個角色的權限過濾示範 | 展示你知道要在檢索階段做 |
| Langfuse ＋ Prometheus | 一份簡單的成本與延遲統計 | 展示你會量測 |
💡 作品集的關鍵不是功能多，是「你能講出取捨」
面試官不會因為你做了 50 個功能而錄取你，但會因為你能說出這段話而印象深刻：
「我的 RAG 一開始用固定切塊，答對率 0.61。加了查詢改寫到 0.68，改成結構感知切塊到 0.79——最大的提升來自切塊，不是 模型。後來加混合檢索到 0.85，重排序到 0.88，但延遲從 180 ms 漲到 620 ms。我最後停在這裡，因為再往上的邊際效益不划算。」
這段話展示了：會量測、懂原理、有判斷力、知道何時停手。這比任何技術清單都有說服力。
今日小結
- 先定義成功，再寫程式。四個問題：誰用、成功長什麼樣、錯誤的代價、不做什麼。第三個問題直接決定架構。
- 把重大決策寫成 ADR（背景、選項、決定、理由、後果），半年後你會感謝自己。
- 分層參考架構中，觀測與治理是橫切層——不在請求主線上，卻掛在每一層旁邊。
- 八週六個里程碑，其中 M4 評測必須與 M3 開發並行，否則會為了趕上線而降低標準。
- 三個發布關卡：MVP（第 3 週）、Beta（第 5 週）、GA（第 8 週）。
- 作品集版可以砍到 1–2 週，但評測集絕對不能砍。
- 作品集的關鍵不是功能多，是你能講出取捨——「我停在這裡，因為再往上的邊際效益不划算」。
明天預告
作品做完了，明天把它變成別人看得懂的能力證明：雙職能自我檢核表怎麼用、80 題考古題型怎麼練、面試最常考的五類題目怎麼答，以及一份作品 集該怎麼呈現才會被記住。
延伸閱讀
- 📄 Michael Nygard, Documenting Architecture Decisions——ADR 格式的原始出處，一頁講完
- 🔗 2022 鐵人賽《小題大作的 30 個 HackMD 技巧》——專題文件與 ADR 的寫作與協作，用得上其中的版本控制與共筆技巧
本文同步發布於 iThome 鐵人賽；Blog 版本為站內閱讀與系列導覽的主要版本。