延遲預算分配：從使用者體驗反推每一段的上限

• 100ms 以內：感覺像即時反應。
• 300ms 以內：流暢，使用者不會分心。
• 1 秒以內：可接受，但已能感知等待。
• 超過 3 秒：需要明確的載入回饋，否則使用者會懷疑壞掉。
• 超過 10 秒：必須改成非同步流程，不要讓使用者盯著等。

一個 RAG 問答的預算分配範例

目標：TTFT p95 < 1200ms

  前端與網路往返          120ms
  身分驗證與權限查詢       40ms
  查詢改寫（小模型）      180ms
  向量檢索                 60ms
  關鍵字檢索（平行）        —
  重排                    220ms
  提示組裝                 20ms
  模型預填充（TTFT）      500ms
  ─────────────────────────────
  合計                   1140ms   餘裕 60ms

超出預算時的處理順序

1. 平行化：向量檢索與關鍵字檢索同時跑，不要序列。
2. 去掉可選環節：查詢改寫在短問題上可以跳過。
3. 降低規模：重排候選從 50 降到 20。
4. 快取：熱門查詢直接回。
5. 改成串流：讓 TTFT 成為使用者感知的時間，而非總時間。

用漸進呈現爭取時間

無法把總時間壓下來時，可以改變「感知時間」：先在 200ms 內顯示「正在查詢 3 份相關文件」，再顯示文件標題，最後才串流答案。使用者全程有回饋，體感遠優於盯著轉圈圈。

要量 p95 不要量平均

# 每一段都要有自己的計時，且要能組合成完整的火焰圖
with span('rerank'):
    ranked = rerank(q, cands)
# 匯總時看各段的 p50 / p95 / p99，找出長尾來源

長尾往往來自少數環節

實務上 p99 的延遲常常集中在一兩個環節——通常是外部 API 或未設逾時的查詢。針對長尾優化的投資報酬率，往往比優化平均值高得多。