过去三年,有两条趋势在同时发生。
一是基座模型的能力持续进化,它带来的结果是对使用者的要求在往下降。早期要让模型稳定地按格式输出、正确地选中一个工具,需要反复打磨 Prompt、设计各种兜底。现在这些能力越来越多地由模型本身承担,长上下文、原生工具调用、更强的指令遵循和多步推理,把大量原本需要工程去补的地方补上了。
二是 Agent 框架的功能持续丰富。从早期需要自己实现规划、记忆、工具注册和状态管理,到现在框架和协议层把这些抽象成标准组件,接一个工具、加一个 Skill,工作量都在显著下降。
两条曲线叠加,结论很直接:搭建 Agent 门槛正在逐年降低。这带来的直接变化是 Agent 落地场景越来越多,越来越发散。
自 2022 年底 ChatGPT(基于 GPT-3.5)发布以来,市场上出现了一波又一波 Agent 项目。但是那些真正走过冷启动、完成灰度扩量、推到全量的项目数量屈指可数。这导致掌握 Agent 评测方法的人非常稀缺。
过去三年绝大部分 Agent 项目都死掉了。它们消失的原因有一些共性:
这三种死法看起来不同,追下去会发现共同点:团队缺少一套可靠的判断机制。不知道当前版本行不行,不知道问题出在哪一层,不知道改完是真的变好还是换了个地方出错,也不知道怎么向外证明这件事的价值。做决策靠的是感觉和个别案例,而感觉在复杂系统面前不可靠。
把两件事放在一起看,会得到一个略显割裂的图景:搭 Agent 的门槛在快速降低,把 Agent 做好的认知却仍十分稀缺。并且,有限的评测认知面对发散的场景,同样力不从心。做好一个 ChatBot 的经验,并不能无缝泛化到做一个长程 Agent 身上。为此,我们希望将团队两年来在众多业务方中打磨出的评测的认知,以体系化的形式分享给大家,希望能帮大家少走一些弯路。
前不久,我们发布了一篇博客《Agent 评测漫谈》,介绍了评测的核心方法论,回答的是“评测是什么、为什么这么做”。文章发出后,我们收到不少的反馈,其中出现频率最高的一类是:方法论看了,但具体到自己的项目,还是不知道从哪下手。
为此,我们计划撰写《Agent 评测白皮书》系列博客,体系化地为大家讲解评测的落地指南 —— 先做什么后做什么,每一步的产出物长什么样,做到什么程度算达标,遇到常见的坑怎么处理。计划分四篇:

本系列博客面向 Agent 产品、研发、算法、运营和评测负责人。如果你正在从零开始搭一个 Agent,或者手里的项目卡在某个阶段推不动,希望这几篇能提供一些可以直接用上的东西。
这里也需要强调一下:评测是一门实践科学,本系列给出的做法来自我们评测团队在美团多个业务的实践,它们在各自的场景里被验证有效,但迁移到新场景时仍然需要结合业务特点做调整。比起照搬步骤,更值得关注的是每个做法背后要解决的问题。理解了问题,做法自然可以因地制宜。
第一篇《评测全览》目的在于让大家系统地了解评测的构成,我们用一套统一的语言对齐行业内尚在发散和纠缠的概念,用一套叙事逻辑打通冷启动、扩量和自进化。有了全览之后,大家可以以终为始,判断自己现在处在哪里、下一步补哪一块。完备的评测体系可以概括为四个模块、三种能力、两条 Loop、一套资产。
评测的核心目的是回答两个问题:Agent 好不好?到底哪里好、哪里不好?前者给出判断,后者指明方向。一套完备的评测体系必须同时回答这两个问题。
在《Agent 评测漫谈》一文中,我们认为评测是一套“精密量具”,这个类比其实包含两个隐喻:
第二点是评测贴近真实业务场景、消除独裁者偏差的关键手段,但却是最容易被忽略的。
理想的评测体系是一套持续运转的系统。它由两条 Loop 构成,二者共享同一批线上真实样本,通过 Case 挖掘与归因这个枢纽相互咬合。

第一条:评测体系迭代 Loop(评测演进)
Agent 上线后,在线评测和在线监控开始持续产出异常信号。这些信号背后的线上真实样本,经过 Case 挖掘进入 Case 池,再经过归因判断问题性质。如果归因结论是“评测集没有覆盖这类问题”,那么这个样本就应该补充进评测集;如果归因结论是“评测标准判错了”,那么迭代评测是 Metrics 和 Rubric 本身。这条 Loop 让评测集从冷启动人工搭建逐步逼近真实用户的反馈,逐步消除前文博客中提到的独裁者偏差。
第二条:Agent 迭代 Loop(Agent 演进)
同样是这批线上真实样本,经过 Case 挖掘和归因之后,定位到 Agent 本身的问题点——可能是 Prompt 写得不够明确、某个 Skill 的描述导致路由错误、上下文管理丢了关键信息,或者模型能力确实不够。研发据此做出变更,变更后用评测集回测,确认没有引入退化,再上线 AB 观察真实效果。这条 Loop 让 Agent 的能力持续提升,同时保证每次提升不以牺牲已有能力为代价。
除了 Case 挖掘和归因这个显而易见的咬合点,其实还有第二个咬合点——评测资产(评测集)。评测体系迭代 Loop 的产出是更完善的评测集,回测的门禁价值就越高;回测门禁越严格,Agent 上线后暴露的新问题就越少。从而形成正反馈。
把两条 Loop 放在一起看,完备的评测体系要同时具备三种能力,并沉淀评测资产(评测集)。

评测资产(评测集):
这三种能力运转起来后,会沉淀下可复用的资产,它们才是评测体系真正的长期价值。
但“什么叫好”的共识和“踩过哪些坑”的记录会随着 Agent 扩量而持续扩充。从这个意义上说,评测体系建设的本质,是把团队对业务质量的隐性认知,转化为可量化、可复用、可传递、可自动执行的显性资产。
从评测体系的视角,可以拆解出四个模块。前三个模块分别回答不同的问题,第四个模块是前三者的地基。


关于模块划分的说明
业界和开源领域对离线评测的定义非常清晰,而在线评测、在线监控、观测以及 Case 挖掘与归因这几个模块彼此之间存在模糊地带,例如 Arize AI、LangFuse、Braintrust 对这几个概念的划分就不尽相同。例如有的产品把“Online Evaluation”和“Monitoring”合并成一个概念,有的把 Trace 采集归入 Observability 而把 Trace 分析归入 Evaluation。
由于行业内没有形成统一的概念划分,为了方便后续讨论中的概念对齐,以及用一套框架贯穿冷启动、扩量和自进化,我们拆解出上面这四个大模块。读者在实践过程中可以按自己团队的组织方式重新切分,不漏掉任何一项职责即可。
一个贯穿全文的例子
为了让后面的讨论有实感,我们先约定一个贯穿全文的场景——商家经营分析 Agent(对应内部的商家 Claw 类场景)。

这个场景的特点是典型的长程 Agent:多步骤、多 Skill 调用、有中间产物、与环境频繁交互、没有唯一正确答案。后面每讲一个模块,我们都会回到这个例子上看它具体长什么样。
离线评测的核心作用在于 Agent 版本变更后的回测,可以作为上线前的门控。它依赖:固定评测集(固定样本和固定评测标准)、尽可能贴近生产的固定执行环境。
当 Agent Harness 的任何一个环节发生变化——模型升级、Prompt 调整、知识库更新、Skill 新增或下线——都可以通过离线评测验证效果,避免不成熟的变更导致 Agent 能力劣化。
为什么强调“固定”
回测的本质是控制变量对比:只让 Agent 版本变化,其他一切保持不变,这样分数的差异才能归因到版本变更上。
实践中最容易被破坏的是执行环境。比如评测时调用的是测试环境的下游接口,而测试环境的数据和生产不一致;或者沙箱里没有预置用户的历史文件,导致 Agent 拿不到必要的上下文。这类环境差异会让离线分数和线上表现系统性偏离,最终让团队不再信任离线评测。
一个实用的检验方法:拿同一批样本,分别在离线环境和线上影子流量里跑一遍,看两边的结论是否一致。差异过大,说明环境保真度不够。
广义的评测集由(问题、参考答案、评价标准)三元组构成,其中问题-参考答案合起来称作评测样本。这个概念最早出自大模型评测领域,如今被借用到 Agent 评测领域。
但随着 Agent 形态从 ChatBot 演进到长程 Agent,这三元组的具体含义也在发生迁移:

这个迁移背后是一个根本性变化:Agent 评测从“答案评测”走向“行为评测”。短程场景下,参考答案是一个可以逐字比对的字符串;长程场景下,参考答案变成了一段对执行过程的描述,评测要看的是 Agent 走过的路径是否符合预期,以及最终环境状态是否达成目标。
借用 Anthropic《Demystifying evals for AI agents》文中对长程 Agent 评测 Task 定义:为“具有明确输入和成功标准的单个测试”,这个概念同样可以泛化到短程 Agent 领域。
借用这个概念,评测集的每一行三元组都可以看做一个 Task。
具体而言 Task 里要有固定输入,比如 Query / answer,或者 prompt / expected behavior;评价部分由 Metrics 和 Rubric 构成,其中 Rubric 是最小粒度的评测标准。

一个完整的 Task 大致长这样:

《Agent 评测漫谈》中强调的二元化 Rubric思路就是用在这里的:把“这个 PPT 做得好不好”这种模糊判断,下钻成一组可以回答是/否的具体检查项,从而将模糊的问题尽可能量化,消除分歧。人人一致率和人机一致率的提升,本质上都来自这种下钻。
评测集总体上可以分成两类:端到端评测集和过程评测集。每一个评测集都由上文的三元组构成。
对于端到端评测和过程评测,都可以建立我们常说的黄金集、必过集,这两套概念彼此独立不冲突。

为什么两类都需要?端到端评测集看的是最终结果,重点回答“事有没有办成”;过程评测集看执行过程,回答的是“中间哪一步出了问题”。回到商家经营分析的例子。端到端评测集告诉你“100 个任务里有 68 个交付了可用的 PPT”,端到端交付率是业务方最关心的数字。但当这个数字从 68 掉到 55 时,端到端评测集无法告诉你原因。而过程评测集可以:如果“投放数据 Skill 调用成功率”从 95% 掉到 70%,问题就定位到了;如果 Skill 成功率没变、但“数据合并正确率”下降,问题就在另一处。若过程评测集指标未发生波动,但端到端交付率降低,则说明发生了未知异常,需要我们进一步挖掘和归因从而迭代评测集。
一个实用的经验:端到端评测集回答“要不要拉响警报”,过程评测集回答“警报响了该找谁”。只有端到端,你会陷入“知道坏了但不知道哪坏了”;只有过程,你会陷入“每个模块都达标但用户就是不满意”,二者相辅相成。
再次强调,端到端评测集是站在用户视角建立的。也就是说当 Agent 功能逐渐增加之后,需要按照端到端的功能模块建立不同的端到端评测集。例如商家 Agent,门店经营是一个核心功能模块,由若干个 Skill 构成;门店百科又是一个核心功能模块,由查数 Skill 和门店知识库构成。这种情况应该分别建立端到端评测集。
过程评测集还可以继续往下拆。比如知识库相关的问题,可以单独沉淀成知识库评测集;具体 Skill 调用相关的问题,可以沉淀成 Skill 评测集。后面业务长出新的子场景,也可以继续往下拆。
评测集要随着 Agent 的功能发展、随着问题的出现而不断细化。以商家经营分析为例,可以拆成这样一棵树:

拆解带来的一个额外收益是责任清晰。当过程评测集和组织分工对齐后,某一层的分数下降,就能直接找到对应的负责人,而不需要先开一轮会来确定“这是谁的问题”。
拆解的边界:不要过早拆得太细
分层拆解是演进的结果,不是设计的起点。《Agent 评测漫谈》博客中明确提到评测是一门实践科学,与其设计精妙的评测体系,不如抓住核心场景先跑起来。
正确的顺序是:先建端到端评测集和核心模块的过程评测集跑起来,遇到“知道坏了但不知道哪坏了”的情况,再进一步丰富。让拆解被真实问题驱动,而不是被完备性焦虑驱动。这一点在《冷启动篇》会详细展开。
Agent 发生变更时,评测集起到门控的作用。通过回测,我们能保证变更前后核心链路、核心指标的一致性。但“跑一遍评测集”和“建立有效的回测机制”之间还有距离。几个关键的工程考量:
离线评测的固有局限
必须清醒认识到离线评测能力的边界。它只能发现已知的问题——评测集里没有的场景,回测永远测不出来。
例如商家经营分析的场景:如果评测集里全是“制作 PPT”类任务,那么当用户开始大量提出“帮我对比三家门店的数据”这种新需求时,固定的离线评测集显然无法覆盖到新出现的 Case。
这正是为什么完备的评测体系必须包含在线部分——离线负责守住已知,在线负责发现未知。
离线评测做得再丰富多样,也是无法穷举所有场景的,而在线评测接受真实世界得分反馈,则可以弥补这部分短板。
在线评测和在线监控处理的是线上真实运行时的质量观察。二者关注的层面不同,但有一块重要的交集 —— 巡检。
一个直观的区分:在线评测回答“系统工作得好不好”,在线监控回答“系统有没有在正常工作”。前者是质量视角,后者是运维视角。Skill 调用成功率 100% 但每次都返回了错误的数据,监控是绿的,评测是红的。

三者的互补关系:影子模式在上线前用真实流量兜底,AB 在上线后确认业务价值,巡检在日常持续盯住基本盘。
巡检处在在线评测和在线监控的交集上,核心作用是持续监控线上 Agent 效果的稳定性。巡检是业务上把“线上质量观察”变成“持续可追踪过程”的常用手段。最常见的做法是从离线评测集中抽取一部分代表性的 Task 用于周期性检查线上 Agent 的表现,随着评测精细化,也可以单独维护一套巡检评测集。巡检同时具备两种属性:
回到商家经营分析的例子,一套合理的巡检可以这样设计:

在线监控关注的是运行指标,工程中常见的大量稳定性指标,都在在线监控的范围内。常见的监控维度包括:
稳定性指标和行为监控类指标要放在一起看,才能得出有意义的结论。举例来说,任务完成率下降 5 个点,如果同时观察到某个 Skill 的失败率从 2% 涨到 15%,那结论极大概率是工程问题;如果 Skill 都正常,但“数据对比类”任务占比从 10% 涨到 35%,那结论是用户结构变了、Agent 在新场景上能力不足——这两种情况的应对完全不同。这就是 Case 挖掘和归因的范畴了。
Case 挖掘与归因主要承接在线评测和在线监控中暴露出来的问题线索,同时也接收线上反馈、真实样本采样和业务规则筛出的样本。
职责分工上:Case 挖掘负责把样本收进 Case 池,归因负责继续往下定位,判断 Agent 流程里的核心问题点。
这个模块是整个体系的枢纽,也是当下火热的“Agent 自进化”的核心切入点。

四类来源需要搭配使用,因为它们的“盲区”不同。只靠线上反馈,你只能看到用户愿意抱怨的那部分问题;只靠监控,你只能看到能被指标刻画的问题;只靠规则挖掘,你只能看到自己已经想到的风险。随机采样是唯一能发现“你根本没想到的问题”的手段,虽然它成本最高、命中率最低,但不可省略。
挖掘出来的样本进入 Case 池后,可以继续区分为 Good Case 和 Bad Case,分别沉淀成不同类型的资产:

错题集是回报最直接的一类资产。它的逻辑很朴素:每一个曾经犯过的错,都不应该再犯第二次。
而黄金集的价值容易被低估。Bad Case 告诉你哪里不行,但它不能告诉你“到什么程度才算行”。没有黄金集,团队在讨论质量时只能各说各话;有了黄金集,“我们要做到这个水平”就变成了一个可以指着看的具体样本。
归因的目标,是定位 Agent 流程里的核心问题点。一个 Bad Case 只能说明“这里出了问题”,还不能说明“为什么出问题”。
归因要继续判断问题发生在哪个环节:常见的做法是将 Agent 执行过程全链路铺开,通过 Trace 日志逐一定位问题点,这个过程与软件问题排查过程中看日志查 bug 高度雷同。正因如此归因高度依赖观测基建 Trace。这个过程可以由人工完成,也可以由机器辅助完成。
一个可操作的归因分层,大致如下:

归因明确之后,正向 Case 一般可以归入评测集中的黄金集、挑战集;负向 Case 则会进入两条不同的路径:

很多团队只走了第一条路径——默认“评测说不行就是 Agent 不行”。这种默认假设会带来一个隐蔽的问题:Agent 会被优化成“迎合评测标准”,而不是“解决用户问题”。当评测标准本身有偏差时,优化得越努力,偏离真实需求越远。定期检查“是不是评测判错了”,是评测体系自我校准的必要动作。
《Agent 评测漫谈》里有一个朴素的表述:看不见的问题,几乎不可能被稳定解决。观测的核心价值在于让 Agent 链路白盒化。这也是 Agent 研发公式“观测 + 评测 = 持续迭代”中,观测被放在第一位的原因。
Agent 的一次执行是一条长链路:用户输入 → 意图理解 → 任务规划 → 工具/Skill 调用 → 环境交互 → 中间结果处理 → 策略调整 → 最终输出。只要其中任意一层出问题,最终效果都可能劣化。但如果系统只能看到“用户说了什么”和“最后回复了什么”,就几乎无法判断问题根因。这正是工业界发展出 Trace 系统的动因——将黑盒内部的推理过程进行全路径披露,把所有影响模型输出的输入信息都记录下来。前篇博客中已经充分论述了观测之于评测的意义,这里不再赘述。
从 Trace SDK,到如今集成在 OpenClaw、Claude Code 当中的 Trace Plugin。观测基建也随着 Agent Harness 高速迭代。
综合前面的讨论,一套支撑完备评测体系的观测基建,至少应该具备以下能力:

由于 Agent Harness 迭代太快,哪怕是开源社区,相关基建也是落后于需求的。观测是地基,但这不意味着必须项目启动之初就需要建立一套完备的系统 。实际落地过程中,观测指标、观测基建也是需要基于需求反向设计的。判断标准很简单:当你发现“想自动化判断某件事,但数据里没有”的时候,就是补埋点的时候。
一个务实的建设思路是:先保证“最小可归因”——至少能拿到完整的模型调用输入输出和 Skill 调用记录,能凭 Trace 复现一个 Bad Case 到底发生了什么。这是冷启动阶段的底线,也是《冷启动篇》会重点讨论的内容。

实践中,我们观察到各业务方评测体系三种最常见的“部分完备”形态。它们各自能解决一部分问题,但都存在明确的能力缺口。

第三种形态最值得警惕,因为它看起来最“完备”——既有评测集又有监控看板,汇报时数据很齐全。但由于缺少中间的枢纽,两套体系是割裂的:线上发现的问题回不到评测集,评测集的结论也解释不了线上现象。这种形态往往投入不少但收效有限,团队容易陷入“我们该做的都做了,为什么还是这样”的困惑。
最后,把前面的讨论收敛成一张可以直接使用的自查表。建议对照打分,找出自己业务最短的那块板。

如何使用这张表?
不要追求所有维度都达到 L3。不同业务阶段对应不同的合理水位:冷启动阶段,观测 L1 + 评测集 L1 + 回测门禁 L1 就足以支撑起最小闭环;扩量阶段,重点是把评测标准和在线评测推到 L2,少量指标推到 L3;全量运营阶段,才需要考虑 L3 的自动化与规模化。
更有价值的用法是看“短板”和“错配”。如果你的评测标准已经到了 L3(机评规模化),但 Case 挖掘还在 L0(靠用户投诉),那么再精密的机评也只是在重复评测已知的样本——投入应该转向补齐挖掘能力。体系的能力上限,由最短的那块板决定。
回到本篇开头的问题:一套完备的评测体系长什么样?可以概括为四个模块、三种能力、两条 Loop、一套资产:
需要强调的是,这张全景图是“终局”而不是“起点”。没有任何一个团队应该照着这张图从头到尾建一遍——那既不现实,投入产出也不划算。
《Agent 评测漫谈》里有一句话值得在这里重复:Agent 评测是一门实践科学,起步阶段“让数据飞轮高效运转起来”的意义,远大于“设计一个复杂精妙的评测体系”。全景图的价值在于让你在每个阶段都清楚:我现在处在哪里,下一步补哪一块收益最大,以及某一块暂时不做的代价是什么。
那么起点在哪里?在一穷二白、没有评测集的冷启动阶段,如何实现评测飞轮的最小闭环?这正是下一篇《冷启动篇》将要回答的问题。
Q:Agent 离线评测集只用在回测吗,为什么不可以按照大模型迭代一样必须比上一次得分高才可以发版?
这个问题涉及到 Agent 的评测和大模型评测的核心差异,需要从两个方面回答。
1、Agent 为什么不像基座模型一样打榜?基座模型提供的是通用能力,可以拆解出一系列的通用能力。提醒大家,大模型评测本身也是行业极其专业的领域。目前大家看到的大模型基座能力的评价指标体系是在过去三年中无数论文堆砌而来的。这三年基座模型 benchmark 的含义本身也发生了极大的变化。而 Agent 是服务于垂直业务领域的,最佳的 Agent 指标就是业务指标,所以对 Agent 而言,上线 AB 看业务指标变化是评价其能力的黄金标准。
2、评测集可以拆分为必过集合和挑战集。显然在垂直业务领域里,挑战集的构建是极其困难的,非常容易跟不上 Agent 版本功能迭代。而必过集样本属于 Agent 核心功能,对于已知的问题必须尽可能解决才可以上线。所以日常工作中,经常会出现必考题(必过集)都会了,难题(挑战集)又见不到的情况。
综上,Agent 离线评测更多是用在回测方面,真实效果的好坏直接通过线上 AB 看业务指标。
补充:如果设立了挑战集,一定要及时更新拟合线上真实场景的分布,否则评测集不置信。
随着大语言模型、生成式AI与多模态交互技术的快速发展,数字人直播已突破早期形象僵硬、交互单一的瓶颈,在本地生活、电商、文娱等领域展现出巨大的商业潜力。美团智播,是面向本地生活场景的AI数字人直播解决方案,融合大模型、数字人与多模态交互技术,提供丰富的行业专属数字人形象,支持真人1:1复刻与门店实景定制,30秒生成直播素材,3分钟完成开播配置,7×24小时稳定上播。过去一年,依托生成式AI技术,数字人直播月日均GTV同比增长82.12%,月日均观看人次同比增长163.44%,开播场次提升11倍,充分验证了AI数字人直播在本地生活商业闭环中的实际价值。
2026年7月8日至10日,美团智播在中国互联网大会上完成行业首秀,以“实时交互数字人+直播带货数字人”为主题亮相科技互动展区。展区中,实时交互数字人通过秒级语音问答与观众自然对话,数字人直播间则让参会者发出“完全看不出是数字人”的感叹——这一亮相标志着美团智播正式从内部打磨走向行业舞台。

如何让数字人直播达到真人级表现力,并满足大规模商业化落地的要求?本文将围绕美团智播的核心能力,系统介绍支撑产品的关键技术突破——涵盖高保真形象生成、自然动作驱动、语音手势协调、高效推理部署及系统架构设计,这些技术共同构成了数字人直播从“能用”到“好用”,再到“规模化量产”的完整技术闭环。凭借这些技术积累,美团智播荣获2026年度“中国多媒体企业创新技术奖”,这一奖项由中国计算机学会(CCF)和中国图象图形学学会(CSIG)指导,中国多媒体大会(ChinaMM)设立并颁发,是对美团在数字人直播领域自主创新能力的行业认可。

美团连接数百万商家与数亿消费者,数字人直播正加速渗透商家日常运营。然而,商家直播面临四重现实困境:
更深层的问题是:现有大部分数字人方案普遍存在“一眼假”——面部僵硬、动作重复、手势与语音脱节,用户停留时长较真人主播明显偏低。如何让数字人直播媲美真人主播,是技术突破的核心方向。
数字人直播为上述问题提供了新思路,但要真正达到规模化商业可用,远非简单的视频生成任务,面临四大相互交织的技术挑战。
挑战一:形象高保真,从“一眼假”到“媲美真人”
任何面部僵硬、五官失调都会让观众一眼识破。更高要求在于:商家需要真人1:1复刻,以及换装、换背景时保持身份一致性。如何在生成与编辑全链路中同时保证高保真度与强一致性,是形象生成技术的核心难题。
挑战二:动作自然多样,从“木偶戏”到“真人感”
7×24小时直播对动作多样性要求极高。有限动作库循环播放导致观众疲劳、留存率下降;动态生成方案又面临质量不稳定、关节扭曲等问题。如何在单一模型中同时实现高质量与高多样性的动作生成,是长时直播的重大挑战。
挑战三:语音语义协调,从“念稿机器”到“音画一致”
优秀主播的手势与语义高度协调,现有技术能生成与节奏同步的自发性动作(点头、摆手),但无法产生与语义精准绑定的协调性手势。如何跨越语音与动作之间的“语义鸿沟”,是互动体验升级的关键瓶颈。
挑战四:规模化推理效率,从“单路昂贵”到“万路并发”
数字人直播系统是多智能体协同平台,如何在保证质量与实时性的前提下,高效协同多个子智能体,大幅压缩单路推理开销,是数字人直播走向普惠的最终门槛。
面对上述挑战,美团智播自研关键技术,围绕数字人主播“长得真→动得准→演得活→卖得好”形成完整技术闭环,实现全链路跃升。

商家对数字人形象有三层递进需求:快速可用(3分钟定制开播)、高度个性化(真人1:1复刻)、灵活可编辑(换装换背景时保持身份一致)。过去的定制化图像生成方法面临身份与姿态耦合、微调耗时长、编辑破坏身份特征等核心问题。
针对数字人生成中身份保真与灵活编辑的双重挑战,美团智播研发团队提出了结构解耦身份个性化(SDIP)和自奖励精准编辑(SREdit)技术方案。
SDIP(Structure-Decoupled Identity Personalization)的核心思想是将姿态、身份、背景三个维度进行结构性解耦,包含两个核心模块:
商家日常运营中常需对数字人进行局部编辑——换应季服装、匹配活动背景、调整妆容。核心约束是:编辑前后身份特征必须保持一致,不能“换了衣服就认不出人”。
针对这一需求,团队提出了SREdit(Self-Rewarding Editing),被ACM MM 2026收录。其技术创新体现在三个层面:
实验结果表明SREdit在公开数据集GEdit-Bench、ImgEdit-Bench、KRIS-Bench上整体性能提升2.5%~3.8%,视觉效果上在保持身份一致性的前提下达到了业界领先的编辑精度。

数字人图像生成与编辑效果示例:

7×24小时数字人直播介绍商品时,不同商品需要不同风格的动作配合,这对动作生成系统提出双重挑战:保证单个动作质量(流畅、自然、物理合理),同时保证长序列的多样性和可控性。
美团智播团队提出的多级因果LLM动作生成MoTiGA(Motion generation via multi-level causal Transformers with LLM-Guided Alignment)方法,被CVPR 2026收录,MoTiGA将大语言模型的自回归生成范式引入人体动作生成,通过多级因果结构和偏好优化实现质量与效率的双重提升。
实验结果表明,MoTiGA在HumanML3D数据集上FID为0.041(较基线降低82.3%)、在KIT-ML数据集上FID为0.180(较基线降低64.7%),生成的动作序列与真实人体动作分布高度吻合,达到了接近真人的自然度与流畅度。

真人主播说“这款披萨用料非常足”时会张开双手比划量大,说“请看右边链接”时手指会指向右侧,这种语音与手势的协调是观众判断“数字人是否像真人”的重要线索。现有技术主要关注“自发性手势”(点头、摆手),缺乏与语义内容的深度绑定,无法精准生成“指向商品”、“比划大小”等协调性手势;在模型设计上,传统方案采用全局去噪架构,需等待整段语音结束后一次性生成全部动作,无法满足直播场景对实时性和无限时长的要求。
StreamingTalk 的核心创新在于将全局去噪过程重构为流式因果生成架构,首次实现了非自发性协调动作的流式生成,支持数字人说话时实时、连续、可控地生成同步手势动作,论文已投稿AAAI 2027,其核心技术创新包括:
StreamingTalk首次验证了流式Flow Matching可在恒定延迟、恒定内存下生成无限长高质量手势流,为数字人从“能动但僵硬”升级为“实时演、持久演、灵活演”的高表现力提供了核心技术支撑。

美团智播直播场景具有显著的规模化特征:数以万计的商家需要同时开播,每一路直播都需要实时的视觉理解、智能交互和画面渲染。按照传统的多模态大模型推理方式,每一路直播需要处理大量的视觉token,单路GPU占用高昂;当并发量达到万路级别时,大模型推理成本将成为产品普惠化的根本瓶颈。因此,如何在保证生成质量的前提下大幅压缩视觉推理开销,是产品普惠化的关键。
美团智播团队提出的Glance2Gaze方法被NeurIPS 2025收录,通过创新的视觉Token压缩策略,在几乎不损失模型性能的前提下实现了75%的Token压缩率和2.5倍的推理加速。其命名灵感来自人类视觉系统的“扫视-注视”机制:人眼首先通过快速扫视(glance)获取场景全局信息,然后通过注视(gaze)聚焦到关键区域获取细节信息。
这种“嵌入式渐进压缩”设计有三个关键优势:压缩过程能够利用LLM的语义理解能力,更智能地判断哪些视觉信息冗余、哪些关键;渐进压缩避免了一次性大幅压缩导致的信息断崖式丢失;完全兼容FlashAttention-2,可以直接部署到现有推理基础设施,无需额外工程适配。

实验结果表明:Glance2Gaze实现了75%的视觉token压缩(576→144),模型在各项视觉理解任务上的性能损失控制在2%以内,推理速度提升2.5倍,将并发成本降低了60%以上。

单项技术的突破只是基础,如何将多项技术整合为一个高效协同的系统,才是产品落地的关键。美团智播在系统层面构建了“双引擎驱动”的技术中台架构,实现实时交互与内容量产的双重能力。
实时交互引擎是美团智播应对“用户即时互动”场景的核心组件。当观众在直播间提出问题或触发互动时,系统需要在极短时间内完成“语义理解→回答生成→动作合成→画面渲染”的全链路响应。美团智播的实时交互引擎实现了全双工通信,系统并行调度形象、文本生成、数字人驱动等核心能力,通过流式连接,前一阶段部分输出即触发下一阶段计算,最大限度压缩总体延迟。
对于日常直播中的商品讲解、活动介绍等“计划性内容”,美团智播构建了多智能体协同的内容量产引擎。该引擎采用“创意-检索-思考-生成-评测”的五阶段协同架构:
这种多智能体协同架构使得内容生产实现了“工业化流水线”模式,单条商品讲解视频的生成时间从人工制作的数小时缩短至分钟级,且质量稳定可控。

支撑双引擎高效运转的,是美团智播精心构建的三大知识库:
美团智播在系统设计上遵循了“形象-动作-场景”三维解耦的核心原则。数字人形象、肢体动作、直播场景三个维度完全独立管理,可以自由组合复用。这种解耦架构使得同一形象可搭配不同动作风格、同一套动作可应用到不同形象、同一场景可快速切换不同主播,组合式复用大幅降低了内容生产的边际成本,使“千人千面”的个性化直播成为可能。
美团智播已在多个业务线实现规模化落地,核心指标表现亮眼:定制化数字人模特从需求到上线仅需3小时,相比传统的定制拍摄效率提升超10倍;商家闲时交易额平均提升7.3%,7×24小时不间断开播有效填补真人主播休息时段的流量空白;整体开播效率提升60%,AI自动生成话术、装修直播间、触发营销动作,将商家从繁琐的直播准备中解放出来。
展望未来,美团智播将在以下方向持续演进:
参考文献:
ACL(Annual Meeting of the Association for Computational Linguistics)是计算语言学和自然语言处理(NLP)领域的国际顶级学术会议,是CCF-A类会议,也是中国计算机学会推荐的自然语言处理方向最高等级国际学术会议。ACL 2026杰出论文奖(Outstanding Paper)在圣地亚哥揭晓,全球共 18 篇入选,美团履约技术团队的《GeoRA:Geometry-Aware Low-Rank Adaptation for RLVR》 就是其中之一。
RLVR已经成为提升大模型推理能力的关键范式,但它的训练开销较高,于是一个自然的技术就是用 LoRA 这类参数高效微调方法来做 RLVR。但是,LoRA 及其变体几乎都是在 SFT 场景下建立并验证的。而近期一系列机制研究表明,RLVR 与 SFT 的优化几何存在本质差异:RLVR 则更像一次受约束的优化,有效更新分散在稀疏的子空间中,并倾向于避开预训练权重的主方向。因此,把为 SFT 设计的先验直接搬到 RLVR 上,就构成了几何错位,后果是效果欠优、能力遗忘甚至训练崩溃。
针对这个问题,美团与北京大学的研究者提出了 GeoRA(Geometry-Aware Low-Rank Adaptation),把低秩适配显式地对齐到 RLVR 的更新几何上:先用几何先验定位出 RLVR 偏好的稀疏更新区域,再用 SVD(奇异值分解)把它压缩成低秩稠密的适配器。在 1.5B 到 32B 的 Qwen 与 Llama 模型上,GeoRA 在数学、医学、代码三类 RLVR 任务上稳定优于流行的低秩基线。该工作已被 ACL 2026 接收为杰出论文(Outstanding Paper)。
本文介绍了一种专为 RLVR 设计的低秩训练方法,以及它在业务 Agentic RL 中的落地经验。
以 OpenAI o1、DeepSeek-R1 为代表的大型推理模型,把 RLVR 确立为解锁复杂推理能力的关键范式。要理解为什么现有 PEFT 方法在这个范式下不够好,得先看清 RLVR 的更新究竟长什么样。
近期一批机制分析工作勾勒出了 SFT 与 RLVR 的分野,表明两者的优化几何存在本质差异:SFT 通过改写权重的主方向来显式注入新信息,RLVR 更像一次受约束的优化,它靠奖励诱导的采样偏置放大模型推理行为,有效更新分散在稀疏的子空间中,并倾向于避开预训练权重的主方向。这个画像还有另一面——RLVR 对更新稳定性敏感,它需要在类信赖域边界内做策略更新,过于激进或落在主方向上的更新则容易引发谱漂移、探索多样性坍塌乃至训练崩溃。
几何错位。LoRA 及其变体是当前的事实标准,它们的一个关键差异在于采用了什么谱先验:LoRA 用高斯和全零初始化,与预训练权重无关;PiSSA 对原始权重做 SVD,把可训练预算都分配给主奇异方向;MiLoRA 则取尾部奇异方向。这些先验主要在 SFT 场景下被设计和验证,没有考虑上一节描述的 RLVR 更新规律。以 PiSSA 为例,它把更新强行推到主成分上的强归纳偏置,恰好与 RLVR 偏好的子空间相冲突,这也预示了实验中更容易崩溃的现象。
工程错位。一种直观的做法是:既然 RLVR 只更新一小部分参数,那直接对这个子空间做稀疏微调就好了。这种方式在更新模式上确实更契合 RLVR 的偏好,但现代 GPU 对非结构化稀疏计算并不高效,减少参数量并不意味着效率提升。本文的效率实验里,稀疏微调把训练参数降低 68.0%,训练耗时却增加了 10.8%。
一边是计算友好但几何不对,一边是几何对但算不快。GeoRA 要同时解决这两个错位,目标即定位契合 RLVR 的稀疏子空间,用低秩稠密的方式去训练它。
GeoRA 可以拆成三个步骤:
整个过程只在训练开始前执行一次,属于一次性预处理;训练阶段的计算图与标准 LoRA 完全一致。
我们用两个互补的掩码(Mask)从预训练权重矩阵 W 中筛选参数区域,两者共用同一个稀疏率 ρ。
最终的几何约束矩阵取两者的并集:W_Geo = W ⊙ (M_Spec ∪ M_Euc)。

两个掩码看起来规则相似,实际选出的参数集合却很少重叠。例如,在 Qwen3-8B 上取 ρ = 0.2,两者各选中 20.0% 的参数,但交集只有 4.55%,Jaccard 相似度仅 0.128。这说明它们捕捉的是两类不同的参数区域,是互补而非冗余关系,论文中的消融实验也印证了这一点:去掉任何一个先验都会带来性能下降。
拿到 W_Geo 之后,对它做 SVD:
W_Geo = U_Geo Σ_Geo V_Geoᵀ
取前 r 个奇异分量来初始化两个低秩矩阵:
A_Geo = Σ_Geo[:r,:r]^(1/2) · V_Geo[:,:r]ᵀ
B_Geo = U_Geo[:,:r] · Σ_Geo[:r,:r]^(1/2)
这样 B_Geo A_Geo 就是 W_Geo 的最优秩-r 近似(Eckart–Young 定理保证了 Frobenius 范数下的最优性)。
这里有一个容易被忽略的要点:GeoRA 取的是 W_Geo 的 top-r 方向,而不是原始权重 W 的 top-r。适配对象的变化,是 GeoRA 与 PiSSA / MiLoRA 的核心区别。

从这个角度看,四种方法的区别可以概括为一句话:LoRA 不看权重,PiSSA 看主方向,MiLoRA 看尾方向,GeoRA 先换一个更合适的适配对象,再在其中取主方向。
最后一步是把剩余权重冻结。按照 LoRA 的缩放约定计算残差矩阵:
W_res = W − (α / r) · B_Geo A_Geo
前向传播时,W_res 冻结,只有适配器可训练:
h = W_res x + (α / r) · B_Geo A_Geo x
这个设计带来两个性质。一是初始化时函数不变,因为两项之和恰好等于 W x,训练启动时模型输出不会突变,避免了冷启动阶段的策略抖动——这对 RLVR 很重要,初期的输出扰动会污染 rollout 采样分布。二是施加了结构约束:优化器只能在 A_Geo、B_Geo 参数化的流形上更新,W_res 作为稳定锚点,防止预训练表示被破坏。
主实验在 DeepMath-103K 上用 GRPO 算法对 Qwen3-8B 和 Llama-3.1-8B 做数学 RLVR,对比对象包括 LoRA、PiSSA、MiLoRA、稀疏微调(SparseFT)和全参微调(FullFT)。同时在 4B 与 1.5B 模型上用 GSM8K 做了规模验证。

这说明在几何对齐的子空间更新,可以在提升目标域推理能力的同时,显著减少对既有能力的遗忘。
为了确认收益不局限于数学,我们在医学和代码场景做了扩展实验。

两个领域的结论一致:GeoRA 稳定优于低秩基线,并与全参微调相当。


相比全参微调,GeoRA 使可训练参数降低 99.5%,单步耗时降低 19.9%,显存占用降低 28.5%。对照 SparseFT 的数据可以看得更清楚:它虽然把参数降了 68.0%,但单步耗时反而上升了 10.8%。GeoRA 的关键工程价值,就在于把几何先验落成了稠密低秩计算,因此参数效率能够真正转化为速度与显存收益。
我们进一步做了结构性分析:W_Geo 是一个稀疏矩阵,把它压缩成秩 r 的形式,为什么损失是可控的?我们对奇异值谱做了三组分析来回答。

三组分析合起来给出了 GeoRA 的结构依据:低秩特性是 RLVR 具备的内在属性。这也解释了为什么 GeoRA 只训练 0.5% 的参数就能与全参微调效果相当——它逼近的正是 RLVR 更新本身的形态。
GeoRA 这个工作的出发点不是发论文,而是实际业务中对高效强化学习的需求。我们所处的场景是 AI 骑手招聘:由 Agent 主动触达和跟进候选人,在多轮沟通中识别其意愿、顾虑与决策卡点,针对性地制定下一步策略,进而把候选人逐步推进到面试和入职。过程上这需要类似于销售的情商、策略、话术和临场应变;目标和结果却明确、可验证(约面/入职/ROI),很适合用 RLVR 来优化;而这一垂直域场景也有着特别的训练需求组合:
一边是训练开销高,一边是增量容量小,这正是面向 RLVR 的低秩高效训练的用武之地。事实上,最早让我们怀疑「为 SFT 设计的低秩先验未必适合 RLVR」的,也是业务训练中的体感:LoRA、PiSSA、MiLoRA 之间效果差异明显,学习率调大训练就不稳甚至崩掉。这说明初始化的几何先验在 RLVR 下是一个大变量,存在优化空间。目前 GeoRA 正在 AI 招聘场景中落地,Agentic RL 实验效果:
效果:与全参训练相当,相比 LoRA 提升约 12%。

效率:与 LoRA 相当,显存相比全参训练降低 54%,若配合 QLoRA 等量化方法可进一步降低。

可见,GeoRA 用 LoRA 的训练成本取得了全参的优化效果,这正是它的应用价值。
落地时还有两点经验,也供同样想在 RLVR 中应用的同学参考:
GeoRA 是首个面向 RLVR 的优化几何设计的低秩训练方法,其核心贡献可以归纳为三点:
除论文实验之外,GeoRA 也在实际业务场景 Agentic RL 中验证,以更低的成本取得更好的训练效果。我们会继续把它推广到更多同类场景,也希望该方法能为 RLVR 的高效训练提供一个新的参考。
在大语言模型(LLM)技术的深刻影响下,搜索引擎正经历第三次范式跃迁:从 1.0 时代的“关键词文本匹配”,到 2.0 时代的“行为统计与个性化搜索”,再到 3.0 时代向“复杂意图理解与认知决策”的全面进化。
美团搜索团队正依托团垂融合新架构与生成式大模型新技术,全面重构本地生活搜索底座。本系列技术博客将持续介绍美团搜索 3.0 的技术探索,本文聚焦 LLM 语义表征在服务零售排序场景上的三期实践——从单点特征验证到系统性表征体系构建,再到跨场景迁移复用,探索语义匹配信号在搜索排序中的应用路径。
服务零售是将服务销售给最终消费者的商业活动,与之对应的概念为商品零售。服务零售和商品零售是美团零售业务的两个主要组成部分。
在美团搜索场景下,相较于到家和其他到店业务,服务零售具有以下显著特点:
传统精排模型的语义建模高度依赖文本匹配,但这类特征构建成本高、泛化能力弱,在面对服务零售大量长尾品类、复杂 Query 意图时尤为明显。例如,"宠物 SPA+洗澡"这个 Query 对应的商品名称可能是"萌宠清洁护理套餐"、"春节大扫除"这个 Query 对应的商品名称可能是"深度保洁服务套餐",在这些 Case 中,搜索词和供给在文字上几乎没有重叠,但语义上是高度相关的。
这类语义 Gap 在美团服务零售搜索场景(生活服务、休闲娱乐等)尤为突出。服务零售的品类长尾分散、商品描述非结构化、Query 意图复杂多样,传统特征工程难以覆盖。而大语言模型(LLM)在语义理解方面的能力成熟度正在快速提升,给我们带来了新的解题思路。
从 2025 年 Q4 到 2026 年 Q2,服务零售搜索排序团队系统性地探索了 LLM 在精排模型中的应用,核心方向是用 LLM 为搜索词(Query)、商家(POI)和商品(Deal)生成高质量的语义向量表征,将语义匹配信息以 cosine 相似度的形式注入排序模型,弥补传统特征在语义理解上的不足。经过三期迭代,累计完成 3 个 Launch Review(LR),均已完成全量上线,带来了显著的线上收益。
下图展示了三期技术演进的整体脉络。每一期都在前一期的基础上进行系统性升级,从验证可行性到全面优化再到跨模块迁移复用,逐步构建起一套完整的语义表征体系。

服务零售精排在语义层面的建模几乎为零,排序模型主要依赖少量文本匹配和 Query 统计类特征。所以一期的目标很纯粹:验证 LLM 表征能否对精排模型有实质性帮助。如果用 LLM 生成的语义向量能带来正向收益,就值得投入更多资源深度优化。整个一期的设计都围绕「先把路走通」。
整体思路是:选择一个轻量级的 LLM 作为基座,对 Query 和 POI 的信息进行统一建模,通过微调,使模型仅依赖文本语义来判断"这个搜索词和这个商家是否匹配",然后全量推理出 Query 和 POI 各自的语义向量,计算它们的 cosine 相似度,作为特征注入精排模型。
模型设计:特殊 Token 与信息隔离
一期选用小参数量的开源基座模型,采用全参数微调。
要提取语义表征,需要一个明确的"聚合点"——模型在哪个位置把输入文本的语义信息汇聚成一个向量。直接用序列末尾 Token 或整个 Token 序列 Mean Pooling 也可以,但缺少可学习性。一期的核心设计是在词表中新增三个特殊 Token——<|query|>、<|item|>、<|qi|>,作为专门的聚合锚点,在训练中与模型参数一起优化。特殊 Token 的嵌入采用平均初始化法,参考 vocab-expansion[1]。
输入 Prompt 的结构如下:
prompt = """用户查询:{}<|query|>
候选商铺信息如下:
商铺名称:{}
热销商品:{}
所属品牌:{}
商铺分类:{} - {} - {}
用户评分:{}分
平均价格:{}元
所在商圈:{}<|item|>
请判断该商铺是否匹配用户查询<|qi|>"""
设计三个而非一个 Token,是因为需要三种不同类型的表征:<|query|> 聚合 Query 侧语义,<|item|> 聚合 item 侧语义,<|qi|> 聚合双侧融合信息——前两者用于推理时独立提取各自的 Embedding 并计算 cosine 相似度,后者仅用于微调时的辅助 Loss。
三个特殊 Token 内嵌在同一条 Prompt 序列中,意味着训练时 Query 和 item 的文本信息是混在一条序列里的。如果不加干预,<|query|> 会自然"看到"后面的 item 文本,<|item|> 也会"看到"前面的 Query 文本。这本身对 <|qi|> 不是问题——它本来就要看两侧信息。但对 <|query|> 和 <|item|> 来说是个问题:推理时,Query 和 item 的 Embedding 是分别独立生成的,如果训练时 <|query|> "看到"了 item 信息,它学到的表征就会依赖 item 上下文,推理时只输入 Query 文本,产出的表征就失去了意义。
因此,通过 Attention Mask 对同一条输入序列进行三次独立 forward pass:提取 query 表征时,mask 将注意力范围限制在 Query 文本段,<|query|> 只能聚合查询信息;提取 item 表征时,mask 限制在 item 文本段,<|item|> 只能聚合商家信息;提取融合表征时使用完整 mask,<|qi|> 可以 attend 到整条序列。这样确保了 Query 和 item 各自的表征是自包含的,可以独立提取和存储。
表征提取方式是取 transformer 最后一层在特殊 Token 位置的 hidden state,经两层 MLP(hidden_size → 512 → ReLU → LayerNorm → 64)降至 64 维,作为最终的目标语义表征。
训练数据与目标
从服务零售垂直搜索链路的精排日志中抽取近 2 个月、共 3,000 余万条训练样本,其中下单:点击未下单:未点击 = 1:3:6。训练目标包含两个 Loss 协同优化:
<|query|> 和 <|item|> 单侧表征的 cosine 相似度,经可学习温度参数缩放后做二分类交叉熵,让模型从语义层面学习匹配程度;
Loss_2 基于 <|qi|> 融合 query 和 item 的双侧信息,经 MLP 后预测点击率,目的是让学到的语义表征对齐下游排序目标。

最终 Loss:L = Loss_1 + Loss_2。
双 Loss 设计的目的是让模型同时学习"单侧表征的质量"和"双侧匹配的判断"——前者直接服务于推理时的 cosine 相似度计算,后者辅助表征对齐下游点击率预估目标。
从模型到特征:推理、分桶与注入
推理时分别独立生成 Query 和 item 的语义 Embedding,离线存储至 Hive 表,按天例行增量更新。
模型推理

精排模型集成

模型获得语义 Embedding 后,计算 Query 与 item 的 cosine 相似度,并按预设的分桶边界将相似度划分进 10 个分桶。分桶边界为[-0.40, -0.30, -0.18, -0.12, 0.00, 0.10, 0.16, 0.22, 0.30],设计时考虑了每个桶内的样本量分布,并尽可能区分下单与未下单、点击与未点击等行为标签。
通过抽取 2 万条搜索曝光样本,我们验证了不同类型样本在各分桶中的分布。如下图所示,Query 和 item 语义越相似,点击/下单的样本占比越高:

这意味着我们可以将 Query 和 item 的语义表征相似度作为一个强特征引入排序模型,以提升模型在点击/下单率预估方面的表现。
为了实现这一目标,我们为每个分桶分配一个可学习的 Embedding 向量(12 维),拼接到精排模型现有特征中。使用分桶而非直接使用连续相似度值的原因是:离散化后的特征能更好地被精排模型的特征交叉网络利用,同时降低噪声敏感度。使用可学习的 Embedding 向量则是为了增强模型对于不同相似度区间的表达能力。
离线验证显示,引入表征特征后点击 NDCG +9bp,下单 NDCG +13bp,验证了方案的有效性。
实验周期 2025 年 9 月 18 日至 10 月 1 日,20%流量 14 天,AA 校验通过。
大盘搜索支付订单显著+0.20%,服务零售订单显著+0.27%。更值得关注的是体验指标的表现:长尾 NDCG@5 显著+2.21pp,长尾 BadCase@1 显著-2.96pp。语义理解提升在长尾场景体感最明显——这正符合预期,因为长尾 Query 恰恰是传统词面匹配最薄弱的地方。
一个只有 64 维的语义表征,仅通过分桶拼接的方式注入精排,就带来了显著的订单增量——这个结果直接证明了 LLM 语义表征在精排场景的价值,坚定了后续深度投入的信心。
一期验证了 LLM 表征在精排中的可行性,但也暴露了四个明显短板。一是只覆盖 Query-商家两端,商品侧语义完全缺失——而在服务零售场景中,用户很多时候是在搜商品而非搜商家。二是全参数微调训练成本高、维护困难,不利于快速迭代。三是微调目标以点击率预估为主,对排序优化不够全面——下游精排同时也关注成单目标。四是三次 Forward Pass 的推理效率有优化空间,表征提取方式还有更高效的替代。这些问题成为二期系统性升级的起点。
一期验证了 LLM 表征在精排中的可行性,但四个短板制约了进一步迭代:仅覆盖 Query-商家两端,缺失商品语义、全参数微调成本高、点击率分类目标对排序不够全面、三次 Forward Pass 效率低。二期的目标不是单点优化,而是系统性重构表征生产的全流程——从训练数据、基座模型、微调方式、表征提取、降维方式到损失函数,逐一对应一期的短板进行升级,同时将下挂商品(Deal)纳入建模,构建 Query-POI-Deal 三元语义表征体系。
贯穿二期的核心矛盾是:一期的训练目标是"判断 Query 和商家是否匹配"的二分类问题,但排序模型真正需要的是"在多个候选中哪个更匹配"的相对序关系。这个矛盾直接驱动了从点击率分类到对比学习的损失函数重设计,也间接影响了训练数据构建(需要难负样本)、表征提取方式(需要更高效的聚合)等其他模块的决策。

训练数据:从单条样本到五元组
一期每条样本只有 Query 和 POI 两部分,用于对齐下游目标的训练信号是"是否点击"。二期将每条样本扩展为五元组:Query、Deal 正样本、POI 正样本、Deal 难负样本、POI 难负样本。难负样本的选取是关键——Deal 难负样本来自同一请求、同一商家下曝光但未点击的商品,POI 难负样本来自同一请求下曝光但未点击的商家。这种"同请求"的难负采样策略确保了负样本与正样本在 Query 意图和上下文上高度相似,只在"是否被用户选择"上有差异,能迫使模型学到更精细的判别能力。最终我们构建了 2766 万条训练样本。
Prompt 设计:反直觉的发现
确定了"喂什么数据"后,下一步是"怎么组织成文本"。我们尝试了多种 Prompt 方案:精简信息陈述+总结引导、简单任务指令、丰富版任务指令、仅信息陈述。实验发现一个反直觉的结论:精简信息陈述+总结引导效果最好,过于复杂的任务指令反而降低表征质量。

这与常见的 LLM 问答任务的直觉相反。我们推测原因是:在 Embedding 训练场景中,Prompt 的作用是引导模型理解"要聚合哪些语义信息",而非传统的"指令遵循"。过于复杂的指令会干扰模型对核心语义信息的聚合,就像给一个本该专注于理解文本的人过多任务要求,反而分散了注意力。这一结论对后续其他表征场景有直接参考价值。
具体的 Prompt 如下:
二期在商家的 Prompt 中也新增了"次级经营品类"、"热销商品"等信息,以期望学到更完整的商家语义表征。
一个值得注意的实验发现是:我们尝试在商品特征中引入 CPV(商品属性)信息后,排序评估效果反而下降:

我们推测原因是当前 CPV 信息过于繁杂,未经筛选地引入反而会带来噪声。这个反直觉的结果说明,在表征训练中,信息质量比信息量更重要。
基座模型与微调方式:从全参到 LoRA
基座模型选择上,我们横向对比了参数量在 0.5B~8B 的多个模型,涵盖通用、Embedding、Instruct 等多个系列。
实验发现,中等参数档位是效果与推理成本的最优平衡点——更大的模型在 NDCG 指标上提升有限且推理成本显著上升;最小参数档位则在各项指标上全面落后。最终选定专门为文本表征任务优化的 Embedding 模型变体,它在 Click-AUC 和 NDCG 上均优于同参数量的通用模型。
微调方式从全参数微调切换到 LoRA[3](r=8、α=32,目标模块 q_proj 和 v_proj)。对比实验显示一个有趣的现象:LoRA 在 NDCG 指标上优于全参数微调,但全参在 AUC 上略有优势。这一现象仅在本场景中观察到,是否具有普适性有待验证。综合考虑训练效率和维护成本最终选择 LoRA。
表征提取:从三 Token 单序列到独立序列+可学习向量
一期在同一条序列中内嵌三个词表 Token,通过三次 Forward Pass 和不同 AttentiOn Mask 实现信息隔离,推理效率低。二期彻底重构了表征提取方式:不再将 Query 和 item 放在同一条序列中,而是各自在独立的序列中处理;特殊 Token 不再是 vocabulary token,而是 nn.Parameter——一个维度为 hidden_size 的可学习向量。具体做法是:对输入文本做 tokenize 后取 input embeddings,找到序列中最后一个有效位置,将该位置的 Embedding 覆写为对应的可学习向量,经过 Transformer 后取该位置的 hidden state 作为表征。Query、POI、Deal 各有独立的可学习向量。
这种设计相比一期有几方面优势:不再需要 Attention Mask 隔离(因为各实体本就在独立序列中处理),一次 Forward 可以同时处理五路输入(五元组的各部分拼接在 batch 维度上),推理效率大幅提升。同时,可学习向量直接作为"聚合锚点"放在序列末尾,模型在训练中学会在该位置汇聚全序列的语义信息。
对比实验显示,Last Special Token Embedding 优于 Mean Pooling 和直接取最后一个有效 Token,推测原因是可学习的特殊 Token 比固定位置或平均池化更能有效聚合序列信息并区分不同实体类型。
降维方式:从 Linear 到 MRL-E
一期用两层 MLP 将 hidden state 降至 64 维。二期改用 MRL-E[4](Matryoshka Representation Learning)策略:设置嵌套维度列表[1024, 512, 256, 128],训练时对每个维度分别计算损失并取平均,推理时直接截取前 128 维。
MRL-E 相比 Linear 降维的核心优势不在于精度提升(离线指标差异不大),而在于灵活性:同一套训练出的表征可以根据不同场景的效率需求选择不同维度,无需重新训练。这在后续三期将表征迁移到下挂精排时体现了价值——不同模块对 Embedding 维度的要求可能不同,MRL-E 提供了开箱即用的多尺度选择。因此我们选择 MRL-E 作为最终降维方案。
损失函数:从分类到对比学习
这是二期最核心的升级,也是"从分类到排序"这一核心矛盾的直接解法。
一期用 BCE Loss 做点击率二分类,模型只学到"是否匹配"的绝对判断。但排序模型需要的是相对序——在多个候选中哪个更匹配。InfoNCE Loss[5]天然面向这个目标:它利用 Batch 内负样本构建对比任务,最大化正样本对相似度的同时最小化与 batch 内其他样本的相似度,本质上是在做"从 N 个候选中选出正确匹配"的排序训练。
我们具体设计了三组 InfoNCE Loss:Query↔POI、Query↔Deal、POI↔Deal。三组对比覆盖了三元实体间所有两两关系,使表征空间同时编码 Query-商家匹配度、Query-商品匹配度和商家-商品一致性。采用归一化嵌入后的内积作为相似度度量,温度参数可学习:


但如果 InfoNCE 的负样本仅来自 Batch 内随机采样,难度不够——大部分 Batch 内负样本与 Query 的语义差距很明显,模型不费力就能区分。为此我们引入 Triplet Loss 专门处理构建出的难负样本:采用欧氏距离,margin=0.5,分别计算 Query-POI 和 Query-Deal 的 Triplet Loss。难负样本是"同请求同商家曝光未点击"的样本,与正样本在 Query 意图和上下文上高度相似,只在用户选择上有差异——这才是模型真正需要学会区分的。

消融实验验证了这一设计:引入 Triplet Loss 后,Q2I-Click-AUC[7] +4.85pp,Q2I-Order-AUC +11.02pp。Order-AUC 的提升幅度远高于 Click-AUC,说明难负样本建模对排序下单信号的捕获比点击信号更难、但更有价值——这也印证了"从分类到排序"的转型方向是正确的。

最终的训练目标为上述五个损失的加权和:

二期相比一期在多项关键指标上取得了显著提升:Q2I-Click-AUC 提升 6.25pp、Q2I-Order-AUC 提升 5.37pp、Q2I-Click-NDCG 提升 1.77pp、Q2I-Order-NDCG 提升 2.03pp。
相似度分桶策略升级
沿用一期的相似度分桶机制,但进行了两项升级。一是从单组相似度扩展到双组——同时计算 Query-POI 和 Query-Deal 的 cosine 相似度,各自分桶,使模型能分别利用 Query-商家和 Query-商品的语义匹配信号。二是引入零向量边界,用于捕获无表征样本(缺失表征置为零向量,并在特征计算中进入专门的缺失值分桶),确保未覆盖样本落入同一桶中,避免无表征样本的噪声干扰。
底层+顶层双重融合
表征信息通过底层和顶层两种方式融入精排模型。底层融合将分桶 Embedding 与精排模型现有特征拼接,参与特征交叉学习;顶层融合将原始 cosine 相似度直接在顶层拼接,经一层 LHUC 后用于 CTR 和 CTCVR 预测。
为什么要同时做底层和顶层?底层融合让语义特征参与特征交叉,能与其他特征产生交互效应,但经过分桶离散化后丢失了相似度的连续信息。顶层融合直接使用原始 cosine 相似度,保留了连续语义信号,但无法参与特征交叉。两者互补——加入顶层融合后点击 NDCG +5bp,下单 NDCG +3bp。
加载方式优化
一期采用 HashTable 热启方式加载表征,但二期引入 Deal 表征且维度从 64 维扩展至 128 维后,若沿用热启方式,模型体积将成倍增长,带来明显的存储和部署压力。为此,在工程实现上,二期优化为"离线训练样本化+线上 KV 读取"方案:离线训练时表征以样本特征形式引入,随样本一同加载;线上服务时从 KV 存储实时读取表征向量。优化后模型体积不增反降,相比一期基线还略有缩减,在牺牲部分应用灵活性的前提下解决了存储和部署压力。
实验周期 2026 年 3 月 17 日至 3 月 23 日,20%流量 7 天,AA 校验通过。
搜索大盘搜索 UV 显著+0.07%,有效点击 QV 显著+0.13%,服务零售结果页有效 QV_CTR 显著+0.10pp(+0.15%)。性能上 TP90 仅+0.2ms。
线上数据中出现了一个值得分析的现象:服务零售搜索 QV 略有下降(-0.05%,不显著),但有效点击 QV 正向(+0.09%,不显著),结果页 QV_CTR 显著正向。下钻分析发现,QV 下降主要集中在美团某事业部(-0.70%,显著),但该事业部的 QV_CTR 反而提升了0.24pp(显著)。原因是实验组优化了排序结果,减少了无效曝光——部分此前会被曝光但不会被点击的结果被更相关的结果替代,虽然总曝光量下降,但转化效率提升。线上排序指标印证了这一判断:实验组点击 NDCG@30 +6bp,点击 GAUC +13bp。
这个现象说明,语义表征的引入不仅是"增加曝光机会",更重要的是"优化曝光质量"——让更匹配的商品和商家排在前面,即使用户看到的选项变少了,转化效率反而更高。
商家精排两期的表征体系已成熟,但下挂精排——对商家下挂的具体商品进行排序——在语义维度的建模几乎为零。三期的核心逻辑是:复用二期已训练的表征模型,将成熟方案平移到下挂精排。这看起来是最自然的延伸,但实际执行中遇到了意料之外的挑战。
与表征迁移同步进行的,还有一项系统性特征治理工作。团队对下挂精排特征进行了全面梳理,发现部分特征已失效,同时在"个性化×商品"和"Query 意图×商品"两个交叉维度上存在建模空白。因此三期是"大模型表征迁移"和"全域交叉统计特征补充"两条线并行推进,最终以叠加效果上线。
扩大覆盖率:迁移的第一道关卡
表征模型直接复用二期,但表征的"覆盖范围"不能直接复用。二期的 Query Embedding 是基于商家精排样本圈选的——即只对商家精排中出现的 Query 生成 Embedding。直接迁移到下挂精排时,Query 覆盖率仅 81.24%,双覆盖率(Query+Deal 同时有 Embedding)更只有 73.61%。
原因在于两个场景的 Query 分布有本质差异。商家精排的 Query 偏向商家意图词(如"SPA"),而下挂精排的 Query 更多是商品意图词(如"双人 XX 套餐")——用户在商家列表页搜索的是"找什么样的店",进入下挂排序时搜索的是"买什么样的商品"。这些商品意图词在商户样本中可能从未出现,自然没有对应的 Embedding。
解决方案是重新用下挂精排的样本分布圈选 Query Embedding 的生成范围。修复后 Query 覆盖率升至 98.92%,双覆盖率达 89.81%。
这个工程细节看起来不起眼,但它直接决定了特征有效性。修复前的 73.61% 双覆盖率意味着超过四分之一的样本拿不到语义匹配信号——如果带着这个缺口上线,特征的价值会被严重稀释。这一经验也成为了跨模块复用表征的标准 checklist:表征模型的迁移不是直接复用模型参数,必须针对目标场景的样本分布重新圈选 Embedding 覆盖范围。
特征有效性前置验证
补充完 Embedding 后,团队先做了一项前置验证:将 Query 和 Deal 的 Embedding cosine 特征等距分为 100 个桶,分别计算每个桶内各 label(成单、货架成单、点击、全域成单)的平均值。结果显示随着 cosine 分数单调上升,所有 label 均值也单调上升,方向明确。这个验证虽然简单,但它回答了一个关键问题:迁移过来的表征在下挂场景是否依然有效?答案是肯定的——Query-Deal 的语义匹配度与用户行为之间存在清晰的正相关。
分桶策略:一种特征,五个视角
cosine 相似度与 label 虽然正相关,但并非严格线性。为了让特征分桶与各 label 呈现更强的正相关性,团队设计了 5 种分桶策略:等样本量分桶(V1,每个桶内样本数相等)、按下挂成单 label 均值等差分桶(V2)、按货架成单 label 均值等差分桶(V3)、以及在下挂曝光样本和货架曝光样本上分别按对应 label 等差分桶(V4、V5)。
为什么要设计 5 种而不是选 1 种?因为下挂精排同时优化多个目标(点击、下挂成单、货架成单),不同目标与 cosine 分数的关系曲线不同。等样本量分桶对综合目标最优,而按特定 label 等差分桶则在该 label 的方向上更敏感。Droprank 特征重要性分析也印证了这一点:V1(等样本量分桶)综合重要性最高(排名第21),但 V2、V3、V4 也分别排在第40、164、129 位——它们从不同方向对模型有独立贡献。

应用方式:从底层拼接到 PEPNet 门控
三期在表征与模型的耦合方式上做了系统探索。对比了 4 种方案:底层拼接交叉统计特征(+7bp)、底层拼接 LLM 相似度+交叉统计特征(+18bp)、LLM 相似度放在输出塔前(+8bp,且部分指标负向)、PEPNet 门控注入[8](+25bp)。
为什么 PEPNet 门控效果最优?底层拼接让语义特征参与特征交叉,但经过分桶离散化后信号被压缩;输出塔前注入保留了连续相似度信号,但无法与模型其他特征交互。PEPNet 门控机制的优势在于:它将语义相似度作为"门控信号"调制模型其他特征的权重——高语义匹配时放大相关特征的贡献,低匹配时抑制。这种自适应调节比固定位置的拼接更灵活,离线 ctcvr_auc_global_poi +25bp,远高于底层拼接的 +18bp。

全域交叉统计特征:语义维度之外
在大模型表征之外,三期还补充了四类全域交叉统计特征:user×deal id 体系交叉统计、POI 的 cate3 统计特征、user×POI 的 cate3 交叉统计、query×deal id 体系交叉统计。这四类特征弥补了下挂精排在"个性化×商品"和"Query 意图×商品"两个交叉维度上的建模空白。其中订单及转化相关特征因覆盖率极低(低于 0.1%),在消融实验中被移除——这也是一个值得注意的经验:统计特征的价值不仅取决于相关性,还取决于覆盖面,覆盖率太低的特征即使方向正确也难以产生实际收益。
实验周期 2026 年 5 月 28 日至 6 月 3 日,10%流量 7 天,AA 校验通过。
服务零售业务订单显著 +0.32%,服务零售访购率显著 +0.29%,搜索大盘支付订单显著+0.35%,大盘访购率显著 +0.25%。
三期的 +0.32% 订单是大模型表征和全域交叉统计特征两类特征叠加的结果。两类特征在离线均单独验证正向,但叠加效应比预期更强。这说明语义维度(LLM 表征)和统计维度(交叉特征)在捕获用户偏好上存在互补性——语义特征捕捉的是" Query 和商品在语义上是否匹配",统计特征捕捉的是"具有某种行为的用户是否偏好这类商品",两者从不同角度刻画了用户-商品的匹配关系,叠加后形成了更完整的判断。
三期迭代的技术细节已在前文展开,这里不再复述,而是聚焦于几条跨阶段的、对后续工作有直接指导意义的判断。
1、中等参数量是当前阶段的最优平衡点,但不一定是终局。 在 0.5B~8B 的参数量区间内,中等档位模型在效果与推理成本上取得了最优平衡。专门为表征任务优化的 Embedding 变体优于同参数量的通用模型。但这个结论有阶段局限性:随着推理优化技术(量化、蒸馏、推测解码)的成熟,更大模型的推理成本会持续下降,最优平衡点也会上移。因此更本质的认知是——表征模型的选型不应追求"最大可用",而应在当前推理预算下选择效果最优的,并定期重新评估。
2、 难负样本是提升表征判别能力的关键。一期使用点击率分类目标,模型只学到"是否匹配"的绝对判断,表征的判别能力有限。二期引入"同请求同商家曝光未点击"的难负样本,配合 InfoNCE + Triplet 对比学习框架后,离线指标大幅提升。难负样本的核心价值在于:它迫使模型学习"在高度相似的候选中,用户为什么选了这个而非那个"——这种精细判别能力是单纯靠正样本和随机负样本无法获得的。在构建表征训练数据时,难负样本的质量直接决定了表征质量的上限。
3、 Embedding 场景的 Prompt,做减法比做加法有效。 在传统 LLM 任务中,更详细的指令通常带来更好的效果。但在 Embedding 训练场景,精简信息陈述+总结引导优于复杂的任务指令和推理链。原因是 Embedding 的 Prompt 作用是"引导模型聚合哪些语义信息",而非"指导模型完成什么任务"——过多的任务指令会干扰模型对核心语义的聚焦。这一结论与传统 LLM 任务的直觉相反,对后续其他表征场景有直接参考价值:写 Embedding 的 Prompt 时,问自己"模型需要从这段文字中聚合什么信息",而不是"模型需要完成什么任务"。
4、 表征迁移的核心风险不在模型,而在覆盖率。 三期最大的工程挑战不是模型适配,而是 Query 覆盖率从 81.24% 到 98.92% 的修复。表征模型的参数可以直接复用,但 Embedding 的覆盖范围必须针对目标场景重新圈选——否则覆盖率缺口会直接压低特征有效性。这条经验看似简单,但容易被忽略,因为"复用模型"天然暗示着"可以直接上线"。后续任何跨模块迁移表征的工作,都应将覆盖率验证作为第一步 Checklist。
5、语义特征和统计特征是互补的,不是替代的。 三期的 +0.32% 订单是两类特征叠加的结果,且叠加效应比预期更强。语义特征从"Query 和商品在语义上是否匹配"的角度刻画用户-商品关系,统计特征从"具有某种行为的用户是否偏好这类商品"的角度刻画——前者是内容理解,后者是行为模式。两者各自有盲区,叠加后形成了更完整的判断。这意味着在特征体系设计中,不应将"大模型表征"和"传统统计特征"视为二选一的方向,而应将它们作为互补的信号源协同设计。
本工作处于"LLM 文本表征"与"搜索排序特征工程"的交叉地带。为厘清本工作在技术版图中的位置,从三个维度梳理业内工作。
维度一:文本表征模型(Producer)
文本表征领域经历了从 Word2Vec 到 BERT 再到 LLM 的演进。以 E5[9]、BGE[10](BAAI)、GTE[11](阿里通义)系列为代表,训练范式以 in-batch negatives + InfoNCE 为标准配方。2025 年基于 LLM 的表征模型成为主流,代表工作有 Qwen3-Embedding(false-negative mask)、Conan-embedding[12](动态硬负样本挖掘)、Llama-Embed-Nemotron[13](纯难负样本 InfoNCE)。这些工作的共同关注点是负例质量——"embedding 质量的天花板在负例质量,不在 backbone"已成为业界共识。在降维策略上,MRL 提供了多尺度可截断方案;高效微调方面,LoRA 成为参数高效微调的事实标准。
维度二:表征在排序中的应用(Consumer)
在表征如何融入排序模型这一问题上,业内存在多条路线。TIGER[14]开创了生成式检索范式,将 Embedding 量化为分层 Semantic ID 用于序列召回,但未直接用于判别式排序。在判别式排序中,表征的注入方式正在从简单拼接向门控和自适应融合演进:UNGER[15]指出语义与协同 Embedding 直接拼接时语义信号会占据主导,需显式模态平衡。
维度三:难负样本策略
难负样本是表征质量的关键杠杆。ANCE[16]首次提出用异步 ANN 索引从全局语料库采样难负样本,解决了 in-batch negatives 信息量不足的问题。此后业界发展出多种策略:Meta 的 realtime hard neg 使用 LLM 聚类后的同簇 OOB 负样本配合 LogQ 校正;Apple Music 的 Elise 采用课程式调度——前期用 InfoNCE 构建全局结构,后期切换到最难 Hinge Loss 锐化边界;小红书的 Uninote 提出多粒度难负挖掘与 JS 散度软标签。这些策略的共性是:从随机负样本转向"够难但不是假负例"的精细构造。
独立创新点
将上述工作作为参照系,本工作在以下方面具有独立创新性:
1、面向搜索排序的语义相似度直接特征注入。业界表征工作以推荐场景为主,表征主要作为底层特征拼接(如 TIGER 的 SID embedding),与排序目标之间的映射是隐式的。本工作基于搜索场景特点,将 query 与供给的 cosine 语义相似度作为直接特征注入精排——分桶离散化参与特征交叉(底层融合),同时保留连续相似度在输出塔前直接参与预测(顶层融合)。这种做法相比推荐场景的底层拼接有两方面优势:一是语义相似度直接刻画"搜索词与供给是否匹配",与搜索排序目标天然对齐,方案更具可解释性;二是底层 + 顶层的双重融合设计兼顾了特征交叉能力和信号保真度,比单一注入方式更充分地利用了语义信号。
2、基于"店+下挂商品"展示结构的难负样本构造。利用美团搜索"店+下挂商品"的两层展示结构,构造"同请求、同商家、曝光未点击"的下挂商品作为难负样本。这类样本与正样本在 query 意图和上下文上高度相似(同一搜索词、同一商家),仅在用户选择上有差异——迫使模型学习"在高度相似的候选中,用户为什么选了这个而非那个"。相比 ANCE 的全局 ANN 难负采样,本方案的难负样本天然绑定了搜索场景的上下文信息(同一请求、同一商家),难度更高且更贴近排序任务的真实分布。消融实验显示,引入此类难负样本后 Q2I-Order-AUC 提升11.02pp,远高于 Click-AUC 的4.85pp,验证了"从分类到排序"转型方向的有效性。
3、Query/POI/Deal 三元实体联合表征。业界文本表征工作以两元对(query-document 或 user-item)为标准建模单元。本工作面向服务零售"搜索词→商家→商品"的三元匹配结构,设计了三组 InfoNCE Loss(Query↔POI、Query↔Deal、POI↔Deal)覆盖三元实体间所有两两关系,使表征空间同时编码 Query-商家匹配度、Query-商品匹配度和商家-商品一致性。这种三元联合对比学习在公开文献中较少见,其设计动机直接来自业务场景——用户在服务零售搜索中既需要找到对的商家,也需要找到对的商品,二者构成层次化匹配关系。
基于三期迭代积累的经验和前沿技术调研,后续有四个值得探索的方向。
1、负例质量提升:当前表征训练的最大洼地。 二期的负例策略是 in-batch 随机负样本+单显式难负样本,已有不错效果,但前沿实践表明这个方向还有很大空间。 Qwen3 Embedding 工作[17]提出了 false-negative mask——把疑似假负例从 InfoNCE 分母中剔除,是零结构改动的即插项;KALM v2[18]的 focal-style 难度重加权让训练聚焦真难例;Nemotron 的相似度阈值筛选只保留"够难但不是假负例"的区间。这些方法的共同认知是:Embedding 质量的天花板在负例质量,不在 backbone。当前仅采用 in-batch 随机负样本 + 单个显式难负样本,负例构造仍是明显短板,优先补这一环的性价比最高。
2、MRL 低维档诊断与 SID 量化:从连续表征到离散语义 ID。 当前使用 MRL-E 的嵌套维度列表[1024, 512, 256, 128],推理时截取前 128 维。前沿调研显示两个值得关注的点:一是 d<128 的极低维档存在退化风险(多篇工作独立证实),需要对各截断层做 neighbor-overlap 诊断,若发现退化,则移除对应维度档位,避免多尺度联合 loss 被最差档拖累。
二是更激进的方向:将连续 Embedding 量化成分层离散语义 ID(Semantic ID)[19]。SID 把 embedding 压成"分层的离散码字序列"(如 3 层码本)[20],既保留语义近邻结构,又能像 ID 一样查 Embedding 表、天然层级共享、对新品友好。SID 的潜在价值在于:它打通了语义表征和 ID 特征的壁垒,让大模型表征能以更原生的方式融入排序模型的特征交叉体系,而非仅通过 cosine 相似度分桶间接参与。
3、针对下挂场景重训表征模型。三期复用的是商家精排的表征模型,训练数据以商户样本为主。下挂样本在 Query 分布(更多商品意图词)和正负样本构成上与商户有显著差异,专项针对下挂场景训练一版表征模型,预期能进一步提升 Embedding 质量和覆盖率。同时,前面提到的负例质量提升和 MRL 诊断,可以一并在这版重训中落地。
4、Producer→Consumer 闭环:让排序信号回灌表征。当前的表征训练和下游排序是单向的——表征产出后通过 cosine 相似度喂给排序模型,但排序模型学到的场景感知相关性没有回流到表征训练。前沿工作 relevance_based_emb 提出了这条闭环的雏形:把下游排序的相关性判断作为蒸馏信号回灌到表征训练,让表征不仅语义准确,还对齐下游排序目标。这是 Producer(表征生产)与 Consumer(排序侧消费)协同的独有优势,有望进一步缩短离在线 Gap。
本文介绍了服务零售搜索排序团队在 2025 年 Q4 至 2026 年 Q2 期间,将 LLM 语义表征引入精排模型的三期实践。一期验证了可行性——用 64 维 cosine 相似度特征就带来了显著订单增量;二期系统性重构了表征生产全流程——从分类目标转向对比学习,从全参数微调转向 LoRA,构建了 query-POI-deal 三元表征体系;三期将成熟表征迁移到下挂精排——在解决覆盖率问题后,通过 PEPNet 门控注入和全域交叉统计特征的叠加,进一步拓展了收益边界。
三期迭代的主线可以概括为一个认知演进:从"用 LLM 生成一个语义特征"到"构建一套可迁移的表征生产体系"。一期的重心是验证"LLM 表征能不能用",二期是解决"怎么把表征做好",三期是探索"好的表征怎么跨场景复用"。每一期的技术决策都建立在前一期的短板分析之上,而非独立的技术选型。
从方法论角度,三期实践沉淀了一条可复用的表征工程路径:用对比学习目标(InfoNCE + Triplet)训练 LLM 表征模型,用 MRL-E 实现多尺度降维,用相似度分桶或 PEPNet 门控注入排序模型。这条路径的每个环节都有明确的工程 checklist——难负样本的质量决定表征上限,Prompt 精简化优于复杂指令,覆盖率验证是跨模块迁移的第一步,语义特征与统计特征应协同设计而非二选一。
注释
KDD(ACM SIGKDD Conference on Knowledge Discovery and Data Mining)是数据挖掘与知识发现领域最具影响力的国际顶级学术会议。KDD 以其严格的论文录用标准和深厚的学术影响力著称,是推动数据驱动研究与应用创新的重要平台。大会为学术界和工业界提供了交流前沿成果的高水平论坛,论文录用率通常在 15%-20% 左右,属于计算机领域的 CCF-A 类顶级会议。
本文精选了美团技术团队被 KDD 2026 收录的 8 篇论文进行分享,这些论文覆盖了推荐大模型、生成与奖励建模框架、智能体搜索、Transformer 框架、元泛化框架等技术领域。
🏆 此外,大众点评技术部还荣获了 2026 KDD Cup 复杂数据分析 Data Agents 国际竞赛的冠军、季军,本文介绍了团队比赛思路和解题策略。希望以上这些内容能够对大家有所帮助或启发。
论文下载:PDF

论文简介:工业推荐系统通常涉及多个场景,而现有的跨域(CDR)和多场景(MSR)方法往往需要大量资源且要求严格的输入对齐,限制了其可扩展性。该论文提出了MTFM(Meituan Foundation Model for Recommendation),一种基于Transformer的框架,旨在解决上述挑战。MTFM不预先对齐输入,而是将跨域数据转换为异质Token,以无对齐的方式捕捉多场景知识。为提升训练效率,MTFM引入了多场景用户级样本聚合机制,显著减少了总实例数量,大幅提升训练吞吐量;同时融合了Grouped-Query Attention和定制化的Hybrid Target Attention,有效降低了内存占用和计算复杂度。 此外,论文还实现了多项系统级优化,如kernel融合和消除CPU-GPU阻塞,进一步提升了训练和推理吞吐。在外卖等场景的离在线实验均验证了MTFM的有效性,证明了通过扩展模型容量和多场景训练数据可以实现显著的性能提升。基于MTFM,团队构建了服务于以上多个业务主场景的统一基座推荐大模型,替换各自的独立精排模型,并完成了全量。
论文下载:PDF

论文简介:本文提出CDRRM,一个对比驱动的评分准则生成与奖励建模框架,旨在提升LLM对齐中奖励模型的可靠性、可解释性与数据效率。传统奖励模型是“黑箱”且依赖昂贵标注;现有准则方法存在冗余与偏见。CDRRM采用“对比-聚合”流程:先对比好/差回答定位关键差异,再聚合为简洁的任务相关准则,指导评判模型。实验表明,CDRRM在三个基准上达最先进水平,缓解话痨、位置等偏见,且仅用3千样本让未微调模型超越全量微调基线,兼具高效与可解释性。
论文下载:PDF

论文简介:本文针对本地生活服务领域AI搜索的研究空白,构建LocalSearchBench评测基准。该基准涵盖国内 9 座城市、6 大服务品类,包含 900 道多跳问答任务,同时配套交互环境 LocalPlayground 与商户检索工具 LocalRAG。实验测评 16 款主流大语言推理模型后发现,当前模型在此类任务表现不佳,普遍存在信息完整性、可信度不足等问题。研究还剖析了模型工具调用、多跳推理等典型缺陷,为本地生活服务场景下智能体搜索的模型训练和基准测试提供了重要支撑。
论文下载:PDF

论文简介:针对联合广告拍卖场景中的算法无法同时满足匿名性和确定性分配的问题,导致实际应用中存在分配不公平和激励不兼容等问题,提出了JTransNet模型。匿名性要求拍卖结果仅依赖于竞标价值,而与参与者身份和顺序无关,确定性分配则保证同样的输入下分配结果唯一。JTransNet通过引入匿名性和确定性分配机制,结合可微分的NeuralSort排序方法,实现了端到端数据驱动的AMD自动化模型拍卖算法。该算法很好的解决了联合拍卖场景下多方出资的流量分配和扣费问题,在离线和在线实验中均显著提升了平台广告收益。JTransNet已在美团零售核心业务场景全量上线,促进了广告业务流量售卖的公平性与收益提升,同时为工业界大规模自动化模型拍卖机制算法设计提供了有效的解决方案。
论文下载:PDF

论文简介:在即时物流场景中,提单页面的预估到达时间(checkout page ETA)对提升用户满意度、优化调度策略和控制运营成本至关重要。在美团Keeta等国际化即时配送平台上,具有显著的跨域异质性,多域建模已成为核心需求。然而,现有方法面临三大挑战:一是无法泛化到完全未见过的新市场域,无法在冷启动阶段实现零样本预测;二是跨域特征空间不一致,新市场域由于缺乏历史数据积累导致离线统计特征结构性缺失;三是成熟域与冷启动域往往需要分别建模,阻碍了知识迁移并增加了维护成本。 为此,本文提出了UME(Unified Meta-generalization framework for ETA),一个统一元泛化框架。UME设计了统一双分支网络和基于超网络的元学习机制,通过域级知识和实例级上下文动态调制特征门控、专家注意力和最终预测,实现跨域关联建模和域内自适应。同时引入知识蒸馏策略弥合特征缺失带来的信息差距。该方法在离线实验与线上实验中均优于现有方法。
论文下载:PDF

论文简介:现代自动竞价系统需要在整体效果、广告主多样化目标和现实约束之间取得平衡,反映行业不断变化的需求。近年来,条件生成模型(如Transformer和扩散模型)能够根据广告主偏好直接生成竞价轨迹,为传统基于马尔可夫决策过程的方法提供了有前景的替代方案。但这些生成方法也面临诸如离线与在线环境分布偏移、动作空间探索有限以及需满足CPM和ROI等约束的挑战。为此,我们提出了GRAD,这是一种可扩展的自动竞价基础模型。GRAD通过动作混合专家模块实现多样化竞价行为探索,并结合因果Transformer进行约束优化。
论文下载:PDF

论文简介:在现代在线广告平台中,保证交付(GD)合约与实时竞价(RTB)拍卖共存并相互竞价。现有方法要么将GD与RTB的优化解耦,要么依赖启发式的优先级规则,因此无法在复杂的多坑位投放和曝光约束下,有效平衡短期收入最大化与长期合约交付目标。针对这些问题,我们提出了HMAF(分层多坑位分配框架),这是一个统一框架,旨在优化GD-RTB广告平台中的曝光分配。HMAF以“规划–校准–执行”范式为核心结构,将离线约束优化与在线决策相结合,统筹离线GD资源规划、动态校准GD与RTB的竞争强度,并在多坑位环境中做出实时的列表级排序决策。
论文下载:PDF

论文简介:生成式推荐在搜索、推荐、广告领域得到越来越广泛的应用,在用户体验和平台收入方面均取得了显著的提升。随着生成式推荐模型Scaling Dense的发展趋势,业界越来越倾向于基于PyTorch生态构建下一代推荐模型训练引擎,最大程度上复用LLM的发展红利。然而,PyTorch 生态在对大规模稀疏Embedding训练的支持上,仍有较大的提升空间。因此,我们基于PyTorch 生态提出了MTGenRec训练框架,统一「稀疏-稠密」训练能力,满足工业级生成式推荐模型训练需求。 具体来说,针对稀疏ID我们提出使用动态Hashtable替换静态表,解决ID动态上下线的问题,方便用户使用;为了提升训练效率,我们提出自动合表、ID去重、变长序列负载均衡等技术,针对推荐场景进行极致优化。此外我们还开发了断点续训、混合精度训练、梯度累积、算子融合等配套技术。大量实验结果显示相比TorchRec baseline,MTGenRec能够取得1.6倍~2.4倍的训练加速比,同时保证训练精度不变。从8卡扩展到128卡,MTGenRec也取得了近似线性的扩展效率。目前MTGenRec已在美团内部多个核心场景落地使用。
KDD Cup 是数据挖掘与知识发现领域全球公认的顶级赛事。在 2026 赛季的 DataAgents 赛道中,美团技术团队历时两个月,从全球参赛队伍中突围,最终摘得冠军与季军。
比赛考察的是模型在真实复杂数据场景下的理解与推理能力——多模态输入、非结构化文档、干扰信息识别,每一项都是当前 Agent 落地的硬骨头。

传统的 Data+AI 系统虽已在特定任务上取得显著进展,但端到端的分析流程仍高度依赖人类专家编排,成为制约数据分析可扩展性与适应性的主要瓶颈。为此,KDD Cup 2026 提出以「数据智能体(Data Agents)」破局——通过融合知识理解、推理与规划能力,自主完成任务拆解与规划、工具选择与调用、异构数据推理以及结果综合。复杂数据分析是其中的核心任务,主要挑战在于真实数据的「异构鸿沟」与推理链路的非线性复杂性。Data Agents智能体接收一份异构的多模态数据包(涵盖数据库、PDF 报告、JSON 数据、图表乃至视频等),并针对一个高层次的自然语言问题,自主编排包含并行分支、迭代循环与结果汇聚的复杂推理过程,最终给出准确答案,旨在推动构建真正自主的数据分析系统。

比赛中,队伍将点评「问点仔」建设过程中积累的 Agent Harness 能力迁移至赛题,利用业余时间构建了完整的 Agent 运行时,支持多类型数据文件的自主探索以及 SQL、Python 等分析工具的选择与执行。通过错误反馈、超时控制和自动重试等机制,提升智能体在长链路任务中的稳定性与容错能力。针对视频和非结构化文档等异构数据,还构建了多模态视频理解子智能体和非结构化文档 ETL 子智能体,进一步增强主智能体的数据提取、理解与综合分析能力。此次获奖验证了相关技术在复杂异构数据分析Agent场景中的有效性,也为后续持续提升「问点仔」智能化水平提供了技术积累。
目前,相关代码已在GitHub开源,后续我们还会通过技术博客分享更多的技术细节,敬请期待!
本篇博客是一篇科普文章,由浅入深的介绍Agent评测。其中前两章系统介绍了评测是什么,以及如何建立评测体系;其中第二章是美团图灵Agent评测团队深入美团各业务团队BP总结出的实践经验,是我们在两年实践过程中逐步打磨出来的认知。第三章重点介绍了龙虾/爱马仕这类长程Agent框架的出现对评测带来的变化。
本篇博客在美团内部发表之后获得了较多的关注,我们发现大家对Agent评测的热情非常高,因此我们决定将内部博客进行公开,想把这些经验分享给更多的同学,希望对大家有所启发或帮助。
评测的核心目的是为了回答 Agent 的好不好?以及到底哪里好,哪里不好? 从而为下一轮迭代指明方向。评测是Agent效果的“精密量具”。
这也是为什么 Agent 评测不能只停留在离线打榜,更不能只看某次 Demo 的表现。它必须服务于真实业务中的研发、上线、回归、优化和规模化落地。
而Agent评测的基石是观测,因此我们得出了Agent研发公式 —— 观测 + 评测 = 持续迭代
评测方法会随着 AI 形态变化而变化,大致经历了三个阶段:

传统机器学习更像在回答“算得准不准”。 大模型评测开始回答“模型能力强不强”。 而 Agent 评测真正要回答的是:
当模型被放进一个真实系统里,和 Prompt、Skill、工具链、记忆、状态管理、业务流程耦合在一起后,它能不能稳定交付好的结果。
这意味着 Agent 的评测对象已经不再是单一模型,而是一个“模型 + 系统 + 工具 + 流程”的复杂系统。
在真实场景中,两个 Agent 可能最终都“做对了”,但工程价值完全不同:
如果只看最终答案,这两者会被误判为同一水平;但从规模化、成本优化、用户体验的角度看,差别非常大。
因此,Agent 评测至少需要覆盖四层内容:
从这个意义上讲,自2023年GPT爆火以来,Agent发展从ChatBot形态快速发展至ClaudCode、OpenClaw这样的多功能长程Agent,Agent能力日渐强大,Agent评测正在从“答案评测”走向“行为评测”。
有一个朴素的认知:Agent 属于广义的 SaaS 层,大模型赋予Agent泛化能力但也带出随机性的问题,而用户仍旧期望得到一个稳定可靠的智能体。为了弥合“随机性”与“可靠性”之间的鸿沟,我们必须回归工程视角看待Agent —— 看不见的问题,几乎不可能被稳定解决。
Agent 的一次执行通常包含如下链路:

只要其中任意一层出问题,最终效果都可能劣化。为了结果稳定,我们需要过程稳定。但如果日志系统只能看到“用户说了什么”和“最后回复了什么”,就几乎无法判断问题根因。正是基于“我想看Case却发现没打日志”这个朴素的问题,工业界发展出了 Trace 系统,将黑盒内部的逻辑推理过程进行全路径的披露,将所有影响模型输出的输入信息都记录下来。
对 Agent 的每一个“隐形动作”进行精准观测,是实现从“概率性生成”向“工业级可靠性”跨越的必由之路。
经过前文的论述,我们知道Agent评测本质是在回答好不好,为迭代指明方向。而Agent评测本身既要关注结果(Response)也要关注过程(Trace或者叫做Trajectory)。
有的同学会好奇,为什么一定要“搭桥”?这是因为Agent评测体系必须追求业务价值与评测指标之间的解释性。而Agent 评测的难点之一,是模型能力指标和业务结果指标之间有天然鸿沟。

这两类指标不能直接映射,中间必须有一层面向任务系统的桥梁指标。我们提供一种分层思路如下:

以 AI 搜索为例,业务可能关心DAU、留存和点击;搜索系统本身关心召回率和点击率;Agent 层则关心意图识别是否准确、检索是否有效、结果整合是否可信。
只有把这些层次串起来,才能真正回答“为什么业务指标变差”以及“模型能力提升为什么没有带来业务收益”。这件事必须依赖真正懂业务流程的人来共同建立指标体系。
经过第一章的介绍,我们知道,Agent的核心目标就是要稳定地交付好的结果。行业内 Agent 评测大量借鉴了大模型评测的方法论,总体上可以拆成客观评测和主观评测:

因此更现实的做法通常是:
“好不好”是一个主观问题,主观的标准需要对齐,否则我们不能确定某次迭代之后,到底是指标的抖动带来的提升还是真实的效果提升。
在评测实践中,真正困难的不是“没有人会评”,而是“不同的人评得不一样,机器和人评得也不一样”。在过去一年,我们图灵团队深度BP业务方的过程中,我们发现多个团队相继踩入了相同的坑。
图灵评测积累的关键认知可以概括为“人人对齐和人机对齐”,具体如下:

具体如何进行对齐呢?最佳实践是把模糊指标下钻成更细的评测Rubric(或者叫评测维度:学界关于评测维度dimension和评测规则rubric的说法尚未统一,我们这里与开源项目Arize AI对齐),再把每个Rubric尽可能二元化。具体如下:
这种拆解法的价值在于:从“主观的模糊感受”转向“可判断的事实依据”,用下钻降低模糊度,从而降低人与人之间、人与机器之间的分歧。应用这套方法,数字站长的人机一致率可以达到99%。Beam以图灵的二元化方案改造评测体系,人机一致率从62%提升到92%。
下面我们分享两个案例。
案例一:如何评价初中生作文的好坏?(满分40分)

案例二:以骑手外呼场景模型回复是否“口语化”举例
经典错误示范 —— 请判断大模型的回答是否口语化,并按照0到10分打分。
下钻与二元化之后的改进版:
补充:标注和评测的关系是什么?
其中,标注是一种动作,而评测是一套目标导向的判断流程。机器预标注可以帮助人工提效,但只有在人机一致率保障才能称为自动化评测,否则只是机器标注。
从执行链路看,Agent 评测可以被拆成五个关键环节,
这5个环节与线上AB、持续观测共同构成了Agent迭代的数据飞轮。
绝大部分新上手Agent评测团队都有一个误区 —— 多方调研总结设计一个复杂精妙的评测指标体系,而越复杂的指标越难以执行和对齐。
而Agent评测是一门实践科学。起步阶段“让数据飞轮高效运转起来”的意义远大于“设计一个复杂精妙的评测体系”。评测体系的建立不是一蹴而就的,而是依靠 Good Case 和 Bad Case 喂养的。
因此 ,Agent 评测指标体系的搭建最佳实践路径如下:
其中,Bad Case 的价值往往更高,因为它最容易暴露能力边界和系统短板;而 Good Case 的作用则是帮助团队定义高质量完成的范式。
一个成熟的评测团队,核心能力不是一开始就搭出完美系统,而是能把线上问题、失败样本、模糊反馈不断转化成结构化评测资产。我们通过Bad Case和Good Case修正评测体系的目标,逐步修正“独裁者”与真实目标之间的负面偏差。例如履约数字站长业务,项目启动之处只有20多个评测指标,而经历1年时间推全之后,我们扩展到了近200个指标。
从GPT 3.5发布至今,虽然基座能力发生了天翻地覆的变化,但是模型能力终究不是万能的。在过去三年的Agent实践中,我们遇到过大量脱离实际的“许愿式”需求。我们要知道模型是训练出来的,模型本身拟合了Token的概率分布,即便在大规模参数下会产生能力的“涌现”,但模型能力的提升依旧强依赖语料的输入,尤其是高质量语料的输入。无论是早期的RLHF,还是如今的DPO、GRPO等算法,虽然训练架构在不断简化,但对高质量核心数据的依赖从未改变。
例如字节专门设立了众包专家标注平台 Xpert,用于生产地理、代码、法律、医学等专业领域的高质量数据,以此支撑豆包基座模型的迭代训练。基座模型能力的提升,大家的直观感受就是它在一个又一个垂直领域的表现越来越好。
因此,当我们在特定垂域面临业务知识语料匮乏(或公网无公开高质数据)的挑战时,通过引入行业专家的知识输入来补足模型/Agent的能力,就成了破局的关键——尤其是在项目的冷启动阶段。

呼应前文,评测的目的是回答“Agent好不好”,那么谁来定义“好不好”呢?靠最懂业务最有Sense的行业专家。
这个章节讲述的是图灵评测从履约的项目出发,又经过这1年多BP公司各个业务方的过程中沉淀的核心方法论。
FAQ
Q1:“独裁者”必须是1个人吗,还是1个团队共同遵循一套评测规范即可?
首先一个团队需要遵循同一套评测体系。独裁者的作用多方征求意见并整合评测体系,当项目方观念无法对齐的时候,由独裁者拍板定论,避免评测体系分化带来项目方各自为政以及内部拉扯带来的损耗。
Q2:评测体系依赖“独裁者”,存不存在风险?
我们要认清一个事实,评测体系是不断演进的。从业务冷启动到扩量再到全量,这个过程中用户从愿意尝鲜的AI爱好者扩展到全部用户,用户画像会发生明显的偏移。这导致评测目标需要随着业务的扩量不断地发生调整。独裁者的价值更多的体现在拉齐标准,评测目标更多的是由真实的业务场景中BadCase/Good Case修正并驱动的。当然,我们需要在评测标准建立之初选出最懂业务的人来制定评测体系。
Q3:冷启动阶段一定要设立种子评测集吗?能不能直接小流量开灰上线,直接收集Good Case和Bad Case来驱动评测呢?
冷启动阶段是否必须设立种子评测集,本质上是一个风险与成本的Trade-Off。
为什么建议设立种子集:大模型具有随机性,Corner Case 可能会导致Agent体验剧烈偏移。因此,需要通过回测保证Agent基线能力,不断融入Good Case和Bad Case来拓宽Agent的能力边界。
关于小流量开灰的策略:如果业务场景容错率高,或者构建高质量种子集的成本远超线上试错带来的负面反馈,可以尝试小流量上线收集线上case。
推荐落地方案:人工生产少量评测集后,AI辅助生成或扩写,以较低成本完成冷启动的种子评测集构建。
Q4:我们邀请的行业专家对“好”的定义不一致应该怎么办?
答:最朴素且有效的方法,邀请一批行业专家定义“好”的标准,从中抽取共性的部分建设评测体系。例如邀请金牌销售来定义优秀的销售SOP。
那么非共性的部分就没有价值了吗?并非如此。对于专家意见不一致的部分,往往意味着业务本身存在多种优秀策略。我们可以将这些分歧转化为 Agent 的不同风格或策略分支(例如:AI电销中,老练激进派 vs 细水长流派),并允许在不同的测试集(Benchmark)中独立评测。这些分歧点非但不是噪声,反而会成为 Agent 未来走向精细化迭代、覆盖更多长尾场景的重要养分。
2023年GPT爆火,2024年工作流出现,去年 Claude Code发布,再到今年的龙虾热、爱马仕热,长程Agent逐渐进入了大众视野。Agent Harness也全面进入长程Agent时代。
长程Agent(Long-horizon Agent)与短程Agent的区别,在于它如何处理“时间跨度带来的复杂性”:

这些差异会为观测评测带来怎样的变化呢?
短程Agent时代的评测对象相对简单。ChatAgent 时代的典型输入输出形态是:Query -> Answer。
这类场景的共同特点是:Agent 更多是在“回答问题”,进行少量的系统操作,而不是“进入操作系统执行任务”。典型应用场景,例如AI搜索、客服机器人。此类Agent评测重点通常落在回答本身,例如:

在过去1年的发展中图灵形成了成熟的解决方案,包括人工评测、机器评测,部分案例如下:

3.2.1 长程Agent带来评测范式变化
长程 Agent 解决的不是“回答一个问题”,而是“完成一个复杂任务”。它通常需要:
让我们回顾一下观测和评测的目标,带着这个目标去看长程Agent

3.2.2 Skill评测
在讲Skill评测之前,我们先分享一下我们关于26年春节后这一轮龙虾/Skill热潮的调研。
谁在提出龙虾和Skill的评测需求(2月至今龙虾/Skill热潮的用户画像)?
总结起来目前龙虾和Skill相关需求主要 广义的运营提效 场景,大致可以分成三类:

用户规模正在从少量专业角色扩展到更广人群
这会带来一个直接结论:
未来需要评测的人,不只是一小撮产运研同学,而可能是每一个会创建、修改、接入 Skill 的人。
这对评测系统提出了新的要求:
当前的本质痛点
本质在于 —— 大家不知道怎样写好 Skill,也缺乏对 Skill 全生命周期进行评测的工具。
为了方便大家理解,我们将Skill全生命周期拆解如下:

综上,Skill评测的痛点总体可以拆解成三个方面:

面向Task的评测
2026年1月9号,Anthropic发表了一篇博客揭秘AI Agent评估,在这篇博客中首次提到了面向Task的长程Agent评测。文中对Task,定义为“具有明确输入和成功标准的单个测试”。
我们综合了Anthropic以及开源软件对Task的定义,简化如下。

prompt定义了我们的问题/诉求,expeted behavior定义了我们预期Agent达成的行为,当我们在正式或测试环境中向Agent发送promt,通过trace获取到长程Agent真实的执行路径,就可以得到(prompt - expeted_behavior - trace)三元组,类似于短程Agent的(query - ground_truth - answer),即可进行评测。
3.2.3 长程Agent评测与短程Agent评测的差异
可以把两者的差异总结如下:

最本质的变化是:
ChatAgent 评测关心“说得好不好”,长程 Agent 评测关心“事情做成没有,以及是怎么做成的”。
3.2.4 人评主导走向机评主导
ChatAgent 时代常见流程是:核心评测员对齐 -> 外包对齐 -> 机评对齐
而在长程 Agent 场景下,这条链路有机会被明显缩短,甚至可以跳过外包对齐,直接进入:核心评测员对齐 -> 机评对齐 -> 规模化扩展
原因主要有三点:
这并不意味着人工不重要,而是意味着:
换句话说,AI 评测真正要放大的,不是“机器打分”本身,而是核心评测员的判断标准。
3.2.5 长程Agent评测基建至少应该具备哪些能力
如果未来要支撑公司内大规模 Agent 和 Skill 生态,评测基础设施至少应包含以下能力:
如果缺少这些能力,评测就容易停留在“单次分析”和“项目制支持”层面,无法真正成为生产系统的一部分。
综合来看,随着大模型能力的增强以及Agent Harness的持续演进,Agent 评测的演进可以概括为两句话:
第一,评测对象变了
过去评测的是“回答”,现在评测的是“任务系统”。
因此我们关心的不再只是输出内容本身,而是完整执行链路中的能力、稳定性、效率与风险。
第二,评测方法变了
过去主流是 Query -> Answer 的文本质量评测,现在逐步转向 Prompt -> Expected Behavior 的行为评测。
标准答案不再总是唯一,过程质量、任务完成度和轨迹质量成为新的核心对象。
因此,未来真正重要的,不只是能不能做几次评测,而是能不能建设出一套:看得见问题、说得清标准、跑得动规模、接得上流程、带得动迭代的 Agent 评测体系。