生成式 AI 客服回覆卡頓，該測什麼？
某企業導入生成式 AI 客服系統後發現，系統整體運作穩定，且在單位時間內可處理大量對話請求。部分使用者仍反映在互動過程中回覆出現卡頓感，經初步排除網路連線與前端介面功能問題後，若專案團隊希望針對此現象進行效能測試，下列何者最符合測試重點？
某企業導入生成式 AI 客服系統，系統整體運作穩定，單位時間內也能處理大量對話請求。但部分使用者反映，互動過程中回覆出現卡頓感。初步已排除網路連線和前端介面的問題。
問你：針對這個卡頓現象進行效能測試，最符合測試重點的是哪一項？
一句話總結
使用者感受到「卡頓」是因為等待回覆的時間太長，要測的是單次互動的反應速度（延遲，Latency），而不是系統整體的吞吐量或穩定性。
先感受問題：明明很快又很穩，為什麼感覺卡？
假設你在「美好家電」客服中心負責 AI 助理的效能監控。系統監控板上顯示一切正常：
- 系統穩定度：99.8%（幾乎沒有當機）
- 每分鐘處理對話數：1,200 則（吞吐量很高）
- 網路連線：正常
- 前端介面：沒問題
但客服主管拿著手機給你看：「你自己試試看，問它一個問題，從送出到開始看到回覆，要等 3 到 5 秒。使用者說感覺很慢、不流暢。」
你明白了：系統「整體」很快，但「單次」回覆的等待時間太長。使用者不在乎每分鐘處理 1,200 則，他在乎的是「我問了，多久看到答案」。
測錯指標，問題永遠找不到
「美好家電」的工程師一開始測了一堆數據，但都不是關鍵：
- 測長時間穩定性：讓系統跑 48 小時，確認沒有崩潰，但使用者感受到的卡頓是在每次回覆的等待中，不是崩潰問題
- 測吞吐量（每秒請求數）：確認系統每秒能處理多少個對話，數字很漂亮，但這是「系統整體的效率」，不是「每個使用者等多久」
- 測回覆語言品質：確認 AI 的回答有沒有語法錯誤或語意不通，這是品質問題，跟速度無關
- 只看後端 CPU 使用率：CPU 不高，但忘了 LLM 推論的時間不只取決於 CPU，還取決於模型大小、token 生成速度
- 只看 API 回應碼：都是 200 OK，代表請求成功，但不代表快，成功和快是兩件事
每一個測試都有意義，但都沒有抓到使用者卡頓感的根源。
測單次回覆的延遲，才能找到卡頓點
「美好家電」的工程師調整測試重點，直接測量使用者能感受到的那個時間：
測量指標：延遲（Latency）。從使用者送出問題，到看到第一個字出現（首字延遲，Time to First Token），以及到整個回覆完成的時間。
測試設計：模擬 100 個使用者同時提問，記錄每一次互動的回覆時間分佈。結果發現：95% 的回覆在 1 秒內開始，但有 5% 的回覆要等超過 4 秒。使用者反映的卡頓感，就是這個長尾延遲造成的。
找到根本原因：當模型被要求生成長回覆（超過 500 個 token）時，推論時間顯著變長。解法是設定合理的回覆長度限制，或改用更快的模型版本處理即時客服場景。
這就是選項 D 講的：分析單次互動回覆的反應速度表現，這才是卡頓感的直接量測方式。
技術版：生成式 AI 系統的效能維度
生成式 AI 系統的效能評估有多個維度，混淆這些維度是造成測試錯誤的主因。
四種效能維度：
- 延遲（Latency）：單次請求從發出到收到回覆的時間，直接影響使用者體驗。LLM 的延遲包含首字延遲（TTFT）和整體生成時間
- 吞吐量（Throughput）：單位時間內系統能處理的請求總數，影響系統承載上限
- 穩定性（Stability）：長時間運行下系統的可用率和崩潰頻率，影響服務連續性
- 品質（Quality）：回覆的語意準確性、語言流暢度，屬於內容評估，不是效能指標
為什麼吞吐量高但延遲高可以同時存在：吞吐量是批次處理能力，系統可以平行處理 1,000 個請求，但每個請求都要等 3 秒。這種情況下，吞吐量高、延遲也高，兩者不矛盾。
為什麼出題者要考這題：AI 應用規劃師在評估生成式 AI 系統時，必須能區分不同效能維度，針對問題症狀選對測試方法。「卡頓感」是使用者體驗問題，對應的測試指標是延遲，不是吞吐量或穩定性。
為什麼其他選項是錯的
A評估系統長時間運作的穩定程度
讓系統跑很長一段時間，確認它不會崩潰、不會異常，測試系統的可靠性。
題目明確說「系統整體運作穩定」，穩定性問題已確認不是現在的問題。繼續測穩定性是浪費資源，找不到使用者感受到的卡頓原因。
看到「效能測試」就直覺選「壓力測試、穩定性測試」的人。但測試的選擇應根據症狀定向，不是選最常見的測試類型。
B測量系統單位時間的總處理量
測試系統每秒或每分鐘能處理多少個對話，確認系統的吞吐量。
題目說系統「在單位時間內可處理大量對話請求」，吞吐量沒問題已確認。再測吞吐量是在確認一個已知沒問題的指標，對找出卡頓原因毫無幫助。
把「處理量大 = 效能好」當成唯一效能標準的人。效能有多個維度，「能處理多少」和「等多久」是不同的問題。
C比較不同回覆內容的語言品質
評估 AI 生成的回覆語言是否流暢、語意是否準確、有沒有錯誤。
語言品質是「回覆內容好不好」的問題，跟「回覆速度快不快」是完全不同的維度。使用者反映的是卡頓感（速度問題），不是說回答很奇怪（品質問題），測語言品質完全答非所問。
把「效能測試」和「品質評估」混在一起的人。對於 AI 系統，品質（說得好不好）和效能（回得快不快）是兩個獨立評估維度。
同個考點下次怎麼變形
什麼是首字延遲（Time to First Token, TTFT）？為什麼它對 AI 客服體驗很重要？
等全部回覆出來的時間才是重點吧？
TTFT 是從送出請求到看到第一個字出現的時間。生成式 AI 通常是「邊生成邊顯示」，使用者看到第一個字就感覺系統開始回應了，TTFT 短就能顯著降低卡頓感，即使整體生成時間較長也不那麼難受。
延遲（Latency）高和吞吐量（Throughput）不足，哪個更難解決？
都是效能問題，解法應該差不多？
兩者通常有取捨關係（trade-off）：增加批次大小可以提升吞吐量，但往往會增加延遲。生成式 AI 對延遲特別敏感，因為 token 是一個一個生成的，縮短延遲通常需要更快的 GPU 或更小的模型，比增加吞吐量更受硬體限制。
生成式 AI 系統的效能測試應包含哪些場景？
正常使用就好，壓力測試不用吧？
至少應測：單使用者低負載（基準延遲）、多使用者並發（壓力下的延遲與吞吐量）、長對話上下文（context 長度增加時的延遲變化）、長回覆生成（token 數多時的表現）。不同場景往往暴露不同瓶頸。
改善生成式 AI 回覆延遲，有哪些常見策略？
只能換更貴的 GPU？
除了升級硬體，還可以：使用更小的模型（如蒸餾模型）、限制最大輸出 token 數、採用串流輸出（讓使用者看到生成過程而非等全部完成）、加入快取（相似問題直接回傳快取答案）。規劃師應根據延遲瓶頸選擇最合適的策略。
使用者體驗中的「可接受延遲」大概是多久？
只要不超過 10 秒應該都可以？
一般對話介面中，使用者對首字延遲的容忍度約在 1 到 2 秒以內，超過就開始有卡頓感。整體生成時間可以長一些（因為使用者看到文字在持續出現），但首字延遲是決定「第一印象快不快」的關鍵指標。
想再往下看，這 5 個
- 即時推論（Real-time Inference）模型即時回應使用者請求的模式，延遲（Latency）是評估即時推論品質的核心指標
- 推論最佳化（Inference Optimization）透過量化、快取、批次推論等手段降低模型回應延遲，是解決 AI 客服卡頓的技術方向
- 生成式 AI（Generative AI）能生成文字、圖像等內容的 AI 系統，逐字生成的特性使延遲測試有別於傳統 API 效能測試
- 批次推論（Batch Inference）累積多個請求一次處理以提升吞吐量，與即時推論的低延遲需求相互取捨
- 推論（Inference）訓練完成的模型接受輸入並產出結果的過程，卡頓問題的根源在推論階段的時間消耗