一把 key 背后的黄金集回归套件：在用户发现前抓住某个后端的能力下滑

当你的应用依赖多个LLM后端时，模型提供方可能会在未通知的情况下更新模型，导致输出质量波动。对于聚合站用户，一个API key背后可能路由到多个模型，因此需要一种主动监控机制来确保每个后端都保持预期的能力水平。黄金集回归测试就是为此设计的：用一小组精心挑选的提示词和对应的参考答案，定期横扫所有后端，对比得分，从而在用户察觉之前发现某个后端的能力下滑。

为什么需要黄金集回归测试

模型更新是常态，但并非每次更新都是改进。有时特定任务的表现会下降，比如代码生成、逻辑推理或格式遵循。如果没有监控，这种下滑可能直到用户投诉才被发现。黄金集回归测试通过自动化定期检查，提供早期预警，让你能及时调整路由策略或联系服务方。

设计黄金集：小而精

黄金集不需要很大，但需要覆盖你的核心使用场景。建议包含10-30个提示词，每个提示词附带一个参考答案或评估标准。关键点：

• 代表性强：覆盖你实际业务中最常见的任务类型，如问答、摘要、翻译、代码补全等。
• 答案明确：对于客观任务，提供唯一正确答案；对于主观任务，提供评分标准（如关键词匹配、格式检查）。
• 难度分层：包含简单、中等和困难样本，以检测不同层次的能力变化。
• 稳定可复现：提示词和参考答案应固定不变，避免因测试集变动导致结果不可比。

执行测试：定期横扫后端

使用你的API key（聚合站支持一个key调用多个模型），编写脚本定期向每个后端发送黄金集中的提示词。注意：

• 相同参数：对每个后端使用相同的温度、最大token等参数，确保公平比较。
• 记录原始输出：保存每个后端的完整响应，便于后续分析。
• 定时运行：根据模型更新频率，可以每天或每周运行一次。

评分与对比

评分方式取决于任务类型：

• 精确匹配：对于有确定答案的任务，直接比较输出与参考答案。
• 模糊匹配：使用关键词覆盖率、Rouge等指标。
• LLM作为裁判：用另一个模型根据标准打分，但需注意裁判模型本身的稳定性。

将每个后端的得分与历史基线对比，如果某个后端的得分显著下降（例如超过阈值），则触发告警。

分析结果与行动

一旦发现异常，首先确认是否由随机性引起（可重复运行几次）。如果持续下降，则：

• 检查该后端是否对应模型版本更新。
• 考虑临时将流量切换到其他后端。
• 通过聚合站的支持渠道反馈问题。

集成到你的监控体系

黄金集回归测试应作为整体监控的一部分，与延迟、错误率等指标一起展示。你可以将结果输出到仪表盘，或设置自动告警。由于聚合站按官方价×1.3扣费，定期测试的成本可控，但建议控制测试频率和样本量以平衡开销。

通过这套方法，你可以在用户察觉之前发现后端能力下滑，保障应用稳定性。