跳到主要內容

IL 201 · 模組 3

原型建置

建立最小範圍的可重現原型,記錄版本、執行設定與人工接手方式。

開始第一節
已完成 0 / 3

學習目標

  • 把假設卡與評估計畫收斂成一個最小範圍(minimal-scope)的原型定義。
  • 建立可重現的執行紀錄:版本、時間、模型/工具、設定、輸入版本與人工判定者。
  • 設計人工接手(human handoff)路徑,讓 AI 不確定或超出範圍時能安全轉交給人。

從假設到可重現的原型

100 分鐘

定義最小範圍

原型的目的是產生可評估的證據,不是做出功能最完整的系統。最小範圍原型只需要涵蓋 Module 1 假設卡所指定的情境與案例類別,其餘功能留到後續階段。

最小範圍原型 checklist(沿用 SYN-CS-001)
項目說明
涵蓋案例類別只涵蓋假設卡指定的類別(例如一般、缺漏資訊),其餘類別標記為超出範圍
輸入來源固定使用 SYN-CS-001 的 documents/ 知識文件版本,不臨時混用未列版本的文件
輸出格式回覆初稿+引用來源,供人工核對,而非直接發送給客戶
明確排除項目列出本次原型「刻意不做」的功能,避免範圍蔓延

注意

常見錯誤:範圍蔓延(scope creep):為了讓 Demo 好看,逐步加入原本假設卡沒有涵蓋的案例類型或功能,結果評估結果無法對應到假設,Evidence Review 時說不清楚原型到底測了什麼。

重點: 原型的範圍必須和 Module 1 的假設卡一一對應,多做的部分不算「加分」,反而讓評估失去焦點。

100 分鐘

可重現的執行紀錄

Evidence Review 需要能回答「這個結果是在什麼版本、什麼設定下產生的」。沒有執行紀錄的結果無法被複查,也無法在下一階段重現。

Run log 最低欄位
欄位說明
run_id每次執行的唯一識別碼
prototype_version原型版本(例如 v0.3),對應程式碼或提示詞版本
run_timestamp執行時間
model_or_tool使用的模型/工具名稱與版本
config關鍵設定(例如提示詞版本、溫度、檢索文件數量上限)
input_version輸入資料(documents/ 知識庫)版本
human_rater人工判定者代碼(不使用真實姓名)
範例 run log 一列(合成資料)
run_id=RUN-014, prototype_version=v0.3, run_timestamp=2026-02-10T09:20, model_or_tool=demo-llm-v2, config=prompt_v3/top_k=5, input_version=docs_2026-02, human_rater=RATER-B

注意

常見錯誤:多次調整提示詞或設定卻只保留最後一版的結果,導致無法解釋「為什麼這次分數比上次高」;每次有意義的變更都應該留下對應的 run_id。

重點: 沒有版本、設定與輸入紀錄的評估結果,在 Evidence Review 時無法被追問,也無法被信任。

100 分鐘

人工接手路徑

原型必須明確定義「AI 不確定或超出範圍時怎麼辦」,而不是讓 AI 硬答一個看似合理但沒有根據的答案。人工接手路徑是 Human-AI-Human 原則在原型層級的具體實作。

人工接手路徑範例(客服知識問答)
  1. AI 嘗試在知識庫中找到相關文件
  2. 找不到足夠證據支持的答案 → 標記「無法回答」並附上已搜尋但不足的文件清單
  3. 轉交客服人員人工處理,附上 AI 已完成的搜尋紀錄(避免重工)
  4. 客服人員判斷後回覆客戶,並記錄此案例屬於「無答案」類別供後續分析

資訊

人工接手不是失敗,而是設計良好的原型的正常路徑之一;驗收集裡刻意包含「無答案」與「權限限制」類別案例,就是要驗證這條路徑是否真的被正確觸發,而不是被 AI 硬答掩蓋。
  1. 練習
    為你的原型畫出人工接手路徑,至少涵蓋「找不到足夠證據」與「超出既定案例類別」兩種觸發情境。
  2. 自我檢核
    確認你至少完整記錄了 3-5 次執行的 run log,並能對照假設卡說明本次原型「刻意不做」哪些事。
自我檢測

AI 原型在找不到足夠證據支持答案時,選擇「硬答一個聽起來合理的回覆」而不是轉交人工。這個設計最主要違反了什麼原則?

AI 原型在找不到足夠證據支持答案時,選擇「硬答一個聽起來合理的回覆」而不是轉交人工。這個設計最主要違反了什麼原則?

重點: 一個原型如果永遠不會觸發人工接手,通常代表它在不確定時仍然硬答,這對後續 Evidence Review 是警訊,不是優點。

接下來做什麼?