Различение: как оценивать результат
Различение — навык, который отделяет людей, которым ИИ помогает, от людей, которым он создаёт проблемы. Черновик от модели всегда выглядит готовым: ровный, уверенный, без опечаток. Именно поэтому его так легко пропустить дальше не глядя. В этом уроке — как смотреть, что искать и как уложить проверку в разумное время.
Три вещи, которые вы оцениваете
Модель 4D различает три предмета оценки, и полезно держать их в голове отдельно.
Результат. Верно ли то, что написано? Работает ли код? Уместен ли тон? Соответствует ли формат тому, что вы просили? Это то, что обычно называют проверкой, и о ней большая часть урока.
Процесс. Как модель пришла к результату? Если вы просили рассуждать по шагам — есть ли в рассуждении пропуски или подмены? Если просили сначала выписать факты из документа, а потом писать — сделала ли она это, или сразу начала сочинять? Ошибка в процессе — сигнал, что результату стоит доверять меньше, даже если он выглядит хорошо.
Поведение. Удобно ли было работать? Модель отвечала на вопрос или на соседний? Соглашалась со всем? Писала втрое длиннее нужного? Это не про качество текущего результата, а про то, что поправить в описании поведения на следующем круге.
Что искать в результате
У ошибок модели есть типичные места. Зная их, можно проверять прицельно.
Факты, которых не было на входе. Самая опасная категория. Модель добавила срок, цифру, название, характеристику, которых нет в исходных данных. Способ проверки: пройдитесь по каждому конкретному утверждению и спросите себя, откуда оно. Если источника нет — это либо удалить, либо подтвердить у того, кто знает. В нашем проекте сайта для мебельной компании именно так появились «премиальная фурнитура» и «срок две недели» на каждой работе: правдоподобно, гладко, ничем не подтверждено.
Сглаженные неопределённости. В заметках было «интеграция под вопросом», в письме стало «интеграция в работе». Модель убирает шероховатости, потому что гладкий текст вероятнее. Проверка: сравните каждое «сделано», «готово», «согласовано» с исходником.
Пропуски. Вы просили учесть пять требований — учтено четыре. Из документа на десять страниц в резюме попало содержимое семи. Проверка: сверьте по списку, а не по впечатлению.
Логические ошибки в правдоподобной упаковке. Расчёт с верными числами, но неверной операцией. Условие в коде, которое проверяет не то. Проверка: для чисел — пересчитать или попросить код; для кода — запустить тесты и прочитать условия глазами.
Несоответствие формату и аудитории. Просили для клиента — написано для разработчика. Просили 200 слов — 500. Это самая безобидная категория, но она показывает, что модель не удержала часть инструкции; возможно, не удержала и другую.
Как проверять по ролям
Проверка должна быть пропорциональна тому, куда идёт результат. Внутренний черновик — беглый взгляд. То, что уходит клиенту или в прод, — полная проверка.
Аналитик, ТЗ или требования. Каждый факт о бизнесе клиента — к источнику: цитата из интервью, действующий сайт, письмо. Каждое «должна» — проверить, что это требование клиента, а не разумное предположение модели. Отдельно — противоречия между разделами: попросите модель найти их, а потом проверьте сами.
Дизайнер, тексты и критика макета. Тексты интерфейса — читать вслух, они часто длиннее, чем поместится. Критика от «пользователя» — проверять, не подсказали ли вы модели ответ самой постановкой вопроса; если спросили «не слишком ли мелкий шрифт?», она согласится.
Разработчик, код. Прочитать дифф целиком, не только изменённые строки. Запустить тесты. Проверить, что тесты проверяют то, что заявляют в названии: тест «у каждой страницы уникальный title», который на деле проверяет непустоту, хуже, чем никакого теста. Обратить внимание на обработку ошибок и граничных случаев — их модель чаще всего опускает.
Тестировщик, чек-листы и кейсы. Сверить с ТЗ построчно: все ли требования покрыты. Найти дубли — модель любит написать один сценарий тремя формулировками. Проверить, что ожидаемые результаты конкретны, а не «форма работает корректно».
Менеджер, письма и статусы. Каждый факт — против заметок. Каждое обещание — ваше ли оно. Тон — уместен ли для этой недели и этого клиента. Имена, названия продуктов, суммы — побуквенно.
Способы проверки, которые экономят время
Проверка не обязана быть ручной от начала до конца. Несколько приёмов.
Попросите модель проверить саму себя — по списку. «Проверь этот текст по критериям: нет фактов, которых нет в источнике; нет обещаний; объём до 200 слов. По каждому критерию — да или нет с примером». Это не заменяет вашу проверку, но находит очевидное.
Второй разговор как рецензент. Откройте новый чат, вставьте результат и попросите найти ошибки, не сообщая, что это написала модель. Чистый контекст без истории даёт более честную оценку.
Спросите об уверенности и источниках. «Какие из этих утверждений ты вывела из документа, а какие — из общих знаний?» Ответ часто вскрывает догадки.
Проверяйте инструментами, где можно. Контраст — формулой, а не мнением. Числа — таблицей. Код — тестами. Ссылки — открыть. Всё, что можно проверить механически, стоит проверять механически.
Ищите первую ошибку, а не все. Если в первых двух абзацах нашлось две выдумки, дальше можно не читать — результат нужно переделывать с другим описанием. Не тратьте время на полировку того, что придётся выбросить.
Ловушка правдоподобия
Отдельно об одном эффекте. Чем лучше модель пишет, тем труднее проверять. Плохой текст сам сигналит: «прочитай меня внимательно». Хороший — усыпляет. Поэтому опытные пользователи ИИ проверяют гладкие тексты внимательнее, чем корявые, и специально ищут, к чему придраться.
Хорошая привычка — читать результат модели как чужой текст на ревью, а не как свой черновик. К чужому тексту мы по умолчанию критичны, к своему — нет.
Попробуйте сами
10–15 мин на рабочем месте- Возьмите любой результат от ИИ, который вы недавно использовали. Пройдитесь по нему с одним вопросом к каждому конкретному утверждению: «откуда это?». Отметьте всё, у чего нет источника. Обычно находится хотя бы одно.
- Попросите модель сделать что-то по документу (резюме, список требований, чек-лист). Затем сверьте по списку, а не по впечатлению: все ли пункты документа отражены. Посчитайте пропуски.
- Откройте новый чат и вставьте туда результат из пункта 2 с просьбой найти ошибки и пропуски, не говоря, что это писал ИИ. Сравните найденное с тем, что нашли вы.
Коротко
- Оцениваем три вещи: результат (верно ли), процесс (как пришли), поведение (удобно ли работать).
- Типичные ошибки: факты не с входа, сглаженные неопределённости, пропуски, логика в красивой упаковке, несоответствие формату.
- Главный вопрос к каждому утверждению: «откуда это?». Нет источника — удалить или подтвердить.
- Глубина проверки пропорциональна тому, куда идёт результат.
- Проверяйте механически всё, что можно: тесты, формулы, таблицы, ссылки.
- Гладкий текст проверяйте внимательнее корявого; читайте как чужой на ревью.
Видеоверсия
Сценарий озвучки · 455 слов, ≈ 4 мин
Различение — это навык, который отделяет людей, которым ИИ помогает, от людей, которым он создаёт проблемы. Черновик от модели всегда выглядит готовым: ровный, уверенный, без опечаток. Именно поэтому его так легко отправить дальше не глядя.
Модель четыре Д выделяет три предмета оценки. Результат: верно ли написано, работает ли код, уместен ли тон. Процесс: как модель к этому пришла — если вы просили сначала выписать факты, а потом писать, сделала ли она это, или сразу начала сочинять. Ошибка в процессе — сигнал, что результату стоит доверять меньше. И поведение: удобно ли было работать, отвечала ли модель на вопрос или на соседний. Это не про качество текущего результата, а про то, что поправить в описании на следующем круге.
У ошибок модели есть типичные места. Первое и самое опасное — факты, которых не было на входе. Срок, цифра, характеристика, которых нет в исходных данных. В одном нашем проекте так появились «премиальная фурнитура» и «срок две недели» на каждой работе в портфолио: правдоподобно, гладко, ничем не подтверждено. Способ проверки один: к каждому утверждению вопрос «откуда это?». Нет источника — удалить или подтвердить у того, кто знает.
Второе — сглаженные неопределённости. В заметках было «интеграция под вопросом», в письме стало «в работе». Модель убирает шероховатости, потому что гладкий текст вероятнее. Третье — пропуски: просили учесть пять требований, учтено четыре. Проверяйте по списку, а не по впечатлению. Четвёртое — логика в красивой упаковке: верные числа, неверная операция; условие в коде, которое проверяет не то. Для чисел — пересчитать, для кода — запустить тесты и прочитать условия глазами.
Глубина проверки зависит от того, куда идёт результат. Внутренний черновик — беглый взгляд. То, что уходит клиенту или в прод, — полная проверка. Аналитик сверяет каждый факт о бизнесе клиента с источником. Разработчик читает дифф целиком и проверяет, что тесты проверяют то, что заявляют в названии. Тестировщик сверяет чек-лист с ТЗ построчно и ищет дубли. Менеджер сверяет каждый факт с заметками, а имена и суммы — побуквенно.
Несколько приёмов, которые экономят время. Попросите модель проверить саму себя по списку критериев, с ответом «да» или «нет» по каждому. Откройте новый чат и попросите найти ошибки, не говоря, что это писал ИИ, — чистый контекст даёт более честную оценку. Спросите, какие утверждения выведены из документа, а какие — из общих знаний. Проверяйте инструментами всё, что можно: контраст формулой, числа таблицей, код тестами. И ищите первую ошибку, а не все: если в двух абзацах две выдумки, дальше не читайте — переделывайте с другим описанием.
И последнее. Чем лучше модель пишет, тем труднее проверять. Плохой текст сам просит прочитать себя внимательно, хороший — усыпляет. Поэтому гладкие тексты проверяйте внимательнее корявых. Хорошая привычка — читать результат модели как чужой текст на ревью, а не как свой черновик. К чужому мы по умолчанию критичны.
Задание: возьмите любой недавний результат от ИИ и пройдитесь по нему с одним вопросом — «откуда это?». Обычно находится хотя бы одно утверждение без источника.