2pegramming

Пятничное чтиво

Сегодня спецвыпуск — три ссылки связаны с llm и агентами.

Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.

—————————————

Test and verification technique effectiveness with Astra

В моей голове, главная проблема кода, сгенерированного с использованием llm — валидация и верификация. Эта же проблема существовала и до «llm эры», но из-за объемов генерируемого кода, усугубилась. Поэтому было интересно почитать об «эксперименте», где GPT-6 Astra заставили писать код с использованием различных подходов к верификации (тесты с tdd, lean, fuzzing и так далее).

Текст начинается с того, как эксперимент проводился. Дали требования для реализации IMAP (RFC + Zstd) и приписка о том, как тестировать полученный код. В итоге автор проверил 25 видов верификации + 1 дефолтный. В результате чего получилась «матрица» стоимость теста/процент безошибочных прогонов. Вторым заходом проверяли реализацию pandoc, которая сложнее IMAP, из-за чего качество тестов и их стоимость отличается. Из интересного — default режим (где не задается конкретный вид теста) дал лучше результат, чем остальные 25 вариантов. Ну и остаток текста, автор, задается вопросом, как относится к данным (слишком мало прогонов) и почему лабы не публикуют подобные исследования.

Русский перевод

#validation_verification #llm

—————————————

Inside GitHub’s new Git storage architecture

Одна из теорий, почему гитхаб так «(не) работает» в последний год — возросшая нагрузка из-за llm агентов (опровергнуть или доказать теорию не могу, поэтому считаю теорией). Статья выше — описание того, как в компании видят работу с гит репозиториями. Со слов команды теперь над репозиторием может работать 5к агентов одновременно.

Текст начинается с объяснения как горизонтальное и вертикальное масштабирование работает в гитхабе (горизонтальное о работе одним человеком над разными репами, вертикальное — куча человек и один репозиторий). При этом, люди работают импульсами (это об elasticity), а агенты — постоянным «потоком» запросов. Для решения проблемы начали «Project Rubicon», который основан на хранении pack data в Azure Blob Storage. В тексте дальше найдете информацию о том, как архитектурно устроено хранение данных, как мутации происходят и почему нужны разные хранилища для данных.

#llm #how_it_works

—————————————

AI Productivity

Каждую неделю вижу пачку статей о продуктивности вокруг написания кода с llm. Статья выше понравилась тем, что автор отдельно описывает ситуацию для менеджеров и для разработчиков и делает это через инженерию. Плюс сохранилось доверие к автору по прошлым текстам. Основная цель текста (со слов автора) — развенчать заблуждения об эффективности вокруг llm. Ну и сразу напишу, статья — личное мнение.

Сам текст делится на две части: в первой объясняется для менеджеров что с разработкой происходит. Во второй — аналогичное объяснение, но для разрабов. В случае менеджеров заблуждения о том, что окупаемость llm не требует компетенций и глубоких знаний. Плюс без инженерии никуда, а идеи нужно валидировать (если идею может сделаь нейронка, то конкуренты смогут сделать тоже самое, что убивает ценность идеи). Отдельно отмечу, что автор объясняет кто такой инженер через ответственность, последовательность, reasonable и через «решение правильных проблем».

Для разрабов, автор, фокусируется на том, как коммуницировать с руководством в текущих условиях. Но начинается блок с гипотез почему людей увольняют (работа невидима и с llm работать проще, чем с человеком). Дальше разбирается проблема «мы купили подписку, почему нет х10 к производительности?» и как взаимодействовать с менеджерами.

#llm #productivity

Пятничное чтиво

Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.

—————————————

Message Queues

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

Текст пытается ответить на три вопроса: зачем очереди нужны, как работает внутрянка очередей и когда использовать очереди. Текст начинается с примера синхронной блокирующей обработки запроса, из-за чего появляются проблемы с latency, traffic spikes, inefficiency и fragility. Для решения описанных проблем как раз очереди и подходят. Далее дается определение очереди и описываются три идеи, которые в SRE помогают: ack, гарантии доставки и предотвращение дубликатов. В конце приводятся примеры, когда брокеры работают лучше синхронной обработки, описываются некоторые нюансы (партишены, durability, DLQ и так далее). А в самом конце — примеры технологий.

Если с очередями на «вы» — статья пойдет как энти поинт. Из минусов — странно, что кафку, вместо лога назвали очередью (но автор SRE).

#async_communications

—————————————

What is Architecture Pricing?

Одна из проблем, к которой не понимаю как подступиться — расчет «цены» архитектурных решений. Можно взять COCOMO модель, но в реальности цена окажется другой, поэтому 99% расчетов все равно получаются «пальцем в небо». Поэтому сегодня статья о том, как считать стоимость архитектуры.

Текст начинается с объяснения модели Architecture Pricing, благодаря которой архитектура переводится в planning units (спринты, пиццы, карты и так далее). При этом, проблемы связываются с арх решениями и через cost of delay, можно сопоставить арх задачи с функциональными требованиями. Состоит модель из четырех пунктов: Detect, Locate, Price и Decide. Далее в тексте описывается каждый из четырех пунктов отдельно и описывается что на вход модели попадает и что получается на выходе.

#architecutre_cost

—————————————

What's a decision model?

Я так и не поймал «хайпа» вокруг ллм. Но третий год подряд надеюсь, что появится больше DSS (decision support systems) решений (видимо ждать еще долго). Поэтому появление в инфополе decision model (таких как jev) — воспринял позитивно. Автор текста как раз рассказывает что такое decision model, зачем нужны такие модели и как модель работает.

Текст начинается с решений, для которых нужны ответы на вопросы в духе «Х это Y или нет?». Как решение — берем llm, получаем простыню вероятностно сгенерированных токенов, вместо прямого ответа да/нет (и генерация ответа медленная). Можно пойти другим путем, через прямое использование вероятностей для генерации детерминированных ответов (сколько раз не спроси, вероятность не меняется). Вот тут и появляется decision model, а точнее jev, о которой и рассказывается в статье. Из интересного — ценообразование, платишь за входные токены, выходные бесплатны. Для обучения используется Reinforcement Learning for Calibrated Decisions (RLCD), для отдачи вероятностей. Поддерживается 4 типа ответа с вероятностями (да/нет, выбор, оценка опций и выделение объекта на картинке). А в конце текста, автор, рассказывает о классификации и главную проблему decision model — калибровку и объяснение распределения.

#llm

Пятничное чтиво

Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.

—————————————

Postgres Transactions are a Distributed Systems Superpower

Статья от инженеров dbos, в которой объясняется, почему в компании советуют держать workflow system в том же инстансе постгреса, что и основное приложение. Т.е. вместо двух баз, одной для приложения, второй для workflow engine, воспользоваться одной общей бд.

Текст начинается с описания главной проблемы — distributed systems, из-за чего решение становится сложнее. Сложности возникают в двух местах: идемпотентности и transactional outbox. Далее автор объясняет каждую из проблем. В случае идемпотентности для шагов проблема в том, что шаг может сломаться когда уже выполнен, но не записан в базу как выполненный. Для этого и нужна идемпотентность каждого из шагов, а за счет одной бд — можно обновлять состояние шага и бизнес логику в одной транзакции. В случае outbox паттерна история похожая, можно в одной транзакции записать как результат выполнения, так и событие для следующего шанга. Что приводит к atomicity.

#distributed_systems

—————————————

The Limits to Growth

Если посмотреть на темпы роста системы, то получится не линейный график. Пример — скорость добавления фичей в новом проекте и в легаси. Ludwig von Bertalanffy касался этой темы через aллометрию и конкуренцию за ресурсы. С другой стороны, если слышали о system dynamic, то там объясняется поведение через скрытый «балансирующий» цикл и заполняемость стоков, благодаря чему появился термин «предел роста» (балгодарить Donella Meadows и Jay Forrester).

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

#system_dynamic

—————————————

SDLC Models Explained and Compared

Обычно, выбор способа разработки software system начинается и заканчивается на аджайле (со скрамом). На деле, выбор модели жизненного цикла (SDLC) такая же инженерная задача как и выбор паттерна или технологии. И также может быть описана через проблемы и требуемые свойства. К сожалению, в интернете мало статей на эту тему, поэтому сегодня нейротекст (о чем пишет автор в самом конце).

Если быстро пересказывать текст, то автор объясняет 8 моделей жизненного цикла (Waterfall, V-Model, Incremental, Iterative, Spiral, Prototype, Rapid Application Development и Agile). Описание состоит из объяснения как работает каждый этап жизненного цикла, какие плюсы и минусы у моделей. В конце модели сравниваются по семи свойствам (как с рисками работать, документация, fit под большие проекты и так далее).

Ссылка выше появилась в посте только чтобы показать, что нет хорошего или плохого life cycle model. И модель разработки необходимо выбирать под проект, этап жизни компании и другие свойства, а не брать agile не думая (или потому что так делают другие), что идентично выбору технологий и паттернов (привет микросервисам и кафке).

#sdlc