Беглость — не истина Изображение: создано ИИ

Я попросил ИИ разобраться в одном вопросе, и он вернулся с отполированным, структурированным, уверенным ответом — который оказался неверным, и я заметил это только случайно. Первая мысль была: может, я неправильно этим пользуюсь? Литература говорит — нет. Не заметить ошибку — это стандартный исход даже для внимательных людей, и решение не в бдительности. Решение — превратить это чувство дискомфорта в нечто, что может проверить машина.

Эвристика беглости, которую сломали LLM

Люди пользуются дешёвым мыслительным ярлыком: если что-то легко воспринимается, значит, это, вероятно, правда. Психологи называют это эвристикой беглости, и на протяжении большей части истории это было разумной ставкой — говорящий, который звучит внятно, уверенно и связно, обычно действительно более компетентен, потому что производить такую речь в условиях человеческих ограничений долго подделывать трудно. LLM — первые массово производимые «говорящие», которые разрывают эту связь. Беглость теперь не стоит модели ничего. Уверенность — это распределение вероятностей токенов, а не сигнал проверенного понимания.

Этот разрыв проявляется прямо в том, как люди оценивают вывод ИИ: получая один и тот же ответ, люди считают его более уверенным, если им сказали, что он от ИИ, чем если сказали, что от человека (phys.org, 2026-05). Уверенней стала не модель. Уверенней стало априорное ожидание читателя.

Эксперты не исключение

Если бы это было проблемой неопытности, обучение бы её решило. Но это не так.

Врачи, уже прошедшие обучение диагностике с помощью ИИ, всё равно не смогли отфильтровать правдоподобно звучащие, но неверные рекомендации LLM — предвзятость автоматизации пережила обучение, которое должно было выработать к ней иммунитет (medRxiv, 2025-08). Это и есть механизм, и он хуже, чем кажется на слух, потому что проходящие ошибки — не из лёгкой категории. Ошибки уровня интерпретации поймать труднее, чем фактические — неверное имя или неверная дата бросаются в глаза; неверная рамка — нет, потому что она звучит правдоподобно и вписывается в нарратив, который читатель уже ожидал (Not Wrong, But Untrue, arXiv:2509.25498). Знание предметной области ловит факты. Оно не гарантированно ловит фрейминг.

В основе обоих наблюдений лежит разрыв калибровки: LLM заявляют уровень уверенности, систематически превышающий их фактическую точность. При измерении на одиннадцати моделях и шести наборах вопросов средняя заявленная уверенность составила 88% против фактической точности в 79% (Confidence Calibration in Large Language Models, arXiv:2605.23909). Модель не лжёт о своей уверенности. Она просто разбалансирована, а эта разбалансированность читается как авторитетность.

Ощущение скорости при фактическом замедлении

Самое ясное доказательство того, что дело не в недостатке знаний, даёт исследование METR 2025 года с участием опытных разработчиков open-source — 16 разработчиков, 246 реальных задач, репозитории объёмом в среднем свыше миллиона строк кода. Это не люди, которые наивно доверяют ИИ. Они каждый день работают с продакшн-кодом.

  • Они ожидали, что ИИ ускорит их работу на 24%.
  • По факту измерений они работали на 19% медленнее.
  • После завершения задач — когда реальные временные затраты уже остались позади — они всё равно были уверены, что стали на 20% быстрее.

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

Чтобы быть точным насчёт того, что можно вынести из этого исследования: шестнадцать разработчиков — небольшая выборка, и сам METR прямо говорит, что результат специфичен для контекста — опытные мейнтейнеры, зрелые кодовые базы на миллион строк, которые они глубоко знали, — и его не следует растягивать до утверждения «ИИ замедляет всех». Так что не стоит переносить эти 19% куда-либо как точечную оценку. Опора этого аргумента — не в величине, а в знаке разрыва: измеренный эффект был отрицательным, воспринимаемый эффект был положительным и до работы, и после неё, а средняя постфактум-оценка оказалась рядом с исходным ожиданием, а вовсе не рядом с измерением. Если бы самовосприятие было просто зашумлённым, оценки постфактум разбросались бы вокруг измеренной истины. Этого не произошло. Они остались там, где было ожидание.

Почему рухнула экономика проверки

До LLM судить о качестве работы по её результату было разумным способом судить о компетентности исполнителя — эти две вещи были связаны, потому что небрежная работа исходила из небрежного производства. LLM разорвали эту связь. Качество результата и компетентность исполнителя больше не связаны между собой, а значит, оценка только по артефакту перестала работать как диагностика (Fluent, Confident, Wrong, ScienceDirect 2026). Проверка стала дороже производства.

Хуже того, цена ошибки не пропорциональна частоте ошибок. Когда неверные фрагменты читаются точно так же, как верные — тот же регистр, та же уверенность, та же отполированность, — локализовать повреждение невозможно, поэтому несколько процентов «загрязнения» обходятся вовсе не в несколько процентов. Это отравляет всю партию целиком: каждое утверждение в выводе теперь несёт на себе подозрение худшего из них. Именно поэтому «модель права в 95% случаев» — вовсе не та обнадёживающая цифра, какой кажется. Доверие рушится скачкообразно задолго до того, как падает точность.

Почти ничьи привычки проверки не адаптировались под это — и именно на этом разрыве построен аргумент Ratchet Pattern на этом сайте: генерация может оставаться вероятностной, но проверка над ней — нет.

Это не неправильное использование — это стандартная реакция большинства

Так неправильно ли я это использую? Литература говорит обратное. Хрестоматийное определение неправильного использования — принимать беглость за сигнал доверия и отключать проверку, — и это не крайний случай, а то, к чему по умолчанию скатывается большинство людей, включая обученных. Врачи в исследовании о предвзятости автоматизации не удержали свой сигнал несогласия. Не удержали его и разработчики в исследовании METR. Если сохранять подозрительность перед гладким, кажущимся неопровержимым ответом ощущается как паранойя, стоит заметить, что это уже ставит вас впереди большинства измеренной популяции — включая тех, чья работа как раз и заключалась в том, чтобы это ловить.

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

Единственное решение

Здесь имеет значение ровно одна корректировка: не останавливайтесь на чувстве тревоги. Превратите его в наблюдаемый критерий приёмки и задайте этот критерий до начала работы, а не после. Ощущение не самокорректируется — METR доказал это напрямую, — а измерение самокорректируется.

«Превратить» — это процедура, а не настроение. Для любого несущего утверждения — того, что вот-вот повлияет на решение, — ответьте на два вопроса прежде, чем позволить ему это сделать:

  1. Что должно быть истинным, чтобы это утверждение работало? Гладкий вывод редко проговаривает свои предпосылки; он «отмывает» их в саму рамку, и именно поэтому знание предметной области соскальзывает с него. Этот вопрос вытаскивает скрытую предпосылку на уровень утверждения, где её наконец можно атаковать.
  2. Что я бы наблюдал, если бы это было неверно? Это вынуждает утверждение поставить ставку на реальный мир. Вывод, который не подразумевает никакой наблюдаемой разницы со своим отрицанием, — не знание, а связность, а связность — это именно то, что модель оптимизирует, когда на кону ничего не стоит.

Для кода, сгенерированного ИИ, оба вопроса сжимаются в один пропуск, который заполняется до того, как код появится: «Если это полезно, то сразу после выпуска пользователь сможет ___». Пропуск должен называть действие в мире пользователя, а не в мире кода — чистая сборка и успешный запуск — это проверки связности, а не проверки полезности. И если вы не можете заполнить пропуск, это самый ценный результат всей процедуры: значит, вы ещё не знаете, что именно просили, и гладкий ответ вот-вот собирался это от вас скрыть.

Всё остальное в литературе о снижении этого риска — отделение уверенного языка от проверенного факта, разбиение вывода на независимо проверяемые единицы, встраивание трения ещё до того, как приземлится гладкий ответ, — это то же самое преобразование, применённое на разных уровнях.

«Разве это не просто скептицизм под новым названием?»

Очевидное возражение: «проверяй, прежде чем доверять» — это именно то, что скептицизм всегда и означал, так что же здесь на самом деле нового? Ответ — когда происходит суждение, и именно синхронизация по времени и есть весь механизм.

Скептицизм — это позиция, которую вы принимаете, глядя на результат, — и каждое исследование выше измеряет именно то, как эта позиция даёт сбой. Врачи не были доверчивы; они прошли обучение диагностике с помощью ИИ — вмешательство, которое как раз и должно было установить эту самую позицию, — и они смотрели прямо на рекомендации. Рекомендации всё равно их обезоружили, потому что гладкий артефакт модулирует применяемое к нему суждение — именно в этом и состоит эвристика беглости. У критерия, заданного до того, как результат появился, нет гладкого артефакта, которым его можно обезоружить. Уверенности не на чем работать, потому что тест был зафиксирован в момент времени, которого результат не может достичь.

Наука институционализировала точно такой же ход по той же причине. Предрегистрация существует не потому, что рецензентам не хватает скептицизма; она существует потому, что исследователь, глядящий на уже собранные данные, может гладко рационализировать любой результат, поэтому научная область перенесла гипотезу на момент до появления данных. Если бы это различие было пустым — если бы «скептицизм после» работал так же хорошо, как «критерий до», — то обученные эксперты отфильтровывали бы плохие рекомендации с высокой частотой. Именно этот эксперимент и провело исследование о предвзятости автоматизации, и результат оказался отрицательным.

«Проверка стоит дороже производства — кто может это себе позволить?»

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

Во-первых, критерий — это не проверка. Записать, что вы бы наблюдали, если бы утверждение было неверным, стоит одного предложения, а платить за собственно проверку приходится только по несущим утверждениям. Заранее заданный наблюдаемый признак также гораздо дешевле проверить, чем открыто и без границ аудировать гладкий артефакт, — основная стоимость постфактум-проверки не в самой проверке, а в незнании, с чего начать, а критерий как раз и схлопывает это пространство поиска.

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

Закодируйте ревьюера

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

Это не гипотеза — именно так был отгейчен текст, который вы сейчас читаете. Reins — open-source фреймворк, построенный ровно для этого: каждый критерий приёмки становится quest‘ом — правилом, которое оценивает Fact{Where, Expected, Actual} и сообщает pass или fail, ни разу не спрашивая, звучит ли окружающая проза убедительно. Ещё до того, как в этом тексте появилось хоть одно предложение, человек записал конкретные утверждения, которые тексту разрешено делать; машина сверила черновик с этим списком; а ревьюер, проверявший покрытие утверждений, работал из контекста, отдельного от того, в котором писался черновик, — потому что самопроверка не является проверкой. abloq, система квестов, на которой работает этот сайт, кодирует это как правило, а не как просьбу.

В этом и есть реальное содержание фразы «не просто чувствуйте это». Не больше бдительности — а место в пайплайне, где бдительность перестаёт быть зависимостью. Два вопроса из предыдущего раздела — что должно быть истинным и что бы это опровергло — перестают быть тем, что нужно помнить задать, как только они становятся правилом гейта, а не мысленной пометкой. Quest не устаёт к десятому прочтению.

Связанные статьи

Источники

История изменений

  • 2026-07-09: Первый релиз