TL;DR
Исследование показывает, как LLM ошибается, когда выбирает лучший из двух планов эксперимента. Авторы взяли реальные эксперименты из научных статей по машинному обучению и сделали вторую версию каждого с одной подставленной методологической ошибкой, меняя около 2% текста. Модель должна выбрать более надёжный план. Каждую пару показывали в двух порядках: оригинал первым и оригинал вторым.
Главная находка: ответ зависит от порядка показа. Модель верно выбирает план в одном порядке и ошибается в другом, хотя текст тот же. У некоторых моделей точность «в каждом порядке по отдельности» около 66%, а «верно в обоих порядках» только 43%. Даже лучшие модели при требовании «верно в обоих» дают около 78%. Ошибаются они не от незнания: часто называют нужный изъян, но потом оправдывают его. Они принимают подробность за строгость («автор честно всё расписал»), частоту за правильность («так делают все») и повторяют убедительное самообоснование слабого плана.
Что с этим делать, подсказывает проверка «подсказок»: если модели прямо сказать, что в одном из планов есть изъян, назвать его категорию или дать отдельный разбор каждого плана по уровням серьёзности, точность заметно растёт. Получается рабочая процедура для LLM-судьи: гонять сравнение в обоих порядках, разбирать каждый вариант отдельно и сверять с чеклистом типовых изъянов.
Схема метода
Это не новая техника, а тест на надёжность LLM-судьи. Вот как его устроили:
ШАГ 1: Берём оригинальный план эксперимента → O
ШАГ 2: Копия с одним подставленным изъяном (правка ≤10% текста) → T
ШАГ 3: Модель выбирает «более методологически надёжный» → два запроса:
• O первым, T вторым
• T первым, O вторым
ШАГ 4: Засчёт только если выбран O в ОБОИХ порядках
Проверка «подсказок» (в оригинале разбирали на трудной части выборки):
Базовый вопрос: «Какой план методологически надёжнее?»
+ Раскрытие изъяна: «В одном плане есть изъян, найди его»
+ Раскрытие категории: + название типа изъяна
+ Разбор по уровням: отдельный обзор каждого плана по тирам серьёзности
+ Полный набор: всё вместе
Как исследовали
- Данные: 1 858 пар из принятых докладов крупных конференций по ML 2024–2026.
- Проверка пар: многоступенчатые фильтры. Человеческая проверка аспирантами оценила долю корректных пар в 86%.
- Модели: около двух десятков современных (Claude, GPT, Gemini, Grok, DeepSeek, Qwen и другие).
- Анализ рассуждений: авторы читали объяснения моделей в случаях, когда те выбирали план с изъяном.
- Проверка на «везение»: другая LLM смотрела, правильно ли названа ошибка в случаях, когда модель угадала только в одном порядке. У сильных моделей ошибка названа верно в 86–92% случаев, так что это не слепой выбор первого варианта.
Какие изъяны подставляли
Это готовый чеклист для ревью любого плана эксперимента, теста, исследования:
- Смешанное сравнение — вместе с проверяемым фактором меняется ещё что-то.
- Заблокированный механизм — убрана ситуация, где проверяемая идея вообще могла бы сработать.
- Не та метрика — измеряют не то, о чём заявлен вывод.
- Неравные условия — одному варианту больше настройки, информации или удобнее подсчёт.
- Вырожденное сравнение — варианты идентичны, все проваливаются или упираются в потолок.
- Невыполненные условия теории — опора на правило, которое здесь не действует.
- Круговая оценка — оценка зависит от самого проверяемого метода или от выбранных по итоговому результату настроек.
- Утечка данных — использована информация, которой не должно быть.
7 типовых ошибок рассуждения LLM-судьи
| Ошибка | Что происходит |
|---|---|
| Подробность как строгость | Чем детальнее и «прозрачнее» описан слабый план, тем выше оценка |
| Стандарт как правильность | «Так принято в области» принимается за доказательство надёжности |
| Эхо самообоснования | Модель пересказывает довод плана в его защиту |
| Неумение взвесить | Критикует оба плана, но не определяет, какой изъян решающий |
| Самопротиворечие | В одном порядке ругает приём, в другом хвалит |
| Неверно применённый принцип | Называет верное правило, но применяет в обратную сторону |
| Галлюцинация о статье | «Вспоминает» исходную работу и подгоняет под неё ответ |
Пример применения
В статье тестировались только ML-эксперименты. Перенос на бизнес-тесты ниже — это адаптация, самими авторами не проверенная. Сильная зона метода: сравнение двух близких планов проверки, где разница в одной методологической детали.
Задача: Продуктовая команда ВкусВилла проверяет, что рассылка в Telegram повышает повторные покупки. Аналитик написал два плана. План А короткий: случайно делим базу, одной группе шлём рассылку, другой нет. План Б длинный, с метриками, сроками и «как у крупных ретейлеров»: сравниваем тех, кто подписался на рассылку, с остальными и заодно запускаем новый промокод. Нужно понять, какому доверять. Модель легко выберет Б из-за подробности и «стандарта».
Промпт:
Ты ревьюер плана эксперимента. Ниже два плана проверки одной гипотезы.
Гипотеза: рассылка в Telegram увеличивает долю повторных покупок
в течение 30 дней у клиентов ВкусВилла в Москве.
[текст плана Б]
[текст плана А]
Шаги:
1. Отдельно для каждого плана составь список методологических
проблем по уровням: КРИТИЧНО (делает вывод невозможным),
СЕРЬЁЗНО, МЕЛКО. Проверь по категориях: смешанное сравнение,
не та метрика, неравные условия, круговая оценка, утечка
информации, вырожденное сравнение, заблокированный механизм.
2. Не засчитывай в плюс подробность описания и ссылки на
«общепринятую практику». Оценивай только, что план реально
позволяет доказать.
3. Определи, какая из критичных проблем решающая.
4. Выбери более надёжный план и объясни в 3 предложениях.
Затем вторым запросом повторите то же, поменяв планы местами (А как Plan_1, Б как Plan_2). Если выбор изменился, не доверяйте ответу и разберите расхождение вручную.
Результат: Модель выдаст два списка проблем по уровням серьёзности, назовёт одну решающую проблему и выберет план. Ожидаемо она заметит, что в плане Б смешаны два фактора (рассылка и промокод) и самоотбор подписчиков. Дальше смотрите на два запроса: совпал ли выбор в обоих порядках.
Почему это работает
Слабость. Модель, увидев два связных текста, подстраивается под то, что прочитала первым. Подробное и уверенное описание выглядит надёжнее краткого. Фраза «как принято» звучит как довод. Если она не обязана взвешивать решающий изъян, она критикует всё понемногу и в итоге не решает ничего. Поэтому порядок показа и меняет ответ.
Сильная сторона. LLM хорошо называет проблемы и знает методологические принципы. Авторы прямо отмечают, что модель часто сама находит нужный изъян. Ей мешает не знание, а то, как она взвешивает аргументы.
Как метод обходит слабость. Запуск в двух порядках ловит нестабильность: расхождение сразу видно. Отдельный разбор каждого плана по тирам серьёзности заставляет выделить решающий изъян до выбора. Чеклист категорий направляет внимание на механику ошибки, а не на красоту описания. Раскрытие, что изъян есть, сдвигает режим с «одобрить» на «найти проблему».
Рычаги: - Порядок планов. Всегда два запроса, итог считайте только при совпадении выбора. - Тиры серьёзности. Добавьте «что решает исход» — заставит взвесить, а не перечислить. - Чеклист категорий. Подгоните под вашу область: для маркетинга добавьте «выживший» и «сезонность». - Анти-эвристики. Фразы «подробность — не доказательство», «стандарт — не доказательство» прямо закрывают две частые ошибки. - Ожидание изъяна. «В одном из планов может быть критичная ошибка» — сдвигает модель к поиску, но может спровоцировать придирки к безупречному плану.
Шаблон промпта
В статье нет готового промпта, только описание условий. Базовый вопрос авторов: «какой дизайн методологически надёжнее». Шаблон ниже собран из описанных в статье элементов: разбор по тирам, категории изъянов, два порядка. Это адаптация, а не авторский текст.
Ты ревьюер плана {что_проверяем}.
{гипотеза_или_вопрос}
{текст_первого_плана}
{текст_второго_плана}
Шаги:
1. Отдельно для каждого плана составь список методологических
проблем по уровням: КРИТИЧНО / СЕРЬЁЗНО / МЕЛКО.
Проверь по категориях: {список_категорий_изъянов}.
2. Подробность описания и ссылки на «стандартную практику»
не считай аргументом. Оценивай, что план позволяет доказать.
3. Определи самую решающую критичную проблему.
4. Выбери более надёжный план. Ответ: «Plan_1» или «Plan_2»
и 3 предложения обоснования.
Подставьте: {что_проверяем} — A/B-тест, исследование, пилот, план миграции. {список_категорий_изъянов} — вставьте 8 категорий выше или свои. Запустите второй раз, поменяв Plan_1 и Plan_2 местами.
🚀 Быстрый старт — вставь в чат:
Вот шаблон сравнения двух планов в двух порядках. Адаптируй
под мою задачу: [твоя задача]. Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, что вы проверяете, какую гипотезу, какие типовые ошибки случаются в вашей области. Это нужно, чтобы заменить универсальный список категорий на ваш и точно задать контекст для сравнения.
Ограничения
⚠️ Другая область: Тест сделан на ML-экспериментах из научных статей. Перенос на бизнес-тесты, маркетинг, аналитику — разумная экстраполяция, но авторы её не проверяли.
⚠️ Даже лучшие модели не надёжны: Лучшие системы верно решали около 78% пар при строгом критерии «в обоих порядках». Как единственному арбитру для важных решений им доверять нельзя.
⚠️ Часть подсказок нереалистична: Раскрытие изъяна и категории — это диагностика. В реальной работе вы не знаете, где ошибка. Применим разбор по тирам и общий чеклист, а не точная подсказка.
⚠️ Порядок не лечится промптом: Эффект позиции показан как устойчивый. Авторы не нашли объяснения и не предлагают способа убрать его одной формулировкой. Остаётся запускать оба порядка.
⚠️ Подставленные изъяны искусственны: Реальные планы ломаются менее «чисто». Авторы оценивают, что около 14% пар в бенчмарке спорные.
⚠️ Текст исследования обрезан: Численный выигрыш от каждой подсказки здесь не виден. Известно только, что она «заметно улучшает» результат на трудной выборке.
Ресурсы
- Tampered ML: Evaluating LLM Judgment of Machine Learning Research — Soroush Ebadian, Parand A. Alamdari (Anthropic Fellows Program, University of Toronto), Joe Benton, Hailey Joren (Anthropic).
- Код и данные: https://github.com/tamperedml/tamperedml
- Смежные работы: FLAWS (Xi et al., 2025), PaperAudit-Bench (Tu et al., 2026), SPOT (Son et al., 2025).
