5.5 可解释性与可信度

5.5 可解释性与可信度

本节摘要：编译产物要不要过工程评审、能不能上生产，取决于它能否自证清白。本节给出产物审计三步法——查示范池、查指令改写、查分数归因，配上"把编译产物讲给非技术干系人听"的沟通模板。可解释性不是框架的恩赐，而是一套可以按清单执行的检查动作。

打开编译产物的黑箱

"编译器自动写的提示词，我们看不看得懂？"这是引入 DSPy 的团队必被问到的质疑。回答分两半。技术上，产物全程可查：每个预测器携带的指令与示范都是明文数据，任何一次模型调用的完整提示词都可以用历史检查工具回放——DSPy 从来没有黑箱，只有没被打开过的箱子。工程上，"可查"不等于"可信"，可信需要一套固定的审计动作，让检查成为流程而非自觉。本节的三步法就是这套流程。

审计第一步：查示范池

示范是模型行为的最大影响因素，审计从这里开始。打开编译产物中每个预测器的示范集合，逐项检查四个属性：来源构成（自举示范与标注示范的比例，纯自举的产物要特别留意分布偏窄）、覆盖面（示范是否覆盖了任务的典型形态与边界形态，全是"顺利路径"的示范池是脆弱信号）、质量抽验（随机抽几条示范回放原始轨迹，确认答案对、过程也对——示范污染是 4.4 节讲过的隐蔽病灶）、体量与长度（示范条数与总长度直接影响运行成本，也影响模型注意力分配，超长示范池往往意味着参数没调好）。

审计示范池有一个实用的快速结论：示范池"像不像你的业务"。合格的示范池读起来应当像业务专家挑过的对话样例；如果读起来像随机拼凑，或者混着明显的坏例子，编译质量就值得怀疑，先回去查指标与数据，不要往下看指令。

审计第二步：查指令改写

用了指令搜索的编译器（COPRO、MIPROv2）会改写你的任务描述。审计要看三层：语义保真（改写后的指令是否还忠实于原任务边界——最典型的走样是把"简短作答"放大成"极简两词作答"，指标抓不到的语义漂移要在人工审读里抓住）、风格适配（针对目标模型的表述习惯是否合理——同一份指令在不同模型上的最优形态确实不同，这正是指令搜索的存在理由）、边界保留（异常处理、禁用项这些"负面契约"是否在改写中幸存——搜索天然倾向优化得分项，负面约束容易被稀释，发现稀释就把该约束挪到断言里去，别指望指令永远记得它）。

把三步检查落成习惯性动作：每次重新编译后，指令 diff 与上一版并排读一遍。指令是编译器最容易自作主张的地方，diff 审读是唯一能及时发现的手段。

审计第三步：查分数归因

分数好看只是起点，审计要回答"分数为什么好看"。归因检查的三个动作：分项得分（把验证集按问题类型、难度、来源切片，看分数分布是否均匀——总分掩盖下的局部塌陷是最常见的假阳性来源，比如总分八成五但某类问题只有五成）、消融对比（把示范池清空跑一遍、把指令还原成原始 docstring 跑一遍，两个消融分数与全量分数的差值，分别就是示范与指令的贡献——这个数字也是向管理层汇报"编译值多少钱"的最硬证据）、稳定性复跑（同配置三次编译的分数方差，方差大说明产物对自举运气敏感，参考 4.2 节的处理）。

三步审完，产出一份产物审计记录：示范池结论、指令 diff 结论、归因数字、以及"是否放行"的明确判断。这份记录在工程评审里就是编译产物的"出厂检验单"——传统软件发布看测试报告，编译程序发布看审计记录，流程对等，信任自然建立。

归因消融的代码骨架

消融对比不需要专门的工具，一个几十行的脚本就能完成：

import copy

def ablation_report(program, devset, metric):
    full = evaluate_score(program, devset, metric)          # 全量分数
    no_demos = strip_demos(copy.deepcopy(program))          # 清空示范池
    no_instr = restore_docstring(copy.deepcopy(program))    # 指令还原为原始描述
    return {
        "full": full,
        "without_demos": evaluate_score(no_demos, devset, metric),
        "without_instructions": evaluate_score(no_instr, devset, metric),
    }

def strip_demos(program):
    for predictor in program.predictors():
        predictor.demos = []          # 示范清空的贡献 = full 与此分数之差
    return program
​

脚本里的两个消融分别量化"示范值多少分"与"指令值多少分"，两个差值加上基线差距，就是编译贡献的完整分解。审计时把这三个数字写进报告——它们是编译产物"值多少钱"的最硬证据，也是向管理层解释预算去向时最有说服力的两行。

审计清单速查表

三步法落成可勾选的清单，每次编译后过一遍：

清单的价值在于把"审计"从依赖个人经验的临场发挥，变成新人也能执行的固定流程。七个项目全部通过，产物才有资格进发布评审——这套门槛与 6.5 节的发布门禁衔接，构成从编译到上线的完整信任链。

把产物讲给非技术干系人听

审计记录是给工程师看的，还有一类沟通对象是业务方与管理者。有效的讲法是三层递进：先讲机制的一句话版（"系统根据我们给的几十个标准案例，自动总结出了最有效的提问方式"）；再讲证据的三个数字（基线分、编译后分、消融差值——消融差值回答"这不是玄学吗"）；最后讲边界的诚实声明（"在证据缺失的问题上，系统会明确说无法回答，这是我们规定的"）。切忌拿总分单打独斗——单一数字在干系人眼里只会引发"那为什么还会错"的无限追问，分数加消融加边界声明的组合才能闭环对话。

可信度的一句话本质：让每个数字可复现、让每条示范有出处、让每次改写有 diff——三件事做完，黑箱焦虑自然消散。

本节要点回顾

• 可查即可信的前提：产物全程明文可回放，但从"可查"到"可信"需要固定流程，三步审计法就是流程化。
• 示范池四查：来源构成、覆盖面、质量抽验、体量长度；快速结论是"像不像你的业务"。
• 指令三层审：语义保真、风格适配、负面契约幸存率；每次编译后必做指令 diff 审读。
• 归因三动作：分项切片防局部塌陷、消融对比量化贡献、稳定性复跑测运气敏感度；审计记录是出厂检验单。
• 通向下一章：程序自证清白之后，就该走进真实业务了——第 6 章把全套体系落到问答、抽取、代码生成、内容创作与生产部署。