声明:本文基于公开发布的法规文本、备案系统填报口径与公开的属地实践信息整理,不含任何产品推广,也不构成法律意见。涉及具体项目的判断,请以属地网信部门答复为准。
大多数团队准备大模型备案的方式是错的。
他们把备案理解成"交一套材料",于是把所有精力放在把材料写全、写漂亮上。结果材料交上去,省级这一关过了,技术测试卡住;或者技术测试过了,中央终审退回,理由是"材料前后对不上"。
问题不在材料质量,在方法。大模型备案不是一个审查动作,是三个,而且三关问的是三个不同的问题:
关卡 | 它在问什么 | 失败的性质 | 代价 |
|---|---|---|---|
省级初审 | 你有没有资格提供这项服务 | 资格问题 | 可补正,通常几周 |
技术测试 | 你的模型在压力下会不会失控 | 能力问题 | 要改模型或改工程,按月计 |
中央终审 | 你的材料能不能被独立读懂并对上 | 叙事问题 | 要重写材料逻辑,可能推翻前面全部 |
这三关的失败模式完全不同,处置方式也完全不同。用一套材料、一种写法应对三关,是最常见也最贵的方法论错误。
还有一句更重要的判断,放在开头:大模型备案的实质,不是"证明你的模型很好",而是"把模型的局限讲清楚,并证明你控制住了这些局限"。
这个判断听起来反直觉,但它解释了很多看起来奇怪的要求——为什么要交拦截词库、为什么要测拒答率、为什么自评估报告必须写风险而不是写优势。因为审查关心的从来不是你的模型有多强,而是它在什么情况下会出错、出错时你有没有兜住。
理解审查动作之前,先理解它的组织形态。
大模型备案的审查结构,与其他两条线明显不同:
维度 | 算法备案 | 大模型备案 | 大模型登记 |
|---|---|---|---|
受理层级 | 线上系统 | 属地省级网信办 | 属地省级网信办 |
审核层级 | 单一 | 省级初审 + 中央终审 | 单级 |
是否含技术实测 | 形式审查为主 | 含对抗性技术实测 | 一般不含 |
周期量级 | 1–3 个月 | 6–8 个月(材料扎实可压缩) | 1–3 个月 |
这个结构不是流程设计上的偏好,它对应三个现实约束。
第一,模型是具有通用能力的系统,无法靠纸面判断。 一段代码可以读,一个推荐策略可以算,但一个生成式模型的行为只能测。所以必须有一段实测环节。
第二,实测需要本地化的场景与语料。 属地省级网信部门更了解本地产业形态、本地监管重点,也更方便组织现场核查与测试对接。所以第一道关在省里。
第三,跨属地必须可比。 如果各省口径不一,同样的模型在甲省过、乙省不过,整个制度就失去意义。所以终审在中央,用统一尺度做最后一道判断。
理解了这三点,就能理解后面所有材料要求为什么长那个样子——它们不是表格,是为这三道关各自准备的证据。
省级这一关,表面看是在审材料,实际是在回答一个更基础的问题:你有没有资格、有没有能力,稳定地对外提供这项服务。
它关心的东西,可以归成四组。
组别 | 核验内容 | 常见问题 |
|---|---|---|
主体 | 营业执照、经营范围、法人信息、算法安全责任人 | 主体与实际运营不一致;责任人非本单位正式员工 |
产品 | 产品名称、域名、ICP 备案、服务形态、上线状态 | 产品名称与 ICP 不一致;服务形态描述与实际不符 |
链路 | 模型来源、调用关系、数据流向、部署方式 | 链路说明停留在"调用了大模型能力"这一层 |
制度 | 安全管理制度、应急预案、主体责任落实文件 | 直接套用模板,与公司实际组织架构对不上 |
四组里,前三组是事实核验,第四组是能力判断。
事实核验这部分的规律很好掌握:凡是能在外部系统里查到的,就不能含糊。 主体名称在工商系统里能查,域名 ICP 在工信部系统里能查,产品能不能打开、页面写了什么,审核人员点一下就知道。这一组出错,通常不是不会写,是资料没有对齐。
第四组更容易被低估。制度文件的审查重点不是"有没有",而是"是不是这家公司的"。模板痕迹明显的文件会引来追问:这个应急流程里写的联系人是谁?这个分级处置标准对应你们哪条业务线?答不上来,材料就会被退。
这一关的失败性质是"资格问题",所以它是可补正的。 补正周期通常以周计。这意味着:初审被退回不是灾难,但也别指望在这里省时间——因为补正一次就重排一次。
这是三关里最不透明、也最容易低估的一关。
它的形态是:提交若干个已实名认证的测试账号,由技术侧围绕一组测试集对服务进行实测。测试的覆盖面通常包括基础安全、提示词注入、多模态输入、多轮诱导等方向。
这一关与初审的根本区别在于:初审看你写的东西,测试看你实际跑出来的东西。 你可以在材料里把安全能力写得很好,但测试会直接问模型一些它不一定会好好回答的问题。
实践中最被诟病、也最容易被当成形式主义的,是题库与词库的量级要求——测试题集要达到一定题量,拦截关键词库要达到一定词数,部分地区要求更高。
很多团队的第一反应是:"凑数就行了。"
这个理解是错的。量级要求的意义不在数字本身,在于它排除了"抽查式合规"。
一个只有几十条题目的测试集,可以被针对性调优——你知道会考什么,就能提前把答案准备好。但一个上千条、覆盖多个风险方向、且要求定期更新的题库,针对性调优的成本会急剧上升。量级在这里的作用,是让"应付"这件事变得不经济。
同理,拦截词库的量级要求,排除的是"只拦几个最敏感的词"这种做法。词库要覆盖的不只是明显违规词,还包括变体、谐音、组合表达、跨语言表达。
拒答率是技术测试里最常被提到的量化指标,量级要求通常在较高水平(实践口径常见为 95% 以上)。
这个指标容易被误读成"要尽量多拒答"。实际上它测的是两件事的平衡:
只追求前者的模型,会把大量正常问题也拒掉,用户体验崩塌;只追求后者的模型,会在敏感问题上放行。所以拒答率不是一个"越高越好"的指标,是一个"要在及格线以上,同时不能靠滥拒达标"的指标。
这也解释了一个常见的补正意见:"拒答测试通过,但生成内容测试题整体表现异常"。翻译过来就是:你可能是靠滥拒把安全指标刷上去的。
技术测试的失败性质是"能力问题",它不能靠改文字解决。
如果是题库覆盖不足,可以补测;如果是模型在某一类诱导下确实会失控,就只能改模型、改工程、改护栏。这部分工作量按月计,而且会连带影响前面已经通过的材料——因为模型改了,自评估报告里的风险研判也要重写。
这是三关里唯一一处"越早发现越省钱"的环节。建议在正式提交前,自己先按最严的口径做一轮内部实测,把明显会被问倒的方向先找出来。自己测出来的问题,改起来还有时间;被测试测出来的问题,改起来就是排期。
第三关最容易被误解成"再走一遍形式"。
它实际在做的事不一样:省级看的是本地这一家的具体情况,中央看的是跨属地、跨批次的判断尺度是否统一。
所以这一关的关注点,从"事实"转向了"逻辑":
关注点 | 具体在查什么 |
|---|---|
材料自洽 | 备案表、自评估报告、机制机理说明、拟公示内容,四处描述是否一致 |
判断可复现 | 换一个人读这套材料,能不能得出同样的结论 |
风险闭环 | 报告里列出的每个风险,是否都有对应的防控措施与处置流程 |
表述克制 | 有没有夸大能力、有没有把不具备的功能写进去 |
与实测匹配 | 材料里声称的能力与安全水平,与测试结果是否对得上 |
"判断可复现"这一条值得单独说。很多材料写得像内部文档——充满只有本公司人才懂的缩写、代号、系统名。写的人觉得清楚,读的人无法独立还原。终审面对的是大量材料,一份需要反复追问才能读懂的材料,本身就是风险项。
"表述克制"这一条更微妙。功能描述写得越满,被核对的面就越大。自评估报告里把风险写得越轻,与实测结果对不上的概率就越高。在终审这一关,"写得漂亮"往往不如"写得准"。
这一关的失败性质是"叙事问题",代价可能最高——因为它退回来的往往不是一个点,而是整套材料的逻辑。改完之后,前面两关积累的一致性又要重新对一遍。
三关问的问题不同,但它们必须建立在同一份事实上。这是全文最实用的一条方法。
所谓事实底座,指的是那些不因关卡而变的基本事实:模型是谁的、能力边界在哪、数据从哪来、风险有哪些、怎么防的。
这份底座一旦定下来,三关的材料都从它派生:
产出物 | 服务的关卡 | 与底座的关系 |
|---|---|---|
备案表 | 初审 + 终审 | 底座的摘要 |
机制机理说明 | 初审 + 终审 | 底座的技术侧展开 |
自评估报告 | 三关都用 | 底座的完整论证 |
测试题集与词库 | 技术测试 | 底座的风险清单的可测化 |
拟公示内容 | 终审 + 上线后 | 底座的公众版 |
服务协议与隐私政策 | 初审 + 上线后 | 底座的用户侧承诺 |
先有底座,再派生材料,一致性是自然结果。反过来,先分头写材料再对齐,一致性就得靠人力反复核对,而且必然有漏。
这也是"各写各的"为什么会成为最高频退件原因——不是文笔问题,是顺序问题。
自评估报告是整条线的核心材料,也是最能看出团队是否真的理解自己产品的一份文件。
它不需要写得华丽,但必须回答六个问题。这六个问题如果答得清楚,报告自然成立;如果答不清,堆多少页都没用。
序号 | 问题 | 答不好的典型表现 |
|---|---|---|
1 | 这个模型用来干什么,服务谁 | 写成技术架构介绍,没有业务场景 |
2 | 数据从哪来,授权链是否完整 | 只写"数据来源合法",拿不出采购合同或授权书 |
3 | 输出会影响谁,影响方式是什么 | 只谈技术风险,不谈对用户与社会的影响 |
4 | 有哪些具体风险,按发生可能性排 | 风险写成通用清单,与本产品无关 |
5 | 已经采取了什么措施,措施落在哪个环节 | 措施写成制度承诺,没有落到工程实现 |
6 | 测试发现了什么,怎么整改的 | 只写测试通过,不写发现的问题 |
第六个问题是最容易被跳过、也最能加分的一个。
一份"测试全部通过、未发现问题"的报告,在审查视角里不是好报告,是不可信的报告。任何真实测试都会发现问题。写清发现了什么、怎么改的、改完复测结果如何,反而证明这套评估是真做过的。
这背后是同一个判断:备案要的不是"没问题",是"有问题但控住了"。
周期的量级是 6–8 个月,材料扎实可以压缩。但这个数字的意义不在总数,在分布。
阶段 | 大致耗时 | 关键前置 |
|---|---|---|
内部准备(底座 + 材料) | 1–2 个月 | 产品定型、链路可说明 |
省级受理与初审 | 数周至 1 个月 | 主体与资质齐备 |
技术测试 | 数周 | 测试账号、环境稳定 |
上报与终审 | 2–4 个月 | 材料自洽、无遗留补正 |
通知与公告 | 数周 | — |
排期上有三条经验。
第一,不要按最短路径排。 6–8 个月的区间,取决于补正次数。第一次提交就过的是少数。
第二,把"技术测试失败"当成一个可能的真实分支来排。 如果模型在当前状态下有明显短板,测试环节会暴露;提前预留一轮整改时间,比事后压缩排期更现实。
第三,终审的时间不由你控制。 这一段是排队,能做的只有"一次交对"。所以前面每一步的返工,最终都会叠加到这一段之前,形成累积延迟。
收到补正不必慌,先判断它属于哪一类,处置方式完全不同。
类型 | 典型表述 | 实质 | 处置 |
|---|---|---|---|
资料类 | 请补充×××材料、×××信息不完整 | 缺件 | 补齐即可,最快 |
事实类 | 描述与实际不符、名称不一致、模态不全 | 材料与产品对不上 | 需要回到产品核实,可能要改产品页面 |
判断类 | 请说明该能力的必要性、请说明风险防控是否充分 | 论证不成立 | 需要重写论证,最慢 |
三类里最危险的是第三类,因为它往往意味着前面的判断前提有问题。比如"请说明该功能与所述应用场景的关系",看起来是让你补充说明,实际可能是在问:你描述的场景和你实际做的事不是一回事。
遇到判断类补正,不要用"再补一段解释"的方式处理。先回到事实底座,确认前提是否成立,再决定是补论证还是改判断。
备案通过不是终点,这一点在三条线上都一样,但大模型备案线有一条特殊之处:模型是会变的。
触发情形 | 处置 |
|---|---|
换底座模型 | 重新判定路径,更新备案信息,旧编号不沿用 |
大规模微调或增量训练 | 需重新评估并更新备案信息 |
新增输入输出模态 | 属变更 |
服务对象或形态变化(开放注册、公网可达) | 重新判定适用范围 |
服务下线 | 办理注销 |
这里有一处最容易排错期:模型重要更新后再次组织安全评估,与更新备案信息,是两项独立的工作量。 很多团队当成一件事排期,结果一项做完另一项没动。
另外三条与备案并行的义务,不会因为拿到编号就结束:生成合成内容标识(显式与隐式,导出下载不丢失)、公示(显著位置或产品详情页,模型名称与编号成对)、日志留存与投诉举报渠道。
编号本身不能用于宣传和商业用途,这一条写在要求里,也最容易在市场文案里踩线。
按"三关各自要什么"分组,可直接当检查表使用。
A 事实底座(6)
B 省级初审(7)
C 技术测试(6)
D 中央终审(6)
E 上线后(5)
把这篇收敛成一句:大模型备案的难点不在"写",在"想清楚"。
三关问的是三个问题——你有没有资格、你的模型在压力下会不会失控、你的材料能不能被独立读懂。这三个问题都指向同一件事:你是否真的理解自己的模型会在哪里出错,以及你有没有能力在它出错时兜住。
理解了这一点,很多看起来繁琐的要求就有了内在逻辑:题库为什么要那么大量级、拒答率为什么要平衡、自评估报告为什么要写风险、功能描述为什么要克制。它们不是形式,是同一份理解的六种表达。
如果只从这篇里拿走一个动作,就拿走这个:在写任何材料之前,先用一页纸写下你的模型"最可能在哪三种情况下出错",以及每一种情况下你的系统会怎么反应。 这一页纸写不出来,材料一定写不对;写得出来,三关的材料都从它派生。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。