想象你是一家小餐馆的老板兼厨师。今天客人点一道“鱼香肉丝”，你凭着多年手感放盐、倒醋、调火候——今天咸了，明天淡了，味道全看心情。更麻烦的是，换一批食材（模型升级），或者客人换了口味（任务变化），你之前的“手感”全部作废，只能从头再试。这就是手动Prompt工程的真实写照：每个提示词都靠经验反复试错，脆弱、难维护、不可复现。 现在，想象一座现代化“中央厨房”。你不再需要亲手控制每一道工序，只需在需求单上写清楚“食材是什么、成品是什么、口味标准是什么”，后厨流水线自动拆解工序，试菜师团队按统一评分卡反复微调配方，最后固化成一张标准菜谱卡——任何分店照着做，出品都稳定如一。这套系统就是 DSPy：一个声明式的Prompt编程框架。它让你从“一句句手写和调优提示词”的泥潭里跳出来，转而声明任务、声明签名、声明评估标准，剩下的交给编译器自动完成。

岗位关联

职业价值：掌握DSPy，意味着你能把Prompt从“玄学手工艺”升级为“可评测、可复用、可自动优化的工程资产”——这正是资深Prompt工程师与初级调参者的分水岭。

目录
  1. 可视化演示
  2. 手动Prompt困境：凭手感做菜的小作坊
  3. 声明式核心理念：从“怎么做”到“要什么”
  4. Signature签名：写清楚食材与成品
  5. Module模块：可组装的厨房工位
  6. Optimizer优化器：不知疲倦的试菜师
  7. 编译器理念：把研发流程标准化
  8. DSPy实战对比：中央厨房 vs 街头小店
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示DSPy的声明式Signature定义、Module到Optimizer到Compiled编译管线和自动Prompt优化过程，通过模式切换理解编译器式Prompt工程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

声明式Signature定义 用Signature声明输入输出，无需手写Prompt Module封装可组合的预测逻辑 声明式编程替代手工Prompt调优

手动Prompt困境：凭手感做菜的小作坊

想象你经营一家街边小餐馆，菜单上只有五道菜，但每天客人点法千变万化：“少放盐”“多点辣”“不要香菜”。你只能凭手感临场发挥，今天咸明天淡。更扎心的是，换了供应商的酱油（模型升级），之前“刚刚好”的用量全得重新试。手动Prompt工程就是这种状态：开发者不断调整提示词措辞，加几个例子、换种语气、改一下输出格式，完全依赖个人经验和运气，今天能跑通的Prompt明天换个模型就“翻车”。

为什么手动调Prompt这么痛苦？因为它会遭遇组合爆炸。一个Prompt往往包含多个可调维度：指令措辞、少样本示例、输出格式、温度参数、角色设定、模型版本……每个维度都有若干候选取值，全部组合起来是一个天文数字。

小作坊老板靠舌头试菜，一次最多试两三遍。当菜品（任务）和顾客要求（需求）组合爆炸式增长时，手工菜单根本维护不过来——这正是DSPy登场的理由。

N=∏i=1kCiN = \prod_{i=1}^{k} C_i
组合数公式：一个任务是手动调优的试错空间大小，维度越多、候选越多，越不可能靠人穷举。
  1. 维度数量 $k$这是Prompt中可以独立调整的设计因素个数，比如措辞、示例、格式、温度等，维度越多组合空间越大。
    k=可调维度总数k = \text{可调维度总数}
  2. 候选数量 $C_i$第 $i$ 个维度上可取值的个数，比如“措辞”有5种写法，“示例”有3组可选。
    Ci=第 i 维的候选取值数C_i = \text{第 } i \text{ 维的候选取值数}
  3. 连乘运算把所有维度的候选数相乘，得到所有可能Prompt的总组合数。
    N=C1×C2×⋯×CkN = C_1 \times C_2 \times \cdots \times C_k
  4. 组合爆炸只要6个维度、每个维度5种选择，就有 $5^6 = 15625$ 种组合，靠人试错完全不现实。

声明式核心理念：从“怎么做”到“要什么”

中央厨房来了位新大厨。他不像小老板那样口述“先热锅、再放油、下葱姜蒜……”，而是直接在需求单上写：“做一道鱼香肉丝，主料里脊，辅料青椒木耳，口味酸甜微辣。”至于油温几成、炝锅顺序，交给后厨的专业系统自动决定。这就叫声明式：你告诉系统“要什么”，而不是“每一步怎么做”。

与之相对的命令式编程，就像手写Prompt时逐字逐句告诉模型“你要扮演一个专家、先思考再回答、使用Markdown格式……”——事无巨细都由人指定。DSPy的核心理念是把这种“命令式”变成“声明式”：开发者只需要声明三样东西——任务用什么签名、用什么模块组装流水线、用什么指标验收质量，剩下的细节由框架自动生成和优化。

你定方向和验收标准，系统负责干活——这是DSPy与手动Prompt工程最本质的分水岭。从此，Prompt调优不再是玄学，而是一条可自动化的流水线。

Program=compile(Signature,Module,Metric,D)\text{Program} = \text{compile}(\text{Signature}, \text{Module}, \text{Metric}, \mathcal{D})
编译公式：DSPy把“签名、模块、评估指标、训练数据”四样输入交给compile函数，产出优化好的完整程序。
  1. Signature（签名）描述“输入是什么、输出是什么”，相当于需求单上的食材与成品。
    Signature=(输入字段→输出字段)\text{Signature} = (\text{输入字段} \to \text{输出字段})
  2. Module（模块）可复用的流水线组件，如“单步预测”“思维链”，相当于后厨的标准化工位。
    Module=可组合的Prompt组件\text{Module} = \text{可组合的Prompt组件}
  3. Metric（评估指标）判断输出好坏的评分标准，相当于顾客满意度调查表。
    Metric=质量评分函数\text{Metric} = \text{质量评分函数}
  4. 数据 $\mathcal{D}$用于优化的小规模验证集，相当于试菜时用的“标准口味样本”。
    D={(输入,期望输出)}\mathcal{D} = \{(\text{输入}, \text{期望输出})\}
  5. compile（编译动作）DSPy编译器把上面四样东西组合起来，自动跑完“采样→评分→优化”的闭环流程。
    compile:四要素→优化后的可执行程序\text{compile}: \text{四要素} \to \text{优化后的可执行程序}

Signature签名：写清楚食材与成品

火锅店的菜单条目写着“鸳鸯锅底+肥牛+黄喉”，后厨一看就明白要准备什么。DSPy里的Signature（签名）就是这样的需求单：声明LLM任务的输入和输出分别是什么。在DSPy中，一句最简单的签名长这样："question -> answer"——左边是输入字段，右边是输出字段。

但光有字段名还不够，你还可以用描述把需求写得更清楚，让优化器少走弯路。比如：

这与“任务即转换”的思想一脉相承：任何LLM任务本质都是“从某种输入转换到某种输出”——文本分类是“文章→类别”，摘要是“长文→短文”，翻译是“中文→英文”。签名越明确，优化器的探索空间就越小、收敛越快。

一份清晰的需求单，是试菜师（优化器）发挥水平的前提。签名的价值就在于：它让模型知道“你要我做什么”，让优化器知道“该朝哪个方向调整”。

f:(x:question)→(y:answer)f: (x: \text{question}) \to (y: \text{answer})
签名公式：一个转换函数，从“问题”字段映射到“答案”字段。
  1. 转换函数 $f$代表整个LLM调用过程，输入经过模型处理得到输出。
    f=LLM完成任务的过程f = \text{LLM完成任务的过程}
  2. 输入字段 $x\text{question}$：声明输入是“问题”类型，并附带自然语言描述，告诉模型这是什么。
    x=输入，类型为questionx = \text{输入，类型为question}
  3. 输出字段 $y\text{answer}$：声明输出是“答案”类型，约束模型往这个方向生成。
    y=输出，类型为answery = \text{输出，类型为answer}
  4. 箭头 $\to$表示“映射”或“转换”，是签名中的核心关系。
    question↦answer\text{question} \mapsto \text{answer}
python3 行
class QA(dspy.Signature):    question = dspy.InputField(desc="用户提出的问题")    answer = dspy.OutputField(desc="简洁准确的回答")

Module模块：可组装的厨房工位

现代后厨不是一人包办，而是切配台、灶台、烤箱各司其职，任意组合就能做出不同套餐。DSPy的Module（模块）就是这样的标准工位。最基础的模块是 dspy.Predict，它接收一个签名，完成一次“输入→输出”的预测；dspy.ChainOfThought 则在预测前先让模型“想一想”，输出推理过程再给最终答案——相当于“边做边尝”的高级工位。

模块最大的魅力在于可组合、可复用。你可以继承 dspy.Module，在 forward 方法里串联多个子模块，搭建出复杂的处理流水线。比如一个“检索增强问答”模块，内部可能是：先用 Retrieve 模块查出相关资料，再用 ChainOfThought 模块基于资料生成答案。每个工位独立调优、独立替换，换菜单（改任务）只需重新排列组合，不用整个厨房重装。

标准化工位让厨房的扩张变得容易：今天做川菜，明天做粤菜，工位不变，换组合就行。这就是模块化带来的工程红利。

y=Mn∘Mn−1∘⋯∘M1(x)y = M_n \circ M_{n-1} \circ \cdots \circ M_1(x)
组合公式：数据依次流过 $M_1$ 到 $M_n$ 这 $n$ 个模块，最终得到输出 $y$。
  1. 模块 $M_i$一个标准化处理单元，如Predict、ChainOfThought或自定义组件。
    Mi=第 i 个模块M_i = \text{第 } i \text{ 个模块}
  2. 输入 $x$进入流水线的原始数据，比如用户问题、待处理文档。
    x=流水线输入x = \text{流水线输入}
  3. 复合运算 $\circ$表示“先执行右边、再执行左边”的串联组合。
    (M2∘M1)(x)=M2(M1(x))(M_2 \circ M_1)(x) = M_2(M_1(x))
  4. 执行顺序从 $M_1$ 开始依次执行到 $M_n$，前一个模块的输出是后一个模块的输入。
    x→M1(x)→M2(M1(x))→⋯→yx \to M_1(x) \to M_2(M_1(x)) \to \cdots \to y

Optimizer优化器：不知疲倦的试菜师

中央厨房养着一支专业试菜师团队。每当后厨端出一版候选菜，他们就按照统一评分卡（色泽、口感、出餐速度）打分，然后反馈给后厨调整配方，再试下一版。DSPy的Optimizer（优化器）就是这支试菜师团队——但它比人类强得多：不知疲倦、有记录、可复现。

优化器的工作分为几个方向：一是提示词优化，自动改写Prompt的指令措辞，找到表达更清晰的描述；二是少样本示例优化，它不会简单随机挑几个训练样本塞进Prompt，而是通过“轨迹自举”的方式，让模型先跑出高质量的中间推理和答案，再用这些真实轨迹构造Few-shot示例；三是参数微调，直接对小型语言模型的权重做精细调整。优化器的一切动作都围绕同一个目标：让评分指标最大化。

人试三遍就腻了，试菜师团队可以一晚试几百遍，每一遍都有记录、有对比。优化器不靠运气靠数据，这正是DSPy能稳定超越手调的核心原因。

θ∗=arg⁡max⁡θ1N∑i=1NMetric(Mθ(xi),yi)\theta^{*} = \arg\max_{\theta} \frac{1}{N} \sum_{i=1}^{N} \text{Metric}(M_{\theta}(x_i), y_i)
优化目标公式：在训练集上找到使平均评分最高的参数 $\theta$。
  1. 参数 $\theta$既包括Prompt的措辞、示例，也包括可微调模型的权重，是优化器调整的对象。
    θ=可调整的Prompt与模型参数\theta = \text{可调整的Prompt与模型参数}
  2. 模型 $M_{\theta}(x_i)$使用当前参数 $\theta$ 的模块对第 $i$ 个输入 $x_i$ 的预测输出。
    Mθ(xi)=用当前参数得到的预测M_{\theta}(x_i) = \text{用当前参数得到的预测}
  3. 评分函数 $\text{Metric}$评估预测与期望答案 $y_i$ 接近程度的函数。
    Metric(y^i,yi)=预测与期望的匹配度\text{Metric}(\hat{y}_i, y_i) = \text{预测与期望的匹配度}
  4. 平均 $\frac{1}{N}\sum_{i=1}^{N}$在所有 $N$ 个验证样本上求评分的平均值，用来衡量总体效果。
    Sˉ=S1+S2+⋯+SNN\bar{S} = \frac{S_1 + S_2 + \cdots + S_N}{N}
  5. $\arg\max$枚举候选参数，找到使平均评分达到最大值的那个参数组合。
    θ∗=评分最高时对应的参数\theta^{*} = \text{评分最高时对应的参数}

编译器理念：把研发流程标准化

新菜研发出来还不是终点。中央厨房会把最佳配方写成标准菜谱卡——精确到克数、火候、时间，发给所有分店照做。DSPy的编译器（Compiler）就是干这件事的：它把签名、模块、优化器、评估指标和训练数据一起“编译”，自动跑完整个优化流程，最后产出一份可直接部署的“菜谱”——包含优化后的Prompt、自举好的Few-shot示例、调整好的参数。

编译过程不是一蹴而就的，而是一个反复迭代的闭环。首先在训练集上采样推理轨迹（让模型跑几遍，收集中间结果和输出）；然后按评估指标评分，找出表现好的轨迹作为榜样；接着利用这些榜样优化Prompt和示例，生成下一版候选程序；再回到第一步继续迭代，直到评分收敛。整个流程像极了新品研发：试菜→调整→再试菜→再调整，直到稳定达标。

有了标准菜谱卡，“分店”（生产环境）不需要再带试菜师，照着卡做就行。编译器的价值不在于多跑几次实验，而在于把整个优化过程沉淀为可复用的工程资产。

Pt+1=Refine(Pt,Tt,Metric)P_{t+1} = \text{Refine}(P_t, \mathcal{T}_t, \text{Metric})
迭代公式：第 $t+1$ 版程序由第 $t$ 版程序、采样轨迹和评分指标共同优化得出。
  1. 当前版本 $P_t$第 $t$ 轮迭代后的程序，包含当前版本的Prompt和模块配置。
    Pt=第 t 轮的程序版本P_t = \text{第 } t \text{ 轮的程序版本}
  2. 轨迹集合 $\mathcal{T}_t$当前版本在训练数据上采样得到的所有推理轨迹。
    Tt={模型运行的输入-中间-输出记录}\mathcal{T}_t = \{\text{模型运行的输入-中间-输出记录}\}
  3. Refine（优化动作）从轨迹中挖掘优秀示范，结合评分反馈，调整Prompt、扩充示例。
    Refine=基于轨迹与评分改进程序\text{Refine} = \text{基于轨迹与评分改进程序}
  4. 更新与收敛把 $P_{t+1}$ 作为新一轮的起点，重复“采样→评分→优化”，评分不再上升时即可停止。
    P0→P1→⋯→P∗P_0 \to P_1 \to \cdots \to P^{*}

DSPy实战对比：中央厨房 vs 街头小店

中央厨房前期投入大——要写需求单、配评分卡、跑编译流程；但一旦建成，从一道菜扩展到一百道菜的成本极低。街头小店起步快——打开锅就炒，但每换一道菜都要重新摸索，规模一大必然崩溃。手动Prompt与DSPy的对比，正是这两种模式的对决。

在效率与稳定性上，DSPy通常显著优于手动调参。手动调一个复杂Prompt可能需要几天，改一次模型又得重来；DSPy自动跑几百轮实验，结果可复现、可迁移到新模型。但DSPy并非万能：它适合多模块组合的复杂任务、有可量化评估指标的场景（如精确匹配、F1分数、人工评分），以及需要长期迭代维护的LLM应用；如果只是一次性跑通的小demo，手动写Prompt反而更轻快。

如果你的LLM应用已经“做菜”做到手忙脚乱——频繁换模型、多个模块串联、指标难达标——是时候把后厨升级成中央厨房了。从一个小而关键的场景切入，定好签名和验收指标，让DSPy替你跑完剩下的路。

Δ=ScoreDSPy−ScoreManual\Delta = \text{Score}_{\text{DSPy}} - \text{Score}_{\text{Manual}}
收益公式：DSPy优化后的评分减去手动调参后的评分，衡量自动化带来的提升。
  1. 手动调参得分 $\text{Score}_{\text{Manual}}$靠经验手调Prompt后在验证集上达到的评分。
    ScoreManual=手工Prompt的验证分数\text{Score}_{\text{Manual}} = \text{手工Prompt的验证分数}
  2. 自动优化得分 $\text{Score}_{\text{DSPy}}$DSPy编译完成后在相同验证集上的评分。
    ScoreDSPy=编译后程序的验证分数\text{Score}_{\text{DSPy}} = \text{编译后程序的验证分数}
  3. 差值 $\Delta$两者之差，$\Delta > 0$ 说明DSPy更优。
    Δ>0⇒DSPy胜出\Delta > 0 \Rightarrow \text{DSPy胜出}
  4. 实践意义实际项目中差值往往来自Few-shot示例的质量和Prompt措辞的精细度。
    Δ≈Few-shot质量提升+措辞优化收益\Delta \approx \text{Few-shot质量提升} + \text{措辞优化收益}

AI 应用场景

智能客服意图识别与槽位提取

阶段：Prompt优化与模块化编排

解决的问题：传统客服机器人需要为十几类意图各写一套Prompt，话术稍微调整或模型升级，意图识别准确率就明显下滑，维护成本极高。DSPy让开发者只需声明“从用户输入提取意图和槽位”，优化器自动在验证集上调优Prompt和Few-shot示例，准确率稳定且易维护。

具体案例：某电商平台的售后客服接入DSPy后，将“退货、换货、退款、物流”四类意图识别封装成统一的 IntentExtraction 签名，配合同一批验证数据自动优化。上线两周内，槽位提取F1值从0.78提升至0.91，且将模型从GPT-4切换到GPT-3.5时，只需重新编译，无需人工重写Prompt。

企业知识库RAG问答系统

阶段：多模块组合与编译器迭代

解决的问题：RAG系统的痛点在于“检索是否精准、回答是否忠实于文档”，这两步的Prompt相互影响，手动调参很难同时兼顾。DSPy把“生成检索查询”和“基于文档生成回答”拆成两个模块，用优化器自动调整两者的Prompt，让整体答案质量最优。

具体案例：某律所的知识库问答系统使用 dspy.ChainOfThought + dspy.Retrieve 组合，输入律师的咨询问题，输出带法条引用的回答。DSPy编译后，答案引用准确率从64%提升到87%，并且每天新增判例后只需重新编译即可适应新知识。

金融研报结构化摘要

阶段：少样本示例自动构建

解决的问题：金融摘要对格式和术语要求严苛，手写Few-shot示例既费时又难覆盖多样化的报告风格。DSPy的优化器能通过轨迹自举，自动从已验证的高质量样本中构建Few-shot示例，并同步优化摘要指令。

具体案例：某证券公司用DSPy把晨会纪要转成“市场概览、板块表现、风险提示”三段式摘要。编译后生成的摘要格式合规率达到96%，原来需要一名运营每天花2小时清洗Prompt，现在只需每周检查一次评估指标。

Python 演示

python46 行
"""简化版DSPy：自动挑选并优化Prompt模板的核心思想演示"""import random def simulate_llm_score(template, sample):    """模拟LLM在特定模板下的回答质量，真实场景由大模型生成后用指标评分"""    if "准确" in template:        return 0.9    if "详细" in template:        return 0.7    return 0.4 def evaluate(template, dataset):    """在验证集上计算该模板的平均得分"""    total = 0.0    for sample in dataset:        total += simulate_llm_score(template, sample)    return total / len(dataset) class PromptOptimizer:    """优化器：多轮试菜，保留得分最高的模板"""     def __init__(self, templates):        self.templates = templates        self.best_template = None        self.best_score = -1.0        self.history = []     def compile(self, dataset, rounds=8):        """模拟DSPy编译：随机尝试模板，按评估分数保留最优"""        for i in range(rounds):            candidate = random.choice(self.templates)            score = evaluate(candidate, dataset)            self.history.append((i, score, candidate))            if score > self.best_score:                self.best_score = score                self.best_template = candidate        return self.best_template if __name__ == "__main__":    dataset = [{"q": "什么是DSPy", "a": "声明式Prompt框架"}]    pool = ["请回答", "请准确回答", "请详细说明"]    opt = PromptOptimizer(pool)    best = opt.compile(dataset, rounds=10)    print("最优Prompt:", best)    print("最高得分:", opt.best_score)    print("优化轨迹:", opt.history)
目的：用几十行代码还原DSPy优化器的核心逻辑——从候选Prompt池中自动挑选最优模板，演示“声明式优化”的最小闭环。
  1. simulate_llm_score(template, sample)模拟LLM在不同提示词下的输出质量，真实场景替换为“调用大模型 + 评估指标打分”
  2. evaluate(template, dataset)对一个候选模板计算其在验证集上的平均分，相当于试菜师按统一标准品尝
  3. class PromptOptimizer实现优化器的主体，内部维护最佳模板 best_template 和最佳分数 best_score
  4. compile(dataset, rounds=8)核心编译方法，多轮随机尝试候选模板，逐轮记录并保留最高分
  5. random.choice(self.templates)每轮从模板池中随机选一个候选，模拟优化器的探索动作
  6. if score > self.best_score贪心更新逻辑：只保留表现更优的模板，最终收敛到局部最优
  7. self.history.append((i, score, candidate))记录优化轨迹，方便回溯与调试，对应DSPy的训练日志

常见误区

误区听名字带个"Py"，又在LLM圈子里火起来，以为DSPy是OpenAI或某大厂新发布的模型，能直接替代GPT-4。

正解DSPy不是模型，而是一套“管理系统”。它就像中央厨房的菜品研发系统，本身不产食材，只负责把食材加工成标准菜谱。它仍然调用GPT、Claude等底层LLM，只是把“怎么写好Prompt”这件事从人手里接了过来。

为何常见：很多新工具名字都带“Py“，加上官方宣传强调”编程框架“，容易让人类比”PyTorch是个深度学习框架→框架里可能有模型”，从而误以为它本身是模型。

误区既然宣传语说“自动优化Prompt”，那我的需求单也不必写了，DSPy能读懂我的心。

正解DSPy优化的是“提示词的措辞和示例”，而不是“任务本身”。你仍然需要定义签名——用 dspy.InputField 和 dspy.OutputField 描述输入输出，还要设计评估指标。就像中央厨房的大厨仍要写菜单需求单，只是不用亲自站在灶台前一遍遍尝咸淡了。DSPy是“自动调Prompt”，不是“免Prompt”。

为何常见：“自动优化”四个字容易被放大成“全自动”，忽视了声明式中“描述任务”这个必要动作；加上网络教程常把“不手写提示词”作为吸引力，进一步强化了误解。

误区自动搜索听起来像随机试错，跟人凭经验手调没什么区别，说不定手调还更可控。

正解DSPy的优化是“数据驱动”的闭环：采样轨迹→评分→反馈→迭代，每一步都有量化记录，且能利用自举生成的Few-shot示例。它在一晚上尝试的实验数量是人工无法企及的，而且结果可复现——同一个训练集和种子，任何人都能复现出同一份菜谱。这就像盲品测试：人觉得“差不多”，盲测数据却会有稳定差异。

为何常见：人们习惯了“调Prompt靠手感”，低估了系统化搜索+反馈闭环的威力；再加上手动调参见效的直接体感，容易把自动优化想象成盲目穷举。

误区听说DSPy把Prompt自动化了，觉得这是给不会写Prompt的新手准备的玩具，资深开发者手动调更精细。

正解恰恰相反，DSPy的价值在复杂场景下才充分释放。多模块组合、跨模型迁移、频繁迭代的LLM应用，正是资深工程师也会头疼的维护难题。DSPy并不是替代理性判断和业务知识——定义评估指标、设计模块结构、解读评分报告，都需要资深经验。它提供的是“放大器”：让专家的经验变成可重复的自动化流程。

为何常见：把“声明式”和“自动化”误读为“傻瓜式”，忽略了声明式背后对问题建模能力的要求；新手友好不等于只适合新手，就像PPT模板小白能用，但高手用它产出的是另一层级的作品。

面试题

Q1. DSPy属于哪种编程范式？

单选题 · easy

  • A.面向对象编程
  • B.声明式编程← 正确答案
  • C.函数式编程
  • D.命令式编程

答案：B。DSPy的核心是“声明要什么，而不是怎么一步步做”——开发者描述任务、签名和评估指标，框架自动生成Prompt细节。这就好比要求菜品的顾客，而不是报菜谱的厨师。面向对象和函数式是代码组织方式，命令式则强调逐步命令，都与DSPy的声明式理念不同。

Q2. 在DSPy中，Signature（签名）的主要作用是什么？

单选题 · easy

  • A.加密API请求数据
  • B.定义输入输出规范← 正确答案
  • C.管理用户权限系统
  • D.自动生成训练数据

答案：B。签名描述LLM任务的输入字段和输出字段，相当于餐厅需求单上写清“食材是什么、成品是什么”。加密和权限属于安全范畴，生成训练数据不是签名的职责——签名只是申明任务边界，数据仍需自己准备。

Q3. 在DSPy中，以下哪个是用于实现思维链推理的模块？

单选题 · mid

  • A.处理单步预测
  • B.处理思维链推理← 正确答案
  • C.处理循环控制
  • D.处理文档检索

答案：B。dspy.ChainOfThought 模块让模型先输出推理过程再给出最终答案，对应“处理思维链推理”；Predict 是单步预测，Retrieve 负责检索文档，DSPy中不存在“循环控制”这样的标准模块。这就像后厨工位各有专长，思维链工位专门负责“边想边做”。

Q4. 关于DSPy优化器（Optimizer），以下哪些说法正确？

多选题 · mid

  • A.自动生成少样本示例← 正确答案
  • B.只能微调预训练大模型
  • C.自动优化提示词指令← 正确答案
  • D.需要手工撰写提示词

答案：AC。DSPy优化器两大核心能力正是“自动构建Few-shot示例”和“优化提示词措辞”。它不只做参数微调，也不是所有优化都在大模型上做，B以偏概全。D与优化器的“自动”本质相悖，若需要手工撰写提示词，就回到了手动Prompt工程的老路。

Q5. DSPy与手动Prompt工程相比，最大优势是什么？

单选题 · mid

  • A.完全不需要写提示词
  • B.系统化自动优化提示词← 正确答案
  • C.支持更多种编程语言
  • D.不需要标注训练数据

答案：B。DSPy的核心优势是把Prompt调优从“凭经验试错”变成“可量化的自动优化循环”——采样、评分、反馈、迭代。它仍然需要定义签名的描述和评估指标，A的说法过于绝对；语言支持和数据需求也不是它的核心卖点。

Q6. 关于DSPy编译流程，下列哪些说法正确？

多选题 · hard

  • A.先采样推理轨迹← 正确答案
  • B.根据指标评分反馈← 正确答案
  • C.迭代优化提示词← 正确答案
  • D.每步需要人工干预

答案：ABC。DSPy编译器的工作闭环是：采样模型推理轨迹→按评估指标评分→基于反馈优化Prompt→生成新版程序→再采样迭代。整个过程全自动，不需要每一步都人工介入，D恰恰是DSPy要解决的问题。人只需在编译前定义好签名、指标和数据。

Q7. 类比“餐厅后厨”，DSPy中的Optimizer对应什么角色？

单选题 · easy

  • A.采购员
  • B.试菜师← 正确答案
  • C.洗碗工
  • D.收银员

答案：B。优化器的工作是反复品尝候选输出、按评分卡打分、反馈给厨房调整配方，正是“试菜师”的职责。采购员负责找食材（对应数据准备），洗碗工是后勤，收银员面对顾客，都与优化器的核心职能不匹配。

Q8. 在DSPy中，声明式编程意味着开发者主要做什么？

单选题 · mid

  • A.描述任务和评估标准← 正确答案
  • B.编写每一步具体提示词
  • C.手动调整温度参数值
  • D.设计模型网络结构

答案：A。声明式的精髓是“描述做什么、验收标准是什么”，而不是“一步步怎么做”。因此开发者定义签名、选模块、定指标就够了；具体Prompt措辞、Few-shot示例交给编译器。B是命令式做法，C属于细节调参，D是模型层的职责，都不是DSPy中开发者的主要工作。

Q9. DSPy适应用的场景有哪些？

多选题 · hard

  • A.多模块组合的复杂任务← 正确答案
  • B.有可量化评估指标的任务← 正确答案
  • C.需要快速稳定复用的LLM应用← 正确答案
  • D.单次跑完即弃的一次性任务

答案：ABC。DSPy的编译优化需要评估指标来驱动反馈，需要模块化来发挥组合优势，需要长期复用来摊薄前期成本。而一次性小demo用DSPy等于“为了一个菜建中央厨房”，手动写Prompt反而更轻快，因此D不适用。

Q10. DSPy通过什么方式来构建少样本示例？

单选题 · mid

  • A.从训练数据中随机抽取
  • B.轨迹引导的自举生成方式← 正确答案
  • C.用户手工编写固定模板
  • D.直接调用外部数据接口

答案：B。DSPy的优化器会先让当前Prompt在训练数据上采样推理轨迹，从高分轨迹中挑选中间过程和结果，构造高质量Few-shot示例——这叫“轨迹自举”。随机抽取的示例质量无法保证，DSPy的设计目标就是避免手工编写模板，而调用外部接口与构建示例无关。