KE（关键信息提取）评测方案

当前数据：v1 pilot，173 条；固定排除 3 条示例后评测 170 条。当前格式为 Plain-KE，主指标为逐题平均的 Key-Step F1。

2026-10-28 已离线核查现存 24 组结果：16 组记录核查通过，8 组含空返回，共 398 条。历史结果未改写；完整清单见项目 data/README.md 和 data/evaluation_audit.json。

§1 任务与范围

给定编程任务及多步 (thought, observation)，模型选出 observation 中包含解决任务关键信息的步骤。Thought 提供行动背景，gold 标签针对工具返回的信息。

原始轨迹导出时已剥离 tool_use 块，无法直接读取工具名称及调用参数；保留的是 assistant 文本（thought）和工具返回（observation）。因此，本评测判断工具返回中的信息是否关键，不评估工具调用本身是否正确。

当前成果包括题库、模型标注、评测代码、逐题结果和方案网站。它是一个 pilot；分数反映与现有标注的吻合程度，不能直接等同于完整编程任务成功率。

原始六份轨迹已于 2026-10-28 按用户要求删除，未另建备份。现有题库评测不依赖原始文件；重新从原文筛选和抽取需重新获取数据。

§2 数据管线

60,000 条轨迹诊断记录
→ 5,540 条候选
→ 243 条均衡采样
→ 192 条有效任务及加工轨迹
→ 整轨迹标注
→ 173 条 pilot
→ 排除 3 条固定示例
→ 170 条正式评测题

2.1 诊断与筛选

step02_diagnosis_all_chunks.jsonl 保留 60,000 条诊断记录；step02_gold_candidates.jsonl 保留 5,540 条筛选结果及源记录指针。两者不含完整原始轨迹，不能用来恢复已删除的原文。

2.2 多样性采样

按 observation 类型、任务长度、用户轮次构成 27 格，每格抽取 9 条，得到 243 条候选。各维度在这一步均为三组各 81 条。

分组规则与采样代码一致。任务长度使用诊断阶段任务文本的字符数（Python len），不是 token 数；候选筛选已要求至少两轮用户交互。后续有效性筛选会改变分布，173 条 pilot 不再严格均衡：

2.3 抽取与标注

历史记录使用 Claude Opus 4.7 抽取任务和最终产出，再对加工轨迹进行 gold/noise 标注。243 条抽取记录中，192 条 final_answer_found=true，有效比例为 79.0%。最终产出可能由模型根据轨迹整理或合成，不代表经过独立执行验证。

抽取阶段超长输入会保留首部和尾部，总上限为 40,000 字符。步骤提取默认保留每步 observation 2,000 字符、thought 800 字符；整轨迹标注再按 observation 1,500 字符、thought 500 字符读取。所谓“整轨迹”指同时判断所有加工步骤，不表示原始文本未经裁剪。

gold 的定义：该步 observation 是最终方案所用关键信息的来源，包括推动关键转向的反馈。纯写入确认、任务管理消息和重复信息不应仅因 thought 有价值而成为 gold。

下面四种情景用于说明标签规则：

若验证结果或报错推动了关键转向，应按其提供的信息判断，不能仅凭“验证”或“报错”这一类型排除。

2.4 打包与固定示例

当前打包参数为 min-gold=2、min-noise=3，并排除 file_write_confirmation 作为 gold。现存 192 条标注按这些参数转换，能够逐条重建出完全一致的 173 条 pilot。

192 条标注产物中，190 条 model_ok=true，2 条模型标注未成功；后者均未进入最终题库。整轨迹标注对选中的 gold 固定填写 model_confidence=5，这个字段不代表独立估计的置信度。

固定示例位于 step06_icl_examples_v1.jsonl。0-shot 和 3-shot 都排除同样的 3 条，正式评测集均为 170 条。缺失示例文件会报错，避免零示例评测悄悄扩大到 173 条。

§3 评测与现存结果

3.1 形式和指标

Plain-KE 要求模型输出关键步骤 ID 列表。Base completion 请求保留原有提示前缀 The critical steps are:\n- step_；TC-KE 和 MC-KE 仍可显式选择。

当前任务每步 observation 最多读取 800 字符、thought 400 字符；示例分别为 300、200 字符。评测输出上限保持 1,024 token；OpenAI 后端温度保持 0，Bedrock 保持原有网关默认。常用 shell 入口并发为 6，底层 Python 默认并发仍为 4。

主指标为逐题计算 F1 后等权平均。辅助指标为 Precision、Recall、F0.5 等；规则基线的 F0.5 已统一使用评分模块的逐题平均口径，主指标 F1 未改。

非空但答错或无法解析的回答仍参与评分，可得 0 分。服务请求失败、重试耗尽或空返回写入 failed.jsonl；含这些失败的运行标记为 incomplete，不发布可比较的 overall 分数。其余已完成结果保留供排查，不通过只平均成功子集来替代完整评测成绩。

3.2 评测模型

以下为历史模型配置记录，本轮未重新验证在线服务及部署上限。

3.3 可追溯的结果表

下表仅采用通过现存记录核查的运行。核查包括 170 题覆盖、空返回、gold 对齐和评分重算；历史配置记录不完整，因此通过核查不等于完成了严格控制实验或统计显著性验证。

DSV4-Flash 的两组结果分别列示，不合并、不只取较高值；完整推理配置未随历史结果保存，尚不能确认两次运行的差异来源。

同一 170 题上离线重算的规则基线：

以下运行保留原文件用于排查，暂不进入模型能力比较：

这些旧汇总均记录 n_succeeded=170、n_failed=0。旧代码将请求耗尽后的 None 转为空预测，再计入 0 分；离线模拟已复现该路径。文件可以证明空返回被计分，尚不能唯一确定历史服务失败的上游原因。

此前主表中的 HY3 32K 2T 40.7% 尚未找到匹配的现存运行，不再作为当前主表成绩。旧 PT 模型的 0 分及其原因也只保留为历史讨论，不并入本表已核查的有效比较。

3.4 当前能说明什么

现存数据能够支持复核题库、计算规则基线和逐题重算历史模型分数。部分模型在这些标注上的 F1 高于简单规则基线，但这不足以单独证明 benchmark 已全面有效。

Opus 同时参与构造标签和接受评测，存在同源偏置；其领先不能拆解为纯粹的 RL 收益。模型家族、架构、训练数据、参数量和部署条件同时变化，现有结果不能确定“激活参数主导能力”或“某个训练阶段导致提升”。

3-shot 在已列运行中得分略低，暂不将其归因于注意力稀释、上下文溢出或示例分布。不同模型几十分之一至几个百分点的差异，仍需结合逐题波动与一致的运行配置解释。file_read 基线的 36.70% 是当前题库上的统计结果，不是该领域不可突破的上限。

3.5 使用方式

在项目根目录执行以下离线命令：

python -B code/audit_results.py
bash code/run_v1_eval.sh baselines
python -B code/test_code_ke.py

外部环境使用独立入口 bash code/run_eval.sh --model MODEL --n-shots 0，通过 OPENAI_API_BASE、OPENAI_API_KEY 连接 OpenAI 兼容服务；Base 模型可加 --use-completion-api。安装依赖和导出方法见项目 PORTABLE.md，不需要 HY 统一评测框架。原有 170 题、固定示例、提示词和评分公式保持不变。

模型评测入口保留原名称：bash code/run_v1_eval.sh MODEL 0 或 3。先配置对应模型服务；Bedrock 凭证从 CODE_KE_APP_ID、CODE_KE_APP_KEY 读取，OpenAI 凭证从 OPENAI_API_KEY 读取。详见项目 README。本轮未新增模型评测或验证在线服务。

新运行名称附带时间和进程标识；显式指定已存在的运行目录会报错。all 模式中任一子任务失败或不完整，父脚本返回失败。新汇总记录数据指纹、模型参数、提示词与代码哈希，完整响应也随逐题结果保存。

3.6 保留范围与限制

保留现有 192 条加工轨迹和标注、173 条 pilot、固定示例、全部历史预测及汇总。异常结果通过独立核查清单标注，不改写为补零或删样后的新分数。

当前项目仍存在 pilot 规模、模型标注偏置及多阶段文本截断等设计限制。本次修复针对明确的实现与记录问题，未改变评分公式、提示词、生成预算或标签，也未追加模型消融实验。

数据 schema 已按现存题库更新：任务文本要求非空，取消与现存 274 步样本不符的 200 步上限；9 条少于 15 字符的多轮跟进任务原样保留。这是格式说明修正，没有重新筛题或改变历史分数。

以下保留历史单题示例，用于解释格式与评分；单题示例不能替代整次运行的有效性核查。

附录：样本格式与评测范例

样本示例

以 code_ke_834b34a9（difficulty=easy, 10 步 3 gold）为例，展示单条样本的完整字段：

{
  "sample_id": "code_ke_834b34a9",
  "difficulty": "easy",
  "user_task": "修改bash的custom.bashrc,注释掉里面conda相关的几行。然后参考/workspace/project 修复803错误",
  "trajectory_steps": [
    {
      "step_id": "step_000",
      "thought": "我来同时读取这两个文件。",
      "obs_type": "file_read",
      "observation": "1\t# 修复 CUDA Error 803（driver/toolkit 版本不匹配）\n2\t\n3\t## 问题现象\n4\t\n5\t```\n6\tRuntimeError: Unexpected error from cudaGetDeviceCount()...",
      "label": "gold"
    },
    {
      "step_id": "step_001",
      "thought": "(continued from previous tool call)",
      "obs_type": "other",
      "observation": "Command running in background with ID: b7qqpjb0i. Output is being written to: /tmp/claude-0/.../tasks/b7qqpjb0i.output",
      "label": "noise"
    },
    {
      "step_id": "step_002",
      "thought": "(continued from previous tool call)",
      "obs_type": "path_list",
      "observation": "<retrieval_status>timeout</retrieval_status>\n<task_id>b7qqpjb0i</task_id>\n<task_type>local_bash</task_type>\n<status>running</status>",
      "label": "noise"
    },
    {
      "step_id": "step_003",
      "thought": "(continued from previous tool call)",
      "obs_type": "path_list",
      "observation": "/root/custom.bashrc\n/root/cuda12.4.bashrc\n/root/.bashrc\n/root/.cshrc\n/root/.tcshrc",
      "label": "noise"
    },
    {
      "step_id": "step_004",
      "thought": "(continued from previous tool call)",
      "obs_type": "file_read",
      "observation": "1\t#!/bin/bash\n2\t\n3\texport LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/cuda-12.4/lib64:...:/usr/local/cuda-12.4/compat/:/usr/local/cuda/compat/\n...",
      "label": "gold"
    },
    {
      "step_id": "step_005",
      "thought": "(continued from previous tool call)",
      "obs_type": "file_read",
      "observation": "1\t#!/bin/bash\n...\n23\t# conda\n24\t. /data/miniconda3/etc/profile.d/conda.sh\n25\tconda deactivate\n26\tconda activate env-3.12\n...",
      "label": "gold"
    },
    {
      "step_id": "step_006",
      "thought": "两个文件都读取到了，现在同时进行两处修改：\n1. custom.bashrc：注释掉 conda 相关的 3 行\n2. cuda12.4.bashrc：按 README 修复 803 错误",
      "obs_type": "file_write_confirmation",
      "observation": "The file /root/custom.bashrc has been updated successfully.",
      "label": "noise"
    },
    {
      "step_id": "step_007",
      "thought": "(continued from previous tool call)",
      "obs_type": "file_write_confirmation",
      "observation": "The file /root/cuda12.4.bashrc has been updated successfully.",
      "label": "noise"
    },
    {
      "step_id": "step_008",
      "thought": "验证修改结果：",
      "obs_type": "file_read",
      "observation": "1\t#!/bin/bash\n... (读回刚写入的 custom.bashrc)",
      "label": "noise"
    },
    {
      "step_id": "step_009",
      "thought": "(continued from previous tool call)",
      "obs_type": "file_read",
      "observation": "1\t#!/bin/bash\n... (读回刚写入的 cuda12.4.bashrc)",
      "label": "noise"
    }
  ],
  "gold_step_ids": ["step_000", "step_004", "step_005"],
  "label_stats": { "n_gold": 3, "n_noise": 7, "n_uncertain": 0, "gold_ratio": 0.30 },
  "final_output": {
    "type": "file_writes",
    "summary": "已完成两处修改：1) 在 /root/custom.bashrc 中将 conda 相关的三行（. /data/miniconda3/etc/profile.d/conda.sh、conda deactivate、conda activate env-3.12，第24-26行）全部用 # 注释掉。2) 按 README 修复 /root/cuda12.4.bashrc 的 CUDA Error 803：用 grep -v 'compat' 主动从 LD_LIBRARY_PATH 中剔除 /usr/local/cuda-12.4/compat/ 和 /usr/local/cuda/compat/（旧版 libcuda.so.1 550.x 与实际 Driver 570.133.20 不匹配是 803 根因），并用 if [[ ... ]] 条件判断防止重复 source 时路径叠加。执行 source ~/.bashrc 即可生效。"
  }
}

评测 Prompt（Plain-KE 格式）

完整 full_prompt（{code_traj.xxx} 表示由 §样本示例 中的 sample 字段动态填入）：

You are an information triage module for a coding agent.

Given a coding task and the agent's trajectory steps (each containing a thought and an observation), identify which steps' Observations provide critical information for solving the task.

A step is critical (gold) when its Observation contains information directly used by the final solution — the first source of a key code snippet, file path, config value, function signature, or command output that the agent relied on. If the same information appears in multiple steps, only the first occurrence counts. A failed result that drove a pivotal direction change (pivot) also counts.

A step is NOT critical (noise) when its Observation is: a write confirmation ("File created"), empty output, an error that did not drive a pivot, a verification re-read of already-known content, directory listings not used, task management events (e.g. "Task #N created"), PID/metadata, or repeated information already seen in an earlier step.

Important: Thought is the agent's own reasoning process and does NOT count as external information — even if the Thought contains valuable analysis or conclusions, as long as the Observation itself has no useful information (e.g. merely "File created" or empty output), the step is NOT critical.

Output only the list of critical step IDs, e.g.: step_003, step_007, step_012.

Task: {code_traj.user_task}

Trajectory Steps:

[{code_traj.trajectory_steps[0].step_id}]
  Thought: {code_traj.trajectory_steps[0].thought}
  Observation Type: {code_traj.trajectory_steps[0].obs_type}
  Observation: {code_traj.trajectory_steps[0].observation}

[{code_traj.trajectory_steps[1].step_id}]
  Thought: {code_traj.trajectory_steps[1].thought}
  Observation Type: {code_traj.trajectory_steps[1].obs_type}
  Observation: {code_traj.trajectory_steps[1].observation}

... (共 {len(code_traj.trajectory_steps)} 步，字段依 §样本示例 逐条填入)

Now identify which steps provided critical information:

The critical steps are:
- step_

Completion 调用参数：

各模型输出与打分（真实评测结果）

opus-4.7（RL） — 精准命中（TP=3, FP=0, FN=0 → P=100%, R=100%, F1=100% ✅）：

step_000, step_004, step_005

hy3-mt-256k-360B（Midtrain 256K） — 高 recall 低 precision，把两步验证性读取和一步路径清单误当作 gold（TP=3, FP=3, FN=0 → P=50%, R=100%, F1=66.7%）：

The critical steps are:
- step_000: README.md content — contains the root cause analysis and the exact fix code for CUDA Error 803
- step_003: path_list — confirmed the existence of both target files
- step_004: cuda12.4.bashrc content — the original broken file that needed to be fixed
- step_005: custom.bashrc content — the original file with conda lines to be commented out
- step_008: verification read of custom.bashrc — confirmed the conda lines were successfully commented out
- step_009: verification read of cuda12.4.bashrc — confirmed the fix was applied correctly