One-Eval：自动化且可追踪的 LLM 评估智能体系统 One-Eval: An Agentic System for Automated and Traceable LLM Evaluation
通过自然语言请求自动生成可执行、可追踪的 LLM 评估工作流
前置知识
大语言模型评估
大语言模型评估是通过设计标准化测试任务（如数学推理、知识问答、代码生成等），在特定数据集上衡量模型能力的系统性方法。评估框架通常需要配置基准数据集、选择合适的评估指标（如准确率、BLEU、Pass@K）、处理多模态输入输出，并确保评估过程可复现。评估结果用于模型选择、迭代优化和部署决策。
本文核心是自动化 LLM 评估流程，需要理解传统评估框架的手工配置痛点，才能理解 One-Eval 的自动化价值。
智能体系统
智能体系统是能够自主感知环境、推理规划并执行工具调用的 AI 系统。在 LLM 领域，智能体通常通过 Prompt Engineering 赋予 LLM 规划能力，使其能够分解复杂任务、调用外部工具（如搜索、代码执行）、进行多轮对话迭代，最终完成端到端的目标。关键组件包括任务分解、工具调用接口、状态管理和决策机制。
One-Eval 将模型评估重新设计为智能体驱动的任务，理解智能体的规划、工具调用、迭代优化机制对理解本文的方法创新至关重要。
基准数据集
基准数据集是用于标准化评估模型能力的数据集集合，包含明确的任务定义、输入输出对和评估协议。常见的评估基准如 GSM8K（小学数学推理）、MMLU（多任务语言理解）、MATH（竞赛数学）、TruthfulQA（事实性问答）等。每个数据集可能有多个配置子集，数据格式异构，需要统一的 schema 规范化。
One-Eval 的核心创新之一是自动化基准数据集的发现、解析和配置，理解基准数据集的异构性和配置复杂性是理解 BenchResolve 模块的基础。
研究动机
现有 LLM 评估框架在实际工业应用中面临显著的手工配置负担。主流的 lm-eval-harness 和 OpenCompass 等工具虽然提供了标准化的执行接口，但要求用户手动完成以下工作：首先从众多公共基准中发现合适的评估数据集（如从 HuggingFace Hub 上数千个数据集中筛选），然后处理异构的数据格式（不同数据集使用不同的字段命名和 schema，如 question vs input、answer vs target），接着配置正确的 subset/split（如 MMLU 有多个学科子集，某些数据集缺少 test split），最后选择合适的评估指标并解释聚合结果。这些流程高度依赖专家经验，迭代成本高，当评估需求变化或新基准发布时，整个配置流程需要重新执行。更重要的是，现有工具的输出通常是孤立的标量分数（如准确率 78.5%），难以支持面向决策的分析，例如识别模型在哪些具体能力维度上薄弱、失败案例的分布特征、性能变化的根本原因等。
本文的目标是本文的目标是构建一个端到端的自动化评估系统，将用户的自然语言评估请求（如评估模型在数学推理和通用知识方面的能力）转化为可执行、可验证、可定制的评估工作流。该系统需要自动化完成意图解析、基准发现、数据获取、配置规范化、指标选择和报告生成的全过程，最小化用户的手工配置工作。同时，系统需要产生决策导向的评估报告，而非仅仅输出标量分数，使评估结果能够直接支持模型选择、发布决策、回归监控等工业应用场景。此外，系统必须保留可审计的证据链，确保评估过程的透明性和可复现性。
与已有工作不同的是，本文的独特切入角度是将模型评估重新构想为一个智能体驱动的端到端决策过程，而非传统的执行框架。现有工具主要关注执行层面（如何高效运行已配置好的评估），而本文关注更高层面的挑战：如何将抽象的评估意图转化为可靠的可执行流水线。关键创新在于引入（1）NL2Bench 模块进行意图结构化和个性化基准规划，而非依赖静态的基准套件；（2）BenchResolve 模块处理异构数据源的自动解析和配置规范化，建立本地优先、动态回退的分层解析策略；（3）Metrics & Reporting 模块进行任务感知的指标推荐和分层次诊断报告生成，突破传统标量分数的局限性。通过显式建模评估意图、工作流构建和结果解释为相互关联的阶段，One-Eval 在用户目标和可执行评估流水线之间架起了桥梁。
核心方法
One-Eval 采用了模块化的三阶段流水线设计。给定用户的自然语言评估请求，系统首先通过 NL2Bench 模块解析评估意图并构建合适的评估计划；然后通过 BenchResolve 模块解析基准并完成数据获取、依赖管理和配置验证，确保评估工作流可执行且一致；最后通过 Metrics & Reporting 模块执行评估指标推荐和生成任务导向的评估报告，产生结构化、支持决策的评估结果而非单一的标量分数。整个流程中集成了人机交互机制，允许用户在关键决策点检查、修正和验证中间决策。从技术路线来看，One-Eval 将每个阶段设计为独立的智能体，通过结构化的状态传递进行协作，同时支持用户干预和回滚，确保自动化效率与可靠性的平衡。
One-Eval 的核心创新在于将模型评估从一个静态的配置执行任务转化为一个智能体驱动的动态决策过程。与 lm-eval-harness 等框架需要用户预先指定基准列表和配置参数不同，One-Eval 通过 NL2Bench 模块自动将自然语言意图转化为结构化的评估计划，并从本地精选基准库和 HuggingFace Hub 双源检索候选基准。BenchResolve 模块采用分层解析策略：对于高频基准使用本地预验证配置确保稳定性，对于长尾基准动态从 HuggingFace 下载并自动推断配置（subset/split、schema 映射、任务类型），构建统一的 BenchInfo 配置对象。Metrics & Reporting 模块通过双轨策略推荐指标：用户提供的静态配置优先，未配置任务则通过知识增强的语义推理动态推荐，并生成宏观能力画像、根因诊断和微观案例分析三个层次的报告。这种设计的关键技术新颖性在于（1）意图驱动的基准发现机制，（2）异构数据源的自动规范化，（3）多粒度诊断报告生成，以及贯穿全流程的可追溯证据链。
方法步骤详情
One-Eval 的方法步骤完整描述如下。第一步（NL2Bench）：用户输入自然语言评估请求（如评估模型在数学推理方面的能力），QueryUnderstandAgent 将其解析为结构化意图表示，包括评估领域和能力焦点（如 domain=[math, reasoning]）、用户明确指定的基准、执行约束（如语言要求）和额外偏好。基于结构化意图，BenchSearchAgent 从本地精选基准库（77 个可端到端运行的基准）和 HuggingFace Hub 双源检索候选基准，使用基于嵌入的语义检索和基于 TF-IDF 的轻量级检索两种可互换后端。候选基准经过归一化处理（如将 mmlu 解析为 cais/mmlu）和选择约束（如评估成本、冗余性、可执行性）过滤后，生成评估计划并通过人机交互供用户确认、编辑或注入自定义基准。第二步（BenchResolve）：BenchResolveAgent 将评估计划转化为可执行配置，采用本地优先的分层解析策略。对于匹配本地注册表的基准，直接加载预验证的配置（包括验证过的评估 split、列映射和任务注解）；对于未匹配的基准，回退到 HuggingFace 动态解析：尝试通过给定名称直接加载，否则搜索候选并使用轻量级启发式方法（如后缀提示和语义相似性）选择最佳匹配。解析后自动下载数据集和元数据，将异构的 schema 规范化为统一的 BenchInfo 对象，记录数据集来源（HuggingFace ID 或本地路径）、评估子集/split、列映射到 One-Eval 标准输入输出接口、以及用于下游指标推荐的任务元数据。BenchResolve 在解析过程中验证这些字段，并将它们作为可追踪的工件（如解析的 ID 和缓存路径）持久化。第三步（Metrics & Reporting）：MetricRecommendAgent 实施优先级双轨策略推荐指标。（1）用户覆盖（静态控制）：基准元数据中提供的显式指标配置具有严格优先级；（2）知识增强推理（动态适配）：对于未配置或开放性任务，智能体对丰富的数据集上下文（如提示模板、少样本样本、任务描述）执行语义推理，通过运行时扫描注册的指标库生成语义描述和决策规则，将这些注入 LLM 上下文以指导指标选择；（3）注册表回退：如果 LLM 未能产生有效计划，系统回退到 MetricDispatcher 的基于规则的建议或最小默认集以保证流水线连续性。指标选择后，ScoreCalcAgent 调用 MetricRunner 作为统一执行层，规范化异构输入、将预测与参考对齐、支持大规模数据集的并行执行、并在可用时用分数、优先级和详细信息打包结果。ReportGenAgent 通过（1）宏观视图（能力画像）将结果聚合为雷达和旭日摘要以进行整体能力画像；（2）诊断视图（根因分析）归因失败模式（如指令跟随错误 vs 幻觉），对失败样本执行盲点分析，总结正确与错误输出的长度分布；（3）微观视图（案例分析）提供链接聚合指标到特定失败实例的案例级检查表，生成分层次诊断报告。
技术新颖性
One-Eval 的技术新颖性体现在多个层面。首先，在意图理解方面，NL2Bench 模块将自然语言请求转化为结构化意图表示，并通过双源检索（本地精选库 + HuggingFace 实时搜索）和相关性阈值过滤（嵌入模式阈值设置为 0.5，TF-IDF 模式阈值设置为 0.3）实现意图对齐的基准推荐，这与传统框架依赖静态基准套件或手动选择形成本质区别。其次，在基准解析方面，BenchResolve 的分层解析策略结合了本地预验证配置的稳定性和动态 HuggingFace 解析的扩展性，通过自动 schema 规范化（如将 GSM8K 的 question 映射为 input、answer 映射为 target，将 TruthfulQA 的 question 映射为 input、correct_answers 映射为 targets）构建统一的 BenchInfo 抽象，解耦了评估执行与数据表示的异构性。第三，在指标推荐方面，双轨策略（用户覆盖、知识增强推理、注册表回退）结合了静态控制的灵活性和动态推理的鲁棒性，通过分散式指标注册接口构建可扩展的指标生态系统。第四，在报告生成方面，多粒度诊断报告（宏观能力画像、根因分析、微观案例分析）突破了传统标量分数的局限性，提供了决策导向的可操作信号。最后，在系统架构方面，人机交互机制作为受控的细粒度干预点（用户可以确认基准覆盖度、调整约束、批准报告偏好），确保自动化与用户评估目标的一致性。
实验结果
通过三个互补的实验研究，One-Eval 展示了在工业可用性和可靠性方面的有效性。在定性案例研究中，系统成功将用户的自然语言请求（聚焦广泛的通用知识覆盖，检查模型是否能够处理一些轻量级推理）转化为可执行和可审计的评估工作流。NL2Bench 模块将请求解析为意图槽位（domain=[text, reasoning]），提议覆盖知识和推理的基准计划，包括 mmlu、truthful_qa、commonsenseqa 以及推理导向的数据集 openai/gsm8k 和 HuggingFaceH4/MATH-500。BenchResolve 自动选择可运行配置和 split 并记录基本原理，例如 GSM8K 配置为 config=main, split=test，MATH-500 使用 config=default, split=test（唯一可用子集），TruthfulQA 回退到 split=validation（无 test split）。系统通过列映射规范化异构 schema，在异构基准间实现统一评估接口。在端到端成功率评估中，研究收集了 100 个涵盖六个广泛能力域（推理、数学、代码、安全、检索和事实性 QA）的自然语言评估请求，在无人工修正的情况下运行完整流水线。三个累积成功指标显示：Plan Executable Rate（系统可解析用户意图并检索至少一个基准候选）为 99/100（99%），单次失败由高度模糊的查询导致意图结构化智能体无法分解；Auto-Complete Rate（推断的子集、split 和键映射正确）为 85/100（85%），表明自动化 schema 推断对大多数公共基准是可靠的；Full Plan Rate（成功的任务类型推断和指标推荐）为 84/100（84%）。8 步流水线每个请求的中位耗时约 11.4 分钟（平均 13 分钟），表明 One-Eval 可以在实用时间预算内从单句自然语言交付可执行的评估计划，无需任何人工干预。在特征级别比较中，One-Eval 在四个关键工作流能力上超越了代表性评估框架：支持自定义基准和指标，而 lm-eval-harness 和 OpenCompass 仅支持自定义，HELM 不支持；端到端自动化，而其他框架均不支持；意图驱动的基准推荐，而其他框架均不支持；意图驱动的指标推荐，而其他框架均不支持。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 端到端评估计划生成 | Plan Executable Rate | 99% | N/A | 99%的自然语言请求可成功解析意图并检索基准候选 |
| 自动化配置完成率 | Auto-Complete Rate | 85% | N/A | 85%的请求自动推断子集、split和键映射均正确 |
| 完整评估计划率 | Full Plan Rate | 84% | N/A | 84%的请求成功完成任务类型推断和指标推荐 |
| 端到端处理时间 | 平均耗时 | 13分钟 | N/A | 中位耗时11.4分钟，实用时间预算内交付可执行计划 |
局限与改进
作者承认的局限性包括：（1）基准覆盖度有限，当前本地精选基准库包含 77 个基准，虽然支持回退到 HuggingFace Hub 搜索长尾基准，但对于非常新或小众的数据集可能支持不足；（2）指标库的扩展性依赖于手工注册新的指标函数和语义元数据，虽然提供了分散式注册接口，但仍需要领域专家贡献；（3）复杂评估场景的支持可能需要额外的工程工作，例如自定义评估逻辑或私有数据处理；（4）人机交互机制虽然提供了细粒度控制，但在某些情况下可能需要多次迭代才能达到满意的基准计划。基于对论文的独立分析，可以观察到以下额外局限性：（1）系统严重依赖 LLM 的意图解析和决策能力，对于高度歧义或领域特定的评估请求可能产生不准确的基准推荐；（2）HuggingFace Hub 的动态解析受限于公开数据集的质量和元数据完整性，某些数据集可能缺少标准的 dataset card 或存在错误的 split 标注；（3）多粒度诊断报告的生成需要额外的计算开销，对于大规模评估任务可能影响整体效率；（4）系统的成功率的评估是在不执行实际模型评估的情况下进行的，真实场景下的端到端成功率可能受到模型推理错误、超时、资源限制等运行时因素影响。
独立分析的弱点
独立分析的第一个弱点是本地精选基准库的规模限制。当前 77 个基准虽然覆盖了常见的能力域，但面对快速发展的 LLM 评估领域，新基准的发布速度远超人工精选的更新频率。改进方向是建立自动化的基准质量验证流水线，定期从 HuggingFace Hub 采样新数据集，自动测试可执行性和配置正确性，动态扩展本地库。第二个弱点是指标推荐的语义推理依赖 LLM 的上下文理解能力，对于复杂任务或多指标组合场景，LLM 可能产生不稳定的推荐。改进方向是增强 MetricRecommendAgent 的知识库，引入任务-指标的专家标注规则库，在语义推理基础上增加基于规则的验证和纠偏。第三个弱点是 HuggingFace Hub 动态解析的健壮性不足，某些数据集的元数据缺失或标注错误会导致解析失败。改进方向是引入容错机制和启发式规则库，对缺失的 split 标注进行推断（如根据数据集大小和命名模式推断 test/validation/train），对异常的 schema 进行标准化映射。第四个弱点是人机交互机制的反馈循环可能需要多次迭代，影响效率。改进方向是引入主动学习机制，从历史用户交互中学习常见调整模式，预判可能的修改建议并自动优化后续推荐。
未来方向
作者提出的未来工作方向包括扩展任务和模态的覆盖度，例如支持多模态评估（视觉-语言模型、音频模型）、更复杂的评估任务（长文档理解、多轮对话评估、代码安全性评估），以及加强对长尾基准的支持。基于 One-Eval 的成果，可以延伸以下研究方向：（1）评估需求的自动化演进分析，通过分析历史评估请求的模式，预测未来可能需要的基准和指标，主动扩展评估能力；（2）评估结果的知识图谱构建，将多轮评估的结果链接到具体的能力维度、失败模式和改进方向，支持评估经验的积累和复用；（3）评估流水线的分布式执行优化，对于大规模评估任务，支持并行执行多个基准、动态资源调度和增量更新；（4）评估报告的个性化生成，根据用户角色（工程师、产品经理、质量专家）定制不同的报告视图和关键指标；（5）评估基准的质量评估和推荐，不仅关注基准的覆盖度，还评估基准的多样性、偏差性和难度分布，推荐更全面的基准组合。
复现评估
One-Eval 的代码已公开在 GitHub（https://github.com/OpenDCAI/One-Eval），为复现提供了基础。系统将中间工件作为一流的持久化状态（计划、配置、解析的基准标识符、schema 映射、缓存路径、每样本追踪），使得结果可被审计和复现。本地精选基准库包含 77 个可端到端运行的基准，每个基准都有规范的元数据（别名、类别标签、任务类型注解、HuggingFace 配置和键映射），确保了评估协议的一致性。对于端到端成功率评估，论文提供了 100 个自然语言评估请求的范围描述（涵盖六个能力域），但未公开具体的请求列表和详细的成功/失败案例分析，这增加了精确复现实验的难度。系统的计算依赖主要包括 LLM API 调用（用于意图解析、基准推荐、指标推荐）、HuggingFace 数据集下载和缓存存储，算力需求相对可控。复现难度主要在于配置 LLM API 密钥、处理网络访问限制、以及可能需要调整某些启发式阈值（如相关性阈值）以适应特定的评估请求分布。总体而言，One-Eval 在框架层面提供了良好的可复现性支持，但在实验细节的公开程度上仍有改进空间。
论文图表