Авторесёрч: автономные ML-эксперименты

Правила агента и режим автономности

Во втором подмодуле мы разобрали, что program.md — это текстовый файл, который человек пишет для агента, и что именно он задаёт направление. Сейчас — шаг глубже: посмотрим на сам текст этого файла изнутри. Что именно агент читает? Какие правила получает? Почему он работает без пауз и не задаёт вопросов?

Структура program.md: три блока

Файл устроен линейно — три блока, читаемых сверху вниз. Агент обрабатывает их в том же порядке, в котором они написаны.

---

Блок 1. Setup — что делается один раз

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

Пять шагов в setup:

1. Завести датированную ветку — autoresearch/<tag>, где тег обычно содержит дату. Это разбирали в предыдущем подмодуле: чтобы легко ориентироваться среди сессий.

2. Прочитать README.md — понять общий контекст репозитория.

3. Прочитать prepare.py и train.py — изучить текущее состояние кода перед тем, как что-то менять. Агент не импровизирует вслепую; он сначала разбирается, что уже есть.

4. Убедиться, что данные закэшированы — проверить, что prepare.py уже был запущен и шарды датасета на месте. Если нет — агент не может начать обучение.

5. Инициализировать results.tsv — создать файл с заголовком колонок, куда будут писаться результаты каждого эксперимента.

Только после всех пяти шагов агент переходит ко второму блоку.

---

Блок 2. Ограничения — что запрещено и что предпочтительно

Это самая важная часть program.md с точки зрения безопасности и честности экспериментов. Несколько жёстких запретов и несколько принципов.

Жёсткие запреты:

• Нельзя менять prepare.py. Причину мы разобрали в третьем подмодуле: именно там живёт логика вычисления val_bpb. Если агент изменит её — он сможет «улучшить» метрику, подправив формулу, а не модель. Это читерство, которое полностью обесценивает результаты.
• Нельзя устанавливать новые пакеты. Агент работает с тем окружением, которое уже собрано через uv sync. Это ограничение удерживает эксперименты воспроизводимыми: если агент мог бы ставить произвольные библиотеки, повторить его результаты стало бы сложнее.
• Нельзя трогать логику оценки. Шире, чем предыдущий пункт: любые изменения, которые влияют на то, как считается val_bpb, запрещены. Метрика должна оставаться стабильным референсом на протяжении всей сессии.

Принципы (не жёсткие правила, но предписания):

• VRAM держать в разумных пределах. Агент видит peak_vram_mb в каждом прогоне и должен учитывать это при следующей гипотезе. Если архитектура резко растёт, следующий эксперимент рискует упасть с OOM. program.md явно это оговаривает.
• Предпочитать простые, элегантные решения. Не усложнять ради мелкого прироста. Если изменение даёт минимальное улучшение val_bpb, но значительно усложняет архитектуру — принцип говорит воздержаться. Это не строгий критерий, а направляющий принцип для агентского суждения.

---

Блок 3. Экспериментальная петля — семь шагов по кругу

Третий блок — это тело бесконечного цикла. После setup агент входит сюда и никогда не выходит сам.

Семь шагов каждой итерации:

1. Посмотреть git-статус. Агент проверяет текущее состояние репозитория — убеждается, что коммит предыдущей итерации сделан правильно и рабочее дерево чистое.

2. Сформулировать гипотезу и внести изменение в train.py. Агент решает, что попробовать: другой оптимизатор, иной размер батча, измененная архитектура слоя, новый learning rate schedule — всё это в рамках train.py.

3. Закоммитить изменение. До запуска обучения — коммит. Это важно: без коммита при откате нет к чему сбрасываться.

4. Запустить прогон и собрать логи:

```bash

uv run train.py > run.log 2>&1

```

Ровно 5 минут wall clock — тренировочный луп сам следит за бюджетом времени.

5. Извлечь метрики:

```bash

grep "^val_bpb:|^peak_vram_mb:" run.log

```

Никакой интерпретации — только два числа из двух строк лога.

6. Принять решение — оставить или сбросить:

- val_bpb снизился → коммит остаётся, ветка продвигается.

- val_bpb не снизился (равен или хуже) → git reset к предыдущему состоянию.

7. Записать результат в results.tsv. В обоих случаях — принято или отброшено. Запись фиксирует всё: что пробовалось, что получилось. Это позволяет человеку потом увидеть весь путь, а не только успешные шаги.

После седьмого шага — немедленно обратно на первый. Без паузы, без ожидания.

---

Директива автономности: агент не останавливается

Последняя строка program.md — самая короткая и самая принципиальная. Смысл: агент работает до ручной остановки и не задаёт вопросов.

Это не просто «продолжай работать» — это явная директива убрать любые остановки между итерациями. Агент не спрашивает «продолжать?» после каждого прогона. Он не ждёт подтверждения гипотезы. Он не просит уточнений, если что-то неоднозначно.

Для пользователя это означает: вы запустили агента и можете идти спать. Утром — открываете results.tsv и смотрите, что было найдено за ночь. Именно так набирается ~100 экспериментов за 8–9 часов.

Одна практическая оговорка: если агент натолкнулся на серьёзную ошибку (например, train.py перестал компилироваться из-за синтаксической ошибки в его же изменении, и run.log содержит traceback без val_bpb) — поведение зависит от того, насколько хорошо агент умеет читать логи и восстанавливаться. Директива автономности не отменяет здравый смысл: хорошо написанный program.md добавляет инструкции на случай ошибочного прогона — например, «если val_bpb не найден в логе, считать прогон неудачным и сбросить изменения».

---

Как это всё соединяется

program.md — небольшой документ, но он замыкает всю конструкцию. Три файла, разобранных во втором подмодуле, получают смысл через него: prepare.py защищён явным запретом, train.py становится единственной ареной, а человек управляет направлением через правку текста, а не Python-кода.

Что стоит понять: program.md — не скрипт и не конфиг. Это инструкция на естественном языке, которую LLM-агент читает и интерпретирует. Именно поэтому в нём есть принципы (не только правила) и нет жёсткой валидации их соблюдения — агент сам решает, когда архитектура «слишком усложнилась» ради «мелкого прироста». Это одновременно гибкость и ограничение: агент может проявлять суждение там, где жёсткий скрипт не справился бы, но и ошибиться там, где скрипт ошибиться не мог.

---

Мини-проверка

Три быстрых вопроса:

1. Агент закончил прогон, val_bpb стал хуже. Какой следующий шаг по program.md? *(git reset, запись в TSV, новая итерация)*

2. Человек хочет сказать агенту «сфокусируйся на снижении параметров». В какой файл он идёт? *(program.md, второй блок — ограничения или даже как явная задача)*

3. Почему агент читает prepare.py в setup, если не имеет права его менять? *(Чтобы понять текущую инфраструктуру и не изобретать то, что уже реализовано)*

---

В следующем и финальном подмодуле честно разберём рамки: где авторесёрч применим, а где нет — и почему задачи из вашего брифа (поиск источников, проверка фактов, академические обзоры) лежат за пределами того, что делает этот репозиторий.