Лидерство и ИИ [Артем Бондарь]

R&D-стратегия

Когда я начинал заниматься МЛ, моя жизнь была полна страданий. Я пришел в область из софтверной инженерии, соответсвенно подходил к мл проектам, как к софтверным: декомпозировал большую задачу на маленькие, строил план работы и шел по нему. Такое планирование сверху вниз, где какие-то дизайн решения принимаются из идейных соображений на старте проекта, а уже потом обрастают конкретикой и кодом. Если архитектура хорошая - то проблем будет мало, если плохая - много.

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

Но с МЛ дело другое - там чаще риск в том, что задача в принципе не решаема в необходимых ограничениях. А во вторых это очень data-driven системы. Когда меня спрашивают «как нам строить агентов саппорта» мой ответ - не знаю. В зависимости от потока запросов вам могут подойти совсем разные решения. Худшее в такой парадигме - это выбрать какой-то один подход и изо всех сил пытаться его «докрутить». Вот когда я в такой парадигме работал я и страдал. Вроде вкладываешь героические усилия - а отдача нулевая. Поставил все фишки на один подход - а он не работает.

Первый ментальный сдвиг, который нужно на мой взгляд сделать, чтобы заниматься R&D - это отказаться от идеи, что ты можешь спланировать финальное решение на берегу. Начать мыслить гипотезами а не «планом победы». И в этом смысле план работ из ганта с финишной прямой превращается в серию экспериментов, результатом которой может быть и понимание, что задача не решаема.

Когда команда осознает это обычно они врезаются в следующую проблему: пространство гипотез почти бесконечно. Если ребята продвинутые, то хотя бы они понимают что предпочитать одни гипотезы другим нужно по метрикам. Но даже так: мл индустрия предлагает огромное количество примитивов, из которых можно строить решение, у каждого из примитивов десятки гиперпараметров и десятки способов наливать в эти кубики данные. Как в этом пространстве приоритизировать гипотезы и что должно дать критерием остановки по каждой из гипотез - неочевидно. А еще хуже, что критерий остановки самого проекта становится непонятен - всегда можно выдвигать новые гипотезы.

И вот тут команде нужен второй фазовый переход: переход к data-driven формированию и управлению списком гипотез. Для начала необходимо сформировать «прогресс-бар» проекта. Найти какую то метрику, значение которой полностью отражает готовность системы к работе. В идеале перенести ее в офлайн. Попробовать измерить ей самое простое решение. Получить значение 0% готовности (или повыше если повезет). А дальше анализировать все отвалы-ощибки системы. В проектах gen-ai можно буквально посмотреть на каждый отвал и на каждый отвал сформировать гипотезу, какое изменение системы позволит этого отвала избежать. В задачах персонализации/предиктивной аналитики скорее нужно смотреть не на отдельные точки, а на когорты/сигналы (хотя и на отдельные точки иногда очень полезно посмотреть для инсайтов). Но важно что все ваши гипотезы должны решать конкретную проблему системы, которую вы обнаружили на данных.

После этого фазового перехода у команд дела идут бодрее, но их может ждать следующая проблема: команде может не удастся кластеризировать все увиденные проблемы в достаточно общие, и ребята начинают заниматься патчворком. Накидывать конкретные примеры в промпты например. Это движет метрику вверх, но очень очень медленно. Ни конца ни края не видно, и команда просто забрасывает проект.

И вот тут нужен последний фазовый переход: успешный мл проект - это набор кубиков + операционных процессов над ними.

Риск менеджмент МЛ стратегий

Любую ML задачу можно решить двумя диаметрально противоположными методами: 1000 регулярок и мультиагентной системой на sota моделях. Мой хот тейк: и ничего другого пробовать не нужно. 80% усилий в проверенную технологию, которая дает предсказуемый результат на единицу усилий (но с падающей отдачей) и 20% в космическую еб**ину, которая скорее всего не полетит, но если полетит то с огромной отдачей на усилия. Все стратегии со средними рисками и средней отдачей - это ваш гроб, и делать их нужно в последнюю очередь от бедности.

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

Обычно я углубляясь в аргументацию своих позиции, но конкретно этот принцип не опирается на логику - это эвртстика. Вот просто «Миша, мне п***й, я так чувствую». Если хочется аргументов - то можно прочесть Талеба, там он эту чуйку обосновывает личным опытом трейдера и своими концепциями антихрупкости.

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

Так что так. Бейзлайн даст основной эффект. Еб**ина откроет новые горизонты. Средний риск и средняя отдача высосет из вас душу.

Angine de Poitrine - лучшее, что случалось с музыкой за последние лет 10. Анти-нейрослоп at its finest.

Отдельный вид спорта - шутки в комментах под их видео

Наша редакция (в лице меня одного) начала получать гневные письма про этот пост,с посылом: «ты вот говоришь, стартап внутри корпорации невозможен - а мы тогда кто???». Пока мне не нацарапали нехорошие слова на машине - раскрою мысль.

Новые продукты запускать корпорациям можно и нужно. Мы буквально окружены в повседневной жизни продуктами, запущенными внутри крупных компаний. И есть огромное количество областей, в которых ты получаешь непропорциональное неконкурентное преимущество используя активы компании изнутри. Например это действительно уникальные технологии, которые невозможно купить на открытом рынке. Или монополия на ключевые каналы дистрибьюции (изнутри за них придется побороться, а снаружи тебя к ним впринципе не подпустят). Административные рычаги, уникальные данные, неподьемные капексы на старте, 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) в центре искусственного интеллекта «Т-Банка» Артём Бондарь.

Попиарил тут нашу computer-use систему. Но важно понимать, что это была титаническая работа команды под лидерством Димы Битмана, чтоб это поехало и я вот так весело рассказывал. Нифига не дать модельке MCP.

Но есть другой путь. Строить карьеру не максимизируя метрики, а отталкиваясь от того, где вы хотите оказаться и какие проблемы хотите решать. Тогда тактика немного меняется:

1. Надо понять, а куда дальше по карьере вы хотите?
Хотя бы следующий шаг. Возможно честный ответ тут: я ничего не хочу менять, меня полностью устраивает моя позиция. Тогда скорее нужно наоборот поработать над тем, чтоб тратить минимум усилий и получать максимум результата. Если же хочется двигаться дальше, то хорошо бы разведать, а что там дальше, и правда ли это именно то, что вы хотите? Возможно гораздо лучше пивот в смежные специализации и не роста в вашей.

2. Узнать «а какие проблемы решают люди на позиции, на которую я хочу попасть»?
Это точно не «то же самое, что я делаю сейчас, но в два раза больше». Общайтесь, слушайте, подглядывайте за своим руководителем, примеряйте его проблемы на себя. Сталкиваясь с управленческим решением пытайтесь понять, какая опция выгоднее не с вашей, а с точки зрения вашего руководителя (и организации). Это кстати и чисто практически даст вам 100 очков в глазах вашего руководителя (вы перестанете создавать ему/ей мелкие неудобства).

3. Найти возможность решать подобные проблемы
Они могут быть меньшего масштаба, но сутево повторять своих братьев этажом выше. Вполне возможно, что вы уже их решаете, просто не вкладывая в них достаточно внимания. Что кстати очень часто: на более высоких позициях обычно решают менее приятные и понятные проблемы, так что всегда есть соблазн ими не заниматься, а делать то, что вам уже понятно и прикольно. Это кстати еще и прикольный тест драйв: а хотите ли вы на самом деле лезть дальше?

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

Headcount-maxxing

Внутри взрослого с виду лидера часто сидит ребенок, который хочет соревноваться и выигрывать. Соревноваться и кому-то что-то доказывать хочется по разными причинам, но я думаю немалая часть управленцев черпала топливо для карьерного роста оттуда. Особенно начинающие: кто поопытнее - заправляет свой бак более экологичным топливом (каким - дальше). Но вот незадача: взрослая карьера - это не школа и не институт. Тут нет циферки ЕГЭ, рейтингов вузов и других условно-объективных спортивных показателей, которыми можно сравнить себя с другими участниками соревнований. Остается только две цифры, за которые можно зацепится: чистая прибыль и headcount в подчинении (иногда позиция относительно СЕО в оргчарте - но это реже).

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

У этой стратегии есть несколько серьезных негативных сторон. Я не буду касаться психологических - это прямо отдельная тема, просто вполне прикладных.

Во-первых: часто эти две игры противоречат друг другу. Обычно в организации есть очень небольшое количество важных инициатив, которые принесут львиную долю эффектов. И на такие инициативы часто нужна не орава народу, а dream-team с сверхвысоким talent density. Остальные инициативы будут распылять фокус внимания, отвлекать сильных людей, и оглянувшись через несколько лет назад вы искренне не будете понимать, а почему вы закопали столько энергии а это. Все проекты, которыми я искренне горжусь были сделаны очень небольшой core командой (все простое и понятное - на аутсорс).

Во-вторых фокус на деньгах закрывает интересные возможности. Например одним из важнейших шагов в своей карьере я считаю запуск нашей командой опенсорс LLM. Ключевые люди индустрии признают, что мы тогда всколыхнули весь рынок, показав, что «так можно». Мы не заработали на этом денег вообще, но косвенные эффекты для компании оказались очень серьезными. С точки зрения долгосрочного развития существенно ценнее всех тех денег, что были затрачены. Если бы мы максимизировали PnL, то мы бы никогда этим не занимались бы.

И третье, самое важное: а правда ли это поможет с точки зрения долгосрочного карьерного плана? Когда вы начинаете общаться с топ-менеджерами компаний и людьми из советов директоров, вы замечаете, что они не смотрят на ваш хедкаунт, не слишком активно интересуются тем, сколько денег вы заработали. У них в голове есть очень конкретные изменения в организации, которые они хотят привести в жизнь. И им ваш трэк-рэкорд важен именно как примеры типов проблем, с которыми вы можете справиться. В этом смысле релевантность часто важнее масштаба. Как я неоднократно слышал: «если ты научился управляться с 15 людьми, то дальше особо ничего не меняется». Ловшука в том, что можно набрать себе кучу разрозненных активов, но если они не связаны общей сложной целью, то масштаб решаемой вами проблемы останется на уровне одной из этих команд, просто повторенной несколько раз. Без качественного скачка.

Пару слов про аплифт моделирование

То ли я криво ищу, то ли на тему индустриального аплифт моделирования преступно мало информации. Обычно пишут что: ну вот раздайте рандомно тритмент, часть данных в обучение, часть в холдаут, учите из стандартной либы 3 стандартных лёрнера и выберите тот, что выбивает наибольшую площадь под аплифт кривой. Если поковыряться поглубже, то можно найти про CATE, что он может быть не в конверсиях а в любой скалярной величине, и как выглядит лосс, чтобы напрямую оптимизировать CATE. На этом все.

А практика обычно такая: тебе надо не конверсии аплифтить, а денег заработать. И вот один твой товарищ построил аплифт в конверсиях (и потом предполагает его множить на средний LTV-скидка), а другой оптимизировал напрямую апдифт в LTV. Продуктовая команда настаивает, что раздавать надо по гороскопу (скидку всем девам). Принесли все они какие-то свои метрики в разных попугаях. И с этим чето надо делать.

Вот мой простой рецепт, что делать:

1. Зафиксируйте метрику приемки А/Б
Это в конечном итоге должна дать одна цифра по которой можно однозначно принять решение. В идеале LTV/cash-flow/PnL. А то оказывается что хочется и конверсия чтоб выросла и отток не нарастить и денег потратить не очень много, и нет однозначного понимания что делать если одна метрика выросла и другая упала. Тут стоит запариться и построить одну единственную метрику для оптимизации. Или одну таргет, вторую как boundary на крайний случай.

2. Соберите офлайн, который позволяет сравнивать разные стратегии раздачи тритмента (включая не аплифтовые)
По факту этот бенч должен давать оценку ожидаемой таргет метрики с прошлого шага на холдауте (сходиться хотя бы по матожиданию к ней). Причем для любой стратегии раздачи тритмента: не только ранжирующих всю базу, но и ту которая раздает тритмент по фазе луны. Любая стратегия на этот бенчмарк - это просто метки тритмента на каждого пользователя. Можно через пересечение с реальными наблюдениями получить оценку тотал эффекта, можно оценивать CATE в когорте - выбирайте где дисперсия меньше.

3. Пробуйте декартово произведение разных лернеров на разные таргеты
Это прямо рутина аплифта. Нет никакого идеального лернера и идеального подхода к выбору таргета. Иногда скалярный таргет слишком шумный и лучше разбить на конверсионный аплифт и помножить потом на скаляр. Иногда лучше учить аплифт сразу на таргет. Надо экспериментировать.

4. Выбирайте модель и когорту по своим бизнес требованиям а не про квини и аплифт кривой
Мой хот тейк: если ты решаешь индустриальную задачу, то забудь про рок ауки и прочие площади под кривыми. Это для учебников. У тебя есть либо ограничение по количеству тритмента: тогда сравнивай модели по uplift@k а в когорту бери K. Либо у тебя задача максимизировать аплифт без ограничения: тогда бери argmax_k(uplift@k) пользователей в когорту, а сравнивай модели по max(uplift@k). Ну либо выбирай k вообще перебором об финальный бенч с шага 2 (что кстати правильнее всего, с точностью до дисперсии).

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

6. Постепенная раскатка
Если не уверены в себе: то запустите не на всю базу а не 10% базы. Так у бережете себя от сильного даунлифта, а если все будет хорошо: то доберете следующим скорингом.

Вот как-то так и выживаем. Ну и Casual inference - это один из последних оплотов classical ml, где происходит что-то интересное: искренне рекомендую почитать статейки 20-х годов (этого века) на эту тему.

Стиль

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

Там конечно много интересных ньюансоа, но есть еще одна вещь прямо на поверхности: это стиль.

Итак, заходим на сайт sequoia capital (их вспомнил, потому что как раз товарищ по Самсунгу туда перешёл): https://sequoiacap.com/our-team/?_role=seed-early

Интерьеры. Натуральное дерево, книги, фото, солнечно, почти в каждом кадре живая зелень. Каждый хорошо чувствует свой стиль. Если чел в пиджаке будет выглядеть как Скрудж-макдак, то одевает поло. Если в футболке будет выглядеть как продавец подержанных пикапов - одевает классический пиджак, но чтоб не было душно - рубашка с интересным принтом. Ну и если опиджачиваемся, то это нетипичный расслабленный крой / кожанка / пальто. Очки под форму лица. Девченки одеты ярко, но не вызывающе. Все улыбаются, взгляд открытый. Объектив не широкоуголит, лица выглядят классно и естественно. Ярко и насыщено.

Теперь смотрим «у нас есть венчуры дома». Ссылки оставлять не буду, чтоб никого не обижать. Но загуглите любой на ваш вкус, я вам гарантирую, что увидите одно и то же.

Фона на фото нет. Вернее просто белый фон, как на паспорт. Может и к лучшему - там бы было серое ублюдство из стекла, крашеного дсп и палок-светилтников под потолком. Одежда - либо офисный работник в пиджаке и галстуке, либо однотонный пуловер в стиле «я из органов». Рубашки у всех поголовно не по размеру - огромные или наоборот мелкие манжеты и воротники. И у мужчин и у женщин. Ткань дешевая, отливает нездоровым синтетическим блеском. Выражение лица - Slavic stare, объектив не подходит для портретных фото, свет отвратительно выставлен и просто засвечивает и без того бледную кожу в плоский блин. Ну чисто стареющий офисный менеджер. Как будто из каста сериала «офис».

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

Ясно, что в среднем по больнице у нас не все хорошо со вкусом: когда тебя каждые десять лет трясет, не до стиля. Но блин, вы же венчуры, вы вроде как десятками-сотнями миллионов долларов крутите. Неужели нельзя съездить пару раз в долину для вдохновения, найти стилиста и дизайнера не-колхозоида, который хоть раз был во и в музее Прадо и в новой Третьяковке. Почему надо превращать все в газпром или «молодежный пластиковый офис». У нас куча исторических зданий, уникальная архитектура, своя глубокая история передовой науки и предпринимательства. Хочешь дореволюционных купцов-старообрядцев переосмысляй, хочешь авангард, хочешь советскую научную среду at its prime. Нет, блядь, хотим на белой площади и чтоб все в пластик закатано, да минималистично. Пластмассовый мир.

Вкус ведь не про моду и картинку, а про умение видеть и ценить сложное. Ценить антихрупкость. Дешевые материалы в моменте могут выглядеть очень ярко и круто, но стареют и устаревают они очень плохо.

Что я вообще хочу этим сказать? Мне кажется наша культура очень любит суть. И это здорово. Но кажется, что эта самая суть вполне заслуживает быть облаченной в более изящную форму.

Найм: на позицию или на задачу

Как я писал выше, первые шаги в управлении я делал в стартапе. Там я на своей шкуре почувствовал, что ошибки найма в стартапе имеют максимально разрушительные последствия (мне кажется на корпоративные деньги - это как ошибиться в найме топ менеджера). Поэтому я много экспериментировал с рекурутментом, нарабатывал подходы и обдумывал ошибки. Уже в последних своих стартапах я нанимал достаточно осмысленно, и секрет успеха всегда был в том, что я брал человека на конкретную задачу.

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

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

Такая среда очень расслабляет: я по себе знаю, что есть соблазн просто посмотреть на цифру грейда, и несложной калькуляцией брать любого кто набрал достаточную. И это очень плохая идея. Мне кажется любому руководителю важно понимать: корпоративный найм НЕ ВАШ ДРУГ. Я это пишу, как человек, который отстроил найм NLP в Т. Найм в корпе решает задачи корпорации за счет нанимающего менеджера. Поэтому ваша задача каждый раз самостоятельно строить процесс найма, осторожно опираясь на результаты стандартных секций (скорее воспринимать их как общую проверку на вшивость).

Как конкретно это сделать? Для этого берём вашу ключевую бизнесовую цель. Раскладываем ее на конкретные активности, необходимые для достижения. Смотрим, какие для этих активностей нужны компетенции. Берём текущую команду (включая себя) и закрашиваем все компетенции, которые сейчас командой закрыты. А вот недостающие и надо закрывать внешним кандидатом. Под каждую компетенцию можно придумать проверочный вопрос. Для краткосрочных проектов там будут больше Харды. В долгосрочных начнут появляться более софтовые. Часть компетенций можно проверить стандартными секциями, а часть надо проверить самостоятельно.

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

Орнул с того, как технодемка-генератор-видео-по-картинке, которую дали вот щас потыкать ребята на SnowBase идеально проиллюстрировала пост выше

Я попытался написать эссе с помощью Opus, так что вам не придется

Меня с момента старта канала несколько человек спросили "а зачем ты вообще этим занимаешься?". И честный ответ: не знаю. Мне нравится умничать и я получаю удовольсвтие, когда получается кого-то этим развлечь. Наверное вот по этому. Так что в этом смысле эксперимент из заголовка поста, мне сразу казался сомнительным. Но из научного интереса решил попробовать текнолоджис в задачке, которая вызывает у меня яркие и живые эмоции. Забегая вперед - получилась полная ерунда, но кое-что полезное я для себя нашел.

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

Получалось плохо: очень длинно, то слишком сухо, то патетично (и везде длинные тире, лол). При этом там были некоторые прикольные примеры конкретных практик, которые я даже решил взять на вооружение. Было очень заметно, что текст какой-то обезличенный что-ли? Я попросил добавить в текст автора, но Opus ограничился одном предложением, описывающем вымышленную ситуацию, в которую я якобы попал - дальше пластик. При этом по фактологии было даже неплохо. Где-то не хватило глубины, или классных ярких сравнений. Сутево мысль то он раскрыл с десятого пинка. Но читать это было неинтересно.

Я вот даже думал: а в чем дело? И понял, что я когда читаю этот текст, я не вижу за ним автора. Там все описано как на википедии. По делу, сухо, но без эмоции и личного опыта. Я еще поигрался, пытался привнести этот дух в текст, задушив опус командами, но у меня ничего не поулчилось. Читать все это просто неинтересно.

При этом, пользу я кстати увидел. Опус сгенерировал действительно прикольную тему (хотя и сам не понял в чем сутевой конфликт внутри этой темы). Опус подкинул прикольыне конкретные примеры практик и иллюстраций. Короче отработал как классный брейншторм-партнер и классная семантическая поисковая система фактов.

Тут на SnowBase Витя Тарнавский сидя на барной стойке, рассказывал, что CTO скоро будут больше не нужны, и надо будет придумать себе через несколкьо лет новое занятие. Вот на случай такого апокалиптического развития событий я думаю я нашел себе полянку "развлекателя байками". На этом попроще опус особо не впечатлил.

UPD: я надеюсь вы мне на слово не верите, и если вам важно, то сами пошли курить законопроект. Потому что я не описал важный ньюанс:
- есть суверенные модели, это те которые полностью обучались в РФ, читай гигачат. Им честь и хвала.
- есть доверенные модели. Это те, которые прошли сертификацию у уполномоченных исполнительных органов и попали в реестр доверенных. Суверенные-национальные почти по определению попадают в список доверенных. Остальные надо как-то в этот реестр заводить. Как - естественно пока не понятно, это уже конкретные органы должны решать. И все кто является критической гос инфрой или работают с ней должны использовать эти доверенные модели которые хотстятся у нас (привет Клод Код). Банки вот критическая инфраструктура - нас это например касается.

Так что ключевой момент там - это как будет устроен этот реестр, потому что пока он описан в виде «мы за все хорошее, просто против шпионажа и диверсий, фсб разберется». А на практике надо будет смотреть как эта процедура реально будет работать .

Прочитал законопроект по регулированию ИИ в России, так что вам не придется

Читаем оригинал. Новости на эту тему не рекомендую читать, там пишут фигню. Если вас это касается, то лучше почитайте сами, потому что я смотрел внимательно только на куски, которые непосредственно могут влиять на мои команды. Какие для себя забрал хайлайты.

1. Вводится понятие доверенных моделей. Могли бы и сразу написать прямым текстом «гигачат» лол. Во всех гос органах и на критической инфраструктуре теперь можно использовать только модели, все стадии тренировки которых проводились в РФ гражданами РФ. И описана куча регуляторки по опразрачиванию данных и регламентов для ФСО/ФСБ, Коммерческие компании не обязаны использовать суверенные модели (по крайней мере я такого не увидел).

2. Информирование и возможность отказаться от ии
Нужно всегда подсвечивать, если в рамках предоставление услуги решения принимает автономно ии без участия человека, за исключением случаев когда это и так очевидно. Что интереснее у пользователя должен быть механизм отказа от ии и получения сервиса через человека. Тут с одной стороны как-то кисло, с другой стороны есть опыт Британии, где запретили авторассылки, и там в итоге сидят специально обученные люди, которые прокликивают не глядя все эти рассылки, чтоб формально выполнять требования.

3. Регулирование сгенерированного континента
Кстати норм тема: сгенерированный контент надо маркировать. Требует явно регламентировать права собственности по всей цепочке использования моделей. Короч вроде норм.

4. Ответственность за косяки моделей
Вот тут интересно: оператор сервиса на базе модели может предъявить иск создателю модели, если оператор принял «все разумные средства предосторожности» а модель все равно накосячила и нанесла ущерб пользователю. С опенсорсом/В2В кажется что станет интереснее и надо будет поработать с юристами плотно.

Резюмируя: могло быть сильно хуже.

Про нетворкинг

Я раньше себя насилу выпихивал «нетворкаться». Списывал своё нежелание на интровертность, но честно тянул эту лямку. Как часто бывает в таких случаях оказалось все скорее в том, что я не понимал в какую игру играю, и просто формально повторял за ребятами поопытнее.

Вот инвестор мой из одного из стартапов. Постоянно был на встречах со всякими заряженными ребятами. Было ощущение, что у него везде друзья и знакомые. Ну и я поверхностно считал, что ну вот просто такой вот дружелюбный харизматичный чувак: не имеет сто рублей, а имеет сто друзей. И время от времени действительно обналичивает свой социальный капитал.

Но как это повторить, я совершенно не понимал. Вот встречаешься ты с каким-то товарищем, который обладает ресурсом полезным, а о чем вообще с ним говорить? Можно конечно и «ни о чем», но так удерживать внимание вообще-то непросто. Дружить? Извините, дружить это вообще-то совсем другое дело. Дружить, это когда человек интересен тебе настолько, что ты готов его боль на себя примерить, а не просто анекдотами обменяться. А на это ты готов только если в этом другом человеке какой-то ответ для тебя важный есть. Иначе ты сидишь и просто все нутро протестует и кричит «что мы здесь делаем».

Дружить в общем не получается. Можно конечно просто на интуиции действовать, но скорее получится психологическими травмами притянуть к себе людей, и разумеется совсем не тех. А чем тогда заниматься? О чем вообще говорить? О чем говорят нетворкеры? А главное, что должно произойти после такого разговора?

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

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

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

Эта классическая simple but not easy мысль открывает совсем новые правила игры. Ты начинаешь больше спрашивать у людей про потребности, больше интересоваться, кто чем занимается, прогнозировать а кто чем будет обладать на каком-то горизонте. Строить более богатый граф в голове, пытаясь соединить неожиданные вершины в выигрышных комбинациях.

А вот тогда в эту игру играть уже интересно даже просто ради самой игры. Чего всем вам и желаю! (Я то все равно нетворкаться не пойду - я правда интроверт).

В догонку прикольная статья на эту тему (особенно респект чуваку, за то что помнит Joel’s test on software): https://www.antifound.com/posts/codegen-is-not-productivity/

Товарищ там немного предвзят: очевидно он большую часть карьеры работал над критичными системами крупных проектов. Если ты стартап запускаешь PoC из говна и палок, то тебе правда все это не очень релевантно. Но на проектах индустриального масштаба мне кажется его тезисы верны на 100%. Если не хочется читать весь rant, то можно скипнуть и посомтреть аппендикс, где он описывает свой LLM-powered workflow, и он мне кажется очень здравым для зрелого проекта.

Генеративки - это новый пластик

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

Я в общем уверен в том, что генеративки сделали цифровой контент дешевле и доступнее, но убили наглухо экологию цифрового пространства.

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

Скриньте: года через три самые модные стартапы будут заманивать внутрь инженеров тем, что «не используют ллм в разработке».