Артём обо всём

hitchhiker's guide to corporate crisis Везде бывают кризисные моменты. Резкие реорги, ухудшение внешней конъюнктуры, исчерпание источников роста, накопленные хронические проблемы, где количество перерастает в качество. Находиться в этом не слишком приятно. Кто-то яркий незаметно уходит в тень. Кто-то спокойный все чаще нервничает. Кто-то нужный уходит в другую компанию. Все чаще слышишь шутки про «досидеть до вестингов». И наоборот, кто-то недобросовестный подымает голову и начинает действовать в мутной водице без оглядки на приличия и здравый смысл. У нормальных неравнодушных людей в такой ситуации автоматически включается «бей или беги». Но оглядываясь назад на свой опыт, я прихожу к выводу, что такая активность часто только усугубляет ситуацию. Действительно иногда важно не увидеть себя в картинке будущего компании и выйти, или биться за сохранение статуса кво. Но далеко не всегда. Так как продолжать конструктивно работать, если чувствуешь, что что-то конкретно идет не так? Для себя я собрал несколько понятных практик на этот случай: 1/ трезво взглянуть на ситуацию Иногда довольно сложно себе признать, что что-то фундаментально идет не так. Кажется что это просто вот этот конкретный мудак тебя выбесил, Или конкретная неудача выбила из колеи. Яростно наброситься на конкретную проблему, и сдвинуться на шаг ближе к выгоранию. Понять ситуацию и ее руткоз - первый шаг, чтоб не начать тонуть. 2/ свериться с окружением Если вы достаточно долго где-то работаете, то неизбежно у вас складывается «мафия взаимного доверия». Более того очень частно она транзитивная: люди имеют невероятную чувствительность к близкой системе ценностей и складу ума и собираются в кучки. Так вот хорошо бы понять: вы одни в такой ситуации (и вас нужен личный план выгребания) или вы все вместе попали в глобальный замес? В идеале общаться с людьми и внутри и снаружи компании, чтобы понимать масштаб бедствия. 3/ избегать эмоциональных «рывков на подвиг» Для амбициозных людей проблема - это призыв к действию на сверхусилиях. Иногда это действительно нужно сделать. Но важно не попасть в ловушку и не пойти на подвиг ради подвига. Нужно очень трезво взвесить выхлоп от своих жертв и избегать эскапизма через прыжки веры. 4/ собрать команду выживания Худшее в такой ситуации - остаться один на один с проблемой. Собирайте банду единомышленников: спасательный круг взаимной поддержки и доверия, на котором вы выплывете из замеса. Ищите людей, в кругу которых вам не грозят внутренние конфликты, и с которыми вы хотите оказаться в завтра. Держитесь за них. Выдерживайте давление вместе. Остаться одному - значит быть жертвой. 5/ берегите энергию Мы имеем свойство недооценивать глубину и масштаб бедствий, стоя на их пороге, поэтому необходимо очень взвешенно и разумно тратить свою энергию. Выкладываться в экзистенциальных вопросах. Не лезть в каждую драку. Энергия еще ой как пригодится. 6/ в кризисе команда нуждается в лидере как никогда Именно кризисы раскрывают сильнейших лидеров. Именно лучшие лидеры честно скажут «мы попали в трудную ситуацию» и найдет правильные слова, чтобы команда почувствовала себя командой, а не беззащитными одиночками. Чем честнее коммуникации - тем больше шансов мобилизовать людей и выйти из трудностей победителями. Будьте со своими людьми. Все совпадения в таймингах этого поста с реальными событиями (и подготовкой к IPO трех крупнейших вендоров LLM) - случайны, а персонажи - вымышлены.

Save the date! А 29-го июня у нас в офисе Сева Викулин и компания проведут митап для мл инженеров про внедрение GenAI в операционку. Я очень рекомендую прийти, потому что будет минимум технодиснейленда, и максимум реальной работы: - как строить контроль качества агентов на индустриальном масштабе - как трансформировать бизнес процессы, чтобы они были AI-реди - как сводить экономику инференса - как строить рабочие системы поверх интерфейсов сотрудников Мы в этом году намеренно вынесли эти темы с нашей большой конфы, чтобы собраться более узким кругом инженеров, занятых в задачах агентизации внутрянки больших компаний. Ждём 👋

Главная дилемма при агентизации бизнесов — какую адаптивность компаний к изменениям мы хотим сохранить. Артём Бондарь, руководитель направления обработки естественного языка в Т-Банке рассказал на Т-дворе, что именно с этой стороны нужно оценивать потребности в ИИ-агентах. «Либо мы строим очень хрупкую систему из очень жёстких процессов и получаем выгоду за счёт агентизации, либо мы оставляем возможность адаптироваться под среду, но тогда нам очень тяжело внедрять агентов, потому что они не понимают, как работают процессы и что делать в случае изменений» Бизнесу нужно определиться с подходом: где есть смысл внедрять агентов, а где важно сохранять гибкость. @exploitex

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

А если вы завтра (6-го) собираетесь на Т-Двор, то залетайте в 16:00 в бар. Там я со стойки прогоню свой обычный rant про бестолковые внедрения AI, но не в формате тг поста, а вживую 💅

Операционная vs продуктовая компания А в какой-то момент карьеры меня занесло в еком. Там надо было взять на себя управление алгоритмами закупками всего Яндекс маркета. Прогнозировать, выставлять заказы на поставщиков, давать прогнозы по выводу людей на склады. Для меня, как инженера это был культурный шок. Я вышел под новый год, и нужно было быстро сварганить план закупки на весну: воспользоваться спадом заказов в январе перед резким ростом в феврале-марте (пребилд - кто знает тот знает). Наш прогноз считался примерно 9 часов, падал и ошибался, а надо было его пересобрать чтобы спрогнозировать на очень длинный горизонт и с кучей доп ограничений. Типо у тебя 5-6 попыток. Это было время когда мы заканчивали работать в 3 ночи и вставали в 9 чтобы посмотреть результаты по последней итерации. Команда работала сменами, я без. У нас в итоге нихера не вышло, и операции пошли строить на икселях (это всегда последний рубеж обороны). Но сдружиться - сдружились. Наверное самый дикий шок - это то, насколько это сложная система, где все влияет на все. Кто-то открутил тв кампанию, но не занес ее сроки в источники? Поздравляю! Алгоритмы на другом конце компании решили что этот скачок спроса - это органика и привезёт на склад две тонны цикория. Починили заказ руками? Классно, но план найма людей на склады уже ушел, так что скоро туда выйдет толпа работяг пинать известно что. Кто-то решил что умнее алгоритма и решил привезти себе товаров побольше на пару единичек? Ну класс, из-за изменившегося количества палет к нам теперь едет ни одна а две фуры. Кто-то попросил подкрутить закуп в алгоритме на высокий сезон ручным коэффициентом в 2 ночи субботы? Будь уверен про него все забудут, и он начнет жечь вам оборотку, когда вы снимите закрутки бюджета через пол года. Проблема в том, что в екоме просто физически невозможно решить задачу оптимально. Ну то есть в теории то можно и даже не очень трудно. Но на практике - вокруг все горит огнём. Поэтому аккуратному инженеру здесь морально очень сложно. Кажется, что это просто сизифов труд, где ты строишь систему (с), а ее тебе всячески пытаются сломать. А потом ты ловишь дзен и понимаешь, что единственный твой друг - это операционная аналитика. И только на нее ты можешь положиться, и вся твоя работа - это пристально смотреть на очередную аномалию, находить быстрое решение, и добавлять новую алерт-лампочку на свою приборную панель. Если повезет то можно еще и что-то системное сделать: мы вот перевели прогноз с деревьев на трансформеры. Зато драйвово. Никогда я еще не чувствовал такой поддержки от инженерной и смежной бизнесовой команды, как там: мы реально были как братья по оружию. Ну и со многими людьми оттуда у меня остались очень теплые отношения. Так что тяжело, не для всех, адреналиново, но очень интересно.

Стартапы Из поста выше про стартапы внутри корпораций может показаться, что я считаю корпоративную жизнь отстойной, а стартапы классными. На эмоциональном уровне я действительно романтизирую предпренимательство, но как человек, который работал в двух seed, одном series B и одним выкупленным Самсунгом стартапе, я по умолчанию достаточно холодно отношусь к идее «го стартап замутим». На мой взгляд есть только одна причина идти в стартап (здесь строго про компании, поднимающие венчурные деньги): строить продукт маржинальность/масштаб рынка которого прямо сейчас неинтересен крупным игрокам, но тренд/развитие технологии через какое-то время должны сделать эту модель ультра-прибыльной и масштабируемой. Часто через монополизацию зарождающегося рынка с сильным рвом. В этом случае реально надо идти, потому что это шанс нанести огромный импакт, несопоставимый с тем что можно сделать в большой компании, спотыкаясь о «дилемму инноватора». Ну и заработать на этом лично гораздо больше. А вот остальные причины выглядят плохо: 1/ в корпе бюрократия, политика и ограничения, а в стартапе мы побежим быстрее и всех обгоним Добежите до капиталоемкого этапа и придется всю эту бюрократию строить (на ходу и всрато). А если это В2В то там крупные продажи и внедрения - это тот еще аттракцион со всем выше перечисленным, помноженный на недоверие ребятам извне. Быстро пройденная первая миля ничего не гарантирует. 2/ в корпе дедовские технологии, а мы будем брать самые продвинутый тех Организовать себе «лабу новых технологий» в большой компании на самом деле не так и сложно. Но если мы говорим про строительство бизнеса, то это может даже затормозить - будете тратить время на проблемы early adopter’ов. Стартапы берут на себя риски авангардных технологий не потому что они продвинутее, а потому что им нечего терять. Но сами риски необкатанной технологии никуда не деваются, и легко могут похоронить небольшую компанию. 3/ в стартапе все реально замотивированы и вкалывают, а не сидят и получают зп Это замаскированный риск. Это означает, что каждый член команды в зоне повышенной нагрузки и если что-то случается вне работы (болезни, личные сложности), это очень сильно бьет по команде. Ну и первый кураж выветривается в среднем за пол года - у вас не так и много времени херачить. Поэтому в стартапах так любят молодых ребят до 25 без семьи. В целом норм, но сама по себе упорная работа это не гарантия успеха. И самый главный момент: венчуры не дадут вам построить «просто хороший нишевый бизнес». Когда бизнесу дают деньги в долг под огромные иксы - в этом так-то нет ничего хорошего. Значит от вас ждут ультрауспех, и это хоронит обычные компании, которые могли бы лично вас кормить всю жизнь. В венчурном мире ты либо антропик, либо тебя нет. Отсюда все эти непомерные риски во всех аспектах ведения бизнеса. И иногда эти риски надо на себя взять, но очень осознанно. Потому что венчурный инвестор - не ваш друг. Его задача столкнуть вас на максимально рискованный трек, дать нереалистичную капитализацию и поставить в нечеловеческие условия просто потому, что так работает их бизнес модель. И если начать смотреть на капитализацию как на долги перед акционерами, то это часто хорошо отрезвляет. Если же очень хочется «свое», гораздо лучше набирать опыта, капитал и связи в найме, и на этой надувной лодке и плыть в свободное плавание с партнерами, не пинающими вас в сторону капитализации по мультипликатору 10-15.

Инженерные 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. Из инженерной компании и культуры меня выдернули амбиции и эстетика. Хотелось делать что-то красивое, технологичное и яркое. Понятно было, что в инженерной компании это сделать сложно, так что я ушел в продуктовую разработку. Там ценности другие. Надо большую часть внимания переключить на клиента. Инженерные решения эпла перестали смешить. В Самсунге американские инженеры переодически били меня по рукам, и говорили, что я переусложняю - если инженерный вопрос можно залить ресурсами - надо заливать. На круг дешевле и быстрее выйдет. Все чаще я собирал решения из готовых блоков, а не писал что-то сам. Зато открылся целый дивный новый мир дизайна, маркетинга и финансов. И безусловно потребность делать яркие красивые вещи тут закрыть гораздо проще. Но бекграунд дает о себе знать. Даже как-то неловко себя чувствуешь, когда на калибровке синьерный инженер рассказывает о невероятной технической сложности решения, которое в инженерной компании сделал бы джун за пару дней. Или искренне недоумеваешь, почему хеды разработки в таких деталях начинают обсуждать техничеку - камон это же все очевидно, линейные ребята такое должны с закрытыми глазами нормально делать. Давайте бизнес обсуждать. Но особенно приятно встретить своих людей. Когда топ менеджер внезапно подхватывает твою историю про технологию спекулятивного исполнения и рассказывает в чем прикол верилога. Или другой хихикает с тобой, когда шутишь про «фабрики бобов». Ни одна из культур точно не лучше другой. Но в зависимости от личных целей важно понимать, куда идешь.

Успех Мне засела в голову фраза крупного артиста (кого конкретно - врать не буду), что любому артисту важно хоть раз в жизни почувствовать успех. Я бы обобщил эту мысль на любые профессии с высоким риском и непропорциональной отдачей на единицу труда. Артисты, писатели, политики, предприниматели, трейдеры - все живут в очень странном мире. Про особенности этого Экстремистана (в противовес Среднестану) прекрасно написал Талеб в «черном лебеде», но если вкратце, то одной из самых явных характеристик этого мира - это сумасшедшая диспропорция в отдаче на усилия между участниками индустрии. Winner takes it all в экстримстане (небольшое количество супер звезд и голодные оставшиеся артисты, топ-100 бизнесменов, владеющих почти 80% всех активов). Радует что в этой игре у тебя сильно больше одной попытки, но в зависимости от уровня амбиций можно всю жизнь пытаться и не получить ничего. Инженерная карьера на мой взгляд берет элементы от обоих миров: с одной стороны у тебя всегда есть очень приятная несгораемая сумма, с другой стороны успешная технологическая карьера в силу местных законов масштабирования скорее развивается экспоненциально. Млщики с доступом к наибольшим точкам дистрибьюции решения могут создать ценности на несколько порядков больше чем их такие же талантливые коллеги, но с доступом к небольшому ручейку пользователей/финансовых потоков. Поддерживать в себе драйв в этой игре очень непросто. В какой-то момент ты начинаешь опираться на собственную компетентность и репутацию: с одной стороны тебя уже и так везде зовут, с другой стороны хочется попробовать свои силы в чем-то еще более сложном. Но до этого состояния надо как-то дожить через череду лишений и регулярных неудач. Есть конечно токсичное топливо: очень хочется кому-то что-то доказать (как правило внутреннему родителю), но на этой ракете можно прилететь в дурку. И мне кажется тут классным внутренним огоньком может дать опыт «большого успеха». Очень важно: субъективно большого. Не большого в сравнении с кем-то в общепринятых метриках. А такого, что тебя самого глубоко потрясло. У меня это была очень смешная вещь, которая поделила карьеру на др и после. Мы с другом как-то угарали и придумали приложение для iOS, которое тянет смешные криминальные новости со всей страны и зачитывает их голосом гугл-переводчика под бит «кровосток - биография». Пресс релиз подхватили, мы повисели на главной «ленты ру» (тогда еще было нестыдно) и получили два миллиона глаз, которые посмотрели на нашу приложуху. Я помню тот день как вчера: я сидел на работе, и каждую минуту обновлял счетчик DAU. А тот прирастал на сотни-тысячи людей каждую минуту. Я не мог вообще ничего делать, просто в какой-то бешеной эйфории сидел и обновлял счетчик, переодически вскакивал, нарезал круги по кабинету и садился назад. С тех пор любые крупные достижения если честно кажутся всего лишь тенью того успеха. Но зато это чувство сделало меня легче и подвижнее. Проще меняю компании, проще беру на себя риски. И это чувство круто поддерживает в тяжелые моменты. В эти моменты ты понимаешь, что с тобой все в порядке, выводит из отчаяния в нормальное состояние, где уже можно проанализировать ошибки и встать назад в лыжню. И есть очень просто способ лишиться такого успеха: достаточно просто не делать того, что дергает твои глубинные струны души. Мне кажется большим лукавством, когда люди говорят «ты должен сделать своей работой то, что любишь» - я не согласен с этим. Но важно дать пространство своей страсти, потому что успех на этом поприще может стать топливом во всех остальных областях жизни.

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

R&D-стратегия Когда я начинал заниматься МЛ, моя жизнь была полна страданий. Я пришел в область из софтверной инженерии, соответсвенно подходил к мл проектам, как к софтверным: декомпозировал большую задачу на маленькие, строил план работы и шел по нему. Такое планирование сверху вниз, где какие-то дизайн решения принимаются из идейных соображений на старте проекта, а уже потом обрастают конкретикой и кодом. Если архитектура хорошая - то проблем будет мало, если плохая - много. Экзекьюшн таких проектов - тоже относительно прямолинейный. Выписываешь зависимости, рисуешь сосиски-ганты и идешь по нему. Риски закладываешь более длинными сосисками. Если проект более непонятный - дизайнишь помельче, планируешь покороче (вот вам и скрам). Если все ясно, или в проекте очень много дорогих взаимозависимостей - то можно и водопадом течь. Возможны пивоты, но вообще считаем, что в основном мы все делаем скорее правильно. Основные риски в том, что ты сам тактически где-то накосячишь. Но с МЛ дело другое - там чаще риск в том, что задача в принципе не решаема в необходимых ограничениях. А во вторых это очень data-driven системы. Когда меня спрашивают «как нам строить агентов саппорта» мой ответ - не знаю. В зависимости от потока запросов вам могут подойти совсем разные решения. Худшее в такой парадигме - это выбрать какой-то один подход и изо всех сил пытаться его «докрутить». Вот когда я в такой парадигме работал я и страдал. Вроде вкладываешь героические усилия - а отдача нулевая. Поставил все фишки на один подход - а он не работает. Первый ментальный сдвиг, который нужно на мой взгляд сделать, чтобы заниматься R&D - это отказаться от идеи, что ты можешь спланировать финальное решение на берегу. Начать мыслить гипотезами а не «планом победы». И в этом смысле план работ из ганта с финишной прямой превращается в серию экспериментов, результатом которой может быть и понимание, что задача не решаема. Когда команда осознает это обычно они врезаются в следующую проблему: пространство гипотез почти бесконечно. Если ребята продвинутые, то хотя бы они понимают что предпочитать одни гипотезы другим нужно по метрикам. Но даже так: мл индустрия предлагает огромное количество примитивов, из которых можно строить решение, у каждого из примитивов десятки гиперпараметров и десятки способов наливать в эти кубики данные. Как в этом пространстве приоритизировать гипотезы и что должно дать критерием остановки по каждой из гипотез - неочевидно. А еще хуже, что критерий остановки самого проекта становится непонятен - всегда можно выдвигать новые гипотезы. И вот тут команде нужен второй фазовый переход: переход к data-driven формированию и управлению списком гипотез. Для начала необходимо сформировать «прогресс-бар» проекта. Найти какую то метрику, значение которой полностью отражает готовность системы к работе. В идеале перенести ее в офлайн. Попробовать измерить ей самое простое решение. Получить значение 0% готовности (или повыше если повезет). А дальше анализировать все отвалы-ощибки системы. В проектах gen-ai можно буквально посмотреть на каждый отвал и на каждый отвал сформировать гипотезу, какое изменение системы позволит этого отвала избежать. В задачах персонализации/предиктивной аналитики скорее нужно смотреть не на отдельные точки, а на когорты/сигналы (хотя и на отдельные точки иногда очень полезно посмотреть для инсайтов). Но важно что все ваши гипотезы должны решать конкретную проблему системы, которую вы обнаружили на данных. После этого фазового перехода у команд дела идут бодрее, но их может ждать следующая проблема: команде может не удастся кластеризировать все увиденные проблемы в достаточно общие, и ребята начинают заниматься патчворком. Накидывать конкретные примеры в промпты например. Это движет метрику вверх, но очень очень медленно. Ни конца ни края не видно, и команда просто забрасывает проект. И вот тут нужен последний фазовый переход: успешный мл проект - это набор кубиков + операционных процессов над ними.

Любительский и профессиональный R&D Я наконец-то в полноценном отпуске с семьей. Плыву в бассейне и слышу, что музыка из двух уличных колонок играет в рассинхроне. Ну и думаю «бл*ть, чуваки you had ONE job». Ну типо если вы звукоинженеры есть считанное количество простых проблем, с которыми нужно фокусно справиться без всякой магии в стиле Рика Рубина. Как и в других профессиях, вот фотографы, например. Надо посмотреть, что тени всрато на лицо не падают, нет засветов, в кадре лишнего нет ничего, поза не выглядит как «одноног-однорук», да и все, уже норм (профи если че поправят в комментах). И общаясь с любыми профессионалами видишь одну и ту же картину: даже в творческих профессиях те сфокусированы натренерованным взглядом следить за считанным количеством ключевых вопросов, а не «экспериментируют на вдохновении». Есть прикольное исследование, где изучают любительский теннис и проходят к выводу: побеждают не самые виртуозные, а те, кто меньше ошибаются. И мне кажется это главное, чем должен быть занят профессионал: на 90% систематизировать стратегии борьбы с типичными проблемами и на 10% оставить место креативу. Я в своей карьере большую часть времени занимаюсь продуктовым и технологическим R&D, и есть очень очень простой тест, которым я отделяю любителей в этой области от профессионалов. И те и те выдвигают гипотезы. Но гипотезы профессионалов снижают уровень неопределенности тотального успеха проекта, а любительские - нет. Конкретика. Вот решили в какой-то продукт внедрять GenAI с агентами. С чего начинает большинство команд? «А давайте соберем агента для какого-то набора задач, которые мы выбрали из чувства прекрасного / потока запросов с поиска / с саппорта. Будет PoC, будет инфра, разберемся что лучше langflow или n8n, что нагрузку держит. Ну и пользователей запустим, они там нам поток своих реальных запросов нагенерят». Когда инфру непонятно как делать, наверное полезно понять, как удобнее ее строить. Но это вопрос на пару десятков процентов эффективности проекта, а не экзистенциальный вопрос «а можем ли мы вообще помочь пользователю агентами». Здравое зерно здесь только в кусочке «а какой поток запросов нам нальют в PoC». Но ответить на этот вопрос можно и без инженерных приседаний вообще, и плюс чаще всего пользователя нужно учить своему продукту, а не ждать, что те сами придумают ему креативное применение. Или же, если полный скоуп продукта ясен (например это автоматизация процесса), бросаются в другую крайность: возьмем одну атомарную операцию, сузим ее до одного частного кейса и его автоматизируем. Это чуть лучше, но все еще не дает информации о том, а можно ли автоматизировать процесс целиком. Ну чтоб быстро и стопроцентно получить пользу. Но простую операцию можно автоматизировать без агентов хорошим софтом. А дальше что? Сколько еще таких операций? Будет ли решение обобщаться на них? А что с предыдущим и следующим шагом? Помните игру акинатор? Там за минимальное количество вопросов система пыталась угадать загаданного игроком персонажа. Хороший руководитель R&D играет в такую же игру. Пытается как можно быстрее выйти к вопросу «какой процент распределения покрывает качественным решением моя текущая система» и отсюда же «в чем руткоз проблема каждого не набранного процентика». С этого оперативного простора можно уже действовать. И нейтан пробовать и прочие модные штучки. Так вот, у хорошего R&D-шника все нутро физически зудит, пока ответа на этот вопрос нет. И он (или она) не размениваясь на мелочи изо всех сил стремится на этот вопрос ответить. Не делает вид, что уже все понятно и нужно только разобраться, как быстрее всего добежать до цели. И по этой одержимости анализом общего распределения (запросов, времени, денег), вы и можете определить опытного r&d-шника.

Риск менеджмент МЛ стратегий Любую ML задачу можно решить двумя диаметрально противоположными методами: 1000 регулярок и мультиагентной системой на sota моделях. Мой хот тейк: и ничего другого пробовать не нужно. 80% усилий в проверенную технологию, которая дает предсказуемый результат на единицу усилий (но с падающей отдачей) и 20% в космическую еб**ину, которая скорее всего не полетит, но если полетит то с огромной отдачей на усилия. Все стратегии со средними рисками и средней отдачей - это ваш гроб, и делать их нужно в последнюю очередь от бедности. Причем этот принцип фрактально протекает и в сами стримы работ: в регулярках 80% усилий нужно потратить на отстройку тупого как лапоть операционного процесса создания регулярок, и 20% на всякие полуавтоматические методы с кластеризацией под капотом. В рискованном треке то же самое: 80% усилий в проверенную индустрией архитектуру агентской системы под ваш кейс и 20% в странную, но прикольную идею, которую принес млщик с постера на ICML. Обычно я углубляясь в аргументацию своих позиции, но конкретно этот принцип не опирается на логику - это эвртстика. Вот просто «Миша, мне п***й, я так чувствую». Если хочется аргументов - то можно прочесть Талеба, там он эту чуйку обосновывает личным опытом трейдера и своими концепциями антихрупкости. Такой подход отзывается не всем. Обычно любят одну из крайностей и приводят примеры тех, кто гиперсфокусированно поставил все на зеро (или наоборот не рисковал вообще) и выиграл. Но обычно это либо ошибка выжившего, либо это только тактика на отдельный отрезок времени (следущий или предыдущий отрезок времени - консервативная тактика). А еще чаще это скрытый профиль рисков: да, чел поставил всю котлету, но если че его или его родителей банковский счет вполне обеспечит неплохую жизнь при любом исходе. Или наоборот: чел вроде вообще спокойно движется по жизни и все получается - но скорее всего пару поколений назад кто-то крупно рискнул, чтобы больше рисковать было вообще не нужно. Так что тут надо в каждой ситуации копать поглубже. Так что так. Бейзлайн даст основной эффект. Еб**ина откроет новые горизонты. Средний риск и средняя отдача высосет из вас душу.

Angine de Poitrine - лучшее, что случалось с музыкой за последние лет 10. Отдельный вид спорта - шутки в комментах под их видео

Опааа, а кого это приняли на ACL рассказать про нашего ai-worker? Shout out фундаментальной команде и команде концепт-кара!

Наша редакция (в лице меня одного) начала получать гневные письма про этот пост,с посылом: «ты вот говоришь, стартап внутри корпорации невозможен - а мы тогда кто???». Пока мне не нацарапали нехорошие слова на машине - раскрою мысль. Новые продукты запускать корпорациям можно и нужно. Мы буквально окружены в повседневной жизни продуктами, запущенными внутри крупных компаний. И есть огромное количество областей, в которых ты получаешь непропорциональное неконкурентное преимущество используя активы компании изнутри. Например это действительно уникальные технологии, которые невозможно купить на открытом рынке. Или монополия на ключевые каналы дистрибьюции (изнутри за них придется побороться, а снаружи тебя к ним впринципе не подпустят). Административные рычаги, уникальные данные, неподьемные капексы на старте, you name it. Проблемы только две: когда продукт у которого нулевой ров за счет корпорации пытается гоняться с командами, которые не обременены вязкостью крупной компании и замотивированы на другом уровне. И когда людям, которые работали в реальных стартапах и понимают что такое свобода собственной компании (и ответственность), продают внутренни проект как стартап. Они приходят и получают обычную работу в крупной конторе, бьются головой о стены и в итоге демотивируются. Так что вот, любым работягам, работающим над дизраптами (в стартапах или нет) привет. Остальным соболезную.

Почему GenAI в кодинге работает круто, а в энтерпрайзе побед меньше Мне кажется любой, кто занимается внедрением GenAI в энтерпрайз сталкивается с тейком «вон клод уже сам написал компилятор С, а у нас до сих пор тысячи людей в операциях сидят. Давайте развернем, значит, OpenClaw и…». И на самом интересно, а почему в кодинге победы, а в энтерпрайзе нет? Питер Тиль говорил, что именно за такими противоречиями и скрываются миллиардные компании. У меня хоть масштаб и не такой, но вопрос стоит не менее остро. Для начала: а что мы вообще хотим от агентов? Принимать хорошие решения. И на низком уровне: какую mcp ручку дернуть и кнопку нажать на каждом конкретном шаге. И на высоком: как помочь клиенту, который не может сделать перевод в таджиктстан. Чтобы принимать хорошие решения мы опираемся на факты, комбинируя которые здравым смыслом, предсказываем, что произойдет с миром и нами от нашего выбора. Факты бывают разные. Верхнеуровневые: «мы не умеем переводить деньги в таджикистан», «если послать человека в жопу, он обидится». Низкоуровневые: «кнопка «платежи» на главной, открывает экран со всеми платежами, включая трансграничные», «если написать console.log(“hello”) в коде, то в логе появится запись hello». Общие для всех: «import “x.h”» добавит в модуль сигнатуры внешних объектов». Специфичные для организации: «лучше всех на второй линии проблемы с комплаенсом решает Иван Андреевич». Неизменные во времени: «Т-Банк основал Олег Тиньков». И изменяющиеся: «Сбером управляем Герман Греф». К чему я. Чтобы LLM смогла качественно решить проблему ей нужны ВСЕ верхнеуроаневые и низкоуровневые факты, необходимые для правильного решения. Эти факты могут лежать либо в весах, либо в контексте. Других вариантов нет. И именно в SDLC покрытие фактов в силу природы задачи самое хорошее: вся информация о языках программирования и инструментарии живет в весах LLM. Вся специфика задачи закодирована самой кодовой базой + инструкциями со стороны инженера, управляющего агентом. Остается сделать правильную организацию работы со всем этим контекстом, чтобы поехало. А в энтерпрайзе не так. Там половина регламентов живет в головах и передается из уст в уста. Базы знаний устаревают и противоречат реальному положению дел. Нет дешевых аналогов юнит и интеграционных тестов систем (а значит и reward сред). Так что просто дать модели все доступные ручки и накинуть RL не получится. Нет, она придумает бизнес процесс за вас, только результат вам не понравится. Что делать? Мы с командой уже несколько лет занимаемся внедрением ллм в операционные процессы и выработали очень простой rule-of-the-thumb. Хочешь успех: своди задачу к in-context. Думай как преобразовать процесс так, чтобы в каждый момент времени у модели была перед глазами вся необходимая информация для принятия решения. Переписывайте базы знаний, записывайте регламенты, дробите процессы на более простые. Стройте системы контекст инженеринга, которые все это подтягивают в горячий контекст. Именно это должно быть фокусом инженера, а не модные харнессы и архитектуры. Это мне кажется само по сеье интернсно: код - часто самая лучшая документация реальных бизнес процессов организации. «Банда четырех» в контексте прикладной разработки - это не столько про код per-se, сколько про управление сложностью. И мне кажется именно поэтому лучших результатов во внедрении GenAI добиваются именно инженеры (в широком смысле): все те вызовы, которые нужно решить внедряторам ИИ, мы уже сто раз видели в области software development. И когда я стал смотреть на плохие бизнес процессы, как на говнокод, внезапно все паттерны разработки софта оказались супер полезными метафорами и инструментами. Возвращаясь к оригинальному вопросу: разница именно в том, что в SDLC мы научились структурировать и описывать сложные процессы гораздо точнее, чем в классическом бизнесе. У мира софта очевидные ограничения - не любую проблему можно решить инженеркой. Но именно эта среда наиболее благодатна для агентизации. Как только ваш бизнес процесс станет похож на софтверную систему, он приобретает это же приятное свойство.

Стартап внутри корпорации Есть в корпоративном мире фразы и концепции «с душком». Вроде «мы не команда, мы - семья», «социально-ответственные компании» и многие другие you name it. Я обычно просто посмеиваюсь над ними, но вот «стартап внутри корпы» для меня как красная тряпка для быка. Я хотел было написать, что хочу чтоб это словосочетание перестали использовать, но, кажется, будет даже лучше, если продолжат. Так проще детектировать глупых либо недобросовестных людей. Откуда столько негодования? Классная же идея: взять лучшее от двух миров. Убираем риск за счет ресурсов корпы. Мой тейк: стартап в корпорации берет худшее от двух миров. Потому что ресурсы корпы ой как не бесплатны, а убирая риск мы убираем и свободу. Давайте с практической точки зрения: какие selling-points стартапа внутри корпы? Ну то, что у тебя останется свобода стартапа, но ты получаешь финансы корпы, доступ к технологиям и каналам дистрибьюции. И именно тут и зарыто противоречие: как только ты пытаешься воспользоваться любым из этих ресурсов - ты получаешь массу ограничений. Ну например технологии. Классно же: можно воспользоваться внутренними наработками. Но если они конкурентноспособны, то они и так, как правило, отправляются в В2В. Но скорее всего они узкоспециализированы и отстают от компаний, которые фокусно строят платформы. Нужные вам доработки будут теряться в беклогах, ваше время будут пожирать архитектурными комитетами, где необходимые вам фичи будут пытаться срезать до наименьшего общего знаменателя умнейшие СТО (которые получат бонус в конце года вне зависимости от ваших успехов). На ваш продукт будут нападать ушлые тех руководители под предлогом «вот вы ничего не умеете, давайте мы сами вам сделаем, к ку5 будет готово». Так что такой сетап на самом деле выгоден не стартапу, а корпе, которая экономит ресурсы. А это жопа: у стартапа и так риски выше крыши, так еще и корпа руками десятков технологических менеджеров устраивает оптимайз и политические разборки, связывая по рукам и ногам. Ладно, а дистрибьюция? Ну вообще говоря за эти каналы вы вступаете в конкуренцию с существующими продуктами. И те не горят желанием делиться ими. Если ваш продукт скорее гипотеза - они найдут миллион аргументов почему это говно и вас нельзя подпускать на выстрел к пользователям. Если ваш продукт очевидно хороший, то его начнут копировать на этом канале дистрибьюции. Скорее всего вам придется как-то объединяться с существующими игроками, что и размывает ваш контроль над продуктом. Решения становятся медленнее и хуже (за счет компромиссов). Финансы? Пожалуй ближе всего у правде, но опять же скорее всего с вас не снимут все контуры контроля за деньгами. Минимум - вы будете ходить на многочасовые ритуалы к CFO. Максимум - вы будете на общих основаниях включены во все системы управления фин потоками. Ваша стратегия компенсации будет кастрирована грейдами. Ваши закупки будут проходить комитеты комплаенса. Да и ваша собственная компенсация в итоге будет привязана к результатам стартапа весьма опосредованно. Ну и самое главное. Вы не рискуете собственной шкурой. Мне посчастливилось работать в двух успешных стартапах, которые стали устойчивыми компаниями и в обоих фаундеры рассказывали про runway на пару недель, массовые сокращения и пивоты. У ребят на полную катушку работали мозги, чтобы провести компанию по самой грани банкротства. Не было варианта отсидеться. И я верю, что именно поэтому у них все и получилось. Поэтому когда вот эти команды головорезов, которые ставят собственную шкуру на кон, сравнивают с сытыми корпоративными ребятами - мне смешно. Нет ничего плохого в том чтобы быть сытым (я вот после стартапов пошел просто денег заработать), но пытаться одно выдать за другое на мой взгляд либо глупость либо лицемерие. Надо называть вещи своими именами. Корпоративных стартапов не бывает. Есть проекты по запуску новых продуктов. И это норм: многие продукты невозможно запустить не находясь в экосистеме. Как и многие продукты невозможно нормально сделать внутри корпоративной среды. Так что давайте перестанем уже говорить про стартапы внутри корпы.

Бигтех сравнил виртуальных сотрудников Ровно через день после того, как «Яндекс» рассказал, что у них появился первый виртуальный сотрудник — Стефания, а мы предсказали, что эпоха ИИ-агентов в бигтехе сменяется эпохой виртуальных сотрудников, «Т-Банк» напомнил, что у них такой ИИ-сотрудник, правда, по имени Афанасий, работает уже год. Ссылку я не помню, но подтверждаю, что «Тшники» действительно рассказывали об этом на прошлой TurboML Conf. Правда, не Эльвире Набиуллиной, поэтому новость прошла незамеченной.

«У нас есть «концепт кар» — ИИ-сотрудник, который использует те же интерфейсы и инструменты, что и люди. Его зовут Афанасий Иванов (АИ), он работает в компании уже больше года и позволяет легко масштабировать нагрузку, что важно при росте бизнеса», — подтвердил сегодня на GoCloud руководитель направления обработки естественного языка (NLP) в центре искусственного интеллекта «Т-Банка» Артём Бондарь.