模型、Prompt、检索器一起升级，效果变好到底是谁的功劳？

摘要：基于Arize Phoenix数据集与实验概念，说明模型、Prompt和检索器同时变化时如何控制变量并做回归。

Arize Phoenix官方文档把Dataset定义为可复用输入集合，把Experiment定义为在同一输入和评测标准下比较应用版本的结构化运行。这个设计解决了“每次拿不同样本试一下”的问题，但不会自动替团队完成因果归因。

假设RAG客服一次升级同时更换模型、Prompt和检索器，综合得分从0.72升到0.79。看起来进步了，但可能是新检索器提升了召回，而新Prompt让拒答率变差；也可能Judge版本变化造成分数漂移。把所有变化塞在一个实验里，结论只能是“组合不同”，不能说哪项有效。

用四格矩阵拆开组合变化

先固定模型，只比较旧/新Prompt与旧/新检索器四个组合；再对最佳组合比较模型。每个实验使用同一Dataset、相同Judge版本、相同重试策略和相同随机种子范围。

报告里要同时放均值和坏例

只放平均分会掩盖少量严重退化。建议同时记录：总体均值、各场景分位数、硬规则失败数、模型拒答、成本、延迟和具体坏例。若付款政策问答整体提升，但“已过有效期优惠券”样本开始给出错误承诺，就不能因均值上升直接发布。

实验结果可以用这张表验收：

最终把失败样本按“数据、检索、生成、评测器、环境”归因，进入下一轮候选集。测试团队不需要追求每次实验都证明一个宏大结论，只要保证同一批输入、同一套口径、单一可解释变化，就能让AI回归从“感觉更好”变成可审计决策。

先冻结数据集版本

实验期间如果一边运行一边修改样本，结果不可比较。数据集应包含sample_id、场景标签、输入、期望行为、来源、风险级别和标签版本。纠正错标时新建版本，并明确哪些历史结果需要重算。

黄金集也不能永久不变。线上新坏例进入候选区，由测试和业务共同审核后再升级；避免模型开发者只挑容易提升的样本，也避免把不可复现投诉直接当真值。

Judge需要自己的校准集

使用LLM-as-Judge时，先准备人工已判定的正反样本，比较Judge的一致性、漏判与偏差。修改Judge Prompt或更换模型，相当于更换测量仪器，历史分数不能直接横比。确定性业务规则应单独统计，不与主观得分平均成一个总分。

例如客服回答语气可由Judge评分，但是否承诺了不存在的退款政策，应由关键词、引用和规则共同判断。若硬失败发生，即使平均质量得分很高，也应阻断发布。

看交互效应，而不是只看单项赢家

四格实验里，新Prompt单独使用可能变差，新检索器单独使用可能提升，组合后却最好。这说明二者存在交互：新Prompt可能更依赖新检索器返回的元数据。报告要写清“组合在固定数据集上表现更好”，不能宣传成“Prompt单独提升”。

将实验接到发布门禁

即时CI跑小型高风险集，检查硬规则与主要场景；夜间跑完整数据集和多次重复；发布前比较候选与当前生产版本，要求高风险桶无退化、整体指标达到最小提升且成本不超预算。任何失败都能回到sample_id与Trace。

这套流程让实验不再是一张漂亮排行榜。每个结论都有数据版本、被测变量、评测器版本和坏例支撑，测试团队才能决定“值得发布”还是“只是换了一组组合”。

重复运行判断稳定性

生成式系统即使配置相同也可能波动。关键实验至少重复三次，报告均值、离散程度和硬失败次数。若候选平均分更高但波动更大，客服、支付等场景未必适合发布。对工具调用任务，还要比较路径一致性和副作用次数。

成本与质量一起做门禁

提升可能来自检索更多文档、使用更大模型或增加多轮Judge，质量上升同时让延迟和成本翻倍。实验表应并列任务成功、硬规则、P95延迟、Token、工具步数与费用。发布条件由业务给出可接受边界，不用单一总分替代取舍。

最后保存候选配置快照：模型、Prompt、检索参数、工具版本、数据集和评测器。没有配置快照的“最佳实验”无法复现，也不能成为CI基线。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。