[2/2] The Effective Software Engineer (Рубрика #Staff)

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

1. Foundations of Effectiveness - переход от «сколько сделали» к «какой эффект получили»: outcomes vs outputs, мыслить бизнес‑контекстом, измерять влияние, собирать обратную связь.
2. Understanding the Fundamentals (L3–L4) - поддерживаемый код, тесты, дисциплина отладки, Git, «писать, чтобы другим было понятно» - все это фундамент, на котором строится рост.
3. Technical Depth vs Breadth (L5+) - модель T‑shape: глубокая экспертиза + рабочая широта. Как проектировать на масштабе, оценивать компромиссы и управлять техдолгом, не теряя фокус продукта.
4. Collaboration & Cross‑Functional Influence - работа с PM/дизайном, как влиять без полномочий и "управлять вверх": проактивная коммуникация, согласование целей, приходить к менеджеру не с проблемами, а с решениями.
5. Anti‑Patterns That Limit IC Effectiveness - каталог антипаттернов: силосы знаний, «герой‑комплекс», овер‑инжиниринг vs YAGNI, несостоятельность делегирования, «невидимая работа», паралич анализа, NIH, перфекционизм, переключение контекстов, scope‑creep, отрицание техдолга, перегруз митингами, сопротивление фидбеку, «охота за тулзами», синдром самозванца.
6. Career Growth & Leveling Up - про системный рост и переход на следующий уровень — от понимания ожиданий до того, а как сделать вклад в результат видимым окружающим
7. Leadership as an IC - лидерство без должности руководителия: как вести инициативы, менторить, умножать эффект команды. Связанные принципы подробно раскрыты в главах про сотрудничество и влияние
8. Strategic Thinking for Engineers - как сместить фокус с «как реализовать» на «что и почему реализовывать»: приоритизация high‑impact работы, баланс долгосрочных улучшений и быстрых результатов, опора на данные.
9. Avoiding Burnout & Sustaining Long‑Term Success - границы, энерго‑менеджмент, "сказать нет", культура, где выгорание не героизируется. Консистентность > спурты. Кейсы и конкретные практики.
10. Individual Effectiveness Anti‑Patterns - "героизм" в последний момент, «накопительство кода», бесконечный рефакторинг и распухание скоупа, self‑merge и "вечные PR". Тут не только описание антипаттернов, но и способы того, как их распознать и заменить на зрелые практики.
11. Team‑Level Effectiveness Anti‑Patterns - тут уже не персональные проблемы, а про системную динамику: силосы, проблемы на ревью, перекосы приоритизации и пр. Автор рассказывает о том, как это чинить процессами и культурой.
12. Thriving in Modern Work Environments - как быть эффективным в распределенных командах: «перекоммуницировать правильно», явная видимость работы, режимы, договариваться про каналы/часы, качать письменную речь и публичные выступления.
13. The Future of Individual Contributors - глава о будущем: как ИИ усиливает IC, про то, что ценность фундаментальных навыков растет, а также о том, что карьера IC жизнеспособна на долгой дистанции.

По итогу, это актуальная книга для инженеров, которые осознанно подходят к развитию своей карьеры.

#Engineering #Leadership #Software #Career #Architecture

[1/2] Hands-On Large Language Models (Рубрика #AI)

В свой отпуск я захватил с собой этот визуальный путеводитель по большим языковым моделям или просто LLM:) Так как я воспринимаю информацию визуально на порядок лучше, чем на слух, а также сам строю схемы для визуализации сложных тем, то эта книга мне показалась просто блестящей - она не просто объясняет сложные темы, она показывает их через визуализации и код.

Книгу написали два эксперта в ML/AI:
- Джей Аламмар - engineering fellow в Cohere, автор культовых визуальных гайдов по ML и NLP. Его диаграммы разбирают в документации NumPy, pandas и на курсах deeplearning.ai. У него есть свой топовый блог
- Маартен Гротендорст - дата-сайентист, автор open-source библиотек (BERTopic, KeyBERT), специалист в теме тематического моделирования и эмбеддингов. У него есть свой топовый блог

Они придерживаются философии обучения когда сначала развивается интуиция (через качественное понимание концепций), а уже затем подкрепляют его формальным описанием и примерами. Для этого используется формат визуального повествования: книга содержит почти 300 оригинальных иллюстраций и диаграмм, созданных специально для этого издания. Посредством наглядных схем, графиков и рисунков сложные механизмы LLM (например, механизм self-attention в трансформерах, работа токенизаторов, многомерные пространства эмбеддингов и т.д.) разъясняются постепенно и доступно. Помимо визуализации, авторы делают акцент на практической стороне применения языковых моделей (об этом говорит hands-on в названии книги). Они приводят много примеров кода, сценариев и практических кейсов (код доступен на GitHub).

Книга отлично подойдет для всех
- Начинающих и продвинутых специалистов в ML/NLP
- Разработчиков и аналитиков, внедряющих LLM в проекты
- Всех, кто хочет уверенно ориентироваться в современных моделях вроде ChatGPT, Mistral или Claude

В продолжении немного про содержимое всех трех частей книги.

#Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems

[2/2] Hands-On Large Language Models (Рубрика #AI)

Продолжая рассказ про эту книгу, скажу о том, что она состоит из трех частей и 12 глав (я пока прочитал четыре с половиной главы, поэтому про них расскажу подробнее). Но если кратко, то книга начинается с основ LLM, дальше авторы переходят к их использованию для решения задач, а заканчивают методами обучения моделей.

Часть I: Понимание языковых моделей
Первая часть закладывает фундамент, объясняя, что такое языковые модели и как они устроены.
Глава 1. Здесь приведен обзор развития обработки языка - от "bags of words и классических представлений текста до появления методов вроде word embeddings и архитектуры трансформеров. Читатель узнает, что собой представляют большие языковые модели, и чем они отличаются от предыдущих подходов. В главе также обсуждается, почему LLM стали настолько полезными.
Глава 2. Авторы погружаются в тему токенизации и эмбеддингов - ключевых понятий для представления текста в численной форме. Авторы подробно описывают, как работает токенизатор LLM (преобразуя текст в токены), сравнивают разные виды токенов (слова, подслова, символы, байты) и демонстрируют свойства обученных токенизаторов. Далее рассматривается, как модель превращает токены в векторные представления (эмбеддинги) и как эти эмбеддинги могут использоваться для представления слов, предложений и документов. Приводятся примеры, как с помощью эмбеддингов измерять семантическую близость текстов. В этой же главе объясняются традиционные алгоритмы построения эмбеддингов (например, word2vec) и более современные подходы, вплоть до того, как LLM сами формируют эмбеддинги во время работы. Завершает главу практический пример: обучение модели эмбеддингов для рекомендательной системы (например, рекомендация песен по схожести эмбеддингов).
Глава 3. Авторы показывают внутренности трансформера, объясняя что происходит под капотом. Они рассказывают про forward-pass модели: как обрабатываются входные токены, как вычисляется матрица внимания (attention) и как на её основе модель выбирает следующий токен. Важная часть главы - интуитивное объяснение механизма Self-Attention (внимания), благодаря которому модель учитывает контекст слов при генерации. Также обсуждаются оптимизации: как модели обрабатывают несколько токенов параллельно, какой максимальный размер контекста поддерживается, и как кеширование ключей и значений ускоряет генерацию текста.

Часть II: Использование предварительно обученных моделей
Вторая часть посвящена практическим способам применения готовых языковых моделей и эмбеддингов в разных задачах обработки текста. Здесь авторы переходят от устройства моделей к их использованию "из коробки" для решения прикладных задач.
Глава 4. Классификация текста
Глава 5. Кластеризация и тематическое моделирование (BERTopic)
Глава 6. Инженерия промтов (Chain of Thought, ReAct, Tree of Thought)
Глава 7. Продвинутые техники генерации текстов и инструменты (LangChain и агенты, Memory, Tools)
Глава 8. Семантический поиск и Retrieval-Augmented Generation (RAG)
Глава 9. Мультимодальные модели (текст + картинки, CLIP, BLIP-2)

Часть III: "Обучение и тонкая настройка моделей"
Последняя часть книги посвящена тому, как создавать свои модели и адаптировать существующие LLM под конкретные задачи. Здесь материал становится более продвинутым
Глава 10. Создание моделей эмбеддингов для текста
Глава 11. Fine-tuning representation models для классификаций
Глава 12. Fine-tuning генеративных моделей

В заключительной части (Afterword) авторы подводят итоги проделанному пути и заглядывают в будущее развития больших языковых моделей. Они отмечают, какой колоссальный и широкомасштабный эффект LLM уже оказали на мир и что понимание принципов их работы открывает перед специалистами новые возможности.

#Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems

Good News For Startups: Enterprise Is Bad At AI (Рубрика #AI)

В этой серии подкаста ребята из Y Combinator обсуждали исследование "The GenAI Divide: State of AI in Business 2025" (см. мой разбор), результаты которого говорят о том, что 95% корпоративных AI-проектов проваливаются. Обсуждение строится на том, а в чем причины этих результатов и почему это на руку AI стартапам, а если точнее, то ребята обсуждают вопросы
- Что на самом деле стоит за вирусной статистикой о "95% провалов" AI-проектов?
- Почему внутренние IT-проекты даже в крупных компаниях зачастую буксуют?
- Что усложняет внедрение сложных AI-систем в корпоративной среде?
- Как небольшие AI-стартапы выигрывают конкуренцию у банков и консалтинга?
- Почему устоявшиеся компании не могут создать работающий AI-продукт и что с этим делать?

Мнения управляющих партнеров Y-Combinator примерно такое:
- Броска фраза «95% провалов» искажена: она относится к внутренним решениям в корпорациях, которые не умеют учиться на обратной связи и адаптироваться. Иными словами, дело не в том, что "ИИ не работает", а в том, что большие компании не умеют его строить. Здесь авторы пинают Apple за их приложение-календарь, а уж если Apple делает хреновые решение, то и у обычных компаний и подавно будут проблемы. Большинство корпоративного ПО очень посредственное, а привлечение дорогих консультантов (E&Y, Deloitte) часто только создаёт "две проблемы вместо одной".
- В крупных компаниях существуют организационные сложности: AI-проекту надо учитывать интересы множества команд, преодолевать политические барьеры и согласовывать требования между отделами. Добавьте устаревшие легаси-системы и дизайн "от комитетов" - внедрение AI превращается в долгий и трудный процесс
- AI-стартапы побеждают там, где корпорации пасуют: маленькие команды быстро строят решения под конкретные задачи, сразу с заложенными AI-возможностями (AI-native) и оперативно доводят продукт до результата. Привели кейсы: стартап Tactile за считанные месяцы сделал для банков AI-систему принятия решений, тогда как Citi и JP Morgan потратили годы и миллионы на нерабочие аналоги
- Сейчас для AI-стартапов идеальный момент: крупные фирмы жаждут внедрить ИИ и готовы рисковать с молодыми командами. Боязнь отстать заставляет корпорации быстрее принимать решения и скорее купить готовое AI-решение, чем пытаться сделать своё. Ребята из стартап-инкубатора нахваливали возможности для стартапов в каждом процессе: спрос на AI настолько опережает внутренние возможности компаний, что в каждой нише есть пространство для внешнего решения
- Если возвращаться к гипотезам, которые могли бы объяснить провалы внедрение, то подкастеры выделили человеческий фактор: многие корпоративные инженеры не верят в ИИ, не пользуются новыми инструментами и даже рады ссылаться на исследования вроде MIT, подтверждающие их скепсис. Такая культура приводит к провалу проектов (самосбывающееся пророчество) и упущенным возможностям. В результате предприятия, где внутренние команды сдались, готовы звать на помощь стартапы.

В общем, 95% неудач внедрения AI в корпорациях - это не повод не пробовать. Наоборот, у вас есть все возможности попасть в 5% успешных. Правда, партнеры одного из крупнейших стартап-инкубаторов говорят, что крупные компании, скорее всего, будут всё активнее обращаться к стартапам и покупать готовые AI-решения, поскольку внутренние команды не справляются:) Но я бы тут сделал скидку на конфликт интересов и трактовал это как возможности не только для стартапов, но и для самих корпораций нарастить свои внутренние возможности по использованию AI.

#AI #Engineering #Software #Leadership #ML

[2/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Аспекты инженерной культуры (Рубрика #Infrastructure)

В этом посте мы продолжим рассматривать крутую статью от запрещенной в России компании Meta и поговорим про аспекты инженерной культуры, которая позволяет быть компании успешной. Если сокращать, то эти аспекты звучат так
- Принцип "Move fast"
- Открытость технологий
- Research in production
- Единая инфраструктура и стандартизация

А теперь давайте поговорим про каждый пункт подробнее.

Принцип "Move fast"
С первых дней в Facebook закрепилась культура быстрого развития и итераций. Это выражается в агрессивной практике непрерывного развёртывания ПО - новый код доставляется в продакшн как можно скорее. Большинство продуктовых сервисов пишутся в виде serverless функций на простых языках вроде PHP, Python, Erlang, что упрощает и ускоряет цикл разработки и деплоя изменений. Команды могут легко менять приоритеты и запускать новые продукты без долгих бюрократических процессов.

Открытость технологий
Meta придерживается открытой инженерной культуры как внутри, так и вне компании. Внутри действует единый монорепозиторий для всего кода, причём в большинстве проектов нет жёстко закреплённых владельцев - любой инженер может внести улучшения непосредственно, что поощряет переиспользование решений и кросс-командный вклад.Внешне компания делится разработками с сообществом: Meta открыто публикует аппаратные дизайны через проект Open Compute и открывает исходный код ключевых систем (таких как фреймворк ИИ PyTorch, база данных RocksDB, библиотека рекомендаций ReAgent и др.)

Research in production
В Meta нет отдельной академической исследовательской лаборатории по системам, а все инновации рождаются прямо в продуктах. Команды инфраструктуры постоянно внедряют новые решения и затем оформляют опыт в научные статьи. Такой подход гарантирует, что исследования сфокусированы на реальных проблемах и проверены в боевых условиях, что повышает практическую ценность и надёжность предлагаемых решений. Интересно, что во многих классических компаниях в отличие от Meta сделано по другому. Там отдельные RnD лабы публикуют материалы о космических результатах, которые найдены на кончике пера и еще не доехали на продакшен, а может никогда не доедут (так как все понимают, что в продакшен окружении они просто не работают)

Единая инфраструктура и стандартизация
В Meta стараются избегать разрозненных групп технологий - вместо этого продвигается глобальная оптимизация. На уровне аппаратуры все сервисы работают на унифицированном парке серверов: для вычислительных (не AI) нагрузок выбран один тип стандартного сервера (ранее с 64 ГБ RAM, теперь 256 ГБ). В отличие от облачных провайдеров, предлагающих множество конфигураций под любые клиентские нужды, Meta может сама оптимизировать своё ПО под ограниченный набор оборудования, избегая распыления на зоопарк железа. То же с софтом: разные продукты, бывало, применяли разные хранилища (Cassandra, HBase и собственный ZippyDB), но со временем все консолидировались на одном решении - ZippyDB для хранения пар «ключ-значение». Для каждой распространённой потребности (деплой, конфигурации, service mesh, тестирование производительности и т.д.) используется единый инструмент, принятый повсеместно внутри компании. Стандартизация дополняется модульностью: Meta предпочитает строить системы из переиспользуемых компонентов, а не как монолиты.

Все эти принципы демонстрируются через пример с запуском приложения Threads (конкурента Twitter/X) - 5 месяцев на разработкку небольшой командой и подготовка инфры за 2 дня до запуска, что прошел успешно.

В конце этой части приводится первый инсайт

Insight 1 : Despite many challenges, it is feasible for a large organization to maintain a culture of moving fast, using a common infrastructure, and sharing a monorepo without strictly enforcing code ownership.

В следующем посте мы поговорим про подходы к обработке пользовательских запросов.

#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps

[3/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Сквозная обработка пользовательских запросов (Рубрика #Infrastructure)

В этом посте мы продолжим рассматривать крутую статью от запрещенной в России компании Meta (предыдущие выпуски: 1 и 2). Мы поговорим про обработку пользовательских запросов, которая спроектирована end-to-end для достижения нужного уровня качества (latency, scalability, reliability, ...) и стоимости.

Глобальная сеть и точки присутствия (PoP)
Чтобы минимизировать задержки, Meta динамически направляет запросы пользователя к ближайшему своему узлу. Когда пользователь открывает, например, facebook.com, DNS Meta возвращает IP ближайшего point of presence (PoP) - небольшого edge датацентра, который завершает входящее соединение от пользователя и проксирует трафик в основные регионы датацентров Meta по заранее установленным долгоживущим соединениям (внутри своей WAN сети). Это позволяет сократить время установления соединения и сбалансировать нагрузку между регионами

CDN и кеширование статичного контента
Если пользовательский запрос касается статического контента, то ответ может быть дан напрямую на уровне PoP, если там содержится свежий кеш. Meta также размещает кеш-серверы внутри сетей интернет-провайдеров при большом объёме трафика.

Маршрутизация динамических запросов
Если запрос не относится к статическому контенту (то есть требует генерации ответа на лету), PoP перенаправляет его во внутреннюю сеть Meta. Специальный балансировщик нагрузки в выбранном регионе ЦОД принимает входящий поток и распределяет запросы по фронтенд-серверам. В Meta фронтенд реализован как масштабируемый serverless слой: каждый пользовательский запрос обрабатывается отдельной фронтенд-функцией, которая может вызывать множество бэкенд-сервисов для составления ответа. Здесь появляется второй инсайт от автора статьи

Insight 2 : Meta’s global infrastructure consists of CDN sites, edge datacenters, and main datacenters. Because of the high volume of our internal cross-datacenter traffic, we have built a private WAN to connect our datacenters, rather than relying on the public Internet.

Асинхронная обработка и офлайн-вычисления
Для задач, не критичных к мгновенному ответу, широко применяется асинхронная обработка. Фронтенд-функции могут ставить события в очередь, которые будут обработаны отдельно специальными фоновыми функциями без блокировки ответа пользователю. Такие event-driven функции запускаются параллельно, их выполнение оптимизировано под пропускную способность (throughput), а не задержки (latency), и они не влияют на время ответа основного запроса. В то же время всё, что происходит при обработке запросов, генерирует огромные объёмы данных, которые непрерывно сбрасываются в хранилище данных (data warehouse). Дальше офлайн-системы Meta используют накопленные данные для пакетных и стриминговых вычислений, которые потом используются онлайн-сервисами при обработке новых пользовательских запросов. Здесь появляется третий инсайт от автора статьи

Insight 3 : Using a data warehouse as an intermediate layer to decouple online and offline processing simplifies the architecture and enables independent optimizations.

Это является ключевым принципом устойчивости и эффективности при гипермасштабе.

Топология и масштаб инфраструктуры
Масштаб инфраструктуры примерно следующий
- Регионов в компании десятки, в каждом регионе множество датацентров, в каждом из которых сотни тысяч серверов
- PoPs сотни, в каждом из них от сотен до тысяч серверов
- CDN site тысячи, в каждом из них типично десятки серверов, но иногда бывают и сотни
- MSB (main switchboards) - штука для секционирования питания внутри датацентров, их дюжины в датацентрах, типично MSB обслуживает десятки тысяч серверов

В следующем посте мы поговорим про подходы, что обеспечивают продуктивность инженеров Meta.

#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps