试想一下线上系统每天刷新几千万条用户行为日志点击、收藏、停留时长、购买全在里面堆着。传统做法是清洗后算特征喂给排序模型。可到了大语言模型时代这些结构化的、散落的数值字段反而成了障碍——模型读不懂“uid1024, itemSKU778, typeclick, ts171000120”到底意味着什么。这个标题所讲的核心就是一口把日志“翻译”成人话再做语言学习式的最优表述让大模型在推荐场景里真正用起来还能扛住生产环境的压力和成本。我最近在一套面向新用户的内容推荐服务里完整跑过这个链路从日志清洗、表述模板设计、微调到灰度上线都过了几轮踩了不少坑也沉淀了一些可复用的方法下面逐一拆开讲。1. 整体设计为什么要把日志“转译”成语言再做推荐先说一个很直接的问题既然大模型这么强直接把用户历史行为按“user_id item_id”喂进去不行吗我试过效果很差。原因是纯ID序列对模型来说是一堆无意义的符号它没法把“昨天点击过三次数码类文章”和“今天推荐手机评测”这两件事联系起来。要让语言模型发挥语义理解的优势必须把行为日志映射成自然语言描述让模型读到的是有逻辑有意图的事件流而不是一串稠密且单调的键值对。这个思路的核心可以用一句话概括把日志当作原料把语言当作中间表达让模型在语言层完成推荐推理。听起来不复杂但放到生产环境里就有很多细小的分岔需要做取舍。1.1 从行为日志到模型输入中间需要一个表述层大多人第一次接触LLM推荐容易直接跳到“把你的prompt写得花团锦簇”这一步结果效果不稳定。真实链路里第一步不是prompt而是日志的语义化。我这边把整条推荐链路拆成四段原始日志接入、日志清洗与场景切分、表述生成、模型推理与后处理。其中表述生成这部分是很多人会忽略但其实最值得投入的地方。它的本质是在原始日志之上抽象出一个“用户故事”用户在什么时间对什么内容做了什么动作动作背后大概是什么偏好形成一个或几个句子。这里有一个关键设计原则表述的粒度要和推荐决策的粒度对齐。比如推荐目标是“下一件要看的文章”那么一条日志里最关键的就不是历史订单而是近期的阅读序列和点击密度。如果推荐目标是“购物车加购”那表述重心就要放在商品类目偏好和价格带上。日志结构是通用的但表述模板必须跟着业务目标走。从实现上看日志转语言的流程大致是日志接入后先按会话session聚合而不是按天硬切。提取关键事件保留行为顺序去掉冗余字段。字段数值映射成语义标签比如停留时长从“120秒”转成“长时间阅读”。填充到预定义的句子里生成一条能直接喂给模型的事件描述。这步做好后面模型的稳定性会质变。我见过有人在这一步偷懒直接用现成日志字段拼话术结果线上推荐经常出现“用户都没看过的内容被当成强偏好”原因就是表述层把偶然点击和真实兴趣混在一起了。1.2 为什么选“语言化”而不是向量召回或序列模型在方案选型的时候同步也考虑了两条更常规的路一条是用户行为序列直接接双塔模型做向量召回另一条是用户日志聚合成特征后进排序模型。这两条路成熟稳定资源开销也小。但它们在内容理解上有个上限整个系统很难感知到“这篇技术文章跟用户刚看过的源码解析是同主题但不同难度层级”这层关系。语言模型的优势在于它把文本里的语义关联直接当作知识来用。用户对五篇包含“后端”“数据库”关键词的文章产生过行为不需要经过一层Embedding训练模型天然就知道下一条推荐可以考虑缓存中间件相关的内容。这类能力天然适合内容型推荐尤其适合新用户冷启动——后台没有足够的交互数据做协同过滤时语言描述本身就能承担“特征”的角色。当然我不建议把所有场景都改成LLM推荐。成本在那里摆着一套线上服务每天处理上千万次请求纯语言化推理的开销远高于双塔模型。比较合理的架构是双塔负责第一阶段的粗召回LLM负责对候选集合做细排序和解释生成。日志语言化在这个架构里充当主链条上的“翻译官”把小规模的候选集转成可推理的语义文本。我最终选型时确定了这样的部署方式日志解析服务独立成一个表述生成不单独占一个模型而是靠模板加规则去生成节省调用量大模型只做候选打分排序。这样算下来每天500万次推荐请求纯增量的大模型推理量控制在50万次左右成本基本可控。2. 核心细节解析最优表述的构建原则与实现方法标题里的“Optimal Verbalization”翻成中文就是最优表述这个词值得琢磨。并不是任何自然语言句子都能让模型给出好结果表述的好坏直接决定推荐的准确性。我刚开始做实验的时候用同样一份日志只是调整了表述句子的顺序和用词NDCG10能从0.31跳到0.44变化非常吓人。2.1 日志清洗与事件语义化的几个关键操作日志清洗是最不性感但最影响结果的一步。几个我反复踩的点列出来时区不统一。线上服务会跨多机房部署用户日志如果用本地时间记录聚合时可能出现时间倒挂。我在清洗层统一把时间全部转成UTC毫秒时间戳并在会话划分前固定好时区。过滤机器行为。有些刷量点击和异常高频请求会混进日志如果直接进表述层模型会把异常行为学成正常偏好。我是按IP维度和设备维度做频率统计超过95分位的高频访问直接剔除。事件去重。用户在同一个商品页短时间反复进入退出会产生多条重复曝光。这里不是简单只留一条而是记录首次进入时间和末次退出时间同时计算停留时长。事件语义化的核心是把连续数值变成离散语义标签。我问过一些开发者大家会倾向于直接把数值放进句子比如“用户停留120秒”。但实测效果是“用户长时间阅读并仔细比较”这种带判断的表述模型更容易形成偏好推断。因为模型学习的是语义标签之间的关联而不是数字之间的相对大小。具体映射我用了一个简单阈值表行为类型原始数值范围语义标签表述示例阅读停留 90秒长时间深读认真阅读完阅读停留30~90秒中等停留浏览了一部分点击频率同源内容点击3次强偏好连续多次查看同主题内容购买行为加购未支付高意向加入购物车但尚未结算分享转发点击分享按钮社交认可愿意分享给他人这套设计背后考虑是规避模型的数值盲区。大模型对绝对数值的判断一般弱于分类语义标签与其让它猜“90秒”和“85秒”有什么区别不如直接告诉它“看完了一篇长文”。语义标签粒度不用太细4到6档就够了太细模型反而会过拟合噪声。2.2 句子结构怎么搭行为顺序、关注焦点和负反馈表述生成不是把多个句子随便拼在一起。我复盘出来的最优模板遵循三个原则第一事件按时间顺序排但同级重要性的行为可以并列。时间顺序给模型呈现一个逻辑链条让它自己体会趋势变化。比如一个人上周阅读的全是入门教程这周开始读进阶实战这就是明显的兴趣升级信号。并列关系则适合表达强度例如连续点击、多个同类目行为并行出现。第二越晚近的行为权重越高。人的兴趣会漂移三个月前的购买记录对今天的推荐意义不大。我在表述层把行为按时间加权最近7天的行为完整保留7~30天的行为压缩成一句概括30天往前的行为只保留长期稳定偏好。句子结构上采用“近期 中期 长期”的三段式让模型自然感受到时间的影响。第三不要只表达正反馈负反馈同样重要。用户点了“不感兴趣”按钮、快速划走、在文章界面只停留四秒这些都是强烈的负信号。我尝试在表述里显式加上负样本句比如“用户对短视频类内容快速划过3次表现出较低的接受意愿”。这个操作让模型在排序时明显降低被打过负反馈标签的内容权重整体线上点击率提升了3.2%。这里我放一个实际在用的表述生成片段用Python做了简化方便说明请求处理时的逻辑def generate_verbalization(session_events, long_term_profile): recent [] mid_term [] for ev in session_events: if ev.days_ago 7: recent.append(f在{ev.time_range}用户{ev.semantic_action}了内容《{ev.title}》{ev.category}) elif ev.days_ago 30: mid_term.append(f过去一个月内用户对{ev.category}内容保持较高关注) long_part f用户长期偏好集中在{long_term_profile} return \n.join(recent mid_term [long_part])在实际生产实现里generate_verbalization的输入来自一个实时的会话特征缓存输出会拼上一段候选商品描述再一起发给模型打分。2.3 离线评估先定准指标再谈效果优化做LLM推荐的评估不能只看最终点击率。我这边搭了一套离线评估框架包含三个层面的指标排序质量指标NDCG10、MRR、Recall20。表述质量指标表述与用户行为的一致性打分由人工抽检和模型自评两部分组成。稳定性指标同一样本多次推理的打分方差、对不同表述模板的敏感度。这里要特别说一下表述质量的评估。我抽了2000条线上日志人工对照原始行为与生成表述判断是否有信息补全、信息扭曲或信息缺失。一开始这个环节漏掉很多问题后来检查才发现部分模板会生成“用户对XX类内容有高度兴趣”但其实用户只是误点了两次。针对这类情况我会在表述生成后增加一层置信度计算行为数量太少时在句子里加“在有限的交互中用户表现出轻微的偏好倾向”这种弱化措辞。排序质量上的对比数据我整理过一次明显看得出语言化表述带来的增益在长尾内容上更突出。指标纯特征排序模型特征排序 LLM语言化重排提升幅度NDCG100.3830.45218.0%MRR0.2710.33423.2%长尾内容曝光占比12.6%18.4%46.0%长尾内容曝光涨这么多我理解是因为语言模型天然能理解语义相似性不需要这些内容跟用户历史行为有严格的ID共现所以之前很难被传统协同过滤发现的冷门内容有了出头机会。3. 实操过程从原始日志到线上稳定服务很多分享停在离线实验阶段但我更关心的是完整落地。这一节把整个实施流程过一遍涉及数据链、训练、部署三块每块都有明确的操作步骤。3.1 数据管道构建日志接入、会话聚合、语义化缓存第一环是日志接入我这边采用的方式是消息队列实时接入加离线批处理补偿。原始日志落在Kafka对应主题中一个消费者组负责实时解析另外每天凌晨跑一个批任务回补当天数据质量检查。主要做两项字段完整性校验和格式统一。接下来是会话聚合这是个吃资源的步骤。会话切分策略比较简单相邻两条行为间隔超过30分钟就断开切出来的会话作为表述生成的最小单元。会话内的事件按类型排序核心事件优先排比如购买 深度阅读 点击 曝光。语义化这一步我放在了独立的服务里输入是会话事件列表输出是一段文本。为了提高复用率我还加了缓存。缓存设计得很粗暴用用户ID和会话ID做键语义化结果存Redis有效期48小时。只有会话发生新事件时才更新。这个设计让模型的重复调用量降了40%左右因为同一用户短时间内的多次推荐请求不再重复拼表述。数据管道的完整流程如下日志接入统一时区过滤异常流量。会话切分按用户维度和时间窗口聚合。提取关键行为映射到语义标签。按模板生成表述并缓存。把表述拼接候选商品信息组成模型输入。3.2 提示模板调优与模型微调的平衡这一步涉及标题里“Language Learning”的另一个侧面。当我拿到一批日志转语言生成的自然语言样本后模型不能只靠零样本推理干活需要用这些样本做有监督微调让模型学会从表述中抽取偏好信号。我使用的微调方式是LoRA而不是全量微调。原因很现实基座模型太庞大全量微调的显存和训练时间根本无法接受而且容易破坏模型原有的通用能力。LoRA只训练一小部分低秩参数适配推荐任务足够用还能随时切换回通用能力。训练数据的构造是整个过程中最费精力的。每条训练样本由三部分组成用户日志转语言后的行为描述。一个候选推荐项的描述。标注标签是否推荐、推荐理由、推荐强度。标注标签不是全部靠人工我用的策略是“人工标注 LLM自动标注 规则校验”三者结合。先人工标注500条高质量种子样本再用这批种子样本通过少量示例示范让模型自动标注一大批最后由规则层过滤掉自相矛盾的标注。微调参数我用的是learning_rate: 2e-4 batch_size: 16 max_seq_len: 2048 lora_rank: 16 lora_alpha: 32 epochs: 33个epoch是我调出来的平衡点训练太少模型学不会训练太多会出现灾难性遗忘模型开始对推荐任务过拟合反而丢掉了语言理解能力。训练完成后必须跑一遍通用能力回归测试比如常识问答、摘要、指令遵循各抽几十条分数掉得太明显要回退参数。这里再加一层提示模板稳定性控制微调后的模型虽然见过大量样本文本但线上推广时提示里会有新出现的候选商品描述所以要设计带均匀随机插入新内容的训练样本。具体做法是每次训练时把候选商品描述里10%替换成随机从知识库抽取的内容让模型对没见过的东西也保持稳定判断。3.3 线上服务部署推理性能与成本控制的实操线上推理我用的是轻量级部署方案因为推荐场景对延迟敏感一般要求在200毫秒内返回。关键优化点有三个。第一个是输入截断策略。日志转语言后的用户行为描述可能很长加上候选商品描述后经常超过2000 token。我写了一个动态截断函数保留行为描述的前半部分和最近3条事件中间压缩成摘要。这个策略能控制95%的请求输入长度在1500 token以内精度损失控制在5%以内。第二个是批量推理时动态padding。一组请求里各输入长度差异很大直接padding到最大长度可以开满GPU算力但浪费严重。我采用的是按长度分桶把长度接近的请求放到一个batch里配合KV Cache复用整体吞吐量大约提升了1.6倍。第三个是静态内容预计算。候选商品描述、常用行为标签这些可复用的内容在服务启动时预先向量化或预先格式化推理时直接查缓存。实测下来生成部分的耗时占比可以降到总耗时的30%以下。部署架构上我拆成两个池子一个池子跑在线请求一个池子专门跑离线重放任务。离线重放任务不直接服务用户而是用历史日志不停回放用来发现模型的不稳定输出和候选集的覆盖盲区。这个设计帮我发现了好几次日志语义化字段变更引发的模型效果滑坡。3.4 灰度发布与A/B测试先别急着全量LLM推荐的灰度发布和传统模型不同它涉及的变更面更广可能改了表述模板、换了模型权重、调了推理参数每一层都会影响最终输出。我习惯做的是多层叠加灰度第一个层级先开小流量占比5%。这个阶段只看基础设施指标包括推理延迟、错误率、显存占用不看业务指标。第二个层级扩到20%观察点击率和用户反馈。第三个层级再扩到50%这时候会看留存和长尾内容分发比例。最后冲全量之前必须回看离线重放任务的指标是否与新流量表现一致。A/B测试的注意点是不能只设一个实验组和一个对照组。我通常设三组全特征排序模型作基准组、特征排序 LLM排序组、特征排序 LLM排序 表述优化组。三个组两两对比分别能分离出LLM本身的增益和表述优化的增益。有一次灰度我印象很深20%流量时整体点击率提升明显但细分人群之后发现新用户点击率涨了8%老用户反而跌了4%。排查后发现是表述模板里太多强调近期行为老用户的长期偏好被挤掉了。紧急调整了长短期行为配比之后老用户指标恢复正常。这类问题在离线评估里很难暴露只能靠分层灰度去发现。4. 常见问题与排查技巧实录做这套系统的过程中遇到的问题五花八门很多不是模型原理层面的而是工程细节。我把最有代表性的几个问题按现象、定位、解决列成了速查表。4.1 高频问题速查表问题现象可能原因定位手段解决操作推荐结果全是热门内容长尾消失表述中过度强调大众偏好检查生成表述和候选描述是否语义集中加入类别均匀化采样调整候选集分布同一条日志生成不同表述模板字段缺失导致随机填充对比同session多次生成结果在模板渲染时增加默认值避免空字段模型对候选内容评分特别高但点击率低表述中缺少负反馈信号人工抽查top-10推荐内容的日志序列补充负样本句明确“划走”“不感兴趣”等行为调用成本超标输入token太长查看在线日志的token分布启用动态截断策略批量分桶日志有延迟模型推荐滞后消息队列堆积观察消费者lag指标增加消费者并行度并加一轮离线补偿还有一个常见但容易被忽视的问题用户隐私字段误入表述。日志里偶尔会带手机型号、地理位置甚至设备标识如果不加过滤模型可能学到一些既没有推荐价值又敏感的关联。我在语义化服务里加了字段白名单机制只有白名单里的字段才能进入模板其他一律丢弃。4.2 避坑心得与一票否决项有几个深坑花了很长时间才趟平坑一全量日志进prompt以为信息越多越好。早期设计时我试着把用户一年内的日志全塞进去结果推荐模型开始学用户的历史惯性给用户推的全是同类内容严重影响探索。后来统一改成“近期 中期 长期”三段式才在相关性和多样性之间找到平衡。坑二别让模型直接对数字做运算。有一版表述里写了“用户点击了17次”模型在做打分时经常把具体出现过的数字当成强特征下面的行为一多反而把偏好淹没了。改成“大量点击”“多次点击”之后效果稳定很多。语言模型擅长的是语义理解不是数值比较表述层要主动替模型把数值转成判断。坑三新内容的表述与训练样本分布严重不一致。上线期间引入了一批新栏目内容候选描述里出现很多训练时没见过的品类词模型给这类内容打分偏低。后面在微调训练样本里会定期注入新内容的描述并对未知描述做后处理纠偏比如调低置信度或加倍多样本投票。所谓一票否决项我指的是三类问题有用户数据泄漏风险的行为一律不做模型在相同输入下产生严重不稳定输出的版本不能上线带有明显毒性或歧视倾向的生成表述必须拦截。这三类问题和推荐效果无关属于安全底线。4.3 后续方向表述的自适应与跨场景复用这套链路跑通之后我认为最有价值的后续扩展方向是让表述自学习。当前模板是人工设计的虽然效果不错但对新业务场景的适配速度还是太慢。比如从文章推荐扩展到短视频推荐同样的行为语义标签需要重新设计。下一步的计划是维护一个“行为语义词典”把日志字段和语义标签做成可配置的映射表配置表变化时自动批量重算历史样本让模型快速适应新场景。另一个方向是跨场景复用。用户在一个业务域的日志转语言结果能不能经过脱敏后复用到另一个推荐场景比如阅读行为的表述能否辅助商品推荐。目前的实验表明只要表述抽象到“长时间深度参与”“快速划过”“内容主题偏好”这个层级跨场景迁移是有可能的。真正卡点反而是数据权限和隐私合规技术本身已经能看到路子。我自己的体会是这套日志转语言、语言驱动推荐的方案核心不只是把数据喂给大模型而是构建了一个“用自然语言描述用户兴趣”的中间层。中间层一旦稳定下游的模型替换、业务扩展都会变得非常灵活。以后模型能力更强可能不需要这么复杂的表述工程但今天要想在真实生产环境里用LLM做推荐把日志转成高质量语言样本这件事值得认真投入。
试想一下线上系统每天刷新几千万条用户行为日志点击、收藏、停留时长、购买全在里面堆着。传统做法是清洗后算特征喂给排序模型。可到了大语言模型时代这些结构化的、散落的数值字段反而成了障碍——模型读不懂“uid1024, itemSKU778, typeclick, ts171000120”到底意味着什么。这个标题所讲的核心就是一口把日志“翻译”成人话再做语言学习式的最优表述让大模型在推荐场景里真正用起来还能扛住生产环境的压力和成本。我最近在一套面向新用户的内容推荐服务里完整跑过这个链路从日志清洗、表述模板设计、微调到灰度上线都过了几轮踩了不少坑也沉淀了一些可复用的方法下面逐一拆开讲。1. 整体设计为什么要把日志“转译”成语言再做推荐先说一个很直接的问题既然大模型这么强直接把用户历史行为按“user_id item_id”喂进去不行吗我试过效果很差。原因是纯ID序列对模型来说是一堆无意义的符号它没法把“昨天点击过三次数码类文章”和“今天推荐手机评测”这两件事联系起来。要让语言模型发挥语义理解的优势必须把行为日志映射成自然语言描述让模型读到的是有逻辑有意图的事件流而不是一串稠密且单调的键值对。这个思路的核心可以用一句话概括把日志当作原料把语言当作中间表达让模型在语言层完成推荐推理。听起来不复杂但放到生产环境里就有很多细小的分岔需要做取舍。1.1 从行为日志到模型输入中间需要一个表述层大多人第一次接触LLM推荐容易直接跳到“把你的prompt写得花团锦簇”这一步结果效果不稳定。真实链路里第一步不是prompt而是日志的语义化。我这边把整条推荐链路拆成四段原始日志接入、日志清洗与场景切分、表述生成、模型推理与后处理。其中表述生成这部分是很多人会忽略但其实最值得投入的地方。它的本质是在原始日志之上抽象出一个“用户故事”用户在什么时间对什么内容做了什么动作动作背后大概是什么偏好形成一个或几个句子。这里有一个关键设计原则表述的粒度要和推荐决策的粒度对齐。比如推荐目标是“下一件要看的文章”那么一条日志里最关键的就不是历史订单而是近期的阅读序列和点击密度。如果推荐目标是“购物车加购”那表述重心就要放在商品类目偏好和价格带上。日志结构是通用的但表述模板必须跟着业务目标走。从实现上看日志转语言的流程大致是日志接入后先按会话session聚合而不是按天硬切。提取关键事件保留行为顺序去掉冗余字段。字段数值映射成语义标签比如停留时长从“120秒”转成“长时间阅读”。填充到预定义的句子里生成一条能直接喂给模型的事件描述。这步做好后面模型的稳定性会质变。我见过有人在这一步偷懒直接用现成日志字段拼话术结果线上推荐经常出现“用户都没看过的内容被当成强偏好”原因就是表述层把偶然点击和真实兴趣混在一起了。1.2 为什么选“语言化”而不是向量召回或序列模型在方案选型的时候同步也考虑了两条更常规的路一条是用户行为序列直接接双塔模型做向量召回另一条是用户日志聚合成特征后进排序模型。这两条路成熟稳定资源开销也小。但它们在内容理解上有个上限整个系统很难感知到“这篇技术文章跟用户刚看过的源码解析是同主题但不同难度层级”这层关系。语言模型的优势在于它把文本里的语义关联直接当作知识来用。用户对五篇包含“后端”“数据库”关键词的文章产生过行为不需要经过一层Embedding训练模型天然就知道下一条推荐可以考虑缓存中间件相关的内容。这类能力天然适合内容型推荐尤其适合新用户冷启动——后台没有足够的交互数据做协同过滤时语言描述本身就能承担“特征”的角色。当然我不建议把所有场景都改成LLM推荐。成本在那里摆着一套线上服务每天处理上千万次请求纯语言化推理的开销远高于双塔模型。比较合理的架构是双塔负责第一阶段的粗召回LLM负责对候选集合做细排序和解释生成。日志语言化在这个架构里充当主链条上的“翻译官”把小规模的候选集转成可推理的语义文本。我最终选型时确定了这样的部署方式日志解析服务独立成一个表述生成不单独占一个模型而是靠模板加规则去生成节省调用量大模型只做候选打分排序。这样算下来每天500万次推荐请求纯增量的大模型推理量控制在50万次左右成本基本可控。2. 核心细节解析最优表述的构建原则与实现方法标题里的“Optimal Verbalization”翻成中文就是最优表述这个词值得琢磨。并不是任何自然语言句子都能让模型给出好结果表述的好坏直接决定推荐的准确性。我刚开始做实验的时候用同样一份日志只是调整了表述句子的顺序和用词NDCG10能从0.31跳到0.44变化非常吓人。2.1 日志清洗与事件语义化的几个关键操作日志清洗是最不性感但最影响结果的一步。几个我反复踩的点列出来时区不统一。线上服务会跨多机房部署用户日志如果用本地时间记录聚合时可能出现时间倒挂。我在清洗层统一把时间全部转成UTC毫秒时间戳并在会话划分前固定好时区。过滤机器行为。有些刷量点击和异常高频请求会混进日志如果直接进表述层模型会把异常行为学成正常偏好。我是按IP维度和设备维度做频率统计超过95分位的高频访问直接剔除。事件去重。用户在同一个商品页短时间反复进入退出会产生多条重复曝光。这里不是简单只留一条而是记录首次进入时间和末次退出时间同时计算停留时长。事件语义化的核心是把连续数值变成离散语义标签。我问过一些开发者大家会倾向于直接把数值放进句子比如“用户停留120秒”。但实测效果是“用户长时间阅读并仔细比较”这种带判断的表述模型更容易形成偏好推断。因为模型学习的是语义标签之间的关联而不是数字之间的相对大小。具体映射我用了一个简单阈值表行为类型原始数值范围语义标签表述示例阅读停留 90秒长时间深读认真阅读完阅读停留30~90秒中等停留浏览了一部分点击频率同源内容点击3次强偏好连续多次查看同主题内容购买行为加购未支付高意向加入购物车但尚未结算分享转发点击分享按钮社交认可愿意分享给他人这套设计背后考虑是规避模型的数值盲区。大模型对绝对数值的判断一般弱于分类语义标签与其让它猜“90秒”和“85秒”有什么区别不如直接告诉它“看完了一篇长文”。语义标签粒度不用太细4到6档就够了太细模型反而会过拟合噪声。2.2 句子结构怎么搭行为顺序、关注焦点和负反馈表述生成不是把多个句子随便拼在一起。我复盘出来的最优模板遵循三个原则第一事件按时间顺序排但同级重要性的行为可以并列。时间顺序给模型呈现一个逻辑链条让它自己体会趋势变化。比如一个人上周阅读的全是入门教程这周开始读进阶实战这就是明显的兴趣升级信号。并列关系则适合表达强度例如连续点击、多个同类目行为并行出现。第二越晚近的行为权重越高。人的兴趣会漂移三个月前的购买记录对今天的推荐意义不大。我在表述层把行为按时间加权最近7天的行为完整保留7~30天的行为压缩成一句概括30天往前的行为只保留长期稳定偏好。句子结构上采用“近期 中期 长期”的三段式让模型自然感受到时间的影响。第三不要只表达正反馈负反馈同样重要。用户点了“不感兴趣”按钮、快速划走、在文章界面只停留四秒这些都是强烈的负信号。我尝试在表述里显式加上负样本句比如“用户对短视频类内容快速划过3次表现出较低的接受意愿”。这个操作让模型在排序时明显降低被打过负反馈标签的内容权重整体线上点击率提升了3.2%。这里我放一个实际在用的表述生成片段用Python做了简化方便说明请求处理时的逻辑def generate_verbalization(session_events, long_term_profile): recent [] mid_term [] for ev in session_events: if ev.days_ago 7: recent.append(f在{ev.time_range}用户{ev.semantic_action}了内容《{ev.title}》{ev.category}) elif ev.days_ago 30: mid_term.append(f过去一个月内用户对{ev.category}内容保持较高关注) long_part f用户长期偏好集中在{long_term_profile} return \n.join(recent mid_term [long_part])在实际生产实现里generate_verbalization的输入来自一个实时的会话特征缓存输出会拼上一段候选商品描述再一起发给模型打分。2.3 离线评估先定准指标再谈效果优化做LLM推荐的评估不能只看最终点击率。我这边搭了一套离线评估框架包含三个层面的指标排序质量指标NDCG10、MRR、Recall20。表述质量指标表述与用户行为的一致性打分由人工抽检和模型自评两部分组成。稳定性指标同一样本多次推理的打分方差、对不同表述模板的敏感度。这里要特别说一下表述质量的评估。我抽了2000条线上日志人工对照原始行为与生成表述判断是否有信息补全、信息扭曲或信息缺失。一开始这个环节漏掉很多问题后来检查才发现部分模板会生成“用户对XX类内容有高度兴趣”但其实用户只是误点了两次。针对这类情况我会在表述生成后增加一层置信度计算行为数量太少时在句子里加“在有限的交互中用户表现出轻微的偏好倾向”这种弱化措辞。排序质量上的对比数据我整理过一次明显看得出语言化表述带来的增益在长尾内容上更突出。指标纯特征排序模型特征排序 LLM语言化重排提升幅度NDCG100.3830.45218.0%MRR0.2710.33423.2%长尾内容曝光占比12.6%18.4%46.0%长尾内容曝光涨这么多我理解是因为语言模型天然能理解语义相似性不需要这些内容跟用户历史行为有严格的ID共现所以之前很难被传统协同过滤发现的冷门内容有了出头机会。3. 实操过程从原始日志到线上稳定服务很多分享停在离线实验阶段但我更关心的是完整落地。这一节把整个实施流程过一遍涉及数据链、训练、部署三块每块都有明确的操作步骤。3.1 数据管道构建日志接入、会话聚合、语义化缓存第一环是日志接入我这边采用的方式是消息队列实时接入加离线批处理补偿。原始日志落在Kafka对应主题中一个消费者组负责实时解析另外每天凌晨跑一个批任务回补当天数据质量检查。主要做两项字段完整性校验和格式统一。接下来是会话聚合这是个吃资源的步骤。会话切分策略比较简单相邻两条行为间隔超过30分钟就断开切出来的会话作为表述生成的最小单元。会话内的事件按类型排序核心事件优先排比如购买 深度阅读 点击 曝光。语义化这一步我放在了独立的服务里输入是会话事件列表输出是一段文本。为了提高复用率我还加了缓存。缓存设计得很粗暴用用户ID和会话ID做键语义化结果存Redis有效期48小时。只有会话发生新事件时才更新。这个设计让模型的重复调用量降了40%左右因为同一用户短时间内的多次推荐请求不再重复拼表述。数据管道的完整流程如下日志接入统一时区过滤异常流量。会话切分按用户维度和时间窗口聚合。提取关键行为映射到语义标签。按模板生成表述并缓存。把表述拼接候选商品信息组成模型输入。3.2 提示模板调优与模型微调的平衡这一步涉及标题里“Language Learning”的另一个侧面。当我拿到一批日志转语言生成的自然语言样本后模型不能只靠零样本推理干活需要用这些样本做有监督微调让模型学会从表述中抽取偏好信号。我使用的微调方式是LoRA而不是全量微调。原因很现实基座模型太庞大全量微调的显存和训练时间根本无法接受而且容易破坏模型原有的通用能力。LoRA只训练一小部分低秩参数适配推荐任务足够用还能随时切换回通用能力。训练数据的构造是整个过程中最费精力的。每条训练样本由三部分组成用户日志转语言后的行为描述。一个候选推荐项的描述。标注标签是否推荐、推荐理由、推荐强度。标注标签不是全部靠人工我用的策略是“人工标注 LLM自动标注 规则校验”三者结合。先人工标注500条高质量种子样本再用这批种子样本通过少量示例示范让模型自动标注一大批最后由规则层过滤掉自相矛盾的标注。微调参数我用的是learning_rate: 2e-4 batch_size: 16 max_seq_len: 2048 lora_rank: 16 lora_alpha: 32 epochs: 33个epoch是我调出来的平衡点训练太少模型学不会训练太多会出现灾难性遗忘模型开始对推荐任务过拟合反而丢掉了语言理解能力。训练完成后必须跑一遍通用能力回归测试比如常识问答、摘要、指令遵循各抽几十条分数掉得太明显要回退参数。这里再加一层提示模板稳定性控制微调后的模型虽然见过大量样本文本但线上推广时提示里会有新出现的候选商品描述所以要设计带均匀随机插入新内容的训练样本。具体做法是每次训练时把候选商品描述里10%替换成随机从知识库抽取的内容让模型对没见过的东西也保持稳定判断。3.3 线上服务部署推理性能与成本控制的实操线上推理我用的是轻量级部署方案因为推荐场景对延迟敏感一般要求在200毫秒内返回。关键优化点有三个。第一个是输入截断策略。日志转语言后的用户行为描述可能很长加上候选商品描述后经常超过2000 token。我写了一个动态截断函数保留行为描述的前半部分和最近3条事件中间压缩成摘要。这个策略能控制95%的请求输入长度在1500 token以内精度损失控制在5%以内。第二个是批量推理时动态padding。一组请求里各输入长度差异很大直接padding到最大长度可以开满GPU算力但浪费严重。我采用的是按长度分桶把长度接近的请求放到一个batch里配合KV Cache复用整体吞吐量大约提升了1.6倍。第三个是静态内容预计算。候选商品描述、常用行为标签这些可复用的内容在服务启动时预先向量化或预先格式化推理时直接查缓存。实测下来生成部分的耗时占比可以降到总耗时的30%以下。部署架构上我拆成两个池子一个池子跑在线请求一个池子专门跑离线重放任务。离线重放任务不直接服务用户而是用历史日志不停回放用来发现模型的不稳定输出和候选集的覆盖盲区。这个设计帮我发现了好几次日志语义化字段变更引发的模型效果滑坡。3.4 灰度发布与A/B测试先别急着全量LLM推荐的灰度发布和传统模型不同它涉及的变更面更广可能改了表述模板、换了模型权重、调了推理参数每一层都会影响最终输出。我习惯做的是多层叠加灰度第一个层级先开小流量占比5%。这个阶段只看基础设施指标包括推理延迟、错误率、显存占用不看业务指标。第二个层级扩到20%观察点击率和用户反馈。第三个层级再扩到50%这时候会看留存和长尾内容分发比例。最后冲全量之前必须回看离线重放任务的指标是否与新流量表现一致。A/B测试的注意点是不能只设一个实验组和一个对照组。我通常设三组全特征排序模型作基准组、特征排序 LLM排序组、特征排序 LLM排序 表述优化组。三个组两两对比分别能分离出LLM本身的增益和表述优化的增益。有一次灰度我印象很深20%流量时整体点击率提升明显但细分人群之后发现新用户点击率涨了8%老用户反而跌了4%。排查后发现是表述模板里太多强调近期行为老用户的长期偏好被挤掉了。紧急调整了长短期行为配比之后老用户指标恢复正常。这类问题在离线评估里很难暴露只能靠分层灰度去发现。4. 常见问题与排查技巧实录做这套系统的过程中遇到的问题五花八门很多不是模型原理层面的而是工程细节。我把最有代表性的几个问题按现象、定位、解决列成了速查表。4.1 高频问题速查表问题现象可能原因定位手段解决操作推荐结果全是热门内容长尾消失表述中过度强调大众偏好检查生成表述和候选描述是否语义集中加入类别均匀化采样调整候选集分布同一条日志生成不同表述模板字段缺失导致随机填充对比同session多次生成结果在模板渲染时增加默认值避免空字段模型对候选内容评分特别高但点击率低表述中缺少负反馈信号人工抽查top-10推荐内容的日志序列补充负样本句明确“划走”“不感兴趣”等行为调用成本超标输入token太长查看在线日志的token分布启用动态截断策略批量分桶日志有延迟模型推荐滞后消息队列堆积观察消费者lag指标增加消费者并行度并加一轮离线补偿还有一个常见但容易被忽视的问题用户隐私字段误入表述。日志里偶尔会带手机型号、地理位置甚至设备标识如果不加过滤模型可能学到一些既没有推荐价值又敏感的关联。我在语义化服务里加了字段白名单机制只有白名单里的字段才能进入模板其他一律丢弃。4.2 避坑心得与一票否决项有几个深坑花了很长时间才趟平坑一全量日志进prompt以为信息越多越好。早期设计时我试着把用户一年内的日志全塞进去结果推荐模型开始学用户的历史惯性给用户推的全是同类内容严重影响探索。后来统一改成“近期 中期 长期”三段式才在相关性和多样性之间找到平衡。坑二别让模型直接对数字做运算。有一版表述里写了“用户点击了17次”模型在做打分时经常把具体出现过的数字当成强特征下面的行为一多反而把偏好淹没了。改成“大量点击”“多次点击”之后效果稳定很多。语言模型擅长的是语义理解不是数值比较表述层要主动替模型把数值转成判断。坑三新内容的表述与训练样本分布严重不一致。上线期间引入了一批新栏目内容候选描述里出现很多训练时没见过的品类词模型给这类内容打分偏低。后面在微调训练样本里会定期注入新内容的描述并对未知描述做后处理纠偏比如调低置信度或加倍多样本投票。所谓一票否决项我指的是三类问题有用户数据泄漏风险的行为一律不做模型在相同输入下产生严重不稳定输出的版本不能上线带有明显毒性或歧视倾向的生成表述必须拦截。这三类问题和推荐效果无关属于安全底线。4.3 后续方向表述的自适应与跨场景复用这套链路跑通之后我认为最有价值的后续扩展方向是让表述自学习。当前模板是人工设计的虽然效果不错但对新业务场景的适配速度还是太慢。比如从文章推荐扩展到短视频推荐同样的行为语义标签需要重新设计。下一步的计划是维护一个“行为语义词典”把日志字段和语义标签做成可配置的映射表配置表变化时自动批量重算历史样本让模型快速适应新场景。另一个方向是跨场景复用。用户在一个业务域的日志转语言结果能不能经过脱敏后复用到另一个推荐场景比如阅读行为的表述能否辅助商品推荐。目前的实验表明只要表述抽象到“长时间深度参与”“快速划过”“内容主题偏好”这个层级跨场景迁移是有可能的。真正卡点反而是数据权限和隐私合规技术本身已经能看到路子。我自己的体会是这套日志转语言、语言驱动推荐的方案核心不只是把数据喂给大模型而是构建了一个“用自然语言描述用户兴趣”的中间层。中间层一旦稳定下游的模型替换、业务扩展都会变得非常灵活。以后模型能力更强可能不需要这么复杂的表述工程但今天要想在真实生产环境里用LLM做推荐把日志转成高质量语言样本这件事值得认真投入。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
