美团搜索 3.0 的一个重要方向，是把生成式大模型带来的语义理解能力，逐步转化为本地生活搜索排序可以稳定使用的信号。服务零售场景中的查询、商品、门店和用户意图往往表达不完整，单纯依赖关键词匹配容易错过真正相关的结果。LLM 语义表征提供了另一条路径：先把复杂文本映射为更有概括能力的向量或语义特征，再将这些信号交给排序模型学习。
这条路径并不是把一个大模型直接塞进在线排序链路，而是经历了从单点特征验证、系统性表征体系构建，到跨场景迁移复用的渐进过程。
三期实践：从一个特征到一套体系
第一阶段的重点是验证语义表征是否真的能补充传统搜索特征。团队可以选择查询与商品标题、查询与门店描述等匹配关系，使用 LLM 生成文本向量，再计算相似度并作为排序模型的输入。这个阶段的价值在于快速回答一个关键问题：语义匹配信号是否能识别词面不同但意图相近的结果。
例如，用户搜索“适合带孩子的火锅”，结果文本可能写成“亲子友好、设有儿童活动区的火锅店”。两者没有完全相同的关键词，但语义上高度相关。向量相似度能够提供关键词倒排之外的补充证据。
当单点实验取得收益后，第二阶段需要解决的是表征体系问题。查询、商品、门店、类目、属性和用户行为分别承载不同信息，单一向量很难覆盖所有排序任务。因此，实际系统通常需要围绕多个对象和关系设计特征：
- 查询与标题的语义相似度，捕捉改写、同义表达和长尾意图。
- 查询与类目或属性的匹配度，判断结果是否满足约束条件。
- 商品、门店和服务描述的语义表征，降低文本写法差异带来的影响。
- 基于行为样本构造的语义关系，帮助模型学习曝光、点击和转化之间的关联。
第三阶段则关注跨场景迁移。服务零售搜索包含餐饮、酒店、休闲娱乐、商超等多个业务场景，各场景的文本风格和用户意图不同，但底层的语义匹配能力存在共性。一个成熟的表征体系应尽量学习可复用的语义关系，再通过场景特征或轻量适配，让排序模型处理业务差异。
为什么不直接在线调用大模型
在线排序对延迟、吞吐、稳定性和成本都有严格要求。直接让 LLM 对每个查询和候选结果逐条推理，通常会引入不可接受的计算开销，也会让服务依赖外部模型的可用性。更可行的工程路径是离线或准实时生成表征，在线阶段只执行向量计算、特征查表和常规排序模型推理。
一种典型链路可以拆成四步：
- 统一清洗查询、商品和门店文本，保留必要的业务字段。
- 使用同一语义编码器生成向量，并写入特征存储。
- 在线召回或排序阶段计算查询向量与候选向量之间的相似度。
- 将相似度和传统特征一起输入排序模型，由模型学习不同信号的权重。
下面是一个可以改造成离线特征任务的最小 Python 示例。示例使用 Sentence Transformers 生成查询和商品文本的向量，并计算余弦相似度；生产环境需要替换为公司内部模型、批量推理服务和特征存储。
运行前安装依赖：
pip install sentence-transformers
可运行示例：
from sentence_transformers import SentenceTransformer
from sklearn.metrics.pairwise import cosine_similarity
model = SentenceTransformer("sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2")
query = "适合带孩子的火锅"
candidates = [
"川味火锅，深夜营业",
"亲子友好火锅店，设有儿童活动区",
"精品日料，提供午市套餐",
]
query_vector = model.encode([query], normalize_embeddings=True)
candidate_vectors = model.encode(candidates, normalize_embeddings=True)
scores = cosine_similarity(query_vector, candidate_vectors)[0]
for score, text in sorted(zip(scores, candidates), reverse=True):
print(f"{score:.4f}\t{text}")
这个例子只展示了语义匹配特征的生成，不等同于完整排序策略。实际使用时，还应加入价格、距离、营业状态、库存、历史点击率等强业务特征，并通过离线指标和线上实验确认语义信号是否带来真实收益。
表征质量之外的工程问题
语义表征进入排序系统后，难点不只在于选择更大的模型。
数据和样本决定上限。 点击和转化行为存在位置偏差、曝光偏差及场景偏差。若直接把行为数据用于训练，模型可能学到“排在前面所以被点击”，而不是“语义上更相关”。样本构造、负样本选择和时间切分都需要与排序目标保持一致。
向量版本必须可管理。 编码器升级后，同一条文本生成的向量可能发生变化。特征表需要记录模型版本、文本处理版本和生成时间，排序服务也要确保查询向量与候选向量处于兼容版本。否则，线上分数变化很难定位。
语义相似不等于业务满足。 “附近可停车的咖啡店”不仅要求文本语义相关，还要求距离、停车设施和实时营业状态成立。LLM 表征适合补充软匹配信号，不能替代结构化约束和实时业务校验。
跨场景迁移需要校准。 餐饮和酒店的点击、交易以及文本分布不同，同一个相似度分数在不同场景中的含义可能不一致。迁移时应检查分数分布、特征贡献和各场景的线上指标，必要时使用场景化归一化或单独的适配层。
落地时可以怎样分阶段
可以把实践拆成一条可观测的迭代路线：
- 选择一个明确的排序痛点，例如长尾查询、同义改写或复杂属性匹配。
- 先离线生成少量语义特征，与现有排序模型做增量对比。
- 固定模型和数据版本，记录覆盖率、延迟、资源消耗及不同场景的收益。
- 在线实验中同时观察相关性指标和业务指标，避免只优化点击率。
- 在收益稳定后扩展到更多对象、关系和业务场景。
- 为向量生成、特征服务和排序模型建立回滚与版本切换机制。
LLM 语义表征的价值，不在于用一个模型替换整个搜索系统，而在于把原本难以编码的语义匹配关系变成排序模型可以利用、评估和复用的信号。对本地生活搜索而言，最稳妥的路径是从具体问题出发，以离线特征验证价值，再逐步构建统一表征体系，最终让跨场景复用成为工程能力。