Autoresearch Experiment Trees

Три разных значения одного слова

Под autoresearch смешивают три существенно разные системы:

1. Оптимизация исполняемого артефакта — например, менять код обучения и максимизировать заранее выбранную метрику. Это узкая, быстро проверяемая задача.
2. Исследовательская платформа — рабочие деревья, compute backends, журнал запусков, provenance и восстановление после сбоя. OpenResearch относится прежде всего сюда.
3. Автономная наука end-to-end — выбрать значимую проблему, найти корректный метод и сделать обоснованный научный вывод. Наличие первых двух уровней третьего не доказывает.

Граница полезности проходит по проверяемости: чем быстрее и однозначнее среда возвращает outcome, тем правдоподобнее автономный цикл. Открытая постановка проблемы, отложенный эффект и неоднозначная интерпретация требуют человеческого решения, а не ещё одной итерации модели.

Контракт экспериментального узла

Минимальный узел дерева хранит:

Статус процесса не заменяет результат: completed сообщает только, что runner завершился. Утверждение о качестве появляется после чтения метрики и логов; отсутствие строки в усечённом выводе не является evidence отсутствия.

Provisional, answered и frozen

Сбой инфраструктуры и отрицательный научный результат нельзя сводить в одно failed.

• Provisional: OOM, отсутствующая зависимость, повреждённый launcher — запуск не ответил на гипотезу. Исправляется тот же узел, сохраняя исходный вопрос.
• Answered: измерение получено, даже если вариант хуже baseline. Это полноценный результат.
• Frozen: после ответа узел не переписывается. Новая гипотеза или содержательное изменение создаёт потомка.

Иначе дерево задним числом теряет неудачные варианты и превращается в рассказ о победителе. Freeze должен быть runtime-инвариантом: Git сам по себе не запрещает агенту изменить старую ветку, а инструкция в skill остаётся вероятностной.

Сопоставимость задаётся run contract

Соседние варианты сравнимы, только если фиксированы evaluation data и split, вычисление метрики, команда запуска, environment и бюджет. Меняется один версионированный фактор — код или конфигурация, связанная с commit.

Явный --run-command у дочернего узла опасен даже тогда, когда агенту текстом сказано его не менять: результаты выглядят соседями, но измеряют разные процедуры. Платформа должна отклонить изменение контракта либо создать новую линию сравнения и пометить старые числа несопоставимыми.

Форма поиска: stacked bushes

Одна длинная цепочка быстро наследует раннюю ошибку. Большой плоский веер тратит бюджет и плохо накапливает выводы. Практический компромисс — stacked bushes:

1. от текущего победителя запустить небольшой набор содержательно разных sibling-гипотез;
2. дождаться достаточного evidence;
3. выбрать следующий parent по заранее заданному критерию;
4. построить от него следующий небольшой куст.

Параллельность здесь не цель. Она полезна, когда варианты действительно различны и укладываются в фиксированный бюджет; одинаковые агенты с одинаковым контекстом легко создают иллюзию исследования из коррелированных кандидатов (Cohort Diversity).

Per-completion loop

После завершения запуска возможны четыре действия:

• repair — запуск не ответил на вопрос из-за технической поломки;
• refill — освободившийся слот получает ещё одну заранее допустимую гипотезу;
• promote — evidence достаточно, выбран parent следующего куста;
• stop — бюджет, серия регрессий, нарушение валидности или человеческое решение закрывают цикл.

Событие run finished — только сигнал пробуждения. Оркестратор после него перечитывает канонический список runs и обрабатывает все новые terminal-состояния. Иначе потерянное, повторное или одновременно пришедшее событие меняет научный результат. Завершение контура определяется состоянием drained, а не тишиной в очереди (Batch Close Protocol).

LLM не обязан быть оптимизатором

В фиксированном численном пространстве поиска классические CMA-ES, TPE и SMAC лучше хранят состояние оптимизации и распределяют следующий бюджет. Исследование HPO для autoresearch показывает более сильную гибридную границу: оптимизатор ведёт mean/covariance/history и предлагает кандидатов, а LLM реже вносит доменно осмысленные изменения кода или направления поиска.

Поэтому LLM полезнее как генератор гипотез, редактор программ и интерпретатор аномалий, чем как единственный scheduler. Чем больше задача похожа на HPO, тем сильнее основание отдать состояние поиска детерминированному алгоритму.

Семантические признаки как объект autoresearch

Ещё одна гибридная граница появляется, когда исходные данные — текст, а целевая метрика численная:

1. LLM предлагает набор предметных вопросов как гипотезы о полезных признаках;
2. типизированная модель решений массово превращает ответы на них в числовые вероятности;
3. классическая supervised-модель учится предсказывать target по этим признакам;
4. ошибки out-of-fold на development set направляют следующий раунд вопросов;
5. held-out test не читается циклом и остаётся независимым судьёй.

В cookbook TypeSafe для wine reviews bag-of-words baseline дал RMSE 2,47, прямой score модели решений — 2,15, первый набор из 18 семантических вопросов — 1,87, а после пяти раундов и 38 вопросов — 1,77. Значим здесь не абсолютный benchmark, а форма разделения ролей и плато: основное улучшение пришло в первом раунде, следующие четыре дали только 0,10 RMSE. Это основание заранее задавать budget/plateau stop, а не доказательство бесконечного self-improvement.

Контракт эксперимента должен фиксировать генератор вопросов, версию decision model, текст каждой рубрики, способ кодирования распределений, learner и split. Иначе изменение «семантического признака» незаметно меняет измеряемую величину, а соседние узлы перестают быть сопоставимыми.

Научные отказы не исправляются одной оркестрацией

AutoResearch Failure Taxonomy показывает, что основные ошибки лежат не в запуске tool calls, а в содержании исследования: эксперимент не проверяет заявленную гипотезу, валидатор круговой, реализация расходится с методом, вывод сильнее evidence, а замеченное противоречие не меняет дальнейший путь.

Отсюда обязательны два гейта:

1. до запуска: может ли эксперимент опровергнуть гипотезу, независимы ли критерий и объект оптимизации;
2. после запуска: следует ли conclusion из полученного evidence и были ли разобраны противоречащие случаи.

Human gate нужен при смене исследовательского вопроса, метрики или run contract, при неожиданном восстановлении/аномалии и перед внешним научным утверждением. Человек не должен вручную подтверждать каждый job, но сохраняет ответственность за смысл критерия и остановку.

Autoresearch не равен self-improvement

В autoresearch меняется исследуемый код или конфигурация. В Continual Agent Evolution меняется способность самого рабочего агента — knowledge, skill, harness или weights. Результаты experiment tree могут стать evidence для offline evolution, но один успешный run не получает права автоматически переписать production skill или собственный validator.

Связано с

• Quality Metric Design — почему неверная метрика делает эффективный поиск хуже, а не лучше
• State Centric Execution — канонический run state вместо реконструкции из transcript
• Agent Execution Platform — immutable source snapshot, runner и evidence как обязанности runtime
• Batch Close Protocol — reconciliation и детерминированное закрытие параллельных запусков
• Continual Agent Evolution — граница между поиском варианта и изменением самого агента
• Benchmarks Agents — fixed expenditure и сопоставимость harness/model revision
• Typed Decision Models — преобразование предложенных LLM семантических вопросов в повторно используемые числовые признаки