首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >大模型备案到底在审什么:三关各自在问一个不同的问题

大模型备案到底在审什么:三关各自在问一个不同的问题

原创
作者头像
AI算法大模型备案当当
发布于 2026-10-19 09:06:17
发布于 2026-10-19 09:06:17
120
举报

声明:本文基于公开发布的法规文本、备案系统填报口径与公开的属地实践信息整理,不含任何产品推广,也不构成法律意见。涉及具体项目的判断,请以属地网信部门答复为准。

0 先说结论

大多数团队准备大模型备案的方式是错的。

他们把备案理解成"交一套材料",于是把所有精力放在把材料写全、写漂亮上。结果材料交上去,省级这一关过了,技术测试卡住;或者技术测试过了,中央终审退回,理由是"材料前后对不上"。

问题不在材料质量,在方法。大模型备案不是一个审查动作,是三个,而且三关问的是三个不同的问题:

关卡

它在问什么

失败的性质

代价

省级初审

你有没有资格提供这项服务

资格问题

可补正,通常几周

技术测试

你的模型在压力下会不会失控

能力问题

要改模型或改工程,按月计

中央终审

你的材料能不能被独立读懂并对上

叙事问题

要重写材料逻辑,可能推翻前面全部

这三关的失败模式完全不同,处置方式也完全不同。用一套材料、一种写法应对三关,是最常见也最贵的方法论错误。

还有一句更重要的判断,放在开头:大模型备案的实质,不是"证明你的模型很好",而是"把模型的局限讲清楚,并证明你控制住了这些局限"。

这个判断听起来反直觉,但它解释了很多看起来奇怪的要求——为什么要交拦截词库、为什么要测拒答率、为什么自评估报告必须写风险而不是写优势。因为审查关心的从来不是你的模型有多强,而是它在什么情况下会出错、出错时你有没有兜住。


1 先看结构:为什么是"两级两段 + 技术测试"

理解审查动作之前,先理解它的组织形态。

大模型备案的审查结构,与其他两条线明显不同:

维度

算法备案

大模型备案

大模型登记

受理层级

线上系统

属地省级网信办

属地省级网信办

审核层级

单一

省级初审 + 中央终审

单级

是否含技术实测

形式审查为主

含对抗性技术实测

一般不含

周期量级

1–3 个月

6–8 个月(材料扎实可压缩)

1–3 个月

这个结构不是流程设计上的偏好,它对应三个现实约束。

第一,模型是具有通用能力的系统,无法靠纸面判断。 一段代码可以读,一个推荐策略可以算,但一个生成式模型的行为只能测。所以必须有一段实测环节。

第二,实测需要本地化的场景与语料。 属地省级网信部门更了解本地产业形态、本地监管重点,也更方便组织现场核查与测试对接。所以第一道关在省里。

第三,跨属地必须可比。 如果各省口径不一,同样的模型在甲省过、乙省不过,整个制度就失去意义。所以终审在中央,用统一尺度做最后一道判断。

理解了这三点,就能理解后面所有材料要求为什么长那个样子——它们不是表格,是为这三道关各自准备的证据。


2 第一关·省级初审:看的是"这门生意成不成立"

省级这一关,表面看是在审材料,实际是在回答一个更基础的问题:你有没有资格、有没有能力,稳定地对外提供这项服务。

它关心的东西,可以归成四组。

组别

核验内容

常见问题

主体

营业执照、经营范围、法人信息、算法安全责任人

主体与实际运营不一致;责任人非本单位正式员工

产品

产品名称、域名、ICP 备案、服务形态、上线状态

产品名称与 ICP 不一致;服务形态描述与实际不符

链路

模型来源、调用关系、数据流向、部署方式

链路说明停留在"调用了大模型能力"这一层

制度

安全管理制度、应急预案、主体责任落实文件

直接套用模板,与公司实际组织架构对不上

四组里,前三组是事实核验,第四组是能力判断。

事实核验这部分的规律很好掌握:凡是能在外部系统里查到的,就不能含糊。 主体名称在工商系统里能查,域名 ICP 在工信部系统里能查,产品能不能打开、页面写了什么,审核人员点一下就知道。这一组出错,通常不是不会写,是资料没有对齐。

第四组更容易被低估。制度文件的审查重点不是"有没有",而是"是不是这家公司的"。模板痕迹明显的文件会引来追问:这个应急流程里写的联系人是谁?这个分级处置标准对应你们哪条业务线?答不上来,材料就会被退。

这一关的失败性质是"资格问题",所以它是可补正的。 补正周期通常以周计。这意味着:初审被退回不是灾难,但也别指望在这里省时间——因为补正一次就重排一次。


3 第二关·技术测试:看的是"模型在压力下会不会失控"

这是三关里最不透明、也最容易低估的一关。

它的形态是:提交若干个已实名认证的测试账号,由技术侧围绕一组测试集对服务进行实测。测试的覆盖面通常包括基础安全、提示词注入、多模态输入、多轮诱导等方向。

这一关与初审的根本区别在于:初审看你写的东西,测试看你实际跑出来的东西。 你可以在材料里把安全能力写得很好,但测试会直接问模型一些它不一定会好好回答的问题。

3.1 为什么要有"量级"要求

实践中最被诟病、也最容易被当成形式主义的,是题库与词库的量级要求——测试题集要达到一定题量,拦截关键词库要达到一定词数,部分地区要求更高。

很多团队的第一反应是:"凑数就行了。"

这个理解是错的。量级要求的意义不在数字本身,在于它排除了"抽查式合规"。

一个只有几十条题目的测试集,可以被针对性调优——你知道会考什么,就能提前把答案准备好。但一个上千条、覆盖多个风险方向、且要求定期更新的题库,针对性调优的成本会急剧上升。量级在这里的作用,是让"应付"这件事变得不经济。

同理,拦截词库的量级要求,排除的是"只拦几个最敏感的词"这种做法。词库要覆盖的不只是明显违规词,还包括变体、谐音、组合表达、跨语言表达。

3.2 拒答率这个指标该怎么理解

拒答率是技术测试里最常被提到的量化指标,量级要求通常在较高水平(实践口径常见为 95% 以上)。

这个指标容易被误读成"要尽量多拒答"。实际上它测的是两件事的平衡:

  • 该拒的有没有拒住(安全侧);
  • 不该拒的有没有乱拒(可用侧)。

只追求前者的模型,会把大量正常问题也拒掉,用户体验崩塌;只追求后者的模型,会在敏感问题上放行。所以拒答率不是一个"越高越好"的指标,是一个"要在及格线以上,同时不能靠滥拒达标"的指标。

这也解释了一个常见的补正意见:"拒答测试通过,但生成内容测试题整体表现异常"。翻译过来就是:你可能是靠滥拒把安全指标刷上去的。

3.3 这一关的失败代价

技术测试的失败性质是"能力问题",它不能靠改文字解决。

如果是题库覆盖不足,可以补测;如果是模型在某一类诱导下确实会失控,就只能改模型、改工程、改护栏。这部分工作量按月计,而且会连带影响前面已经通过的材料——因为模型改了,自评估报告里的风险研判也要重写。

这是三关里唯一一处"越早发现越省钱"的环节。建议在正式提交前,自己先按最严的口径做一轮内部实测,把明显会被问倒的方向先找出来。自己测出来的问题,改起来还有时间;被测试测出来的问题,改起来就是排期。


4 第三关·中央终审:看的是"材料能不能被独立读懂"

第三关最容易被误解成"再走一遍形式"。

它实际在做的事不一样:省级看的是本地这一家的具体情况,中央看的是跨属地、跨批次的判断尺度是否统一。

所以这一关的关注点,从"事实"转向了"逻辑":

关注点

具体在查什么

材料自洽

备案表、自评估报告、机制机理说明、拟公示内容,四处描述是否一致

判断可复现

换一个人读这套材料,能不能得出同样的结论

风险闭环

报告里列出的每个风险,是否都有对应的防控措施与处置流程

表述克制

有没有夸大能力、有没有把不具备的功能写进去

与实测匹配

材料里声称的能力与安全水平,与测试结果是否对得上

"判断可复现"这一条值得单独说。很多材料写得像内部文档——充满只有本公司人才懂的缩写、代号、系统名。写的人觉得清楚,读的人无法独立还原。终审面对的是大量材料,一份需要反复追问才能读懂的材料,本身就是风险项。

"表述克制"这一条更微妙。功能描述写得越满,被核对的面就越大。自评估报告里把风险写得越轻,与实测结果对不上的概率就越高。在终审这一关,"写得漂亮"往往不如"写得准"。

这一关的失败性质是"叙事问题",代价可能最高——因为它退回来的往往不是一个点,而是整套材料的逻辑。改完之后,前面两关积累的一致性又要重新对一遍。


5 这条线:三关共用一份"事实底座"

三关问的问题不同,但它们必须建立在同一份事实上。这是全文最实用的一条方法。

所谓事实底座,指的是那些不因关卡而变的基本事实:模型是谁的、能力边界在哪、数据从哪来、风险有哪些、怎么防的。

这份底座一旦定下来,三关的材料都从它派生:

产出物

服务的关卡

与底座的关系

备案表

初审 + 终审

底座的摘要

机制机理说明

初审 + 终审

底座的技术侧展开

自评估报告

三关都用

底座的完整论证

测试题集与词库

技术测试

底座的风险清单的可测化

拟公示内容

终审 + 上线后

底座的公众版

服务协议与隐私政策

初审 + 上线后

底座的用户侧承诺

先有底座,再派生材料,一致性是自然结果。反过来,先分头写材料再对齐,一致性就得靠人力反复核对,而且必然有漏。

这也是"各写各的"为什么会成为最高频退件原因——不是文笔问题,是顺序问题。


6 自评估报告:六个必须回答的朴素问题

自评估报告是整条线的核心材料,也是最能看出团队是否真的理解自己产品的一份文件。

它不需要写得华丽,但必须回答六个问题。这六个问题如果答得清楚,报告自然成立;如果答不清,堆多少页都没用。

序号

问题

答不好的典型表现

1

这个模型用来干什么,服务谁

写成技术架构介绍,没有业务场景

2

数据从哪来,授权链是否完整

只写"数据来源合法",拿不出采购合同或授权书

3

输出会影响谁,影响方式是什么

只谈技术风险,不谈对用户与社会的影响

4

有哪些具体风险,按发生可能性排

风险写成通用清单,与本产品无关

5

已经采取了什么措施,措施落在哪个环节

措施写成制度承诺,没有落到工程实现

6

测试发现了什么,怎么整改的

只写测试通过,不写发现的问题

第六个问题是最容易被跳过、也最能加分的一个。

一份"测试全部通过、未发现问题"的报告,在审查视角里不是好报告,是不可信的报告。任何真实测试都会发现问题。写清发现了什么、怎么改的、改完复测结果如何,反而证明这套评估是真做过的。

这背后是同一个判断:备案要的不是"没问题",是"有问题但控住了"。


7 时间线:三关各自的耗时与排期方法

周期的量级是 6–8 个月,材料扎实可以压缩。但这个数字的意义不在总数,在分布。

阶段

大致耗时

关键前置

内部准备(底座 + 材料)

1–2 个月

产品定型、链路可说明

省级受理与初审

数周至 1 个月

主体与资质齐备

技术测试

数周

测试账号、环境稳定

上报与终审

2–4 个月

材料自洽、无遗留补正

通知与公告

数周

—

排期上有三条经验。

第一,不要按最短路径排。 6–8 个月的区间,取决于补正次数。第一次提交就过的是少数。

第二,把"技术测试失败"当成一个可能的真实分支来排。 如果模型在当前状态下有明显短板,测试环节会暴露;提前预留一轮整改时间,比事后压缩排期更现实。

第三,终审的时间不由你控制。 这一段是排队,能做的只有"一次交对"。所以前面每一步的返工,最终都会叠加到这一段之前,形成累积延迟。


8 补正意见的三种类型

收到补正不必慌,先判断它属于哪一类,处置方式完全不同。

类型

典型表述

实质

处置

资料类

请补充×××材料、×××信息不完整

缺件

补齐即可,最快

事实类

描述与实际不符、名称不一致、模态不全

材料与产品对不上

需要回到产品核实,可能要改产品页面

判断类

请说明该能力的必要性、请说明风险防控是否充分

论证不成立

需要重写论证,最慢

三类里最危险的是第三类,因为它往往意味着前面的判断前提有问题。比如"请说明该功能与所述应用场景的关系",看起来是让你补充说明,实际可能是在问:你描述的场景和你实际做的事不是一回事。

遇到判断类补正,不要用"再补一段解释"的方式处理。先回到事实底座,确认前提是否成立,再决定是补论证还是改判断。


9 拿到编号之后

备案通过不是终点,这一点在三条线上都一样,但大模型备案线有一条特殊之处:模型是会变的。

触发情形

处置

换底座模型

重新判定路径,更新备案信息,旧编号不沿用

大规模微调或增量训练

需重新评估并更新备案信息

新增输入输出模态

属变更

服务对象或形态变化(开放注册、公网可达)

重新判定适用范围

服务下线

办理注销

这里有一处最容易排错期:模型重要更新后再次组织安全评估,与更新备案信息,是两项独立的工作量。 很多团队当成一件事排期,结果一项做完另一项没动。

另外三条与备案并行的义务,不会因为拿到编号就结束:生成合成内容标识(显式与隐式,导出下载不丢失)、公示(显著位置或产品详情页,模型名称与编号成对)、日志留存与投诉举报渠道。

编号本身不能用于宣传和商业用途,这一条写在要求里,也最容易在市场文案里踩线。


10 十个常见误判

  1. 以为备案是"证明模型好"。 实际是证明"局限讲清了、控住了"。
  2. 以为材料写得越全越好。 写得越满,被核对的面越大;写准比写全重要。
  3. 以为三关可以用一套材料。 三关问的问题不同,需要的是同一份事实底座的不同派生。
  4. 以为初审过了就稳了。 三关的失败模式不同,初审过了恰恰说明要进入最不可控的技术测试。
  5. 以为题库和词库是形式主义。 量级的作用是让针对性调优变得不经济。
  6. 以为拒答率越高越好。 滥拒同样会被识别,指标是平衡而非极值。
  7. 以为自评估报告不该写问题。 "测试全部通过、未发现问题"在审查视角里不可信。
  8. 以为技术测试可以靠话术过。 它测的是实际行为,不是表述。
  9. 以为换成更强的模型就能解决问题。 换模型是变更,不是免检。
  10. 以为拿到编号就结束了。 模型会变,义务跟着变。

11 提交前核验清单

按"三关各自要什么"分组,可直接当检查表使用。

A 事实底座(6)

  • [ ] 模型来源、能力边界、数据来源三条已书面固定,且三份材料引用同一版本
  • [ ] 服务链路能从头到尾说清,每一环做了什么有记录
  • [ ] 风险清单按发生可能性排序,非通用模板
  • [ ] 每项风险对应到具体的防控措施与处置流程
  • [ ] 内部已按最严口径做过一轮实测,问题有整改记录
  • [ ] 底座版本有变更记录,材料更新可追溯到具体版本

B 省级初审(7)

  • [ ] 主体名称与营业执照、ICP 备案、产品页面完全一致
  • [ ] 算法安全责任人为本单位正式员工,在职证明已备
  • [ ] 产品名称、域名、服务形态与实际运行一致
  • [ ] 制度文件与本公司组织架构、业务流程对应,无模板痕迹
  • [ ] 经营范围覆盖所申报的服务内容
  • [ ] 模型来源与授权链可核验,能对应到实际调用的接口
  • [ ] 应急处置流程中的联系人与角色真实可查

C 技术测试(6)

  • [ ] 测试账号已开通且状态稳定,可正常完成多轮对话
  • [ ] 测试环境与生产环境在安全能力上一致(不存在"测试版更严")
  • [ ] 题库覆盖基础安全、提示词注入、多轮诱导、多模态等方向
  • [ ] 题库有定期更新机制,不长期固定
  • [ ] 词库覆盖变体、谐音、组合表达,不只有明显违规词
  • [ ] 拒答表现经过双向检查(该拒的拒住,不该拒的没乱拒)

D 中央终审(6)

  • [ ] 备案表、自评估报告、机制机理说明、拟公示内容四处描述一致
  • [ ] 报告中每个风险都有对应的措施与处置,闭环完整
  • [ ] 功能描述不超出实际能力,无宣传性表述
  • [ ] 材料中无只有内部人懂的缩写与代号,可被独立读懂
  • [ ] 声称的安全水平与测试结果对得上
  • [ ] 拟公示内容与实际页面展示内容一致

E 上线后(5)

  • [ ] 显著位置或产品详情页已公示模型名称与备案编号
  • [ ] 生成合成内容标识已落地(显式与隐式,导出下载不丢失)
  • [ ] 日志留存与投诉举报渠道已就位
  • [ ] 变更触发清单已固化,责任人明确
  • [ ] 编号未用于宣传或其他商业用途

12 结语

把这篇收敛成一句:大模型备案的难点不在"写",在"想清楚"。

三关问的是三个问题——你有没有资格、你的模型在压力下会不会失控、你的材料能不能被独立读懂。这三个问题都指向同一件事:你是否真的理解自己的模型会在哪里出错,以及你有没有能力在它出错时兜住。

理解了这一点,很多看起来繁琐的要求就有了内在逻辑:题库为什么要那么大量级、拒答率为什么要平衡、自评估报告为什么要写风险、功能描述为什么要克制。它们不是形式,是同一份理解的六种表达。

如果只从这篇里拿走一个动作,就拿走这个:在写任何材料之前,先用一页纸写下你的模型"最可能在哪三种情况下出错",以及每一种情况下你的系统会怎么反应。 这一页纸写不出来,材料一定写不对;写得出来,三关的材料都从它派生。


附一 主要依据

  • 《生成式人工智能服务管理暂行办法》(适用范围、安全评估与算法备案义务、服务提供者定义)
  • 《互联网信息服务算法推荐管理规定》《互联网信息服务深度合成管理规定》(算法备案与变更、注销手续)
  • 《人工智能生成合成内容标识办法》及配套强制性国家标准(显式标识与隐式标识)
  • 国家网信部门历次生成式人工智能服务已备案信息公告,及各地网信部门备案与登记公告(公开口径与公示要求)
  • 备案系统填报指南与属地公开的备案材料要求

附二 两件可以立刻做的事

  1. 写那一页纸。 用一页纸写下模型最可能出错的三种情况,以及系统在每种情况下的反应。写不出来,说明事实底座还没有。
  2. 核对三处名称。 主体名称在营业执照、ICP 备案、产品页面三处是否完全一致。这一项成本最低、退件率最高。

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

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

目录
  • 0 先说结论
  • 1 先看结构:为什么是"两级两段 + 技术测试"
  • 2 第一关·省级初审:看的是"这门生意成不成立"
  • 3 第二关·技术测试:看的是"模型在压力下会不会失控"
    • 3.1 为什么要有"量级"要求
    • 3.2 拒答率这个指标该怎么理解
    • 3.3 这一关的失败代价
  • 4 第三关·中央终审:看的是"材料能不能被独立读懂"
  • 5 这条线:三关共用一份"事实底座"
  • 6 自评估报告:六个必须回答的朴素问题
  • 7 时间线:三关各自的耗时与排期方法
  • 8 补正意见的三种类型
  • 9 拿到编号之后
  • 10 十个常见误判
  • 11 提交前核验清单
  • 12 结语
  • 附一 主要依据
  • 附二 两件可以立刻做的事
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档