對於一個承諾解決 AI 工程最大挑戰的框架來說，這樣的落差令人懷疑。然而，使用 DSPy 的公司持續報告相同的好處。

JetBlue、Databricks、Zoro UK、VMware、Sephora、Replit

DSPy 的問題不在於它錯了，而是它很難。這些抽象概念不熟悉，迫使你以不同的方式思考。而你現在想要的不是改變思考方式，而是痛苦快點消失。

但我一直看到同樣的情況發生：人們最終實作出一個更差的 DSPy 版本。我喜歡開玩笑地說，現在有了 Khattab 定律（基於 Greenspun 對 Common Lisp 的定律）：

任何足夠複雜的 AI 系統，都包含一個臨時的、非正式規範、充滿錯誤的 DSPy 半成品實作。

你無論如何都會建立這些模式，只是會花更多時間、經歷更多痛苦，且做得更差。

讓我們來看看幾乎每個團隊如何最終實作自己的「自家 DSPy」。我們將以一個簡單的結構化抽取任務作為範例。別被範例的簡單性騙了；隨著系統越來越複雜，這些模式變得越來越重要。

假設你需要從文字中抽取公司名稱，你可能會先用 OpenAI API：

它基本上可行，所以你上線了，生活美好。

但不可避免地，產品團隊會想要更快迭代。每次提示詞改動都重新部署太麻煩了，所以你決定把提示詞存到資料庫：

現在你有了提示詞表格和一個簡單的管理介面來編輯它。當然，某人上週二弄壞了生產環境後，你還得加上版本歷史。

你注意到模型有時會回傳「Company: Acme Corp」而不只是「Acme Corp」，於是你加入結構化輸出：

你現在有了類型化的輸入與輸出，且更有信心系統在做它該做的事。

運行一段時間後，你會注意到像是 529 錯誤等暫時性失敗，或是解析失敗的罕見情況，於是你加上重試機制：

現在每次呼叫都有更多韌性。不過實務上你可能會因為重試一個過載且回傳 529 的服務只會得到另一個 529 而改用其他供應商。

最後，你可能開始解析更冷門的公司名稱，模型可能無法辨識某些實體是公司名稱，於是你想加上基於已知公司資訊的檢索增強生成（RAG）來提升抽取效果：

現在我們有兩個提示詞：一個用來建立查詢，一個用來解析公司名稱。我們也引入了其他參數如 k。值得注意的是，這些參數並非完全獨立，因為檢索到的文件會影響最終提示詞，任何改動都會影響整體效能。

你不斷更改兩個提示詞、嵌入模型、k 值以及任何能改的參數來修正錯誤，但你永遠不確定改動是否完全解決問題，也不確定是否破壞了其他功能。於是你終於意識到需要大家都在談的「評估」機制：

資料抽取任務是最容易評估的，因為有明確的「正確」答案。但即使如此，我們也能想像其中的複雜性。首先，我們必須確保用於評估的資料集始終代表真實資料。通常你的資料會隨著新用戶加入及用戶使用平台的方式改變而變動。保持資料集更新是評估維護的關鍵挑戰：確保評估測量的是你真正且持續關心的東西。

不可避免地，某家公司會釋出令人興奮的新模型，大家都想試試看。假設 Anthropic 推出新模型，但你的程式碼充斥著 openai.chat.completions.create，這對 Anthropic 並不適用。你的提示詞可能也不適合新模型。

於是你決定重構一切：

你現在有了類型簽名、可組合模組、可替換後端、集中重試邏輯，以及與應用程式碼分離的提示詞管理。

恭喜！你剛剛打造出一個更差的 DSPy 版本。

以下是在 DSPy 中完成的相同公司抽取任務——包含 RAG、評估與模型替換：

就是這樣。類型化輸入輸出、RAG、思路鏈推理、模型無關。沒有提示詞管理表格，沒有重試裝飾器，沒有 get_prompt("extract_company_v3")。

想試試 Claude 嗎？一行程式碼搞定：

不需重構，不需新 API 客戶端，也不需手動重新調整提示詞。優化器甚至能自動為新模型重新優化！

DSPy 封裝了每個嚴肅 AI 系統最終都需要的重要模式：

類型化輸入與輸出。輸入是什麼，輸出是什麼，並有架構定義。

可組合單元，可串接、替換、獨立測試。

改善提示詞的邏輯，與執行提示詞的邏輯分離。

這些只是軟體工程的基本功。關注點分離、可組合性、宣告式介面。但不知為何，許多優秀工程師要麼忘了這些，要麼難以將它們應用於 AI 系統。

你無法逐步執行提示詞。輸出是機率性的。當它終於運作時，你不想再碰它。

讓大型語言模型運作感覺像是一種成就。乾淨的架構感覺像是以後的奢侈品。

你該如何劃分界線？你的提示詞既是程式碼又是資料，什麼都不熟悉。

所以工程師做當下有效的事。內嵌提示詞。複製貼上並微調。一時解決方案變成永久方案。

但六個月後，他們淹沒在半吊子抽象的複雜度中。

DSPy 強迫你事先思考這些抽象概念。這就是為什麼學習曲線陡峭。替代方案是透過痛苦發現這些模式。

接受學習曲線。閱讀文件。做幾個玩具專案直到抽象概念理解透徹。然後用它做真正的工作。

不要直接用 DSPy，但從一開始就用它的模式來建構。見下文。

DSPy 採用率低，是因為它要求你在還沒感受到與眾不同思考痛苦前，就先改變思考方式。

DSPy 體現的模式不是可有可無。如果你的 AI 系統夠複雜，你一定會重新發明它們。唯一問題是你是有意還是無意。

你不必用 DSPy，但你應該像懂得它存在意義的人一樣建構系統。

如果你有共鳴，歡迎在 X 或 LinkedIn 繼續討論！