无标注AI测试的三种解法：大模型判官、合成数据与一致性自检

年初的时候，我接手了一个挺尴尬的活儿：团队新上了一个AI审核功能，产品经理拿着需求文档跟我说"测一下效果"，我问她要标注测试集，她反问了一句："标注不是你们测试自己想办法的吗？"那一刻我就知道，这又是一个"没有数据标注，AI测试怎么跑"的经典困局。

当时项目连一条人工标注的样本都没有，模型又必须按期上线。硬着头皮把所有能试的无标注测试方案都试了一遍之后，我发现这事在2026年确实有解法了，而且不止一种。这篇文章就把我这一年多在实际项目里验证过的三条核心路线、具体配置和踩过的坑整理出来，给正在被同类问题卡住的人一个参考。

1. 先拆究竟：没有标注，传统AI测试到底断在哪一环

想解决问题，得先搞清楚传统AI测试的哪些动作是离不开标注的。我把它拆成了三个具体断点，这样才好对症下药。

1.1 断点一：指标计算直接失效

准确率、精确率、召回率、F1这些指标，本质上都是拿模型输出跟"标准答案"做比对算出来的。标准答案就是标注。没有标注，这些指标一个都算不出来。这是最直观的断点，也是团队里最容易引发争吵的地方——你会听到"效果挺好的"和"你怎么证明它好"两种声音同时出现，而你没有第三种声音来仲裁。

1.2 断点二：回归测试没有基线

AI系统迭代和传统软件有一个本质区别：改动一个模块，很可能让另一个模块的行为跟着漂移。你优化了A场景的处理逻辑，B场景的输出可能就变了。为了发现这种"改坏了旧功能"的问题，回归测试需要一套固定的输入和可对比的预期结果。没有标注测试集，就没有可比对的基线。你只能凭印象说"感觉好像好了一点"，但这种感觉没法写进发布评审里，更没法在出问题时追溯"是从哪一次改动开始变差的"。

1.3 断点三：覆盖范围无法度量

测试要回答"哪些场景测过了、哪些还没测"。传统做法是把标注数据按场景打标分类，然后看这批测试集在场景维度上的分布是否合理。没有标注，你连"这批测试数据覆盖了哪些场景"都说不清。更麻烦的是长尾场景——高频场景可能还有几条业务方顺手给的样本，长尾场景是彻底空白，无人标注，也无人问津。

但这三个断点背后，其实藏着一个可以绕过去的本质问题。测试的目标从来不是"比对标注"本身，而是"判定输出质量是否达标"。标注只是实现质量判定的一种手段，而且是最贵、最慢的那种。2026年这套新打法的核心逻辑，就是把"质量判定"这件事从人肉标注转移到三种自动化手段上：让模型当判官、让程序造数据、让系统自己审自己。

2. 2026年的三套无标注测试打法：怎么选、怎么搭

下面这张表是把三条路线放在一起看的选型参考，先有个整体印象，后面再逐条展开。

选型逻辑其实很朴素：

• 项目刚起步、什么历史资源都没有，先用合成数据打底，解决"有没有测试集"的问题；
• 系统已经跑起来了，但没人说得出质量好坏，上大模型判官，解决"质量怎么量化"的问题；
• 系统迭代频繁、最怕把旧功能改坏，上一致性自检当回归红线，解决"缺陷怎么第一时间发现"的问题；
• 资源和时间都允许，三条一起上，各管一段，效果最好。

为什么这套打法到了2026年才成立？我自己的观察是三个条件最近两年刚刚凑齐：一是通用大模型的推理成本降到了可以批量拿来当评价工具的程度；二是开源模型能力足够，本地就能搭判官和生成器，不用把数据送到外部；三是算力普及，让"跑大量扰动测试 + 多次采样投票"这种以前觉得浪费的活变得可以接受。说白了，不是方法变新了，是成本结构变了。

3. 打法一：大模型判官——配置公式与三个隐藏陷阱

大模型判官的原理一句话就能讲清：不给测试数据标答案，而是把"输入 + 输出 + 评价标准"一起丢给大模型，让它照着标准打分或判定。最典型的一个项目，是给一个评论分类系统做测试。当时系统业务上要把用户评论分成若干个类别，但一条历史标注都没有。我给判官设计的是下面这个结构的提示词：

你是一个质量评估员，请根据以下规则对系统的输出进行判定。 判定维度： 1. 类别是否与内容相符，返回相符/部分相符/不符； 2. 是否存在边界争议情况，返回有/无； 3. 用一句话说明判定理由。 输入内容：{{input}} 系统输出：{{output}} 输出要求：严格按 JSON 格式返回以上三个维度的结果。

3.1 判官配置的三个关键点

第一个关键点，评价维度一定要拆细，不要只给一个总分。总分会把信息全糊在一起：系统到底是类别分错了，还是边界情况处理得不到位？完全看不出来。而拆成多个维度之后，每个维度的得分可以单独追踪，后续定位问题模块就快得多。这也是模型判官比人肉标注更实用的地方——人标的时候通常只给一个"对/错"，模型却能以几乎相同的成本一次性给出一组细粒度评价。

第二个关键点，判定标准必须写得"可观察"，不能写抽象标准。"判断分类是否合理"这种话等于没说，判官模型同样会被含糊指令带偏，最后给你一大批模棱两可的"部分相符"。正确的写法是给具体信号："如果输入内容明确提到X，而输出分类完全不涉及X，则判为不符"。

第三个关键点，用多次独立采样加阈值平移来控制误判。有人以为把温度设成0就万事大吉，实际上温度0多次请求之间仍然会有微小波动。更稳的做法是对同一批样本做多次独立判定，用多数表决出一个结论，然后把通过线设置得比人肉评测习惯的标准更严。比如人工评测时90%正确率就敢发布，用模型判官我会把阈值提到92%～95%。

3.2 三个隐藏陷阱

陷阱一是判官和被测系统"同源"时容易互相吹捧。如果被测系统本身就是个大模型，判官又跟它是同一个生态的模型，判定结果通常会虚高——它们的偏好是一致的。我试过最有效的解法是换个不同背景的模型当判官，哪怕它单看能力弱一点，只要跟被测系统不同源，反而更容易挑出毛病。

陷阱二是判官会偏爱"看起来像正确答案"的输出。长答案、格式工整、套话多的结果得分往往偏高。这不是判官有主观恶意，而是训练数据里这类文本得到的正向评价天然就多。解法是把"长度"和"格式"单独列成无关维度，在提示词里明确要求忽略格式差异，只判断内容逻辑。

陷阱三是判官误判会被当成真理沉淀。这是最隐蔽的一个。判官给出的结论直接进测试报告，没人质疑它的正确性，但它是会错的。我的习惯是每个迭代周期至少抽5%～10%的判定结果让人工过一遍，不是重新标数据，而是检查判官有没有系统性跑偏，比如某类措辞总是被误判。抽检成本远低于全量标注，却能拦住最危险的信任危机。

4. 打法二：合成数据测试——把"等标注"变成"造场景"

合成数据解决的是另一个问题：没有测试集。传统方式是等标注慢慢标出来，合成方式是直接把测试输入造出来。要说明的是，合成出来的数据本身没有标准答案，所以它通常要和大模型判官配合使用——合成数据负责扩充覆盖，判官负责给这批数据的结果做质量判定。两条路线是合着用的。

按可控程度，我把造数据的方式分成三档。

4.1 三档造数据方式

第一档：模板加规则。手写一套模板，变量用规则随机填。比如测试一个文档信息抽取系统，我先定一套合同模板：甲方、乙方、金额、日期、条款编号，然后随机组合正常值、缺省值、格式错位值。这一档成本最低、产出完全可控，但生成的数据面貌太"规整"，测不出太野的场景，适合冒烟测试和基础覆盖。

第二档：通用大模型扩写。给模型几粒"种子"样例，让它模仿生成更多变体。种子可以来自生产环境的脱敏样本，也可以来自手头仅有的十几条真实数据。这一档产出面貌自然、多样性好，但有个致命风险：生成分布会被种子困住。种子全是某一类形态，生成出来的就都是那一类形态的变种，长尾问题依旧测不到。

第三档：变异和模糊化。拿已有样本做随机变异：替换同义词、打乱顺序、插入噪声、截断超长文本。这一档最接近传统软件测试里的模糊测试思路，专门测鲁棒性。它不追求数据的"真实性"，只追求数据的"刁钻程度"。

4.2 配套的覆盖度检查机制

合成数据测试系统最怕的是"造了一堆看起来很多、其实全是同一类"的数据。所以需要配套一个覆盖度检查机制。我常用的做法是把生成的样本转成向量，计算它们在特征空间里的分布，再看整体多样性指标的变化趋势。多样性持续上升，说明覆盖在扩展；多样性停滞，说明生成器在自我重复，该换种子或者换一档生成方式了。这个过程不需要任何标注，只需要算向量。

4.3 抽检机制不能省

另一个关键经验是合成数据必须接受人工抽检。生成器会因为提示词里的一个小疏忽，批量生成一批"业务事实说不通"的数据。比如让大模型生成简历摘要测试数据，它可能把同一段工作经历编造出互相矛盾的两个版本，而你不会发现，直到某次抽检才暴露。我的习惯是每个批次抽 5%，只检查两件事：业务上是否说得通、格式上是否满足约束。抽检成本可控，但能拦住最蠢的批量事故。

5. 打法三：一致性自检与对抗式出题——没有标准答案就找"矛盾"

还有一类测试，连质量判定都先不做，只做一件事：找矛盾。对AI系统来说，"不一致"本身就是一类明确的缺陷信号，而且这个信号完全不需要标注就能识别。

5.1 三类自检玩法

第一类是差分对比。同一个输入分别喂给两个版本，比如旧版和新版、主模型和备用模型，把输出差异大的样本全部挑出来。差异大不代表新版错了，但一定代表"行为发生了实质变化"。在回归测试里，这就是必须人工确认的高风险信号。对没有标注数据的团队来说，这是几乎免费的回归红线。

第二类是扰动一致性。把输入做微小扰动：同义替换、打乱语序、插入无意义分隔符，然后看输出是否保持稳定。一个稳定的系统不应该因为这类无关扰动而剧烈改变输出。这个思路跟传统测试里的幂等性测试很像。扰动一致性不需要任何标注，却能在上线前拦住一大批鲁棒性问题。

第三类是对抗式出题。让被测系统自己出题考自己。测试一个知识问答系统时，我让它基于自己的知识库生成一批"最难的问题"，再回答一遍，检查有没有自相矛盾。也可以让一个模型扮演出题人，另一个扮演答题人，互相挑剔。这套玩法离标准答案最远，但用来暴露知识盲区和推理漏洞，效果出奇地好——因为它生成的题目天然贴合模型的思维习惯，人的出题思路反而测不到这些死角。

5.2 核心洞察：不一致就是缺陷信号

这类打法的核心洞察是：测试不一定非要回答"哪个是对的"，只需要回答"这里有没有问题"。把有问题的样本挑出来，再用人肉或者判官做二次判定，标注量就从"全量"降级成了"几十条高危样本"。这是我认为2026年最值得推广的降本思路。你不用知道正确答案，只需要知道哪里出了状况，然后把有限的注意力集中在那些状况上。

6. 落地前先看这份避坑清单（含参数和校准思路）

这一年多我把三条路线在项目里轮了个遍，有些坑是踩完之后才反应过来的，整理成五条，供直接参考。

6.1 不要迷信单一判官

任何单一大模型判官都存在系统性偏差。最少要用两个不同定位的模型做交叉判定，或者一个模型判、一个轻量模型复核。我自己项目里交叉判定的不一致率一开始高达15%——看到这个数字，你就知道单判官有多不靠谱。

6.2 合成数据的质检环节不能省

省掉抽检，你测的其实是"生成提示词的符合度"，而不是"业务场景的质量"。数据造得再像，业务事实说不过去，测试结果就是典型的垃圾进垃圾出。每批次5%的抽检比例是我实践下来比较平衡的数值，业务风险高的场景可以提到10%。

6.3 把评价过程本身当成测试资产

没有标注数据，你拿不到"准确率96.7%"这种漂亮数字，但你得到了一套更宝贵的资产：评价流程。判官配置、合成数据版本、扰动规则、阈值设置，这些东西要全部版本化、留痕、可复跑。下次迭代继续用同一套流程，不同版本之间才有可比性。每批次的判定结果和抽检记录都要保存好，它们就是你未来出问题时的追溯依据。

6.4 阈值从严，宁可多拦不可少拦

模型判官整体偏向宽松，原因是它倾向于做"合理性判断"而非"严格对错判断"。所以拿它的判定结果做发布决策时，阈值要往严了调。具体调多少没有标准答案，我的方法是先抽一批人工抽检样本做一轮校准，看判官得分和人工结论之间的差距，再定通过线。

6.5 在场景里选路线，别在会议室里选路线

我见过一个团队花好几周搭最复杂的对抗式自检框架，结果他们的问题只是"新模块连最基础的功能对不对都没验证过"。搭个模板加规则的一档合成数据就够用了，资源全浪费在炫技上。选路线之前，先回答一个朴素问题：这个系统现在最缺的是覆盖、质量判定，还是回归保障？缺什么就补什么。

注意：以上数值和比例不是标准答案，是我自己项目里的处理方式。人力、业务复杂度、发布节奏不同，参数都要重新校准。

7. 如果只留一条建议

真要让我只留下一句话，我会说：三条路线最后一定会在一个闭环里汇合。合成数据批量扩充覆盖，大模型判官给出维度化的质量判定，一致性自检兜住回归风险，每轮抽检的人工反馈再回来修正生成器和判官配置。跑两三轮之后你会发现，团队对"质量"的理解反而比有标注数据的时候更清楚。标注数据只会告诉你"对不对"，而这套组合会告诉你"哪里可能不对"以及"为什么需要重点看它"。对一个测试工程师来说，后者才是真正值钱的信息。