feat: add CVRP benchmark (VehicleRouting/CVRP) - #102
Conversation
Add a capacitated VRP benchmark task to the VehicleRouting suite: - 12 deterministic TSPLIB-style instances (seed 42), stdlib-only runtime - Near-optimal deterministic reference (GRASP multi-start + 2-opt + relocate/swap + 2-opt* + LNS) - Weak canonical baseline (random-order cheapest insertion, 55.59 vs reference 100) - Unified-task metadata and Dockerfile for containerized evaluation - Measured agent scores (deepseek-v4-flash): openevolve 96.38, ShinkaEvolve 99.31, AB-MCTS 98.70
Suite-level README describing the Vehicle Routing domain and linking to the CVRP task (consistent with sibling suites such as GameAI, Astrodynamics, MarketMaking).
🤖 AI Code Review (gemini-3-flash-preview)🇬🇧 English Analysis1. Executive Summary
2. AI Content Analysis
3. Engineering & Economic Assessment
4. Quality Assurance
5. Security & Privacy Check
🇨🇳 中文分析1. 摘要
2. AI 成分分析
3. 工程与经济评估
4. 质量保证
5. 安全与隐私检查
|
PR #102 Review CommentThank you for submitting this CVRP benchmark PR. The task documentation, baseline, reference solver, unified metadata, and Dockerfile are all well organized, and I verified locally that the baseline reproduces at However, the current implementation has several issues that affect the credibility of the evaluation, so I do not recommend merging it yet. Main issues:
Please complete the following changes before continuing the review:
Thank you again for your contribution. After completing the above modifications, the review can continue. |
…ors, run records, docker isolation, tests
Reviewer-driven hardening of the CVRP benchmark:
- Copy only candidate-needed files into the eval sandbox (no verification/, no data/reference.json)
- Add 12 held-out instances (data/instances_heldout) and score them; reference.json covers all 24
- Remove reference distances from evaluator artifacts (only instance count remains)
- Add verification/validator.py: EVOLVE-BLOCK integrity, forbidden reference/import checks, per-instance hardcoding detection, absolute-path ban, determinism probe
- Add baseline/result_log.txt, verification/multiseed_stat.py (fresh instance sets per seed), and document agent run records in README/Task
- Integrate docker isolation: minimal image mounts the sandbox; README documents task.runtime.isolation_mode=docker
- Add unit tests (verification/test_{evaluator,validator,ref_solver}.py)
🤖 AI Code Review (gemini-3-flash-preview)🇬🇧 English Analysis1. Executive Summary
2. AI Content Analysis
3. Engineering & Economic Assessment
4. Quality Assurance
5. Security & Privacy Check
🇨🇳 中文分析1. 摘要
2. AI 成分分析
3. 工程与经济评估
4. 质量保证
5. 安全与隐私检查
|
A candidate that memorizes the fixed public instance set (24 instances) can still score near 100 without learning a general solver. Setting CVRP_EVAL_GENERATE_SEED (and optional CVRP_EVAL_GENERATE_COUNT, default 6) now makes the evaluator generate fresh instances at evaluation time and score them against references computed on the fly by the reference solver (GRASP + LNS, fixed seeds). Same seed => same instances => reproducible; unset => previous behaviour unchanged. - verification/evaluator.py and frontier_eval/evaluator.py support the feature; the sandbox copy loads the host generator/reference solver via FRONTIER_EVAL_UNIFIED_SOURCE_BENCHMARK_DIR (verification/ is never copied) - CVRP_EVAL_GENERATE_SEED/COUNT are stripped from the candidate env - 4 new unit tests (42 total pass); README (EN/ZH) documents the feature and the docker-mode env-forwarding limitation
…-generation additions)
🤖 AI Code Review (gemini-3-flash-preview)🇬🇧 English Analysis1. Executive Summary
2. AI Content Analysis
3. Engineering & Economic Assessment
4. Quality Assurance
5. Security & Privacy Check
🇨🇳 中文分析1. 摘要
2. AI 成分分析
3. 工程与经济评估
4. 质量保证
5. 安全与隐私检查
|
🤖 AI Code Review (gemini-3-flash-preview)🇬🇧 English Analysis1. Executive Summary
2. AI Content Analysis
3. Engineering & Economic Assessment
4. Quality Assurance
5. Security & Privacy Check
🇨🇳 中文分析1. 摘要
2. AI 成分分析
3. 工程与经济评估
4. 质量保证
5. 安全与隐私检查
|
…imitation wording
🤖 AI Code Review (gemini-3-flash-preview)🇬🇧 English Analysis1. Executive Summary
2. AI Content Analysis
3. Engineering & Economic Assessment
4. Quality Assurance
5. Security & Privacy Check
🇨🇳 中文分析1. 摘要
2. AI 成分分析
3. 工程与经济评估
4. 质量保证
5. 安全与隐私检查
|
…nges
The unified runtime (HEAD) does not forward env vars into the docker
container, so the sandbox evaluator could not locate the host benchmark dir
to read reference.json → every instance scored "no reference distance".
Inject the host-benchmark path directly into the eval command via the
{repo_root} placeholder (the same placeholder other benchmarks use), so
docker isolation works on Linux/WSL without touching the shared framework.
The candidate env is still stripped of FRONTIER_EVAL_UNIFIED_*.
- frontier_eval/eval_command.txt: prefix with
FRONTIER_EVAL_UNIFIED_SOURCE_BENCHMARK_DIR={repo_root}/benchmarks/VehicleRouting/CVRP
- README / README_zh-CN: document docker mode (Linux/WSL validated,
task.runtime.docker_user for sandbox write access, Windows host blocked by
a framework path bug; runtime-generated instances remain process-mode only)
🤖 AI Code Review (gemini-3-flash-preview)🇬🇧 English Analysis1. Executive Summary
2. AI Content Analysis
3. Engineering & Economic Assessment
4. Quality Assurance
5. Security & Privacy Check
🇨🇳 中文分析1. 摘要
2. AI 成分分析
3. 工程与经济评估
4. Quality Assurance
5. 安全与隐私检查
|
…t hidden) The README claimed held-out instances are "never exposed to the agent (absent from agent_files.txt and Task.md)", but Task.md is in agent_files.txt and names the VHO-* instances, and data/instances_heldout/ is copied into the sandbox. Rewrite the bullets to describe the actual protections honestly: double-sized evaluation set + static rejection of name-keyed hardcoding + runtime-generated instances (CVRP_EVAL_GENERATE_SEED), and a threat model that acknowledges the files are visible.
🤖 AI Code Review (gemini-3-flash-preview)🇬🇧 English Analysis1. Executive Summary
2. AI Content Analysis
3. Engineering & Economic Assessment
4. Quality Assurance
5. Security & Privacy Check
🇨🇳 中文分析1. 摘要
2. AI 成分分析
3. 工程与经济评估
4. 质量保证
5. 安全与隐私检查
|
Each framework now has 3 runs on the 24-instance set (deepseek-v4-flash): - openevolve: 98.00/97.96/97.47 -> mean 97.81 ± 0.24 - ShinkaEvolve: 98.13/54.69*/98.65 -> mean 83.82 ± 20.60 (* one run produced invalid programs in every generation; best stayed at the baseline 54.69 — a genuine failure mode, documented) - AB-MCTS: 98.49/96.78/99.26 -> mean 98.18 ± 1.04 Updated the reference-scores bests (ShinkaEvolve 98.65, AB-MCTS 99.26) and added all run IDs to the Experiments table.
🤖 AI Code Review (gemini-3-flash-preview)🇬🇧 English Analysis1. Executive Summary
2. AI Content Analysis
3. Engineering & Economic Assessment
4. Quality Assurance
5. Security & Privacy Check
🇨🇳 中文分析1. 摘要
2. AI 成分分析
3. 工程与经济评估
4. 质量保证
5. 安全与隐私检查
|
- Task.md (agent-facing) claimed held-out instances are "never shown to the agent (absent from agent_files and this document)" — but Task.md is in agent_files.txt and names the VHO-* instances itself, and their files are copied into the sandbox. Rewrite to describe the actual protections (double-sized set + static hardcoding rejection + runtime generation). - README file-tree comments said "shown to no agent" — corrected. - Task.md/Task_zh-CN.md reference-scores tables still had the pre-multi-run bests (ShinkaEvolve 98.13, AB-MCTS 98.49); updated to 98.65 / 99.26 to match the README and the measured run records.
🤖 AI Code Review (gemini-3-flash-preview)🇬🇧 English Analysis1. Executive Summary
2. AI Content Analysis
3. Engineering & Economic Assessment
4. Quality Assurance
5. Security & Privacy Check
🇨🇳 中文分析1. 摘要
2. AI 成分分析
3. 工程与经济评估
4. 质量保证
5. 安全与隐私检查
|
The reviewer's "hidden/held-out instances" intent was not fully met: the held-out .vrp files were copied into the sandbox, so a candidate could read them during evolution and hardcode routes for them. Now: - copy_files.txt no longer copies data/instances_heldout/ - both evaluators read held-out instances from the host source dir (FRONTIER_EVAL_UNIFIED_SOURCE_BENCHMARK_DIR) and pass each path to the candidate only at scoring time, so a candidate cannot read them during evolution (direct mode still reads the local dir) - new unit test for host-source held-out reading (43 tests pass) - README/Task (EN/ZH) describe the held-out visibility accurately Runtime-generated instances (CVRP_EVAL_GENERATE_SEED) remain a second, stronger anti-memorization layer.
🤖 AI Code Review (gemini-3-flash-preview)🇬🇧 English Analysis1. Executive Summary
2. AI Content Analysis
3. Engineering & Economic Assessment
4. Quality Assurance
5. Security & Privacy Check
🇨🇳 中文分析1. 摘要
2. AI 成分分析
3. 工程与经济评估
4. 质量保证
5. 安全与隐私检查
|
Reviewer follow-ups (Einsia#2, Einsia#5): - eval_command.txt now injects the host-benchmark path via the framework's {benchmark_source} placeholder instead of a hardcoded {repo_root}/benchmarks/... segment (robust to repo moves; renders to the container path in docker mode, host path in process mode — verified both). - New verification/test_frontier_eval_evaluator.py exercises the sandbox copy of the evaluator (frontier_eval/evaluator.py): baseline scoring, host-source held-out reading, runtime generation, preflight rejection of a cheating candidate, and a parse-instance consistency check vs the verification copy. This surfaced a real drift: the sandbox load_reference had no local fallback (direct runs got no reference distances); it now mirrors the verification copy (host source -> CVRP_EVAL_REFERENCE_JSON -> local reference.json). 49 unit tests pass.
🤖 AI Code Review (gemini-3-flash-preview)🇬🇧 English Analysis1. Executive Summary
2. AI Content Analysis
3. Engineering & Economic Assessment
4. Quality Assurance
5. Security & Privacy Check
🇨🇳 中文分析1. 摘要
2. AI 成分分析
3. 工程与经济评估
4. 质量保证
5. 安全与隐私检查
|
…ity) The unified runtime sets FRONTIER_ENGINEERING_ROOT (host repo root) for every eval, and candidate_env only stripped FRONTIER_EVAL_UNIFIED_* — so a candidate could read the repo root, find verification/ref_solver.py on the host, import it via string concatenation (bypassing the static token checks), and call grasp_solve directly. Reproduced end-to-end: the cheat candidate scored 100.00 / valid 1.0 on the 24-instance set. Fix: candidate_env (both the verification copy in validator.py and the sandbox copy in frontier_eval/evaluator.py) now strips ALL FRONTIER_* variables, not just FRONTIER_EVAL_UNIFIED_*. Re-running the cheat candidate scores 0. New unit test locks the strip list; 50 unit tests pass. README threat model updated. Process and docker (WSL) eval paths re-verified (54.69/24).
🤖 AI Code Review (gemini-3-flash-preview)🇬🇧 English Analysis1. Executive Summary
2. AI Content Analysis
3. Engineering & Economic Assessment
4. Quality Assurance
5. Security & Privacy Check
🇨🇳 中文分析1. 摘要
2. AI 成分分析
3. 工程与经济评估
4. 质量保证
5. 安全与隐私检查
|
… ref / 6 sandbox)
🤖 AI Code Review (gemini-3-flash-preview)🇬🇧 English Analysis1. Executive Summary
2. AI Content Analysis
3. Engineering & Economic Assessment
4. Quality Assurance
5. Security & Privacy Check
🇨🇳 中文分析1. 摘要
2. AI 成分分析
3. 工程与经济评估
4. 质量保证
5. 安全与隐私检查
|
- The held-out bullet claimed the instances are "absent from agent_files.txt and Task.md", but Task.md is in agent_files.txt and names the VHO-* instances. Rewrite: the .vrp files are not copied into the sandbox and the agent is told they exist (Task.md / constraints.txt), but their data is not available at code-generation time, so an LLM cannot hardcode routes by name. - Fix zh-CN reproduction test counts (23/16/5/6, matching the EN README).
🤖 AI Code Review (gemini-3-flash-preview)🇬🇧 English Analysis1. Executive Summary
2. AI Content Analysis
3. Engineering & Economic Assessment
4. Quality Assurance
5. Security & Privacy Check
🇨🇳 中文分析1. 摘要
2. AI 成分分析
3. 工程与经济评估
4. 质量保证
5. 安全与隐私检查
|
The env-strip test was appended after the __main__ block, so running python verification/test_validator.py directly skipped it (unittest.main ran before the class was defined); move the block to the end and fix a method-name typo (fronteer -> frontier).
The repo-level task table should list every contributed benchmark; add the VehicleRouting/CVRP row to TASK_DETAILS.md and its Chinese translation.
|
感谢详细评审——七条均已处理并验证。逐条说明:
|
🤖 AI Code Review (gemini-3-flash-preview)🇬🇧 English Analysis1. Executive Summary
2. AI Content Analysis
3. Engineering & Economic Assessment
4. Quality Assurance
5. Security & Privacy Check
🇨🇳 中文分析1. 摘要
2. AI 成分分析
3. 工程与经济评估
4. 质量保证
5. 安全与隐私检查
|
🤖 AI Code Review (gemini-3-flash-preview)🇬🇧 English Analysis1. Executive Summary
2. AI Content Analysis
3. Engineering & Economic Assessment
4. Quality Assurance
5. Security & Privacy Check
🇨🇳 中文分析1. 摘要
2. AI 成分分析
3. 工程与经济评估
4. 质量保证
5. 安全与隐私检查
|
cbfdb98 to
ece8a74
Compare
🤖 AI Code Review (gemini-3-flash-preview)🇬🇧 English Analysis1. Executive Summary
2. AI Content Analysis
3. Engineering & Economic Assessment
4. Quality Assurance
5. Security & Privacy Check
🇨🇳 中文分析1. 摘要
2. AI 成分分析
3. 工程与经济评估
4. 质量保证
5. 安全与隐私检查
|
Summary
基准(benchmarks/VehicleRouting/CVRP)
标准库
LNS);刻意弱化的规范 baseline(随机顺序最近插入),给
agent 留出明确提升空间(55.59 → 100)
Dockerfile
Background
CVRP 是经典 NP-hard 物流优化问题:最小化容量约束车队的总配
送距离。实例坐标聚类模拟城市客户分布(Reality
Gap);成本最小化工程价值明确(Economic Value)。
Verification
python verification/evaluator.py baseline/solver.py→ combined_score 55.59, valid 1.0(12实例)
python -m frontier_eval task=unified task.benchmark=VehicleRouting/CVRP algorithm.iterations=0docker build -t cvrp-benchmark -f verification/docker/Dockerfile . && docker run --rm cvrp-benchmarkShinkaEvolve 99.31 / AB-MCTS 98.70,对 reference 100