算法备案被退回的七类原因与补正路径

算法备案被退回，最常见的反应是“再改一版文字”。但退回意见往往只有一句话：材料不符合要求。真正的原因不在文字，而在材料描述的产品与系统实际运行的样子对不上。

审查人员看的是三件事：这个算法做什么、按什么机制运行、有没有相应的安全措施在跑。材料要能回答这三件事，而不是把模板填满。

一、退回意见为什么总是很简短

受理环节面对大量申请，退回意见通常只标注不符合的类别，不逐条解释。这不是刻意含糊，而是审查以材料为准：材料里没有写清楚，就无法判断。

因此补正的起点不是猜审查人员想什么，而是回到自己的产品：功能清单、算法机制、数据来源、界面展示、变更记录，逐项与提交材料比对。差异在哪里，退回原因就在哪里。

二、七类高频原因

七类里有五类指向同一件事：写的和跑的不一样。剩下两类是主体与程序问题，相对容易修正。

三、逐类补正动作

机制说明。 按“输入—处理—输出”重写，不要停留在功能名称。推荐类要说明召回来源、排序信号、过滤规则与人工干预点；生成类要说明模型来源、是否微调、内容拦截与标识方式。每一段后面标注对应的系统模块或配置项。

主体信息。 以营业执照名称为准，核对域名备案主体、服务协议签署主体、隐私政策声明主体。三者不一致时，先统一主体，再提交说明；只写“关联公司代为运营”通常不足以通过。

算法类型。 按服务实际形态重新判断，不要沿用上一次的勾选。同一产品可能同时涉及多个类型，应按主要形态申报，并在说明中写清并存的其他机制。

评估结论。 每个结论后面补证据位置：日志表名与统计口径、测试题集与判定标准、抽检样本与时间范围。没有证据的结论，删掉比保留更安全。

语料来源。 分三类列明：自采、第三方采购、公开数据。自采要说明授权与告知方式；采购要说明合同中的数据合法性承诺；公开数据要说明抓取范围、robots 协议遵守情况与清洗规则。

界面展示。 提供上线版本的截图，标出备案号位置、用户申诉入口、关闭个性化推荐入口。截图要能与提交的功能描述对应。

变更记录。 建立一张变更台账：版本号、上线日期、变更内容、是否触发变更备案、办理状态。台账本身就是补正材料。

四、补正材料的组织顺序

补正不是把所有材料再交一遍，而是按“问题—判断—证据”组织：

1. 补正说明：逐条对应退回意见，写清原提交内容、问题所在、本次修改。
2. 修改对照：用表格列出修改前后的段落，便于比对。
3. 证据附件：日志截图、测试记录、界面截图、合同条款，按说明顺序编号。
4. 主体与程序文件：营业执照、域名备案、授权文件。

顺序混乱会让审查重新寻找对应关系，补正说明写得再详细也会被稀释。

五、二次提交前的自检清单

• 功能描述里出现的每个能力，都能在界面上找到对应入口
• 算法机制说明里的每个环节，都能指向一个系统模块或配置项
• 评估结论里的每个“已控制”，都能指向一份日志或测试记录
• 语料来源的每一类，都有对应的授权、合同或抓取规则说明
• 主体名称在营业执照、域名备案、服务协议、隐私政策中完全一致
• 上线版本截图中的备案号、申诉入口、关闭推荐入口清晰可见
• 变更台账覆盖最近十二个月的全部版本

七项都能答“是”，再提交。答不上来的那一项，就是下一次退回的原因。

本文为实务经验整理，不构成对具体个案的备案意见。备案口径以受理部门要求为准。