Уверенный, правдоподобный, неправильный: проверка отчёта ИИ

У одного руководителя из этой отрасли, о котором я недавно читал разбор, в рабочей папке хранится документ со странным названием: журнал исправлений. Прямо в описании аналитического исследования – таблица «Утверждения, отозванные в ходе работы», с причиной отказа от каждого. В соседней папке другой отчёт открывается предупреждением: три утверждения в ранних версиях этого документа были неверны и отозваны.

Оба документа написаны ИИ-агентом. И самое ценное в них – именно список отозванного.

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

Почему ошибочный отчёт выглядит убедительно

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

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

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

И в этом сценарии ошибка агента устроена конкретно. Она редко выглядит бредом. Чаще это вывод, который вы сами могли бы написать в усталом состоянии: верное направление мысли, число из соседнего периода, причинно-следственная связь там, где в данных только совпадение. Человек-аналитик в таком месте обычно мнётся и ставит оговорку. Агент формулирует вывод без оговорки.

Журнал исправлений

Практика из того разбора проста до неприличия. Каждое утверждение агента требует подтверждения и до проверки фактом не считается. Подтверждают его источником, числом, цитатой – или отзывают. Отозванное записывается: что за утверждение, почему не прошло.

Пример из реального исследования: агент проанализировал набор задач и рекомендовал разделить несколько целей в системе сборки. Итоговый отчёт начинается с прямой строки: «короткая версия, и она в основном негативная». Часть рекомендаций не подтвердилась исходными данными – и вместо того чтобы тихо переписать текст, автор оставил таблицу отозванного с причинами.

Зачем оставлять? Начну с очевидного: это открытость перед читателем. Тот, кто откроет отчёт через месяц, увидит выводы вместе с историей их проверки.

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

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

Попробовать такую проверку на себе – дело десяти минут. Сложность в другом месте: превратить её в привычку, которая срабатывает на каждом отчёте, включая самые будничные. В этом и разница между знанием и навыком.

Почему записывать – половина эффекта

Можно возразить: зачем журнал, если ошибку видно сразу – исправил и пошёл дальше. Возражение понятное, но у него есть изъян: исправленная без записи ошибка нигде не сохраняется, а ошибки агента повторяются. Модель не учится на вашей правке – следующий отчёт она напишет с той же уверенностью и тем же типом ошибки. Учиться приходится вам, а к следующей неделе человек обычно уже забыл, где именно инструмент ошибся.

Тут уместна одна наша находка. В исследовании устойчивости моделей к давлению (июль 2026) мы проверяли, как восемнадцать моделей удерживают правильный ответ, когда их пытаются переубедить без новых фактов. В среднем по моделям одно лишь «ты уверен?» приводило к смене верного ответа на неверный в 8% случаев – без единого нового аргумента, просто от интонации сомнения. Отсюда два неудобных вывода. Слепое доверие опасно. Беспредметное давление тоже не помогает: агент откажется и от верного ответа. Работает только проверка по существу: источник, данные, объём выборки.

Журнал исправлений – это такая проверка, оформленная как процесс. Плюс по нему видно, что проверка действительно была.

Проверьте сами: пять утверждений против данных

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

Промпт ниже я прогонял на Kimi K3 – по нашим описаниям моделей она сильна именно в аналитике, – и для сравнения на DeepSeek V4 Pro. В ответе смотрите на два места: какие вердикты получили утверждения 1 и 4 и как модель переписала сводку в конце.

Утверждение 1 в этой сводке – мой любимый тип ошибки. Направление верное: 17 закрытых задач действительно меньше 24. Но «третий спринт подряд» в данных просто отсутствует – падение одно, в спринте 14. Агент дописал тренд, которого в данных нет, потому что тренд звучит убедительнее единичного провала. Утверждение 4 тоньше: «просил ускорить» и «недоволен сроками» – разные вещи, и вторая из данных не следует.

Как вести журнал, чтобы он работал

Из того разбора рабочего пространства и из собственного опыта я бы собрал четыре правила.

Первое – данные лежат рядом с выводами. В том пространстве запросы к телеметрии хранятся в той же папке, что и отчёт, и пронумерованы в порядке постановки вопросов: q01, q02 и так далее до q17. Проверяющий может пересчитать любое число сам и не обязан верить сводке. Для менеджера это проще, чем звучит: выгрузка из Jira, протокол созвона, файл с метриками – в папке с отчётом, а не в почте.

Второе – у каждого документа есть датированная версия, которая после публикации не переписывается. Отчёт называется pool-saturation-2026-08-27.md, а не «Отчёт финал (новый)». Датированную версию можно критиковать, а исправления выпускать следующей версией. С документом, который молча переписывается, журнал исправлений не работает – в нём просто некуда писать отзыв.

Третье – вердикты короткие и стандартные. Подтверждено, частично, не подтверждено – плюс одна строка причины. Если объяснения длинные, журнал быстро забрасывают.

Четвёртое – отзыв фиксируется публично, прямо в отчёте или рядом. Это дисциплинирует сильнее любого внутреннего намерения «быть внимательнее».

Сводный чеклист на каждый отчёт агента:

• Для каждого числа есть запрос или файл, из которого оно взялось
• Утверждение без цитаты источника помечается как неподтверждённое
• Объём выборки у каждого числа проверен отдельно (период, фильтры, состав)
• Отозванные утверждения записаны с причиной отзыва
• Следующий отчёт агента начинается с контекста прошлых отзывов

Чего журнал не сделает

Честности ради – границы у практики тоже есть, и главная из них неприятная.

Журнал не заменяет проверяющего. В том разборе есть сухая строчка, которую стоит помнить каждому, кто внедряет агентов в аналитику: корректность по-прежнему зависит от оператора. Последний рубеж проверки там – скептический человек; сам процесс корректности не гарантирует. Журнал делает скептицизм дешевле и заметнее, но не отменяет его.

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

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

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

Другие части серии

Часть 1

Рабочее пространство для ИИ-агента: гид для менеджера

Часть 3

От промптов к системе: скиллы, субагенты и память ИИ