Авито открыл набор на магистерские программы по ML и продакт-менеджменту, разработанные совместно с МФТИ и НИУ ВШЭ

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

Магистратура «Управление продуктом в IT-бизнесе» в ВШБ НИУ ВШЭ опирается на матрицу компетенций продакт-менеджера в Авито и охватывает всё управление продуктами: от аналитики и пользовательских исследований до бизнес-моделей и работы с данными.

В рамках «Прикладное машинное обучение и анализ данных» и «Машинное обучение (ML) в цифровом продукте» будут осваивать навыки, начиная от классического ML и компьютерного зрения до рекомендательных систем и генеративного ИИ.

👉 Больше информации о магистратуре

Сейчас у Авито запущено всего 12 программ высшего образования, включая магистратуры, для студентов и выпускников со всей страны.

По мере того как роли в сферах разработки продуктов, дизайна, Data Science и других сливаются воедино благодаря ИИ, я размышлял о том, как они могут выглядеть в будущем (Boris Cherny, Claude Code)

Например, глядя на команду Claude Code, я выделяю пять архетипов:

1. Прототипировщик (Prototyper): генерирует совершенно новые идеи; выдает множество идей, большинство из которых не доходят до стадии реализации.

2. Создатель (Builder) быстро превращает прототип или идею в готовый к эксплуатации продукт или инфраструктуру.

3. Упорядочиватель (Sweeper): приводит в порядок интерфейс, упрощает код и систему, удаляет лишнее, оптимизирует производительность.

4. Развиватель (Grower): берёт уже созданный продукт и дорабатывает его для улучшения соответствия продукта рынку (Product-Market Fit).

5. Поддержка (Maintainer): отвечает за зрелую систему, обеспечивая её безопасность, надёжность, быстродействие и эффективность по мере масштабирования.

Многие специалисты совмещают две, а иногда и три роли. Я также заметил, что эти роли не жестко привязаны к должностным обязанностям.

Например, в Anthropic есть дизайнеры, соответствующие категориям 1, 2 или 3; то же самое касается инженеров, продакт-менеджеров и специалистов по данным.

Здоровой команде требуется сочетание этих ролей в зависимости от продукта:

- Для нового продукта, ещё не нашедшего соответствие рынку (pre-PMF), нужны люди с сильными навыками типов 1, 2 и 3.

- Для растущего продукта, нашедшего соответствие рынку, нужны типы 2, 3, 4 и отчасти 5.

- Для продукта с сильным соответствием рынку нужны типы 3, 4, 5 и отчасти 2.

Возможно, именно так будут выглядеть продуктовые роли будущего, а не как нынешние узкоспециализированные должности.

– 3 основных типа лидеров продукта
– Новая структура любого отдела в компании
– Командные роли по Белбину

Трамп отменил ограничения на Fable и она снова доступна 🔥 По такому случаю поделюсь опытом, который был отложен как раз до этого дня:

TLDR: Fable – самая умная и быстрая ИИ, что я видел за всё время

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

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

В общем... за 5 минут Fable нашла в нём порядка 6 критических уязвимостей, дающих полный доступ ко всем проектам и данным внутри системы и ещё около десятка мелких, расписав по шагам как их активировать и использовать.

Прикинув, сколько лет заключения начинало бы светиться на кончиках моих пальцев, начни я проверять это всё на практике, я быстренько закрыл сессию от греха подальше и удалил её на всякий случай 🙂

Окей, к продуктам:

1. Отдавай Fable только «последнюю милю» рассуждения, а не весь процесс, ибо прогонять весь объём работы через самую сильную модель дорого и нецелесообразно.

Используй связку Sonnet → Fable → Sonnet как цикл
ИЛИ
Fable → Sonnet → Fable

Sonnet расширяет (собирает варианты, черновики, сырой список идей), Fable сужает (выбирает и обосновывает лучший вариант с учётом trade-off'ов), Sonnet снова расширяет (превращает решение в конкретные тикеты, сообщения, план действий). Или наоборот.

Прибереги Fable для decision log, а не для повседневных апдейтов

Смысл Fable в том, чтобы она добавляла именно тот последний процент, который остальные ИИ упускают. Так Fable работает ровно на той стадии, где нужно суждение, а не генерация объёма.

2. Используй Fable как самого-главного-менеджера, а не как ревьюера, попросив сыграть роль самого скептичного CPO/CEO, (который ставит под сомнение и режет фичи) и разнести кейс по существу.

Обычное ревью ищет опечатки в логике, в то время как ролевая атака Fable ищет дыры в самой стратегии логики, и именно в этом разница в интеллекте Fable ощущается сильнее всего.

3. Для этого прогоняй одну и ту же стратегическую задачу через Fable трижды в разных фреймингах

Первый раз оптимизируй под использование, второй раз под масштабирование, третий раз под риски. Четвертый раз в этой же сессии попроси сделать финальный анализ.

В Fable разница между всеми тремя ответами будет более содержательной, а финальное расхождение между прогонами – это и есть то, над чем должен работать человек.

4. Не давай Fable контекст, который ты сам не перечитал

Чем сильнее модель (а Fable сейчас сильнее всех), тем правдоподобнее она достроит недостающий контекст сама и тем незаметнее будет ошибка, если ей подсунули устаревшую метрику или неверное допущение.

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

5. Держи Fable отдельно от документа, который писала НЕ она!

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

6. Проси Fable явно проговорить, при каком условии она неправа. Не просто "дай рекомендацию", а "дай рекомендацию и укажи, какой факт, если он окажется неверным, полностью всё сломает".

7. Прогоняй через Fable процессы, а не документы

Раз в квартал давайте модели не PRD, а свой шаблон PRD или свой процесс приоритизации целиком и спрашивайте, какой систематический слепой участок в них вами упущен.

Это применение той же логики внешнего цикла, но на уровне не одной сессии, а всей вашей продуктовой методологии и именно в таком контексте сильнее всего окупается разница между Sonnet/Opus и Fable.

– He was a friend to me and went everywhere with me. But honestly, he’s still with me right There ))

ClaudeMD автоматического выбора ИИ-модели для продуктовой работы

Рейтинги – это стартовая калибровка, а не фиксированные данные и чем выше число, тем лучше.

Модель / Стоимость / Интеллект / Вкус
sonnet-5 / 8 / 6 / 6 /
opus-4. / 8 / 5 / 8 / 7 /
fable-5 / 3 / 9 / 8 /

– Стоимость. То, что ощущается в лимитах токенов и скорости.
– Интеллект. Насколько сложную, многошаговую или неоднозначную задачу можно доверить модели без присмотра.
– Вкус. Качество структуры документа, формулировок, тона в коммуникации и чуткость к контексту.

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

Как применять:

– Это дефолты, а не ограничения. Если результат дешёвой модели не дотягивает, то не спрашивай разрешения, перезапускай с более сильной. Суди по результату, а не по тому, что модель просто должна была справиться.

Пересогласование стоит дешевле, чем решение, принятое на слабом анализе

– Когда параметры конфликтуют для чего-то, что реально влияет на решения или уходит наружу, опирайся на:

1. Интеллект > 2. Вкус > 3. Стоимость

– Массовая механическая работа (расшифровка транскриптов интервью, разметка тикетов, сведение таблиц с метриками, черновой синтез фидбека из десятков источников): sonnet-5.

– Всё, что уходит наружу стейкхолдерам, клиентам, руководству (питчи, обоснование приоритизации, деликатные апдейты о задержках, переговоры о scope): нужен вкус ≥ 7.

– Ревью и вторая пара глаз (проверка PRD перед отправкой инженерам, стресс-тест roadmap, поиск дыр в бизнес-кейсе): fable-5 или opus-4.8, по возможности оба как независимые мнения, если решение необратимое.

– Стратегические и неоднозначные решения (trade-off между конкурирующими метриками, приоритизация, спорные ставки без явного правильного ответа): fable-5.

– Никогда не используй самую слабую модель для документов, которые пойдут выше вашего уровня или станут прецедентом для команды.

Режимы работы

– Написание PRD и спек с нуля → opus-4.8 как основа → fable-5 для финального ревью перед отправкой в разработку.

– Discovery-синтез sonnet-5 для чистой расшифровки на входе (несколько интервью → инсайты → гипотезы) → fable-5 для самого синтеза (нужен интеллект, чтобы не сгладить противоречия)

– Приоритизация бэклога / RICE-скоринг → sonnet-5 для механического прогона по формуле → opus-4.8 для проверки, не искажает ли формула реальный контекст → fable-5 для синтеза

– Коммуникация о задержках и плохих новостях стейкхолдерам → fable-5 или opus-4.8. Тон и причины здесь важнее скорости.

– Рутинные апдейты статуса, саммари встречи, заметки в трекер → sonnet-5.

– Pre-mortem, поиск слабых мест в плане запуска → opus-4.8 → fable-5 как отдельная независимая проверка.

– Черновик поста / статьи / контента на основе рабочих заметок → opus-4.8 для черновика → fable-5 для финальной правки тона и структуры.

– Анализ больших выгрузок данных / метрик → sonnet-5 для первого прохода и агрегации → эскалация на opus-4.8, если нужна интерпретация неоднозначных паттернов → fable-5 для финальной проверки паттернов.

Почему ИИ на самом деле не научился «видеть» так, как видим мы

Профессор Стэнфорда Джуди Фан выступила на сцене MIT и объяснила, почему люди так хорошо умеют делать невидимое видимым.

1. Природа никогда не давала нам прямых линий или острых углов. Числовая прямая, координатная плоскость, основы геометрии — всё это изобретения человека.

Мы создали инструменты, которых не существует в природе, просто потому, что нам нужен был способ мыслить яснее.

2. Система координат, изобретенная Декартом, решила проблему, которая веками ставила математиков в тупик — удвоение объёма куба. После изобретения этот инструмент стал настолько незаменимым, что практически каждая математическая программа на Земле до сих пор зависит от него.

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

Исследовательская группа Фан изучает нечто обманчиво простое: как люди решают, что включить в рисунок, а что опустить

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

6. Люди не просто копируют то, что видят. Они постоянно принимают решения о том, какой уровень детализации действительно служит цели коммуникации, и делают это естественно, никогда не обучаясь теории, лежащей в основе этого.

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

В одном исследовании участники рисовали пояснительные диаграммы, которые подчеркивали движущиеся, причинно-следственные части машины, в то время как изобразительные рисунки акцентировали внимание на фоне и общем внешнем виде, хотя оба варианта изображали один и тот же объект.

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

Нельзя оптимизировать один рисунок для достижения обеих целей одновременно. Визуальная коммуникация всегда предполагает компромиссы

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

11. Когда исследователи сравнивали эскизы, созданные людьми, с эскизами, сгенерированными ИИ, при ограниченном количестве штрихов, оба варианта были одинаково узнаваемы при большем количестве штрихов, но резко расходились по мере сокращения лимита штрихов.

Люди и системы ИИ упрощают рисунки принципиально разными способами, когда ресурсы становятся дефицитными.

12. Чтение графика — навык, который включает в себя восприятие, знание, куда смотреть, сопоставление этой визуальной информации с фактическим задаваемым вопросом, а затем преобразование этого сопоставления в ответ.

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

13. Люди выбирают совершенно разные типы диаграмм в зависимости от того, на какой конкретный вопрос они пытаются ответить, а не из-за общего предпочтения столбчатых диаграмм или диаграмм рассеивания.

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

Займи слот ИТ-Пикником от Т-Банка

8 августа — время отложить ноутбуки и встретиться офлайн на ИТ-Пикнике от Т-Банка в музее-заповеднике «Коломенское».

Вот сколько всего запланировано:

— научпоп-лекции;
— мастер-классы;
— дискуссии об ИИ и больших языковых моделях;
— доклады о кибербезопасности;
— примеры, как данные из логов становятся решениями;
— много музыки.

Бери с собой друзей, супругов и детей — каждый найдёт себе что-то по душе.

Зарегистрироваться и узнать больше можно здесь