以評估為導向的開發

為實際應用程式製作提示時，您會發現一個重要的取捨：兼顧簡潔與有效性。在所有因素相同的情況下，簡潔的提示比冗長的提示更快、更便宜，也更容易維護。這在延遲和權杖限制很重要的網路環境中尤其重要。但如果提示過於簡短，模型可能缺乏背景資訊、指示或範例，無法產生高品質的結果。

評估導向開發 (EDD) 可讓您有系統地監控及最佳化這項取捨。這項技術提供可重複測試的程序，可逐步改善輸出內容、偵測迴歸，並隨著時間推移，讓模型行為符合使用者和產品期望。

這就像是測試推動開發 (TDD)，但適用於 AI 的不確定性。與確定性單元測試不同，AI 評估無法以硬式編碼方式設定，因為輸出內容 (包括格式正確和失敗的內容) 可能會採取意想不到的形式。

EDD 也支援探索工作。就像編寫測試有助於釐清功能行為一樣，定義評估條件和檢查模型輸出內容，可讓您面對不清楚之處，並逐步為開放式或不熟悉的工作新增更多詳細資料和結構。

同理使用者、注意語氣和清晰度，並願意將模型視為創意協作者，是製作更優質提示和功能的必要條件，才能引起使用者共鳴。

定義問題

您可以將問題架構為 API 合約，包括輸入類型、輸出格式和任何其他限制。例如：

• 輸入內容類型：網誌文章草稿
• 輸出格式：包含 3 個貼文標題的 JSON 陣列
• 限制：少於 128 個字元，使用友善語氣

接著，收集輸入內容範例。為確保資料多樣性，您會納入理想範例和實際的混亂輸入內容。請考慮各種變化和極端情況，例如含有表情符號的貼文、巢狀結構和大量程式碼片段。

初始化基準

撰寫第一個提示。您可以從零樣本開始，並加入：

• 清楚的操作說明
• 輸出格式
• 輸入變數的預留位置

評估及最佳化時，您會增加複雜度，並使用其他元件和進階提示技術。首先，我們需要設定評估系統，引導最佳化工作朝正確的方向發展。

建立評估系統

在 TDD 中，您會在瞭解需求後開始撰寫測試。生成式 AI 沒有明確的輸出內容可供測試，因此您需要投入更多心力來設計評估迴圈。

您可能需要多種評估工具，才能有效評估成效。

定義評估指標

評估指標可以是決定性指標。舉例來說，您可以檢查模型是否傳回有效的 JSON，或輸出正確數量的項目。

不過，您應該花費大量時間，找出並改善主觀或質性指標，例如清晰度、實用性、語氣或創意。您可能會從廣泛的目標開始，但很快就會遇到更細微的問題。

舉例來說，假設你的標題產生器過度使用特定片語或模式，導致產生重複、機械式的結果。在這種情況下，您會定義新的指標，以鼓勵變化，並避免過度使用結構或關鍵字。一段時間後，核心指標就會趨於穩定，您也能追蹤改善成效。

如果專家瞭解應用程式領域中「良好」的樣貌，並能找出細微的失敗模式，這個程序就能從中受益。舉例來說，如果您正在開發寫作助理，請與內容製作人或編輯合作，確保評估結果符合他們的觀點。

選擇評審

不同評估標準需要不同評估人員：

• 以程式碼為基礎的檢查非常適合用於確定性或以規則為基礎的輸出內容。舉例來說，您可以掃描標題，找出要避免使用的字詞、檢查字元數，或驗證 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。

如要進一步改善提示，請參閱情境感知開發。最好由機器學習工程師執行這項作業。

隨堂測驗