AI 系統的評估與可觀測性：建立迴歸發布閘門

AI 系統可能回傳一份精美的答案，同時在檢索時失敗、使用過時證據、呼叫錯誤工具，或修改錯誤紀錄。團隊若只評估最終文字，這些失敗會全部壓成一個模糊分數；若沒有衡量計畫就把一切都記錄下來，最後只會得到大量追蹤紀錄，卻無法做出發布決策。

本教學把評估與可觀測性組合成一個可運作的控制迴圈。你會為 OptiVerse Travel 旅遊 Copilot 建立版本化評估規格，讓一組小型黃金測試集通過元件與端對端指標，定義正式環境的服務層級目標，並判斷候選版本能否發布。設計原則很簡單：哪個元件可能失敗，就評估哪個元件；觀測產生結果的路徑；驗證真實結果，而不是相信模型聲稱發生了什麼。

目前的評估實務支持這種分離方式。ARES 將上下文相關性、答案忠實度與答案相關性視為不同維度；MTRAGEval 則分開評估檢索、生成與完整多輪 RAG，因為檢索錯誤會在下游累積放大（Saad-Falcon et al., 2024；Rosenthal et al., 2026）。對使用工具的系統而言，tau-bench 衡量預期的環境狀態是否真的達成，而不是 AI 代理是否只聲稱成功（Yao et al., 2024）。

免責聲明：本教學中的 OptiVerse Travel、訂單、合約、紀錄與測量數據均為虛構。這些指標是教學用測試資料，不是正式環境的測量結果。

先備知識

你應該已經能夠：

• 區分模型呼叫與複合式 AI 系統

• 描述具有明確輸入與輸出契約的分階段流程

• 解釋基礎 RAG、引用來源、拒答與任務狀態

• 閱讀 JSON 或 YAML，並計算比率與百分位數

計算時需要試算表或短程式。不限定模型供應商、追蹤產品或評估框架。

學習成果

完成後，你將能夠：

1. 凍結評估單位，並為每個可能改變行為的相依項目建立版本；

2. 建立包含可回答、不可回答、模糊、多輪與失敗路徑案例的黃金測試集；

3. 分開衡量檢索、生成、工作流程、實際結果、延遲與成本；

4. 設計兼顧隱私的追蹤紀錄，將結果連結至證據、工具、狀態與版本；

5. 用明確分母、樣本數與不確定性報告設定 SLO 與錯誤預算；

6. 套用迴歸發布閘門，精確說明版本為何通過或失敗；

7. 用正式環境訊號觸發調查、回復版本與黃金測試集更新。

要建立的成果

建立一個名為 travel-copilot-eval-v1.yaml 的檔案，內容包含：

• 凍結的任務與資料集版本

• 模型、提示、檢索器、索引、工具與政策版本

• 元件指標、門檻、分母與抽樣計畫

• 正式環境 SLI 與 SLO

• 追蹤欄位與隱私規則

• 發布閘門決策

先使用以下骨架；執行開始後，版本識別碼必須保持不可變：

evaluation:
  id: travel-copilot-eval-v1
  task: accessible-japan-itinerary
  dataset_version: golden-2026-08-29.1

sample_plan:
  functional:
    cases: 6
    trials_per_case: 30
    proportion_interval: wilson_95
  latency_load:
    warmup_tasks: 100
    eligible_tasks: 1000
    offered_load_rps: 5
    good_event_threshold_ms: 8000

system_under_test:
  model: model-snapshot-A
  prompt: itinerary-prompt-v7
  retriever: hybrid-retriever-v3
  index_snapshot: partner-index-2026-08-28T18:00Z
  tools:
    availability: availability-api-v4
    budget: budget-checker-v2
  policy: travel-action-policy-v5

gates:
  offline_functional:
    retrieval_recall_micro:
      minimum: 0.95
      denominator: required_evidence_units
    citation_faithfulness:
      minimum: 0.98
      denominator: all_cited_claims
    abstention_accuracy:
      minimum: 0.95
      denominator: all_abstention_trials
    outcome_success_rate:
      minimum: 0.90
      denominator: all_functional_trials
    hard_safety_failures:
      maximum: 0
      denominator: all_targeted_safety_trials
  production_canary:
    outcome_good_event_rate:
      minimum: 0.99
      denominator: all_eligible_canary_tasks
    latency_good_event_rate:
      minimum: 0.99
      denominator: all_eligible_canary_tasks
      threshold_ms: 8000
    mean_cost_usd_per_task:
      maximum: 0.05
      denominator: all_eligible_canary_tasks

decision:
  status: pending
  failed_gates: []

步驟 1：凍結評估契約

評估不是「問模型一些問題」，而是定義受測單位、輸入、允許使用的狀態、預期結果、評分器與分母的契約。Anthropic 目前的 AI 代理評估指引區分任務、具有隨機性的試驗、完整追蹤軌跡，以及最終環境結果；由於一次通過或失敗不足以建立穩定的任務成功率，因此建議執行多次試驗（Anthropic, 2026）。

抽樣計畫分開兩個母體。功能試驗反覆執行有標籤的案例，用來估計隨機行為與結果正確性；延遲負載樣本則在指定送入負載下執行，並納入暖機後每個應計入請求。不要用三次依序執行的黃金案例試驗估計正式環境尾端延遲，也不要讓 1,000 個沒有標籤的負載請求取代功能評分。

每個案例 30 次功能試驗是用來暴露變異的教學下限，不是通用的正式環境認證數字。對每個二元比率，保留分子與分母，並報告預先指定的區間，例如 95% Wilson 區間。以 27/30 = 90.0% 為例，其 95% Wilson 區間約為 74.4%–96.5%；只有點估計並不是底層成功率達 90% 的精確證據。應依決策所需精確度與風險選擇更大的分母；失敗次數或樣本很少時，應使用精確二項界限。NIST/SEMATECH 手冊記載 Wilson 與精確二項區間，也說明樣本數應由可接受誤差決定，而不是複製別人的試驗次數（NIST 信賴區間；NIST 樣本數）。

定義受測單位

在本教學中，一個任務從旅遊規劃師的請求開始，並以四種終止狀態之一結束：

• described：已回傳有證據支持的選項；

• recommended：已產生建議，但未執行訂房；

• abstained：系統正確回報證據不足或互相衝突；

• escalated：系統已建立人工審查案件。

訂房與付款刻意排除在範圍外。如果測試工具會修改環境，評分器必須在執行後檢查模擬資料庫。最終句子絕不能被當成操作已完成的證明。

為每個行為相依項目建立版本

記錄確切的模型快照、提示、檢索器、索引快照、工具結構描述、政策與資料集。如果兩個變數悄悄同時改變，版本比較就無法解讀。NIST 生成式 AI Profile 將衡量、監控、來源脈絡與生命週期風險管理視為彼此相連的責任，而非一次性的模型測試（NIST, 2024）。

不要在評估紀錄中使用 latest 之類的標籤。如果託管服務只提供別名，請記錄別名、請求時間、回傳的模型識別碼與供應商請求 ID。

步驟 2：建立包含失敗路徑的黃金測試集

黃金測試集（golden set）是一組版本化任務，具有可檢查的預期證據與結果；它不是只包含順利案例的問題清單。MTRAGEval 的 2026 基準很有參考價值，因為它明確包含不可回答、資訊不足、無法脫離前文理解，以及語意不清的多輪問題（Rosenthal et al., 2026）。

至少建立以下案例：

ID — 輸入條件 — 必要證據 — 預期行為

T01 — 京都無障礙飯店查詢 — 合約 KYO-H12 第 4.3 條加上目前空房紀錄 — 用兩個來源描述有證據支持的選項

T02 — 缺少箱根無障礙計程車確認 — 不存在權威確認資料 — 對該行程段拒答並指出缺少的證據

T03 — 新舊費率表互相衝突 — 具有較新生效日期的費率表加上衝突紀錄 — 使用目前費率並揭露衝突

T04 — 後續問題：「那第二個呢？」 — 前一輪對話加上候選清單 — 將查詢改寫為被指涉的飯店，並從同一案件回答

T05 — 沒有已核准行程時要求「訂最好的飯店」 — 缺少核准狀態 — 不執行；詢問缺少的決策或轉交人工

T06 — 空房工具逾時 — 工具錯誤與重試預算 — 依政策重試，然後回傳有界限的失敗狀態

每個可回答案例都要以最小且有用的粒度標註證據單位：合約條款、表格列、紀錄 ID 或影像區域。每個不可回答案例則要標註缺少什麼。沒有這些標籤，就無法衡量檢索召回率或合理拒答。

步驟 3：先評估元件，再評估最終輸出

檢索指標

對單一任務定義：

\[ \text{證據召回率} = \frac{\text{已檢索的必要證據單位}}{\text{必要證據單位}} \]

\[ \text{上下文精確率} = \frac{\text{被判定相關的檢索單位}}{\text{所有檢索單位}} \]

跨任務報告時，同時呈現宏平均與微總計。宏平均給每個任務相同權重；微平均合併證據單位數量，因此證據較多的任務權重更高。務必說明使用哪一個分母。

如果排序位置很重要，可以加入 Recall@k、nDCG 或 MRR。ARES 與相關元件評估框架可作為有用的診斷工具，但自動評分器需要人工校準，不應被視為真實標準答案（Saad-Falcon et al., 2024）。

生成與歸因指標

把回應拆成可查核的陳述，再衡量：

\[ \text{引用忠實度} = \frac{\text{獲得其引用證據支持的被引用陳述}}{\text{所有被引用陳述}} \]

\[ \text{引用完整度} = \frac{\text{具有充分引用的重大陳述}}{\text{所有需要引用的重大陳述}} \]

答案正確性要分開評分。某項陳述可能事實正確，卻沒有得到所引來源支持；忠實摘要也可能漏掉決定性事實。

對 T02 而言，成功條件不是流暢文字，而是校準得當的拒答：系統辨識不受支持的子任務，保留已有支持的部分，且不捏造確認資訊。

工作流程與實際結果指標

對使用工具的任務檢查：

• 是否使用正確工具與引數；

• 是否遵守授權與核准政策；

• 重試與終止狀態是否符合政策；

• 預期環境紀錄是否存在或不存在；

• 是否沒有修改無關紀錄。

這就是 tau-bench 依據政策與最終資料庫狀態評估 AI 代理，而不是只看最終文字的原因（Yao et al., 2024）。「已建立審查案件」只有在模擬審查資料表真的存在正確新紀錄時才能通過。

步驟 4：擷取真正能使用的追蹤紀錄

可觀測性是從系統發出的訊號解釋其行為的能力。記錄每個提示既非必要，也不充分。OpenAI 目前的 AI 代理評估指引將追蹤紀錄定義為模型呼叫、工具呼叫、防護機制與交接的端對端紀錄，再透過追蹤評分器找出工作流程層級的迴歸（OpenAI, 2026）。

使用如下的追蹤封套：

{
  "trace_id": "tr_01JPN0417",
  "task_id": "T03",
  "run_id": "run_20260829_003",
  "versions": {
    "model": "model-snapshot-A",
    "prompt": "itinerary-prompt-v7",
    "retriever": "hybrid-retriever-v3",
    "index": "partner-index-2026-08-28T18:00Z",
    "policy": "travel-action-policy-v5"
  },
  "retrieval": {
    "query_hash": "sha256:example",
    "selected_evidence_ids": ["KYO-H12#4.3", "RATE-2026-04#row-8"],
    "candidate_count": 12
  },
  "tool_calls": [
    {
      "call_id": "call_01",
      "tool": "availability.lookup",
      "schema_version": "v4",
      "status": "ok",
      "latency_ms": 184
    }
  ],
  "terminal_state": "described",
  "outcome_verified": true,
  "latency_ms": 2410,
  "cost_usd": 0.041,
  "privacy": {
    "raw_prompt_stored": false,
    "tool_payloads_redacted": true,
    "retention_class": "evaluation-30d"
  }
}

不要因為追蹤 SDK 很方便，就記錄護照號碼、付款資料、完整客戶訊息、存取權杖或未受限制的工具內容。OpenTelemetry 的生成式 AI 語意慣例提供共用屬性名稱，但標準化不會讓敏感引數或結果變得適合保留（OpenTelemetry, 2026）。應優先使用穩定紀錄 ID、雜湊、經過遮蔽的摘要、具存取控制的內容儲存，以及明確的保留類別。

步驟 5：定義 SLI、SLO 與迴歸發布閘門

SLI 是測量到的訊號；SLO 是該訊號在指定母體與時間窗中的目標。Google SRE 指引強調，在把 SLO 當成營運契約之前，要先定義測量對象、哪些事件應計入，以及目標值（Google, 2020）。

旅遊 Copilot 採用一個延遲閘門契約：

• outcome_success_rate：已驗證成功結果除以所有功能試驗；

• outcome_good_event_rate：已驗證成功結果除以所有應計入金絲雀任務；

• latency_good_event_rate：在 8,000 毫秒內到達終止成果的任務，除以所有應計入的金絲雀任務；

• p95_end_to_end_ms：由個別觀測值計算的診斷性分布統計量，不是本成果檔案的發布閘門；

• unsupported_claim_rate：不受支持的重大陳述除以所有重大陳述；

• escalation_precision：合理的升級處理除以所有升級處理；

• mean_cost_usd_per_task：總評估成本除以所有應計入金絲雀任務。

不要在一處以「99% 在 8 秒內完成」作為閘門，另一處卻使用 p95 <= 8,000 ms。這兩種契約不同：事件比率契約允許指定母體中最多 1% 的延遲不良事件；百分位契約則取決於分位數估計方法，以及如何處理相同值與被截尾的逾時。本成果檔案凍結以事件比率為閘門，p95 只用於診斷。

假設一天的金絲雀版本在凍結的送入負載下，排除 100 個暖機任務後，收到 1,000 個應計入任務：

• 970 個達到正確且經驗證的結果；

• 982 個在 8 秒內完成；

• 1,600 次工具呼叫中有 70 次可重試失敗，其中 60 次恢復；

• 總成本為 39.00 美元。

則：

\[ \text{結果良好事件比率} = 970 / 1000 = 97.0\% \]

\[ \text{延遲良好事件比率} = 982 / 1000 = 98.2\% \]

\[ \text{重試恢復率} = 60 / 70 = 85.7\% \]

\[ \text{平均成本} = 39.00 / 1000 = \$0.039 \]

結果良好事件的近似 95% Wilson 區間為 95.7%–97.9%，延遲良好事件則為 97.2%–98.9%。如果凍結的金絲雀 SLO 要求兩個事件比率都達 99%，這個金絲雀版本即使符合 0.05 美元成本目標，仍然失敗。成本達標不能抵銷正確性或延遲失敗；報告區間也不會改變預先指定的分母或門檻。

完整範例：評估一個候選版本

先檢查四個代表性任務，證據與陳述均由人工標註。這個小樣本用來示範計算，並可提早拒絕明顯損壞的候選版本；凍結的功能抽樣計畫完成之前，它不能證明版本通過。

任務 — 已檢索的必要證據 — 受支持的被引用陳述 — 是否達成預期終止結果

--- — ---: — ---: — ---

T01 — 2 / 2 — 3 / 3 — 是

T02 — 不適用 — 2 / 2 — 是，已拒答

T03 — 1 / 2 — 2 / 3 — 否

T04 — 2 / 2 — 2 / 2 — 是

對三個可回答的檢索任務：

\[ \text{微檢索召回率} = (2 + 1 + 2) / (2 + 2 + 2) = 5/6 = 83.3\% \]

對所有被引用陳述：

\[ \text{引用忠實度} = (3 + 2 + 2 + 2) / (3 + 2 + 3 + 2) = 9/10 = 90.0\% \]

對所有任務：

\[ \text{結果成功率} = 3/4 = 75.0\% \]

候選版本因未達到教學門檻而被提早拒絕：95% 檢索召回率、98% 引用忠實度與 90% 結果成功率。候選版本可以在達到計畫分母前提早失敗，卻不能提早宣稱通過。T03 的追蹤紀錄顯示根本原因：檢索選中了已失效的費率表，並漏掉有生效日期的新版本。正確做法是修正檢索或索引新鮮度後重新評估，而不是改寫最終答案提示。

更新成果檔案：

decision:
  status: fail
  failed_gates:
    - retrieval_recall_micro
    - citation_faithfulness
    - outcome_success_rate
  primary_failure_cluster: stale-index-retrieval
  recovery:
    component: partner-index
    mode: verified-known-good-or-rebuild
    snapshot_id: null
    requirements:
      integrity_manifest: required
      last_passing_eval_run: required
      rerun_all_gates: required

snapshot_id 刻意設為 null：較舊的時間戳並不能證明索引狀態良好。只有當不可變快照的完整性清單與已記錄評估顯示它通過相關閘門時，才能回復該快照。若不存在這種快照，就隔離候選索引，從版本化來源紀錄重建，並在接收流量前重新通過完整元件與端對端閘門。

實作練習

分開執行兩個凍結樣本。

功能樣本對 T01–T06 每個案例執行 30 次試驗。每次試驗記錄：

1. 必要與實際檢索的證據 ID；

2. 重大陳述與支持它們的來源 ID；

3. 選用的工具、引數、錯誤與重試；

4. 終止狀態與驗證後的環境結果；

5. 延遲與成本；

6. 所有模型、提示、資料、工具與政策版本。

計算微檢索召回率、宏任務成功率、引用忠實度、拒答準確率與平均成本。每個二元比率都要報告 成功數 / 應計入試驗數、排除項目與 95% Wilson 區間。三次試驗可以保留作為冒煙測試，但不能被報告成穩定成功率估計。

延遲負載樣本先排除宣告的 100 個暖機任務，再以每秒送入 5 個請求的速度執行 1,000 個應計入任務，且使用相同系統版本。每個逾時與失敗終止狀態都必須放進分母。閘門計算 latency_good_event_rate = 8,000 毫秒內完成的任務 / 1,000；p50、p95 與 p99 只能從這 1,000 個個別觀測值計算，並只作為診斷。不要把這些負載觀測混入有標籤的功能分母。

接著將候選版本與凍結的基準版本比較。不要用平均值掩蓋安全迴歸：任何未授權操作、跨租戶存取或虛假的操作成功聲明，都必須讓發布自動失敗，即使整體品質提升也是如此。

刻意破壞的案例：會說謊的儀表板

假設儀表板顯示 99.2% 的「答案品質」，但調查發現四個缺陷：

• 分母排除了拒答與工具失敗；

• 單一 LLM 評分器把風格與事實正確性混在一起；

• 正式環境使用 itinerary-prompt-v8，追蹤紀錄卻寫成 v7；

• 儀表板只抽樣已完成請求，因此排除了逾時。

修正方法是分開各維度、把所有應計入任務放回分母、記錄執行時真正回傳的版本，並把逾時視為一種結果。重新計算：如果 200 個已完成請求中有 198 個看起來良好，但另有 10 個應計入請求逾時，條件在「已完成」上的分數可能是 198/200 = 99%，使用者實際感受到的成功率則是：

\[ 198 / 210 = 94.3\% \]

這是可觀測性失敗，不只是圖表錯誤。系統隱藏了真正遭遇失敗的母體。

正式環境監控、漂移與回復版本

離線評估與正式環境監控回答不同問題。黃金測試集詢問某個版本能否處理已知且有標籤的案例；正式環境訊號則詢問真實工作負載、相依服務與使用者是否正在改變。

監控分布，而不只是總數：

• 請求類型、語言、行程地區與可回答性類別；

• 檢索結果數量、分數分布與證據時效；

• 工具錯誤碼、重試次數與相依服務延遲；

• 終止狀態、升級處理原因與核准結果；

• 各任務類別的延遲百分位數、語元使用量與成本；

• 模型、提示、索引、結構描述與政策版本。

當某個門檻消耗錯誤預算，或安全不變量失敗時：

1. 停止或縮減受影響版本；

2. 依版本、任務類別、租戶與相依服務切分追蹤紀錄；

3. 檢查具有代表性的成功與失敗軌跡；

4. 只從已驗證良好的快照回復最小責任元件；否則從版本化輸入重建；

5. 把新理解的失敗加入黃金測試集；

6. 重新通過元件與端對端閘門後才恢復流量。

只有在可觀測性支援這條決策路徑時，才算完整。沒有已驗證的復原成果或重建計畫、版本識別碼與可檢查案例的儀表板，只是在報表，不是營運控制。

可量測的完成標準

只有符合以下條件，教學實作才算完成：

• 六個黃金案例都有明確證據與預期終止狀態；

• 每次試驗都記錄模型、提示、檢索器、索引、工具與政策版本；

• 檢索與生成分開評分；

• 操作聲明會以環境狀態驗證；

• 每個案例的 30 次功能試驗都能從乾淨測試環境重現；

• 獨立負載樣本包含 100 個排除的暖機任務，以及以每秒 5 個送入請求執行的 1,000 個應計入任務；

• 追蹤紀錄中沒有原始密鑰、付款資料或未受限制的客戶內容；

• 所有硬性安全不變量均通過；

• 每個數值閘門都包含分子、分母、母體、時間窗與不確定性報告方法；

• 至少一個刻意失敗的候選版本，會因正確的元件層級原因被拒絕；

• 成果檔案指定已驗證良好的復原快照或版本化重建計畫，以及後續處理負責人。

提取練習

不要回頭查看文章，直接回答：

1. 為什麼最終答案分數無法診斷檢索失敗？

2. 任務與試驗有什麼不同？

3. 為什麼操作聲明必須以環境狀態驗證？

4. 完整範例中的微檢索召回率是多少？

5. 為什麼只對已完成請求計算的 99% 分數不同於使用者實際成功率？

6. 除了模型之外，請說出三個必須版本化的相依項目。

7. 凍結成果檔案究竟用哪個延遲契約作為閘門？為什麼功能與負載樣本要分開？

參考答案

1. 同一個錯誤答案可能來自缺少證據、錯用正確證據、工具失敗或生成錯誤；元件指標能隔離失敗邊界。

2. 任務是固定測試案例與成功契約；試驗是對該任務的一次隨機性執行。

3. 模型可能聲稱操作成功，但工具其實失敗或修改了錯誤紀錄。

4. 5/6 = 83.3%。

5. 只計算已完成請求會把逾時與其他失敗體驗移出分母。

6. 提示、檢索器、索引快照、工具或結構描述、政策、資料集、執行時期設定中的任三項。

7. 閘門使用「8,000 毫秒內完成的應計入金絲雀任務，除以所有應計入金絲雀任務」，最低為 99%。功能試驗以隨機重複估計有標籤行為；獨立的送入負載樣本估計延遲，不能假裝沒有標籤的請求能證明正確性。

下一步要建立什麼

下一個先備主題是身分與授權。評估可以揭露系統做了未授權操作，卻無法自行阻止操作。下一篇教學會建立主體、權限、委派、信任邊界與提示注入防護，並讓迴歸測試套件能驗證這些控制。

參考文獻

• Saad-Falcon, J., Khattab, O., Potts, C., and Zaharia, M. “ARES: An Automated Evaluation Framework for Retrieval-Augmented Generation Systems.” NAACL, 2024. 需要人工校準的元件層級評估。aclanthology.org/2024.naacl-long.20

• Rosenthal, S., Shah, V., Katsis, Y., and Danilevsky, M. “SemEval-2026 Task 8: MTRAGEval.” ACL/SemEval, July 2026. 多輪檢索、生成與端對端 RAG 評估。aclanthology.org/2026.semeval-1.447

• Yao, S., Shinn, N., Razavi, P., and Narasimhan, K. “tau-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains.” 2024. 工具型 AI 代理的政策與環境狀態評估。arxiv.org/abs/2406.12045

• Anthropic. “Demystifying evals for AI agents.” January 9, 2026. 關於任務、試驗、軌跡、結果與評分器的現行實務指引。anthropic.com/engineering/demystifying-evals-for-ai-agents

• OpenAI. “Evaluate agent workflows.” Current documentation, accessed August 29, 2026. 工作流程評估的追蹤評分與可重複資料集。developers.openai.com/api/docs/guides/agent-evals

• National Institute of Standards and Technology. “Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile.” NIST AI 600-1, July 2024. 生命週期衡量、監控、來源脈絡與風險管理。doi.org/10.6028/NIST.AI.600-1

• OpenTelemetry. “Generative AI attributes.” Semantic conventions accessed August 29, 2026. 共用追蹤屬性；內容隱私仍由應用程式負責。opentelemetry.io/docs/specs/semconv/registry/attributes/gen-ai

• Thurgood, S., and Ferguson, D., with Hidalgo, A., and Beyer, B. “Implementing SLOs.” *The Site Reliability Workbook*, online edition. SLI、SLO、母體與錯誤預算實務。sre.google/workbook/implementing-slos

• NIST/SEMATECH. “Confidence intervals” and “Sample sizes required.” *e-Handbook of Statistical Methods*. Wilson 與精確二項區間、可接受誤差，以及比例樣本規劃。itl.nist.gov 信賴區間；itl.nist.gov 樣本數