{/ Эта страница автоматически передается из навыков SKILL.md с помощью сайта/scripts/generate-skill-docs.py. Редактируйте исходный SKILL.md, а не эту страницу. /}

Написание исследовательских статей

Напишите ML-статьи для NeurIPS/ICML/ICLR: от дизайна доработки.

Метаданные навыки


Источник	Встроенный (устанавливается по умолчанию)
Путь	`навыки/исследования/написание исследовательских работ`
Версия	`1.1.0`
Автор	Исследование оркестра
Лицензия	Массачусетский технологический институт
Зависимости	`semanticscholar`, `arxiv`, `habanero`, `requests`, `scipy`, `numpy`, `matplotlib`, `SciencePlots`
Платформы	Linux, MacOS
Теги	`Исследования`, `Написание статей`, `Эксперименты`, `ML`, `AI`, `NeurIPS`, `ICML`, `ICLR`, `ACL`, `AAAI`, `COLM`, `LaTeX`, `Цитирование`, `Статистический анализ`
Связанные навыки	`arxiv`, `ml-paper-writing`, `subagent-driven-development`, `plan`

Справочник: полный SKILL.md:::информация

Ниже приведено полное описание навыка, который Hermes загружает при активации этого навыка. Это то, что агент видит в качестве инструкций, когда навыки активны.

Конвейер написания исследовательских статей

Сквозной конвейер для создания готовых к публикации исследовательских статей по ML/AI, ориентированных на NeurIPS, ICML, ICLR, ACL, AAAI и COLM. Эти качества соответствуют полному жизненному циклу исследования: проектирование экспериментов, выполнение, мониторинг, анализ, составление статей, рецензирование, доработка и подача.

Это не линейный конвейер — это итеративный цикл. Результаты запускают новые эксперименты. Рецензии запускают новый анализ. Агент должен обработать этот цикл обратной связи.

┌─────────────────────────────────────────────────────────────┐
│                 КОНВЕЙЕР ИССЛЕДОВАТЕЛЬСКОЙ СТАТЬИ           │
│                                                             │
│  Фаза 0: Настройка проекта ──► Фаза 1: Обзор литературы     │
│       │                          │                          │
│       ▼                          ▼                          │
│  Фаза 2: Дизайн          Фаза 5: Написание черновика ◄──┐  │
│       эксперимента               │                       │  │
│       │                          ▼                       │  │
│       ▼                    Фаза 6: Саморецензирование     │  │
│  Фаза 3: Выполнение &           и доработка ─────────────┘  │
│       Мониторинг                 │                          │
│       │                          ▼                          │
│       ▼                    Фаза 7: Подача                    │
│  Фаза 4: Анализ ─────► (возврат к Фазе 2 или 5)           │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Когда использовать этот навык

Используйте этот навык, когда: - Начинаете новую исследовательскую статью на основе условной кодовой базы или идеи. - Проектирование и проведение экспериментов для подтверждения утверждений статей. - Пишете или доработаете любой раздел исследовательской статьи. - Готовитесь к подаче на конкретную конференцию или семинар. - Отвечаете на рецензии с помощью дополнительных экспериментов или доработок. - Конвертируете статью между форматами конференций. - Пишете неэмпирические статьи — теоретические, обзорные, эталонные или позиционные (см. Типы статей за категории эмпирического ML) - Проектирует электромагнитные измерения для НЛП, HCI или согласования исследований. - Готовите материалы после принятия — постеры, доклады, релизы кода

Основная философия

Будьте проактивны. Предоставляйте полные черновики, а не вопросы. Ученые работают — создают что-то конкретное, на что они могут отреагировать, а затем итерируют.
Никогда не галлюцинируйте цитирования. Сгенерированные AI цитирования содержат ~40% ошибок. Всегда получайте их программно. Помечайте непроверяемые цитирования как [НУЖНА ЦИТАЦИЯ].
Статья — это история, а не набор экспериментов. Каждая статья должна иметь одно четкое утверждение, выраженное в одном предложении. Если вы не можете это сделать, статья не готова.
Эксперименты по соблюдению требований. Каждый эксперимент должен быть подтвержден каким-либо утверждением его поддержки. Никогда не проводите эксперименты, которые не влияют на повествование статей.
Фиксируйте рано, фиксируйте часто. каждую завершенную партию экспериментов, каждое обновление статьи черновика — фиксируйте с описательными сообщениями. Git log — это история экспериментов.

Проактивность и сотрудничество

По умолчанию: Будьте проактивны. Сначала черновик, затем спрашивайте с черновиком.

Уровень уверенности	Действие
Высокий (понятный репозиторий, очевидный вклад)	Напишите полный черновик, предоставьте, итерируйте на основе обратной связи
Средний (не какая уникальность)	Напишите черновику с отмеченными неопределенностями, продолжайте
Низкий (серьёзные неизвестные)	Задайте 1-2 целенаправленных вопроса через `clarify`, затем черновик

Раздел	Черновик автономный?	Отметить в черновике
Аннотация	Да	«Сформулировал вклад как X — скорректируйте, если нужно»
Введение	Да	«Сделал акцент на проблеме Y — исправьте, если неправильно»
Методы	Да	«Включил детали A, B, C — недостающие части»
Эксперименты	Да	«Выделил результаты 1, 2, 3 — измените порядок, если нужно»
Связанные работы	Да	«Процитировал статьи X, Y, Z — цитаты те, что я пропустил»

Запрашивайте ввод только тогда, когда: целевая площадка неясна, несколько противоречивых формулировок, результаты являются неполными, явный запрос на предварительный просмотр.

Фаза 0: Настройка проекта

Цель: Создать космическое пространство, понять существующую работу, определить вклад.

Шаг 0.1: Исследуйте репозиторий

# Понять структуру проекта
ls -la
find. -name "*.py" | head -30
find. -name "*.md" -o -name "*.txt" | xargs grep -l -i "result\|conclusion\|finding"

Ищите: - README.md — обзор проекта и заявления - results/, outputs/, experiments/ — возникновение результатов - configs/ — настройка экспериментов - файлы .bib — периодические цитирования - Черновики документов или заметки

Шаг 0.2: Организуйте игровое пространство

разработать согласованную структуру рабочих пространств:

workspace/
  paper/               # Исходники LaTeX, рисунки, скомпилированные PDF
  experiments/         # Скрипты запуска экспериментов
  code/                # Реализация основного метода
  results/             # Сырые результаты экспериментов (автосгенерированные)
  tasks/               # Определения задач/бенчмарков
  human_eval/          # Материалы для человеческой оценки (если необходимо)

Шаг 0.3: Настройка контроля управления

git init  # если еще нет
git remote add origin <repo-url>
git checkout -b paper-draft  # или main

Дисциплина Git: каждая завершенная партия экспериментов фиксируется описательным сообщением. Пример:

Add Monte Carlo constrained results (5 runs, Sonnet 4.6, policy memo task)
Add Haiku baseline comparison: autoreason vs refinement baselines at cheap model tier

Шаг 0.4: Определите вкладку

Прежде чем что-либо писать, сформулируйте: - Что: Что именно эта статья вносит? - Почему: Какие доказательства это подтверждают? - И что: Почему читателям должно быть это важно?

Предложите ученому: «Исходя из моего понимания, основной вклад: [одно предложение]. Ключевые результаты отображаются [Y]. Это та формулировка, которую вы хотите?»

Шаг 0.5: Создание списка TODO

Используйте инструмент todo для создания структурированного запланированного проекта:

TODO исследовательской статьи:
- [ ] Определить вклад в одно предложение
- [ ] Обзор литературы (связанные работы + базовые методы)
- [ ] Разработать основные эксперименты
- [ ] Провести эксперименты
- [ ] Проанализировать результаты
- [ ] Написать первый черновик
- [ ] Саморецензирование (симуляция рецензентов)
- [ ] Доработать на основе рецензии
- [ ] Подготовка к подаче

Обновляйте это на протяжении всего проекта. Это обеспечивает поддержание состояния между сеансами.

Шаг 0.6: Оцените вычислительный бюджет

Перед запуском экспериментов оцените стоимость и время:

Контрольный список вычислительного бюджета:
- [ ] Затраты на API: (цена модели за токен) × (оценка токенов на запуск) × (количество запусков)
- [ ] GPU-часы: (время на эксперимент) × (количество экспериментов) × (количество сидов)
- [ ] Затраты на человеческую оценку: (аннотаторы) × (часы) × (почасовая ставка)
- [ ] Общий потолок бюджета и резерв (добавьте 30-50% на перезапуски)

Отслеживайте фактические расходы на выполнение экспериментов:

# Простой шаблон отслеживания затрат
import json, os
from datetime import datetime

COST_LOG = "results/cost_log.jsonl"

def log_cost(experiment: str, model: str, input_tokens: int, output_tokens: int, cost_usd: float):
    entry = {
        "timestamp": datetime.now().isoformat(),
        "experiment": experiment,
        "model": model,
        "input_tokens": input_tokens,
        "output_tokens": output_tokens,
        "cost_usd": cost_usd,
    }
    with open(COST_LOG, "a") as f:
        f.write(json.dumps(entry) + "\n")

Когда бюджет ограничен: запустите пилотные эксперименты (1–2 сидения, подмножество задач), прежде чем переходить к полным прогонам. Используйте более простые модели для отладки конвейеров, а затем переключайтесь на целевые модели для окончательных запусков.

Шаг 0.7: Координация нескольких авторов

Большинство статей имеют от 3 до 10 авторов. Предварительно определите рабочие процессы:

Рабочий процесс	Инструмент	Когда использовать
На обороте	На основе браузера	Несколько авторов редактируют одновременно, нет опыта работы с git
Git + LaTeX	`git` с `.gitignore` для вспомогательных файлов	Техническая сила, нужен взгляд на основу веток
На обороте + синхронизация с Git	Премиум на обороте	Лучшее из-за угла — совместная работа в первое время со сложным поворотом

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

Контрольный список координации авторов:
- [ ] Согласовать владение разделами (кто что пишет)
- [ ] Настроить общее рабочее пространство (Overleaf или git репозиторий)
- [ ] Установить соглашения по обозначениям (до того, как кто-либо начнет писать)
- [ ] Запланировать внутренние раунды рецензирования (не только в конце)
- [ ] Назначить одного человека для финального форматирования
- [ ] Согласовать стиль рисунков (цвета, шрифты, размеры) до создания рисунков

Соглашения по LaTeX, которые необходимо согласовать заранее: - Макрос \method{} для единообразного наименования методов - Стиль цитирования: использование \citet{} vs \citep{} - Математическая нотация: строчная жирная для векторов, прописная жирная для матриц и т.д. - Британское и американское написание

Фаза 1: Обзор литературы

Цель: Найти связанные работы, определить базовые методы, собрать цитирования.

Шаг 1.1: Определите исходные статьи

Приступим к статьям, уже упомянутым в кодовой базе:

# Через терминал:
grep -r "arxiv\|doi\|cite" --include="*.md" --include="*.bib" --include="*.py"
find. -name "*.bib"

Шаг 1.2: Поиск работ

Загрузите навыки arxiv для структурированного поиска статей: skill_view("arxiv"). Он обеспечивает поиск через REST API arXiv, графы цитирования Semantic Scholar, авторов профиля и генерации BibTeX.

Используйте web_search для широкого поиска, web_extract для получения официальных статей:

# Через web_search:
web_search("[основная техника] + [область применения] site:arxiv.org")
web_search("[базовый метод] сравнение ICML NeurIPS 2024")

# Через web_extract (для конкретных статей):
web_extract("https://arxiv.org/abs/2303.17651")

Дополнительные поисковые запросы:

Поисковые запросы:
- "[основная техника] + [область применения]"
- "[базовый метод] сравнение"
- "[название проблемы] state-of-the-art"
- Имена авторов из существующих цитирований

Рекомендуется: Установите Exa MCP для поиска академических материалов в ближайшее время:

claude mcp add exa -- npx -y mcp-remote "https://mcp.exa.ai/mcp"

Шаг 1.2b: Углубление поиска (сначала ширина, затем глубина)

Плоский поиск (один раунд запроса) обычно пропускает важные сопутствующие работы. Используйте итерационный шаблон сначала ширину, затем глубину, вдохновленный конвейерами глубокого исследования:

Итеративный поиск литературы:

Раунд 1 (Ширина): 4-6 параллельных запросов, охватывающих разные углы
  - "[метод] + [домен]"
  - "[название проблемы] state-of-the-art 2024 2025"
  - "[базовый метод] сравнение"
  - "[альтернативный подход] vs [ваш подход]"
  → Собрать статьи, извлечь ключевые концепции и терминологию

Раунд 2 (Глубина): Создать последующие запросы из знаний Раунда 1
  - Новая терминология, обнаруженная в статьях Раунда 1
  - Статьи, цитируемые наиболее релевантными результатами Раунда 1
  - Противоречивые результаты, требующие исследования
  → Собрать статьи, определить оставшиеся пробелы

Раунд 3 (Целевой): Заполнить конкретные пробелы
  - Отсутствующие базовые методы, выявленные в Раундах 1-2
  - Параллельные работы (последние 6 месяцев, та же проблема)
  - Ключевые отрицательные результаты или неудачные подходы
  → Остановиться, когда новые запросы возвращают в основном уже просмотренные статьи

Когда остановиться: Если в раунде возвращается >80% статей, уже находящихся в вашей коллекции, поиск насыщен. Обычно достаточно 2-3 раундов. Для обзорных статей ожидайте 4-5 раундов.

Для агентских рабочих процессов: Делегируйте запросы каждого раунда параллельно через delegate_task. Соберите результаты, удалите дубликаты, а затем сгенерируйте запрос следующего раунда объединенных знаний.

Шаг 1.3: Проверяйте каждое цитирование

НИКОГДА не генерируйте BibTeX по памяти. ВСЕГДА получите программно.

Для каждого цитирования следуйте обязательному 5-шаговому процессу:

Проверка цитирования (ОБЯЗАТЕЛЬНО для каждого цитирования):
1. ПОИСК → Запросите Semantic Scholar или Exa MCP с конкретными ключевыми словами
2. ПРОВЕРКА → Подтвердите, что статья существует в 2+ источниках (Semantic Scholar + arXiv/CrossRef)
3. ПОЛУЧЕНИЕ → Получите BibTeX через согласование содержимого DOI (программно, а не по памяти)
4. ВАЛИДАЦИЯ → Подтвердите, что утверждение, которое вы цитируете, действительно присутствует в статье
5. ДОБАВЛЕНИЕ → Добавьте проверенный BibTeX в библиографию
Если ЛЮБОЙ шаг не удался → отметьте как [CITATION NEEDED], сообщите ученому

# Получение BibTeX через DOI
import requests

def doi_to_bibtex(doi: str) -> str:
    response = requests.get(
        f"https://doi.org/{doi}",
        headers={"Accept": "application/x-bibtex"}
    )
    response.raise_for_status()
    return response.text

Если вы не можете проверить цитирование:

\cite{PLACEHOLDER_author2024_verify_this}  % TODO: Проверить существование этого цитирования

Всегда сообщайте ученому: «Я отметил [X] цитирований как заполнители, которые необходимы на стороне».

См. references/citation-workflow.md для полной документации API и полного класса CitationManager.

Шаг 1.4: Организуйте сопутствующие работы

Группируйте статьи по методологии, а не постатейно:

Хорошо: «Одна линия работ использует предположение X [ссылки], тогда как мы используем предположение Y, потому что...» Плохо: «Смит и др. Представлены X. Джонс и др. Представители Y. Мы объединяем оба.»

Фаза 2: Дизайн эксперимента

Цель: Разработайте эксперименты, которые официально заявляют о статьях декларации. Каждый эксперимент должен быть на конкретный вопрос.

Шаг 2.1: Сопоставьте условия с экспериментами

Определить явное парламентие:

Утверждение	Эксперимент	Ожидаемые доказательства
«Наш метод превосходит базовые»	Основное сравнение (Таблица 1)	Процент победы, статистическая инновационность
«Эффект сильнее для слабых моделей»	Исследование масштабирования моделей	Монотонная кривая модернизация
«Сходимость требует ограничения области»	С ограничениями vs без	Сравнение скорости сходимости

Правило: Если эксперимент не соответствует утверждению, не проводите его.

Шаг 2.2: Разработайте базовые методы

Сильные базовые методы — это то, что отличает принятые статьи от отклонений. Рецензенты спрашивают: «Сравнили ли они с X?»

Стандартные категории базовых методов: - Наивный базовый: Самый простой возможный подход - Сильный базовый: Лучший известный существующий метод - Абляционные базовые: Ваш метод минус один компонент. - Базовые с поэтапными вычислениями: тот же вычислительный бюджет, другие финансовые потоки.

Шаг 2.3: Определите оценку протокола

Прежде чем что-либо запустить, укажите: - Метрики: Что вы измеряете, направление символов (выше/ниже лучше) - Агрегация: Как результаты объединяются по запускам/задачам. - Статистические тесты: Какие тесты устанавливают инновационность - Размеры выбора: Сколько запусков/проблем/задач.

Шаг 2.4: Напишите скрипты экспериментов

Следуйте этим шаблонам успешных исследовательских производств:

Инкрементальное сохранение — сохраняет результаты после каждого шага для восстановления после сбоя:

# Сохранять после каждой проблемы/задачи
result_path = f"results/{task}/{strategy}/result.json"
if os.path.exists(result_path):
    continue  # Пропустить уже выполненную работу
#... запустить эксперимент...
with open(result_path, 'w') as f:
    json.dump(result, f, indent=2)

Сохранение документов — сохраняйте все промежуточные результаты:

results/<experiment>/
  <task>/
    <strategy>/
      final_output.md          # Финальный результат
      history.json             # Полная траектория
      pass_01/                 # Артефакты каждой итерации
        version_a.md
        version_b.md
        critic.md

Разделение ответственности — разделяйте генерацию, наблюдайте и визуализируйте:

run_experiment.py              # Основной запуск эксперимента
run_baselines.py               # Сравнение с базовыми методами
run_comparison_judge.py        # Слепая оценка
analyze_results.py             # Статистический анализ
make_charts.py                 # Визуализация

См. references/experiment-patterns.md для полных шаблонов проектирования, хрон-диптихов и восстановления после ошибок.

Шаг 2.5: Разработайте человеческую оценку (если применимо)

Многие статьи по НЛП, HCI и соглашениям требуют дополнительных оценок в качестве основных или дополнительных доказательств. Разработайте это для запуска автоматических экспериментов — человеческая оценка часто требует больше времени (одобрение IRB, среди аннотаторов).

Когда нужна человеческая оценка: - Автоматизированные метрики не отражают то, что вас волнует (беглость, полезность, безопасность). - Ваш вклад касается внимания, ориентированности на человека (читабельность, предпочтение, доверие) - Рецензенты на НЛП-площадках (ACL, EMNLP) ожидания этого для постановки задач

Ключевые проектные решения:

Решение	Варианты	Рекомендации
Совет аннотатора	Эксперт, краудворкер, конечный пользователь	Соответствуйте тому, что требуют эти положения
Шкала	Лайкерт (1-5), популярное сравнение, ранжирование	Попарное сравнение надежнее Лайкерта для выходов LLM
Размер выбора	На аннотатора и всего элементов	Анализ мощности или минимум 100 элементов, 3+ аннотатора
Метрика соглашения	Коэн каппа, альфа Криппендорфа, ICC	Альфа Криппендорфа для >2 аннотаторов; сообщайте также о сыром соглашении
Платформа	Prolific, MTurk, внутренняя команда	Плодовитый по качеству; MTurk для масштаба; внутренняя экспертиза в домене

Контрольный список инструкций по аннотациям:

- [ ] Четкое описание задачи с примерами (хорошими И плохими)
- [ ] Критерии принятия решений для неоднозначных случаев
- [ ] Как минимум 2 проработанных примера на категорию
- [ ] Проверки внимания / эталонные элементы (10-15% от общего числа)
- [ ] Квалификационное задание или отборочный раунд
- [ ] Расчетное время на элемент и справедливая компенсация (>= местной минимальной зарплаты)
- [ ] Обзор IRB/этики, если требуется вашим учреждением

Требования к Великобритании (рецензенты проверяют все это): - Количество аннотаторов и их квалификация - Межаннотаторское соглашение с конкретной метрикой и значением - Детали завершения (сумма, расчетная почасовая поставка) - Описание или скриншот интерфейса аннотации (приложение) - Общее время аннотации

См. references/human-evaluation.md для всех случаев, статистические тесты для данных высоких оценок, шаблоны контроля качества краудсорсинга и рекомендации по IRB.

Фаза 3: Выполнение эксперимента и мониторинг

Цель: Надежно запускать эксперименты, следить за прогрессом, восстанавливаться после сбоев.

Шаг 3.1: Запустите эксперименты

Используйте nohup для длительных экспериментов:

nohup python run_experiment.py --config config.yaml > logs/experiment_01.log 2>&1 &
echo $!  # Запишите PID

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

Шаг 3.2: Настраиваем мониторинг (шаблон Cron)

Для длительных экспериментов предусмотрены периодические проверки. Запрос cron должен соответствовать этому шаблону:

Шаблон запроса мониторинга:
1. Проверить, работает ли процесс: ps aux | grep <pattern>
2. Прочитать последние 30 строк лога: tail -30 <logfile>
3. Проверить наличие завершенных результатов: ls <result_dir>
4. Если результаты есть, прочитать и сообщить: cat <result_file>
5. Если все готово, зафиксировать: git add -A && git commit -m "<описательное сообщение>" && git push
6. Сообщить в структурированном формате (таблицы с ключевыми метриками)
7. Ответить на ключевой аналитический вопрос для этого эксперимента

Тихий режим: Если с момента последней проверки ничего не изменилось, ответьте [SILENT], чтобы подавить пользователя. Сообщайте только тогда, когда есть новости.

Шаг 3.3: Обработка сбоев

Распространенные типы сбоев и восстановления:

Сбой	Обнаружение	Восстановление
Лимит скорости API / исчерпание кредитов	Ошибки 402/429 в логах	Подождать, а затем перезапустить (скрипты пропускают выполненную работу)
Сбой процесса	PID исчез, неполные результаты	Перезапуск с последней контрольной точки
Тайм-аут на сложные задачи	Процесс зависит, прогресса нет в логе	Убить и пропустить, отметить в обществе
Неправильный идентификатор модели	Ошибки, ссылающиеся на имя модели	Исправить ID и перезапустить

Ключевой момент: Скрипты всегда должны проверять наличие имеющихся результатов и пропускать выполненную работу. Это делает перезапуски безопасными и эффективными.

Шаг 3.4: Фиксируйте готовые результаты

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

git add -A
git commit -m "Добавить <имя эксперимента>: <ключевой вывод в 1 строке>"
git push

Шаг 3.5: Ведите журнал экспериментов

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

// experiment_journal.jsonl — добавляйте одну запись на каждую попытку эксперимента
{
  "id": "exp_003",
  "parent": "exp_001",
  "timestamp": "2025-05-10T14:30:00Z",
  "hypothesis": "Добавление ограничений области исправит ошибку сходимости из exp_001",
  "plan": "Перезапустить autoreason с max_tokens=2000 и фиксированным шаблоном структуры",
  "config": {"model": "haiku", "strategy": "autoreason", "max_tokens": 2000},
  "status": "completed",
  "result_path": "results/exp_003/",
  "key_metrics": {"win_rate": 0.85, "convergence_rounds": 3},
  "analysis": "Ограничения области исправили сходимость. Win rate вырос с 0.42 до 0.85.",
  "next_steps": ["Попробовать те же ограничения на Sonnet", "Протестировать без шаблона структуры"],
  "figures": ["figures/exp003_convergence.pdf"]
}

Зачем журнал, а не только git? Git отслеживает изменения файлов. Журнал отслеживает обсуждение: почему вы попробовали X, что вы узнали и что это означает для следующего эксперимента. При написании статьи это было бесценно для раздела «Методы» («мы наблюдали X, что мотивировало Y») и для честного отчета о неудачах.

Выбор лучшего пути: Когда журнал показывает ветвящееся дерево (exp_001 → exp_002a, exp_002b, exp_003), определите путь, который лучше всего поддерживает статьи положений. Документируйте тупиковые ветви в приложениях, таких как абляция или отрицательные результаты.

Снимок кода для каждого эксперимента: Копируйте скрипт эксперимента после каждого запуска:

cp experiment.py results/exp_003/experiment_snapshot.py

Это обеспечивает точное вмешательство даже после внесения изменений в код.

Фаза 4: Анализ результатов

Цель: Извлечь выводы, вычислить статистику, определить историю.

Шаг 4.1: Агрегируйте результаты

Напишите скрипты анализа, которые: 1. Загружают все результаты результатов партий. 2. Вычислить показатели по задачам и агрегированные метрики. 3. Генерируют сводные таблицы

# Стандартный шаблон анализа
import json, os
from pathlib import Path

results = {}
for result_file in Path("results/").rglob("result.json"):
    data = json.loads(result_file.read_text())
    strategy = result_file.parent.name
    task = result_file.parent.parent.name
    results.setdefault(strategy, {})[task] = data

# Вычислить агрегированные метрики
for strategy, tasks in results.items():
    scores = [t["score"] for t in tasks.values()]
    print(f"{strategy}: mean={np.mean(scores):.1f}, std={np.std(scores):.1f}")

Шаг 4.2: Статистическая инновационность

Всегда запасайте: - Планки погрешностей: Стандартное отклонение или ошибка, указывающая, что именно стандарт - Доверительные интервалы: 95% ДИ для ключевых результатов. - Попарные тесты: Тест Макнемара для сравнения двух методов. - Размеры результатов: Коэн d или h для практической инновации.

См. references/experiment-patterns.md для полных реализаций теста Макнемара, бутстреп-ДИ и Коэна h.

Шаг 4.3: Определите историю

После анализа ясно ответьте: 1. Каков основной вывод? Сформулируйте его в одном предложении. 2. Что вас удивило? Неожиданные результаты часто делают лучшие статьи. 3. Что не удалось? Неудачные эксперименты могут оказаться наиболее информативными. Честный отчет о неудачах в статье. 4. Какие эксперименты нужны? Результаты часто поднимают новые вопросы.

Обработка отрицательных или нулевых результатов

Если ваша гипотеза окажется неверной или результаты неубедительны, у вас есть три помощника:

Ситуация	Действие	Подступающая площадка
Гипотеза неверна, но почему информативно	Построить статью об анализе причин	NeurIPS, ICML (если анализ строгий)
Метод не превосходит базовые, но раскрывает что-то новое	Переформулировать вклад как понимание/анализ	ICLR (ценит понимание), семинары
Чистый отрицательный результат по популярному утверждению	Напишите об этом — сообществу нужно знать	Наборы данных и тесты NeurIPS, TMLR, семинары
Результаты неубедительны, нет четкой истории	Изменить направление — провести другие эксперименты или переформулировать	Не форсируйте статьи, которых нет

Как написать в статье, отрицательный результат: - сделаем вывод с тем, что верит сообщество и почему важно это проверить - Опишите вашу строгую методологию (должна быть безупречной — рецензенты будут проверять обоснование) - Представлять нулевой результат четко со статистическими доказательствами - Проанализируйте почему ожидаемый результат не материализовался - Обсудите последствия для области

Площадки, которые явно приветствуют отрицательные результаты: NeurIPS (наборы данных и тесты), TMLR, ML Reproducibility Challenge, семинары на крупных конференциях. Некоторые семинары специально призывают к отрицательным результатам.

Шаг 4.4: Создание рисунков и таблиц

** Рисунки**: - Используйте векторную графику (PDF) для всех графиков: plt.savefig('fig.pdf') - Палитры, безопасные для дальтоников (Окабе-Ито или Пол Тол) - Самодостаточные подключения — читатель должен понимать без основного текста - Без заголовка внутри рисунка — функция поддержания подписи.

Таблицы: - Используйте пакет LaTeX booktabs - Выделите жирным лучшее значение по каждой метрике. - Включайте символы направления (выше/ниже лучше) - Согласованная точность десятичных знаков

\usepackage{booktabs}
\begin{tabular}{lcc}
\toprule
Метод & Точность $\uparrow$ & Задержка $\downarrow$ \\
\midrule
Базовый & 85.2 & 45ms \\
\textbf{Наш} & \textbf{92.1} & 38ms \\
\bottomrule
\end{tabular}

Шаг 4.5: Решите: больше экспериментов или писать?

Ситуация	Действие
Основные утверждения подтверждены, результаты значимы	Перейти к Фазе 5 (написание)
Результаты неубедительны, нужны дополнительные данные	Вернуться к Фазе 2 (дизайн)
Неожиданный результат указывает на новое направление	Вернуться к Фазе 2 (дизайн)
Не хватает одной абляции, которую рецензенты спросят	Провести ее, затем Фаза 5
Все эксперименты были выполнены, но некоторым не удалось	Отметить неудачи, перейти к Фазе 5

Шаг 4.6: Запишите журнал экспериментов (большинство к написанию)

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

Создайте experiment_log.md со следующей структурой:

# Журнал экспериментов

## Вклад (одно предложение)
[Основное утверждение статьи]

## Проведенные эксперименты

### Эксперимент 1: [Название]
- **Проверяемое утверждение**: [Какое утверждение статьи это поддерживает]
- **Настройка**: [Модель, набор данных, конфиг, количество запусков]
- **Ключевой результат**: [Одно предложение с числом]
- **Файлы результатов**: results/exp1/final_info.json
- **Сгенерированные рисунки**: figures/exp1_comparison.pdf
- **Удивительные выводы**: [Что-то неожиданное]

### Эксперимент 2: [Название]...

## Рисунки
| Имя файла | Описание | В каком разделе находится |
|-----------|----------|---------------------------|
| figures/main_comparison.pdf | Гистограмма, сравнивающая все методы на бенчмарке X | Результаты, Рисунок 2 |
| figures/ablation.pdf | Абляция с удалением компонентов A, B, C | Результаты, Рисунок 3 |...

## Неудачные эксперименты (документируйте для честности)
- [Что было испробовано, почему не удалось, что это говорит нам]

## Открытые вопросы
- [Что результаты подняли, что статья должна осветить]

Почему это важно: При написании черновика агент (илигированный под-агент) может загрузить experiment_log.md вместе с шаблоном LaTeX и создать первый черновик, основанный на практических принципах. Без этого моста пишущий агент должен разобрать сырые файлы JSON/CSV и вывести историю — распространенный источник галлюцинированных или неверно сообщенных чисел.

Дисциплина Git: Фиксируйте этот журнал вместе с состояниями, которые он описывает.

Итеративное уточнение: выбор стратегии

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

Быстрая таблица решений

Ваша ситуация	Стратегия	Почему
Модель среднего уровня + ограниченная задача	Авторазум	Идеальное сочетание. Разрыв между поколением и оценкой высшей. Базовые методы активного крепления обеспечивают выходы слабых моделей.
Модель среднего уровня + открытая задача	Автопричина с добавленными ограничениями в областях	Добавьте фиксированные факты, текстуры или результаты, чтобы уточнить улучшение пространства.
Фронтирная модель + ограниченная задача	Авторазум	Выигрывает 2/3 ограниченных задач даже на фронтире.
Фронтирная модель + неограниченная задача	Критика и пересмотр или один проход	Авторазум на последнем месте. Модель достаточно хорошо оценивает себя.
Конкретная техническая задача (системный дизайн)	Критика и пересмотр	Прямой цикл «найди и исправь» более эффективен.
Задача заполнить шаблон (одна правильная структура)	Один проход или Консервативный	Минимальное пространство решений. Итерация не добавляет ценности.
Код с тестовыми примерами	Авторазум (вариант для кода)	Структурированный анализ почему это не удалось перед исправлением. Уровень восстановления 62% против 43%.
Очень слабая модель (класс Лама 8B)	Один проход	Модель слишком слаба для кандидатов. Инвестируйте в качественную генерацию.

Разрыв между генерацией и оценкой

Ключевое понимание: Ценность Autoreason зависит от разрыва между возможностями модели и ее способностью к самооценке.

Уровень модели     │ Генерация │ Самооценка │ Разрыв │ Ценность Autoreason
───────────────────┼───────────┼────────────┼────────┼─────────────────────
Слабая (Llama 8B)  │ Плохая    │ Плохая     │ Маленький│ Нет — не может генерировать разнообразных кандидатов
Средняя (Haiku 3.5)│ Приемлемая│ Плохая     │ БОЛЬШОЙ │ МАКСИМАЛЬНАЯ — 42/42 идеальных Borda
Средняя (Gemini Flash)│ Приемлемая│ Умеренная │ Большой│ Высокая — выигрывает 2/3
Сильная (Sonnet 4) │ Хорошая   │ Приемлемая │ Средний │ Умеренная — выигрывает 3/5
Фронтир (S4.6)     │ Отличная  │ Хорошая    │ Маленький│ Только с ограничениями

Этот разрыв структурный, а не временный. По мере снижения затрат сегодняшний фронтир становится завтрашним средним уровнем. Идеальное сочетание смещается, но никогда не исчезает.

Цикл Autoreason (кратко)

Каждый проход создает три кандидата от свежих, изолированных агентов:

Критик → находит проблемы в действующем кандидате A (без исправлений)
Автор B → пересматривает A на основе критики
Синтезатор → объединяет A и B (рандомизированные метки)
Панель судей → 3 слепых CoT судьи ранжируют A, B, AB по методу Borda
Сходимость → A выигрывает k=2 последовательных прохода → готово

Ключевые параметры: - k=2 сходимость (k=1 преждевременно, k=3 слишком дорого, без прироста качества) - CoT судьи всегда (в 3 раза быстрее сходимость) - Температура 0.8 для авторов, 0.3 для судей - Консервативное разрешение ничьих: действующий кандидат выигрывает ничьи - Каждая роль — свежий агент без общего контекста

Применение к черновикам статей

При уточнении самой статьи через autoreason: - Предоставьте критику фактические данные: фактические экспериментальные данные, JSON результатов, статистические выходы. Без этого модели галлюцинируют вымышленные абляционные исследования и поддельные доверительные интервалы. - Используйте минимум 3 работающих судьи: Сломанный парсер судьи не добавляет шума — он полностью предотвращает равновесие. - Ограничьте область доработки: «Устраните эти конкретные слабости», а не «улучшите статью».

Режимы отказа

Сбой	Обнаружение	Исправление
Нет сходимости (A никогда не выигрывает)	A выигрывает <15% за 20+ проходов	Добавьте ограничения области к задаче
Дрейф синтеза	Количество слов неограниченно растет	Ограничьте структуру и результат
Деградация ниже single pass	Базовые методы оцениваются выше итеративного выхода	Переключитесь на single pass; модель может быть слишком слабой
Переобучение (код)	Высокий проход публичного теста, низкий проход приватного	Используйте структурированный анализ, а не только обратную связь от тестов
Сломанные судьи	Ошибки парсинга уменьшают панель до менее 3	Исправьте парсер перед продолжением

См. references/autoreason-methodology.md для полных промптов, деталей подсчета Borda, руководства по выбору модели, шаблонов проектирования ограничений области и справочника по вычислительному бюджету.

Фаза 5: Написание черновика статьи

Цель: Написать полную, готовую к публикации статью.

Управление контекстом для больших проектов

Проект статьи с 50+ файлами экспериментов, несколькими каталогами результатов и обширными заметками по литературе может легко превысить контекстное окно агента. Управляйте этим проактивно:

Что загружать в контекст для каждой задачи написания:

Задача написания	Загрузить в контекст	НЕ загружать
Написание Введения	`experiment_log.md`, формулировка вклада, 5-10 наиболее релевантных аннотаций статей	Сырые JSON результатов, полные скрипты экспериментов, все заметки по литературе
Написание Методов	Конфиги экспериментов, псевдокод, описание архитектуры	Сырые логи, результаты других экспериментов
Написание Результатов	`experiment_log.md`, сводные таблицы результатов, список рисунков	Полные скрипты анализа, промежуточные данные
Написание Связанных работ	Организованные заметки по цитированиям (результат Шага 1.4),.bib файл	Файлы экспериментов, сырые PDF
Проход доработки	Полный черновик статьи, конкретные замечания рецензентов	Все остальное

Принципы: - experiment_log.md — это основной мост контекста — он обобщает все необходимое для написания без загрузки сырых файлов данных (см. Шаг 4.6) - Загружайте контекст одного раздела за раз при делегировании. Под-агенту, пишущему Методы, не нужны заметки по обзору литературы. - Обобщайте, не включайте сырые файлы. Для JSON результата на 200 строк загрузите сводную таблицу на 10 строк. Для статьи на 50 страниц загрузите 5-предложенную аннотацию + вашу 2-строчную заметку о ее релевантности. - Для очень больших проектов: Создайте каталог context/ с предварительно сжатыми сводками: context/ contribution.md # 1 предложение experiment_summary.md # Таблица ключевых результатов (из experiment_log.md) literature_map.md # Организованные заметки по цитированиям figure_inventory.md # Список рисунков с описаниями

Принцип повествования

Самый строгий вывод: Ваша статья — это не набор экспериментов, это история с одним четким вкладом, подкрепленным доказательствами.

Каждая успешная статья об отмывании денег состоит из того, что Нил Нанда Кримина «нарративом»: короткая, строгая, основанная на доказательствах, техническая история с выводом, важным для читателей.

Три стола (должны быть кристально блестящие к концу введения):

Столп	Описание	Тест
Что	1-3 новых новых заявления	Можете ли вы сформулировать их в одном предложении?
Почему	Строгие эмпирические доказательства	Отличают ли эксперименты вашу гипотезу от альтернативы?
И что	Почему читателям должно быть важно	Связано ли это с признанной проблемой сообщества?

Если вы не можете сформулировать свой вклад в одном предложении, у вас еще нет статей.

Источники, стоящие за этим руководством

Этот специалист синтезирует философию, написанную на основе наблюдений, которые многие площадки публиковали среди ведущих. Слой философии написания был первоначально составлен Orchestra Research как навык ml-paper-writing.

Источник	Ключевой вклад	Ссылка
Нил Нанда (Google DeepMind)	Принцип повествования, кадр Что/Почему/И что	Как писать статьи по ML
Себастьян Фаркуар (DeepMind)	Формула аннотации из 5 предложений	[Как писать статьи по ML] (https://sebastianfarquhar.com/on-research/2024/11/04/how_to_write_ml_papers/)
Гопен и Лебедь	7 препятствий ожиданиям читателей	Наука научного письма
Закари Липтон	Выбор слов, устранение оговорок	Эвристика для написания научных статей
Джейкоб Стейнхардт (Калифорнийский университет в Беркли)	Точность, согласованная терминология	Советы по написанию
Итан Перес (Антропный)	Микросоветы по ясности	[Советы по простому написанию бумаги] (https://ethanperez.net/easy-paper-writing-tips/)
Андрей Карпаты	Фокус на одной вкладке	Различные лекции

Для более глубокого погружения в любом из этих источников см.: - references/writing-guide.md — Полные объяснения с примерами - references/sources.md — Полная библиография

Распределение времени

Потратьте примерно равномерное время на каждое из: 1. Аннотация 2. Введение 3. Рисунки 4. Все остальное вместе взятое

Почему? Большинство рецензентов строят мнения до того, как дойдут до ваших методов. Читатели сталкиваются с такими статьями, как: заголовок → аннотация → введение → рисунки → возможно, остальное.

Написание рабочего процесса

Контрольный список написания статьи:
- [ ] Шаг 1: Определите вклад в одно предложение
- [ ] Шаг 2: Создайте черновик Рисунка 1 (основная идея или самый убедительный результат)
- [ ] Шаг 3: Создайте черновик аннотации (формула из 5 предложений)
- [ ] Шаг 4: Создайте черновик введения (макс. 1-1.5 страницы)
- [ ] Шаг 5: Создайте черновик методов
- [ ] Шаг 6: Создайте черновик экспериментов и результатов
- [ ] Шаг 7: Создайте черновик связанных работ
- [ ] Шаг 8: Создайте черновик заключения и обсуждения
- [ ] Шаг 9: Создайте черновик ограничений (ТРЕБУЕТСЯ всеми площадками)
- [ ] Шаг 10: Спланируйте приложение (доказательства, дополнительные эксперименты, детали)
- [ ] Шаг 11: Заполните контрольный список статьи
- [ ] Шаг 12: Финальная проверка

Шаблон двухпроходного уточнения

При написании черновика с AI-агентом используйте двухпроходный подход (доказал свою эффективность в конвейере AI-Scientist от SakanaAI):

Проход 1 — Написание + мгновенное уточнение по каждому разделу: Для каждого раздела напишите полный черновик, а затем немедленно уточните его в том же пятом. Это выявляет локальные проблемы (ясность, поток, полноту), пока раздел свеж.

Проход 2 — Глобальное уточнение с контекстом полной статьи: После того, как все разделы написаны, редактируйте каждый раздел с осознанием всех статей. Это приводит к межраздельным проблемам: повторяемости, несогласованной терминологии, потоку повествования и пробелам, где один раздел обещает, что другой не выполняется.

Промпт для второго прохода уточнения (по разделам):
"Проверьте [РАЗДЕЛ] в контексте полной статьи.
- Соответствует ли он остальной части статьи? Есть ли избыточность с другими разделами?
- Согласована ли терминология с Введением и Методами?
- Можно ли что-то вырезать без ослабления сообщения?
- Плавно ли повествование переходит из предыдущего раздела и в следующий?
Вносите минимальные, целенаправленные правки. Не переписывайте с нуля."

Контрольный список ошибок LaTeX

Прикрепите этот контрольный список к каждому предложению уточнения. Это самая распространенная ошибка, когда LLM пишет LaTeX:

Контрольный список качества LaTeX (проверять после каждого редактирования):
- [ ] Нет незакрытых математических символов (знаки $ сбалансированы)
- [ ] Ссылаться только на существующие рисунки/таблицы (\ref соответствует \label)
- [ ] Нет вымышленных цитирований (\cite соответствует записям в.bib)
- [ ] Каждый \begin{env} имеет соответствующий \end{env} (особенно figure, table, algorithm)
- [ ] Нет HTML-загрязнения (</end{figure}> вместо \end{figure})
- [ ] Нет незаэкранированных подчеркиваний вне математического режима (используйте \_ в тексте)
- [ ] Нет дублирующихся определений \label
- [ ] Нет дублирующихся заголовков разделов
- [ ] Числа в тексте соответствуют фактическим экспериментальным результатам
- [ ] Все рисунки имеют подписи и метки
- [ ] Нет чрезмерно длинных строк, вызывающих предупреждения overfull hbox

Шаг 5.0: Заголовок

Заголовок — самый читаемый элемент статьи. Он определяет, перейдет ли кто-то к аннотациям.

Хорошие заголовки: - Формула вносит вклад или результат: «Авторазум: когда итеративное уточнение LLM работает и почему оно терпит неудачу» - Выделяют удивительный результат: «Масштабирование языковых моделей с ограничением данных» (подразумевает, что можно) - Называют метод + что он делает: «DPO: Прямая оптимизация языковых моделей по предпочтениям»

Плохие заголовки: - Слишком общее: «Подход к улучшению результатов языковой модели» - Слишком длинный: все, что длиннее ~15 слов - Только жаргон: «Асимптотическая сходимость итеративного уточнения стохастической политики» (для кого это?)

Правила: - Включите название вашего метода, если оно есть (для цитируемости) - Включите 1-2 ключевых слова, которые будут искать рецензенты. - Избегайте двоеточий, если обе части несут смысла. - Тест: узнал ли рецензент домена и вклад только из заголовка?

Шаг 5.1: Аннотация (формула из 5 предложений)

От Себастьяна Фаркуара (DeepMind):

1. Что вы достигли: «Мы представляем...», «Мы доказываем...», «Мы демонстрируем...»
2. Почему это сложно и важно
3. Как вы это делаете (со специализированными ключевыми словами для обнаружения)
4. Какие у вас есть доказательства
5. Ваше самое примечательное число/результат

Удалите общие вступления вроде «Большие языковые модели достигли замечательного успеха...»

Шаг 5.2: Рисунок 1

Рисунок 1 — это вторая вещь, на которую смотрят большинство читателей (после аннотации). Создайте его черновик до написания введения — это заставляет вас прояснить основную идею.

Тип Рисунка 1	Когда использовать	Пример
Диаграмма метода	Новая архитектура или конвейер	Блок-схема TikZ, показывающая вашу систему
Тизер результатов	Один убедительный результат рассказывает всю историю	Гистограмма: «Наш vs базовые» с четким разрывом
Иллюстрация проблемы	Проблема неинтуитивна	До/после, показывающее режим отказа, который вы исправляете
Концептуальная диаграмма	Абстрактный вклад нуждается в визуальной основе	Матрица 2x2 свойств метода

Правила: Рисунок 1 должен быть понятен без чтения какого-либо текста. Одна подпись должна передавать основную идею. Используйте цвет целенаправленно — не просто украшайте.

Шаг 5.3: Введение (макс. 1-1.5 страницы)

Должно включать: - Четкую формулировку проблемы - Краткий обзор подхода - Список из 2-4 пунктов вклада (макс. 1-2 строки каждый в двухколоночном формате) - Методы должны начинаться на странице 2-3

Шаг 5.4: Методы

Обеспечьте возможность повторной реализации: - Концептуальный план или псевдокод - Все гиперпараметры перечислены - Архитектурные детали, достаточные для воспроизведения - Представьте окончательные проектные решения; абляции идут в эксперименты

Шаг 5.5: Эксперименты и результаты

Для каждого эксперимента явно укажите: - Какое утверждение он поддерживает - Как он связан с основным вкладом - Что наблюдать: «синяя линия показывает X, что демонстрирует Y»

Требования: - Планки погрешностей с методологией (std dev vs std error) - Диапазоны поиска гиперпараметров - Вычислительная инфраструктура (тип GPU, общее количество часов) - Методы установки сидов

Шаг 5.6: Связанные работы

Организуйте методологически, а не постатейно. Цитируйте щедро — рецензенты, вероятно, являются авторами соответствующих работ.

Шаг 5.7: Ограничения (ТРЕБУЕТСЯ)

Все крупные конференции требуют этого. Честность помогает: - Рецензентам предписано не наказывать за честное признание ограничений - Предвосхищайте критику, выявляя слабые места первыми - Объясните, почему ограничения не подрывают основные утверждения

Шаг 5.8: Заключение и обсуждение

Заключение (требуется, 0.5-1 страница): - Повторите вклад в одном предложении (другими словами, чем в аннотации) - Обобщите ключевые результаты (2-3 предложения, не список) - Последствия: что это означает для области? - Будущая работа: 2-3 конкретных следующих шага (не расплывчатое «мы оставляем X для будущей работы»)

Обсуждение (опционально, иногда объединяется с заключением): - Более широкие последствия за пределами непосредственных результатов - Связи с другими подобластями - Честная оценка того, когда метод работает, а когда нет - Практические соображения по развертыванию

НЕ вводите новые результаты или утверждения в заключении.

Шаг 5.9: Стратегия приложения

Приложения не ограничены по объему на всех крупных площадках и необходимы для воспроизводимости. Структура:

Раздел приложения	Что сюда идет
Доказательства и выводы	Полные доказательства, слишком длинные для основного текста. Основной текст может формулировать теоремы с «доказательство в Приложении A».
Дополнительные эксперименты	Абляции, кривые масштабирования, разбивки по наборам данных, чувствительность гиперпараметров
Детали реализации	Полные таблицы гиперпараметров, детали обучения, спецификации оборудования, случайные сиды
Документация набора данных	Процесс сбора данных, руководства по аннотации, лицензирование, предобработка
Промпты и шаблоны	Точные использованные промпты (для методов на основе LLM), шаблоны оценки
Человеческая оценка	Скриншоты интерфейса аннотации, инструкции, данные аннотаторам, детали IRB
Дополнительные рисунки	Разбивки по задачам, визуализации траекторий, примеры случаев отказа

Правила: - Основная статья должна быть самодостаточной — рецензенты не обязаны читать приложения - Никогда не помещайте критические доказательства только в приложение - Перекрестные ссылки: «Полные результаты в Таблице 5 (Приложение B)», а не просто «см. приложение» - Используйте команду \appendix, затем \section{A: Доказательства} и т.д.

Управление бюджетом страниц

Когда превышен лимит страниц:

Стратегия сокращения	Экономит	Риск
Перенести доказательства в приложение	0.5-2 страницы	Низкий — стандартная практика
Сократить связанные работы	0.5-1 страница	Средний — можно пропустить ключевые цитирования
Объединить таблицы с подрисунками	0.25-0.5 страницы	Низкий — часто улучшает читаемость
Использовать `\vspace{-Xpt}` экономно	0.1-0.3 страницы	Низкий, если незаметно, высокий, если очевидно
Удалить качественные примеры	0.5-1 страница	Средний — рецензенты любят примеры
Уменьшить размеры рисунков	0.25-0.5 страницы	Высокий — рисунки должны оставаться читаемыми

НЕ: уменьшайте размер шрифта, меняйте поля, удаляйте обязательные разделы (ограничения, более широкое влияние) или используйте \small/\footnotesize для основного текста.

Шаг 5.10: Заявление об этике и более широком влиянии

Большинство площадок теперь требуют или настоятельно рекомендуют заявление об этике/более широком влиянии. Это не шаблонный текст — рецензенты читают его и могут отметить проблемы этики, которые приведут к отклонению без рецензирования.

Что включать:

Компонент	Содержание	Требуется
Положительное влияние на общество	Как ваша работа приносит пользу обществу	NeurIPS, ICML
Потенциальное негативное влияние	Риски неправильного использования, проблемы двойного назначения, режимы отказа	NeurIPS, ICML
Справедливость и предвзятость	Есть ли у вашего метода/данных известные предвзятости?	Все площадки (неявно)
Воздействие на окружающую среду	Углеродный след вычислений для крупномасштабного обучения	ICML, все чаще NeurIPS
Конфиденциальность	Использует ли ваша работа или позволяет обрабатывать личные данные?	ACL, NeurIPS
Раскрытие LLM	Был ли AI использован при написании или экспериментах?	ICLR (обязательно), ACL

Написание заявления:

\section*{Заявление о более широком влиянии}
% NeurIPS/ICML: после заключения, не учитывается в лимите страниц

% 1. Положительные применения (1-2 предложения)
Эта работа позволяет [конкретное применение], что может принести пользу [конкретной группе].

% 2. Риски и меры смягчения (1-3 предложения, будьте конкретны)
[Метод/модель] потенциально может быть использован во вред для [конкретного риска]. Мы смягчаем
это с помощью [конкретных мер, например, выпуск только весов модели выше размера X,
включение фильтров безопасности, документирование режимов отказа].

% 3. Ограничения утверждений о влиянии (1 предложение)
Наша оценка ограничена [конкретным доменом]; более широкое развертывание потребует
[конкретной дополнительной работы].

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

Углеродный след вычислений (для статей с интенсивным обучением):

# Оценка с использованием методологии ML CO2 Impact
gpu_hours = 1000  # общее количество GPU-часов
gpu_tdp_watts = 400  # например, A100 = 400W
pue = 1.1  # Коэффициент эффективности использования энергии (накладные расходы ЦОД)
carbon_intensity = 0.429  # кг CO2/кВтч (среднее по США; варьируется по регионам)

energy_kwh = (gpu_hours * gpu_tdp_watts * pue) / 1000
carbon_kg = energy_kwh * carbon_intensity
print(f"Энергия: {energy_kwh:.0f} кВтч, Углерод: {carbon_kg:.0f} кг CO2-экв")

Шаг 5.11: Паспорт данных и моделей карточек (если применимо)

Если ваша статья представляет собой новый набор данных или выпускает модель, структурированную документацию. Рецензенты все чаще наблюдают за этим и отслеживают наборы данных и тесты NeurIPS, требующие этого.

Паспорта данных для наборов данных (Gebru et al., 2021) — в приложении:

Документация набора данных (Приложение):
- Мотивация: Зачем был создан этот набор данных? Какую задачу он поддерживает?
- Состав: Из чего состоят экземпляры? Сколько их? Какие типы данных?
- Сбор: Как собирались данные? Каков был источник?
- Предобработка: Какая очистка/фильтрация применялась?
- Распространение: Как распространяется набор данных? Под какой лицензией?
- Поддержка: Кто его поддерживает? Как сообщать о проблемах?
- Этические соображения: Содержит ли личные данные? Получено ли согласие?
  Потенциальный вред? Известные предвзятости?

Карточки моделей (Mitchell et al., 2019) — в приложении для релизов моделей:

Карточка модели (Приложение):
- Детали модели: Архитектура, обучающие данные, процедура обучения
- Предполагаемое использование: Основные случаи использования, варианты вне области
- Метрики: Метрики оценки и результаты на бенчмарках
- Этические соображения: Известные предвзятости, оценки справедливости
- Ограничения: Известные режимы отказа, области, где модель показывает низкие результаты

Стиль написания

Ясность на уровне предложений (7 соглашений Gopen & Swan):

Принцип	Правило
Близость подлежащего и глагола	Держите подлежащее и глагол рядом
Позиция ударов	Поместите акцент в конец предложений
Позиция темы	Ставьте контекст сначала, новую информацию после
Старое перед новым	Знакомая информация → Знакомая информация
Одна единица, одна функция	Каждый абзац делает одну точку
Действие в глаголе	Используйте глаголы, а не отглагольные существительные
Контекст перед новым	Задайте ситуацию перед представлением

Выбор слов (Липтон, Стейнхардт): - Будьте конкретны: «точность», а не «производительность». - Устраните разговоры: выберите «может», если нет явных неопределенностей. - Согласованная терминология на протяжении всей работы. - Избегайте инкрементальной лексики: «разрабатываем», а не «объединяем»

Полное руководство по написанию с примерами: См. references/writing-guide.md

Использование шаблонов LaTeX

Всегда сначала скопируйте весь шаблон каталога, а затем вставьте его внутрь.

Контрольный список настройки шаблона:
- [ ] Шаг 1: Скопировать весь каталог шаблона в новый проект
- [ ] Шаг 2: Проверить, что шаблон компилируется как есть (до любых изменений)
- [ ] Шаг 3: Прочитать пример содержимого шаблона, чтобы понять структуру
- [ ] Шаг 4: Заменить пример содержимого раздел за разделом
- [ ] Шаг 5: Использовать макросы шаблона (проверьте преамбулу на определения \newcommand)
- [ ] Шаг 6: Очистить артефакты шаблона только в конце

Шаг 1: Скопируйте полный шаблон

cp -r templates/neurips2025/ ~/papers/my-paper/
cd ~/papers/my-paper/
ls -la  # Должны быть: main.tex, neurips.sty, Makefile и т.д.

Копите ВЕСЬ каталог, а не только файл.tex. Шаблоны включают файлы стилей (.sty), библиографии стилей (.bst), пример оценки и Makefile.

Шаг 2: проверьте, что шаблон компилируется первым

Перед любыми изменениями:

latexmk -pdf main.tex
# Или вручную: pdflatex main.tex && bibtex main && pdflatex main.tex && pdflatex main.tex

Если немодифицированный шаблон не скомпилирован, сначала исправьте его (обычно отсутствующие пакеты TeX — установите через tlmgr install <package>).

Шаг 3: Сохраните стандарты шаблона как справочное

Не удаляйте сразу пример оценки. Закомментируйте его и используйте как справочник по формированию:

% Пример шаблона (сохранить для справки):
% \begin{figure}[t]
%   \centering
%   \includegraphics[width=0.8\linewidth]{example-image}
%   \caption{Шаблон показывает стиль подписи}
% \end{figure}

% Ваш фактический рисунок:
\begin{figure}[t]
  \centering
  \includegraphics[width=0.8\linewidth]{your-figure.pdf}
  \caption{Ваша подпись, следующая тому же стилю.}
\end{figure}

Шаг 4: Замените требования раздела за разделом

Работайте систематически: заголовок/авторы → аннотация → введение → методы → эксперименты → сопутствующие работы → заключение → ссылки → приложение. Компилируйте после каждого раздела.

Шаг 5: Используйте макросы-шаблоны

\newcommand{\method}{YourMethodName}  % Согласованное именование метода
\newcommand{\eg}{например,\xspace}    % Правильные сокращения
\newcommand{\ie}{т.е.,\xspace}

Подводные камни-шаблоны

Подводный камень	Проблема	Решение
Копирование только файла `.tex`	Отсутствует `.sty`, не компилируется	Копите весь каталог
Изменение файлов `.sty`	Нарушает формирование конференции	Никогда не редактируйте файлы стилей
Добавление случайных пакетов	Конфликты, ломает шаблон	Добавляйте только при необходимости
Удаление шаблона рано	Потеря справочника по формированию	Сохраняйте комментарии, которые дополняются
Редкая компиляция	Ошибки накапливаются	Компилируйте после каждого раздела
Растровые PNG для рисунков	Размыто в статье	Всегда воспользуйтесь векторным PDF через `savefig('fig.pdf')`

Быстрый справочник по шаблонам

Конференция	Основной файл	Файл стиля	Лимит страниц
НейрИПС 2025	`main.tex`	`neurips.sty`	9 страниц
ICML 2026	`example_paper.tex`	`icml2026.sty`	8 страниц
ICLR 2026	`iclr2026_conference.tex`	`iclr2026_conference.sty`	9 страниц
ACL 2025	`acl_latex.tex`	`acl.sty`	8 страниц (длинные)
АААИ 2026	`aaai2026-unified-template.tex`	`aaai2026.sty`	7 страниц
КОЛМ 2025	`colm2025_conference.tex`	`colm2025_conference.sty`	9 страниц

Универсально: Двойное слепое рецензирование, ссылки не наблюдаются, приложения без ограничений, LaTeX обязателен.

Шаблоны в каталоге templates/. См. templates/README.md для компиляции (VS Code, CLI, Overleaf, другие IDE).

Таблицы и рисунки

Таблицы — викорируйте booktabs для профессионального форматирования:

\usepackage{booktabs}
\begin{tabular}{lcc}
\toprule
Метод & Точность $\uparrow$ & Задержка $\downarrow$ \\
\midrule
Базовый & 85.2 & 45ms \\
\textbf{Наш} & \textbf{92.1} & 38ms \\
\bottomrule
\end{tabular}

Правила: - Выделите жирным лучшее значение по каждой метрике. - Включайте символы направления ($\uparrow$ выше лучше, $\downarrow$ ниже лучше) - Выравнивайте числовые столбцы по правому краю. - Согласованная точность десятичных знаков

** Рисунки: - Векторная графика (PDF, EPS) для всех графиков и диаграмм — plt.savefig('fig.pdf') - Растровая (PNG 600 DPI) только для фотографий - Палитры, безопасные для дальтоников (Окабе-Ито или Пол Тол) - проверить читаемость в результатах серого (8% мужчин имеют нарушение цветового зрения) - Без заголовка внутри рисунка — эта функция обеспечивает подпись. - Самодостаточные подключения** — читатель должен понимать без основного текста

Повторная подача на конференцию MSC Group

Для конвертации между площадками см. Фазу 7 (Подготовка к подаче) — она соответствует полному рабочему процессу конвертации, таблице изменений страниц и рекомендациям после отклонений.

Профессиональная преамбула LaTeX

Добавьте эти дополнения в любую статью для профессионального качества. Они совместимы со всеми необходимыми файлами стилей конференций:

% --- Профессиональные пакеты (добавлять после файла стиля конференции) ---

% Типографика
\usepackage{microtype}              % Микротипографические улучшения (выступ, расширение)
                                     % Делает текст заметно более качественным — всегда включайте

% Таблицы
\usepackage{booktabs}               % Профессиональные правила таблиц (\toprule, \midrule, \bottomrule)
\usepackage{siunitx}                % Согласованное форматирование чисел, выравнивание десятичных знаков
                                     % Использование: \num{12345} → 12,345; \SI{3.5}{GHz} → 3.5 ГГц
                                     % Выравнивание в таблицах: тип столбца S для чисел с десятичным разделителем

% Рисунки
\usepackage{graphicx}               % Включение графики (\includegraphics)
\usepackage{subcaption}             % Подрисунки с метками (a), (b), (c)
                                     % Использование: \begin{subfigure}{0.48\textwidth}... \end{subfigure}

% Диаграммы и алгоритмы
\usepackage{tikz}                   % Программируемые векторные диаграммы
\usetikzlibrary{arrows.meta, positioning, shapes.geometric, calc, fit, backgrounds}
\usepackage[ruled,vlined]{algorithm2e}  % Профессиональный псевдокод
                                     % Альтернатива: \usepackage{algorithmicx}, если шаблон его включает

% Перекрестные ссылки
\usepackage{cleveref}               % Умные ссылки: \cref{fig:x} → "Рисунок 1"
                                     % ДОЛЖЕН быть загружен ПОСЛЕ hyperref
                                     % Обрабатывает: рисунки, таблицы, разделы, уравнения, алгоритмы

% Математика (обычно включена в.sty конференции, но проверьте)
\usepackage{amsmath,amssymb}        % AMS математические окружения и символы
\usepackage{mathtools}              % Расширяет amsmath (dcases, coloneqq и т.д.)

% Цвета (для рисунков и диаграмм)
\usepackage{xcolor}                 % Управление цветами
% Палитра Okabe-Ito, безопасная для дальтоников:
\definecolor{okblue}{HTML}{0072B2}
\definecolor{okorange}{HTML}{E69F00}
\definecolor{okgreen}{HTML}{009E73}
\definecolor{okred}{HTML}{D55E00}
\definecolor{okpurple}{HTML}{CC79A7}
\definecolor{okcyan}{HTML}{56B4E9}
\definecolor{okyellow}{HTML}{F0E442}

Примечания: - «микротипия» — этот пакет оказывает наибольшее влияние на визуальное качество. Он регулирует межсимвольные интервалы на субпиксельном уровне. Всегда включайте его. - siunitx обрабатывает спортивные десятичные знаки в таблицах через тип столбца S — используется ручное соревнование. - cleveref должен быть загружен после hyperref. Большинство файлов.sty конференции конференций загружают гиперссылку, поэтому поместите умный в последнюю очередь. - Проверьте, не загружает ли шаблон конференции уже какие-либо из этих пакетов (особенно algorithm, amsmath, graphicx). Не загружайте несколько раз.

Выравнивание таблиц с siunitx

siunitx составляет таблицы с большим количеством чисел значительно более читаемыми:

\begin{tabular}{l S[table-format=2.1] S[table-format=2.1] S[table-format=2.1]}
\toprule
Метод & {Точность $\uparrow$} & {F1 $\uparrow$} & {Задержка (мс) $\downarrow$} \\
\midrule
Базовый         & 85.2  & 83.7  & 45.3 \\
Абляция (без X) & 87.1  & 85.4  & 42.1 \\
\textbf{Наш}    & \textbf{92.1} & \textbf{90.8} & \textbf{38.7} \\
\bottomrule
\end{tabular}

Тип столбца S автоматически перемещается по десятичной точке. Заголовки на экране {} способствуют победе.

Подрисунки

Стандартный шаблон для рисунков рядом:

\begin{figure}[t]
  \centering
  \begin{subfigure}[b]{0.48\textwidth}
    \centering
    \includegraphics[width=\textwidth]{fig_results_a.pdf}
    \caption{Результаты на наборе данных A.}
    \label{fig:results-a}
  \end{subfigure}
  \hfill
  \begin{subfigure}[b]{0.48\textwidth}
    \centering
    \includegraphics[width=\textwidth]{fig_results_b.pdf}
    \caption{Результаты на наборе данных B.}
    \label{fig:results-b}
  \end{subfigure}
  \caption{Сравнение нашего метода на двух наборах данных. (a) показывает поведение
  масштабирования, а (b) показывает результаты абляции. Оба используют 5 случайных сидов.}
  \label{fig:results}
\end{figure}

Используйте \cref{fig:results} → «Рисунок 1», \cref{fig:results-a} → «Рисунок 1a».

Псевдокод с алгоритмом2e

\begin{algorithm}[t]
\caption{Итеративное уточнение с панелью судей}
\label{alg:method}
\KwIn{Задача $T$, модель $M$, судьи $J_1 \ldots J_n$, порог сходимости $k$}
\KwOut{Финальный вывод $A^*$}
$A \gets M(T)$ \tcp*{Начальная генерация}
$\text{streak} \gets 0$\;
\While{$\text{streak} < k$}{
  $C \gets \text{Критик}(A, T)$ \tcp*{Выявить слабые места}
  $B \gets M(T, C)$ \tcp*{Пересмотренная версия, учитывающая критику}
  $AB \gets \text{Синтезировать}(A, B)$ \tcp*{Объединить лучшие элементы}
  \ForEach{судья $J_i$}{
    $\text{rank}_i \gets J_i(\text{перемешать}(A, B, AB))$ \tcp*{Слепое ранжирование}
  }
  $\text{победитель} \gets \text{BordaCount}(\text{ранги})$\;
  \eIf{$\text{победитель} = A$}{
    $\text{streak} \gets \text{streak} + 1$\;
  }{
    $A \gets \text{победитель}$; $\text{streak} \gets 0$\;
  }
}
\Return{$A$}\;
\end{algorithm}

Шаблоны диаграмм TikZ

TikZ — это стандарт для диаграммных методов в ML-статьях. Распространенные шаблоны:

Схема конвейера/потока (самая распространенная в ML-статьях):

\begin{figure}[t]
\centering
\begin{tikzpicture}[
  node distance=1.8cm,
  box/.style={rectangle, draw, rounded corners, minimum height=1cm, 
              minimum width=2cm, align=center, font=\small},
  arrow/.style={-{Stealth[length=3mm]}, thick},
]
  \node[box, fill=okcyan!20] (input) {Вход\\$x$};
  \node[box, fill=okblue!20, right of=input] (encoder) {Кодировщик\\$f_\theta$};
  \node[box, fill=okgreen!20, right of=encoder] (latent) {Скрытое\\$z$};
  \node[box, fill=okorange!20, right of=latent] (decoder) {Декодировщик\\$g_\phi$};
  \node[box, fill=okred!20, right of=decoder] (output) {Выход\\$\hat{x}$};

  \draw[arrow] (input) -- (encoder);
  \draw[arrow] (encoder) -- (latent);
  \draw[arrow] (latent) -- (decoder);
  \draw[arrow] (decoder) -- (output);
\end{tikzpicture}
\caption{Обзор архитектуры. Кодировщик отображает вход $x$ в скрытое представление 
$z$, которое декодировщик восстанавливает.}
\label{fig:architecture}
\end{figure}

Диаграмма сравнения/матрицы (для показа вариантов метода):

\begin{tikzpicture}[
  cell/.style={rectangle, draw, minimum width=2.5cm, minimum height=1cm, 
               align=center, font=\small},
  header/.style={cell, fill=gray!20, font=\small\bfseries},
]
  % Заголовки
  \node[header] at (0, 0) {Метод};
  \node[header] at (3, 0) {Сходится?};
  \node[header] at (6, 0) {Качество?};
  % Строки
  \node[cell] at (0, -1) {Single Pass};
  \node[cell, fill=okgreen!15] at (3, -1) {Н/Д};
  \node[cell, fill=okorange!15] at (6, -1) {Базовый};
  \node[cell] at (0, -2) {Critique+Revise};
  \node[cell, fill=okred!15] at (3, -2) {Нет};
  \node[cell, fill=okred!15] at (6, -2) {Деградирует};
  \node[cell] at (0, -3) {Наш};
  \node[cell, fill=okgreen!15] at (3, -3) {Да ($k$=2)};
  \node[cell, fill=okgreen!15] at (6, -3) {Улучшает};
\end{tikzpicture}

Диаграмма итеративного цикла (для методов с обратной связью):

\begin{tikzpicture}[
  node distance=2cm,
  box/.style={rectangle, draw, rounded corners, minimum height=0.8cm, 
              minimum width=1.8cm, align=center, font=\small},
  arrow/.style={-{Stealth[length=3mm]}, thick},
  label/.style={font=\scriptsize, midway, above},
]
  \node[box, fill=okblue!20] (gen) {Генератор};
  \node[box, fill=okred!20, right=2.5cm of gen] (critic) {Критик};
  \node[box, fill=okgreen!20, below=1.5cm of $(gen)!0.5!(critic)$] (judge) {Панель судей};

  \draw[arrow] (gen) -- node[label] {выход $A$} (critic);
  \draw[arrow] (critic) -- node[label, right] {критика $C$} (judge);
  \draw[arrow] (judge) -| node[label, left, pos=0.3] {победитель} (gen);
\end{tikzpicture}

latexdiff для идентификации изменений

Необходимые условия для подачи заявления — последовательно PDF с разметкой, показывающей изменения между версиями:

# Установка
# macOS: brew install latexdiff (или идет с TeX Live)
# Linux: sudo apt install latexdiff

# Генерация diff
latexdiff paper_v1.tex paper_v2.tex > paper_diff.tex
pdflatex paper_diff.tex

# Для многофайловых проектов (с \input{} или \include{})
latexdiff --flatten paper_v1.tex paper_v2.tex > paper_diff.tex

Это создает PDF-файл с удалением красных зачеркнутых и добавлением синим — стандартный формат для приложений к приложениям.

SciencePlots для matplotlib

Установите и воспользуйтесь графиками публикационного качества:

pip install SciencePlots

import matplotlib.pyplot as plt
import scienceplots  # регистрирует стили

# Использовать стиль science (похож на IEEE, чистый)
with plt.style.context(['science', 'no-latex']):
    fig, ax = plt.subplots(figsize=(3.5, 2.5))  # Ширина одной колонки
    ax.plot(x, y, label='Наш', color='#0072B2')
    ax.plot(x, y2, label='Базовый', color='#D55E00', linestyle='--')
    ax.set_xlabel('Шаги обучения')
    ax.set_ylabel('Точность')
    ax.legend()
    fig.savefig('paper/fig_results.pdf', bbox_inches='tight')

# Доступные стили: 'science', 'ieee', 'nature', 'science+ieee'
# Добавьте 'no-latex', если LaTeX не установлен на машине, генерирующей графики

Стандартные размеры рисунков (двухколоночный формат): - Одна колонка: figsize=(3.5, 2.5) — помещается в одну колонку - Две колонки: figsize=(7.0, 3.0) — выполняет обе колонки - Квадратный: figsize=(3.5, 3.5) — для тепловых карт, матриц ошибок

Фаза 6: Саморецензирование и доработка

Цель: Имитировать процесс рецензирования дотации. Выявить слабые места заранее.

Шаг 6.1: Имитация рецензий (ансамблевый узор)

Создайте рецензии с несколькими точками зрения. Ключевое понимание алгоритмических исследовательских конвейеров (особенно AI-Scientist от SakanaAI): ансамблевое рецензирование с мета-рецензированием дает гораздо более калиброванную беспроводную связь, чем однопроходное рецензирование.

Шаг 1: Сгенерируйте N независимых рецензий (N=3–5)

Используйте разные модели или настраивайте температуру. Каждый рецензент видит только статью, а не другие рецензии. По умолчанию отрицательный уклон — LLM имеет хорошо документированную склонность к позитиву в оценке.

Вы — эксперт-рецензент для [ПЛОЩАДКА]. Вы критичны и дотошны.
Если у статьи есть слабые места или вы не уверены в утверждении, четко
отметьте это и отразите в своих оценках. Не давайте преимущества сомнения.

Проверьте эту статью в соответствии с официальными рекомендациями рецензента. Оцените:

1. Обоснованность (хорошо ли подтверждены утверждения? справедливы ли и сильны ли базовые методы?)
2. Ясность (хорошо ли написана статья? сможет ли эксперт ее воспроизвести?)
3. Значимость (важно ли это для сообщества?)
4. Оригинальность (новые идеи, а не просто инкрементальная комбинация?)

Предоставьте свою рецензию в виде структурированного JSON:
{
  "summary": "резюме из 2-3 предложений",
  "strengths": ["сильная сторона 1", "сильная сторона 2",...],
  "weaknesses": ["слабость 1 (самая критичная)", "слабость 2",...],
  "questions": ["вопрос к авторам 1",...],
  "missing_references": ["статья, которую следует процитировать",...],
  "soundness": 1-4,
  "presentation": 1-4,
  "contribution": 1-4,
  "overall": 1-10,
  "confidence": 1-5
}

Шаг 2: Мета-рецензия (агрегация головного отделения)

Подайте все N рецензий по мета-рецензии:

Вы — председатель секции на [ПЛОЩАДКА]. Вы получили [N] независимых рецензий
на статью. Ваша задача:

1. Определить консенсусные сильные и слабые стороны среди рецензентов
2. Разрешить разногласия, изучив статью напрямую
3. Создать мета-рецензию, представляющую совокупное суждение
4. Использовать УСРЕДНЕННЫЕ числовые оценки по всем рецензиям

Будьте консервативны: если рецензенты расходятся во мнении, является ли слабость
серьезной, считайте ее серьезной, пока авторы не устранят ее.

Рецензии:
[review_1]
[review_2]...

Шаг 3: Цикл рефлексии (опционально, 2-3 раунда)

Каждый рецензент может уточнить свою рецензию после просмотра мета-рецензии. Используйте сторожевой сигнал раньше времени: если рецензент отвечает «Я закончил» (без изменений), остановите итерацию.

Выбор модели для рецензирования: Рецензирование лучше всего выполнять с самой независимой доступной моделью, даже если вы написали статью с более дешевой. Модель-рецензент должна выбираться независимо от модели-писателя.

Калибровка с несколькими примерами: Если доступно, 1-2 опубликованных рецензии на горную площадку в качестве примера. Это значительно увеличивает калибровку оценок. См. references/reviewer-guidelines.md для примера рецензий.

Шаг 6.1b: Визуальный проход рецензирования (VLM)

Текстовое рецензирование пропускает целый класс проблем: качество рисунков, проблемы верстки, визуальная согласованность. Если у вас есть доступ к моделям с удобствами, отключите отдельное визуальное рецензирование скомпилированного PDF:

Вы проверяете визуальное представление этого PDF исследовательской статьи.
Проверьте:
1. Качество рисунков: Читаемы ли графики? Разборчивы ли подписи? Различимы ли цвета?
2. Соответствие рисунка и подписи: Описывает ли каждая подпись свой рисунок точно?
3. Проблемы верстки: Сиротские заголовки разделов, неудобные разрывы страниц, рисунки далеко от ссылок на них
4. Форматирование таблиц: Выровненные столбцы, согласованная точность десятичных знаков, жирный шрифт для лучших результатов
5. Визуальная согласованность: Одинаковая цветовая схема на всех рисунках, согласованные размеры шрифтов
6. Читаемость в оттенках серого: Были бы рисунки понятны при печати в черно-белом?

Для каждой проблемы укажите номер страницы и точное местоположение.

Это выявляет проблемы, которые не могут объяснить текстовое рецензирование: график с нечитаемыми подписями Осей, рисунок, представленный через 3 страницы из первых ссылок на него, несогласованные цветовые палитры между Рисунком 2 и Рисунком 5, или таблица, явно шире колонки.

Шаг 6.1c: Проход проверки утверждений

После имитации рецензий запустите все проверки проходов. Это приводит к фактическим ошибкам, которые рецензенты могут пропустить:

Протокол проверки утверждений:
1. Извлеките каждое фактическое утверждение из статьи (числа, сравнения, тенденции)
2. Для каждого утверждения проследите его до конкретного эксперимента/результата, который его поддерживает
3. Проверьте, что число в статье соответствует фактическому файлу результата
4. Отметьте любое утверждение без отслеживаемого источника как [VERIFY]

Для агентских рабочих процессов: делегируйте проверку свежему подагенту, который получает только текстовые статьи и сырые результаты результатов. Свежий контекст предвзятость подтверждения — проверяющий не «помнит», какими должны быть результаты.

Шаг 6.2: Приоритизация обратной связи

После сбора рецензий классифицируйте:

Приоритет	Действие
Критический (технический недостаток, отсутствующий базовый метод)	Должен быть исправлен. Может быть произведено новые эксперименты → возврат к Фазе 2
Высокий (проблема ясности, отсутствующая абляция)	Следует исправить эту доработку
Средний (незначительные проблемы с написанием, дополнительные эксперименты)	Исправить, если позволяет время
Низкий (стилистические предпочтения, дополнительные предложения)	Отметить на будущую работу

Шаг 6.3: Цикл доработки

Для каждой критической/высокой проблемы: 1. Определите конкретный(е) раздел(ы), который касается 2. Сделать черновик исправления 3. Проверьте, что исправления не нарушают другие положения. 4. Обновите статью 5. Проверьте соответствие замечаний рецензента.

Шаг 6.4: Написание апелляций

При ответе на реальные рецензии (после подачи) апелляции — это отдельный навык от доработки:

Формат: По пунктам. Для каждого замечания рецензента:

> R1-W1: «В статье не хватает сравнения с методом X.»

Мы благодарим рецензента за это предложение. Мы добавили сравнение с 
методом X в Таблицу 3 (исправлено). Наш метод превосходит X на 3.2 п.п. по [метрике] 
(p<0.05). Отметим, что X требует в 2 раза больше нашего вычислительного бюджета.

Правила: - Ответьте на каждое замечание — рецензенты замечают, если вы пропустили одно - Начинайте с самых сильных ответов - Будьте кратки и прямые — рецензенты читают десять обращений - Включайте новые результаты, если вы проводите эксперименты в период апелляции. - Никогда не будьте осторожны оборонительные или пренебрежительные, даже к слабой критике. - Используйте latexdiff для создания PDF с разметкой, вызывающей изменения (см. раздел Профессиональные инструменты LaTeX) - Благодарите рецензентов за конкретную, действующую обратную связь (без рекомендации).

Чего НЕ делать: «Мы с уважением не согласны» без доказательств. «Это выходит за рамки» без объяснений. Игнорирование слабости, ответ только на сильную сторону.

Шаг 6.5: Отслеживание эволюции статей

Сохраняйте характеристики основных компонентов:

paper/
  paper.tex                    # Текущая рабочая версия
  paper_v1_first_draft.tex     # Первый полный черновик
  paper_v2_post_review.tex     # После имитации рецензирования
  paper_v3_pre_submission.tex  # Финальная перед подачей
  paper_v4_camera_ready.tex    # Финальная после принятия

Фаза 7: Подготовка к подаче

Цель: Финальные проверки, оформление и подача.

Шаг 7.1: Контрольный список конференции

На каждой площадке есть обязательные контрольные механизмы. Заполните их внимательно — неполные контрольные мероприятия могут привести к отклонениям без рецензирования.

См. references/checklists.md для: - Контрольный список статей NeurIPS из 16 пунктов - ICML более широкое влияние + воспроизводимость - Политика раскрытия LLM ICLR - Обязательный раздел блокировки ACL - Универсальный предпочитаемый контрольный список.

Шаг 7.2: Контрольный список анонимизации

Двойное слепое рецензирование означает, что рецензенты не могут знать, кто написал статью. проверить ВСЕ это:

Контрольный список анонимизации:
- [ ] Нет имен авторов или принадлежностей где-либо в PDF
- [ ] Нет раздела благодарностей (добавить после принятия)
- [ ] Самоцитирования в третьем лице: «Смит и др. [1] показали...», а не «Мы ранее показали [1]...»
- [ ] Нет URL GitHub/GitLab, указывающих на ваши личные репозитории
- [ ] Используйте Anonymous GitHub (https://anonymous.4open.science/) для ссылок на код
- [ ] Нет логотипов учреждений или идентификаторов на рисунках
- [ ] Нет метаданных файла, содержащих имена авторов (проверьте свойства PDF)
- [ ] Нет формулировок «наша предыдущая работа» или «в нашей более ранней статье»
- [ ] Названия наборов данных не раскрывают учреждение (переименуйте при необходимости)
- [ ] Дополнительные материалы не содержат идентифицирующей информации

Распространенные ошибки: Сообщения git-коммитов, встречающиеся в дополнительном коде, водяные знаки на рисунках институциональных инструментов, оставленные благодарности из заявления черновика, препринт arXiv, опубликованный до периода анонимности.

Шаг 7.3: Проверка формирования

Предподачная проверка формата:
- [ ] Соблюден лимит страниц (исключая ссылки и приложение)
- [ ] Все рисунки векторные (PDF) или высокого разрешения (600 DPI PNG)
- [ ] Все рисунки читаемы в оттенках серого
- [ ] Все таблицы используют booktabs
- [ ] Ссылки компилируются правильно (нет «?» в цитированиях)
- [ ] Нет overfull hbox в критических областях
- [ ] Приложение четко обозначено и отделено
- [ ] Обязательные разделы присутствуют (ограничения, более широкое влияние и т.д.)

Шаг 7.4: Предкомпиляционная валидация

Запустите эти автоматические проверки до попытки pdflatex. Выявление ошибок здесь быстрее, чем отладка вывода компилятора.

# 1. Линтинг с chktex (выявляет распространенные ошибки LaTeX)
# Подавить шумные предупреждения: -n2 (конец предложения), -n24 (скобки), -n13 (между предложениями), -n1 (команда завершена)
chktex main.tex -q -n2 -n24 -n13 -n1

# 2. Проверить, что все цитирования существуют в.bib
# Извлечь \cite{...} из.tex, проверить каждое по.bib
python3 -c "
import re
tex = open('main.tex').read()
bib = open('references.bib').read()
cites = set(re.findall(r'\\\\cite[tp]?{([^}]+)}', tex))
for cite_group in cites:
    for cite in cite_group.split(','):
        cite = cite.strip()
        if cite and cite not in bib:
            print(f'ПРЕДУПРЕЖДЕНИЕ: \\\\cite{{{cite}}} не найдено в references.bib')
"

# 3. Проверить, что все упомянутые рисунки существуют на диске
python3 -c "
import re, os
tex = open('main.tex').read()
figs = re.findall(r'\\\\includegraphics(?:\[.*?\])?{([^}]+)}', tex)
for fig in figs:
    if not os.path.exists(fig):
        print(f'ПРЕДУПРЕЖДЕНИЕ: Файл рисунка не найден: {fig}')
"

# 4. Проверить на дублирующиеся определения \label
python3 -c "
import re
from collections import Counter
tex = open('main.tex').read()
labels = re.findall(r'\\\\label{([^}]+)}', tex)
dupes = {k: v for k, v in Counter(labels).items() if v > 1}
for label, count in dupes.items():
    print(f'ПРЕДУПРЕЖДЕНИЕ: Дублирующаяся метка: {label} (появляется {count} раз)')
"

Исправьте любые замечания перед продолжением. Для агентских рабочих процессов: передайте вывод chktex обратно агенту с рекомендациями по минимальным исправлениям.

Шаг 7.5: Финальная компиляция

# Чистая сборка
rm -f *.aux *.bbl *.blg *.log *.out *.pdf
latexmk -pdf main.tex

# Или вручную (тройной pdflatex + bibtex для перекрестных ссылок)
pdflatex -interaction=nonstopmode main.tex
bibtex main
pdflatex -interaction=nonstopmode main.tex
pdflatex -interaction=nonstopmode main.tex

# Проверить, что вывод существует и имеет содержимое
ls -la main.pdf

Если компиляция не удалась: Проанализируйте файл .log на предмет первой ошибки. Распространенные исправления: - «Неопределенная последовательность управления» → отсутствующий пакет или опечатка в имени команды - «Вставлен недостающий $» → математический символ вне математического режима - «Файл не найден» → неправильный путь к рисунку или отсутствующий.sty файл - «Цитирование не определено» → запись.bib отсутствует или bibtex не запущен

Шаг 7.6: Особые требования конференции

Площадка	Особые требования
НейриПС	Контрольный список статей в приложении, краткое описание для внешних публикаций в случае принятия
ИКМЛ	Заявление о более широком влиянии (после заключения не наблюдается в лимите)
ИКЛР	Требуется раскрытие LLM, соглашения о взаимном рецензировании
ACL	Обязательный раздел ограничений, контрольный список Ответственный НЛП
АААИ	Строгий файл стиля — никаких модификаций
КОЛМ	Формулировка вклада для сообщества языковых моделей

Шаг 7.7: Повторная подача на конференцию MSC и формирование конверта

При конвертации между площадками никогда не копируйте преамбулы LaTeX между шаблонами:

# 1. Начните с чистого шаблона целевой площадки
cp -r templates/icml2026/ new_submission/

# 2. Скопируйте ТОЛЬКО разделы содержимого (не преамбулу)
#    - Текст аннотации, содержимое разделов, рисунки, таблицы, записи bib

# 3. Скорректируйте под лимиты страниц
# 4. Добавьте обязательные разделы для конкретной площадки
# 5. Обновите ссылки

От → К	Изменение страниц	Ключевые корректировки
НейрИПС → ICML	9 → 8	Сократить 1 страницу, добавить Более широкое воздействие
ICML → ICLR	8 → 9	Расширить эксперименты, дополнительно раскрыть LLM
НейрИПС → ACL	9 → 8	Перестроить соглашения NLP, добавить ограничения
ICLR → АААИ	9 → 7	проявляются строго, строгое соблюдение стиля
Любая → КОЛМ	разное → 9	Переформулировать для фокуса на языковых моделях

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

После отклонения: Учтите замечания рецензентов в новой версии, но не включите раздел «изменения» и не ссылайтесь на предыдущую подачу (слепое рецензирование).

Шаг 7.8: Подготовка камеры к работе (после принятия)

После принятия подготовьте версию для камеры:

Контрольный список Camera-Ready:
- [ ] Деанонимизация: добавьте имена авторов, принадлежности, адреса электронной почты
- [ ] Добавьте раздел благодарностей (финансирование, гранты на вычисления, полезные рецензии)
- [ ] Добавьте публичный URL кода/данных (настоящий GitHub, не анонимный)
- [ ] Устраните любые обязательные доработки от мета-рецензента
- [ ] Переключите шаблон в режим camera-ready (если применимо — например, AAAI \anon → \camera)
- [ ] Добавьте уведомление об авторских правах, если требуется площадкой
- [ ] Обновите все заполнители «анонимно» в тексте
- [ ] Проверьте, что финальный PDF чисто компилируется
- [ ] Проверьте лимит страниц для camera-ready (иногда отличается от подачи)
- [ ] Загрузите дополнительные материалы (код, данные, приложение) на портал площадки

Шаг 7.9: Стратегия arXiv и препринтов

Публикация на arXiv — стандартная практика в ОД, но соблюдается осторожность во времени и анонимности.

Дерево решения по времени:

Ситуация	Рекомендация
Подача на площадку со слепым рецензированием (NeurIPS, ICML, ACL)	Публикуйте на arXiv после дедушки онлайн-предложения, а не делайте этого. Публикация может технически нарушить анонимность, хотя правоприменение существенно ухудшается.
Подача на ICLR	ICLR явно разрешает публикацию материалов arXiv. Но не указывайте имена авторов в самой подаче.
Статья уже на arXiv, подача на новую площадку	Приемлемо на большинстве площадок. НЕ обновляйте версию arXiv во время рецензирования изменений, которые ссылаются на рецензии.
Семинарская статья	arXiv подходит в любое время — семинары обычно не проводятся слепым рецензированием.
Хотите установить приоритет	Если есть опасения по поводу операций, немедленно опубликуйте, но примите компромисс анонимно.

Выбор категории arXiv (статьи ML/AI):

Категория	Код	Лучше всего для
Машинное обучение	`cs.LG`	Общие методы ML
Вычисления и язык	`cs.CL`	НЛП, языковые модели
Искусственный интеллект	`cs.AI`	Рассуждение, планирование, агенты
Компьютерное зрение	`cs.CV`	Модели рассмотрения
Информационный поиск	`cs.IR`	Поиск, рекомендации

Укажите основные + 1-2 перекрестные категории. Больше категорий = более значимые, но перекрестно указывайте только там, где это действительно релевантно.

Стратегия версионирования: - v1: Первоначальная подача (соответствует подаче на конференцию MSC Group) - v2: После принятия с исправлениями камера готова (добавьте «принято на [Площадка]» в аннотации) - Не публикуйте v2 в период рецензирования с изменениями, которые явно требуют отзывов рецензентов.

# Проверьте, не занят ли заголовок вашей статьи на arXiv
# (до выбора заголовка)
pip install arxiv
python -c "
import arxiv
results = list(arxiv.Search(query='ti:\"Ваш Точный Заголовок\"', max_results=5).results())
print(f'Найдено {len(results)} совпадений')
for r in results: print(f'  {r.title} ({r.published.year})')
"

Шаг 7.10: Упаковка исследовательского кода

Выпуск чистого, работоспособного кода значительно увеличивает цитирование и надежность рецензентов. Упакуйте код вместе с подарком, готовым для камеры.

Структура репозитория:

your-method/
  README.md              # Установка, использование, инструкции по воспроизведению
  requirements.txt       # Или environment.yml для conda
  setup.py               # Для pip-устанавливаемых пакетов
  LICENSE                # Рекомендуется MIT или Apache 2.0 для исследований
  configs/               # Конфигурации экспериментов
  src/                   # Реализация основного метода
  scripts/               # Скрипты обучения, оценки, анализа
    train.py
    evaluate.py
    reproduce_table1.sh  # Один скрипт на основной результат
  data/                  # Небольшие данные или скрипты загрузки
    download_data.sh
  results/               # Ожидаемые выходы для проверки

Шаблон README для исследовательского кода:

# [Заголовок статьи]

Официальная реализация «[Заголовок статьи]» (Площадка Год).

## Установка
[Точные команды для настройки окружения]

## Воспроизведение
Для воспроизведения Таблицы 1: `bash scripts/reproduce_table1.sh`
Для воспроизведения Рисунка 2: `python scripts/make_figure2.py`

## Цитирование
[Запись BibTeX]

Предрелизный контрольный список:

- [ ] Код запускается из чистой копии (протестируйте на свежей машине или Docker)
- [ ] Все зависимости закреплены за конкретными версиями
- [ ] Нет жестко закодированных абсолютных путей
- [ ] Нет API-ключей, учетных данных или личных данных в репозитории
- [ ] README охватывает установку, воспроизведение и цитирование
- [ ] Файл LICENSE присутствует (MIT или Apache 2.0 для максимального повторного использования)
- [ ] Результаты воспроизводимы в пределах ожидаемой дисперсии
- [ ].gitignore исключает файлы данных, контрольные точки, логи

Анонимный код для подачи (до принятия):

# Используйте Anonymous GitHub для двойного слепого рецензирования
# https://anonymous.4open.science/
# Загрузите ваш репозиторий → получите анонимный URL → укажите в статье

Фаза 8: Материалы после принятия

Цель: Максимизировать влияние принятой статьи с помощью презентационных материалов и взаимодействия с сообществом.

Шаг 8.1: Постер конференции

Большинство конференций требуют постерной сессии. Принципы дизайна постера:

Элемент	Рекомендация
Размер	Проверьте требования площадки (обычно 24"x36" или A0 портрет/ландшафт)
Содержание	Заголовок, авторы, вклад в 1 предложение, рисунок метода, 2-3 ключевых результата, заключение
Поток	Слева направо сверху вниз (Z-образный паттерн) или колонками
Текст	Заголовок читаем с 3 м, тело с 1 м. Никаких полных абзацев — только маркированные списки.
Рисунки	Используйте рисунки из статьи с более высоким разрешением. Увеличьте ключевой результат.

Инструменты: LaTeX (пакет beamerposter), PowerPoint/Keynote, Figma, Canva.

Производство: Заказывайте за 2+ недели до конференции. Тканевые постеры легче для путешествий. Многие конференции теперь поддерживают также виртуальные/цифровые постеры.

Шаг 8.2: Доклад на конференции / Spotlight

Если удостоены устного или spotlight доклада:

Тип доклада	Длительность	Содержание
Spotlight	5 мин	Проблема, подход, один ключевой результат. Репетируйте ровно до 5 минут.
Устный	15-20 мин	Полная история: проблема, подход, ключевые результаты, абляции, ограничения.
Семинарский доклад	10-15 мин	Адаптируйте под аудиторию семинара — может потребоваться больше контекста.

Правила дизайна слайдов: - Одна идея на слайд - Минимум текста — говорите детали, не проецируйте их - Анимируйте ключевые рисунки для пошагового понимания - Включите слайд «вывод» в конце (вклад в одно предложение) - Подготовьте запасные слайды для ожидаемых вопросов

Шаг 8.3: Пост в блоге / Социальные сети

Доступное резюме значительно увеличивает влияние:

Тред в Twitter/X: 5-8 твитов. Начинайте с результата, а не с метода. Включите Рисунок 1 и рисунок ключевого результата.
Пост в блоге: 800-1500 слов. Написан для практикующих ML, не для рецензентов. Пропустите формализм, сделайте акцент на интуиции и практических последствиях.
Страница проекта: HTML-страница с аннотацией, рисунками, демо, ссылкой на код, BibTeX. Используйте GitHub Pages.

Время: Публикуйте в течение 1-2 дней после появления статьи в материалах конференции или arXiv camera-ready.

Семинарские и короткие статьи

Семинарские статьи и короткие статьи (например, короткие статьи ACL, статьи Findings) следуют тому же конвейеру, но с другими ограничениями и ожиданиями.

Семинарские статьи

Свойство	Семинар	Основная конференция
Лимит страниц	4-6 страниц (обычно)	7-9 страниц
Стандарт рецензирования	Ниже планка полноты	Должна быть полной, тщательной
Процесс рецензирования	Обычно одностороннее слепое или легкое рецензирование	Двойное слепое, строгое
Что ценится	Интересные идеи, предварительные результаты, позиционные материалы	Полная эмпирическая история с сильными базовыми методами
arXiv	Публикуйте в любое время	Время имеет значение (см. стратегию arXiv)
Планка вклада	Новое направление, интересный отрицательный результат, работа в процессе	Значительный прогресс с сильными доказательствами

Когда ориентироваться на семинар: - Идея на ранней стадии, по которой вы хотите получить обратную связь до полноценной статьи - Отрицательный результат, который не оправдывает 8+ страниц - Позиционная статья или мнение по актуальной теме - Репликационное исследование или отчет о воспроизводимости

Короткие статьи ACL и Findings

Площадки ACL имеют различные типы подач:

Тип	Страницы	Что ожидается
Длинная статья	8	Полное исследование, сильные базовые методы, абляции
Короткая статья	4	Сфокусированный вклад: одна четкая точка с доказательствами
Findings	8	Солидная работа, которая немного не дотянула до основной конференции

Стратегия короткой статьи: Выберите ОДНО утверждение и тщательно его подтвердите. Не пытайтесь сжать длинную статью в 4 страницы — напишите другую, более сфокусированную статью.

Типы статей за пределами эмпирического ML

Основной конвейер выше нацелен на эмпирические ML-статьи. Другие типы статей требуют разных структур и стандартов доказательств. См. references/paper-types.md для подробных рекомендаций по каждому типу.

Теоретические статьи

Структура: Введение → Предварительные сведения (определения, обозначения) → Основные результаты (теоремы) → Наброски доказательств → Обсуждение → Полные доказательства (приложение)

Ключевые отличия от эмпирических статей: - Вклад — это теорема, граница или результат о невозможности — не экспериментальные числа - Раздел методов заменен на «Предварительные сведения» и «Основные результаты» - Доказательства — это доказательства, а не эксперименты (хотя эмпирическая валидация теории приветствуется) - Наброски доказательств в основном тексте, полные доказательства в приложении — стандартная практика - Раздел экспериментов опционален, но укрепляет статью, если подтверждает теоретические предсказания

Принципы написания доказательств: - Формулируйте теоремы формально со всеми явными предположениями - Давайте интуицию перед формальным доказательством («Ключевое понимание заключается в...») - Наброски доказательств должны передавать основную идею на 0.5-1 странице - Используйте окружения \begin{proof}...\end{proof} - Нумеруйте предположения и ссылайтесь на них в теоремах: «При предположениях 1-3,...»

Обзорные / Учебные статьи

Структура: Введение → Таксономия / Организация → Детальное освещение → Открытые проблемы → Заключение

Ключевые отличия: - Вклад — это организация, синтез и выявление открытых проблем — не новые методы - Должны быть всеобъемлющими в рамках области (рецензенты проверят на пропущенные ссылки) - Требуется четкая таксономия или организационная структура - Ценность проистекает из связей между работами, которые отдельные статьи не устанавливают - Лучшие площадки: TMLR (трек обзоров), JMLR, Foundations and Trends in ML, ACM Computing Surveys

Статьи-бенчмарки

Структура: Введение → Определение задачи → Построение набора данных → Базовая оценка → Анализ → Предполагаемое использование и ограничения

Ключевые отличия: - Вклад — это сам бенчмарк — он должен заполнять реальный пробел в оценке - Документация набора данных обязательна, а не опциональна (см. Паспорта данных, Шаг 5.11) - Должен демонстрировать, что бенчмарк сложен (базовые методы не насыщают его) - Должен демонстрировать, что бенчмарк измеряет то, что вы утверждаете (конструктная валидность) - Лучшие площадки: трек NeurIPS Datasets & Benchmarks, ACL (ресурсные статьи), LREC-COLING

Позиционные статьи

Структура: Введение → Предыстория → Тезис / Аргумент → Подтверждающие доказательства → Контраргументы → Последствия

Ключевые отличия: - Вклад — это аргумент, а не результат - Должны серьезно рассматривать контраргументы - Доказательства могут быть эмпирическими, теоретическими или логическим анализом - Лучшие площадки: ICML (трек позиционных статей), семинары, TMLR

Интеграция с агентом Hermes

Этот навык разработан для агента Hermes. Он использует инструменты Hermes, делегирование, планирование и память для полного жизненного цикла исследования.

Связанные навыки

Комбинируйте этот навык с другими навыками Hermes для конкретных фаз:

Навык	Когда использовать	Как загрузить
arxiv	Фаза 1 (Обзор литературы): поиск на arXiv, генерация BibTeX, поиск связанных статей через Semantic Scholar	`skill_view("arxiv")`
subagent-driven-development	Фаза 5 (Написание черновика): параллельное написание разделов с двухэтапным рецензированием (соответствие спецификации, затем качество)	`skill_view("subagent-driven-development")`
plan	Фаза 0 (Настройка): создание структурированных планов перед выполнением. Записывает в `.hermes/plans/`	`skill_view("plan")`
qmd	Фаза 1 (Литература): поиск в локальных базах знаний (заметки, стенограммы, документы) через гибридный поиск BM25+векторный	Установка: `skill_manage("install", "qmd")`
diagramming	Фаза 4-5: создание рисунков и архитектурных диаграмм на основе Excalidraw	`skill_view("diagramming")`
data-science	Фаза 4 (Анализ): Jupyter live kernel для интерактивного анализа и визуализации	`skill_view("data-science")`

Этот навык заменяет ml-paper-writing — он содержит все содержимое ml-paper-writing плюс полный конвейер экспериментов/анализа и методологию autoreason.

Справочник по инструментам Hermes

Инструмент	Использование в этом конвейере
`terminal`	Компиляция LaTeX (`latexmk -pdf`), операции git, запуск экспериментов (`nohup python run.py &`), проверки процессов
`process`	Управление фоновыми экспериментами: `process("start",...)`, `process("poll", pid)`, `process("log", pid)`, `process("kill", pid)`
`execute_code`	Запуск Python для проверки цитирований, статистического анализа, агрегации данных. Имеет доступ к инструментам через RPC.
`read_file` / `write_file` / `patch`	Редактирование статей, скриптов экспериментов, файлов результатов. Используйте `patch` для целевых правок в больших.tex файлах.
`web_search`	Поиск литературы: `web_search("transformer attention mechanism 2024")`
`web_extract`	Получение содержимого статей, проверка цитирований: `web_extract("https://arxiv.org/abs/2303.17651")`
`delegate_task`	Параллельное написание разделов — порождайте изолированных под-агентов для каждого раздела. Также для одновременной проверки цитирований.
`todo`	Основной трекер состояния между сеансами. Обновляйте после каждого перехода фазы.
`memory`	Сохраняйте ключевые решения между сеансами: формулировка вклада, выбор площадки, отзывы рецензентов.
`cronjob`	Планирование мониторинга экспериментов, обратного отсчета дедлайнов, автоматических проверок arXiv.
`clarify`	Задавайте пользователю целенаправленные вопросы, когда застряли (выбор площадки, формулировка вклада).
`send_message`	Уведомляйте пользователя, когда эксперименты завершены или черновики готовы, даже если пользователь не в чате.

Паттерны использования инструментов

Мониторинг экспериментов (самый распространенный):

terminal("ps aux | grep <pattern>")
→ terminal("tail -30 <logfile>")
→ terminal("ls results/")
→ execute_code("анализ результатов JSON, вычисление метрик")
→ terminal("git add -A && git commit -m '<описательное сообщение>' && git push")
→ send_message("Эксперимент завершен: <резюме>")

Параллельное описание разделов (с использованием делегирования):

delegate_task("Напишите раздел Методы на основе этих скриптов экспериментов и конфигов. 
  Включите: псевдокод, все гиперпараметры, архитектурные детали, достаточные для 
  воспроизведения. Пишите в LaTeX, используя соглашения шаблона neurips2025.")

delegate_task("Напишите раздел Связанные работы. Используйте web_search и web_extract для 
  поиска статей. Проверьте каждое цитирование через Semantic Scholar. Группируйте по методологии.")

delegate_task("Напишите раздел Эксперименты. Прочитайте все файлы результатов в results/. 
  Укажите, какое утверждение поддерживает каждый эксперимент. Включите планки погрешностей и значимость.")

Каждый гат запускается как свежий подагент без общего контекста — незамедлительно предоставив всю необходимую информацию. Соберите выходы и интегрируйте.

Проверка цитирований (с использованием кода выполнения):

# В execute_code:
from semanticscholar import SemanticScholar
import requests

sch = SemanticScholar()
results = sch.search_paper("attention mechanism transformers", limit=5)
for paper in results:
    doi = paper.externalIds.get('DOI', 'N/A')
    if doi!= 'N/A':
        bibtex = requests.get(f"https://doi.org/{doi}", 
                              headers={"Accept": "application/x-bibtex"}).text
        print(bibtex)

Управление состоянием с помощью `memory` и `todo`

Инструмент memory — сохраняет ключевые решения (ограничено: ~2200 символов для MEMORY.md):

memory("add", "Статья: autoreason. Площадка: NeurIPS 2025 (9 страниц). 
  Вклад: структурированное уточнение работает, когда разрыв между генерацией и оценкой велик.
  Ключевые результаты: Haiku 42/42, Sonnet 3/5, S4.6 ограниченный 2/3.
  Статус: Фаза 5 — написание раздела Методы.")

Обновляйте память после серьезных решений или переходов. Это продолжается между сеансами.

Инструмент todo — отслеживайте детальный прогресс:

todo("add", "Разработать эксперименты с ограниченными задачами для Sonnet 4.6")
todo("add", "Запустить сравнение базовых методов Haiku")
todo("add", "Написать раздел Методы")
todo("update", id=3, status="in_progress")
todo("update", id=1, status="completed")

Протокол запуска сеанса:

1. todo("list")                           # Проверить текущий список задач
2. memory("read")                         # Вспомнить ключевые решения
3. terminal("git log --oneline -10")      # Проверить недавние коммиты
4. terminal("ps aux | grep python")       # Проверить запущенные эксперименты
5. terminal("ls results/ | tail -20")     # Проверить новые результаты
6. Сообщить статус пользователю, спросить направление

Мониторинг Cron с помощью `cronjob`

Используйте инструмент cronjob для планирования периодических проверок экспериментов:

cronjob("create", {
  "schedule": "*/30 * * * *",  # Каждые 30 минут
  "prompt": "Проверить статус эксперимента:
    1. ps aux | grep run_experiment
    2. tail -30 logs/experiment_haiku.log
    3. ls results/haiku_baselines/
    4. Если завершен: прочитать результаты, вычислить оценки Borda, 
       git add -A && git commit -m 'Добавить результаты Haiku' && git push
    5. Сообщить: таблица результатов, ключевой вывод, следующий шаг
    6. Если ничего не изменилось: ответить [SILENT]"
})

Протокол [SILENT]: Если с момента последней проверки ничего не изменилось, ответьте ровно [SILENT]. Это контролирует доставку уведомлений пользователю. Сообщайте только тогда, когда есть реальные изменения, о которых стоит знать.

Отслеживание дедлайнов:

cronjob("create", {
  "schedule": "0 9 * * *",  # Ежедневно в 9 утра
  "prompt": "Дедлайн NeurIPS 2025: 22 мая. Сегодня {date}. 
    Осталось дней: {вычислить}. 
    Проверить список todo — мы в графике? 
    Если <7 дней: предупредить пользователя об оставшихся задачах."
})

Паттерны общения

Когда уведомлять пользователя (через send_message или прямой ответ): - Партия экспериментов завершена (с таблицей результатов) - Неожиданный результат или сбой, требующий решения - Раздел черновика готов к боку - Дедлайн проявляется с незавершенными задачами

Когда НЕ уведомлять: - Эксперимент все еще эффективен, новых результатов нет → [SILENT] - Плановый мониторинг без изменений → [SILENT] - Промежуточные шаги, не требующие внимания.

Формат отчета — всегда включайте структурированные данные:

## Эксперимент: <название>
Статус: Завершен / Выполняется / Не удался

| Задача | Метод A | Метод B | Метод C |
|--------|---------|---------|---------|
| Задача 1 | 85.2 | 82.1 | **89.4** |

Ключевой вывод: <одно предложение>
Следующий шаг: <что происходит дальше>

Точки принятия решений, требующие ввода человека

Используйте clarify для целенаправленных вопросов, когда действительно застряли:

Решение	Когда спрашивать
Целевая площадка	Перед началом статьи (влияет на лимиты страниц, формулировку)
Формулировка вклада	Когда существует несколько допустимых формулировок
Приоритет эксперимента	Когда в списке TODO больше экспериментов, чем позволяет время
Готовность к подаче	Перед финальной подачей

НЕ спрашивайте о (будьте проактивны, сделайте выбор, отметьте его): - Выборе слов, порядке разделов - Какие конкретные результаты выделить - Полноте цитирований (пишите черновик с тем, что нашли, отмечайте пробелы)

Критерии оценки рецензентов

Понимание того, на что смотрят рецензенты, помогает сфокусировать усилия:

Критерий	Что они проверяют
Качество	Техническая обоснованность, хорошо подтвержденные утверждения, справедливые базовые методы
Ясность	Четкое написание, воспроизводимость экспертами, согласованная нотация
Значимость	Влияние на сообщество, продвижение понимания
Оригинальность	Новые идеи (не требует нового метода)

Оценка (6-балльная шкала NeurIPS): - 6: Strong Accept — новаторская, безупречная - 5: Accept — технически обоснованная, высокое влияние - 4: Borderline Accept — обоснованная, ограниченная оценка - 3: Borderline Reject — слабые стороны перевешивают - 2: Reject — технические недостатки - 1: Strong Reject — известные результаты или проблемы этики

См. references/reviewer-guidelines.md для подробных рекомендаций, распространенных проблем и стратегий апелляции.

Распространенные проблемы и решения

Проблема	Решение
Аннотация слишком общая	Удалите первое предложение, если оно может предварять любую ML-статью. Начните с вашего конкретного вклада.
Введение превышает 1.5 страницы	Перенесите предысторию в Связанные работы. Вынесите пункты вклада вперед.
В экспериментах не хватает явных утверждений	Добавьте: «Этот эксперимент проверяет, [конкретное утверждение]...» перед каждым.
Рецензенты считают статью трудной для понимания	Добавьте указатели, используйте согласованную терминологию, сделайте подписи к рисункам самодостаточными.
Отсутствует статистическая значимость	Добавьте планки погрешностей, количество запусков, статистические тесты, доверительные интервалы.
Расползание объема экспериментов	Каждый эксперимент должен соответствовать конкретному утверждению. Сократите эксперименты, которые не соответствуют.
Статья отклонена, нужно подать повторно	См. Повторная подача на конференцию в Фазе 7. Учтите замечания рецензентов, не ссылаясь на рецензии.
Отсутствует заявление о более широком влиянии	См. Шаг 5.10. Большинство площадок требуют его. «Нет негативных последствий» почти никогда не заслуживает доверия.
Человеческая оценка раскритикована как слабая	См. Шаг 2.5 и references/human-evaluation.md. Сообщите метрики согласия, детали аннотаторов, компенсацию.
Рецензенты ставят под сомнение воспроизводимость	Выпустите код (Шаг 7.9), документируйте все гиперпараметры, включите сиды и детали вычислений.
Теоретической статье не хватает интуиции	Добавьте наброски доказательств с объяснениями на простом языке перед формальными доказательствами. См. references/paper-types.md.
Результаты отрицательные/нулевые	См. Фазу 4.3 по обработке отрицательных результатов. Рассмотрите семинары, TMLR или переформулировку как анализ.

Справочные документы

Документ	Содержание
references/writing-guide.md	7 принципов Gopen & Swan, микро-советы Perez, выбор слов Lipton, точность Steinhardt, дизайн рисунков
references/citation-workflow.md	API цитирований, код Python, класс CitationManager, управление BibTeX
references/checklists.md	16 пунктов NeurIPS, требования ICML, ICLR, ACL, универсальный предподачный контрольный список
references/reviewer-guidelines.md	Критерии оценки, баллы, распространенные проблемы, шаблон апелляции
references/sources.md	Полная библиография всех руководств по написанию, рекомендаций конференций, API
references/experiment-patterns.md	Шаблоны дизайна экспериментов, протоколы оценки, мониторинг, восстановление после ошибок
references/autoreason-methodology.md	Цикл Autoreason, выбор стратегии, руководство по моделям, промпты, ограничения области, подсчет Borda
references/human-evaluation.md	Дизайн человеческой оценки, руководства по аннотации, метрики согласия, контроль качества краудсорсинга, рекомендации IRB
references/paper-types.md	Теоретические статьи (написание доказательств, структура теорем), обзорные статьи, статьи-бенчмарки, позиционные статьи

Шаблоны LaTeX

Шаблоны в templates/ для: NeurIPS 2025, ICML 2026, ICLR 2026, ACL, AAAI 2026, COLM 2025.

См. templates/README.md для инструкций по компиляции.

Ключевые внешние источники

Философия написания: - Neel Nanda: How to Write ML Papers - Sebastian Farquhar: How to Write ML Papers - Gopen & Swan: Science of Scientific Writing - Lipton: Heuristics for Scientific Writing - Perez: Easy Paper Writing Tips

API: Semantic Scholar | CrossRef | arXiv

Площадки: NeurIPS | ICML | ICLR | ACL