这两年LLM落地推荐系统的项目越来越多但有一个关键环节经常被低估——怎么把用户行为日志“翻译”成人话。我见过不少团队把模型接进线上后效果就是起不来排了半天问题最后发现日志到提示词的文本化环节做得太粗糙要么直接把结构化特征拼成JSON丢给模型要么生成一段冗长到超出上下文窗口的“小作文”。这个项目想解决的就是在一套真实的推荐生产链路里找到从日志到语言的最优表达方式让LLM既能真正“读懂”用户行为又能满足线上延迟和成本约束。适合正在做LLM推荐、RAG问答或者任何“结构化数据与大模型结合”方向的同学参考。1. 项目核心问题为什么日志必须先转成语言1.1 LLM不认识表格只认识文本先说一个基础认知LLM不是数据库查询引擎它的预训练语料是自然语言文本不是行为日志。用户的行为痕迹比如点击序列、浏览时长、加购记录本质上是高度结构化的表格数据。直接把字段拼成JSON塞给模型模型也能处理但理解质量会大打折扣。这个现象在业界有一个说法叫表达鸿沟representation gap。结构化数据里隐含的语义比如“用户在深夜反复查看同一款商品但始终没有下单”如果只是给模型一个数值字段它很难捕捉到这种犹豫情绪和决策张力但如果你用自然语言把这条行为描述出来模型理解起来就完全不同。我打个生活化的比方你让一个经验丰富的销售看一份数据报表他能看懂数字但如果你把同一个客户的故事用一两句话讲给他听——“这位客户上周来看了三次每次都问价格能不能再低但始终没签字”——他的判断和决策会立刻发生变化。LLM也一样填饱了自然语言的语料它对自然语言的语义密度最敏感。在推荐场景里我们想要的不是让LLM记住所有原始字段而是让它理解用户行为背后的模式和意图。日志到语言的这一步转换决定了LLM能在多大程度上“代入”用户视角。这个步骤做得不好后面无论你的模型多大、推理多快效果都像隔了一层雾。1.2 生产环境对文本化的三重约束在离线实验里把日志转成文本很简单想怎么写就怎么写反正不跑线上。但生产环境不一样它给文本化方案上了三道紧箍咒而且每一道都直接影响架构取舍。第一道是成本约束。LLM推理按token计费你喂进去多少字就要付多少钱。一个用户如果积累了上百条行为记录逐条翻译成句子一条请求就要几千个token放在日均千万级请求的推荐系统里这个成本不是线性的是爆炸性的。你必须在信息表达和token预算之间找到平衡点。第二道是延迟约束。用户的推荐请求是实时的从行为日志写入到推荐结果返回整个链路往往只有几百毫秒的预算。LLM本身的推理延迟已经不低如果文本化环节再做大量拼接、检索、展开延迟会进一步恶化。生产环境要求文本化模块足够快最好能够在请求进来之前就把大部分内容准备好。第三道是稳定性约束。LLM推荐系统的输出是自然语言形式的候选序列或排序解释但下游的排序模块、重排模块需要的是结构化结果。文本化环节不仅要管输入还要管输出格式的约束和解析。如果模型今天输出JSON、明天输出自然句子中间解析就会出乱子。你要在提示词设计、解码参数、后处理校验上做一套兜底机制保证线上行为稳定。这三道约束并不是孤立存在的它们之间还有互锁关系。比如你想压缩token就可能丢信息推荐质量下降你想提高质量就要增加文本长度和推理次数延迟成本又上来了。这个项目最大的一个设计目标就是找到这三者之间的最优操作区间。2. Verbalization方案设计从日志到提示词的关键决策2.1 信息取舍保留什么丢掉什么文本化的第一步是信息取舍。原则我总结成一句话“最少但足够”。不要追求把日志里的所有字段都描述出来而是要站在LLM的角度问自己如果我是推荐官我最需要知道这个用户的哪些情况我在这个项目里把日志信息分成了三类。第一类是行为序列也就是用户最近看过、买过、收藏过哪些物品顺序如何间隔多久。第二类是物品属性也就是候选物品的标题、类目、价格区间、关键属性。第三类是上下文信号包括当前时间、用户所在渠道、设备类型、是否是促销节点。分类之后我建议每个团队带着业务方一起过一遍每一类信息里哪些字段是模型做决策时真正依赖的哪些是锦上添花的。基于此做减法。我们做过一个对比实验把用户最近50条行为全量描述和只保留最近10条关键行为模型效果几乎没有差异但token消耗差了近5倍。原因是行为序列里存在大量重复信息比如用户连续翻看了同类目下的不同款这些信息用一句话概括就够了。值得特别注意的信息就是时间衰减。同一个“浏览”动作发生在5分钟前和发生在5天前对当前推荐决策的意义完全不同。文本化时不能简单地按时间顺序罗列而要在表达上体现时效差异。比如“用户5分钟内连续查看了3条夏季连衣裙”和“用户上周查看过一款背包”模型从字面上就能感知到兴趣的先后权重比给它两个时间戳字段直观得多。2.2 行为序列的模板化表达行为序列的文本化是整个方案的骨架。我推荐的做法是设计一套基于规则的模板来生成表达而不是让模型自由发挥。规则模板的好处是可控、可测、可优化。一个可参考的模板结构长这样用户在过去{时间窗口}内的行为轨迹在{时间}浏览了{物品标题}商品ID{id}停留约{时长}秒 随后在{时间}查看了{item}的详情页并将该商品加入购物车 近{天}内用户共计浏览过{n}件来自{类目}类目的商品平均每件商品浏览时长约{avg_time}秒 其中对价格在{price_low}-{price_high}区间的商品表现出明显偏好。这个模板看起来简单但里面有几个细节是调试出来的不是拍脑袋定的。行为动词的选择很关键。“浏览”“点击”“加购”“收藏”这几个词在语义上是有强弱之分的。“加购”代表强意图“收藏”代表弱但持久的兴趣“浏览”则更偏向泛探索。模板里用准确的动词来描述行为模型对用户意图的推理会更有依据。我们测试过把“加购”写成“加入购物车”语义没问题但模型对意图强度的感知会稍微弱一档因为“加购”这个词在电商语料里出现的上下文更集中、语义更明确。时间窗口要按业务场景动态计算不能写死。服饰类目看三天的行为就够数码类目用户可能研究一个月才下单模板里应该设计成参数化的窗口长度由上游特征服务实时计算。窗口内行为太稀疏时可以放宽到更长周期避免模板生成出来的文本像流水账。序列末尾要显式给出一个“小结式”的总结句。这个是我在实际调试中发现的LLM面对一长串行为序列时容易被中间信息干扰遗漏开头或结尾的强信号。如果模板在序列结束后给它一句汇总性的描述比如“整体来看用户近期偏好是{n}类目下价格适中的{attr}”模型的排序准确度会明显提升。本质上是在给模型划重点降低注意力分散的风险。2.3 候选物品与用户画像的言语化候选物品属性的表达方式和行为序列不同它更偏静态适合用结构化的模板。候选物品信息 - 标题{title} - 类目{category_path} - 价格{price}元 - 核心属性{attribute_list} - 近期销量{sales_count}这里的取舍点在于属性列表的长度。一个商品可能有几十个属性字段全列出来token爆炸。我的经验是从中选出“与决策强相关”的核心属性集合一般控制在5个以内。如果业务方说某个品类属性特别多可以考虑按类目维护不同的模板版本。服饰类关注材质、版型、适用季节数码类关注内存、续航、处理器版本。模板要能做到“一类目一模板”而不是企图用同一个模板通吃所有类目。用户画像的言语化也比较讲究。统计特征天然是数字化的比如“性别女”“年龄28”“历史消费金额3500元”直接拼进提示词会让整体风格非常割裂。我建议把统计特征也转成半自然语言的描述根据历史消费记录用户是一名{n}岁左右的女性消费者年度消费金额在{消费范围}区间 购买频次主要集中在{月份}对{类目}类商品有较高粘性。这种表达方式对LLM更友好而且有个额外的好处它天然把连续数值离散成语义区间比如消费金额不要写精确到分的数字而是写成“3000-4000元区间”。这样模型不会在无关紧要的数字精度上浪费注意力。2.4 上下文信号嵌入策略上下文信号指的是那些不属于用户长期画像、也不属于物品属性但会显著影响当前推荐决策的信息。比如现在是冬季用户在搜索结果页当前是晚间场景这些信号要融进文本里但要控制位置和密度。我的做法是把上下文信号放在整个提示词的前半段作为“场景总览”的一部分。原因很简单LLM对文本开头的关注度天然高于中间位置上下文信号恰恰是理解整个推荐任务的前提放在开头可以帮助模型更快进入状态。这里有一个常见的坑把太多上下文信号堆在一起比如把天气、温度、节假日、渠道、设备全部写成一张很长的清单。信号太多等于没有信号模型不知道哪个是重点。我建议每个请求最多放3个上下文信号而且必须是从业务指标里验证过有增量价值的信号宁缺毋滥。我们曾经做过一次实验增加了“是否处于大促预热期”的信号后在线点击率提升了0.8个百分点但同时也把另外两个看似合理的信号天气、时段去掉效果反而没有下降。这说明信号的价值要靠实验验证不是靠直觉堆砌。3. 实操生产环境落地的完整链路3.1 离线评估阶段做的事在写在线代码之前我强烈建议先做一轮离线仿真实验把不同的文本化方案在同一个评估框架下对比。这比直接上线试错成本低得多。离线评估的第一步是构造样本。从历史日志里选取推荐请求把请求发生时间之前的用户行为拼成输入把用户实际点击或购买的商品作为正样本随机负采样一批未交互商品作为负样本。用这样的构造方式你才能拿到“给定历史行为模型能否推荐对商品”的评估标准。评估指标我建议看召回率RecallK和排序质量NDCGK不要只看单一指标召回率反映模型是否候选到了正确商品NDCG反映模型对相关商品的排序是否靠前两者结合才能说明文本化方案的效果。第二步是文本化方案的对比。我们会固定同一个LLM和同一套推理参数只改变日志到语言的转换方式。建议最少对比三组纯JSON结构输入、朴素模板输入简单拼接、优化模板输入带时序和意图语义的言语化方案。这个对比能直观展现出verbalization设计带来的增量。我在这个环节的实践中发现离线效果差距一般在3到8个百分点之间但有意思的是在部分用户群体上差距会拉大到15个百分点以上。分析后发现这些差距大的用户恰恰是行为丰富、历史长、画像复杂的头部用户。也就是说行为序列越长文本化质量的影响就越明显。这对设计的一个启示是文本化方案要优先保证长行为序列场景的表达质量而不是只针对稀疏行为做优化。还有一个离线阶段容易被忽略的问题模板生成的文本里可能包含不符合公序良俗或容易引发反感的表述比如涉及年龄、收入等敏感推断时措辞要中性、客观不做主观评价涉及性别、地域等维度时不要生成任何可能引发传播风险的刻画。我们在模板规范里增加了多轮人工审核确保生成的提示词文本不包含任何主观倾向和敏感信息。3.2 在线推荐链路的结构经过离线验证的文本化方案最终要嵌入在线链路。我们这个项目的在线架构大致分为四层。第一层是请求接入层。用户发起推荐请求后网关层将用户标识和上下文信息传给下游的服务模块。第二层是特征服务层。这一层负责查询用户行为日志、物品属性、实时上下文信息把原始数据整合成中间格式。关键性能优化是开启本地缓存只有缓存未命中时才回源查库。第三层就是文本化服务层也是这个项目的核心模块。它拿到特征服务层输出的结构化数据根据提前注册好的模板库和规则引擎生成自然语言提示词。这个模块独立部署的好处是改动文本化逻辑不影响其他服务可以单独做压力测试和版本控制。第四层是LLM推理层接收提示词后生成推荐结果。推理层后面通常还会接一个结果校验和重排模块用于解析模型输出、过滤非法格式、按业务规则重排候选物品。在线架构里有两个细节值得多说一句。一个是文本化模块和特征服务层建议用gRPC通信而不是HTTP这样能省掉大量序列化开销。另一个是模板引擎的处理速度非常快一次文本化操作在纯CPU环境下单次耗时通常在5毫秒以内相比LLM推理的几百毫秒可以忽略不计所以性能瓶颈不会出现在这一层。3.3 性能优化缓存、压缩与并发在线性能优化我有三个实战经验可以分享。第一个是结果的语义级缓存。LLM推荐系统有一个特点同一用户在一段时间内的行为变化是平缓的两个相邻请求之间用户的行为序列基本一致。对于这类请求可以用用户ID加上时间窗口作为key缓存上一轮的文本化结果和推荐结果命中率能达到40%以上。这个优化直接让平均延迟下降了一个数量级比任何推理加速手段都有效。第二个是提示词压缩。当用户行为特别长比如一个重度用户过去7天有几百条行为记录即使模板做了精简生成的文本还是可能超过模型上下文窗口的一半。我们的做法是分档截断行为数超过阈值时优先保留最近的并且删除低价值行为同时把物品属性描述合并为URL级摘要。实测下来把行为从200条截到30条推荐效果只下降约1个百分点但token成本下降了85%这个取舍是非常划算的。第三个是并发控制。LLM推理服务对并发非常敏感高并发下单个请求的响应时间会急剧上升。我们在推理层前面加了一个请求缓冲队列把并发数控制在模型的最佳吞吐区间内宁可让少量请求排队也不让所有请求同时涌进模型。配合面向会话的批处理推理整体GPU利用率可以提升30%以上。3.4 模板管理与版本迭代模板在项目里不是写死的一段字符串而是一套需要持续迭代的资产。我强烈建议把模板纳入版本管理每一个模板版本都记录对应的实验效果。我们内部有一个简单的模板版本表字段包括模板版本号、模板内容摘要、离线评估指标、在线实验结果、上线时间、回滚记录。这样一个表长期维护下来团队里任何人做文本化调整都有据可查不会出现“这个模板是谁写的、为什么这么写、能不能改”这种反问三连。模板迭代有一个节奏问题。我建议不要频繁改动模板因为模板变化直接影响线上推荐行为频率太高会让推荐结果不稳定用户感知变化突兀。比较好的节奏是一个月到两个月做一次模板更新每次只改一个小点比如调整行为窗口长度参数或者增加一种行为动词的表达颗粒度这样既保证持续优化又把风险控制在可追踪范围。每个模板上线前要跑回归测试确保所有类目的推荐请求都能正常生成提示词不会因为某个新物品缺少属性字段而报错。模板里凡是涉及用户属性、行为轨迹、历史消费等描述的地方都只采用中性措辞不做价值判断不输出任何带主观倾向的词句也不会出现采集、追踪等敏感描述。全链路数据的使用范围严格限定在推荐任务本身文本化模板不存储任何原始日志的明文信息只保留脱敏后的特征摘要。4. 常见问题与排查技巧实录4.1 生成的文本太长直接超出上下文窗口这是项目里遇到最多的线上问题。现象是模型返回报错提示输入序列长度超过了限制。排查时先看是单个字段超长还是整体拼接后超长。我们遇到过一次比较隐蔽的场景某个商品的属性字段里有个很长的文本型参数值单独看每个字段都正常但拼接进模板后整体超限。解决方法分两层。第一层是入口裁剪在文本化生成前检查字段长度超过阈值就截断或用摘要替代。第二层是生成结果校验模板引擎输出后做一个token估算超过预算就自动降级到低配模板。记住这里不要等LLM报错再处理必须在文本化模块内把超限问题消灭掉。token估算可以用简单的字符数乘系数也可以用tokenizer精确计算后者准确但多一次调用生产上限频率调用时建议用估算系数。4.2 LLM输出格式不稳定LLM生成结果的可解析性是生产环境的老大难。模型今天按提示词要求输出JSON数组明天心情不好就给你来一段“基于以上分析我认为推荐如下商品”的散文。应对思路是“双层保险”。第一层是提示词约束在模板里明确给出输出格式示例。注意要给出“正例”而不是只告诉模型“不要输出什么”。实践下来给一个具体的JSON格式样例比写一百字“请严格按照格式输出”有效得多。第二层是后处理校验对模型输出做格式解析解析失败则说明原因并触发一次带修正提示的重试如果重试还失败就降级到规则推荐结果保证线上永远有推荐返回。这里要提醒大家重试次数一定要限制一般一次就够了。重试越多延迟越不可控代价也越高。我们线上实测单次重试成功率大约在60%到80%之间加上后处理兜底整体返回成功率能稳定在99%以上。4.3 冷启动物品没有行为数据文本化后缺乏语义新品和长尾物品的日志记录少按模板生成出来的文本干巴巴的只有标题和类目没有行为数据支撑。模型对这类物品的推荐信心天然不足。解决思路是引入物品知识侧的信息补全。具体做法是给这些物品增加知识图谱属性比如关联类目下的热门关键词、品牌风格描述、典型适用场景。这些信息不依赖用户行为但能支撑LLM做基于内容的推理。比如一件没有销量的连衣裙如果知识侧描述了“适合约会场合碎花风格”模型就能依赖用户偏好做匹配判断。我们在冷启动物品上叠加知识侧描述后新品曝光召回率提升了约5个百分点效果还是明显的。4.4 线下效果好线上业务指标波动大这是推荐系统的经典难题LLM场景也不例外。原因之一是离线评估用的是日志回放用户行为是过去式而线上是实时交互行为分布每时每刻都在变化。原因之二是离线评估只衡量了推荐准确度而线上指标包含了用户对推荐结果的即时反馈比如点击、停留时长、下单率这些环节受推荐位、视觉展示、文案吸引力的综合影响。应对方式有三步。第一先做小流量A/B实验不要全量上线观察至少一周第二同时监控多个指标不要只看CTR还要看人均推荐位点击数、用户会话深度等长线指标第三准备预案一旦核心业务指标低于基线立即触发自动回滚。只要回滚机制足够快即使线上有波动影响也能控制在可接受范围内。5. 项目收官几条执行层面的建议整个项目从方案设计到线上稳定运行我最大的体会是文本化不是一锤子买卖而是一个需要持续调优的基础设施。它不像模型结构或训练策略那样高调但它的质量直接影响LLM推荐的天花板。很多团队在模型上砸了大量资源却在日志到语言的这个环节草草了事最后效果达不到预期这是很可惜的。我给即将做同类项目的同学三条建议。第一文本化方案一定要和业务方一起定义信息取舍和模板设计不能只由算法团队拍板业务方对哪些信号关键、哪些描述准确最有发言权。第二把文本化当作独立的模块来设计和维护不要散落在业务代码里否则后期优化会非常痛苦。第三从一开始就建立模板版本管理和线上监控文本化的语义变化对推荐效果的影响往往滞后于模型参数变化没有监控很容易踩坑而不自知。还有一个具体的小技巧所有模板在发布前批量生成一批样例提示词逐条人工阅读一遍。模型对文本语义的细微变化非常敏感一段看起来没问题的描述实际可能给模型传递了错误暗示。这个“人工过一遍”的动作成本很低但能挡掉大量线上问题。推荐系统的复杂之处在于有时候决定效果的恰恰是这些看起来不起眼的细节。