# NVIDIA Agentic AI 讀書會整合講義（Master Markdown）

本檔案為整合版（單一 Markdown），內容包含 5 門課的讀書會講義、題庫與案例題。

## 目錄
1. [Building RAG Agents With LLMs（8 小時）](#building-rag-agents-with-llms-8-小時)
2. [Evaluating RAG and Semantic Search Systems（3 小時）](#evaluating-rag-and-semantic-search-systems-3-小時)
3. [Building Agentic AI Applications With LLMs（8 小時）](#building-agentic-ai-applications-with-llms-8-小時)
4. [Adding New Knowledge to LLMs（8 小時）](#adding-new-knowledge-to-llms-8-小時)
5. [Deploying RAG Pipelines for Production at Scale（8 小時）](#deploying-rag-pipelines-for-production-at-scale-8-小時)

---

## Building RAG Agents With LLMs（8 小時）

> 來源：`01_course_rag_agents/guide.md`

# Building RAG Agents With LLMs（讀書會版講義）

> 目的：用「可上線」的視角建立 RAG Agent。重點不是會做，而是：可回放、可稽核、可維運、可擴展。
> 建議用於 Week 1/Week 7（RAG 與平台串接）與 Capstone 的骨幹。

---

## 0. 考點對齊（你要用來排除陷阱選項）
高命中考點通常長這樣：
- 你如何設計 RAG pipeline 以支援 **版本化、可回放、可追溯引用**？
- 你如何處理 **失效模式**：檢索不到、檢索不相關、資訊過期、引用錯誤？
- 你如何做 **評估閉環**：離線→線上→再調整（chunk/embedding/rerank/prompt）？
- 你如何加上 **guardrails**（含：工具越權、資料外洩、防 prompt injection）？

---

## 1. 參考架構（推薦用於出題/互審）
### 1.1 典型 RAG Agent 模組
1) Ingestion：資料蒐集、清理、去重、版本標記
2) Chunking：切塊策略 + metadata
3) Embedding：向量化 + 索引
4) Retrieval：top-k + filter（tenant/時間/權限）
5) Re-ranking：提升 precision（避免「看似相關」的誤檢索）
6) Generation：回答＋引用＋信心/不確定性
7) Guardrails：輸入/輸出/工具/資料外洩
8) Observability：trace/log/metrics（用於回放與事故回溯）
9) Evaluation：離線資料集 + 線上監控 + 錯題分類表

### 1.2 必備的「可回放」欄位（很常考）
每次問答至少留：
- `trace_id`
- `index_version`（或 knowledge snapshot id）
- `retrieval_query`、`top_k`、`filters`
- `retrieved_doc_ids`（含段落位置）
- `rerank_model/version`
- `prompt_template_version`
- `policy_decision`（允許/拒絕/轉人工）

> 原因：沒有這些，你無法重現同一題，也無法做 A/B 評估或事故回溯。

---

## 2. Chunking（偏難高命中）
### 2.1 Chunking 不是越小越好：你要在「召回 vs 精準」之間取捨
- chunk 太小：recall↑但 precision↓，rerank 壓力上升、成本上升
- chunk 太大：precision↑但「關鍵句被稀釋」、上下文塞不進模型

### 2.2 可操作的設計規則（可出題）
- 以「語意邊界」切：標題/小節/條列/表格（不要只用固定字數）
- metadata 必備：來源、日期、版本、部門/租戶、敏感等級、段落座標
- 對表格：優先做「表格→結構化」再 embedding，避免語意崩壞

### 2.3 常見陷阱選項
- 只改模型大小、不改 chunking 與 rerank
- 只用 top-k，沒有 filter / rerank / freshness 控制

---

## 3. Retrieval 與 Re-ranking（用失效模式來記）
### 3.1 4 大失效模式（考試最愛）
1) 檢索不到（recall 低）
2) 檢索到但不相關（precision 低）
3) 檢索到但過期（freshness/版本一致性）
4) 引用錯誤（citation mismatch：引用段落與結論不一致）

### 3.2 失效模式→優先修正順序（可直接背成診斷 Playbook）
- 檢索不到：先查 query rewrite / chunking / embedding model / top-k
- 不相關：先加 rerank、再調 metadata filter、最後才調 prompt
- 過期：先做版本化與時間 filter、再做增量更新策略
- 引用錯誤：強制「引用再生成」或「先摘要後回答」，並做 citation-check

---

## 4. Guardrails（不要只寫成拒答）
### 4.1 你要防的不是「壞人」，而是「系統性風險」
- Prompt injection：讓模型改規則
- 資料外洩：把不該吐的段落吐出來
- 工具越權：叫工具做不允許的動作

### 4.2 最小可行的 guardrail 設計（可驗收）
- 輸入檢查：敏感資料遮罩（PII）、指令注入 pattern
- 檢索檢查：只允許取用授權範圍（tenant/role filter）
- 輸出檢查：必須含 citation；若無 citation → 降級回答或轉人工
- 工具檢查：工具 contract（schema + 權限），不允許「泛用寫入」工具

---

## 5. 評估（LLM-as-a-judge 要會，但要知道限制）
### 5.1 指標優先順序（出題常用）
1) groundedness/faithfulness（有無被證據支持）
2) citation correctness（引用是否對得上結論）
3) retrieval quality（recall/precision proxy）
4) latency / cost / throughput（上線指標）

### 5.2 Judge 的一致性控制（偏難）
- 固定 rubric（不可每題換標準）
- 盲測（避免 judge 看見系統提示/中間資訊）
- 多評審/多輪投票（降低隨機性）
- pairwise（比較 A vs B）比單一分數穩

---

## 6. 最小 Demo（驗收點）
你可以用任何框架，但驗收點要一致：
1) 能 ingest 1–3 份文件（含版本/日期）
2) 能回答 10 題固定題（含 citation）
3) 能故意做 2 題失效：檢索不到/引用錯誤，並能在 log 裡看出原因
4) 能輸出 `trace_id` 與 `index_version`（可回放）

---

# 題庫（15 題，偏難版）
> 命名建議：Wk1_Name_Qxx 或 Course1_Name_Qxx

## Q01. （版本一致性）
你在 production 的 RAG 系統每天增量更新索引。為了讓評估與事故回溯可重現，下列哪一個設計最合理？
A) 只要更新向量庫即可，因為模型回答會自動變好
B) 在 log 裡保存完整 prompt，其他都不必留
C) 在每次問答記錄 `index_version` 並保留 rollback 能力
D) 增加 top-k 讓檢索更全面即可
✅ 正確答案：C
為何正確：版本化與 rollback 才能重現同一題在不同知識快照下的行為，支援評估與事故回溯。
其他選項為何錯：A 忽略可重現性；B 少了檢索快照與引用；D 不能解決版本漂移問題。

## Q02. （失效模式診斷）
你發現回答內容看似合理，但引用段落與結論不一致（citation mismatch）。優先修正策略應是？
A) 改用更大的 LLM
B) 增加 top-k
C) 加入「引用驗證/引用後生成」的流程或 citation-check
D) 移除引用功能以免出錯
✅ 正確答案：C
為何正確：citation mismatch 是生成端與引用對齊問題，需要加入驗證或重新生成策略。
其他選項為何錯：A/B 不一定解決對齊；D 失去可稽核性，production 風險更高。

## Q03. （chunking 取捨）
同一份政策文件，chunk size 從 500 tokens 改成 1500 tokens 後，recall 下降但 precision 上升。最合理的解釋是？
A) embedding 壞掉了
B) chunk 變大使得檢索回來內容更集中，但容易漏掉分散的小段關鍵資訊
C) rerank 一定會更差
D) LLM 不支援長 context
✅ 正確答案：B
為何正確：chunk 變大通常提升語意聚合但降低細粒度覆蓋，造成 recall 下降。
其他選項為何錯：A/C/D 都不是直接推論。

## Q04. （retrieval 不相關）
RAG 系統檢索到的段落常常「主題相近但答案不在裡面」。你要先做哪一個？
A) 先加 reranking
B) 先把模型換成更大參數
C) 先把所有文件全丟進 prompt
D) 先移除 metadata filter
✅ 正確答案：A
為何正確：這是 precision 問題，reranking 通常是最高性價比的第一步。
其他選項為何錯：B/C 成本高且不一定解；D 可能更不相關。

## Q05. （freshness）
你要回答「最新制度」問題，但文件更新頻繁。下列哪個設計最符合可維運？
A) 每次查詢都重新爬全部資料並重建索引
B) 用版本化索引 + 增量更新 + 查詢時加時間/版本 filter
C) 只加 top-k
D) 把最新資訊寫進 long-term memory 就好
✅ 正確答案：B
為何正確：增量更新搭配版本/時間 filter 才能控成本且可回放。
其他選項為何錯：A 成本不可控；C 無法保證新；D 容易污染記憶且不可稽核。

## Q06. （可回放欄位）
下列哪一組欄位最能支持 debug 與回放？
A) 只有最終答案
B) `trace_id`、`index_version`、`retrieved_doc_ids`、`prompt_template_version`
C) 只有使用者問題
D) 只有 token 數量
✅ 正確答案：B
為何正確：需要同時保存檢索快照與提示模板版本，才能重現流程。
其他選項為何錯：A/C/D 都不足以重現。

## Q07. （工具越權防護）
RAG agent 允許呼叫「建立工單」工具。最合理的防護是？
A) 把工具描述寫得更長
B) 讓模型自己判斷可不可以用
C) 工具 contract 明確 schema + 權限檢查 + 審核節點（必要時 human-in-the-loop）
D) 完全禁用工具
✅ 正確答案：C
為何正確：越權屬系統性風險，需要 contract 與權限機制。
其他選項為何錯：A/B 不可靠；D 失去需求功能。

## Q08. （retry 與副作用）
工具呼叫失敗時要重試，但工具有副作用（例如寫 DB）。最關鍵的是？
A) 把 timeout 設很長
B) 加入 idempotency key / request id
C) 增加 prompt 長度
D) 換成更大模型
✅ 正確答案：B
為何正確：重試會造成重複寫入風險，冪等性是必要條件。
其他選項為何錯：A 不能保證；C/D 不相關。

## Q09. （輸出必含 citation）
在合規/稽核要求高的情境，最合理策略是？
A) 允許無引用回答，因為比較流暢
B) 若無足夠引用，降級回答或轉人工並記錄原因
C) 移除向量庫
D) 只依賴模型內建知識
✅ 正確答案：B
為何正確：可稽核情境要可追溯，無引用時要明確處置並記錄。
其他選項為何錯：A/D 不可稽核；C 不符合需求。

## Q10. （資料外洩）
你使用多租戶資料（不同部門資料隔離），最關鍵的設計是？
A) 讓模型「記得不要洩漏」
B) retrieval 層做 tenant/role filter，並在 log 留下 filter 條件
C) 增加 top-k
D) 用更長 prompt
✅ 正確答案：B
為何正確：資料隔離必須在檢索層落地，並可稽核。
其他選項為何錯：A/D 不可靠；C 無法隔離。

## Q11. （LLM-as-a-judge 限制）
你用 LLM-as-a-judge 評分兩個 RAG 版本，結果不穩定。最合理改善是？
A) 只跑一次就好
B) 固定 rubric + 多輪投票或 pairwise 比較
C) 直接用更大 judge 模型就會穩
D) 移除評估
✅ 正確答案：B
為何正確：一致性控制需要固定標準與多次評估，pairwise 常較穩。
其他選項為何錯：A 不穩；C 不一定；D 失去迭代依據。

## Q12. （retrieval 與 prompt 調整順序）
回答不相關時，你應優先：
A) 先調 prompt 讓模型「更聰明」
B) 先調 retrieval（rerank/filter/chunk）再調 prompt
C) 直接禁用檢索
D) 只增加 top-k
✅ 正確答案：B
為何正確：不相關通常是 retrieval 問題，先修檢索可提升證據品質。
其他選項為何錯：A 常只是掩飾問題；C 不符合 RAG；D 不一定改善 precision。

## Q13. （增量更新策略）
文件每天新增少量內容，最合理的 ingestion 策略是？
A) 每天全量重建索引
B) 只做增量 embedding，並保留版本/回滾策略
C) 完全不更新，靠模型內建知識
D) 把新增內容直接寫入 memory
✅ 正確答案：B
為何正確：增量更新可控成本，版本化支援可回放與 rollback。
其他選項為何錯：A 成本高；C/D 風險高且不可稽核。

## Q14. （監控指標）
下列哪個最能早期發現 RAG 品質退化？
A) 只看 GPU 使用率
B) 只看 token 數
C) 監控「引用率/無引用回答比例」與「使用者回饋」並抽樣做 judge/人工複核
D) 只看 QPS
✅ 正確答案：C
為何正確：品質退化要看 groundedness proxy（引用率）與回饋/抽驗。
其他選項為何錯：A/B/D 是資源或流量，不直接反映品質。

## Q15. （安全降級）
模型遭遇可疑 prompt injection（要求忽略規則並輸出敏感內容）。最合理處置是？
A) 直接照做，避免使用者不滿
B) 先檢索更多資料再輸出
C) 觸發安全策略：拒答/改寫需求/轉人工，並記錄 `policy_decision`
D) 把 system prompt 寫得更長
✅ 正確答案：C
為何正確：注入屬安全事件，需要 policy-driven 處置與稽核記錄。
其他選項為何錯：A/B 會外洩；D 不保證有效。

---

# 案例題（2 題，情境題）

## Case 1：多租戶 RAG + 合規稽核
你要在同一套系統支援 A 部門與 B 部門，資料不可互相洩漏，且需可稽核。請提出：
- retrieval 隔離設計（filter/索引分割/權限）
- logging/trace 必備欄位（至少 5 個）
- 無引用時的降級策略
- 一個你預期會被考的「陷阱選項」與反駁理由
> 以下以「建立工單（寫 DB）＋呼叫外部系統（偶發 timeout）」為情境，給一套可落地的設計（偏工程規格書寫法）。

 

## 1) 工具 contract（輸入 / 輸出 / 錯誤碼）

### 1.1 Tool：`create_ticket`

**用途**：由 agent 將使用者自然語言描述轉成結構化工單，寫入 DB，並（可選）觸發外部系統同步。

**輸入（JSON）**

* `request_id` *(string, required)*：冪等鍵（見第 2 節）
* `user_id` *(string, required)*：使用者識別（內部）
* `source` *(string, required)*：來源（web/line/slack/api）
* `title` *(string, required)*：工單標題
* `description` *(string, required)*：工單內容（可含原文）
* `priority` *(enum, optional)*：P0/P1/P2/P3（預設 P2）
* `category` *(string, optional)*：分類
* `labels` *(array[string], optional)*
* `attachments` *(array[{name,url,hash}], optional)*
* `external_sync` *(object, optional)*：

  * `enabled` *(bool)*：是否呼叫外部系統（預設 true）
  * `system` *(string)*：外部系統代號（如 JIRA/SNOW/ServiceNow…）
  * `timeout_ms` *(int)*：呼叫超時（預設 3000）
* `client_context` *(object, optional)*：例如 `client_ip`, `user_agent`, `locale`
* `dry_run` *(bool, optional)*：只驗證不落庫（預設 false）

**輸出（JSON）**

* `status` *(enum)*：`CREATED` | `EXISTING` | `PENDING_EXTERNAL` | `FAILED`
* `ticket_id` *(string)*：內部工單 ID（UUID/ULID）
* `request_id` *(string)*
* `created_at` *(RFC3339 string)*
* `external` *(object)*：

  * `sync_status`：`NOT_REQUESTED` | `SYNCED` | `PENDING` | `FAILED_RETRYABLE` | `FAILED_PERMANENT`
  * `external_ticket_id` *(string, nullable)*
  * `last_error_code` *(string, nullable)*
  * `next_retry_at` *(RFC3339, nullable)*
* `message` *(string)*：給 agent/使用者的摘要訊息

**錯誤碼（HTTP / tool error code）**

* `400 INVALID_ARGUMENT`：欄位缺漏、priority 不合法、JSON schema 不符
* `401 UNAUTHENTICATED` / `403 FORBIDDEN`
* `409 IDEMPOTENCY_CONFLICT`：同 request_id 但 payload hash 不一致（疑似重放但內容不同）
* `422 UNPROCESSABLE`：語意不足無法產生必要欄位（例如 title/description 空）
* `429 RATE_LIMITED`：超出配額
* `500 INTERNAL`：DB error、序列化錯誤
* `503 DEPENDENCY_UNAVAILABLE`：外部系統不可用（熔斷開啟或健康檢查 fail）
* `504 EXTERNAL_TIMEOUT`：外部 timeout（可重試）
* `502 EXTERNAL_BAD_GATEWAY`：外部 5xx（多半可重試，視策略）

> 實務上建議：**DB 寫入與外部同步拆成兩個工具**（`create_ticket_db`、`sync_ticket_external`），但若一定要單一 tool，就要回傳 `PENDING_EXTERNAL` 讓 agent 知道「內部已建立、外部尚未完成」。

---

## 2) Idempotency 設計（request id 來源與保存）

### 2.1 request_id 來源（優先順序）

1. **客戶端提供**（最穩）：前端/呼叫端生成 `X-Idempotency-Key`（UUIDv4/ULID），同一操作重送必須帶同 key。
2. **平台事件 ID**：若是 Line/Slack/Webhook，有 `event_id/message_id` 可直接使用（天然冪等）。
3. **伺服端生成（不推薦單靠）**：若客戶端無法提供，伺服端可用「使用者＋時間窗＋內容摘要」生成，但風險是誤判同一請求/不同請求。

### 2.2 保存與約束（DB）

建立一張 **idempotency 表**（或在 ticket 表加 unique constraint）

* `request_id` *(PK/Unique)*
* `user_id`
* `payload_hash`（canonical JSON 後算 SHA-256）
* `ticket_id`
* `status`：`IN_PROGRESS` | `SUCCEEDED` | `FAILED_RETRYABLE` | `FAILED_PERMANENT`
* `created_at`, `updated_at`
* `ttl_expires_at`：保存期限（例如 7～30 天，依商務決策）
* `last_error_code`, `last_error_message`

**流程**

1. 收到請求 → 以 `(request_id)` 做 **唯一寫入/鎖定**
2. 若已存在：

   * `payload_hash` 一致 → 回 `EXISTING`＋同 ticket_id（冪等命中）
   * `payload_hash` 不一致 → 回 `409 IDEMPOTENCY_CONFLICT`
3. 若不存在：插入 `IN_PROGRESS` 後再進行 DB 建單與外部同步

> 關鍵點：**在開始任何副作用之前就先「占位」request_id**，避免並發重送造成雙寫。

---

## 3) retry/backoff 與 circuit breaker 策略

### 3.1 Retry / Backoff（外部系統 timeout/5xx）

**哪些錯誤可重試（Retryable）**

* timeout（504 / EXTERNAL_TIMEOUT）
* 外部 5xx、連線重置、DNS 暫時失敗
* 429（視外部規範：可能要遵守 `Retry-After`）

**不可重試（Non-retryable）**

* 4xx（例如 400/401/403/404/422），除非能自動修正（通常不行）
* `IDEMPOTENCY_CONFLICT`

**建議策略**

* **Exponential backoff + jitter**

  * 第 1 次：1s
  * 第 2 次：2s
  * 第 3 次：4s
  * 第 4 次：8s
  * 第 5 次：16s
  * 上限：60s（或 2 分鐘）
* 最大重試次數：**5 次**（或以總時間上限，例如 2–5 分鐘）
* 若外部回 `Retry-After`：以它為準（仍加 jitter）

**同步 vs 非同步**

* 同步路徑（使用者在等）：建議只嘗試 **1–2 次**，再回 `PENDING_EXTERNAL`，其餘交給背景工作（queue/worker）
* 非同步 worker：跑完整重試策略直到成功或判定永久失敗

### 3.2 Circuit Breaker（針對外部系統）

以「外部系統 system」為維度維護 breaker 狀態（可存在 Redis / memory + 分散式一致性視需求）。

**狀態**

* `CLOSED`：正常
* `OPEN`：短期拒絕呼叫，直接回 503（避免雪崩）
* `HALF_OPEN`：放少量探測請求（試水溫）

**觸發條件（範例）**

* 滾動視窗 60 秒內

  * 失敗率 ≥ 50% 且樣本數 ≥ 20 → `OPEN`
  * 或連續 timeout ≥ 10 次 → `OPEN`
* `OPEN` 維持 30–60 秒後 → `HALF_OPEN`
* `HALF_OPEN` 探測 5 次：

  * 成功率 ≥ 80% → 回 `CLOSED`
  * 否則回 `OPEN`（再延長 open duration，可做指數延長）

**搭配 bulkhead**

* 每個外部系統設**併發上限**（例如 20）與排隊上限（例如 200），避免外部慢導致內部 thread pool 被塞爆。

---

## 4) 可回放（replayable）的 log 欄位（至少 6 個）

目標：任何一次呼叫都能被重建、重跑、追查，且能串起「agent → tool → DB → 外部」。

建議至少紀錄以下欄位（實務我會放 12+）：

1. `timestamp`（RFC3339 + 毫秒）
2. `trace_id`（分散式追蹤，串整條鏈路）
3. `span_id`（每一步）
4. `request_id`（冪等鍵）
5. `user_id`（或 `actor_id`）
6. `operation`（例如 `create_ticket`, `sync_external`）
7. `payload_hash`（canonical payload SHA-256；避免直接落敏感原文）
8. `ticket_id`（內部工單 ID）
9. `external_system`（JIRA/SNOW…）
10. `external_request_id`（呼叫外部時也帶一個，或沿用 request_id）
11. `attempt`（第幾次 retry）
12. `result_status`（SUCCESS/RETRYABLE_FAIL/PERM_FAIL）
13. `error_code` / `error_message`（標準化）
14. `latency_ms`（每次呼叫耗時）
15. `next_retry_at`（若排程重試）
16. `circuit_state`（CLOSED/OPEN/HALF_OPEN 當下狀態）

> 若要「可回放」到能重送外部：除了 hash，通常還需要可安全還原的 payload。做法是把原始 payload **加密存**在 `replay_store`（例如 S3/DB blob），log 只留 `payload_ref`（指到加密物件）＋hash。

---

## Case 2：索引增量更新造成答案飄移
你在兩週內更新索引三次，使用者抱怨「同一問題答案不一致」。請提出：
- 你如何用 `index_version` 做回放與比對
- 你會先檢查哪 3 個可能原因（freshness/filter/rerank/prompt 版本等）
- 你會如何灰度釋出與 rollback
- 你要新增哪 3 個監控指標（品質 + 維運）

---

## 1) 用 `index_version` 做回放與比對（Replay + Diff）

### 1.1 回放（Replay）最小必要條件

每次回答都要在回應紀錄（或工單/對話紀錄）存：

* `dataset_id`
* `index_version`（例如 `v2026_02_01_01` / ULID）
* `as_of_time`（可選，但建議存）
* `retrieval_config_version`（top_k、chunk_policy、filters 版本）
* `rerank_model_version`
* `prompt_template_version`
* `llm_model_version`（含溫度、max_tokens）

**回放做法**

* 使用者抱怨那筆回覆 → 取出當時的 `index_version` 與各版本號
* 用同一組參數重新執行：
  `retrieve(query, dataset_id, index_version, as_of_time, filters...) -> passages`
  `rerank(passages, rerank_model_version) -> ranked_passages`
  `generate(ranked_passages, prompt_template_version, llm_model_version) -> answer`
* 這樣可以判斷「不一致」是來自：檢索（index/filters）變了、rerank 變了、prompt/LLM 變了。

### 1.2 比對（Diff）建議輸出（給工程排查）

同一 query 同時跑兩版（例如 `v1` 與 `v2`）：

* **Retrieval Diff**

  * Top-K 命中集合交集比例：`Jaccard(topK_v1, topK_v2)`
  * 新增/消失的 doc_id、chunk_id 清單
  * 每個 passage 的分數差異（retrieval score / rerank score）
* **Generation Diff**

  * 引用來源是否一致（doc_id/revision_id）
  * Answer embedding 相似度（或關鍵結論一致性規則檢查）
  * 關鍵數值/日期/建議是否有衝突（rule-based extract）

> 實務上我會做一支「`compare_answer` 工具」：輸入 query + 兩個 index_version，輸出 retrieval/rerank/generation 的差異報告，讓維運可以直接定位。

---

## 2) 優先檢查的 3 個可能原因（我會先抓這三個）

### 原因 A：**查詢 filter / freshness 的邏輯有變或失效**

常見情境：

* `index_version` 切換後，**預設版本**或 `ACTIVE` 指向錯誤（例如灰度期間不同 user hit 到不同版）
* `as_of_time` 沒有固定，導致「同一問題」在不同時間點取到不同有效 chunk（valid_to/valid_from）
* tenant / category / 權限 filter 漏掉，造成有時候召回到不該看的資料

**先查什麼**

* query log 裡每次請求實際使用的：`resolved_index_version`、`filters_applied`、`as_of_time`
* 向量庫/DB 二次過濾是否一致（有些系統是先向量召回再 DB filter，容易出現差異）

### 原因 B：**rerank 或 chunking 策略改版造成 Top-K 內容漂移**

即使索引內容差不多，只要：

* chunk_policy 改了（512/1024、overlap、分段規則）
* rerank_model 改了（版本更新、參數不同）
* top_k / candidate_k 改了
  都可能讓最終輸入給 LLM 的 evidence 變掉，答案就漂。

**先查什麼**

* `chunk_policy_id` 是否在兩週內變更
* `rerank_model_version` 是否在三次更新中有不同
* topK overlap 指標是否突然下降（見第 4 節監控）

### 原因 C：**prompt / LLM generation 設定變了（溫度、模板、引用規則）**

同 evidence 下，仍可能因：

* prompt_template_version 更新
* temperature 從 0.1 → 0.7
* “允許推論/補全” vs “必須引用證據”規則改了
  導致答案不一致或更發散。

**先查什麼**

* `prompt_template_version`、`llm_model_version`、`temperature`
* 是否啟用「多樣性解碼 / self-consistency」之類策略

---

## 3) 灰度釋出與 rollback（建議流程）

### 3.1 灰度釋出（Canary）

* 新索引版本先標為 `BUILDING` → 完成後 `CANDIDATE`
* **只讓 5% 使用者**（或指定 internal/test tenant）走 `CANDIDATE`
* 其餘 95% 繼續走 `ACTIVE`
* 灰度期間所有回答必須寫入：

  * `resolved_index_version`（實際命中的版本）
  * `release_bucket`（canary/control）

**流量切換策略**

* 5% → 25% → 50% → 100%
  每個階段必須滿足監控指標未劣化（見第 4 節）。

### 3.2 Rollback（秒級回滾設計）

* `ACTIVE` 指標只是一個「指向版本」的設定（config / feature flag）
* 一旦 canary 指標劣化或抱怨暴增：

  * 立即把 `ACTIVE` 指回上一個穩定版 `index_version_prev`
  * 新版標為 `DEPRECATED` 或 `FAILED`
* **資料不刪**：保留新版本供離線比對與問題定位

> 這種 rollback 不需要重建索引，只是切「指標」，速度快且風險低。

---

## 4) 新增的 3 個監控指標（品質 + 維運）

我會挑「能直接解釋不一致」且能在灰度決策用的指標。

### 指標 1（品質）：**Answer Consistency Rate（跨版本一致性）**

* 對固定的 regression query set（例如 200～1000 題）每天跑：

  * `ACTIVE` vs `CANDIDATE`（或 vs 前一版）
* 定義一致性：

  * evidence overlap ≥ 某門檻（例如 Top-5 Jaccard ≥ 0.4）且
  * answer embedding similarity ≥ 某門檻（例如 ≥ 0.85）或關鍵欄位一致
* 這個指標直接對應「同題不同答」風險。

### 指標 2（品質）：**Retrieval Drift（Top-K Overlap / Citation Coverage）**

* 監控 Top-K overlap（同題在不同版本的召回集合差異）
* 同時監控「回答有引用證據」比例（citation coverage）
* 若 overlap 掉很快、引用率下降，通常代表：

  * filter 問題、chunking 問題、rerank 問題，或索引品質下降

### 指標 3（維運）：**Index Ingest Health（增量更新健康度）**

至少包含：

* `kb_ingest_event` backlog（PENDING 數量、最老事件延遲）
* ingest 成功率 / retry 次數分布
* 向量庫 upsert latency / error rate
* 版本狀態：BUILDING 卡住時間、FAILED 次數

> 這個指標能抓到「更新三次其實有一版不完整」或「增量漏寫」造成的答案漂移。

---

---

## Evaluating RAG and Semantic Search Systems（3 小時）

> 來源：`02_course_eval_rag_search/guide.md`

# Evaluating RAG and Semantic Search Systems（3 小時｜讀書會版講義）

> 目的：把「評估」做成可重現的工程閉環，而不是只看一個分數。
> 本講義以 **決策題/報表判讀題** 為主，對齊 Agentic AI Professional 常見出題方式：你看到指標與失效模式，要能判斷先動哪個旋鈕（資料/檢索/重排/提示/模型/部署）。

---

## 0. 考點對齊（高命中）
你要能回答以下問題：
1) **離線評估**跟**線上監控**差在哪裡？為什麼離線分數好，線上仍會壞？
2) 看到 retrieval 指標與 latency/cost，如何判斷先改：chunking、embedding、rerank、query rewrite、prompt、或資料品質？
3) 如何建立 **可回放** 的評估：同一題在不同 index_version / prompt_version 下能重現結果。
4) LLM-as-a-judge 要會用，但要懂它的**一致性控制**與**偏差**。

---

## 1. 評估系統的最小可行設計（MVP）
### 1.1 固定題庫（Evaluation Set）
建議先做 30 題（可擴到 100+）：
- 10 題：單段落可直接回答（baseline）
- 10 題：跨段落整合/條列整理（需要多 chunk）
- 5 題：時間敏感/版本敏感（freshness）
- 5 題：容易被 prompt injection 誘導（安全）

### 1.2 Golden set（參考證據）
每題至少標註：
- `doc_id`、`span_start/end` 或段落定位
- 允許答案範圍（可接受的同義表述）
- 是否必須引用（通常 production 建議 **必須**）

### 1.3 版本化（可回放的核心）
每次評估（或線上抽樣）都要記：
- `trace_id`
- `index_version`
- `embedding_model/version`
- `rerank_model/version`
- `prompt_template_version`
- `retrieval_filters`（tenant/role/time）
- `policy_decision`（允許/拒絕/轉人工/降級）

> 沒有版本化，你的評估不具可重現性，難以做 A/B、也難以事故回溯。

---

## 2. 指標（偏難但高命中）
### 2.1 Retrieval（Semantic Search）指標
- **Recall@k**：答案所在證據是否出現在前 k 個檢索結果（偏召回）
- **MRR**：第一個正確結果的排名品質（偏排序）
- **nDCG**：多相關等級下的排序品質（偏整體排名）

**常見陷阱：**
- 只看 Recall@k 卻忽略「不相關噪音」：recall 高但 precision 低，RAG 仍會答錯。
- 只看平均值，忽略長尾：少數困難題拖垮體驗（線上更常發生）。

### 2.2 RAG（Answer）指標
建議把答案評估拆成四類：
1) **Groundedness / Faithfulness**：結論是否被檢索證據支持
2) **Citation correctness**：引用段落是否真的支撐該句結論（避免 citation mismatch）
3) **Completeness**：是否漏掉必要條件/例外條款
4) **Freshness**：是否使用正確版本（制度更新題常考）

### 2.3 系統（Production）指標
- latency（p50/p95/p99）、timeout rate
- cost（token/請求、GPU 時間）、QPS、吞吐
- fallback rate、cache hit rate
- 無引用回答比例（groundedness proxy）
- 事件回溯可用率（log/trace 欄位完整性）

---

## 3. LLM-as-a-judge（會考的不是“會用”，而是“會控”）
### 3.1 Judge 風險
- 標準漂移：每次評分標準不一樣
- 位置偏差：看到冗長答案容易誤判「看起來很完整」
- 風格偏差：語氣順暢不等於正確

### 3.2 一致性控制（可出題）
- 固定 rubric（不可每次換標準）
- 盲測（judge 不看 system prompt/中間工具輸出）
- 多輪投票（3–5 次）取中位數或 majority
- **Pairwise**（A vs B）通常比單一分數穩
- 抽樣人工複核（用於校正 judge 漂移）

---

## 4. Debug Playbook（失效模式 → 優先旋鈕）
> 出題最常用：給你一張報表或一段症狀，問你第一步做什麼。

### 4.1 檢索不到（Recall 低）
優先順序：
1) query rewrite（同義詞、關鍵詞補全）
2) chunking/metadata（是否切錯邊界、缺少標題/日期）
3) embedding 模型（語言、領域、長文表現）
4) top-k（最後才加，避免成本爆）

### 4.2 檢索到但不相關（Precision 低）
優先順序：
1) rerank（最高性價比）
2) metadata filter（role/tenant/time/topic）
3) query rewrite（讓 query 更可判斷）
4) prompt（最後再調，避免掩蓋問題）

### 4.3 過期/版本不一致（Freshness 問題）
優先順序：
1) index versioning + time filter
2) 增量更新策略（文件版本標記）
3) 灰度釋出與 rollback

### 4.4 引用錯誤（Citation mismatch）
優先順序：
1) citation-check（引用驗證）
2) 引用後生成（先鎖定證據再生成）
3) 先摘要後回答（避免跨段落亂拼）

---

## 5. 最小驗收（你可以拿來當 Week 4/5 的驗收清單）
- [ ] 有固定題庫（≥30 題）與 golden set
- [ ] 每次跑分會產生可回放記錄（至少包含 index_version、retrieved_doc_ids、prompt_version）
- [ ] 有失效模式分類表（至少 4 類）與對應修正待辦
- [ ] LLM judge 有一致性控制（rubric + 多輪或 pairwise）
- [ ] 有線上抽樣監控（無引用比例、fallback rate、latency p95）

---

# 題庫（15 題｜偏難版）

## Q01.（離線 vs 線上）
離線評估分數顯著提升，但上線後使用者抱怨答案變不穩定。最合理的原因是？
A) 離線評估一定不準，應直接取消
B) 線上資料分布與離線題庫不同，且存在漂移與長尾情境
C) 只要把模型加大就會穩定
D) 把 top-k 加到 50 就一定穩
✅ 正確答案：B
為何正確：線上分布、長尾與漂移會讓離線分數無法直接外推。
其他選項為何錯：A 沒有解決；C 可能增加成本但不保證；D 成本暴增且 precision 可能更差。

## Q02.（版本化）
要讓同一題在事故回溯時可重現，最關鍵要記錄的是？
A) 最終答案文字
B) 使用者滿意度分數
C) `index_version` 與 `prompt_template_version`（以及 retrieval/rerank 相關版本）
D) 只記錄 token 數
✅ 正確答案：C
為何正確：沒有版本化就無法回放同一條 pipeline 的行為。
其他選項為何錯：A 不足以重現；B/D 與重現無關。

## Q03.（指標解讀）
你看到 Recall@10 很高，但使用者仍抱怨「常答非所問」。最可能的問題是？
A) 召回太高是壞事
B) Precision 低／需要 reranking 或 filter
C) LLM 太小
D) chunk 太大一定會造成答錯
✅ 正確答案：B
為何正確：召回到“包含答案”不代表前幾段落足夠精準，RAG 仍可能用錯證據。
其他選項為何錯：A 不成立；C 不一定；D 過度武斷。

## Q04.（調整順序）
回答常引用到“相近但不包含答案”的段落。你第一步應該做？
A) 先改 prompt 讓模型更嚴謹
B) 先加 reranking（或改 rerank 設定）
C) 直接改用更大模型
D) 直接移除引用機制
✅ 正確答案：B
為何正確：這是 retrieval precision 問題，rerank 通常最有效率。
其他選項為何錯：A 可能掩蓋問題；C 成本高不保證；D 失去可稽核性。

## Q05.（citation mismatch）
你發現答案引用的段落與結論不一致。最正確的處置是？
A) 增加 top-k
B) 加入 citation-check 或引用後生成流程
C) 讓模型自行“更誠實”
D) 將引用移除以避免錯誤
✅ 正確答案：B
為何正確：citation mismatch 需要機制驗證或重建生成步驟。
其他選項為何錯：A 不對症；C 不可靠；D 破壞稽核。

## Q06.（freshness）
制度更新題常答錯，你應優先：
A) 將所有資料寫入 long-term memory
B) 建立索引版本化與時間 filter，並在 log 記錄 filter 條件
C) 加大模型
D) 只調 prompt 要求“回答最新”
✅ 正確答案：B
為何正確：freshness 問題要從資料版本與檢索條件落地。
其他選項為何錯：A 會污染且不可稽核；C/D 不保證最新。

## Q07.（judge 一致性）
LLM-as-a-judge 分數波動大，最佳改善策略是？
A) 只跑一次
B) 固定 rubric + 多輪投票或 pairwise 比較
C) 改用更大 judge 一定會穩
D) 取消評估
✅ 正確答案：B
為何正確：一致性控制是穩定 judge 的核心。
其他選項為何錯：A 不穩；C 不一定；D 失去迭代依據。

## Q08.（nDCG）
下列哪個情境最適合使用 nDCG 作為檢索排序指標？
A) 只有 0/1 相關的二元標註
B) 有多層級相關（高度相關/部分相關/不相關）且重視排名品質
C) 只看第一個結果是否正確
D) 只看 latency
✅ 正確答案：B
為何正確：nDCG 適用多層級相關與排名折扣。
其他選項為何錯：A/C 可用其他指標；D 不是排序指標。

## Q09.（MRR）
MRR 主要反映什麼？
A) 平均召回率
B) 第一個正確結果出現得有多前面
C) 生成答案的流暢度
D) GPU 使用率
✅ 正確答案：B
為何正確：MRR 取決於第一個正確結果的排名倒數。
其他選項為何錯：A/C/D 無關。

## Q10.（長尾）
線上品質退化通常先反映在哪裡？
A) 平均分數
B) 長尾題（困難/模糊/跨段落/版本敏感）與 p95/p99 延遲
C) token 數一定變少
D) 只要加大 top-k 就能解決
✅ 正確答案：B
為何正確：線上長尾與尾延遲更容易造成體感問題。
其他選項為何錯：A 可能掩蓋；C 不必然；D 成本高且不一定有效。

## Q11.（成本/效能 trade-off）
你要降低成本但不想明顯損失品質。最合理的順序是？
A) 先把 top-k 大幅增加
B) 先做快取（cache）與 rerank/生成的動態策略（只在需要時用重資源）
C) 先把模型換成更大以減少重試
D) 先取消引用
✅ 正確答案：B
為何正確：快取與動態策略能在不破壞架構基礎下控成本。
其他選項為何錯：A 增加成本；C 更貴；D 破壞稽核。

## Q12.（抽樣監控）
下列哪個監控最能早期發現 RAG 品質漂移？
A) GPU 使用率
B) QPS
C) 無引用回答比例 + 使用者負回饋 + 抽樣 judge/人工複核
D) token 平均值
✅ 正確答案：C
為何正確：這些是品質 proxy 與真實回饋的組合，可較早捕捉漂移。
其他選項為何錯：A/B/D 是資源或流量，不直接反映品質。

## Q13.（資料集污染）
你用線上對話紀錄自動生成評估集（synthetic）。最大的風險是？
A) 指標變得更好
B) 測試資料與訓練/調參資料洩漏，導致過度樂觀（data leakage）
C) latency 變快
D) rerank 會自動變強
✅ 正確答案：B
為何正確：資料洩漏會讓離線評估失真，線上不一定能維持。
其他選項為何錯：A/C/D 不相關。

## Q14.（先修什麼）
你同時看到：precision 低、freshness 低、citation mismatch 偶發。最合理的優先順序是？
A) 先修 prompt injection
B) 先修 freshness（版本化/time filter），再修 rerank/filter，最後補 citation-check
C) 先把 top-k 加到 100
D) 先換更大模型
✅ 正確答案：B
為何正確：freshness 影響“用對版本”，rerank/filter 影響 precision，citation-check 解決對齊；這順序最符合風險與性價比。
其他選項為何錯：A 未必是主要症狀；C 成本爆；D 不對症。

## Q15.（可回放需求）
以下哪個做法最不利於可回放與比較？
A) 記錄 index_version
B) 記錄 prompt_template_version
C) 直接覆蓋索引且不保留舊版本
D) 記錄 retrieved_doc_ids
✅ 正確答案：C
為何正確：覆蓋且無版本，無法重現過去行為。
其他選項為何錯：A/B/D 都有助可回放。

---

# 案例題（2 題｜情境題）

## Case 1：報表判讀 → 修正優先順序
你拿到一份報表：
- Recall@10：0.82（高）
- 無引用回答比例：18%（偏高）
- 使用者負回饋集中在「答非所問」
- latency p95：偏高

請提出：
1) 你判斷的主要失效模式是什麼？
2) 你第一個要動的旋鈕（rerank/filter/chunk/prompt/cache/佇列）與理由
3) 你要新增哪些回放欄位或監控指標（至少 5 個）

## Case 2：制度更新造成 Freshness 事故
制度在一週內更新兩次，線上出現「同題不同答」爭議。請提出：
1) 你如何建立 index 版本化與灰度釋出/rollback
2) 你如何設計 time filter 與 metadata，避免檢索到舊版段落
3) 你如何安排線上抽樣驗證與 postmortem（含 trace_id）

---

## Building Agentic AI Applications With LLMs（8 小時）

> 來源：`03_course_agentic_apps/guide.md`

# Building Agentic AI Applications With LLMs（8 小時｜讀書會版講義）

> 目的：把 Agent 從「會說」做成「可上線的系統」。
> 這門最常被考成：**工具契約、權限邊界、狀態管理、可靠性護欄、可回放與可稽核**。

---

## 0. 考點對齊（高命中）
你要能判斷：
- 什麼情境要用 **ReAct / Plan-Execute / Router / Reflection**？
- tool/function schema 怎麼設計才不會越權、才可測、才可維運？
- retry/backoff/circuit breaker/fallback 何時用？副作用如何避免重複執行？
- memory 何時寫入、何時淘汰？怎麼避免「把錯誤輸出寫進長期記憶」？
- multi-agent 要怎麼分工與協議？衝突怎麼解？

---

## 1. Agent patterns（偏難高命中）
### 1.1 ReAct（Reason + Act）
適用：需要邊做邊看工具回傳、逐步修正的任務（查詢、分段處理）。
風險：容易被 prompt injection 誘導去用不該用的工具；需 tool policy 與審核點。

### 1.2 Plan-Execute（先規劃後執行）
適用：多步任務、需要可回放與可追溯步驟（例如：資料整理→檢核→輸出報告）。
風險：計畫可能不合理；需 validation（限制條件、資源、權限）。

### 1.3 Router（路由/分類器）
適用：多種任務入口（查知識 / 叫工具 / 轉人工 / 安全事件）。
風險：路由錯誤會造成“看似合理但走錯流程”；需觀測與回訓資料。

### 1.4 Reflection / Critic（自我檢核）
適用：高風險輸出（合規、醫療、財務）或需要高可靠度；可當第二層防線。
風險：成本增加；需明確觸發條件（只在不確定/高風險時啟用）。

---

## 2. State 與可回放（考試很愛）
### 2.1 什麼叫 stateful orchestration
不是把所有對話丟進 prompt，而是：
- 你能描述「目前做到哪一步」
- 你能從某個 checkpoint 續跑
- 你能用 trace 回放整個決策過程

### 2.2 最小狀態機（例）
- `S0: intake`（收問題與限制）
- `S1: retrieve`（檢索/資料來源）
- `S2: decide_tool`（是否需要工具）
- `S3: tool_exec`（工具執行/錯誤處理）
- `S4: compose_answer`（含引用/證據）
- `S5: safety_check`（輸出審查/轉人工）
- `S6: done`

### 2.3 可回放欄位（至少）
- `trace_id`、`state`、`state_transition_reason`
- `tool_calls[]`（name, args, response, error_code, duration_ms）
- `policy_decision`（允許/拒絕/轉人工/降級）
- `prompt_template_version`

---

## 3. Tool / Function Contract（核心必考）
### 3.1 為什麼 tool schema = 權限邊界
你不能依賴模型“自律”。必須用工程機制讓“做不到”。

### 3.2 Contract 必備元素
- **輸入**：型別、必填欄位、範圍、正則（避免 prompt injection 變成 tool 參數）
- **輸出**：結構化回傳（讓 agent 可以判斷下一步）
- **錯誤碼**：可機器判斷（例如：TIMEOUT、RATE_LIMIT、PERMISSION_DENIED）
- **權限**：角色/租戶/資源範圍（read vs write）
- **副作用**：標註是否有 side effect，決定重試策略
- **冪等性**：有副作用工具必須支援 idempotency key

### 3.3 常見陷阱（出題用）
- 把所有操作都塞進一個「萬用工具」：容易越權、難稽核、難測試
- 工具失敗只回自然語言：無法做自動化 fallback
- 無限重試：會造成級聯失敗或重複寫入

---

## 4. Reliability（可上線的護欄）
### 4.1 Retry / Backoff
適用：暫時性失敗（網路抖動、短暫過載）。
必備：最大次數、指數退避、jitter、以及 idempotency（若有副作用）。

### 4.2 Circuit Breaker
目的：避免下游故障造成級聯失敗與資源耗盡。
狀態：closed → open → half-open（可出題）

### 4.3 Fallback（降級策略）
- 無法檢索：改成要求更多資訊或轉人工
- 工具不可用：提供只讀替代、或延後處理（建立待辦）
- 模型不確定：要求確認或提供多方案選擇

---

## 5. Memory（偏難高命中）
### 5.1 Session vs Long-term
- session：當次會話上下文、短期狀態
- long-term：跨會話偏好/已驗證知識/使用者設定

### 5.2 Memory write policy（一定要會）
**不可把未驗證的模型輸出寫入 long-term memory**。
建議策略：
- 只寫入「可追溯來源」或「使用者明確確認」的資訊
- 寫入時附 `source`（doc_id / ticket_id / user_confirmed）
- 設 eviction（TTL / LRU）與刪除能力（合規）

---

## 6. Multi-agent（協作與衝突）
### 6.1 何時需要多代理
- 任務可平行化（檢索/比較/風險分析）
- 需要互審（生成者 vs 審核者）
- 需要角色分工（planner/executor/critic/safety officer）

### 6.2 通訊協議（可出題）
- 訊息格式（schema）
- 共享狀態（哪些欄位可寫）
- 衝突解決（仲裁/投票/優先權）

---

## 7. 最小驗收（Week 2/3 很好用）
- [ ] 至少 2 個 agent pattern（ReAct + Plan-Execute）能跑
- [ ] 至少 2 個工具：read-only + write（有副作用）
- [ ] write 工具支援 idempotency key
- [ ] 工具回傳結構化錯誤碼，agent 有 fallback
- [ ] 記錄 trace_id + tool_calls + policy_decision，可回放

---

# 題庫（15 題｜偏難版）

## Q01.（Pattern 選擇）
你要做一個多步驟任務：先讀資料、再叫工具建立工單、最後產出可稽核報告。最適合的 pattern 是？
A) 單一 LLM 呼叫
B) Plan-Execute（含狀態機與可回放）
C) 只用向量庫檢索
D) 隨機選工具
✅ 正確答案：B
為何正確：多步任務需要明確步驟、可回放、可稽核。
其他選項為何錯：A 不可控；C 不含工具/流程；D 不可靠。

## Q02.（Tool contract）
下列哪個最能降低工具越權風險？
A) 把工具描述寫得更長
B) 工具 schema 明確輸入輸出 + 權限檢查 + 審核節點
C) 讓模型自行判斷是否可用
D) 只用 system prompt 禁止越權
✅ 正確答案：B
為何正確：越權需工程落地，不能只靠文字規範。
其他選項為何錯：A/C/D 不可靠且不可稽核。

## Q03.（副作用與重試）
工具有副作用（寫 DB），失敗要重試。最關鍵是？
A) 把 timeout 設長
B) idempotency key / request id
C) 增加 top-k
D) 用更大模型
✅ 正確答案：B
為何正確：避免重試造成重複寫入。
其他選項為何錯：A 不保證；C/D 不相關。

## Q04.（錯誤碼）
工具失敗時回傳自然語言錯誤訊息，不回傳錯誤碼。最主要問題是？
A) 使用者不喜歡
B) agent 無法自動判斷 fallback/重試策略
C) latency 會下降
D) 內容會更短
✅ 正確答案：B
為何正確：需要機器可判斷的錯誤碼做可靠性策略。
其他選項為何錯：A 次要；C/D 無關。

## Q05.（Circuit breaker）
Circuit breaker 最主要解決什麼？
A) 提升模型準確率
B) 防止級聯失敗造成系統過載
C) 增加記憶體使用量
D) 讓 prompt 更長
✅ 正確答案：B
為何正確：斷路器避免連續失敗持續打下游。
其他選項為何錯：A/C/D 不相關。

## Q06.（Stateful orchestration）
下列哪個最符合「可回放」需求？
A) 每次只保留最終答案
B) 記錄 state transition + tool_calls + prompt_version + trace_id
C) 只記錄 token 數
D) 只記錄使用者問題
✅ 正確答案：B
為何正確：回放需要流程、版本與工具呼叫細節。
其他選項為何錯：A/C/D 不足以重現。

## Q07.（Memory 污染）
下列哪個做法最可能造成 long-term memory 污染？
A) 只存使用者確認過的偏好
B) 存可追溯來源的制度條文片段
C) 把模型未驗證的結論直接寫進 long-term memory
D) 存 TTL 限制的短期摘要
✅ 正確答案：C
為何正確：未驗證輸出容易把幻覺固化成“事實”。
其他選項為何錯：A/B/D 有治理策略。

## Q08.（Reflection 觸發）
Reflection/critic 最合理的觸發條件是？
A) 每次都跑，越多越好
B) 只在高風險或不確定度高時觸發（成本可控）
C) 完全不用
D) 只在模型回覆很長時觸發
✅ 正確答案：B
為何正確：平衡可靠性與成本。
其他選項為何錯：A 成本爆；C 降可靠；D 不對症。

## Q09.（Router）
Router 的核心價值是？
A) 讓回答更長
B) 在多流程入口下，做可觀測的路由決策（查知識/叫工具/轉人工/安全）
C) 取代向量庫
D) 取代監控
✅ 正確答案：B
為何正確：路由是把任務導向正確 pipeline，並能監控其錯誤率。
其他選項為何錯：A/C/D 不成立。

## Q10.（多代理通訊）
多代理系統中通訊協議的主要目的為？
A) 增加模型參數
B) 定義訊息格式與協作方式，確保可靠交換資訊與同步狀態
C) 降低記憶體使用
D) 讓 UI 更漂亮
✅ 正確答案：B
為何正確：協作需要一致訊息與狀態同步。
其他選項為何錯：A/C/D 無關。

## Q11.（共享狀態風險）
多代理共享同一份狀態（state store）最大風險之一是？
A) 速度變快
B) 寫入衝突與不可預期覆蓋，導致不可回放
C) token 變少
D) 一定更安全
✅ 正確答案：B
為何正確：共享狀態需鎖/版本或仲裁，否則難以重現與除錯。
其他選項為何錯：A/C/D 不必然。

## Q12.（Fallback）
工具不可用（PERMISSION_DENIED 或 OUTAGE）時，最符合可維運的策略是？
A) 無限重試
B) 直接產生看似合理的答案當作成功
C) 依錯誤碼觸發降級或轉人工，並在 log 記錄 policy_decision
D) 刪除所有 log 以避免洩漏
✅ 正確答案：C
為何正確：可維運需要可觀測、可稽核的降級處置。
其他選項為何錯：A 造成級聯失敗；B 造成幻覺；D 破壞稽核。

## Q13.（最小權限）
下列哪個設計最符合最小權限（least privilege）？
A) 一個工具同時具備讀/寫/刪全部資源
B) 分成 read-only 與 write 工具，並限制資源範圍與角色
C) 讓模型自由選擇任何 API
D) 把權限規則寫在自然語言提示裡
✅ 正確答案：B
為何正確：拆分工具與限制範圍是最小權限的工程落地。
其他選項為何錯：A/C/D 高風險且不可稽核。

## Q14.（可測性）
要讓工具整合可測（unit/integration），最重要的是？
A) 工具回傳結構化資料，且可 mock
B) 工具回傳越長越好
C) 工具完全不需要文件
D) 只測 UI
✅ 正確答案：A
為何正確：結構化回傳與可 mock 是自動化測試的前提。
其他選項為何錯：B/C/D 不足。

## Q15.（安全事件）
偵測到疑似 prompt injection 要求越權使用工具。最合理處置是？
A) 直接照做
B) 先檢索更多資料再照做
C) 觸發安全策略：拒絕/改寫需求/轉人工，並記錄事件與 trace_id
D) 只把 system prompt 加長
✅ 正確答案：C
為何正確：注入屬安全事件，需要 policy-driven 處置與稽核。
其他選項為何錯：A/B 可能越權與外洩；D 不保證。

---

# 案例題（2 題｜情境題）

## Case 1：工單工具與冪等性
你要做一個 agent：收到使用者描述後自動建立工單（寫 DB），但外部系統偶爾 timeout。請提出：
- 工具 contract（輸入/輸出/錯誤碼）
- idempotency 設計（request id 的來源與保存）
- retry/backoff 與 circuit breaker 的策略
- 可回放的 log 欄位（至少 6 個）

## Case 2：多代理互審（生成者 vs 審核者）
你設計兩個代理：Generator 產出方案，Reviewer 負責檢核合規與可維運。請提出：
- 兩者通訊協議（訊息 schema）
- 共享狀態的寫入規則與衝突解決（仲裁/投票/優先權）
- 何時轉 human-in-the-loop
- 你預期會被考的陷阱選項與反駁理由

---

## Adding New Knowledge to LLMs（8 小時）

> 來源：`04_course_add_knowledge/guide.md`

# Adding New Knowledge to LLMs（講師授課 8 小時｜讀書會版講義）

> 目的：你要能在考題情境下，清楚做出「**應該用 RAG 還是微調**」的工程決策，並能解釋資料治理、版本、評估與風險控制。
> 本講義把新增知識的方法拆成：**檢索式（RAG）**、**參數式（微調）**、**工具式（tool / DB / API）** 三條路徑，並提供可上線的決策矩陣與常見陷阱。

---

## 0. 會考的核心不是名詞，而是「決策」
你要能回答：
1) 這個需求是「**知識新增**」還是「**行為/格式/風格**」？
2) 需要 **可稽核引用** 嗎？資料會更新嗎？
3) 允許把資料放進模型參數嗎（合規/授權/隱私）？
4) latency/cost/SLO 要求是什麼？
5) 失效時要怎麼 rollback？

---

## 1. 三種新增知識路徑（考題常用框架）
### 1.1 檢索式：RAG（Retrieval-Augmented Generation）
**概念：** 知識留在資料層（文件/DB/向量庫），模型在推論時檢索並引用。
**適用：**
- 知識常更新（政策、制度、產品規格）
- 需要引用與可稽核
- 需要權限控管與資料分層（tenant/role）
**風險：**
- 檢索不到、檢索不相關、引用錯誤、版本過期（freshness）

### 1.2 參數式：微調（Fine-tuning / PEFT）
**概念：** 把知識或行為注入模型參數。
**適用：**
- 主要是「行為」：格式一致性、分類、路由、工具選擇策略
- 固定領域語彙與風格（但需可控與可驗證）
- 大量重複模式（例如結構化抽取）
**風險：**
- 知識過期難更新（需重新訓練）
- 可能記住敏感資訊（資料外洩風險）
- 不一定可引用、可稽核性較弱（除非搭配 RAG）

### 1.3 工具式：外部資料源（DB/API/KG）+ Tool calling
**概念：** 知識在權威系統（source of truth），LLM 只負責決策與編排。
**適用：**
- 需要強一致性（庫存、訂單、病歷查詢、權限嚴格）
- 需要交易性與審核（write operations）
**風險：**
- 工具越權與 prompt injection
- 工具失敗需可靠性策略（retry/backoff/circuit breaker/fallback）

---

## 2. 決策矩陣（高命中：RAG vs 微調 vs 工具）
用下表做快速決策（考試常以情境題呈現）：

### 2.1 先判斷：是「知識」還是「行為」？
- **知識新增**（facts、規章、內容會更新）→ 先選 **RAG / 工具式**
- **行為校準**（格式、分類、路由、工具選擇）→ 先選 **微調 / 提示工程 / 規則**

### 2.2 需要可稽核引用？資料更新頻率高？
- 需要引用、且更新頻繁 → **RAG（版本化 + time filter）**
- 不需要引用、且相對穩定 → 可考慮 **微調**（仍需合規與資料治理）

### 2.3 合規與授權（決策門檻）
- 若資料有授權/隱私限制，**不適合進參數** → 優先 **RAG + 權限控管** 或 **工具式查詢**

### 2.4 latency/cost 的常見折衷
- 超低延遲、固定問題型態 → 可能偏向 **微調 + 小模型**
- 高正確與可追溯、可接受稍高延遲 → **RAG + rerank + citation-check**
- 強一致性、需交易可靠 → **工具式（source of truth）**

---

## 3. RAG 的「新增知識」工程流程（你要講得出來）
### 3.1 資料準備（ingest）
- 文件切分（chunking）：以語意邊界為主，避免把條件與例外拆開
- metadata：版本、日期、來源、權限標籤（role/tenant）
- 索引版本化：`index_version` 必須可回放

### 3.2 檢索與重排
- retrieval：embedding + top-k
- rerank：提高 precision（避免答非所問）
- time filter / version filter：解 freshness

### 3.3 生成與引用
- 引用後生成（先鎖證據再生成）
- citation-check：避免 citation mismatch
- 低信心轉人工：human-in-the-loop

---

## 4. 微調的「新增知識」：你要懂限制在哪裡
### 4.1 微調更擅長什麼
- 結構化輸出（抽取/分類/路由）
- 特定格式與語氣一致性（例如固定報告樣式）
- 工具使用策略（但需配合 tool policy）

### 4.2 微調不擅長什麼（考點）
- 頻繁更新的事實（容易過期）
- 需要引用與可稽核的條文（除非仍搭 RAG）
- 敏感/授權資料（外洩風險）

### 4.3 何時用 PEFT（LoRA 等）
- 資源有限、需要快速迭代
- 希望可 rollback（切換 adapter）
- 仍要搭配評估與版本控制

---

## 5. 安全與治理（Adding Knowledge 的常考陷阱）
- **資料最小化**：只收必要資料
- **可刪除性**：使用者要求刪除/撤回時，參數式難；RAG/工具式較可控
- **權限控管**：RAG 的 retrieval filter / 工具的 RBAC
- **提示注入**：尤其 tool calling 要做 policy gate

---

## 6. 最小驗收（你可以當 Week 7/8 的交付）
- [ ] 有「決策矩陣」：能說清楚為何選 RAG/微調/工具式
- [ ] RAG 有 index_version、time filter、metadata 權限標籤
- [ ] 有 citation-check 或引用後生成流程
- [ ] 微調（若有）有資料治理與避免敏感資訊的機制
- [ ] 失效策略：降級/轉人工/rollback（adapter 或索引版本）

---

# 題庫（15 題｜偏難版）

## Q01.（RAG vs 微調）
某制度每月更新一次，且需要在回答中提供可稽核引用。最合適方案為？
A) 直接微調模型把制度背起來
B) RAG（版本化 + time filter + 引用）
C) 只用更大模型
D) 只要求模型「請回答最新」
✅ 正確答案：B
為何正確：更新頻繁且要引用，RAG 最符合可稽核與可更新。
其他選項為何錯：A 過期難更新且有外洩風險；C 不解版本；D 不可靠。

## Q02.（工具式）
你需要查詢即時庫存與下單，且必須符合權限與交易一致性。最佳做法是？
A) 用 RAG 把庫存文件放進向量庫
B) 用 tool calling 查詢權威系統（source of truth），並做 RBAC
C) 直接微調
D) 讓模型自行推測
✅ 正確答案：B
為何正確：即時與交易一致性應由權威系統處理。
其他選項為何錯：A 會過期；C/D 不符合一致性與稽核。

## Q03.（行為 vs 知識）
你要改善輸出格式一致性（固定 JSON schema），且內容本身不常更新。較合理做法是？
A) 先考慮微調/提示工程，並加結構化驗證
B) 一律 RAG
C) 只加大 top-k
D) 只加大模型
✅ 正確答案：A
為何正確：這是行為校準/格式問題，不是知識更新問題。
其他選項為何錯：B 不對症；C/D 無直接關聯。

## Q04.（敏感資料）
若訓練資料含敏感個資，最不建議的作法是？
A) 先做資料去識別與最小化
B) 優先選 RAG/工具式，並做權限控管
C) 直接把資料微調進參數以提升“記憶”
D) 加入存取紀錄與稽核
✅ 正確答案：C
為何正確：把敏感資料寫進參數有外洩與不可刪除風險。
其他選項為何錯：A/B/D 是必要治理。

## Q05.（freshness）
RAG 系統常引用舊版條文，最有效的第一步是？
A) 加大 top-k
B) 建立 index_version 與 time/version filter，並在 trace 中記錄條件
C) 改用更大模型
D) 取消引用
✅ 正確答案：B
為何正確：freshness 需用版本與檢索條件落地。
其他選項為何錯：A 不對症；C 無保證；D 破壞稽核。

## Q06.（PEFT/LoRA）
採用 LoRA 的一個重要好處是？
A) 一定比全參數微調準確
B) 可快速切換/回復（rollback）不同 adapter，降低迭代成本
C) 會自動提供引用
D) 不需要評估
✅ 正確答案：B
為何正確：PEFT 的工程優勢在於快速迭代與可回復。
其他選項為何錯：A/C/D 不成立。

## Q07.（引用與可稽核）
微調後的模型要做到可稽核引用，最常見做法是？
A) 讓模型自行編引用
B) 仍搭配 RAG 或工具式取得證據，並引用後生成
C) 只靠 system prompt
D) 不需要引用
✅ 正確答案：B
為何正確：引用需要外部證據鏈與驗證機制。
其他選項為何錯：A 會產生錯誤引用；C 不可靠；D 不符合題意。

## Q08.（資料更新頻率）
當資料更新頻率極高（每日甚至每小時），較合理的路徑是？
A) 微調
B) 工具式查詢權威系統或即時資料源
C) 只加大模型
D) 只改 prompt
✅ 正確答案：B
為何正確：高頻更新不適合寫進參數。
其他選項為何錯：A 不可維護；C/D 不解更新。

## Q09.（資料集汙染）
將線上輸入直接納入微調資料，最大風險之一是？
A) 模型一定變好
B) 資料洩漏與把錯誤/攻擊內容學進參數（prompt injection 進化）
C) latency 下降
D) 不需要治理
✅ 正確答案：B
為何正確：線上資料可能包含攻擊、錯誤、敏感資訊，需要治理與過濾。
其他選項為何錯：A/C/D 不成立。

## Q10.（chunking）
RAG 的 chunking 若把「條件」與「例外」拆開，最可能導致？
A) Recall 變高
B) Answer completeness 下降（漏掉例外）並導致錯誤結論
C) latency 一定下降
D) 不影響
✅ 正確答案：B
為何正確：語意邊界切錯會造成生成時只看到半套規則。
其他選項為何錯：A/C/D 不必然。

## Q11.（metadata filter）
多租戶（multi-tenant）RAG 中最重要的控制是？
A) 把 top-k 變大
B) retrieval metadata filter（tenant/role）與存取稽核
C) 只用更大 embedding
D) 不需要控制
✅ 正確答案：B
為何正確：多租戶需要權限隔離，避免資料外洩。
其他選項為何錯：A/C 不解權限；D 明顯錯。

## Q12.（rollback）
當 RAG 更新索引後品質下降，最可控的處置是？
A) 直接覆蓋舊索引
B) 以灰度釋出並保留 index_version，可快速切回舊版本
C) 只要求模型更小心
D) 取消檢索
✅ 正確答案：B
為何正確：版本化與灰度釋出讓 rollback 可行。
其他選項為何錯：A 無法回復；C 不可靠；D 失去能力。

## Q13.（何時“真的需要”微調知識）
下列哪個情境最可能需要微調來補強知識？
A) 文件每天更新且要引用
B) 內容高度穩定、同一類問題大量重複，且模型需要在不檢索時也能掌握基本術語與分類邏輯
C) 需要即時庫存
D) 需要權限隔離
✅ 正確答案：B
為何正確：穩定且大量重複模式，微調可提升一致性與效率（仍需合規）。
其他選項為何錯：A 適合 RAG；C 適合工具式；D 需 RBAC。

## Q14.（新增知識的評估）
新增知識後要確認有效，最合理的做法是？
A) 只看單次 demo
B) 建立固定評估集，記錄版本，並同時評估 groundedness/freshness/citation correctness
C) 只看 token 數
D) 只看 latency
✅ 正確答案：B
為何正確：新增知識必須可回放與可量化驗證。
其他選項為何錯：A 不可重現；C/D 不完整。

## Q15.（組合策略）
下列哪個組合最符合「可更新 + 可稽核 + 可維運」？
A) 只微調
B) RAG + tool policy + 版本化 + 監控/回溯
C) 只改 prompt
D) 只加大模型
✅ 正確答案：B
為何正確：可更新與可稽核需資料層與治理機制，並結合工具與監控。
其他選項為何錯：A/C/D 都缺少核心治理。

---

# 案例題（2 題｜情境題）

## Case 1：RAG vs 微調決策（制度類）
你要做一個「醫療制度」問答系統：制度每月更新、必須引用條文段落、且不同醫院有不同權限。請提出：
1) 你的決策（RAG/微調/工具式）與理由
2) metadata 設計（至少 6 個欄位，含版本/權限）
3) freshness 的處理（index_version/time filter/灰度）
4) 最小驗收清單（至少 6 項）

## Case 2：格式一致性（抽取/分類）
你要把長文病摘轉成固定 JSON（欄位完整且格式一致），且內容本身相對穩定。請提出：
1) 你會用微調、提示工程、還是兩者混合？
2) 你如何避免敏感資訊被學進參數？（資料治理策略）
3) 你如何建立評估（固定題庫 + 結構化驗證 + 錯誤分類）

---

## Deploying RAG Pipelines for Production at Scale（8 小時）

> 來源：`05_course_deploy_rag_scale/guide.md`

# Deploying RAG Pipelines for Production at Scale（8 小時｜讀書會版講義）

> 目的：把 RAG/Agent 從 PoC 做到可上線、可擴展、可維護、可稽核。
> 考試常考「部署決策題」：你要能在 cost/latency/reliability/security 之間做取捨，並提出具體工程措施（SLO、佇列、快取、灰度、rollback、觀測、事件回溯）。

---

## 0. 考點對齊（高命中）
你要能回答：
1) 什麼時候要用 **佇列/非同步**？什麼時候要同步？
2) cache 放哪裡（retrieval、rerank、LLM 回覆）？cache key 怎麼設計？
3) 版本控管與灰度釋出怎麼做（prompt/index/model）？rollback 怎麼做？
4) 觀測（logging/tracing/metrics）要收哪些欄位才可事故回溯？
5) 安全：如何防 prompt injection、越權工具調用、資料外洩？

---

## 1. 上線架構最小切分（可被考成架構題）
典型 RAG pipeline（production）：
1) API Gateway（rate limit / auth）
2) Orchestrator（state machine / policy gate）
3) Retrieval service（vector DB + filters + versioning）
4) Rerank service（可選）
5) LLM inference（可自架或託管；要有 timeout）
6) Citation check（可選但很加分）
7) Observability（trace/log/metrics）
8) Feedback & Eval（線上抽樣、離線回放）

> 關鍵：把每一段做成「可替換、可降級」的模組，而不是一個黑盒。

---

## 2. SLO / SLI（常考：要會講 p95/p99）
### 2.1 你至少要定三個 SLO
- latency：p95 < X ms（不同路徑不同 SLO）
- availability：成功率（不含使用者錯誤）
- quality proxy：無引用回答比例、fallback rate、負回饋率

### 2.2 常見陷阱
- 只看平均 latency：尾延遲（p99）才會造成“卡住”的體感
- 只看 QPS：品質漂移不會反映在 QPS

---

## 3. Scaling（擴展策略：先解瓶頸再加資源）
### 3.1 Top bottlenecks（常見）
- 向量檢索：索引大小、filter、跨區延遲
- rerank：算力吃緊
- LLM 推論：GPU、batching、上下文長度
- IO：文件載入、metadata 查詢

### 3.2 擴展策略
- 水平擴展：stateless service + autoscaling
- 佇列：吸收尖峰（burst），避免下游被打爆
- 動態路由：低風險/高命中走快路徑，高風險走慢路徑（加 rerank/critic）

---

## 4. Cache（考試很愛問“放哪裡”）
### 4.1 三層快取
1) **Retrieval cache**：query → retrieved_doc_ids
2) **Rerank cache**：query+candidate → reranked list
3) **LLM response cache**：prompt hash → answer（需注意個資與權限）

### 4.2 cache key 設計（偏難）
至少要包含：
- user/tenant/role（避免跨權限命中）
- index_version（避免過期）
- prompt_template_version（避免不同版本混用）
- query normalization（避免同義不同字造成 miss）

---

## 5. 版本控管、灰度與 rollback（必考）
你至少有三種版本要控：
- **index_version**（資料）
- **prompt_template_version**（提示模板）
- **model_version**（embedding/rerank/LLM）

### 5.1 灰度釋出
- 1% → 5% → 25% → 100%（依風險與監控調整）
- 同步監控：quality proxy + latency + cost

### 5.2 rollback
- index：切回舊版本
- prompt：切回舊模板
- model：切回舊模型或關閉 rerank/critic（降級）

---

## 6. Observability（你要能列出“欄位清單”）
### 6.1 Logging（事件）
- trace_id, user_id/tenant/role（可匿名化）
- index_version, prompt_version, model_version
- retrieved_doc_ids + scores
- tool_calls（若 agent）
- policy_decision（允許/拒絕/轉人工/降級）
- error_code, duration_ms（每段）

### 6.2 Metrics（指標）
- latency p50/p95/p99（分路徑）
- timeout rate、fallback rate、cache hit rate
- cost（token/請求、GPU 時間）
- 無引用回答比例、引用錯誤比例（抽樣）

### 6.3 Tracing（鏈路）
- 讓你能回答：這次慢在哪一段？哪個服務？哪個版本？

---

## 7. Reliability（上線必備）
- timeout（每段都要有）
- retry/backoff（僅針對暫時性錯誤）
- circuit breaker（避免級聯失敗）
- fallback（降級策略）
- idempotency（有副作用工具必備）

---

## 8. Security（常考：prompt injection / data exfiltration）
- tool policy gate：工具白名單 + 最小權限
- retrieval filter：tenant/role/time
- PII 防護：日誌遮罩、cache 不跨權限
- 事件回溯：安全事件要記 trace_id 與決策理由

---

## 9. 最小驗收（你可以當 Week 6/7 的交付）
- [ ] 3 個版本（index/prompt/model）可追蹤與可 rollback
- [ ] 有灰度釋出流程與監控閾值
- [ ] 有 3 層快取策略（至少實作 1 層）
- [ ] 有 SLO/SLI（含 p95/p99）
- [ ] 有完整 observability 欄位清單（可事故回溯）
- [ ] 有安全策略（policy gate + filter + 日誌遮罩）

---

# 題庫（15 題｜偏難版）

## Q01.（SLO）
為什麼 production 會更重視 p95/p99 latency，而不是平均 latency？
A) 平均值一定錯
B) 尾延遲決定使用者“卡住”的體感與超時風險
C) p95/p99 比較好看
D) 平均值不能計算
✅ 正確答案：B
為何正確：尾延遲會直接造成 timeout、重試、與體感崩壞。
其他選項為何錯：A/C/D 不成立。

## Q02.（佇列）
下列哪個情境最適合用佇列（queue）？
A) 低延遲即時對話回覆且每次必須同步完成
B) 尖峰流量會打爆下游，允許非同步處理或延後回覆
C) 只為了讓架構更複雜
D) 只要用佇列就不需要監控
✅ 正確答案：B
為何正確：佇列可吸收 burst，保護下游服務。
其他選項為何錯：A 不一定適合；C/D 錯。

## Q03.（cache key）
LLM response cache 的 key 若沒包含 tenant/role，最大風險是？
A) latency 下降
B) 跨權限命中造成資料外洩
C) cost 一定下降
D) 不影響
✅ 正確答案：B
為何正確：cache 命中可能把不該看的內容給另一個權限。
其他選項為何錯：A/C/D 不成立。

## Q04.（版本）
要能事故回溯與比較，最少要記錄哪些版本？
A) 只記 LLM 版本
B) index_version、prompt_template_version、model_version（含 embedding/rerank/LLM）
C) 只記時間
D) 不需要記錄
✅ 正確答案：B
為何正確：RAG 的行為受資料、提示與模型共同影響。
其他選項為何錯：A/C/D 不足或錯。

## Q05.（灰度）
灰度釋出最主要目的是？
A) 讓所有人同時受影響
B) 降低風險，先用小流量驗證品質與成本，再逐步擴大
C) 增加成本
D) 取代測試
✅ 正確答案：B
為何正確：灰度讓問題在小範圍被偵測並可 rollback。
其他選項為何錯：A/C/D 不成立。

## Q06.（rollback）
索引更新後品質下降，最可控的處置是？
A) 直接覆蓋舊索引
B) 切回舊 index_version，並保留問題版本供分析
C) 只改 prompt
D) 取消檢索
✅ 正確答案：B
為何正確：版本化是可回復的前提。
其他選項為何錯：A 無法回復；C/D 不對症。

## Q07.（觀測欄位）
下列哪個欄位最能幫助判斷「答錯是因為檢索還是生成」？
A) retrieved_doc_ids + scores
B) 使用者名稱
C) UI 顏色
D) 只看 token 數
✅ 正確答案：A
為何正確：檢索結果可直接判斷是否找得到/找得準。
其他選項為何錯：B/C/D 無關。

## Q08.（動態路由）
為何要做動態路由（fast path vs safe path）？
A) 讓系統更難維護
B) 在成本與可靠性之間做條件式取捨：高風險才啟用 rerank/critic
C) 讓 prompt 變長
D) 取代快取
✅ 正確答案：B
為何正確：把重資源用在需要的情境，提升性價比。
其他選項為何錯：A/C/D 不成立。

## Q09.（circuit breaker）
circuit breaker 開啟後，最合理的行為是？
A) 繼續狂打下游直到恢復
B) 快速失敗並走 fallback，待 half-open 再試探恢復
C) 直接刪除所有資料
D) 關閉監控
✅ 正確答案：B
為何正確：斷路器用於保護系統並逐步恢復。
其他選項為何錯：A/C/D 錯。

## Q10.（retry）
下列哪種情境不適合重試？
A) 暫時性網路抖動
B) RATE_LIMIT（可退避重試）
C) PERMISSION_DENIED（權限不足）
D) 服務短暫過載
✅ 正確答案：C
為何正確：權限不足是永久性錯誤，重試無用且可能造成噪音。
其他選項為何錯：A/B/D 可視為暫時性。

## Q11.（資料外洩）
多租戶 RAG 中，哪個機制最直接降低資料外洩風險？
A) top-k 變大
B) retrieval filter（tenant/role）與日誌遮罩
C) 更大模型
D) 取消引用
✅ 正確答案：B
為何正確：權限隔離與遮罩是直接控制。
其他選項為何錯：A/C/D 不對症。

## Q12.（成本控制）
要降低成本但不顯著影響品質，最合理做法是？
A) 把 top-k 加到 100
B) 先做 cache + 動態策略（只在必要時 rerank/critic）
C) 只換更大模型
D) 取消監控
✅ 正確答案：B
為何正確：cache 與動態策略通常是最有效的成本槓桿。
其他選項為何錯：A 成本爆；C 更貴；D 風險大。

## Q13.（citation-check）
加入 citation-check 的主要價值是？
A) 讓答案更長
B) 降低 citation mismatch、提升可稽核性
C) 降低 QPS
D) 取代 retrieval
✅ 正確答案：B
為何正確：citation-check 解的是證據對齊與稽核。
其他選項為何錯：A/C/D 不成立。

## Q14.（事件回溯）
postmortem 最需要的關鍵資料是？
A) 只有使用者抱怨內容
B) trace_id + 版本（index/prompt/model）+ 各段 duration/error_code + policy_decision
C) 只有 UI 截圖
D) 只有 GPU 使用率
✅ 正確答案：B
為何正確：事故回溯要能重現與定位瓶頸/錯誤。
其他選項為何錯：A/C/D 不足。

## Q15.（快取風險）
把 LLM response cache 開到最大且不設 TTL/版本，最可能造成？
A) 永遠正確
B) 過期答案長期被重複命中（freshness 事故）
C) 讓系統更安全
D) 取代資料版本化
✅ 正確答案：B
為何正確：快取若不含版本與 TTL，會放大過期問題。
其他選項為何錯：A/C/D 不成立。

---

# 案例題（2 題｜情境題）

## Case 1：上線架構與 SLO 設計
你要把一個 RAG 系統上線給 3 家醫院使用（多租戶、權限不同）。請提出：
1) 你的最小架構切分（至少 6 個模組）
2) 你要定義的 SLO/SLI（至少 5 個，含 p95/p99）
3) 你的 observability 欄位清單（至少 10 個）
4) 你的灰度釋出與 rollback 流程（含 index/prompt/model）

## Case 2：尖峰流量與成本暴增
讀書會 demo 後爆紅，尖峰流量讓 LLM 推論成本暴增、p95 延遲飆高。請提出：
1) 你會先加哪一層快取（retrieval/rerank/LLM）與 cache key 設計
2) 你會如何用佇列/動態路由做降載
3) 你會如何設計 fallback（低風險快路徑 vs 高風險慢路徑）
4) 你要新增哪些監控與告警閾值（至少 6 個）