Замеры — доказать подъём слабой модели
Тезис Chimera состоит в том, что структура позволяет слабой и дешёвой модели бить выше своего веса. Честный способ это показать — контролируемый A/B на стандартном замере: закрепить подмножество задач и модель, сделать единственной переменной обвязку и сообщить разницу с доверительным интервалом, а не голое «стало лучше». (Независимые исследования показывают, что одна только обвязка качает ту же модель примерно на 7 пунктов, поэтому оценка без оговорок не говорит ничего о вашем вкладе.)
Эксперимент
Замер: Terminal-Bench 2.0 — задача в Docker, инструкция и проверочные тесты, оценка «прошло / не прошло» этими тестами, всё под управлением обвязки Harbor, не зависящей от конкретного агента.
- Плечо A (база): одна бесплатная модель в нейтральном каркасе Harbor — «слабая модель в одиночку».
- Плечо B (воздействие): та же модель, те же идентификаторы задач, под управлением Chimera.
- Метрика: pass@1. Заголовочное число: Δ = доля(B) − доля(A) с 95% ДИ.
- Защита от самообмана: закрепить подмножество идентификаторов задач (и опубликовать его), прогнать не меньше 3 зёрен, опубликовать все стенограммы и добавлять строку с передовой моделью только как ориентир потолка, но никогда как предмет сравнения.
Единственное число, доказывающее тезис: бесплатная модель одна = X%, бесплатная модель с Chimera = Y%, те же задачи, Y ≫ X.
Как это запустить
uv sync --extra bench # installs terminal-bench (Harbor); also needs Docker
playwright install chromium # only if a task needs the browser tool
Chimera подключается как агент воздействия через chimera/eval/terminal_bench.py
(make_chimera_tb_agent(model) собирает BaseAgent для Harbor, который запускает chimera solve с
флагами обвязки). Направьте Harbor на закреплённое подмножество и бесплатную модель для каждого
плеча; точный вызов harbor run и --agent-import-path смотрите в
документации Harbor.
SWE-bench Verified (второе табло) — проведено дважды
Terminal-Bench доказывает тезис на задачах командной строки; SWE-bench доказывает его на настоящих
исправлениях ошибок с GitHub: получив репозиторий на базовом коммите и описание проблемы, агент
должен выдать патч, при котором тесты FAIL_TO_PASS этого случая проходят, а PASS_TO_PASS остаются
зелёными. «Verified» — это подмножество, проверенное людьми.
Результаты
Два заранее объявленных запуска на одном и том же замороженном срезе из 19 случаев django/django
(самый лёгкий слой сложности), deepseek-chat-v3.1, pass@1, оценка только официальным стендом
swebench 4.1.0 в Docker. Полное описание:
bench/swe_bench/RESULTS.md.
| запуск | база | + Chimera | парная Δ | 95% ДИ | |
|---|---|---|---|---|---|
1 (max_steps=8) |
36,8% (7/19) | 36,8% (7/19) | +0,0% | [−8,5%, +8,5%] | не значимо |
2 (max_steps=30) |
42,1% (8/19) | 57,9% (11/19) | +15,8% | [−1,9%, +15,8%] | не значимо |
Первый запуск — ровный ноль, и он опубликован без изменений. Второй исправил две неисправности, которые были нашими (каркас работал без своего сильнейшего механизма, а восьми шагов с вызовами инструментов не хватает, чтобы сориентироваться в репозитории на 250 МБ), и дал 3 случая выиграно, 0 проиграно. Находка — именно в паре: каркас не стоит ничего, когда агента морят шагами, и стоит трёх случаев, когда не морят, — и выигрывает он тем, что правит лучше (точность 69% против 57%, когда правит), а не тем, что правит больше.
⚠️ 57,9% — это не оценка по SWE-bench Verified. Срез намеренно лёгкий и из одного репозитория, выбран так, чтобы парному A/B было где что-то измерить; настоящая оценка Verified требует всех 500. И разница не значима — при 8 парах, где провалились оба плеча, n=19 оставляет всего три информативные пары.
Второй запуск несёт ещё и отзыв: механизм, которым мы объяснили пустые патчи первого запуска, оказался неверным (лекарством был бюджет шагов, а не проверка разницы, на которую мы грешили), и поправка опубликована так же заметно, как и само утверждение.
Переходник
Переходник (chimera.eval.swe_bench) честен относительно своей границы: чистые части — вызов
chimera solve для каждого случая (плечо воздействия) и разбор официального отчёта об оценке —
живут здесь и покрыты модульными тестами; набор данных и стенд оценки в Docker подключаются по
желанию и не поставляются в комплекте, а вердикт «прошло / не прошло» приходит от собственных
тестов SWE-bench, а не сообщается нами самими.
# 1. Curate a JSONL slice (one instance object per line): instance_id, repo, base_commit,
# problem_statement, and (optionally) test_cmd. build_solve_command turns each into a
# `chimera solve <issue> --verify <test_cmd> --repo-map --progress-ledger --replan --checklist`.
# 2. Run both arms through the official SWE-bench harness (model-only vs model+Chimera) on the
# SAME instance ids, producing two evaluation reports.
# 3. Score the honest A/B:
chimera swe-bench-compare model_only_report.json chimera_report.json --instances mini.jsonl
Оба отчёта проецируются на общий список случаев (отсутствующий идентификатор считается нерешённым), поэтому два плеча всегда сравниваются на одинаковых случаях — а дальше применяется тот же вердикт по доверительному интервалу Ньюкомба.
Как посчитать A/B (замер не нужен)
Когда каждое плечо выдало «прошло / не прошло» по задачам, статистика считается одной командой — и для этого не нужно никаких дополнений, так что машинка честной отчётности доступна всегда:
chimera bench-compare baseline.json chimera.json --treatment-name chimera
Каждый файл — это список булевых значений в JSON (или {task_id: bool}) по одним и тем же
идентификаторам задач. На выходе: доля прохождения каждого плеча с границами Уилсона, разница, её
95% ДИ по Ньюкомбу и вывод, значима ли разница (интервал не включает ноль). Если не значима, об
этом говорится прямо — нужно либо большее подмножество и больше зёрен, либо возможность признать, что
нововведение действительно не двигает число.
Тот же bench-compare служит мерилом для каждой последующей возможности: любое добавление в M14
обязано показать, что двигает Δ на том же подмножестве, иначе его вырезают.
Честная ловушка (чего избегать)
- Загрязнение — у публичного SWE-bench задокументированы утечки решений; предпочитайте наборы, устойчивые к загрязнению, и сообщайте эту оговорку.
- Смешение с обвязкой — никогда не сообщайте голое «мы набрали X%»; вклад Chimera выделяет только разница в A/B.
- Неверная база и отбор удобного — сравнивайте «слабая модель + Chimera» с той же слабой моделью в одиночку на одинаковых идентификаторах задач, с зёрнами и полными журналами. Передовая модель — это потолок, а не соперник.