Написание научных статей

Статьи по ML для NeurIPS/ICML/ICLR: от замысла к подаче.

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


Источник	Встроенный (установлен по умолчанию)
Путь	`skills/research/research-paper-writing`
Версия	`1.1.0`
Автор	Orchestra Research
Лицензия	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

инфо

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

Конвейер написания научных статей

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

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

┌─────────────────────────────────────────────────────────────┐
│                    RESEARCH PAPER PIPELINE                  │
│                                                             │
│  Phase 0: Project Setup ──► Phase 1: Literature Review      │
│       │                          │                          │
│       ▼                          ▼                          │
│  Phase 2: Experiment     Phase 5: Paper Drafting ◄──┐      │
│       Design                     │                   │      │
│       │                          ▼                   │      │
│       ▼                    Phase 6: Self-Review      │      │
│  Phase 3: Execution &           & Revision ──────────┘      │
│       Monitoring                 │                          │
│       │                          ▼                          │
│       ▼                    Phase 7: Submission               │
│  Phase 4: Analysis ─────► (feeds back to Phase 2 or 5)     │
│                                                             │
└─────────────────────────────────────────────────────────────┘

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

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

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

Базовая философия

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

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

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

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

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

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

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

Цель: подготовить рабочее пространство, понять уже сделанное, определить вклад.

Шаг 0.1: Изучите репозиторий

# Understand project structure
ls -la
find . -name "*.py" | head -30
find . -name "*.md" -o -name "*.txt" | xargs grep -l -i "result\|conclusion\|finding"

Ищите:

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

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

Заведите единообразную структуру рабочего пространства:

workspace/
  paper/               # LaTeX source, figures, compiled PDFs
  experiments/         # Experiment runner scripts
  code/                # Core method implementation
  results/             # Raw experiment results (auto-generated)
  tasks/               # Task/benchmark definitions
  human_eval/          # Human evaluation materials (if needed)

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

git init  # if not already
git remote add origin <repo-url>
git checkout -b paper-draft  # or main

Дисциплина git: каждый завершённый пакет экспериментов коммитится с осмысленным сообщением. Пример:

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

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

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

Что: какую единственную вещь вносит эта статья?
Почему: какие данные это подкрепляют?
И что с того: почему это должно волновать читателей?

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

Шаг 0.5: Составьте список TODO

С помощью инструмента todo создайте структурированный план проекта:

Research Paper TODO:
- [ ] Define one-sentence contribution
- [ ] Literature review (related work + baselines)
- [ ] Design core experiments
- [ ] Run experiments
- [ ] Analyze results
- [ ] Write first draft
- [ ] Self-review (simulate reviewers)
- [ ] Revise based on review
- [ ] Submission prep

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

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

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

Compute Budget Checklist:
- [ ] API costs: (model price per token) × (estimated tokens per run) × (number of runs)
- [ ] GPU hours: (time per experiment) × (number of experiments) × (number of seeds)
- [ ] Human evaluation costs: (annotators) × (hours) × (hourly rate)
- [ ] Total budget ceiling and contingency (add 30-50% for reruns)

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

# 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")

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

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

У большинства статей от 3 до 10 авторов. Договоритесь о рабочих процессах заранее:

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

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

Author Coordination Checklist:
- [ ] Agree on section ownership (who writes what)
- [ ] Set up shared workspace (Overleaf or git repo)
- [ ] Establish notation conventions (before anyone writes)
- [ ] Schedule internal review rounds (not just at the end)
- [ ] Designate one person for final formatting pass
- [ ] Agree on figure style (colors, fonts, sizes) before creating figures

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

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

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

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

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

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

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

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

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

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

# 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")

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

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

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

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

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

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

Iterative Literature Search:

Round 1 (Breadth): 4-6 parallel queries covering different angles
  - "[method] + [domain]"
  - "[problem name] state-of-the-art 2024 2025"
  - "[baseline method] comparison"
  - "[alternative approach] vs [your approach]"
  → Collect papers, extract key concepts and terminology

Round 2 (Depth): Generate follow-up queries from Round 1 learnings
  - New terminology discovered in Round 1 papers
  - Papers cited by the most relevant Round 1 results
  - Contradictory findings that need investigation
  → Collect papers, identify remaining gaps

Round 3 (Targeted): Fill specific gaps
  - Missing baselines identified in Rounds 1-2
  - Concurrent work (last 6 months, same problem)
  - Key negative results or failed approaches
  → Stop when new queries return mostly papers you've already seen

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

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

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

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

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

Citation Verification (MANDATORY per citation):
1. SEARCH → Query Semantic Scholar or Exa MCP with specific keywords
2. VERIFY → Confirm paper exists in 2+ sources (Semantic Scholar + arXiv/CrossRef)
3. RETRIEVE → Get BibTeX via DOI content negotiation (programmatically, not from memory)
4. VALIDATE → Confirm the claim you're citing actually appears in the paper
5. ADD → Add verified BibTeX to bibliography
If ANY step fails → mark as [CITATION NEEDED], inform scientist

# 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

Если проверить цитату не удаётся:

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

Всегда сообщайте учёному: “Я пометил [X] цитат как заглушки, требующие проверки.”

Полную документацию по API и весь класс CitationManager см. в references/citation-workflow.md.

Шаг 1.4: Структурируйте обзор литературы

Группируйте статьи по методологии, а не по принципу «одна статья — один абзац»:

Хорошо: “Одно из направлений опирается на предположение X [refs], тогда как мы используем предположение Y, потому что…” Плохо: “Smith et al. предложили X. Jones et al. предложили Y. Мы объединяем оба.”

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

Цель: спроектировать эксперименты, прямо подкрепляющие утверждения статьи. Каждый эксперимент должен отвечать на конкретный вопрос.

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

Составьте явное сопоставление:

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

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

Шаг 2.2: Подберите базовые методы

Сильные baseline-ы — то, что отличает принятые статьи от отклонённых. Рецензенты спросят: “А сравнили ли они с X?”

Стандартные категории базовых методов:

Наивный baseline: простейший возможный подход
Сильный baseline: лучший известный существующий метод
Аблационные baseline-ы: ваш метод без одного компонента
Baseline-ы с равным compute: тот же бюджет вычислений, иное распределение

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

До запуска чего бы то ни было задайте:

Метрики: что вы измеряете, символы направления (больше/меньше — лучше)
Агрегация: как результаты сводятся по прогонам и задачам
Статистические тесты: какие тесты подтвердят значимость
Размеры выборок: сколько прогонов, задач, проблем

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

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

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

# 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)

Сохранение артефактов — храните все промежуточные выводы:

results/<experiment>/
  <task>/
    <strategy>/
      final_output.md          # Final result
      history.json             # Full trajectory
      pass_01/                 # Per-iteration artifacts
        version_a.md
        version_b.md
        critic.md

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

run_experiment.py              # Core experiment runner
run_baselines.py               # Baseline comparison
run_comparison_judge.py        # Blind evaluation
analyze_results.py             # Statistical analysis
make_charts.py                 # Visualization

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

Шаг 2.5: Спроектируйте оценку с участием людей (если применимо)

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

Когда нужна оценка людьми:

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

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

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

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

- [ ] Clear task description with examples (good AND bad)
- [ ] Decision criteria for ambiguous cases
- [ ] At least 2 worked examples per category
- [ ] Attention checks / gold standard items (10-15% of total)
- [ ] Qualification task or screening round
- [ ] Estimated time per item and fair compensation (>= local minimum wage)
- [ ] IRB/ethics review if required by your institution

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

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

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

Фаза 3: Проведение и мониторинг экспериментов

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

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

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

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

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

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

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

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

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

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

Частые режимы сбоев и восстановление:

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

Главное: скрипты должны всегда проверять наличие готовых результатов и пропускать уже сделанное. Так перезапуски безопасны и эффективны.

Шаг 3.4: Коммитьте готовые результаты

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

git add -A
git commit -m "Add <experiment name>: <key finding in 1 line>"
git push

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

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

// 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"]
}

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

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

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

cp experiment.py results/exp_003/experiment_snapshot.py

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

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

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

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

Пишите аналитические скрипты, которые:

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

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

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

Всегда считайте:

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

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

Шаг 4.3: Нащупайте историю

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

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

Что делать с негативными или нулевыми результатами

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

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

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

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

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

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

Рисунки:

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

Таблицы:

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

\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}

Шаг 4.5: Решите: ещё эксперименты или писать?

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

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

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

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

# 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]

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

Дисциплина git: коммитьте этот лог вместе с описываемыми им результатами.

Итеративная доработка: выбор стратегии

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

Таблица быстрого решения

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

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

Главная мысль: ценность autoreason зависит от разрыва между способностью модели генерировать и её способностью себя оценивать.

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

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

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

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

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

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

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

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

При доработке самой статьи через autoreason:

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

Режимы сбоев

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

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

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

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

Управление контекстом для крупных проектов

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

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

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

Принципы:

experiment_log.md — главный мост контекста: он подытоживает всё нужное для написания, не загружая сырые файлы данных (см. шаг 4.6)
Загружайте контекст одного раздела за раз при делегировании. Субагенту, пишущему «Методы», не нужны заметки по обзору литературы.
Подытоживайте, а не включайте сырые файлы. Для result-JSON на 200 строк загрузите сводную таблицу на 10 строк. Для связанной статьи на 50 страниц — аннотацию из 5 предложений плюс вашу заметку на 2 строки о её релевантности.

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

context/
  contribution.md          # 1 sentence
  experiment_summary.md    # Key results table (from experiment_log.md)
  literature_map.md        # Organized citation notes
  figure_inventory.md      # List of figures with descriptions

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

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

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

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

Опора	Описание	Проверка
Что	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 — полная библиография

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

Тратьте примерно поровну на каждое из:

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

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

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

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

Паттерн доработки в два прохода

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

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

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

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."

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

Добавляйте этот чек-лист к каждому промпту доработки. Вот самые частые ошибки LLM при написании LaTeX:

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 (</end{figure}> 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

Шаг 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):

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

Удаляйте общие зачины вроде “Large language models have achieved remarkable success…”

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

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

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

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

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

Должно включать:

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

Шаг 5.4: Методы

Дайте возможность переписать реализацию:

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

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

Для каждого эксперимента явно укажите:

Какое утверждение он подкрепляет
Как он связан с основным вкладом
На что смотреть: “синяя линия показывает X, что демонстрирует Y”

Требования:

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

Шаг 5.6: Обзор литературы

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

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

Этого требуют все крупные конференции. Честность помогает:

Рецензентам предписано не наказывать за честное признание ограничений
Опередите критику, назвав слабости первыми
Объясните, почему ограничения не подрывают основные утверждения

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

Заключение (обязательно, 0.5-1 страница):

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

Обсуждение (опционально, иногда объединяется с заключением):

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

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

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

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

Раздел приложения	Что сюда идёт
Доказательства и выводы	Полные доказательства, слишком длинные для основного текста. В тексте можно дать теоремы с пометкой «доказательство в приложении A».
Дополнительные эксперименты	Аблации, кривые масштабирования, разбивки по датасетам, чувствительность к гиперпараметрам
Детали реализации	Полные таблицы гиперпараметров, детали обучения, характеристики железа, random seed-ы
Документация датасета	Процесс сбора данных, инструкции аннотаторам, лицензирование, предобработка
Промпты и шаблоны	Точные использованные промпты (для методов на основе 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 страницы	Высокий — рисунки должны оставаться читаемыми

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

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

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

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

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

Как писать заявление:

\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].

Частые ошибки:

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

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

# 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")

Шаг 5.11: Datasheet-ы и Model Card-ы (если применимо)

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

Datasheets for Datasets (Gebru et al., 2021) — в приложение:

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?

Model Cards (Mitchell et al., 2019) — в приложение при выпуске модели:

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

Стиль письма

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

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

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

Будьте конкретны: «accuracy», а не «performance»
Уберите хеджирование: бросьте «may», если нет настоящей неопределённости
Единая терминология на протяжении всей статьи
Избегайте инкрементальной лексики: «develop», а не «combine»

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

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

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

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

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

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

Копируйте ВЕСЬ каталог, а не только файл .tex. В шаблоны входят файлы стилей (.sty), стили библиографии (.bst), примеры содержимого и Makefile-ы.

Шаг 2: Сначала проверьте компиляцию шаблона

Прежде чем вносить ЛЮБЫЕ изменения:

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

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

Шаг 3: Держите содержимое шаблона как образец

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

% 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}

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

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

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

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

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

Подводный камень	Проблема	Решение
Скопирован только файл `.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/. Настройку компиляции (VS Code, CLI, Overleaf, другие IDE) см. в templates/README.md.

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

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

\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}

Правила:

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

Рисунки:

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

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

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

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

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

% --- 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}

Примечания:

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

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

siunitx заметно улучшает читаемость таблиц с большим числом чисел:

\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}

Тип столбца S автоматически выравнивает по десятичной точке. Заголовки в {} выходят из-под выравнивания.

Подрисунки

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

\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}

\cref{fig:results} → “Figure 1”, \cref{fig:results-a} → “Figure 1a”.

Псевдокод через algorithm2e

\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*{Initial generation}
$\text{streak} \gets 0$\;
\While{$\text{streak} < k$}{
  $C \gets \text{Critic}(A, T)$ \tcp*{Identify weaknesses}
  $B \gets M(T, C)$ \tcp*{Revised version addressing critique}
  $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*{Blind ranking}
  }
  $\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}

Паттерны диаграмм TikZ

TikZ — стандарт для схем методов в статьях по ML. Частые паттерны:

Конвейерная/потоковая диаграмма (самая частая в статьях по ML):

\begin{figure}[t]
\centering
\begin{tikzpicture}[
  node distance=1.8cm,
  box/.style={rectangle, draw, rounded corners, minimum height=1cm, 
              minimum width=2cm, align=center, font=\small},
  arrow/.style={-{Stealth[length=3mm]}, thick},
]
  \node[box, fill=okcyan!20] (input) {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}

Сравнительная/матричная диаграмма (для показа вариантов метода):

\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}

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

\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}

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

Незаменим для rebuttal-ов — генерирует PDF с разметкой изменений между версиями:

# 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

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

SciencePlots для matplotlib

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

pip install SciencePlots

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

Стандартные размеры рисунков (двухколоночный формат):

Одна колонка: 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 хорошо задокументирована позитивная предвзятость при оценке.

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
}

Шаг 2: Мета-рецензия (агрегация уровня Area Chair)

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

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]
...

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

Каждый рецензент может уточнить рецензию, увидев мета-рецензию. Используйте сигнал ранней остановки: если рецензент отвечает “I am done” (без изменений), прекращайте итерации.

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

Few-shot-калибровка: при наличии включите 1-2 реальных опубликованных рецензии с целевой площадки как примеры. Это резко улучшает калибровку оценок. Примеры рецензий см. в references/reviewer-guidelines.md.

Шаг 6.1b: Проход визуальной проверки (VLM)

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

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.

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

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

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

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]

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

Шаг 6.2: Расставьте приоритеты по фидбэку

Собрав рецензии, рассортируйте их:

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

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

Для каждой критической/высокоприоритетной проблемы:

Определите затронутые разделы
Набросайте исправление
Убедитесь, что оно не ломает другие утверждения
Обновите статью
Перепроверьте по замечанию рецензента

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

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

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

> 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.

Правила:

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

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

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

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

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

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

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

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

У каждой площадки есть обязательные чек-листы. Заполняйте их внимательно — незаполненный чек-лист может привести к отклонению на столе редактора.

См. references/checklists.md для:

чек-листа NeurIPS из 16 пунктов
broader impact + воспроизводимость ICML
политики раскрытия LLM на ICLR
обязательного раздела ограничений ACL
универсального чек-листа перед подачей

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

Двойное слепое рецензирование означает, что рецензенты не должны знать автора. Проверьте ВСЁ из этого:

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

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

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

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.)

Шаг 7.4: Валидация перед компиляцией

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

# 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)')
"

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

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

# 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

Если компиляция падает: найдите в файле .log первую ошибку. Частые исправления:

“Undefined control sequence” → нет пакета или опечатка в имени команды
“Missing $ inserted” → математический символ вне математического режима
“File not found” → неверный путь к рисунку или нет файла .sty
“Citation undefined” → нет записи .bib или не запущен bibtex

Шаг 7.6: Требования конкретных конференций

Площадка	Особые требования
NeurIPS	Чек-лист статьи в приложении, lay summary при принятии
ICML	Broader Impact Statement (после заключения, не считается в лимит)
ICLR	Требуется раскрытие LLM, взаимное соглашение о рецензировании
ACL	Обязательный раздел Limitations, Responsible NLP checklist
AAAI	Строгий файл стиля — никаких модификаций
COLM	Сформулируйте вклад для сообщества языковых моделей

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

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

# 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

Из → В	Изменение объёма	Ключевые правки
NeurIPS → ICML	9 → 8	Срезать 1 страницу, добавить Broader Impact
ICML → ICLR	8 → 9	Расширить эксперименты, добавить раскрытие LLM
NeurIPS → ACL	9 → 8	Перестроить под NLP-конвенции, добавить Limitations
ICLR → AAAI	9 → 7	Значительные сокращения, строгое следование стилю
Любая → COLM	varies → 9	Переформулировать с фокусом на языковые модели

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

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

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

После принятия подготовьте camera-ready-версию:

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

Шаг 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 в период рецензирования с правками, явно отвечающими на фидбэк рецензентов

# 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})')
"

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

Выпуск чистого, запускаемого кода заметно повышает цитируемость и доверие рецензентов. Упаковывайте код вместе с camera-ready-подачей.

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

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

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

# [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 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

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

# Use Anonymous GitHub for double-blind review
# https://anonymous.4open.science/
# Upload your repo → get an anonymous URL → put in paper

Фаза 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 минут.
Устный	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) идут по тому же конвейеру, но с другими ограничениями и ожиданиями.

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

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

Когда целиться в воркшоп:

Ранняя идея, по которой хотите фидбэк до полной статьи
Негативный результат, не оправдывающий 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 (трек обзоров), JMLR, Foundations and Trends in ML, ACM Computing Surveys

Бенчмарковые статьи

Структура: Введение → Определение задачи → Построение датасета → Оценка baseline-ов → Анализ → Назначение и ограничения

Ключевые отличия:

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

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

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

Ключевые отличия:

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

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

Этот навык рассчитан на агента Hermes. Он задействует инструменты 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 для интерактивного анализа и визуализации	`skill_view("data-science")`

Этот навык вытесняет 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`	Правка статьи, скрипты экспериментов, файлы результатов. Для точечных правок крупных .tex используйте `patch`.
`web_search`	Поиск литературы: `web_search("transformer attention mechanism 2024")`
`web_extract`	Получение содержимого статьи, проверка цитат: `web_extract("https://arxiv.org/abs/2303.17651")`
`delegate_task`	Параллельный черновик разделов — порождение изолированных субагентов для каждого раздела. Также для параллельной проверки цитат.
`todo`	Главный трекер состояния между сессиями. Обновляйте после каждого перехода между фазами.
`memory`	Сохранение ключевых решений между сессиями: формулировка вклада, выбор площадки, фидбэк рецензентов.
`cronjob`	Планирование мониторинга экспериментов, обратного отсчёта до дедлайна, автоматических проверок arXiv.
`clarify`	Задать пользователю точечные вопросы при затыке (выбор площадки, формулировка вклада).
`send_message`	Уведомить пользователя о завершении экспериментов или готовности черновиков, даже если его нет в чате.

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

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

terminal("ps aux | grep <pattern>")
→ terminal("tail -30 <logfile>")
→ terminal("ls results/")
→ execute_code("analyze results JSON, compute metrics")
→ terminal("git add -A && git commit -m '<descriptive message>' && git push")
→ send_message("Experiment complete: <summary>")

Параллельный черновик разделов (через делегирование):

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.")

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

Проверка цитат (через execute_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)

Управление состоянием через `memory` и `todo`

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

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.")

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

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

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")

Протокол начала сессии:

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

Мониторинг через cron с `cronjob`

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

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]"
})

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

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

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."
})

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

Когда уведомлять пользователя (через send_message или прямой ответ):

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

Когда НЕ уведомлять:

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

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

## Experiment: <name>
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>

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

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

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

НЕ спрашивайте про (действуйте на опережение, выбирайте сами, помечайте):

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

Критерии оценки рецензентами

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

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

Шкала оценок (6-балльная шкала NeurIPS):

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

Подробные рекомендации, частые замечания и стратегии rebuttal-а см. в references/reviewer-guidelines.md.

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

Проблема	Решение
Слишком общая аннотация	Удалите первое предложение, если оно подошло бы любой ML-статье. Начните со своего конкретного вклада.
Введение длиннее 1.5 страницы	Вынесите предысторию в обзор литературы. Вынесите буллеты вклада вперёд.
Эксперименты без явных утверждений	Добавьте «Этот эксперимент проверяет, [конкретное утверждение]…» перед каждым.
Рецензентам трудно следить за статьёй	Добавьте указатели, используйте единую терминологию, делайте подписи рисунков самодостаточными.
Нет статистической значимости	Добавьте полосы погрешностей, число прогонов, статистические тесты, доверительные интервалы.
Расползание области в экспериментах	Каждый эксперимент должен сопоставляться с конкретным утверждением. Уберите те, что не сопоставляются.
Статью отклонили, нужна повторная подача	См. Повторную подачу в Фазе 7. Устраните замечания, не ссылаясь на рецензии.
Нет заявления о broader impact	См. Шаг 5.10. Большинство площадок его требуют. «Нет негативного воздействия» почти никогда не убедительно.
Человеческую оценку сочли слабой	См. Шаг 2.5 и references/human-evaluation.md. Сообщайте метрики согласия, детали аннотаторов, оплату.
Рецензенты сомневаются в воспроизводимости	Выпустите код (Шаг 7.9), задокументируйте все гиперпараметры, укажите seed-ы и детали вычислений.
Теоретической статье не хватает интуиции	Добавьте наброски доказательств с пояснениями на простом языке перед формальными доказательствами. См. 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, выбор стратегии, руководство по моделям, промпты, ограничения области, подсчёт Борда
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.

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

Философия письма:

API: Semantic Scholar | CrossRef | arXiv

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