首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >语料标注规则:其他五份材料的依据都在这里

语料标注规则:其他五份材料的依据都在这里

原创
作者头像
AI备案指南当当
发布于 2026-11-06 13:40:22
发布于 2026-11-06 13:40:22
260
举报

本文讨论《生成式人工智能服务备案》材料中「语料标注规则」附件与其他材料之间的引用关系,视角为交叉核验与一致性问题。文首声明:本文不含产品推广,不构成法律意见;具体的材料清单与要求以属地网信部门口径为准。


0 先说结论

这份材料已经被讨论过几个层面:它是什么(材料定位)、原料从哪来(上游状态)、句子怎么写(文本结构)、发布后怎么维持(生命周期)。这四个层面都成立,但它们都把它当作一份独立的文件在讨论。

实践中的问题往往不在它自己身上。

结论:语料标注规则是六份核心材料里的"依据文件"。其他五份里凡是涉及语料与标注的表述,成立与否取决于它里面有没有对应的内容。

由此引出四个判断:

判断一:它单独写得再好,也可能因为其他材料引用不到它而失效。 反之,它写得粗糙,会连带拖累至少三份材料。

判断二:四类连带失效最常见,且都表现得很像"合规"——评估报告写了措施、词库写了覆盖、题集写了题型、协议写了承诺,每份都合格,但两两对照就对不上。

判断三:正确的编制顺序是反的。 不是先写完规则再让其他材料引用,而是先看其他五份已经承诺了什么,规则必须能兜住这些承诺。前者容易漏,后者天然覆盖。

判断四:一致性核验只有四个部位值得逐个对齐——时间、数量、口径、角色。 其余细节可以容忍差异,这四个对不上就是硬伤。

后面按这个顺序展开。


1 六份材料之间的引用关系

先把关系画清楚。六份核心材料里,只有一份是描述过程的,其余五份描述结果或状态。这个不对称决定了引用方向。

材料

描述对象

是否涉及语料/标注

与规则的关系

备案表

算法与服务的基本信息

应用场景、数据来源类型

互为依据:来源类型须与规则一致

安全评估报告

服务的安全措施与结论

语料来源合法性、过滤机制、标注质量

引用规则:规则是这些措施的落地证据

语料标注规则

标注过程本身

全部

—

拦截关键词列表

内容安全的拦截范围

与语料过滤环节的关系

引用规则:更新机制、维护角色写在规则里

评估测试题集

测试的题型与判据

风险分类的判定口径

引用规则:题型须对应规则里的判定类别

模型服务协议

对用户的承诺

语料审核、内容不生成的承诺

引用规则:承诺的背后措施在规则里

四份单向引用、一份双向。这个结构说明一件事:规则的失误会被放大五次,而其他材料的失误通常只影响自己。

1.1 为什么安全评估报告最依赖它

在安全评估报告里,关于语料的部分通常写三段:来源是否合法、是否做了内容过滤、标注是否规范。

这三段都是结论。审核方追问的不会是结论,而是"依据在哪里"。

  • 来源合法性 → 依据是规则里的来源类型与授权链描述,以及在评估时点是否仍然成立。
  • 内容过滤 → 依据是规则里的过滤环节、过滤标准、过滤记录形态。
  • 标注规范 → 依据是规则本身,加上人员与质检机制。

所以一个典型的返工场景是:评估报告被要求补充"语料来源合法性的具体说明",团队回去补报告,但没有回到规则里补来源分类和授权证据形态——下次追问还是同一个问题。

这类反复的根因不是报告写得不够细,是依据那一层是空的,补在结论层没有用。

1.2 为什么这类错位难以自查

原因不在能力,在分工。六份材料通常由不同的人、在不同的时间、为不同的读者写。

材料

通常的起草方

主要读者

更新触发

备案表

合规/项目负责人

受理系统

主体或产品变化

安全评估报告

合规主导,算法配合

省级初审、终审

模型版本、措施变化

语料标注规则

数据团队或代笔

内部执行+审核方

语料、模态、口径变化

拦截关键词列表

内容安全团队

内部执行+审核方

词库更新

评估测试题集

算法或测试团队

技术测试环节

模型能力、风险变化

模型服务协议

法务

用户+审核方

条款调整

六个起草方、六套更新触发。没有任何一个人同时看这六份,所以也没有任何一个人能发现它们之间对不上。

这就是为什么"每份都合规、合起来不对"会是一种稳定状态——它不是谁的疏忽,是结构决定的。

修法不复杂,但需要一个动作被明确指派:在提交前安排一次交叉比对,责任人固定为一个人,而不是让六个人各自检查自己那份。 各自检查的结果一定是六份都合格,因为单份检查发现不了跨材料的错位。


2 四类连带失效

以下四种是实践中出现频率最高的。它们的共同点是:单看每份材料都合格,两两对照才暴露。

2.1 报告写了措施,规则里找不到环节

安全评估报告写"已建立语料内容过滤机制"。这句话本身没有错,但它需要一个可核验的位置:过滤发生在哪个环节、由谁执行、判定标准是什么、记录保存在哪里。

如果规则里只写了标注阶段的判定,完全没有"入库过滤"这个环节,那句话就退化成自述。

判据:在规则里搜索"过滤"这个词。搜不到,报告里那句"已建立过滤机制"就没有落地位置。

2.2 词库写了覆盖,规则里没有对应分类

拦截关键词列表通常会声明覆盖的风险类别,比如若干类违法不良信息。

而语料标注规则里也会有自己的风险分类。这两套分类如果类别数和划分口径不一致,会出现一个具体的后果:被词库声明覆盖的某一类,在规则里没有对应的判定标准,于是标注阶段实际上没有人在管这一类。

这类不一致在提交时几乎看不出来,因为它需要把两份材料的分类表并排看。

2.3 题集测的不是规则管的东西

评估测试题集的作用是验证服务在压力下的表现。它的题型设计通常从风险分类出发。

问题在于:如果规则里的判定类别与题集的风险类别不是同一套,题集测出来的结论就无法反推规则是否被执行。

举个具体的错位:规则按"内容性质"分类(违法、不良、敏感),题集按"交互场景"分类(诱导、越狱、多轮绕过)。两套都对,但它们之间没有映射关系,于是"测试全部通过"不能说明"规则被遵守"。

2.4 协议承诺了,规则里没有周期与责任人

模型服务协议是面向用户的,里面常有类似"定期审核语料""及时处理违规内容"的表述。

"定期"和"及时"在协议里可以接受,因为面向用户不需要精确。但同一个承诺落到规则里,必须变成周期和角色——多久一次、谁做、记录在哪。

如果规则里没有,这个承诺就是无落地承诺。 它在协议层面成立,在核验层面不成立。

2.5 四种失效的共同形态

失效类型

表面现象

对照位置

后果

措施悬空

报告有结论,规则无环节

报告的措施描述 ↔ 规则的环节划分

结论退化为自述

覆盖错位

词库有类别,规则无判据

词库的类别表 ↔ 规则的分类表

某类实际无人管

测试失焦

题集有题型,规则无映射

题集的题型 ↔ 规则的判定类别

通过不等于遵守

承诺无落地

协议有承诺,规则无周期

协议的承诺 ↔ 规则的周期与角色

对外承诺不可证


3 编制的正确顺序是反的

多数团队的顺序是:先写规则 → 再写评估报告 → 再整理词库和题集 → 最后定协议。

这个顺序的问题是:规则是在真空中写的。

写规则的人当时手上只有法规和标准,没有"我们已经在别处承诺了什么"这个约束。于是规则写得自洽,但与已有的对外表述错位。

反过来做会更省事,只需要四步:

第一步,把其他五份材料里涉及语料的句子全部摘出来。 通常是十几到几十句,工作量在半天以内。摘的时候不改写,原样抄。

第二步,逐句问:这句要成立,需要规则里有哪条内容。 答案写在这句旁边。这一步会暴露一批"承诺了但没有依据"的句子。

第三步,把这些需求合并成规则的章节。 会出现重复——比如报告的"过滤机制"和词库的"更新机制"其实都指向规则的同一个环节。合并时注意不要因为来源不同就拆成两节。

第四步,规则写完之后,回头逐句确认。 每句都能指到具体条款,才算闭环。指不到的,要么改规则,要么改那句表述。

这个顺序的额外收益是:规则的章节结构天然对齐了其他材料的核验点,后面被追问时,回答路径是现成的。

3.1 一个常见的反向错误

也有团队走向另一个极端:为了让所有材料都能引用,把规则写成一份大而全的文件,什么都写一点。

结果是规则变得极长,而每一部分都不够细到可判。这时候其他材料虽然"引用得到",但引用到的是一句原则,等于没引用。

判断标准是引用之后能不能落地: 报告写"依据规则第 X 节",翻过去如果看到的是"应对语料进行审核",这个引用是无效的;看到的是"入库前按某标准抽样,超阈值不采集,记录形态为某某",这个引用才成立。


4 一致性核验的四个部位

跨材料比对不需要逐字对,只需要对齐四个部位。这四个对不上就是硬伤,其余可以容忍差异。

4.1 时间

比对项

常见错位

后果

规则版本日期 ↔ 评估报告评估时点

规则在评估之后更新过

报告描述的措施已不是当前措施

规则版本 ↔ 词库版本

词库更新了,规则未同步

覆盖声明与实际不符

规则生效日 ↔ 服务上线日

规则生效晚于上线

存在一段无规则的运行期

时间错位最隐蔽,因为它不影响任何单份材料的自洽。有时序意识的团队会在报告里写"截至评估基准日",这半句能省掉大量解释。

4.2 数量

需要对齐的数字不多,但每一个都会被核对:

  • 语料来源的类别数(报告说三类,规则写了四类)
  • 各类占比的门槛(同一条标准在不同材料里写成不同数字)
  • 标注与审核人员数量(规则写五人,实际组织架构里只有三人)
  • 抽检比例与批次规模

数量不一致的解释成本很高,因为审核方无法判断哪个是对的。

4.3 口径

同一个词在不同材料里指不同的事,是最难发现的一类。

常见的高风险词:样本、批次、审核、抽检、违规、敏感。

举例:"批次"在规则里可能指"一次标注任务覆盖的数据集合",在评估报告里可能指"一次交付的数据量",在词库维护里可能指"一次词库更新周期"。

三个含义都合理,但同时存在时,"本批次合格率"这个指标就没有确定含义。

处理方式不是统一成一个意思,而是在规则里设一节术语定义,明确本文档内的含义,并在其他材料首次使用该词时注明"详见语料标注规则的术语定义"。

4.4 角色

规则里写"由专人审核",报告里写"设置独立审核岗",而实际组织架构里这两件事都由同一个人兼。

这一项的问题不在文字,在事实。规则描述的角色与实际分工不一致时,任何一次现场核对都会暴露。

一个可行的自检:把规则里出现的所有角色名抄成一列,逐个问"这个角色现在由谁担任,姓名是什么"。 答不出来的那一行,就是纸面角色。

4.5 冲突时改哪一份

对齐过程中一定会遇到两处不一致,而两份材料都不算写错。这时需要一条判断原则,否则会陷入反复改、改到两边都模糊。

原则只有一句:往"更难被推翻"的那一侧改。

展开成四种情形:

冲突类型

往哪边改

理由

规则写"每批抽检 5%" ,报告写"定期抽检"

改报告,采用规则的量化值

量化值可核验,模糊表述不可核验

规则写三类来源,实际有四类

改规则,补第四类

事实优先于文档,隐藏一类会留下隐患

规则写五人,组织架构三人

改规则,写成实际人数并说明兼岗

人数会被现场核对,写多写少都是硬伤

协议写"及时处理",规则写"三个工作日内"

两边都不动,在规则中注明协议承诺的对应时限

面客语言需要柔和,内部标准需要精确

四种情形背后是同一条逻辑:可核验的压过不可核验的,事实压过表述,精确压过模糊。 唯一例外是对外文件的面客措辞——那里不必精确,但必须在内部找出精确对应,否则承诺无落地。

还有一个实践提醒:改哪一份的决定,最好一次做完并记录。分次改最容易出现"改了一半"的状态——规则改了,报告还是旧的;或者报告改了,词库没跟。

这类半完成状态比原来的不一致更难处理,因为它连"哪一版是基准"都说不清了。


5 一张交叉核验表

下表把六份材料两两之间的关键交叉点列出,可直接用于提交前的自查。

交叉点

一侧

另一侧

核验方式

语料来源类型

备案表的应用场景描述

规则的来源章节

类型名称与数量是否一致

来源合法性

评估报告的措施段

规则的授权链与证据形态

报告所指的措施能否在规则中定位

过滤机制

评估报告

规则的过滤环节与标准

是否写明环节、标准、记录

风险分类

词库的类别表

规则的判定分类

类别数与划分口径是否一致

词库更新

词库的维护说明

规则的角色与周期

谁维护、多久一次、如何留痕

测试题型

题集

规则的判定类别

是否存在类别映射关系

人员数量

评估报告

规则的角色章节

与组织架构是否一致

对外承诺

服务协议

规则的周期与角色

"定期""及时"是否已量化

版本时序

规则版本与生效日

报告基准日、上线日

是否存在无规则的运行期

术语含义

各材料首次出现处

规则的术语定义节

同词是否同义

这张表的价值在于:它把"材料是否齐全"这个问题,换成了"材料之间是否对得上"。前者是清单思维,后者才是核验思维。

5.1 一个反例推演

假设一家公司认真准备了三轮,每轮都被人指出问题,但指出的位置每次不同。把三轮的追问排在一起,就能看出它们其实是同一条线。

轮次

被追问的内容

当时的处理

结果

第一轮

语料来源合法性的具体说明不够

在评估报告里补了一段说明

通过,但留下了伏笔

第二轮

该说明提到"多来源采集",需说明各类占比

在报告里补了占比数字

通过,但数字与规则不符

第三轮

规则中的来源分类与报告不一致,需说明

改规则,向报告靠拢

通过,但规则与词库分类又错位

三轮的处理都是"就地问、就地答",每轮都通过了。但真正的根因在第一次就没有被处理:来源分类这一层从来没有被统一过,于是它在报告、规则、词库三处各长成一套。

如果在第一轮就回到规则里把来源分类写清,并把报告和词库都对齐到这一套,三轮可以压成一轮。

这个推演的用处不是事后复盘,是提醒一个动作:当某份材料被追问时,先问一句"这个问题的依据在哪份材料里",而不是直接在被追问的那份上改。 直接改通常能过,但会把不一致留给下一轮。

5.2 交叉核验怎么做成例行动作

不必每次都从头做。压缩成三个动作,每季度或每次提交前跑一次:

第一,摘句。 用检索的方式把其他五份材料里涉及语料的句子找出来,通常十几到几十句。关键词不必多,四个够用:语料、数据、标注、审核。

第二,比对。 逐句问"要成立需要规则里有什么",答案写在旁边。这里会出现两类问题:一类是规则里没有,一类是规则里有但说的不是一回事。

第三,留档。 把这次的比对结果存一份,标注日期与对应的规则版本。下一次比对时先看上一份,只处理变化的部分,工作量会降到第一次的三分之一。

三个动作加起来,第一次约半天,之后每次一到两小时。这个投入相对于一次返工,成本比大约是 1:10。


6 提交前核验清单

26 项,四组。逐项打勾之前不建议提交。

A 引用闭环(7)

  • [ ] 其他五份材料中涉及语料的表述已全部摘出,形成清单
  • [ ] 每一句都能指向规则中的具体条款
  • [ ] 指向的条款是判定句或检测句,不是原则表述
  • [ ] 无法指向的句子,已修改表述或补齐规则
  • [ ] 规则的章节结构与其他材料的核验点对应
  • [ ] 规则未因覆盖面要求而变得过长,各部分仍可判
  • [ ] 已确认不存在"多处引用同一节但各说各话"的情况

B 时间与时序(6)

  • [ ] 规则版本日期不早于评估报告的评估基准日
  • [ ] 规则生效日不晚于服务上线日
  • [ ] 规则更新后,评估报告中受影响的段落已同步
  • [ ] 词库版本与规则版本的时间关系明确
  • [ ] 存在版本交替期时,已注明各批次适用哪一版
  • [ ] 报告中已写明"截至某基准日"这类时序限定

C 数量与口径(7)

  • [ ] 语料来源类别数在各材料中一致
  • [ ] 各类占比门槛的数字一致
  • [ ] 标注与审核人员数量与实际组织架构一致
  • [ ] 抽检比例与批次规模的定义一致
  • [ ] 规则中设有术语定义节,覆盖样本/批次/审核/抽检等词
  • [ ] 其他材料首次使用上述术语时,注明以规则定义为准
  • [ ] 同一指标在各材料中的计算口径一致

D 承诺与角色(6)

  • [ ] 服务协议中"定期""及时"类表述,在规则中已量化为周期
  • [ ] 规则中的每个角色,都能对应到具体担任人
  • [ ] 不存在同一人同时担任执行与审核、且未被说明的情况
  • [ ] 外包场景下,规则制定方与执行方的职责边界已写明
  • [ ] 人员离岗时的权限回收,有对应条款与记录形态
  • [ ] 对外承诺涉及的措施,均可在规则中找到执行位置

7 六种常见的不一致

形态

发现方式

处置

类别数对不上

把两份分类表并排

统一类别表,以覆盖面更全的为准

时间错位

对比版本日期与基准日

补时序限定,或同步更新报告

术语同名不同义

逐词查首次出现处

设术语定义节,其余材料引用

纸面角色

逐个角色问"现在谁担任"

改角色描述,或补实际分工

引用到原则

翻到被引条款看是否可判

改写该条款或补充判定标准

承诺未量化

搜"定期""及时""适当"

一律换成周期、次数或时限

六种里,"引用到原则"最不容易被自己发现。因为引用关系是存在的,编号也对,只有在真正去翻那一节、发现里面是原则表述时,才会意识到这个引用没有实质作用。

一个有效的做法:把所有引用关系做成两列——"引用出处"和"被引条款的原文第一句"。两列并排看,凡是第二列读起来像口号而不是判据的,都要处理。


8 FAQ

问:六份材料必须同一时间定稿吗? 答:不必,但必须有明确的时间关系与基准日。做法是每份材料都标注"本版对应的规则版本"和"信息截止日",更新时只改受影响的部分,并记录变更原因。强行要求同时定稿,通常导致所有材料都不敢改。

问:规则里要不要直接抄其他材料的表述? 答:不要。抄过来会产生两个维护点,之后一改就不同步。正确做法是规则写判据,其他材料写结论并引用规则,形成单向依赖。

问:词库的分类和规则的分类必须完全一致吗? 答:数量与划分层级必须一致,表述可以不同。比如规则的"违法信息"下有若干子类,词库可以按投放场景再细分,但顶层类别必须能一一对应,否则覆盖声明无法核验。

问:题集与规则没有映射关系,一定要补吗? 答:建议补一张映射表,不需要改写任何一份材料。表的形式是"题集的风险类别 → 规则中对应的判定条款"。这张表能回答一个关键问题:测试通过说明规则被执行到了什么程度。

问:小团队只有两三个人,角色对不上怎么办? 答:不必虚构岗位。规则里可以写"由某角色承担,本团队由某某兼任",并说明兼岗时的补偿措施(如外部复核、交叉抽检)。虚构角色比承认兼岗风险更大,因为现场核对一定会问。

问:这套内容是法规要求还是经验总结? 答:材料清单与语料、标注的基本要求来自《生成式人工智能服务管理暂行办法》与 GB/T 45674—2025《网络安全技术 生成式人工智能数据标注安全规范》(2025-04-25 发布、2025-11-01 实施)等文件。而"六份材料之间的引用关系""四类连带失效""四个一致性部位"是实践视角的归纳,用于组织工作,不替代标准条文。


9 结语

这份材料的特殊性在于:它是唯一描述过程的,因此它天然是其他材料的依据。

这带来一个不对称的后果——它写得好,只能保证自己合格;它写得空,会连带让另外三到四份材料的表述失去支撑。

所以判断它的质量,不该只问"这份材料写全了吗",而该问一句:

把其他五份材料摊开,凡提到语料的地方,能不能都在这里找到落点?

找不到的那几处,就是你真正的缺口。它们藏在别的文件里,不在这一份里。


附:主要依据

  • 《生成式人工智能服务管理暂行办法》——语料来源合法、标注规范、服务协议与安全评估的规范来源。
  • 《互联网信息服务深度合成管理规定》——训练数据与内容管理要求。
  • GB/T 45674—2025《网络安全技术 生成式人工智能数据标注安全规范》,2025-04-25 发布、2025-11-01 实施——标注规则、人员管理、质量评估与隔离要求的直接依据。
  • GB/T 45652—2025《网络安全技术 生成式人工智能预训练和优化训练数据安全规范》——语料来源、内容安全与授权的前置要求。
  • GB/T 45654—2025《生成式人工智能服务安全基本要求》——服务侧整体要求,附录对语料安全给出量化参照(属资料性附录)。

说明:文中未引用具体条款号,以避免因标准版本差异造成误引;引用量化值时保留原文的"应/宜"性质。实际填报请以正式标准文本及属地网信部门口径为准。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

目录
  • 0 先说结论
  • 1 六份材料之间的引用关系
    • 1.1 为什么安全评估报告最依赖它
    • 1.2 为什么这类错位难以自查
  • 2 四类连带失效
    • 2.1 报告写了措施,规则里找不到环节
    • 2.2 词库写了覆盖,规则里没有对应分类
    • 2.3 题集测的不是规则管的东西
    • 2.4 协议承诺了,规则里没有周期与责任人
    • 2.5 四种失效的共同形态
  • 3 编制的正确顺序是反的
    • 3.1 一个常见的反向错误
  • 4 一致性核验的四个部位
    • 4.1 时间
    • 4.2 数量
    • 4.3 口径
    • 4.4 角色
    • 4.5 冲突时改哪一份
  • 5 一张交叉核验表
    • 5.1 一个反例推演
    • 5.2 交叉核验怎么做成例行动作
  • 6 提交前核验清单
  • 7 六种常见的不一致
  • 8 FAQ
  • 9 结语
  • 附:主要依据
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档