
Искусственный интеллект. С неба на землю
Однако, важно понимать, что зоны не являются статичными и могут меняться со временем. Поэтому, команда должна постоянно оценивать свой контекст и адаптировать свой подход к ретроспективам. Цель ретроспектив не в том, чтобы применять Agile бесконечно, а в том, чтобы уводить команду от ситуации неопределенности к ситуации сложных упорядоченных или простых упорядоченных систем. Только тогда ретроспективы будут приносить пользу и удовольствие команде и проекту».
Ответ GigaChat: «Agile – это методология разработки программного обеспечения, которая стала очень популярной в последние годы. Она предлагает гибкий подход к управлению проектами, который позволяет быстро реагировать на изменения и адаптироваться к новым требованиям. Однако, бесконечное применение Agile может привести к проблемам.
Одной из главных причин, почему Agile бесконечно применять неправильно, является то, что он может привести к ситуации неопределенности. В Agile-проектах мы часто сталкиваемся с изменениями требований и приоритетов, что может вызывать неопределенность в отношении того, что нужно делать дальше.
Проведение ретроспектив является одним из способов борьбы с этой неопределенностью. Ретроспективы помогают команде понять, что было сделано правильно и что нужно улучшить в будущем. Они также помогают команде перейти от ситуации неопределенности к ситуации сложных упорядоченных или простых упорядоченных систем.
Однако, если мы бесконечно применяем Agile без проведения ретроспектив, то мы можем остаться в ситуации неопределенности. Это может привести к тому, что команда будет тратить много времени на исправление ошибок и адаптацию к новым требованиям, а не на создание нового функционала.
Кроме того, бесконечное применение Agile может привести к тому, что команда будет постоянно работать над мелкими задачами и не будет иметь времени на создание больших функциональных блоков. Это может привести к тому, что проект будет развиваться медленно и не будет соответствовать ожиданиям заказчика.
В целом, Agile – это отличный подход к управлению проектами, но его бесконечное применение может привести к проблемам. Проведение ретроспектив помогает команде перейти от ситуации неопределенности к ситуации сложных упорядоченных или простых упорядоченных систем и улучшить качество работы команды».
Ответ Yandex GPT2: «Бесконечное применение Agile может привести к неправильным решениям и проблемам с качеством продукта. Важно понимать, что Agile не является универсальным решением для всех проектов и команд, и его постоянное использование может привести к потере эффективности и продуктивности.
Одним из ключевых принципов Agile является проведение ретроспективных сессий, которые помогают команде проанализировать свои прошлые успехи и неудачи. Однако, если эти ретроспективы проводятся постоянно, это может увести команду от решения реальных проблем и задач.
Вместо того чтобы помогать команде развиваться и становиться более эффективными, постоянные ретроспективы могут привести к ситуации, когда команда постоянно обсуждает одни и те же проблемы и не может продвинуться вперед. Это может создать ситуацию неопределенности, когда команда не знает, что делать дальше, или же наоборот, может привести к созданию сложных и неупорядоченных систем, которые только усложняют процесс работы.
Чтобы избежать этого, важно определить, когда и как часто проводить ретроспективные сессии. Они должны быть сфокусированы на анализе конкретных проблем и возможностей для улучшения, а не на обсуждении одних и тех же вопросов снова и снова.
Также важно понимать, что каждая команда и проект уникальны, и то, что работает для одной команды, может не работать для другой».
YandexGPT 3 Pro: «Почему Agile может быть неправильным выбором?
Agile – это методология управления проектами, которая предполагает итеративный подход к разработке программного обеспечения. Она включает в себя регулярные встречи команды, постоянное взаимодействие с заказчиком и готовность к изменениям.
Однако применение Agile не всегда является правильным решением. В некоторых случаях использование этой методологии может привести к негативным последствиям.
Вот несколько причин, почему Agile может быть неправильным выбором:
Не подходит для крупных проектов. Agile лучше всего подходит для небольших проектов, где можно быстро реагировать на изменения. В крупных проектах, где требуется более тщательное планирование и координация, Agile может привести к хаосу и потере контроля.
Не подходит для проектов с чёткими требованиями. Если проект имеет чёткие требования, которые не подлежат изменению, Agile может привести к ненужным затратам времени и ресурсов.
Не подходит для проектов с длительным циклом разработки. Agile предполагает короткие циклы разработки, которые позволяют быстро реагировать на изменения. В проектах с длительным циклом разработки это может привести к тому, что проект будет постоянно меняться, и его завершение станет невозможным.
Важно понимать, что Agile – это не универсальная методология, которая подходит для всех проектов. Выбор методологии должен основываться на особенностях проекта, его целях и задачах.
Как избежать негативных последствий применения Agile?
Чтобы избежать негативных последствий применения Agile, необходимо тщательно проанализировать проект и определить, подходит ли эта методология для его реализации. Если вы решите использовать Agile, необходимо соблюдать следующие правила:
Проводить регулярные ретроспективы. Ретроспективы позволяют команде анализировать свою работу и выявлять слабые места. Это помогает избежать повторения ошибок и повысить эффективность работы.
Устанавливать чёткие цели и сроки. Это поможет команде сосредоточиться на выполнении задач и избежать потери времени.
Поддерживать коммуникацию с заказчиком. Это позволит своевременно получать обратную связь и вносить необходимые изменения в проект.
Проведение ретроспектив должно уводить от ситуации неопределённости к ситуации сложных упорядоченных или простых упорядоченных систем. Это позволит команде анализировать свою работу, выявлять слабые места и принимать меры по их устранению.
В заключение можно сказать, что Agile – это эффективная методология, которая может принести много пользы при правильном применении. Однако её использование требует тщательного планирования и анализа».
Ответ AI Search: «Привет, друзья! Сегодня я хотел бы поделиться своими мыслями о том, почему Agile, несмотря на его популярность и эффективность, часто применяется неправильно. Особое внимание я обращу на то, почему проведение ретроспектив является важным инструментом для перехода от ситуации неопределенности к упорядоченным или сложным системам.
Agile – это философия и подход к разработке программного обеспечения, который изменяет традиционный подход к управлению проектами, делая его более гибким и адаптивным к изменениям. Однако, несмотря на явные преимущества, Agile может быть применен неправильно, и в результате, его потенциал не раскрывается полностью.
Одной из главных проблем неправильного применения Agile является недостаток регулярного проведения ретроспектив. Ретроспектива, как экспертная оценка прошедшей работы, помогает командам принять во внимание произошедшие изменения, недостатки и улучшения при планировании будущих итераций. Это позволяет отточить процесс работы и увеличить эффективность. Однако, некоторые команды часто игнорируют проведение ретроспектив или проводят их несистематически.
Не проводя регулярные ретроспективы, команды упускают возможность видеть свои проблемы, подтверждать или изменять свое видение и настраивать этапы разработки. В результате, команды могут застрять в ситуации неопределенности и не иметь возможности двигаться вперед.
Одним из главных принципов Agile является обеспечение быстрого отклика на изменения и непрерывное улучшение процесса работы. Если ретроспективы не проводятся регулярно, команды недостаточно осознают свои ошибки и упущения, что затрудняет прогресс в достижении упорядоченности и эффективности.
Кроме того, проведение регулярных ретроспектив помогает двигаться командам от ситуации неопределенности к сложным или простым упорядоченным системам. Начиная с простых упорядоченных систем, где правила и процессы легко определены и контролируются, команды могут постепенно переходить к более сложным системам, где правила более неоднозначны и требуют большей адаптации.
Итак, ретроспективы являются важной частью Agile-процесса и помогают командам двигаться от неопределенности к упорядоченности и сложным системам. Они позволяют командам осознать свои ошибки и изъяны, а также увидеть области для улучшения. Не пренебрегайте регулярными ретроспективами, чтобы ваша команда могла максимально раскрыть потенциал Agile и достичь высокой эффективности работы.
Желаю вам успешной работы в применении Agile и постоянного совершенствования своих процессов! Будьте гибкими, настойчивыми и внимательными».
Ну, и мой пост: «Почему Agile не вечен и не панацея?»
В последние годы все как один декларируют, что они Agile.
Давайте будем честны: большинство под этим скрывают банальный хаос. Ведь Agile – не про отсутствие планирования. Кроме того, он очень чувствителен к выполнению определенных правил и к стабильности команды, ее мотивации. Если у вас не соблюдаются эти условия, вы – не Agile.
Использование того же Scrum, Kanban или других подходов должно приводить к отсутствию необходимости реализации проектов по Agile.
Но почему?
Давайте вспомним, что Agile изначально был задуман для работы и реализации проектов в ситуации высокой неопределенности.
Даже есть специальный инструмент – модель Кеневин, – который помогает понять, в какой ситуации вы находитесь и какой подход нужно выбирать, на чем фокусироваться. Так, в упорядоченных системах (простых или сложных ситуациях) Agile, наоборот, противопоказан, т.к. увеличивает затраты на достижение результата. То есть Agile результативен в случаях, когда надо сделать «то – не знаю что». Но он не про эффективность.
А теперь давайте обратим внимание на ретроспективу. Все подходы внутри Agile предполагают регулярные ретроспективы, анализ своей работы, взаимодействия с клиентом / заказчиком / партнером. То есть сама логика этих инструментов в том, чтобы уйти от неопределенной ситуации и научиться прогнозировать их, становиться эффективнее.
Если вы постоянно (раз в полгода-год) меняете работу или постоянно запускаете новые продукты, а не тиражируете определенные решения (что для бизнеса странно), то да, вам нужно быть Agile.
Но если у вас есть сегмент, и вы наработали с опытом и экспертизой типовые подходы / продукты, которые нужно корректировать и адаптировать в небольшой части, то рано или поздно вы должны уйти от Agile и прийти к упорядоченной системе, где нужны каскадные или гибридные подходы. Эти ретроспективы вас и должны привести к пониманию того, чего хотят заказчики в 90% случаев и как работает организация.
В итоге, если вы Agile на постоянной основе и везде, а не на период перестройки / запуска / адаптации, то это может говорить о том, что:
– вы не соблюдаете инструменты Agile;
– вы не нашли свой продукт и свою нишу, не наработали нужную экспертизу;
– у вас каждый раз уникальный продукт / проект (что должно отражаться на высокой цене ваших услуг);
– организация «больна» изнутри, и вы таким образом маскируете высокую текучку, отсутствие работы над процессами и т. д.
А что вы думаете по этому поводу?»
Качество ответов нейросетей больше похоже на слабого студента, который просто подбирает похожие слова, но не понимает, о чем говорит. Мог бы я добиться аналогичного поста от нейросети? Чтобы она передала мои смыслы? Да, конечно, но свой пост я написал за 25 минут, а сколько времени у меня ушло бы на попытки добиться такого результата от ИИ? И похоже ли это на действительно думающий интеллект? Да и вообще на Интеллект?
Дело в том, что наше мышление сильно завязано на идеях и образах. То есть в основном в мышлении мы используем подход от общего к частному, мыслим образами, и потом от неких размытых, но понятных нам на бессознательном уровне абстракций приходим к мельчайшим деталям. Параллельно проводим кучу ассоциаций, целиком завязанных опять же на образах. Не зря в человеческой речи так много метафор, сравнений, намеков и переиначиваний слов.
Современные нейросети «думают» совершенно иначе. Им просто неведомы понятия «смысл», «суть», «идея», как и сам процесс размышления. Сгенерированные нейросетью тексты выглядят как логичные не потому, что нейросеть реально понимает, о чем пишет, а потому что она способна вычислить, какие слова чаще всего стоят рядом друг с другом в доступных для ее обучения текстах на заданную вами тему. Чистая математика, основанная на просчете вероятностей.
Однако справедливости ради надо отметить и существенный прогресс в этом направлении. Сейчас разработчики стараются научить ИИ размышлять: он задает сам себе вопросы и, давая ответы, делает выводы. Это имитация внутреннего диалога для повышения качества контента, что свойственно моделям от Open AI конца 2024 года и Yandex GPT 4 Pro RC.
Вот пример ответа модели Yandex GPT 4 Pro RC на запрос «Напиши пост о том, почему Agile бесконечно применять неправильно. Сделай акцент на том, что проведение ретроспектив должно уводить от ситуации неопределенности к ситуации сложных упорядоченных или простых упорядоченных систем».
Ответ Yandex GPT 4 Pro RC: «Почему Agile не всегда работает: как ретроспективы могут помочь перейти от неопределённости к порядку.
Agile – это гибкий подход к управлению проектами, который позволяет быстро адаптироваться к изменениям и улучшать процессы на основе обратной связи. Однако, несмотря на все преимущества, применение Agile без учёта контекста может привести к проблемам. В этом посте мы рассмотрим, почему Agile не стоит применять бесконечно и как ретроспективы помогают перейти от ситуации неопределённости к упорядоченным системам.
Проблемы бесконечного применения Agile
1. Отсутствие чёткой структуры. Agile основан на принципах гибкости и адаптивности, что может привести к отсутствию чёткой структуры и плана действий. Это может затруднить принятие решений и управление рисками.
2. Сложность оценки результатов. Без чёткого плана и критериев оценки результатов сложно определить, насколько успешно продвигается проект. Это может вызвать сомнения в эффективности подхода.
3. Риск потери контроля. Бесконечное применение Agile может привести к потере контроля над проектом. Без чётких границ и ограничений команда может потерять фокус и начать отклоняться от первоначальной цели.
4. Неэффективное использование ресурсов. Если команда постоянно адаптируется к новым условиям, это может привести к неэффективному использованию ресурсов. Вместо того чтобы сосредоточиться на ключевых задачах, команда будет тратить время на постоянные изменения.
5. Снижение мотивации команды. Постоянная адаптация и изменения могут вызвать стресс и усталость у команды. Это может снизить мотивацию и продуктивность.
Как ретроспективы помогают перейти к упорядоченным системам
Ретроспективы – это один из ключевых инструментов Agile, который помогает команде анализировать свою работу и выявлять области для улучшения. Они позволяют перейти от ситуации неопределённости к более упорядоченным системам, где процессы и решения становятся более предсказуемыми и управляемыми.
Вот несколько способов, как ретроспективы могут помочь:
• Определение проблем и их решений. Ретроспективы позволяют выявить проблемы, которые возникли в процессе работы, и найти способы их решения. Это помогает избежать повторения ошибок в будущем.
• Улучшение процессов. Ретроспективы помогают понять, какие процессы работают хорошо, а какие нуждаются в улучшении. Это позволяет оптимизировать рабочие процессы и повысить эффективность.
• Повышение мотивации. Когда команда видит результаты своих усилий и понимает, что они приносят пользу, это повышает мотивацию и удовлетворённость работой.
• Создание культуры непрерывного улучшения. Ретроспективы способствуют формированию культуры, в которой постоянное улучшение и адаптация являются нормой. Это помогает команде быть более гибкой и готовой к изменениям.
В целом, ретроспективы являются важным инструментом для перехода от ситуации неопределённости к более структурированным и упорядоченным процессам. Они помогают команде адаптироваться к изменениям, улучшать свои процессы и достигать поставленных целей».
Да, модель ушла в академичность и видно, что это выдержки из статей, а не размышление. Но это огромный прогресс, с моделью уже можно работать и использовать как инструмент.
Однако, имея в наличии только слабый ИИ и мечтая о более-менее сильном, уже сейчас различные исследователи в своей классификации выделяют суперсильный ИИ (ASI, Artificial Superintelligence).
Это такой ИИ, который:
– может решать как рутинные, так и творческие задачи;
– моментально ориентируется в неопределенности даже без подключения к сети Интернет;
– адаптирует решение задач к контексту обстоятельств и доступных возможностей / ресурсов;
– понимает эмоции людей (не только через текстовый запрос, но и на основе анализа мимики, тембра голоса и других параметров) и учитывает их в работе;
– способен самостоятельно взаимодействовать с реальным миром для решения задач.
Это такой ИИ, который мы видим пока что только в фантастических фильмах. Даже сам ИИ пишет об ASI как о «гипотетической концепции» и «предмете научной фантастики и активных исследований в области искусственного интеллекта» (YandexGPT 3 Pro). Это некоторая желаемая точка в далеком будущем, достигнуть которую пока не представляется возможным.
Chat GPT 4 характеризует ASI так: «гипотетическая система искусственного интеллекта с интеллектом, превосходящим человеческий. Это не просто усовершенствованный ИИ, а система, способная адаптироваться, учиться и развиваться самостоятельно, превышая человеческие способности в обучении, решении проблем, когнитивных функциях и самоусовершенствовании.
Суперсильный ИИ, или ASI, будет иметь возможность понимать и обрабатывать множество типов данных (текст, изображения, звук, видео), что позволит ему выполнять сложные задачи и принимать решения. Он будет использовать продвинутые технологии ИИ, такие как многомерные языковые модели (LLMs), многоразрядные нейронные сети и эволюционные алгоритмы.
В настоящее время ASI остается концептуальным и спекулятивным этапом развития ИИ, но он представляет собой значительный шаг вперед от текущего уровня ИИ».
И если слабых ИИ сейчас сотни, под каждую задачу, то сильных ИИ будут лишь десятки (скорее всего произойдет разделение по направлениям, мы это рассмотрим в следующем блоке), а суперсильный ИИ будет одним на государство или вообще всю планету.
Ограничения на пути к сильному ИИ
Если быть честным, я мало верю в быстрое появление сильного или суперсильного ИИ.
Во-первых, это очень затратная и сложная задача с точки зрения регуляторных ограничений. Эпоха бесконтрольного развития ИИ заканчивается. На него будет накладываться все больше ограничений. На тему регулирования ИИ мы поговорим в отдельной главе.
Ключевой тренд – риск-ориентированный подход. Так, в риск-ориентированном подходе сильный и суперсильный ИИ будут на верхнем уровне риска. А значит, и меры со стороны законотворчества будут заградительными.
Во-вторых, это сложная задача с технической точки зрения, причем сильный ИИ будет и очень уязвимым.
Сейчас, в середине 2020-х, для создания и обучения сильного ИИ нужны гигантские вычислительные мощности. Так, по мнению Леопольда Ашенбреннера, бывшего сотрудник OpenAI из команды Superalignment, потребуется создание дата-центра стоимостью в триллион долларов США. А его энергопотребление превысит всю текущую электрогенерацию США.
Также нужны и сложные ИИ-модели (на порядки сложнее нынешних) и их сочетание (не только LLM для анализа запросов). То есть придется экспоненциально увеличивать количество нейронов, выстраивать связи между нейронами, а также координировать работу различных сегментов.
При этом надо понимать, что если человеческие нейроны могут быть в нескольких состояниях, а активация может происходить «по-разному» (да простят меня биологи за такие упрощения), то машинный ИИ – упрощенная модель, которая так не умеет. Условно говоря, машинные 80—100 млрд нейронов не равны человеческим 80—100 млрд. Машине потребуется больше нейронов для решения аналогичных задач. Тот же GPT4 оценивают в 100 трлн параметров (условно нейронов), и он все равно уступает человеку.
Все это приводит к нескольким факторам.
Первый фактор – рост сложности всегда приводит к проблемам надежности, увеличивается количество точек отказа.
Сложные ИИ-модели трудно как создавать, так и поддерживать от деградации во времени, в процессе работы. ИИ-модели нужно постоянно «обслуживать». Если этого не делать, то сильный ИИ начнет деградировать, а нейронные связи будут разрушаться, это нормальный процесс. Любая сложная нейросеть, если постоянно не развивается, начинает разрушать ненужные связи. При этом поддержание взаимосвязей между нейроннами – энергозатратная задача. ИИ всегда будет оптимизироваться и искать наиболее эффективное решение задачи, а значит, начнет отключать ненужные потребители энергии.
То есть ИИ станет похожим на старика с деменцией, а срок «жизни» сильно сократится. Представьте, что может натворить сильный ИИ с его возможностями, но который при этом будет страдать потерей памяти и резкими откатами в состояние ребенка? Даже для текущих ИИ-решений это актуальная проблема.
Давайте приведем пару простых примеров из жизни.
Можно сравнить создание сильного ИИ с тренировкой мышц человека. Когда мы только начинаем заниматься в спортивном зале и увлекаться силовыми занятиями, бодибилдингом, то прогресс идет быстро, но чем дальше, тем ниже КПД и рост результатов. Нужно все больше ресурсов (времени, нагрузок и энергии из пищи) для прогресса. Да даже просто удержание формы становится все более сложной задачей. Плюс рост силы идет от толщины сечения мышцы, а вот масса растет от объема. В итоге мышца в определенный момент станет настолько тяжелой, что не сможет сама себя двигать, а может даже и сама себя повредить.
Еще один пример сложности создания, но уже из области инженерии – гонки Формулы 1. Так, отставание в 1 секунду можно устранить, если вложить 1 млн и 1 год. Но вот чтобы отыграть решающие 0,2 секунды, может потребоваться уже 10 млн и 2 года работы. А фундаментальные ограничения конструкции машины могут заставить вообще пересмотреть всю концепцию гоночной машины.
И даже если посмотреть на обычные машины, то все точно так же. Современные автомобили дороже и создавать, и содержать, а без специального оборудования невозможно поменять даже лампочку. Если взять современные гиперкары, то после каждого выезда требуются целые команды техников для обслуживания.
Если все же посмотреть с точки зрения разработки ИИ, то в этой области есть два ключевых параметра:
– количество слоев нейронов (глубина ИИ-модели);
– количество нейронов в каждом слое (ширина слоя).
Глубина определяет, насколько велика способность ИИ к абстрагированию. Недостаточная глубина модели влечет за собой проблему с неспособностью к глубокому системному анализу, поверхностности этого анализа и суждений.
Ширина слоев определяет число параметров / критериев, которыми может оперировать нейронная сеть на каждом слое. Чем их больше, тем более сложные модели используются и возможно более полное отражение реального мира.
При этом, если количество слоев линейно влияет на функцию, то ширина нет. В итоге мы и получаем ту аналогию с мышцей – размер топовых ИИ-моделей (LLM) переваливает за триллион параметров, но модели на 2 порядка меньше не имеют критического падения производительности и качества ответов. Важнее то, на каких данных обучена модель и имеет ли она специализацию.
Ниже приведена статистика для LLM моделей от разных производителей.

Статистика для LLM моделей от разных производителей
Сравните показатели LLaMa 2 70B, LLaMa 2 7B, LLaMa 2 13B. Показатели 70B, 7B и 13B условно демонстрируют сложность и обученность модели – чем выше значение, тем лучше. Но как мы видим, качество ответов от этого радикально не меняется, в то время как цена и трудозатраты на разработку растут существенно.
И мы можем наблюдать, как лидеры наращивают вычислительные мощности, отстраивая новые дата-центры и в спешке решая вопросы энергоснабжения и охлаждения этих монстров. При этом повышение качества модели на условные 2% требует увеличения вычислительных мощностей на порядок.