960da7c8c4
四件均起草到「只差律所定稿+创始人提交」,尾附待律所确认清单合计 28 项;现行法规名不编造、不确定处标待核。A1闸门看板 #7-#10 转「材料就绪(草稿)」,人办清单①段同步。 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
14 KiB
合规材料 02 · 互联网信息服务算法备案材料
本材料是什么：绘境AI 平台就其"游戏流(feed)推荐排序"这项算法推荐服务,依《互联网信息服务算法推荐管理规定》向属地网信主管部门办理算法备案所需的申报材料草稿。对应 A1 闸门看板 #10「算法备案」。 起草状态：算法机制说明、数据处理说明、用户权益保障、安全自评框架已起草到位;主体信息为占位待填,算法分类归属与是否/何时触发备案的定性待律所确认(问题清单见文末)。 备案对象：平台游戏流的规则化排序重排算法——按每款游戏的运营质量分
quality_score等信号对已发布游戏做曝光排序。当前为"规则 + 信号"的非机器学习、非个性化排序,个性化推荐是增长期形态、尚未上线。这个"非个性化"事实是算法分类与义务范围的关键,是文末待确认的第一问。
〇、给创始人和律所的阅读提示
《互联网信息服务算法推荐管理规定》把算法推荐技术分为几类(生成合成、个性化推送、排序精选、检索过滤、调度决策)。绘境AI 的游戏流排序落在"排序精选"这一类,而且有一个对备案义务很关键的特征——它现在不做个性化:所有用户看到的排序,依据的是每款游戏的公共运营信号(播放、完玩、互动、举报、加载成功率等的聚合),不基于观看者个人身份特征做千人千面的推送。个性化推荐(基于用户画像)在平台规划里是"增长期"才上的形态(内部编号 T-FED-13),MVP 阶段没有上线。
这个区别之所以重要:算法备案与后续的用户权益义务(尤其"一键关闭个性化推荐"),很多是针对基于个人特征的个性化推送设定的。我方当前是非个性化的统一排序,义务范围可能因此不同。但"非个性化排序是否仍需备案、以及备案后哪些义务适用"要由律所结合备案系统口径确认——本材料据实说明现状(非个性化),不预设可以免备或免除某项义务。
材料引用的法规名称力求准确;算法分类的最终归属、备案系统的具体填报字段与办理流程以现行有效规定和律所意见为准,凡无法自证的流程细节标注"待律所确认"。
一、主体信息(待填)
同 合规-01 §一 的主体信息表,填一次复用。此处补充算法备案特有项:
| 字段 | 取值 |
|---|---|
| 算法安全责任人 | 【待填:通常为法定代表人或指定负责人】 |
| 算法备案填报联系人 | 【待填】 |
| 应用产品/服务名称 | 绘境AI 游戏流(feed) |
| 服务是否具有舆论属性或社会动员能力 | 【待律所判定——此项决定是否强制备案,见文末问 1】 |
二、算法基本情况
算法名称(申报口径)：绘境AI 游戏流质量分排序算法。
算法类型：排序精选类算法推荐(最终分类归属以备案系统口径与律所意见为准)。
应用场景：平台"游戏流"是一个竖屏、可上滑切换的游戏信息流,把平台上已发布并通过内容审核的轻量小游戏排成一条流推给用户即点即玩。算法的作用是决定这些游戏的曝光排序——让运营质量高、可玩性好、受欢迎的游戏更靠前,让技术上跑不动、被跳过、被举报的游戏沉底,同时给新创作者的作品保底曝光机会、保留运营人工精选的干预位。
技术定性(现阶段)：MVP 阶段的推荐是**"规则 + 信号"的确定性排序,不使用机器学习模型,不做基于用户画像的个性化推送**。同一时刻,不同用户看到的排序依据是相同的公共信号,不因观看者个人特征而异。个性化推荐算法(基于用户兴趣画像)是平台增长期的规划形态,当前未上线。
三、算法机制说明(算法基本原理、目的意图与运行机制)
这一节是备案要求"公示算法基本原理、目的意图与主要运行机制"的核心内容,也是本材料最实质的部分。
3.1 排序打分公式
每款进入候选的游戏,由一个打分公式算出排序分 Score,按 Score 降序决定其在游戏流中的曝光位置:
Score = w1·quality_score （综合质量分，正向）
+ w2·freshness （新鲜度，正向）
+ w3·interaction_rate （互动率，正向）
− w4·skip_rate （跳过率，负向）
− w5·error_rate （加载/运行错误率，负向·硬降权）
− w6·report_rate （举报率，负向）
+ bonus_new_creator （新创作者保底曝光）
+ bonus_featured （运营精选加权）
其中 w1…w6 为各信号权重,bonus_* 为调节项。这是一个透明、可解释、可复核的加权求和公式——每一款游戏为什么排在这个位置,都能拆解到上述具体信号,不存在黑箱。
3.2 各信号的定义与数据来源
所有信号均来自平台遥测(telemetry)对行为事件的聚合,按"游戏"为单位统计,不针对具体自然人做画像:
| 信号 | 含义 | 方向 | 来源 |
|---|---|---|---|
quality_score |
综合运营质量分(0–100),衡量"玩家玩得好不好、留不留得住",由遥测按播放数、完玩数、游玩时长、互动等行为聚合算出 | 正 · 核心输入 | telemetry 聚合计算 |
freshness |
新鲜度,给新发布的游戏一个曝光窗口,避免老内容长期霸榜 | 正 | 发布时间 |
interaction_rate |
互动率(点赞 / 收藏 / 分享占曝光的比例),玩家"用脚投票"的正反馈 | 正 | 互动事件聚合 |
skip_rate |
跳过率,刷到即划走的比例,反映吸引力不足 | 负 | 行为事件聚合 |
error_rate |
加载失败 / 运行异常率。这是公式中唯一的"硬降权"信号——技术上跑不动的游戏直接沉底,可玩性是底线 | 负 · 硬降权 | 运行时质量采集 |
report_rate |
举报率(举报数 / 曝光数)。除在排序上减分外,超过阈值还会额外触发人工审核(转交内容审核队列,见 合规-04) | 负 | 举报事件聚合 |
quality_score口径澄清(防误读)：平台内有两个同名不同义的质量分。此处备案对象是遥测/推荐侧的quality_score(0–100,运营质量,衡量玩家玩得好不好);另有一个生成侧的质量分(0–1,衡量模型把游戏生成得好不好)是生成质量门用的,与排序无关、二者不互相灌入。本材料只涉及前者。
3.3 两个调节项:生态公平与人工干预
排序不是纯粹的冷数据,还有两个调节项,体现平台的价值取向与运营责任:
bonus_new_creator(新人保底曝光)：给新创作者的作品一个保底加分,打破"零曝光 → 没数据 → 更没曝光"的冷启动死循环,让新作有被看见的机会,维护创作生态的公平。bonus_featured(运营精选加权)：运营在算法排序之上保留一个人工精选置顶的干预位,用于扶持优质内容、配合专区运营。这是人工可干预算法结果的显式入口,操作留台账、可追溯。
3.4 候选集与出流机制
- 候选集限定为已发布且通过内容审核的游戏——未过审、被下架、被硬剔除(
exposure_limit达剔除阈值)的游戏不进候选。 - 候选集按
Score排序缓存(采用带过期时间的有序集合,秒级过期后重算),通过游标(cursor)分页向用户无限流式下发,并做去重(同一游戏在一次浏览中不重复出现)。 - 内容安全处置直接作用于排序:违规内容可下架(移出流)或降权(调高
exposure_limit,Score自动下沉),处置由内容审核侧发起,详见 合规-04。
3.5 算法的目的意图(备案要求的"目的意图")
该算法的目的是:在保证可玩性底线(跑不动一票否决)的前提下,把运营质量高、受玩家欢迎的游戏排到更靠前,同时通过新人保底与运营精选维护创作生态的公平与内容导向。算法不以诱导用户过度使用、过度消费为目的,不设计使用户沉迷的机制;对未成年用户,叠加内容分级过滤与防沉迷限制(见 隐私政策与用户协议 未成年人专章)。
四、数据处理说明
| 项 | 说明 |
|---|---|
| 算法输入数据 | 按游戏聚合的行为统计信号(播放、完玩、时长、点赞/收藏/分享、跳过、加载错误、举报),以及游戏的发布时间、运营精选标记 |
| 是否使用个人画像 | 否(现阶段)。排序不基于观看者的个人身份特征、兴趣画像做差异化推送 |
| 未登录用户 | 行为以匿名标识(anon_id)聚合,不与真实身份绑定 |
| 个人信息最小化 | 排序算法本身消费的是聚合信号,不直接读取个人身份信息;个人行为事件的采集、存储、去标识化口径见 隐私政策 |
| 数据用于质量改进 | 玩家行为数据回流用于计算 quality_score、优化推荐与改进生成质量,该授权在 用户协议与隐私政策 中取得 |
五、算法用户权益保障
《互联网信息服务算法推荐管理规定》要求算法推荐服务提供者保障用户的知情权、选择权等权益。对照落实如下(部分口径待律所确认):
| 权益 | 落实说明 |
|---|---|
| 知情权(算法透明) | 本材料第三节即为算法基本原理、目的意图与运行机制的公示底稿,可在平台以适当方式向用户说明 |
| 关闭个性化推荐 | 法定要求需向用户提供关闭针对其个人特征的推荐选项。现阶段平台推荐为非个性化统一排序,不基于个人特征差异化推送,故不存在需要关闭的个性化处理;仍按法定要求预留该项的产品口径。"非个性化是否即已满足该义务、还是仍须显式提供关闭入口",待律所确认(问 2) |
| 不利标签/画像 | 不设置违反法律或公序良俗的用户标签;现阶段不做用户画像 |
| 举报与投诉 | 平台内提供举报入口(举报转内容审核人工队列);对外投诉受理渠道待建(占位) |
| 未成年人保护 | 识别未成年用户后叠加内容分级过滤与防沉迷限制,不向未成年人推送不适龄内容;详见 隐私政策与用户协议 |
| 老年人等群体 | 不适用/待评估(平台面向轻量小游戏创作,暂无适老化专项要求,待律所确认) |
六、算法安全自评估框架
算法备案通常要求随附算法安全自评估。以下为按平台实际情况整理的自查框架,作为正式自评估报告的底稿;正式报告模板与深度以属地网信办要求为准(待律所确认)。
| 自评维度 | 现状与说明 |
|---|---|
| 算法机制机理安全 | 打分公式透明可解释、可复核;无诱导沉迷/过度消费的机制设计 |
| 数据安全 | 输入为按游戏聚合的行为信号;个人数据处理遵循 隐私政策 与最小必要原则 |
| 内容导向安全 | 候选集限已过审内容;违规内容下架/降权;举报率超阈值转人审 |
| 防沉迷 | 算法不以沉迷为目的;未成年人叠加防沉迷与分级过滤 |
| 人工干预与可追溯 | 运营精选、降权、下架均由人工发起、留台账、可回溯 |
| 公平性 | 新人保底曝光,防止冷启动死循环;无歧视性标签 |
| 应急与处置 | 可对违规内容即时下架/降权,配合主管部门处置(具体报送流程待确认) |
| 记录留存 | 排序信号与处置记录留存(留存期限口径待律所确认,见 合规-04) |
七、待律所确认问题清单(共 6 项)
- 是否强制备案 / 分类归属：非个性化的"规则+信号"排序精选算法,是否属于须备案的"具有舆论属性或社会动员能力的算法推荐服务"?算法类型归"排序精选类"是否准确?游戏流这一场景是否被认定具有舆论属性?
- "关闭个性化推荐"义务：现阶段推荐为非个性化统一排序,是否已满足"提供关闭个性化推荐选项"的义务?还是仍须在产品上显式提供一个关闭入口(即便当前无个性化)?待增长期上线个性化(T-FED-13)时的备案变更义务如何?
- 内测是否触发 / 触发时点：邀请制内测阶段是否已触发算法备案义务?还是可推迟到公开经营/达到一定用户规模时点?触发的边界是什么?
- 备案与登记的关系：本项算法备案与 合规-01 生成式 AI 服务登记 是否需同窗、按何先后办理?"游戏生成"用到的第三方大模型属"生成合成类"算法,是否需就生成侧另做算法备案(还是并入生成式 AI 服务登记)?
- 办理路径：本项备案的属地主管部门、互联网信息服务算法备案系统的填报要点、办理周期与材料清单。
- 自评估报告：算法安全自评估报告是否有强制模板、深度要求,能否由第六节框架升格为正式报告?是否需第三方评估?
附:关联材料
- 合规-01 大模型登记材料——生成侧,与本项同窗办理
- 合规-03 隐私政策与用户协议——数据授权与用户权益条款
- 合规-04 内容合规材料——举报召回与内容处置的实现
- 律所合规咨询 brief——问 4(算法备案适用性)
- 运营域 · 合规闸门——本项在 12+1 道闸门中的位置