📊 Unit-экономика ИИ-проекта. От «а вдруг заработает» к управляемому росту.
🧐 Когда вы запускаете ИИ-продукт, легко увлечься технологией:
— «У нас SOTA-модель!»
— «Инференс за 200 мс!»
— «Cherry-picked демки взрывают мозг!»
🥺 Но на первом же совещании с инвестором вас спросят не про F1-score, а про CAC, LTV и payback.
⁉️ И тут начинается самое сложное - как вообще считать unit-экономику для ИИ?
Потому что:
📌 Выручка зависит от конверсии free в paid
📌 COGS это не только хостинг, а токены + GPU + data labeling
📌 CAC - не просто маркетинг, а стоимость привлечения платящего юзера
📌 Gross margin рушится, если не учесть нагрузку от free-пользователей
🔧 Поэтому я собрал готовый калькулятор unit-экономики для ИИ-проектов с поддержкой реалий российского рынка:
✅ Три модели монетизации: SaaS, лицензия, интеграция
✅ Детализация затрат:
– Токены (in/out) и GPU на запрос
– Data labeling на платящего
– Персонал (с учётом ИТ-льгот 7.6%)
– Маркетинг (онлайн + оффлайн)
✅ Несколько сценариев: базовый / оптимистичный / пессимистичный
✅ Ключевые метрики:
– LTV:CAC
– Payback
– Gross Margin
– TCO ×1 - полная стоимость владения одним юнитом
✅ Аналитика и рекомендации - базовые рекомендация на rule based подходе
✅ Полностью автономный HTML-файл - работает оффлайн, без регистрации
💡 Для кого это:
📌 PM/Product Owner - чтобы обосновать roadmap и приоритеты
📌Founder/CEO чтобы быстро прикинуть цифры
📌CFO/Finance - для построения P&L и прогноза cash flow
📌Инженер - чтобы понять, как архитектура влияет на экономику
Unit-экономика - это не «финансовая бюрократия». Это ваша «система раннего предупреждения».
📉Если LTV:CAC < 3 — вы масштабируете убытки.
🗓️Если payback > 12 мес. — вы сжигаете кэш быстрее, чем растёте.
🧮 А если вы не считаете COGS на платящего — вы просто не видите реальную маржу.
Этот калькулятор - инструмент принятия решений, а не просто таблица.
Он помогает не угадывать, а считать - и строить ИИ-продукт, который зарабатывает, и проверять гипотезы быстро пока не стало слишком больно.
Важно: в любом случае советую проверять расчеты 😉
Если тебе отдается в печени все, то о чем я написал, то калькулятор в следующем посте 👇👇👇
🧐 Когда вы запускаете ИИ-продукт, легко увлечься технологией:
— «У нас SOTA-модель!»
— «Инференс за 200 мс!»
— «Cherry-picked демки взрывают мозг!»
🥺 Но на первом же совещании с инвестором вас спросят не про F1-score, а про CAC, LTV и payback.
⁉️ И тут начинается самое сложное - как вообще считать unit-экономику для ИИ?
Потому что:
📌 Выручка зависит от конверсии free в paid
📌 COGS это не только хостинг, а токены + GPU + data labeling
📌 CAC - не просто маркетинг, а стоимость привлечения платящего юзера
📌 Gross margin рушится, если не учесть нагрузку от free-пользователей
🔧 Поэтому я собрал готовый калькулятор unit-экономики для ИИ-проектов с поддержкой реалий российского рынка:
✅ Три модели монетизации: SaaS, лицензия, интеграция
✅ Детализация затрат:
– Токены (in/out) и GPU на запрос
– Data labeling на платящего
– Персонал (с учётом ИТ-льгот 7.6%)
– Маркетинг (онлайн + оффлайн)
✅ Несколько сценариев: базовый / оптимистичный / пессимистичный
✅ Ключевые метрики:
– LTV:CAC
– Payback
– Gross Margin
– TCO ×1 - полная стоимость владения одним юнитом
✅ Аналитика и рекомендации - базовые рекомендация на rule based подходе
✅ Полностью автономный HTML-файл - работает оффлайн, без регистрации
💡 Для кого это:
📌 PM/Product Owner - чтобы обосновать roadmap и приоритеты
📌Founder/CEO чтобы быстро прикинуть цифры
📌CFO/Finance - для построения P&L и прогноза cash flow
📌Инженер - чтобы понять, как архитектура влияет на экономику
Unit-экономика - это не «финансовая бюрократия». Это ваша «система раннего предупреждения».
📉Если LTV:CAC < 3 — вы масштабируете убытки.
🗓️Если payback > 12 мес. — вы сжигаете кэш быстрее, чем растёте.
🧮 А если вы не считаете COGS на платящего — вы просто не видите реальную маржу.
Этот калькулятор - инструмент принятия решений, а не просто таблица.
Он помогает не угадывать, а считать - и строить ИИ-продукт, который зарабатывает, и проверять гипотезы быстро пока не стало слишком больно.
Важно: в любом случае советую проверять расчеты 😉
Если тебе отдается в печени все, то о чем я написал, то калькулятор в следующем посте 👇👇👇
👍1🔥1
AI UE Calc .html
39.6 KB
p.s Не работает с Айфона / IOS не сумел победить :(. Только десктоп и Андрюша.
P.S. Делитесь тем, что вас беспокоит при расчете ии проектов, возможно именно ваша боль появиться как фича в новой версии калькулятора!
P.S. Делитесь тем, что вас беспокоит при расчете ии проектов, возможно именно ваша боль появиться как фича в новой версии калькулятора!
❤1🔥1
В продолжение прошлой темы.
Если ваще расписание выглядит как-то так как на прикрепленном сообщений, то у меня для вас плохие новости - вы не управляете процессом, а процесс управляет вами.
Да я залетел в 2 проекта с двух ног, когда они уже на всех парах летели как нам казалось к релизу, но тут выяснились подводные камни и раскиданные грабли и развешанные чеховские ружья на старте проекта которые сыграли свою роль, но об этом в следующий раз (да, будет длиннопост про предпроектную стадию и как ее организовать так, что бы не тушить пожары в проде).
🤯 А сегодня о том - как начать валидировать гипотезы и убеждать стейхолдеров так, что бы это не превратилось в бесконечную череду бессмысленных совещаний и конф-коллов.
И так что же тут основное, а вот что:
🆘1. Не перегружать ЛПР техничкой - она им нафиг не нужна и в 99% им фиолетово как будет технически реализован продукт, главное что бы он закрывал бизнес боль и давал бизнес-эффект.
Брат, если ты начинаешь презентацию со слов: «Мы используем fine-tuned LLaMA-3 с RAG и vector DB на базе Pinecone…» - ты уже проиграл.
Он не хочет слышать про:
- precision/recall,
- latency модели,
- архитектуру API.
Он хочет слышать - «Это сэкономит 48 млн ₽ в год за счёт недонайма 25 операторов».
Техническая детализация - для технической команды.
На встрече со стейкхолдером - только бизнес-фрейм.
🤑2. Бизнес-эффект должен быть четко выражен в понятных ЛПР терминах - экономия денег за счет чего-то что вы автоматизируете (кусок процесса, функция etc.) за счет упрощения, удешевления, недонайма, сокращения и всего такого.
«Улучшим клиентский опыт» — это поэзия, а не аргумент.
«Сократим время обработки» - надежда, а не метрика.
🎁3. Всегда говорите в терминах TCO - сколько будет стоить не только реализовать, но и внедрить и поддерживать и не съест это всю экономию которую вы зафиксировали в пункте 2.
Да, ты посчитал, что автоматизация сэкономит 50 млн ₽.
Но сколько будет стоить поддержка?
- Облачные ресурсы?
- Мониторинг дрифта данных?
- Переобучение модели?
- Интеграция с 12 legacy ИС?
Gartner говорит: 70% ИИ-проектов недооценивают TCO и очень зря!
🤝4. Любая встреча должна начинаться повесткой и заканчиваться протоколом! Нет встреч ради встреч, каждая встреча должна заканчиваться принятым решением! И лучше всего с видеозаписью.
Если повестки нет - не иду.
Если протокола не будет - не участвую.
Это не бюрократия. Это защита от хаоса.
🤖5. Заручитесь поддержкой технической команды - пусть они присутствуют на встречах со стейхолдерами и подтверждают ваши слова, когда вы будете «срезать» лишнее с хотелок бизнеса и говорить «нет» на «очень крутую фичу» от стейхолдеров.
Когда стейкхолдер говорит:
- ты можешь сказать «нет».
Но если рядом сидит DS или архитектор и спокойно говорит:
отказ звучит не как твоё мнение, а как реальность.
Техническая команда — не «исполнители».
Они - соавторы границ возможного.
И чем раньше стейкхолдер увидит, что «быстро» ≠ «возможно», тем меньше будет «очень крутых фич».
💟6. Формализуйте и согласуйте все требования (хотя бы по email) до старта проработке БФТ.
БФТ - не место для уточнений.
Это результат уточнений.
Поэтому:
- Все требования в письменной форме (лучше в email или Notion).
- Все изменения только через change request.
- Все решения подтверждены протоколом.
⁉️ Почему это поможет сократить безсмысленные встречи на 85%?
📌Ты убираешь импровизацию - всё по протоколу.
📌Ты убираешь двусмысленность - всё зафиксировано.
📌Ты убираешь «вот бы ещё» - есть технический якорь.
📌Ты убираешь «а как это работает?» - говоришь на языке бизнеса.
📌Ты убираешь иллюзии - считаешь TCO vs эффект.
И остаётся только одно - принять решение.
😎Примени эти 6 правил. И посмотри, как твоё расписание превратится из «кризис → кризис 2.0» в «встреча → решение → результат».
Удачи и пусть у тебя будет меньше бессмысленных встреч и максимум пользы! 😉
Если ваще расписание выглядит как-то так как на прикрепленном сообщений, то у меня для вас плохие новости - вы не управляете процессом, а процесс управляет вами.
Да я залетел в 2 проекта с двух ног, когда они уже на всех парах летели как нам казалось к релизу, но тут выяснились подводные камни и раскиданные грабли и развешанные чеховские ружья на старте проекта которые сыграли свою роль, но об этом в следующий раз (да, будет длиннопост про предпроектную стадию и как ее организовать так, что бы не тушить пожары в проде).
🤯 А сегодня о том - как начать валидировать гипотезы и убеждать стейхолдеров так, что бы это не превратилось в бесконечную череду бессмысленных совещаний и конф-коллов.
И так что же тут основное, а вот что:
🆘1. Не перегружать ЛПР техничкой - она им нафиг не нужна и в 99% им фиолетово как будет технически реализован продукт, главное что бы он закрывал бизнес боль и давал бизнес-эффект.
Брат, если ты начинаешь презентацию со слов: «Мы используем fine-tuned LLaMA-3 с RAG и vector DB на базе Pinecone…» - ты уже проиграл.
Он не хочет слышать про:
- precision/recall,
- latency модели,
- архитектуру API.
Он хочет слышать - «Это сэкономит 48 млн ₽ в год за счёт недонайма 25 операторов».
Техническая детализация - для технической команды.
На встрече со стейкхолдером - только бизнес-фрейм.
🤑2. Бизнес-эффект должен быть четко выражен в понятных ЛПР терминах - экономия денег за счет чего-то что вы автоматизируете (кусок процесса, функция etc.) за счет упрощения, удешевления, недонайма, сокращения и всего такого.
«Улучшим клиентский опыт» — это поэзия, а не аргумент.
«Сократим время обработки» - надежда, а не метрика.
🎁3. Всегда говорите в терминах TCO - сколько будет стоить не только реализовать, но и внедрить и поддерживать и не съест это всю экономию которую вы зафиксировали в пункте 2.
Да, ты посчитал, что автоматизация сэкономит 50 млн ₽.
Но сколько будет стоить поддержка?
- Облачные ресурсы?
- Мониторинг дрифта данных?
- Переобучение модели?
- Интеграция с 12 legacy ИС?
Gartner говорит: 70% ИИ-проектов недооценивают TCO и очень зря!
🤝4. Любая встреча должна начинаться повесткой и заканчиваться протоколом! Нет встреч ради встреч, каждая встреча должна заканчиваться принятым решением! И лучше всего с видеозаписью.
Если повестки нет - не иду.
Если протокола не будет - не участвую.
Это не бюрократия. Это защита от хаоса.
🤖5. Заручитесь поддержкой технической команды - пусть они присутствуют на встречах со стейхолдерами и подтверждают ваши слова, когда вы будете «срезать» лишнее с хотелок бизнеса и говорить «нет» на «очень крутую фичу» от стейхолдеров.
Когда стейкхолдер говорит:
«А давайте ещё добавим NLP для анализа настроений в соцсетях! Это же быстро!»
- ты можешь сказать «нет».
Но если рядом сидит DS или архитектор и спокойно говорит:
«Для этого нужны данные, которых нет. И 6 месяцев на сбор. Это выведет нас за бюджет»
отказ звучит не как твоё мнение, а как реальность.
Техническая команда — не «исполнители».
Они - соавторы границ возможного.
И чем раньше стейкхолдер увидит, что «быстро» ≠ «возможно», тем меньше будет «очень крутых фич».
💟6. Формализуйте и согласуйте все требования (хотя бы по email) до старта проработке БФТ.
БФТ - не место для уточнений.
Это результат уточнений.
Поэтому:
- Все требования в письменной форме (лучше в email или Notion).
- Все изменения только через change request.
- Все решения подтверждены протоколом.
⁉️ Почему это поможет сократить безсмысленные встречи на 85%?
📌Ты убираешь импровизацию - всё по протоколу.
📌Ты убираешь двусмысленность - всё зафиксировано.
📌Ты убираешь «вот бы ещё» - есть технический якорь.
📌Ты убираешь «а как это работает?» - говоришь на языке бизнеса.
📌Ты убираешь иллюзии - считаешь TCO vs эффект.
И остаётся только одно - принять решение.
😎Примени эти 6 правил. И посмотри, как твоё расписание превратится из «кризис → кризис 2.0» в «встреча → решение → результат».
Удачи и пусть у тебя будет меньше бессмысленных встреч и максимум пользы! 😉
❤1🔥1
Что должен знать продакт-овнер в AI/ML, если он не инженер
Ты - не исследователь, не инженер, не архитектор. Ты - продакт. Но ты работаешь не с кнопочками и формочками, а с системами, где “фича” может весить два месяца работы GPU и $150k. И если ты до сих пор думаешь, что твоя роль - просто “передать пожелания бизнеса дата-сайентистам”, то либо тебе повезёт, либо тебя заменит ИИ агент. Агент, кстати, будет делать это лучше.
Давай разберём, что на самом деле нужно знать, понимать и чувствовать продакту в AI/ML-продукте особенно если ты претендуешь на роль технического продакт-овнера, head of product или даже CPO платформы агентов
1. Бизнес-проблема - твой компас.
Многие начинают с “А давайте внедрим эмбеддинги / GNN / агентов!”
Но настоящий продакт начинает с - “Что мы теряем, если не внедрим ничего? И как измерим выгоду, если внедрим?”
Ты обязан уметь операционализировать неопределённость. То есть перевести расплывчатую боль бизнеса (“клиенты уходят”) в измеримый эффект (“можно снизить churn на 12%, если предсказывать отток за 7 дней до ухода с точностью ≥0.85”).
И тут ты должен понимать бизнес-метрику vs модельную метрику.
📌 AUC = 0.98? Круто. Но если это не влияет на retention - это просто цифра.
📌 Precision vs Recall? Зависит от стоимости ошибки. Ложно-положительный отток - это потерянные маркетинговые бюджеты. Ложно-отрицательный - ушедший клиент. Сравни их цену.
Ты не выбираешь метрику. Ты выбираешь экономику.
2. Данные - это не топливо. Это твоя ответственность.
Ты обязан понимать:
📌 Откуда берутся данные (event-трекинг? CRM? логи?)
📌 Как часто они обновляются (real-time? batch раз в сутки?)
📌 Есть ли в них data leakage (например, target попал в features)
📌 Есть ли дрейф данных - когда распределение данных в проде отличается от обучающего датасета
Если ты не контролируешь качество данных, ты не контролируешь продукт. И не важно, кто формально ответственен за DQ в глазах бизнеса - виноват будешь ты.
3. Онлайн vs оффлайн граница твоей ответственности
Вот ключевой момент, который рушит 80% AI-продуктов на стенде модель выдаёт AUC = 0.96, в проде - пользователи негодуют, конверсия падает
Почему? Потому что ты не продумал онлайн-часть:
📌Как быстро модель должна отвечать? (latency <200ms - иначе UX страдает)
📌Как часто она пересчитывается? (real-time inference или precomputed recommendations?)
📌Как обрабатывается cold start? (новый пользователь = белый лист для модели)
📌Как ты логируешь предсказания и факты, чтобы потом посчитать реальный uplift?
Здесь заканчивается зона ответственности DS и начинается твоя.
продолжение ниже 👇👇👇
Ты - не исследователь, не инженер, не архитектор. Ты - продакт. Но ты работаешь не с кнопочками и формочками, а с системами, где “фича” может весить два месяца работы GPU и $150k. И если ты до сих пор думаешь, что твоя роль - просто “передать пожелания бизнеса дата-сайентистам”, то либо тебе повезёт, либо тебя заменит ИИ агент. Агент, кстати, будет делать это лучше.
Давай разберём, что на самом деле нужно знать, понимать и чувствовать продакту в AI/ML-продукте особенно если ты претендуешь на роль технического продакт-овнера, head of product или даже CPO платформы агентов
1. Бизнес-проблема - твой компас.
Многие начинают с “А давайте внедрим эмбеддинги / GNN / агентов!”
Но настоящий продакт начинает с - “Что мы теряем, если не внедрим ничего? И как измерим выгоду, если внедрим?”
Ты обязан уметь операционализировать неопределённость. То есть перевести расплывчатую боль бизнеса (“клиенты уходят”) в измеримый эффект (“можно снизить churn на 12%, если предсказывать отток за 7 дней до ухода с точностью ≥0.85”).
И тут ты должен понимать бизнес-метрику vs модельную метрику.
📌 AUC = 0.98? Круто. Но если это не влияет на retention - это просто цифра.
📌 Precision vs Recall? Зависит от стоимости ошибки. Ложно-положительный отток - это потерянные маркетинговые бюджеты. Ложно-отрицательный - ушедший клиент. Сравни их цену.
Ты не выбираешь метрику. Ты выбираешь экономику.
2. Данные - это не топливо. Это твоя ответственность.
Модель - лишь зеркало твоих данных. Если в данных мусор, твоя модель - писатель с шизофренией.
Ты обязан понимать:
📌 Откуда берутся данные (event-трекинг? CRM? логи?)
📌 Как часто они обновляются (real-time? batch раз в сутки?)
📌 Есть ли в них data leakage (например, target попал в features)
📌 Есть ли дрейф данных - когда распределение данных в проде отличается от обучающего датасета
Если ты не контролируешь качество данных, ты не контролируешь продукт. И не важно, кто формально ответственен за DQ в глазах бизнеса - виноват будешь ты.
3. Онлайн vs оффлайн граница твоей ответственности
Вот ключевой момент, который рушит 80% AI-продуктов на стенде модель выдаёт AUC = 0.96, в проде - пользователи негодуют, конверсия падает
Почему? Потому что ты не продумал онлайн-часть:
📌Как быстро модель должна отвечать? (latency <200ms - иначе UX страдает)
📌Как часто она пересчитывается? (real-time inference или precomputed recommendations?)
📌Как обрабатывается cold start? (новый пользователь = белый лист для модели)
📌Как ты логируешь предсказания и факты, чтобы потом посчитать реальный uplift?
Здесь заканчивается зона ответственности DS и начинается твоя.
Ты должен проектировать всю цепочку от гипотезы через данных к обучению и интеграции с мониторингом получая обратную связь.
продолжение ниже 👇👇👇
🔥2❤1
4. AI - не всегда решение.
Ты должен уметь задавать себе правильный вопрос - “А что, если мы просто добавим флаг в интерфейс и правило в workflow?”
Если задачу можно решить бизнес-правилом то делай так. Это дешевле, быстрее, прозрачнее и надёжнее.
AI/ML оправдан если:
📌 Паттерны сложны и нестабильны (например, распознавание намерений в чате)
📌 Объём решений слишком велик для ручного управления (тысячи персонализированных предложений)
📌 Есть чёткий путь к измерению эффекта
5. Архитектура - ТВОЕ дело!
Ты не обязан проектировать pipeline. Но обязан понимать ограничения архитектуры:
📌Если у вас нет feature store’а вы не сможете быстро переключать фичи.
📌Если у вас нет A/B-платформы вы не докажете эффект модели.
📌Если у вас нет мониторинга drift’а вы внедрите “умный” продукт, который со временем станет глупее.
И особенно агентные архитектуры. Если ты строишь платформу агентов ты должен понимать:
📌Разницу между reactive и goal-driven агентами
📌Как они координируются (orchestration vs choreography)
📌Что такое “tool use” и почему это критично для utility
📌Как оценивать multi-agent взаимодействие (emergent behavior это не фича, это риск)
6. Ты - интерфейс между хаосом и логикой
Твоя главная суперсила - перевод
👨💼Бизнес говорит: “сделайте, чтобы клиенты не уходили”
🧑💼Ты говоришь инженерам: “нам нужна модель с recall ≥0.9 на класс ‘уход через 7 дней’, интегрированная в CRM, с алертами при деградации качества”
👷Инженеры говорят: “у нас нет лейблов”
🧑💼Ты говоришь бизнесу: “давайте запустим пилот с ручной разметкой 500 обращений — это даст нам baseline”
Если ты не говоришь на обоих языках ты просто мессенджер. А мессенджеры легко заменяются группой в телеге.
7. Заключение.
В AI-продукте нет места “просто запустить что-то”. Каждая инициатива это инвестиция.
И ты должен уметь:
📌 Оценить ROI до старта
📌 Построить контрольную группу во время
📌 Посчитать реальный бизнес-эффект после
📌 Понимать где инженерный компромисс, а где overhead
📌 Знать из каких данных создано решение, кто их владелец и как часто они обновляются
А самое главное - как именно на сколько и где твое решение будет полезно бизнесу!
Ты должен уметь задавать себе правильный вопрос - “А что, если мы просто добавим флаг в интерфейс и правило в workflow?”
Если задачу можно решить бизнес-правилом то делай так. Это дешевле, быстрее, прозрачнее и надёжнее.
AI/ML оправдан если:
📌 Паттерны сложны и нестабильны (например, распознавание намерений в чате)
📌 Объём решений слишком велик для ручного управления (тысячи персонализированных предложений)
📌 Есть чёткий путь к измерению эффекта
LLM - не универсальный гаечный ключ. Если ты используешь LLM там, где хватило бы регулярки - ты забиваешь гвозди микроскопом.
5. Архитектура - ТВОЕ дело!
Ты не обязан проектировать pipeline. Но обязан понимать ограничения архитектуры:
📌Если у вас нет feature store’а вы не сможете быстро переключать фичи.
📌Если у вас нет A/B-платформы вы не докажете эффект модели.
📌Если у вас нет мониторинга drift’а вы внедрите “умный” продукт, который со временем станет глупее.
И особенно агентные архитектуры. Если ты строишь платформу агентов ты должен понимать:
📌Разницу между reactive и goal-driven агентами
📌Как они координируются (orchestration vs choreography)
📌Что такое “tool use” и почему это критично для utility
📌Как оценивать multi-agent взаимодействие (emergent behavior это не фича, это риск)
6. Ты - интерфейс между хаосом и логикой
Твоя главная суперсила - перевод
👨💼Бизнес говорит: “сделайте, чтобы клиенты не уходили”
🧑💼Ты говоришь инженерам: “нам нужна модель с recall ≥0.9 на класс ‘уход через 7 дней’, интегрированная в CRM, с алертами при деградации качества”
👷Инженеры говорят: “у нас нет лейблов”
🧑💼Ты говоришь бизнесу: “давайте запустим пилот с ручной разметкой 500 обращений — это даст нам baseline”
Если ты не говоришь на обоих языках ты просто мессенджер. А мессенджеры легко заменяются группой в телеге.
7. Заключение.
Ты - не менеджер фич. Ты - ответственный за эффект
В AI-продукте нет места “просто запустить что-то”. Каждая инициатива это инвестиция.
И ты должен уметь:
📌 Оценить ROI до старта
📌 Построить контрольную группу во время
📌 Посчитать реальный бизнес-эффект после
📌 Понимать где инженерный компромисс, а где overhead
📌 Знать из каких данных создано решение, кто их владелец и как часто они обновляются
А самое главное - как именно на сколько и где твое решение будет полезно бизнесу!
Хабр
Каким должен быть Feature Store, чтобы оптимизировать работу с ML-моделями
В работе с данными для обучения нейросетей много рутины: под каждую ML-модель нужно создать датасет, потом «вычеркнуть» лишние признаки (фичи) и протестировать точность предсказаний. Иногда при...
🔥1
Forwarded from MLTimes
Alice AI обработала 2.9 миллиарда запросов в 2025 году
Яндекс раскрыл статистику использования нейросетей на базе Alice AI за 2025 год. Система обработала более 2.9 миллиарда запросов. Пользователи решали через AI задачи от бытовых до профессиональных.
В чат с Алисой AI отправили более 131 миллиона картинок. Система распознавала изображения и отвечала на вопросы. В сентябре появилась опция Оживи фото. С этого момента пользователи оживили более 180 миллионов фотографий, мемов и других изображений.
https://mltimes.ai/alice-ai-obrabotala-2-9-milliarda-zaprosov-v-2025-godu/
Яндекс раскрыл статистику использования нейросетей на базе Alice AI за 2025 год. Система обработала более 2.9 миллиарда запросов. Пользователи решали через AI задачи от бытовых до профессиональных.
В чат с Алисой AI отправили более 131 миллиона картинок. Система распознавала изображения и отвечала на вопросы. В сентябре появилась опция Оживи фото. С этого момента пользователи оживили более 180 миллионов фотографий, мемов и других изображений.
https://mltimes.ai/alice-ai-obrabotala-2-9-milliarda-zaprosov-v-2025-godu/
❤1👌1
Forwarded from MLTimes
Anthropic купит миллион TPU-чипов на $21 миллиард у Broadcom
SemiAnalysis сообщает о планах Anthropic приобрести около миллиона чипов Google TPUv7 Ironwood. Компания развернет их на площадках под собственным контролем. Это первый случай, когда передовая AI-лаборатория строит инфраструктуру такого масштаба вне облачной модели.
Чипы будут закупаться у Broadcom. Компания производит TPU по дизайну Google. Физическое развертывание возьмет на себя Fluidstack. Кабельная разводка, обкатка оборудования, приемочные испытания и обслуживание - их зона ответственности.
https://mltimes.ai/anthropic-kupit-million-tpu-chipov-na-21-milliard-u-broadcom/
SemiAnalysis сообщает о планах Anthropic приобрести около миллиона чипов Google TPUv7 Ironwood. Компания развернет их на площадках под собственным контролем. Это первый случай, когда передовая AI-лаборатория строит инфраструктуру такого масштаба вне облачной модели.
Чипы будут закупаться у Broadcom. Компания производит TPU по дизайну Google. Физическое развертывание возьмет на себя Fluidstack. Кабельная разводка, обкатка оборудования, приемочные испытания и обслуживание - их зона ответственности.
https://mltimes.ai/anthropic-kupit-million-tpu-chipov-na-21-milliard-u-broadcom/
❤1🔥1
👾 AI агенты в enterprise в 2025. Они уже не ждут команды. Они ждут, пока ты перестанешь им мешать.
Раньше, чтобы автоматизировать процесс, нужно было:
📌 найти проблему,
📌 уговорить аналитика её описать,
📌 выторговать бюджет,
📌 пережить три релиза, в которых всё сломалось,
📌 и получить благодарность от коллеги, который теперь делает в два раза больше, потому что это хозяйство надо обслуживать и сопровождать.
А теперь?
Теперь агенты сами строят многоходовки, проходят сквозь CRM, ERP, собирают данные из систем - и принимают решения. Не предлагают. Не спрашивают. Просто делают!
Сегодня на разборе относительно «свежее» исследование от Antropic. О том как агенты реально изменяют подходы к бизнесу в enterprise в 2025 году!
Итак ИИ-агенты уже работают.
Пока ты убеждаешь стейкхолдера, что «RAG - это инновация», мир движется дальше.
И да, это не гипербола. Это цитата из отчёта на конец 2025 года.
Заметь не “могут стать”, а они уже - инфраструктура.
И как они используются?
То есть твой коллега из финансов, аналитик из продаж и DevOps-инженер - их уже связывает не Slack-чат, а совместный агент, который согласовывает бюджет, данные и SLA без твоего участия.
Приятно, правда? 🤣
А вот ещё:
Не «повышение вовлечённости», не «ускорение инновационной культуры». А приносит отдачу! Измеримую. Экономическую. Отдачу.
А как насчёт кода?
То есть то о чем в России только говорят и запускают с низким эффектом (привет зеленый банк!) ТАМ уже реальность.
А вот конкретные примеры:
📌 Doctolib, кстати, оптимизировал процессы тестирования с недель на часы и теперь выпускает фичи на 40% быстрее.
А ты всё ещё споришь, в какую из систем по регламенту заносить тестовый план 😉
📌Thomson Reuters в юриспруденции - 150 лет прецедентного права за минуты.
📌 eSentire в кибербезе - анализ угроз за 7 минут вместо 5 часов при 95% совпадении с мнением экспертов.
📌 L’Oréal в ритейле - 44 000 человек в месяц получают ответы с точностью 99,9%, просто спросив агента.
🤷♂️А ты мне скажешь - «Но, у нас же«специфика, качество данных не позволяет и с legacy боль».
И знаешь что? Это нормально.
Вот ключевая разница -те, кто работает с этими проблемами, а не прячется за них - уже меняют правила игры!
Ты уже понял, что твоя ценность - в проектировании продуктов, где агенты уже часть workflow ландшафта?
P.S. Вопрос сейчас не в том внедрять ли агентов. Вопрос - как быстро ты сможешь их внедрить!
Раньше, чтобы автоматизировать процесс, нужно было:
📌 найти проблему,
📌 уговорить аналитика её описать,
📌 выторговать бюджет,
📌 пережить три релиза, в которых всё сломалось,
📌 и получить благодарность от коллеги, который теперь делает в два раза больше, потому что это хозяйство надо обслуживать и сопровождать.
А теперь?
Теперь агенты сами строят многоходовки, проходят сквозь CRM, ERP, собирают данные из систем - и принимают решения. Не предлагают. Не спрашивают. Просто делают!
Сегодня на разборе относительно «свежее» исследование от Antropic. О том как агенты реально изменяют подходы к бизнесу в enterprise в 2025 году!
Итак ИИ-агенты уже работают.
Пока ты убеждаешь стейкхолдера, что «RAG - это инновация», мир движется дальше.
И да, это не гипербола. Это цитата из отчёта на конец 2025 года.
«AI agents have moved from experimental to an essential part of an organization’s tech stack.»
«ИИ-агенты перешли из разряда экспериментов в разряд неотъемлемой части технологического стека организаций.»
Заметь не “могут стать”, а они уже - инфраструктура.
И как они используются?
«
More than half of organizations (57%) now deploy agents for multi-stage workflows, with 16% running cross-functional processes across multiple teams.
»
«
Более половины
организаций (57%) уже используют агентов в многоэтапных рабочих процессах, а 16%
запускают их в кросс-функциональных сценариях
между командами.»
То есть твой коллега из финансов, аналитик из продаж и DevOps-инженер - их уже связывает не Slack-чат, а совместный агент, который согласовывает бюджет, данные и SLA без твоего участия.
Приятно, правда? 🤣
А вот ещё:
«80% of organizations report their AI agent investments are already delivering measurable economic returns.»
«80% компаний сообщают, что их инвестиции в ИИ-агентов
уже приносят
измеримую экономическую отдачу.»
Не «повышение вовлечённости», не «ускорение инновационной культуры». А приносит отдачу! Измеримую. Экономическую. Отдачу.
А как насчёт кода?
«Nearly 90% of organizations use AI to assist with development, and 86% deploy agents for production code.»
«
Почти 90% компаний используют ИИ для помощи в разработке
, и 86% внедряют агентов в продакшен-код.»
То есть то о чем в России только говорят и запускают с низким эффектом (привет зеленый банк!) ТАМ уже реальность.
А вот конкретные примеры:
📌 Doctolib, кстати, оптимизировал процессы тестирования с недель на часы и теперь выпускает фичи на 40% быстрее.
А ты всё ещё споришь, в какую из систем по регламенту заносить тестовый план 😉
📌Thomson Reuters в юриспруденции - 150 лет прецедентного права за минуты.
📌 eSentire в кибербезе - анализ угроз за 7 минут вместо 5 часов при 95% совпадении с мнением экспертов.
📌 L’Oréal в ритейле - 44 000 человек в месяц получают ответы с точностью 99,9%, просто спросив агента.
🤷♂️А ты мне скажешь - «Но, у нас же«специфика, качество данных не позволяет и с legacy боль».
И знаешь что? Это нормально.
«The data points to three primary challenges - integration with existing systems (46%), data access and quality (42%), and change management needs (39%).»
«Главные вызовы - интеграция с существующими системами (46%), доступ и качество данных (42%) и необходимость управления изменениями (39%).»
Вот ключевая разница -те, кто работает с этими проблемами, а не прячется за них - уже меняют правила игры!
«Nine in 10 leaders report that agents are shifting how their teams work, with employees spending more time on strategic activities, relationship building, and skill development rather than routine execution.»
«9 из 10 лидеров отмечают, что агенты
меняют характер работы команд. С
отрудники тратят
больше времени
на стратегию и мысли о росте выручки и меньше на рутину.»
Ты уже понял, что твоя ценность - в проектировании продуктов, где агенты уже часть workflow ландшафта?
P.S. Вопрос сейчас не в том внедрять ли агентов. Вопрос - как быстро ты сможешь их внедрить!
❤1🔥1
Forwarded from MLTimes
Brookfield запустит дешевое облако Radiant для конкуренции с AWS
Brookfield Asset Management планирует запустить собственные облачные сервисы. Один из крупнейших управляющих инвестициями в альтернативные активы намерен конкурировать с гиперскейлерами. Об этом сообщает Silicon Angle со ссылкой на доклад в The Information. Компания будет сдавать в аренду ИИ-чипы напрямую клиентам. Бизнес-модель позволит снизить стоимость строительства и эксплуатации ИИ-центров обработки данных.
Новым бизнесом будет управлять подразделение Brookfield Radiant. Оно работает в связке с инфраструктурной программой стоимостью 100 млрд долларов. Программу анонсировали в ноябре 2025 года. Brookfield Artificial Intelligence Infrastructure Fund уже выделил на проект 10 млрд долларов. Половина этих средств поступит от отраслевых партнеров. Среди них NVIDIA и Kuwait Investment Authority.
https://mltimes.ai/brookfield-zapustit-deshevoe-oblako-radiant-dlya-konkurenczii-s-aws/
Brookfield Asset Management планирует запустить собственные облачные сервисы. Один из крупнейших управляющих инвестициями в альтернативные активы намерен конкурировать с гиперскейлерами. Об этом сообщает Silicon Angle со ссылкой на доклад в The Information. Компания будет сдавать в аренду ИИ-чипы напрямую клиентам. Бизнес-модель позволит снизить стоимость строительства и эксплуатации ИИ-центров обработки данных.
Новым бизнесом будет управлять подразделение Brookfield Radiant. Оно работает в связке с инфраструктурной программой стоимостью 100 млрд долларов. Программу анонсировали в ноябре 2025 года. Brookfield Artificial Intelligence Infrastructure Fund уже выделил на проект 10 млрд долларов. Половина этих средств поступит от отраслевых партнеров. Среди них NVIDIA и Kuwait Investment Authority.
https://mltimes.ai/brookfield-zapustit-deshevoe-oblako-radiant-dlya-konkurenczii-s-aws/
✍1❤1
Forwarded from How2AI (дядя_д)
This media is not supported in your browser
VIEW IN TELEGRAM
Гуманоидный робот Atlas готов к промышленному развертыванию – производство запущено в Бостоне, первые поставки в ближайшие месяцы отправятся Hyundai и Google DeepMind.
- Работать автономно и самостоятельно менять батареи без остановки (до 4 часов работы на одной)
- Мгновенно реплицировать новые навыки на весь флот роботов (гугловские модели под капотом)
- 56 степеней свободы, полностью вращающиеся суставы, поднимает до 50 кг
Hyundai инвестирует $26 млрд и строит завод мощностью 30 000 роботов в год.
@how2ai
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1🔥1
TCO vs ROI. Или как ии-мечты разбиваются о суровую sre-реальность.
Когда стейкхолдеры начинают обсуждать «инвестиции в ИИ», у них в глазах вспыхивает 🤑ROI - волшебный процентик, обещающий выручку, как у Скруджа МакДака.
А потом приходит TCO и аккуратно спрашивает: «А вы считали, сколько будет стоить не только обучить модель, но и содержать её, как капризного кота?»
😻 ROI (Return on Investment) это мечта:
📌 Сколько денег мы заработаем или сохраним?
📌 Какой эффект в % от текущих затрат?
📌 Через сколько месяцев всё окупится?
🤯 TCO (Total Cost of Ownership) - это реальность:
📌 Инфраструктура, лицензии, MLOps, хранение данных, ретрейны…
📌 Зарплата команды, которая будет эту систему держать на плаву
📌 Затраты на ошибки, когда модель вдруг начнёт рекомендовать покупать носки вместо ноутбуков
💡 Фишка в том, что в AI-проектах ROI часто рисуют красиво, а TCO - вскользь.
А потом оказывается, что «эффект от автоматизации» покрывается необходимостью нового найма в рост команды, расширение поддержки и необходимостью держать резерв мощности. Об этом не думает 90% на запуске.
🤓 Правило продукта
Если вы не можете оценить TCO - ваш ROI это не прогноз, а пожелание вселенной.
Потому что это все всплывает когда вы начинаете его масштабировать, все внезапно спрашивают - «А кто это будет сопровождать? Кто будет чинить, когда упадёт? Кто будет развивать?»
И тогда выясняется, что TCO - «это база», это считать надо!
🩼 MVP стоил 50 млн. Реальная операционка - в разы дороже
На старте проекта всё выглядело просто:
⚙️ 4 сервера с H100 для inference и fine-tuning,
⚙️ интеграция в IDE через плагин
⚙️ базовая система логирования и аудита
Но реальность оказалась сложнее:
1. Инфраструктура не «просто работает». H100 - это не только CapEx, но и:
📌 электропитание, охлаждение, резервирование,
📌 лицензии на CUDA, NVIDIA Enterprise Support,
📌 отказоустойчивость при пиковых нагрузках от более 6 тыс. пользователей.
2. Легаси не терпит «воткнуть и забыть». Чтобы решение заработало в корпоративной среде, пришлось:
📌 встроить в существующие IAM, SIEM, DLP
📌 сделать трассировку каждого токена (Compliance),
📌 разработать и внедрить отдельную систему аудита - кто, когда, что сгенерировал, куда вставил.
3. «Поддержка» превратилась в отдельную линию. Оказалось, что:
📌 DevOps-команда не справляется - нужны dedicated SRE для LLM-стека,
📌 Инциденты из-за «токсичных промптов» требуют дополнительного мониторинга,
📌 Баг в плагине IDE ломает workflow - нужно отдельно переделывать.
4. Продукт не останавливается развиваться на MVP. После запуска продукт не останавливает развитие и это требует:
📌 Полноценную продуктовую команду (PO, UX, аналитик),
📌 Расширенную MLE/DS-команду (fine-tuning, evaluation, guardrails),
📌 Затраты под интеграции (не только IDE, но и Git, Jira, Confluence или их аналогов).
В итоге то, что начиналось как «инструмент для разработчиков», стало отдельным цифровым активом с полным жизненным циклом.
продолжение ниже 👇👇👇
Когда стейкхолдеры начинают обсуждать «инвестиции в ИИ», у них в глазах вспыхивает 🤑ROI - волшебный процентик, обещающий выручку, как у Скруджа МакДака.
А потом приходит TCO и аккуратно спрашивает: «А вы считали, сколько будет стоить не только обучить модель, но и содержать её, как капризного кота?»
😻 ROI (Return on Investment) это мечта:
📌 Сколько денег мы заработаем или сохраним?
📌 Какой эффект в % от текущих затрат?
📌 Через сколько месяцев всё окупится?
🤯 TCO (Total Cost of Ownership) - это реальность:
📌 Инфраструктура, лицензии, MLOps, хранение данных, ретрейны…
📌 Зарплата команды, которая будет эту систему держать на плаву
📌 Затраты на ошибки, когда модель вдруг начнёт рекомендовать покупать носки вместо ноутбуков
💡 Фишка в том, что в AI-проектах ROI часто рисуют красиво, а TCO - вскользь.
А потом оказывается, что «эффект от автоматизации» покрывается необходимостью нового найма в рост команды, расширение поддержки и необходимостью держать резерв мощности. Об этом не думает 90% на запуске.
🤓 Правило продукта
Если вы не можете оценить TCO - ваш ROI это не прогноз, а пожелание вселенной.
Потому что это все всплывает когда вы начинаете его масштабировать, все внезапно спрашивают - «А кто это будет сопровождать? Кто будет чинить, когда упадёт? Кто будет развивать?»
И тогда выясняется, что TCO - «это база», это считать надо!
🩼 MVP стоил 50 млн. Реальная операционка - в разы дороже
На старте проекта всё выглядело просто:
⚙️ 4 сервера с H100 для inference и fine-tuning,
⚙️ интеграция в IDE через плагин
⚙️ базовая система логирования и аудита
Но реальность оказалась сложнее:
1. Инфраструктура не «просто работает». H100 - это не только CapEx, но и:
📌 электропитание, охлаждение, резервирование,
📌 лицензии на CUDA, NVIDIA Enterprise Support,
📌 отказоустойчивость при пиковых нагрузках от более 6 тыс. пользователей.
2. Легаси не терпит «воткнуть и забыть». Чтобы решение заработало в корпоративной среде, пришлось:
📌 встроить в существующие IAM, SIEM, DLP
📌 сделать трассировку каждого токена (Compliance),
📌 разработать и внедрить отдельную систему аудита - кто, когда, что сгенерировал, куда вставил.
3. «Поддержка» превратилась в отдельную линию. Оказалось, что:
📌 DevOps-команда не справляется - нужны dedicated SRE для LLM-стека,
📌 Инциденты из-за «токсичных промптов» требуют дополнительного мониторинга,
📌 Баг в плагине IDE ломает workflow - нужно отдельно переделывать.
4. Продукт не останавливается развиваться на MVP. После запуска продукт не останавливает развитие и это требует:
📌 Полноценную продуктовую команду (PO, UX, аналитик),
📌 Расширенную MLE/DS-команду (fine-tuning, evaluation, guardrails),
📌 Затраты под интеграции (не только IDE, но и Git, Jira, Confluence или их аналогов).
В итоге то, что начиналось как «инструмент для разработчиков», стало отдельным цифровым активом с полным жизненным циклом.
продолжение ниже 👇👇👇
❤2🔥1
🗿Где же TCOx1 и COGSx1?
В бизнес-кейсе выше (ты уже понял что речь тдет о copilot’е) никто не посчитал:
1. TCOx1 - полную стоимость владения на одного пользователя:
📌 лицензия Copilot Enterprise или self-hosted аналог?
📌 стоимость инференса на H100 в расчёте на запрос,
📌 накладные на аудит, безопасность, поддержку.
2. COGSx1 - стоимость «доставки ценности»:
📌 сколько стоит обработать 1 PR с участием ЦП?
📌 сколько стоит провести ревью сгенерированного кода?
📌 сколько стоит устранить инцидент из-за сгенереного бага?
Без этого ROI — фантазия потому что:
А если TCO растёт нелинейно (а он растёт!), то даже огромный «потенциальный выигрыш» может превратиться в чистый убыток.
⁉️ Почему это критично для метрик?
🤓
Допустим, вы сократили Lead Time на 10%. Отлично!
Но если это стоило:
👉 4×H100 + поддержка + расширенная команда + интеграции в легаси,
👉 и при этом коэффициент проникновения ЦП всего 30%, то ROI отрицателен.
Именно поэтому любая система оценки ROI должна включать TCO как обязательный компонент на равне с другими хардовыми метриками.
✅Что делать? - ввести «TCO-aware» подход
1. Считать TCO на всех уровнях пирамиды метрик - то есть на всех уровнях формирования value chain.
о том что это за пирамида, через один пост ;)
2. Связать TCO с ROI в единой формуле:
3. Не масштабировать до тех пор, пока TCOx1 не стабилизирован.
MVP — это не повод для тиражирования.
Тиражировать можно когда:
📌 есть полноценная поддержка
📌 есть команда развития,
📌 есть прозрачная модель затрат.
Потому что это ДЕНЬГИ! Которые лягут на косты!
🏁Вывод
ROI без TCO - как скорость без тормозов.
Вы можете «разогнаться» до млрд ₽ ROI, но если не знаете, сколько стоит остановиться - рано или поздно врежетесь.
Ты не просто внедряешь ИИ. Ты создаёшь новый цифровой актива и он требует полноценной экономики владения.
Именно поэтому подход к оценке ROI должен учитывать TCO как фундаментальный слой - не «дополнительно», а обязательно.
Потому что реальный бизнес-эффект - это не то, что вы «сэкономили на тайпинге», а то, что осталось в кассе после всех затрат на поддержку, развитие и сопровождение.
💰Сколько стоит ИИ-иллюзии?
Я не могу раскрывать реальные цифры, но постораюсь сделать их наглядными что бы вы могли осмыслить масштаб.
P.S. В следующем посте пример расчета реального ROI под проект связанный с внедрением copilot для разработчиков!
В бизнес-кейсе выше (ты уже понял что речь тдет о copilot’е) никто не посчитал:
1. TCOx1 - полную стоимость владения на одного пользователя:
📌 лицензия Copilot Enterprise или self-hosted аналог?
📌 стоимость инференса на H100 в расчёте на запрос,
📌 накладные на аудит, безопасность, поддержку.
2. COGSx1 - стоимость «доставки ценности»:
📌 сколько стоит обработать 1 PR с участием ЦП?
📌 сколько стоит провести ревью сгенерированного кода?
📌 сколько стоит устранить инцидент из-за сгенереного бага?
Без этого ROI — фантазия потому что:
Эффект = (Ценность − TCO) / TCO
А если TCO растёт нелинейно (а он растёт!), то даже огромный «потенциальный выигрыш» может превратиться в чистый убыток.
⁉️ Почему это критично для метрик?
🤓
Потому что хард-метрики бессмысленны без учёта затрат!
Допустим, вы сократили Lead Time на 10%. Отлично!
Но если это стоило:
👉 4×H100 + поддержка + расширенная команда + интеграции в легаси,
👉 и при этом коэффициент проникновения ЦП всего 30%, то ROI отрицателен.
Именно поэтому любая система оценки ROI должна включать TCO как обязательный компонент на равне с другими хардовыми метриками.
✅Что делать? - ввести «TCO-aware» подход
1. Считать TCO на всех уровнях пирамиды метрик - то есть на всех уровнях формирования value chain.
2. Связать TCO с ROI в единой формуле:
Net Effect = (ΔTTM × Revenue Impact) − TCO
Если Net Effect < 0 — масштабировать нельзя.
3. Не масштабировать до тех пор, пока TCOx1 не стабилизирован.
MVP — это не повод для тиражирования.
Тиражировать можно когда:
📌 есть полноценная поддержка
📌 есть команда развития,
📌 есть прозрачная модель затрат.
Потому что это ДЕНЬГИ! Которые лягут на косты!
🏁Вывод
ROI без TCO - как скорость без тормозов.
Вы можете «разогнаться» до млрд ₽ ROI, но если не знаете, сколько стоит остановиться - рано или поздно врежетесь.
Ты не просто внедряешь ИИ. Ты создаёшь новый цифровой актива и он требует полноценной экономики владения.
Именно поэтому подход к оценке ROI должен учитывать TCO как фундаментальный слой - не «дополнительно», а обязательно.
Потому что реальный бизнес-эффект - это не то, что вы «сэкономили на тайпинге», а то, что осталось в кассе после всех затрат на поддержку, развитие и сопровождение.
💰Сколько стоит ИИ-иллюзии?
Я не могу раскрывать реальные цифры, но постораюсь сделать их наглядными что бы вы могли осмыслить масштаб.
P.S. В следующем посте пример расчета реального ROI под проект связанный с внедрением copilot для разработчиков!
❤2🔥1
Бизнес-эффект как узкое горлышко продукта. Или почему бизнес-эффект от ИИ часто остаётся на бумаге.
Сегодня почти каждая технологическая компания запускает ИИ-ассистенты для разработчиков. И почти все с гордостью заявляют - «Наш Copilot даёт бизнес-эффект в миллиарды рублей за счёт ускорения разработки».
Но краткое время спустя после внедрения та же компания тихо признаёт - «Эффект… пока не проявляется. Но DAU растёт!»
Почему так происходит?
Не потому, что ИИ не работает.
А потому, что мы измеряем не то и не там.
🔢 Как считают ROI — и почему это работает только в Excel
Типичная модель выглядит так:
Звучит логично.
Но на практике эта модель игнорирует три критических проблемы такого подхода.
⚠️ Проблема 1: % ИИ-кода ≠ экономия времени
Метрика «% ИИ-кода в PR» считается как совпадение токенов между тем, что выдал ИИ, и тем, что попало в коммит.
Она не учитывает:
- был ли код отредактирован и сколько времени на это потратили
- вызвал ли баги после мерджа
- не висел ли PR 5 дней из-за перегруженного тимлида.
Более того чем выше доля кода, оставленного без изменений, тем выше риск низкокачественного решения.
Copilot - не архитектор. Он - быстрый, но глупый.
Таким образом, % ИИ-кода — это метрика доверчивости, а не продуктивности.
И использовать её как KPI - значит поощрять пассивное копирование, а не осознанное применение. Такое годится только для «покраски забора».
⚠️ Проблема 2: ROI без TCO — это гипотеза, а не кейс
MVP ИИ-помощника часто оценивают условно в 50 млн ₽:
- 4 сервера с H100,
- плагин в IDE,
- базовая интеграция.
Но при масштабировании на 7 500 человек выясняется, что реальный TCO включает:
📌Поддержку инфраструктуры (SRE, MLOps, мониторинг) за 12 млн ₽/год,
📌Продуктовую команду PO, UX, аналитик) за 21 млн ₽/год,
📌Расширенную MLE/DS-команду за 32 млн ₽/год,
📌Интеграции в легаси-системы (IAM, SIEM, DLP, аудит) за 15+ млн ₽/год.
Итого около 80 млн ₽/год только OpEx. За 2 года ~210 млн ₽ TCO.
А если реальный эффект - не 2 млрд, а 400–600 млн (из-за простоев на ревью, багов, низкого adoption), то чистый результат скромен.
⚠️ Проблема 3: Узкие места не в IDE — а в процессах
Даже если разработчик пишет код на 30% быстрее, это не ускоряет Time-to-Market если:
📌тимлид в одного отвечает за CR.
📌 PR висят по 5 дней из-за его загрузки,
📌 баги из-за «нейрослопа» падают в продуктив
📌 команды переписывают фичи дважды.
Инженерная цепочка — это система, а не сумма индивидуальных скоростей.
И если в ней есть узкое место, то ускорение на одном этапе не даёт общего эффекта.
💡 Что делать? Три принципа, которые работают
1. Измеряйте не активность, а результат. Замените «% ИИ-кода» на «доля чистых PR», «снижение времени ревью»или «Lead Time».
2. Считайте TCO честно. Включайте не только железо, но и команды, поддержку, compliance, инциденты.
3. Связывайте метрики вертикально. Эффект должен «подниматься» от разработчика к команде затем стриму и в конце влиять на всю компанию. Если на уровне команды нет роста качества - ROI на уровне компании невозможен.
🔑 Вывод
ИИ-помощники - это не «фича», а горизонтальное расширение команды.
И как любое расширение, оно требует:
- Ясной экономики,
- Системы измерения,
- Понимания реальных процессов.
Пока мы измеряем «сколько нажали Ctrl+C / Ctrl + V», а не «сколько доставили в прод», бизнес-эффект будет оставаться в Excel-моделях.
Настоящий эффект рождается не в IDE, а в инженерном цикле от кода к PR через ревью и до мержа оседая в проде.
И если вы хотите масштабировать ИИ-помощников без иллюзий пора перейти от метрик использования к метрикам ценности.
P.S. В следующем посте я расскажу о том как мы стали оценивать ИИ-инструменты - через связь инфраструктуры, процессов и бизнес-результат. Это будет длиннопост, следи за публикациями!
Сегодня почти каждая технологическая компания запускает ИИ-ассистенты для разработчиков. И почти все с гордостью заявляют - «Наш Copilot даёт бизнес-эффект в миллиарды рублей за счёт ускорения разработки».
Но краткое время спустя после внедрения та же компания тихо признаёт - «Эффект… пока не проявляется. Но DAU растёт!»
Почему так происходит?
Не потому, что ИИ не работает.
А потому, что мы измеряем не то и не там.
🔢 Как считают ROI — и почему это работает только в Excel
Типичная модель выглядит так:
- У нас 7 500 разработчиков.
- Каждый работает 8 часов в день.
- Средняя ставка - 5 500 ₽/час.
- ИИ генерирует 7% финального кода.
- Значит, 7% времени можно вычесть → экономия = 7 500 × 1 800 ч × 5 500 ₽ × 7% ≈ 5 млрд ₽/год.
- С учётом «реализуемости» — скажем, 2 млрд за 2 года.
Звучит логично.
Но на практике эта модель игнорирует три критических проблемы такого подхода.
⚠️ Проблема 1: % ИИ-кода ≠ экономия времени
Метрика «% ИИ-кода в PR» считается как совпадение токенов между тем, что выдал ИИ, и тем, что попало в коммит.
Она не учитывает:
- был ли код отредактирован и сколько времени на это потратили
- вызвал ли баги после мерджа
- не висел ли PR 5 дней из-за перегруженного тимлида.
Более того чем выше доля кода, оставленного без изменений, тем выше риск низкокачественного решения.
Copilot - не архитектор. Он - быстрый, но глупый.
Таким образом, % ИИ-кода — это метрика доверчивости, а не продуктивности.
И использовать её как KPI - значит поощрять пассивное копирование, а не осознанное применение. Такое годится только для «покраски забора».
⚠️ Проблема 2: ROI без TCO — это гипотеза, а не кейс
MVP ИИ-помощника часто оценивают условно в 50 млн ₽:
- 4 сервера с H100,
- плагин в IDE,
- базовая интеграция.
Но при масштабировании на 7 500 человек выясняется, что реальный TCO включает:
📌Поддержку инфраструктуры (SRE, MLOps, мониторинг) за 12 млн ₽/год,
📌Продуктовую команду PO, UX, аналитик) за 21 млн ₽/год,
📌Расширенную MLE/DS-команду за 32 млн ₽/год,
📌Интеграции в легаси-системы (IAM, SIEM, DLP, аудит) за 15+ млн ₽/год.
Итого около 80 млн ₽/год только OpEx. За 2 года ~210 млн ₽ TCO.
А если реальный эффект - не 2 млрд, а 400–600 млн (из-за простоев на ревью, багов, низкого adoption), то чистый результат скромен.
⚠️ Проблема 3: Узкие места не в IDE — а в процессах
Даже если разработчик пишет код на 30% быстрее, это не ускоряет Time-to-Market если:
📌тимлид в одного отвечает за CR.
📌 PR висят по 5 дней из-за его загрузки,
📌 баги из-за «нейрослопа» падают в продуктив
📌 команды переписывают фичи дважды.
Инженерная цепочка — это система, а не сумма индивидуальных скоростей.
И если в ней есть узкое место, то ускорение на одном этапе не даёт общего эффекта.
💡 Что делать? Три принципа, которые работают
1. Измеряйте не активность, а результат. Замените «% ИИ-кода» на «доля чистых PR», «снижение времени ревью»или «Lead Time».
2. Считайте TCO честно. Включайте не только железо, но и команды, поддержку, compliance, инциденты.
3. Связывайте метрики вертикально. Эффект должен «подниматься» от разработчика к команде затем стриму и в конце влиять на всю компанию. Если на уровне команды нет роста качества - ROI на уровне компании невозможен.
🔑 Вывод
ИИ-помощники - это не «фича», а горизонтальное расширение команды.
И как любое расширение, оно требует:
- Ясной экономики,
- Системы измерения,
- Понимания реальных процессов.
Пока мы измеряем «сколько нажали Ctrl+C / Ctrl + V», а не «сколько доставили в прод», бизнес-эффект будет оставаться в Excel-моделях.
Настоящий эффект рождается не в IDE, а в инженерном цикле от кода к PR через ревью и до мержа оседая в проде.
И если вы хотите масштабировать ИИ-помощников без иллюзий пора перейти от метрик использования к метрикам ценности.
P.S. В следующем посте я расскажу о том как мы стали оценивать ИИ-инструменты - через связь инфраструктуры, процессов и бизнес-результат. Это будет длиннопост, следи за публикациями!
❤1🔥1
ГаллюцинацИИ, брат pinned «4. AI - не всегда решение. Ты должен уметь задавать себе правильный вопрос - “А что, если мы просто добавим флаг в интерфейс и правило в workflow?” Если задачу можно решить бизнес-правилом то делай так. Это дешевле, быстрее, прозрачнее и надёжнее. AI/ML…»
Forwarded from MLTimes
Пекин планирует удвоить ИИ-сектор до 142 млрд долларов
Власти Пекина опубликовали план развития ИИ-индустрии в городе. За два года объем сектора должен вырасти с 450 млрд юаней до 1 трлн юаней. В долларах это 142 млрд. Программа предусматривает запуск кластера с более чем 100 тысячами китайских чипов. Еще одна цель - помочь более 10 ИИ-компаниям провести IPO и поддержать рост более 20 стартапов до статуса единорогов.
План выглядит амбициозно. Но он появился через два месяца после тревожного заявления DeepSeek. Старший исследователь этой ИИ-компании Чэнь Дэли выступил на World Internet Conference в ноябре 2025 года. Он предупредил, что люди будут полностью освобождены от работы. Звучит неплохо, но это потрясет общество до основания, сказал Чэнь.
https://mltimes.ai/pekin-planiruet-udvoit-ii-sektor-do-142-mlrd-dollarov/
Власти Пекина опубликовали план развития ИИ-индустрии в городе. За два года объем сектора должен вырасти с 450 млрд юаней до 1 трлн юаней. В долларах это 142 млрд. Программа предусматривает запуск кластера с более чем 100 тысячами китайских чипов. Еще одна цель - помочь более 10 ИИ-компаниям провести IPO и поддержать рост более 20 стартапов до статуса единорогов.
План выглядит амбициозно. Но он появился через два месяца после тревожного заявления DeepSeek. Старший исследователь этой ИИ-компании Чэнь Дэли выступил на World Internet Conference в ноябре 2025 года. Он предупредил, что люди будут полностью освобождены от работы. Звучит неплохо, но это потрясет общество до основания, сказал Чэнь.
https://mltimes.ai/pekin-planiruet-udvoit-ii-sektor-do-142-mlrd-dollarov/
🔥1
Forwarded from MLTimes
Три топовых ИИ-модели показали одинаковые результаты в новом тесте
Artificial Analysis представила обновленный рейтинг ИИ-систем Intelligence Index 4.0. Результаты показали неожиданную картину - разница между тремя ведущими моделями практически исчезла.
По итогам измерений на первой строчке оказалась GPT-5.2 X-High от OpenAI. Однако её преимущество над Claude Opus 4.5 и Gemini 3 Pro настолько мало, что находится в пределах статистической ошибки. Фактически можно говорить о троевластии на рынке больших языковых моделей.
https://mltimes.ai/tri-topovyh-ii-modeli-pokazali-odinakovye-rezultaty-v-novom-teste/
Artificial Analysis представила обновленный рейтинг ИИ-систем Intelligence Index 4.0. Результаты показали неожиданную картину - разница между тремя ведущими моделями практически исчезла.
По итогам измерений на первой строчке оказалась GPT-5.2 X-High от OpenAI. Однако её преимущество над Claude Opus 4.5 и Gemini 3 Pro настолько мало, что находится в пределах статистической ошибки. Фактически можно говорить о троевластии на рынке больших языковых моделей.
https://mltimes.ai/tri-topovyh-ii-modeli-pokazali-odinakovye-rezultaty-v-novom-teste/
🔥1
Почему ИИ-помощник не будет работать - даже если «все используют».
Когда вы объявляете бизнес-эффект от ИИ в 2 млрд рублей за 2 года, вас слушают с уважением.
Когда вы говорите, что эффект не проявляется, вас просят - «Просто заставьте разработчиков чаще нажимать Ctrl+С\Ctrl+V».
Но проблема не в «нажатиях».
Проблема в том, что мы посчитали ROI до того, как поняли, как он вообще может возникнуть - и забыли про реальную инженерную цепочку.
Этот пост — про то, почему бизнес-эффект от ИИ требует сквозной системы метрик, процессов и ответственности - от одного разработчика до всего банка.
пост основан на практическом подходе к оценке цифровых помощников над которым я работал в enterprise-среде. Он согласован с тремя авторитетными фреймворками - DORA, SPACE, и DX Framework и прямо следует их требованиям.
KPI на индивидуальном уровне - запрещены
В моем подходе на уровне разработчика KPI по использованию ЦП не устанавливаются. Это не мнение - это требование лучших практик.
DORA (2023)
SPACE
DX Framework:
Поэтому в нашем подходе индивидуальный уровень - зона нематериальной мотивации: ачивки, грамоты, мерч.
А KПЭ начинаются только на уровне команды - где ценность становится измеримой и социально ответственной.
Тем более так мы избавляемся от необходимости бегать по всем разработчикам и сосредоточены только на team lead’ах, чьей головной болью становятся KPI в дополнение к сотне других вопросов 🤣
📈Пирамида метрик: от поведения к стратегии
Подход опирается на пирамиду метрик по уровням управления - от разработчика до всей компании.
Каждый уровень - качественный переход, согласованный с фреймворками.
Уровень 1️⃣: Индивидуальный - зона наблюдения
Здесь живут софтовые метрики (Activity в терминах SPACE):
📌 DAU/MAU
📌 частота запросов,
📌 % применённого ИИ-кода (через токенизацию и n-граммы).
Но! Никаких KПЭ. Только нематериальная мотивация.
SPACE:
Уровень 2️⃣: Командный - здесь рождается реальность
На этом уровне расположены ключевые хард-метрики это DORA-совместимые индикаторы:
📌 Доля «чистых» PR - proxy метрика для Change Failure Rate
📌 Среднее время CR - влияет на Lead Time for Changes,
📌 Частота PR при сохранении качества - proxy метрика для Deployment Frequency.
DORA:
Без измерения на этом уровне любая оценка ROI ненаучна.
продолжение поста 👇👇👇
Когда вы объявляете бизнес-эффект от ИИ в 2 млрд рублей за 2 года, вас слушают с уважением.
Когда вы говорите, что эффект не проявляется, вас просят - «Просто заставьте разработчиков чаще нажимать Ctrl+С\Ctrl+V».
Но проблема не в «нажатиях».
Проблема в том, что мы посчитали ROI до того, как поняли, как он вообще может возникнуть - и забыли про реальную инженерную цепочку.
Этот пост — про то, почему бизнес-эффект от ИИ требует сквозной системы метрик, процессов и ответственности - от одного разработчика до всего банка.
пост основан на практическом подходе к оценке цифровых помощников над которым я работал в enterprise-среде. Он согласован с тремя авторитетными фреймворками - DORA, SPACE, и DX Framework и прямо следует их требованиям.
ROI от ИИ — это всегда ROI от процессов, в которые он встроен. Если процессы хрупкие - ИИ их разрушит.
Если зрелые - усилит.
KPI на индивидуальном уровне - запрещены
В моем подходе на уровне разработчика KPI по использованию ЦП не устанавливаются. Это не мнение - это требование лучших практик.
DORA (2023)
«Метрики производительности никогда не должны применяться на индивидуальном уровне. Они предназначены для измерения результатов на уровне команды и производительности системы, а не индивидуальной продуктивности».
State of DevOps Report 2023, p. 42, “Avoiding Anti-Patterns in Measurement”.
SPACE
«Использование метрик активности (например, строк кода, коммитов, использования инструментов) в качестве прокси индивидуальной эффективности ведёт к манипуляциям, выгоранию и снижению коллаборации»
“The SPACE of Developer Productivity”, IEEE Software, Vol. 38, No. 2, p. 75
DX Framework:
«Цифровая трансформация терпит неудачу, когда организации оптимизируют локальную эффективность (например, индивидуальный вывод) в ущерб сквозному потоку ценности»)
“Unlocking success in digital transformations”, McKinsey Quarterly, Oct 2022, Principle #4
Поэтому в нашем подходе индивидуальный уровень - зона нематериальной мотивации: ачивки, грамоты, мерч.
А KПЭ начинаются только на уровне команды - где ценность становится измеримой и социально ответственной.
Тем более так мы избавляемся от необходимости бегать по всем разработчикам и сосредоточены только на team lead’ах, чьей головной болью становятся KPI в дополнение к сотне других вопросов 🤣
📈Пирамида метрик: от поведения к стратегии
Подход опирается на пирамиду метрик по уровням управления - от разработчика до всей компании.
Каждый уровень - качественный переход, согласованный с фреймворками.
Уровень 1️⃣: Индивидуальный - зона наблюдения
Здесь живут софтовые метрики (Activity в терминах SPACE):
📌 DAU/MAU
📌 частота запросов,
📌 % применённого ИИ-кода (через токенизацию и n-граммы).
Но! Никаких KПЭ. Только нематериальная мотивация.
SPACE:
«Активность - лишь одно измерение продуктивности. Её необходимо интерпретировать вместе с удовлетворённостью, результативностью, коммуникацией и эффективностью - никогда изолированно»)
IEEE Software, p. 72
Уровень 2️⃣: Командный - здесь рождается реальность
На этом уровне расположены ключевые хард-метрики это DORA-совместимые индикаторы:
📌 Доля «чистых» PR - proxy метрика для Change Failure Rate
📌 Среднее время CR - влияет на Lead Time for Changes,
📌 Частота PR при сохранении качества - proxy метрика для Deployment Frequency.
DORA:
«Четыре ключевые метрики - частота деплоев, время доставки изменений, частота сбоев и время восстановления являются валидированными предикторами производительности доставки ПО и организационных результатов»
State of DevOps Report 2023, p. 18
Без измерения на этом уровне любая оценка ROI ненаучна.
продолжение поста 👇👇👇
Уровень 3️⃣: Стримовый - здесь должен проявиться эффект
Главный вопрос - Ускорили ли мы Time-to-Market?
Метрики этого уровня являются агрегатами предыдущего:
📌 Lead Time (DORA),
📌 Снижение дефектов в ПреПроме
📌 Коэффициент вовлечённости (≥85% команд с «чистыми» PR).
DX Framework:
“Measuring Digital Value”, BCG Tech Brief, Q1 2023
Уровни 4️⃣ - 5️⃣: Дивизион и Банк
Только если:
🏆 TTM сократился,
🏆 качество выросло,
🏆 инциденты снизились
Тогда можно говорить о реальном ROI!
Иначе - это гипотетическа цифра нарушающая принцип:
DX Framework:
🌸«Взаимное опыление метрик»: требование SPACE и DORA
Концепция «взаимного опыления метрик»- центральный элемент подхода. Она означает что метрики должны коррелировать между уровнями.
SPACE:
DORA:
Это означает, что если % ИИ-кода растёт, но Lead Time не меняется - ЦП работает вхолостую.
Именно поэтому % ИИ-кода как KПЭ опасен. Он поощряет пассивное копирование, а не создание ценности.
Три принципа сквозной оценки.
Принцип 1. Не используйте активность как основной фактор
✅ Не мотивируйте за активность - мотивируйте за результат
Метрика «Сокращение времени на задачу при сохранении качества - соответствует DORA Principle #3 -«Измеряйте результаты, а не объёмы».
Принцип 2. Встраивайте хард-метрики в КПЭ но только на уровне команды и выше
✅ Соответствует SPACE Guideline #5 - «Используйте метрики на уровне команды для подотчётности».
3. Оценивайте TCO честно
✅ Соответствует DX Framework - «Включайте скрытые издержки инструментов: безопасность, поддержка, когнитивная нагрузка».
🏁Финал. Бизнес-эффект - это не цифра, а система.
Мы сформулировали эффект как линейную экстраполяцию ускорения, а не как нелинейную систему взаимодействий, описанную в DORA, SPACE и DX.
Но вовремя поняли что налажали и пересобрали
всю методику оценки!
Осталось одно перестать считать «% ИИ-кода» KПЭ
и начать измерять то, что действительно влияет на TTM и качество.
Потому что бизнес-эффект от ИИ не в том, сколько напечатали,
а в том, сколько доставили, насколько стабильно - и насколько раньше конкурентов.
ИИ - не волшебная таблетка. Это зеркало ваших процессов.
Если в зеркале хаос, никакой Copilot не спасёт.
P.S. Следующим постом я приложу методику расчета этих метрик на каждом уровне и расскажу подробно про их взаимосвязь
Главный вопрос - Ускорили ли мы Time-to-Market?
Метрики этого уровня являются агрегатами предыдущего:
📌 Lead Time (DORA),
📌 Снижение дефектов в ПреПроме
📌 Коэффициент вовлечённости (≥85% команд с «чистыми» PR).
DX Framework:
«Реализация ценности в цифровой трансформации требует прослеживаемости от результатов на уровне команды до бизнес-воздействия. Если TTM не улучшается, никакое внедрение инструментов не является успехом»)
“Measuring Digital Value”, BCG Tech Brief, Q1 2023
Уровни 4️⃣ - 5️⃣: Дивизион и Банк
Только если:
🏆 TTM сократился,
🏆 качество выросло,
🏆 инциденты снизились
Тогда можно говорить о реальном ROI!
Иначе - это гипотетическа цифра нарушающая принцип:
DX Framework:
«Измерение на основе результатов всегда превосходит прогнозирование на основе активности. Цифровая ценность реализуется в продакшене, а не на пилотных дашбордах»
🌸«Взаимное опыление метрик»: требование SPACE и DORA
Концепция «взаимного опыления метрик»- центральный элемент подхода. Она означает что метрики должны коррелировать между уровнями.
SPACE:
«Эффективные системы измерения демонстрируют согласованность между измерениями: например,
рост использования инструмента (Активность) должен коррелировать с ускорением доставки (Результативность)
и более высокой удовлетворённостью».
DORA:
«Команды, которые одновременно улучшают все четыре ключевые метрики, достигают наибольшего уровня успеха. Изолированные улучшения часто иллюзорны».
Это означает, что если % ИИ-кода растёт, но Lead Time не меняется - ЦП работает вхолостую.
Именно поэтому % ИИ-кода как KПЭ опасен. Он поощряет пассивное копирование, а не создание ценности.
Три принципа сквозной оценки.
Принцип 1. Не используйте активность как основной фактор
✅ Не мотивируйте за активность - мотивируйте за результат
Метрика «Сокращение времени на задачу при сохранении качества - соответствует DORA Principle #3 -«Измеряйте результаты, а не объёмы».
Принцип 2. Встраивайте хард-метрики в КПЭ но только на уровне команды и выше
✅ Соответствует SPACE Guideline #5 - «Используйте метрики на уровне команды для подотчётности».
3. Оценивайте TCO честно
✅ Соответствует DX Framework - «Включайте скрытые издержки инструментов: безопасность, поддержка, когнитивная нагрузка».
🏁Финал. Бизнес-эффект - это не цифра, а система.
Мы сформулировали эффект как линейную экстраполяцию ускорения, а не как нелинейную систему взаимодействий, описанную в DORA, SPACE и DX.
Но вовремя поняли что налажали и пересобрали
всю методику оценки!
Осталось одно перестать считать «% ИИ-кода» KПЭ
и начать измерять то, что действительно влияет на TTM и качество.
Потому что бизнес-эффект от ИИ не в том, сколько напечатали,
а в том, сколько доставили, насколько стабильно - и насколько раньше конкурентов.
ИИ - не волшебная таблетка. Это зеркало ваших процессов.
Если в зеркале хаос, никакой Copilot не спасёт.
P.S. Следующим постом я приложу методику расчета этих метрик на каждом уровне и расскажу подробно про их взаимосвязь