vivo探索游戏推荐“最后一公里”：大模型助力用户从“给结果”走向“帮决策”

排序精准用户仍难选择做游戏分发时有两类场景反复出现。一类是用户打开页面看到几款游戏排序虽把最可能被点的放前面但用户因几款游戏看着差不多而犹豫另一类是用户拿玩过的游戏当锚找相似的却需自己弄清楚差异。这两类用户都需先看懂游戏差异才愿尝试而排序不负责让用户看懂差异且优化排序的边际收益会随候选池变窄而减小。游戏决策成本比内容、短视频高可解释性和表达是游戏推荐决策的一部分。为何聚焦“游戏理解与表达”推荐系统擅长算“你大概率喜欢A”却不太能回答“A凭什么值得你喜欢”等问题。可解释性和表达因维护成本高、短期难拉指标优先级靠后。大模型的出现让补上“讲清楚”这一段有了落地做法而讲清游戏的前提是先理解它。已有标签体系为何再做一套游戏分发已有成熟的分类和标签体系但新体系需产出旧体系给不了的信息增量。旧体系擅长回答“这是什么”却回答不了“玩家为什么玩、为什么付费”。新体系要补的增量包括“游戏动机”和“付费机制”如捕鱼游戏新体系能给出“一款靠快节奏爽感和解压留人、用概率抽奖驱动付费的轻度游戏”这样的信息。确定要补的维度后先用大模型探索让多个模型从各种角度拆游戏但自由生成会使标签失控。于是分工明确探索交给模型收敛和立规矩由人来做挑出可解释、可比较、可复用、有决策价值的维度定成闭集schema再让模型填空。最后在API层加normalize兜底确保输出稳定。大模型对游戏的理解上限标签解决“是什么”而探索大模型对游戏底层逻辑“本质”的理解上限有个朴素标准让不了解游戏的人读完能清楚玩家在游戏里做什么、获得什么。以《逆水寒》为例按固定解读结构展开有极速判断卡还会逐层回答几个固定问题最后落一句决策句。这份解读是按预先设计的分区结构逼出来的理解深度取决于喂给它的结构。且从“模型能钻多深”到“用户用得上”还需人的取舍。多游对比从单次可行到稳定生产游戏标签和深度理解多针对单款游戏而用户常需对比多款游戏做决定。最初直接把几款游戏丢给模型讲差异结果够用但做成复杂系统后结果退化。教训是复杂化不一定进步要先锁死“必须产出什么”再让结构保证稳定产出且跨品类对齐。收敛出的“品类配置”包括core_dimensions、expression_schema、highlight_priority三部分喂给prompt驱动模型产出相关字段。目前已配出数十个品类的草案该pipeline让“该怎么比”变成可复用的配置表且不依赖推荐上下文。排序解决“推什么”对比解决“怎么选”。同一套理解的其他应用场景推荐解释传统推荐理由信息量少有了游戏理解推荐理由能落到用户真实体验上还能为排序侧排除游戏提供结构性理由目前只作为内部诊断字段具体应用还需探索。场景化引导同一款游戏在不同入口说法不同底层是同一套理解话术按场景调整部分表达场景正在接入前端后续会陆续上线。AI的边界做这套东西要遵循“事实来自数据表达来自模型”的原则模型负责理解、归纳等不凭空造事实、不替代排序推荐系统负责“推什么”AI补“怎么说清楚”这样便于出问题时定位。可复用的工程经验1. 探索和生产要区分使用模型的不同状态先发散探索再收敛执行。2. 模型的原始输出不算接口需闭集schema normalize保证稳定输出。3. prompt的结构决定理解的深度合理的结构能让模型输出更深入。4. 把“比什么”“怎么说”“谁上卡片”解耦分别约束避免跨品类偏差。5. 让能力不依赖上下文做成无状态插件实现跨场景复用。产品视角的变化AI让“系统结构”成为产品的一部分也压短了推荐表达层的链路让PM能将判断、结构和Demo串成可验证的系统路径。以前推荐系统分工明确AI进来后分工线变模糊需求路径也从“业务目标 → 功能设计 → 工程实现”变为“业务问题 → 能力探索 → 结构设计 → 原型验证 → 系统协同”复杂度前移。最终形成一层挂在排序之上、只读不回写的能力层。项目现状与进展项目从单人探索起步经评估正逐步进入正式生产。部分前端场景已开发、测试待上线部分在详设和迁移生产中。项目源于用户选游戏难的场景搭建了“游戏标签 → 单游戏深度理解 → 多游对比 → 推荐应用”的路径其价值还需落地后的数据验证但为推荐系统帮助用户做决策提供了可能。