Scaffold Bias: LLM одобряет невозможное — и как заставить модель проверять иначе

Задача: Фёдор Овчинников (Додо Пицца) показывает потенциальному инвестору питч новой франчайзинговой модели. Инвестор просит ChatGPT проверить — нет ли там дыр в логике и финансовой выполнимости.

Промпт:

Ты — строгий финансовый аудитор. Твоя задача — найти фатальные ошибки 
в бизнес-плане, а НЕ оценить его в целом.

Вот критерии для проверки (проверяй КАЖДЫЙ отдельно):

1. ЮНИТ-ЭКОНОМИКА: при заявленных издержках и выручке — операционная 
   прибыль на точку положительная?
2. МАСШТАБИРУЕМОСТЬ: операционная модель физически реализуема при 
   200 точках без кратного роста управленческого аппарата?
3. РЫНОЧНЫЕ ПРЕДПОСЫЛКИ: цифры по росту рынка соответствуют 
   независимым данным (Росстат, Nielsen)?
4. ЗАВИСИМОСТИ: есть ли единственная точка отказа — один поставщик, 
   одна платформа, одно регуляторное разрешение?
5. ВРЕМЕННЫЕ РАМКИ: заявленные сроки выхода на окупаемость реалистичны 
   для данного сегмента?

Для каждого критерия:
— Статус: ВАЛИДНО / МИНОРНАЯ ПРОБЛЕМА / ФАТАЛЬНАЯ ОШИБКА
— Что именно проверял
— Почему такой вывод

Не комментируй стиль, оформление и полноту документа. 
Только физическую/финансовую выполнимость.

[Бизнес-план здесь]

Результат: Модель пройдёт по каждому из пяти критериев отдельно и выставит статус. В отличие от запроса «оцени этот бизнес-план» — где она похвалит структуру и скажет «выглядит обоснованно» — здесь она будет вынуждена проверить конкретики. Если в юнит-экономике не сходится маржа, она это укажет, даже если весь документ выглядит профессионально.

LLM обучена на огромном корпусе текстов, где экспертные документы действительно обычно правильные. Полный, грамотный, терминологически корректный текст → в обучающих данных такой документ чаще всего оказывался верным. Поэтому модель выработала эвристику: «выглядит как экспертный → скорее всего валидный».

Это работает для фактических ошибок. Но ломается для композиционных — когда каждый элемент правильный, а их сборка невозможна. Как правило, модель замечает явные противоречия («здесь написано X, а ниже X невозможно»), но пропускает неявные — те, которые требуют рассуждений через несколько шагов.

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

Рычаги управления: - Количество критериев → 3-5 оптимально; больше 7 — модель начинает «размываться» - Формулировка статусов → добавь свои метки: КРИТИЧНО / ПРОВЕРИТЬ / ОК — под конкретную задачу - Запрет на комментарии оформления → критически важен, иначе модель уйдёт в стиль и структуру - Три запуска → для решений с высокой ценой ошибки (большая сделка, медицинское, юридическое)

Ты — строгий аудитор {область: финансовая/техническая/юридическая/логистическая}. 
Твоя задача — найти фатальные ошибки в {тип документа}, 
а НЕ дать общую оценку.

Проверяй КАЖДЫЙ критерий отдельно:

1. {Критерий 1}: {что именно проверить}
2. {Критерий 2}: {что именно проверить}
3. {Критерий 3}: {что именно проверить}
[добавь нужное количество]

Для каждого критерия укажи:
— Статус: ВАЛИДНО / МИНОРНАЯ ПРОБЛЕМА / ФАТАЛЬНАЯ ОШИБКА
— Что проверял
— Почему такой вывод

Не комментируй {что игнорировать: оформление/стиль/полноту/структуру}.
Только {на что фокус: выполнимость/логическую корректность/финансовую реалистичность}.

{Документ или описание}

Что подставлять: - {область} — тип экспертизы: финансовая, техническая, юридическая - {тип документа} — бизнес-план, ТЗ, договор, маркетинговая стратегия - {Критерий N} — конкретные вопросы, которые надо проверить (не «всё ли правильно», а «сходится ли юнит-экономика») - {что игнорировать} — явно запрети комментировать оформление и стиль

🚀 Быстрый старт — вставь в чат:

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

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

LLM спросит про тип документа, область экспертизы и ключевые ограничения твоей ситуации — потому что без этого не заполнить критерии, а именно они делают метод рабочим.

⚠️ Неявные ограничения требуют экспертизы: метод работает, только если ты сам знаешь, какие критерии поставить. Если не знаешь что проверять — попроси модель сначала составить список потенциальных рисков для твоего домена, а потом используй его как чеклист.

⚠️ Самосогласованность не даёт надёжности для критических решений: даже при единогласном результате трёх запусков — точность около 80%. Для медицинских, юридических или финансовых решений с большой ценой ошибки нужна человеческая экспертиза.

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

⚠️ Граничные случаи («минорная проблема») модели калибруют хуже всего: если задача — выловить именно пограничные ситуации, а не явные провалы, метод работает хуже.

Команда собрала 683 экспертно размеченных протокола (Gold set) и 5000 сгенерированных совместно с экспертами (Silver set) по шести областям биомедицинских измерений — от сигналов мышц до радаров жизнедеятельности. Каждый протокол получил метку: валидный, минорная проблема, фатальное нарушение. Двое независимых аннотаторов достигли согласия 91,4% — это высокая планка для задачи такой сложности.

Шесть моделей проверяли четырьмя стратегиями: zero-shot, CoT, самосогласованность и инструментальное дополнение. Лучший результат — 53 балла macro-F1 из 100 возможных. Это чуть лучше ключевой эвристики (43), но всё равно провал: каждый пятый фатально невыполнимый протокол модели пропустили.

Самое любопытное — исследователи вручную разобрали 76 промахов лучшей модели и разделили их 54/46: 54% — ошибки внимания (модель вообще не заметила ограничение), 46% — ошибки суждения (заметила, но решила что «это незначительно»). В обоих случаях общий паттерн один: модель видит профессиональный каркас — и снижает критичность. Это и есть scaffold bias в действии.

🔧 Техника: роль «скептика», а не «эксперта»

Стандартный системный промпт «ты эксперт в X» усиливает scaffold bias — модель входит в роль эксперта, который доверяет экспертным документам. Попробуй вместо этого:

Copy

Ты — скептик, задача которого найти одну фатальную ошибку в этом документе.
Исходи из того, что ошибка есть. Твоя работа — её найти.

Это ломает эвристику «выглядит профессионально → наверное правильно» и переключает модель в режим поиска, а не оценки.

🔧 Техника: разделить обнаружение и диагностику

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

Copy

Запрос 1: «Есть ли в этом документе фатальная ошибка? Да/Нет + одно предложение.»
Запрос 2 (только если Да): «Теперь объясни подробно: что именно не так и почему.»

Один промпт "найди и объясни" даёт хуже, чем два отдельных.

PhysDox: Benchmarking LLMs on Physical Feasibility Auditing of Physiological Sensing Protocols

He Liu (Donghua University), Boyuan Gu (University of Electronic Science and Technology of China / Tsinghua University), Shuaiqi Cheng, Haiyang Sun, Siyu You (UESTC), Xuming Hu (HKUST Guangzhou)

Ключевые понятия из работы: scaffold bias, severity calibration, cascade errors, implicit vs explicit constraints, fatal-gate recall