На этой странице Пишите ML-статьи для NeurIPS/ICML/ICLR: от проектирования до подачи.

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

|---|--- Source| Встроенный (устанавливается по умолчанию) Path| skills/research/research-paper-writing Version| 1.1.0 Author| Orchestra Research License| MIT Зависимости| semanticscholar, arxiv, habanero, requests, scipy, numpy, matplotlib, SciencePlots Платформы| linux, macos Теги| Research, Paper Writing, Experiments, ML, AI, NeurIPS, ICML, ICLR, ACL, AAAI, COLM, LaTeX, Citations, Statistical Analysis Связанные навыки| arxiv, ml-paper-writing, subagent-driven-development, plan

Справка: полный SKILL.md¶

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

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

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

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

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

[/code]

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

Используйте этот навык, когда:

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

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

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

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

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

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

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

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

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

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

Шаг 0.1: Изучение репозитория¶

[code] # Понимание структуры проекта ls -la find . -name ".py" | head -30 find . -name ".md" -o -name "*.txt" | xargs grep -l -i "result|conclusion|finding"

[/code]

Ищите:

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

Шаг 0.2: Организация рабочего пространства¶

Создайте согласованную структуру рабочего пространства:

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

[/code]

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

[code] git init # если ещё не инициализирован git remote add origin git checkout -b paper-draft # или main

[/code]

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

[code] 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

[/code]

Шаг 0.4: Определение вклада¶

Прежде чем что-либо писать, сформулируйте:

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

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

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

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

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

[/code]

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

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

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

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

[/code]

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

[code] # Simple cost tracker pattern 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")

[/code]

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

Шаг 0.7: Координация соавторов¶

В большинстве статей 3-10 авторов. Установите рабочие процессы заранее:

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

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

[/code]

Соглашения LaTeX, которые нужно обсудить заранее:

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

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

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

Шаг 1.1: Определение ключевых статей¶

Начните со статей, уже указанных в кодовой базе:

[code] # Via terminal: grep -r "arxiv|doi|cite" --include=".md" --include=".bib" --include=".py" find . -name ".bib"

[/code]

Шаг 1.2: Поиск связанных работ¶

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

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

[code] # Via web_search: web_search("[main technique] + [application domain] site:arxiv.org") web_search("[baseline method] comparison ICML NeurIPS 2024")

# Via web_extract (for specific papers):
web_extract("https://arxiv.org/abs/2303.17651")

[/code]

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

[code] Search queries: - "[main technique] + [application domain]" - "[baseline method] comparison" - "[problem name] state-of-the-art" - Author names from existing citations

[/code]

Рекомендуется: Установите Exa MCP для поиска в реальном времени по академическим источникам:

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

[/code]

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

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

[code] Iterative Literature Search:

Round 1 (Breadth): 4-6 параллельных запросов, покрывающих разные углы
  - "[method] + [domain]"
  - "[problem name] state-of-the-art 2024 2025"
  - "[baseline method] comparison"
  - "[alternative approach] vs [your approach]"
  → Собрать статьи, извлечь ключевые концепции и терминологию

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

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

[/code]

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

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

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

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

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

[code] Citation Verification (MANDATORY per citation): 1. SEARCH → Запросить Semantic Scholar или Exa MCP с конкретными ключевыми словами 2. VERIFY → Подтвердить, что статья существует в 2+ источниках (Semantic Scholar + arXiv/CrossRef) 3. RETRIEVE → Получить BibTeX через DOI content negotiation (программно, не по памяти) 4. VALIDATE → Подтвердить, что утверждение, которое вы цитируете, действительно есть в статье 5. ADD → Добавить проверенный BibTeX в библиографию Если ЛЮБОЙ шаг не удался → пометить как [CITATION NEEDED], сообщить учёному

[/code]

[code] # Fetch BibTeX via 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

[/code]

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

[code] \cite{PLACEHOLDER_author2024_verify_this} % TODO: Verify this citation exists

[/code]

Всегда сообщайте учёному: "Я отметил [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: Написание скриптов экспериментов¶

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

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

[code] # Save after each problem/task result_path = f"results/{task}/{strategy}/result.json" if os.path.exists(result_path): continue # Skip already-completed work # ... run experiment ... with open(result_path, 'w') as f: json.dump(result, f, indent=2)

[/code]

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

[code] results// / / final_output.md # Итоговый результат history.json # Полная траектория pass_01/ # Артефакты по итерациям version_a.md version_b.md critic.md

[/code]

Разделение ответственности — храните генерацию, оценку и визуализацию отдельно:

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

[/code]

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

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

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

Когда необходима человеческая оценка:

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

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

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

Чеклист руководства по аннотации:

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

[/code]

Требования к отчёту (рецензенты проверяют все эти пункты):

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

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

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

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

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

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

[code] nohup python run_experiment.py --config config.yaml > logs/experiment_01.log 2>&1 & echo $! # Record the PID

[/code]

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

Шаг 3.2: Настройка мониторинга (паттерн Cron)¶

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

[code] Monitor Prompt Template: 1. Check if process is still running: ps aux | grep 2. Read last 30 lines of log: tail -30 3. Check for completed results: ls 4. If results exist, read and report: cat 5. If all done, commit: git add -A && git commit -m "" && git push 6. Report in structured format (tables with key metrics) 7. Answer the key analytical question for this experiment

[/code]

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

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

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

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

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

Шаг 3.4: Фиксация завершённых результатов¶

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

[code] git add -A git commit -m "Add : " git push

[/code]

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

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

[code] // experiment_journal.jsonl — append one entry per experiment attempt { "id": "exp_003", "parent": "exp_001", "timestamp": "2025-05-10T14:30:00Z", "hypothesis": "Adding scope constraints will fix convergence failure from exp_001", "plan": "Re-run autoreason with max_tokens=2000 and fixed structure template", "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": "Scope constraints fixed convergence. Win rate jumped from 0.42 to 0.85.", "next_steps": ["Try same constraints on Sonnet", "Test without structure template"], "figures": ["figures/exp003_convergence.pdf"] }

[/code]

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

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

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

[code] cp experiment.py results/exp_003/experiment_snapshot.py

[/code]

Это обеспечивает точное воспроизведение даже после последующих изменений кода.

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

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

Шаг 4.1: Агрегация результатов¶

Напишите скрипты анализа, которые:

Загружают все файлы результатов из партии
Вычисляют метрики по задачам и агрегированные метрики
Генерируют сводные таблицы

[code] # Standard analysis pattern 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

# Compute aggregate metrics
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}")

[/code]

Шаг 4.2: Статистическая значимость¶

Всегда вычисляйте:

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

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

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

После анализа явно ответьте:

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

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

Когда ваша гипотеза оказалась неверной или результаты неубедительны, у вас есть три варианта:

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

Как написать статью с негативными результатами:

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

Конференции, которые явно приветствуют негативные результаты: NeurIPS (трек Datasets & Benchmarks), TMLR, ML Reproducibility Challenge, воркшопы на крупных конференциях. Некоторые воркшопы специально запрашивают негативные результаты.

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

Рисунки:

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

Таблицы:

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

[code] \usepackage{booktabs} \begin{tabular}{lcc} \toprule Method & Accuracy $\uparrow$ & Latency $\downarrow$ \ \midrule Baseline & 85.2 & 45ms \ \textbf{Ours} & \textbf{92.1} & 38ms \ \bottomrule \end{tabular}

[/code]

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

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

Шаг 4.6: Написание журнала экспериментов (Мост к написанию)¶

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

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

[code] # Experiment Log

## Contribution (one sentence)
[The paper's main claim]

## Experiments Run

### Experiment 1: [Name]
- **Claim tested**: [Which paper claim this supports]
- **Setup**: [Model, dataset, config, number of runs]
- **Key result**: [One sentence with the number]
- **Result files**: results/exp1/final_info.json
- **Figures generated**: figures/exp1_comparison.pdf
- **Surprising findings**: [Anything unexpected]

### Experiment 2: [Name]
...

## Figures
| Filename | Description | Which section it belongs in |
|----------|-------------|---------------------------|
| figures/main_comparison.pdf | Bar chart comparing all methods on benchmark X | Results, Figure 2 |
| figures/ablation.pdf | Ablation removing components A, B, C | Results, Figure 3 |
...

## Failed Experiments (document for honesty)
- [What was tried, why it failed, what it tells us]

## Open Questions
- [Anything the results raised that the paper should address]

[/code]

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

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

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

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

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

Ваша ситуация	Стратегия	Почему
Модель среднего уровня + ограниченная задача	Autoreason	Идеальное сочетание. Разрыв генерация-оценка максимален. Бейзлайны активно разрушают слабые выходы модели.
Модель среднего уровня + открытая задача	Autoreason с добавлением ограничений области	Добавьте фиксированные факты, структуру или результат, чтобы ограничить пространство улучшений.
Фронтирная модель + ограниченная задача	Autoreason	Выигрывает 2/3 ограниченных задач даже на фронтире.
Фронтирная модель + неограниченная задача	Critique-and-revise или single pass	Autoreason на последнем месте. Модель достаточно хорошо самооценивается.
Конкретная техническая задача (системный дизайн)	Critique-and-revise	Прямой цикл найти-и-исправить более эффективен.
Задача заполнения шаблона (одна правильная структура)	Single pass или conservative	Минимальное пространство решений. Итерация не добавляет ценности.
Код с тестовыми случаями	Autoreason (вариант для кода)	Структурированный анализ того, почему это не сработало, перед исправлением. Уровень восстановления 62% vs 43%.
Очень слабая модель (класс Llama 8B)	Single pass	Модель слишком слаба для разнообразных кандидатов. Инвестируйте в качество генерации.

Разрыв генерация-оценка¶

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

[code] Model Tier │ Generation │ Self-Eval │ Gap │ Autoreason Value ──────────────────┼────────────┼───────────┼────────┼───────────────── Weak (Llama 8B) │ Poor │ Poor │ Small │ None — can't generate diverse candidates Mid (Haiku 3.5) │ Decent │ Poor │ LARGE │ MAXIMUM — 42/42 perfect Borda Mid (Gemini Flash)│ Decent │ Moderate │ Large │ High — wins 2/3 Strong (Sonnet 4) │ Good │ Decent │ Medium │ Moderate — wins 3/5 Frontier (S4.6) │ Excellent │ Good │ Small │ Only with constraints

[/code]

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

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

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

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

Ключевые параметры:

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

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

При уточнении самой статьи через autoreason:

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

Режимы сбоя¶

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

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

Фаза 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/ с предварительно сжатыми сводками:

[code] context/ contribution.md # 1 предложение experiment_summary.md # Таблица ключевых результатов (из experiment_log.md) literature_map.md # Организованные заметки по цитированиям figure_inventory.md # Список рисунков с описаниями

[/code]

Принцип нарратива¶

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

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

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

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

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

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

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

Источник	Ключевой вклад	Ссылка
Neel Nanda (Google DeepMind)	Принцип нарратива, рамка Что/Почему/Зачем	How to Write ML Papers
Sebastian Farquhar (DeepMind)	Формула аннотации из 5 предложений	How to Write ML Papers
Gopen & Swan	7 принципов ожиданий читателя	Science of Scientific Writing
Zachary Lipton	Выбор слов, устранение уклончивости	Heuristics for Scientific Writing
Jacob Steinhardt (UC Berkeley)	Точность, согласованная терминология	Writing Tips
Ethan Perez (Anthropic)	Советы по микро-ясности	Easy Paper Writing Tips
Andrej Karpathy	Фокус на одном вкладе	Различные лекции

Для более глубокого погружения в любой из этих источников см.:

references/writing-guide.md — Полные объяснения с примерами
references/sources.md — Полная библиография

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

Уделите примерно равное время каждому из:

Аннотация
Введение
Рисунки
Всё остальное вместе взятое

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

Рабочий процесс написания¶

[code] Paper Writing Checklist: - [ ] Step 1: Define the one-sentence contribution - [ ] Step 2: Draft Figure 1 (core idea or most compelling result) - [ ] Step 3: Draft abstract (5-sentence formula) - [ ] Step 4: Draft introduction (1-1.5 pages max) - [ ] Step 5: Draft methods - [ ] Step 6: Draft experiments & results - [ ] Step 7: Draft related work - [ ] Step 8: Draft conclusion & discussion - [ ] Step 9: Draft limitations (REQUIRED by all venues) - [ ] Step 10: Plan appendix (proofs, extra experiments, details) - [ ] Step 11: Complete paper checklist - [ ] Step 12: Final review

[/code]

Паттерн двухпроходного уточнения¶

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

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

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

[code] Second-pass refinement prompt (per section): "Review the [SECTION] in the context of the complete paper. - Does it fit with the rest of the paper? Are there redundancies with other sections? - Is terminology consistent with Introduction and Methods? - Can anything be cut without weakening the message? - Does the narrative flow from the previous section and into the next? Make minimal, targeted edits. Do not rewrite from scratch."

[/code]

Чеклист ошибок LaTeX¶

Прикрепите этот чеклист к каждому запросу на уточнение. Это наиболее распространённые ошибки при написании LaTeX языковыми моделями:

[code] LaTeX Quality Checklist (verify after every edit): - [ ] No unenclosed math symbols ($ signs balanced) - [ ] Only reference figures/tables that exist (\ref matches \label) - [ ] No fabricated citations (\cite matches entries in .bib) - [ ] Every \begin{env} has matching \end{env} (especially figure, table, algorithm) - [ ] No HTML contamination ( instead of \end{figure}) - [ ] No unescaped underscores outside math mode (use _ in text) - [ ] No duplicate \label definitions - [ ] No duplicate section headers - [ ] Numbers in text match actual experimental results - [ ] All figures have captions and labels - [ ] No overly long lines that cause overfull hbox warnings

[/code]

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

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

Хорошие заголовки:

Указывают вклад или результат: "Autoreason: When Iterative LLM Refinement Works and Why It Fails"
Выделяют удивительный результат: "Scaling Data-Constrained Language Models" (подразумевает, что это возможно)
Называют метод + что он делает: "DPO: Direct Preference Optimization of Language Models"

Плохие заголовки:

Слишком общие: "An Approach to Improving Language Model Outputs"
Слишком длинные: всё больше ~15 слов
Только жаргон: "Asymptotic Convergence of Iterative Stochastic Policy Refinement" (для кого это?)

Правила:

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

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

От Sebastian Farquhar (DeepMind):

[code] 1. What you achieved: "We introduce...", "We prove...", "We demonstrate..." 2. Why this is hard and important 3. How you do it (with specialist keywords for discoverability) 4. What evidence you have 5. Your most remarkable number/result

[/code]

Удалите шаблонные открытия вроде "Large language models have achieved remarkable success..."

Шаг 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"

Требования:

Планки погрешностей с методологией (стд откл vs стд ошибка)
Диапазоны поиска гиперпараметров
Вычислительная инфраструктура (тип 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: Proofs} и т.д.

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

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

Стратегия сокращения	Экономит	Риск
Перенести доказательства в приложение	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

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

[code] \section*{Broader Impact Statement} % NeurIPS/ICML: after conclusion, does not count toward page limit

% 1. Positive applications (1-2 sentences)
This work enables [specific application] which may benefit [specific group].

% 2. Risks and mitigations (1-3 sentences, be specific)
[Method/model] could potentially be misused for [specific risk]. We mitigate
this by [specific mitigation, e.g., releasing only model weights above size X,
including safety filters, documenting failure modes].

% 3. Limitations of impact claims (1 sentence)
Our evaluation is limited to [specific domain]; broader deployment would
require [specific additional work].

[/code]

Распространённые ошибки:

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

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

[code] # Estimate using ML CO2 Impact tool methodology gpu_hours = 1000 # total GPU hours gpu_tdp_watts = 400 # e.g., A100 = 400W pue = 1.1 # Power Usage Effectiveness (data center overhead) carbon_intensity = 0.429 # kg CO2/kWh (US average; varies by region)

energy_kwh = (gpu_hours * gpu_tdp_watts * pue) / 1000
carbon_kg = energy_kwh * carbon_intensity
print(f"Energy: {energy_kwh:.0f} kWh, Carbon: {carbon_kg:.0f} kg CO2eq")

[/code]

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

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

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

[code] Dataset Documentation (Appendix): - Motivation: Why was this dataset created? What task does it support? - Composition: What are the instances? How many? What data types? - Collection: How was data collected? What was the source? - Preprocessing: What cleaning/filtering was applied? - Distribution: How is the dataset distributed? Under what license? - Maintenance: Who maintains it? How to report issues? - Ethical considerations: Contains personal data? Consent obtained? Potential for harm? Known biases?

[/code]

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

[code] Model Card (Appendix): - Model details: Architecture, training data, training procedure - Intended use: Primary use cases, out-of-scope uses - Metrics: Evaluation metrics and results on benchmarks - Ethical considerations: Known biases, fairness evaluations - Limitations: Known failure modes, domains where model underperforms

[/code]

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

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

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

Выбор слов (Lipton, Steinhardt):

Будьте конкретны: "точность" (accuracy), а не "производительность" (performance)
Устраните уклончивость: опустите "может" (may), если нет реальной неопределённости
Согласованная терминология на протяжении всей статьи
Избегайте инкрементальной лексики: "разрабатывать" (develop), не "объединять" (combine)

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

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

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

[code] Template Setup Checklist: - [ ] Step 1: Copy entire template directory to new project - [ ] Step 2: Verify template compiles as-is (before any changes) - [ ] Step 3: Read the template's example content to understand structure - [ ] Step 4: Replace example content section by section - [ ] Step 5: Use template macros (check preamble for \newcommand definitions) - [ ] Step 6: Clean up template artifacts only at the end

[/code]

Шаг 1: Копирование полного шаблона

[code] cp -r templates/neurips2025/ ~/papers/my-paper/ cd ~/papers/my-paper/ ls -la # Should see: main.tex, neurips.sty, Makefile, etc.

[/code]

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

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

До внесения ЛЮБЫХ изменений:

[code] latexmk -pdf main.tex # Or manual: pdflatex main.tex && bibtex main && pdflatex main.tex && pdflatex main.tex

[/code]

Если неизменённый шаблон не компилируется, сначала исправьте это (обычно не хватает TeX-пакетов — установите через tlmgr install <package>).

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

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

[code] % Template example (keep for reference): % \begin{figure}[t] % \centering % \includegraphics[width=0.8\linewidth]{example-image} % \caption{Template shows caption style} % \end{figure}

% Your actual figure:
\begin{figure}[t]
  \centering
  \includegraphics[width=0.8\linewidth]{your-figure.pdf}
  \caption{Your caption following the same style.}
\end{figure}

[/code]

Шаг 4: Замена содержимого раздел за разделом

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

Шаг 5: Использование макросов шаблона

[code] \newcommand{\method}{YourMethodName} % Consistent method naming \newcommand{\eg}{e.g.,\xspace} % Proper abbreviations \newcommand{\ie}{i.e.,\xspace}

[/code]

Типичные ошибки с шаблонами¶

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

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

Конференция	Основной файл	Файл стиля	Лимит страниц
NeurIPS 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 страниц (long)
AAAI 2026	`aaai2026-unified-template.tex`	`aaai2026.sty`	7 страниц
COLM 2025	`colm2025_conference.tex`	`colm2025_conference.sty`	9 страниц

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

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

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

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

[code] \usepackage{booktabs} \begin{tabular}{lcc} \toprule Method & Accuracy $\uparrow$ & Latency $\downarrow$ \ \midrule Baseline & 85.2 & 45ms \ \textbf{Ours} & \textbf{92.1} & 38ms \ \bottomrule \end{tabular}

[/code]

Правила:

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

Рисунки:

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

Повторная отправка на конференцию¶

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

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

Добавьте эти пакеты в любую статью для профессионального качества. Они совместимы со всеми основными стилевыми файлами конференций: [code] % --- Professional Packages (add after conference style file) ---

% Typography  
\usepackage{microtype}              % Microtypographic improvements (protrusion, expansion)  
                                     % Makes text noticeably more polished — always include

% Tables  
\usepackage{booktabs}               % Professional table rules (\toprule, \midrule, \bottomrule)  
\usepackage{siunitx}                % Consistent number formatting, decimal alignment  
                                     % Usage: \num{12345} → 12,345; \SI{3.5}{GHz} → 3.5 GHz  
                                     % Table alignment: S column type for decimal-aligned numbers

% Figures  
\usepackage{graphicx}               % Include graphics (\includegraphics)  
\usepackage{subcaption}             % Subfigures with (a), (b), (c) labels  
                                     % Usage: \begin{subfigure}{0.48\textwidth} ... \end{subfigure}

% Diagrams and Algorithms  
\usepackage{tikz}                   % Programmable vector diagrams  
\usetikzlibrary{arrows.meta, positioning, shapes.geometric, calc, fit, backgrounds}  
\usepackage[ruled,vlined]{algorithm2e}  % Professional pseudocode  
                                     % Alternative: \usepackage{algorithmicx} if template bundles it

% Cross-references  
\usepackage{cleveref}               % Smart references: \cref{fig:x} → "Figure 1"  
                                     % MUST be loaded AFTER hyperref  
                                     % Handles: figures, tables, sections, equations, algorithms

% Math (usually included by conference .sty, but verify)  
\usepackage{amsmath,amssymb}        % AMS math environments and symbols  
\usepackage{mathtools}              % Extends amsmath (dcases, coloneqq, etc.)

% Colors (for figures and diagrams)  
\usepackage{xcolor}                 % Color management  
% Okabe-Ito colorblind-safe palette:  
\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}

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

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

siunitx делает таблицы с большим количеством чисел значительно более читаемыми: [code] \begin{tabular}{l S[table-format=2.1] S[table-format=2.1] S[table-format=2.1]}
\toprule
Method & {Accuracy $\uparrow$} & {F1 $\uparrow$} & {Latency (ms) $\downarrow$} \
\midrule
Baseline & 85.2 & 83.7 & 45.3 \
Ablation (no X) & 87.1 & 85.4 & 42.1 \
\textbf{Ours} & \textbf{92.1} & \textbf{90.8} & \textbf{38.7} \
\bottomrule
\end{tabular}

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

Подфигуры¶

Стандартный шаблон для рисунков рядом друг с другом: [code] \begin{figure}[t]
\centering
\begin{subfigure}[b]{0.48\textwidth}
\centering
\includegraphics[width=\textwidth]{fig_results_a.pdf}
\caption{Results on Dataset A.}
\label{fig:results-a}
\end{subfigure}
\hfill
\begin{subfigure}[b]{0.48\textwidth}
\centering
\includegraphics[width=\textwidth]{fig_results_b.pdf}
\caption{Results on Dataset B.}
\label{fig:results-b}
\end{subfigure}
\caption{Comparison of our method across two datasets. (a) shows the scaling
behavior and (b) shows the ablation results. Both use 5 random seeds.}
\label{fig:results}
\end{figure}

[/code] Используйте \cref{fig:results} → "Figure 1", \cref{fig:results-a} → "Figure 1a".

Псевдокод с algorithm2e¶

[code] \begin{algorithm}[t]
\caption{Iterative Refinement with Judge Panel}
\label{alg:method}
\KwIn{Task $T$, model $M$, judges $J_1 \ldots J_n$, convergence threshold $k$}
\KwOut{Final output $A^$}
$A \gets M(T)$ \tcp
$\text{streak} \gets 0$\;
\While{$\text{streak} < k$}{
$C \gets \text{Critic}(A, T)$ \tcp{Identify weaknesses}
$B \gets M(T, C)$ \tcp
$AB \gets \text{Synthesize}(A, B)$ \tcp{Merge best elements}
\ForEach{judge $J_i$}{
$\text{rank}_i \gets J_i(\text{shuffle}(A, B, AB))$ \tcp
}
$\text{winner} \gets \text{BordaCount}(\text{ranks})$\;
\eIf{$\text{winner} = A$}{
$\text{streak} \gets \text{streak} + 1$\;
}{
$A \gets \text{winner}$; $\text{streak} \gets 0$\;
}
}
\Return{$A$}\;
\end{algorithm}

[/code]

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

TikZ — стандарт для диаграмм методов в ML-статьях. Распространённые шаблоны: Диаграмма конвейера/потока (самая распространённая в ML-статьях): [code] \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) {Input\$x$};
\node[box, fill=okblue!20, right of=input] (encoder) {Encoder\$f_\theta$};
\node[box, fill=okgreen!20, right of=encoder] (latent) {Latent\$z$};
\node[box, fill=okorange!20, right of=latent] (decoder) {Decoder\$g_\phi$};
\node[box, fill=okred!20, right of=decoder] (output) {Output\$\hat{x}$};

  \draw[arrow] (input) -- (encoder);  
  \draw[arrow] (encoder) -- (latent);  
  \draw[arrow] (latent) -- (decoder);  
  \draw[arrow] (decoder) -- (output);  
\end{tikzpicture}  
\caption{Architecture overview. The encoder maps input $x$ to latent   
representation $z$, which the decoder reconstructs.}  
\label{fig:architecture}  
\end{figure}

[/code] Сравнительная/матричная диаграмма (для показа вариантов метода): [code] \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},
]
% Headers
\node[header] at (0, 0) {Method};
\node[header] at (3, 0) {Converges?};
\node[header] at (6, 0) {Quality?};
% Rows
\node[cell] at (0, -1) {Single Pass};
\node[cell, fill=okgreen!15] at (3, -1) {N/A};
\node[cell, fill=okorange!15] at (6, -1) {Baseline};
\node[cell] at (0, -2) {Critique+Revise};
\node[cell, fill=okred!15] at (3, -2) {No};
\node[cell, fill=okred!15] at (6, -2) {Degrades};
\node[cell] at (0, -3) {Ours};
\node[cell, fill=okgreen!15] at (3, -3) {Yes ($k$=2)};
\node[cell, fill=okgreen!15] at (6, -3) {Improves};
\end{tikzpicture}

[/code] Диаграмма итеративного цикла (для методов с обратной связью): [code] \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) {Generator};
\node[box, fill=okred!20, right=2.5cm of gen] (critic) {Critic};
\node[box, fill=okgreen!20, below=1.5cm of $(gen)!0.5!(critic)$] (judge) {Judge Panel};

  \draw[arrow] (gen) -- node[label] {output $A$} (critic);  
  \draw[arrow] (critic) -- node[label, right] {critique $C$} (judge);  
  \draw[arrow] (judge) -| node[label, left, pos=0.3] {winner} (gen);  
\end{tikzpicture}

[/code]

latexdiff для отслеживания правок¶

Необходим для rebuttal'ов — создаёт размеченный PDF, показывающий изменения между версиями: [code] # Install
# macOS: brew install latexdiff (or comes with TeX Live)
# Linux: sudo apt install latexdiff

# Generate diff  
latexdiff paper_v1.tex paper_v2.tex > paper_diff.tex  
pdflatex paper_diff.tex

# For multi-file projects (with \input{} or \include{})  
latexdiff --flatten paper_v1.tex paper_v2.tex > paper_diff.tex

[/code] Это создаёт PDF с удалениями, показанными красным зачёркиванием, и добавлениями синим — стандартный формат для приложений к rebuttal'ам.

SciencePlots для matplotlib¶

Установите и используйте для графиков публикационного качества: [code] pip install SciencePlots

[/code] [code] import matplotlib.pyplot as plt
import scienceplots # registers styles

# Use science style (IEEE-like, clean)  
with plt.style.context(['science', 'no-latex']):  
    fig, ax = plt.subplots(figsize=(3.5, 2.5))  # Single-column width  
    ax.plot(x, y, label='Ours', color='#0072B2')  
    ax.plot(x, y2, label='Baseline', color='#D55E00', linestyle='--')  
    ax.set_xlabel('Training Steps')  
    ax.set_ylabel('Accuracy')  
    ax.legend()  
    fig.savefig('paper/fig_results.pdf', bbox_inches='tight')

# Available styles: 'science', 'ieee', 'nature', 'science+ieee'  
# Add 'no-latex' if LaTeX is not installed on the machine generating plots

[/code] Стандартные размеры рисунков (двухколоночный формат): * Одна колонка: 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 хорошо документирован позитивный уклон в оценке. [code] You are an expert reviewer for [VENUE]. You are critical and thorough.
If a paper has weaknesses or you are unsure about a claim, flag it clearly
and reflect that in your scores. Do not give the benefit of the doubt.

Review this paper according to the official reviewer guidelines. Evaluate:

1. Soundness (are claims well-supported? are baselines fair and strong?)  
2. Clarity (is the paper well-written? could an expert reproduce it?)  
3. Significance (does this matter to the community?)  
4. Originality (new insights, not just incremental combination?)

Provide your review as structured JSON:  
{  
  "summary": "2-3 sentence summary",  
  "strengths": ["strength 1", "strength 2", ...],  
  "weaknesses": ["weakness 1 (most critical)", "weakness 2", ...],  
  "questions": ["question for authors 1", ...],  
  "missing_references": ["paper that should be cited", ...],  
  "soundness": 1-4,  
  "presentation": 1-4,  
  "contribution": 1-4,  
  "overall": 1-10,  
  "confidence": 1-5  
}

[/code] Шаг 2: Мета-рецензия (агрегация председателем секции) Подайте все N рецензий мета-рецензенту: [code] You are an Area Chair at [VENUE]. You have received [N] independent reviews
of a paper. Your job is to:

1. Identify consensus strengths and weaknesses across reviewers  
2. Resolve disagreements by examining the paper directly  
3. Produce a meta-review that represents the aggregate judgment  
4. Use AVERAGED numerical scores across all reviews

Be conservative: if reviewers disagree on whether a weakness is serious,  
treat it as serious until the authors address it.

Reviews:  
[review_1]  
[review_2]  
...

[/code] Шаг 3: Цикл рефлексии (опционально, 2-3 раунда) Каждый рецензент может уточнить свою рецензию после просмотра мета-рецензии. Используйте страж раннего завершения: если рецензент отвечает "I am done" (без изменений), прекратите итерации. Выбор модели для рецензирования : Рецензирование лучше всего проводить с самой сильной доступной моделью, даже если вы писали статью с более дешёвой. Модель-рецензент должна выбираться независимо от модели-писателя. Калибровка по нескольким примерам : Если доступно, включите 1-2 реальных опубликованных рецензии с целевой площадки в качестве примеров. Это значительно улучшает калибровку оценок. См. references/reviewer-guidelines.md для примеров рецензий.

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

Текстовое рецензирование упускает целый класс проблем: качество рисунков, проблемы вёрстки, визуальная согласованность. Если у вас есть доступ к модели с vision-возможностями, запустите отдельное визуальное рецензирование скомпилированного PDF: [code] You are reviewing the visual presentation of this research paper PDF.
Check for:
1. Figure quality: Are plots readable? Labels legible? Colors distinguishable?
2. Figure-caption alignment: Does each caption accurately describe its figure?
3. Layout issues: Orphaned section headers, awkward page breaks, figures far from their references
4. Table formatting: Aligned columns, consistent decimal precision, bold for best results
5. Visual consistency: Same color scheme across all figures, consistent font sizes
6. Grayscale readability: Would the figures be understandable if printed in B&W?

For each issue, specify the page number and exact location.

[/code] Это выявляет проблемы, которые не может обнаружить текстовое рецензирование: график с нечитаемыми подписями осей, рисунок, размещённый через 3 страницы от первого упоминания, несогласованные цветовые палитры между Рисунком 2 и Рисунком 5, или таблица, которая явно шире ширины колонки.

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

После моделирования рецензий запустите отдельный проход верификации. Это выявляет фактические ошибки, которые рецензенты могут пропустить: [code] Claim Verification Protocol:
1. Extract every factual claim from the paper (numbers, comparisons, trends)
2. For each claim, trace it to the specific experiment/result that supports it
3. Verify the number in the paper matches the actual result file
4. Flag any claim without a traceable source as [VERIFY]

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

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

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

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

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

Шаг 6.4: Написание rebuttal'а¶

При ответе на реальные рецензии (после отправки) rebuttal'ы — это отдельный навык от доработки: Формат : По пунктам. Для каждого замечания рецензента: [code] > R1-W1: "The paper lacks comparison with Method X."

We thank the reviewer for this suggestion. We have added a comparison with   
Method X in Table 3 (revised). Our method outperforms X by 3.2pp on [metric]   
(p<0.05). We note that X requires 2x our compute budget.

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

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

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

Сохраняйте снимки на ключевых этапах: [code] paper/
paper.tex # Current working version
paper_v1_first_draft.tex # First complete draft
paper_v2_post_review.tex # After simulated review
paper_v3_pre_submission.tex # Final before submission
paper_v4_camera_ready.tex # Post-acceptance final

[/code]

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

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

Шаг 7.1: Чек-лист конференции¶

У каждой площадки есть обязательные чек-листы. Заполняйте их внимательно — неполные чек-листы могут привести к отклонению без рецензирования. См. references/checklists.md для: * NeurIPS 16-пунктный чек-лист статьи * ICML заявление о более широком влиянии + воспроизводимость * ICLR политика раскрытия использования LLM * ACL обязательный раздел ограничений * Универсальный предотправочный чек-лист

Шаг 7.2: Чек-лист анонимизации¶

Двойное слепое рецензирование означает, что рецензенты не могут знать, кто написал статью. Проверьте ВСЁ это: [code] Anonymization Checklist:
- [ ] No author names or affiliations anywhere in the PDF
- [ ] No acknowledgments section (add after acceptance)
- [ ] Self-citations written in third person: "Smith et al. [1] showed..." not "We previously showed [1]..."
- [ ] No GitHub/GitLab URLs pointing to your personal repos
- [ ] Use Anonymous GitHub (https://anonymous.4open.science/) for code links
- [ ] No institutional logos or identifiers in figures
- [ ] No file metadata containing author names (check PDF properties)
- [ ] No "our previous work" or "in our earlier paper" phrasing
- [ ] Dataset names don't reveal institution (rename if needed)
- [ ] Supplementary materials don't contain identifying information

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

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

[code] Pre-Submission Format Check:
- [ ] Page limit respected (excluding references and appendix)
- [ ] All figures are vector (PDF) or high-res raster (600 DPI PNG)
- [ ] All figures readable in grayscale
- [ ] All tables use booktabs
- [ ] References compile correctly (no "?" in citations)
- [ ] No overfull hboxes in critical areas
- [ ] Appendix clearly labeled and separated
- [ ] Required sections present (limitations, broader impact, etc.)

[/code]

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

Запустите эти автоматические проверки до попытки pdflatex. Выявление ошибок здесь быстрее, чем анализ вывода компилятора. [code] # 1. Lint with chktex (catches common LaTeX mistakes)
# Suppress noisy warnings: -n2 (sentence end), -n24 (parens), -n13 (intersentence), -n1 (command terminated)
chktex main.tex -q -n2 -n24 -n13 -n1

# 2. Verify all citations exist in .bib  
# Extract \cite{...} from .tex, check each against .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'WARNING: \\\\cite{{{cite}}} not found in references.bib')  
"

# 3. Verify all referenced figures exist on disk  
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'WARNING: Figure file not found: {fig}')  
"

# 4. Check for duplicate \label definitions  
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'WARNING: Duplicate label: {label} (appears {count} times)')  
"

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

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

[code] # Clean build
rm -f .aux .bbl .blg .log .out .pdf
latexmk -pdf main.tex

# Or manual (triple pdflatex + bibtex for cross-references)  
pdflatex -interaction=nonstopmode main.tex  
bibtex main  
pdflatex -interaction=nonstopmode main.tex  
pdflatex -interaction=nonstopmode main.tex

# Verify output exists and has content  
ls -la main.pdf

[/code] Если компиляция не удалась : Проанализируйте .log файл на первую ошибку. Частые исправления: * "Undefined control sequence" → отсутствующий пакет или опечатка в имени команды * "Missing $ inserted" → математический символ вне математического режима * "File not found" → неверный путь к рисунку или отсутствующий .sty файл * "Citation undefined" → запись .bib отсутствует или bibtex не запущен

Шаг 7.6: Специфические требования конференций¶

Площадка	Особые требования
NeurIPS	Чек-лист статьи в приложении, краткое описание на простом языке в случае принятия
ICML	Заявление о более широком влиянии (после заключения, не учитывается в лимит страниц)
ICLR	Обязательное раскрытие использования LLM, соглашение о взаимном рецензировании
ACL	Обязательный раздел ограничений, чек-лист Responsible NLP
AAAI	Строгий стилевой файл — никаких модификаций
COLM	Формулировка вклада для сообщества языковых моделей
### Шаг 7.7: Повторная отправка на конференцию и конвертация формата
При конвертации между площадками никогда не копируйте преамбулы LaTeX между шаблонами:
[code]
# 1. Start fresh with target template
cp -r templates/icml2026/ new_submission/

# 2. Copy ONLY content sections (not preamble)  
#    - Abstract text, section content, figures, tables, bib entries

# 3. Adjust for page limits  
# 4. Add venue-specific required sections  
# 5. Update references

[/code] Откуда → Куда| Изменение объёма| Ключевые корректировки
---|---|---
NeurIPS → ICML| 9 → 8| Сократить на 1 страницу, добавить Broader Impact
ICML → ICLR| 8 → 9| Расширить эксперименты, добавить раскрытие LLM
NeurIPS → ACL| 9 → 8| Перестроить для конвенций NLP, добавить Limitations
ICLR → AAAI| 9 → 7| Значительные сокращения, строгое соблюдение стиля
Любая → COLM| разный → 9| Переформулировать для фокуса на языковых моделях
При сокращении страниц: перенесите доказательства в приложение, сожмите обзор родственных работ, объедините таблицы, используйте подфигуры. При расширении: добавьте абляции, расширьте ограничения, включите дополнительные baseline'ы, добавьте качественные примеры. После отклонения : Ответьте на замечания рецензентов в новой версии, но не включайте раздел «изменения» и не ссылайтесь на предыдущую отправку (слепое рецензирование).

Шаг 7.8: Подготовка camera-ready (после принятия)¶

После принятия подготовьте финальную версию: [code] Camera-Ready Checklist:
- [ ] De-anonymize: add author names, affiliations, email addresses
- [ ] Add Acknowledgments section (funding, compute grants, helpful reviewers)
- [ ] Add public code/data URL (real GitHub, not anonymous)
- [ ] Address any mandatory revisions from meta-reviewer
- [ ] Switch template to camera-ready mode (if applicable — e.g., AAAI \anon → \camera)
- [ ] Add copyright notice if required by venue
- [ ] Update any "anonymous" placeholders in text
- [ ] Verify final PDF compiles cleanly
- [ ] Check page limit for camera-ready (sometimes differs from submission)
- [ ] Upload supplementary materials (code, data, appendix) to venue portal

[/code]

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

Публикация на arXiv является стандартной практикой в ML, но имеет важные соображения по времени и анонимности. Дерево решений по времени: Ситуация| Рекомендация
---|---
Отправка в площадку с двойным слепым рецензированием (NeurIPS, ICML, ACL)| Публикуйте на arXiv после дедлайна отправки, не до. Публикация до может технически нарушать политику анонимности, хотя применение варьируется.
Отправка в ICLR| ICLR явно разрешает публикацию на arXiv до отправки. Но не указывайте имена авторов в самой отправке.
Статья уже на arXiv, отправка в новую площадку| Допустимо на большинстве площадок. НЕ обновляйте arXiv-версию во время рецензирования изменениями, ссылающимися на рецензии.
Воркшоп-статья| arXiv подходит в любое время — воркшопы обычно не используют двойное слепое рецензирование.
Хотите установить приоритет| Публикуйте немедленно, если есть риск, что вас опередят — но примите компромисс с анонимностью.
Выбор категории arXiv (ML/AI статьи): Категория| Код| Лучше всего подходит для
---|---|---
Machine Learning| cs.LG| Общие методы ML
Computation and Language| cs.CL| NLP, языковые модели
Artificial Intelligence| cs.AI| Рассуждение, планирование, агенты
Computer Vision| cs.CV| Модели зрения
Information Retrieval| cs.IR| Поиск, рекомендации
Укажите основную + 1-2 перекрёстные категории. Больше категорий = больше видимость, но указывайте перекрёстные только там, где это действительно релевантно. Стратегия версионирования: * v1 : Первоначальная отправка (соответствует отправке на конференцию) * v2 : После принятия с camera-ready исправлениями (добавьте «accepted at [Venue]» в аннотацию) * Не публикуйте v2 в период рецензирования с изменениями, которые явно отвечают на отзывы рецензентов

[code] # Check if your paper's title is already taken on arXiv
# (before choosing a title)
pip install arxiv
python -c "
import arxiv
results = list(arxiv.Search(query='ti:\"Your Exact Title\"', max_results=5).results())
print(f'Found {len(results)} matches')
for r in results: print(f' {r.title} ({r.published.year})')
"

[/code]

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

Выпуск чистого, воспроизводимого кода значительно увеличивает цитирования и доверие рецензентов. Пакуйте код вместе с camera-ready отправкой. Структура репозитория: [code] your-method/
README.md # Setup, usage, reproduction instructions
requirements.txt # Or environment.yml for conda
setup.py # For pip-installable packages
LICENSE # MIT or Apache 2.0 recommended for research
configs/ # Experiment configurations
src/ # Core method implementation
scripts/ # Training, evaluation, analysis scripts
train.py
evaluate.py
reproduce_table1.sh # One script per main result
data/ # Small data or download scripts
download_data.sh
results/ # Expected outputs for verification

[/code] Шаблон README для исследовательского кода: [code] # [Paper Title]

Official implementation of "[Paper Title]" (Venue Year).

## Setup  
[Exact commands to set up environment]

## Reproduction  
To reproduce Table 1: `bash scripts/reproduce_table1.sh`  
To reproduce Figure 2: `python scripts/make_figure2.py`

## Citation  
[BibTeX entry]

[/code] Предрелизный чек-лист: [code] - [ ] Code runs from a clean clone (test on fresh machine or Docker)
- [ ] All dependencies pinned to specific versions
- [ ] No hardcoded absolute paths
- [ ] No API keys, credentials, or personal data in repo
- [ ] README covers setup, reproduction, and citation
- [ ] LICENSE file present (MIT or Apache 2.0 for max reuse)
- [ ] Results are reproducible within expected variance
- [ ] .gitignore excludes data files, checkpoints, logs

[/code] Анонимный код для отправки (до принятия): [code] # Use Anonymous GitHub for double-blind review
# https://anonymous.4open.science/
# Upload your repo → get an anonymous URL → put in paper

[/code]

Фаза 8: Результаты после принятия¶

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

Шаг 8.1: Конференционный постер¶

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

Шаг 8.2: Конференционный доклад / Spotlight¶

Если вам предоставили устный или spotlight доклад: Тип доклада| Длительность| Содержание
---|---|---
Spotlight| 5 мин| Проблема, подход, один ключевой результат. Репетируйте ровно до 5 минут.
Oral| 15-20 мин| Полная история: проблема, подход, ключевые результаты, абляции, ограничения.
Воркшоп-доклад| 10-15 мин| Адаптируйтесь под аудиторию воркшопа — может потребоваться больше контекста.
Правила дизайна слайдов: * Одна идея на слайд * Минимум текста — говорите детали вслух, не проецируйте их * Анимируйте ключевые рисунки для пошагового понимания * Включите слайд «ключевой вывод» в конце (вклад в одно предложение) * Подготовьте запасные слайды для ожидаемых вопросов

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

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

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

Воркшопы и короткие статьи¶

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

Воркшоп-статьи¶

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

ACL Short Papers и Findings¶

Площадки ACL имеют различные типы отправок: Тип| Страниц| Что ожидается
---|---|---
Long paper| 8| Полное исследование, сильные baseline'ы, абляции
Short paper| 4| Сфокусированный вклад: один чёткий тезис с доказательствами
Findings| 8| Солидная работа, которая немного не прошла на основную конференцию
Стратегия короткой статьи : Выберите ОДНО утверждение и тщательно его обоснуйте. Не пытайтесь сжать длинную статью в 4 страницы — напишите другую, более сфокусированную статью.

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

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

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

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

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

Обзорные / Обучающие статьи¶

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

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

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

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

Структура : Введение → Предыстория → Тезис / Аргумент → Подтверждающие доказательства → Контраргументы → Следствия Ключевые отличия: * Вклад — это аргумент, а не результат * Должен серьёзно рассматривать контраргументы * Доказательства могут быть эмпирическими, теоретическими или логическим анализом * Лучшие площадки: ICML (position track), воркшопы, TMLR

Интеграция с Hermes Agent¶

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

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

Комбинируйте этот навык с другими навыками Hermes для конкретных фаз: Навык| Когда использовать| Как загрузить
---|---|---
arxiv| Фаза 1 (Обзор литературы): поиск на arXiv, генерация BibTeX, поиск связанных статей через Semantic Scholar| skill_view("arxiv")
subagent-driven-development| Фаза 5 (Написание): параллельное написание разделов с 2-этапным рецензированием (соответствие спецификации, затем качество)| 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`	Уведомляйте пользователя, когда эксперименты завершены или черновики готовы, даже если пользователь не в чате.
### Шаблоны использования инструментов
Мониторинг экспериментов (самый распространённый):
[code]
terminal("ps aux	grep ")
→ terminal("tail -30 ")
→ terminal("ls results/")
→ execute_code("analyze results JSON, compute metrics")
→ terminal("git add -A && git commit -m '' && git push")
→ send_message("Experiment complete: ")

[/code] Параллельное написание разделов (с использованием делегирования): [code] delegate_task("Draft the Methods section based on these experiment scripts and configs.
Include: pseudocode, all hyperparameters, architectural details sufficient for
reproduction. Write in LaTeX using the neurips2025 template conventions.")

delegate_task("Draft the Related Work section. Use web_search and web_extract to   
  find papers. Verify every citation via Semantic Scholar. Group by methodology.")

delegate_task("Draft the Experiments section. Read all result files in results/.   
  State which claim each experiment supports. Include error bars and significance.")

[/code] Каждый делегат запускается как новый подагент без общего контекста — предоставьте всю необходимую информацию в промпте. Соберите результаты и интегрируйте их. Верификация цитирований (с использованием execute_code): [code] # In 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)

[/code]

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

Инструмент memory — сохраняйте ключевые решения (ограничение: ~2200 символов для MEMORY.md): [code] memory("add", "Paper: autoreason. Venue: NeurIPS 2025 (9 pages).
Contribution: structured refinement works when generation-evaluation gap is wide.
Key results: Haiku 42/42, Sonnet 3/5, S4.6 constrained 2/3.
Status: Phase 5 — drafting Methods section.")

[/code] Обновляйте memory после крупных решений или переходов между фазами. Это сохраняется между сессиями. Инструмент todo — отслеживайте детальный прогресс: [code] todo("add", "Design constrained task experiments for Sonnet 4.6")
todo("add", "Run Haiku baseline comparison")
todo("add", "Draft Methods section")
todo("update", id=3, status="in_progress")
todo("update", id=1, status="completed")

[/code] Протокол запуска сессии: [code] 1. todo("list") # Check current task list
2. memory("read") # Recall key decisions
3. terminal("git log --oneline -10") # Check recent commits
4. terminal("ps aux | grep python") # Check running experiments
5. terminal("ls results/ | tail -20") # Check for new results
6. Report status to user, ask for direction

[/code]

Мониторинг через cron с помощью `cronjob`¶

Используйте инструмент cronjob для планирования периодических проверок экспериментов: [code] cronjob("create", {
"schedule": "/30 * * * ", # Every 30 minutes
"prompt": "Check experiment status:
1. ps aux | grep run_experiment
2. tail -30 logs/experiment_haiku.log
3. ls results/haiku_baselines/
4. If complete: read results, compute Borda scores,
git add -A && git commit -m 'Add Haiku results' && git push
5. Report: table of results, key finding, next step
6. If nothing changed: respond with [SILENT]"
})

[/code] Протокол [SILENT] : Когда с момента последней проверки ничего не изменилось, отвечайте ровно [SILENT]. Это подавляет доставку уведомлений пользователю. Сообщайте только когда есть реальные изменения, о которых стоит знать. Отслеживание дедлайнов: [code] cronjob("create", {
"schedule": "0 9 * * *", # Daily at 9am
"prompt": "NeurIPS 2025 deadline: May 22. Today is {date}.
Days remaining: {compute}.
Check todo list — are we on track?
If <7 days: warn user about remaining tasks."
})

[/code]

Паттерны коммуникации¶

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

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

Формат отчёта — всегда включайте структурированные данные: [code] ## Experiment:
Status: Complete / Running / Failed

| Task | Method A | Method B | Method C |  
|------|---------|---------|---------|  
| Task 1 | 85.2 | 82.1 | **89.4** |

Key finding: <one sentence>  
Next step: <what happens next>

[/code]

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

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

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

Понимание того, что ищут рецензенты, помогает сфокусировать усилия: Критерий| Что они проверяют
---|---
Качество| Техническая обоснованность, хорошо подтверждённые утверждения, честные baseline'ы
Ясность| Чёткое изложение, воспроизводимость экспертами, согласованные обозначения
Значимость| Влияние на сообщество, продвижение понимания
Оригинальность| Новые идеи (не требует нового метода)
Оценка (6-балльная шкала NeurIPS): * 6: Strong Accept — революционная, безупречная * 5: Accept — технически надёжная, высокое влияние * 4: Borderline Accept — надёжная, ограниченная оценка * 3: Borderline Reject — недостатки перевешивают * 2: Reject — технические недостатки * 1: Strong Reject — известные результаты или проблемы этики

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

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

Проблема	Решение
Аннотация слишком общая	Удалите первое предложение, если оно может предварять любую ML-статью. Начинайте с вашего конкретного вклада.
Введение превышает 1.5 страницы	Разделите предысторию на Related Work. Вынесите пункты вклада в начало.
Экспериментам не хватает явных утверждений	Добавьте: «Этот эксперимент проверяет, является ли [конкретное утверждение]...» перед каждым.
Рецензентам трудно следить за статьёй	Добавьте указатели, используйте согласованную терминологию, делайте подписи к рисункам самодостаточными.
Отсутствует статистическая значимость	Добавьте погрешности, количество запусков, статистические тесты, доверительные интервалы.
Расползание объёма экспериментов	Каждый эксперимент должен соответствовать конкретному утверждению. Удалите эксперименты, которые не соответствуют.
Статья отклонена, нужно переотправить	См. Повторная отправка на конференцию в Фазе 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	NeurIPS 16 пунктов, ICML, ICLR, ACL требования, универсальный предотправочный чек-лист
references/reviewer-guidelines.md	Критерии оценки, скоринг, распространённые проблемы, шаблон rebuttal'а
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 * Метаданные навыка * Справочник: полный SKILL.md * Когда использовать этот навык * Основная философия * Проактивность и сотрудничество * Фаза 0: Настройка проекта * Шаг 0.1: Исследуйте репозиторий * Шаг 0.2: Организуйте рабочее пространство * Шаг 0.3: Настройте контроль версий * Шаг 0.4: Определите вклад * Шаг 0.5: Создайте список TODO * Шаг 0.6: Оцените вычислительный бюджет * Шаг 0.7: Координация нескольких авторов * Фаза 1: Обзор литературы * Шаг 1.1: Определите ключевые статьи * Шаг 1.2: Поиск связанных работ * Шаг 1.2b: Углубление поиска (сначала вширь, затем вглубь) * Шаг 1.3: Проверьте каждое цитирование * Шаг 1.4: Организуйте related work * Фаза 2: Дизайн экспериментов * Шаг 2.1: Сопоставьте утверждения с экспериментами * Шаг 2.2: Разработайте baseline'ы * Шаг 2.3: Определите протокол оценки * Шаг 2.4: Напишите скрипты экспериментов * Шаг 2.5: Разработайте человеческую оценку (если применимо) * Фаза 3: Выполнение и мониторинг экспериментов * Шаг 3.1: Запустите эксперименты * Шаг 3.2: Настройте мониторинг (шаблон cron) * Шаг 3.3: Обработка сбоев * Шаг 3.4: Сохраните завершённые результаты * Шаг 3.5: Ведите журнал экспериментов * Фаза 4: Анализ результатов * Шаг 4.1: Агрегируйте результаты * Шаг 4.2: Статистическая значимость * Шаг 4.3: Определите историю * Шаг 4.4: Создайте рисунки и таблицы * Шаг 4.5: Решите: ещё эксперименты или писать? * Шаг 4.6: Напишите журнал экспериментов (мост к статье) * Итеративное улучшение: выбор стратегии * Быстрая таблица решений * Разрыв между генерацией и оценкой * Цикл Autoreason (кратко) * Применение к черновикам статей * Режимы отказа * Фаза 5: Написание статьи * Управление контекстом для больших проектов * Принцип повествования * Источники, стоящие за этим руководством * Распределение времени * Рабочий процесс написания * Двухпроходный шаблон улучшения * Чек-лист ошибок LaTeX * Шаг 5.0: Название * Шаг 5.1: Аннотация (формула из 5 предложений) * Шаг 5.2: Рисунок 1 * Шаг 5.3: Введение (макс. 1-1.5 страницы) * Шаг 5.4: Методы * Шаг 5.5: Эксперименты и результаты * Шаг 5.6: Related Work * Шаг 5.7: Ограничения (ОБЯЗАТЕЛЬНО) * Шаг 5.8: Заключение и обсуждение * Шаг 5.9: Стратегия приложения * Управление бюджетом страниц * Шаг 5.10: Заявление об этике и более широком влиянии * Шаг 5.11: Datasheets и Model Cards (если применимо) * Стиль написания * Использование шаблонов LaTeX * Ловушки шаблонов * Быстрый справочник по шаблонам * Таблицы и рисунки * Повторная отправка на конференцию * Профессиональная преамбула LaTeX * siunitx Выравнивание таблиц * Подфигуры * Псевдокод с algorithm2e * Шаблоны диаграмм TikZ * latexdiff для отслеживания правок * SciencePlots для matplotlib * Фаза 6: Саморецензирование и доработка * Шаг 6.1: Моделирование рецензий (ансамблевый шаблон) * Шаг 6.1b: Визуальный рецензионный проход (VLM) * Шаг 6.1c: Проход верификации утверждений * Шаг 6.2: Приоритизация обратной связи * Шаг 6.3: Цикл доработки * Шаг 6.4: Написание rebuttal'а * Шаг 6.5: Отслеживание эволюции статьи * Фаза 7: Подготовка к отправке * Шаг 7.1: Чек-лист конференции * Шаг 7.2: Чек-лист анонимизации * Шаг 7.3: Проверка форматирования * Шаг 7.4: Предкомпиляционная валидация * Шаг 7.5: Финальная компиляция * Шаг 7.6: Специфические требования конференций * Шаг 7.7: Повторная отправка на конференцию и конвертация формата * Шаг 7.8: Подготовка camera-ready (после принятия) * Шаг 7.9: Стратегия arXiv и препринтов * Шаг 7.10: Упаковка исследовательского кода * Фаза 8: Результаты после принятия * Шаг 8.1: Конференционный постер * Шаг 8.2: Конференционный доклад / Spotlight * Шаг 8.3: Пост в блоге / Социальные сети * Воркшопы и короткие статьи * Воркшоп-статьи * ACL Short Papers и Findings * Типы статей за пределами эмпирического ML * Теоретические статьи * Обзорные / Обучающие статьи * Статьи-бенчмарки * Позиционные статьи * Интеграция с Hermes Agent * Связанные навыки * Справочник инструментов Hermes * Шаблоны использования инструментов * Управление состоянием с помощью memory и todo * Мониторинг через cron с помощью cronjob * Паттерны коммуникации * Точки принятия решений, требующие ввода человека * Критерии оценки рецензентов * Распространённые проблемы и решения * Справочные документы * Шаблоны LaTeX * Ключевые внешние источники

Метаданные навыка​¶

Справка: полный SKILL.md​¶

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

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

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

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

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

Шаг 0.1: Изучение репозитория​¶

Шаг 0.2: Организация рабочего пространства​¶

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

Шаг 0.4: Определение вклада​¶

Шаг 0.5: Создание списка задач​¶

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

Шаг 0.7: Координация соавторов​¶

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

Шаг 1.1: Определение ключевых статей​¶

Шаг 1.2: Поиск связанных работ​¶

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

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

Шаг 1.4: Организация связанных работ​¶

Фаза 2: Проектирование эксперимента​¶

Шаг 2.1: Сопоставление утверждений с экспериментами​¶

Шаг 2.2: Разработка бейзлайнов​¶

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

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

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

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

Шаг 3.1: Запуск экспериментов​¶

Шаг 3.2: Настройка мониторинга (паттерн Cron)​¶

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

Шаг 3.4: Фиксация завершённых результатов​¶

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

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

Шаг 4.1: Агрегация результатов​¶

Шаг 4.2: Статистическая значимость​¶

Шаг 4.3: Определение истории​¶

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

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

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

Шаг 4.6: Написание журнала экспериментов (Мост к написанию)​¶

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

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

Разрыв генерация-оценка​¶

Цикл Autoreason (Кратко)​¶

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

Режимы сбоя​¶

Фаза 5: Написание статьи​¶

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

Принцип нарратива​¶

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

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

Рабочий процесс написания​¶

Паттерн двухпроходного уточнения​¶

Чеклист ошибок LaTeX​¶

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

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

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

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

Шаг 5.4: Методы​¶

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

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

Шаг 5.7: Ограничения (ОБЯЗАТЕЛЬНО)​¶

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

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

Управление страничным бюджетом​¶

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

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

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

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

Типичные ошибки с шаблонами​¶

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

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

Повторная отправка на конференцию​¶

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

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

Подфигуры​¶

Псевдокод с algorithm2e​¶

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

latexdiff для отслеживания правок​¶

SciencePlots для matplotlib​¶

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

Справка: полный SKILL.md¶

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

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

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

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

Шаг 0.1: Изучение репозитория¶

Шаг 0.2: Организация рабочего пространства¶

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

Шаг 0.4: Определение вклада¶

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

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

Шаг 0.7: Координация соавторов¶

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

Шаг 1.1: Определение ключевых статей¶

Шаг 1.2: Поиск связанных работ¶

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

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

Шаг 1.4: Организация связанных работ¶

Фаза 2: Проектирование эксперимента¶

Шаг 2.1: Сопоставление утверждений с экспериментами¶

Шаг 2.2: Разработка бейзлайнов¶

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

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

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

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

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

Шаг 3.2: Настройка мониторинга (паттерн Cron)¶

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

Шаг 3.4: Фиксация завершённых результатов¶

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

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

Шаг 4.1: Агрегация результатов¶

Шаг 4.2: Статистическая значимость¶

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

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

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

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

Шаг 4.6: Написание журнала экспериментов (Мост к написанию)¶

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

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

Разрыв генерация-оценка¶

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

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

Режимы сбоя¶

Фаза 5: Написание статьи¶

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

Принцип нарратива¶

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

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

Рабочий процесс написания¶

Паттерн двухпроходного уточнения¶

Чеклист ошибок LaTeX¶

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

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

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

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

Шаг 5.4: Методы¶

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

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

Шаг 5.7: Ограничения (ОБЯЗАТЕЛЬНО)¶

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

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

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

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

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

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

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

Типичные ошибки с шаблонами¶

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

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

Повторная отправка на конференцию¶

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

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

Подфигуры¶

Псевдокод с algorithm2e¶

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

latexdiff для отслеживания правок¶

SciencePlots для matplotlib¶

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