AI Engineer Europe 2026 · 演講 · 2026-04-10 · 41 分
用 GEPA 把 LLM 評審校準到能用
Judge the Judge: Building LLM Evaluators That Actually Work with GEPA · Mahmoud Mabrouk,Agenta AI
Mahmoud 拿 tau-bench 的航空客服資料,示範怎麼用人工標註加 GEPA 提示詞優化,把空泛的 LLM-as-a-judge 校準成真的判得出問題的評審。
概要
- 現成的 judge 判不出東西Mahmoud 認為直接套函式庫裡的 hallucination judge,prompt 只是在叫模型「判斷有沒有幻覺」,模型若真的看得出來,應用從第一天就不會出錯,所以要拿人工標註去校準 judge。
- 指標要從場景長出來評估項目應該由領域專家看對話、歸納錯誤類型而來,不要套通用指標。Mahmoud 的例子拆成四種錯誤,各配一個 judge,而且每個都只做是非判斷,不打 1 到 5 分。
- 標註要附理由沒有理由,judge 得自己猜為什麼失敗,像政策遵循這種問題幾乎學不起來。Mahmoud 也強調取得與整理資料才是最難的一步。
- GEPA 的做法從一個種子 prompt 出發,每輪用反思(讓 LLM 看輸入輸出後改寫)與合併兩種方式產生新候選,再用 Pareto 前緣挑出「每個測試案例至少有一個候選能解」的集合,直到預算用完。
- 種子與反思模板都要自己調Mahmoud 把種子 judge 設成預設判合規,也自己寫了反思模板,因為預設的模板學不好。結果準確率有進步,但自己也承認離理想還遠。
- 要先小跑再放大小模型當 judge 或改寫者都失敗,單是這些小實驗就花了兩三百美元。Mahmoud 的建議是先在小迭代裡看 trace、先對訓練資料過擬合,再增加取樣。
原話
▶ 01:40“the speed in which you move to production or add features is actually the speed into which you can complete this loop.”
上線或加功能的速度,其實就是你跑完這個迴圈的速度
▶ 08:36“it does not make sense to have general metrics like hallucination when you're evaluating your ai agent”
評估自己的 agent 時,用 hallucination 這種通用指標沒有意義
▶ 12:37“having that reasoning is very important later for the llm as a judge to learn”
有那段理由,之後 LLM judge 才學得起來
▶ 27:21“if you don't have any reason to believe it's non-compliant, it should be compliant.”
沒有理由相信它不合規,就應該判合規
▶ 35:05“smaller models really are very bad at least in this example to be either an LLM as a judge or a refiner for the LLM as a judge”
至少在這個例子裡,小模型不管當 judge 還是改寫 judge 的角色都很糟
延伸
- Mahmoud 提到飛輪的想法:評估也能像 harness 一樣自動優化,這場只示範了 judge 的優化,沒有展開完整的自動迴圈。
- Mahmoud 的假設是:種子 prompt 一開始就放進 agent 的政策,會卡在局部最小值改不動;不放政策、只靠標註裡的理由,反而能把 prompt 的空間探索得更開。
章節
點時碼直接跳到原片的那一段。
- 開場:現成 judge 的問題以線上客服 agent 出包的情境破題,指出 hallucination judge 的 prompt 根本沒給模型判斷所需的資訊。
- 為什麼要校準 judge迭代速度取決於評估速度;人工標註準但慢,沒校準的 judge 快但訊號沒用;校準後可用於線上評估與資料飛輪。
- Mahmoud 與 AgentaMahmoud 是開源 LLMOps 平台 Agenta 的共同創辦人兼 CEO,有超過 15 年的機器學習經驗。
- 實作計畫與資料集以 tau-bench 的航空客服 agent 為例,資料有 599 筆附標註的對話 trace,政策複雜、資料不太乾淨。
- 四步驟與指標設計流程分設計指標、標註、優化 judge、驗證;指標要出自使用情境,由領域專家決定。
- 錯誤分析與四種錯誤專家逐筆標註再把錯誤分群,Mahmoud 歸出四類,並為每一類各做一個 judge,而不是一個總評審。
- 用是非判斷取代分數二元分類本來就難校準,再加 1 到 5 分更難,連兩個人工標註者都未必給同一個分數。
- 標註與理由、資料品質標註佇列要填判斷和理由;Mahmoud 說前兩步是最難的部分,而這份資料的 trace 少、分布不均、標註還是由 AI 依原始斷言產生。
- GEPA 演算法概觀概念近似遺傳演算法,從種子 prompt 出發,反覆取樣新候選、評估、保留好的;有兩種取樣策略,反思改寫與合併。
- Pareto 前緣選候選不挑平均分數最高的,而是看每個任務上最好的候選,保留能覆蓋所有案例的集合,增加多樣性。
- optimize anything 介面gepa 作者新推的 API,要給種子候選與評估函式;評估函式要回傳輸出之外的錯誤與推理等診斷資訊。
- Notebook:資料切分訓練集 480 筆、驗證集 112 筆,依任務切開,兩邊沒有重複;同一個模型多次跑出的資料在各自集合內有些冗餘。
- 種子 judge 的設計種子 judge 一開始就假設 agent 合規,只有找到具體理由才改判不合規;在驗證集上準確率 61%,幾乎都判合規。
- 自寫反思模板預設模板效果不如預期,自己寫了一份,讓它看到 judge 的判斷與標註答案,並要求它整理出真正的政策規則。
- 優化結果約跑一小時,judge 學到部分政策、偏誤消除,準確率從 69% 升到 74%;Pareto 前緣達 100%,但合併成單一 prompt 很吃力。
- 失敗的實驗用 GPT-4o 這類較小或較舊的模型都失敗;先小跑看推理、種子不放 agent 政策反而表現更好。
- 成本與建議小實驗就花兩三百美元,但對大量線上評估的 judge 而言值得;每個實驗約 200 到 300 輪,批次大小等參數也要調。
名詞
- LLM-as-a-judge
- 用 LLM 當評審判斷 agent 的輸出,這場的主題是怎麼把它校準到接近人工標註
- GEPA
- 優化 prompt 的演算法,靠反思改寫與合併產生候選,用 Pareto 前緣篩選
- Pareto frontier
- GEPA 選候選的方式,保留每個任務上表現最好的候選,而不是平均分最高的
- optimize anything
- gepa 函式庫新推的 API,可優化 prompt 以外的配置,需提供種子候選與評估函式
- tau-bench
- 客服 agent 的基準資料集,Mahmoud 用的是其中的航空客服情境;印象中是 Sierra 做的
- Agenta
- Mahmoud 共同創辦的開源 LLMOps 平台,涵蓋觀測、prompt 管理與評估
- Hamel
- hamel.dev 的作者,Mahmoud 認為錯誤分析與標註流程 Hamel 講得最好
- seed prompt(種子 prompt)
- GEPA 優化的起點,這場是一個預設「agent 合規」的簡單 judge
- reflection template(反思模板)
- GEPA 用來讓 LLM 看結果後改寫 prompt 的提示,Mahmoud 自己重寫了一份








