Вот так вот душевно поболтали про тонкости агентизации. Там мы и про пузыри поговорили, и про причины овероптимизма части инженерного комьюнити в вопросе агентизации всего и вся (и почему эта задача существенно сложнее чем агентизировать кодинг или личную эффективность), а так же какие катаклизмы это может вызвать, если мы не перестанем шапкозакидательски относиться к трудоемкости внедрения ИИ в реальный бизнес. Все эти темы я и дальше планирую раскрывать, так что приходите на живые выступления тоже!
👍2
Forwarded from Эксплойт
Media is too big
VIEW IN TELEGRAM
Главная дилемма при агентизации бизнесов — какую адаптивность компаний к изменениям мы хотим сохранить.
Артём Бондарь, руководитель направления обработки естественного языка в Т-Банке рассказал на Т-дворе, что именно с этой стороны нужно оценивать потребности в ИИ-агентах.
«Либо мы строим очень хрупкую систему из очень жёстких процессов и получаем выгоду за счёт агентизации, либо мы оставляем возможность адаптироваться под среду, но тогда нам очень тяжело внедрять агентов, потому что они не понимают, как работают процессы и что делать в случае изменений»
Бизнесу нужно определиться с подходом: где
есть смысл внедрять агентов, а где важно сохранять гибкость.
@exploitex
Артём Бондарь, руководитель направления обработки естественного языка в Т-Банке рассказал на Т-дворе, что именно с этой стороны нужно оценивать потребности в ИИ-агентах.
«Либо мы строим очень хрупкую систему из очень жёстких процессов и получаем выгоду за счёт агентизации, либо мы оставляем возможность адаптироваться под среду, но тогда нам очень тяжело внедрять агентов, потому что они не понимают, как работают процессы и что делать в случае изменений»
Бизнесу нужно определиться с подходом: где
есть смысл внедрять агентов, а где важно сохранять гибкость.
@exploitex
❤9👍4
Save the date!
А 29-го июня у нас в офисе Сева Викулин и компания проведут митап для мл инженеров про внедрение GenAI в операционку. Я очень рекомендую прийти, потому что будет минимум технодиснейленда, и максимум реальной работы:
- как строить контроль качества агентов на индустриальном масштабе
- как трансформировать бизнес процессы, чтобы они были AI-реди
- как сводить экономику инференса
- как строить рабочие системы поверх интерфейсов сотрудников
Мы в этом году намеренно вынесли эти темы с нашей большой конфы, чтобы собраться более узким кругом инженеров, занятых в задачах агентизации внутрянки больших компаний.
Ждём 👋
А 29-го июня у нас в офисе Сева Викулин и компания проведут митап для мл инженеров про внедрение GenAI в операционку. Я очень рекомендую прийти, потому что будет минимум технодиснейленда, и максимум реальной работы:
- как строить контроль качества агентов на индустриальном масштабе
- как трансформировать бизнес процессы, чтобы они были AI-реди
- как сводить экономику инференса
- как строить рабочие системы поверх интерфейсов сотрудников
Мы в этом году намеренно вынесли эти темы с нашей большой конфы, чтобы собраться более узким кругом инженеров, занятых в задачах агентизации внутрянки больших компаний.
Ждём 👋
❤17👍6😎4
hitchhiker's guide to corporate crisis
Везде бывают кризисные моменты. Резкие реорги, ухудшение внешней конъюнктуры, исчерпание источников роста, накопленные хронические проблемы, где количество перерастает в качество.
Находиться в этом не слишком приятно. Кто-то яркий незаметно уходит в тень. Кто-то спокойный все чаще нервничает. Кто-то нужный уходит в другую компанию. Все чаще слышишь шутки про «досидеть до вестингов». И наоборот, кто-то недобросовестный подымает голову и начинает действовать в мутной водице без оглядки на приличия и здравый смысл.
У нормальных неравнодушных людей в такой ситуации автоматически включается «бей или беги». Но оглядываясь назад на свой опыт, я прихожу к выводу, что такая активность часто только усугубляет ситуацию. Действительно иногда важно не увидеть себя в картинке будущего компании и выйти, или биться за сохранение статуса кво. Но далеко не всегда. Так как продолжать конструктивно работать, если чувствуешь, что что-то конкретно идет не так? Для себя я собрал несколько понятных практик на этот случай:
1/ трезво взглянуть на ситуацию
Иногда довольно сложно себе признать, что что-то фундаментально идет не так. Кажется что это просто вот этот конкретный мудак тебя выбесил, Или конкретная неудача выбила из колеи. Яростно наброситься на конкретную проблему, и сдвинуться на шаг ближе к выгоранию. Понять ситуацию и ее руткоз - первый шаг, чтоб не начать тонуть.
2/ свериться с окружением
Если вы достаточно долго где-то работаете, то неизбежно у вас складывается «мафия взаимного доверия». Более того очень частно она транзитивная: люди имеют невероятную чувствительность к близкой системе ценностей и складу ума и собираются в кучки. Так вот хорошо бы понять: вы одни в такой ситуации (и вас нужен личный план выгребания) или вы все вместе попали в глобальный замес? В идеале общаться с людьми и внутри и снаружи компании, чтобы понимать масштаб бедствия.
3/ избегать эмоциональных «рывков на подвиг»
Для амбициозных людей проблема - это призыв к действию на сверхусилиях. Иногда это действительно нужно сделать. Но важно не попасть в ловушку и не пойти на подвиг ради подвига. Нужно очень трезво взвесить выхлоп от своих жертв и избегать эскапизма через прыжки веры.
4/ собрать команду выживания
Худшее в такой ситуации - остаться один на один с проблемой. Собирайте банду единомышленников: спасательный круг взаимной поддержки и доверия, на котором вы выплывете из замеса. Ищите людей, в кругу которых вам не грозят внутренние конфликты, и с которыми вы хотите оказаться в завтра. Держитесь за них. Выдерживайте давление вместе. Остаться одному - значит быть жертвой.
5/ берегите энергию
Мы имеем свойство недооценивать глубину и масштаб бедствий, стоя на их пороге, поэтому необходимо очень взвешенно и разумно тратить свою энергию. Выкладываться в экзистенциальных вопросах. Не лезть в каждую драку. Энергия еще ой как пригодится.
6/ в кризисе команда нуждается в лидере как никогда
Именно кризисы раскрывают сильнейших лидеров. Именно лучшие лидеры честно скажут «мы попали в трудную ситуацию» и найдет правильные слова, чтобы команда почувствовала себя командой, а не беззащитными одиночками. Чем честнее коммуникации - тем больше шансов мобилизовать людей и выйти из трудностей победителями. Будьте со своими людьми.
Все совпадения в таймингах этого поста с реальными событиями (и подготовкой к IPO трех крупнейших вендоров LLM) - случайны, а персонажи - вымышлены.
Везде бывают кризисные моменты. Резкие реорги, ухудшение внешней конъюнктуры, исчерпание источников роста, накопленные хронические проблемы, где количество перерастает в качество.
Находиться в этом не слишком приятно. Кто-то яркий незаметно уходит в тень. Кто-то спокойный все чаще нервничает. Кто-то нужный уходит в другую компанию. Все чаще слышишь шутки про «досидеть до вестингов». И наоборот, кто-то недобросовестный подымает голову и начинает действовать в мутной водице без оглядки на приличия и здравый смысл.
У нормальных неравнодушных людей в такой ситуации автоматически включается «бей или беги». Но оглядываясь назад на свой опыт, я прихожу к выводу, что такая активность часто только усугубляет ситуацию. Действительно иногда важно не увидеть себя в картинке будущего компании и выйти, или биться за сохранение статуса кво. Но далеко не всегда. Так как продолжать конструктивно работать, если чувствуешь, что что-то конкретно идет не так? Для себя я собрал несколько понятных практик на этот случай:
1/ трезво взглянуть на ситуацию
Иногда довольно сложно себе признать, что что-то фундаментально идет не так. Кажется что это просто вот этот конкретный мудак тебя выбесил, Или конкретная неудача выбила из колеи. Яростно наброситься на конкретную проблему, и сдвинуться на шаг ближе к выгоранию. Понять ситуацию и ее руткоз - первый шаг, чтоб не начать тонуть.
2/ свериться с окружением
Если вы достаточно долго где-то работаете, то неизбежно у вас складывается «мафия взаимного доверия». Более того очень частно она транзитивная: люди имеют невероятную чувствительность к близкой системе ценностей и складу ума и собираются в кучки. Так вот хорошо бы понять: вы одни в такой ситуации (и вас нужен личный план выгребания) или вы все вместе попали в глобальный замес? В идеале общаться с людьми и внутри и снаружи компании, чтобы понимать масштаб бедствия.
3/ избегать эмоциональных «рывков на подвиг»
Для амбициозных людей проблема - это призыв к действию на сверхусилиях. Иногда это действительно нужно сделать. Но важно не попасть в ловушку и не пойти на подвиг ради подвига. Нужно очень трезво взвесить выхлоп от своих жертв и избегать эскапизма через прыжки веры.
4/ собрать команду выживания
Худшее в такой ситуации - остаться один на один с проблемой. Собирайте банду единомышленников: спасательный круг взаимной поддержки и доверия, на котором вы выплывете из замеса. Ищите людей, в кругу которых вам не грозят внутренние конфликты, и с которыми вы хотите оказаться в завтра. Держитесь за них. Выдерживайте давление вместе. Остаться одному - значит быть жертвой.
5/ берегите энергию
Мы имеем свойство недооценивать глубину и масштаб бедствий, стоя на их пороге, поэтому необходимо очень взвешенно и разумно тратить свою энергию. Выкладываться в экзистенциальных вопросах. Не лезть в каждую драку. Энергия еще ой как пригодится.
6/ в кризисе команда нуждается в лидере как никогда
Именно кризисы раскрывают сильнейших лидеров. Именно лучшие лидеры честно скажут «мы попали в трудную ситуацию» и найдет правильные слова, чтобы команда почувствовала себя командой, а не беззащитными одиночками. Чем честнее коммуникации - тем больше шансов мобилизовать людей и выйти из трудностей победителями. Будьте со своими людьми.
❤19👍1
Как нарушать ритуалы не оскорбляя чувств «верующих»
Эрик Берн, один из идеологов транзакционного анализа в психологии рассуждает в своих работах про две концепции: процедуры и ритуалы. Процедуры строят взрослые люди, чтобы решать типовые вопросы, не затрачивая каждый раз много энергии и для достижения рациональной выгоды. Ритуалы передают родители детям (в широком смысле), как нечто незыблемое. Каждый ритуал когда-то был процедурой.
Я думаю вы сами встречали такое и не раз в жизни и работе: какие-то серии внутренних встреч, организаторы которых уже пропали, и настоящую цель которых (а не декларируемую) уже позабыли. Какой-то мутный критерий грейдапа. Какой-то левый чувак, чье мнение почему-то нужно учитывать. Есть простой способ детектировать ритуал: чем более абстрактными понятиями объясняется цель конструкции, тем выше шанс, что это именно что ритуал.
«Нам полезно оставаться в одном контексте», «это важно для чистоты профессии», «с ним полезно выровняться». Хотя на деле когда-то давно «нужно было следить за этими чуваками, пока они не нахуевертили», «надо было не дать конкретный грейдап», а с челом договаривались, потому что «без его ОК никто пальцем не шевелил».
Наверно самый хрестоматийный ритуал - это алгосекция при найме. Понятно, что на масштабе Гугла нужны люди, которые находят о(log) алгоритмы. Ну и масс найм не позволяет давать задачи фокусно под позицию. Но когда алгосекции дают в независимых командах, где можно было бы построить найм под свои конкретные нужды (процедуру), то это, конечно, типичный перенятый без критического осмысления ритуал. И к слову алгособес - отличный пример теряющего актуальность ритуала. Из-за его массовости, люди в индустриальных масштабах научились его обходить, что еще сильнее снизило эффективность этой когда-то процедуры.
Казалось бы, call to action ясен: критически переосмысляй происходящее, сворачивай ритуалы и вводи процедуры. Но есть ньюанс. Еще Берн отмечал, что ритуалы нас держат именно психологическим выхлопом. Их разрушение - это и конфликт с виртуальной «родительской фигурой» и потеря комфортной предсказуемости. Так как же разумно поступать, если на пути ваших целей стоит ритуал?
1/ не устраивать публичных «акций разоблачения»
Даже если все согласны с вами, что «король голый» и вешать стикеры 4 часа на доску не особо поможет вам достичь успеха, ваше нападение на ритуал с высокой вероятностью мало кто поддержит. Непублично да, а вот на публике вас скорее задавят. Мы можем не любить ритуалы, но конфликты мы любим еще меньше.
2/ найти стейкхолдера/ов, который считает происходящее процедурой.
Как правило это не администратор ритуала (в администраторы как раз часто идут люди склонные к фанатизму - не будь корпораций, они бы ушли в секту). Вот с этим человеком надо обсуждать через призму ожидаемых выгод происходящее. Выразить сомнения, что текущая конструкция даст ожидаемые результаты и поторговаться за изменение ритуала в свою пользу (превращаем назад в процедуру).
3/ выжать максимум из ритуала
Но увы предыдущий шаг работает не всегда. Вы поразитесь насколько много фанатичных людей работает в корпоративной среде. В этом случае конечно можно устроить крестовый поход с эскалацией, но причина должны быть существенной. А иногда причина - это просто раздражение от впустую потраченного времени. Значит надо сделать это время потраченным не зря. Как? Это вам виднее, но вот пару идей:
- превратить ритуал в платформу продвижения своего видения.
- погрузиться лучше в проблемы ваших соседей (ищем сделки)
- попрофилировать ваших коллег: с кем стоит что-то делать вместе, а кто несет чушь и лучше держаться от человека подальше
Это все звучит довольно абстрактно, но на практике про любую встречу активность процесс можно задать себе вопрос «как я могу этим воспользоваться, чтобы решить проблемы в зоне моей ответственности».
Иначе с ума сойти можно, а это никому на пользу не идет.
Эрик Берн, один из идеологов транзакционного анализа в психологии рассуждает в своих работах про две концепции: процедуры и ритуалы. Процедуры строят взрослые люди, чтобы решать типовые вопросы, не затрачивая каждый раз много энергии и для достижения рациональной выгоды. Ритуалы передают родители детям (в широком смысле), как нечто незыблемое. Каждый ритуал когда-то был процедурой.
Я думаю вы сами встречали такое и не раз в жизни и работе: какие-то серии внутренних встреч, организаторы которых уже пропали, и настоящую цель которых (а не декларируемую) уже позабыли. Какой-то мутный критерий грейдапа. Какой-то левый чувак, чье мнение почему-то нужно учитывать. Есть простой способ детектировать ритуал: чем более абстрактными понятиями объясняется цель конструкции, тем выше шанс, что это именно что ритуал.
«Нам полезно оставаться в одном контексте», «это важно для чистоты профессии», «с ним полезно выровняться». Хотя на деле когда-то давно «нужно было следить за этими чуваками, пока они не нахуевертили», «надо было не дать конкретный грейдап», а с челом договаривались, потому что «без его ОК никто пальцем не шевелил».
Наверно самый хрестоматийный ритуал - это алгосекция при найме. Понятно, что на масштабе Гугла нужны люди, которые находят о(log) алгоритмы. Ну и масс найм не позволяет давать задачи фокусно под позицию. Но когда алгосекции дают в независимых командах, где можно было бы построить найм под свои конкретные нужды (процедуру), то это, конечно, типичный перенятый без критического осмысления ритуал. И к слову алгособес - отличный пример теряющего актуальность ритуала. Из-за его массовости, люди в индустриальных масштабах научились его обходить, что еще сильнее снизило эффективность этой когда-то процедуры.
Казалось бы, call to action ясен: критически переосмысляй происходящее, сворачивай ритуалы и вводи процедуры. Но есть ньюанс. Еще Берн отмечал, что ритуалы нас держат именно психологическим выхлопом. Их разрушение - это и конфликт с виртуальной «родительской фигурой» и потеря комфортной предсказуемости. Так как же разумно поступать, если на пути ваших целей стоит ритуал?
1/ не устраивать публичных «акций разоблачения»
Даже если все согласны с вами, что «король голый» и вешать стикеры 4 часа на доску не особо поможет вам достичь успеха, ваше нападение на ритуал с высокой вероятностью мало кто поддержит. Непублично да, а вот на публике вас скорее задавят. Мы можем не любить ритуалы, но конфликты мы любим еще меньше.
2/ найти стейкхолдера/ов, который считает происходящее процедурой.
Как правило это не администратор ритуала (в администраторы как раз часто идут люди склонные к фанатизму - не будь корпораций, они бы ушли в секту). Вот с этим человеком надо обсуждать через призму ожидаемых выгод происходящее. Выразить сомнения, что текущая конструкция даст ожидаемые результаты и поторговаться за изменение ритуала в свою пользу (превращаем назад в процедуру).
3/ выжать максимум из ритуала
Но увы предыдущий шаг работает не всегда. Вы поразитесь насколько много фанатичных людей работает в корпоративной среде. В этом случае конечно можно устроить крестовый поход с эскалацией, но причина должны быть существенной. А иногда причина - это просто раздражение от впустую потраченного времени. Значит надо сделать это время потраченным не зря. Как? Это вам виднее, но вот пару идей:
- превратить ритуал в платформу продвижения своего видения.
- погрузиться лучше в проблемы ваших соседей (ищем сделки)
- попрофилировать ваших коллег: с кем стоит что-то делать вместе, а кто несет чушь и лучше держаться от человека подальше
Это все звучит довольно абстрактно, но на практике про любую встречу активность процесс можно задать себе вопрос «как я могу этим воспользоваться, чтобы решить проблемы в зоне моей ответственности».
Иначе с ума сойти можно, а это никому на пользу не идет.
👍10💯7❤4
Что же делать с управлением качеством GenAI систем
Три года назад все и их мамы стали промпт инженерами. Потом все эти промптинг трюки отжили свое, а мы, засучив рукава, занялись context/harness/specs инженерингом и побежали разворачивать MCP. Сейчас Борис Черный утверждает, что это все снова пройденный этап, и нам надо учится луп-инженирингу. Жизнь кипит, только успевай за этим паровозом: это и фаново и сулит большой аплифи т от внедрения в работу. Ну мы и внедряем.
И на все это смотрят СТО и владельцы бизнес процессов и задаются вопросом «а это вообще будет нормально работать?». И на мой взгляд это самый главный вопрос внедрений GenAI: как измерять и управлять качеством получившихся продуктов. Потому что в этой кроличьей норе много ньюансов:
1/ human-in-the-loop
То с чего начинались все внедрения GenAI, и на первый взгляд самый надежный способ контроля и управления качеством. Каждая единица контента/решение проходит через человека. Но есть две проблемы. Во-первых HitL убивает львиную долю эффекта от агентизации. Во-вторых встает в полный рост вопрос ответственности проверяющих. Все, кто управлял службами контроля качества знают, что такая монотонная активность притупляет внимание, и люди совершают много ошибок. Да и очень сложно держать замотивированными квалифицированных людей на такой работе (спросите любого кодера, любят ли они код ревью?). Сильно хуже ситуация, если контент LLM может давать отложенные эффекты. Например плохо написанный код может отстрелить не сразу. И эти инциденты могут наслоиться друг на друга в произвольный момент, что делает всю систему хрупкой. Так что вопрос ответственности за контент, созданный LLM, и мотивации встанет в полный рост и должен стать ключевым фокусом внедрятора.
2/ эвалы для строго верифицируемых задач
Есть узкий класс проблем, где по входным данным и состоянию среды мы точно знаем, что должен сделать агент. Например, к условиям математической задачки мы знаем точный ответ. Или по запросу разработчика на человеческом языке на задачу в терминале мы знаем какую CLI команду должен вызвать агент. В общем, если мы можем очень точно проэмулировать среду и знаем ответ - мы можем проверять на этом поведение агента. Важно, что не любую среду можно проэмулировать: например в поддержке это невозможно. И системы бизнеса могут быть сложные и поведение пользователя непредсказуемо. Плюс создавать такие эвалы - часто очень дорогое удовольствие. Зато если получилось, то можно давать агенту полную свободу в среде и проверять только финальный стейт. Есть мягкая версия такого эвала в кодинге - это сет автотестов. Очевидно, они не могут полностью проверить качество работы агента, но хотя бы отсеют очевидный шлак. Ну и этот подход дает только измерение качества: что делать с системой, чтоб это качество растить - каждый раз уникальный ребус.
3/ пошаговые эвалы
А что делать, если среда неэмулируемая, и проблему можно решить множеством способов? Поддержка или продажи - это отличный пример подобной ситуации. Как правило такая автоматизация предполагает, что есть люди, которые уже как-то справляются с этой задачей, и мы постфактум можем разметить каждую интеракцию на «хорошие» и «плохие». В этом случае мы можем измерять «попадание» агента в действия человека на каждом шаге цепочки действий. И надеяться что накопленная ошибка не уведет в проде агента с нужной нас траектории. Попадания могут быть и строгими (нажал на ту же кнопку) и нестрогими (ответил по сути так же). Такой метод контроля качества позволяет проверять агента задешево на широком наборе кейсов, но очевидно не заменяет замеров качества на взаимодействии с реальной средой. Плюс в полный рост встает вопрос строгости регламентов: если из одного состояния человек может успешно добраться до финального разными путями, то метрика получится очень шумная. Так что в таком подходе большая часть фокуса уйдет на синхронизацию сотрудников и причесываение единых регламентов (иначе агента будет сложно настроить).
На деле, конечно, подходов больше, но на индустриальном масштабе они особо не масштабируются.
Три года назад все и их мамы стали промпт инженерами. Потом все эти промптинг трюки отжили свое, а мы, засучив рукава, занялись context/harness/specs инженерингом и побежали разворачивать MCP. Сейчас Борис Черный утверждает, что это все снова пройденный этап, и нам надо учится луп-инженирингу. Жизнь кипит, только успевай за этим паровозом: это и фаново и сулит большой аплифи т от внедрения в работу. Ну мы и внедряем.
И на все это смотрят СТО и владельцы бизнес процессов и задаются вопросом «а это вообще будет нормально работать?». И на мой взгляд это самый главный вопрос внедрений GenAI: как измерять и управлять качеством получившихся продуктов. Потому что в этой кроличьей норе много ньюансов:
1/ human-in-the-loop
То с чего начинались все внедрения GenAI, и на первый взгляд самый надежный способ контроля и управления качеством. Каждая единица контента/решение проходит через человека. Но есть две проблемы. Во-первых HitL убивает львиную долю эффекта от агентизации. Во-вторых встает в полный рост вопрос ответственности проверяющих. Все, кто управлял службами контроля качества знают, что такая монотонная активность притупляет внимание, и люди совершают много ошибок. Да и очень сложно держать замотивированными квалифицированных людей на такой работе (спросите любого кодера, любят ли они код ревью?). Сильно хуже ситуация, если контент LLM может давать отложенные эффекты. Например плохо написанный код может отстрелить не сразу. И эти инциденты могут наслоиться друг на друга в произвольный момент, что делает всю систему хрупкой. Так что вопрос ответственности за контент, созданный LLM, и мотивации встанет в полный рост и должен стать ключевым фокусом внедрятора.
2/ эвалы для строго верифицируемых задач
Есть узкий класс проблем, где по входным данным и состоянию среды мы точно знаем, что должен сделать агент. Например, к условиям математической задачки мы знаем точный ответ. Или по запросу разработчика на человеческом языке на задачу в терминале мы знаем какую CLI команду должен вызвать агент. В общем, если мы можем очень точно проэмулировать среду и знаем ответ - мы можем проверять на этом поведение агента. Важно, что не любую среду можно проэмулировать: например в поддержке это невозможно. И системы бизнеса могут быть сложные и поведение пользователя непредсказуемо. Плюс создавать такие эвалы - часто очень дорогое удовольствие. Зато если получилось, то можно давать агенту полную свободу в среде и проверять только финальный стейт. Есть мягкая версия такого эвала в кодинге - это сет автотестов. Очевидно, они не могут полностью проверить качество работы агента, но хотя бы отсеют очевидный шлак. Ну и этот подход дает только измерение качества: что делать с системой, чтоб это качество растить - каждый раз уникальный ребус.
3/ пошаговые эвалы
А что делать, если среда неэмулируемая, и проблему можно решить множеством способов? Поддержка или продажи - это отличный пример подобной ситуации. Как правило такая автоматизация предполагает, что есть люди, которые уже как-то справляются с этой задачей, и мы постфактум можем разметить каждую интеракцию на «хорошие» и «плохие». В этом случае мы можем измерять «попадание» агента в действия человека на каждом шаге цепочки действий. И надеяться что накопленная ошибка не уведет в проде агента с нужной нас траектории. Попадания могут быть и строгими (нажал на ту же кнопку) и нестрогими (ответил по сути так же). Такой метод контроля качества позволяет проверять агента задешево на широком наборе кейсов, но очевидно не заменяет замеров качества на взаимодействии с реальной средой. Плюс в полный рост встает вопрос строгости регламентов: если из одного состояния человек может успешно добраться до финального разными путями, то метрика получится очень шумная. Так что в таком подходе большая часть фокуса уйдет на синхронизацию сотрудников и причесываение единых регламентов (иначе агента будет сложно настроить).
На деле, конечно, подходов больше, но на индустриальном масштабе они особо не масштабируются.
💯9👍5❤2
🚩Маленькая красная книжечка Мао для корпоративного млщика
За пол года у меня собралась серия очерков про особенности работы MLE в корпорации, и для вновь присоединившихся я решил собрать их в некоторую структуру.
Мне кажется начинающим инженерам и лидерам полезно понимать тонкости работы в такой среде, потому что машинное обучение любит большие компьют, данные и масштабы.
Мл-систем дизайн/стратегия
Чеклист здорового МЛ проекта
Стратегия R&D проектов
Управление риском
Измерение качества в GenAI
Про аплифт моделирование
Опыт внедрения genAI в операции
Векторный поиск, как антипаттерн
LLM as a judge, как антипаттерн
Карьера/корпоративная культура
Суть работы управленца
Как проходить кризисы
Как нанимать
Культура операционных компаний
Культура технологических компаний
Когда идти в стартап
Стартапы внутри корпорации
Про empire-building
Про нетворкинг
Смыслы
Успех
За пол года у меня собралась серия очерков про особенности работы MLE в корпорации, и для вновь присоединившихся я решил собрать их в некоторую структуру.
Мне кажется начинающим инженерам и лидерам полезно понимать тонкости работы в такой среде, потому что машинное обучение любит большие компьют, данные и масштабы.
Мл-систем дизайн/стратегия
Чеклист здорового МЛ проекта
Стратегия R&D проектов
Управление риском
Измерение качества в GenAI
Про аплифт моделирование
Опыт внедрения genAI в операции
Векторный поиск, как антипаттерн
LLM as a judge, как антипаттерн
Карьера/корпоративная культура
Суть работы управленца
Как проходить кризисы
Как нанимать
Культура операционных компаний
Культура технологических компаний
Когда идти в стартап
Стартапы внутри корпорации
Про empire-building
Про нетворкинг
Смыслы
Успех
Telegram
Артём обо всём
Чеклист здорового мл проекта
В Т по долгу службы мне надо присматривать за десятками МЛ проектов одновременно. Со временем у меня сложилась простая диагностическая рутина, которая вылавливает очевидные косяки. Если кто-то из олдов помнит Joel test для кодинга…
В Т по долгу службы мне надо присматривать за десятками МЛ проектов одновременно. Со временем у меня сложилась простая диагностическая рутина, которая вылавливает очевидные косяки. Если кто-то из олдов помнит Joel test для кодинга…
❤15👍11💅5
Вайбкодим игры
Выбрались с семьей в большой отпуск. Где-то день на третий надоело купаться, начали со страшим вайбкодить дипсиком игры (в чат интерфейсе - бесплатный и безгеморгый вариант). Классно поугарали, некоторые из игр выложили сюда (Работает только с компа)
Наблюдения:
супер фаново: ощущения, что вернулся во времена flash-игр. Специально делали что-то тупое и странное. В таком сеттинге баги не напрягают, а скорее ожидаемы
хорошо получаются идеи, опирающиеся на популярные концепты (bomberman, crimsonland, etc), но с твистом. Постмодернизм тут не стиль, а единственная рабочая стратегия
Опыт инженеринга все еще очень полезен: несколько проблем отловил с дебаггером. Например для управления по wasd аппка подписалась на события клавиатуры, но когда та была в русской раскладке эти события не проходили фильтры
Так и не решил вопрос графики. Из идей: скачать пак ассетов и vlm разметить его на подробную метадату, доступной для агента. Но это уже за гранью сеттинга «пофаниться в отпуске», поэтому забил.
Я прямо очень кайфую от концепта disposable software. Помню свой восторг, когда я начал работать с Jupyter ноутбуками, и фигачил в них, как в черновиках, не заморачиваясь о долговечности. Кажется, что такого кода и софта станет больше: уж даже отец посмотрел на эти поделия и пошел пилить себе мини-апп-планнер ближайшего путешествия. Мне кажется, что это очень классная альтернатива классическим агентам: все же отлаживать/проверять запеченную в коде логику сильно проще, чем колдовать над харнессами с бубном. Ощущение, что управляемости больше. Помню года два назад в рамках вечернего трепа в офисе мы с командой ботов объясняли Вите Тарнавскому, что избавиться от регулярок на самом деле очень сложно, потому что как только ты ее отдалил - она работает очень круто. На что Витя предложил сделать «фабрику регулярок» на базе ллм. Что кажется вполне жизнеспособный нишевый (а может и не очень) подход в мире софта.
Выбрались с семьей в большой отпуск. Где-то день на третий надоело купаться, начали со страшим вайбкодить дипсиком игры (в чат интерфейсе - бесплатный и безгеморгый вариант). Классно поугарали, некоторые из игр выложили сюда (Работает только с компа)
Наблюдения:
супер фаново: ощущения, что вернулся во времена flash-игр. Специально делали что-то тупое и странное. В таком сеттинге баги не напрягают, а скорее ожидаемы
хорошо получаются идеи, опирающиеся на популярные концепты (bomberman, crimsonland, etc), но с твистом. Постмодернизм тут не стиль, а единственная рабочая стратегия
Опыт инженеринга все еще очень полезен: несколько проблем отловил с дебаггером. Например для управления по wasd аппка подписалась на события клавиатуры, но когда та была в русской раскладке эти события не проходили фильтры
Так и не решил вопрос графики. Из идей: скачать пак ассетов и vlm разметить его на подробную метадату, доступной для агента. Но это уже за гранью сеттинга «пофаниться в отпуске», поэтому забил.
Я прямо очень кайфую от концепта disposable software. Помню свой восторг, когда я начал работать с Jupyter ноутбуками, и фигачил в них, как в черновиках, не заморачиваясь о долговечности. Кажется, что такого кода и софта станет больше: уж даже отец посмотрел на эти поделия и пошел пилить себе мини-апп-планнер ближайшего путешествия. Мне кажется, что это очень классная альтернатива классическим агентам: все же отлаживать/проверять запеченную в коде логику сильно проще, чем колдовать над харнессами с бубном. Ощущение, что управляемости больше. Помню года два назад в рамках вечернего трепа в офисе мы с командой ботов объясняли Вите Тарнавскому, что избавиться от регулярок на самом деле очень сложно, потому что как только ты ее отдалил - она работает очень круто. На что Витя предложил сделать «фабрику регулярок» на базе ллм. Что кажется вполне жизнеспособный нишевый (а может и не очень) подход в мире софта.
❤12
Не успели еще разобрать сцену после вчерашнего GenAI митапа, а я уже приглашаю вас на наш флагманский мл ивент: TurboML Conf 18 июля. В этом году ваш покорный был ответственен ровно за две вещи:
- выносить мозги бедным деврелам на тему поиска стильной площадки
- вместе с фундаментальной нлп командой думать, чем бы вас в очередной раз порадовать
Приходите 18-го в Серп и молот разбираться, преуспел ли я в этих начинаниях. Ну и это классная возможность вырвать в графике дату, пересечься и наконец вживую про все наши мл и не очень дела. Ждём!
- выносить мозги бедным деврелам на тему поиска стильной площадки
- вместе с фундаментальной нлп командой думать, чем бы вас в очередной раз порадовать
Приходите 18-го в Серп и молот разбираться, преуспел ли я в этих начинаниях. Ну и это классная возможность вырвать в графике дату, пересечься и наконец вживую про все наши мл и не очень дела. Ждём!
❤10👍7😎6💅1
Что мне с этого вашего AlphaEvolve
Мои любимые МЛ трюки и концепции - это те, про которые тебе независимо и увлеченно рассказывают несколько незнакомых друг с другом инженеров. Я тут поймал себя на мысли, что самые талантливые ребята из моего окружения все чаще стали ссылаться на гугловый AlphaEvolve.
В чем его суть: мы берём задачу с автоматически верифицируемым ревордом (например: написать оптимальный алгоритм. Реворд - скорость и корректность исполнения на тесткейсах). Для нее пишем затравочное решение и просим LLM сгенерировать несколько более оптимальных решений. Эти решения скорим и укладываем в базу экспериментов. Дальше семплируем из этой базы несколько экспов с результатами и просим LLM сделать следующую модификацию. И так, пока не найдем перебором более эффективное решение.
Самый сок - это семлировние. Алгоритм строит некоторую метрику в пространстве решений, и вдохновляясь генетическими алгоритмами берет не жадно самое лучшее, как новую базу, а набирает диверсифицированный сет из «островов» этого пространства. Очень красиво, автоматизировано и накинуло много пользы во внутренних гугловских задачах: https://deepmind.google/blog/alphaevolve-impact/
Но тут есть загвоздка: не во всех задачах можно легко найти верифицируемый реворд. И не все задачи можно решать изолированно без контекста (как математические задачки).
Но если подумать, то все же многие полезные энтерпрайз задачи можно загнать в этот сетап. Например если мы автоматизируем какой-то процесс, то реворд - это попадание в поведение живых людей, проверенное llm-as-a-judge. А в шаг эволюции может включать не только думание в вакууме, но и походы во внешние базы знаний в поиске правильного граундинга под наблюдаемое поведение. И получается, что любую задачу по автоматизации существующего процесса можно загнать в этот сетап. Не писать промты руками, а дать алгоритму самому собирать правильный контекст из всех возможных источников.
Что делать с этой мыслью - думаю. Это точно сработало «на руках», где шаг эволюции мы проводили вручную, но возможно этот процесс автоматизируется еще сильнее.
Мои любимые МЛ трюки и концепции - это те, про которые тебе независимо и увлеченно рассказывают несколько незнакомых друг с другом инженеров. Я тут поймал себя на мысли, что самые талантливые ребята из моего окружения все чаще стали ссылаться на гугловый AlphaEvolve.
В чем его суть: мы берём задачу с автоматически верифицируемым ревордом (например: написать оптимальный алгоритм. Реворд - скорость и корректность исполнения на тесткейсах). Для нее пишем затравочное решение и просим LLM сгенерировать несколько более оптимальных решений. Эти решения скорим и укладываем в базу экспериментов. Дальше семплируем из этой базы несколько экспов с результатами и просим LLM сделать следующую модификацию. И так, пока не найдем перебором более эффективное решение.
Самый сок - это семлировние. Алгоритм строит некоторую метрику в пространстве решений, и вдохновляясь генетическими алгоритмами берет не жадно самое лучшее, как новую базу, а набирает диверсифицированный сет из «островов» этого пространства. Очень красиво, автоматизировано и накинуло много пользы во внутренних гугловских задачах: https://deepmind.google/blog/alphaevolve-impact/
Но тут есть загвоздка: не во всех задачах можно легко найти верифицируемый реворд. И не все задачи можно решать изолированно без контекста (как математические задачки).
Но если подумать, то все же многие полезные энтерпрайз задачи можно загнать в этот сетап. Например если мы автоматизируем какой-то процесс, то реворд - это попадание в поведение живых людей, проверенное llm-as-a-judge. А в шаг эволюции может включать не только думание в вакууме, но и походы во внешние базы знаний в поиске правильного граундинга под наблюдаемое поведение. И получается, что любую задачу по автоматизации существующего процесса можно загнать в этот сетап. Не писать промты руками, а дать алгоритму самому собирать правильный контекст из всех возможных источников.
Что делать с этой мыслью - думаю. Это точно сработало «на руках», где шаг эволюции мы проводили вручную, но возможно этот процесс автоматизируется еще сильнее.
Google DeepMind
AlphaEvolve: Gemini-powered coding agent scaling impact across fields
Discover how AlphaEvolve optimizes algorithms for genomics, quantum physics, global infrastructure, and more to accelerate scientific progress and solve real-world challenges.
👍11
Как понять, чем заниматься в корпорации
Какое-то время назад, я решил обновить свой CV, чтоб оглянуться назад и оценить результаты десятилетия своих усилий на мл поприще свежим взглядом. Свежим, потому что моя оптика в тот момент заметно обновилась: позиция уже давно предполагала непосредственную близость к бизнесу, поэтому результаты хотелось оценить через созданную долгосрочную ценность, а не через заковыристость моделек и ощущение сложности проекта.
И результаты были интересные. По многим прошлым проектам я вообще не знал, как они повлияли в итоге на бизнес в долгосроке. Некоторые активности, казавшиеся невероятно важными и отъедавшие уйму времени, в конечном итоге не раскрывались в виде твердых результатов. А задачи, от которых я воротил нос - лежали внятной и внушительной цифрой. После этого упражнения я скорректировал свое отношение к работе: стал на любую задачу смотреть через призму вопроса «а как я положу это в итоге себе в резюме?».
Это серьезно перекроило подход к выбору активностей, за которые я берусь. Меня стали интересовать только два вопроса: какой здесь endgame с точки зрения эффекта для компании (в индустриально понятных метриках) и достаточно ли у меня ресурсов для реализации. Сложно забрать в CV абстрактное «прокачал платформы». Легко взять «обеспечили инфрой запуск инициатив на Х ярдов». Сложно - 20 небольших проектов с зоопарком метрик и эффектов. Просто забрать факт напрямую из отчета для инвесторов компании.
И если первое время я больше интересовался вопросом эффекта, предполагая что «умрем, но достигнем» доступными ресурсами, то со временем второй вопрос меня стал волновать больше. Что вцелом немудрено: на линейных позициях основной доступный ресурс - это собственная энергия и навыки. И особенно после 4 лет стартаперства, где ты занимаешься в-с-е-м, кажется, что имея достаточно денег любой критический вопрос проекта можно плюс минус закрыть собой (надо научиться мобильной разработке? Дайте ночь и методичку). Но увы это крайне ограниченный ресурс, поэтому даже в эпоху ллм амбициозные проекты надо делать командами и не всегда под прямым управлением. И вот тут оказывается, что помимо непосредствннной работы для успеха крупного проекта надо заниматься еще и кучей сопутствующих активностей: сидеть в комитетах корпы, чтоб повлиять на важные тебе решения по распределению ресурсов. Ходить на ивенты, чтобы качать технобренд и привлекать лучших. Приводить в чувства найм и внутренние эйчар процессы, чтоб иметь возможность завести внутрь и замотивировать на результат сотрудников. Планировать закупки, проводить реорги, искать возможности объединиться с другими тимами, влиять на целеполагание команд от которых ты зависишь. Короче много-много далекой от фактической продуктовой работы. Ее невозможно положить результатами в CV, и она может легко сожрать ВСЕ ваше время и энергию, если не подходить к ней осознанно, как к необходимой, но по сути вторичной по отношению к созданию прямой ценности.
Чтобы ловить баланс между этими активностями я обычно размышляю про свои проекты деревом зависимостей. Чего мне не хватает, чтобы проект доехал до конкретного CV-пригодного результата? И как дешевле всего снять блокер на пути проекта? Со временем горизонт планирования растет, и блокеры становятся все интереснее: мотивация сотрудников, заинтересованность стейкхолдеров, согласованность с целями соседних команд. Но суть та же: что я должен сделать сегодня, чтобы через год-три-пять я смог бы записать себе простой и очевидно классный результат. Классный в тех попугаях, которые ценятся на интересном мне уровне управления. Вот это и ответ на вопрос «чем же тут надо заниматься», иначе ваш задор с легкостью прожует и переварит корпоративная машина.
Какое-то время назад, я решил обновить свой CV, чтоб оглянуться назад и оценить результаты десятилетия своих усилий на мл поприще свежим взглядом. Свежим, потому что моя оптика в тот момент заметно обновилась: позиция уже давно предполагала непосредственную близость к бизнесу, поэтому результаты хотелось оценить через созданную долгосрочную ценность, а не через заковыристость моделек и ощущение сложности проекта.
И результаты были интересные. По многим прошлым проектам я вообще не знал, как они повлияли в итоге на бизнес в долгосроке. Некоторые активности, казавшиеся невероятно важными и отъедавшие уйму времени, в конечном итоге не раскрывались в виде твердых результатов. А задачи, от которых я воротил нос - лежали внятной и внушительной цифрой. После этого упражнения я скорректировал свое отношение к работе: стал на любую задачу смотреть через призму вопроса «а как я положу это в итоге себе в резюме?».
Это серьезно перекроило подход к выбору активностей, за которые я берусь. Меня стали интересовать только два вопроса: какой здесь endgame с точки зрения эффекта для компании (в индустриально понятных метриках) и достаточно ли у меня ресурсов для реализации. Сложно забрать в CV абстрактное «прокачал платформы». Легко взять «обеспечили инфрой запуск инициатив на Х ярдов». Сложно - 20 небольших проектов с зоопарком метрик и эффектов. Просто забрать факт напрямую из отчета для инвесторов компании.
И если первое время я больше интересовался вопросом эффекта, предполагая что «умрем, но достигнем» доступными ресурсами, то со временем второй вопрос меня стал волновать больше. Что вцелом немудрено: на линейных позициях основной доступный ресурс - это собственная энергия и навыки. И особенно после 4 лет стартаперства, где ты занимаешься в-с-е-м, кажется, что имея достаточно денег любой критический вопрос проекта можно плюс минус закрыть собой (надо научиться мобильной разработке? Дайте ночь и методичку). Но увы это крайне ограниченный ресурс, поэтому даже в эпоху ллм амбициозные проекты надо делать командами и не всегда под прямым управлением. И вот тут оказывается, что помимо непосредствннной работы для успеха крупного проекта надо заниматься еще и кучей сопутствующих активностей: сидеть в комитетах корпы, чтоб повлиять на важные тебе решения по распределению ресурсов. Ходить на ивенты, чтобы качать технобренд и привлекать лучших. Приводить в чувства найм и внутренние эйчар процессы, чтоб иметь возможность завести внутрь и замотивировать на результат сотрудников. Планировать закупки, проводить реорги, искать возможности объединиться с другими тимами, влиять на целеполагание команд от которых ты зависишь. Короче много-много далекой от фактической продуктовой работы. Ее невозможно положить результатами в CV, и она может легко сожрать ВСЕ ваше время и энергию, если не подходить к ней осознанно, как к необходимой, но по сути вторичной по отношению к созданию прямой ценности.
Чтобы ловить баланс между этими активностями я обычно размышляю про свои проекты деревом зависимостей. Чего мне не хватает, чтобы проект доехал до конкретного CV-пригодного результата? И как дешевле всего снять блокер на пути проекта? Со временем горизонт планирования растет, и блокеры становятся все интереснее: мотивация сотрудников, заинтересованность стейкхолдеров, согласованность с целями соседних команд. Но суть та же: что я должен сделать сегодня, чтобы через год-три-пять я смог бы записать себе простой и очевидно классный результат. Классный в тех попугаях, которые ценятся на интересном мне уровне управления. Вот это и ответ на вопрос «чем же тут надо заниматься», иначе ваш задор с легкостью прожует и переварит корпоративная машина.
❤22👍16
Как делать классные доклады
Как вы уже поняли по количеству постов в этом канале - меня хлебом не корми, дай что-то рассказать. И одна из вещей, которой я искренне горжусь - это то, как хорошо мои ребята инженеры начинают делать доклады, после того как я плотно ими позанимаюсь. Без лишней скромности: мои потоки на конфах/точечные доклады ребят всегда в топе, и есть несколько простых механик, исполнения которых этому способствует.
1/ у любого рассказа должна быть цель
Что должны сделать слушатели, по выходу из зала. Они должны пойти и добиться успеха в своей компании используя ваш подход? Они должны восхититься вашей классностью и прислать резюме? Нужно, чтобы они предпочли ваше решение другому? Нужно чтоб вас загрейдапили в ближайшем ревью? А почему они без вашего доклада этого не делают? Отвечая на этот вопрос раз за разом по методу Сократа вы и поймете, какие ключевые тезисы должны быть раскрыты и проданы. Чем лучше вы проработаете этот вопрос - тем интереснее ваш доклад будет (или вы поймете что его делать и не надо).
2/ тезисный план
Любой доклад можно и нужно уметь рассказать за минуту/5 минут/45 минут. Для этого вам нужна иерархическая структура повествования, где вы сначала выписываете ключевые тезисы текстом, а потом начиняете рассказ уточнениями и деталями 2-го, 3-го и более уровней. Так что сначала пишем одностраничник с планом рассказа, а потом уже возимся с красотой на слайдах.
3/ на слайдах не должно быть текста
Люди читают быстро, и не будут вас слушать а будут читать и скучать. На слайд выносим то, что плохо воспринимается с голоса: таблицы, графики, схемы, иллюстрации. Если пишем текст, то только ключевую мысль, которую вы раскрываете голосом. Если на одном слайде несколько буллетов - добавляете их по одному через смену слайда. Слайды - бесплатные, делайте их хоть 500. А вот текст полезно считать платным: по сто рублей за слово, например.
4/ репетируйте
Если вы уже набили себе руку, можно импровизировать прямо на сцене - иначе с таймером репетируйте, пока не станет хорошо. Записываете себя на диктофон и слушаете. Убираете эээ, мэээ, так, ну, типа. Сложно, но очень облегчает восприятие. Золотое правило: лучше помолчать, чем навалить словесной каши. Хорошие ораторы работают паузами не хуже, чем словами.
5/ волнуйтесь
На самом деле если вы не волнуетесь перед выступлением - это плохой знак. Аудитория читает эмоции очень хорошо, и раз вы не волнуетесь, то вам ваш рассказ не кажется важным, а значит и аудитория будет следить с меньшим интересом. Волнение через край тоже плохо, но тут аудитория может быть вашим другом: честно скажите, что волнуетесь, не пытайтесь задавить эмоцию. Вы удивитесь, сколько поддержки вы можете получить, просто честно сказав вслух, что волнуетесь.
6/ не шутите, но расскажите личное
Матожидание эффекта от шутки в неизвестной аудитории - строго отрицательно. Если вы опытный спикер, и знаете, что ваши приколы залетают, а цена ошибки невысока - вперед. Иначе не надо этого делать. Такие трюки обычно выполняются профессионалами. А поделиться личным - это супер. Спикер всегда в невыгодном и уязвимом положении, и сделать себя еще уязвимее - универсально вызывает симпатию.
7/ будьте собой
Ваша история и опыт ценны сами по себе. Даже если они не уникальны. Мы любим слушать истории, когда в них есть Человек. Лучше найти свою небольшую аудиторию, рассказав то, что вам важно, чем вещать в массы то, что не трогает вас. Так что добавьте в свою историю побольше себя. И я сейчас не про публичные выступления.
Как вы уже поняли по количеству постов в этом канале - меня хлебом не корми, дай что-то рассказать. И одна из вещей, которой я искренне горжусь - это то, как хорошо мои ребята инженеры начинают делать доклады, после того как я плотно ими позанимаюсь. Без лишней скромности: мои потоки на конфах/точечные доклады ребят всегда в топе, и есть несколько простых механик, исполнения которых этому способствует.
1/ у любого рассказа должна быть цель
Что должны сделать слушатели, по выходу из зала. Они должны пойти и добиться успеха в своей компании используя ваш подход? Они должны восхититься вашей классностью и прислать резюме? Нужно, чтобы они предпочли ваше решение другому? Нужно чтоб вас загрейдапили в ближайшем ревью? А почему они без вашего доклада этого не делают? Отвечая на этот вопрос раз за разом по методу Сократа вы и поймете, какие ключевые тезисы должны быть раскрыты и проданы. Чем лучше вы проработаете этот вопрос - тем интереснее ваш доклад будет (или вы поймете что его делать и не надо).
2/ тезисный план
Любой доклад можно и нужно уметь рассказать за минуту/5 минут/45 минут. Для этого вам нужна иерархическая структура повествования, где вы сначала выписываете ключевые тезисы текстом, а потом начиняете рассказ уточнениями и деталями 2-го, 3-го и более уровней. Так что сначала пишем одностраничник с планом рассказа, а потом уже возимся с красотой на слайдах.
3/ на слайдах не должно быть текста
Люди читают быстро, и не будут вас слушать а будут читать и скучать. На слайд выносим то, что плохо воспринимается с голоса: таблицы, графики, схемы, иллюстрации. Если пишем текст, то только ключевую мысль, которую вы раскрываете голосом. Если на одном слайде несколько буллетов - добавляете их по одному через смену слайда. Слайды - бесплатные, делайте их хоть 500. А вот текст полезно считать платным: по сто рублей за слово, например.
4/ репетируйте
Если вы уже набили себе руку, можно импровизировать прямо на сцене - иначе с таймером репетируйте, пока не станет хорошо. Записываете себя на диктофон и слушаете. Убираете эээ, мэээ, так, ну, типа. Сложно, но очень облегчает восприятие. Золотое правило: лучше помолчать, чем навалить словесной каши. Хорошие ораторы работают паузами не хуже, чем словами.
5/ волнуйтесь
На самом деле если вы не волнуетесь перед выступлением - это плохой знак. Аудитория читает эмоции очень хорошо, и раз вы не волнуетесь, то вам ваш рассказ не кажется важным, а значит и аудитория будет следить с меньшим интересом. Волнение через край тоже плохо, но тут аудитория может быть вашим другом: честно скажите, что волнуетесь, не пытайтесь задавить эмоцию. Вы удивитесь, сколько поддержки вы можете получить, просто честно сказав вслух, что волнуетесь.
6/ не шутите, но расскажите личное
Матожидание эффекта от шутки в неизвестной аудитории - строго отрицательно. Если вы опытный спикер, и знаете, что ваши приколы залетают, а цена ошибки невысока - вперед. Иначе не надо этого делать. Такие трюки обычно выполняются профессионалами. А поделиться личным - это супер. Спикер всегда в невыгодном и уязвимом положении, и сделать себя еще уязвимее - универсально вызывает симпатию.
7/ будьте собой
Ваша история и опыт ценны сами по себе. Даже если они не уникальны. Мы любим слушать истории, когда в них есть Человек. Лучше найти свою небольшую аудиторию, рассказав то, что вам важно, чем вещать в массы то, что не трогает вас. Так что добавьте в свою историю побольше себя. И я сейчас не про публичные выступления.
❤28👍5🥴2💯2
T-Search - наша открытая AgenticRAG модель 👽
Выкладываем специализированную 35B-A3B Agentic search модель, заточенную на multi-hop ретрив контекста из классических поисковых индексов. Выкладываем вместе с харнессом, который несложно прикрутить к вашему существующему поиску. Модель на базе Qwen3.6 влазит в H100, а собирает контекст частно круче, чем взрослые диприсеч модели. Drop-in replacement вашего ретривала в раге с качеством ретрива уровня диприсеч+ по цене в пять раз ниже, чем у моделей-бегемотов. Не привязан к определенному алгоритму ретрива: будет работать и с bm25 и с эмбедами не теряя в качестве.
Пробенчить такую способность модели оказалась не менее интересная задача: помимо стандартных BrowseComp и SealQA мы собрали свой бенч TRuST. И выкладываем его тоже.
Фронтирные опенсорс модельки уже достаточно классно справляются с бизнесовыми задачами, если собрать им правильный контекст, и T-Search это наша попытка уйти от ручного context-engineering’а в сторону автоматического и эффективного по костам решения.
И если хотите узнать подробности, приходите завтра на турбомл послушать/поспрашивать ребят непосредственно. А если не получится дойти ногами, то скоро скинем подробный отчет на хабру.
Выкладываем специализированную 35B-A3B Agentic search модель, заточенную на multi-hop ретрив контекста из классических поисковых индексов. Выкладываем вместе с харнессом, который несложно прикрутить к вашему существующему поиску. Модель на базе Qwen3.6 влазит в H100, а собирает контекст частно круче, чем взрослые диприсеч модели. Drop-in replacement вашего ретривала в раге с качеством ретрива уровня диприсеч+ по цене в пять раз ниже, чем у моделей-бегемотов. Не привязан к определенному алгоритму ретрива: будет работать и с bm25 и с эмбедами не теряя в качестве.
Пробенчить такую способность модели оказалась не менее интересная задача: помимо стандартных BrowseComp и SealQA мы собрали свой бенч TRuST. И выкладываем его тоже.
Фронтирные опенсорс модельки уже достаточно классно справляются с бизнесовыми задачами, если собрать им правильный контекст, и T-Search это наша попытка уйти от ручного context-engineering’а в сторону автоматического и эффективного по костам решения.
И если хотите узнать подробности, приходите завтра на турбомл послушать/поспрашивать ребят непосредственно. А если не получится дойти ногами, то скоро скинем подробный отчет на хабру.
Please open Telegram to view this post
VIEW IN TELEGRAM
huggingface.co
t-tech/TRuST · Datasets at Hugging Face
We’re on a journey to advance and democratize artificial intelligence through open source and open science.
❤30👍15💅7🌚1💯1😎1
А 3-го августа в 17:00 залетайте на прямой эфир: иду в гости к Саше Поломодову разгонять про агентизацию не-айти энтерпрайза. Что по другому, а что ровно так же, как в агентизации инженерии. Приходите 😎
❤17👍7💅5
Чеклист здоровья среды успешного МЛ проекта
Какое-то время назад я написал очерк про "чеклист здоровья МЛ проекта". Он описывает набор необходимых условий с точки зрения чистой техники, но перестает быть достаточным, когда проект опускается в конкретную среду и на плечи конкретных людей. Поэтому сегодня хотелось бы чуть больше сфокусироваться на взаимоотношениях ключевых участников проекта - именно то, за чем пристальнее всего наблюдают em/directing ребята:
1/ проект не попадает в "инверсию приоритетов" по всей массе задействованных команд
Если для вашего стейкхолдера проект - это приоритет номер 1, а для команды, от которой вы зависите - это десятый приоритет, то успех либо не случится, либо будет стоить вам мотивации ключевых людей команды. Желательно бы такое обнаруживать на берегу и сводить стейкхолдеров договариваться о ресурсах. Ну а если такое вскрывается по дороге и не решается переговорами - то полезно пивотить команду, чтоб она не билась головой о стену. В такой ситуации очень важна изобретательность и для переговоров и для поиска фолбека, если переговоры зашли в тупик.
2/ команда смогла поделить роли
Типичный пример - ты очень хочешь позаниматься задачей, на нее высаживают кого-то еще, а тебя назначают "помогать". Помощь тогда будет такой, что лучше бы и не помогали (очевидно). Такие конфликты невероятно важно выводить на свет из под ковра, чтобы они не превращались в хроническую вялотекущую политическую возню. Для этого важно, чтоб в компании был лидер или группа лидеров, которому доверяют все участники сабантуя, и кто поможет выстроить внятные границы отвественности. На первому этапе в storming стадии абсолютно окей, что участники притираются друг к другу и примеряют роли в команде, но если притирка затягивается и не модерируется, то это может превратиться в вялотекущий ад, выбивающий из команды лучших людей.
3/ все принципиальные роли закрыты замотивированными людьми
Вообще на работе нормально делать не "то что хочется", а "то что надо". Но есть ньюанс. Если это "надо" все время идет в разрез с "хочется", но рано или поздно неудовлетворенность перельется через край и человек (даже самый отвественный) забьет на свои обязательства, причем на все сразу, а не только те, что бесят. Нереалистично раздать всем задачи, которые им нравятся. Но очень важно работать над поиском правильных людей в команду. "Лягушка" для одного чувака - это возможность для другого.
4/ у ключевых участников нет конфликтов интересов
По этому пункту добиться идеала практически невозможно: процитирую одного успешного бизнес лидера "хорошо, если цели сотрудика и организации хотя-бы сонаправлены". Но бывают очевидные ситуаци, где ключевой челвоек приследует личные цели. Либо удовлетворяет амбиции в ущерб результату, либо пытается занять удобную для себя, но вредную для прогресса роль. Тут талант менеджера в том, чтобы понимать мотивацию всех участников квартета, и вовремя выводить тех, чья польза перестает перевешивать вред. И в этом вопросе доверие - снова ваш друг и товарищ. Конечно можно вывыести на чистую воду просто насев на сотрудника - но будьте уверены, в этом случае это ваш последний продуктивный совместный проект.
5/ у лидеров продукта есть внятный ответ на вопрос "а что дальше"
Где-то на пол пути к победе даже в самом классном продукте у любого нормального лидера будет вопрос "хорошо, ну вот сделаю я все это - а дальше что?". И худший ответ тут "посмотрим". Потому что нормальные лидеры с высокой агентностью "посмотрят" и сами. И найдут. И найдут еще до того, как вы доделали текущий проект. Поэтому критчиески важно, чтобы люди понимали общую картину, и куда вы их ведете, и ради чего усилия прямо сейчас. Худшее, что может случиться тут - это лидер, который не понимает куда двигаться дальше. Такой начнет сильно тормозить и команду и себя.
Вообще когда осознаешь, как много звезд должно сложиться, чтобы проект доехал до успеха начинаешь понимать, что любая организация держится на скотче и молитвах. И конечно же таланте хороших управленцев, которых надеюсь со временем будет становиться все больше.
Какое-то время назад я написал очерк про "чеклист здоровья МЛ проекта". Он описывает набор необходимых условий с точки зрения чистой техники, но перестает быть достаточным, когда проект опускается в конкретную среду и на плечи конкретных людей. Поэтому сегодня хотелось бы чуть больше сфокусироваться на взаимоотношениях ключевых участников проекта - именно то, за чем пристальнее всего наблюдают em/directing ребята:
1/ проект не попадает в "инверсию приоритетов" по всей массе задействованных команд
Если для вашего стейкхолдера проект - это приоритет номер 1, а для команды, от которой вы зависите - это десятый приоритет, то успех либо не случится, либо будет стоить вам мотивации ключевых людей команды. Желательно бы такое обнаруживать на берегу и сводить стейкхолдеров договариваться о ресурсах. Ну а если такое вскрывается по дороге и не решается переговорами - то полезно пивотить команду, чтоб она не билась головой о стену. В такой ситуации очень важна изобретательность и для переговоров и для поиска фолбека, если переговоры зашли в тупик.
2/ команда смогла поделить роли
Типичный пример - ты очень хочешь позаниматься задачей, на нее высаживают кого-то еще, а тебя назначают "помогать". Помощь тогда будет такой, что лучше бы и не помогали (очевидно). Такие конфликты невероятно важно выводить на свет из под ковра, чтобы они не превращались в хроническую вялотекущую политическую возню. Для этого важно, чтоб в компании был лидер или группа лидеров, которому доверяют все участники сабантуя, и кто поможет выстроить внятные границы отвественности. На первому этапе в storming стадии абсолютно окей, что участники притираются друг к другу и примеряют роли в команде, но если притирка затягивается и не модерируется, то это может превратиться в вялотекущий ад, выбивающий из команды лучших людей.
3/ все принципиальные роли закрыты замотивированными людьми
Вообще на работе нормально делать не "то что хочется", а "то что надо". Но есть ньюанс. Если это "надо" все время идет в разрез с "хочется", но рано или поздно неудовлетворенность перельется через край и человек (даже самый отвественный) забьет на свои обязательства, причем на все сразу, а не только те, что бесят. Нереалистично раздать всем задачи, которые им нравятся. Но очень важно работать над поиском правильных людей в команду. "Лягушка" для одного чувака - это возможность для другого.
4/ у ключевых участников нет конфликтов интересов
По этому пункту добиться идеала практически невозможно: процитирую одного успешного бизнес лидера "хорошо, если цели сотрудика и организации хотя-бы сонаправлены". Но бывают очевидные ситуаци, где ключевой челвоек приследует личные цели. Либо удовлетворяет амбиции в ущерб результату, либо пытается занять удобную для себя, но вредную для прогресса роль. Тут талант менеджера в том, чтобы понимать мотивацию всех участников квартета, и вовремя выводить тех, чья польза перестает перевешивать вред. И в этом вопросе доверие - снова ваш друг и товарищ. Конечно можно вывыести на чистую воду просто насев на сотрудника - но будьте уверены, в этом случае это ваш последний продуктивный совместный проект.
5/ у лидеров продукта есть внятный ответ на вопрос "а что дальше"
Где-то на пол пути к победе даже в самом классном продукте у любого нормального лидера будет вопрос "хорошо, ну вот сделаю я все это - а дальше что?". И худший ответ тут "посмотрим". Потому что нормальные лидеры с высокой агентностью "посмотрят" и сами. И найдут. И найдут еще до того, как вы доделали текущий проект. Поэтому критчиески важно, чтобы люди понимали общую картину, и куда вы их ведете, и ради чего усилия прямо сейчас. Худшее, что может случиться тут - это лидер, который не понимает куда двигаться дальше. Такой начнет сильно тормозить и команду и себя.
Вообще когда осознаешь, как много звезд должно сложиться, чтобы проект доехал до успеха начинаешь понимать, что любая организация держится на скотче и молитвах. И конечно же таланте хороших управленцев, которых надеюсь со временем будет становиться все больше.
Telegram
Артём обо всём
Чеклист здорового мл проекта
В Т по долгу службы мне надо присматривать за десятками МЛ проектов одновременно. Со временем у меня сложилась простая диагностическая рутина, которая вылавливает очевидные косяки. Если кто-то из олдов помнит Joel test для кодинга…
В Т по долгу службы мне надо присматривать за десятками МЛ проектов одновременно. Со временем у меня сложилась простая диагностическая рутина, которая вылавливает очевидные косяки. Если кто-то из олдов помнит Joel test для кодинга…
👍9💯4
А 8-го августа приходите на айти-пикник! Там я буду открывать поток GenAI своими рассуждениями на тему «а кому в gen-ai жить хорошо?». Какими проверочными вопросами отсекать откровенный скам, и как нанести непоправимую финансовую пользу организациям, внедряя эти ваши генеративки. До встречи!
💅8😎7❤4👍3
Я «отпилил» себе две ноги, чтобы стать senior tech manager’ом
Мой руководитель в одном из интервью очень точно подметил динамику карьерного роста в корпорации: «чтобы перейти на новый уровень управления тебе нужно отпилить себе любимую ногу, которая тебя делает успешным на текущем уровне, и отрастить новую». Я очень люблю эту метафору именно за точность ощущений в процессе.
В инженерных профессиях подавляющее большинство руководителей начинают линейными инженерами. Ты набираешь экспертизу, все ловчее справляешься со все более сложными проблемами, и вот однажды, тебе предлагают (или ты сам принимаешь решение) стать тимлидом. И в этот момент очень важно не обманывать себя: тебе предлагают много денег за то, что ты начнешь постепенно терять свою хардовую экспертизу, все больше погружаясь в организационные вопросы. Взамен ты получаешь проявленность в организации и больше власти.
Худшее, что можно сделать в этой ситуации: это попытаться усидеть на двух стульях. Именно в таком сетапе рождаются микроменеджеры с пачкой джунов, которые «в соло держат небо на плечах». Не буду расписывать к чему это приводит, думаю вы и так таких ребят встречали. В крупных технологических компаниях это отлично понимают, и там есть понятие «терминального грейда», выше которого расти не обязательно - можно работать и заниматься любимым делом. А иногда и полезно вернуться на этот уровень из менеджмента, чтоб освежить тех скиллы (сам такое практиковал - жив здоров).
Этот фазовый переход с отпиливанием инженерной ноги оканчивается примерно на уровне мидл-менеджмента, где ты уже ведешь группу команд. Ты уже окончательно попрощался с чисто-инженерными вопросами. Ты гораздо более силен в управлении людьми и проектам, становишься лицом крупных инициатив и на контакте с ключевыми бизнес лидерами. И после нескольких крупных побед в полный рост встает новая развилка.
Выход в senior-level менеджмент предполагает очень важный сдвиг роли: тебе нужно уйти на вторые роли в конкретных проектах, и дать дорогу новому поколению лидеров. Теперь у тебя нет никакой возможности схватить штурвал инициативы и вытащить ее из канавы (потому что в это время на твоем уровне начнут решать вопросы без тебя). Твоя цель здесь - это сводить капитал с людьми, которые в состоянии его приумножить. Создавать для этого условия и управлять рисками. Уходить от ручного управления талантами в сторону создания систем, которые сами подымают талантливых людей вверх. Теперь нет никакого «твоего» успеха. Есть только успех твоих ребят.
Это на самом деле очень сложная перестройка, от которой иногда нужно осознанно отказываться. Например, когда ты еще чувсьвуешь, что ты хочешь побыть на первых ролях в интересных тебе проектах ради опыта/портфолио. Или ты в принципе чувствуешь в себе драйв быть на острие классных продуктов и инициатив с возможностью сказать «я это сделал». Причин может быть много, но как и в прошлый раз попытка усидеть на двух стульях приведет к полному разочарованию.
На мой взгляд правильная мотивация здесь - это искреннее желание поделиться опытом и взрастить людей, которые через какое-то время могли бы занять твою текущую позицию. Тогда новый уровень дохода поможет закрыть бытовые вопросы и даст больше уверенности в будущем, а сложности политики, стратегии и бюрократии будут понятной ценой, которую ты платишь, чтобы вырастить крутых лидеров.
Мой руководитель в одном из интервью очень точно подметил динамику карьерного роста в корпорации: «чтобы перейти на новый уровень управления тебе нужно отпилить себе любимую ногу, которая тебя делает успешным на текущем уровне, и отрастить новую». Я очень люблю эту метафору именно за точность ощущений в процессе.
В инженерных профессиях подавляющее большинство руководителей начинают линейными инженерами. Ты набираешь экспертизу, все ловчее справляешься со все более сложными проблемами, и вот однажды, тебе предлагают (или ты сам принимаешь решение) стать тимлидом. И в этот момент очень важно не обманывать себя: тебе предлагают много денег за то, что ты начнешь постепенно терять свою хардовую экспертизу, все больше погружаясь в организационные вопросы. Взамен ты получаешь проявленность в организации и больше власти.
Худшее, что можно сделать в этой ситуации: это попытаться усидеть на двух стульях. Именно в таком сетапе рождаются микроменеджеры с пачкой джунов, которые «в соло держат небо на плечах». Не буду расписывать к чему это приводит, думаю вы и так таких ребят встречали. В крупных технологических компаниях это отлично понимают, и там есть понятие «терминального грейда», выше которого расти не обязательно - можно работать и заниматься любимым делом. А иногда и полезно вернуться на этот уровень из менеджмента, чтоб освежить тех скиллы (сам такое практиковал - жив здоров).
Этот фазовый переход с отпиливанием инженерной ноги оканчивается примерно на уровне мидл-менеджмента, где ты уже ведешь группу команд. Ты уже окончательно попрощался с чисто-инженерными вопросами. Ты гораздо более силен в управлении людьми и проектам, становишься лицом крупных инициатив и на контакте с ключевыми бизнес лидерами. И после нескольких крупных побед в полный рост встает новая развилка.
Выход в senior-level менеджмент предполагает очень важный сдвиг роли: тебе нужно уйти на вторые роли в конкретных проектах, и дать дорогу новому поколению лидеров. Теперь у тебя нет никакой возможности схватить штурвал инициативы и вытащить ее из канавы (потому что в это время на твоем уровне начнут решать вопросы без тебя). Твоя цель здесь - это сводить капитал с людьми, которые в состоянии его приумножить. Создавать для этого условия и управлять рисками. Уходить от ручного управления талантами в сторону создания систем, которые сами подымают талантливых людей вверх. Теперь нет никакого «твоего» успеха. Есть только успех твоих ребят.
Это на самом деле очень сложная перестройка, от которой иногда нужно осознанно отказываться. Например, когда ты еще чувсьвуешь, что ты хочешь побыть на первых ролях в интересных тебе проектах ради опыта/портфолио. Или ты в принципе чувствуешь в себе драйв быть на острие классных продуктов и инициатив с возможностью сказать «я это сделал». Причин может быть много, но как и в прошлый раз попытка усидеть на двух стульях приведет к полному разочарованию.
На мой взгляд правильная мотивация здесь - это искреннее желание поделиться опытом и взрастить людей, которые через какое-то время могли бы занять твою текущую позицию. Тогда новый уровень дохода поможет закрыть бытовые вопросы и даст больше уверенности в будущем, а сложности политики, стратегии и бюрократии будут понятной ценой, которую ты платишь, чтобы вырастить крутых лидеров.
YouTube
Как расти в ML: трек руководителя
Начинаем второй сезон с темы, которая понравится всем, кто хочет развиваться в ML. Наш герой руководит ML-направлением в Т-Банке, но до этого изучал теоретическую физику, успел поработать в Яндексе и запустить свой стартап. Разберем его опыт, узнаем, как…
❤25👍11😎9
Артём обо всём
А 3-го августа в 17:00 залетайте на прямой эфир: иду в гости к Саше Поломодову разгонять про агентизацию не-айти энтерпрайза. Что по другому, а что ровно так же, как в агентизации инженерии. Приходите 😎
И если не получилось подключиться онлайн, то вот запись: Саша классный, было очень интересно поразгонять и за энтерпрайз и за старую-добрую софтверную инженерию
YouTube
Code of Leadership S2E7: Как внедрять GenAI в операционную работу с с Артемом Бондарем
Продолжаю разбираться, что происходит с работой, когда GenAI выходит за пределы разработки. В кодинге у модели есть кодовая база, инструменты и тесты. В обычном бизнес-процессе половина правил может жить в головах сотрудников, исключения - в переписке, а…
❤9👍5
Разогреваясь перед айти пикником заехал в гости на эфир Радио РБК к Аркадию Глушенкову тезисно поразгонять про трудности внедрения ИИ в Энтерпрайз. А углубимся мы в эти темы уже в субботу на айти пикнике! Расскажу про это в генеративном шатре в 13:00 и на панельке Норникеля в 15:00 в шатре «бигтех в каске». До встречи!
На фото обозреваю ситуацию на рынках.
❤20😎4👍2😁1
У меня дома варят трубы из-за протечки, так что я сижу в коридоре и изучаю B2B рынок GenAI
Делюсь наблюдениями. Какие модели дистрибьюции AI решений разной степени упакованности я вижу на рынке.
1 - продаем сырые токены
OAI, Antropic, Google, китайцы, Яндексы и сберы. Предполагается, что вы внутри продвинутые ребята, сами займетесь продуктизацией, либо компании высадят forward deploy engineers. А компании дадут фронтирные модели, заоптимизируют инференс и возьмут свои 50-100% маржи. Честный бизнес, но сильно опирается на силу экспертизы на стороне Энтерпрайзов. Дистрибьюция - через B2C, проф комьюнити и пиар вокруг силы фронтирныэ моделей и опенсорса. Далее - через консалтинг и мелких интеграторов. Рычаг - цена и свойства моделей. Короче база, но большая часть добавочной ценности дальше по цепочке
2 - продавать general-purpose ассистентов
Это Энтерпрайз версии B2C ассистентов. Из плюшек - управление доступами и бюджетами и разной степени интеграция с хранилищами данных. От готовой интеграции с экосистемой Microsoft 365, до возможности подключать кастомные MCP у Claude. Дистрибьюция через B2C клиентов, которые уже подсели на инструмент, или через enterprise бандловые подписки. Рычаг - популярность в В2С против машины корпоративных продаж. Пока побеждает народная любовь, но посмотрим, как будет. Там кажется будет тяни-толкай с ценами, потому что эффекты таких внедрений слабозаметны, хоть и стали гигиеническим минимумом
3 - платформы агентов для операций
Тут может показаться, что я про конструкторы типо langflow, но самые прикольные и настоящие платформы - это апсейл к текущим платформам данных. Классный пример - agentsforce от salesforce. Там уже есть все интегры и ручек и данных, останется только наклепать самих агентов. Туда же движется Microsoft со своим копайлотом. Дистрибьюция - через экосистемы, где уже есть все данные. Кто продает CRM/ERP, тот держит этот рынок имхо
4 - копилоты для офисных чуваков
Ребята, которые продают инструменты офисной продуктивности встраивают туда ai-фичи. Офисные пакеты, таск трекеры, видеозвонки. Дистрибьюция поверх существующей экосистемы инструментов. Тут естественно Microsoft 360 и все их подражатели. Все, кто пытается строить поверх чужой экосистемы рискуют быть съеденимы экосистемой
5 - копилоты/среды агентов для SDLC
Это наш любимый Claude code и прочие. Продаются, как платформа для стандартизированной среды разработки. Дистрибутируется через среду power-user’ов. Кажется, что даже нечего объяснять, мы сами их дистрибьюцией по сути занимались последний год
6 - вертикальные утилиты под конкретные профессии
Те самые «компания-промпт поверх чат гпт». Самые широко представленные по абсолютному количеству, но самые несчастные по масштабам рынков и оседающей добавочной ценности. Дистрибьюция как и у классических вертикальных SaaS. Сложный и болезненный путь самураев
7 - вертикальные е2е сервисы на базе GenAI
Самые любопытные и слабо представленные в этом паноптикуме ребята. При этом, вероятно, самые перспективные с точки зрения возврата капитала. Но про них хочется поговорить отдельным будущим постом.
Делюсь наблюдениями. Какие модели дистрибьюции AI решений разной степени упакованности я вижу на рынке.
1 - продаем сырые токены
OAI, Antropic, Google, китайцы, Яндексы и сберы. Предполагается, что вы внутри продвинутые ребята, сами займетесь продуктизацией, либо компании высадят forward deploy engineers. А компании дадут фронтирные модели, заоптимизируют инференс и возьмут свои 50-100% маржи. Честный бизнес, но сильно опирается на силу экспертизы на стороне Энтерпрайзов. Дистрибьюция - через B2C, проф комьюнити и пиар вокруг силы фронтирныэ моделей и опенсорса. Далее - через консалтинг и мелких интеграторов. Рычаг - цена и свойства моделей. Короче база, но большая часть добавочной ценности дальше по цепочке
2 - продавать general-purpose ассистентов
Это Энтерпрайз версии B2C ассистентов. Из плюшек - управление доступами и бюджетами и разной степени интеграция с хранилищами данных. От готовой интеграции с экосистемой Microsoft 365, до возможности подключать кастомные MCP у Claude. Дистрибьюция через B2C клиентов, которые уже подсели на инструмент, или через enterprise бандловые подписки. Рычаг - популярность в В2С против машины корпоративных продаж. Пока побеждает народная любовь, но посмотрим, как будет. Там кажется будет тяни-толкай с ценами, потому что эффекты таких внедрений слабозаметны, хоть и стали гигиеническим минимумом
3 - платформы агентов для операций
Тут может показаться, что я про конструкторы типо langflow, но самые прикольные и настоящие платформы - это апсейл к текущим платформам данных. Классный пример - agentsforce от salesforce. Там уже есть все интегры и ручек и данных, останется только наклепать самих агентов. Туда же движется Microsoft со своим копайлотом. Дистрибьюция - через экосистемы, где уже есть все данные. Кто продает CRM/ERP, тот держит этот рынок имхо
4 - копилоты для офисных чуваков
Ребята, которые продают инструменты офисной продуктивности встраивают туда ai-фичи. Офисные пакеты, таск трекеры, видеозвонки. Дистрибьюция поверх существующей экосистемы инструментов. Тут естественно Microsoft 360 и все их подражатели. Все, кто пытается строить поверх чужой экосистемы рискуют быть съеденимы экосистемой
5 - копилоты/среды агентов для SDLC
Это наш любимый Claude code и прочие. Продаются, как платформа для стандартизированной среды разработки. Дистрибутируется через среду power-user’ов. Кажется, что даже нечего объяснять, мы сами их дистрибьюцией по сути занимались последний год
6 - вертикальные утилиты под конкретные профессии
Те самые «компания-промпт поверх чат гпт». Самые широко представленные по абсолютному количеству, но самые несчастные по масштабам рынков и оседающей добавочной ценности. Дистрибьюция как и у классических вертикальных SaaS. Сложный и болезненный путь самураев
7 - вертикальные е2е сервисы на базе GenAI
Самые любопытные и слабо представленные в этом паноптикуме ребята. При этом, вероятно, самые перспективные с точки зрения возврата капитала. Но про них хочется поговорить отдельным будущим постом.
❤9😁4💅3👍2😎2