EVALS 入門不需要太多。我們看到的適用於小型團隊的模式看起來很像應用於 AI 工程的測試驅動開發： 1/ 將評估錨定在使用者故事中，而不是抽象的基準測試中：與你的產品/設計同行坐下來，列出你的模型需要為使用者做的具體事情。“準確回答保險索賠問題”、“從自然語言生成 SQL 查詢”。對於每個輸入，寫入 10-20 個代表性輸入和所需的輸出/行為。這是您的第一個 EVAL 檔。 2/ 從第一天開始自動化，即使它很脆。抵制 「只是盯著它 」的誘惑。 好吧，好吧，Vibes 的擴展時間不會太長。將評估包裝在代碼中。你可以編寫一個簡單的 PyTest 來迴圈你的示例，調用模型，並斷言某些子字串出現。這很粗糙，但這是一個開始。 3/ 使用該模型來引導更難的評估數據。手動編寫數百個邊緣案例的成本很高。您可以使用推理模型 （O3） 生成合成變體（“給我 50 個涉及火災損壞的索賠問題”），然後手動篩選。這可以在不犧牲相關性的情況下加快覆蓋率。 4/ 不要追逐排行榜;反覆運算失敗的內容。當生產中出現問題時，不要只修復提示符 - 將失敗的情況添加到您的 EVAL 集中。隨著時間的推移，您的套件將增長以反映您的真實故障模式。定期對 EVALS 進行切片（按 Input Length、按 locale 等），以查看是否在特定 Segment 上回歸。 5/ 隨著產品的成熟而改進您的指標。隨著規模的擴大，您將需要更細緻的評分（語義相似性、人工評分、成本/延遲跟蹤）。在您的 EVAL Harness 中構建 Hook 以記錄這些並隨著時間的推移對其進行趨勢分析。檢測您的UI以收集隱式反饋（使用者是否點擊了“豎起大拇指”？）並將其反饋到您的離線評估中。 6/ 使 evals 可見。在團隊和利益相關者面前放置一個簡單的儀錶板，顯示評估通過率、成本、延遲。在站立比賽中使用它。這創造了問責制，並説明非ML人員參與權衡討論。 最後，將 EVALS 視為核心工程工件。 分配擁有權，在 Code Review 中審查它們，當您添加新的棘手案例時慶祝。隨著您的擴展，該學科將帶來復合紅利。