Сергей Баранов: архитектура и ИТ-стратегия

Я про бэкенд @ Яндекс

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

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

1. На открытии Антон Полднев задавал общую рамку и сказал такую фразу (не дословно): «Удивительно было, когда я попросил модель сложить два числа, а она не пошла складывать, а написала питон-скрипт и сложила». Вот уж правда никогда не знаешь, откуда придет инсайт/обобщение опыта. Я сам не раз сталкивался с такой ситуацией и слышал от других: «агент написал скрипт, которые съел весь процессор/память/…» и эти наблюдения после фразы выше сформировались в общее наблюдение, – а ведь действительно, мы детально формулируем задачи для агента на реализацию функционала, но полностью отдаем ему реализацию вспомогательных скриптов. И это может стать следующей точкой оптимизации, ведь мы платим не только за токены, но и за инфраструктуру на которой агент исполняется и вольное поведение агента вполне может привести к высоким необснованным затратам, особенно если нет внешних ограничений.
2. Просто интересное. Не так давно в яндекс.картах появились светофоры. Изначально эту тему исследовали те, кто разрабатывает беспилотные автомобили под свои нужды, они научились получать данные, но задержка в получении данных оказалась слишком высокой, что для карт не так критично и наработки использовали в картах. Такая вот горизонтальная связь.
3. Архитектурные подходы в целом не новые, новое в них добавляют новая инфраструктура и новые нагрузки. То есть спроектировать решение с ИИ-компонентом не сказать, что невероятно сложно, однако когда появляются высокие нагрузки, то стандартные решения просто перстают работать, как и в любой комплексной адаптивной системе. Причем проявляется это во всех плоскостях - и выдерживать нагрузку с обеспечением безопасного доступа, и уметь непрерывно и быстро поднимать/опускать сотни и тысячи инстансов инфраструктурных компонентов (эластичность на максималках) и следить за экономикой решения. Но повторюсь, если проект по требованиям вполне себе типовой, то здесь скучная, дисциплинированная инженерия (и архитектура) дают вполне приличный, предсказуемый результат.

Всем хорошего дня и надежных решений :)

Достаточно ли восстановить данные для харнесса по коду?

Ситуация: запускается агентская разработка, нужен харнесс и данные для него собираются из текущих артефактов - репозиториев, API, документации.

Дальше возможен градиент от «все идеально» до «соткано из антипаттернов и противоречий».

Сборка данных может отличаться
▪️Cобрать данные и перекреститься
▪️Собрать данные, провести анализ, найти противоречия хотя бы на уровне определений, понятий и связей и перекреститься
▪️Предыдущее + архитектурный аудит на уровне границ ответственности, глобальных инвариантов, соответствия анализа относительно ключевых сценариев и много всего остального, что входит в архитектурный адудит; зафиксировать риски, агентскую разработку стартовать в изолированной области, где риски минимальны, остальные готовить

Возвращаясь к началу, ответы разделились
▪️Одни притормозили когда поняли, что в текущей архитектуре и состоянии документов агенты могут разнести системы в пух и прах и взялись за архитектуру (или как минимум воспроизводить неоптимальные паттерны)
▪️Другие пытаются, но не могут получить обещанную пользу от агентов

Архитектура является обеспечивающим условием того, чтобы ИИ-инициативы можно было реализовать (проще/легче лучше/хуже - другой вопрос).

OpenAI так же указывает на важность архитектуры в своей статье https://openai.com/index/harness-engineering/ (см скрин). Да, без деталей, но я уверен, что они подразумевают все это, просто фокусируются на своей теме, однако даже они не забывают упомянуть, что архитектура важна.

Ну и напоследок, набившая уже оскомину фраза, источник которой не найти, но возможно это было State of AI-assisted Software Development - «ИИ работает как мультипликатор и для сильных и для слабых сторон организации.

Я местами гиперболизирую, это чтобы проблема не потерялась в скучных рассуждениях - ведь везде, где есть компоненты, связи и какая-то логика над способом организации этого всего, есть архитектура, какая - это уже второй вопрос :)

Архитектурная ката @ Podlodka Crew

Вчера с @MaksCher побывали в жюри архитектурной каты от подлодки.

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

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

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

Для себя я тоже отметил несколько наблюдений:

1. Специфики при использовании моделей в решениях было не так много на уровне набора компонентов, – ML, MCP, LLM-Proxy, сами LLM, то есть структурно решения были плюс/минус схожими. И это важно, потому что с позиции архитектуры AI для нас – это не фундаментальные изменения, а в большей степени более массовое использование компонентов с недетерменированным в общем случае поведением.

2. При этом NFR/QA, поведенческие характеристики, могли отличаться существенно. Например - агент вполне может серьезно увеличить нагрузку на API, потому что появился класс задач, для которых в рамках рассуждений ему нужно не 2 раза обратиться к какому-то API, а она решила, что 20 раз надо перепроверить и сделала это. Важным становится вопрос темпоральности (работа со временем), – агент дошел до некоторого этапа, долго ждал ответа от пользователя и что-то изменилось в тех данных, на которые он опирался при принятия ранних решений. Что делать? Все перепроверять каждый раз? Придерживаться ранее принятых решений, даже если теперь есть противоречие? Это бизнес-решение, находящее свое прямое отражение в архитектуре. Вопросы безопасности стали острыми как никогда в том числе в части определения ролей агентов и разделения полномочий.

3. Единогласное мнение – если можно без агента, – лучше без агента. Это относится к тому, когда можно принять решение не доводя до агента, быстро и безопасно. Например - сразу одобрить возврат для надежного клиента или если уже известно, что есть брак.

4. Для систем с агентами важен второй контур – смысловой анализ диалогов. Тенденция к полному исключению людей из цепочки диалога с внешним миром легко может привести к тому, что в какой-то момент собственник посмотрит на цифры, увидит убытки, спишет на экономическую ситуацию, а в действительности окажется, что это потому, что агенты якобы успешно закрывая диалог допускали ошибки, не решали задачи людей, а постоянно их водили по кругу, выполняли действия, о которых не просили. И люди постепенно уходили. Возможно и в вашем окружении уже есть люди, которые именно по этой причине перестали пользоваться услугами каких-то компаний, в моем – уже есть. И здесь интересный момент, что в такой модели выиграет тот, кто сможет построить максимально надежную систему, которая будет действительно полезной (а это во многом архитектурная задача), но есть мнение, что пока этот момент в области взаимодействия с людьми еще не наступил – слишком много разных людей, ситуаций, контекстов, недостаточно накопленных данных и внутренние корпоративные системы и сами данные часто еще не готовы. Я не так часто пользуюсь первой линией, но даже у меня в копилке уже две таких ситуации и оба раза я решал проблемы находя знакомых внутри компаний, других способов просто физически нет было. И, повторюсь, выглядит так, что у этих компаний нет способа узнать об этом, и так, кейс за кейсом, неспеша, компании могут незаметно терять долю рынка. Выходит, что нужны три контура Observability - в обычном представлении, финансовый (учет расходов на диалоги в части использования моделей и других платных API) и смысловой (что происходит у наших клиентов и что мы с этим делаем).

Благодарю @thebits и @Gskoba за приглашение поучаствовать в жюри, Podlodka как всегда на высоте!

Посетил Demo Day сертфиикации для архитекторов от Сбер.

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

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

1. Компании все еше не адаптировались к новой скорости появления технологрий. На практике это означает, что пока EA согласовала новую технологию со всеми у себя в компании (иногда это год+), технология может уже устареть.
2. Компании все еще ищут экономические модели использования ИИ. Полная автоматизация бэкофиса со сроками окупаемости в десятки лет не считается за экономический успех.
3. Корпоративная архитектура все чаще становится частью инвестиционного цикла на практике и на практике все чаще начинает работать с финансовой стороной вопроса (считаю позитивным сдвигом для отрасли)

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

В общем, в домашних условиях за $8000 собирается рабочая конфигурация, равная GPT Luna и окупается она за 29 месяцев. Вот так.

«Лидерство во льдах», Альфред Лансинг

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

Книга об экспедиции Шеклтона в 1914 году (а сама книга – 1959-го года). Он хотел первым пересечь Антарктиду пешком, но не достигнув материка судно вмерзло в лед и несколько месяцев дрейфовало, пока его не раздавило, а команде пришлось почти полгода жить в палатках на дрейфующих льдинах. Лед начал ломаться и они пересели в спасательные шлюпки. После долгих дней в шлюпках они причалили к острову, но остров был необитаем и они понимали, что искать их никто там не будет. Шеклтон с несколькими людьми отправился на шлюпке через океан, проплыли они где-то 1300 километров за 16 дней на 7-метровой шлюпке в ледяной шторм. Они нашли остров, но оказались с его необитаемой стороны и еще сутки с половиной шли через горы. В итоге нашли людей на острове и спасли всех, кто оставался на острове.

Это если по сюжету. Что же в ней такого?

Я в ней разглядел стоические мотивы. Люди не могут повлиять на шторм, ветер, лед, течения, но полностью отвечают за то, как они к этому относятся. В книге стойкость проявляется через ежедневную рутину, то, как люди соблюдают распорядок, делят еду, шутят, ждут и не позволяют себе опустить руки.
Помимо этого, можно было ожидать, что цивилизованность в подобной ситуации исчезнет и начнется борьба каждого за себя (или чего хуже, как в книге Повелитель Мух), но вместо этого общество держалось на мелочах – на справедливом распределении, на ритуалах и на доверии к лидеру (хотя люди остаются людьми - они раздражаются, ссорятся, завидуют и отчаиваются и тем важнее, что при всем при этом они не распались).

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

1. Главная цель лидера может измениться. Экспедиция провалилась и Шеклтон озвучил новую цель - вернуться домой. Не все ситуации в жизни несут экзистенциальную угрозу, поэтому мы можем долго идти к цели, которая уже не имеет смысла, руководствуясь самообманом и не признавая реальность.
2. Моральный дух – такой же ресурс и им можно управлять. Например, Шеклтон держал распорядок дня, поощрял игры и песни. Был такой момент, что кому-то стало плохо и он велел всем разогреть горячего молока, чтобы не выделять одного человека.
3. Самых нервных и склонных к пессимизму Шеклтон поселил в своей палатке :) Он так гасил недовольство до того, как оно распространится. В книге прямо указывается, что Шеклтон понимал, что раскол группы означает смерть для всех.
4. Авторитет Шеклтона держался на личном примере, – он ел то же, что и все, отдал свои рукавицы, взялся отправиться на шлюпке вникуда. Дела важнее слов, в общем.
5. Интересный был момент – как проходила жеребьевка при распределении спальников. Шеклтон с офицерами так устроили жеребьевку так, что им самим достались худшие спальники =) Смысл в том, что в условиях нехватки ощущение несправедливости разрушает группу быстрее, чем сама нехватка.
6. Шеклтон мог долго ждать, но когда наступал подходящий момент - действовал решительно и быстро.
7. Шеклтон понимал свои ограничения, поэтому в шлюпку подобрал сильных людей и доверился им. Это важно, – знать свои слабые стороны, собрать сильную команду и доверять этой команде.

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

#Книги

Адаптирую материал школы архитекторов, мое любимое определение архитектуры (неформальное, но все же) в своей изначальной форме более не актуально.

«Набор ключевых решений в системе, которые избавляют разработчиков от ненужной креативности»

Да, было так, что архитектура защищала от «креативности» живых разработчиков, которые могли написать лишний/сложноподдерживаемый код.

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

Архитектурные ограничения (guardrails) теперь становятся жестким фильтром для AI-агентов. Архитектура должна явно задавать рамки, за которые AI не имеет права выходить при генерации кода. И это не так просто, как кажется на первый взгляд. Мы ведь формулируем guardrails на естественном языке, а какая проблема с естественным языком? Именно так, которую и подсвечивает DDD и которая в целом нередко проявляется в жизни – ограниченность любого языка. У нас огромный контекст в голове, мы пишем и даже не представляем, что то, что мы написали кто-то может трактовать иначе, а этот кто-то чистает и через призму наполнения своего мозга воспринимает именно иначе =)

Может кто помнит, была такая игра - игра в требования, где аналитику выдавалась картинка, он описывал что видит как ТЗ словами, относил разработчику и тот должен был по описанию нарисовать картинку (см изображение к посту). Ни у кого ни разу не получилось воссоздать, чего там только не рисовали. На картинке еще хороший результат.

Кроме того, модели не видят надсистему и социальную сложность. AI видит код и файлы, но откуда ему знать реальные политические ограничения стейкхолдеров, квалификацию команды и будущую бизнес/IT-стратегию.

Ну и конечно AI-агенты стали «цифровыми членами команд». Появилась новая социальная сложность гибридных команд (человек + AI).

Думаю, придется сделать несколько дополнительный веток практического обучения, в частности база по онтологиям, нейросимволичности и DDD конкретно в этом узком контексте, иначе… плывет оно и чтобы каждый раз собирать разъехавшееся решение в кучу, приходится прилагать экстра-усилия (тем, кто инженерию не практикует, разумеется) :)