Russian Association of Software Architects

🎤 Выложил запись доклада "Сжатие приводит к истине? Как LLM выбирает, во что верить". Это рассказ про исследование, про которое уже писал, плюс все что накопал с тех пор И сразу мега крутая новость: вчера мою статью "Truth as a Compression Artifact in Language Model Training", на которой построен доклад, приняли в основной трек NeurIPS 2026! Моя первая серьезная научная статья - и сразу на одну из главных конференций по ИИ в мире!!!1 🎉🎉🎉 Насколько я смог найти, это вообще первый случай, когда в основной трек взяли работу независимого автора-одиночки из России Началось все с простого вопроса. Почему модели из разных стран одинаково не верят в астрологию, гомеопатию и в то, что на одной китайской площади ничего не произошло? В обучающих данных миллионы сайтов с гороскопами и весь китайский интернет. Чтобы разобраться, пришлось вступить на скользкую дорожку борца с мифами и лженаукой Главная мысль - обучение вымывает из данных непредсказуемость. Из научных данных можно последовательно делать предсказуемые выводы, поэтому наука хорошо сжимается. Астрология нет: по одной натальной карте разные астрологи выдают абсолютно разные прогнозы. Чтобы это проверить, обучил с нуля 300+ LLM-моделей разной архитектуры от 3.5M до 3B параметров. Никаких инициализаций открытыми весами, чистый рандом. Начал на своем маке, а закончил на кластере из восьми H100. Было дорого В докладе: - 1:14 - миф про 10% мозга (который так любят бизнес-коучи) - 3:20 - Кеплер и эпициклы - 4:47 - плоскоземельщик на ток-шоу - 6:34 - из лжи следует что угодно, или как Рассел доказал, что он Папа Римский - 11:12 - случайные ошибки модель вымывает, даже когда правильных ответов всего 10% - 12:33 - одно согласованное ложное правило - и предпочтение правды пропадает - 13:29 - с несколькими ложными правилами модель вдруг неожиданно начала предпочитать сложную ложь обычной математике. Потом рецензенты нашли ошибку в подсчетах - 15:05 - разбавил математику текстами из FineWeb так, что ее осталось 8% - 16:05 - случайно меняем географию в Википедии, так что в истории Франции появляется Уссурийск - 17:19 - что нашли рецензенты NeurIPS - 18:26 - главный вывод В посте про расцензуренный DeepSeek я писал, что алайнмент полностью снялся правкой 0,06% весов, а во что модель верит по-настоящему, решает претрейн. Когда китайская модель в чате уходит от ответа - это работа алайнмента, картина мира у нее может быть совсем другой. А вот для претрейна согласованная дезинформация неотличима от истины. Спасает то, что настоящие фейки редко бывают согласованными до конца Статья на arXiv | Код и данные на GitHub | Презентация из доклада P.S. Первое, что мне написали рецензенты: "парень, у тебя какая-то ерунда в данных". Они были правы - и теперь это статья на NeurIPS 😄 P.P.S. Число подписчиков моего канала уже почти 5000 человек (или агентов, тут уж не знаю). Мне очень приятно, спасибо 🙏

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

The distribution of human effort also changes. Using eye tracking and interaction monitoring, [13] found that developers working with LLM-generated code devote substantial cognitive effort to understanding, inspecting, validating, and correcting generated solutions. Automatic generation therefore does not eliminate human work; it shifts part of that work from implementation toward supervision and evaluation.

Думать все равно приходится:

Generative artificial intelligence is transforming Software Engineering by automating the generation of code and other software artifacts. Yet it does not eliminate the essential complexity described by [3]; rather, it redistributes engineering effort from implementation toward domain understanding, specification, validation, and software evolution. This shift underlies the Specification Paradox: the more capable AI systems become at generating software, the greater the dependence on high-quality human-produced specifications. As specifications increasingly guide automated generation, their quality directly affects the reliability and alignment of generated artifacts. Rather than diminishing RE, AI may therefore strengthen its strategic role.

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

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

Identifying and Quantifying Architectural Debt https://dl.acm.org/doi/epdf/10.1145/2884781.2884822 AI раскрывает новые возможности. Если раньше читаешь и понимаешь - дааа, но лень, то теперь действительно многое можно достаточно быстро опробовать. Я раньше использовал адаптированный под себя code-maat, дописанный-переписанный, но Clojure я до этого не знал, так что приходилось дописывать по-немногу и делать интеграцию через файлы, а теперь открылись просто новые грани. В этой статье арх долг на границе дизайна и архитектуры: ArchDebt=⟨FileSetSequence, DebtModel⟩, где FileSetSequence — это последовательность связанных групп файлов в разных релизах DebtModel описывает, как менялись затраты на исправление ошибок в этих группах В статье поиск происходит в несколько стадий: 1. Crawling - отбор областей поиска, - файлы, которые хотя бы раз менялись ради исправления ошибки с первого релиза по текущий, после чего отбирают группы файлов и их зависимостей, – у которых ведущий файл находится в этом пространстве ошибок. 2. Indexing - из истории исправлений строят матрицу History Coupling Probability (HCP). Ячейки HCP[A,B] показывают условную вероятность изменения B, если изменился A. В каждой группе есть опорный файл, остальные файлы могут добавляться или исчезать от релиза к релизу 3. Modeling. В исследовании кандидат должен встречаться как минимум в половине релизов и иметь бОльшие затраты к последнему наблюдаемому релизу, чем к первому. Затраты приближают числом измененных строк кода в исправлениях ошибок (bug-fixing churn) по файлам группы. Тут чуть ли не самое интересное – раньше можно было бы сказать, – да ладно, в строках кода считать моветон, а если это агент, то это токены == деньги. 4. Ranking - найденные долги упорядочивают по связанным с ними накопленным затратам Пример в статье с Cassandra показал, что «ADFileSet calculated using anchor ColumnParent in Cassandra. Each member file structurally depends on the anchor file, and when the anchor file changes, the member files change as well with probabilities from 41% to 100%.». Расценивается как сигнал для проверки. Долг оценивается через bug-fixing churn, то есть объем изменений при исправлении ошибок. Неявно можно предположить, что высокий bug-fixing churn может потреблять больше токенов (когда мог бы потреблять меньше). То есть понятно, что потребление зависит от самой задачи, (вход+выход+иные задачи), но при прочих равных, меньшая связанность может потреблять меньше. Усилить можно, если выйти за пределы репозитория, тогда и без токенов координационная нагрузка подсветит дополнительные расходы, для этого нужно построить связку через багтрекер (она должна быть), но часто связей между зависимыми задачами разных команд нет, это усложняет задачу. Написал скрипт по статье, отладил, проверял три гипотезы: H1. При одинаковом объеме правок багфикс в бакете архитектурного долга требует больше токенов контекста, чем изолированный фикс H2. По числу изменённых строк нельзя понять, сколько токенов понадобится модели (в большом бакете долга токенов больше, чем следует из объема правок) H3. Контекст из связанных файлов долга заметно больше контекста только из измененных файлов (соответственно чем больше меняется, тем выше скорость роста числа токенов, так как увеличивает число читаемых файлов с некоторой вероятностью). Очевидная гипотеза, но интересно посмотреть. Проверка через tiktoken, репозиторий: https://github.com/temporalio/sdk-java Результат на скрине. Общий вывод Нарушение модульности дороже изолированной правки и в текущем фиксе, и в каждом следующем. Последующие фиксы платят тот же контекст снова. В первой четверти истории типичному такому исправлению хватает примерно 9 300 токенов контекста. Со второй четверти типичный контекст поднимается до 30 000 и дальше держится около 34–35 тысяч. Лишние токены по четвертям: 3,0 млн, 5,2 млн, 4,5 млн, 4,7 млн. Исходник стыдно выкладывать и он съедает 70gb памяти на таком небольшом проекте, так что в другой раз.

Новый кейс в «Архитектурных этюдах» Как решаете задачи валидации, когда смешиваются в одной задаче и размытые формулировки и алгоритмически проверяемые (обязательно) факты? https://t.me/archicases/10055/10056

Запись вебинара «Определение объектов и границ объектов NFR» Youtube: https://www.youtube.com/watch?v=7sLMNBNCMi8 VK: https://vkvideo.ru/video-184472537_456239215

Старт через 5 минут.

NFR – это требование к чему именно? Наверняка у всех вас в том или ином виде описаны атрибуты качества, такие как безопасность, производительность, масштабируемость. На первый взгляд все в порядке: они указаны и даже заданы количественно или качественно. Однако при детальном рассмотрении часто выясняется, что совершенно непонятно, к какому объекту относится требование. Требование производительности – к чему конкретно? К продукту? К отдельному модулю? К сервису? К данным? К конкретному пользовательскому сценарию? К каким проблемам это может привести? ▪️Компания берет на себя обязательства, которые невозможно проверить и защитить перед клиентом или регулятором: не зафиксировано, к какому именно объекту относятся эти обязательства ▪️Архитектурный артефакт невозможно однозначно спроектировать и протестировать, если NFR сформулированы без привязки к нему ▪️Требования нельзя проверить на полноту и согласованность между командами, поскольку отсутствует воспроизводимая практика определения объектов и границ NFR Что разберем на вебинаре? Одна из обязательных частей сценария атрибуты качества – объект, к которому относится требование. На вебинаре обсудим два вопроса: ▪️Какими бывают объекты NFR? ▪️Как определить границы этих объектов? Вебинар проведет Сергей Баранов. 🗓 8 сентября, 17:00 МСК 🔗 Подключение: https://scrumtrek.ktalk.ru/sccu2uneqagt Регистрация не требуется – добавляйте событие в календарь, чтобы не забыть 🙂

Поговорим о знании Существует модель описания знания, включающая в себя три основных компонента: - декларативное знание (что?) - процедурное знание (как?) - условное знание (когда и почему?) Декларативное знание - это факты и утверждения, процедурное - правила действий. Декларативное - предпосылка для процедурного. При этом в зависимости от обретаемого знания конкретные типы могут быть разного объема, где-то больше декларативного (теоретическая наука), где-то процедурного (езда на велосипеде). При этом знание неотделимо от контекста и деятельности, в которой оно применяется. Подумайте о кешировании и про: - разработку самого компонента кэша (разработчик) - выбор класса и конкретной реализации (архитектор) - настройка и мониторинг (SRE) Таким образом, часть знания не существует в голове отдельно от практики, в которой она проявляется. Помимо этого, в знании есть условные понятия, качественно меняющие понимание всей области. Вспомним снова про кеширование, с точки зрения архитектуры примером будет переход от «настроить идеально инструмент кеширования» к «пойти на компромисс между целостностью и скоростью». Исходя из вышесказанного, декларативное знание предшествует процедурному, однако затем они развиваются в процессе обучения, но не обязательно синхронно. Согласно модели Дрейфуса (на является универсальной, но применяется в образовании), на ранней стадии доминирует декларативное знание в виде явных, контекстно-независимых фактов, на поздних - все более интуитивным. Это, в частности объясняет, почему нельзя научиться проектированию архитектуры за короткое время, - принятие решений почти всегда контекстно-зависимое. Универсальная модель обучения, таким образом: - декларативные знания - обучение, чтение, наблюдение - процедурные - повторяемая практика - условный - накопление опыта в разных ситуациях Важно отметить, что механизмы получения знания - не взаимозаменяемы. Если вы идете на конференцию, например, ArchDays, - вы получаете декларативное знание, отберите для себя выступления, которые могут быть вам полезны, заранее подумайте, как сможете применить и после выступления спрашивайте спикеров именно о том, как применить, какие действия выполнять, обменяйтесь контактами, спрашивайте по мере продвижения, либо исследуйте более глубоко тему самостоятельно. Так вы получите максимальный эффект. В организационном контексте подумайте следующем: - достаточно ли у сотрудников декларативного знания, чтобы качественно выполнять процедуры (процессы) - достаточно ли у сотрудников декларативного знания, чтобы реализовать в коде требуемые процедуры (фичи) - существуют ли процедуры, развивающие то, что декларируется (мы инновационны.. но есть ли процедуры это развивающие, обучающие?) - мы - гибкие, но заложены ли циклы обратной связи с последующими изменениями на основе этих циклов? - …. Для архитектора: - декларативное - курсы, книги, доклады, документация - процедурное - реальное проектирование систем - условное - разбор компромиссов, работа с разными контекстами

Domain-Driven Design matters more when AI writes your code via Learn Building Modern Go applications

В Архитектурных Этюдах новый кейс: https://t.me/archicases/9786/9787

Вот так Notebooklm сжал теорию первого дня корп курса по Event Storming, очень хорошо сжал, я бы сказал. Никакой лишней информации нет, так что можно выложить :)

Тест

SPDD (Structured Promt Driven Development) https://martinfowler.com/articles/structured-prompt-driven/ Пришла пора подвести итоги использования SPDD, как самостоятельного, так и в рамках консалтинга. Я не увидел в SPDD чего-то, что бы фундаментально меняло подход к разработке, в сущности – это инструмент для того, чтобы обуздать и дисциплинировать работу ненадежным, стохастическим генератором кода (хотя Мартин Фаулер иного мнения - «material change in how developers build software», можно так сказать, но даже сама статья не сказать, что этот тезис раскрывает). Инженерная работа, которую ранее разработчик мог выполнить во время написания кода, – проработка структуры сущностей, описание модели, фиксация атрибутов качества, определение инвариантов, теперь, как и завещали нам все инженерные школы (начиная с XP) выносится вперед, как проработка конкретной задачи перед началом работы над ней, иначе нейронка просто не реализует то, что нужно. Все дело в том, что разработчики (developers) к моменту начала разработки обладали большим количеством неявного знания отовсюду, - из доков, ранее написанного кода, жизненного опыта, кучи встреч и случайных обсуждений. Логично, что у нейронки этого нет и это надо: a) вынести из головы в промт б) структурировать должным образом Такой Structured Promt обычно содержит не мало подробностей (REASONS), чуть приземленнее: ▪️в какой слой вносить изменения ▪️конкретные изменения в API и какие API трогать нельзя ▪️какие инваринаты домена нельзя нарушать ▪️какие тесты обязательны ▪️какие граничные кейсы обязательно обработать ▪️какие архитектурные соглашения соблюдать ▪️что считается успешным результатом В целом, выгоды очевидны, их ощущаешь даже в одиночку: ▪️[Возможная] повторяемость, причем спустя долгое время (все же зависит и от модели и от температуры и от самого промта, тут не очевидно) ▪️Более точный результат, тут без комментариев – больше деталей – точнее результат ▪️Если есть ревью, людьми, то ревью проходит лучше – есть описание задачи и результат, своего рода сверка ▪️Быстрые драфты, особенно там где надо кучу кода изменить, – можно делать небольшие изменения в промте, которые распространяются сразу на много частей системы, объективно быстрее при накопленной строгой структуре ▪️Senior пишет правила, по которым составляется промт, всякие чеклисты, шаблоны и в целом ребята с меньшим опытом могут ими пользоваться Однако, у всего есть побочка: ▪️Не просто так разработчики решали задачи в процессе разработки, – постепенное продвижение в решении с каждым шагом открывало новые вопросы, которые в момент обсуждения голосом могли даже не возникнуть в голове, пресловутое «о, а тут что должно быть?». Соответственно, глобально меняется модель мышления – сначала решение, затем модель пишет код. Это теперь _требует_ использования структурированных методов решения инженерных задач, коих много, но которые часто игнорировались. Похоже, этим практикам и методам теперь дается вторая жизнь. ▪️Чтобы грамотно поставить задачу нейронке, нужно с ней общаться на понятном ей языке, а она понимает любой язык (и сила и слабость). То есть если ей не сказать – здесь лучше использовать Chain of Responsibility и Builder, то она с высокой вероятностью не будет их использовать. А это методы локализации изменений, а локализация изменений – прямой метод оптимизации потребления токенов и повышения вероятности успеха при внесении изменений. То есть нужен точный доменный и инженерный язык. ▪️Все это нужно описать словами. А это бывает нудно. Если человек привык писать код по 10 часов в день в течение 10 лет, то перейти к написанию спецификаций может оказаться сложным (но придется) В итоге SPDD снижает стоимость печатания кода 🙂 Но повышает важность постановки задачи, декомпозиции, верификации и архитектурной дисциплины. То есть это не про преимущество над классической разработкой в сложной инженерной работе, а скорее существенное преимущество в управляемом использовании LLM.

Я обещал написать, начал писать и уже получилось пять страниц, так что это будет уже статья, но кое что я все же напишу здесь. В прошлом году я выступил с темой «Экономические последствия архитектурных решений». В ней было о том, как архитектура влияет на экономику. После этого было несколько проектов, в которых мы реализовали оценку архитектурных решений в деньгах. Это оказалось проще, чем кажется на первый взгляд, но требует некоторых усилий в изменении процессов, модели принятия архитектурных решений и подходам к работе с инициативами. Однако встал очередной вопрос, который именно сейчас стал болезненным. Заключается он в том, что аналогия технического долга, и архитектурного в частности, завязана на деньги. Прошлым летом у меня было выступление на тему архитектурного долга, но суть в том, что мы всегда считали объем архитектурного долга в терминах технических метрик. И это большая проблема – архитектурные изменения дорогие, дорогие в терминах денег, а обоснование в большинстве источников через связанность, зависимости, избыточную сложность. Основная цель коммерческой организации – зарабатывать деньги, иначе с чего платить зарплату. И расходы тут играют не последнюю роль, как, конечно и доходы, но когда мы строим IT-стратегию или пытаемся обосновать выделение сервиса или что-то подобное, стоит это обычно сколько-то денег, например, месяц работы команды, а что это даст? В деньгах что даст. Вот мы решили апнуть версию базы, неделя команды, а выгода в деньгах какая? Может мы платим процентов по такому долгу 1000 рублей в год, тогда апгрейд версии базы не окупится условно никогда. Конечно, есть еще риски и иные факторы, но все же. Прямой способ, который описывается во всех источниках - учет времени на выплату процентов по долгу с переводом в деньги по ставке членов команды. Я подсознательно, и на своем опыте, и по опыту работы с различными компаниями, понимаю, что это красивая сказка, так не работает, – тут и отторжение и избыточная нагрузка… Но мы же инженеры и я решил проверить как обстоит дело и запустил опрос. Вот вижу, что кто-то все же честные трудозатраты считает, вопрос к корректности остается открытым, но все же это 20% от всех ответивших. По индустрии будет и того меньше, я думаю, что подводит нас к тому, что этот подход массово не рабочий. У меня есть несколько других подходов, которые я уже обкатал, которые по косвенным признакам позволяют все же перевести архитектурный долг в деньги, это и мой опыт и опыт коллег, с кем мы в тесном контакте. В скором времени выпущу статью и небольшое решение, которое позволит посчитать его. Важно - мой акцент на долге _над кодом_, потому что долг уровня кода сейчас отдается за минуты, почти бесплатно. Так как я с самыми мощными моделями и в доверенных источниках не нашел прагматичных методов, думаю, что это будет хорошее решение, а цель достаточно простая – объективно оценить, что отдавать, а что не надо, потому что в условиях бюджетных огранчений выбирать нужно очень аккуратно, ориентируясь на реальные финансовые показатели, а не только на технические параметры и метрики системы.