GPT‑5 調參實戰指南：reasoning_effort × verbosity，三步把速度、成本、品質一次調好

TL;DR

• 你不需要把 GPT-5 永遠開在 high/high。預設 effort=low × verbosity=low 就能吃下 70–85% 低風險任務（示意），把昂貴的推理檔位留給「合規/金額、多步推理、需要引用」的情境。
• 三步策略：① 預設低檔、② 符合條件才升級、③ 用 JSON Schema＋雙門檻（SLA/成本） 自動回退。
• 任務配方表告訴你不同任務該用哪個組合，「為何不是別的組合」也寫清楚，避免盲目升級。
• 驗證與上線門檻提供閾值表、抽樣與盲測、自動回退偽碼，幫助你在 1 週內完成小規模 canary（示意）。

為什麼你需要知道？

多數團隊把模型開很大，卻仍抱怨延遲慢、成本高、理由說不清。

真正的核心不是「換更貴的模型」，而是把「思考深度」與「輸出長度」調到位：讓模型在該用力的題上用力、該省的題上節省。這篇把方法、門檻與驗證一次講清，立即就能小規模上線。

適用範圍 & 前置條件

適用範圍：

• 客服自動摘要、FAQ 問答（可不附引用）
• 具結構輸出的工作流（例如 decision/risks/next_steps）、工單歸類
• 有延遲、成本、合規率門檻的企業內部應用

不建議直接套用：

• 高風險決策（法律、醫療、金流）且缺乏人工復核
• 完全無法蒐集驗證樣本或無法加上 JSON Schema 的情境

前置條件：

• 能記錄請求日誌：request_id, model, effort, verbosity, latency_ms, cost, json_pass, citations_coverage
• 有最小可行 Schema（下文提供）
• 有灰度能力：分流 5–25% 用戶到新策略（canary）

名詞釋義

• reasoning_effort（思考深度/時長）：告訴模型要用多少「推理步數／時間預算」。越高，通常延遲/成本↑，但在複雜任務上穩定度↑（示意）。
• verbosity（輸出長度/細節）：控制答案要不要「完整鋪陳」與「結構化」。越高越長、越詳細，但也更佔 token/更慢。
• 多步推理：需要把任務拆解為多個可驗證的中間結論（例如條款逐條比對→評估風險→再下決策）。
• 治理（Governance）：把輸入脫敏、輸出結構化、可追溯、可回退等規則寫成系統級機制，而不是靠每次 prompt 的「道德勸說」。
• 邊車路由（Sidecar Routing）：在服務旁掛一個決策側車，判斷任務風險→選模型/檔位→監控→回退；主服務不改動或少量改動。

---

一、為什麼要管這兩個參數？（動機、經濟、風險）

動機：同一個模型，因「推理深度」與「輸出長度」不同，能產生數倍的延遲與成本差；而且差異常常跟品質沒有線性相關。

經濟面：把 80% 日常任務（摘要/分類/短答）鎖在 low×low，就能把省下來的延遲與成本投到真正需要深度推理的 20%（示意）。

風險面：在高風險任務上，如果只調 verbosity 而不升 effort，模型會「說很多但理由不穩」，可稽核性差；反過來在低風險任務升 effort，只是更慢更貴。

二、參數與影響（更細的技術機制）

2.1 reasoning_effort：影響了什麼？

• 生成路徑長度：更長的內部推理步驟（如 chain-of-thought 風格的內部搜索），帶來更高的計算時間與中間 token（若可見）產生。
• 迷你快取（Prompt Cache）命中：當上下文相近時，低 effort 更易命中快取（示意），但在新奇/複雜任務上可能不夠用力。
• 與工具連動：若你有工具呼叫（RAG/DB/搜尋），低 effort 容易過早下結論；高 effort 比較願意「先查再答」。

實務建議：

• 預設 low；命中合規/金額、多步>2、要引用才升級 high。
• 中間檔 med 用在「要理由、但不需要逐條引用」的情境（內部規範說明、訓練教材草稿）。

2.2 verbosity：不只是變長

• 可讀性：verbosity=low 適合決策型欄位（如 decision），high 適合教學/稽核（要鋪陳理由與引用）。
• JSON 合規：過長、過花的輸出比較容易踩到 Schema 邊界（例如字數超上限、跑出無定義欄位）。
• 與 max_tokens：若不調整最大輸出長度，verbosity=high 可能被硬切，產生殘缺 JSON。

實務建議：

• 在結構化輸出任務（API 消費）先設 verbosity=low/med，再用擴充欄位補充理由。
• 若要文字解說與引用，升到 high，但需同步提高 max_tokens 與 stop 規則。

2.3 兩者交互作用

• effort=low × verbosity=high：話多但未必真懂；適合「產出說明文字」但不做高風險決策。
• effort=high × verbosity=low：想得深但說得短；適合「工具規劃/產碼」或結構化決策。

---

三、三步調參策略與任務配方

Step 1｜預設低檔（把 70–85% 先吃下來）

• 目標：延遲、成本先達標，品質維持可用。
• 建議：客服摘要、分類、一般 FAQ → gpt-5-mini + effort=low + verbosity=low（示意）。
• 輸出格式：維持 3 欄為主：decision（≤80字）、risks（≤200字）、next_steps（≤160字）。

Step 2｜何時升級（明確可操作的條件）

• 升級條件（任一命中即可）：
  1. 涉及 金額/法務/合規；
  2. 工具步數 > 2；
  3. 需要引用（必須能指認來源段落）；
  4. 風險分數 ≥ 7（自訂：金額3、合規3、工具2、引用2）。
• 升級動作：切到 gpt-5 + effort=high（必要時 verbosity=high），並提高 max_tokens。

Step 3｜可治理輸出與自動回退

• Schema 驗證：以 JSON Schema 限長度、欄位、型別；不合規立即重試 ≤2，仍失敗則回退。
• 雙門檻回退：P95 延遲 超標 或 $/req 超上限，且品質指標無提升 → 自動回退到預設策略。
• 審核與追溯：寫入 request_id, tool_run_id, citations[]，事後能追到資料來源與決策歷程。

任務配方表

任務	模型	effort	verbosity	為何不是別的組合？
客服摘要	gpt-5-mini	low	low	追速度與成本；升到 high 只會更慢更貴（示意），且摘要不需複雜推理
FAQ＋引用	gpt-5-mini	med	med	要來源＋適度理由；high/high 不划算、字數也更易超出 Schema
合約判讀	gpt-5	high	high	高風險需可稽核與引用；低檔常漏條文風險、理由不足
SQL 產生	gpt-5	high	low	要深度規劃但不需長篇解說；high/low 較穩且省 token
內訓教材草稿	gpt-5-mini	med	high	需要鋪陳概念，但推理不必太深；選 mini 控制成本

---

---

四、最小可行範例（請求樣板）

系統提示（摘要任務）

你是一個企業內部助手。請以結構輸出 decision/risks/next_steps。若不確定，保持保守並提出下一步。

API 請求（示意）

{
  "model": "gpt-5-mini",
  "reasoning_effort": "low",
  "verbosity": "low",
  "temperature": 0.2,
  "response_format": { "type": "json_object", "schema_name": "decision_risks_nextsteps_v1" },
  "input": { "ticket_text": "<工單文字>" },
  "metadata": { "request_id": "req_...", "tool_run_id": "tool_..." },
  "timeout_ms": 12000
}

JSON Schema（節錄）

{
  "$id": "decision_risks_nextsteps_v1",
  "type": "object",
  "required": ["decision", "risks", "next_steps"],
  "properties": {
    "decision":   { "type": "string", "maxLength": 80 },
    "risks":      { "type": "string", "maxLength": 200 },
    "next_steps": { "type": "string", "maxLength": 160 }
  },
  "additionalProperties": false
}

---

路由與回退偽碼

def route(task):
    risk = score(task)  # 金額3、合規3、工具2、引用2（自訂）
    if risk >= 7 or task.needs_citation or task.tool_steps > 2:
        return ModelCfg(model="gpt-5", effort="high", verbosity="high")
    return ModelCfg(model="gpt-5-mini", effort="low", verbosity="low")

def call_llm(cfg, payload):
    for attempt in range(1, 3):  # 重試 ≤2
        out = llm.invoke(cfg, payload)
        ok  = json_schema_validate(out)
        if ok: return out, attempt
    raise JsonInvalidError()

def guarded_infer(task):
    start = now()
    cfg   = route(task)
    out, attempts = call_llm(cfg, task.payload)
    latency = now() - start
    cost    = estimate_cost(cfg, out)
    quality = score_quality(out)  # 盲測或規則

    if (latency > SLA_MS or cost > COST_UPPER) and not quality_improved(task, out):
        # 回退
        fallback = ModelCfg("gpt-5-mini", "low", "low")
        out, _ = call_llm(fallback, task.payload)
        log(task, cfg, out, latency, cost, attempts, fallback=True)
        return out
    log(task, cfg, out, latency, cost, attempts, fallback=False)
    return out

---

五、觀測與驗證

最小指標集合：

• 延遲：P50/P95 latency_ms（端到端）
• 成本：$/req（含輸入/輸出 token；考慮快取命中）
• 結構合規：JSON pass rate
• 引用：citations_coverage（需要引用的任務）
• 穩定度：重試率、回退率

成本估算（示意）：

$/req = (input_tokens/1000 * price_in) + (output_tokens/1000 * price_out) - cache_saving

---

驗證：抽樣、盲測、上線門檻

抽樣：7/30 天分層抽樣（新/舊類型、長/短文本），每類 ≥20 筆（示意）。

盲測：把新舊策略的輸出混洗，請 2 位評審就決策正確/引用正確/體驗分打分。

門檻（三選二過關）（示意）：

• P95 ≤ 2.5s
• JSON 合規率 ≥ 95%
• 引用覆蓋率 ≥ 90% 通過條件：≥2 項達標，且$/req 在預算以內 → 放大流量；否則回退並記錄缺陷。

---

常見錯誤與排除

1. 只升 verbosity 不升 effort → 話多但沒理由可驗；對高風險任務一定要一起升 effort。
2. Schema 太鬆 → 合規率看似高，實際充滿雜訊；加上長度/枚舉/格式限制。
3. 忽略 max_tokens → high 輸出被截斷；請同步提高上限並設 stop。
4. 無回退機制 → 一旦超時/爆成本就卡住；務必實作雙門檻回退。
5. 沒有樣本池 → 調了也不知道好壞；先建立 100–300 筆代表樣本（示意）。

---

安全與合規

• 脫敏：電話、Email、住址等以遮罩規則處理；先脫敏再送出。
• 引用稽核：對需要來源的任務，要求 citations[]（來源 ID、段落 span、URL）；抽查 10%。
• 保存：保留決策與引用 90 天（示意），以便追溯與內部稽核。

---

結論與下一步

把模型轉大不是萬靈丹。真正的效率來自把 effort × verbosity 調到剛好：該省則省，該穩就穩。

想直接動手：下載我準備的「OpenAI GPT-5 API 串接檢查表」；照著填，就能在一週內做完 canary、定出你的升級/回退門檻。

---

FAQ

Q1：如果同一任務有時很簡單、有時很複雜，要怎麼自動判斷？

A：用風險分數（金額/合規/工具步數/是否要引用），≥7 就升級；並記錄分數分佈，週更門檻。

Q2：RAG 場景下要怎麼配？

A：若需要逐段引用與多輪檢索，建議 effort=high；若只有簡單定位＋概述，med/med 足夠。

Q3：高 verbosity 會不會讓 JSON 更容易壞？

A：會。用結構先、解釋後：主體是 JSON、解釋放 explanation 欄位或附件欄。

Q4：為什麼不直接把所有任務都丟給 gpt-5 high/high？

A：成本與延遲不可接受（示意），且在低風險任務上品質提升有限；應把昂貴資源留給真正需要的 20%。

Q5：怎麼確定我的門檻設定是合理的？

A：用盲測＋A/B；只要兩個指標達標、成本可控，就可以先小規模放量，再逐步優化。

---

結尾｜把 AI 調參與治理做成日常

① 今天就做（3 分鐘）

1. 為三種任務設「預設檔位」：檢索問答 effort=medium＋verbosity=compact；長文/策略 high/verbose；工具路由 low/compact
2. 抽樣 20 筆，記 P95 延遲、$ / req、成功率（示意）
3. 把不達標的組合列入「回退」清單，2 週內改版

二選一留言：你的預設檔位更接近 A 速度優先，還是 B 品質優先？為什麼？

② 下集你想看哪個實測？

• effort 低→中 的準確率提升幅度 vs 成本曲線
• verbosity 對「工具參數錯誤率」的影響
• 不同任務的「三選二門檻」配置參考

在留言寫 1/2/3，或貼你的任務情境，我會把數據補進後續篇。

下載《OpenAI GPT-5 API 串接檢查表》 下載後複製到你的雲端或 Wiki，照表檢查就能落地。

追蹤我的臉書（個人） 追蹤我的粉專 LinkedIn 追蹤

數字皆為「示意」。不同任務請以你的評測集實測為準。