人工智能 评测能力迁移的渐进迁移方案

给存量评测系统加入 LLM 能力时，迁移的风险不只在调用是否成功，还包括响应契约、队列负载和计费行为是否变化。迁移计划应把旧流程当作可回退的基线，而不是一次性替换目标。

先做兼容与影子验证

新服务先接收采样后的复制请求，不向用户返回结果。比较时应检查字段类型、状态含义、超时和错误分类；题解文本可以不同，但判题结论和权限边界不能无解释地变化。涉及用户代码时，比对日志必须脱敏并限制保存期限。

灰度要可停止

以稳定的用户或租户键分桶，逐步扩大范围。流量开关、超时、队列上限和降级策略应独立配置。出现解析失败、队列积压或成本异常时，先关闭可选能力，主评测路径继续工作。

func chooseNew(userID string, percent int) bool {
    if percent <= 0 { return false }
    if percent >= 100 { return true }
    return int(fnv32(userID)%100) < percent
}

发布前演练关闭开关和恢复旧版本，并记录实际耗时。是否扩大灰度，应依据本系统的差异率、尾部延迟和资源预算决定，而不是预设一个通用百分比。

继续把问题说具体

围绕评测能力迁移的渐进迁移方案，最需要避免的是把一个结果当成全部证据。题解、评测或代码审查都有自己的输入分布：容易的样本、边界样本和错误输入给出的信号并不相同。先做兼容与影子验证、灰度要可停止已经说明了主要做法，补充部分应该把“什么算通过”说得更细，而不是把一次高分或一次构建成功写成质量结论。

实际判断可以从反例开始。对题解就看是否漏掉条件和复杂度，对缓存和算法就看失效、负权或状态转移是否被覆盖，对合并改动则看冲突解决后语义有没有悄悄改变。每次只引入一个能解释的问题，比堆一长串抽象术语更适合读者复现和讨论。

测试名称和断言最好描述行为，而不是描述实现。比如写清“重复请求不会生成两份记录”或“负权输入被明确拒绝”，比断言某个内部变量更耐改。发现失败时，把输入、预期和实际结果放在一起；尚未确认的原因就标注为待查，不要用推测替代结论。

这样积累下来的样例既能防回归，也能反过来约束功能范围。需求变了就新增样例或调整判定规则，旧样例仍保留其背景，文章的判断链条才不会随着一次改版断掉。

容易漏掉的细节

影子阶段最好保留两套结果的可追溯关联，而不是只记一条“新旧不一致”。同一份提交在旧评测器和新能力中分别得到什么结论、哪一步发生了超时或降级，都应能被回看。这样灰度遇到争议时，讨论的是一条具体判定，而不是抽象地争论模型是否可靠。

对用户可见的反馈也要克制。新能力给出的解释可以作为辅助信息，但不要改变主评测的判定口径，更不能在旧结果尚未确认时把推测当成最终答案。把这层区分写进接口字段和页面文案，迁移才不会把技术试验变成用户体验上的摇摆。

保持切换可解释

当新旧结果不一致时，先按结果类型分组，再决定是否扩大灰度。不能解释的差异继续留在影子阶段，避免把排查压力转给正在使用系统的人。