AI 刷题系统怎么验从确定性单测到评测集闸门修改 Prompt、检索策略或模型版本后不能只凭几道题的输出判断效果。刷题系统的模型输出具有随机性但输入编排、工具调用和代码执行这些环节可以建立明确的测试标准。一个可执行的做法是把评估分成单元、集成和端到端三层。1. 单元测试验证确定性逻辑单元测试不评估模型“答得好不好”而是检查模型周边的代码Prompt 变量是否完整注入结构化输出能否解析生成的代码能否通过语法检查。这里应使用固定夹具而不是依赖线上模型响应。func TestParseCodeBlock(t *testing.T) { got, err : ParseCodeBlock(go\npackage main\nfunc main() {}\n) if err ! nil { t.Fatal(err) } if got.Language ! go || got.Code { t.Fatalf(unexpected result: %v, got) } }对 Go 题解可用go/parser做语法检查Python 则可调用ast.parse。语法检查只说明代码可解析不能替代运行测试。2. 集成测试验证调用契约集成测试关注 RAG、工具调用和服务接口是否按约定协作。模型可以用 mock 响应替代重点检查题干进入检索器后是否带上题目 ID、语言和版本等过滤条件execute_code等工具的参数是否符合 JSON Schema超时、取消和工具错误是否会返回可诊断的错误而不是悄悄降级trace 中是否能关联一次请求内的检索、推理和执行步骤。检索质量不应写成脱离数据集的固定阈值。应先定义带人工标注的评测集再记录 RecallK、无结果率和错误召回样本。3. 端到端测试用评测集验证代码端到端测试将固定版本的题目、隐藏用例和模型配置一起保存。对每道题记录编译是否成功、是否通过用例、运行时间和资源限制命中情况。常见主指标是 Pass1第一次生成的解答通过全部测试用例的比例。运行未知代码时沙箱需要独立于业务进程并限制网络、文件系统、CPU、内存和运行时间。以下命令仅示意 Docker 的基础限制生产环境还需要镜像供应链、运行时隔离和审计机制。docker run --rm --networknone --read-only \ --memory128m --cpus0.5 --pids-limit64 \ -i sandbox-image4. 在 CI 中安排闸门层级建议触发时机主要产物单元测试每个提交解析、模板和 Schema 回归结果集成测试合并前工具契约、检索和错误路径结果端到端评估发布前或定时任务版本化评测集、Pass1 与失败样本具体样本量、超时和阻断阈值应根据语言、题库和成本设定并在报告中注明执行环境。模型升级时应把新旧版本放在相同数据集上比较而不是混用不同批次的结果。5. 三层测试各自定位什么分层测试不能消除模型的不确定性但能把问题定位到更小的范围是模板和解析器回归、工具链路失效还是模型在某类题目上的正确率下降。先保存评测集和配置再讨论“效果是否变好”结论才有可复核的依据。