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