«Внедрение нейросетей на производстве — это часто скрытая война»

Камиль Гадеев

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

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

О том как новая технология ломает старые методы и создаёт новые, взгляд на автоматизацию с точки зрения реинжиниринга бизнес-процессов, психологии и мотивации, и о переписке с Майклом Хаммером, мировым гуру в этой области. Потому что автоматизация — это всегда про людей, а не только про технологии.

Claude добавил новую фичу в десктопной версии.

А именно, в интерфейсе появилась третья закладка — Code.

Главное нововведение — это возможность подключать код проекта прямо в чат и работать с ним без копипаста.

Возможно это было уже давно, но я увидел только сегодня.

А именно, когда начинается новый чат в Claude, то там появляются такие подменюшки под окном для чата

Write - Learn - Code - Life Stuff - Claude’s Choice

Кликнул ради интереса последнюю, открылся ещё целый список. И он, кстати, все время меняется.

В общем, это заготовки для начала чата по определённой теме, т.е., образец готового промта. Мне попалась на глаза тема "Узнать об архитектурных концепциях". И поскольку живёшь в мире программирования, то первая мысль об архитектурных паттернах )). Но оказалось, что это именно об архитектуре как строительстве чего-то в реальном, физическом мире.

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

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

Содержание этого документа интересно и с исторической точки зрения (а как там “деды” воевали программировали), так и в плане уточнения некоторых современных представлений об этом паттерне и программной архитектуре в целом.

Иллюстрации по максимуму сохранены как в оригинале. По ходу есть сноски с подробностями и ассоциации редактора в конце.

СУЩНОСТЬ-МОДЕЛЬ-ВЬЮ¹-РЕДАКТОР

на примере из системы планирования²

Кому: LRG³

От: Тригве Реенскауг⁴

Файл: [IVY]<Reenskaug>SMALL>TERMINOLOGY2.DOC

Дата: 12 мая 1979⁵

Цель данной заметки - исследовать метафоры thing-model-view-editor через последовательный набор примеров. Все примеры взяты из моей системы планирования и иллюстрируют вышеуказанные четыре понятия. Все примеры были реализованы, хотя и не в рамках чистой структуры классов, описанной здесь. Метафоры соответствуют real world-Model-view-Tool, предложенным в заметке о требованиях DynaBook ([Ivy]<Reenskaug>DynaBook.doc).

THING (СУЩНОСТЬ)

ОПИСАНИЕ ТЕРМИНА

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

ПРИМЕР: КРУПНЫЙ ПРОЕКТ

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

Несколько месяцев назад решил поэкспериментировать с ChatGPT по поводу поиска информации в интернете. Задал вопрос «Что такое длинная воля?».

Это выражение встречается в работах Льва Гумилёва, на мой взгляд, лучшего учёного‑историка нашего времени. Не помню уже в какой именно книге, но в его работах это выражение встречается несколько раз по отношению, в частности, к Чингис‑Хану. Но толком не объясняется.

В общем, задал вопрос и получаю ответ совсем никудышный. ChatGPT выдаёт несколько «ответов» со ссылками на какие‑то совершенно левые работы, даже не упоминая непосредственно работы Гумилёва. И сами ответы были в таком стиле, что это выражение встречается в его работах, но как это понимать — ни слова. И главным источником информации названа статья какого‑совсем неизвестного автора 20–30-х годов. В общем, облом.

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

После этого активно пользуюсь этой самой Perplexity. Google уже практически забыт, да и ChatGPT практически тоже выглядит как бы ненужным. И с удовольствием отмечаю, что не я один это заметил. Потому как в интернете пошли слухи, что Apple обсуждает возможность купить Perplexity за $24 ярда, что для Apple самая крупная покупка.

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

На YouTube опубликовано видео, посвящённое теме искусственного интеллекта. В нём автор со своей точки зрения обычного человека (не ИТ и не ИИ) и журналиста обсуждает эту тему с Андреем Дроничевым, который был участником выпуска про жизнь наших соотечественников в Кремниевой долине пять лет назад (как время бежит!))

В IT-кругах Андрей Дроничев известен тем, что долгое время работал в Google, участвовал в создании мобильного YouTube, а теперь основал свой стартап, в котором они с помощью ИИ ищут молекулы для создания лекарств от онкологических заболеваний. Там они приводят цифры, что человек за день может просмотреть пару тысяч изображений молекул, а нейронка за минуты - до миллиарда!

В этом интервью много интересных моментов. Например, как обучают ИИ, сколько эти ИИ сжирают электричества (на $10 000 в день), какая новая и самая перспективная профессия уже реально есть по причине нейронок, как принципиально меняется профессия программиста и др. Эта статья не ставит себе целью пересказать их все. Затрону только те, которые, на мой взгляд, достаточно свежие и не тавтологичные в контексте нынешнего бурного обсуждения ИИ и его возможностей.

В этой статье рассказывал об опыте создания мобильного приложения с помощью Claude Sonnet. И в одном из комментариев было сказано, что надо было «сделать скрининг запросов и вывода при использовании ИИ». Это удивило, потому что чат составил порядка 77 страниц и каким образом можно было бы опубликовать все те промты, которые там использовались?

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

В результате стало ясно, что есть 2 вида промтов — горизонтальные и вертикальные.

Часть 2: Загрузка данных and Improving или "Хождение по промтам"

Цель этой публикации — показать процесс взаимодействия с ИИ при написании мобильного приложения. Обычно в таких историях публикуют исходный промт, а затем готовый результат. Здесь же хотелось показать более подробно именно сам процесс «Хождения по промтам», как по ходу выстраиваются «взаимоотношения» и происходит взаимообучение ИИ и разработчика. Думаю это будет полезно как уже работающим с ИИ для написания кода, так и тем, кто только начинает входить в этот сегодняшний main stream.

Статья написана в продолжение поста, в котором рассказывалось как с помощью Claude Sonnet 3.7 было написано небольшое мобильное приложение на SwiftUI. Это пользовательский список фильмов. И да, я знаю, что таких приложений вагон и маленькая тележка, но как любому разработчику не нравится брать что‑то навороченное и непонятное, а хочется, как всегда, сделать что‑то «простое и удобное».

Загрузка данных

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

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

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

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

И в эту минуту я чувствую как начинают шевелиться волосы на моей голове. От шока, что не понимаю, чтоэто такое.

Потом подумал, что он, наверное, это где‑то объяснил, а я пропустил. Проверил предыдущие страницы, не нашёл. Может он потом объяснит, бывают же такие преподы, сначала что‑то скажет, а потом разберёт. Посмотрел вперёд, не нашёл тоже.

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

С тех пор, если встречается в книге, что автор научит всех, даже тех, кто «никогда не программировал», то невольно вздрагиваю, как от легкого удара электрическим током.

И самое смешное, что недавно, на современном курсе по изучению программирования, услышал то же самое. Преподаватель, как только зацепился за тип Int, тут же начал рассуждать все о тех же Int16, Int32, Int64 и т. д. Как будто он попадает в разъезженную колею и уже не может из нее выбраться.

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

Постановка проблемы

На сегодняшний день наиболее известны такие архитектурные паттерны как MVC, MVVM, MVP, Viper, Clean Code.

Все они в той или иной мере работают с тремя основными сущностями - Модель, Вью, Контроллер, добавляя время от времени некоторые дополнительные, например, Presenter.

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

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

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

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

Именно в такие моменты приходится переосмысливать общую архитектуру проекта и отвечать на вопросы “Зачем нужен тот или иной код, какую задачу он решает?”, “Где расположен код, реализующий ту или иную функциональность и как он работает?”. И т.д.

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

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

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

При этом, задача понимается как бизнес-процесс.