Уверенность ИИ и собственное суждение: как не отдать решение модели

Что известно об уверенности и критическом мышлении

В работе CHI 2025 исследователи Microsoft Research и Carnegie Mellon опросили 319 работников, описавших 936 случаев применения ИИ. Более высокое доверие к ИИ было связано с меньшей заявленной критической проверкой. Это самоотчёты и связь показателей, а не доказательство, что ИИ причинно снижает интеллект. Lee et al., CHI 2025

Метаанализ Nature Human Behaviour 2024 года включал 106 экспериментов и 370 эффектов из работ 2020–2023 годов. В среднем сочетание человека и ИИ уступало лучшему из них по отдельности: Hedges’ g = −0,23, 95% ДИ от −0,39 до −0,07. Это стандартизированный эффект, не «потеря 23% точности». Vaccaro et al., Nature Human Behaviour, 2024

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

Сначала сформулируйте собственный критерий

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

После обсуждения сравните итог с этим черновиком. Если появился новый критерий, установите его источник: это реальная потребность, найденное ограничение или эффект красивого описания? Менять критерии нормально, если вы понимаете причину. Именно эта запись позволяет отличить обучение в процессе анализа от незаметного присоединения к последнему уверенно высказанному мнению.

Условный кейс: выбор инструмента по слишком гладкой таблице

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

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

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

Как попросить Consensus поддержать проверку

В Colay участники Consensus обсуждают запрос, а координатор формирует итог. Предложенная постановка задачи: «Сначала проверьте критерии. Назовите неизвестные данные. Покажите, какое из них может изменить выбор. Затем предложите минимальную проверку». Пользователь может отдельно попросить сохранить альтернативу, которая остаётся разумной при других допущениях. Это рабочая рекомендация, а не измеренная гарантия улучшения решений.

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

Проверяйте пользу на своих задачах

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

По возможности дайте коллеге оценить обезличенные результаты, не сообщая, где какой режим. Небольшая внутренняя выборка не докажет превосходство продукта для всех пользователей, но покажет, на каких ваших задачах обсуждение окупает время. Особое внимание уделите случаям, где участники согласились с ошибкой: они объясняют пределы процесса лучше, чем удачный демонстрационный пример.

Человек должен иметь возможность остановить вывод

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

Начните со следующего рабочего выбора: напишите критерии, запустите обсуждение, проверьте один решающий факт и объясните вывод самостоятельно. Такой цикл делает роль человека видимой. Consensus здесь полезен как организованное пространство для разных аргументов; ответственность за критерии, подтверждение фактов и окончательное действие остаётся у принимающего решение.