Skip to content

Add pinned Kimi Vendor Verifier smoke / 添加固定版本的 Kimi Vendor Verifier 冒烟评估 - #2547

Open
adibarra wants to merge 29 commits into
mainfrom
feat/tool-use-eval-smoke
Open

Add pinned Kimi Vendor Verifier smoke / 添加固定版本的 Kimi Vendor Verifier 冒烟评估#2547
adibarra wants to merge 29 commits into
mainfrom
feat/tool-use-eval-smoke

Conversation

@adibarra

@adibarra adibarra commented Aug 10, 2026

Copy link
Copy Markdown
Collaborator

Summary

  • Run the unmodified upstream Kimi Vendor Verifier tests/tool_call_json_schema suite in non-streaming and streaming modes. The adapter pins upstream commit b9ed3a6665bdff2c943246f7d2903cd003d6ddd6.
  • Add opt-in eval-framework: kimi-vendor and eval-suite: kimi_tool_call_schema workflow inputs. Existing jobs keep lm-eval and GSM8K defaults.
  • Install verifier dependencies into an isolated runtime, bound the upstream pytest subprocess to 900 seconds, and clean only provider-scoped artifacts.
  • Project the native upstream report into inferencex-eval-v1 results, use exact-match as the primary score, enforce a 1.0 threshold, aggregate the suite identity, and preserve it during reusable-artifact validation.
  • Emit zero-score compatibility artifacts for setup, timeout, runtime, projection, and artifact-write failures so CI records deterministic failure data instead of losing the result. Pre-test failures report n_eff: 0; valid two-mode reports report n_eff: 2.
  • Forward matrix spec-decoding into agentic eval jobs so STP and MTP configurations launch their matching benchmark scripts.

Scope

  • Phase 1 is optional and single-node only. It does not enable tool-use evals by default.
  • perf-changelog.yaml, model configurations, images, and Kimi benchmark scripts are unchanged by this PR.
  • MiniMax and BFCL remain follow-up integrations. This PR keeps provider request and report handling local to the Kimi adapter rather than introducing a premature shared verifier protocol.

Validation

  • Focused regression suite, 128 passed.
  • Shell syntax, Python compilation, workflow YAML parsing, actionlint, and git diff --check passed.
  • All 26 hardcoded line-link targets in both AgentX procedure documents resolve within their files, and the English and Chinese target sets match.
  • A deterministic local OpenAI-compatible mock passed the unmodified upstream suite in both request modes, 2 passed.
  • Real B300 validation on commit 58858593f ran distinct STP and MTP Kimi K3 FP4 vLLM jobs. Both jobs, collection, and score validation succeeded. The aggregate contains two rows, spec_decoding: none and spec_decoding: mtp, each with em_strict: 1.0 and n_eff: 2.
  • GitHub assigned run 31438656725 a failed envelope even though its API lists only successful or skipped jobs and no failed or cancelled job. A narrow collector dependency experiment did not change the envelope and was reverted. The hardware evals and gates are green; the envelope anomaly remains an infrastructure issue.
  • Repeated read-only architecture reviews and the repository Claude review traced dispatch, dependency isolation, timeout and cleanup, result projection, thresholding, reuse identity, failure metadata, and STP/MTP selection. The review findings were addressed, including failure sample counts, result-format drift protection, shared path resolution, and stale bilingual line links.

中文说明

概要

  • 直接运行上游 Kimi Vendor Verifier 未修改的 tests/tool_call_json_schema 测试集,覆盖非流式和流式两种模式。适配器固定到上游提交 b9ed3a6665bdff2c943246f7d2903cd003d6ddd6
  • 新增可选工作流输入 eval-framework: kimi-vendoreval-suite: kimi_tool_call_schema。现有任务继续默认使用 lm-eval 和 GSM8K。
  • 将验证器依赖安装到隔离运行目录,把上游 pytest 子进程限制在 900 秒内,并且只清理对应供应商的产物。
  • 把上游原生报告转换为 inferencex-eval-v1 结果,以精确匹配率作为主评分,设置 1.0 阈值,在聚合及可复用产物校验中保留测试集标识。
  • 配置、超时、运行、结果转换及产物写入失败时生成零分兼容性产物,确保 CI 记录确定性的失败数据,而不是丢失结果。测试启动前失败时记录 n_eff: 0,有效的双模式报告记录 n_eff: 2
  • 将矩阵中的 spec-decoding 传给 Agentic 评估任务,确保 STP 和 MTP 配置启动对应的基准测试脚本。

范围

  • 第一阶段为可选的单节点评估,不会默认启用工具调用评估。
  • 本 PR 不改动 perf-changelog.yaml、模型配置、镜像或 Kimi 基准测试脚本。
  • MiniMax 和 BFCL 留待后续集成。本 PR 将供应商请求格式和报告解析保留在 Kimi 适配器内,避免过早引入通用验证器协议。

验证

  • 聚焦回归测试通过,共 128 passed
  • Shell 语法、Python 编译、工作流 YAML 解析、actionlintgit diff --check 均通过。
  • 两份 AgentX 流程文档中的 26 个硬编码行号链接均指向有效文件范围,英文和中文版本的目标集合完全一致。
  • 使用确定性的本地 OpenAI 兼容模拟端点运行上游原始测试集,两种请求模式均通过,共 2 passed
  • 在提交 58858593f 上完成真实 B300 验证,分别运行 STPMTP 的 Kimi K3 FP4 vLLM 任务。两个任务、结果收集和分数校验均成功。聚合结果包含 spec_decoding: nonespec_decoding: mtp 两行,两者均为 em_strict: 1.0n_eff: 2
  • 尽管 运行 31438656725 的 API 只列出成功或跳过的任务,没有失败或取消的任务,GitHub 仍将工作流整体标记为失败。一次收窄范围的收集器依赖调整未改变该结论,现已回退。硬件评估及评分门禁均为绿色,该工作流整体状态异常仍属于基础设施问题。
  • 多轮只读架构审查及仓库 Claude 审查覆盖了任务分发、依赖隔离、超时与清理、结果转换、阈值、复用标识、失败元数据及 STP/MTP 选择。审查发现的问题均已修正,包括失败样本数、结果格式漂移保护、共享路径解析及失效的双语行号链接。

中文:添加基于 Kimi Vendor Verifier 原生实现的工具调用评估
@github-actions

Copy link
Copy Markdown
Contributor

Thanks for the contribution! Please reach out to respective companies' CODEOWNER to fill in the latest PR_REVIEW_CHECKLIST.md before pinging core maintainer on Slack for review. In order for the signoff PR check bot to trigger, you must follow the PR_REVIEW_CHECKLIST.md template correctly, including the phrase As a PR reviewer and CODEOWNER, I have reviewed this and have.

For PR verification, add the full-sweep-fail-fast label (strongly recommended) to this PR — the benchmark sweep only runs on labeled PRs. Use full-sweep-enabled only if you need matrix jobs to keep running past a failure.

PR authors are responsible for ensuring that after merging, all GitHub Action jobs fully pass. A lot of the time, failures are just flakes and simply re-running the failed jobs will fix it. See GitHub's docs on re-running failed jobs


感谢你的贡献!请联系相应公司的 CODEOWNER 填写最新的 PR_REVIEW_CHECKLIST.md,然后再在 Slack 上联系核心维护者进行审阅。为了触发 signoff PR 检查机器人,你必须正确遵循 PR_REVIEW_CHECKLIST.md 模板,包括保留英文语句 As a PR reviewer and CODEOWNER, I have reviewed this and have

如需进行 PR 验证,请为此 PR 添加 full-sweep-fail-fast 标签(强烈推荐)— 基准测试 sweep 仅在带有标签的 PR 上运行。仅当需要矩阵任务在失败后继续运行时才使用 full-sweep-enabled

PR 作者有责任确保合并后所有 GitHub Action 任务完全通过。 很多时候失败只是偶发抖动(flake),重新运行失败的任务即可解决。参见 GitHub 关于重新运行失败任务的文档

中文:精简工具调用评估实现并接入工作流选择路径
中文:合并最新主分支以完成发布准备
中文:隔离 Kimi 验证器依赖并明确供应商适配边界,同时加入执行超时和通用结果格式标识。
中文:合并最新 main,确保发布前验证基于当前代码。
@adibarra adibarra changed the title Add stock Kimi tool-use smoke eval / 添加 Kimi 原生工具调用冒烟评估 Add pinned Kimi Vendor Verifier smoke / 添加固定版本的 Kimi Vendor Verifier 冒烟评估 Aug 10, 2026
中文:区分失败结果产物写入成功与写入失败,同时保留原始安装失败退出码。
中文:将 agentic 评估矩阵的投机解码模式传递给启动器,避免 MTP 配置静默回退到 STP。
中文:合并最新 main,准备发布。
中文:补全纯评估工作流的结果收集依赖,避免所有评估任务成功后工作流仍显示失败。
The collector dependency change did not affect GitHub’s workflow conclusion and added unrelated orchestration scope.

中文:恢复纯评估结果收集的原有范围。该依赖调整未改变 GitHub 工作流结论,且扩大了无关改动范围。
中文:合并最新 main,准备进入评审。
@adibarra
adibarra marked this pull request as ready for review August 10, 2026 22:47
@adibarra
adibarra requested a review from a team August 10, 2026 22:47
@claude

claude Bot commented Aug 10, 2026

Copy link
Copy Markdown
Contributor

Claude finished @adibarra's task in 6m 48s —— View job


PR Review

  • Gather context and read the full diff
  • Review workflow changes (benchmark-tmpl.yml, e2e-tests.yml)
  • Review benchmarks/benchmark_lib.sh verifier integration
  • Review utils/evals/kimi_vendor_eval.py adapter
  • Review collection/validation changes and tests
  • Post findings

LGTM - no blocking issues found

Verified end-to-end: the always-set EVAL_FRAMEWORK env default (lm-eval) matches the previous effective default so existing lm-eval/swebench dispatch is unchanged; artifacts flow from EVAL_RESULT_DIR through append_lm_eval_summary's *.json* move into the workspace, where the upload globs (results*.json, *_vendor_report.json) and provider-scoped cleanup cover them; the inferencex-eval-v1 projection is picked up by collect_eval_results.py and scored by validate_scores.py with val < min_score semantics, so the 1.0 threshold passes on a perfect run and every zero-score failure artifact fails deterministically; the eval_suite identity uses a legacy sentinel in eval_key, keeping pre-existing reusable artifacts internally consistent; and the spec-decoding forwarding matches the pattern already used by the sibling benchmark jobs (the matrix always defines it).

@claude claude Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Beyond the inline findings, I also checked the multi-node rejection path in _run_kimi_tool_call_schema_eval (benchmarks/benchmark_lib.sh): when IS_MULTINODE is true it returns early without writing a zero-score compatibility artifact, unlike the setup-failure paths. This is a real asymmetry but not a bug in this PR's scope — run_eval's scenario dispatch never routes multi-node jobs to kimi-vendor, so the path is unreachable in practice today.

Extended reasoning...

I reviewed the multi-node rejection branch in _run_kimi_tool_call_schema_eval because it looked structurally similar to the other early-return failure paths that do write a zero-score compatibility artifact via _write_kimi_vendor_integration_error. This one instead returns exit code 2 with only a stderr message and no artifact. Tracing the call graph, run_eval's framework dispatch is single-node only for the kimi-vendor case in this PR (Phase 1 is explicitly scoped to single-node), so there's currently no caller that reaches this branch with IS_MULTINODE=true. I'm noting it as examined-and-ruled-out rather than filing it, since it doesn't affect current CI behavior.

Comment thread utils/evals/kimi_vendor_eval.py
Comment thread benchmarks/benchmark_lib.sh
Comment thread utils/evals/kimi_vendor_eval.py
Comment thread benchmarks/benchmark_lib.sh
中文:修正验证器失败样本数、共享格式契约、路径复用及双语文档链接。
中文:保留结果收集器测试的现有格式,仅添加格式契约测试。
中文:在启动失败时保留验证器计划样本数,同时将有效样本数记录为零。
@adibarra
adibarra marked this pull request as draft August 10, 2026 23:27
中文:合并最新 main,并保留工具调用评估元数据。
中文:保留可配置的 eval 调度行为,并修正失败返回码、Bash 兼容性和 eval 文档。
中文:强化验证器评审路径。
@adibarra
adibarra marked this pull request as ready for review August 11, 2026 22:11
@claude

claude Bot commented Aug 11, 2026

Copy link
Copy Markdown
Contributor

Claude finished @adibarra's task in 6m 17s —— View job


Re-review (new changes since 2026-08-10T23:01Z review)

  • Identify commits since the last review — 6793c9e3f (preserve configurable eval dispatch behavior), 294e39d51 (harden verifier review paths), plus a merge from main
  • Review the new changes
  • Verify previously reported findings were addressed
  • Post re-review summary

Re-review: one 🟡 warning — the latest commit re-broke the bilingual doc line anchors that an earlier commit had fixed (inline comment on docs/eval-agentx-procedures.md:100). Commit 294e39d51 added the 13-line EVAL_SUITE guard inside run_eval (benchmarks/benchmark_lib.sh:1818-1829) without refreshing the docs, so the 8 anchors pointing past L1815 in both eval-agentx-procedures.md and eval-agentx-procedures_zh.md now land 13 lines early (e.g. "trace resolution" #L2008 lands mid-pip install instead of at resolve_trace_source(), now L2021). Exact corrected ranges are in the inline comment.

Everything else in the new commits checks out:

  • Previous review findings are all addressed: n_eff is now threaded through _compatibility_result(..., n_samples=...) (0 on pre-test failures, 2 only after a parsed two-mode report), with the matching n_eff is not None rendering fix in collect_eval_results.py so a real 0 displays; _eval_patches_dir now derives from INFERENCEX_REPO_ROOT; and test_kimi_vendor_result_format_matches_collector_contract pins the inferencex-eval-v1 producer/consumer literals together.
  • Report-projection hardening (utils/evals/kimi_vendor_eval.py:77-107) is sound: by_status keys are whitelisted to passed/failed, counts must be non-negative ints summing to total, and per-result statuses are whitelisted — any upstream format drift lands in the existing ValueError → zero-score compatibility path with n_eff: 0, covered by new tests.
  • EVAL_SUITE guard: the character whitelist and kimi-vendor-only restriction are correct for all current callers (workflow env defaults EVAL_SUITE to empty; every script calls run_eval exactly once). One latent trap worth knowing about, not a bug today: run_swebench_eval exports EVAL_SUITE (benchmark_lib.sh:1676), so a hypothetical second run_eval call in the same shell session after a swebench run would now be rejected by the new guard.
  • _env_is_true rewrite drops the bash-4 ${1,,} lowercase expansion for a portable bracket-class pattern, and the ${EVAL_ONLY:-false} guards fix unbound-variable failures under set -u.
  • multinode_agentic_evals added to the e2e-tests trusted-changelog flatten list matches a real family key emitted by the generator (confirmed in utils/matrix_logic/validation.py:924 and utils/process_changelog.py:180), with a regression test.

Not verified locally: the focused pytest suites and bash -n/py_compile checks were blocked by tool permission approval in this environment, so I relied on reading the diffs plus the PR's own CI; if you want me to execute tests in future runs, the action's --allowedTools needs to permit python3 -m pytest.


Comment thread docs/eval-agentx-procedures.md Outdated
5. `run_eval` and artifact staging run.

Relevant implementation: [context setup](../benchmarks/benchmark_lib.sh#L853-L888), [eval dispatch and failure policy](../benchmarks/benchmark_lib.sh#L1537-L1654), and [workflow inputs](../.github/workflows/benchmark-tmpl.yml#L162-L185).
Relevant implementation: [context setup](../benchmarks/benchmark_lib.sh#L1049-L1078), [eval dispatch and failure policy](../benchmarks/benchmark_lib.sh#L1789-L1908), and [workflow inputs](../.github/workflows/benchmark-tmpl.yml#L79-L97).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 WARNING: The latest commit (294e39d51) re-broke the bilingual line anchors this PR previously fixed. That commit inserted 13 lines into benchmarks/benchmark_lib.sh (the EVAL_SUITE guard at L1818–L1829, inside run_eval) without refreshing the docs, so every benchmark_lib.sh anchor pointing past L1815 in this file and docs/eval-agentx-procedures_zh.md is now 13 lines early.

Why it matters: The links land on the wrong code — e.g. "run_eval batching" (#L1824-L1885) now starts at the esac of the new EVAL_SUITE guard and cuts off before the deferred-failure tail, and "trace resolution" (#L2008-L2087) starts mid-pip install list instead of at resolve_trace_source() (now L2021). This also regresses a finding from the previous review that had been addressed, and AGENTS.md requires docs to track the implementation in both languages.

Fix: Shift these 8 anchors by +13 in both docs/eval-agentx-procedures.md and docs/eval-agentx-procedures_zh.md (same lines/values in each):

Doc line Current Correct
100 #L1789-L1908 #L1789-L1921
124 #L1824-L1885 #L1837-L1898
176 #L2089-L2113 #L2102-L2126
209 #L2251-L2253 #L2264-L2266
213 #L2008-L2087 #L2021-L2100
213 #L2089-L2255 #L2102-L2268
245 #L2305-L2345 #L2318-L2358
294 #L2221-L2245 #L2234-L2258

(Anchors at or before L1815 — #L1049-L1078, #L1080-L1162, #L1163-L1222 — are still correct.)

Fix this →

@claude claude Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM — the one new finding (EVAL_SUITE leaking across repeated run_eval calls in the same sourced shell) is a nit with a trivial workaround and no CI impact, since every workflow job runs run_eval once in a fresh process.

Extended reasoning...

This run's bug hunt surfaced a single nit: a plain (non-local) export EVAL_SUITE=... in run_swebench_eval/run_kimi_vendor_eval leaks into the calling shell, which can trip the new EVAL_SUITE guard in run_eval on a second call within the same sourced shell. This only affects interactive/manual multi-call workflows, not CI (each CI job runs run_eval once in a fresh process), and is easily worked around with unset EVAL_SUITE.

The rest of the diff is the same Kimi Vendor Verifier smoke-eval integration already covered by prior review passes on this PR (dispatch, dependency isolation, timeout/cleanup, result projection, thresholding, reuse identity, and STP/MTP forwarding), plus a ruled-out candidate issue (zero-score artifact handling for unsupported-suite/multinode failures) that was checked and is not a real bug. Given the change is CI/tooling scoped, opt-in behind new workflow inputs with unchanged defaults for existing jobs, and the only new finding is a low-severity nit, I don't think this warrants blocking approval.

Comment on lines 1674 to 1677
local out_dir="${EVAL_RESULT_DIR:-$(mktemp -d /tmp/eval_out-XXXXXX)}"
local task_name="${SWEBENCH_TASK_NAME:-swebench_lite}"
export EVAL_SUITE="${EVAL_SUITE:-$task_name}"
local gen_dir

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 run_swebench_eval() and run_kimi_vendor_eval() both do a plain (non-local) export EVAL_SUITE=..., which leaks into the calling shell after the function returns. Because run_eval() now rejects any set EVAL_SUITE for a non-kimi-vendor framework, a later run_eval --framework lm-eval (or a second --framework swebench) call in the same sourced shell fails immediately with "EVAL_SUITE is only supported with EVAL_FRAMEWORK=kimi-vendor" before dispatching, breaking the documented "source benchmark_lib.sh once, run_eval repeatedly" workflow. Fix by resetting/unsetting EVAL_SUITE at the top of run_eval, or scoping the export to the duration of the dispatched call.

Extended reasoning...

What the bug is. run_eval() in benchmarks/benchmark_lib.sh adds a new guard: if [ -n "${EVAL_SUITE:-}" ] && [ "$framework" != "kimi-vendor" ]; then ... return 2; fi. This is meant to stop a stray EVAL_SUITE override from silently being ignored by non-kimi frameworks. However, both run_swebench_eval() (export EVAL_SUITE="${EVAL_SUITE:-$task_name}") and run_kimi_vendor_eval() (export EVAL_SUITE="$eval_suite") use a plain, non-local export. Bash exports made this way persist in the current shell (or any shell that sourced benchmark_lib.sh) even after the function that set them returns.

How it manifests. In the documented interactive workflow — source benchmarks/benchmark_lib.sh once, then issue multiple run_eval calls in the same shell/process (see docs/eval-agentx-procedures.md and utils/evals/EVALS.md) — the first call to run_eval --framework swebench (or --framework kimi-vendor) leaves EVAL_SUITE set afterward (e.g. EVAL_SUITE=swebench_lite). Any subsequent run_eval call with a different (or even the same) non-kimi framework in that shell then hits the new guard and fails with rc=2 and "ERROR: EVAL_SUITE is only supported with EVAL_FRAMEWORK=kimi-vendor" — before ever dispatching to the underlying runner. Notably, this even blocks a second run_eval --framework swebench call in the same shell, and the error message is confusing since the user never set EVAL_SUITE themselves.

Step-by-step proof:

  1. source benchmarks/benchmark_lib.sh
  2. run_eval --framework swebench --port 8888 — this calls run_swebench_eval(), which executes export EVAL_SUITE="${EVAL_SUITE:-swebench_lite}". This export is not scoped to the function; it persists in the shell even if the swebench run itself later fails, because the export happens before any dataset/generation logic.
  3. Back at the shell prompt, EVAL_SUITE=swebench_lite is now exported globally.
  4. run_eval --framework lm-eval --port 8888 is issued next (e.g. to run a GSM8K smoke after a SWE-bench smoke). run_eval()'s guard sees EVAL_SUITE is non-empty and framework != kimi-vendor, prints the error, and returns 2 — run_lm_eval is never invoked.
  5. The same failure recurs for a second run_eval --framework swebench call in that shell, since the guard fires for any framework other than kimi-vendor once EVAL_SUITE is set.

Why nothing currently catches it. The guard and both leaking exports are new in this PR (the diff adds export EVAL_SUITE="${EVAL_SUITE:-$task_name}" inside run_swebench_eval, the new run_kimi_vendor_eval export, and the new guard in run_eval), so this is a PR-introduced interaction, not a pre-existing issue. utils/evals/test_run_eval_dispatch.py tests each run_eval/run_kimi_vendor_eval/run_swebench_eval invocation in an isolated subprocess (subprocess.run(["bash", "-c", ...])), so no test exercises two sequential run_eval calls sharing one shell/process, and the leak never surfaces in CI.

Impact and fix. In CI this is low-impact: every workflow job runs run_eval exactly once in a fresh process, so the score gate and sweep are unaffected. The impact is confined to interactive/manual usage that follows the documented "source once, call run_eval repeatedly" pattern, and is trivially worked around with unset EVAL_SUITE. The straightforward fix is to reset/unset EVAL_SUITE at the top of run_eval() before framework dispatch (or to scope the export in run_swebench_eval/run_kimi_vendor_eval to only the duration of the call, e.g. via a subshell or by passing the value directly to the dispatched function instead of exporting it into the caller's shell).

中文:限定评估套件状态的作用域,并修正双语 AgentX 文档中的源码行号链接。
中文:将发生不可纠正 NVLink 错误的 b300-017 节点排除在 Slurm 分配之外。
中文:让 B300 启动器将 SALLOC_EXCLUDE 传递给 salloc,避免调度到已知故障节点。
中文:启用多节点 Kimi 验证器
中文:强化 Kimi 评估运行时故障处理
中文:捕获 Kimi 工具调用响应诊断数据。
中文:采集确定性的 Kimi 工具调用诊断数据。
中文:启用 Kimi 结构化工具调用约束。
中文:格式化 Kimi 配方回归测试。
中文:重试 Kimi 验证器的临时下载失败。
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

1 participant