19｜CI/CD 里怎么集成大模型评测？

开场先讲触发设计：prompt、模型版本、检索配置、依赖代码，任何一项变更都触发评测——触发点挂在这些资产的变更事件上，不是挂日历上。这点说清楚，工程味就出来了。

回答思路

第一步：流水线分三层

层级	跑什么	作用
提交级	核心集（几十条）分钟级冒烟	给开发者快速反馈
门禁级	P0 场景全过 + 指标阈值判定	不过不让合并
夜间级	全量集 + 趋势对比	盯慢性漂移

第二步：非确定性的工程处理——本题最硬核的部分

• 同样输入多次采样（3 到 5 次）取均值或多数投票
• 阈值设容差区间：比如通过率 92% 到 100% 都算过——防随机抖动导致流水线误报阻塞发布
• judge 类评测本身有波动，同样多跑取稳

能主动讲「防抖动」，说明你真搭过评测流水线、被误报折磨过。

第三步：讲结果资产

每次评测结果落库，指标按版本画趋势线——质量回退和慢性漂移早发现，评测数据本身也是资产。

收尾

目标是让评测像单测一样自动、像门禁一样有牙齿——否则评测集建得再好也只是手工跑表。

考察重点

维度	说明
企业动机	评测不进流水线就不可持续。评测工程化是测试开发在 AI 时代的核心增值点，企业招的就是这个
过线标准	分层流水线 + 非确定性处理（采样、容差）
区分度	讲得出「容差区间防抖动」的是真踩过评测流水线误报的坑；只会说「接到 Jenkins 上」的是没做过大模型评测——传统 CI 经验直接平移不了
加分项	指标趋势落库、慢性漂移监控这类运营视角

来源

整理自知识星球帖《面试情报 01｜大模型测试 20 题》，返回题库。