AD-Bench：当LLM Agent遇上真实广告投放，最强模型也只能拿69分

论文标题：AD-Bench: A Real-World, Trajectory-Aware Advertising Analytics Benchmark for LLM Agents

论文链接：https://arxiv.org/abs/2602.14257v1

作者：Lingxiang Hu, Yiding Sun, Tianle Xia, Wenwei Li, Ming Xu, Liqun Liu, Peng Shu, Huan Yu, Jie Jiang

机构：腾讯（Tencent）

🎯 一句话总结：腾讯团队从823条真实广告分析请求出发，构建了一个不仅看答案对不对、还看Agent"做题路径"合不合理的评测基准，结果发现即便是GPT-5.1也只能答对69%——广告分析这件事，LLM Agent还差得远。

📖 为什么需要AD-Bench？

LLM Agent这两年火得一塌糊涂。从写代码到做数据分析，各路基准测试（benchmark）层出不穷。但有一个非常实际且商业价值巨大的场景，几乎没有人认真评测过——在线广告投放分析。

想想看，广告投放这件事有多复杂：一个广告优化师每天要盯着几十个账户、几百条计划的数据，回答类似"最近三天哪个账户的ROI下降了"、"帮我看看这组素材在25-35岁女性群体中的转化成本"这样的问题。这些问题看着不难，但要准确回答，需要调用多个API、处理多层筛选条件、做数学运算，最后还得把结果总结成人话。

现有的Agent基准要么是通用的（比如GAIA、AgentBench），要么聚焦在代码生成、数学推理这些"学术风"任务上。它们有几个共同的短板：

  • 数据是编造的：很多benchmark用的是合成数据或学术数据集，和真实业务场景差距巨大
  • 评估只看结果：答案对了就算过关，至于Agent中间调了什么API、参数传对没有，一概不管
  • 数据会过时：静态的ground truth一旦时间长了就不准了，特别是广告数据这种实时性很强的领域

AD-Bench要解决的就是这三个问题。

🏗️ AD-Bench的整体设计

图2：AD-Bench流程概览

图2：AD-Bench的两阶段流程。左边是在线广告环境中，专家标注生成带标注的Ground Truth；右边是离线评估环境中，LLM Agent执行任务后，用LLM Judge判断答案正确性，同时对Agent的工具调用轨迹做子序列覆盖率匹配。

整个基准分两个阶段来理解：

阶段一：数据从哪来？ 腾讯广告的营销平台每天处理海量的投放请求。团队从真实的广告运营场景中收集了2000条原生用户分析请求，经过清洗去重后得到823条高质量实例——这些都是广告优化师实际会问的问题，不是研究员坐在办公室拍脑袋编出来的。然后由领域专家逐条标注，记录下完成这个查询需要调用的工具序列和最终答案。

阶段二：怎么评？ 被评测的LLM Agent在一个沙箱化的离线环境里接收查询，可以调用9个预定义的营销分析工具。评测从两个维度打分：一是用LLM Judge（Gemini-3-Pro担任裁判）比对最终答案和ground truth的匹配度（Pass@k），二是看Agent实际调用工具的序列和专家标注的序列之间的覆盖率（Trajectory Coverage）。

这个设计很像考试的"结果分+过程分"：不光看你最后算对了没有，还看你的解题步骤规不规范。

三级难度体系

图5：三级难度任务示例

图5：L1、L2、L3三个难度级别的具体示例。每个级别展示了查询内容、Agent调用工具的步骤序列和最终答案。从简单数据检索到多源推理+知识检索，复杂度逐级递增。

823条查询按复杂度分成三级：

难度 比例 描述 典型任务
L1 24% 简单数据检索 "查一下账户A昨天的消费"
L2 47% 条件筛选+数值计算 "过去7天ROI低于2的计划有哪些？平均转化成本多少？"
L3 29% 多数据源推理+领域知识 "结合行业均值分析这组素材效果，给出优化建议"

用考试来类比的话：L1是填空题，翻翻书就能找到答案；L2是计算题，要列方程、代数字、算出结果；L3是综合分析题，不仅要算数，还得结合课外知识写一篇小论文。

从分布来看，L2占了将近一半——这说明在真实广告运营中，"帮我筛选+算一下"是最高频的需求。而L3虽然只占29%，却是区分Agent能力的关键战场。

九大营销工具集

Agent可以使用9个专门为广告分析设计的工具：

工具名称 功能 对应的真实操作
get_user_account_list 获取用户的广告账户列表 登录广告后台看账户
get_account_advertise_list 获取某账户下的广告计划列表 展开某个账户的投放列表
daily_data_by_group_and_field 按维度分组查询每日数据 在报表里筛选+分组查看
search 关键词搜索 在系统内搜索特定计划或素材
filter 条件过滤 设定筛选条件
calculator 数值计算 拿计算器算ROI、环比等
summarize_results 汇总分析 把一堆数据写成分析报告
knowledge_retrieval 领域知识检索 查行业报告、最佳实践
report 生成最终报告 输出结论

这个工具集的设计挺有讲究。它基本覆盖了广告优化师日常工作的全链路：从查数据、筛数据、算数据到总结数据。Agent需要根据用户的问题，自己决定调用哪些工具、传什么参数、按什么顺序执行——这和真实的Agent使用场景完全一致。

🧠 两个核心技术亮点

亮点一：轨迹感知评估（Trajectory-Aware Evaluation）

大多数Agent基准只关心最终答案对不对。但在广告分析场景中，过程和结果一样重要。为什么？因为如果Agent用了错误的API或错误的参数碰巧得到了正确答案（比如数据恰好只有一条记录，不筛选也能蒙对），这种"假阳性"在生产环境中是非常危险的。

AD-Bench引入了轨迹覆盖率（Trajectory Coverage）这个指标，具体做法是：

把专家标注的工具调用序列作为参考轨迹 \(T_{ref} = [t_1, t_2, ..., t_n]\)，把Agent实际执行的工具调用序列作为预测轨迹 \(T_{pred}\)，然后计算 \(T_{ref}\) 是否是 \(T_{pred}\) 的子序列。

子序列匹配的意思是：专家定义的关键步骤都要出现在Agent的执行路径中，但Agent可以有额外的探索步骤。打个比方，专家说做一道菜的步骤是"切菜→炒菜→装盘"，Agent的步骤是"切菜→洗锅→炒菜→尝一口→装盘"，虽然Agent多做了两步，但关键步骤都覆盖到了，所以算通过。

这种设计的好处在于：它不强求Agent和专家走一模一样的路，而是检查Agent是否覆盖了所有关键操作环节。这比完全匹配更合理，因为不同的Agent可能有不同的探索策略，只要核心步骤没漏就行。

亮点二：动态Ground Truth生成

传统基准的一大硬伤是数据会过时。广告系统的数据每天都在变——昨天的消费和今天的消费完全不同。如果ground truth是三个月前标注的，评测结果就完全不可信了。

AD-Bench的解决方案很巧妙：记录专家操作的轨迹，而不是记录最终答案。评测时，系统会先回放专家的工具调用序列，用当前的实时数据重新生成一份ground truth，然后再拿这份新鲜的ground truth去评判Agent的输出。

这就像老师出数学题，题目的步骤和方法是固定的，但每次考试换一组数字。学生（Agent）需要用正确的方法解出当前的数字，而不是背上一次考试的标准答案。

这个机制从根本上解决了基准"保质期"的问题：数据可以随时刷新，评测永远基于最新状态。对于广告分析这种数据时效性极强的场景，这个设计几乎是必需品。

🧪 实验结果：谁是广告分析最强Agent？

十大模型大乱斗

研究团队在AD-Bench上测试了10个主流LLM，基于ReAct框架构建Agent。让我们看看谁的表现最好。

图1：各模型Pass@3成绩

图1：10个模型在AD-Bench上的Pass@3得分。GPT-5.1以69%领跑，但距离"好用"还有不小距离。值得关注的是，国产模型HY-2.0（混元）和DeepSeek-V3都达到了62%，与Gemini-3-Pro持平。

整理成表格：

模型 Pass@1 Pass@3 定位
GPT-5.1 57% 69% 第一梯队
Gemini-3-Pro 51% 62% 第二梯队
HY-2.0（混元） 49% 62% 第二梯队
DeepSeek-V3 51% 62% 第二梯队
o3 51% 59% 第三梯队
GLM-4.7 46% 59% 第三梯队
Kimi-K2 47% 59% 第三梯队
Qwen3-235B 34% 45% 第四梯队
Qwen3-32B 30% 41% 第四梯队
Qwen3-8B 24% 34% 第四梯队

几个有意思的发现：

没有一个模型突破70%。最强的GPT-5.1也只拿到69分——放在考试里这只是勉强及格。广告分析远比通用问答难得多，因为每一步都需要精确的参数传递和数值计算，容不得半点马虎。

Pass@1到Pass@3的提升幅度值得玩味。GPT-5.1从57%涨到69%，涨了12个点；而Qwen3-8B从24%涨到34%，也涨了10个点。这说明：给模型多试几次确实能提升成功率，但提升的幅度对强弱模型来说差别不大。换句话说，弱模型不是运气差，而是能力确实不够。

国产模型的表现可圈可点。混元2.0、DeepSeek-V3都能和Gemini-3-Pro打平手（62%），GLM-4.7和Kimi-K2也紧随其后（59%）。不过Qwen系列整体偏弱，特别是Qwen3-8B（34%），这可能和小模型在复杂工具调用场景下的指令遵循能力有关。

分难度级别的表现

更有意思的是按难度级别拆开看：

模型 L1 Pass@3 L2 Pass@3 L3 Pass@3
GPT-5.1 ~85% ~70% ~50%
Gemini-3-Pro ~80% ~62% ~42%
DeepSeek-V3 ~78% ~63% ~40%
Qwen3-8B ~55% ~30% ~15%

（注：上表为根据论文图表的近似值，用于展示趋势）

L1任务，多数模型都能拿到75%以上——毕竟就是查个数据，API调对了就行。但到了L3，成绩断崖式下跌，最强的GPT-5.1也只有50%左右。L3任务需要Agent跨多个数据源整合信息，还要调用知识检索工具获取行业背景，这种多步推理+知识融合的能力，目前的LLM Agent显然还撑不住。

轨迹覆盖率的故事

图4：各模型分难度级别的轨迹覆盖率

图4：分组柱状图展示了每个模型在L1、L2、L3三个难度级别上的轨迹覆盖率。L1几乎所有模型都能达到93%以上；到L2降至73-87%；L3更是直接跳水到27-70%。

轨迹覆盖率这个指标揭示的信息和Pass@k不太一样：

  • L1级别：所有模型的轨迹覆盖率都在93%以上。这说明简单任务大家都能"走对路"，关键步骤不会漏。
  • L2级别：覆盖率降到73-87%。有些模型开始跳步了，比如忘记做条件筛选就直接计算，或者漏掉了数据分组步骤。
  • L3级别：覆盖率暴跌到27-70%。最弱的Qwen3-8B只有27%，意味着专家标注的关键步骤中，它只走对了不到三分之一。

这里有个反直觉的点：L2级别轨迹覆盖率和Pass@3的相关系数只有0.372，远低于L1的0.784和L3的0.803。这意味着在L2任务上，即使Agent走对了路（轨迹覆盖率高），最终答案也不一定对。

为什么？因为L2的难点不在规划，而在精确计算。Agent可能正确地调用了数据查询和计算器工具，但传入了错误的数值、用错了聚合方式，或者在多步计算中累积了浮点误差。这就像一个学生知道要用二元一次方程组来解题（步骤对了），但在代入数字和消元的过程中算错了（结果不对）。

轨迹覆盖率与答案正确率的相关性

图3：轨迹覆盖率与Pass@3的相关性分析

图3：四组散点图展示轨迹覆盖率和Pass@3的相关性。整体相关系数r=0.691；按难度拆分后，L1为0.784（强相关），L2为0.372（弱相关），L3为0.803（强相关）。L2的低相关性说明该级别的瓶颈在计算精度而非规划能力。

这四张散点图讲了一个清晰的故事：

整体来看（r=0.691），轨迹走得对的模型，答案通常也更准——这验证了"过程评估"的合理性。但这个相关性不是完美的，说明光走对路还不够，执行的质量也很关键。

L1和L3呈现强相关。L1很好理解：简单任务步骤走对了，结果基本就对了。L3的强相关则说明：在复杂任务上，如果Agent连正确的工具调用路径都走不出来，最终答案就更不用指望了。L3的瓶颈确实在规划能力——模型需要拆解复杂需求、确定数据获取策略、安排工具调用顺序，任何一步出错都会导致后续全线崩溃。

L2的弱相关是最有价值的发现。它告诉我们：中等难度任务的失败点不在于"不知道该做什么"，而在于"做的时候做错了"。这对Agent系统的优化方向有直接指导意义——与其花大力气改进L2任务的规划能力，不如强化Agent在数值计算和参数传递环节的准确性。

🔬 错误分析：Agent到底在哪里翻车？

图6：L3任务的错误分析案例

图6：一个L3任务的详细错误分析，展示了四种错误模式（E1-E4）与正确轨迹的对比。E1是规划和参数错误，E2是检索失败和幻觉，E3是计算错误，E4是依赖性崩溃（上下文窗口耗尽）。这四种错误往往形成连锁反应。

研究团队系统性地分类了Agent的错误，归纳出四种典型模式：

E1：规划与参数错误（Planning & Parameter Error）

这是最上游的问题。Agent要么选错了工具，要么传错了参数。比如用户问"账户A过去7天的日均消费"，Agent调用了daily_data_by_group_and_field，但时间范围参数设成了30天而不是7天，或者把"日均"理解成了"总和"。

这种错误在L3任务中尤其频繁，因为L3任务的查询通常涉及多个约束条件和隐含的领域知识，Agent需要同时理解用户意图、拆解子任务、匹配正确的API——任何一个环节出问题都会污染后续所有步骤。

E2：检索失败与幻觉（Retrieval Failure & Hallucination）

Agent调用了知识检索工具但没找到相关信息，或者干脆跳过检索直接编造了一个"行业均值"。广告领域有很多特定的指标定义和行业标准（比如什么叫"优质计划"、ROI的计算口径是什么），如果Agent不去查而是靠自己的参数化知识来回答，就很容易出现言之凿凿却完全错误的情况。

这个问题其实在所有基于LLM的Agent系统中都存在，但在广告分析场景下格外致命：一个错误的行业数据可能直接影响投放决策，造成真金白银的损失。

E3：计算错误（Computation Error）

Agent正确获取了原始数据，也调用了计算器工具，但中间的数学运算出了问题。可能是单位换算错误、百分比计算方式不对、分母搞错了，或者在多步运算中丢了精度。

LLM做数学的能力一直是个老大难问题。虽然Agent可以借助calculator工具来减轻这个负担，但"把正确的数字以正确的方式传给计算器"本身就需要准确的理解和推理。就好比你给了一个人计算器，他还是可能因为按错了数字或者选错了运算符而得到错误的结果。

E4：依赖性崩溃（Dependency Breakdown）

这是最有意思的一种错误，也是L3任务中最常见的杀手。当Agent在前面几步消耗了大量token（比如检索返回了很长的数据表），到后面需要做整合分析时，上下文窗口已经快被撑满了。Agent要么"忘了"前面检索到的关键信息，要么因为生成长度受限而给出一个草草了事的结论。

这就像一个人在做开卷考试时，翻阅了太多参考资料，到写答案的时候脑子已经装不下了，只能凭着模糊的印象随便写两句。

四种错误的连锁反应：在实际案例中，这四种错误往往不是孤立出现的。E1（规划错误）会导致E2（检索了错误的信息），E2会喂给E3（用错误的数据做计算），而整个过程的冗长轨迹最终触发E4（上下文耗尽），形成一个恶性循环。这也解释了为什么L3任务的表现会如此惨淡——错误在多步推理中被不断放大。

📊 与其他Agent基准的对比

AD-Bench在几个维度上和现有基准形成了差异化：

特性 GAIA AgentBench WebArena SWE-Bench AD-Bench
领域 通用 通用 网页操作 代码修复 广告分析
数据来源 人工编写 合成+改编 模拟网站 真实GitHub 真实业务请求
评估维度 仅答案 仅答案 任务完成率 代码测试 答案+轨迹
数据时效性 静态 静态 静态 动态（PR更新） 动态（回放生成）
任务数量 466 多领域 812 2294 823
工具交互 部分 有 浏览器 代码编辑 9个专业工具

AD-Bench最大的亮点在于两个"真实"：数据来自真实业务场景，评估同时覆盖结果和过程。SWE-Bench虽然也用了真实GitHub issue，但它只评估代码是否通过测试，不关心代理的解题过程。而AD-Bench的轨迹评估维度，让它能捕捉到"蒙对答案但方法有问题"这种情况。

💡 我的观点和思考

这篇论文做对了什么？

从真实业务出发构建基准，这个方向我非常认同。学术界太多基准是"为了评测而评测"，数据是研究者自己编的，任务难度按主观感觉划分，和真实业务场景存在巨大的 gap。AD-Bench直接从腾讯广告营销平台的日志中筛选请求，这保证了任务分布的真实性——L2占47%这个比例，就不是拍脑袋能想到的。

轨迹评估的子序列匹配设计很优雅。既不要求Agent和专家走完全一样的路（太苛刻），也不是只看最终答案（太宽松）。子序列匹配允许Agent有自己的探索方式，只要关键步骤都到位就行。这个平衡点找得不错。

动态Ground Truth机制解决了一个真正的工程痛点。做过真实业务评测的人都知道，维护一套准确的ground truth有多费劲——数据一变，整套标注全得重来。轨迹回放的方式把"维护答案"变成了"维护方法"，大幅降低了长期运营成本。

哪些地方可以做得更好？

Agent框架的选择比较单一。论文只用了ReAct框架来驱动Agent。ReAct确实是主流选择，但像Reflexion（加入自我反思机制）、Plan-and-Execute（先规划后执行）这类更高级的框架，在复杂任务上可能会有完全不同的表现。只用ReAct评测，可能低估了某些模型在更好框架下的能力。

9个工具的设计覆盖面有限。真实的广告分析场景远不止这9个操作——A/B测试分析、素材归因、竞品对比、预算优化模拟等，都是高频需求。当前的工具集有点"精简版"的意思，未来可以扩展得更丰富。

样本量823条对于三级难度的分布，L3只有约240条。在这个量级下，个别极端case可能会对统计结果产生不小的影响。L3的结论虽然趋势明确，但置信区间可能比看上去要宽。

LLM Judge评测答案正确性引入了额外的不确定性。用一个LLM去判断另一个LLM的答案对不对，这个评估链条本身就不完美。论文没有详细报告LLM Judge和人工判断之间的一致性数据——在广告分析这种需要精确数值匹配的场景，LLM Judge的判断标准是什么？它如何处理"近似正确"的情况？这些细节值得更多讨论。

对工程实践的启发

如果你正在搭建广告分析相关的Agent系统，AD-Bench的结果给出了几个清晰的行动指引：

  1. 不要在L3任务上死磕单Agent架构。L3任务的多步推理+知识融合需求，靠单个Agent从头到尾执行很容易出E4（上下文崩溃）。更好的做法是拆分成多个子Agent：一个负责数据获取，一个负责分析计算，一个负责知识检索和总结。

  2. L2任务重点优化计算精度。论文的相关性分析清楚地表明，L2的瓶颈不在规划而在执行。可以考虑引入结构化的计算流水线——比如先让Agent生成SQL或Python代码来做数据运算，而不是通过自然语言描述让calculator工具去猜该怎么算。

  3. 轨迹监控是必要的。如果你的Agent系统只监控最终答案的准确率，你会错过很多"蒙对"的假阳性。建立工具调用轨迹的日志和分析机制，可以更早发现Agent的规划能力退化。

  4. 上下文窗口管理不能忽视。E4错误模式提醒我们，在长链条的多步推理中，要主动做信息压缩和摘要——不是把所有检索结果原封不动地塞进上下文，而是提取关键信息后丢弃冗余内容。

🔗 相关工作和技术脉络

AD-Bench的出现处在LLM Agent评测这条研究线路的一个关键节点上。往回追溯，这个领域的发展大致经历了三个阶段：

第一阶段：通用能力评测（2023-2024）。GAIA、AgentBench等基准试图回答"LLM Agent到底能做什么"这个宽泛的问题。它们的贡献在于建立了Agent评测的基本范式，但任务设计偏学术化，与真实业务场景脱节。

第二阶段：垂直领域评测（2024-2025）。SWE-Bench（代码）、WebArena（网页操作）、MINT（多轮交互）等基准开始聚焦特定领域。这一阶段的关键进步是引入了更真实的任务和更严格的评判标准——比如SWE-Bench要求代码能通过测试用例，而不是"看着差不多"。

第三阶段：过程感知评测（2025至今）。AD-Bench属于这一波。它的核心洞见是：在Agent系统中，结果正确性和过程合理性是两个独立的维度，都需要评估。这个方向目前还处于早期，但我认为会越来越受重视——毕竟在生产环境中，没人敢用一个"结果对但过程不可解释"的系统。

在工具使用（Tool Use）领域，ToolBench和API-Bank是两个有影响力的前驱工作。它们关注Agent能否正确选择和调用API，但评测的粒度比较粗——通常只看"调了对的API"，不检查参数是否正确。AD-Bench在这个基础上做了细化，把参数匹配也纳入了轨迹评估的范围。

在广告和营销领域，之前几乎没有像样的Agent基准。最接近的工作是一些广告文案生成的评测（比如Ad Creative Benchmark），但那些关注的是创意生成能力，不是分析推理能力。AD-Bench填补了"广告分析智能体评测"这个空白，对于广告技术（AdTech）行业来说是一个有价值的参考。

📝 总结

AD-Bench给我的最大感受是：LLM Agent在垂直业务场景中的能力被严重高估了。在通用基准上跑到80分的模型，放到广告分析这个具体场景中可能连70分都拿不到。这不是说模型不行，而是真实业务的复杂度——精确的参数传递、多步的数值运算、跨数据源的推理整合——远超通用评测能覆盖的范围。

从评测方法论的角度看，AD-Bench的"结果+过程"双维评估、动态Ground Truth生成机制，都值得其他垂直领域的基准借鉴。特别是轨迹感知评估这个idea，我觉得会逐步成为Agent评测的标配——一个只看结果不看过程的评测，就像只看期末考试成绩不看平时作业的老师，注定会漏掉很多重要的信息。

L2任务中轨迹覆盖率和答案正确率的低相关性（r=0.372），是这篇论文最有启发性的发现。它揭示了一个被广泛忽略的问题：Agent的规划能力和执行能力是两码事。我们在优化Agent系统时，不能只盯着让它"想对"，还要确保它"做对"。对于广告分析这类数据密集、计算密集的应用场景，后者可能比前者更关键。

展望未来，我期待看到AD-Bench团队在几个方向上的扩展：更丰富的工具集、更大规模的任务数据、多Agent协作场景的评测，以及——最重要的——把评测结果转化为具体的Agent架构改进方案。毕竟，评测的最终目的不是排名，而是指明优化方向。