Осталось только всё улучшить: почему с ИИ так трудно закончить работу

С искусственным интеллектом в его современном состоянии есть одна известная проблема, которая называется шумным критиком.

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

Кроме того, если с самого начала пытаться создать протокол поиска ошибок, то нередко внезапно оказывается, что этот протокол не очень то эффективный, но жрет много токенов.

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

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

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

Одна фраза — и вы снова заняты

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

Добавить экспорт? Придётся разобраться с форматами данных.

Переделать интерфейс? Нужно вспомнить, почему он вообще устроен именно так.

Поддержать ещё одну операционную систему? Придется изучить все подводные камни.

На этом этапе часть идей отваливается. В том числе очень хорошие идеи.

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

«Добавь».

«Перепиши».

«Проверь ещё раз».

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

А ведь новый код нужно даже если не прочитать, но хотя бы как-то надежно протестировать. Все изменения нужно проверить, все побочные эффекты найти, зависимости отследить.

ИИ действительно может взять на себя значительную часть этой работы.

Но каждый новый круг всё равно требует ресурсов и решений.

Особенно решения о том, что считать удовлетворительным результатом.

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

Вот такая вот выходит диалектика раба и господина, но уже на новом историческом этапе.

Проект всегда почти готов

В самом начале у пользователя обычно существует ясное и простое, можно сказать незамутненно-наивное, представление о конечном результате.

Программа должна обработать документ. График — показать зависимость. Небольшой сервис — решить одну задачу по автоматизации.

Но когда от идеи переходим к реализации с помощью ИИ, начинаем видеть возможности. Неограниченные возможности, которые увлекают и порабощают человека.

К документу добавим красивую вёрстку. К графикам добавим интерактивность. К сервису — личный кабинет. Раз уж появился личный кабинет, неплохо бы сделать восстановление доступа, кроссплатформенность. А здесь уже открывается настоящий ад.

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

Самое же интересное происходит с этим волшебным словом «готово».

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

Разумеется, требования не только могут, но и должны меняться, потому что работа над проектом помогает понять задачу лучше. Но как вовремя остановиться?

Например:

— Можно заканчивать?

— Заявленные требования выполнены. Обязательные проверки пройдены, все тесты зеленые. Но есть несколько недочетов и возможных улучшений.

— Давай сначала их.

ИИ сообщил всё правильно. Но именно тем самым начал бесконечный цикл правок. Которые могут не только не улучшат, но и в итоге ухудшат конечный результат.

Лампа уже светит. Осталось закончить инфраструктуру.

Своя маленькая машина Голдберга

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

Такие конструкции придумывают специально. Наблюдать за ними приятно именно потому, что путь к результату совершенно несоразмерен самому результату.

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

При создании кода с помощью ИИ подобные конструкции возникают сами собой без такого намерения. Во-первых, потому что сам кодогенератор по сути является наследником бредогенераторов текста или расширенным T9. Хотя работать он стал гораздо лучше, суть не изменилась, и именно она будет проявляться всё равно при расширении масштаба проекта.

Во-вторых, описанная выше проблема шумного критика построению подобной машины Голдберга из кода весьма неплохо способствует. Потому что ИИ не умеет по-настоящему согласовывать каждую новую попытку улучшения с уже построенной архитектурой. Растут зависимости, растут костыли, правки, и вокруг кода вырастает настоящий монстр.

Всегда стоит остановиться и проверить, не строим ли мы машину Голдберга вместо того, чтобы сделать работающий код.

Демонстрация механической энергии, научный центр Бхопала. Фото: Utkarshraj Atmaram. CC BY-SA 3.0; источник.

Ещё четыре фотографии машин Голдберга

Машина Голдберга в Imagination Station. Фото: Mbrickn. CC0 1.0; источник.

Фрагмент машины Голдберга, 2006. Фото: Jeff Kubina. CC BY-SA 2.0; источник.

Making Orange Juice: машина для приготовления апельсинового сока. Фото: jclarson. CC BY 2.0; источник.

Конкурсная машина Toyland: забить гвоздь через цепочку действий. Фото: ENERGY.GOV / Argonne National Laboratory. Public domain (US DOE); источник.

Перфекционизм получил помощника

Конечно, бесконечная доводка существовала задолго до нейросетей.

Однако старый перфексионизм обычно не ухудшал проект вместо улучшения, и не получал машины Голдберга, руководствуясь благими намерениями.

Сто исправленных замечаний могут означать огромный прогресс. А могут означать, что мы давно потеряли меру и создали машину Голдберга вместо рационального проекта. По одному количеству изменений этого не определить.

Проверка тоже умеет строить машины Голдберга

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

Проблема возникает, когда разные предложения попадают в один список:

• при прерывании обработки теряется прогресс;

• программа неверно обрабатывает один из форматов;

• можно добавить ещё один формат;

• стоит сделать переключатель темы оформления или другую дополнительную фичу.

Все четыре пункта могут быть сформулированы одинаково убедительно.

Но к готовности текущей версии они относятся по-разному.

Первые два указывают на невыполненные обязательства.

Остальные предлагают расширить возможности продукта.

Если воспринимать весь список как обязательную программу, то любая перепроверка становится ещё и планированием следующей версии.

После реализации понадобится новая проверка и так до бесконечности. Количеством тестов это не решить: можно только усугубить. Разорвать порочный круг помогает конкретный вопрос: а какая действительно важная цель еще не достигнута?

Улучшать безопаснее, чем выпускать

Пока проект в разработке, легко принять что угодно за улучшение. Новая функция — прогресс. Красивый отчёт — прогресс. Устранённое замечание — тоже.

Но если этим проектом начать пользоваться, и особенно кому-то давать еще, возникает много вопросов, которые полностью разрушают всю эту иллюзию.

Понятно ли людям, зачем им это вообще нужно?

Решает ли программа их проблемы? Не создает ли новых?

Ещё одна внутренняя проверка не даст полного ответа, необходима практика использования. А если пользователей предполагается много, то даже настоящее A/В-тестирование.

Выводы

Итак, ИИ способен помочь закончить то, что без него годами оставалось бы в черновиках, смелых идеях и без него, возможно, никогда бы оттуда и не вышло в реальность.

Мне кажется полезным ещё до работы разделить три вещи:

1. Что обязательно должно работать.

2. Какие обнаруженные проблемы действительно критичны.

3. Какие идеи можно спокойно сохранить на потом.

Это разделение можно пересматривать. Но лучше сделать его заранее.

А какое «последнее небольшое улучшение» у вас однажды превратилось в отдельный проект? И кто в итоге сказал: достаточно, выпускаем?

Если эта публикация вас вдохновила и вы хотите поддержать автора — не стесняйтесь нажать на кнопку