看到 OpenAI Cookbook 這篇 Building Resilient Prompts Using an Evaluation Flywheel，覺得蠻實用的。很多人寫 prompt 的方式就是「prompt-and-pray」— 改一改，跑看看，感覺好像可以就上了。但這種做法在 production 環境下遲早會出事，因為你根本不知道改了之後到底是變好還是變差。

這篇介紹的「Evaluation Flywheel」是一個系統化的迭代流程，而且重點是: 不需要寫 code，用 OpenAI 後台內建的評估功能就能做到。

Flywheel 三個階段

整個流程是一個持續循環的飛輪，分三步:

1. Analyze — 搞清楚哪裡壞了

先人工看一批 output（建議 50 筆起跳），用 annotation 標記每筆的問題。這裡用了質性研究的方法:

  • Open Coding: 先自由標記，像是「bot 建議了一個不存在的時段」「amenities 清單沒有換行」，不用管分類
  • Axial Coding: 再把這些標記歸類成高階分類，例如「排程問題」佔 35%、「格式問題」佔 10%

這步驟的價值在於，你會知道問題的分布。與其亂猜哪裡有問題，不如用數據告訴你該先修什麼。

2. Measure — 用 Grader 自動化評估

OpenAI 後台支援多種 grader，包括 Python grader 和 LLM grader。你可以針對前一步發現的問題類別，建立對應的自動評分器。例如:

  • 格式 grader: 檢查 output 是否符合預期格式
  • 準確性 grader: 比對 model 回傳的資訊跟 ground truth

有了自動 grader，每次改 prompt 或換 model 都能立刻跑分，不用再靠人眼一筆筆看。

3. Improve — 改進 prompt

可以根據分析結果手動調整 prompt，也可以用 OpenAI 內建的 prompt optimizer，它會參考你的 annotation 和 grader 結果，自動生成改進版的 prompt。

然後這個循環就繼續轉下去 — 改完再分析，發現新的問題，再量測，再改進。

兩個進階技巧

合成資料擴充測試集

如果 production log 不夠多，可以用 LLM 生合成資料。但不要直接叫它「生 N 筆」，那出來的東西太同質。比較好的做法是定義維度（例如: 管道 x 意圖 x 角色），然後針對不同組合生成測試案例，覆蓋率會好很多。

校準你的 LLM Judge

自動評分器只有在判斷可靠的時候才有用。文章建議用 train/validation/test split 來校準 LLM judge，特別要看 True Positive Rate 和 True Negative Rate，因為大部分測試集都是 pass 居多，光看 accuracy 會被騙。

小結

這篇的核心觀念其實很簡單: 把 prompt engineering 當成一個工程問題來處理，而不是憑感覺調整。有系統地分析錯誤、量化表現、迭代改進。而且 OpenAI 後台現在已經把這些工具都整合好了，包括 dataset 管理、annotation、grader、prompt optimizer，不需要自己寫一堆 eval 腳本。

如果你的 AI 應用已經上線，或是準備要上線，花點時間建立這個 evaluation flywheel，會比「改 prompt → 手動測幾個 case → 感覺 OK 就部署」可靠太多了。