面向业务落地的AI产品评测体系设计与平台实现

一、背景和挑战

1.1 背景

在人工智能技术迅猛发展的推动下，各行各业正经历前所未有的数字化转型浪潮。从智能制造的智能调度系统，到医疗领域的辅助诊断工具；从金融行业的风险预测模型，到电商场景下的个性化推荐引擎——AI 正在以一种不可逆转的趋势重塑产业格局。尤其值得关注的是，大模型技术的突破性进展不仅显著降低了 AI 应用的技术与人员门槛，更催生了“产业+AI”融合创新的广泛应用场景，为行业智能化升级注入了强劲动能。

在此大背景下，淘宝闪购技术部也在前两年就开始前瞻布局 AI 技术在业务中的深度应用。随着大模型的发展和业务场景探索的结合，FY26的AI应用已经从技术探索向价值落地转型，全面渗透至用户、商家、BD的核心操作环节环节，成为提升效率、优化体验的关键驱动力。当前已形成四类主要应用场景：

1. 数字人：如餐饮/零售智能新签经理、商家经营助手、AI 销售助手、面试招聘助手等，整体的发展路径从“被动”等用户提问到“主动”推出功能能力，提升用户满意度。

2. 数据分析与决策类产品：如经营分析、营销托管、AI售后、门店异动分析等，既可作为助手类产品的功能延伸，也可在自己模块内作为一个模块，有的具备一键采纳执行能力，助力商户快速识别问题并采取行动，提升决策效率。

3. 多模态内容创作类产品：如店铺装修、智能帮写、语音会议纪要等，进一步降低内容创作门槛，用户可一键采纳执行，赋能高效完成日常运营任务。

4. 搜推AI化：如C端、B端AI搜索，能够帮助用户搜索推荐店铺、商品，商户快速搜功能、搜品、搜订单、搜规则等。

1.2 挑战

在AI产品落地过程中，它的不确定性、动态性和复杂性，给质量和体验保障带来了前所未有的挑战。AI产品的特性使得测试既不是简单的功能验证，也不是纯算法模型的评测，我们梳理了面临的几个比较突出的挑战点：

研发合作模式变革	技术快速演进	Agent链路复杂度高
1、从“验收式测试”到“共创式评测” 工程产品是“需求明确 → 设计实现 → 测试验证”，AI产品则是“技术驱动 → 场景探索 → 效果迭代”的螺旋式过程。 挑战点： 评测需前置至需求阶段，与产品和研发共同定义“好”的标准。	1、应用架构演进快 模型、应用框架等基础建设日新月异，导致研发框架迭代升级频繁。 挑战点： 白盒分层测试在架构调整时要大改测试用例、脚本和基线，维护成本极高；如何平衡端到端测试和白盒测试。	1、金标数据回测难 在算法评测中，金标评测集可以长期复用；在agent场景：每次评测时，外部服务数据、时间、接口行为可能变化；即使输入相同，也会因为外围导致答案偏离原始金标。 挑战点：如何构建可回放的环境充分利用金标数据，减少金标数据失效。
2、研发节奏与版本形态变化 以前一个版本是一次代码发布；现在一个版本可能是：模型更换、prompt 改写、检索策略调整、工具编排改造或它们的任意组合； 挑战点：需要建立适配不同变更类型的评测策略组合，否则要么评测成本爆炸，要么质量风险不可控。	2、评测技术发展快 近年来LLM-as-a-judge、多模型互评、 Agent-as-a-judge、自动化对抗样本等新技术层出不穷。 挑战点：如何设计通用的评测平台，能快速集成新的用例集生成和评测方式；避免平台成为绑定特定技术的重资产系统。	2、线上效果评估难 线上效果评估同样面临链路复杂度与人工资源双重制约。 挑战点：如何通过"自动化+半自动化"构建标注体系，以裁判与规则筛查为主、辅以少量人工抽检校准。

二、评测体系思考

面对上述研发合作模式、技术演进与 Agent 链路复杂度带来的多重挑战，评测工作需要从传统的“验收活动”升级为贯穿AI产品全生命周期的“质量工程体系”，构建一套支撑其持续迭代发布的评测体系和平台，成为AI产品优化迭代的“指路灯”。

首先，我们来看整个研发模式流程的变化：

1）评测标准的制定从研发单一角色制定转变到产品、设计、研发、业务方（BD/运营）共同参与指标，从“研发自说自话”转向“业务-技术目标同频”，解决AI产品常见的“技术达标但体验崩坏”问题。

2）质量保障重心从单一线下测试拓展为“线下守基线+线上效果评估”双轨并行，确保迭代稳定性与线上效果的实时对齐。

3）针对多数产品缺乏专职标注团队的现状，人工评测不再依赖规模化的外包打标，而是通过“化整为零”策略，回收研发评测、产设验收及线上运营标注数据——将优质数据沉淀为金标集，对差的数据结合预期修正后转化为自动化回归用例，盘活全链路人工数据价值。

接下来，我们从"评什么（维度），怎么评（评测方式策略）、怎么度量（覆盖与效率）"以及“线上效果怎么评估”几个方面进行思考：

2.1 评什么（维度）——AI产品评价维度

AI 产品的评价指标不应千篇一律，但在顶层维度上可以相对稳定。通常可从以下五个维度展开，并根据产品生命周期和当前迭代重点动态调整侧重点，动态裁剪： 业务目标：对业务结果的贡献，如转化率、留存、GMV、人工替代率等； 产品效果：回答正确率、用户帮助性、组件/工具选择准确率、忠实度、逻辑性、数值幻觉等核心质量指标； 性能与体验：响应时延、多轮交互体验、截断率、用户满意度等； 安全与合规：内容安全、数据隐私、合规要求等； 服务与成本：服务稳定性、推理成本、资源使用效率、运维复杂度及整体性价比。

2.2 怎么评 ——评测方式和策略

端到端评测 VS 分层评测比较：

评测方式	端到端评测	分层评测
优点	1. 贴近真实用户体验，能直接回答“是否解决用户问题”； 2. 指标易于对业务方解释（任务成功率、满意度等）； 3. 适合作为版本对比和上线决策依据；	1. 能细化到意图识别 / 工具规划 / 文本召回等模块，便于精准定位问题和针对性优化； 2. 不同层可以采用最合适的指标；
缺点	1. 难以精确定位问题来源（是模型、检索还是工具出错）； 2. 在 Agent + 外部服务场景下，链路易随时间漂移，结果不稳定；	1. 评测集维护工作量指数级上升，需要为每一层单独维护用例与脚本； 2. 评测集和评测方式与开发实现耦合度高，需频繁跟随架构升级迭代调整；

面对Agent架构下链路复杂度高、版本形态多变等挑战，90%以上的供给AI应用均是基于E-LLM-Stack进行开发，E-LLM-Stack是面向淘宝闪购大模型应用解决方案的基建设施，旨在为淘宝闪购各业务线开发同学提供一套模板化、规范化、生产级的大模型应用解决方案，涵盖了从应用框架到原子能力的一站式方案。其他部门也会提供对前端的TPP、HSF接口，这部分的接口相对稳定，即使架构升级也会兼容老逻辑。

因此，我们推荐大部分AI产品的评测基于端到端评测，以AI应用对外的顶层解决方案/接口作为切入点，同时复杂的AI应用也会对接多个下游Agent，也可针对某个下游Agent实施精准测试，形成"全局把控+局部深挖"的保障机制，即避免了白盒过度绑定细节，也能精准定位到哪一类功能/问题，配合E-LLM-Stack上自带的链路跟踪排查工具，解决归因定位的问题。

主流的评测方式从是否有参考答案的维度上来讲：

• 有参考答案（Reference-based）

• 无参考答案（Reference-free）

对这2种方式进行一个比较：

评测方式	有参考答案	无参考答案
特点及适用场景	每个样本可以预先定义标准答案或有限集合的“可接受答案” 适用于目标明确、可标准化的场景：结构化问答、信息抽取、数据计算、一键执行调用参数正确性等	场景本身不存在唯一标准答案，或穷举标准答案成本极高 适用于开放式生成、多轮对话、创意写作等主观性强且答案多样的场景
优点	指标客观、可重复 可形成“金标集”，作为产品和模型演进的基线	数据构造灵活 能覆盖更多真实复杂场景
缺点	标注成本高，对开放式任务覆盖有限 在 Agent + MCP 场景下需依赖“可回放环境”，否则金标容易失效	评价主观性强，易受裁判 / 模型偏好影响，需通过抽样人工复核、裁判版本固化等方式控制稳定性和可比性 对数值、链接等强约束信息，如果没有配套规则/工具，即使人工也很难做精确核验

线下评测是 AI 产品质量保障的基础环节，评测方式重点是在可控环境下，充分利用金标数据对版本进行验证。没有金标数据的情况下，也要尽可能收集参考资料，为裁判评测提供依据。那针对有参考答案（Reference-based）和无参考答案（Reference-free）存在的短板要思考相对应的解决方案：

1）针对有参考答案的评测，我们核心要解决的是构造一个稳定可复现的“环境”。

去年我们在做智能新签评测时，已经意识到稳定可复现环境的重要性，开发了基于 EAgent3.0 （供给内部的一个对话类解决方案模板）的录制回放插件，可以在调用时记录外围工具的入参/出参、时间等信息；回放时注入当时记录的数据，实现评测环境的稳定，金标用例的可重复回放；后续规划将统一基于 E_llm_stack 对 MCP 层请求和响应进行记录和回放的能力，达到平台通用的目的。

2）针对无参考答案的评测，我们核心要解决的是跟上评测技术发展，有快速接入新评测范式的能力。

目前FY26 S1 我们采用的大多是 LLM-as-a-Judge范式，主要的落地形式有2种：

I、通过设计多维度、可量化的打分维度（如正确性、完整性、逻辑性、安全性等）建立类似指标衡量的基线；

II、通过抽样采集线上近几天数据进行预发回放，比对线上/预发返回做定性比较“好”、“坏”、“差不多”（比对评测）。

在实践中发现，通用裁判模型对有些产品内的细节不了解，难以判断，因此针对复杂场景从通用的“模型裁判”升级为微调的 "模型裁判"或“Agent 裁判”，让裁判本身具备检索、工具调用等能力，主动收集可佐证的参考资料后再打分，提高对事实、数值、外链等细节的判断能力。如下图所示：

此外，我们尝试规则和启发式检测，沉淀通用工程规则、裁判通用规则（如格式校验、淘宝闪购禁发品黑名单等规则等），提供给各个业务做检测支持。构建通用+定制的多裁判的方式。

2.3 怎么度量——覆盖度量与效率

评测方式和策略确定之后，真正落地到每一次版本迭代，首先要回答的不是“怎么评”，而是“评多少、评哪些”：在有限的时间和人力内，本次迭代应该选择哪些评测集、覆盖到哪些场景和链路，才能既保证质量，又能满足90%以上的回归在小时级别完成，这恰恰是当前线下评测的核心难点之一。我们建议按“变更范围 × 变更风险”来设计三档评测策略，并通过用例标签体系自动筛选推荐用例：

版本等级	典型变更	线下评测策略	用例选择
小变更	Prompt 针对性微小调整 召回参数、排序权重小幅微调 UI 文案 / 轻量交互变更，对底层能力影响极小	目标：快速确认“无裂化” 小规模端到端冒烟用例（覆盖关键主链路 + 典型高频场景）	筛选核心场景 + 抽样高风险场景 + 抽样高频BadCase的少量代表性用例
中等变更	日常需求迭代，新增 / 调整一个工具或知识源/接入Agent 调整 Agent 策略（如规划、反思、重试逻辑）	目标：确认变更点效果有提升且未引入新的明显问题 围绕变更点的定向专项端到端评测 补充无参考答案评估（LLM 评审 + 人工抽查）	筛选或新增本次特定业务场景 + 受到本次变更工具/链路的影响数据 + 历史 BadCase
重大变更	基础模型替换或新增模型路由 大规模重构，多工具编排方案变化 关键业务流程逻辑重写	目标：系统性验证整体质量 全量或高覆盖端到端回归（覆盖核心业务、长尾场景、安全与越权场景）	全量沉淀的产品金标用例 线上近期数据的对比回放裁判评测 必要时引入对抗样本，探索潜在新风险

这套“按变更分级 + 标签选集”的策略能否落地，前提是要有一套清晰、可操作的用例标签体系。S2 阶段我们计划从三个主维度入手进行建设，在保证简单可用的前提下，为后续按需扩展留出空间。

主维度	标签字段	示例取值
业务维度	业务领域	基础与咨询/履约/营销/门店基础/……
	商户/用户特征	到家/到店，单店/连锁等等
	场景功能	异常归因/商圈诊断/机会品/账单诊断/……
质量与风险维度	风险等级	高/中/低
	重要程度	P0 / P1 / P2
	是否线上BadCase	是/否
	对抗样本	是/否
系统链路维度	任务类型	RAG问答/数据分析/工具执行/经验匹配……
	工具/服务	无工具 / Tool_A / Tool_B / Agent_C …
	是否深度思考	是/否

2.4 怎么评估线上效果

线上评估方面，我们从数据采集（用户反馈+系统日志）→ 问题发现（监控+人工+智能挖掘）→ 根因定位（基于链路分析工具）→ 优化落地，形成“监测-分析-优化”完整闭环。

2.5 怎么能力扩展通用——支撑更多业务

每个业务有自己的特色，平台除了主站提供通用能力外，已完成与三大主流淘宝闪购AI开发与评测平台的深度对接，但底层任务调度与执行依然由评测平台保障和支撑。

三、平台建设

3.1 平台架构及能力

除了在实践中不断思考和实践评测体系外，我们也持续建设了一年多的大模型应用评测平台，沉淀了较丰富和完整的能力，支撑我们的评测体系落地。平台核心设计理念是"标准化流程+插件化扩展"——在评测技术日新月异的背景下，通过解耦评测步骤与实现逻辑，既保障流程规范性，又能快速集成各模块的新实现。

在平台建设中逐步将供给域验证有效的评测能力抽象为通用组件服务更多团队：评测场景注册支持集团内HSF/TPP/Whale等多协议接入，评测集兼容Excel/ODPS、SQL/流量录制/日志等多源数据；评价指标覆盖工程指标、文本指标、RAG指标和Agent指标、同时支持模型裁判、agent裁判。

具体架构图如下所示：

3.2 平台成果

自大模型应用评测平台上线后，不仅支持了淘宝闪购部门，外部羚羊、菜鸟、淘天、阿里云等部门同学的试用和交流。平台能力演示等如下：

大模型应用平台阶段成果

平台用户增长 接入部门：10+ AI产品数：90+ 平台UV：300+ 深度用户：200+创建评测任务用户

资产沉淀及问题发现 评测集：1,053 评测场景：652 裁判评价模板：67 发现问题200+仅统计默认空间 累计问题研发解决率80%+

平台稳定性 累计执行任务12,000+次 累计执行数据量：150w+ 执行成功率：95%+ 答疑24H解决率：85%+ 线上问题双周解决率：95%+

备注：数据统计截止2025.9.30

四：未来展望

01、支持多模态评测能力

目前平台主要服务于文本类 AI 产品，评测流程和工具相对成熟。但随着图片、音视频等多模态能力在业务中的落地，单一文本评测已经无法覆盖整体体验。

规划方向：

平台从“AI文本类产品评测平台”演进为“多模态 AI 评测平台”。

• 在现有评测框架之上，逐步扩展对图片类 AI 产品的评测能力；
• 引入适配多模态的自动评估方法（如多模态 LLM 裁判、视觉质量指标）与人工标注流程，构建文本 + 图片贯通的评测基线。让平台从“文本评测工具”演进为“多模态 AI 评测基础设施”。

02、可视化标注工作台

目前标注人员需要直接理解技术字段（如工具组件名称、工具调用链路），上手门槛高，业务同学参与度有限。要想把评测真正做成“产品–研发–测试–业务共建”，必须降低标注门槛、提高协作效率。

规划方向：

通过可视化标注工作台，让“懂业务的人能轻松标，懂技术的人能高效复盘”，真正把评测数据建设变成全团队的持续协同过程。

• 构建动态渲染引擎，将抽象的技术组件和链路信息（定制组件渲染、工具调用等）转化为直观的页面表达，以「业务视角」呈现评测样本。

03、开放"评测能力插件市场"

不同业务线在评测标准、规则与指标上存在差异和定制，若所有评测规则和指标都由平台团队统一实现，不但响应慢、维护成本高，也难以匹配各业务的细粒度需求。

规划方向：

评测平台从“一个团队维护的工具”升级为“多业务共建的评测能力生态”：

• 提供统一的评测能力接口规范，支持各业务方上线自定义的评价规则（如专有安全规则、业务得分模型）和评价指标；
• 在平台中构建「评测能力插件市场」，允许不同业务沉淀的插件被跨业务复用（如通用安全规则、通用事实核验 Agent 等）；