用 DSPy 做上下文工程

Evry 的評估（evals）負責人、O'Reilly 出版社 DSPy 專書作者 Mike Taylor 主張，DSPy 真正長久的價值不在提示技巧，而在於一套穩定的任務介面——有型別的輸入與輸出——能在模型更換後依然成立；而真正的回報來自「最佳化器—評估器」（optimizer-evaluator）迴路：用一個訓練過的 LLM 評審來訓練任務本身。本集大部分時間是在 Jupyter notebook 裡實作這套迴路：簽章（signature）、模組、訓練／測試切分、一個從 80% 起步並被最佳化到 100% 的評審，以及一個從 10% 起步、依模型不同可達約 70–85% 的人味改寫器（humanizer）。標題所稱的「脈絡工程」（context engineering）說得通但略嫌單薄——它主要出現在 Drew 主張 DSPy 簽章比 markdown 提示檔更好讀，以及結尾談 RLM 與 DSPy Flex 的討論中。

與 Taylor 同臺的是 Compound 共同創辦人 Isaac 與 Drew。Compound 是 DSPy 背後的團隊，也與 Dropbox、Shopify、Figma 等企業合作；Isaac 是該函式庫的主要維護者之一。讀者讀完應該能掌握最佳化器—評估器模式的具體運作機制、對資料需求有務實的認識（20 個範例就能跑，50 個以上最理想），以及講者對框架走向的看法：從非結構化回饋中學習指標，以及 Flex——讓最佳化器搜尋推論階段的策略，而不只是提示。

最佳化器—評估器模式是 DSPy 工作中可重複使用的核心

Taylor 最核心的實務貢獻，是一套針對「沒有標準答案」任務的兩階段做法。第一步，用你*確實*知道答案的資料（這段文字是不是 AI 生成的）訓練一個評審，採精確比對計分。等評審與你的標註高度一致後，再把它當成代理指標，去最佳化主觀任務（改寫 AI 文字，讓它讀起來像人寫的）。他說這套模式「幾乎用在我做過的每一個專案上」，包括為一家大型信用卡公司生成 5,000 個 AI 人物誌來測試卡產品方案。

現場示範的數字讓這套迴路一目瞭然：

Taylor 指出，評審最佳化跑了約 15 分鐘，花費約 1 美元的 OpenAI 額度。他提到這個評審「未經最佳化就已經是相當不錯的評審」，一開始就有 80%；而最佳化後學到的規則包括：不要「只因為文字文法正確、內容籠統簡短或只是在摘要某個概念」就判定為 AI 生成。

「你是為了最佳化器而來，卻為了簽章而留下，這話還真的一點不假。」——Mike Taylor

他描述的工作流程如下：

flowchart TD
    A["標註資料：人類 vs AI 文字"] --> B["以精確比對指標訓練評審"]
    B --> C{"評審夠準了嗎？"}
    C -->|"80% 到 100%"| D["把評審當作代理指標"]
    C -->|否| B
    D --> E["以評審為目標最佳化人味改寫器"]
    E --> F["推論時做 best-of-N 取樣"]
    F --> G["換掉模型字串，重新評估"]
    G --> H["與主管權衡成本與可靠性"]

Taylor 說明這件事在商業上的意義：「這就是你用 DSPy 賺到錢的方式——向你的老闆、客戶或團隊證明，你確實可衡量地改善了這項任務。」他把它連回自己績效行銷的背景——每花 1 美元要換回 2 美元的紀律——並主張 DSPy 讓團隊能展示 AI 任務的投資報酬率，「而這正是現在大多數人做不到的事。」

GEPA 的結構勝過把同樣的活交給 coding agent

Drew 明確區分 GEPA（這群人唸作「JEPA」，刻意撞名 Yann LeCun 的 JEPA；Drew 說這讓 LeCun 很不高興，還發文說發明者應該改掉發音）與一般所謂的代理式最佳化。他的主張是：GEPA「在成本和能達到的上限上都傾向勝出」，關鍵在於它如何管理脈絡——勝出的提示會成為下一輪變體的起點，在遺傳式的帕雷托前沿（Pareto front）上測試，而這個結構「恰好能把模型推出原本的分佈，找到新穎的想法」。

他引用一批近期關於脈絡慣性（context inertia）的研究佐證，並說自己在部落格上寫過整理。三個來源指向同一結論：Anthropic 的 Fork and Flush 論文、UC Berkeley 研究者 Shengyan Tan 關於「遺忘」重要性的論文，以及一篇關於長跨度任務的相關論述。Drew 轉述的發現是：到了某個點，模型會過度聚焦在單一解法上，忽略需要橫向思考的更好方案；把脈絡刪掉就能重置。據稱 Tan 的論文顯示，隨著脈絡變長，推理 Token 越來越短、修改幅度越來越小——而遺忘能讓兩者都回升。

「脈絡越長，模型想得越少……修改幅度——在我看來這才是最大的問題——越來越短、越來越短、越來越短。」——Drew

Taylor 在 notebook 裡示範 GEPA 時，最佳化器在第 3 輪就提出新的提示，還自己寫出規則。Drew 也提到一則社群軼事：有人拿 GEPA 去跑 GPT-OSS-20B，發現許多勝出的提示都以「good luck」結尾——這是最佳化器找到、人類絕對想不到的模型專屬怪癖。

簽章是穩定的那一層，底下的一切卻不斷在變

Drew 最有力的架構論點是：DSPy 的介面從 ChatGPT 問世之前至今幾乎沒變，而「AI 生態系裡幾乎其他所有東西都不斷被重新發明」。他說自己兩年前寫的 DSPy 程式現在還能跑——只要換模型、重新最佳化就好。Taylor 說這是他「現在唯一會讀的程式碼」；Drew 則主張 DSPy 簽章讀起來像 pseudocode，比「一大段 markdown 檔或三引號字串」好得多。

Taylor 拆解其結構：一個繼承 dspy.Signature 的類別、一段作為提示起點的 docstring，以及 dspy.InputField / dspy.OutputField 宣告。他坦承對習慣手寫提示的人來說，把內容放在 docstring 裡「感覺有點不自然」，請大家先忍耐一下。Isaac 的提醒是：「如果你發現自己在 docstring 裡做太多提示工程，那就是個大警訊。但當然，先把所有資訊都丟進去，之後再慢慢學。」Drew 指出也可以透過 instructions 引數傳入長指令，並提到在最近一次測試中，精簡的 docstring 和「相當於一份技能清單的 Markdown」都必須經過最佳化才能達到上限。

模型設定只要一行——用 dspy.LM 加上 API key——換模型就是改一個字串。Isaac 提到，就在錄音前一天，DSPy 已不再依賴 LiteLLM，他稱之為「非常令人振奮」，並歸功於「Isaac、Max 與團隊的艱鉅努力」。

結構化輸出省掉了過去定義提示工程的那堆解析程式碼

Taylor 說結構化 I/O「被嚴重低估」。因為 DSPy 知道輸出欄位，所以不需要正規表示式、不需要解析程式碼、也不需要「請以人類回應冒號開頭作答」這類指令。Isaac 的說法：「寫解析程式碼超痛苦，根本不該有人得寫解析程式碼。連你的 agent 都不該寫。」Taylor 的版本：「你的 agent 把 Token 都捐給我們的 agent 了。」

Drew 描述他在 Overture Maps Foundation 把這件事推到極致。該基金會是 Linux 基金會旗下推動免費開放地理空間資料的組織：他們把一整個大型 Pydantic schema 當成輸出型別傳進去，「它照樣搞定」。Taylor 則提到一份 5,000 人人物誌的信用卡調查，客戶的問卷約有 15 個選項、每個選項還有子選項；他建好 Pydantic 物件後，所有重試程式碼都成了多餘——「第一次就全部答對。」

對話中提到 TypeSafe（decision model 背後的公司）主要是作為對照。Taylor 說他跟該團隊通話的前 10 分鐘，都在被 Diogo 調侃結構化輸出早已取代純文字輸出。Drew 釐清相容性規則：decision model 支援與浮點數相容的輸出，例如布林值和選項，但若混入字串輸出就不行；同一個簽章可以跑在 decision model 或 LM 上，所以品質不夠時換掉模型字串即可。Isaac 對「DSPy 從 2022 年就能做一樣的事，為何 TypeSafe 會爆紅」的觀察是：「如果它真的又快又便宜，我就會真的動手拿它來做東西。」

評估是資產，資料工作是本業

Taylor 直言，DSPy「逼你把功課做完」，而他做 DSPy 之後大部分的工作，是找或親手寫出好的範例，有時還要跟領域專家一起寫。他用自駕車比喻這個轉變：規則退場，行車影像上場。「DSPy 有點像在幫你的程式做自駕，只不過物件是你的程式。所以你的工作就是收集行車影像。」

Drew 把這個道理延伸到組織設計：當領域專家直接改提示、改程式碼，就會產生程式碼衝突——這正是產品經理把使用者故事與實作切開來所要解決的問題。在 DSPy 裡，專家的範例存在自己的空間，與控制流程隔離。

談到資料量，Taylor 說即使只給 GEPA 一輪，它寫出的提示也比他好；示範用了約 20 個範例，而最理想是 50 個以上。Drew 說這要看任務——精確比對型的任務可能要 100–200 個——並提到 GEPA 最早的應用場景（改善 agent 對 Qualcomm 硬體晶片指令集的運用）大約用了 40 個範例。Drew 對建立評估資料的建議，是本集最值得引用的實務重點：

「不要只在 markdown 檔裡寫『不要這樣』，而是用一個範例說『不要長這樣』，這種做法才能長長久久。」——Drew

兩位主持人都強調要看資料。Taylor：「我每次出問題，原因都是我沒去看資料。」Drew 建議用 vibe coding 做資料檢視工具——他前一天才替自己的資料做了一個 Tinder 式的左滑／右滑介面。Taylor 的版本：「你現在不用再看程式碼了，但你一定要看你的資料。」

RLM 與 Flex 指向會寫程式的最佳化器，而不只是寫提示

Isaac 把 RLM（遞迴語言模型，recursive language model）形容為「LLM 的 code mode 版本」：輸入以變數形式放進 Python REPL，模型自己寫程式來完成簽章——例如為一本書的每一章各開一個子 agent 做摘要，再合併結果。Taylor 的簡稱是「DSPy 版的 Claude Code」，主執行緒永遠不會把脈絡用完。

Isaac 列出適合用 RLM 的三種情況：任何長脈絡問題（直接預設用它）、涉及符號操作而用 for 迴圈比把摘要塞進脈絡更有效的任務，以及你不想讓模型一次發出 12 個平行原生工具呼叫的情況。他說很常見的做法是檢視 RLM 寫了什麼，把它反覆寫出的函式提升為工具，逐步推向確定性。

DSPy Flex 則是這件事的極端版：一個模組，底下可接受任何推論階段策略，由最佳化器嘗試各種模組、策略與拆解方式的組合，找出最能滿足簽章的做法。Taylor 的形容是：你只寫上層簽章——這是我的輸入，這是我要的輸出——「它基本上就幫你把 DSPy 模組寫好了。」Isaac 確認 Flex 寫出的所有東西都會回饋到你的簽章裡。

談到發展藍圖，Isaac 說有一個最佳化器正在研究中，目標是接收範例上的非結構化回饋，從中學出指標與資料集。Taylor 開玩笑：「我本來是提示工程師，DSPy 讓我失業，我就轉去當評估負責人，現在你們連這個也要自動化。」Isaac 的回答是：「你會變成回饋工程師。」

檔案、採用，以及「知道自己要什麼」的難題

Drew 提出一個尚無定論的問題：現在 agent 也會讀檔案，那檔案到底是給誰看的？他的答案是，人類需要的是心智模型，好在鍵盤前知道自己該要求什麼，而不是細節。Taylor 的書《DSPy in Eight Steps》是在向原版檔案的好記程度致敬；他說會寫這本書，是因為原網站「太學術」，讓他覺得「自己笨到用不了這個工具」。

談到非技術人員的採用，Drew 認為在 Claude Code 專案層級工作的人可以用：請它寫 DSPy，產出的程式碼你看得懂也改得動，而且因為這套介面深植於模型權重之中，agent 本來就知道怎麼寫簽章。Isaac 的採用論點是：「任何最後採用最佳評估實務的團隊，最後都會走上自己打造 DSPy 這條路。」Taylor 的陰謀論則是：很多公司用了 DSPy 卻不張揚，因為把它當成獨門秘方；Drew 證實確實有公司會告訴 Compound，但要求不要具名。

結尾由 Taylor 收束：DSPy 像一面鏡子。「它不讓你拖延這些事。我想當人們說自己用 DSPy 很痛苦時……你真正痛苦的其實是：要搞清楚自己到底要什麼，真的很難。」Drew 說這句標語出自一位叫 Raymond 的人：DSPy 的標語應該是「太好了，現在我非得知道自己要什麼了。」

值得關注

有兩條線索尚未有結果，值得持續追蹤。第一，Isaac 描述的那個「學習指標」最佳化器明確還是研究專案，沒有時程——如果成功，它會自動化人類目前最難的最後一步（寫評估），並把工作重心轉向收集回饋，也就是 Taylor 所說的「回饋工程師」。第二，Compound 表示錄音後約四到六週會有平臺訊息——一個可以推送程式、呼叫執行、觀察執行、最佳化成新版本、做 A/B 測試，再扶正贏家的地方。Taylor 自己的示範還透露了一個較不張揚的重點：同一個最佳化過的程式從一個模型換到 Gemini 後，成績提升約 10 個百分點——這正是他所說、團隊應該跟主管明確討論、而不是憑感覺決定的成本與可靠性取捨。