昨天把 Eval 裡失敗的案例拆成 Retrieval、Context、Generation、Format 和 Unsupported Answer 之後，我原本覺得評估這件事情已經慢慢有一個比較完整的樣子，至少現在看到錯誤時，不會再只得到一個模糊的「回答不好」，而是能大概知道問題出在哪一層。

但如果今天真的把這套 AI 功能放到使用者面前，只看答案正不正確還是不夠。

一個回答可能非常完整，也真的引用到正確資料，可是每次都要等二十秒；另一個版本準確率只差一點，卻可以在三秒內回來，Token 使用量也少很多，這兩個版本放在 Demo 裡可能看不出太大的差別，一旦開始有幾百、幾千次 Request，體感和成本就會慢慢被放大。

所以 Day 12 我開始把 Latency 和 Token Cost 放進原本的 Eval 裡。

同一份測試資料，再多記兩個數字

我沒有另外做新的測試集，而是直接拿前幾天一直使用的 QA Dataset，因為這樣才有辦法把品質、速度和成本放在同一個基準上比較。

每個 Case 原本會留下輸入、模型輸出、Retrieval 結果、是否答對以及失敗類型，今天再補上幾個欄位，包括整體 Response Time、Prompt Tokens、Completion Tokens 和 Total Tokens，如果流程裡有 Retrieval，我也另外記 Retrieval 花掉多少時間，這樣比較不會看到整體變慢就直接怪模型。

跑完之後很快就可以看到一些之前沒注意過的差異。

例如前幾天 Top-K 實驗裡，K 從 3 拉到 10 的時候，確實可能讓某些問題比較容易拿到需要的資料，但輸入 Context 也跟著變長，Token 數量增加之外，模型還得在更多片段裡找答案，速度跟品質不一定一起往好的方向走。

這時候「多塞一點資料比較保險」就開始有代價了。

Prompt 越完整，也可能越貴

另一個很明顯的地方是 Prompt。

前面幾天為了讓輸出穩定，我慢慢加入格式限制、回答規則、引用要求、禁止事項以及一些 Example，單次看起來都只是多幾行文字，可是當每一個 Request 都會重複帶著同一段 System Prompt 進模型時，這些內容其實每次都在花 Token。

我沒有因此開始瘋狂砍 Prompt，因為有些規則拿掉之後，Format Error 或 Unsupported Answer 可能馬上增加，所以今天真正想找的是哪些內容確實對品質有幫助，哪些只是以前一路補上去，現在已經沒有太大作用。

做法也很單純，我保留同一批 Eval Cases，拿目前的 Prompt 當 Baseline，接著刪掉一部分重複規則再跑一次，如果 Token 明顯下降，但 Accuracy、引用正確性和格式成功率沒有跟著掉，那這段內容就很有機會可以簡化。

反過來，如果省了幾百個 Token 卻讓錯誤案例增加很多，那這個成本可能就值得留下。

最快的版本不一定適合上線

做到這裡之後，我也開始發現 Production Optimization 很難只看一個數字。

假設有三個版本，A 的準確率最高但平均需要八秒，B 少一點 Context 後只要四秒，品質幾乎沒掉，C 再把模型換小之後只剩一秒多，但某些複雜問題開始回答不完整，如果只看 Latency 很容易直接選 C，如果只看 Accuracy 又可能永遠選最慢最貴的 A。

實際上還是要回到產品本身，看使用者到底在做什麼。

像是背景批次整理文件，慢幾秒可能完全沒差，但聊天介面如果每次都卡十幾秒，使用感受就會很明顯；同樣地，一個每天只跑幾十次的內部工具，Token Cost 可能根本還不是優先問題，可是請求量開始增加之後，同一個 Prompt 多出來的 Token 就會被重複乘上去。

所以今天我沒有替這些指標硬做一個總分，而是把它們一起留下來看，Accuracy、Failure Type、Latency、Input Token、Output Token 都放在同一筆紀錄裡，這樣至少每次調整時，可以看清楚自己到底換到了什麼。

Eval 開始不像只是測答案

前幾天講 Eval 的時候，我主要在意的是 AI 到底答對幾題、改 Prompt 之後有沒有 Regression，做到今天之後，它慢慢變成一份系統版本之間的比較紀錄。

同樣一個版本可能回答更準，卻多花一倍 Token；另一個版本速度變快，但 Retrieval Recall 掉了一些，這些差異如果平常沒有記，最後很容易只靠「我覺得新版比較快」或「這次看起來回答得不錯」來決定要不要上線。

而這也是我目前覺得 AI Demo 跟真的要維護的 AI 系統差距很大的地方，Demo 通常只需要成功回答眼前那幾次問題，Production 則會一直重複跑，所以那些單次看起來很小的延遲、Token 和失敗率，最後都會累積起來。

明天我想再往這裡延伸一步，開始把 Trace 加進流程，因為目前雖然已經知道一次 Request 花了多少時間，但如果整體突然從四秒變成十秒，我還需要知道時間到底卡在 Retrieval、模型、外部 Tool，還是某一段程式邏輯裡。