Книжный куб

Predictive Synthesis of API-Centric Code (Рубрика #AI) Я продолжаю изучать темы, связанные с AI в SDLC, что наталкивает меня на статьи вроде "Predictive Synthesis of API-Centric Code" 2022 года. В этой статье Daye Nam и остальные представляют новый подход, enumerative program synthesis для работы с API обработки данных, таких как PyTorch, NumPy и Pandas. Этот подход объединяет человеческую интуицию программирования с автоматизированным синтезом, используя сочетание глубокого обучения (deep learning) и традиционных методов поиска. Ниже я приведу некоторые ключевые моменты статьи 1) Композиционная модель для предсказания последовательностей API Ключевая идея заключается в том, что код, ориентированный на API, можно синтезировать путем предсказания последовательностей вызовов функций API композиционным способом. Авторы предлагают два варианта моделей: - First-of-Sequence (FOS): Предсказывает первую функцию API в последовательности на основе свойств входных/выходных тензоров. - Full-Sequence (FUS): Генерирует всю последовательность вызовов API, необходимых для преобразования входных данных в выходные. Обе модели используют рекуррентные нейронные сети (RNNs) для кодирования форм тензоров (tensor shapes) и эмбеддингов API, что позволяет им изучать шаблоны по примерам входных и выходных данных. 2) Интеграция с перечислительным поиском (Enumerative Search) ML-модели интегрируются в перечислительный синтезатор для сокращения пространства поиска. Приоритизируя последовательности API, предсказанные нейронными моделями, время синтеза сокращается в 6–10 раз по сравнению с базовыми методами, такими как DeepCoder. 3) Обработка сложных структур данных В работе представлены графовые кодировки (graph-based encodings) для представления фреймов данных (dataframes) и тензоров, что позволяет нейронным сетям понимать структурные преобразования. Это особенно важно для таких API, как pandas, где операции включают изменение формы данных, объединение и агрегацию таблиц. Детали реализации Датасет: Модели обучаются на синтетических примерах входных и выходных данных, сгенерированных путем выполнения случайных последовательностей вызовов API. Для pandas AutoPandas использует 1.4 миллиона точек данных, охватывающих 119 функций. Embedding Layers: Кодируют функции API и формы тензоров в плотные векторы. RNN Layers: Обрабатывают последовательности эмбеддингов для предсказания следующего вызова API или всей последовательности. Graph Neural Networks (GNNs): Представляют фреймы данных как графы с узлами (столбцы/строки) и ребрами (отношения между ними). Улучшения алгоритма поиска Подход объединяет символьное исполнение (symbolic execution) с ML-ориентированной приоритизацией. Для каждого кандидата вызова API система проверяет семантическую корректность (например, совместимость форм тензоров) и использует оценки уверенности модели для приоритизации исследования. Интересно, что эта whitepaper повлияла на последующие работы 1. Развитие ML-ориентированного синтеза программ Методология статьи повлияла на инструменты вроде AutoPandas, который использует генераторы на основе нейронных сетей для синтеза преобразований фреймов данных. 2. Вывод типов (Type Inference) и автозавершение кода Поздние работы, такие как Type4Py и DeepInfer, опираются на идею использования ML для семантических предсказаний Ограничения и открытые вопросы - Обобщение на неизвестные API: Модели испытывают трудности с обработкой API, не включенных в обучающие данные; это требует повторного обучения моделей. - Масштабируемость для длинных последовательностей: Точность предсказаний снижается для последовательностей длиной более 3–4 шагов (что решается иерархическим обучением с подкреплением) - Интерпретируемость: Black box нейронных моделей затрудняет отладку; это стимулирует исследования в области explainable synthesis. Интересно, что эта whitepaper была написана до засилья авторегрессионных моделей типа GPT всех версий и больше полагалась на RNN сети, получая пристойные результаты. #AI #ML #Engineering #Software #Architecture #SystemDesign #DistributedSystems

[2/2] The learning trap. How Byju's took Indian edtech for a ride (Ловушка обучения) (Рубрика #Management) Продолжая историю компании BYJU's (1 и 2) стоит рассказать о моменте, когда агрессивный рост дал сбой и к чему все это привело. По мнению автора книги к падению привели следующие проблемы 1) Долговая спираль (2023–2024) - Рост ставок: повышение ставок ФРС увеличило стоимость долларовых займов BYJU'S. - Коллапс залогов: BlackRock снизил оценку компании до $1 млрд к декабрю 2023 г., а партнеры заморозили образовательные кредиты. - Распродажа активов: продажа Epic! и Tynker принесла гораздо меньше, чем было потрачено на их приобретение на пике во времена ковида 2) Юридические проблемы - Банкротство в США: Судья в США признал перевод средств «прямым мошенничеством», инициировав расследование против Равендрана. - Процедура несостоятельности в Индии: NCLT начал процесс банкротства в 2024 г., а кредиторы вернули малую долю средств. - Расследования: индийские органы начали изучать отмывание денег, а против Равендрана действуют запреты на выезд. Все это повлияло не только на BYJU's, что был лидером edtech сектора, но и на остальные компании 1) Отток инвестиций - Обвал оценок: Unacademy и Vedantu потеряли больше половины стоимости, а глобальные фонды (Sequoia, SoftBank) сократили вложения. - Жесткий аудит: инвесторы теперь требуют аудированную отчетность и планы выхода на прибыльность. 2) Регуляторные изменения - Защита потребителей: Edtech Consortium ввел обязательные возвраты и «периоды охлаждения». - Этический кодекс: с 2024 г. запрещены гарантии успеха в рекламе и таргетинг на несовершеннолетних. 3) Перестройка рынка - Гибридные модели: PhysicsWallah и upGrad развивают офлайн-центры, сочетая их с цифровым контентом. - Нишевая фокусировка: стартапы вроде Scaler и Masai School сместились на профессиональное обучение, избегая K-12 (школьников). 4) Системные последствия - Ответственность основателей: дело Равендрана стимулировало реформы Закона о компаниях. - Зрелость сектора: доля edtech на индийском рынке образования ($180 млрд) упала до 3,8% (с 6,2% в 2022 г.). В итоге, крах этого единорога индийского рынка показывает как погоня за ростом оценки, рискованные ставки на приобретение компаний, непрофессиональный менеджмент и культ личности мешают устойчивому росту компании. Хотя компания дала доступ к образованию миллионам, ее управленческие и финансовые провалы подорвали доверие. Будущее индийского edtech зависит от сбалансированного роста, этичных практик и ориентации на образовательные результаты, а не рыночную шумиху. P.S. Кажется, что российские edtech компании тоже после ковида подсдулись, хотя и не так ярко, как BYJU's. #Edu #SelfDevelopment #Management #Leadership #Processes

Обложки книг "The learning trap. How Byju's took Indian edtech for a ride" и "Ловушка обучения"

[1/2] The learning trap. How Byju's took Indian edtech for a ride (Ловушка обучения) (Рубрика #Management) С большим интересом я прочитал эту книгу осени 2023 года, в которой подробно рассказано о махинациях гиганта индийского edtech сектора Byju's. Если говорить про саму компанию, то когда-то оценка компании составляла 22 млрд долларов, а сейчас она буквально ничего не стоит. Отдельно отмечу потерянную игру слов в английском названии книги - основное приложение BYJU's называлось "The Learning App", а автор в своем названии обыграл это через "The learning trap" и получилось очень точно и красиво. Книгу написал журналист Прадип Сахи, который задавал вопросы по поводу бизнес-модели компании и когда она была на коне, но когда начались проблемы он решил оформить свое журналисткое расследование в остросюжетную книгу. Здесь Прадип раскрывает агрессивные маркетинговые тактики, корпоративные провалы и финансовые махинации под руководством основателя Биджу Равендрана, чья империя рухнула из-за обвинений в мошенничестве, неустойчивой бизнес-модели и токсичной корпоративной культуры. К 2025 году BYJU'S столкнулась с процедурой банкротства, потерей 95% стоимости и судебными исками в Индии и США, став поворотным моментом для всего сектора. Последствия включают скептицизм инвесторов, усиление регуляторного контроля и переоценку гиперроста. Основные моменты истории отмечены ниже 1) BYJU'S когда-то начиналась с офлайн-репетиторства Равендрана в Керале, которое к 2015 году трансформировалось в цифровую платформу. Компания использовала пробелы индийской системы образования, позиционируя себя как инструмент для «средних учеников». Пандемический спрос на онлайн-обучение подстегнул рост: в 2020–2022 гг. BYJU'S поглотила конкурентов, включая Aakash Educational Services ($1 млрд), Epic! ($500 млн) и Great Learning ($600 млн). 2) Стратегия компании основывалась на страхе упустить возможность (FOMO) получения хорошего образования, практиковались следующие вещи - Хищнический маркетинг: запугивание родителей обещаниями гарантированных результатов с участием звезд (например, Шахрукх Кхана или Леонель Месси) - Манипуляции метриками: завышение числа подписок через «самопокупки» сотрудников и быстрые возвраты средств. - Культ личности: харизма Равендрана маскировала операционные проблемы, а его выступления сравниваются с «религиозными проповедями». 3) В компании не было профессионального менеджмента и управления финансами - Безответственное лидерство: Равендран игнорировал совет директоров, единолично одобряя сделки, включая кредит $1,2 млрд в 2021 г. - Творческий учет: задержка отчетности за 2022 финансовый год скрыла рост убытков на 81%, аудированная отчетность задерживалась на годы, аудиторы публично отказывались от работы с BYJU's - Токсичная культура: сотрудники отдела продаж сталкивались с нереальными целями, что привело к массовым увольнениям и психическим расстройствам. Продолжение рассказа в следующем посте. #Edu #SelfDevelopment #Management #Leadership #Processes

Andrew Ng Explores The Rise Of AI Agents And Agentic Reasoning | BUILD 2024 Keynote (Рубрика #AI) Три месяца назад Andrew Ng выступал с keynote докладом про AI Agents и агенсткие размышления. Мне доклад понравился и я решил поделиться саммари с основными мыслями 1) AI как трансформационная технология Эндрю сравнивает AI с "новым электричеством", подчеркивая его потенциал для создания прорывных приложений. Основной фокус смещается к прикладному уровню, где генерируется основная ценность, благодаря возможности быстрого прототипирования (создание MVP за дни вместо месяцев). 2) Эволюция стек-технологий ИИ Выделены три слоя: - Инфраструктура - полупроводники, облачные платформы - Базовые модели - trainings, foundation models - Application слой - быстрорастущий сегмент с примерами вроде чат-ботов и автоматизированных рабочих процессов 3) Gen AI как катализатор Создание приложений с AI возможностями в некоторых случаях ускорилось в 100 раз: создание приложений типа распознавания речи или анализа изображений теперь занимает 3 дня вместо года. Ключевой вызов - оценка эффективности моделей, где внедряются параллельное тестирование и автоматизированные циклы обратной связи. 4) Агентские рабочие процессы — новая парадигма Представлены 4 шаблона проектирования: - Reflecation: Итеративное улучшение кода через автоматизированную критику (пример: генерация Python-скрипта с проверкой юнит-тестами). - Tool use (API calls): Интеграция с внешними сервисами (возврат платежей, отправка email). - Planning (decide on steps for task): Последовательное выполнение сложных задач (генерация изображения → анализ позы → коррекция). - Multi-agent collaboration: Коллаборация специализированных агентов (аналитик + дизайнер + тестировщик). 5) Vision Agent - кейс применения Платформа Landing AI демонстрирует: - Автоматическую индексацию видео с выделением ключевых кадров (пример: поиск "лыжник в воздухе" среди 10 часов записи). - Распознавание контекста: Поиск объектов по сложным описаниям ("черный чемодан с царапиной у ручки"). - Генерацию метаданных для тренировки custom-моделей. 6) Тренды будущего - Революция в обработке изображений/видео по аналогии с текстовым ИИ. - Рост мультимодальных агентов, способных комбинировать текст, изображения и API-вызовы. - Смена парадигмы разработки: смещение от hand-coded алгоритмов к оркестровке автономных агентов. В заключении своего рассказа Эндрю призывает разработчиков экспериментировать с агентскими фреймворками, прогнозируя взрывной рост приложений в компьютерном зрении и мультимедийной аналитике. Ключевой месседж: "Сейчас лучшее время создавать ИИ-продукты, где 90% работы выполняют агенты, а люди фокусируются на высокоуровневом дизайне". #AI #ML #Engineering #Software #Architecture #SystemDesign #DistributedSystems

[2/4] What Improves Developer Productivity at Google? Code Quality. (Рубрика #DevEx) Продолжим рассмотрение статьи про developer productivity обсуждение проблем опросов, которые часто используются для ответов на вопросы о продуктивности. Представим опрос про связь самооценки продуктивности инженеров и воспринимаемого уровня качества кода. Даже получив результаты опросы, у нас эффекты, что мешают вывести причинно-следственную связь между качеством кода и продуктивностью 1) Time-invariant effects - эти эффекты имеют тот же самый эффект в разные моменты времени, например, уровень образования респондентов 2) Respondent-independent time effects - это эффекты, которые влияют на респондентов одинаково, например, сезонные эффекты или крупные инициативы на всю компанию 3) Non-differentiated response effects - это эффекты, когда респонденты склонны давать одинаковый ответ на все вопросы. У одного респондента это может быть средний вариант ответа на все вопросы, а у другого самый высокий. Но в панельном исследовании есть возможность устранить эти эффекты, анализируя данные за разные промежутки времени, а также есть возможность попробовать установить не только корреляции, но и причинно-следственные связи. Дальше авторы описывают связанные научные работы и показывают как обычно использовались time-series данные и что их можно использовать для ответов на часть вопросов, изначально поставленных в исследовании. Правда, эти эти способы не использовались раньше для анализа developer productivity, а также они не подходят для того типа данных, что используют авторы этого исследования. Дальше авторы переходят к рассказу о методах панельного исследования, где в качестве источников данных используются 1) Данные из логов использования внутренних инструментов, навроде, данных о редактировании файлов, билдах, работе в системе codee review и так далее. Важно отметить, что эти данные содержат хорошо гранулированную историю о работе инженеров, что точно измерять поведение инженеров и характеризовать используемые ими рабочие практики и задачи, которые они выполняют при этом. 2) Данные лонгитюдных исследований (опросов), которые проводятся посредством EngSat (engineering satisfaction survery). Это долговременные исследования в виде опросов, ответы на которые собираются каждый квартал у трети инженеров. Подробнее про них в отдельном whitepaper "Measuring Developer Experience With a Longitudinal Survey", про который я уже рассказывал. Дальше описываются зависимые и независимые переменные, которые используются в модели исследования и объясняется как мы строим модель, чтобы ее можно было ответить на изначальные вопросы исследования. В качестве зависимых переменных используются самооценки продуктивности инженеров, которые взяты из опросов. С одной стороны именно эту переменную исследовали в других исследованиях и выявили некоторую корреляцию между субъективным и объективными исследованиями. В качестве объективных метрик были взяты следующие три категории метрик 1) The amount of output (per quater) - тут было 2 метрики: total number of changelists и total lines of code 2) The amount of time per item (changelist) - тут было 2 метрики: median active coding time, median well-clock coding 3) The amount of time for non-productive activities - тут было 2 метрики: median wall-clock review time и median wall-clock merge time Для анализа авторы собрали данные 6 последовательных кварталов с 2018Q1 по 2019Q2. Для анализа у исследователей накопилось порядка 2к точекк и дальше они построили модельку, что на рандомно выбранных 10% данных для валидации получили 83% precision и 99% recall. Причем основным предиктивным фактором оказался Median Active Coding TIme, что кажется логичным. На этом этот пост заканчивается, а в следующий раз я расскажу про независимые переменные и модельку целиком. #Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

Beyond the Hype: A Realistic Look at Large Language Models • Jodie Burchell • GOTO 2024 Джоди Берчилл, developer advocate в JetBrains, в своем выступлении в середине 2024 года представила реалистичный взгляд на большие языковые модели (LLM), их развитие, возможности и ограничения. Она стремилась развеять ажиотаж вокруг LLM и представить сбалансированное понимание их применения. 1. История и развитие LLM - LLM являются частью долгой истории исследований в области обработки естественного языка (NLP), начиная с автоматизации текстовых задач, таких как классификация и обобщение текстов - Прорывы в технологиях, такие как CUDA (для обучения нейронных сетей на графических процессорах) и доступ к большим наборам данных (например, Common Crawl), позволили создать более мощные модели. - Важным этапом стали сети с LSTM (Long short-term memory), появившиеся в середине 2000х годов, которые улучшили обработку контекста, но их ограничения привели к созданию трансформеров. 2. Модели-трансформеры и GPT - Трансформеры заменили последовательную обработку текста на параллельную, что сделало их более эффективными для NLP. - Генеративные предварительно обученные трансформеры (GPT) стали основой современных моделей. - С момента выхода GPT-1 до GPT-4 наблюдается значительное улучшение качества генерации текста: -- GPT-1 создавал грамматически правильный текст без контекста. -- GPT-3 начал учитывать контекст и кодировать языковую информацию. -- GPT-4 достиг 1 триллиона параметров и стал более универсальным. 3. Возможности и ограничения LLM LLM демонстрируют впечатляющие результаты в задачах NLP, таких как перевод, суммирование текста и ответы на вопросы. Однако они остаются ограниченными: - Модели могут запоминать обучающие данные вместо обобщения. - Их способность решать новые задачи зависит от уровня обобщения: -- Локальное обобщение: работа с похожими примерами. -- Широкое обобщение: решение задач в разных областях. -- Крайнее обобщение: выход за рамки человеческих возможностей (недостижимо для текущих моделей). - Проблема оценки интеллекта моделей связана с фокусом на навыках, а не на базовых способностях. 4. Применение и практические примеры Джоди продемонстрировала использование LLM для извлечения информации из баз данных с помощью подхода RAG (поисковая расширенная генерация): - Разделение документов на части, создание вложений и сохранение их в векторной базе данных. - Преобразование запросов во вложения для поиска релевантных данных. - Создание приложений для ответов на вопросы с помощью инструментов вроде LangChain. Пример: поиск информации в документации PyCharm с использованием модели ChatGPT. Про RAG отдельно интересно почиать статью "Emerging Patterns in Building GenAI Products", про которую я рассказывал раньше 5. Оценка производительности и выбор модели Эффективность моделей зависит от предметной области и варианта использования. Для сложных задач может потребоваться настройка модели или создание специализированных наборов данных, а таблицы лидеров, такие как Huggingface, помогают сравнивать производительность моделей. 6. Ограничения и перспективы Несмотря на успехи, LLM не достигли уровня искусственного общего интеллекта (AGI). Они требуют тщательной настройки, выбора задачи и оценки производительности. Джоди подчеркнула важность реалистичного подхода к ожиданиям от LLM, сравнив текущие проблемы с теми, что существуют в разработке ПО и машинном обучении десятилетиями. Таким образом, выступление Джоди Берчилл акцентировало внимание на необходимости трезвой оценки возможностей LLM, их ограничений и практического применения. #AI #ML #Engineering #Software #Architecture #SystemDesign #DistributedSystems

Oscar, an open-source contributor agent architecture (Рубрика #AI) Oscar - это интересный проект от Google про применение LLM-агентов в программировании. Правда, ребята ставят себе целью не генерацию кода, а скорее устранение рутинной работы по поддержанию крупного open source проекта. Суть в том, что написание кода является интересной частью создания софта, а вот обработка входящих issues, сопоставление вопросов с существующей документацией или проверка reports - это все неинтересная часть работы и ее хорошо было бы автоматизировать. Сам проект Oscar является сейчас экспериментом и частью проекта golang, но в будущем может стать отдельным проектом. Изначальной целью было

- Reduce maintainer effort to resolve issues [note that resolve does not always mean fix] - Reduce maintainer effort to resolve change lists (CLs) or pull requests (PRs) [note that resolve does not always mean submit/merge] - Reduce maintainer effort to resolve forum questions - Enable more people to become productive maintainers

Для решения этих задач авторы решили, что у Oscar должно быть три ключевых вощможности 1) Индексирование и отображение связанного контекста проекта во время взаимодействия участников. 2) Использование естественного языка для управления детерминированными инструментами. 3) Анализ отчетов о проблемах, Change list / Pull requests и групповых обсуждений для их улучшения в режиме реального времени во время или вскоре после отправки, а также для их соответствующей маркировки и маршрутизации отчетов В общем, подход авторов состоит в том, чтобы использовать LLM в том, в чем они сильны, а точнее в семантическом анализе естественного языка и его трансформации в вызовы детерминистического кода для выполнения остальной работы. 1) Индексирование и отображение связанного контекста проекта Здесь авторы предлагают использовать embeddings и векторые базы данных для индексирования и поиска релевантной информации. Примерно об этом рассказывалось и в других документах: статье Фаулера"Emerging Patterns in Building GenAI Products" (мой краткий рассказ здесь) и Whitepaper "Agents" by Google (мой рассказ здесь). Авторы проекта Oscar отмечают следующие плюсы использование агентов - The agent surfaces related context to contributors - контрибьюторам сообщается о похожих проблемах, что позволяет не дублировать проблемы - The agent surfaces related context even to project maintainers - мейнтейнерам бывает полезно увидеть похожие баги и собрать более точную информацию, что позволяет правильно выставить приоритет, закрыть или переоткрыть баг - The agent interacts with bug reporters immediately - немедленная обратная связь тому, кто зарепортил баг, позволяет собрать больше релевантной информации, так как reporterts готов предоставить доп. информацию в моменте или глубже исследовать проблемное поведение, если его попросить об этом сразу 2) Using natural language to control deterministic tools Здесь авторы бота оставили точку для расширения, но пока не интегрировали это в бот. Но, по-факту, тут описывается использование tools из фреймворка про агентов, описанного в whitepaper "Agents", про который я уже писал. Например, тут может быть фикс текста репорта или предложение как его пофиксить. Например, вот тут есть whitepaper от ребят из Google "Evaluating Agent-based Program Repair at Google". 3) Analyzing issue reports and CLs/PRs Здесь авторы опять оставили точку расширения под действия навроде проставления правильного label для issue или проверки правильного заполнения отчета об ошибке. В принципе, тут все достаточно понятно. Внутри go коммьюнити Oscar представлен в виде бота Gaby ("Go AI bot"), который работает с новыми issues. Интересно, что внутри go коммьюнити есть gopherbot, но он основан на коде, который детермистическом реагирует на команды. #AI #ML #Engineering #Software #Architecture #SystemDesign #DistributedSystems

Code of Leadership #30 - Interview with Vadim Goncharov about T-Bank and management approaches (Рубрика #Management) В этом выпуске подкаста ко мне опять пришел Вадим Гончаров, мой коллега, с которым мы обсудили его путь в Т-Банке. Вадим в веб-разработке больше 15 лет. В 2008 руководил собственной веб-студией. С 2013 работал в VK, а в 2017 присоединился к Т-Банку, где в качестве технического руководителя запускал самое крупное медиа про деньги в России: Т—Ж. А с 2020 Вадим года руководит разработкой интерактивных спецпроектов и игр в мобильном приложении Т-Банка. Он проповедует lifelong learning: закончил МИЭМ, учился в Британке и Вышке, а сейчас учится в Сколково на программе МБА. Этот выпуск продолжает "Code of Leadership #28", где мы обсудили работу Вадима до Т-Банка, а также важность дизайна в разработке. Ну а здесь мы говорили про - Появление Вадима в Т - Работа в Т-Журнале и улучшение финансовой грамотности населения и бренда - Переход к руководству людьми и проблемы выгорания и делегирования - Спецпроекты в Т-Банке - Игры и их развитие в экосистеме Т - Использование моделей управления (DISC, PSM, Hogan) - Образование и постоянное развитие как залог карьерного и личностного роста Эпизод доступен в Youtube, VK Video, Podster.fm, Ya Music. #Management #Leadership #Software #Processes #Retrospective #Design #Processes #SelfDevelopment

Whitepaper "Agents" by Google (Рубрика #AI) На выходных прочел интересный whitepaper на тему агентов от ребят из Google (Julia Wiesinger, Patrick Marlow, Vladimir Vuskovic). В этой статье они описывают фреймвор для создания AI агентов, что способны к автономному принятию решения и взаимодействию с реальным миром. Для этого они описывают как такие системы могут объединять когнитивную архитектуру с LLM моделями, что позволяет обойти ограничения последних. Эта статья напоминает по подходу "Emerging Patterns in Building GenAI Products", про которую я рассказывал раньше. Но статья "Emerging ..." совсем про базу (прямой вызов LLM, prompt engineering, RAG), а эта уже про агентов. Авторы специализируются на AI инфраструктуре и когнитивной архитектуре, а точнее Julia Wiesinger на обучении агентских систем, Patrick Marlow на иструментах оркестрации, Vladimir Vuskovic на децентрализованных AI системах. Их работа основана на развитии LLM и агентских workflow, а также презентует Google’s Vertex AI как foundational платформу для разворачивания таких систем, поэтому во всех примерах она активно используется. Вообще, ребята в Google определяют агентов как

An autonomous system that observes its environment, reasons about goals, and takes actions using tools to achieve outcomes

Здесь важно, что агент - Наблюдает за окружением через сенсоры - Формирует внутреннее состояние через рассуждения - Выбирает действия через планировщик с использованием инструментов (API, функции, базы данных) В этом определении фокус не на статических LLM моделях, а на динамическом взаимодействии с внешними данными и инструментами. Вообше, архитектура представляет 1) The model - LLM как центральный процессор для chain-of-thought reasoning; 2) The tools - соединяет агентов с реальным миром через тройку - Extensions - интеграция с API, исполнение на строне агента - Functions - генерация кода для исполнения, что выполнеяется на стороне клиента, что вызывает агента - Data stores - работа с базами данных, которые обычно бывают векторными и для поиска используются embeddings 3) The orchestration layer - управление итеративным размышлением с использованием подходов вида - ReAct - Reasoning + Acting - CoT - Chain of Thoughts - ToT - Tree-of-Thoughts Сами агенты могут использовать три стратегии обучения - In-context learning: адптация в реальном времени с использованием промпта и примеров в нем - Retrieval-based learning: динамичепский доступ к внешней памяти для принятие решений с дополнительным контекстом - Fine-tuning: специфичное для домена до-обучение (pre-training) для оптимизации во время использования в этом домене Агенты могут работать независимо, проактивно планируя свои шаги для достижения целей без постоянного привлечения людей. Например, они могут приоритизировать задачи, подстраивать свою стратегию на основе обратной связи от окружения, а также восстанавливаться от ошибок. У Google есть проект с открытым исходным кодом "Project Oscar" для созданиия агентов для SDLC. Его интересно изучить, так как он фокусируется не на написании кода (что является веселой частью этой работы), а для скучных частей

Oscar is a project aiming to improve open-source software development by creating automated help, or “agents,” for open-source maintenance. We believe there are many opportunities to reduce the amount of toil involved with maintaining open-source projects both large and small.

Если говорить про будущее агентов, то - Агенты будут независимо управлять вычислительными ресурсами, что сможет снизить зависимость от централизированных платформ - Агенты смогут в коллаборации решать более сложные проблемы - Для агентов будут важны вопросы безопасности, чтобы сложнее было эксплуатировать уязвимости API или получать неправомерный доступ к данным в data stores В итоге, это хороший базовый whitepaper на тему построения агентских систем. #AI #ML #Engineering #Software #Architecture #SystemDesign #DistributedSystems

Манюня: День рождения Ба (Рубрика #Kids) В прошлые выходные мы были с детишками на только что вышедшем фильме "Манюня: День рождения Ба", который основан на книгах Наринэ Абгарян, про которые я уже писал. Картина отлично передает атмосферу книги и сочетает в себе ностальгию по детским приключениям, семейные ценности и тонкий юмор. Основой для фильма послужила повесть Наринэ Абгарян «Манюня, юбилей Ба и прочие треволнения» — заключительная часть серии о приключениях трех подруг. Абгарян, известная своими автобиографическими историями, вложила в сценарий личные воспоминания о детстве в армянском городке. Её участие в написании сценария (совместно с Нарой Акобян и Гайком Асатряном) обеспечило экранизации близость к первоисточнику. Например, эпизоды с побегом барана или испорченным тортом напрямую отсылают к книжным описаниям, подчеркивая хаотичное очарование деревенской жизни. Важным элементом стала тема взросления. Если в первых фильмах франшизы акцент делался на шалостях героинь, то в финальной части режиссер и сценаристы исследуют их эмоциональные конфликты. Сцена ссоры Наринэ и Манюни из-за предстоящего переезда последней отражает страх потерять дружбу — мотив, который Абгарян раскрывает через метафору кошмара Наринэ. В общем, фильм интересно смотреть - в нем есть примеры сложных ситуаций, но нет излишнего морализаторства. Несмотря на скромный бюджет, фильм демонстрирует, что семейное кино может быть одновременно смешным, трогательным и глубоким. Правда, в некоторых сценах видно, что бюджет был сильно ограничен, поэтому, например, за побегом барана мы следим скорее по реакции главных героев, а не по действиям самого барана:) #ForKids #ForParents #Humor

Jeff Dean & Noam Shazeer – 25 years at Google: from PageRank to AGI (Рубрика #AI) Интересное интервью двух легендарных инженеров Google раскрывает трансформацию компании от стартапа до лидера в области искусственного интеллекта. Джефф Дин и Ноам Шазир, проработавшие в корпорации суммарно почти 50 лет, поделились инсайтами о технологической эволюции, текущих проектах и будущем AI. Эволюция Google и личный опыт Рост компании от 25 сотрудников до технологического гиганта сопровождался сменой парадигмы управления. Дин вспоминает этапы: от личного знакомства со всеми коллегами до системы управления через проектные метрики. Шазир подчеркивает уникальность ранней культуры Google, где он начинал под менторством самого Дина, разрабатывавшего базовую инфраструктуру компании. Интересно, что Ноам дважды покидал компанию (с разницей примерно в 12 лет), что стало внутренней шуткой. Его последнее возвращение стоило корпорации $2.7 млрд по условиям сделки с Character.AI. Развитие ИИ-технологий Основное внимание в интервью уделено проекту Gemini — флагманской системе AI Google. Разработчики раскрывают три ключевых аспекта: - Архитектурные инновации: переход от монолитных моделей к модульной системе с асинхронным обновлением компонентов. Это позволяет улучшать отдельные модули без полного переобучения системы. - Контекстное окно: работа над расширением до триллионов токенов, что во много раз превосходит текущие показатели. Эксперименты показывают, что модели с увеличенным контекстом демонстрируют элементы долгосрочного планирования. - Экономика вычислений: стоимость ИИ-операций снижена в 100 раз по сравнению с чтением электронной книги и в миллион раз относительно найма разработчика. Это достигнуто за счёт новых TPU 5-го поколения, оптимизированных именно для inference. Практическое применение 25% кода Google уже генерируется ИИ через специальную версию Gemini, обученную на внутренней кодовой базе. Внедрена система MENA — корпоративный чат-бот, предшественник ChatGPT, используемый сотрудниками с 2021 года. Шазир отмечает парадокс: несмотря на публичную сдержанность, Google десятилетиями инвестирует в ИИ, начиная с пионерских работ по статистическому машинному переводу и спелл-чекингу на основе веб-индекса ещё в 2000-х. Будущие направления - "Органические" архитектуры: разработка систем с самоадаптацией, где разные модули специализируются на конкретных задачах (язык, код, планирование). - Мультиагентные системы: управление тысячами параллельных агентов с персонализацией через интеграцию персональных данных (email, документы, метрики здоровья). Аппаратные инновации: проектирование чипов, где ИИ автоматизирует 80% процесса разработки, сокращая цикл с 3 лет до 9 месяцев. Инженеры скептически относятся к "магии больших данных", делая акцент на системном подходе: успех современных моделей - результат синергии алгоритмов, архитектуры и аппаратной оптимизации. Дин подводит итог интерью отмечая, что мы находимся в начале новой эры, где AI станет расширением человеческого интеллекта, а не его заменой #AI #Engineering #Software #History #Management #Architecture

Без воды. Как писать предложения и отчеты для первых лиц (Рубрика #Management) Недавно я прочитал эту небольшую книгу Павла Безручко и она показалась мне полезной. Но сначала отмечу, что автор, управляющий партнер "ЭКОПСИ Консалтинн" и практикующий бизнес-консультант, которым приходится писать много отчетов и для топ-менеджеров в том числе. В какой-то момент он решил написать книгу про то, как лаконично доносить свои идеи до топ-менеджеров и такая книга вышла в 2013 году. Я добрался до нее только сейчас и меня заинтересовало содержание, которое основано на использовании принципов 1) Психологический портрет адресата Первые лица компаний, по наблюдениям Безручко, обладают «туннельным мышлением» — фокусируются только на данных, напрямую влияющих на ключевые показатели бизнеса. Автор рекомендует перед написанием документа четко определить: - Какую именно KPI затронет предложение - Какие финансовые/репутационные риски оно нивелирует - Какой управленческий ресурс потребует 2) Инвертированная структура документа Не от проблемы к решению, а от выводов а дальше к их подкреплению - Рекомендуемое действие (с указанием сроков и ответственных) - Альтернативные варианты с оценкой рисков - Подробные расчеты/аргументы в приложении Мне кажется, что применимость этого подхода зависит от культуры - условно, в "The Culutre Map", о которой я рассказывал, есть примеры, когда в некоторых культурах такая инверсия не работает 3) Работа с текстом, чтобы добиться лаконичности (когда уже нечего убавить) - Удаление в первый проход всех прилагательных, общих фраз, повторяющихся тезисов - Замена сложных конструкций на глаголы действия («оптимизировать» вместо «осуществить процесс оптимизации») Здесь может помочь LLM-ассистенты от Perplexity, OpenAI, Google и так далее И тут возникает вопрос, а может быть книга совсем устарела в век Gen AI? Мне кажется, то не совсем, так как - Для предложений важно понимание контекста, а AI пока не может адекватно оценивать корпоративную культуру и неформальные отношения в руководстве, которые критичны для принятия решений - Gen AI ассистенты генерят текст, что похож на рекомендации, но у решений обычно бывают последствия от их внедрения, которые Gen AI может не учитывать, а автор в этой книге делает фокус на учете вторичных эффектов принятия управленческих решений - Книга учит не просто сокращать текст, но и предугадывать когнитивные искажения руководителей, что опять же сложно учесть Gen AI ассистентам, так как у них нет контекста. В итоге, я вижу плюсы в прочтении этой книги, одновременно я понимаю как можно зная методику автора использовать ассистентов более эффективно для подготовки коммуникаций под целевую аудиторию. Условно я могут правильнее написать промпт, который мой длинный текст суммаризирует в нужный формат и дальше я его напильником немного подправлю:) #Writing #Management #Leadership #Storytelling

Majorana 1 Explained: The Path to a Million Qubits (Рубрика #PopScience) Интересное видео от Microsoft про квантовые вычисления и их прорыв в этой области. Вообщем, квантовые вычисления с нами уже давно, но обычно это здоровенная сильно охлажденная штука в которой несколько десятков кубитов (квантовых битов). А тут ребята из Microsoft рассказывают, что они 17 лет исследовали исследовали и наисследовали новый материал, что помогает организовать топологические кубиты (надо будет отдельно изучить что это и как работает). Этот материал позволяет получить миллион топологических кубитов при комнатной температуре, но пока получено всего восемь. Но это proof of concept, где мы получили 2^3, а обещают, что будет 2^20. Всего лишь надо от 3 до 20 дойти в степени двойки:) Но если вернуться к тому, а почему все так ждали квантовый компьютер, то такие вычисления в перспективе позволят гораздо проще моделировать поведение субатомных частиц, что очень хорошо повлияет на материаловедение, создание новых лекарств и так далее. В общем, на все те области, что сейчас слишком сложно точно считать на классических компьютерах с архитектурой фон Неймана. Отдельно интересно почитать биографию ученого, в честь которого назван чит. Этторе Майорана был гениальным физиком-теоретиком, что публиковал работы в 30-е годы и предсказал существование особого типа фермионов, которые являются своей собственной античастицей. А лет 15 назад физики наметили путь реализации этих частиц на практике, дальше прошло еще сколько-то лет и Microsoft выпустило этот чип Majorana 1. Интересно, что сам Этторе не стремился к славе - он пропал без вести в 1938 году, но есть документальные подвтерждения, что с 1955 до 1959 он жил в Вэнесуэле, а потом его следы потерялись. #PopularScience #Physics #Math #Engineering #Software

[1/3] What Improves Developer Productivity at Google? Code Quality. (Рубрика #DevEx) Наконец-то я дочитал и написал разбор этого whitepaper 2022 года, что пролежал распечатанным на моем столе около года. Не могу сказать, что заставило меня остановиться при первом прочтении на полпути, возможно это 16 страниц убористого шрифта, а возможно наличие целых 40 параметров анализа того, что влияет на продуктивность инженеров, но я с этим справился:) Оказалось, что треть этих страниц - это аппендиксы, а из 40 параметров авторы выделили целых 6, что оказались статзначимы и сильно влияли на продуктивность. В условиях Google эти пять параметров такие: code quality, technical debt, infra tools & support, team communications, goals & priorities, org change & process. Собственно, первое место заняло code quality, поэтому его проанализировали поглубже и вынесли в название статьи. Если говорить про статью в общем, то она очень интересная и если вы планируете исследовать тему developer productivity у себя в компании, то очень рекомендую изучить эту статью, так как авторы рассказывают в деталях о методологии, пишут формулы и проводят анализ того, что может нарушить валидность модели (этого часто не хватает во многих других исследованиях, что попроще). Ну а теперь двинемся внутрь статьи и начинается она с того, что организации хотят максимирзировать продуктивность разработки софта, а точнее делать лучший софт за максимальное короткое время. На этот вопрос можно смотреть с разных сторон, но вопрос индивидуальной продуктивности инженеров по мнению авторов является плодотворным Статья начинается с постановки research вопроса

What causes improvements to developer productivity in practice?

который для меня кажется похожим н классические вопросы "Кто виноват" и "Что делать" Авторы делают обзор предыдущих исследований на эту тему, но делают вывод, что 1) Из контролируемых экспериментов можно понять причинно-следственные связи, но не ясно будут ли они воспроизводиться на рабочем месте. Эти эксперименты обычно ставятся в таких условиях, когда экспериментаторы привлекают студентов или даже опытных специалистов и устраивают им аля лабораторные работы, навроде, дебаггинга новым инструментом по сравнению со старым. 2) Полевые исследования могут дать валидные наблюдения в контексте организации, но их сложно обобщить, а также есть проблемы с определением не просто корреляций, а причинно-следственных связей. Основной вклад этой статьи в исследования продуктивности - возможность получить более строгий вывод о факторах, что причинно-следственно влияют на продуктивность инженеров. Для этого авторы решают использовать подход под названием "panel data analysis" (панельное исследование). Если объяснять на пальцах, то в таких исследованиях данные собираются за определённое время у одних и тех же групп людей или индивидов, а затем проводится регрессия. То есть в широком смысле панельное исследование - это синоним лонгитюдного исследования. Стандартным форматом для проведения исследований продуктивности является использование cross-sectional data (перекрёстных данных). Если объяснять на пальцах, то в таких исследованиях данные собираются путём наблюдения за объектами в один и тот же период времени. Обычно это проще всего сделать, бахнув опрос, но тут есть проблемки. А про них мы поговорим в следующей части обзора. #Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

Финансовые результаты МКПАО "Яндекс" за 2024 год (Рубрика #Management) Сегодня Яндекс опубликовал свои показатели за Q4 и за весь 2024 год, а также прогнозы по вырчке и прибыли на 2025 год. Что можно сказать интересного про группу компаний - Все показатели на инфографике подросли (если бы не подросли, то их бы не было на инфографике) - Бизнес-направления агрегируют внутри сервисы, чтобы показывать благополучение направлений в общем, по крайней мере с точки зрения роста - Проникновение сервисов значительное, поиск 110 млн, go - 53.2 млн, плюс - 39.2 млн - На инфографике не слишком ясно кто из бизнес-линий является донором денег, а кто реципиентом (и тратит их в качестве инвестиций для развития направления). Условно реклама-поиск зарабатывают и делятся с райдтехом, автономными технологиями, а яндекс плюс как бы связывает экосистему и ARPU вроде не покрывает затраты на оригинальныый контект и лицензионные платежи В общем, думаю, что интересно не только взгянуть на инфографику, но и почитать подробный отчет - можно в качестве снотворного перед сном:) #Economics #Engineering

Карта мира (Рубрика #Stories) В прошлом декабре у моей жены был очередной день рождения и я думал над подарком. Сегодня подарок наконец-то дошел до целевого состояния на стене кухни:) А дело было так. Мой сумрачный гений в декабре решил, что надо подарить карту мира в виде слоеного пазла из дерева разных цветов, так как жена у меня любит путешествовать. Школа мысли была примерно такой, что, смотря на карту, можно планировать новые путешествия или вспоминать о тех, что уже были. Но при вручении подарка я не увидел энтузиазма в глазах и мне объяснили, что планирование - это не весело, а весело в путешествии попасть в новую страну, пообщаться с новыми людьми и побывать в теплом климате. Как можно понять, ничего из этого деревянная карта два на полтора метра на стене не дает. Так я отложил сбор карты до момента, когда мы вернулись со Шри-Ланки. В январе я собрал ее за пару тройку вечеров и отложил из-за того, что мы с младшим сыном попали в больницу. Когда я вышел, то решил наконец-то повесить карту на стену, но пришлось выдержать битву с женой и освободить стену на кухне от больших круглых часов для начала. Потом я взял двухсторонний скотч из комплекта, что шел с набором и поклеил его на все 50+ частей и успокоился ... Мы уехали с детьми в театр или кино, а когда вернулись, то все элементы карты оказались на полу - двухсторонний скотч не выдержал. Мне пришлось собирать все части карты, отдельно замечая отлетевшие элементы, чтобы потом их починить. Дальше мы заказали проверенный мощный скотч и только вчера вечером я заново поклеил карту на стену и презентовал ее жене со словами, что это очень дорогой подарок, если учитывать сколько туда вложено моих усилий. Заодно я показал, что могу работать руками, хотя подарок от Лемана Тех я тут совсем не использовал:) #Stories

Emerging Patterns in Building GenAI Products (Рубрика #AI) Интересная статья от Мартина Фаулера и Bharani Subramaniam, в которой ребята рассказывают в формате паттернов про базовые кубики, из которых строятся GenAI приложения. Эта статья характерна для текущего Фаулера - в ней нет совсем ничего нового, но достаточно четко описано то, что уже известно на текущий момент:) Сейчас в списке паттернов присутствуют только те, что приведены ниже, но авторы обещают его постепенно пополнять. - Direct prompting - пропмптинг из приложения foundation LLM. Не уверен, что это тянет на паттерн, но авторы походу в этом уверены. Думаю, что это примерно как вызов функции назвать дизайн паттерном:) - Embeddings - здесь авторы рассказывают о переводе текста или картинки в вид многомерного вектора так, чтобы близкие по сути сущности были близки в этом многомерном пространстве. Метрика близости может быть разная, но часто это cosine similarity, когда мы смотрим насколько векторы соноправлены. В примере само преобразование текста в embedding происходит через вызов библиотечной функции. Суть в том, что эти embeddings нужны и самой LLM и их также можно дальше использовать для поиска по векторной базе данных. Рекомендую глянуть доклад "A Fun & Absurd Introduction to Vector Databases - Alexander Chatzizacharias - GOTO 2024", про который я рассказывал раньше - Evals - здесь авторы рассказывают про оценку ответов LLM в контексте конкретных задач. По-факту, это напоминает тестирование обычного софта, но со звездочкой. Звездочка обусловлена тем, что ответ LLM не детерминирован, а значит тестировать в лоб "запрос - ответ" не получится, а надо делать что-то типа нагрузочного тестирования, когда мы тестируем performance модели в плане семантики и точности ответа. Для этого нужны сценарии + ожидания от ответа + какой люфт мы разрещаем в отклонениях от этого ответа. - Hybrid retriever - здесь авторы рассказывают, что можно комбинировать ответы от векторной базы данных при поиске близких сущностей в плане embeddings с более каноническим поиском, условно, full text - Query rewriting - можно использовать LLM#2 для того, чтобы переписать промпт и дальше несколько его вариантов скормить LLM#1. Это в теории позволяет улучшить промпт, причем LLM#1 и LLM#2 могут быть как одной и той же LLM, так и разными. Например, LLM#2 может быть обучена делать хорошие промпты из плохих, а LLM#1 отвечать качественно на промпты - Reranker - При поиске данных может возвращаться много документов, а контекст моделей пока не резиновый, поэтому есть вариант отдельно отранжировать найденные документы и только нужные прокинуть в контекст запроса для LLM - Retrieval augmented Generation (RAG) - этот паттерн про то, что можно не просто просить LLM сгенерировать ответ, но и позволить ей сделать поиск информации, а дальше найденную информацию прокинуть в контекст запроса. В рамках этого паттерна мы можем использовать Hybrid retriever, Reranker, Query rewriting Про файнтюнинг моделей обещали написать в следующих сериях, возможно, потом допишут что-то и про агентов. В общем, статья полезна именно инженерам, чтобы понять базовые примитивы GenAI приложений. P.S. Про статью я узнал из канала @startup_architecture моего коллеги, Антона Скогорева, который является техдиром у нас в AI Центре. #AI #ML #Engineering #Software #Architecture #SystemDesign #DistributedSystems

#211 – The Architect && #280 – The Tech Stack and the Architect (Рубрика #Architecture) Продолжая вчерашнюю тему отрыва от земли и самопереноса части архитекторов в башню из слоновой кости, покажу пару историй из Comic Agile: 211 и 280. Мне кажется, что они отлично описывают как это выглядит. Интересно, что мы к себе таких не набираем, о чем была речь в шестом эпизоде подкаста "Code of Leadership". В этом выпуске мы вместе с Лешей обсуждали как выглядит матрица SDE (software development engineer), какие треки развития есть у инженеров, как выглядит процесс роста внутри и найм сотрудников снаружи. Также ближе к концу дискуссии мы обсуждаем один из этапов собеседований, который называется "Architecture & SDLC", который мы проводим для кандидатов на Staff+ уровень. Именно такие инженеры чаще всего исполняют роль архитекторов, что помогают с организацией архитектурных процессов и драйвят большие кросс-командные изменения. #Management #Software #Processes #Project #Engineering #Processes #Leadership #Staff #Architecture