為實際應用程式製作提示時，您會發現一個重要的取捨：兼顧簡潔與有效性。在所有因素相同的情況下，簡潔的提示比冗長的提示更快、更便宜，也更容易維護。這在延遲和權杖限制很重要的網路環境中尤其相關。不過，如果提示過於簡短，模型可能缺乏背景資訊、指示或範例，無法產生高品質結果。
評估導向開發 (EDD) 可讓您有系統地監控及調整這項取捨。這項可重複測試的程序有助於以小而穩健的步驟改善輸出內容、偵測迴歸，並隨著時間推移，讓模型行為符合使用者和產品期望。
這就像是測試推動開發 (TDD)， 但適用於 AI 的不確定性。與確定性單元測試不同，AI 評估無法以硬式編碼方式設定，因為輸出內容 (包括格式正確和失敗的內容) 可能會採取意想不到的形式。
EDD 也支援探索工作。就像編寫測試有助於釐清功能行為一樣，定義評估條件及檢查模型輸出內容，可讓您面對缺乏明確性的問題，並逐步為開放式或不熟悉的工作新增更多細節和結構。
同理使用者、注意語氣和清晰度，並願意將模型視為創意協作者，是製作更優質提示和功能的必要條件，才能引起使用者共鳴。界定問題
您可以將問題視為 API 合約，包括輸入類型、輸出格式和任何其他限制。例如：
- 輸入類型：網誌文章草稿
- 輸出格式：包含 3 個貼文標題的 JSON 陣列
- 限制：不得超過 128 個字元，語氣友善
接著，收集輸入內容範例。為確保資料多樣性，請同時納入理想範例和實際的混亂輸入內容。請考慮各種變化和極端情況，例如含有表情符號的貼文、巢狀結構，以及大量程式碼片段。
初始化基準
撰寫第一個提示。請從零樣本開始，並加入清楚的指示、輸出格式，以及輸入內容的變數預留位置。
您將增加系統的複雜度，並使用其他元件或提示技術來最佳化 AI 系統。為確保有效運用時間並最佳化合適的元件，您需要設定評估系統。
建立評估系統
在 TDD 中，您瞭解需求後，即可開始撰寫測試。生成式 AI 沒有明確的輸出內容可供測試，因此您需要投入更多心力來設計評估迴圈。
您可能需要多種評估工具，才能有效評估。
定義評估指標
評估指標可以是決定性指標，也就是有已知的正確答案。舉例來說，您可以檢查模型是否傳回有效的 JSON，或輸出正確數量的項目。
不過，有了 AI，您就能將大部分時間用於找出及改善主觀的質性評估。包括輸出內容的品質、實用性、語氣和創意。您可以先設定較廣泛的成功目標，瞭解輸出內容應如何符合您的期望。最終，您會遇到具體而細微的問題，有助於更清楚地定義目標。
舉例來說，假設你的標題產生器過度使用特定片語或模式，導致結果重複且不自然，在這種情況下，您應定義新的指標，鼓勵變化，並避免過度使用結構或關鍵字。一段時間後，核心指標就會趨於穩定，您也能追蹤改善成效。
如果專家瞭解應用程式領域中「良好」的定義，並能找出細微的失敗模式，這個程序就能事半功倍。舉例來說，如果您正在開發寫作助理，請與內容製作人或編輯合作，確保評估結果符合他們的觀點。
選擇評審
不同的評估標準需要不同的評估人員：
- 以程式碼為基礎的檢查非常適合用於確定性或以規則為基礎的輸出內容。舉例來說，您可以掃描標題，找出要避免使用的字詞、檢查字元數，或驗證 JSON 結構。這些函式快速、可重複使用，非常適合按鈕或表單欄位等固定輸出 UI 元素。
- 人工意見回饋對於評估較主觀的特質 (包括語氣、清晰度或實用性) 至關重要。尤其是在初期，自行 (或與領域專家) 檢查模型輸出內容，有助於快速疊代。不過，這種做法無法妥善擴充。應用程式上線後，您也可以收集應用程式內信號 (例如星等)，但這些信號通常會產生雜訊，且缺乏精確最佳化所需的細微差異。
- LLM 做為評估者：使用其他 AI 模型評估輸出內容或提出批評，以可擴充的方式評估主觀標準。這比人工審查更快，但並非沒有缺點：在簡單的實作中，這可能會延續甚至加強模型的偏見和知識差距。
重質不重量。在傳統機器學習和預測式 AI 中，眾包資料註解是常見做法。對於生成式 AI，眾包註解員通常缺乏網域背景資訊。相較於規模，高品質且內容豐富的評估更為重要。
評估及最佳化
越快測試及調整提示，就越快能找出符合使用者期望的內容。您需要養成持續最佳化的習慣。嘗試改善、評估，然後嘗試其他做法。
在正式環境中，請持續觀察及評估使用者和 AI 系統的行為。然後分析這項資料，並轉換為最佳化步驟。
自動執行評估管道
為減少最佳化作業的阻力，您需要自動評估、追蹤變更，以及將開發作業連結至生產作業的作業基礎架構。這通常稱為 LLMOps。雖然有平台可協助自動化，但您應先設計理想的工作流程，再決定採用第三方解決方案。
以下是幾個值得考慮的關鍵元件：
- 版本管理：將提示、評估指標和測試輸入內容儲存在版本控制中。將其視為程式碼，確保可重現性及清楚的變更記錄。
- 自動批次評估：使用工作流程 (例如 GitHub Actions) 針對每個提示更新執行評估，並產生比較報表。
- 提示的 CI/CD：透過自動檢查 (例如確定性測試、LLM 評分或防護措施) 控管部署作業，並在品質下降時封鎖合併作業。
- 實際執行環境記錄和可觀測性：擷取輸入內容、輸出內容、錯誤、延遲時間和權杖用量。監控是否有偏移、非預期模式或失敗次數激增。
- 意見回饋擷取：收集使用者信號 (喜歡、重寫、放棄)，並將重複發生的問題轉化為新的測試案例。
- 實驗追蹤：追蹤提示版本、模型設定和評估結果。
透過小幅度的指定目標變更進行疊代
提示詞修正通常會從改善提示詞的語言開始。例如，提供更明確的指示、釐清意圖或消除模糊不清之處。
請注意不要過度擬合。常見的錯誤是新增過於嚴格的規則，以修正修補程式模型問題。舉例來說，如果標題產生器持續產生以「The Definitive Guide」(最終指南) 開頭的標題，您可能會想明確禁止使用這個詞組。請改為抽象化問題，並調整較高層級的指令。 這可能表示您強調原創性、多樣性或特定編輯風格，因此模型會學習潛在偏好，而非單一例外狀況。
另一種做法是嘗試更多提示技巧，並結合這些做法。選擇技術時，請自問：這項工作最適合透過類比 (少樣本)、逐步推論 (連鎖思考) 或反覆修正 (自我反思) 解決嗎？
系統進入正式版後，EDD 飛輪不應減速。如果有的話，應該是加速。如果系統會處理及記錄使用者輸入內容，這些內容應會成為最有價值的洞察資料來源。在評估套件中加入週期性模式，並持續找出及實作下一個最佳化步驟。
重點
依據評估結果開發提示，可協助您有條不紊地應對 AI 的不確定性。明確定義問題、建構專屬的評估系統，並透過小規模的改善作業進行疊代，即可建立回饋循環，持續提升模型輸出內容的品質。
資源
如要導入 LLM 做為評估者，建議閱讀下列文章：
- 比較 LLM 的摘要功能。
- 請參閱 Hamel Husain 的指南，瞭解如何使用 LLM 做為評估者。
- 閱讀論文：A Survey on LLM-as-a-Judge。
如要進一步改善提示，請參閱情境感知開發。建議由機器學習工程師執行這項作業。
隨堂測驗
以評估為導向的開發作業主要目標為何？
為什麼要使用較大的模型來評估用戶端系統？
使用 LLM 做為評估法官時，可能會遇到哪些潛在陷阱？
建議的自動評估管道包含哪些元件？
為評估系統選擇評審時，使用人工意見回饋的主要限制為何？