TL;DR
Multiple-rollout cruxes — это способ найти, от каких именно вопросов зависит вывод модели. Нужно прогнать один и тот же запрос несколько раз независимо, затем сравнить ответы попарно. Развилка (crux, «ключевой вопрос») — это вопрос, по которому два прогона заняли разные стороны: один счёл, что ставка не снизится из-за инфляции, другой — что снизится из-за замедления экономики.
Главная находка: модель не умеет заранее назвать, где её собственные ответы разойдутся. Попросите «назови ключевые факторы этого решения» — и список окажется не связан с тем, на чём реально расходятся прогоны. В исследовании он совпадал с реальными развилками хуже, чем случайный набор. Причина в том, что список «важных факторов» — это правдоподобный текст, а не замер собственной неопределённости. Развилки живут в распределении ответов, а не в одном ответе. Один прогон, разобранный по следам рассуждения, помогает заметно лучше, но всё равно пропускает много развилок.
Метод для важных решений: 3 шага — сделать N независимых прогонов, сравнить пары и вытащить вопросы «да/нет», по которым они расходятся, а затем сгруппировать перефразированные дубли. Дёшево (спросить заранее) и средне (один прогон) — недостаточно, если цена ошибки высока.
Схема метода
ШАГ 1: N независимых прогонов одного запроса (разные чаты) → N ответов с рассуждением
ШАГ 2: Каждую пару ответов сравнить → список вопросов «да/нет»,
где стороны разошлись + ответ каждой стороны
(сравнивать даже те пары, где итог одинаковый)
ШАГ 3: Сгруппировать перефразы одного и того же вопроса → частота каждой развилки
Шаги 2–3 — отдельные запросы к LLM. Шаг 1 — несколько чистых чатов или запусков.
Пример применения
Задача: Владелец небольшого производства в Новосибирске решает, брать ли кредит на станок сейчас или ждать снижения ключевой ставки ЦБ. Он спрашивает у ChatGPT: «Снизит ли ЦБ ставку на ближайшем заседании?» Ответ выглядит убедительно, но владелец не знает, от чего он зависит. Если просто спросить «назови ключевые факторы», он получит красивый список, который не совпадёт с тем, на чём модель реально меняет мнение.
Промпт (шаг 1, повторить в 5 новых чатах):
Ты аналитик. Оцени вероятность того, что Банк России снизит ключевую
ставку на ближайшем заседании. Опирайся на последние доступные данные
(инфляция, инфляционные ожидания, курс рубля, заявления ЦБ, рынок кредитования).
Рассуждай по шагам, затем дай вероятность в процентах и вывод.
Промпт (шаг 2, для каждой пары ответов):
Ниже два независимых анализа одного вопроса. Найди фактические вопросы,
по которым они занимают РАЗНЫЕ стороны — даже если итоговая вероятность
у них похожа.
Для каждого вопроса дай:
- формулировку как вопрос «да/нет»;
- ответ анализа А;
- ответ анализа Б.
Не включай вопросы, по которым обе стороны согласны.
[Анализ А]
[Анализ Б]
Промпт (шаг 3, один раз на все пары):
Вот список вопросов «да/нет» из всех сравнений. Объедини те, что являются
одним и тем же вопросом в разных формулировках: два вопроса одинаковы,
если одно и то же свидетельство подтвердит или опровергнет оба. Верни
список уникальных вопросов и для каждого — в скольких парах он встретился.
Результат: Сначала придут 5 ответов с разными вероятностями и обоснованиями. Затем для каждой пары — короткие списки вопросов «да/нет», где ответы расходятся, например по инфляционным ожиданиям или по тому, как ЦБ отреагирует на курс. В конце будет сводный список уникальных развилок с частотой. Самые частые — то, что нужно проверить самому по первичным данным перед решением о кредите.
Почему это работает
Слабость LLM. Когда модель «называет важные факторы», она генерирует правдоподобный список по общему знанию о теме. Она не знает, как поведут себя её же будущие ответы, и не может заглянуть в своё распределение. Поэтому список факторов и реальные развилки почти не пересекаются.
Сильная сторона. Модель хорошо сравнивает два конкретных текста и находит, где они противоречат друг другу. Это задача на чтение, а не на самонаблюдение.
Как метод использует это. Он не просит модель угадать, где она будет колебаться. Он берёт реальные расхождения, которые она уже выдала, и просит только их описать. Так исчезает и необходимость заранее перебирать все возможные факторы: остаются лишь те, что действительно всплыли.
Рычаги управления: - Число прогонов → новые развилки добавляются примерно линейно с числом прогонов. Пять-семь прогонов уже дают большую часть развилок, которые дали бы девять. - Сравнивать пары с одинаковым итогом → оставь. Два прогона могут прийти к одному выводу и расходиться в допущениях. - Строгость слияния → «одно и то же свидетельство подтверждает или опровергает оба» (строго) или «решение одного закрывает спор в другом» (мягко). Мягче — меньше дублей, но грубее. - Источники вариации → если нужны разные данные поиска, пусть каждый прогон ищет сам. Если хочешь изолировать вариацию самой модели, дай всем один и тот же пакет материалов.
Шаблон промпта
Промпт для шага 2 (ядро метода):
Ты редактор, который ищет развилки между двумя независимыми анализами
одного вопроса.
Вопрос, на который отвечали оба анализа: {исходный_вопрос}
Найди фактические вопросы, по которым анализ А и анализ Б занимают
РАЗНЫЕ стороны. Учитывай расхождения, даже если итоговый вывод у них
одинаковый.
Для каждой развилки:
- Вопрос (формулировка «да/нет»): ...
- Ответ А: ...
- Ответ Б: ...
Если развилок нет — напиши «расхождений нет».
Не включай то, в чём анализы согласны.
{анализ_А}
{анализ_Б}
Промпт для шага 3 (группировка):
Ниже список вопросов «да/нет» из разных сравнений: {список_развилок}
Два вопроса считаются одним, если одно и то же свидетельство
подтвердило бы или опровергло оба (порядок ответов не важен).
Сгруппируй перефразы и верни список уникальных развилок с числом
сравнений, где каждая встретилась.
Подстановки:
- {исходный_вопрос} — текст запроса, который гонялся в шаге 1.
- {анализ_А}, {анализ_Б} — два независимых ответа с рассуждением.
- {список_развилок} — склеенные результаты всех сравнений.
🚀 Быстрый старт — вставь в чат:
Вот шаблон поиска развилок между независимыми ответами модели.
Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какое решение ты принимаешь, какие данные должны быть общими для всех прогонов, сколько прогонов реально сделать и как важно, чтобы развилки были строгими или широкими. Это нужно, чтобы сформулировать исходный вопрос и степень слияния, от которых зависит, что считать «одной и той же развилкой».
Ограничения
⚠️ Вопрос заранее не работает: «Назови ключевые факторы решения» не показывает, где ответы модели реально расходятся. Совпадение с настоящими развилками хуже случайного. Не полагайтесь на такой список как на карту рисков.
⚠️ Один прогон — недостаточно: Разбор рассуждения одного ответа заметно лучше, чем вопрос заранее, но всё равно пропускает значительную часть развилок.
⚠️ Стоимость: Число пар растёт быстро (при 9 прогонах — 36 пар). Вручную в чате это терпимо для 4–6 прогонов; дальше нужна автоматизация. Авторы для группировки используют отдельную модель-реранкер на GPU — читателю она недоступна, придётся группировать самой LLM.
⚠️ Только для прогнозов: Проверяли на бинарных прогнозах (спортивные матчи, события Metaculus). Для открытых задач (тексты, код) переносимость не проверена.
⚠️ Нет эффекта «вот так надо делать лучше»: Метод показывает, где модель неуверенна, но не делает сам прогноз точнее. Дальше нужно проверять развилки по первичным данным.
⚠️ Текст статьи неполный: В предоставленном фрагменте обрезаны результаты по single-rollout для Metaculus и остальные разделы. Выводы по ним взяты из аннотации.
Как исследовали
Идея простая: если вопрос действительно развилка, то в независимых прогонах он должен получать разные ответы. Команда взяла два набора прогнозных задач: 15 событий с платформы Metaculus и 59 матчей баскетбольного турнира March Madness. На Metaculus каждый вопрос получил 30 прогонов, и вариация шла и от модели, и от результатов веб-поиска. В баскетболе зафиксировали данные: сначала собрали по три отчёта на каждую команду, и все прогоны читали одни и те же отчёты. Так осталась только вариация самой модели.
Потом сравнили три способа: спросить развилки заранее, извлечь их из одного прогона и найти в парах многих прогонов. Сложность была в том, что одна развилка формулируется по-разному. Для слияния дублей использовали reranker (малую модель, которая оценивает схожесть двух текстов за один проход) вместо LLM-судьи: примерно в 86 раз дешевле. Чтобы результат не получился случайно высоким, сравнили с перестановочным базлайном: те же развилки, но метки «заранее» и «из прогонов» перемешаны случайно.
Что удивило: развилки, предсказанные заранее, совпали с реальными реже, чем при случайной перестановке. В баскетболе совпадение составило около 13% против базлайна около 39%. 55 из 59 матчей оказались ниже собственного базлайна. Для практики это значит: список «ключевых факторов» от модели — не карта её сомнений.
Ещё одна неожиданность: число уникальных развилок растёт примерно линейно, хотя число пар растёт квадратично. Развилки повторяются, поэтому уже пять из девяти прогонов давали около 61% всех уникальных развилок.
Адаптации и экстраполяции
🔧 Техника: требовать «ответ с обеими сторонами» → проще проверять развилку
Авторы хранят каждую развилку как вопрос «да/нет» с двумя ответами. Это удобно для проверки: сразу видно, что надо найти. Добавь в формат вывода «Что именно подтвердит ответ А, и что — ответ Б».
🔧 Техника: подсчёт частоты → приоритет проверки
После шага 3 просто сортируй развилки по числу сравнений, где они встретились. Это моя надстройка поверх метода, не из статьи: чем чаще вопрос всплывает, тем выше его вес при проверке.
Экстраполяция: агент-разработчик. В статье в качестве мотивации приводится агент, который молча пропускает входные данные, ломающие конвейер. Тут тоже можно применить идею: запусти агента на одной и той же задаче несколько раз в чистых сессиях, затем дай другой модели пары дифов и этот промпт:
Сравни два решения одной задачи. Найди неявные допущения, по которым они расходятся (что пропущено, что считается неважным, как обработаны ошибочные входные данные). Для каждого — вопрос «да/нет» и позиция каждого решения.Это перенос идеи на код, авторы его не проверяли.
Ресурсы
- Работа: Can LLMs Anticipate Their Cruxes? (preprint, under review)
- Авторы: David Reber, James Reber, Ari Holtzman, Victor Veitch
- Университет: University of Chicago (Department of Computer Science, Data Science Institute, Department of Statistics)
- Отсылки: понятие crux (Sabien, 2017); CruxBench (Dai et al., 2026); Qwen3-Reranker-8B (Zhang et al., 2025); платформа Metaculus