Вже доступно! Дослідження Telegram за 2025 — головні інсайти року 
Артём обо всём
Відкрити в Telegram
Head of NLP в Т. Пишу про все то, о чем не могу не писать.
Показати більшеКраїна не вказанаКатегорія не вказана
520
Підписники
Немає даних24 години
+27 днів
+2730 день
Триває завантаження даних...
Схожі канали
Немає даних
Виникли проблеми? Будь ласка, оновіть сторінку або зверніться до нашого support-менеджера.
Хмара тегів
Немає даних
Виникли проблеми? Будь ласка, оновіть сторінку або зверніться до нашого support-менеджера.
Вхідні та вихідні згадування
---
---
---
---
---
---
Залучення підписників
липень '26
липень '26
+2
в 0 каналах
червень '26
+36
в 0 каналах
Get PRO
травень '26
+34
в 1 каналах
Get PRO
квітень '26
+460
в 2 каналах
| Дата | Залучення підписників | Згадування | Канали | |
| 04 липня | +1 | |||
| 03 липня | 0 | |||
| 02 липня | +1 | |||
| 01 липня | 0 |
Дописи каналу
Не успели еще разобрать сцену после вчерашнего GenAI митапа, а я уже приглашаю вас на наш флагманский мл ивент: TurboML Conf 18 июля. В этом году ваш покорный был ответственен ровно за две вещи:
- выносить мозги бедным деврелам на тему поиска стильной площадки
- вместе с фундаментальной нлп командой думать, чем бы вас в очередной раз порадовать
Приходите 18-го в Серп и молот разбираться, преуспел ли я в этих начинаниях. Ну и это классная возможность вырвать в графике дату, пересечься и наконец вживую про все наши мл и не очень дела. Ждём!
| 2 | Еще не успели разобрать сцену от вчерашнего GenAI митапа, а я вас уже приглашаю 18 июля на TurboML Conf. Ваш покорный в этом году ответственен ровно за две вещи:
- выносил мозги несчастным деврелам, чтоб у нас была стильная локация
- и вместе с нашей фундаментальной командой размышлял, чем бы вас порадовать на конфе
Чтобы узнать, получилось ди у меня в этом преуспеть - регистрируйтесь и приходите 18-го в Серп и молот. Классный повод увидеться со всеми с кем давно не выходит пересечься и пообщаться вживую. | 5 |
| 3 | Вайбкодим игры.
Выбрались с семьей в большой отпуск. Где-то день на третий надоело купаться и тупить, начали со страшим вайбкодить дипсиком игры (в чат интерфейсе - бесплатный и безгеморгый вариант). Классно поугарали, некоторые из игр выложили сюда. Работает только с компа:
https://aobondar.github.io/vibegames/
Наблюдения:
- супер фаново: ощущения, что вернулся во времена flash-игр. Специально делали что-то тупое и странное. В таком сеттинге баги не напрягают, а скорее ожидаемы
- хорошо получаются идеи, опирающиеся на популярные концепты (bomberman, crimsonland, etc), но с твистом. Постмодернизм тут не стиль, а единственная рабочая стратегия
- Опыт инженеринга все еще очень полезен: несколько проблем отловил с дебаггером. Например для управления по wasd аппка подписалась на события клавиатуры, но когда та была в русской раскладке эти события не проходили фильтры. Вообще верю, что следущий большой шаг в качестве агентов - это когда они научатся классно орудовать дебаггером.
- Так и не решил вопрос графики. Векторная выглядит как из времен преусловутого Flash. Из идей: скачать пак ассетов и vlm разметить его на подробную метадату, доступной для агента. Но это уже за гранью сеттинга «пофаниться в отпуске», поэтому пока забил.
Я прямо очень кайфую от концепта disposable software. Помню свой восторг, когда я начал работать с Jupyter ноутбуками, и фигачил в них, как в черновиках, не заморачиваясь о долговечности. Кажется, что такого кода и софта станет больше: уж даже отец посмотрел на наши с сыном поделия и пошел пилить себе мини-апп-планнер ближайшего путешествия. Мне кажется, что это очень классная альтернатива классическим агентам: все же отлаживать/проверять запеченную в коде логику для многих сетапов сильно проще, чем колдовать над харнессами с бубном. Ощущение, что управляемости больше. Помню года два назад в рамках вечернего трёпа в офисе мы с командой ботов объясняли Вите Тарнавскому, что избавиться от регулярок на самом деле очень сложно, потому что как только ты ее отдалил - она работает очень круто. На что Витя предложил сделать «фабрику регулярок» на базе ллм. Что кажется вполне жизнеспособный нишевый (а может и не очень) подход в более широком смысле в мире софта. | 362 |
| 4 | 🚩Маленькая красная книжечка Мао для корпоративного млщика🚩
За пол года у меня собралась серия очерков про особенности работы MLE в корпорации, и для вновь присоединившихся я решил собрать их в некоторую структуру.
Мне кажется начинающим инженерам и лидерам полезно понимать тонкости работы в такой среде, потому что машинное обучение любит большие компьют, данные и масштабы.
Мл-систем дизайн/стратегия
Чеклист здорового МЛ проекта
Стратегия R&D проектов
Управление риском
Измерение качества в GenAI
Про аплифт моделирование
Опыт внедрения genAI в операции
Векторный поиск, как антипаттерн
LLM as a judge, как антипаттерн
Карьера/корпоративная культура
Суть работы управленца
Как проходить кризисы
Как нанимать
Культура операционных компаний
Культура технологических компаний
Когда идти в стартап
Стартапы внутри корпорации
Про empire-building
Про нетворкинг
Смыслы
Успех | 697 |
| 5 | Так что если вы хотите влезть с агентами в дорогую операцию (а мы хотим именно туда, а не демок наклепать, правда же?), то первый вопрос тут не «какой будет архитектура моей системы», а «как я планирую измерять и управлять качеством». | 1 |
| 6 | Что же делать с управлением качеством GenAI систем
Три года назад все и их мамы стали промпт инженерами. Потом все эти промптинг трюки отжили свое, а мы, засучив рукава, занялись context/harness/specs инженерингом и побежали разворачивать MCP. Сейчас Борис Черный утверждает, что это все снова пройденный этап, и нам надо учится луп-инженирингу. Жизнь кипит, только успевай за этим паровозом: это и фаново и сулит большой аплифи т от внедрения в работу. Ну мы и внедряем.
И на все это смотрят СТО и владельцы бизнес процессов и задаются вопросом «а это вообще будет нормально работать?». И на мой взгляд это самый главный вопрос внедрений GenAI: как измерять и управлять качеством получившихся продуктов. Потому что в этой кроличьей норе много ньюансов:
1/ human-in-the-loop
То с чего начинались все внедрения GenAI, и на первый взгляд самый надежный способ контроля и управления качеством. Каждая единица контента/решение проходит через человека. Но есть две проблемы. Во-первых HitL убивает львиную долю эффекта от агентизации. Во-вторых встает в полный рост вопрос ответственности проверяющих. Все, кто управлял службами контроля качества знают, что такая монотонная активность притупляет внимание, и люди совершают много ошибок. Да и очень сложно держать замотивированными квалифицированных людей на такой работе (спросите любого кодера, любят ли они код ревью?). Сильно хуже ситуация, если контент LLM может давать отложенные эффекты. Например плохо написанный код может отстрелить не сразу. И эти инциденты могут наслоиться друг на друга в произвольный момент, что делает всю систему хрупкой. Так что вопрос ответственности за контент, созданный LLM, и мотивации встанет в полный рост и должен стать ключевым фокусом внедрятора.
2/ эвалы для строго верифицируемых задач
Есть узкий класс проблем, где по входным данным и состоянию среды мы точно знаем, что должен сделать агент. Например, к условиям математической задачки мы знаем точный ответ. Или по запросу разработчика на человеческом языке на задачу в терминале мы знаем какую CLI команду должен вызвать агент. В общем, если мы можем очень точно проэмулировать среду и знаем ответ - мы можем проверять на этом поведение агента. Важно, что не любую среду можно проэмулировать: например в поддержке это невозможно. И системы бизнеса могут быть сложные и поведение пользователя непредсказуемо. Плюс создавать такие эвалы - часто очень дорогое удовольствие. Зато если получилось, то можно давать агенту полную свободу в среде и проверять только финальный стейт. Есть мягкая версия такого эвала в кодинге - это сет автотестов. Очевидно, они не могут полностью проверить качество работы агента, но хотя бы отсеют очевидный шлак. Ну и этот подход дает только измерение качества: что делать с системой, чтоб это качество растить - каждый раз уникальный ребус.
3/ пошаговые эвалы
А что делать, если среда неэмулируемая, и проблему можно решить множеством способов? Поддержка или продажи - это отличный пример подобной ситуации. Как правило такая автоматизация предполагает, что есть люди, которые уже как-то справляются с этой задачей, и мы постфактум можем разметить каждую интеракцию на «хорошие» и «плохие». В этом случае мы можем измерять «попадание» агента в действия человека на каждом шаге цепочки действий. И надеяться что накопленная ошибка не уведет в проде агента с нужной нас траектории. Попадания могут быть и строгими (нажал на ту же кнопку) и нестрогими (ответил по сути так же). Такой метод контроля качества позволяет проверять агента задешево на широком наборе кейсов, но очевидно не заменяет замеров качества на взаимодействии с реальной средой. Плюс в полный рост встает вопрос строгости регламентов: если из одного состояния человек может успешно добраться до финального разными путями, то метрика получится очень шумная. Так что в таком подходе большая часть фокуса уйдет на синхронизацию сотрудников и причесываение единых регламентов (иначе агента будет сложно настроить).
На деле, конечно, подходов больше, но на индустриальном масштабе они особо не масштабируются. | 526 |
| 7 | Как нарушать ритуалы не оскорбляя чувств «верующих»
Эрик Берн, один из идеологов транзакционного анализа в психологии рассуждает в своих работах про две концепции: процедуры и ритуалы. Процедуры строят взрослые люди, чтобы решать типовые вопросы, не затрачивая каждый раз много энергии и для достижения рациональной выгоды. Ритуалы передают родители детям (в широком смысле), как нечто незыблемое. Каждый ритуал когда-то был процедурой.
Я думаю вы сами встречали такое и не раз в жизни и работе: какие-то серии внутренних встреч, организаторы которых уже пропали, и настоящую цель которых (а не декларируемую) уже позабыли. Какой-то мутный критерий грейдапа. Какой-то левый чувак, чье мнение почему-то нужно учитывать. Есть простой способ детектировать ритуал: чем более абстрактными понятиями объясняется цель конструкции, тем выше шанс, что это именно что ритуал.
«Нам полезно оставаться в одном контексте», «это важно для чистоты профессии», «с ним полезно выровняться». Хотя на деле когда-то давно «нужно было следить за этими чуваками, пока они не нахуевертили», «надо было не дать конкретный грейдап», а с челом договаривались, потому что «без его ОК никто пальцем не шевелил».
Наверно самый хрестоматийный ритуал - это алгосекция при найме. Понятно, что на масштабе Гугла нужны люди, которые находят о(log) алгоритмы. Ну и масс найм не позволяет давать задачи фокусно под позицию. Но когда алгосекции дают в независимых командах, где можно было бы построить найм под свои конкретные нужды (процедуру), то это, конечно, типичный перенятый без критического осмысления ритуал. И к слову алгособес - отличный пример теряющего актуальность ритуала. Из-за его массовости, люди в индустриальных масштабах научились его обходить, что еще сильнее снизило эффективность этой когда-то процедуры.
Казалось бы, call to action ясен: критически переосмысляй происходящее, сворачивай ритуалы и вводи процедуры. Но есть ньюанс. Еще Берн отмечал, что ритуалы нас держат именно психологическим выхлопом. Их разрушение - это и конфликт с виртуальной «родительской фигурой» и потеря комфортной предсказуемости. Так как же разумно поступать, если на пути ваших целей стоит ритуал?
1/ не устраивать публичных «акций разоблачения»
Даже если все согласны с вами, что «король голый» и вешать стикеры 4 часа на доску не особо поможет вам достичь успеха, ваше нападение на ритуал с высокой вероятностью мало кто поддержит. Непублично да, а вот на публике вас скорее задавят. Мы можем не любить ритуалы, но конфликты мы любим еще меньше.
2/ найти стейкхолдера/ов, который считает происходящее процедурой.
Как правило это не администратор ритуала (в администраторы как раз часто идут люди склонные к фанатизму - не будь корпораций, они бы ушли в секту). Вот с этим человеком надо обсуждать через призму ожидаемых выгод происходящее. Выразить сомнения, что текущая конструкция даст ожидаемые результаты и поторговаться за изменение ритуала в свою пользу (превращаем назад в процедуру).
3/ выжать максимум из ритуала
Но увы предыдущий шаг работает не всегда. Вы поразитесь насколько много фанатичных людей работает в корпоративной среде. В этом случае конечно можно устроить крестовый поход с эскалацией, но причина должны быть существенной. А иногда причина - это просто раздражение от впустую потраченного времени. Значит надо сделать это время потраченным не зря. Как? Это вам виднее, но вот пару идей:
- превратить ритуал в платформу продвижения своего видения.
- погрузиться лучше в проблемы ваших соседей (ищем сделки)
- попрофилировать ваших коллег: с кем стоит что-то делать вместе, а кто несет чушь и лучше держаться от человека подальше
Это все звучит довольно абстрактно, но на практике про любую встречу активность процесс можно задать себе вопрос «как я могу этим воспользоваться, чтобы решить проблемы в зоне моей ответственности».
Иначе с ума сойти можно, а это никому на пользу не идет. | 473 |
| 8 | Как нарушать ритуалы не оскорбляя чувств «верующих»
Эрик Берн, один из идеологов транзакционного анализа в психологии рассуждает в своих работах про две концепции: процедуры и ритуалы. Процедуры строят взрослые люди, чтобы решать типовые вопросы, не затрачивая каждый раз много энергии и для достижения рациональной выгоды. Ритуалы передают родители детям (в широком смысле), как нечто незыблемое. Каждый ритуал когда-то был процедурой.
Я думаю вы сами встречали такое и не раз в жизни и работе: какие-то серии внутренних встреч, организаторы которых уже пропали, и настоящую цель которых (а не декларируемую) уже позабыли. Какой-то мутный критерий грейдапа. Какой-то левый чувак, чье мнение почему-то нужно учитывать. Есть простой способ детектировать ритуал: чем более абстрактными понятиями объясняется цель конструкции, тем выше шанс, что это именно что ритуал.
«Нам полезно оставаться в одном контексте», «это важно для чистоты профессии», «с ним полезно выровняться». Хотя на деле когда-то давно «нужно было следить за этими чуваками, пока они не нахуевертили», «надо было не дать конкретный грейдап», а с челом договаривались, потому что «без его ОК никто пальцем не шевелил».
Наверно самый хрестоматийный ритуал - это алгосекция при найме. Понятно, что на масштабе Гугла нужны люди, которые находят о(log) алгоритмы. Ну и масс найм не позволяет давать задачи фокусно под позицию. Но когда алгосекции дают в независимых командах, где можно было бы построить найм под свои конкретные нужды (процедуру), то это, конечно, типичный перенятый без критического осмысления ритуал. И к слову алгособес - отличный пример теряющего актуальность ритуала. Из-за его массовости, люди в индустриальных масштабах научились его обходить, что еще сильнее снизило эффективность этой когда-то процедуры.
Казалось бы, call to action ясен: критически переосмысляй происходящее, сворачивай ритуалы и вводи процедуры. Но есть ньюанс. Еще Берн отмечал, что ритуалы нас держат именно психологическим выхлопом. Их разрушение - это и конфликт с виртуальной «родительской фигурой» и потеря комфортной предсказуемости. Так как же разумно поступать, если на пути ваших целей стоит ритуал?
1/ не устраивать публичных «акций разоблачения»
Даже если все согласны с вами, что «король голый» и вешать стикеры 4 часа на доску не особо поможет вам достичь успеха, ваше нападение на ритуал с высокой вероятностью мало кто поддержит. Непублично да, а вот на публике вас скорее задавят. Мы можем не любить ритуалы, но конфликты мы любим еще меньше.
2/ найти стейкхолдера/ов, который считает происходящее процедурой.
Как правило это не администратор ритуала (в администраторы как раз часто идут люди склонные к фанатизму - не будь корпораций, они бы ушли в секту). Вот с этим человеком надо обсуждать через призму ожидаемых выгод происходящее. Выразить сомнения, что текущая конструкция даст ожидаемые результаты и поторговаться за изменение ритуала в свою пользу (превращаем назад в процедуру).
3/ выжать максимум из ритуала
Но увы предыдущий шаг работает не всегда. Вы поразитесь насколько много фанатичных людей работает в корпоративной среде. В этом случае конечно можно устроить крестовый поход с эскалацией, но причина должны быть существенной. А иногда причина - это просто раздражение от впустую потраченного времени. Значит надо сделать это время потраченным не зря. Как? Это вам виднее, но вот пару идей:
- превратить ритуал в платформу продвижения своего видения.
- погрузиться лучше в проблемы ваших соседей (ищем сделки)
- попрофилировать ваших коллег: с кем стоит что-то делать вместе, а кто несет чушь и лучше держаться от человека подальше
Это все звучит довольно абстрактно, но на практике про любую встречу активность процесс можно задать себе вопрос «как я могу этим воспользоваться, чтобы решить проблемы в зоне моей ответственности».
Иначе с ума сойти можно, а это никому на пользу не идет. | 28 |
| 9 | hitchhiker's guide to corporate crisis
Везде бывают кризисные моменты. Резкие реорги, ухудшение внешней конъюнктуры, исчерпание источников роста, накопленные хронические проблемы, где количество перерастает в качество.
Находиться в этом не слишком приятно. Кто-то яркий незаметно уходит в тень. Кто-то спокойный все чаще нервничает. Кто-то нужный уходит в другую компанию. Все чаще слышишь шутки про «досидеть до вестингов». И наоборот, кто-то недобросовестный подымает голову и начинает действовать в мутной водице без оглядки на приличия и здравый смысл.
У нормальных неравнодушных людей в такой ситуации автоматически включается «бей или беги». Но оглядываясь назад на свой опыт, я прихожу к выводу, что такая активность часто только усугубляет ситуацию. Действительно иногда важно не увидеть себя в картинке будущего компании и выйти, или биться за сохранение статуса кво. Но далеко не всегда. Так как продолжать конструктивно работать, если чувствуешь, что что-то конкретно идет не так? Для себя я собрал несколько понятных практик на этот случай:
1/ трезво взглянуть на ситуацию
Иногда довольно сложно себе признать, что что-то фундаментально идет не так. Кажется что это просто вот этот конкретный мудак тебя выбесил, Или конкретная неудача выбила из колеи. Яростно наброситься на конкретную проблему, и сдвинуться на шаг ближе к выгоранию. Понять ситуацию и ее руткоз - первый шаг, чтоб не начать тонуть.
2/ свериться с окружением
Если вы достаточно долго где-то работаете, то неизбежно у вас складывается «мафия взаимного доверия». Более того очень частно она транзитивная: люди имеют невероятную чувствительность к близкой системе ценностей и складу ума и собираются в кучки. Так вот хорошо бы понять: вы одни в такой ситуации (и вас нужен личный план выгребания) или вы все вместе попали в глобальный замес? В идеале общаться с людьми и внутри и снаружи компании, чтобы понимать масштаб бедствия.
3/ избегать эмоциональных «рывков на подвиг»
Для амбициозных людей проблема - это призыв к действию на сверхусилиях. Иногда это действительно нужно сделать. Но важно не попасть в ловушку и не пойти на подвиг ради подвига. Нужно очень трезво взвесить выхлоп от своих жертв и избегать эскапизма через прыжки веры.
4/ собрать команду выживания
Худшее в такой ситуации - остаться один на один с проблемой. Собирайте банду единомышленников: спасательный круг взаимной поддержки и доверия, на котором вы выплывете из замеса. Ищите людей, в кругу которых вам не грозят внутренние конфликты, и с которыми вы хотите оказаться в завтра. Держитесь за них. Выдерживайте давление вместе. Остаться одному - значит быть жертвой.
5/ берегите энергию
Мы имеем свойство недооценивать глубину и масштаб бедствий, стоя на их пороге, поэтому необходимо очень взвешенно и разумно тратить свою энергию. Выкладываться в экзистенциальных вопросах. Не лезть в каждую драку. Энергия еще ой как пригодится.
6/ в кризисе команда нуждается в лидере как никогда
Именно кризисы раскрывают сильнейших лидеров. Именно лучшие лидеры честно скажут «мы попали в трудную ситуацию» и найдет правильные слова, чтобы команда почувствовала себя командой, а не беззащитными одиночками. Чем честнее коммуникации - тем больше шансов мобилизовать людей и выйти из трудностей победителями. Будьте со своими людьми.
Все совпадения в таймингах этого поста с реальными событиями (и подготовкой к IPO трех крупнейших вендоров LLM) - случайны, а персонажи - вымышлены. | 544 |
| 10 | Save the date!
А 29-го июня у нас в офисе Сева Викулин и компания проведут митап для мл инженеров про внедрение GenAI в операционку. Я очень рекомендую прийти, потому что будет минимум технодиснейленда, и максимум реальной работы:
- как строить контроль качества агентов на индустриальном масштабе
- как трансформировать бизнес процессы, чтобы они были AI-реди
- как сводить экономику инференса
- как строить рабочие системы поверх интерфейсов сотрудников
Мы в этом году намеренно вынесли эти темы с нашей большой конфы, чтобы собраться более узким кругом инженеров, занятых в задачах агентизации внутрянки больших компаний.
Ждём 👋 | 586 |
| 11 | sticker.webp | 18 |
| 12 |  Главная дилемма при агентизации бизнесов — какую адаптивность компаний к изменениям мы хотим сохранить.
Артём Бондарь, руководитель направления обработки естественного языка в Т-Банке рассказал на Т-дворе, что именно с этой стороны нужно оценивать потребности в ИИ-агентах.
«Либо мы строим очень хрупкую систему из очень жёстких процессов и получаем выгоду за счёт агентизации, либо мы оставляем возможность адаптироваться под среду, но тогда нам очень тяжело внедрять агентов, потому что они не понимают, как работают процессы и что делать в случае изменений»
Бизнесу нужно определиться с подходом: где
есть смысл внедрять агентов, а где важно сохранять гибкость.
@exploitex | 560 |
| 13 | Вот так вот душевно поболтали про тонкости агентизации. Там мы и про пузыри поговорили, и про причины овероптимизма части инженерного комьюнити в вопросе агентизации в его и вся (и почему эта задача существенно сложнее чем агентизировать кодинг или личную эффективность), а так же какие катаклизмы это может вызвать, если мы не перестанем шапкозакидательски относиться к трудоемкости внедрения ИИ в реальный бизнес. Все эти темы я и дальше планирую раскрывать, так что приходите на живые выступления тоже! | 505 |
| 14 |  А если вы завтра (6-го) собираетесь на Т-Двор, то залетайте в 16:00 в бар. Там я со стойки прогоню свой обычный rant про бестолковые внедрения AI, но не в формате тг поста, а вживую 💅 | 580 |
| 15 |  Операционная vs продуктовая компания
А в какой-то момент карьеры меня занесло в еком. Там надо было взять на себя управление алгоритмами закупками всего Яндекс маркета. Прогнозировать, выставлять заказы на поставщиков, давать прогнозы по выводу людей на склады.
Для меня, как инженера это был культурный шок. Я вышел под новый год, и нужно было быстро сварганить план закупки на весну: воспользоваться спадом заказов в январе перед резким ростом в феврале-марте (пребилд - кто знает тот знает). Наш прогноз считался примерно 9 часов, падал и ошибался, а надо было его пересобрать чтобы спрогнозировать на очень длинный горизонт и с кучей доп ограничений. Типо у тебя 5-6 попыток. Это было время когда мы заканчивали работать в 3 ночи и вставали в 9 чтобы посмотреть результаты по последней итерации. Команда работала сменами, я без. У нас в итоге нихера не вышло, и операции пошли строить на икселях (это всегда последний рубеж обороны). Но сдружиться - сдружились.
Наверное самый дикий шок - это то, насколько это сложная система, где все влияет на все. Кто-то открутил тв кампанию, но не занес ее сроки в источники? Поздравляю! Алгоритмы на другом конце компании решили что этот скачок спроса - это органика и привезёт на склад две тонны цикория. Починили заказ руками? Классно, но план найма людей на склады уже ушел, так что скоро туда выйдет толпа работяг пинать известно что. Кто-то решил что умнее алгоритма и решил привезти себе товаров побольше на пару единичек? Ну класс, из-за изменившегося количества палет к нам теперь едет ни одна а две фуры. Кто-то попросил подкрутить закуп в алгоритме на высокий сезон ручным коэффициентом в 2 ночи субботы? Будь уверен про него все забудут, и он начнет жечь вам оборотку, когда вы снимите закрутки бюджета через пол года.
Проблема в том, что в екоме просто физически невозможно решить задачу оптимально. Ну то есть в теории то можно и даже не очень трудно. Но на практике - вокруг все горит огнём. Поэтому аккуратному инженеру здесь морально очень сложно. Кажется, что это просто сизифов труд, где ты строишь систему (с), а ее тебе всячески пытаются сломать.
А потом ты ловишь дзен и понимаешь, что единственный твой друг - это операционная аналитика. И только на нее ты можешь положиться, и вся твоя работа - это пристально смотреть на очередную аномалию, находить быстрое решение, и добавлять новую алерт-лампочку на свою приборную панель. Если повезет то можно еще и что-то системное сделать: мы вот перевели прогноз с деревьев на трансформеры.
Зато драйвово. Никогда я еще не чувствовал такой поддержки от инженерной и смежной бизнесовой команды, как там: мы реально были как братья по оружию. Ну и со многими людьми оттуда у меня остались очень теплые отношения.
Так что тяжело, не для всех, адреналиново, но очень интересно. | 648 |
| 16 | Стартапы
Из поста выше про стартапы внутри корпораций может показаться, что я считаю корпоративную жизнь отстойной, а стартапы классными. На эмоциональном уровне я действительно романтизирую предпренимательство, но как человек, который работал в двух seed, одном series B и одним выкупленным Самсунгом стартапе, я по умолчанию достаточно холодно отношусь к идее «го стартап замутим».
На мой взгляд есть только одна причина идти в стартап (здесь строго про компании, поднимающие венчурные деньги): строить продукт маржинальность/масштаб рынка которого прямо сейчас неинтересен крупным игрокам, но тренд/развитие технологии через какое-то время должны сделать эту модель ультра-прибыльной и масштабируемой. Часто через монополизацию зарождающегося рынка с сильным рвом.
В этом случае реально надо идти, потому что это шанс нанести огромный импакт, несопоставимый с тем что можно сделать в большой компании, спотыкаясь о «дилемму инноватора». Ну и заработать на этом лично гораздо больше. А вот остальные причины выглядят плохо:
1/ в корпе бюрократия, политика и ограничения, а в стартапе мы побежим быстрее и всех обгоним
Добежите до капиталоемкого этапа и придется всю эту бюрократию строить (на ходу и всрато). А если это В2В то там крупные продажи и внедрения - это тот еще аттракцион со всем выше перечисленным, помноженный на недоверие ребятам извне. Быстро пройденная первая миля ничего не гарантирует.
2/ в корпе дедовские технологии, а мы будем брать самые продвинутый тех
Организовать себе «лабу новых технологий» в большой компании на самом деле не так и сложно. Но если мы говорим про строительство бизнеса, то это может даже затормозить - будете тратить время на проблемы early adopter’ов. Стартапы берут на себя риски авангардных технологий не потому что они продвинутее, а потому что им нечего терять. Но сами риски необкатанной технологии никуда не деваются, и легко могут похоронить небольшую компанию.
3/ в стартапе все реально замотивированы и вкалывают, а не сидят и получают зп
Это замаскированный риск. Это означает, что каждый член команды в зоне повышенной нагрузки и если что-то случается вне работы (болезни, личные сложности), это очень сильно бьет по команде. Ну и первый кураж выветривается в среднем за пол года - у вас не так и много времени херачить. Поэтому в стартапах так любят молодых ребят до 25 без семьи. В целом норм, но сама по себе упорная работа это не гарантия успеха.
И самый главный момент: венчуры не дадут вам построить «просто хороший нишевый бизнес». Когда бизнесу дают деньги в долг под огромные иксы - в этом так-то нет ничего хорошего. Значит от вас ждут ультрауспех, и это хоронит обычные компании, которые могли бы лично вас кормить всю жизнь. В венчурном мире ты либо антропик, либо тебя нет.
Отсюда все эти непомерные риски во всех аспектах ведения бизнеса. И иногда эти риски надо на себя взять, но очень осознанно. Потому что венчурный инвестор - не ваш друг. Его задача столкнуть вас на максимально рискованный трек, дать нереалистичную капитализацию и поставить в нечеловеческие условия просто потому, что так работает их бизнес модель. И если начать смотреть на капитализацию как на долги перед акционерами, то это часто хорошо отрезвляет.
Если же очень хочется «свое», гораздо лучше набирать опыта, капитал и связи в найме, и на этой надувной лодке и плыть в свободное плавание с партнерами, не пинающими вас в сторону капитализации по мультипликатору 10-15. | 604 |
| 17 |  Инженерные vs продуктовые компании
Я свою карьеру начинал в компании Parallels: это ребята, которые строили виртуальные машины и контейнеры. Ты приходишь там в команду и первая твоя задача - это дописать кодовую базу за челом, который написал в одно лицо ключевые куски сетевого стека линукса. И MR в код которого до сих пор регулярно отклоняются мейнтейнерами ядра по причине «Alexey is a genius so we won’t touch this». Или к тебе, вчерашнему джуну, приходят и casually говорят «слушай, тут макось от нашего биоса непонятно чего хочет, можешь плз дизассемблировать из прошивку и разобраться в чем там дело» (оказалось эти пидорасы эпловцы засунули себе в биос png декодер, чтобы в режиме шифрования всего диска иметь возможность подгрузить из прошивки лого яблочка и показать его, пока диск расшифровывается. Мне это расследование стоило месяца жизни).
Первый мой серьезный MR (реализация файловой системы по спекам) отклоняли 14 раз. В офисе я сидел первые пару лет по 10-12 часов, просто потому что не хочется отставать. А еще потому что тебя затягивало в задачу. Я включал ambient, открывал дизассемблер или sublime, заваривал чай и пропадал на часы. Ехал домой и переваривал увиденное. Мне снился только код, переодически просыпался от кошмаров, где я все никак не мог выстроить в голове архитектурную картинку. Находил параллели, отращивал интуицию. Начал искренне хохотать при виде некоторых инженерных решений эпловских систем. С закрытыми глазами ориентировался в Intel software developers manual и помнил адреса доброй половины model specific registers.
Из инженерной компании и культуры меня выдернули амбиции и эстетика. Хотелось делать что-то красивое, технологичное и яркое. Понятно было, что в инженерной компании это сделать сложно, так что я ушел в продуктовую разработку.
Там ценности другие. Надо большую часть внимания переключить на клиента. Инженерные решения эпла перестали смешить. В Самсунге американские инженеры переодически били меня по рукам, и говорили, что я переусложняю - если инженерный вопрос можно залить ресурсами - надо заливать. На круг дешевле и быстрее выйдет. Все чаще я собирал решения из готовых блоков, а не писал что-то сам. Зато открылся целый дивный новый мир дизайна, маркетинга и финансов. И безусловно потребность делать яркие красивые вещи тут закрыть гораздо проще.
Но бекграунд дает о себе знать. Даже как-то неловко себя чувствуешь, когда на калибровке синьерный инженер рассказывает о невероятной технической сложности решения, которое в инженерной компании сделал бы джун за пару дней. Или искренне недоумеваешь, почему хеды разработки в таких деталях начинают обсуждать техничеку - камон это же все очевидно, линейные ребята такое должны с закрытыми глазами нормально делать. Давайте бизнес обсуждать.
Но особенно приятно встретить своих людей. Когда топ менеджер внезапно подхватывает твою историю про технологию спекулятивного исполнения и рассказывает в чем прикол верилога. Или другой хихикает с тобой, когда шутишь про «фабрики бобов».
Ни одна из культур точно не лучше другой. Но в зависимости от личных целей важно понимать, куда идешь. | 626 |
| 18 | Успех
Мне засела в голову фраза крупного артиста (кого конкретно - врать не буду), что любому артисту важно хоть раз в жизни почувствовать успех. Я бы обобщил эту мысль на любые профессии с высоким риском и непропорциональной отдачей на единицу труда.
Артисты, писатели, политики, предприниматели, трейдеры - все живут в очень странном мире. Про особенности этого Экстремистана (в противовес Среднестану) прекрасно написал Талеб в «черном лебеде», но если вкратце, то одной из самых явных характеристик этого мира - это сумасшедшая диспропорция в отдаче на усилия между участниками индустрии. Winner takes it all в экстримстане (небольшое количество супер звезд и голодные оставшиеся артисты, топ-100 бизнесменов, владеющих почти 80% всех активов). Радует что в этой игре у тебя сильно больше одной попытки, но в зависимости от уровня амбиций можно всю жизнь пытаться и не получить ничего.
Инженерная карьера на мой взгляд берет элементы от обоих миров: с одной стороны у тебя всегда есть очень приятная несгораемая сумма, с другой стороны успешная технологическая карьера в силу местных законов масштабирования скорее развивается экспоненциально. Млщики с доступом к наибольшим точкам дистрибьюции решения могут создать ценности на несколько порядков больше чем их такие же талантливые коллеги, но с доступом к небольшому ручейку пользователей/финансовых потоков. Поддерживать в себе драйв в этой игре очень непросто. В какой-то момент ты начинаешь опираться на собственную компетентность и репутацию: с одной стороны тебя уже и так везде зовут, с другой стороны хочется попробовать свои силы в чем-то еще более сложном. Но до этого состояния надо как-то дожить через череду лишений и регулярных неудач.
Есть конечно токсичное топливо: очень хочется кому-то что-то доказать (как правило внутреннему родителю), но на этой ракете можно прилететь в дурку. И мне кажется тут классным внутренним огоньком может дать опыт «большого успеха».
Очень важно: субъективно большого. Не большого в сравнении с кем-то в общепринятых метриках. А такого, что тебя самого глубоко потрясло. У меня это была очень смешная вещь, которая поделила карьеру на др и после. Мы с другом как-то угарали и придумали приложение для iOS, которое тянет смешные криминальные новости со всей страны и зачитывает их голосом гугл-переводчика под бит «кровосток - биография». Пресс релиз подхватили, мы повисели на главной «ленты ру» (тогда еще было нестыдно) и получили два миллиона глаз, которые посмотрели на нашу приложуху. Я помню тот день как вчера: я сидел на работе, и каждую минуту обновлял счетчик DAU. А тот прирастал на сотни-тысячи людей каждую минуту. Я не мог вообще ничего делать, просто в какой-то бешеной эйфории сидел и обновлял счетчик, переодически вскакивал, нарезал круги по кабинету и садился назад.
С тех пор любые крупные достижения если честно кажутся всего лишь тенью того успеха. Но зато это чувство сделало меня легче и подвижнее. Проще меняю компании, проще беру на себя риски. И это чувство круто поддерживает в тяжелые моменты. В эти моменты ты понимаешь, что с тобой все в порядке, выводит из отчаяния в нормальное состояние, где уже можно проанализировать ошибки и встать назад в лыжню.
И есть очень просто способ лишиться такого успеха: достаточно просто не делать того, что дергает твои глубинные струны души. Мне кажется большим лукавством, когда люди говорят «ты должен сделать своей работой то, что любишь» - я не согласен с этим. Но важно дать пространство своей страсти, потому что успех на этом поприще может стать топливом во всех остальных областях жизни. | 629 |
| 19 | То есть вам нужно не закрывать своими руками каждый неправильный кейс, а дизайнить систему, в которой операционная команда сможет самостоятельно закрывать эти кейсы по очень хорошему курсу размена эффектов на усилия. Ваша система обречена если инженер должен будет своими глазами смотреть каждый отвал и писать каждый доп кейс в промпт. Так что работая над ошибками системы нужно дизайнить систему, в которой кто-то другой увидив глазами этот кейс сделал бы именно то, что вам нужно (добавил бы примером в тренировку, переразмеиил, добавил бы кубик в граф вычислений, etc).
У всех этих операционных процессов, обусловленных дизайном системы есть своя стоимость операции и отдача на усилия. И у зрелых команд гипотезы оцениваются не только по изменению метрики в моменте, а еще и по стоимости обслуживания процесса в долгосроке.
Если бы я мог вернуться к себе десятилетней давности, то я был дал ровно один совет: «каждый твой шаг в МЛ должен радикально снижать неопределенность». Если руководствоваться этим мотто, то здоровый воркфлоу мл проекта сложится сам собой. | 636 |
| 20 | R&D-стратегия
Когда я начинал заниматься МЛ, моя жизнь была полна страданий. Я пришел в область из софтверной инженерии, соответсвенно подходил к мл проектам, как к софтверным: декомпозировал большую задачу на маленькие, строил план работы и шел по нему. Такое планирование сверху вниз, где какие-то дизайн решения принимаются из идейных соображений на старте проекта, а уже потом обрастают конкретикой и кодом. Если архитектура хорошая - то проблем будет мало, если плохая - много.
Экзекьюшн таких проектов - тоже относительно прямолинейный. Выписываешь зависимости, рисуешь сосиски-ганты и идешь по нему. Риски закладываешь более длинными сосисками. Если проект более непонятный - дизайнишь помельче, планируешь покороче (вот вам и скрам). Если все ясно, или в проекте очень много дорогих взаимозависимостей - то можно и водопадом течь. Возможны пивоты, но вообще считаем, что в основном мы все делаем скорее правильно. Основные риски в том, что ты сам тактически где-то накосячишь.
Но с МЛ дело другое - там чаще риск в том, что задача в принципе не решаема в необходимых ограничениях. А во вторых это очень data-driven системы. Когда меня спрашивают «как нам строить агентов саппорта» мой ответ - не знаю. В зависимости от потока запросов вам могут подойти совсем разные решения. Худшее в такой парадигме - это выбрать какой-то один подход и изо всех сил пытаться его «докрутить». Вот когда я в такой парадигме работал я и страдал. Вроде вкладываешь героические усилия - а отдача нулевая. Поставил все фишки на один подход - а он не работает.
Первый ментальный сдвиг, который нужно на мой взгляд сделать, чтобы заниматься R&D - это отказаться от идеи, что ты можешь спланировать финальное решение на берегу. Начать мыслить гипотезами а не «планом победы». И в этом смысле план работ из ганта с финишной прямой превращается в серию экспериментов, результатом которой может быть и понимание, что задача не решаема.
Когда команда осознает это обычно они врезаются в следующую проблему: пространство гипотез почти бесконечно. Если ребята продвинутые, то хотя бы они понимают что предпочитать одни гипотезы другим нужно по метрикам. Но даже так: мл индустрия предлагает огромное количество примитивов, из которых можно строить решение, у каждого из примитивов десятки гиперпараметров и десятки способов наливать в эти кубики данные. Как в этом пространстве приоритизировать гипотезы и что должно дать критерием остановки по каждой из гипотез - неочевидно. А еще хуже, что критерий остановки самого проекта становится непонятен - всегда можно выдвигать новые гипотезы.
И вот тут команде нужен второй фазовый переход: переход к data-driven формированию и управлению списком гипотез. Для начала необходимо сформировать «прогресс-бар» проекта. Найти какую то метрику, значение которой полностью отражает готовность системы к работе. В идеале перенести ее в офлайн. Попробовать измерить ей самое простое решение. Получить значение 0% готовности (или повыше если повезет). А дальше анализировать все отвалы-ощибки системы. В проектах gen-ai можно буквально посмотреть на каждый отвал и на каждый отвал сформировать гипотезу, какое изменение системы позволит этого отвала избежать. В задачах персонализации/предиктивной аналитики скорее нужно смотреть не на отдельные точки, а на когорты/сигналы (хотя и на отдельные точки иногда очень полезно посмотреть для инсайтов). Но важно что все ваши гипотезы должны решать конкретную проблему системы, которую вы обнаружили на данных.
После этого фазового перехода у команд дела идут бодрее, но их может ждать следующая проблема: команде может не удастся кластеризировать все увиденные проблемы в достаточно общие, и ребята начинают заниматься патчворком. Накидывать конкретные примеры в промпты например. Это движет метрику вверх, но очень очень медленно. Ни конца ни края не видно, и команда просто забрасывает проект.
И вот тут нужен последний фазовый переход: успешный мл проект - это набор кубиков + операционных процессов над ними. | 559 |
