Дерево гипотез: от проблемы к эксперименту
Коротко: что делать
-
Если код исследования уже есть, подготовьте рабочую папку:
репозиторий с кодом должен лежать рядом с папкой
ResearcherOS. См. как установить ResearcherOS рядом с кодом. -
Откройте чат с помощником на основе искусственного интеллекта
(ИИ-помощником) и попросите запустить
сценарий подключения проекта
(
koi-project-onboard). Он изучит код и научные работы по теме, затем будет задавать по одному вопросу о проблеме, предполагаемой причине и способе проверки. - Отвечайте на вопросы и подтверждайте формулировки. После подтверждения помощник запишет дерево: проблема → причина → ожидаемое свидетельство или вмешательство → метод.
- Откройте дерево в ResearcherOS и проверьте, что цепочка передаёт вашу постановку. Затем переходите к уроку «Постановка эксперимента».
Научное знание получают разными способами. Наблюдение, эксперимент, построение моделей, индуктивные и дедуктивные рассуждения, проверка гипотез используются в разных сочетаниях; единого метода, одинакового для всех наук, нет.
ResearcherOS выбирает одну рабочую рамку — критическую проверку гипотез, близкую к фальсификационизму Карла Поппера. Исследователь формулирует объяснение так, чтобы оно допускало проверку и возможное опровержение: «наблюдаем X; предполагаем причину Y; если Y верна, ожидаем Z; проверяем это способом M».
Успешная проверка не доказывает гипотезу окончательно. Она лишь даёт основания временно её поддержать. Неожиданный результат тоже требует разбора: ошибаться могут гипотеза, вспомогательные допущения, измерение или сам эксперимент.
В ResearcherOS каждый эксперимент должен быть связан с такой цепочкой. Это проектное правило системы, а не утверждение, что вся наука обязана работать только так. По мере новых результатов исследователь пересматривает причины, добавляет проверки и постепенно приближается к объяснению явления или решению проблемы.
Подробнее о границах этой рамки: Scientific Method и Karl Popper в Стэнфордской энциклопедии философии.
В этом уроке разберём, как построить дерево гипотез для своей проблемы и как поручить первичную сборку дерева сценарию ResearcherOS.
1. Как научный метод устроен в ResearcherOS
Исследование хранится как дерево связанных утверждений. Корень фиксирует проблему. От него отходят предполагаемые причины, от причин — ожидаемые свидетельства или возможные вмешательства, затем методы и отдельные эксперименты. Ветви позволяют проверять несколько объяснений одной проблемы, не смешивая их в одном выводе.
flowchart TD
P[Проблема] --> C1[Предполагаемая причина]
P --> C2[Другая предполагаемая причина]
C1 --> E[Ожидаемое свидетельство]
C1 --> R[Вмешательство]
E --> M1[Метод проверки]
R --> M2[Метод проверки]
M1 --> X1[Эксперимент]
M2 --> X2[Эксперимент]
X1 --> V[Рабочий вердикт по причине]
X2 -. учитывается вместе со свидетельствами .-> V
Таблица понятий
| Понятие | Роль в исследовании |
|---|---|
| Проблема | Наблюдаемое явление или практическое затруднение, которое нужно объяснить либо устранить. Техническое название: problem. |
| Причина | Проверяемое предположение о механизме, порождающем проблему. Здесь хранится рабочий вердикт. Техническое название: cause. |
| Ожидаемое свидетельство | Наблюдение, которое должно быть получено, если предполагаемая причина верна. Техническое название: cause_evidence. |
| Вмешательство | Изменение системы, которое должно ослабить проблему, если представление о причине верно. Неудача вмешательства сама по себе не опровергает причину. Техническое название: remediation. |
| Метод | Протокол проверки: что меняется, что контролируется, что измеряется и по какому правилу интерпретируется результат. Техническое название: method. |
| Эксперимент | Отдельный запуск или анализ, оформленный карточкой на доске задач. |
| Вердикт | Рабочее состояние причины: получила поддержку (supported), отклонена в рамках текущей проверки (refuted) или остаётся открытой (open). Это вывод внутри проекта, а не окончательное доказательство истины или ложности. |
Результат вмешательства и свидетельство причины отвечают на разные вопросы. Если вмешательство помогло, это поддерживает его полезность. Чтобы судить о самой причине, нужны прямые свидетельства и проверка вспомогательных допущений.
2. Как сценарий подключения собирает дерево
Сценарий подключения проекта (koi-project-onboard)
предназначен для репозитория, в котором уже есть код, но ещё нет дерева
исследования. Он не придумывает постановку по одному описанию и не
записывает файлы без согласия исследователя.
Сначала помощник изучает код: какую задачу решает проект, что уже меняют в экспериментах и какие проверки запускают. Затем он просматривает близкие работы, чтобы сопоставить формулировку проблемы и возможные причины с литературой. После этого ведёт послойный научный диалог и задаёт по одному вопросу.
Исследовательская программа — необязательная организационная группа для нескольких проектов, связанных одной долгосрочной темой. Она помогает группировать проекты в интерфейсе, но не входит в причинную ветвь дерева.
flowchart TD
A[Репозиторий с кодом] --> B[Обзор кода]
B --> C[Сверка с литературой]
C --> D[Проблема]
D --> E[Принадлежность к программе, если она есть]
E --> F[Предполагаемая причина]
F --> G[Ожидаемое свидетельство или вмешательство]
G --> H[Метод]
H --> I[Проверка понятности]
I --> J[Подтверждение исследователя]
J --> K[Запись дерева]
На этапе причины помощник обязательно спрашивает, какой результат заставит отказаться от объяснения. Затем уточняет, какое свидетельство ожидается или какое вмешательство должно помочь. На этапе метода фиксирует сравнение, контроль, основной измеряемый показатель и правило решения. Перед записью короткие заголовки проверяются с позиции читателя, который не знает проект.
Как вызвать сценарий
Откройте рабочую папку, где рядом лежат ResearcherOS и репозиторий с кодом, затем напишите помощнику:
Подключи <путь-к-репозиторию> к ResearcherOS.
Помоги построить дерево исследования.
Изучи код и близкую литературу, затем пройди по слоям:
проблема, программа, причина, ожидаемое свидетельство
или вмешательство, метод.
Задавай по одному вопросу.
Не записывай файлы без моего подтверждения.
Следуй сценарию koi-project-onboard до конца.3. Пример: исследование агента для ARC-AGI-3
ARC-AGI-3 — набор интерактивных заданий для оценки программ, которые самостоятельно исследуют среду и выбирают действия. В новых абстрактных пошаговых средах нет явных инструкций: программа должна вывести цель, построить внутреннюю модель происходящего и спланировать действия.
Официальная оценка учитывает достижение цели и число затраченных действий; сто процентов означают, что программа решила все задания не менее эффективно, чем люди. В техническом отчёте ARC-AGI-3 указано, что на момент запуска в марте 2026 года передовые модели получали по этой оценке менее одного процента.
Само соревнование задаёт область и способ оценки, но не готовую проблему для нашего проекта. Исследователю ещё нужно решить, какой разрыв он хочет объяснить и какое утверждение проект будет проверять.
От описания соревнования к проблеме
Начать можно с вопроса: «Какой наблюдаемый разрыв между человеком и агентом мы хотим объяснить?» Например, нас интересует не любой проигрыш, а неэффективное освоение новой среды при ограниченном числе действий.
Ниже — одна возможная ветвь. Это пример исследовательской постановки, а не установленное объяснение результатов ARC-AGI-3.
Агенты неэффективно осваивают новые среды
В незнакомых интерактивных средах без инструкций агенты тратят больше действий, чем люди, и реже достигают цели.
Агенты не строят устойчивую модель среды
Предполагаем, что агент плохо связывает наблюдения и действия в модель, которая предсказывает переходы, цель и последствия следующего шага.
Предсказания переходов расходятся с наблюдениями
Если причина верна, агент будет систематически ошибаться в прогнозе следующего состояния после известных действий; качество прогноза должно быть связано с успехом в игре.
Сравнить прогнозы переходов с наблюдениями
На записанных последовательностях агент сначала предсказывает следующее состояние, а затем его прогноз сравнивается с фактическим состоянием среды.
Явная модель мира обновляется после действий
После каждого действия агент сохраняет состояние, выбранное действие и наблюдаемый переход, затем исправляет свою модель среды.
Сравнить агента с моделью мира и без
Две одинаково настроенные копии базового агента проходят один набор новых сред: одна использует явную модель мира, другая — нет. Для обеих копий среды ранее не встречались, начальное состояние памяти сброшено, бюджет действий и случайные условия совпадают. Сравниваются доля решённых сред и число действий относительно человеческого уровня.
Рост результата поддержит эффективность вмешательства. Отсутствие роста не опровергнет причину автоматически: сначала нужно проверить качество построенной модели мира и остальные допущения метода.
Пример запуска сценария
Если код агента уже лежит в отдельном репозитории, можно начать так:
Подключи <путь-к-репозиторию-агента> к ResearcherOS.
Проект исследует агентов для ARC-AGI-3.
Используй официальное описание набора заданий как исходный контекст,
но не копируй его как проблему проекта.
Помоги выяснить:
— какой наблюдаемый разрыв мы объясняем;
— какую причину предполагаем;
— после какого результата будем готовы отказаться от неё
в рамках этого проекта.
Задавай по одному вопросу и не записывай дерево
без моего подтверждения.
Следуй сценарию koi-project-onboard.Помощник не должен сразу принять примерную ветвь выше. Он сопоставит её с кодом, литературой и ответами исследователя; итоговая постановка может оказаться другой.