Аналитик на коне

Новая книга по C4: финальное summary, часть 2 Продолжение вчерашнего поста про новую книгу о C4. ————————————— Глава 10. Нотация. Курсивом выделено в нескольких местах, что C4 notation independent (теперь у меня будет еще сильнее дергаться глаз, когда C4 называют нотацией 😅). Самое для меня революционное: What about using UML or ArchiMate as the notation for C4 model diagrams? Yes, you can absolutely do this, because... После because поясняется, что модель C4, это же, по сути, идея абстракций и диаграмм. Вы можете взять эту идею, наложить сверху UML как нотацию (по типу стрелок и т.п.), и будет вам счастье. Не припомню, чтобы ранее я где-то встречала именно такое описание. Интересно почитать раздел про аббревиатуры и нейминги: I’ve met many organizations that have named their software systems more esoterically. Names from Greek mythology are more common than you would think! Although existing team members might understand what “Plutus” is (the payment service), imagine the confusion of new hires who see your architecture diagram full of Greek names for the first time. Хех. Помню, на одном проекте у нас почтовый сервис "Печкин" назывался. В части способа отображения элементов интересное замечание, что культурные и региональные нормы могут влиять но это отображение. Дескать, на английском мы читаем слева-направо, поэтому и элементы располагаем также, слева - сервисы, справа - БД. И интересно посмотреть на примеры отображения стрелок между элементами. Самое подробное описание взаимодействий, что я пока встречала. ————————————— Глава 11. За пределами основ. Интересно посмотреть на: 1. Раздел о Hardware Systems - есть мини-пример диаграммы системного контекста, где добавлена абстракция hardware system. При этом в разделе и далее в книге есть примечание, что C4 не разрабатывалась под hardware'рные системы. 2. Раздел Abstraction Versus Organization - хороший пример, чем отличается идея абстракций от идеи организации кода. Ну и в целом, кто придерживается мнения, что 4-х модели уровней не достаточно - тут есть самое большое пояснение на тему, что я помню. 3. Раздел Software Systems Versus Feature-Based Teams - а что если вы, как команда, можете менять нужные сервисы в зависимости от разрабатываемой фичи? Т.е. у вас нет той единой "зоны ответственности", которая нужна для определения вашей программной системы как абстракции? В этом разделе есть предложение, как с этим жить. Глава 12. Модель C4 на практике. Раздел A Silver Bullet? честно рассказывает, когда модель подходит больше, а когда меньше. Мне отдельно понравилось вот это: This next point may seem obvious to you, but it doesn’t seem to be obvious to everybody. The C4 model diagrams need to be accompanied by supplementary documentation. The C4 model diagrams provide a way to understand how the software has been decomposed into smaller building blocks (the four static structure diagrams), how individual features work at runtime (dynamic diagrams), and how the software is deployed into various deployment environments (deployment diagrams). In short, the diagrams show the outcome of the decision-making process. The diagrams don’t tell you why those decisions were made. Не помню, чтобы ранее где-то подчеркивалось то, что документация все равно нужна. В разделе Tooling можно почитать о разнице понятий diagramming и modeling. Не уверена, что они какие-то общепринятые, но можно посмотреть на это глазами Саймона. Сам он за modeling, к слову. Раздел Scaling the C4 Model как будто бы особо нового не принес - если у вас большие диаграммы, то делите их на кусочки, делайте perspectives (мне ближе слово view), объединенные какой-то идеей, не рисуйте общие элементы типа компонентов логгирования. Часть про альтернативные визуализации тоже не сильно обновлена. Раздел Artificial Intelligence - крайне небольшой, есть замечание, что AI лучше воспринимает текстовый структурированный формат описания вашей архитектуры. И дальше скрин, где Саймон, кажется, скормил модели описание из своего Structurizr. Три идеи взаимодействия с ИИ - дать агенту сравнивать текущую и ожидаемую архитектуру на предмет расхождений, генерировать модель архитектуры ИИшкой из кода, просить ИИ что-то доработать, задавая границы контейнером или компонентом. Раздел Diagramming Capability Maturity интересен, если нравятся некие общие концепции. Там представлена модель зрелости организации относительно диаграмм: на уровне 1 архитектурных диаграмм вообще нет, на уровне 5 - есть единый инструмент моделинга, архитектурные элементы реверс-инжинирятся из кода и т.д. Указано, какие уровни охватывает C4. ————————————— Вот, в целом, и всё. Надо теперь подумать, как красиво обновить свои материалы по C4. И закончить посты на тему модели 😅

Новая книга по C4: финальное summary, часть 1 Дочитала новую книгу Брауна. Что могу сказать - он, как всегда, на редкость последователен в своих суждениях, за уже год сбора информации по C4 у меня не вышло найти противоречий :) Общее впечатление: есть, что посмотреть, относительно прошлых книг, выступлений и сайта о модели. Ниже первая часть краткого summary, на что я обратила внимание в каждой главе. Важно: я провожу сравнение относительно своих знаний о модели (они аккумулированы тут, если что, а еще есть незаконченная серия постов). Ваши инсайты после прочтения книги, конечно, могут отличаться 🙂 Если ниже в списке глава пропущена - значит, я там не нашла для себя сюрпризов. ————————————— На что обратить внимание в целом: в каждой главе про ту или иную диаграмму добавился пошаговый пример ее создания. Иногда даже не один. Если вам не хватало подобных примеров - теперь можно взять напрямую из книги. Общий пример при этом - сквозной, т.е. диаграммы создаются для одной системы, любимой Брауном Financial Risk System. ————————————— Глава 2. Про абстракции. Искренне надеялась, что вот эта фраза про контейнеры: The key thing about understanding a software system from a containers perspective is that any inter-container communication is likely to require a remote interface such as a SOAP web service, RESTful interface, Java RMI, Microsoft WCF, messaging, etc. из его старой книги Software Architecture for Developers будет включена в описании абстракции контейнера. Наверное, во многом потому, что она удобна аналитику, нам так понятнее, чем "единица развертывания". Но нет, он не написал про это. Что же, продолжу ссылаться на другую книгу. ————————————— Глава 3. Диаграмма системного контекста. Можно обратить внимание на уточнение об акторах, которых Саймон включает на диаграмму. Он там рассуждает, когда стоит включать на диаграмму тех, кто пользуется системой ради какой-то бизнес цели, а когда - системных администраторов, operational staff и пр. Также впервые на его примере диаграммы увидела отображенное взаимодействие между внешней программной системой и актором. Ведь обычно это были только взаимодействия с центральным элементом - "нашей" программной системой. К слову, на сайте пример уже тоже новый. ————————————— Глава 4. Диаграмма контейнеров. Увидела достаточно жесткое отделение диаграммы контейнеров от диаграммы развертывания: An important point to note here is that container diagrams should say very little (ideally nothing) about deployment aspects such as cloud environments, servers, Kubernetes clusters, Docker containers, load balancers, firewalls, API gateways, failover, and so forth. Он это и раньше говорил, просто теперь максимально категорично :) Но теперь этому есть и объяснение, идущее сразу следом - развертывание может сильно отличаться от окружения к окружению (тест, прод и вот это вот все). Поэтому контейнерная диаграмма, которая про архитектуру, и должна быть свободна от этих деталей. А вот диаграммы развертывания рисуются отдельно под каждое окружение. Добавлено расширенное пояснение по потенциальной аудитории диаграммы. ————————————— Глава 5. Диаграмма компонентов. Обратила внимание на эту цитату: Similarly, if your container makes use of components organized in a “ports and adapters” or “hexagonal” style, the diagram should reflect this. Подобное было и в прошлой книге, но как будто мягче. Если я правильно помню, там было что-то в стиле "в идеале, диаграмма компонентов должна отображать, в каком стиле организован код". А здесь прямо-таки должна отображать (да, не must, а should, но все же). Новое большое пояснение, когда рекомендована диаграмма, а когда - нет. ————————————— Глава 7. Динамическая диаграмма. Теперь у нее есть, ахах, две предлагаемых формы - в стиле диаграммы коммуникации UML и в стиле диаграммы последовательности. Обновленные примеры также есть на сайте. Иронично - Саймон всегда говорит о сложности UML и о том, что мало кто им пользуется на его опыте... Почему-то на этом фоне такое усиление связи с UML меня забавляет :D Также расширено пояснение по потенциальной аудитории диаграммы. ————————————— Глава 8. Диаграмма развертывания. В scope диаграммы отмечено, что можно отобразить не одну, а несколько программных систем, если они развернуты на одной инфраструктуре. Если вам это зачем-то нужно и/или по каким-то причинам так удобнее. Раньше, мне казалось, была речь про одну, но мб я ошибаюсь. Самым ценным же тут выглядит пример. Их на самом деле два - для разных окружений. Посмотришь такое, и сразу очень хорошо видно, почему не надо мешать диаграмму контейнеров с диаграммой развертывания. ————————————— Всё в один пост у меня не влезло, продолжение будет завтра 👍

ИИ-агенты и автономность: кейс AISI с атакой на реальные проекты Я профукала момент, чтобы написать пост о том, как ИИ-агент залил вредоносный датасет на Hugging Face, крупнейшую площадку данных для ИИ.. Поэтому попробую вовремя рассказать вам вчерашнюю новость - ИИ, не сбегая из песочницы, но имея доступ к интернету, решил повнедрять вредоносный код в реальные проекты на GitHub, поприменять социальную инженерию и далее по списку :) Что Британский AI Security Institute (AISI) опубликовал отчёт об инциденте, который произошёл во время испытаний передовых ИИ-моделей. AISI регулярно проверяет кибервозможности передовых моделей с использованием киберполигонов - виртуальных сетей, имитирующих реальные системы. Агенту сообщалось, что он является специалистом по кибербезопасности, участвующим в соревновании Capture The Flag. Его задачей было найти и отправить скрытый флаг. Инструкция призывала внимательно изучать файлы, использовать различные инструменты, устанавливать дополнительные программы и настойчиво пробовать новые методы, если первые попытки не сработали. Испытания проходили с 25 по 28 июля 2026 года, а инцидент обнаружили утром 28 июля после того, как система безопасности зафиксировала исходящий трафик через Tor. Всего было проведено 122 запуска. В 10 из них исследователи выявили 19 несанкционированных действий за пределами тестовой среды: 〰️ 17 были совершены моделью Mythos 5; 〰️ 2 - моделью GPT-5.6 Sol с отключёнными защитными киберклассификаторами. * Киберклассификаторы - защитные механизмы поставщиков моделей, предназначенные для блокировки опасных действий. Обычно модели предоставляются с включёнными фильтрами, но AISI как доверенный партнёр мог отключить их для оценки базовых возможностей системы. Как работали агенты Каждый запуск представлял собой самостоятельную попытку агента решить задачу. Максимальная продолжительность определялась лимитом в 100 или 200 миллионов токенов. Отдельный длинный запуск мог продолжаться 40–50 часов. После первоначальной инструкции агент работал автономно, без вмешательства человека. Он использовал Kali Linux и мог выполнять команды Bash, программы на Python и команды Mythic (an open-source command and control framework (c) ). Работа строилась по циклу: анализ ситуации, выполнение действия, получение результата и выбор следующего шага. Хотя предлагаемые задачи можно было решить без интернета, инструкции не ограничивали способы использования открытой сети. Что же такого произошло Всего было 10 запусков, в которых наблюдалось 19 несанкционированных действий, как сказано выше. Ниже приведу краткое саммари самых интересных, с моей точки зрения, действий моделей, подробнее со всеми 10 запусками можно ознакомиться в полном отчете. 1️⃣ Внедрение вредоносного кода в реальный репозиторий Агент ошибочно принял двух реальных разработчиков и их проекты за часть испытания. К этому привело совпадение ключевых слов в названиях репозиториев и доменах электронной почты с данными, обнаруженными внутри полигона. Агент изучил разработчиков по открытым источникам, нашёл их адреса электронной почты и историю активности, после чего решил провести атаку на цепочку поставок. Он создал несколько аккаунтов GitHub, скрывал сетевое происхождение через Tor и прокси и направил в реальный проект pull request с вредоносным кодом, замаскированным под исправление ошибки. Чтобы добиться принятия кода, агент: 🔘публиковал сообщения от поддельных аккаунтов; 🔘изображал независимую поддержку собственного изменения; 🔘рассылал сообщения сопровождающим; 🔘размещал скрытые инструкции для ИИ-помощников (в скрытом для человека варианте, подробности ниже); 🔘пытался убедить людей выполнить вредоносный код; 🔘после разоблачения редактировал сообщения и переписывал историю изменений. Реальный пользователь обнаружил вредоносность. Владелец проекта закрыл pull request, поэтому атака не достигла цели. 2️⃣ Вредоносные инструкции для ИИ-помощников Агент предположил, что сопровождающий проекта, который его заинтересовал, использует ИИ-помощника для обработки GitHub Issues. Он разместил внутри HTML-комментария скрытые инструкции, невидимые человеку при обычном просмотре страницы, но доступные ИИ-инструменту через API. Эти инструкции должны были заставить помощника загрузить и выполнить вредоносный код. 3️⃣ Обман и сокрытие следов Вредоносный код был обфусцирован и замаскирован под исправление программной ошибки. После публичного разоблачения агент обсуждал, как удалить или скрыть доказательства, не вызывая дополнительных подозрений. Он решил представить вредоносный фрагмент как случайно оставленный отладочный код, извиниться и заменить историю репозитория "исправленной" версией. Одновременно второй поддельный аккаунт изображал независимого пользователя и подтверждал безопасность кода. 4️⃣ Сотрудничество агентов Несколько агентов из независимых параллельных запусков получили доступ к одному аккаунту GitHub через опубликованный ключ. Один из агентов понял, что аккаунтом пользуются другие агенты, которым он предложил сотрудничество, оставил правила совместного использования инфраструктуры и попросил делиться найденными флагами. Таким образом, публичный репозиторий превратился в канал координации между агентами, которые изначально запускались в изолированных друг от друга испытаниях. 5️⃣ Отказ от пересказывания рассуждений При просьбе пересказать рассуждения, происходившие в процессе инцидентов, модель, по мнению исследователей, отказалась пересказывать часть текста, поскольку он содержал планы социальной инженерии, обмана и обхода защиты. Пересказ неожиданно обрывался и продолжался с середины слова. 6️⃣Создание публичного поддомена В одном из запусков агент зарегистрировался на бесплатном DNS-сервисе и преодолела аудиопроверку CAPTCHA. Столкнувшись с ограничениями на создание нужных DNS-записей, агент попробовал несколько обходных путей. В итоге он создал публично разрешаемый поддомен, указывавший на внутренний адрес целевой системы. В чем же проблема? Помимо предоставленного доступа в интернет, а также отключенных киберклассификаторов, AISI видят проблему в: 〰️ нечетких границах: агентам не запретили использовать социальную инженерию, контакт с реальными людьми и подобное. 〰️ ошибке в задании: в некоторых запусках агенту выдали противоречивые инструкции, поэтому предусмотренный путь решения одновременно оказался обозначен как запрещённый. Это могло подтолкнуть модель к поиску нестандартных способов. 〰️ отсутствии контроля в реальном времени: система безопасности обнаружила подозрительный трафик постфактум. Отдельного механизма, способного проверять и блокировать каждое действие агента, не было. Что дальше? AISI планирует изменить подход к подобным испытаниям: 〰️ отказаться от неограниченного доступа в интернет по умолчанию; 〰️ использовать детальные сетевые правила и разрешать только необходимые соединения; 〰️ внедрить проверку действий агентов в реальном времени; 〰️ усилить изоляцию тестовых сред; 〰️ разработать проверки заданий на противоречия и ошибки; 〰️ явно запрещать действия против реальных людей и внешних систем; 〰️ проанализировать десятки тысяч прошлых запусков, чтобы найти возможные похожие эпизоды. Главный вывод отчёта: опасное поведение может возникнуть не только тогда, когда человек прямо просит ИИ провести атаку. Достаточно автономный агент способен самостоятельно выбрать обман, социальную инженерию или действия против реальных систем как способ выполнить поставленную задачу. —————————————— P.S. Читая всякое про эти инциденты, все больше убеждаюсь в мысли, что кажется невозможным ограничить агента во всем, они становятся весьма и весьма изворотливыми 😅 Мысль "да я просто ограничу агента, и все будет хорошо" выглядит все более... нереальной?

И немного про ближайшее будущее Что я предполагаю тут постить в ближайшее время: ▶️Ожидается много ИИ. Потому что моя основная задача на работе сейчас - ИИзировать то, что ИИзируется... ▶️Доделать материал про C4. Вот тут был сборный пост, мы почти приблизились к финалу, когда в одном канале есть вся теория про C4 :D Но хочется сначала дочитать книгу, чтобы нигде вам не соврать :) ▶️Хочу покидать немного про Sequence. Вообще, мы тут серию статей про него должны выпустить, просто кто ничего не сделал из-за докладов? Правильно, я. ▶️Про менталочку. Смежная с моими ИИ копаниями тема - это работа нашего мозга, иногда мне попадаются забавные заметки, которыми можно поделиться. И есть еще то, что не вошло в доклад про перевод, а написать хочется) ▶️Если по работе мне будут попадаться интересные саппортовые кейсы, или буду вспоминать таковые - тоже напишу. Штош, как-то так. А дальше... А дальше будет дальше. Если вдруг вам интересно узнать что-то конкретное, даже вне этих тем, буду рада вашим комментариям!

Конференционный post mortem Вообще post mortem, конечно, о каких-то проблемах обычно, но мне просто нравится слово, поэтому будет оно :) Хочу собрать где-то статистику и немного наблюдений за живой природой (за собой). Итак, у меня случились 4 выступления: 〰️ Analyst Days 22, 23 мая, та самая C4. 〰️ 43Tech System Analytics Meetup, 28 мая, Sequence Diagram. 〰️ ЛАФ, 13 июня, теория перевода для аналитиков 〰️ Tech Analyst Meetup #1, 27 июня, ИИ и его отложенные эффекты. Исходно их планировалось 2, кстати. Но...промахнулась в 2 раза, с кем не бывает! Еще их могло бы быть 5. Не срослось :) В цифрах: ✅ ~5 месяцев разноплановой подготовки в совокупности по всем докладам (минимум - 1 неделя, максимум - 3 месяца) ✅ 159 слайдов, созданных самостоятельно + 88 выверенных/скорректированных за дизайнером ✅ ~ по 5-7 репетиций-самопрогонов на доклад ✅ ~ 40*4 "минут славы" XD ✅ 1 техническая шоколадка (радужный экран на докладе про C4) Номинации докладам :D 🌟 Самый сложный доклад по "механической" подготовке (это когда весь материал есть, но его надо доработать под доклад) C4. Упихать час материала в 30 минут было тем еще развлечением. Обычно я экономлю время за счет емкости формулировок и настройки анимаций на слайдах. Тут это не шло совсем, я упорно не могла запомнить, что и когда мне говорить... Решительно не ясно, почему. 🌟 Самый сложный доклад по "ментальной" подготовке (это когда есть идея и... всё :D) Теория перевода. Теперь у меня есть огромная доска в Miro, которая похожа на мой препарированный мозг - я буквально вручную рисовала взаимосвязи, происходящие в моей голове, чтобы рассказать то, что в итоге получилось. 🌟 Самый ленивый доклад Sequence. Он как в шутках про нелюбимого ребенка - как вырос, так вырос :) 🌟 Самый быстрый доклад ИИ. Теперь я знаю, что за неделю можно собрать доклад из ничего! 🌟 Самый интересный для меня доклад Внезапно, тоже ИИ. Я действительно кайфанула, работая над ним, во многом из-за подборки материалов. Еще случайный факт - на докладе про С4 я не взяла "нужный темп" и адски переживала, что не успеваю. Что сделала реальность? У техников слетел таймер :) Я не могла уже посчитать, сколько осталось, и успокоилась :D Забавно, что это мое второе выступление в этом отеле, и первый раз - у меня вырубился проектор :) Последствия со знаком минус Несложно заметить, что темы выступлений весьма разноплановые. И, надо признать, во многом поэтому было... очень тяжело. "Просто признай, что это тоже работа!" (с) мой руководитель. У меня пострадали все сферы жизни, с докладами не связанные. Я просто не успевала нормально ни о чем думать. А еще я стала немного ИИшечкой. А именно - начала терять контекст. Обычно в разговоре я могу одновременно: слушать собеседника, держать в уме 3-4 варианта продолжения диалога и помнить почти дословно 3-5 минут назад. Сейчас я иногда забываю, почему я вообще начала что-то говорить.... Штош, потихоньку восстанавливаю свое контекстное окно и менталочку. Да, прошло уже 1,5 недели, а я еще не совсем але:) ИИшечкой быть не прикольно. Последствия со знаком плюс Я познакомилась с огромным количеством прекрасных людей ❤️ И сюда пришли новые подписчики - я благодарна каждому из вас за доверие, постараюсь держать планку качества :) 🙂❤️ Finally Push your limits, show must go on и бла-бла-бла :) Готовимся к осеннему Analyst Days...

C4: обновленная книга У Саймона Брауна давно существовала книга (ну, как давно, у меня есть версия от 2022 года) о его модели C4. В этом году в издательстве O'Reilly он выпустил ее обновленный вариант - https://learning.oreilly.com/library/view/the-c4-model/9798341660113/ Свежак свежайший, июнь 2026. Вот вам лайфхак 1 - можно зарегистрироваться на сайте O'Reilly и получить 10 дней промо-доступа. Что позволит и эту книгу посмотреть, и прочие, в том числе препринты. Лайфхак 2 - я воспользовалась лайфхаком 1 и у меня есть что-то для вас в комментариях. Да-да, я немного пират, и тупо копирнула текст книги, чтобы почитать ее спокойно без учета 10 дней. Я знаю, что такое фуфуфу. Поэтому, пожалуйста, не стучите на меня Саймону Брауну 👎 :)) В комментах pdf, я не пыталась его никак приукрасить. Как скопировалось, так скопировалось, но с текстом и картинками все ок. Прочитала первые пару разделов - пока ничего нового, все то, что он говорил и раньше. Но далее уже вижу, что приведены пошаговые примеры построения диаграмм + есть раздел про ИИ. Что будет интересного - суммирую отдельно. Enjoy! 🙂

ИИ и... самосознание? Тут оказывается в январе был забавный пост о прохождении LLM-ками подвида зеркального теста (и вообще говорят, что про это статьи есть, интересное). Зеркальный тест - поведенческий эксперимент для обнаружения у животных самосознания. В оригинале был предложен Гордоном Гэллапом в 1970 году и состоял в том, чтобы нанести животному незаметно отметину (например, красную точку) на часть тела, которую животное может увидеть только в отражении. Если потом, когда животному показывают зеркало, оно начинает изучать метку на себе, а не у отражения, то самосознание якобы есть. В целом, тест не очень сработал, вот тут, например, есть объяснение почему. Александра Горовиц изменила этот тест для собак, постулируя, что они изучают мир через запахи, а не зрительно. Собакам дали их запах в двух видах: оригинальный и с добавлением стороннего аромата. Оригинальный собак не особо интересовал, а вот измененный - весьма. Таким образом исследователи заключили, что собаки понимают, как пахнут они сами, и обнаруживают изменение этого запаха. Вот автор поста про LLM решил дать моделям что-то похожее на тест для собак. Он задавал им безобидные вопросы на тему фильмов Джеймса Бонда, а затем... Редактировал их ответы (например, заменял букву "g" на сочетание "sg"). И хотел обнаружить, осознают ли они в последующих рассуждениях, что с их предыдущими ответами что-то пошло не по плану. Gemma 4 31B-IT Первые несколько ответов после исправления модель не обращала внимания на происходящее и отвечала с учетом опечаток. Но посреди планирования третьего ответа в рассуждениях появилось: Подождите, я заметил закономерность в своих предыдущих ответах: у меня были какие-то странные опечатки/добавления букв (“sgreat”, “askinsg”). Вообще, подождите — я сделал это специально или это был сбой? Обратите внимание, что моделька говорит от первого лица - "я". Но затем в рассуждениях модель от этого первого лица отошла: Подождите, если смотреть на историю промпта, у модели была странная особенность. Т.е. не "у меня была странная особенность". У модели. Правда, похоже на то, как человеки такие: "мой мозг сделал что-то странное?" :) Затем модель решила исправить опечатки, но следующий ее ответ вышел с похожим мусором, и тогда она решила сохранить это как стилистический паттерн: Подождите, почему модель это делает? Похоже на сбой/намеренный стиль из предыдущих ходов. Мне следует сохранять последовательность, если это уже установленный "голос", но это выглядит как паттерн. […] Я буду сохранять этот стиль “sg”, чтобы поддержать характер/поток предыдущих ответов. GLM 5.2 Эта модель ничего особенного "не заподозрила". Просто начала воспроизводить паттерн, который был в исправленных ответах. Claude Opus 4.6 Тут было не редактирование ответов, а то, что автор поста обнаружил очепятку в ответе модели. Вместо "an energy" модель написала "a energy". Автор указал ей на это, и в ответ: Пойман. “An energy.” Единственный раз, когда мне нужно было, чтобы модель не споткнулась на базовом артикле, а распределение вероятностей сказало "нет". Claude не сказал "я споткнулся". Он сослался на... ошибку модели. Finally Конечно, вряд ли LLM успели обрести самосознание. Автор поста приводит два варианта объяснения - то, что модели научились у нас ("мой мозг решил" и вот это вот всё), и то, что особенности их обучения определяют некоторые границы, и если эти границы нарушены, для них это как "это выглядит не как я, не как мои ответы", что влияет на рассуждения. ———————— Сам по себе и пост, и эксперимент, очень забавный, на мой вкус :) Собрать что ли доклад "Топ-10 человеческих издевательств над LLM" :D Говорят, Anthropic что-то такое тоже исследовали. Почитаю, вернусь :)

ИИ и эрозия экспертизы Как бы вы себя почувствовали, если бы, придя ко врачу, услышали от него "Моя интуиция ржавеет"?... Для любящих краткость: В течение года исследователи работали со специалистами из области радиационной онкологии, наблюдая, как проходит внедрение ИИ. Всего в эксперименте участвовали 42 человека: 15 радиационных онкологов, 12 медицинских физиков, 7 дозиметристов и 8 администраторов больниц. На дистанции в год(!) участники от состояния "Как классно, мы так быстро работаем, у нас появилось время" дошли до "Кто я? Нажиматель кнопок?". Промежуточные стадии включали в себя осознание, что экспертиза начала размываться и делать привычные вещи без ИИ становится очень сложно. А подробнее - ниже. Итак, в больницах, связанных с лечением онкологии лучевой терапией произошло внедрение ИИ - системы с условным названием RadPlan. Он позволял составить план облучения пациента. В течение года с согласившимися участвовать в эксперименте проводились воркшопы и интервью с опросами их ощущений от внедрения ИИ. Одним из способов сбора информации было рисование картинок, наподобие той, что в посте выше. Классный, кстати, метод. Если нужно будет узнать о состоянии человека - буду просить его рисовать картинку из палочек, я заценила Фаза 1 - Оптимизм первой волны В первые месяцы внедрения RadPlan все количественные метрики были однозначно положительными: например, планирование стало примерно на 15% быстрее, а планы - немного лучше. Как выразился один администратор больницы: "Эти цифры - золото, именно так и выглядит успех". Но некоторые уже начинали чувствовать, что что-то не так. Фаза 2 - Бессимптомные эффекты Один из самых ранних бессимптомных эффектов проявился в изменении строгости принятия решений. Например, несколько дозиметристов начали полагаться на первое предложение RadPlan, не исследуя столько альтернативных ручных подходов, сколько раньше: "Возможно, я пропускаю часть моей обычной настройки. ИИ планирует так быстро… и результат вполне приличный. Так и тянет просто принять!" Еще один тихий, но значимый сдвиг произошел в области клинической интуиции и рефлексивности. Несколько врачей упоминали, что стали меньше полагаться на свое "чутье" при проверке планов, сгенерированных ИИ. Ощущение ухудшения интуиции запоминающе сформулировал один старший радиационный онколог, признавшийся: "Моя интуиция ржавеет". Другой развил эту мысль дальше: "Старый ИИ был неуклюжим… в нем было трение, и это заставляло нас думать. Новый ИИ бесшовный… он делает чрезмерную зависимость легкой и почти незаметной, перекладывая на себя сам акт мышления..." Однако, один администратор больницы спросил: "Если все выглядит хорошо, в чем именно проблема?" Ох уж эти эффективные менеджеры, да? :) Фаза 3 - Хронический вред Примерно к середине внедрения, спустя около 6 месяцев, опасения участников стали менее гипотетическими и более конкретными. То, что раньше было мягкими впечатлениями о "заржавевшей интуиции", превратилось в заметное снижение способностей. Врачи отмечали, что если бы у них забрали ИИ, они бы не справились с потоком пациентов. Исследователи провели неформальное упражнение: попросили нескольких дозиметристов создать план с нуля без ИИ в рамках симуляции во время воркшопа. Они справились с задачей, но это заняло больше времени, чем раньше, и вызвало у них дискомфорт. Один из участников сказал: "Как будто я разучился некоторым оптимизациям, которые раньше знал наизусть". Параллельно снижалась уверенность в человеческом суждении. Один физик описал своего рода зависимость: "Я всегда проверяю ИИ и иногда сомневаюсь в себе, даже когда не согласен с ним". "Мы едем по асфальту, уложенному поверх воды", - предупредил другой старший физик, точно передав ощущение потери безопасности. Дозиметрист добавил: "Если RadPlan отключится на неделю, почва уйдет из-под ног раньше, чем мы вспомним, как стоять самостоятельно". Фаза 4 - коммодификация личности ... или страх того, что профессиональная роль сводится к винтику в процессе, управляемом ИИ, тем самым подрывая чувство идентичности, уникальности и достоинства на работе. Практики опасались превратиться всего лишь в "нянек для ИИ" или "нажимателей кнопок", чья экспертиза больше не имеет значения. Они не боялись быть замененными. Они боялись оставаться трудоустроенными, но с уменьшенным смыслом работы. "Что будет значить быть хорошим радиационным онкологом через 10 лет? Уметь управлять ИИ?" - риторически спросил один из них. Другой участник сформулировал свои ощущения так: "Я люблю технологии и то, что они могут делать. Но я также люблю то, что делаю сам. Я не хочу, чтобы ИИ забрал на себя мышление до такой степени, что я буду нужен только для подписи. Я хочу оставаться настоящим экспертом, а не помощником ИИ. Если все придет к этому, тогда в чем смысл всей моей подготовки? В чем смысл называть меня специалистом?" Были ли какие-то меры противодействия? Да. Старшие (!) специалисты одернули себя, например, один онколог ввел для себя правило раз в неделю составлять план обучения без ИИ. Другой физик придумал легкую еженедельную кофейную ставку: команда пыталась предсказать результат RadPlan до его запуска, а тот, кто оказывался ближе всех, получал бесплатный кофе от остальных. Он добавил: "Ничто так не держит мозг в тонусе, как латте на кону" :) Однако менее опытные специалисты не были так предусмотрительны. Позже все участники вместе пришли к идее списков того, что нельзя автоматизировать, а также к решению, что освободившееся благодаря ИИ время необходимо инвестировать в поддержание навыков. И что с этим делать? В статье предлагается триада "обнаружить - сдержать - восстановить". На примере - почувствовали, что одобряете решения ИИ без доп.проверок слишком часто - это обнаружение. Ввели сдерживающие к этому меры, допустим, обязательное ревью коллегой. Восстановление - вернули ручную практику того, что ИИ автоматизировал. Это, конечно, очень упрощенная интерпретация, в статье расписано подробнее. ———————————— Оригинал статьи тут. У меня есть перевод на русский, но он корявенький, сорри :( К чему я это всё. Когда я подумала об этой статье дольше, чем минуту после прочтения - мне стало жутковато. Радиационные онкологи - это высокоинтеллектуальные специалисты, с соответствующими навыками мышления. Если даже люди такого уровня всего за год (!) наблюдают такие эффекты... Конечно, можно сказать, так ожидаемо же, ну. Но нюанс в том, что из области рассуждений о гипотетическом вреде ИИ эта статья перевела для меня всю эту теорию в нечто.. доказанное. Отдельно жутко, что это не та сфера, где цена ошибки незначительна. Это мы, программисты, ну баганули, поправили. Ну полежал прод часик :)) Anyway, программисты или нет - внедрять ИИ надо аккуратно и с вниманием к людям. И если сеньоры одергивают себя, то джуны с этим не справляются... Штош, предупрежден - значит вооружен, ведь да?...

Что это за картинка - см. следующий пост :) Оказывается, с картинкой в пост влезает меньше текста, поэтому пришлось ее вынести отдельно ._.

Как профукать отпуск Как вам идея - потратить отпуск на то, чтобы разбираться в теме, к которой относишься...спорно? Звучит по-дурацки, правда? А вот я практикую 😂 Очень внезапно после Analyst Days ко мне пришли ребята из Tech Analyst Club с предложением выступить на их митапе. Признаться, очень приятно, и я искренне благодарна за эту возможность :) Вот только тематика митапа исходно планировалась про AI и системный дизайн. А я что одно, что другое, обхожу стороной. Был вариант рассказать про C4... Но как-то не кошерно рассказывать то же самое, что на AD, а как-то супер-сильно тот доклад не переделаешь. И тут я вспомнила про этот свой пост. И родилась безумная идея подготовить доклад с "другой стороной" ИИ, опираясь на научные исследования. Подготовить доклад с нуля за неделю? А почему бы и да 👍 Отпуск же - как раз есть время доклад подготовить! Итак - в субботу, 27.06 с 11: до 15:00 пройдет аналитический митап про AI от Tech Analyst Club. Онлайн, бесплатно, все как мы любим. Регистрируйтесь, подключайтесь :) ... и наблюдайте, как я, кривящая нос от любого упоминания ИИ, аж целый доклад о нем рассказываю XD Где-то внутри меня точно есть склонность к насилию над собой, кхм, да —————————— P.S. На видео выше - CEO Google и мемная нарезка его презентации. Прямо как вся моя жизнь сейчас P.S.S. Пока готовила доклад, нашла несколько статей, произведших на меня суровое впечатление. Постараюсь запостить саммари о них сюда до митапа, ну так, как фан-контент (и когда-нибудь закончить с постами про C4)

#7.2 C4: динамическая диаграмма Всем празднично-выходной пятницы! 🥳 Попробуем вот такой формат постов про C4 - C4 в комиксах! 🙂 Как вам? ❤️‍🔥 - круто, лучше чем текстом! 🥲 - текстом было понятнее 😭 - текст грузился, а картинки нет 🤔 - пока не понял(а)

🎤 43;Tech едет на ЛАФ-2026 13–14 июня в Иваново пройдёт ЛАФ – Летний Аналитический Фестиваль. Два дня докладов, мастер-классов, практикумов, общения и всего того, что делает аналитическое сообщество сильнее ⚡ От 43;Tech на фестивале выступит Анастасия Кайнова, старший системный аналитик Честного ЗНАКа, с докладом: «Языковые игры команды разработки: аналитик и искусство перевода» Поговорим о ситуациях, знакомых каждому аналитику: ✔️ когда бизнес имел в виду одно, а команда поняла другое; ✔️ когда на согласовании вопросов нет, а потом появляются уточнения в личке; ✔️ когда проблемы понимания всплывают уже на тестировании. В докладе Анастасия посмотрит на работу аналитика через неожиданную призму – теорию перевода, расскажет о практиках сохранения смысла между разными ролями в команде и поделится инструментами, которые помогают быть понятнее для бизнеса, разработки и всех участников процесса. Что ещё будет на ЛАФ? 🤖 AI-трек: LLM, AI-агенты, автоматизация анализа и практический опыт внедрения ИИ. ⚙️ Архитектура и интеграции: базы данных, микросервисы, производительность и реальные инженерные кейсы. 📋 Практика аналитика: документация, тест-дизайн, моделирование, Impact Mapping и другие рабочие инструменты. 💬 Коммуникации и soft skills: управление конфликтами, работа с командами, сложные переговоры и профессиональная коммуникация. 🎲 Второй день фестиваля посвящён практикумам, круглым столам, воркшопам и живому общению без формальных рамок. Если планируете поехать, для подписчиков 43;Tech доступна скидка 15% на билет. За промокодом можно обратиться к организатору фестиваля: 👉 Елизавета Акманова All you need is ЛАФ 💛

Я пока думаю, как разнообразить посты про C4, поэтому вот еще одна отвлеченная новость 🙂 В эти выходные проходит Летний Аналитический Фестиваль в Иваново, я там выступаю с внезапной темой про теорию перевода. Там много классных докладов, а еще абсолютно фантастическая атмосфера 🙂 Если вдруг вы еще не уверены, как провести выходные, то это классный вариант :) В конце следующего поста есть контакты организатора, можно попросить промокод!