klein-code-bench / docs /EVALUATION.md
Banaxi-Tech's picture
Release Klein-Code-Bench v0.1.0: 260 validated project-generation tasks
072246b verified
|
Raw History Blame Contribute Delete
4.91 kB

Evaluation protocol v1.0

  1. Pin the dataset revision and evaluator version. Select a subset or all 260 tasks before generation.
  2. Give the agent only prompt (including its examples) and an empty project directory. Keep acceptance tests, the benchmark package and references outside its context and workspace. Use a consistent token, time and tool budget across the reported comparison.
  3. Generate one project per task. Save the complete project, model name/version, parameter count, quantization, chat template, context size, sampling settings, seed, tool access, agent version, token use, wall time and host specifications. Record interventions and retries; a manually corrected project is not a first-attempt result.
  4. Evaluate with the dataset's static acceptance scenarios. Do not tune submissions after seeing test failures when reporting resolve@1. A timeout, crash, protocol violation, absent entrypoint or any wrong response fails the task.
  5. Report tier totals, resolved counts, the complete denominator, dataset commit, evaluator version and any excluded tasks. Use klein-bench score to aggregate unique report files. Do not compare partial runs as complete benchmark scores.

Candidate execution

The candidate is invoked with the evaluator's Python executable using -E -s -S (ignore Python environment variables and disable site-package loading). It retains its own project directory on the import path for supporting modules. Working directory is a fresh copy per scenario. A max-tier process also receives an absolute --state-dir path. No shell is involved in candidate launch. UTF-8 JSON is exchanged one line at a time; each response must be flushed. Normal tiers must exit with code zero on EOF. Max-tier sessions are killed after their final response and are not given graceful shutdown time.

A session is limited to 10 seconds total wall time, including startup, all its requests and normal EOF handling. The runner caps stdout at 1 MiB and retains at most 8 KiB of stderr diagnostics. A submission is limited to 2,000 files and 20 MB of source/data. .git, virtual environments, node_modules, caches and credential files are not copied. Symlink files and special files are rejected; symlink directories are not traversed. Process-group cleanup also applies after normal termination to remove surviving same-group children. These limits are evaluator limits, not security isolation or protection from all memory/disk exhaustion.

Each request has one expected response. Malformed input lines are literal strings in the scenario request list; regular requests are JSON objects. Each scenario has name and sessions; each session has equally sized nonempty requests and expected lists. Acceptance tests live only in the parent evaluator. A source hash identifies the copied submission; the dataset SHA-256 manifest identifies test data.

Contract coverage

  • All tiers: valid cases, Unicode, deterministic domain generation, each missing required field, malformed JSON, malformed envelopes, unknown commands, post-error recovery and tier-specific unavailable operations.
  • Intermediate+: revision increments, deep values/null, repeated replacement, evaluation without mutation, deletion failures, prefix matching and sorted listing.
  • Hard+: compare-and-swap conflicts and type checks, atomic batch success/failure, nested forbidden operations, maximum batch size, transaction nesting limits, missing transactions, revision/history restoration and nested commit followed by outer rollback.
  • Max: force-kill restart of writes/deletes and outer commits, discarded open transactions and nested commits, key pagination, history cursor/limits, replayed requests after restart, cached revision-conditional retries, token conflicts and tokens forgotten after failure/rollback.

The protocol in every task prompt is the normative interface. All layers are cumulative. A tier's task differs from another tier of the same family through required project behavior rather than an artificial increase in numerical input bounds.

Interpretation

Targets 2–8B, 8–16B, 16–32B and 60–200B are unvalidated. Shared service functionality may make implementation reuse easier than a collection of independent projects. Reset agent memory and workspaces between tasks; disclose whether the same agent has already seen other tasks or tiers. Score differences can reflect Python familiarity, tool quality, quantization and generation budgets as well as parameter count.

The public source contains fixed evaluation cases and oracles. An unrestricted host agent can discover these files or fetch them from the internet. The benchmark does not claim to enforce test secrecy or prevent deliberate cheating. Controlled experiments must enforce their own access policy without exposing evaluator data to the agent. The default runner is for trusted local experiments.