Конфа по архитектуре в Лемана Тех (Рубрика #Architecture)
Сегодня я участвовал в панельной дискуссии на конфе по архитектуре в Лемана Тех (это ИТ компания бывшего Леруа), где мы обсуждали следующие вопросы
1. Управление архитектурными изменениями в быстро меняющемся мире
2. Сложные кейсы архитектуры: что делать, когда все не так, как должно быть?
3. Архитектурный репозиторий: как сделать его инструментом для всех?
4. Архитектор как посредник между бизнесом и ИТ: как говорить на одном языке?
5. Эффективное управление архитектурными изменениями: от идеи до внедрения
В дискуссии мы вспоминали много разных тем и конкретно книгу "The Software Architect Elevator" Gregor Hohpe, про которую я писал раньше. Суть была в том, что архитектору не стоит отрываться от земли и уходить в фантазии на N-том этаже своей башни, а стоит быть поблжие к земле и спускаться в машинный зал, где работают инженеры. Забавно, что после окончания конфы спикерам раздали подарки в сумке "Do it yourself", где были шуруповерты. В общем, я понял намек на то, что слова не должны расходиться с делами и обязательно воспользуюсь этим инструментом:)
P.S.
Попробую запись мини-выпуск с ответами на эти вопросы, если они вам интересны. Только напишите об этом в комменатриях.
#Architecture #Software #Management #Leadership
Сегодня я участвовал в панельной дискуссии на конфе по архитектуре в Лемана Тех (это ИТ компания бывшего Леруа), где мы обсуждали следующие вопросы
1. Управление архитектурными изменениями в быстро меняющемся мире
2. Сложные кейсы архитектуры: что делать, когда все не так, как должно быть?
3. Архитектурный репозиторий: как сделать его инструментом для всех?
4. Архитектор как посредник между бизнесом и ИТ: как говорить на одном языке?
5. Эффективное управление архитектурными изменениями: от идеи до внедрения
В дискуссии мы вспоминали много разных тем и конкретно книгу "The Software Architect Elevator" Gregor Hohpe, про которую я писал раньше. Суть была в том, что архитектору не стоит отрываться от земли и уходить в фантазии на N-том этаже своей башни, а стоит быть поблжие к земле и спускаться в машинный зал, где работают инженеры. Забавно, что после окончания конфы спикерам раздали подарки в сумке "Do it yourself", где были шуруповерты. В общем, я понял намек на то, что слова не должны расходиться с делами и обязательно воспользуюсь этим инструментом:)
P.S.
Попробую запись мини-выпуск с ответами на эти вопросы, если они вам интересны. Только напишите об этом в комменатриях.
#Architecture #Software #Management #Leadership
❤19👍10🔥8🤣1
#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
Продолжая вчерашнюю тему отрыва от земли и самопереноса части архитекторов в башню из слоновой кости, покажу пару историй из Comic Agile: 211 и 280. Мне кажется, что они отлично описывают как это выглядит. Интересно, что мы к себе таких не набираем, о чем была речь в шестом эпизоде подкаста "Code of Leadership". В этом выпуске мы вместе с Лешей обсуждали как выглядит матрица SDE (software development engineer), какие треки развития есть у инженеров, как выглядит процесс роста внутри и найм сотрудников снаружи. Также ближе к концу дискуссии мы обсуждаем один из этапов собеседований, который называется "Architecture & SDLC", который мы проводим для кандидатов на Staff+ уровень. Именно такие инженеры чаще всего исполняют роль архитекторов, что помогают с организацией архитектурных процессов и драйвят большие кросс-командные изменения.
#Management #Software #Processes #Project #Engineering #Processes #Leadership #Staff #Architecture
😁4❤3🔥3
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
Интересная статья от Мартина Фаулера и 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
martinfowler.com
Emerging Patterns in Building GenAI Products
Patterns from our colleagues' work building with Generative AI
❤6👍6🔥2
Карта мира (Рубрика #Stories)
В прошлом декабре у моей жены был очередной день рождения и я думал над подарком. Сегодня подарок наконец-то дошел до целевого состояния на стене кухни:) А дело было так.
Мой сумрачный гений в декабре решил, что надо подарить карту мира в виде слоеного пазла из дерева разных цветов, так как жена у меня любит путешествовать. Школа мысли была примерно такой, что, смотря на карту, можно планировать новые путешествия или вспоминать о тех, что уже были. Но при вручении подарка я не увидел энтузиазма в глазах и мне объяснили, что планирование - это не весело, а весело в путешествии попасть в новую страну, пообщаться с новыми людьми и побывать в теплом климате. Как можно понять, ничего из этого деревянная карта два на полтора метра на стене не дает. Так я отложил сбор карты до момента, когда мы вернулись со Шри-Ланки. В январе я собрал ее за пару тройку вечеров и отложил из-за того, что мы с младшим сыном попали в больницу. Когда я вышел, то решил наконец-то повесить карту на стену, но пришлось выдержать битву с женой и освободить стену на кухне от больших круглых часов для начала. Потом я взял двухсторонний скотч из комплекта, что шел с набором и поклеил его на все 50+ частей и успокоился ... Мы уехали с детьми в театр или кино, а когда вернулись, то все элементы карты оказались на полу - двухсторонний скотч не выдержал. Мне пришлось собирать все части карты, отдельно замечая отлетевшие элементы, чтобы потом их починить. Дальше мы заказали проверенный мощный скотч и только вчера вечером я заново поклеил карту на стену и презентовал ее жене со словами, что это очень дорогой подарок, если учитывать сколько туда вложено моих усилий. Заодно я показал, что могу работать руками, хотя подарок от Лемана Тех я тут совсем не использовал:)
#Stories
В прошлом декабре у моей жены был очередной день рождения и я думал над подарком. Сегодня подарок наконец-то дошел до целевого состояния на стене кухни:) А дело было так.
Мой сумрачный гений в декабре решил, что надо подарить карту мира в виде слоеного пазла из дерева разных цветов, так как жена у меня любит путешествовать. Школа мысли была примерно такой, что, смотря на карту, можно планировать новые путешествия или вспоминать о тех, что уже были. Но при вручении подарка я не увидел энтузиазма в глазах и мне объяснили, что планирование - это не весело, а весело в путешествии попасть в новую страну, пообщаться с новыми людьми и побывать в теплом климате. Как можно понять, ничего из этого деревянная карта два на полтора метра на стене не дает. Так я отложил сбор карты до момента, когда мы вернулись со Шри-Ланки. В январе я собрал ее за пару тройку вечеров и отложил из-за того, что мы с младшим сыном попали в больницу. Когда я вышел, то решил наконец-то повесить карту на стену, но пришлось выдержать битву с женой и освободить стену на кухне от больших круглых часов для начала. Потом я взял двухсторонний скотч из комплекта, что шел с набором и поклеил его на все 50+ частей и успокоился ... Мы уехали с детьми в театр или кино, а когда вернулись, то все элементы карты оказались на полу - двухсторонний скотч не выдержал. Мне пришлось собирать все части карты, отдельно замечая отлетевшие элементы, чтобы потом их починить. Дальше мы заказали проверенный мощный скотч и только вчера вечером я заново поклеил карту на стену и презентовал ее жене со словами, что это очень дорогой подарок, если учитывать сколько туда вложено моих усилий. Заодно я показал, что могу работать руками, хотя подарок от Лемана Тех я тут совсем не использовал:)
#Stories
👍13❤7🔥6
Финансовые результаты МКПАО "Яндекс" за 2024 год (Рубрика #Management)
Сегодня Яндекс опубликовал свои показатели за Q4 и за весь 2024 год, а также прогнозы по вырчке и прибыли на 2025 год. Что можно сказать интересного про группу компаний
- Все показатели на инфографике подросли (если бы не подросли, то их бы не было на инфографике)
- Бизнес-направления агрегируют внутри сервисы, чтобы показывать благополучение направлений в общем, по крайней мере с точки зрения роста
- Проникновение сервисов значительное, поиск 110 млн, go - 53.2 млн, плюс - 39.2 млн
- На инфографике не слишком ясно кто из бизнес-линий является донором денег, а кто реципиентом (и тратит их в качестве инвестиций для развития направления). Условно реклама-поиск зарабатывают и делятся с райдтехом, автономными технологиями, а яндекс плюс как бы связывает экосистему
В общем, думаю, что интересно не только взгянуть на инфографику, но и почитать подробный отчет - можно в качестве снотворного перед сном:)
#Economics #Engineering
Сегодня Яндекс опубликовал свои показатели за Q4 и за весь 2024 год, а также прогнозы по вырчке и прибыли на 2025 год. Что можно сказать интересного про группу компаний
- Все показатели на инфографике подросли (если бы не подросли, то их бы не было на инфографике)
- Бизнес-направления агрегируют внутри сервисы, чтобы показывать благополучение направлений в общем, по крайней мере с точки зрения роста
- Проникновение сервисов значительное, поиск 110 млн, go - 53.2 млн, плюс - 39.2 млн
- На инфографике не слишком ясно кто из бизнес-линий является донором денег, а кто реципиентом (и тратит их в качестве инвестиций для развития направления). Условно реклама-поиск зарабатывают и делятся с райдтехом, автономными технологиями, а яндекс плюс как бы связывает экосистему
В общем, думаю, что интересно не только взгянуть на инфографику, но и почитать подробный отчет - можно в качестве снотворного перед сном:)
#Economics #Engineering
❤6👍5🔥1🥱1
[1/4] 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 вопроса
который для меня кажется похожим н классические вопросы "Кто виноват" и "Что делать"
Авторы делают обзор предыдущих исследований на эту тему, но делают вывод, что
1) Из контролируемых экспериментов можно понять причинно-следственные связи, но не ясно будут ли они воспроизводиться на рабочем месте. Эти эксперименты обычно ставятся в таких условиях, когда экспериментаторы привлекают студентов или даже опытных специалистов и устраивают им аля лабораторные работы, навроде, дебаггинга новым инструментом по сравнению со старым.
2) Полевые исследования могут дать валидные наблюдения в контексте организации, но их сложно обобщить, а также есть проблемы с определением не просто корреляций, а причинно-следственных связей.
Основной вклад этой статьи в исследования продуктивности - возможность получить более строгий вывод о факторах, что причинно-следственно влияют на продуктивность инженеров. Для этого авторы решают использовать подход под названием "panel data analysis" (панельное исследование). Если объяснять на пальцах, то в таких исследованиях данные собираются за определённое время у одних и тех же групп людей или индивидов, а затем проводится регрессия. То есть в широком смысле панельное исследование - это синоним лонгитюдного исследования.
Стандартным форматом для проведения исследований продуктивности является использование cross-sectional data (перекрёстных данных). Если объяснять на пальцах, то в таких исследованиях данные собираются путём наблюдения за объектами в один и тот же период времени. Обычно это проще всего сделать, бахнув опрос, но тут есть проблемки.
А про них мы поговорим в следующей части обзора.
P.S.
Интересно, что по результатам этого исследования родилась куча отдельных статей на отдельные темы, многие из которых попали в колонку IEEE про developer proudctivity, о которой я уже рассказывал. Причем эту колонку видут соавторы рассматриваемой в этом посте статьи:)
#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes
Наконец-то я дочитал и написал разбор этого 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 (перекрёстных данных). Если объяснять на пальцах, то в таких исследованиях данные собираются путём наблюдения за объектами в один и тот же период времени. Обычно это проще всего сделать, бахнув опрос, но тут есть проблемки.
А про них мы поговорим в следующей части обзора.
P.S.
Интересно, что по результатам этого исследования родилась куча отдельных статей на отдельные темы, многие из которых попали в колонку IEEE про developer proudctivity, о которой я уже рассказывал. Причем эту колонку видут соавторы рассматриваемой в этом посте статьи:)
#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes
research.google
What Improves Developer Productivity at Google? Code Quality.
👍8❤7🔥4
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
Интересное видео от 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
❤6👍4🔥3❤🔥2👏1
Без воды. Как писать предложения и отчеты для первых лиц (Рубрика #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
Недавно я прочитал эту небольшую книгу Павла Безручко и она показалась мне полезной. Но сначала отмечу, что автор, управляющий партнер "ЭКОПСИ Консалтинн" и практикующий бизнес-консультант, которым приходится писать много отчетов и для топ-менеджеров в том числе. В какой-то момент он решил написать книгу про то, как лаконично доносить свои идеи до топ-менеджеров и такая книга вышла в 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
👍26❤5🔥5
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
Интересное интервью двух легендарных инженеров 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
YouTube
Jeff Dean & Noam Shazeer — 25 years at Google: from PageRank to AGI
This week I welcome two of the most important technologists in any field. Jeff Dean is Google's Chief Scientist, and through 25 years at the company, has worked on basically the most transformative systems in modern computing: from MapReduce, BigTable, Tensorflow…
👍8❤3🔥3
Манюня: День рождения Ба (Рубрика #Kids)
В прошлые выходные мы были с детишками на только что вышедшем фильме "Манюня: День рождения Ба", который основан на книгах Наринэ Абгарян, про которые я уже писал. Картина отлично передает атмосферу книги и сочетает в себе ностальгию по детским приключениям, семейные ценности и тонкий юмор. Основой для фильма послужила повесть Наринэ Абгарян «Манюня, юбилей Ба и прочие треволнения» — заключительная часть серии о приключениях трех подруг. Абгарян, известная своими автобиографическими историями, вложила в сценарий личные воспоминания о детстве в армянском городке. Её участие в написании сценария (совместно с Нарой Акобян и Гайком Асатряном) обеспечило экранизации близость к первоисточнику. Например, эпизоды с побегом барана или испорченным тортом напрямую отсылают к книжным описаниям, подчеркивая хаотичное очарование деревенской жизни. Важным элементом стала тема взросления. Если в первых фильмах франшизы акцент делался на шалостях героинь, то в финальной части режиссер и сценаристы исследуют их эмоциональные конфликты. Сцена ссоры Наринэ и Манюни из-за предстоящего переезда последней отражает страх потерять дружбу — мотив, который Абгарян раскрывает через метафору кошмара Наринэ.
В общем, фильм интересно смотреть - в нем есть примеры сложных ситуаций, но нет излишнего морализаторства. Несмотря на скромный бюджет, фильм демонстрирует, что семейное кино может быть одновременно смешным, трогательным и глубоким. Правда, в некоторых сценах видно, что бюджет был сильно ограничен, поэтому, например, за побегом барана мы следим скорее по реакции главных героев, а не по действиям самого барана:)
#ForKids #ForParents #Humor
В прошлые выходные мы были с детишками на только что вышедшем фильме "Манюня: День рождения Ба", который основан на книгах Наринэ Абгарян, про которые я уже писал. Картина отлично передает атмосферу книги и сочетает в себе ностальгию по детским приключениям, семейные ценности и тонкий юмор. Основой для фильма послужила повесть Наринэ Абгарян «Манюня, юбилей Ба и прочие треволнения» — заключительная часть серии о приключениях трех подруг. Абгарян, известная своими автобиографическими историями, вложила в сценарий личные воспоминания о детстве в армянском городке. Её участие в написании сценария (совместно с Нарой Акобян и Гайком Асатряном) обеспечило экранизации близость к первоисточнику. Например, эпизоды с побегом барана или испорченным тортом напрямую отсылают к книжным описаниям, подчеркивая хаотичное очарование деревенской жизни. Важным элементом стала тема взросления. Если в первых фильмах франшизы акцент делался на шалостях героинь, то в финальной части режиссер и сценаристы исследуют их эмоциональные конфликты. Сцена ссоры Наринэ и Манюни из-за предстоящего переезда последней отражает страх потерять дружбу — мотив, который Абгарян раскрывает через метафору кошмара Наринэ.
В общем, фильм интересно смотреть - в нем есть примеры сложных ситуаций, но нет излишнего морализаторства. Несмотря на скромный бюджет, фильм демонстрирует, что семейное кино может быть одновременно смешным, трогательным и глубоким. Правда, в некоторых сценах видно, что бюджет был сильно ограничен, поэтому, например, за побегом барана мы следим скорее по реакции главных героев, а не по действиям самого барана:)
#ForKids #ForParents #Humor
👍9👎9❤4🤔2💊2🔥1
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 определяют агентов как
Здесь важно, что агент
- Наблюдает за окружением через сенсоры
- Формирует внутреннее состояние через рассуждения
- Выбирает действия через планировщик с использованием инструментов (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. Его интересно изучить, так как он фокусируется не на написании кода (что является веселой частью этой работы), а для скучных частей
Если говорить про будущее агентов, то
- Агенты будут независимо управлять вычислительными ресурсами, что сможет снизить зависимость от централизированных платформ
- Агенты смогут в коллаборации решать более сложные проблемы
- Для агентов будут важны вопросы безопасности, чтобы сложнее было эксплуатировать уязвимости API или получать неправомерный доступ к данным в data stores
В итоге, это хороший базовый whitepaper на тему построения агентских систем.
#AI #ML #Engineering #Software #Architecture #SystemDesign #DistributedSystems
На выходных прочел интересный 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
Kaggle
Agents
Authors: Julia Wiesinger, Patrick Marlow and Vladimir Vuskovic
❤11🔥3👍2
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, PCM, Hogan)
- Образование и постоянное развитие как залог карьерного и личностного роста
Эпизод доступен в Youtube, VK Video, Podster.fm, Ya Music.
#Management #Leadership #Software #Processes #Retrospective #Design #Processes #SelfDevelopment
В этом выпуске подкаста ко мне опять пришел Вадим Гончаров, мой коллега, с которым мы обсудили его путь в Т-Банке. Вадим в веб-разработке больше 15 лет. В 2008 руководил собственной веб-студией. С 2013 работал в VK, а в 2017 присоединился к Т-Банку, где в качестве технического руководителя запускал самое крупное медиа про деньги в России: Т—Ж. А с 2020 Вадим года руководит разработкой интерактивных спецпроектов и игр в мобильном приложении Т-Банка. Он проповедует lifelong learning: закончил МИЭМ, учился в Британке и Вышке, а сейчас учится в Сколково на программе МБА. Этот выпуск продолжает "Code of Leadership #28", где мы обсудили работу Вадима до Т-Банка, а также важность дизайна в разработке. Ну а здесь мы говорили про
- Появление Вадима в Т
- Работа в Т-Журнале и улучшение финансовой грамотности населения и бренда
- Переход к руководству людьми и проблемы выгорания и делегирования
- Спецпроекты в Т-Банке
- Игры и их развитие в экосистеме Т
- Использование моделей управления (DISC, PCM, Hogan)
- Образование и постоянное развитие как залог карьерного и личностного роста
Эпизод доступен в Youtube, VK Video, Podster.fm, Ya Music.
#Management #Leadership #Software #Processes #Retrospective #Design #Processes #SelfDevelopment
YouTube
Code of Leadership #30 - Interview with Vadim Goncharov about T-Bank and management approaches
В этом выпуске подкаста ко мне опять пришел Вадим Гончаров, мой коллега, с которым мы обсудили его путь в Т-Банке. Вадим в веб-разработке больше 15 лет. В 2008 руководил собственной веб-студией. С 2013 работал в VK, а в 2017 присоединился к Т-Банку, где в…
🔥5❤🔥3👍2
Oscar, an open-source contributor agent architecture (Рубрика #AI)
Oscar - это интересный проект от Google про применение LLM-агентов в программировании. Правда, ребята ставят себе целью не генерацию кода, а скорее устранение рутинной работы по поддержанию крупного open source проекта. Суть в том, что написание кода является интересной частью создания софта, а вот обработка входящих issues, сопоставление вопросов с существующей документацией или проверка reports - это все неинтересная часть работы и ее хорошо было бы автоматизировать. Сам проект Oscar является сейчас экспериментом и частью проекта golang, но в будущем может стать отдельным проектом. Изначальной целью было
Для решения этих задач авторы решили, что у 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
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
👍6❤4🔥1
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
Джоди Берчилл, 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
YouTube
Beyond the Hype: A Realistic Look at Large Language Models • Jodie Burchell • GOTO 2024
This presentation was recorded at GOTO Amsterdam 2024. #GOTOcon #GOTOams
https://gotoams.nl
Jodie Burchell - Data Scientist and Developer at JetBrains @jodieburchell
RESOURCES
https://twitter.com/t_redactyl
https://www.linkedin.com/in/jodieburchell
ht…
https://gotoams.nl
Jodie Burchell - Data Scientist and Developer at JetBrains @jodieburchell
RESOURCES
https://twitter.com/t_redactyl
https://www.linkedin.com/in/jodieburchell
ht…
❤6👍4🔥2🥱1
[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
Продолжим рассмотрение статьи про 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
Telegram
Книжный куб
[1/4] What Improves Developer Productivity at Google? Code Quality. (Рубрика #DevEx)
Наконец-то я дочитал и написал разбор этого whitepaper 2022 года, что пролежал распечатанным на моем столе около года. Не могу сказать, что заставило меня остановиться при…
Наконец-то я дочитал и написал разбор этого whitepaper 2022 года, что пролежал распечатанным на моем столе около года. Не могу сказать, что заставило меня остановиться при…
👍4🔥3❤2🌚1
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
Три месяца назад 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
YouTube
Andrew Ng Explores The Rise Of AI Agents And Agentic Reasoning | BUILD 2024 Keynote
In recent years, the spotlight in AI has primarily been on large language models (LLMs) and emerging large multi-modal models (LMMs). Now, building on these tools, a new paradigm is emerging with the rise of AI agents and agentic reasoning, which are proving…
🔥5👍3❤2
[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 когда-то начиналась с офлайн-репетиторства ооснователя компании, Byju Raveendran (Бью Равендрана), в Керале, которое к 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
С большим интересом я прочитал эту книгу осени 2023 года, в которой подробно рассказано о махинациях гиганта индийского edtech сектора Byju's. Если говорить про саму компанию, то когда-то оценка компании составляла 22 млрд долларов, а сейчас она буквально ничего не стоит. Отдельно отмечу потерянную при переводе игру слов в английском названии книги - основное приложение BYJU's называлось "The Learning App", а автор в своем названии обыграл это через "The learning trap" и получилось очень точно и красиво. Книгу написал журналист Прадип Сахи, который задавал вопросы по поводу бизнес-модели компании и когда она была на коне, но когда начались проблемы он решил оформить свое журналисткое расследование в остросюжетную книгу. Здесь Прадип раскрывает агрессивные маркетинговые тактики, корпоративные провалы и финансовые махинации под руководством основателя Биджу Равендрана, чья империя рухнула из-за обвинений в мошенничестве, неустойчивой бизнес-модели и токсичной корпоративной культуры. К 2025 году BYJU'S столкнулась с процедурой банкротства, потерей 95% стоимости и судебными исками в Индии и США, став поворотным моментом для всего сектора. Последствия включают скептицизм инвесторов, усиление регуляторного контроля и переоценку гиперроста.
Основные моменты истории отмечены ниже
1) BYJU'S когда-то начиналась с офлайн-репетиторства ооснователя компании, Byju Raveendran (Бью Равендрана), в Керале, которое к 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
👍11❤4🔥2❤🔥1
Обложки книг "The learning trap. How Byju's took Indian edtech for a ride" и "Ловушка обучения"
👍6❤3🔥3