Agent评测的反直觉感悟：质量优化与可规模化性的取舍¶

📊 Level ⭐⭐⭐ | 8.0KB

摘要¶

基于 Langfuse 实战经验，揭示 Agent 评测中的核心反直觉现象：质量优化可能破坏产品可规模化性。Tracing 的价值不在调试，而在让成本-质量取舍成为产品评审中可讨论的线索。

核心要点¶

Bad Case 归因的陷阱¶

从用户 bad case 入手做评测归因是常见做法，但 bad case 有四个棘手特征：

• 极端边界：不代表典型用户场景
• 模型幻觉：随机性强，难以系统性修复
• 技术修复 ROI 高：修复单个 bad case 可能引入更大成本
• 偶发性：难以稳定复现，修复效果难以验证

更关键的是：修好 bad case 后，token 成本可能反而上升。

反直觉核心：质量优化破坏可规模化性¶

一个 Agent 如果每次做 8 次检索、3 次 rerank、5 次模型调用，demo 会显得很聪明，但线上变成不可承受的成本结构。这不是假设，而是 Langfuse Tracing 能直接暴露的现实。

具体表现： - 更多上下文塞进 prompt → 短期提升准确率，但 token 成本和 latency 上升 - 引入更强 judge / 更多 self-check → 体验等待变长 - 增加检索和 rerank 次数 → 答案更稳，但每个请求的成本翻倍

这一洞察与 Llm Observability 4 Layer Model 中的成本监控层直接相关。

Tracing 的真正价值¶

Trace 的价值不是"总成本高"或"整体慢"这类笼统结论，而是：

• 哪一个 Observation 让成本失控 — 精确定位成本热点
• 哪一步阻塞了用户等待 — 精确定位延迟瓶颈

Tracing 让成本-质量取舍不再停留在架构师脑中，而变成产品评审中可讨论的线索。这是将技术决策透明化的产品化实践。

深度分析¶

「正确性评测」与「可规模化性评测」的分工¶

离线评测回答的是「答对没有」，它把系统当作一个函数：给定输入，输出是否正确。但生产环境里真正决定一个产品能否活下去的问题是另一个——「答对的代价是什么」。这两者不是同一把尺子。一个 Agent 完全可以在离线 golden set 上把准确率从 62% 推到 71%，同时把单次请求的 token 成本抬高一倍、把 P95 延迟推过用户的耐心阈值；在评测报告里这是一个胜利，在线上这是一次倒退。

因此评测需要拆成两条并行的轨道：正确性评测守住质量下限（回归、拒答、事实性），可规模化性评测守住成本与延迟的天花板。两者共享同一批真实流量，但产出的是不同形态的结论——前者回答「能不能上」，后者回答「上得起多少量」。两条轨道不是两份互不相干的报告，而是同一批 trace 的两组视图：同一次请求既贡献正确性样本，也贡献成本样本。把它们放进同一条流水线，才能回答真正的问题——这次改动买到的质量增量，是不是用可接受的代价换来的。

Bad Case 归因的陷阱：四类特征为何使归因失效¶

从用户 bad case 入手做评测归因，是最自然也最危险的做法。危险不在于 bad case 不重要，而在于它作为一类统计对象几乎没有可归因性：

• 极端边界：它落在分布尾部，修好它并不改善典型用户的体验中位数
• 模型幻觉：成因带有随机性，同一修复手段在下一个 case 上不一定复现
• 技术修复 ROI 高（表面高）：看起来是小改动，但改动会进入主链路，抬高全部请求的成本
• 偶发性：无法稳定复现，就没有可靠的「修复前 / 修复后」对照

四类特征叠加后得出一个反直觉结论：bad case 驱动的迭代会让系统在质量曲线上小幅前进，同时在成本曲线上大幅后退。这也解释了「修好 bad case 后 token 成本反而上升」的机制——修复通常以「给模型更多信息、更多推理、更多检查」的方式实现，而这些动作都按请求计价。归因失效的本质，是拿尾部样本去驱动一个作用于全体请求的改动。

Observation 级 vs Task 级的成本归因¶

Task 级的成本数字是给管理层看的，Observation 级的成本数字才是给工程用的。说「这个 Agent 平均每次 4 万 token」不产生任何动作；说「一个 8 次检索、3 次 rerank、5 次模型调用的编排里，第三次 rerank 吃掉了 41% 的成本，且只在 6% 的请求中被触发」才产生动作——可能的处置是砍掉它、把它降级为条件触发、或者缓存它的结果。

这正是 demo 与线上的分水岭。8×3×5 的编排在演示里表现为「聪明」，因为它把每一步的最优解叠加在了一起；在线上它是一个不可承受的成本结构，因为成本随编排长度近似线性增长，而质量增益通常是次线性的。Observation 级归因把这个结构性问题从「感觉上有点贵」变成「第几步、值不值、能不能只对有需要的请求开启」。参见 推理预算与成本曲线。

把 Trace 变成产品评审物料：组织含义与预算门禁¶

Tracing 的真正价值不是调试，而是让成本-质量取舍离开架构师的个人判断，沉淀为产品评审中可讨论的物料。这带来三个组织层面的变化。

其一，成本从「运维指标」变成「产品指标」。产品经理需要像看留存一样看每个功能的单请求成本，因为成本直接决定该功能能被开放给多少用户。其二，取舍必须在有数据的前提下被显式做出：是保留更强的 judge 换取更长的等待，还是牺牲一点准确率换三倍容量。没有 trace，这个取舍只能靠直觉；有了 trace，它可以被写进评审纪要并被追认。其三，与线上 SLO 和预算门禁直接挂钩——observation 级的成本一旦被稳定观测，就可以被写成门禁：单请求 token 上限、单位时间预算、某条编排的触发条件。质量优化于是从「越强越好」变成「在预算内最优」。

这一逻辑与 Langfuse 评测与 trace 成本结构、Llm Observability 4 Layer Model 中的成本监控层是同一条线索的两端：观测能力决定了取舍能被讨论到什么颗粒度。评测的终点不是更高的分数，而是一条能被讨论、能被定价、能被门禁化的成本-质量曲线。

实践启示¶

1. 评测时同时关注正确性和成本：每个 bad case 修复后，追踪 token 成本变化
2. 用 Observation 级别而非 Task 级别分析成本：定位具体哪一步消耗过多
3. 在产品评审中引入 Tracing 数据：让非技术人员也能理解成本-质量取舍
4. 警惕"demo 聪明，线上昂贵"的陷阱：8 次检索 + 3 次 rerank + 5 次模型调用可能是过度优化

关联¶

• 相关概念: Harness Engineering
• 相关: Agent 架构