手調 prompt 的迴圈大家都跑過:改幾個字,跑一次,憑感覺判斷有沒有變好,再改幾個字。這個迴圈有兩個問題:「憑感覺」不可靠,「改幾個字」沒有方向。昨天說過,輸出一旦結構化就可以被程式打分數;今天講的就是把打分數接上優化迴圈之後發生的事:prompt 可以不用人寫。
DSPy 是 Stanford 開發的框架,它的核心想法是一個視角轉換:傳統做法把 prompt 手寫死在程式裡;DSPy 讓你只宣告任務的輸入輸出結構(叫 Signature,長得像型別宣告),具體的 instructions 留白,交給 optimizer 去找。
class GenerateResponse(dspy.Signature):
"""Solve the problem and provide the answer."""
problem = dspy.InputField()
answer = dspy.OutputField()
宣告跟實作分離之後,prompt 的地位就變了:它從你的創作,變成系統的可優化參數。這個轉換是今天整篇的前提。
GEPA 是 DSPy 的 optimizer 之一,來自一篇主張「反思式的 prompt 演化可以贏過強化學習」的研究。它的優化循環長這樣:
關鍵設計在第二步:metric 不能只回傳 0 或 1。純分數只告訴系統「錯了」,反思模型無從歸納。GEPA 要求 metric 附帶文字回饋:正確答案是什麼、完整解法長怎樣。反思模型拿到的是 16 份「錯誤加解答」,它才能歸納出「模型常把等腰三角形當成等邊三角形」這種具體規則,寫進新的 prompt 裡。
優化後的 prompt 長什麼樣?看實際跑出來的對比。優化前的 instructions 只有一句:
Solve the problem and provide the answer in the correct format.
GEPA 吃了 112 個訓練樣本之後,自動長出這種東西(節錄):
- For geometry problems:
- Confirm exact shape properties (isosceles triangle has
two equal sides; NOT equilateral)
- For word problems:
- "A beats B by 200 meters" means when A finishes,
B has run 800 meters NOT 600
每一條都對應一類真實發生過的錯誤:模型真的把等腰三角形當過等邊,真的把「領先 200 米」算錯過。它跟人類會寫的優雅指令完全是兩回事,不優雅,但有效,因為每個字都有失敗案例背書。
GEPA 的另一個設計值得單獨講:它用兩個模型。執行端用便宜的小模型跑大量樣本,佔 99% 的呼叫;反思端用強模型做深度分析,只佔 1%。一次實際的優化跑下來,兩百多個樣本的總花費不到半美元。
這個「執行要便宜、反思要聰明」的配置,之後會在很多系統裡再看到:量大的工作給小模型,找 pattern 的工作給大模型。先把這個模式記下來。
效果方面給個實際的數字:112 個訓練樣本、最輕量的優化模式,準確率從 52.2% 提升到 57.8%,大約 11% 的相對改善。樣本再多、優化開重一點,空間還更大。
自動優化不是萬靈丹,適用條件很明確:你要有明確的輸入輸出結構(能寫成 Signature)、要有帶正確答案的資料(metric 才有依據)、任務要可重複(優化出來的 prompt 才能攤提成本)。開放式對話沒有標準答案,GEPA 無從優化;需要即時調整的場景也不行,它是離線的批次流程。
滿足條件的場景(分類、抽取、固定格式的推理),它把 prompt engineering 從手藝變成 pipeline:收集失敗、自動歸納、驗證上線。
這六天把 L1 走完了:機制(Day 2)、成本(Day 3)、快取(Day 4)、結構化(Day 5)、自動優化(今天)。你可能注意到一件事:連自動優化都做了,這一層還是有些問題完全碰不到。模型不知道你公司的內部資料,再好的 instructions 也生不出它沒看過的事實;對話跑長之後品質下滑,問題也不在指令。明天講 L1 的極限:哪些問題在 prompt 層根本無解,為什麼答案在窗口的另一邊。