好的评测改造,业务代码一行不用改

上期体检五问,第一问就是「被测入口」。今天砌这块砖,先给一个反直觉的判断:

好的评测改造,业务代码一行不用改。

评测要接进来,要动的不是业务,是业务和评测中间的那一层。这层缺位,评测就是业务代码身上的寄生者;这层立住,评测才是独立的资产。

直接调业务,是评测欠下的第一笔债

最直觉的接法:让评测脚本直接调业务内部接口,拼好参数发过去,拿到回答开始打分。跑通很快,但三种债当场签下,一种比一种疼。

债一:接口耦合。评测脚本把业务接口的入参签名抄进了自己的代码。业务哪天把「问题」字段改成「查询文本」,评测当场全崩——20 条用例一条都跑不起来,崩点还散落在每一处拼参数的地方,修完东墙补西墙。

债二:上线风险。有人反着图省事:评测不好接,那就在业务代码里埋评测埋点、加评测开关。评测逻辑混进生产链路,业务代码被迫跟着评测的节奏改——本该最稳的一块代码,被评测改造拖下了水。

债三:无法复用。评测脚本和被测对象长在一起,换个被测智能体,评测全部重写。你以为在攒评测资产,其实攒的是一批一次性脚本。

三笔债,同一个根因:评测直接碰了业务。解法是测试人最熟悉的老办法——加一层。

适配层:评测只认「问题进、回答出」

适配层,就是被测对象对评测暴露的唯一窗口。对评测来说,被测对象只该呈现一件事:问题进、回答出。至于密钥从哪来、会话怎么建、参数怎么拼、挂了怎么办,全部挡在这层里面,评测一个字都不用知道。

适配层的四个职责

本期核心。先上概念级伪代码,四个职责在代码里各占一行:

# 概念级伪代码:适配层对评测暴露的唯一入口
def ask(question: str) -> str:
    creds   = load_credential()          # 职责一 鉴权:密钥只在这层出现
    session = open_session(creds)        # 职责一 会话:登录态在这里建立
    raw     = call_business(session,
                build_params(question))  # 职责二 参数:业务入参在这层翻译
    if is_unavailable(raw):
        return ERROR_SIGNAL             # 职责三 兜底:返回约定的错误信号
    return normalize(raw)               # 职责四 规整:统一成评分器认识的形状

职责一,鉴权与会话。凭据获取、会话建立全在这层,评测脚本里永远不出现密钥。多说一句:密钥管理是 AI 工具链的头号泄漏面,评测链路也不例外——评测脚本会被复制、会被发群、会被整段贴进 AI 工具问「这段代码有什么问题」,密钥落进去一次,泄漏面就摊开了。

职责二,参数拼装与格式转换。业务入参和评测样本字段是两套语言,适配层做双向翻译。业务接口怎么变,只改这一层,用例集一个字不动——这是债一的解药。

职责三,异常与超时兜底。被测对象挂了,适配层要返回明确的错误信号,而不是让评测半路崩掉。基础设施错误和业务质量失败必须分得清:被测服务超时,是环境的错,不是智能体的差;混在一起,报表里就多出一条冤案。第(三)期讲报表纪律时立过这条规矩,适配层就是执行它的地方。

职责四,输出规整。被测对象的返回什么形态都有:纯文本、带标记的结构体、层层嵌套的报文。评分器不迁就被测对象,是适配层把所有输出统一成评分器认识的形状。

四条设计规则,可以直接抄走

规则②值得多说一句:适配层是评测证据的运输队,不是加工厂。它要是好心帮你去掉口头禅、补全标点,评分器看到的就不再是智能体的真实输出——你测的其实是适配层,不是被测对象。

规则④是这层真正的回报:用例集和评分器都长在「问题进、回答出」这个稳定契约上。换被测对象,换的只是适配层,评测资产原封不动搬过去——「换被测不改评测」,说的就是这一刻。

三个反模式,见到就拆

1.在评测脚本里现拼业务参数——债一当场签下;

2.在业务代码里埋评测埋点——债二当场签下;

3.在适配层里偷偷兜底重试——最隐蔽的一个:失败被静默重试掩盖,低分被悄悄抹掉,评测结果系统性失真。

第三个最容易和职责三混淆,一句话分清:兜底是让失败显式,重试是让失败消失。返回错误信号,报表能算清「这次没测成」;偷偷重试到成功,你拿到的就是被美化过的分数——和第(三)期讲过的「重跑变绿」一样,都是选择偏差。评测要的是真实分数,不是好看的分数。

两个高频疑问

问:业务接口设计得乱,适配层会不会越写越厚?会,但厚对了地方。入参拼装、鉴权握手这些脏活本来就得有人干,适配层把它们收拢到一处,总比散落在评测脚本每个角落强。真正要警惕的是往里塞业务判断逻辑——那是违规责②,适配层一参与判断,证据就不干净了。

问:先有评测,还是先有适配层?先有适配层,哪怕最初只是一个透传函数。入口不稳,后面灌多少用例都是沙上盖楼——这也是体检五问把被测入口排在第一问的原因。

诚实边界

照例说清楚:本篇给的是模式与设计规则,来自我们团队的改造原则和行业通行做法;文中失败场景是教学示例,数字为示意。我们自己的被测智能体正按这个模式改造中,真实的代码结构和踩坑实录,随「从零到一改造记」后续篇目带出。不装已完成,只记录进行中。

下期预告

入口这块砖砌好了,下一块是用例集工程——从测试用例到评测资产:老用例怎么翻译成样本、标准答案从哪来、业务规则怎么成文。改造记(六),见。

如果你觉得今天这篇有收获,欢迎点赞、在看、转发三连,我们下篇见。

往期推荐