打造高信號回饋的自我優化迴圈

070Annabell Schäfer（Langfuse）17:392026-07-18

Stop Burning Tokens: Why self-improvement needs domain expertise first - Annabell Schäfer, Langfuse

用單一標籤分類任務測試 agent 自我優化迴圈，說明多數領域沒有明確對錯，得先設計出高信號評估標準才能真正持續改進。

重點摘要

多數任務沒有清楚對錯：coding 之所以能自動優化，是因為有「code compiles 與否」這種明確訊號，但像醫療合規、分類這類場景，目標本身就不完整，很難有這麼乾淨的判準。
拿分類任務找最乾淨的訊號：實驗用 archive 論文分類當測試題，用 GPT-5 nano 當受測 agent、Claude Opus 4.8 當優化者，跑在 fit、validate、test 三份資料上，避免過擬合。
迴圈跑法很單純：先用最陽春的 prompt 跑出 baseline 準確率，做錯誤分析，Opus 針對最大錯誤類別提案修改，通過 validation 才採用，設定 15 輪或 92% 準確率兩個停止條件。
第一輪就吃下大部分進步：準確率從 baseline 一路衝到 83%，之後大致維持在 80% 上下，在 test set 上也有 80.2% 的表現，顯示高信號回饋能讓優化者很快抓到問題核心。
優化加的是規則和範例，不是描述：Opus 加進 prompt 的是分類原則、易混淆類別的判斷規則，還有常錯的範例配對，而不是講者原本猜測的「幫每個標籤補說明」。
把高信號設計搬進真實應用：與其用 correctness、helpfulness 這種一到十分的評分，不如拆成 yes、no 的具體判準，例如「答案是不是真的來自知識庫」「品牌名稱有沒有拼對」，再靠找專家一起看樣本、定期人工複查，把隱性知識變成明確範例。

時間軸13 段

00:00	開場	講者是 Langfuse 的 growth engineer，主題是別浪費 token，要及早把領域知識放進迴圈設計與應用設計裡。
00:42	coding 為何能自動優化	coding 之所以能自動朝目標前進，是因為一直都有「code compiles 與否」這種清楚的目標函數。
01:19	多數領域目標不明確	醫療合規、聊天機器人這類應用的目標函數不夠清楚，一開始設定的方向也未必是最佳終點。
02:28	找最乾淨的目標函數	為了驗證這個問題，選了單一標籤分類當測試題，因為可以直接用準確率判斷對錯。
03:32	打造最小自我優化迴圈	用 GPT-5 nano 當 agent、Claude Opus 4.8 當優化者，在 fit、validate、test 三組資料上跑，避免過擬合。
05:57	迴圈實際跑法	先跑 base prompt 拿 baseline 準確率並做錯誤分析，Opus 針對最大錯誤類別提案，通過 validation 才採用，15 輪或 92% 準確率任一達成就停。
07:16	結果衝到 83%	準確率從 baseline 一路上升到 83%，之後大致維持在 80% 上下，在 test set 上也有 80.2% 的表現。
08:09	第一輪吃下大半進步	準確率最大的躍進發生在第一次疊代，一次跳了 10%，之後的進步幅度就小很多。
10:05	Opus 怎麼找問題	針對從 68% 跳到 78% 的那一輪，Opus 會先統計錯誤數量與最常混淆的類別，再據此形成假設並修改 prompt。
11:49	多數應用沒有這種乾淨訊號	大部分場景沒有非黑即白的答案，LLM-as-judge 本身也不穩定，同一個評分同一次評測跑兩次都可能不同。
13:14	把低訊號評分換成具體判準	correctness、helpfulness 這種一到十分的評分訊號太弱，不如拆成「答案是否真的出自知識庫」這種 yes、no 的具體判準。
15:03	靠專家與人工複查建立訊號	建議找領域專家一起看樣本、問為什麼是這個而不是那個，把隱性知識變成明確範例，並定期用人工而非 coding agent 複查 production 資料。
16:47	迴圈要有驗證與停損機制	像傳統機器學習一樣做 validation 避免過擬合，同時要給系統逃生出口，不要讓它耗時耗力還一直燒 token。

值得記的話5 句

a target that you give an agent is actually also always incomplete.agent 拿到的目標，本身也永遠不完整01:19
the first iteration immediately gained 10% and then it was only a little bit movement.第一次疊代就直接拿下 10%，之後的進步幅度就小很多08:09
what are the quality criteria that you want to work for your application.你該問的是，這個應用要達到什麼判準才算好13:14
the most important thing we see is working with your experts.我們看到最重要的一件事，就是和你的領域專家一起合作15:03
you're not just burning tokens but actually looping towards a system where a human and your agent together collaborate on an improving system.重點不是在燒 token，而是朝著人類與 agent 一起協作、持續改進的系統前進17:03

名詞與人物9 個

Langfuse: 開源的 LLM 觀測與評估平台，講者任職的公司。
target function（目標函數）: 這場的核心概念，指用來判斷 agent 輸出對錯的量化標準。
fit / validate / test 資料集: 這次實驗切出的三份資料，分別用來找錯誤模式、驗證修改是否泛化、最後測試整體效果。
GPT-5 nano: 這次實驗中被優化的 agent 所用的小型便宜模型，講者挑它就是要看很小很便宜的模型能被優化到什麼程度。
Claude Opus 4.8: 這次實驗中負責分析錯誤、提出 prompt 修改的優化者模型。
LLM-as-judge: 用語言模型當評審打分數的評估方式，講者認為它本身也不穩定。
Andrej Karpathy: 講者提到今年稍早引爆「自動改進」話題討論的人物。
Peter Steinberger: 講者提到主張「該設計 loop、不要直接對 agent 寫 prompt」的人物。
Boris Cherny: 講者開場引用的人物之一，說自己已經不寫 prompt、只設計 loop；同段還引用了 Peter Steinberger。

提到但沒有展開

Opus 提案修改時參考的模型官方 prompting guide，這場只提到名字，沒有說明內容。
Boris 那句「不再自己寫 prompt、只設計 loop」的說法，這場只當引言帶過，沒有展開脈絡。
講者提到 Langfuse.com 有更多相關想法，但這場沒有進一步說明是哪些內容。

評估Agent開發工具

在 YouTube 看原片 ↗