分类目录归档：AI评测
导读：这篇文章系统讲述如何从零设计一个"用 AI 测 AI"的 Agent 评测平台，覆盖五类用户角色、十大核心模块与"一个 Agent 一个 Project"的架构定位，并给出了从技术选型到 MVP 路径的完整落地参考。最有价值的设计是分层断言体系——L1 请求级（Tool 调用、参数、副作用）、L2 行为级（结构、业务规则）、L3 结果级语义判定，原则是"能不用 LLM 判的就不用 LLM"；同时强调 AI Judge 必须配人工校准闭环（与 Golden Set 人工标注的一致率 ≥85% 作为发布门禁）。适合要搭建
导读：这篇文章提出了一套 Agent 测试的 L0–L4 分层方案——从 L0 平台自检（先证明测量工具可信）、L1 单 Skill 冒烟、L2 单 Skill 批量放行门禁（L1 通过率 ≥80% 才允许用例入库）、L3 跨 Skill 全量回归对比 baseline，到 L4 稳定性回归筛掉 Flaky，核心理念是把"平台问题"和"Agent 质量问题"分开记账，让每次 FAIL 都能下钻到具体环节。文中还给了两个反复踩出来的实战经验：记忆按用户持久化（如 mem0）会导致二次跑"假 FAIL"，需用新会话/fresh_us
导读：本文基于线上全量 trace 对两个 Agent 技能做「运行时体检」，起因是一次空转 12 分 20 秒被强制中断的提问（模型逐人查 149 人、撞递归上限 350 步）。核心结论：模型升级并没有变慢（同源同日 A/B 下单次生成与首 token 反而更快），慢在编排与工具——一轮问答平均 14～16 次模型调用加 20～23 次工具调用，沙箱脚本约占工具耗时 76%，且平台「0% 错误率」只是流未断的假象，真实异常（递归越界）从 9/14 起明显上升。给出的方向是「Proxy 化下沉＋SKILL.md
导读：这篇文章给出用 Langfuse 对生产 LLM 应用做错误分析的六步闭环：事件归一化 → Skill 归因 → 根因分类矩阵 → 时间趋势对照发布 → 僵尸会话/重复请求去重 → P0/P1/P2 分级修复。几个关键量级值得记住：同一失败会在多个观测上重复呈现约 2.9 倍、单条僵尸会话可占 48 小时失败总量近一半、框架级缺陷（思考模式字段未回传）约占失败四成五。适合做 LLM 应用线上故障排查与可观测性建设的后端/SRE 工程师，方法可直接复制。
分类：AI评测 ｜ 标签：LLM、可
最近学习了一套 Agent 评测体系的完整框架，从思维导图整理成这篇笔记。它回答了一个很现实的问题：当 Agent 从 Demo 走向生产，我们拿什么保证它"既聪明又稳定"？
传统测试那一套在这里几乎失效——Agent 不是"输入 A 必然输出 B"的函数，而是一条概率性、多步、依赖上下文的执行轨迹。这篇笔记沿着"为什么要评 → 怎么可观测 → 离线怎么保 → 线上怎么兜"的主线，把这些年做质量保障的经验和这套体系对照着梳理一遍。
在 LLM 质量保障的日常里，最常被问到的问题之一是："这个模型到底行不行？"
但"行不行"从来不是一个数字能回答的。同样是"MMLU 78 分"，few-shot 设成几？prompt 模板用什么？是不是 chat 格式？温度多少？有没有踩到测试集污染？——任何一项没对齐，跨团队、跨模型、跨版本的数字都不可比。
lm-evaluation-harness 就是为消灭这种"不可比"而生的。它是 EleutherAI 维护的 LLM 评测框架，也是 HuggingFace Open LLM Leaderboard 背后的评测引擎。这篇文章是我把它真正用进质量体系的实战笔记，不堆概念，只讲怎么跑、
导读：这篇讲把对话质检从「上线后异步评测」前置成 Skill 发布/分享前的硬门禁——「上传成功 ≠ 可分享」。核心是一套 L1 路由/能力命中、L2 工具调用/业务执行、L3 语义判定的三层门禁，收敛为 passed = solved ∧ confidence（默认 ≥0.7）∧ not leaked ∧ not evidence_blocker，并用四态状态机把 error（没测成）和 degraded（证据不足）与 failed 分开处理，配合 eval overlay 独占挂载和稳定 seed 保证可复现。适合做 Agent 平台
导读：一篇用 4 条 trace 逐条证伪平台结论的方法复盘：某纯编排型 Agent 技能被打成健康度 41/100「不健康」，但拉明细后发现 P99 长尾（149.4s、最长 317.6s）来自跨业务定时任务混入采样的噪音，83.8%（150/179）的「中断」大多是业务写成功后收尾轮被平台切掉、并非用户流失。核心结论是分数失真源于采样口径污染 + 中断语义错位，真正可动的是把 read_file 从 4-5 次/trace 压到 ≤1、成功后立即终止这类纯编排优化，零业务改动。适合做 Agent 评测、健康度指标治理的工程师
导读：本文复盘一个 Agent 评测失败案例：用户只问"我接的订单在哪里看，给我链接"，Agent 却走了 109 步、调用 82 次工具（其中 44 次盲猜 API 路径），最终仍没查出订单数据，而正常路径只需 5～10 步、10～30 秒。归因得出五层系统性叠加的问题——技能路由失败致订单查询技能从未进入主路径、身份与技能可见范围配置错误（服务者身份下暴露的是员工端技能）、RAG 泛化替代（20 次知识库检索兜底）、会话旧记忆干扰（翻历史会话"考古"旧技能名）、无约束的暴力盲探（44 次猜 URL），
导读：这篇文章演示如何用 Langfuse 对生产 LLM 应用做耗时拆解：按端分层、全池随机抽样 80 条 trace，用"独占耗时"口径（父节点时长减去子节点）把 LLM、工具、Skill、框架规划各段分别量化。核心结论是大模型生成耗时占全链路 67.6%~95.9%，输入长度与耗时强正相关（r≈0.71）、多轮上下文累积让成本加速膨胀，超长尾多来自模型服务端抖动。适合做 LLM 应用性能优化与可观测性建设的工程师，采样与归因方法可复制到任何应用。
分类：AI评测 ｜ 标签：LLM、可观测性、Langfuse、性能分析
数据