LLM 语义表征进搜索排序，工程上先看成本和回滚
本文由本站基于公开热点摘要整理和原创分析生成，原文来源：美团技术团队《美团搜索3.0：LLM 语义表征在排序模型的探索与应用》。
先别急着把它看成模型故事
基于公开摘要可见，美团这篇文章讲的是把 LLM 语义表征用到服务零售排序里：先做单点特征验证，再搭一套更系统的表征体系，后面还尝试跨场景迁移复用。听起来是算法团队的活，但我第一反应不是“效果涨了多少”，而是这东西如果真压到线上链路里，谁来保证它稳定、便宜、可回滚。
搜索排序是很怕抖的系统。用户敲一个词，后面可能串着召回、粗排、精排、重排、广告、风控、埋点，任何一段加了重模型特征，都可能把延迟和资源账单带起来。LLM 语义表征的吸引力很直观，它比传统稀疏词特征更懂语义，也更容易处理“用户想要的东西”和“商家提供的东西”之间那些不完全同词的匹配。但它不是免费午餐。
真正麻烦的是特征怎么进生产
这类方案落地时，最先卡人的往往不是训练代码，而是特征生产链路。Query 侧表征能不能实时算？Item 或商户侧表征多久更新一次？缓存命中率怎么样？如果模型升级，旧向量和新向量能不能共存一段时间？这些问题不漂亮，但会直接决定上线方式。
我更关心灰度和回滚。排序模型引入新的语义信号后，线上效果可能不是均匀变好。有些品类受益，有些品类可能被误伤；大城市样本多，小城市长尾更敏感；热门 query 容易被缓存兜住，冷门 query 的开销却可能悄悄堆起来。要是没有按场景、品类、流量层级拆监控，出问题时只能看一个总指标，然后大家在群里猜。
跨场景复用听着省，边界要画清楚
摘要里提到跨场景迁移复用，这点很有工程味。大模型表征贵，能复用当然好。一个语义底座服务多个业务，理论上可以少训几套模型，少维护几条特征流水线。小团队尤其会喜欢这种做法，因为人少，重复建设很快就会变成值班负担。
但复用也容易把问题藏深。外卖、到店、零售的 query 形态和用户意图不一定一样，同一个“附近买药”和“附近火锅”背后的排序约束差很多。语义向量可以共享，业务侧的解释、过滤、降级策略未必能共享。我的习惯是先把公共表征当成底层能力，再给每个场景留足特征开关和降级入口。别把所有业务绑在一个看似统一的黑盒上。
普通团队能学什么
不是每个团队都有美团这种搜索规模，也不一定需要把 LLM 表征塞进排序模型。更现实的借鉴是：先找一个边界清楚的场景做验证，比如站内知识库搜索、客服工单匹配、商品标题和类目的语义召回。先离线算，先缓存，先把成本打明白，再谈实时化。
如果这东西要进生产，我会先列四张表：延迟预算、特征更新频率、失败降级方案、效果监控口径。模型效果当然要看，但工程上更怕的是上线后没人知道它什么时候坏了。语义表征是好工具，尤其适合补传统关键词匹配的短板；可一旦进入核心排序链路，它就不再只是一个模型，而是一段需要长期维护的基础设施。
