Python: The Documentary | An origin story (Рубрика #Software)

Посмотрел вчера интересный документальный фильм про путь языка программирования Python от побочного проекта до языка, что вознесся до самого популярного благодаря AI революции:) Фильм вышел в конце августа и был выпущен студией Cult.Repo (бывший Honeypot), а режиссёром была Ида Бехтле. Создание фильма профинансировали Anaconda, запрещенная в России Meta, OpenTeams, PyCharm (JetBrains), Quansight. Если кратко говорить про основные моменты, то вот они
1. Истоки истории в CWI (Амстердам), а также влияние языка ABC и раннего интернета
2. Первые пользователи и индустриальные успехи (NASA, YouTube, Dropbox)
3. Становление научного стека (NumPy/SciPy)
4. Сильные стороны и кризисы сообщества на примере перехода от python 2 к python 3
5. Культурный код «The Zen of Python»
6. Роль инклюзивных инициатив (например, PyLadies)
7. Отказ Гвидо ван Россума от роли BDFL после спора вокруг оператора «морж» (:=)

В титрах и в официальных материалах упоминается много уважаемых людей: Guido van Rossum, Travis Oliphant, Barry Warsaw, Armin Ronacher, Brett Cannon, Mariatta Wijaya, Jessica McKellar, Steven Pemberton, Lambert Meertens, Sjoerd Mullender, Ken Manheimer, Tim O’Reilly, Ton Roosendaal, Peter Wang, Lisa Guo, Lisa Roach, Paul Everitt, Benjamin Peterson, Robin Friedrich, Drew Houston, Bob (Robert) Kahn и др.

Если делать выводы из этой документалки, то они такие
1. Сила Python - не только в языке, но и в культуре. Простота/читабельность + «Zen of Python» и открытая инженерная этика задали стандарт, к которому тянулись и ядро, и экосистема.
2. Сообщество - главный «двигатель». PyCon, PSF, PyLadies, добровольцы‑мейнтейнеры и компании‑партнёры - всё это и есть «топливо» развития.
3. Сложные решения имеют цену, но дают будущее. История миграции с v2 на v3 - болезненная, однако именно она позволила языку эволюционировать и обновить основы (а спор вокруг PEP 572 привёл к более устойчивой модели управления).
4. Python побеждает как «клей» над быстрыми библиотеками. Успех в науке/ИИ объясняется тем, что язык удобно объединяет мир C/C++/Fortran‑библиотек в единую продуктивную среду. Фильм подчёркивает это через истории NumPy/Anaconda/ML.
5. История языка - это история людей. От академических лабораторий CWI и Usenet‑эпохи до YouTube/Dropbox: персональные выборы и локальные инициативы складываются в глобальный результат.

В общем, фильм очень приятно снят и интересно смотрится, рекомендую.

#Software #Architecture #Engineering #Leadership #AI #ML #Data

[1/2] Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence (Рубрика #AI)

Интересное исследование на тему влияния AI на трудоустройство от ребят из Стэнфордского университета: Erik Brynjolfsson, Bharat Chandar и Ruyu Chen. Кстати, Бриньолфсон соавтор крутой книги "Machine, Platform, Crowd", про которую я уже рассказывал. Цель у этого нового исследования была в оценке недавних изменений (2022 - 2025 годы) на рынке труда США в профессиях, наиболее подверженных влиянию генеративного искусственного интеллекта. Данные для анализа были получены в сотрудничестве с компанией ADP - крупнейшим поставщиком программного обеспечения для расчёта заработной платы в США, что обеспечило авторам доступ к масштабным актуальным сведениям о занятости. Executive summary итогов исследования выглядит так

1. Сокращение занятости молодых специалистов в профессиях с высоким воздействием ИИ.
С момента широкого внедрения генеративного ИИ (конец 2022 года) занятость молодых работников в возрасте 22–25 лет в наиболее “подверженных ИИ” профессиях заметно снизилась (13%-ное относительное снижение), хотя занятость более опытных специалистов старшего возраста не падала.
2. Общий рост занятости при застое для молодёжи в уязвимых сферах.
Общая занятость в экономике продолжает уверенно расти. Иными словами, наблюдается перераспределение рабочих мест: в целом рабочие места добавляются, но рост практически не затрагивает именно молодых работников в высоко-автоматизируемых ролях
3. Большее сокращение там, где ИИ автоматизирует, а не помогает.
Спад занятости концентрируется в тех должностях, где применение ИИ скорее автоматизирует человеческий труд, чем дополняет его. В профессиях, использующих ИИ в качестве инструмента дополнения (усиления) работы человека, серьёзных сокращений не обнаружено. Однако в задачах, которые ИИ способен полностью автоматизировать, занятость молодых снизилась наиболее сильно, например, в разработке софта или службах саппорта клиентов.
4. Эффект сохраняется даже с учётом факторов компаний/отраслей
Авторы проверили, не обусловлены ли наблюдаемые сокращения какими-либо специфическими шоками на уровне отдельных фирм или отраслей. Оказалось, что дело не в этом.
5. Корректировка происходит через увольнения, а не через зарплаты.
Анализ рынка труда показывает, что адаптация к ИИ происходит преимущественно за счёт изменений в уровне занятости, а не через изменение уровня оплаты труда.
6. Результаты устойчивы при различных проверках и выборках
Авторы проверили влияние конфаундеров, но оказалось, что дело не в них. Все вышеперечисленные тенденции сохранились при различных дополнительных проверках. Например, исключение из анализа технологических компаний, а также профессий, легко переходящих на удалённую работу, не изменило общих выводов

В совокупности эти результаты предоставляют первые крупномасштабные доказательства того, что “революция ИИ” уже начала заметно и непропорционально влиять на работников начального уровня на американском рынке труда. Молодые специалисты в высокотехнологичных и автоматизируемых профессиях выступают здесь в роли “канареек в шахте” - раннего индикатора грядущих перемен.

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

#AI #Software #Engineering #Management #Leadership #Data #Whitepaper #Metrics

[2/2] Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence (Рубрика #AI)

Продолжая рассказ про канареек, надо рассказать о том, что методология опиралась на данные ADP по зарплатам, а также на оценке подверженности профессий влиянию AI, где использовался подход из "GPTs are GPTs: Labor market impact potential of LLMs" и "Экономический индекс Anthropic" ("Which Economic Tasks are Performed with AI? Evidence from Millions of Claude Conversations"). Экономический индекс от Anthropic основан на анализе реального использования ИИ (модели Claude) по миллионам запросов, показывающий, какая часть запросов связана с задачами определённых профессий. Он позволяет разделить применения ИИ на автоматизирующее vs. дополняющее: индекс оценивает, сколько запросов носят автоматический характер (полное выполнение задачи ИИ) и сколько - вспомогательный (помощь человеку). Это позволило авторам исследования про канарейки классифицировать профессии по тому, используется ли ИИ в них как замена труда либо как инструмент для повышения эффективности труда.

Сопоставив кадровые данные ADP с показателями экспозиции, исследователи проследили динамику занятости с конца 2022 по середину 2025 года. Отправная точка – осень 2022, когда произошёл скачок в доступности генеративных ИИ-инструментов (например, появление GPT-3.5/ChatGPT). Анализ проводился по группам: сравнивались профессии с высокой и низкой экспозицией к ИИ, а внутри них – молодые специалисты vs. сотрудники старшего возраста. Чтобы изолировать эффект именно ИИ, авторы применили контроль на уровне фирм (учитывали шоки и тенденции внутри отдельных компаний и отраслей)

Если говорить про будущее, то авторы подчеркивают не только кратковременное влияние на уровень занятости, но подчёркивают и адаптивные механизмы. Исторически, технологические революции (как компьютеризация в 1980-90х) сопровождались периодом перераспределения рабочих мест, после которого наступал новый рост занятости и зарплат. Возможно, аналогичный процесс разворачивается и сейчас: появляются сигналы, что молодёжь уже реагирует на тренд, переориентируясь в сторону менее «автоматизируемых» профессий (фиксируется снижение интереса к специальностям, тесно связанным с ИИ, например, к компьютерным наукам).

Индустриям предстоит приспособиться: компании, активно внедряющие ИИ, должны продумывать стратегии переподготовки персонала и создания новых ролей, где человеческий труд дополняет ИИ. В краткосрочной перспективе отдельным секторам экономики придётся решать проблему молодёжной занятости – чтобы избежать «потерянного поколения» начинающих специалистов, вытесненных алгоритмами. В долгосрочной же перспективе, если адаптация пойдёт успешно, ИИ может стать инструментом, который повысит производительность и откроет новые возможности для роста в большинстве отраслей, как это случалось с предыдущими волнами технологий. Однако текущее исследование ясно даёт понять: эффект ИИ на рынок труда уже начался, и игнорировать его сигналы индустриям не следует.

#AI #Software #Engineering #Management #Leadership #Data #Whitepaper #Metrics

Большое исследование AI в инженерной культуре России (Рубрика #AI)

Мы в Т-Банке активно работаем над созданием AI экосистемы инструментов для наших разработчиков, которые помогают нам эффективнее создавать продукты для клиентов. Мы много рассказываем про это конференциях для разработчиков, а в пятничной мега-конференции BigTechNight весь трек Т-Банка был посвящен этой теме. И именно в пятницу мой коллега Станислав Моисеев рассказывал доклад про измерение продуктивности на уровне человека / команды / компании / целой индустрии. И если первый три уровня мы измерять умеем, то последний требует отдельного подхода. И Стас анонсировал старт большого исследования AI в инженерной культуре российских компаний.

Мы решили провести такой опрос для того, чтобы
- Получить актуальные данные о том, как AI‑решения применяют в России. Пока есть информация только о международных практиках, но к российскому рынку это почти неприменимо
- Отделить хайп от реального эффекта. Многие компании экспериментируют с AI, но не всегда ясно, помогает ли это повысить продуктивность и качество. Исследование поможет измерить реальные результаты;
- Понять, как AI влияет на бизнес‑результаты. Например, на пользовательский опыт и удержание сотрудников;
- Помочь компаниям и инженерам. Компаниям - понять, где они находятся в контексте рынка и какие AI‑решения правда работают, а инженерам - оценить, насколько их опыт совпадает с опытом коллег.

Мы ожидаем, что в опросе поучаствуют
- Инженеры и технические специалисты: разработчики, DevOps/SRE, инженеры данных, QA‑инженеры, специалисты по ML и AI;
- Технические лиды и менеджеры: тимлиды, Engineering Managers, руководители групп разработки;
- Руководители и топ‑менеджеры: CTO, Heads of Engineering, директоры по продукту.

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

P.S.
Я отвечаю за методологию этого исследования и подведение итогов, поэтому я очень заинтересован в большом охвате исследования. И если вы не только пройдете сам опрос, но и скинете ссылку на него своим друзьям и коллегам, то я буду вам очень благодарен.

#AI #Software #Engineering #Management #RnD #Leadership #Data

Review of Book "AI Engineering" #3 - Chapter 3 & 4: Evaluation Methodology и Evaluate AI Systems(Рубрика #AI)

Вышла третья серия подкаста с разбором крутой книги "AI Engineering", которая дает представление об оценке как самих foundation models, так и приложений на их основе. Книгу разбирает Александр Поломодов, технический директор Т-Банка, а также Евгений Сергеев, engineering director в Flo. Собственно, в этой серии мы обсудили две главы: "Chapter 3: Evaluation Methodology" и "Chapter 4: Evaluate AI Systems". Ну а если раскладывать по темам, то они представлены ниже

- Введение и тема выпуска
- Почему оценка ИИ‑приложений сложна; рост важности валидации
- Валидация в пайплайнах и сложности доменов
- Ограничения бенчмарков и переход к продуктовой валидации
- Риски неконтролируемой генерации
- Теория информации: энтропия как база метрик
- Кросс‑энтропия и KL‑дивергенция для оценки моделей
- Перплексия и влияние контекста на уверенность модели
- Функциональная корректность vs нефункциональные требования
- От лексической к семантической близости; эмбеддинги
- Паттерны валидации и AI as a judge
- Попарные сравнения и ранжирование моделей; транзитивность и голосования
- Каркас системы: критерии → выбор моделей → сборка пайплайнов
- Факт‑чек и референс‑чек; доверенные источники; человеческий бейзлайн
- Дизайн пайплайна: независимые тесты, гайдлайны, разметка; финальные выводы

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

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

[1/2] Monarch: Google's Planet-Scale In-Memory Time Series Database (Рубрика #Architecture)

Наконец-то я дочитал оригинальный whitepaper про эту интересную систему для работы с time-series данными от Google. Идея появилась после моего погружения в архитектурный whitepaper, где эту систему перепроектировали с использованием quality-based подхода и UML диаграмм. Если кратко, то суть примерно такая, что в 2020 году вышла статья на VLDB Endowment про эту самую масштабную в мире базу для временных рядов
1) Monarch - это глобально распределённая, мультитенантная in‑memory БД временных рядов для мониторинга почти всех пользовательских и инфраструктурных сервисов Google. Ежесекундно принимает терабайты метрик и обрабатывает миллионы запросов. Архитектура - разделенная по регионам с глобальным plane запросов и конфигурации.
2) Ключ к масштабу: лексикографическое шардирование по “target”, агрегация на этапе сбора, компактные индексы подсказок (Field Hints Index), двухуровневые исполнители запросов (Root/Zone Mixers).
3) На июль 2019: почти 950 млрд рядов в оперативной памяти (~петабайт сжатых данных); средняя агрегация при сборе 36:1 (до 1 000 000:1); индексы позволяют срезать fan-out до десятков тысяч лишних leaf‑узлов.

Как это примерно работало
- Система мультитенантная и глобальная. Региональные зоны автономно принимают и хранят данные в памяти, а глобальные плоскости обеспечивают единый запрос и конфигурацию. Это снижает зависимость от внешней персистентности и повышает доступность мониторинга во время инцидентов.
- Модель данных и запросов отличается от предшественника Borgman (кстати, именно Borgman стал прототипом Prometheus - об этом можно глянуть в документалке, о которой я рассказывал). В отличие от “строчных ключей” прежних систем, Monarch использует типо‑насыщенную реляционную модель метрик (включая распределения/гистограммы) и выразительный язык запросов, что упрощает статический анализ и оптимизации.
- Архитектура обработки выглядела примерно так
-- Ингест: клиенты → ingestion routers → зона → leaf router → Leaves (in‑memory). Уже здесь может работать collection aggregation.
-- Запросы: Root Mixer распределяет по зонам (Zone Mixers); Index Servers (в т.ч. Field Hints Index) заранее исключают нерелевантные узлы, резко уменьшая фан‑аут.
- Отдельно были сделаны оптимизации
-- Collection aggregation: в среднем 36 входных рядов → 1; в экстремуме до 10⁶:1. Экономит память/CPU и трафик.
-- Field Hints Index (FHI): зоны с >10 000 leaves и триллионами ключей; FHI позволяет отсечь ~73 000 нерелевантных leaves для сложных выборок.
-- Лексикографическое шардирование по target: все метрики одного объекта попадают на один leaf → локальные агрегации/джойны, меньше fanout.

В продолжении рассказ, а что было с этой системой дальше.

#Software #Architecture #DistributedSystems #SRE #Engineering #Databases #Data

[2/2] Monarch: Google's Planet-Scale In-Memory Time Series Database (Рубрика #Architecture)

Но на этом история монарха не закончилась. Уже в 2023 году на конфе ICSE‑SEIP’23 ребята из Google опубликовали whitepaper-продолжение (что я уже разбирал).
Тезисно этот paper можно сократить до следующих пунктов
1) Причина: двукратный рост год‑к‑году QPS и числа рядов, проблемы с поддержкой и дальнейшим попаданием в SLO
2) Команда решила провести редизайн с опорой на quality‑attribute сценарии + лёгкие UML‑модели
3) Фактически, декомпозицировали Leaf на Leaf (KV‑хранилище), Leaf Index Server и Leaf Mixer.
4) Это повлияло в плюс на доступность и сопровождаемость, а latency выросла умеренно, хотя хопов стало больше на 2  (рост с ~12–14 до 16–18 RPC)

Но и это было не все - принципы Monarch легли в основу облачного Managed Service for Prometheus: это сервис на том же бэкенде Monarch, которым Google мониторит свои сервисы. Запросы PromQL частично вычисляются на стороне Monarch. Для инженерных команд это даёт из коробки «глобальный» Prometheus‑опыт. Кстати, вопрос масштабирования отдельных Prometheus возникает у крупных компаний часто и для решения этого вопроса появился проект Thanos. Еще можно глянуть на VIctoriaMetrics, этот проект тоже борется с ограничениями Prometheus, но по другому (можно глянуть мой разбор подкаста где автор проекта про это рассказывал)

Если подбивать уроки из истории Monarch, то стоит
- Собирать метрики ближе к источнику, аггрегировать рано (уменьшение кардинальности и стоимости)
- Дешёвый предикатный индекс → дешевле распределённые запросы (урезать fanout до выполнения)
- Строго разделять stateful и stateless части (проще сопровождать, легче выдерживать SLO при росте) - фокус на этом во втором whitepaper про редизайн
- Шардирование по бизнес‑ключу (target) - локальные агрегации/джойны дешевле.

#Software #Architecture #DistributedSystems #SRE #Engineering #Databases #Data

Программирование смыслов (Рубрика #AI)

Посмотрел вчера интересное выступление Алексея Гусакова, CTO бизнес‑группы «Поиск и рекламные технологии» в Яндексе. Алексей рассказывал об изменениях в подходах к созданию продуктов - они активно развивают ML и LLM‑стек и внедряет нейросети в ключевые сервисы (Поиск, Алиса, Браузер и др.). Если кратко, то фокус разработки смещается от детального кодирования алгоритмов к проектированию намерений и смыслов: вы формулируете задачу, ограничения, источники знаний и метрики качества, а поведение системы «программируете» комбинацией промптов, данных, инструментов и вознаграждения (reward). В такой модели ценность создаётся не одиночным микросервисом, а циклом: гипотеза → прототип → измерение → дообучение/тонкая настройка → интеграция. Внутренний стек и процессы должны это поддерживать.

Собственно, доклад Алексея отлично рассказывает переход к программированию смыслов по шагам
1) Как всё началось
В 2022 Яндекс запустил диалоговый эксперимент «Гуру по товарам» - это была попытка превратить поиск в помощника по выбору: задаёшь вопросы (“какой телек взять?”), система уточняет параметры и ведёт к покупке. Но пользователям не зашло - общение с гуру ощущалось как заполнение скучной анкеты. Команда потратила много ресурсов, наделала ошибок, но получила важные сигналы о том, какой диалог “продаёт”, а какой — раздражает.
2) Поворотный момент
В конце 2022 года вышел ChatGPT и появились генеративные ответы в Bing. Перед командой Yandex появилась дилемма: пилить “большую сложную штуку” (аля как у Bing) или идти инкрементально. Выбрали второе - быстрые, приземлённые улучшения вокруг текущей выдачи.
3) Что именно сделали (и где)
- Начали собирать ответы на основе сниппетов и инфоконтекста; обучили собственную LLM для абзацев‑ответов.
- Перешли к структурированным ответам из нескольких источников: модель планирует, какие документы использовать и как сшивать факты. Балансировали стабильность vs. риск: не выпускать “магический” ответ любой ценой, а двигаться ступеньками, проверяя качество. Сместили фокус с “идеальной рекомендации” к системе ограничений: не повторяться, сохранять разнообразие, поддерживать новичков и т. п. Оптимизация таргета происходила внутри набора правил, а не поверх “чёрной коробки”, - так проще контролировать поведение.
- Пошли в ассистенты, но абстрактные описания вроде “будь умным и полезным” не собирают дают продукт. Выработали принципы, которые действительно работают: ответы не слишком длинные/короткие, правдивые, персонализированные, без вымышленных товаров/свойств; форму ответа модель выбирает, глядя на онлайн‑сигналы.
4) Машинное обучение как конвейер
Запустили повторяемый цикл: AI-тренеры размечают и оценивают ответы → обучаются генеративная модель и модель вознаграждения (RM) → катим улучшения → снова собираем обратную связь. Стали на встречах “мудрецов” обсуждать работу моделей
- Использовали пайплайны с несколькими моделями на один запрос: даже с “замороженными” параметрами можно сильно вырасти за счёт правильной оркестрации и большего вычисления.
5) Какие проблемы были и как их лечили
- Reward‑хаккинг: после первого цикла RM модель “учится” радовать оценщик - внезапно удлиняет ответы, начинает копировать куски источников, вставляет лишние дисклеймеры.
- Фиксы: в модель rewards добавили регуляризацию на длину, штрафы за копипасту/канцелярит; отдрессировали стилистику. Был прикольный пример про дисклеймеры, которые оставили только там, где они реально помогают.
- В итоге, продуктовая и ML‑разработка смешались - промпты, RM, правила и метрики стали такими же артефактами продукта, как код.
6) Принципы ранжирования и ответов
Ссылки в выдаче — это смесь офлайн‑оценки релевантности и онлайн‑вероятности успеха.
Ассистенты строят ответы поверх этих ссылок, а не “из воздуха”, чтобы сохранять верифицируемость.

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

Техношоу «Дропнуто»: выпуск 1 (Рубрика #SRE)

Посмотрел вчера интересный выпуск нового шоу "Дропнуто" от моих коллег из Т-Банка. В этом шоу ребята говорят об инцидентах на дата‑платформах, с честным разбором причин и выводов. Интересно, что шоу идет в прямом эфире, что должно вселять надежду в минимум редактуры и зап...ния. Формат выдержан в духе blameless postmortems, где мы подходим к постмортемам без обвиненений и даже с прицелом на обучение - чель поговорить про то, а почему отказы случаются, как их предотвратить и что изменить в процессах/архитектуре для повышения надежности (кстати, про надежность в Т-Банке хорошо рассказывал Леша Мерсон в статье, о которой я писал раньше).

В первом выпуске подкаста гостем был Александр Крашенинников из Т‑Банка, практик в области платформ данных/ETL/DWH, а также просто человек с хорошим чувством юмора и навыками импровизации, что можно увидеть из его рассказа о двухнедельном инциденте в датаплатформе, о котором он рассказывает в этом эпизоде. Цепочка инцидента выглядит кратко примерно так: удаление/потеря метаданных → падение чтения в Trino → нет бэкапа/медленное CDC‑восстановление → критичный инцидент → разворот на новую Kafka‑архитектуру + контракты → унификация схем, параллельные загрузки → валидация и исправление расхождений → восстановление сервиса с возможной частичной потерей → восстановление сервиса из бекапов и дозагрузка исторических данных.

Инженерам может понравитсья этот «боевой» разбор инцидента
- Эксплуатация CDC (change data capture): где Debezium удобен, его архитектурные варианты, типовые грабли
- Паттерны целостности: outbox‑подход для надёжного обмена событиями между сервисами и границы применимости.
- Наблюдаемость пайплайнов: какие SLI поднимать для «скорости данных» (freshness/latency), целостности (дупликаты/пропуски), устойчивости коннекторов.

Руководителям эпизод полезен для управленческой оптики:
- Единый язык риска: связать цвет/серьёзность инцидента с бюджетам ошибок и фризом релизов
- Культура обучения на сбоях: blameless‑постмортемы как системный инструмент качества и коммуникации между командами данных/продукта/SRE.
- Управление SLO: перевод пользовательских метрик (например, «данные в витрине свежи ≤ X минут 99,9% времени») в алерты и план/факт по риску.

#SRE #SystemDesign #Software #Architecture #Metrics #SoftwareArchitecture #Engineering #Databases #Data