awesome-evals
AI Agent 评测领域的精选知识库,443条资源+146篇深度笔记,Claude Code自动更
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
AI Agent 评测领域的精选知识库,443条资源+146篇深度笔记,Claude Code自动更
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
深夜两点,你终于把 Agent 的工具调用逻辑调通,却发现一个更头疼的问题:怎么量化评估它的表现?传统的单元测试不适用,端到端验收没有标准答案,让人工打分成本太高且不可复现。你翻遍了 GitHub,下载了十几个 benchmark,结果发现大多数要么数据泄露严重、要么脱离实际场景、要么根本没有可运行的代码。
这正是 BenchFlow awesome-evals 试图解决的核心痛点——它不是一个 benchmark,而是一套经过严格筛选、可验证的 AI Agent 评估知识库,由从业者手工维护,拒绝 SEO 垃圾内容,每一条都附带背景说明和来源链接。
AI Agent 赛道在 2024-2025 年爆发式增长,但评估基础设施严重滞后。大多数 benchmark 存在三大通病:
数据污染(Contamination):热门评测集(如 MMLU、HellaSwag)早已被各大模型的训练语料覆盖,刷分成了"背诵考试"而非能力测量。BenchFlow 在 README 中专门开设" Benchmark vs. eval"章节,系统性揭示了数据污染、饱和效应、标签错误、排行榜作弊等问题的识别方法。
脱离实际场景:很多 benchmark 考的是选择题或短问答,而真实 Agent 需要完成多步骤、工具调用、环境交互的复杂任务。Agent 评估的核心是轨迹(Trajectory)评分和世界状态(World State)追踪,不是简单的文本匹配。
缺少可运行代码:大多数论文只描述方法,不提供实现。开发者拿到结论后还要自己写 evaluator,工作量巨大。
BenchFlow 的维护团队(BenchFlow.ai)正是看到这个缺口,决定构建一个"非 BS"(原文 non-BS)的精选列表,目标是让从业者能在 5 分钟内找到可信的评估方案并直接复用代码。
BenchFlow awesome-evals 的内容分为两大部分:
第一部分:README.md 分类索引。作者采用"递归引用爬取(Depth-4 Citation Crawl)"从 1.16 万篇论文中筛选出学术经典,同时结合目标从业者发现(Targeted Practitioner-Web Discovery),覆盖了 Eugene Yan、Shreya Shankar、Hamel Husain 等一线实践者的博客和演讲内容。整理出以下分类:
第二部分:PATTERNS.md 可运行代码模式库。这是整个项目最有价值的部分——不同于一般资源列表只给链接,PATTERNS.md 提供了可直接复制到项目中的代码模板,每种模式都标注了来源(引用链可查)。包括:
LLM-as-judge 二值判决器:核心思路是不用 1-5 分制,改用 PASS/FAIL 二值判决。判决器先写推理过程,再输出结论。用专家标注的少量样本(Few-shot critique)替代长篇评分标准,用 TPR(Recall on failures)和 TNR(Precision on passes)分开验证,而非原始准确率。
pass@k / pass^k 无偏估计器:当需要从 k 次尝试中任意一次成功就算通过时(如代码生成),用无偏估计器计算真实通过率,避免低采样导致的偏差。代码中附带了完整的 Python 实现和数学推导。
轨迹 & 工具调用评估:评估 Agent 的中间步骤质量,而非仅看最终结果。包含轨迹截断率、工具调用顺序、上下文利用效率等多维度指标。
环境状态评分:对于涉及文件系统、数据库、外部 API 的 Agent,追踪执行前后的状态差异作为客观评分依据,避免主观判断。
CI 门禁集成:将评测集作为回归测试嵌入 CI 流水线,在每次 PR 时自动检测能力退化,并提供可配置的阈值告警。
图1:BenchFlow 官网开放图
最令人印象深刻的工程细节是"The Scan"——项目通过 Claude Code GitHub Actions 实现了自主更新。每天 UTC 08:23(可手动触发),工作流会:
这意味着 awesome-evals 是一个活的文档,不需要维护者手工追踪领域动态,系统会自动发现并验证新内容。
推荐使用的人群:工作 1-3 年的 AI 应用工程师、评测平台开发者、高校 AI 研究者。
不适合的场景:如果你需要的是一个开箱即用的 benchmark 而非评估方法论,这个仓库对你来说太"元"了。它给的是"怎么选 benchmark"和"怎么写 evaluator",不是 benchmark 本身。
上手建议:从 PATTERNS.md 开始,先看"LLM-as-judge"和"pass@k"两个模式,这两类场景覆盖了 80% 的 Agent 评估需求。README.md 作为索引,遇到具体问题再深入对应章节。