黃金樣本（Golden Samples）

提示：用 ←/→ 或底部按鈕換頁；點目錄可跳頁；點 ⤓ 可列印成 PDF。

• 同一個 prompt，不同時間/模型/資料狀態，結果可能不同。
• 錯誤常見不是「完全錯」，而是：缺一段、引用不對、推論過頭、口徑不一。
• 只做「人工抽查」成本高、覆蓋低；只做「AI 查 AI」又容易同源偏誤。
• 黃金樣本的目的：把品質問題變成可測試，讓每次改版都有回歸測試。

• Input：使用者問題 / 任務輸入（含情境、限制、必要欄位）。
• Context / Sources：允許使用的資料來源（RAG 文件集、版本、時間點）。
• Expected Output：標準輸出（可為文字、表格、JSON）。
• Acceptance Criteria：驗收規則（必備主張、必引來源、欄位格式、禁語/紅線）。
• Metadata：風險等級、更新頻率、責任人、建立/修訂日期、關聯系統版本。

1. 界定任務：先挑 1–3 個最常用、最關鍵的 AI 任務（例如：知識問答、抽取、分類）。
2. 選案例：每個任務先做 10–30 個案例，覆蓋典型情境 + 邊界情境 + 反例。
3. 定義驗收：把「正確」拆成規則（必備欄位、必引用、禁止推測、格式要求）。
4. 做標準答案：由 domain expert 或核可流程產生；必要時附「答案依據」。
5. 凍結資料版本：RAG 的文件/資料要有版本號（避免今天跑過、明天因文件更新而失敗）。
6. 加上 metadata：風險、責任人、更新頻率、最後驗證日期、關聯 prompt/模型版本。
7. 上 CI/排程：每次改 prompt / 模型 / 資料索引都跑一次；至少每日/每週跑一次回歸。

實務上先求「可以穩定跑」比追求「一次做很大」更重要。黃金樣本會在回補迴路中逐步成長。

提醒：只用「AI 查 AI」不夠；至少要搭配黃金樣本、抽查與結構化校驗。

• 缺資料：來源庫沒有、或檢索抓不到 → 補資料/metadata/索引權重。
• 切錯：chunk 太碎/太大、缺前後文 → 調 chunk 策略（重疊、引用、章節化）。
• 口徑不一：不同版本/不同文件矛盾 → 設定「單一權威來源」與版本策略。
• 推論過頭：沒有證據仍下結論 → 強制引用、禁止推測、把不確定改成追問。

• 以風險分級：高風險任務（合規、財務、工程、安全）要有更高覆蓋率與更嚴格門檻。
• 先做小集合：每個用例先 10–30 個，確保「跑得動、看得懂、修得了」。
• 拆成可自動檢查的規則：引用、欄位、格式、禁語、信心閾值、缺資料要追問。
• 把「引用」變成第一級 KPI：沒有來源＝不算通過（適用於需要可追溯的情境）。
• 不要只測平均：要測 P95、邊界案例、長文、噪音輸入（拼字錯、缺欄位）。
• 雙軌驗證：黃金樣本（固定）＋抽樣稽核（活的）＋結構化校驗（規則）。
• 版本控管：案例、資料、prompt、模型都要有版本；回歸失敗要能回溯。
• 標準答案要可追溯：答案背後要能說明依據（哪份文件、哪個條款/段落）。
• 定期汰換：每季檢視：過時案例刪除、加入新錯誤型態、更新權威來源。
• 把回補當 KPI：每次失敗都要結案：錯誤分類→修正→回歸通過→記錄。

建議資料夾結構

golden/
  README.md
  rag_qa/
    v1/
      cases/
        gs001.yaml
        gs002.yaml
      sources.lock.json
  extract_json/
    v1/
      schema.json
      cases/
        gs101.yaml
  decision_guardrails/
    v1/
      labels.json
      cases/
        gs201.yaml

建議單一案例格式（YAML）

# Golden Sample (YAML)
id: gs001
usecase: rag_qa
risk: high
owner: "ops-policy@company.com"
created_at: "2026-01-01"
last_verified_at: "2026-01-15"

# 1) 測試輸入
input:
  user_query: "公司的差旅報銷上限是多少？哪些費用不能報？"
  locale: "zh-Hant"

# 2) 檢索/資料鎖定（避免資料更新造成漂移）
retrieval:
  corpus: "travel_policy"
  sources_lock: "sources.lock.json"
  must_include_doc_ids: ["POL-TRAVEL-2025-10"]

# 3) 期望輸出（可文字或結構化）
expected:
  format: "markdown"
  must_have_claims:
    - claim: "上限金額"
      evidence_doc_id: "POL-TRAVEL-2025-10"
    - claim: "不可報項目"
      evidence_doc_id: "POL-TRAVEL-2025-10"
  forbidden:
    - "推測"
    - "未經核實"
  citation_required: true

# 4) 自動化檢查（可擴充）
checks:
  - type: "has_citations"
  - type: "claim_evidence_mapping"
  - type: "no_forbidden_phrases"
  - type: "max_tokens"
    value: 900

重點：案例本身要能獨立讀懂（含風險、資料鎖定、驗收規則），否則很難跨人/跨班交接。

• 範本 1：RAG 知識問答（強制引用＋主張對應證據）
• 範本 2：資料抽取→JSON（schema 驗證＋欄位紅線）
• 範本 3：分類/決策建議（標籤＋理由＋HITL／禁語）

• 目標：每個關鍵主張都要能對應到來源（段落/章節/文件 ID）。
• 常見失敗點：找不到正確文件、引用對但回答少一段、或引用不足仍下結論。
• 自動化可檢查：是否有引用、引用是否落在允許文件、必備主張是否出現。

id: rag_qa_001
usecase: rag_qa
risk: high
owner: "compliance@company.com"

input:
  user_query: "請說明公司資料保留（Data Retention）年限與例外情況。"
  audience: "internal_employee"

retrieval:
  corpus: "compliance_handbook"
  must_include_doc_ids: ["POL-DATA-RETENTION-2025-06"]
  must_exclude_doc_ids: ["DRAFT-*"]

expected:
  format: "markdown"
  structure:
    - heading: "結論"
    - heading: "適用範圍"
    - heading: "年限（按資料類型）"
    - heading: "例外與核准流程"
    - heading: "引用來源"
  must_have_claims:
    - claim_id: "retention-years-by-type"
      description: "每一種資料類型的年限（至少 3 類）"
      evidence:
        doc_id: "POL-DATA-RETENTION-2025-06"
        evidence_must_quote: true   # 可以用引用片段或段落編號
    - claim_id: "exception-approval"
      description: "例外需要誰核准、流程是什麼"
      evidence:
        doc_id: "POL-DATA-RETENTION-2025-06"
  citation_required: true
  forbidden:
    - "推測"
    - "可能是"
    - "我不確定但"

checks:
  - type: "has_citations"
  - type: "citations_in_allowed_docs"
  - type: "required_headings"
  - type: "claim_evidence_mapping"
  - type: "no_forbidden_phrases"
  - type: "max_length_chars"
    value: 2200

triage_on_fail:
  - if: "no_citations"
    action: "block_release"
  - if: "missing_required_claim"
    action: "open_bug:context_or_retrieval"
  - if: "forbidden_phrase"
    action: "open_bug:generation_guardrail"

最有效的一行：must_have_claims。它把主觀的「回答好不好」變成可檢查的最小集合。

• 目標：輸出固定 schema；欄位缺失要回傳 null 或提出追問，而不是亂補。
• 常見失敗點：日期格式亂、金額單位混、欄位幻覺、把推測當事實。
• 自動化可檢查：JSON 可 parse、通過 JSON Schema、欄位範圍、必填欄位。

JSON Schema（摘要版）

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "ContractSummary",
  "type": "object",
  "required": ["counterparty", "start_date", "end_date", "payment_terms", "termination_notice_days"],
  "properties": {
    "counterparty": { "type": ["string", "null"] },
    "start_date": { "type": ["string", "null"], "pattern": "^\d{4}-\d{2}-\d{2}$" },
    "end_date": { "type": ["string", "null"], "pattern": "^\d{4}-\d{2}-\d{2}$" },
    "payment_terms": { "type": ["string", "null"] },
    "termination_notice_days": { "type": ["integer", "null"], "minimum": 0, "maximum": 365 },
    "non_compete": {
      "type": "object",
      "required": ["exists", "duration_months"],
      "properties": {
        "exists": { "type": "boolean" },
        "duration_months": { "type": ["integer", "null"], "minimum": 0, "maximum": 120 }
      }
    },
    "open_questions": { "type": "array", "items": { "type": "string" } }
  }
}

黃金樣本案例（YAML）

id: extract_101
usecase: extract_json
risk: medium
input:
  text: |
    甲方：宏遠科技股份有限公司（下稱甲方）
    乙方：星辰資訊有限公司（下稱乙方）
    合約期間：自 2026/02/01 起至 2027/01/31 止。
    付款：每月月底結算，次月 15 日前匯款。
    終止：任一方欲終止，須於 60 天前以書面通知。
    競業：乙方不得於合約終止後 12 個月內招攬甲方客戶。

expected:
  json:
    counterparty: "星辰資訊有限公司"
    start_date: "2026-02-01"
    end_date: "2027-01-31"
    payment_terms: "每月月底結算，次月 15 日前匯款"
    termination_notice_days: 60
    non_compete:
      exists: true
      duration_months: 12
    open_questions: []
checks:
  - type: "json_parseable"
  - type: "json_schema"
    schema_file: "schema.json"
  - type: "no_extra_fields"  # 限制只允許 schema 欄位
  - type: "no_hallucinated_dates"

實務上最常見的回補：把日期/金額/單位的正規化規則寫進檢查器，而不是期待模型每次都「剛好做對」。

• 目標：輸出固定 label + 理由 + 下一步動作；遇到高風險要自動升級 Human-in-the-loop。
• 常見失敗點：分類猜測、理由胡扯、或越權承諾（例如法律/退款/合約）。
• 自動化可檢查：label 是否在白名單、理由是否引用輸入片段、是否觸發紅線詞。

id: decision_201
usecase: decision_guardrails
risk: high

labels_allowed: ["billing", "technical", "account", "legal", "security", "other"]

input:
  customer_email: |
    我們懷疑帳號被盜用，昨天晚上出現多筆異常登入與扣款。
    請立刻停用並退回所有費用，否則我們要提告。

expected:
  json:
    label: "security"
    priority: "P0"
    next_actions:
      - "要求客戶立即更改密碼並啟用 MFA"
      - "提供官方帳務爭議/退款流程連結（不得承諾一定退款）"
      - "建立資安事件工單並交由資安值班人員處理"
    must_ask:
      - "異常登入時間區間"
      - "最後一次確認正常使用的時間"
    forbidden:
      - "保證退款"
      - "法律建議"
    hitl_required: true
checks:
  - type: "label_in_allowlist"
  - type: "contains_must_ask_questions"
  - type: "no_forbidden_promises"
  - type: "hitl_flag_on_security_or_legal"

這類任務的黃金樣本，重點通常不在文字漂不漂亮，而是：不越權、會升級、會追問關鍵資訊。

第 1 週 盤點與定義

• 挑 1–3 個任務：RAG 問答 / 抽取 JSON / 分類分流
• 定義驗收門檻：引用合規率、schema 通過率、禁語率、HITL 觸發率

第 2–3 週 試辦與校正

• 每個任務先做 10–30 個黃金樣本（含邊界案例）
• 把檢查器接進 CI 或每日排程；失敗就產出「錯誤分類＋回補工單」

第 4 週 擴大與制度化

• 建立版本控管：案例、資料、prompt、模型、索引
• 每週例行：抽樣稽核 + 新增/汰換案例 + 回補結案

當黃金樣本成為 release gate，AI 才會從「個人效率」進化成「可交接的組織流程」。

• 黃金樣本讓你把 AI 的品質從「感覺」變成「數字」。
• 三層查核（R/C/G）＋回補迴路，讓錯誤可修、可追溯、可防再犯。
• 最有效的起手式：先做 10–30 個黃金樣本，接進 CI，每次改版都跑。