Telegram Web
...Isms. Understanding Modern Art (...Измы. Как понимать фотографию) (Рубрика #Culture)

За неделю неспешного чтения изучил книгу Эммы Льюис 2017 года о том, как понимать фотографию. Эмма - британский куратор и историк фотографии, которая работала на момент написания книги в качестве ассистента куратора международного искусства в галерее Tate Modern в Лондоне, где она занимается фотографическими приобретениями и курирует выставки. Эмма структурировала свою книгу хронологически, выделив пять основных периодов развития фотографии:

Часть 1: Изобретение фотографии и документация мира (1826 — 1910)
Эта часть охватывает самые ранние этапы развития фотографии, от изобретения фотографического процесса до начала XX века.
Часть 2: В сторону модернизма (1850 — 1930)
Этот период охватывает раннее развитие фотографии и включает зарождение различных направлений. В рамках этой эпохи особое внимание уделяется пикториализму — движению, которое стремилось доказать, что фотография может быть искусством, подражая живописи. Значительную роль в развитии пикториализма сыграли такие фотографы, как Альфред Стиглиц и группа «Фото-Сецессион».
Часть 3: Общество и человечество (1930 — 1970)
Эта эпоха знаменита развитием уличной фотографии и документальной съемки. Ключевыми фигурами стали Эжен Атже, который создал тысячи фотографий старого Парижа между 1890 и 1928 годами, а также американские фотографы Уокер Эванс и Хелен Левитт.
Часть 4: Постмодернизм (1950 — 1990)
Этот период включал эксперименты с формой и содержанием, отход от традиционных представлений о фотографии.
Часть 5: Современная фотография (1980 — 2010)
Это была эпоха цифровой фотографии и социальных медиа, включая период «от изобретения фотографического процесса до пост-интернет эры.

Если бы Эмма писала книгу сейчас, то она точно бы добавила что-то про текущее разлдолье LMM (large multimodal models), которые позволяют генерировать любые изображения и видео, но книга была написана почти 10 лет назад, когда сгенерированные изображения еще не были настолько хороши.

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

P.S.
Я когда-то увлекался фотографией - с тех пор у меня осталось какое-то количество фоток на 500px, а также любовь к чтению книг на тему фотографии:)

#Culture #Photography
Космонавтика (Рубрика #PopularScience)

В выступлении Илона Маска, про которое я рассыказывал в выходные, мне понравилась часть, где он рассказывал про Space X. Я сам когда-то в детстве мечтал полететь в космос, но потом я вырос и понял, что скорее всего у меня не получится. Но я до сих пор люблю читать про космос, астрофизику, а после поездки в Китай я верулся с космонавтом из набора лего, который теперь стоит на моем столе в офисе. А рядом с ним лежит книга "NASA. The Archive" и "Космические туманности 3D", которые иногда можно полистать для получения вдохновения:)

#PopularScience #Photography
Alexander Wang: Building Scale AI, Transforming Work with Agents & Competing with China (Рубрика #AI)

Посмотрел на выходных очень интересное выступление Александра Вана, американо-китайского предпринимателя, родившийся в 1997 году в Лос-Аламосе, Нью-Мексико. В 24 года он стал самым молодым self-made миллиардером в мире. Ван — математический вундеркинд, который участвовал в олимпиадах по математике и программированию с детства. До основания Scale AI работал программистом в Quora в возрасте 17 лет, а также учился в MIT, откуда ушел для развития своего стартапа. Его компания Scale AI — это платформа для аннотирования данных, предоставляющая обучающие данные для моделей машинного обучения (аля Mechanical Turk от AWS или "Толока" от Яндекса). Александр основал ее совместно с Люси Го в 2016 году в рамках акселератора Y Combinator (Александру тогда было 19). Изначально Scale AI позиционировалась как "API для человеческого труда", но быстро сфокусировалась на данных для беспилотных автомобилей (про это Александр рассказывает подробно в подкасте). Сегодня Scale AI стоит $29 миллиардов после недавних инвестиций Meta в размере $14 миллиардов, а Александр возглавит новую лабораторию суперинтеллекта Meta

Если говорить про основные тезисы выступления, то они следующие
1. Эволюция Scale AI: от данных к агентам
Ван рассказал о трансформации компании от простой платформы разметки данных к провайдеру агентных решений. Компания прошла путь от фокуса на беспилотные автомобили до создания ИИ-приложений стоимостью сотни миллионов долларов для крупнейших корпораций и правительства
2. Будущее работы: люди как менеджеры агентов
Александр Ван представил техно-оптимистичное видение будущего работы. По его мнению, конечное состояние экономики — это "крупномасштабное управление людьми и агентами". Люди будут выполнять роль менеджеров, координирующих работу ИИ-агентов, при этом сохраняя контроль над видением и конечными результатами. Забавно, что техно-пессимисты иногда говорят, что агентами будут люди, а менеджерить их будет AGI:)
3. Конкуренция с Китаем в области ИИ
Ван открыто обсудил вызовы конкуренции с китайскими ИИ-лабораториями. Он отметил, что китайские модели хороши частично благодаря промышленному шпионажу, а Китай имеет преимущества в данных и энергетике. США отстают в производстве энергии из-за регуляторных ограничений, в то время как Китай продолжает наращивать мощности. Ирониично было слушать обсуждение конкуренции с Китаем от Гарри Тена, главы Y Combinator, и Александра Вана, главы Scale AI.
4. "Последний экзамен человечества"
Scale AI создала benchmark под названием "Humanity's Last Exam" — набор сверхсложных научных задач, составленных ведущими исследователями. Эти задачи требуют многочасовых размышлений и никогда не появлялись в учебниках. Лучшие модели уже набирают более 20% баллов, что показывает быстрый прогресс ИИ в решении передовых исследовательских задач
5. Законы масштабирования и специализированные модели
Ван подчеркнул важность законов масштабирования, которые стали очевидными с выходом GPT-3 в 2020 году. В будущем каждая компания будет иметь специализированную модель как основной IP, обученную на собственных данных и для решения конкретных бизнес-задач
6. Агентные рабочие процессы
Scale AI активно использует обучение с подкреплением для автоматизации внутренних процессов, преобразуя человеческие рабочие процессы в агентские. Компания применяет эти решения для анализа данных, отчетов о продажах и других операционных задач.

В общем, интервью достаточно глубокое и интересное, причем видно насколько Александр увлечен своей работой и шарит в теме - не зря Марк Цукерберг вложился в компанию Александра и позвал руководить лабораторией.

#AI #Engineering #Management #Leadership #ML #Software
Turbo ML Conf от Т-Банка (Рубрика #AI)

19 июля Т-Банк проведет масштабную конференцию для специалистов в области машинного обучения — Turbo ML Conf. Это уникальная площадка, где соберутся ведущие эксперты для обсуждения самых актуальных тем и прикладных кейсов в сфере искусственного интеллекта. Участников ждут как доклады, ориентированные на продукт и бизнес-метрики, так и глубокие технические разборы из мира R&D и научных исследований. В программе конференции 5 треков

1. NLP (Обработка естественного языка)
Спикеры поделятся опытом в автоматизации клиентской поддержки, обсудят alignment, reasoning, а также мультимодальные большие языковые модели (LLM) и их механистическую интерпретируемость.
2. Research & RnD
Обсуждение того, как устроены исследования в России и кто создает новые направления. Обсуждение alignment, reasoning, LMM и mechanistic interprebability
3. RecSys (Рекомендательные системы)
Эксперты представят свежие инсайты из промышленных A/B-тестов, расскажут о применении нейросетей на разных этапах создания рекомендательных систем и поделятся опытом построения персонализации в крупных проектах. Также будут затронуты техники улучшения бизнес-метрик и применение графовых нейронных сетей (GNN).
4. CV (Компьютерное зрение) и Speech
Этот трек будет посвящен последним достижениям в области синтеза и распознавания речи, генеративным сетям, VLM (Vision-Language Models) и OCR (оптическое распознавание символов).
5. LLM Applications (Применение LLM)
Этот блок будет посвящен практическому использованию больших языковых моделей. Будут рассмотрены LLM-платформы, архитектура решений, инструментарий (тулинг), агентные системы, RAG (Retrieval-Augmented Generation) и применение LLM в разработке программного обеспечения. Отдельное внимание будет уделено низкоуровневым оптимизациям для работы моделей на различных устройствах.

В общем, регистрируйтесь и приходите послушать крутые доклады.

#AI #ML #Engineering #Software #Conference
Профессиональное управление проектом (Рубрика #Management)

В рамках разбора своих книжных полок от старых книжек наткнулся на книгу Кима Хелдмана про проектное управление. Именно с этой книги у меня начиналось знакомство с этой областью менеджмента, когда я 20 лет назад учился в совместной магистратуре МФТИ и IBS. Тогда книга показалась мне интересной и полезной, но сейчас книга мне кажется формальным учебником для подготовки к сдаче PMP (Project Management Professionals) экзамена. Интересно, что 20 лет назад я заботал эту книгу и не сдавал экзамен, а вот лет 7 назад я вернулся к этому вопросу и с тех пор стал профессионалом в управлении проектами. Кстати, если вы хотите книгу на похожую тему, но на голову выше, то рекомендую книгу "Rita Mulcahy's PMP® Exam Prep, Tenth Edition", про которую я писал раньше.

Но если возвращаться к самой книге, то в ней 12 глав, которые дают неплохое представление о проектном управлении
1. Что такое проект? — введение в основные понятия, как говорится начнем с терминологии
2. Приступая к разработке проекта — области знаний, что нужны для управления проекктом, инициация проекта, постановка целей, определение ограничений
3. Создание устава проекта — методология отбора проектов, первоначальные цели, создание устава
4. Сфера действия проекта и создание структуры организации работ — определение содержания проекта, структуры работ и декомпозиция их на блоки
5. Планирование и оценка ресурсов — разработка планов по ресурсам и времени, подбор кадров, оценка стоимости
6. Обеспечение контроля за планированием проекта — определение стандартов качества, планирование степени риска
7. Составление плана проекта — составление графика проекта, установление базового уровня сметы
8. Формирование команды проекта — исполнения плана проекта (синки, значимые результаты), формирование команды и организация работы, распространение информации
9. Оценка и контроль выполнения проекта — контрактная часть, контроль качества, управление прогрессом проектов
10. Контроль за изменениями — контроль ограничений проектного треугольника: scope, time, cost. Разработка реакции на возможные риски
11. Закрытие проекта — процедура финализации, административная + lessons learned
12. Профессиональная ответственность — что-то из серии клятвы Гиппократа, но с точки зрения руководителей проектов:)

Итого:
+ Книга охватывает все ключевые аспекты управления проектами: от интеграции до управления рисками
- Книга 2005 года безнадежно устарела и рассказывает про процессы из PMBoK очень старой версии (хотя автор продолжил выпускать новые издания, коих набежало уже порядка 10 штук)

Сейчас эту старую книгу можно полистать, но читать для погружения в проектную деятельность надо что-то посвежее:)

P.S.
Отнес эту книжку в booksharing уголок в нашем московском офисе, что расположен на 7 этаже - вдруг кто-то захочет полистать раритет:)

#Management #Project #Leadership #Processes
Архитектура предприятия, управляемая моделью (Рубрика #Architecture)

Я интересуюсь архитектурой во всех ее проявлениях, поэтому иногда смотрю за потугами и корпоративных архитекторов. На недавней конференции Сбера было выступление Олега Захарчука на тему архитектуры, управляемой моделью. Сам Олег закончил МФТИ в далеком 1987 году, а сейчас руководит компанией "АСиС Софт", является экспертом в области архитектуры предприятия и членом-корреспондентом РАЕН. Он известен своими работами в области создания единой метамодели.

Если кратко обобщать идеи выступления, то в нем рассказано про
- Концепцию холархии, что должна прийти на смену традиционным иерархическим структурам
- Четырехуровневую модель: действия, задачи, рабочие группы, организации
- Единую онтологии деятельности и создании цифровых моделей предприятий на базе этой модели
- Цифровых агентах, что должны где-то бултыхаться на уровне действия и отдельных сервисов для их автоматизации (видимо, это отсылка к AI агентам)

В общем, если попробовать проанализировать проблемные места подхода, предложенного в докладе, то
1. Концептуальная сложностью Несмотря на заявления о упрощении, четырехуровневая холархия с множественными связями "обязательств" может оказаться более сложной для понимания и внедрения, чем существующие подходы.
2. Масштабируемости решения на уровень компании. Хотя автор утверждает, что подход позволяет описывать системы различного масштаба, практический опыт показывает, что единые метамодели часто сталкиваются с проблемами при масштабировании на уровень крупных предприятий
3. Интеграция с существующими решениями. Большинство предприятий уже имеют развитую ИТ-инфраструктуру, построенную на различных стандартах и методологиях . Не ясно как эта модель Захарчука может быть интегрирована в существующую компанию
4. Поддержка и развитие модели. В отличие от открытых стандартов типа TOGAF или ArchiMate, которые развиваются международными консорциумами, модель Захарчука является проприетарным решением одной компании.

Дальше я поделюсь своим мнением о подходе автора, который напоминает мне проповеди о светоносном эфире, перед корпусами Физтеха одного старичка.
Автор взял подходы из прошлого:
- Концепцию холархии была сформулирована еще в 1960-х годах философом Артуром Кестлером
- Идею единой онтологии для предприятий активно разрабатывалась в рамках семантического веба в районе двухтысячных
- И так далее
Автор провел ребрендинг и начал продавать их как работающее решение ... и все вроде неплохо, но оно не работает и это проблема не только модели Олега Захарчука, а всего подхода к архитектуре предприятия, где можно выделить следующие проблемы

1. Отсутствие связи с реальностью
Общая тенденция архитектуры предприятий — создавать красивые теоретические модели, которые плохо работают на практике. Приоритет отдается архитектурной чистоте, а не жизнеспособным и эффективным в реальном мире решениям
2. Проблема "моделирования ради моделирования"
Команды создают модели чего-то, но не имеют ясного понимания цели, для которой они моделируют . Архитектура, которая не обращается к набору заинтересованных сторон, часто приводит к низкой воспринимаемой ценности.
3. Фреймворки корпоративной архитектуры бесполезны. Фреймворки вроде Zachman, TOGAF или FEAF являются не более чем типичными управленческими причудами, агрессивно продвигаемыми консалтинговыми компаниями и гуру. Они бесполезны в лучшем случае и вредны в худшем (подробнее в whitepaper)
4. Псевдонаучность корпоративной архитектуры. Системное мышление, как инструмент для архитектуры предприятий, часто восхваляется в публикациях, связанных с архитектурой предприятий, но на практике не способно предоставить какие-либо действенные предложения . Исследования ставят под сомнение научную обоснованность архитектуры предприятий с точки зрения критериев фальсицируемости Поппера (подробнее в whitepaper)

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

#Architecture #Software #Engineering #Management #DistributedSystems
Code of Leadership #42 Interview with Andrew Romanovsky about Сareer as an Engineering Manager (Рубрика #Management)

Через 2 часа стартанет live интервью с Андреем Романовским о карьере engineering manager в крупной технологической компании. Андрей руководит продуктовой разработкой Яндекс.Лавки и является CTO Yango.Tech Retail, а кроме того ведет канал Lead’s Notes (@leadsnotes). Мы точно обсудим вопросы ниже, но если вы придете, то сможете спросить что-то свое
- Что входет в роль engineering manager?
- Ради чего вообще стоит идти в менеджерский карьерный трек?
- Как устроен рост менеджера?
- Растет ли сложность работы с продвижением по карьерной лестнице?
- Как решать проблемы тайм-менеджмента: перегруз, баланс работы и личной жизни?
- Как не потерять технические скиллы и стоит ли за этим гнаться?

#Software #Engineering #Management #Architecture #Processes
ML-платформа: всеобщее благо или лучше не надо (Рубрика #AI)

Посмотрел интересное интервью моих коллег на тему ML платформы. Мне нравится и ML и platform engineering, а тут собралось комбо, поэтому я не мог пройти мимо этого выпуска "Желтый AI Club Talks". В нем участвуют два человека:
- Даниил Гаврилов — ведущий, руководитель Research-команды
- Михаил Чебаков — гость, руководитель разработки платформ ML

Вот основные идеи интервью
1. Философия ML-платформы
Михаиил представил концепцию идеальной ML-платформы через метафору канализации — она должна быть незаметной в работе, но критически важной для функционирования. Платформа должна инкапсулировать операционные затраты, связанные с масштабированием, предоставлением ресурсов, мониторингом и обеспечением отказоустойчивости, позволяя разработчикам сосредоточиться на основной работе.
2. Эволюция платформы
Развитие ML-платформы в Т-Банке началось с классической проблемы — кластера серверов с SSH-доступом, который перестал справляться с растущими потребностями команд. Первым решением стало внедрение простого оркестратора, что повысило утилизацию серверов.
3. Самая важная функция
По мнению Михаила, ключевой особенностью платформы стала возможность управления данными — создание папок, доступных из любой точки кластера, с автоматическим резервным копированием. Эта функция позволяет командам легко обрабатывать нестандартные данные, генерировать промежуточные артефакты и переносить работу между кластерами.
4. Проблемы с пользовательским опытом
Миша привел пример фичи, где пользователи просили добавить папки для организации своей работы. Ребята подумали и придумали максимально общую систему организации работы через лейблы — решение получилось технически правильным. Через фильтрацию лейблов можно было делать любые представления, но это было не user friendly с точки discovery этой фичи, а также дальше в процессе использования. В итоге, Михаил подчеркнул важность создания интуитивно понятного интерфейса, где функционал можно найти без изучения документации.
5. Сопротивление переходу на платформу
Многие разработчики предпочитают работать через SSH из-за ощущения контроля, прозрачности процессов и совместимости с большинством open-source проектов. Однако такой подход создает проблемы с воспроизводимостью результатов, потерей данных и масштабированием.
6. Три ключевых домена ML платформы
- Инженерный опыт — интерактивная работа одного разработчика с минимальным циклом обратной связи
- Производственные конвейеры — автоматизация устоявшихся процессов с акцентом на воспроизводимость
- Развертывание и эксплуатация — обеспечение эффективности и полезности готовых решений
7. Принципы проектирования
Основной принцип — делать правильные пути простыми, а неправильные — сложными. Это предотвращает ошибки и направляет пользователей к оптимальным решениям.
8. Методы оценки эффективности
- Базовые метрики: количество пользователей, команд, retention
- Регулярные опросы и замеры удовлетворенности
- Догфудинг — использование платформы для собственных внутренних задач разработки платформы
- Плотное взаимодействие с командами в режиме co-development
9. Разнообразие ML-направлений
Платформа обслуживает десять различных направлений: R&D, RecSys, CV, генерацию изображений, LLMs, прикладное NLP, антифрод, рисковые скоринги, распознавание и синтез речи. Каждое направление имеет уникальные требования к данным, воспроизводимости и аппаратуре.
10. Видение будущего
Михаил видит идеальное будущее платформы в полном воспроизведении опыта работы с SSH-серверами, но с преимуществами платформенного подхода — все необходимые функции должны быть доступны "из коробки" без необходимости изучения документации.

Ключевой вызов заключается в том, что команда разработки платформы работает как "вторая производная" от продукта — они создают инструменты для технологий, которые затем используются для создания продуктов. Это требует постоянного мониторинга индустриальных трендов и опережающего развития функционала.

#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops #DistributedSystems
Measuring AI code assistants and agents (Рубрика #AI)

Прочитал свежий (вчерашний) research на тему измерения эффекта от AI в разработке от Abi Noda, кофаундера и CEO платформы DX для измерения продуктивности разработки. Этот отчет интересен, так как ребята из DX являются одними из законодателей мод в мире developer productivity:
- Они запилили модель DevEx, которую я уже разбирал "DevEx: What Actually Drives Productivity" и "DevEx in Action"
- В команду платформы входит Nicole Forsgren, которая драйвила развитие DORA метрик, была автором книги "Accelerate", приложила руку к фреймворку SPACE

Теперь, когда ясно почему ребят интересно изучать, давайте заглянем в сам отчет и выделим основные идеи

1. Влияние AI на разработку
AI кардинально меняет подход к инженерной деятельности в технологических компаниях - компании больше не ограничены количеством инженеров, а скорее степенью аугментации их возможностей с помощью AI. Упоминаются такие результаты нескольких компаний
- Booking.com, внедрив AI-инструменты для более чем 3500 инженеров, достигла 16% увеличения throughput за несколько месяцев
- Intercom, почти удвоив использование AI-ассистентов кода, добилась 41% увеличения экономии времени разработчиков.
AI также расширяет понятие "разработчика" - продакт-менеджеры, дизайнеры и бизнес-аналитики теперь могут создавать работающее программное обеспечение с помощью AI, размывая границы между техническими и нетехническими ролями. Вспоминаем про vibe coding:)

2. Ключевые метрики для измерения
Авторы отчета расширяют свой DX фреймворк отдельным направлением DX AI, где фокус на трех вещах
- Utilization - отслеживание внедрения и использования AI-инструментов. Исследования показывают, что даже ведущие организации достигают лишь около 60% активного использования AI-инструментов.
- Impact - измерение реального эффекта на производительность. Рекомендуется сочетать:
-- Прямые метрики: экономия времени разработчиков
-- Косвенные метрики: анализ DX Core 4 показателей (PR throughput, percieved rate of delivery, developer experience index)
- Cost - отслеживание затрат, чистой прибыли (сэкономленное время разработчиков - затраты)
Интересно, что у ребят есть бенчмарки по этим метрикам, которые они предоставляют клиентам DX платформы

3. Баланс скорости и качества
Организации должны балансировать метрики эффективности с показателями качества, чтобы избежать подрыва долгосрочной скорости разработки. AI-генерированный код может быть менее интуитивным для понимания человеком, что создает потенциальные проблемы.

4. Измерение AI-агентов
Исследование рекомендует рассматривать автономных агентов как расширения команд разработчиков, а не как независимых участников. Каждый разработчик будет все больше работать как "менеджер" команды AI-агентов, а оценивать его результаты надо будет по результатам работы этой команды AI агентов

5. Подходы к внедрению системы измерений
Важно правильно коммуницировать цели вндерения метрик, связанных с использованием AI. Авторы рекомендуют четко подчеркивать три ключевых момента:
- Метрики не будут использоваться для индивидуальной оценки производительности сотрудников (ведь не будут же?)
- Цель измерения - понять, как AI-assisted работа влияет на опыт разработчиков и качество программного обеспечения, а не микроменеджмент
- Данные необходимы для принятия инвестиционных решений, помогая определить, какие инструменты и рабочие процессы приносят реальную ценность

6. Избежание ловушек

Отчет категорически предостерегает от директивных мандатов сверху или использования метрик для индивидуальной оценки производительности. Такие метрики, как объем генерации кода, особенно подвержены манипуляциям. Проактивная коммуникация является ключевой - без неё спекуляции и страхи могут заполнить информационный вакуум.

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

#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops
Почему ИИ не работает без настоящего инженера (Рубрика #AI)

Посмотрел интересный выпуск подкаста "Организованное программирование" Кирилла Мокевина, куда он позвал интересного гостя, Андрея Татаринова, поговорить про AI не только с точки зрения концепций, но и практического применения. Сам Андрей — опытный инженер (ex-Yandex, ex-Google) с бэкграундом в области машинного обучения. После работы в найме он основал собственную команду "Эпоха 8" (Epoch 8), которая специализируется на решении задач методами машинного обучения и помогает стартапам внедрять ИИ в реальные продукты (кстати, в блоге на сайте Андрея интересно почитать кейсы внедрения AI решений). Ниже представлены основные моменты обсуждения, что длилось около 2.5 часов:)

1. ИИ как "волшебные API-вызовы"
Андрей отмечает, что сложная тематика машинного обучения превратилась в классические API-вызовы к сервисам. Для большинства разработчиков современный ИИ — это не самостоятельное обучение моделей с нуля, а умелое использование готовых решений через API.
2. Пределы экспоненциального роста
Андерй считает, что мы близки к возможному насыщению в развитии AI. Он сравнивает текущую ситуацию с космическими технологиями: после бурного роста наступает плато, требующее качественно новых подходов. Быстрая смена лидеров на бенчмарках указывает на приближение к теоретическому пределу качества.
3. Техническая архитектура LLM
Инференс и рантаймы: Нейросети представляют собой последовательность матричных перемножений и нелинейностей. Выбор рантайма критически важен для эффективности, особенно для больших моделей. Языковые модели генерируют токены по одному, запуская инференс многократно для получения полного ответа. Это объясняет стриминговый характер вывода.
4. Практические вызовы внедрения
Fine tuning и prompt engineering - это технологии для масс, так как обучение с нуля имеет "заградительный ценник" для обычных компаний. Причем начинать рекомендуется начинать с написания лучшего промта и его тестирования. Отдельно Андрей отметил проблемы совместимости - кастомизация моделей часто приводит к несовместимости с различными рантаймами. Конвертация между рантаймами аналогична кросс-компиляции программ. А вообще, рантаймов много и для LLM есть помимо общих вида PyTorch существуют llama.cpp, Ollama, Llamafile, ...
5. RAG и векторные базы знаний
RAG (Retrieval Augmented Generation) решает проблему ограничений промтов по объему. Система использует векторную базу знаний для поиска релевантной информации и "насыщения" промта целевыми данными. Очень популярная техника в текущий момент
6. Ограничения современных моделей
Даже с четкими правилами модели могут выдавать неточную информацию из-за своей вероятностной природы. Это особенно критично для специализированных задач, таких как рекомендательные системы в e-commerce. Количество информации, что может усвоить модель на претрейне ограничено количеством гипер-параметров. Дообучение модели иногда приводит к забыванию знаний в других областях, что были усвоены во время тренировок.
7. Будущее ИИ-агентов
Стандарт MCP (Model Control Protocol) открывает возможности для создания бизнес-ассистентов. Однако ограничивающим фактором остается способность к многошаговому рассуждению. Андрей скептично относится к возможности создания универсального ассистента, который разумно решал бы многостадийные задачи в ближайшем будущем.

По результатам общения можно выделить ряд практических советов для решения задач с помощью LLM
- Начинайте с промт-инжиниринга вместо попыток обучить модель с нуля
- Используйте RAG для работы с большими объемами специализированных данных
- Тестируйте качество итеративно, как в классическом ML
- Учитывайте ограничения рантаймов при планировании архитектуры
- Реалистично оценивайте возможности текущих ИИ-решений

#AI #Software #Architecture #Metrics #Engineering #ML #Agents
Engineering Leadership Report 2025 от LeadDev (Рубрика #Management)

С интересом изучил мартовский отчет от LeadDev на тему инженерного лидерства, который был основан на опросе 600+ лидеров, что проводился в марте этого года. Начать стоит с того, что компания LeadDev, создатель отчета, была основана в 2013 году и специализируется на развитии engineering leadership. Компания проводит конференции и митапы по всему миру в технологических хабах. Их миссия в том, чтобы помогать инженерным лидерам становиться более эффективными, где под лидерами понимаются технические руководители, lead engineers, технические директора.

Исследование проводилось в период с 14 по 27 марта 2025 года и имело следующие параметры
- Количество респондентов - 617
- Географическое распределение: USA (34%), UK (20%), Germay (10%), Canada (6%), Asia (4%), Others (6%)
- Профили участников: менеджеры инженеров (37%), менеджеры менеджеров (18%), advanced engineers (14%), software engineers (12%), techleads (9%), CTO (6%), others (3%)
- Размер организаций: компании [1000, 5000) - 21%, компании [5000, ∞) - 21%, [100, 250) - 16% и так далее до 5% на стартапы до 20 человек

Если смотреть на ключевые результаты исследования, то они такие
- 65% респондентов обеспокоены рецессией, что отражает общую тревогу в технологическом секторе. Страхи о сокращении доступных рабочих мест выросли с 48% в 2024 году до 53% в 2025 году.
- Снижение волны увольнений и замораживания найма на 17 процентных пунктов по сравнению с предыдущим годом. Если в 2024 году 67% компаний сталкивались с увольнениями или заморозкой найма, то в 2025 году этот показатель снизился до 50%.
- Изменения в управленческой структуре. Наблюдается продолжение тенденции "выравнивания" организационных структур. Среди компаний, которые сократили количество менеджеров:
-- 67% сократили линейных менеджеров
-- 56% сократили менеджеров среднего звена
-- 18% затронули высшее управление
- Трансформация роли инженерных лидеров. 65% респондентов сообщили о расширении своих обязанностей, включая более широкие области ответственности. 40% получили дополнительных подчиненных. Это привело к тому, что 38% инженерных лидеров стали работать больше часов. Похожие показатели были и в 2024 году, но все параметры выросли на 3-4 процентных пункта. 58% респондентов тратят больше времени на коммуникацию с командами, клиентами и заинтересованными сторонами, в то время как 26% сократили время на написание и ревью кода.
- Кризис мотивации и выгорание. 40% респондентов считают, что их команды менее мотивированы приходить на работу, чем 12 месяцев назад.
- Воздействие искусственного интеллекта. 53% респондентов внедрили AI-функции в свои продукты за последние 12 месяцев. 58% инженерных лидеров рассматривают инвестиции в AI-инструменты для кодирования. Однако 60% не верят, что AI значительно повысил продуктивность их команд.
- Изменения в отношении к DEI. Только 5% организаций ликвидировали программы разнообразия, справедливости и инклюзивности в прошлом году, несмотря на громкие заголовки о сворачивании их в Bigtech компаниях

Если подумать о советах, что можно дать по итогам исследования, то стоит их поделить на категории
Для инженерных лидеров
- Развивайте навыки коммуникации и управления изменениями, так как лидерам приходиться тратить больше времени на коммуникацию
- Боритесь с выгоранием проактивно
- Пересмотрите подход к мотивации команды

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

В общем, интересный отчет, но никаких особых инсайтов у меня от него не возникло.

#Leadership #Engineering #Management #Software #Processes
2025/06/27 06:10:19
Back to Top
HTML Embed Code: