智能评测灰度发布时，先验证什么

智能评测灰度发布时先验证什么给刷题或代码评测系统接入 LLM 时灰度的目的不是证明新版本“效果更好”而是确认它出错时不会拖住评测主链路。模型输出不稳定、响应时间波动以及结构化结果不合规都应被当成正常失败路径处理。先定义可回退的边界新引擎应只负责可选能力例如提示、测试用例建议或题解草稿判题结果、积分和提交记录仍由确定性服务维护。上线前至少确认LLM 输出是否能通过 JSON Schema 或显式反序列化校验超时、限流、解析失败时是否返回明确的降级结果评测队列长度、超时率和降级率是否有独立监控新字段是否可选旧客户端能否忽略它。超时阈值、灰度比例和告警阈值应来自本系统的基线数据不适合照搬其他服务的数值。一个可取消的调用封装调用方需要把请求取消传到模型客户端并把不可信输出限制在边界内。下面的示例只返回可诊断的错误类别不记录用户源代码或完整模型回复。package evaluator import ( context encoding/json errors time ) var ErrInvalidModelOutput errors.New(invalid model output) type Hint struct { Text string json:text } type Client interface { Generate(context.Context, string) ([]byte, error) } func GenerateHint(ctx context.Context, client Client, prompt string) (Hint, error) { ctx, cancel : context.WithTimeout(ctx, 3*time.Second) defer cancel() raw, err : client.Generate(ctx, prompt) if err ! nil { return Hint{}, err } var hint Hint if err : json.Unmarshal(raw, hint); err ! nil || hint.Text { return Hint{}, ErrInvalidModelOutput } return hint, nil }建议的验证顺序先在回放或影子流量中比较结构和失败率再从小范围、可关闭的用户分组开始。灰度期间要抽样检查模型失败是否真的走了降级、队列是否继续消费、旧客户端是否能展示响应。出现异常时把流量开关设为零应足够恢复主路径自动回滚只是补充不能替代手工止损方案。