Transcription
Всем привет. Искусственный интеллект, ну, он всё активнее меняет правила игры в разработке ПО. Как нам, инженерам, аналитикам, тимлидам, ээ, как не просто приспособиться, а вот использовать эту мощь, ну, себе во благо, да? Вопрос такой очень актуальный. Как остаться именно инженером-мыслителем, а не просто, ну, оператором. И вот-вот.
И сегодня мы как раз поищем ответы в идеях Джима Арлу и Иланы Нойштат. У них книга есть "Generative Analysis". Генеративный анализ. Звучит, да, интригующе. По названию кажется, что это какой-то такой системный подход, чтобы, ну, осмысленно работать с генеративным и формулировать задачи так, чтобы он помогал по-настоящему.
Именно. Давайте разбираться тогда, что это за генеративный анализ, что он предлагает, какие инструменты и главное, насколько это вообще применимо, ну, в реальной работе.
Слушай, тут важный момент сразу нужно прояснить. Эта книга - это не про то, как найти волшебную кнопку или там идеальный промт, чтобы и и раз и всё сделал. Нет.
Угу. Это гораздо глубже. Речь про интеграцию и в сам процесс, в анализ, в проектирование. Как нам создавать такие описания, ну, модели реальности, чтобы ИИ стал полезным партнёром, а не просто генератором кода по шаблону.
Точно. Ключ он в тщательном, структурированном анализе. Вот это главное. То есть, чтобы получить умный результат от ИИ, надо сначала самому, ну, хорошенько так подумать и всё чётко сформулировать.
Именно так. В этом, собственно, и есть суть генеративного анализа или ГА. Это методология такая, где в центре коммуникация и моделирование. Идея - это простая, но важная. И мы, люди, и ИИ мы же работаем не с реальностью напрямую, а с её моделями, с нашими представлениями о ней.
Совершенно верно. И вот цель ГА - научить создавать очень точные, недвусмысленные, формализованные модели предметной области.
Это что может быть? UML-диаграммы?
И UML-диаграммы, и спецификации, и тексты структурированные. В общем, любые артефакты, которые описывают систему. Если модель сделана, ну, правильно, качественно, то и ИИ её поймёт, да, сможет понять и использовать для генерации кода, например.
Угу. А кроме кода, тестов, документации, возможно, даже других моделей сможет сгенерировать. Но тут, конечно, возникает классическая проблема.
Разные уровни мышления.
Угу. Программисты мыслят кодом, аналитики, ну, больше бизнес-процессами. Как им договориться между собой? Да ещё и объяснить это всё машине. ИИ.
Да уж, задачка. И вот ГА как раз пытается на этот вызов ответить. Авторы говорят, что нужно, ну, как бы движение с обеих сторон. Программистам учиться подниматься над кодом, мыслить абстрактнее, может, архитектурно.
А аналитикам? А бизнес-аналитикам, наоборот, спускаться к большей точности, формализму. Может быть, активнее использовать языки моделирования, тот же UML, Unified Modeling Language.
То есть развивать такую ментальную гибкость, чтобы переключаться между уровнями абстракции. Помню, в книге был забавный пример про собак Павлова.
Да-да. Про собак, которые там осиливали всего два-три уровня сигналов.
Угу. А наша сила как раз в способности оперировать многими уровнями, от молекул там до целых экосистем. И вот это сейчас критически важно. Потому что ИИ, особенно LLM, да, они ведь тоже работают с абстракциями, и нам нужно очень чётко понимать, на каком уровне мы с ними общаемся. Модель - это ведь всегда упрощение. Карта, а не территория.
Значит, надо правильно выбрать масштаб этой карты для конкретной задачи, для ИИ.
Вот именно. И авторы тут вводят два типа абстракции. Первое - количественная. Это как на карте города. Можно показать все переулки, а можно только главные улицы.
Меняем количество деталей.
Да, но суть представления - географическая карта, она та же. А есть качественная абстракция. Это вот как заменить географическую карту схемой метро.
А, понятно. Меняется сам принцип, чтобы увидеть другое, там пересадки, например.
Точно, фокус меняется, видны другие связи.
Поняла. То есть или меняем количество деталей, или сам способ взгляда на проблему. И как это помогает в общении с ИИ?
Ну, понимание этих типов помогает осознанно модель для ИИ выбирать. Иногда нужно просто шум убрать, это количественное. А иногда дать ей принципиально другое представление задачи, качественное, чтобы он, ну, смог сгенерировать то, что нам нужно.
Интересно. И вот тут мы подходим к ээ любопытному моменту. Как ИИ понимает наши запросы и почему он иногда, ну, галлюцинирует?
Да, кстати, авторы там проводят неожиданную параллель с человеческим восприятием, даже НЛП упоминают. Звучит, ну, немного ээ странно для технарской книги.
Ну, они используют это скорее как аналогию, конечно, не как прямое равенство. Идея в чём? Наш мозг, он же фильтрует реальность, что-то удаляет, что-то искажает. Ну, чтобы просто справиться с потоком информации.
Защитный механизм такой.
Да. LLM, они же обучены на огромных массивах текстов, и они делают нечто похожее, но на основе статистики просто предсказывают следующее, наиболее вероятное слово. И вот галлюцинация - это когда эта статистическая модель генерирует текст, который, ну, вроде складный, но неверный или нерелевантный запросу.
Как бы сбои в статистике.
Ну, можно и так сказать. Модель как бы теряет связь с реальностью запроса и уходит в мир своих статистических паттернов.
И какой отсюда практический вывод, как заставить ИИ помогать, а не галлюцинировать?
А вывод старой как мир: "Garbage in, garbage out". Мусор на входе, мусор на выходе. Значит, всё опять упирается в качество промпта.
В точность, ясность, детализацию запроса. Да, если дать общий запрос типа "сгенерируй класс пользователя", ну, почти наверняка получишь какую-то шаблонную ерунду, галлюцинацию.
Ага. А вот если дать детальную спецификацию, ну, например, "класс Employee, атрибуты: name, тип string; position, string; department, ссылка на класс Department", вот это уже даст гораздо более предсказуемый результат.
То есть чем меньше свободы для творчества, тем меньше ошибок. Но всегда ли это так работает?
Не всегда. И вот тут авторы прямо очень настойчиво повторяют: "Всегда проверяйте результат работы ИИ, даже при идеальном промте".
Даже при идеальном. ИИ он склонен к удалениям, как они пишут. Он может что-то пропустить, забыть реализовать какое-то ограничение бизнес-правил, даже если оно было упомянуто.
Понятно. Он мощный ускоритель, да, но не оракул. Источник правды - это всё равно наше знание. Наши модели, наши требования и наш критический взгляд инженера. Нужно проверять, тестировать, верифицировать.
Получается, такое узкое место смещается не кодирование само по себе, а именно анализ, моделирование, формулирование задачи для ИИ. Какие инструменты предлагает ГА, чтобы с этим справляться?
Авторы берут несколько известных, проверенных техник и адаптируют их для, так сказать, подготовки пищи для ИИ. Во-первых, майндмэп, ментальные карты.
А, ну это знакомо для мозгового штурма, да?
Да, для быстрого штурма. Фиксация идей после встречи, например. Структура свободная, ассоциативная. Для старта самое то.
Хорошо. Что ещё?
Во-вторых, концептуальные карты. Концептмэппинг - это уже более строгий инструмент. Узлы - это понятие, а линии между ними - это именованные связи. Они описывают отношения. Ну, например, "библиотекарь" - узел, "каталог" - узел, а связь "управляет". Получаются такие атомарные факты.
Именно их называют пропозиции. "Библиотекарь управляет каталогом". Вот такие структурированные факты ИИ понимает гораздо лучше, чем просто неструктурированный текст.
Пропозиция звучит как основа для будущих требований к системе.
Так и есть, по сути. Третий инструмент. Карты диалогов. Диалогмэппинг. Это больше для фасилитации, особенно когда обсуждение сложное, много мнений, противоречий. Wicked problems, как их называют.
Да-да, эта техника помогает визуализировать ход дискуссии, вопросы, идеи, аргументы за и против, решения, чтобы структурировать хаос и как-то прийти к консенсусу.
Полезно. И четвёртое.
Четвёртое - структурированное письмо. Structured writing.
Это о том, как писать тексты, чтобы они были понятны и людям, и машинам. Да, там набор довольно простых принципов: релевантность, чёткая цель у текста, логичная структура, информация небольшими блоками, понятные заголовки, списки, графика, чтобы и человек легко прочитал и понял, и ИИ мог эффективно извлечь нужную информацию.
Так, понятно. Карты для идей, карты для диалогов, принципы для текстов. А вот как быть с UML-диаграммами? Их же часто бизнес не очень понимает. Теряется контекст, почему именно так смоделировано.
Вот для этого авторы предлагают штуку под названием "Literate Modelling". Грамотное моделирование, можно перевести.
И в чём идея?
Идея в том, чтобы не просто рисовать диаграммы и писать текст рядом, а встраивать фрагменты моделей, ну, тот же UML, прямо в повествование на естественном языке. Получается такой документ "бизнес-контекста" - Business Context Document или BCD.
Как это выглядит на практике?
Ну, представь. Идёт текст, который рассказывает о системе. И когда в тексте упоминается какой-то термин, который соответствует элементу модели, ну, скажем, "класс Заказ" или "атрибут Статус Заказа",
Угу. этот термин выделяется, и прямо рядом с текстом встраивается небольшой фрагмент UML-диаграммы, где этот элемент показан. Текст поясняет модель, а модель иллюстрирует текст. Они как бы живут вместе, контекст не теряется.
Звучит здорово, прямо как решение для создания общего языка и понимания между разными ролями в команде. А ИИ тут может помочь?
Может, конечно, может сгенерировать черновик такого BCD по уже существующей модели или наоборот, предложить фрагменты UML по написанному тексту. Но главная ценность тут, мне кажется, всё-таки в коммуникации между людьми.
Ясно. Слушай, ещё один термин зацепил в книге - "Software Sanity". Здравость. Что авторы в это вкладывают?
А это такой, знаешь, прагматичный взгляд на софт. Они предлагают смотреть на ПО по двум осям. Первое - "Interface Sanity", здравость интерфейса.
То есть насколько система полезна, удобна, понятна для пользователя. Внешний вид, польза.
Именно. А вторая ось - "Implementation Sanity", здравость реализации. Это уже про то, насколько хорошо система устроена внутри. Качество дизайна, понятность кода, поддерживаемость, стабильность.
И что даёт эта матрица из двух осей?
А она даёт четыре квадранта. Ну, идеальный случай - "Interface Sanity" и "Implementation Sanity". То есть и пользователю удобно, и внутри всё красиво, здраво.
Понятно? Худший случай - "Interface Unsanity" и "Implementation Unsanity". То есть и пользователю неудобно, и внутри бардак. Тоже ясно. Интереснее два других квадранта.
Какие?
Первый - "Interface Unsanity" и "Implementation Sanity". Это когда внутри всё хорошо спроектировано, код чистый, но пользоваться системой невозможно или неудобно.
Бывает такое.
А второй, самый такой провокационный, что ли, "Interface Sanity" и "Implementation Unsanity". Это когда пользователю всё нравится, система полезная, удобная - "Interface Sanity", но вот внутри там либо хаос, либо вообще чёрный ящик.
Как раз как многие системы глубокого обучения. Да.
Точно. Они могут быть очень полезны, решать задачи пользователя - "Interface Sanity", но их внутренняя работа не всегда до конца понятна даже создателям, или она не идеальна с точки зрения классической инженерии - "Implementation Unsanity".
Угу. И вот тут ключевой вывод авторов, как я его понял. Успех таких систем-чёрных ящиков показывает, что ценность для пользователя, вот эта "Interface Sanity", может быть важнее, чем идеальная внутренняя реализация - "Implementation Sanity".
Ого, это же серьёзный такой вызов традиционному фокусу инженеров именно на чистоте кода, на внутреннем устройстве.
Да, это так. Это не значит, конечно, что теперь можно писать плохой код как попало. Вовсе нет. Но это значит, что фокус, возможно, смещается.
И как тут помогает ИИ?
ИИ как раз и помогает, концентрируясь на максимально точном описании требований к поведению системы, то есть на спецификации вот этой самой "Interface Sanity". Даже если внутри у нас чёрный ящик, у нас должен быть чёткий критерий для тестирования, для верификации, делает ли система то, что от неё ожидается.
То есть управление сложностью переносится с кода на спецификацию.
В каком-то смысле, да. Если мы можем точно описать, что система должна делать, мы можем это проверить, даже не всегда понимая до конца, как она это делает внутри.
Логично. Ну вот смотри, у нас получается куча всего. Ментальные карты, концептуальные, диалоговые, BCD, пропозиции, требования. Как во всей этой информации не утонуть? Как этим управлять?
Для этого авторы предлагают довольно простую модель управления информацией - JIA, Information Model. J - это от их имён Джим, Иланна, Арлоу.
А, понятно. Там всего восемь типов информации: информация как таковая, действия, вопрос, пропозиция, ресурс (например, ссылка на документ), идея, требования и термин. У каждого типа есть свои атрибуты, там статус, приоритет, источник и свой жизненный цикл, чтобы отслеживать прогресс.
Какие из этих типов самые важные для JIA?
Ну, пожалуй, ключевые - это пропозиции, требования и термины. Пропозиции - это вот те самые атомарные факты о предметной области.
Ага. Причём для них используется интересная четырёхзначная логика: True (истина), False (ложь), Maybe (возможно) и Undefined (не определено). Это чтобы честно отражать неопределённость, которая всегда есть на ранних этапах анализа.
А требования?
Требования - это уже чёткие утверждения вида: "система должна" или "система не должна". Они идут в спецификацию. А термины - это ключевые понятия предметной области. Их важно собрать в единый глоссарий проекта, чтобы все говорили на одном языке.
Понятно. А как на практике использовать эти типы информации? Сидеть и вручную размечать тексты протоколов встреч, например?
Можно и вручную. Авторы предлагают технику семантическое выделение, semantic highlighting. Просто берёшь маркеры разных цветов и выделяешь в тексте: термины жёлтым, требования синим, вопросы красным, ну и так далее. Визуально помогает структурировать.
Да, но и тут тоже может помочь. Современные NLP-модели вполне способны автоматически находить и классифицировать вот эти единицы информации в тексте. Не идеально, конечно, но как первый проход вполне.
Слушай, в книге все эти концепции и инструменты иллюстрируются на сквозном примере. Система "Оклас" для библиотеки Мискотоникского университета. С Лавкрафтом там ещё связано.
Да, да, сеттинг такой с юмором. Привет Лавкрафту. Но пример, на мой взгляд, очень удачный. Он достаточно комплексный, чтобы показать применение техник ГА на разных этапах.
Что они там делают?
Ну, они начинают с анализа Vision Statement, видения системы, с помощью концептуальных карт. Потом используют ИИ, там "Кайлот" упоминается, для генерации кода, диаграмм, но с обязательным рефреном: "проверяйте и верифицируйте".
Без этого никуда. Конечно. Дальше они строят модель прецедентов, ищут акторов, сами кейсы, разбивают систему на подсистемы. Очень хорошо показано, как они решают проблему омонимов. Ну, когда одно слово имеет разные значения, через глоссарий и точное моделирование. Например, слово "библиотекарь" - это роль или должность?
Важный нюанс. Да, показывают, как создавать те самые грамотные модели BCD, как применять ООП, паттерны, например, "Type Instance" для каталога книг. Даже затрагивают продвинутые техники из NLP типа "Meta Model Plus" для анализа коммуникаций. В общем, "Оклас" - это такая хорошая песочница, чтобы увидеть весь инструментарий ГА в действии.
И убедиться, что ИИ - это всё-таки инструмент, а не замена мозгов.
Именно так. Он помогает, ускоряет, но думать, анализировать, принимать решения - это по-прежнему задача инженера. Картина вырисовывается действительно интересная. Получается, генеративный анализ - это не просто набор каких-то техник, а скорее целая философия. Философия адаптации к новому миру разработки, где ИИ уже активный участник процесса. Что же самое главное нужно из этого вынести? Вот если подытожить?
Но если суммировать, ГА выдвигает на первый план несколько ключевых навыков, которые становятся ещё важнее. Во-первых, это умение мыслить и работать на нужном уровне абстракции. Та самая ментальная гибкость, о которой мы говорили.
Угу. Во-вторых, это мастерство точной коммуникации. Причём как с людьми через вот эти BCD, структурированные тексты, модели, так и с ИИ, через точные промпты, через формализованные модели.
Гибкость и точность. Что ещё?
В-третьих - это владение инструментами структурирования знаний: карты, модели, глоссарии, умение превращать хаос идей и требований в какой-то порядок.
Наводить порядок в голове и в документах.
Да. И в-четвёртых, возможно, это самое важное сейчас, это критическое мышление, способность сомневаться, проверять, верифицировать абсолютно всё, особенно то, что сгенерировал ИИ. Инженер остаётся последней инстанцией здравого смысла.
Да уж, эти навыки точно не обесценятся с приходом ИИ, скорее наоборот. Это всё, конечно, подталкивает к размышлениям о будущем нашей профессии.
И вот тут, знаешь, есть финальный вопрос на подумать. Он вытекает как раз из концепции "Software Sanity", о которой мы говорили, особенно из того квадранта "Interface Sanity" и "Implementation Unsanity". Ну, то есть чёрные ящики, которые полезны пользователю, но внутри не до конца понятны. Так вот, если мы действительно всё чаще будем создавать такие системы, которые великолепны для пользователя, но чья внутренняя работа сложна, запутана или просто непостижима для нас самих, как это изменит саму суть профессии инженера ПО в долгосрочной перспективе?
Действительно, как не получится ли так, что главной нашей задачей станет вот это филигранное описание задачи, построение идеальной спецификации, идеального промпта? И будет ли одного этого навыка - точно ставить задачу машине - достаточно? Достаточно для создания действительно надёжных, безопасных, развиваемых систем? Или есть риск, или мы рискуем построить нечто внешне очень красивое и полезное, но стоящее на таком шатком фундаменте нашего неполного понимания того, как оно работает внутри.
Отличный вопрос, прям почти экзистенциальный для профессии. На нём, наверное, и стоит сегодня остановиться и дать возможность нашим слушателям над этим подумать.
Да, вопрос открытый. На этом наше сегодняшнее погружение завершаем. Спасибо за внимание. Так.