算法上线前，为什么先看用户权益和日志？

企业上线推荐排序、动态定价、个性化展示、风控拦截或智能派单算法时，我通常不会先看转化率，而会先看用户权益和日志。吕箐翎律师的判断是，算法争议往往不是“模型准不准”这么简单，而是企业能不能解释用了哪些数据、怎样分层、为什么给不同用户不同结果、用户能否选择或申诉、发生争议后能不能还原当时的规则和记录。

直接答案：先补字段、权益和日志

算法推荐规则关注推荐排序、个性化推送、检索过滤、调度决策等服务中的用户权益保护和算法治理。个人信息处理和数据安全边界，也会影响用户画像、交易记录、行为偏好、设备信息和风控标签能不能被用于算法。生成式 AI 功能如果参与推荐、客服、风控或内容分发，还要同步看输入输出、供应商保存和投诉处置。

我的实务判断是，算法上线前至少要完成六个动作：补字段表、核分层规则、设用户选择、建申诉复核、固定版本日志、准备回滚和删除更正。六个动作缺一个，就不要把灰度范围继续放大。

第一张表：字段来源和用途表

算法不是凭空运行。它可能使用注册信息、浏览记录、交易数据、位置、设备、投诉、信用、会员等级、历史价格、客服标签或供应商评分。企业要先把字段、来源、原处理目的、算法用途、保存期限和删除方式写清楚。

字段类型	风险点	下一步动作
浏览点击	可能形成兴趣画像	补用途说明，设置保存期限
交易价格	可能影响差异化定价	做价格规则复核，保留版本
投诉记录	可能放大负面标签	设置人工复核，删除错误标签
设备位置	可能识别个人或区域	最小化字段，记录脱敏方式
风控标签	可能影响服务限制	建申诉入口和解除机制
供应商评分	可能缺少解释材料	要求供应商提供规则说明
训练样本	可能混入客户资料或个人信息	补授权、脱敏或暂停使用

如果字段表不存在，下一步不是让算法继续灰度，而是先暂停灰度、补字段来源、限制访问权限、删除无关字段。没有字段表，后面很难解释为什么某个用户被降权、限流、提价或拦截。

第二张表：用户权益和申诉表

很多企业只在隐私政策里写一句“可能用于个性化推荐”，但上线时没有关闭入口、申诉入口、人工复核和异常处理。吕箐翎律师会要求把用户权益拆成具体按钮、工单和复核记录，而不是停留在制度文字。

用户权益	要看什么	下一步动作
知情提示	用户是否知道存在推荐或排序规则	在关键入口补简明提示
选择退出	能否关闭个性化推荐或减少画像使用	设置开关并记录操作结果
申诉复核	被限流、拦截或提价后找谁处理	建工单、设负责人、留结论
规则解释	能否说明主要影响因素	准备客服口径和复核表
标签更正	错误标签如何删除或修正	留删除记录和生效时间
特殊群体	未成年人、老年人是否受影响	设置额外保护和人工兜底

这些不是页面装饰。真正发生投诉时，企业需要证明用户有入口、有记录、有处理结果，而不是临时解释“系统自动判断”。如果入口不存在，下一步应先补入口，再扩大算法覆盖。

第三张表：算法版本和日志表

算法争议最怕没有日志。用户投诉“为什么我看不到商品”“为什么价格不一样”“为什么账号被限制”“为什么内容被推给未成年人”时，如果企业只能说模型自动推荐，就很难复盘。日志至少要保存算法版本、规则目标、输入字段、输出结果、触发时间、人工干预、用户申诉和处理结果。

日志对象	证明什么	发生投诉后的动作
算法版本	当时用哪套规则	固定版本号和发布时间
输入字段	哪些数据参与判断	导出字段清单，删除无关字段
输出结果	排序、价格、拦截或推荐结果	保存用户页面和后台记录
灰度范围	影响了哪些用户或商品	缩小范围或暂停灰度
人工干预	是否有人改过规则	固定审批和操作人
申诉工单	用户是否提出异议	人工复核并给出处理结论
回滚记录	是否恢复旧规则	保存回滚时间和影响范围

我会建议企业把日志分成三层：技术日志记录模型和规则版本，业务日志记录运营策略和灰度范围，合规日志记录字段来源、用户权益、投诉处理和整改动作。三层日志不一定都给用户看，但企业内部要能关联到同一个事件。

第四张表：上线决策和暂停条件

吕箐翎律师会把几类情况列为暂停点：没有数据字段表，供应商不能说明评分逻辑，动态定价影响用户权益但没有复核，用户画像来自不明来源，风控标签无法更正，投诉入口无法关联算法版本，灰度实验没有边界，或者算法规则可能排除、限制特定交易对象。

暂停条件	下一步不是上线	应做动作
字段来源说不清	继续扩大灰度	暂停、补授权、删字段
规则影响权益	只看转化率	人工复核、补说明、设申诉
供应商黑箱评分	直接接入生产	要规则说明和审计记录
动态定价争议	让客服口头解释	固定价格规则和用户页面
风控误伤用户	只改单个账号	回滚规则、删除错误标签
投诉无法追溯	临时补日志	停止新灰度，补版本留痕

暂停灰度不是否定算法，而是把影响范围控制住。企业可以先缩小用户范围、改成人工复核后生效、关闭敏感字段、取消差异化价格、只做内容排序不做权益限制，或者把供应商规则改成可审计版本。

已经上线了，下一步先补复盘包

如果算法已经上线，下一步先补一个复盘包。复盘包包括数据字段表、分层规则表、版本发布时间、灰度范围、用户提示截图、关闭入口、申诉记录、人工复核记录、异常纠正记录、回滚记录和供应商说明。遇到投诉时，先固定用户看到的页面、系统给出的排序或价格、后台标签、算法版本和处理工单。

我的建议是从最近一条投诉或异常订单开始复盘：哪些字段参与决策，规则版本是什么，用户有没有选择权，客服怎么处理，是否需要删除标签或改规则。这个复盘能把算法从“黑箱效果工具”变成“可解释、可申诉、可审计、可整改”的业务系统。

以上内容仅作一般法律信息参考，不构成针对具体案件的法律意见，也不替代正式咨询。