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

Написание статей по 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

к сведению

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

Ищите:

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

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

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

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

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

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

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

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

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

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

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

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

Шаг 0.5: Создайте список задач

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

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 сида, подмножество задач), прежде чем переходить к полным прогонам. Используйте более дешевые модели для отладки конвейеров, затем переключайтесь на целевые модели для финальных запусков.

Шаг 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{} vs \citep{}
• Математическая нотация: строчные жирные для векторов, прописные жирные для матриц и т.д.
• Британское vs американское написание

---

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

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

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

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

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

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

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

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

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

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

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

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

Рекомендуется: Установите 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 параллельных запросов, охватывающих разные углы
  - "[метод] + [домен]"
  - "[название проблемы] современное состояние 2024 2025"
  - "[базовый метод] сравнение"
  - "[альтернативный подход] vs [ваш подход]"
  → Собрать статьи, извлечь ключевые концепции и терминологию

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

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

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

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

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

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

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

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

# 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 [ссылки], тогда как мы используем предположение Y, потому что...» Плохо: «Смит и др. представили X. Джонс и др. представили Y. Мы объединяем оба.»

---

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

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

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

Создайте явное сопоставление:

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

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

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

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

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

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

Шаг 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) ожидают этого для задач генерации

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

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

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

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

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

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

Полное руководство, включая статистические тесты для данных человеческой оценки, паттерны контроля качества краудсорсинга и рекомендации по 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. 4+ одновременных эксперимента на одном 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: Агрегируйте результаты

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

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

# 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: Определите историю

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

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