https://kkbill.github.io/tags/evaluation/ Recent content in Evaluation on kkBill's Blog Hugo en Sun, 31 May 2026 21:15:58 +0800 https://kkbill.github.io/posts/harness-engineering-07-evaluation/ Sat, 30 May 2026 21:00:00 +0800 https://kkbill.github.io/posts/harness-engineering-07-evaluation/ <p><img alt="image.png" loading="lazy" src="https://kkbill.github.io/posts/harness-engineering-07-evaluation/images/image00.png"></p> <h2 id="1-harness-evaluation-as-a-task-to-feedback-lifecycle">1. Harness Evaluation as a Task-to-Feedback Lifecycle</h2> <p>首先，我们需要打破传统评估的固有认知，即<strong>评估分数应当被视为“Model-Harness 对”的属性</strong>，而不仅仅是模型本身的能力体现。这对应于本文贯穿始终的“绑定约束理论”，即任务执行的可靠性很大程度上取决于模型之外的 Harness 基础设施（Agent = Model + Harness）。因此，这要求在评估协议中，要么保持 Harness 不变，对比模型；要么保持模型不变，将不同的 Harness 配置作为显式的实验因子进行测试。</p> <p>此外，Harness 评估与传统 LLM 评估也存在根本差异。<strong>传统 LLM 评估</strong>通常针对固定的输入，对输出进行评分（如 <a href="https://arxiv.org/abs/2009.03300">MMLU</a>）；<strong>Harness 评估</strong>衡量的则是一个执行集(Execution Episode，即 Agent 与环境交互的一个完整周期)——任务被锚定于某个环境中，智能体在其中与工具、状态进行多轮交互，评估者需要判断<strong>最终结果</strong>以及<strong>达成结果的路径（轨迹）</strong>。</p> <p>为此，作者提出了一个核心概念，<strong>将 Harness 评估视为一个“从任务到反馈的生命周期(Task-to-Feedback Lifecycle)”</strong>。下图展示了 task-to-feedback lifecycle 的五个阶段。</p> <p><img alt="image.png" loading="lazy" src="https://kkbill.github.io/posts/harness-engineering-07-evaluation/images/image01.png"></p> <p>作者引入生命周期视角的一个重要动机在于，评估基础设施的噪声可能被误当作模型的失败。 在复杂的智能体运行中，失败的原因可能多种多样，如工具损坏、上下文过时、沙箱未重置、测试用例不稳定或评估器本身出现偏差。 因此，评估不能仅仅给出一个最终分数，而必须将 Agent 行为转化为<strong>结构化的判断、失败归因和回归反馈</strong>。</p> <p>task-to-feedback lifecycle 的五个阶段涵盖了从任务定义到系统改进的全过程，具体包括：</p> <ul> <li><strong>阶段 1：任务与基准锚定 (Task and Benchmark Grounding)</strong> <ul> <li>核心问题：评估什么？</li> <li>内容：定义环境状态、可用工具、允许的操作、约束条件和成功准则。</li> </ul> </li> <li><strong>阶段 2：执行前就绪验证 (Pre-execution Readiness Validation)</strong> <ul> <li>核心问题：环境设置准备好了吗？</li> <li>内容：在运行前检查沙箱、依赖项、工具、权限策略和预算是否正确初始化，确保环境的公平性和可重复性。</li> </ul> </li> <li><strong>阶段 3：受控执行与轨迹捕获 (Controlled Execution and Trace Capture)</strong> <ul> <li>核心问题：发生了什么？</li> <li>内容：在可重复的条件下运行智能体，记录模型输出、工具调用、状态变化、错误、成本和延迟，将运行过程转化为可诊断的证据。</li> </ul> </li> <li><strong>阶段 4：多级判断与失败归因 (Multi-level Judgement and Failure Attribution)</strong> <ul> <li>核心问题：为什么成功或失败？</li> <li>内容：不仅看结果是否正确（Outcome），还看路径是否合规高效（Trajectory），并将失败具体归因到模型、工具接口或上下文管理等具体的 Harness 组件上。</li> </ul> </li> <li><strong>阶段 5：持续回归与部署反馈 (Continuous Regression and Deployment Feedback)</strong> <ul> <li>核心问题：如何改进？</li> <li>内容：将评估诊断结果转化为回归测试和工程反馈，驱动下一轮的 Harness 迭代和优化。</li> </ul> </li> </ul> <h2 id="2-stage-1---task-and-benchmark-grounding">2. Stage 1 - Task and Benchmark Grounding</h2> <p>阶段 1 的核心任务是回答“<strong>到底在评估什么</strong>”这一基本问题。在 Harness Engineering 语境下，一个任务不仅仅是一段提示词，而必须包含以下要素：</p>