不再手動調 Prompt——DSPy 讓 AI 自動優化自己的完整教學

45%。這是 Dropbox 把手動 Prompt 換成 DSPy 自動優化後，預測誤差降低的幅度。原本工程師要花一到兩週反覆調整的 Prompt，DSPy 在一到兩天內就跑完優化，而且結果更好。

如果你曾經花整個下午在改一句 Prompt、加幾個 few-shot example、然後重新跑測試，只為了讓 LLM 的輸出品質提升那麼一點點——DSPy 要解決的就是這個問題。它是一套用程式碼定義「你要什麼」、讓演算法自動幫你找到最佳 Prompt 的框架，並非又一個 Prompt 模板庫。

Stanford NLP 團隊從 2022 年開始研發 DSPy，到 2026 年已經累積超過 28,000 個 GitHub Stars、每月 16 萬次 pip 下載。JetBlue、Databricks、Sephora、VMware 等企業已經在生產環境使用。這不再是實驗室裡的玩具——它正在改變工程團隊跟 LLM 互動的方式。

這篇文章會帶你完整走過 DSPy 的三大核心概念——Signature、Module、Optimizer——搭配可以直接跑的 Python 程式碼範例，讓你從「手動調 Prompt」畢業，進入「程式化優化 Prompt」的階段。無論你是剛接觸 LLM 應用開發的工程師，還是已經在生產環境跑 RAG pipeline 的團隊，都能從這裡找到可以立刻用上的東西。

為什麼手動 Prompt Engineering 走到了瓶頸

先講一個大家都有過的經驗：你寫了一段 Prompt，在 GPT-4 上跑得很好，換到 Claude 上結果就崩了。或者你好不容易調出一個穩定的 Prompt，結果模型一更新，輸出格式又亂掉。

手動 Prompt Engineering 的核心問題在於——它是一個不可重現、不可擴展、高度依賴直覺的過程。你沒辦法用版本控制管理它，沒辦法用自動化測試驗證它，更沒辦法在模型升級時自動適配。

一份 2026 年的產業分析指出，隨著 LLM 應用從概念驗證進入生產環境，手動 Prompt Engineering 已經成為最大的維護負擔之一。每次模型版本升級、每次新增一種輸入場景，都需要工程師重新調整 Prompt——這在只有一兩個 LLM 呼叫的小專案裡還行，但在有十幾個 LLM 模組串聯的 pipeline 裡，維護成本呈指數級上升。

手動調整與程式化優化的本質差異

如果你的專案只有一個簡單的 ChatGPT API 呼叫，手動 Prompt 完全夠用。但一旦你的系統有 RAG 檢索、分類器、摘要器等多個 LLM 模組串在一起，手動逐一調整每個模組的 Prompt 就變成一場噩夢。這正是 DSPy 的切入點。

DSPy 到底是什麼——用程式取代猜測

DSPy 的全名是 Declarative Self-improving Python，由 Stanford NLP 團隊開發。它的核心理念用一句話概括：Programming, not prompting。你不再手寫 Prompt，而是用 Python 程式碼定義你要 LLM 做什麼（輸入和輸出的語意規格），然後讓 DSPy 的 Optimizer 自動幫你生成、測試、篩選出效果最好的 Prompt。

想像你在訓練一個機器學習模型：你不會手動去調整每個神經元的權重，而是定義 loss function 和訓練資料，讓 gradient descent 自動優化。DSPy 對 Prompt 做的事情本質上一樣——你定義評估指標和訓練範例，讓演算法自動搜尋最佳的 Prompt 組合。

DSPy 的三個核心元件構成了完整的工作流程：

• Signature（簽名）：宣告你要 LLM 做什麼——輸入是什麼、輸出是什麼
• Module（模組）：決定 LLM 該怎麼做——用什麼策略執行（直接回答、思維鏈、ReAct 等）
• Optimizer（優化器）：自動搜尋最佳的 Prompt——生成指令、挑選 few-shot 範例、調整參數

Signature——告訴 LLM「你要什麼」

Signature 是 DSPy 最基礎的概念。它用宣告式的方式定義一個 LLM 任務的輸入和輸出，不涉及任何實作細節。你只需要告訴 DSPy：「我會給你什麼，你要回給我什麼」，剩下的交給框架去處理。

Inline Signature：最簡潔的寫法

最簡單的 Signature 就是一個字串，用箭頭分隔輸入和輸出：

# 最簡單的問答 Signature
qa = dspy.Predict("question -> answer")

# 帶上下文的 RAG 風格 Signature
rag = dspy.Predict("context: list[str], question: str -> answer: str")

# 情感分類
classifier = dspy.Predict("text -> sentiment: Literal['positive', 'negative', 'neutral']")

# 多輸出
summarizer = dspy.Predict("document -> summary: str, keywords: list[str]")

注意看：欄位名稱本身就帶有語意。question 和 answer 不只是變數名，DSPy 會利用這些名稱的語意來生成 Prompt。所以命名很重要——用 question 比用 input1 效果好得多。

Class-Based Signature：適合複雜任務

當任務比較複雜、需要更多描述時，可以用 Python class 定義 Signature：

import dspy
from typing import Literal

class EmotionClassifier(dspy.Signature):
    """根據使用者的訊息，判斷其情緒狀態。"""
    
    message: str = dspy.InputField(desc="使用者發送的訊息內容")
    context: str = dspy.InputField(desc="對話的前後文脈絡")
    emotion: Literal["happy", "sad", "angry", "neutral", "anxious"] = dspy.OutputField()
    confidence: float = dspy.OutputField(desc="情緒判斷的信心分數，0 到 1 之間")

# 使用這個 Signature
classify = dspy.ChainOfThought(EmotionClassifier)
result = classify(message="今天被主管罵了一頓", context="工作壓力大的上班族")
print(result.emotion)      # angry
print(result.confidence)   # 0.85

Module——決定 LLM「怎麼做」

有了 Signature 定義「做什麼」，Module 決定「怎麼做」。DSPy 提供多種內建 Module，每一種對應不同的推理策略：

Module 的威力在於——你可以用同一個 Signature，搭配不同的 Module，看哪種推理策略效果最好。這就像在機器學習裡，你不會一開始就決定要用 Random Forest 還是 XGBoost，而是先定義問題，再嘗試不同的演算法。

更重要的是，Module 可以組合。你可以把多個 Module 串成一個 pipeline——先用一個做文件檢索，再用一個做答案生成，最後用一個做事實驗證。DSPy 的 Optimizer 會端到端地優化整個 pipeline 中每一個 Module 的 Prompt，而不是讓你逐個手動調整。

實戰：打造一個 RAG Pipeline Module

下面是一個完整的 RAG（Retrieval-Augmented Generation）pipeline，用 DSPy 的方式來寫：

import dspy

# 1. 設定 LLM
lm = dspy.LM("openai/gpt-4o-mini", max_tokens=1000)
dspy.configure(lm=lm)

# 2. 定義 RAG Module
class RAGModule(dspy.Module):
    def __init__(self, num_passages=3):
        self.retrieve = dspy.Retrieve(k=num_passages)
        self.generate = dspy.ChainOfThought(
            "context: list[str], question: str -> answer: str"
        )
    
    def forward(self, question: str):
        # 檢索相關段落
        context = self.retrieve(question).passages
        # 基於上下文生成答案
        result = self.generate(context=context, question=question)
        return dspy.Prediction(answer=result.answer)

# 3. 建立實例並使用
rag = RAGModule(num_passages=5)
response = rag(question="DSPy 的 Optimizer 有哪些類型？")
print(response.answer)

注意這段程式碼裡完全沒有出現任何 Prompt 文字。你定義的是程式邏輯——檢索多少段落、用什麼推理策略——而不是「請根據以下上下文回答問題，注意要準確且簡潔...」這種手工 Prompt。實際的 Prompt 內容，交給 Optimizer 去生成和優化。

Optimizer——讓演算法幫你找到最佳 Prompt

Optimizer 是 DSPy 最具突破性的元件。它接收三樣東西：你的 DSPy 程式、一組訓練資料、一個評估指標——然後自動搜尋出效果最好的 Prompt 組合（包括指令文字和 few-shot 範例）。

這個過程很像機器學習的超參數搜尋：Optimizer 會嘗試不同的 Prompt 變體，用你定義的指標評估每一個變體的效果，最後保留分數最高的那一組。整個過程通常花 10 到 30 分鐘，成本大約 2 到 10 美元。

主要 Optimizer 完整解析

DSPy 目前提供七種 Optimizer，各有適用場景：

BootstrapFewShot 是最基礎的 Optimizer。它會用一個「教師」模型（通常是更大的 LLM）來為你的訓練資料生成完整的推理過程（demonstrations），然後把最好的幾個注入到 Prompt 裡作為 few-shot 範例。適合訓練資料少於 10 筆的場景。

MIPROv2 是目前最強大的 Optimizer。它結合了指令生成、few-shot 範例挑選、以及貝氏優化（Bayesian Optimization）三種技術。在每一輪優化中，它會同時考慮指令的變化和範例的搭配，用貝氏優化來高效探索這個組合空間。Stanford 團隊的 benchmark 顯示，MIPROv2 在多數任務上的表現優於其他所有 Optimizer。

COPRO（Collaborative Prompt Optimization）用座標上升法（coordinate ascent）來優化指令。它不動 few-shot 範例，只專注於找到最好的指令文字。適合你只需要優化指令、不需要 few-shot 的場景。

GEPA 是一個比較新的 Optimizer，它讓 LLM 反思整個程式的執行軌跡——哪些步驟做得好、哪些步驟出了問題——然後根據反思結果提出改進方案。這個概念跟反思型 Agent 架構很類似，本質上就是讓 AI 自我改進。

Optimizer 選擇速查表

實戰範例與真實案例——DSPy 的效果有多大

光講概念不夠，直接看一個完整的端到端範例。假設你要做一個「問答品質評估器」——給定一個問題和一個回答，判斷這個回答是否正確且完整。

import dspy
from dspy.evaluate import Evaluate

# ── Step 1: 設定 LLM ────────────────────────────
lm = dspy.LM("openai/gpt-4o-mini")
dspy.configure(lm=lm)

# ── Step 2: 定義 Signature ──────────────────────
class AnswerQuality(dspy.Signature):
    """評估一個回答是否正確且完整地回應了問題。"""
    question: str = dspy.InputField(desc="使用者的問題")
    answer: str = dspy.InputField(desc="模型生成的回答")
    is_correct: bool = dspy.OutputField(desc="回答是否事實正確")
    is_complete: bool = dspy.OutputField(desc="回答是否涵蓋問題的所有面向")
    score: float = dspy.OutputField(desc="整體品質分數，0.0 到 1.0")

# ── Step 3: 建立 Module ────────────────────────
evaluator = dspy.ChainOfThought(AnswerQuality)

# ── Step 4: 準備訓練資料 ────────────────────────
trainset = [
    dspy.Example(
        question="Python 的 GIL 是什麼？",
        answer="GIL 是 Global Interpreter Lock，限制 Python 同時只有一個 thread 執行 bytecode。",
        is_correct=True, is_complete=False, score=0.7
    ).with_inputs("question", "answer"),
    dspy.Example(
        question="Docker 和 VM 有什麼差別？",
        answer="Docker 用容器虛擬化，共享主機 OS kernel；VM 是完整的作業系統虛擬化。Docker 更輕量、啟動更快。",
        is_correct=True, is_complete=True, score=0.95
    ).with_inputs("question", "answer"),
    # ... 實際場景建議準備 50-200 筆
]

# ── Step 5: 定義評估指標 ────────────────────────
def quality_metric(example, prediction, trace=None):
    score_diff = abs(example.score - prediction.score)
    correct_match = example.is_correct == prediction.is_correct
    return correct_match and score_diff < 0.15

# ── Step 6: 執行優化 ────────────────────────────
optimizer = dspy.MIPROv2(
    metric=quality_metric,
    auto="medium",    # light / medium / heavy
    num_threads=4,
)
optimized_evaluator = optimizer.compile(
    evaluator,
    trainset=trainset,
)

# ── Step 7: 儲存並部署 ──────────────────────────
optimized_evaluator.save("optimized_evaluator.json")

# 載入已優化的程式
loaded = dspy.ChainOfThought(AnswerQuality)
loaded.load("optimized_evaluator.json")
result = loaded(
    question="什麼是 Kubernetes？",
    answer="K8s 是容器編排平台。"
)
print(f"正確: {result.is_correct}, 完整: {result.is_complete}, 分數: {result.score}")

這段程式碼的重點：從頭到尾你沒有寫過一行 Prompt 文字。你定義了問題的結構（Signature）、選擇了推理策略（ChainOfThought）、準備了訓練資料、設定了評估指標——然後讓 MIPROv2 自動幫你找到效果最好的 Prompt 組合。最後你可以把優化結果存成 JSON，部署到生產環境。

真實案例——企業級的 DSPy 成效數據

理論講完了，來看真實世界的數字。

Dropbox Dash：NMSE 降低 45%

Dropbox 的工程團隊公開分享了他們用 DSPy 優化 Dash 搜尋產品的 LLM 評分器（relevance judge）的過程。這個評分器負責判斷搜尋結果跟用戶查詢的相關程度——直接影響 Dash 的搜尋品質。

導入 DSPy 之前，工程師手動調 Prompt 的迭代週期是一到兩週。導入之後，同樣的優化流程在一到兩天內完成。更關鍵的是結果：NMSE（Normalized Mean Squared Error）從 8.83 降到 4.86，降幅達 45%。而且因為優化後的 Prompt 可以在更便宜的模型上跑，標註成本降低了 10 到 100 倍。

ArXiv 多任務研究：準確率提升 18 個百分點

一份 ArXiv 上的多場景研究在多個 NLP 任務上測試了 DSPy 的效果。在 Prompt 品質評估任務上，準確率從 46.2% 提升到 64.0%——這純粹靠優化 Prompt 就達到的效果，過程中並未微調模型。在 hallucination detection 任務上也觀察到選擇性的改進。

綜合多個公開案例，DSPy 在結構化任務上通常能帶來 10-40% 的品質提升。但要注意：DSPy 不是銀彈。在非常開放式的創意生成任務上，自動優化的效果往往不如在有明確評估標準的任務上明顯。

DSPy 與其他框架的定位比較

很多人會問：「我已經在用 LangChain / LlamaIndex 了，還需要 DSPy 嗎？」答案是：它們解決的是不同層次的問題。

關鍵觀念：DSPy 跟 LangChain、LlamaIndex 不是互斥的。你完全可以用 LangChain 搭建應用架構、用 LlamaIndex 處理向量檢索，然後用 DSPy 來優化整個 pipeline 中每一個 LLM 呼叫的 Prompt。事實上，Haystack 已經提供了 DSPy 整合模組，讓你直接在 Haystack pipeline 中使用 DSPy 的優化能力。

如果你正在開發AI Agent 系統，DSPy 可以用來優化 Agent 中每個工具呼叫的決策 Prompt。在多 Agent 辯論架構中，每個 Agent 的推理品質直接決定辯論的深度和結論的可靠性——用 DSPy 優化每個 Agent 的 Prompt，等於同時提升整個系統的智能水準。

導入 DSPy 的具體步驟與避坑指南

看到這裡，你大概已經想試試看了。以下是從零開始導入 DSPy 的建議路徑：

第一階段：從單一模組開始

不要一開始就想把整個 pipeline 都用 DSPy 重寫。先挑一個效果最差、或最難手動調 Prompt 的模組，用 DSPy 重構它。觀察優化前後的指標變化，建立信心。

• 安裝：pip install dspy，目前最新版本為 2.6.x
• 準備 10-30 筆帶標註的測試資料
• 定義明確的評估指標（accuracy、F1、自訂 metric function）
• 用 BootstrapFewShot 做第一次優化，觀察基準提升

第二階段：擴展到多模組 pipeline

第一個模組成功後，把 pipeline 中其他 LLM 呼叫也用 DSPy Module 包裝。這時候你會發現 DSPy 端到端優化的真正威力——它會自動協調多個模組之間的 Prompt，而不是各自為政。

第三階段：生產環境部署

優化完成後，用 .save() 匯出 JSON，在生產環境用 .load() 載入。DSPy 程式在推論階段不需要 Optimizer，就是一般的 Python 程式——不會增加額外的延遲或依賴。

如果你的團隊正在評估思維樹（Tree of Thoughts）或Constitutional AI等進階推理技術，DSPy 的 Module 系統讓你可以很自然地把這些技術整合進 pipeline，並且用 Optimizer 自動找到最佳的組合方式。

DSPy 在 2026 年的發展與未來方向

2026 年的 DSPy 跟 2024 年初發布時已經是完全不同的東西了。社群貢獻者超過 250 人，生態系圍繞著幾個核心方向在擴展：

• 新的 Optimizer 不斷加入——SIMBA 用隨機小批量取樣來找出挑戰性範例，GEPA 用 LLM 反思軌跡來發現盲點，BetterTogether 則把 Prompt 優化和權重優化結合在一起
• 生態系整合深化——Haystack、Databricks、MLflow 等平台都已提供 DSPy 整合，在既有的 MLOps 工作流程中加入 Prompt 優化變得越來越簡單
• 生產環境工具成熟——.save() / .load() 的序列化機制、推論階段的輕量化運行、與現有 CI/CD pipeline 的整合文件，都讓 DSPy 從研究工具走向生產就緒
• 多模態支援探索——隨著視覺語言模型的成熟，DSPy 社群正在探索如何把 Signature 和 Optimizer 的概念延伸到圖片和多模態輸入

值得一提的是，DSPy 的成長並不意味著手動 Prompt Engineering 會消失。就像自動化測試沒有消滅手動測試一樣，DSPy 更像是給了你一個強大的工具——在需要的時候，你仍然可以手動介入、微調 Signature 或修改訓練資料。它是增強你的能力，不是取代你的判斷。

該不該現在導入 DSPy——決策清單

DSPy 很強大，但不是每個專案都適合。以下幾個問題可以幫你判斷：

• 你的系統有 2 個以上的 LLM 呼叫嗎？如果只有一個簡單的 API 呼叫，手動 Prompt 足矣。多模組 pipeline 才是 DSPy 發光的場景。
• 你有辦法定義量化的評估指標嗎？DSPy 的 Optimizer 需要一個 metric function 來衡量好壞。如果你的任務無法量化評估（純創意寫作等），DSPy 能幫的有限。
• 你有至少 10-30 筆帶標註的測試資料嗎？沒有資料就沒辦法優化。好消息是 DSPy 需要的資料量很少——不像 fine-tuning 動輒要幾千筆。
• 你的團隊有 Python 和基本 ML 概念嗎？DSPy 的 API 設計跟 PyTorch 類似，如果你的團隊熟悉 ML 框架的思維模式，上手會很快。

如果以上四個問題中有三個答案是「是」，那現在就是導入 DSPy 的好時機。如果你的專案還在早期探索階段、或者團隊對 ML 概念不熟悉，建議先從手動 Prompt Engineering 開始，等到系統複雜到手動調整不動了再引入 DSPy。

不確定你的 AI 應用架構該怎麼規劃？我們提供 AI 策略諮詢服務，協助你從需求分析到技術選型，找到最適合你團隊的 LLM 開發方案。

DSPy 常見問題解答

手動調 Prompt 的時代不會馬上結束，但寫 Prompt 的方式正在從「靠直覺」轉向「靠演算法」。DSPy 代表的是這個轉變的前沿——讓你用工程師的思維去處理 Prompt 優化，而不是用文學系的思維去琢磨措辭。

從一個簡單的 Signature 開始，跑一次 BootstrapFewShot，看看跟你手動調的 Prompt 比起來效果差多少。如果你跟大多數人的經驗一樣，你會發現 DSPy 不只是省時間——它找到的 Prompt 組合，是你手動嘗試很難碰到的。

如果你正在規劃企業級的 AI 應用、需要建構多模組的 LLM pipeline，聯繫我們的 AI 顧問團隊，我們可以幫你評估 DSPy 是否適合你的場景，並協助你從 POC 走到生產環境。