LLM Cross-Verification: почему просить ту же модель «проверить себя» почти бесполезно

Это не техника с промптом — это исследовательская находка о поведении LLM, из которой вытекают практические выводы:

ФАКТ 1: Одна модель → просишь проверить себя → видит те же ошибки, что сделала
        Эффективность перепроверки ≈ 0-30%

ФАКТ 2: Та же модель + другой промпт → немного лучше, но незначительно
        Смена промпта ≠ смена угла зрения

ФАКТ 3: Разные модели → лучше, но всё равно не независимо
        Реализуется ~43-44% потенциального выигрыша от независимой проверки

ФАКТ 4: Даже разные ошибки часто имеют общий корень
        Поверхностное разнообразие ≠ разнообразие по существу

Задача: Ты написал деловое письмо клиенту с предложением о сотрудничестве на 200 000 рублей. Хочешь проверить логику аргументов, ценовое обоснование и возможные слабые места.

❌ Что большинство делает (неэффективно):

[В том же чате GPT-4]

Проверь это письмо. Найди слабые места и улучши его.

[текст письма]

Модель видит то, что сама же написала. Слепые пятна остаются слепыми.

✅ Что работает лучше — кросс-модельная верификация:

Шаг 1 — получаешь первый вариант от Модели A (например, ChatGPT).

Шаг 2 — открываешь Модель B (например, Claude) и пишешь:

Я получил следующее деловое предложение от AI-ассистента.
Твоя задача — найти то, что он мог пропустить.

Контекст: {краткое описание ситуации и цели письма}

Что проверить:
1. Логические дыры — есть ли утверждения без доказательств?
2. Слабые места в ценовом обосновании — на что клиент может возразить?
3. Что здесь выглядит как шаблон, а не живая аргументация?
4. Чего здесь нет, но должно быть для убедительности?

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

[текст письма]

Шаг 3 — сравни оба ответа. Там, где модели сходятся в оценке — скорее всего, правда. Там, где расходятся — требует твоего суждения.

Результат: Модель B укажет на проблемы, которые Модель A считала нормой. Получишь 2-4 реальных возражения, которые клиент мог бы использовать. Это не гарантия полноты, но существенно лучше, чем просить одну модель проверить себя.

Слабость LLM: Модель генерирует ответ по паттернам из обучения. Когда она «проверяет» свой же текст — она применяет те же паттерны, что и при написании. Ошибочное рассуждение кажется ей правильным — именно потому, что оно соответствует её внутренней логике. Это не невнимательность, это архитектура.

Почему разные модели помогают: Разные компании обучали модели на разных данных, с разными методами, с разными акцентами. GPT-4 и Claude строят немного разные «карты» того, как выглядит хороший текст или правильное рассуждение. Слепые пятна частично не совпадают — и это даёт реальное улучшение.

Почему смена промпта помогает меньше: Ты меняешь формулировку, но не меняешь модель. Она всё равно применяет те же внутренние паттерны, просто с другого угла. Это как попросить одного и того же эксперта переформулировать своё мнение — он скажет то же самое другими словами. Модель важнее промпта, когда цель — независимая проверка.

Рычаги управления: - Явная инструкция «предполагай ошибку» → снимает склонность модели соглашаться с уже написанным - Запрет улучшать → фокусирует на поиске проблем, не на редактировании - Конкретные категории для проверки → уменьшает шанс, что модель пройдётся по поверхности - Две разные модели вместо одной дважды → главный рычаг из исследования

Я получил ответ от другого AI-ассистента по следующей задаче:
{краткое описание задачи}

Твоя роль — критик, а не редактор. Не улучшай — ищи проблемы.

Предположи, что первый ассистент мог ошибиться. Проверь:
— {критерий 1 под твою задачу}
— {критерий 2 под твою задачу}
— {критерий 3 под твою задачу}
— Что здесь выглядит как шаблонное рассуждение без реального анализа?
— Какие важные аспекты {темы} здесь не учтены?

Ниже — текст для проверки:

{текст от первой модели}

Что подставлять: - {задача} — зачем писался текст, кому, в каком контексте - {критерий X} — конкретные вещи, которые важны именно для твоей задачи (логика, факты, тон, юридическая точность, финансовые риски) - {текст} — полный вывод первой модели

🚀 Быстрый старт — вставь в Claude/ChatGPT (в новом чате, не там где писал):

Вот шаблон кросс-модельной верификации. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

LLM спросит какой текст проверять и по каким критериям — потому что для эффективной критики нужно знать, что важно именно в твоём контексте.

⚠️ Разные модели ≠ независимые модели: Исследование показало, что даже разные модели реализуют лишь около половины теоретически возможного выигрыша. Общие слепые пятна остаются — модели обучались на пересекающихся данных и с похожими целями.

⚠️ Эффект сильнее при одной модели: Когда ты просишь GPT-4 проверить ответ GPT-4 — эффективность верификации падает ниже 30% от потенциала. Это почти ничего.

⚠️ Глубокие ошибки выглядят как разные: Исследование обнаружило, что поверхностно разные ошибки часто имеют общий корень. Две модели могут ошибиться «по-разному», но из одного и того же непонимания задачи.

⚠️ Исследовалось на коде: Задачи были алгоритмические — с чёткими правильными ответами и автоматическими тестами. Для творческих, субъективных или открытых задач степень зависимости ошибок может отличаться.

Команда задалась вопросом, который звучит просто, но никто не проверял системно: если попросить несколько LLM решить одну задачу — они будут ошибаться независимо или на одних и тех же входных данных? Взяли 224 задачи по программированию из IBM-датасета — достаточно сложных, чтобы модели не просто всегда правы или всегда неправы. Проверили двенадцать разных моделей, пять языков программирования и три стиля промптов.

Ключевая часть дизайна — они не просто считали «правильно/неправильно». Они измеряли паттерн ошибок: совпадают ли конкретные тест-кейсы, на которых падают разные модели, чаще, чем если бы это было случайно? Это важное различие — можно ошибаться одинаково часто, но на разных входных данных (это хорошо) или на одних и тех же (это плохо).

Результат оказался хуже ожидаемого: даже разные топовые модели реализовали только 43-44% потенциального выигрыша от идеально независимых систем. Одна модель дважды — меньше 30%. Интересно и то, что смена языка программирования и смена промпта давали минимальный эффект — модель важнее всего остального. В ручном анализе обнаружился ещё один инсайт: разные ошибки при ближайшем рассмотрении часто вырастали из одних и тех же неправильных предположений в логике решения.

🔧 Техника: явное указание роли критика → острее находит проблемы

Вместо нейтрального «проверь» — прямо назначь роль скептика:

Ты — адвокат дьявола. Твоя задача — найти всё, что может пойти не так 
в следующем {плане / тексте / решении}. Не ищи плюсы — ищи риски.

Это усиливает эффект кросс-модельной проверки: не только другая модель, но и другая роль.

🔧 Экстраполяция: принцип «разные модели» → структурированный Devil's Advocate

Если у тебя доступ только к одной модели — симулируй «другой взгляд» через явную смену роли и контекста:

Шаг 1 (обычный чат): напиши {текст/план/решение}

Шаг 2 (новый чат, явная инструкция):
Представь, что ты смотришь на следующий {текст} глазами 
{скептичного инвестора / требовательного клиента / конкурента}.
Что здесь слабо? На что ты бы возразил?

[текст из шага 1]

Это не заменяет разные модели, но частично компенсирует: новый чат без контекста + явная враждебная роль = меньше склонности соглашаться со своим же выводом.

Название: A Systematic Methodology for Evaluating Failure Independence in LLM-Generated Code

Датасет и материалы: tinyurl.com/CodeDiversity

Базовый датасет: PROBE benchmark — huggingface.co/datasets/OSS-forge/PROBE

Авторы: Rodrigo Pato Nogueira, Karthik Pattabiraman, Marco Vieira, João R. Campos

Университеты: University of Coimbra (Португалия), University of North Carolina at Charlotte (США), University of British Columbia (Канада)