分类分级准确率 95% 是怎么算出来的：七种测试操纵手法

95% 准确率是怎么算出来的

分类分级测试的潜规则

上一期我们拆穿了三类伪 AI 工具——字典翻译派、规则伪装派、小模型贴牌派。读者反馈最集中的一个问题是：

既然有这么多伪 AI,为什么它们在 PoC 演示中能跑出 95% 甚至 98% 的准确率?这些数字是怎么来的?

这个问题问得正中要害。今天市场上几乎每一家分类分级厂商都会在销售材料里印一个准确率指标——95%、97%、99% 都有，看起来都很漂亮。但只要把测试方法揭开一层，会发现这些数字背后藏着一套精心设计的「测试潜规则」。

更让人不安的是——这套潜规则不仅厂商在用，许多机构内部的「自验」流程也在用。结果是整个行业进入了一种「集体自我欺骗」的状态：所有人都知道准确率指标有水分，但所有人都还在引用这些指标。

这一期我们做一件实在的事——把准确率这个指标拆开，讲清楚它在分类分级测试中是如何被操纵的，以及一份合理的 PoC 测试应该怎么做。

一、为什么准确率如此容易被操纵

准确率这个指标，在很多领域是相对客观可信的——比如图像识别、语音识别，有公开的标准数据集（ImageNet、LibriSpeech），任何模型都可以在同一份数据上跑分，谁的数字高一目了然。

但分类分级的「准确率」之所以容易被操纵，是因为它缺少这三个客观锚点：

锚点缺失一:没有公开标准测试集

分类分级涉及的是企业内部的真实字段——客户数据、账户数据、交易数据、合规标签——这些数据天然敏感、不可能公开。这导致整个行业没有像 ImageNet 那样的「黄金标准数据集」，每家厂商都用自己的测试集报数。

如果一家厂商说「我们在自己的测试集上准确率 98%」，这个数字基本没有可比性——因为你不知道这个测试集长什么样、覆盖了哪些场景、有没有刻意挑过题。

锚点缺失二:没有统一的「正确答案」

即便给定同一组字段，不同的标注者也会给出不同的分类结果——这不是标注者水平问题，是因为分类分级标准本身就有模糊地带。

举个例子：一个字段叫「客户经理评分」，里面存的是销售人员给客户打的内部评分。它应该被分类为「客户数据」（因为评分对象是客户）还是「内部数据」（因为评分主体是行内）？JR/T 0197 在这里只给出了原则，没有给出明确答案——不同的合规专家会给出不同判断。

当「正确答案」本身就有 5%-10% 的内在不确定性时，一个厂商完全可以通过选择有利于自己的「正确答案」来推高准确率。

锚点缺失三:没有统一的测试流程

分类分级测试是端到端的——从字段输入到分类输出，中间还涉及业务上下文、字段说明、关联表分析、样本数据等多种输入。不同的输入信息量会显著影响识别效果。

如果厂商在测试时允许使用「字段名 + 业务说明 + 样本数据 + 表结构 + 关联字段」全套信息，准确率自然就高；如果只给「字段名 + 字段类型」，准确率会断崖式下跌。

但客户在真实业务中能提供的信息往往是后者——业务说明早就缺失了、样本数据涉及脱敏、关联字段需要额外的数据血缘工具。「测试时的输入」和「落地时的输入」根本不是同一回事。

二、七种最常见的测试操纵手法

以上三个锚点缺失给了厂商充足的操纵空间。下面这七种手法是市场上最常见的——它们都不违法，甚至在技术上「合理」，但每一种都会把真实准确率包装成漂亮数字。

手法一:测试集由厂商提供

最朴素也最有效的手法。厂商在 PoC 阶段说：「我们准备了一份测试集，1000 个字段，覆盖了主要场景，你们可以验证我们的产品。」

听起来很合理——厂商已经准备好测试集，节省了客户的工作。但本质上这是一场考试，考题由考生自己出。厂商的测试集必然偏向自己擅长的场景：常见字段、规范命名、结构化数据。结果当然漂亮。

**正确做法:**测试集必须由客户从自己生产系统中抽取,厂商不能接触、不能挑选、不能预览。厂商只能在「客户给定的字段集」上跑结果。

手法二:分母被刻意收窄

第二种手法更隐蔽。厂商在产品页面上说「准确率 98%」，但仔细看脚注：「在可识别字段上的准确率」。

什么意思？厂商的产品先把字段分两类——「能识别的」和「不能识别的」。不能识别的字段直接归入「未分类」，不参与准确率计算。98% 是建立在剩下「能识别的字段」上的。

如果厂商的产品能识别 70% 的字段，剩下 30% 直接放弃——那 98% 的「准确率」实际等价于 70% × 98% = 68.6% 的「全字段准确率」。

这就是为什么客户在 PoC 时看到漂亮数字，落地后发现一半字段还没识别——准确率没骗人，但分母骗了人。

**正确做法:**准确率必须按「全字段」计算——未识别等同于识别错误。如果厂商坚持「在已识别字段上」给数字,要求他们必须同时披露「识别覆盖率」(已识别 / 总字段)。

手法三:类别加权偏向常见字段

第三种手法是利用「类别分布的不均匀」。

真实业务系统中的字段类别分布是极不均匀的——可能 50% 的字段是「客户姓名 / 身份证 / 手机号 / 地址」这四类常见 PII，剩下 50% 才是各种业务特有字段（理财产品代码、风控因子、精算系数等）。

如果厂商在常见 PII 上识别率 99%、在业务特有字段上识别率 50%，整体加权后的「准确率」会显示为 75%——这个数字掩盖了「业务特有字段一半识别错了」这个核心问题。

而对客户而言，正是这些业务特有字段才是分类分级的核心难题——常见 PII 用十年前的规则引擎就能识别。

**正确做法:**要求厂商分档披露准确率——「高频通用字段」「行内特殊字段」「历史遗留字段」三档分别给数,不允许只给整体平均值。

手法四:未公开标注口径

第四种手法更技术化一些——在「正确答案」的定义上做文章。

前面提到，分类分级的「正确答案」有 5%-10% 的内在不确定性。厂商可以利用这个空间，把自己产品输出的分类标准定义为「正确」，然后在测试时按这个标准核对——准确率自然高。

最典型的场景：某个字段在 JR/T 0197 里既可以归为 L3 也可以归为 L4，厂商的产品判为 L3，标注口径也按 L3 算，准确率就是 100%；如果客户内部合规判断应该是 L4，那这个判断就是错的——但客户没法知道厂商用的是哪种口径。

**正确做法:**PoC 开始前,客户和厂商共同确定一份「标注口径文档」——明确每一类边界字段的判定规则,有争议的字段事先达成共识,测试时严格按这份文档评判。

手法五:把非结构化排除在外

第五种手法是范围操纵。

如同上一期讲过的，金融机构 60%-80% 的敏感数据其实存在于非结构化场景——投保单、贷款合同、客服录音、客户经理签报。但绝大多数厂商的产品只能处理结构化字段。

所以在 PoC 测试时，厂商会建议「我们先从结构化数据开始测，非结构化部分后期再扩展」——后期再也不会来。结果是 95% 的准确率只覆盖了 30% 的真实数据资产。

**正确做法:**测试集必须包含结构化与非结构化两类样本,各自单独给准确率。如果厂商不能处理非结构化,要明确写在评估报告里——这是产品能力的硬缺口,不是「后续扩展项」。

手法六:不公布混淆矩阵

第六种手法是用「整体准确率」掩盖「类别失衡」。

机器学习里有一个基础概念叫混淆矩阵——它会告诉你每一类的精确率（Precision）和召回率（Recall）。这两个指标比「整体准确率」重要得多：

1. **精确率：**判定为某类的字段中,真正属于这类的比例——决定「会不会错杀」；

2. **召回率：**真正属于某类的字段中,被正确判定的比例——决定「会不会漏判」。

在分类分级场景里，对监管的核心要求是「不能漏判」——一个 L4 字段被漏判为 L3，会被监管直接定性为合规漏洞。但厂商只报「整体准确率」时，召回率低这件事完全看不出来。

**正确做法:**测试报告必须包含每一类的精确率和召回率,特别关注「高敏感类别」(L4 / 核心数据 / 重要数据) 的召回率——这是监管最关心的指标。

手法七:测试集与训练集同源

最后一种手法是机器学习领域的经典作弊——「测试集泄漏」。

如果厂商用过去三年从行业里收集的字段样本训练模型，再用同一批样本做测试集（哪怕换个名字、改几个字段），模型当然能跑出 95% 的准确率——它本质上是在「记忆」而不是在「推理」。

更隐蔽的版本是：厂商用某家头部银行的字段训练模型，然后到其他银行做 PoC——只要这两家银行的字段命名规范相似，模型就能跑出很高的准确率。但只要换一家命名规范不同的机构，准确率就会大幅下跌。

**正确做法:**PoC 协议中要求厂商书面声明:测试集中所有字段从未参与过其产品的任何模型训练或字典构建。如果厂商不能给出这个声明,这次 PoC 就没有任何参考意义。

三、七种手法速查表

把以上七种手法整理成一份速查表，方便采购方在 PoC 协议谈判时直接对照。

四、一份合理的 PoC 测试应该长什么样

讲完七种手法之后，反过来定义一份合理的 PoC 测试。整个流程可以分四个阶段。

阶段一:样本准备(客户主导)

客户从自己生产环境中按以下规则抽取测试集：

1. 覆盖至少 3 个不同业务系统(核心、信贷、风控);

2. 覆盖至少 1 个老旧系统(建于 2010 年前、命名不规范的系统);

3. 覆盖至少 30% 的「行内特殊字段」(命名不在公开字典里的);

4. 如果机构有非结构化数据需要处理,至少包含 100 份典型文档样本;

5. 样本总量建议不少于 3000 个字段。

样本抽取过程不允许厂商参与，最好由客户的数据治理团队和合规团队共同确定。

阶段二:标注口径对齐(双方共同)

客户和厂商共同制定一份「标注口径文档」：

1. 明确分类标准的版本号(JR/T 0197-2020 / 金规 24 号 / 行内自定义);

2. 对边界字段事先达成共识(列出 20-30 个最容易有争议的字段,逐一标注);

3. 约定标注方式——是否提供字段说明、是否提供样本数据、是否提供关联表结构。

这份文档应作为 PoC 协议的附件，正式签署。

阶段三:盲测执行(厂商主导)

厂商在不接触客户内部环境的情况下，对样本集运行产品：

1. 客户向厂商提供事先约定的字段信息(按标注口径文档约定的范围);

2. 厂商在指定时间内(通常 24-72 小时)给出全部分类结果;

3. 结果必须包括每一个字段的分类标签、置信度,以及——这一条特别重要——推理依据。

如果厂商无法给出推理依据，只能给「这是某类」的结论，参考上一期讲过的，这是规则伪装派的典型信号。

阶段四:结果评估(客户主导)

客户按以下维度评估：

1. **总体覆盖率:**厂商识别出多少字段(已识别 / 总字段);

2. **分档准确率:**高频通用字段、行内特殊字段、历史遗留字段三档分别给数;

3. **高敏感召回率:**L4 / 核心数据 / 重要数据的召回率——这是合规风险指标;

4. **可解释性:**随机抽 20 个识别结果,验证厂商给出的推理依据是否符合监管标准;

5. **运维成本:**如果客户需要新增一类字段,厂商需要多久才能支持。

这五个维度合起来，才是一次完整的产品评估。

五、一个合理的准确率预期是多少

讲到这里，读者会问一个反向问题：

既然 95% 是水分,那真实的分类分级产品准确率应该是多少才合理?

基于我们走访市场以及自身产品落地的经验，给出一个相对客观的参考区间：

规则引擎 + 字典(第一代 / 字典翻译派)

1. **高频通用字段:**85%-95%(字典覆盖范围内表现尚可);

2. **行内特殊字段:**30%-50%(字典覆盖之外几乎失效);

3. **历史遗留字段:**10%-30%;

4. **整体准确率:**40%-65%(取决于业务系统的现代化程度)。

训练式模型(第二代 / 小模型贴牌派)

1. **高频通用字段:**90%-97%;

2. **行内特殊字段:**55%-75%(取决于训练数据与客户字段的分布吻合度);

3. **历史遗留字段:**40%-60%;

4. **整体准确率:**65%-80%。

业务推理引擎(第三代)

1. **高频通用字段:**95%-99%;

2. **行内特殊字段:**85%-95%(通过业务上下文推理,不依赖训练样本);

3. **历史遗留字段:**80%-90%;

4. **整体准确率:**90%-95%,常见类型可至 97%。

注意这些数字是「在合理 PoC 流程下」的真实表现——包含拼音字段、行内特殊字段、历史遗留系统、非结构化样本。如果一个产品宣传「99% 准确率」但拒绝在合理 PoC 流程下验证，这个数字大概率是包装出来的。

写在最后

回到本文开头那个问题:为什么市场上充斥着 95% 甚至 99% 的准确率数字?

不是这些厂商在「造假」——他们的测试方法在技术上都成立。问题在于:这套测试方法回避了分类分级的真实难题——拼音命名、行内特殊字段、历史遗留系统、非结构化数据——把测试集设计成了产品擅长的样子,然后报出漂亮数字。

整个行业心照不宣地接受了这套规则,客户在采购阶段被漂亮数字吸引,在落地阶段为真实表现买单——这种「集体自我欺骗」的状态在 2026 年的执法年里已经无以为继。

一个能在生产环境真实跑出 90% 准确率的产品,远比一个 PoC 演示能跑出 99% 准确率的产品有价值。

下一期我们会跳出金融行业,讨论一个更根本的问题——「中国式分类分级」与海外 Classification 的本质差异。这件事关乎为什么直接搬海外 DSPM 工具进中国一定水土不服,也关乎中国的数据安全工具应该走一条什么样的路。

—— AiDClass 团队 · 模界数智