Agent自动化评测技术
1.大模型评测的通用技术框架
（1）核心评测维度
模型效果（事实性、有用性、有害性）
推理性能（响应延迟、资源消耗）
健壮性（安全性、容错性）
（2）常见评测方法
人工评测（专家打分、双盲对比）
自动化评测（文本相似度、Rank排序、Elo分等）
人机协同评测
（3）技术痛点
评测集“失真”（模型效果与实际应用脱节）
评测指标单一化（依赖少数指标评估模型原子能力）
动态效果追踪难
事实性：指模型在回答时是否遵从通识和常识，在给定上下文的情况下是否依据证据作答，是否存在“幻觉”。
有用性：回答的是否对任务有帮助，不能只是讲了实话却对问题没有实际价值。
有害性：模型训练和评估都会关注的方向，比如是否触及政治敏感、是否引导不当行为等。
性能与推理性能：首个Token出现的时间，也就是首字符/首Token时延，以及完整推理过程中的生成速度等；同时还要看资源消耗，这些都应纳入评估口径。
稳健性：鲁棒性，重点在于能不能容错、持续稳定地输出，以及面对对抗或异常输入时的抗攻击能力。这些都直接关系到上线后的可用性与风险。
人工评测：在大模型生成带有主观性的内容时，比如一次性生成几千张创意图片，哪个更好、哪个更差，通常要先请领域专家过一遍，并据此写出清晰的评价标准——我们认为什么是“好”，什么是“坏”；
自动化评测：客观题，便于直接做结果匹配；文本类会更难一些，常见的思路是和标准答案做相似度比较，配合相应算法和指标，比如BLEU、ROUGE等；还有一类是基于排序的评估（rank），在RLHF里就很典型——不是给一个绝对分，而是让人对多个候选进行相对优劣比较，从而完成与人的偏好对齐。

人机协同评测：很多场景里，纯自动化还达不到足够准确、足够让人放心的程度，于是通常采用机器先给出初步结论和建议，再由人工复核与定判。
评测Benchmark：静态评测和线上实际效果脱节的问题。评测往往针对模型的单一能力，或者若干常见的通用能力。即便有了一个评测集，业务在变，产品定义在变，线上用户的使用方式也在变。这个时候，评测就更难反馈线上的真实情况。

数据应用Agent的垂直适配难点
领域特殊性：数据领域偏重SQL，应用和评测。数据分析对准确性要求极高。
维度扩展：从基础能力到复杂场景（如深度分析的逻辑合理性和洞察性评估），对复杂数据源和多分析角度的评估。
效率挑战：评测时效影响研发迭代（自动化评测尤为重要），新场景层出，需要评测快速定义场景、构建评测集、开发评测算法。

三层评测体系设计
贯穿“技术选型-研发迭代-业务效果”的全流程评测
技术选型：对比不同基座模型在数据应用场景的适配性，提供量化依据。
研发迭代：Step-wise单元评测（如召回、规划等阶段/组件级的评测）。Multi-Agent、ReAct、workflow。
业务效果：结合业务场景，评估Agent端到端效果，同时将线上问题回流。

基础能力评测：技术选型阶段，先设定一个“准入门槛”，以数据领域为例，会关注工具调用能力（Function Call、Tool using、MCP等）、数值计算与表格理解、数据幻觉的控制、复杂指令遵循，以及编码与Text-to-SQL。各个方向基本都有可参考的开源Benchmark。
组件：面向的是Agent的各个组成部分，可以把一个Agent的工作流程拆成几个阶段：先是召回，比如做Schema Linking，然后是理解与规划，接着进入洞察、分析与执行，最后是结果总结，把结论写成报告。
问题出在第几个阶段，以及每个阶段的实际表现如何。放到一个典型的RAG应用里，前序召回的上下文质量会直接决定后续表现：Scheme里有没有找到正确的字段、阈值和指标，都会影响后面SQL能不能写对。如果第一阶段就偏差很大，后面再怎么优化Agent也很难“拉回”。
端到端效果评测：一方面，我们针对特定的业务场景构建相应的评测集；层级越往上，我们离业务越近，评测也就越贴近实际的业务场景和产品形态的定义。
我们相应地构建评测集和自动化评测方法；同时，在我们的评估平台上设有“数据与飞轮”模块对接业务，把线上的会话日志采集进来，用于Case Study、回归评测集的沉淀，以及人工标注。