Apple Developer onepage/WWDC26
#WWDC26#Evaluations#FoundationModels#PromptEngineering2026-06-08 · 26:41

Prompt hill-climbing：用 Evaluations 把 AI 功能調校變成實驗流程

這場 session 延續「Meet the Evaluations framework」，示範如何用 BookTracker tag generator 做 prompt 改良、judge alignment、comparative evaluations，最後甚至不只改 prompt，而是加入工具。

// 一句話結論

不要把 prompt engineering 當靈感手工藝；Apple 的路線是先校準 judge，再一次改一個變因，用 evaluation score、Cohen's kappa 與 side-by-side comparison 決定下一步。

Apple Developer · WWDC26 · Video ID: sNDkT9mYDTQApple Developer 官方頁
Content map

這支影片在拆的不是 prompt，而是實驗紀律

Feature

BookTracker 的 tag generator 不穩

模型產生的 tags 有時抓不到主題，有時反映讀者情緒，有時直接複製 review 字句，導致搜尋用途變差。

Judge drift

先確認 judge 是否像人類專家

如果 model judge 對 usefulness 的評分與人類期待分歧，就算 evaluation pass，也可能只是在最佳化錯誤目標。

Experiment

Xcode 27 支援 control vs experimental 比較

用同一 dataset 比較 baseline prompt 與 experimental prompt，並在 report 中看 score、樣本與 trade-off。

Beyond prompt

改 prompt 不夠時，改 feature primitive

影片最後加入 BookLookupTool，讓模型拿到 title / author context；hill-climbing 可改 prompt、tool、model、dataset 與 evaluator。

Decision map

Prompt hill-climbing 的實作路線

1

建立 baseline evaluation

用 dataset、ScoreDimensions、ModelJudgeEvaluator 與 Swift Testing #expect 定義目前 feature 的期望。

2

找出 judge 與人類的 drift

比對 model judge ratings 與 human ratings；不要只看 accuracy，因為不均勻分布會讓準確率看起來虛高。

3

用 Cohen's kappa 衡量 alignment

Kappa 扣掉隨機一致的機率，比單純 accuracy 更能反映 judge 是否真正貼近專家判斷。

4

做 controlled comparative evaluation

每次只改一個變因：prompt 加 app context、score dimension 改描述、judge 加 few-shot examples，逐步看效果。

5

必要時跳出 prompt 層

若模型缺上下文，就加入 tool 或改資料管線；若 judge 不可信，就先對齊 evaluator，而不是繼續調主功能 prompt。

重點 1：Evaluation pass 不代表功能好

影片中的 BookTracker tag generator 會根據讀者 review 產生搜尋 tags。Treasure Island 與 Little Women 的案例顯示，模型可能產生看似合理但不適合搜尋的 tags，例如太情緒化、太具體，或沒有抓到書本主題。

這也是 AI feature 與傳統 deterministic feature 的差異：你需要的是能持續檢查品質的 evaluation pipeline，而不是一次性手動試幾個 prompt。

重點 2：Judge alignment 是 hill-climbing 的前置條件

影片把 drift 定義為 model judge ratings 與 expert ratings 的分歧。若 judge 對 usefulness 的判斷和你不同，後續 prompt 調校只會把系統推向 judge 喜歡、但使用者不一定受益的方向。

Accuracy 不夠當分數分布不均時，judge 可能靠常猜高分得到看似不錯的 accuracy，卻沒有真正理解評分標準。
Cohen's kappaKappa 會扣除隨機一致，影片用它衡量 judge 與 human ratings 的真實 alignment，並設定目標值。
Alignment dataset從既有 evaluation attachment 抽出 summary/tag pairs，加上 human ratings，再拿同一 ModelJudgeEvaluator 當 subject。
Failure analysisFrankenstein、The Ramakien 等案例顯示，judge 可能把過度具體或離題 tags 評太高，代表 prompt 缺 context。

重點 3：Comparative evaluation 讓 prompt 改動可被比較

Xcode 27 的 evaluation report 可以比較 control 與 experimental runs。影片先讓 experimental prompt 加入 app context 與好/壞 tag 例子，結果 relevance 提升但 usefulness 下降；接著將 prompt change 固定，改 ScoreDimension 描述，隔離變因後再比較。

這個流程的價值是把 prompt engineering 變成可討論的 trade-off：你可以知道哪個 score 上升、哪個下降、是哪批樣本造成，而不是只憑幾次輸出觀感。

風險與遷移注意事項

Few-shot examples 會過擬合影片刻意只加入少量 worked examples，避免 judge 只是記住 alignment set，而不是學會評分標準。
一次只改一個變因同時改 prompt、score dimension、dataset 與 model，會讓結果無法解釋；hill-climbing 需要科學式控制。
小 dataset 不能代表 production影片最後工具版在 13 samples 上變好，但仍提醒樣本太少，還需要觀測 tool calls 與 agentic behavior。
不要只最佳化 judge scoreJudge score 是導航，不是產品目標本身。要持續抽查 human ratings，並留意 drift 重新出現。

對 AI app 團隊的實務啟發

最可帶走的做法是把 prompt、judge prompt、score dimensions、dataset、tools 都視為可被實驗的變因。先讓 evaluator 可信，再透過 controlled comparison 逐步調整；當 prompt 無法補足輸入資訊時，加入工具或改資料流，才是正確方向。

來源

主要來源為 Apple Developer 官方影片頁、transcript 與章節摘要；YouTube 影片頁用於 iframe 與發布 metadata。官方頁：Improve your prompts by hill-climbing with Evaluations - WWDC26。YouTube：WWDC26: Improve your prompts by hill-climbing with Evaluations | Apple。

// TL;DR