Привет!

Это канал про продуктовый менеджмент решений на основе AI / ML от лица бывшего Data Scientist.

Обо мне:

• AI/ML Technical Product Manager в Wildberries
• 6 лет в DS / ML
• 30+ DS в командах
• 20+ моделей и сервисов в проде
• Опыт: промышленность, финтех, e-commerce

Пишу про:

• ML-продукты
• Продакшн, процессы, грабли
• Взаимодействие DS / MLE / MLOps / PM
• Иногда — мысли вслух

Начнем с актуального.

https://career.rwb.ru/vacancies/22082

🚀 Ищу AI/ML Technical Product Manager (Wildberries)

🧩 Продукты
• эмбеддинги текста, картинок и видео, сегментаторы, детекторы, OCR
• зоопарк LLM / VLM (с квантизаций и дообучением)
• text2image, image2video
• векторный поиск, RAG-и, кодовые ассистенты, модели для переводов и многое другое

👥 Заказчики
• Поиск, Контент, Рекомендации, Финтех, Реклама и др

🎯 Основная цель - реализация ML-сервисов, вывод в прод и последующая интеграция в пайплайны заказчиков для повышения эффективности даунстрим приложений.

🛠 Ключевые задачи
• сбор требований и согласование критериев приемки
• курирование процесса обучения и упаковки моделей в сервисы (DS/MLE 30+ человек)
• анализ офлайн и асессорских оценкок, защита перед заказчиками и подготовка к АБ
• постановка и приемка задач по продакшанализации моделей (MLOps)
• сопровождение интеграции, мониторинг метрик после запуска в проде и оперативная координация смежных команд для обеспечения стабильной работы сервиса
• оценка экономического эффекта от реализованных решений
• проведение консультаций и пресейла внутренним пользователям
• повышение SLA (стабилизация инференса, инцидент менеджмент)

🙂 Заинтересовало и есть опыт вывода ML-продуктов в прод?

📌 присылайте CV
📌 опишите 2–3 ключевых ML-продукта/сервиса, с которыми работали и вашу роль

🚀 Как ML Product может поднять ключевую метрику в кредитном скоринге?

Я начал свою работу в роли ML PM-а в компании OneFactor. В начале 22 года это был один из крупнейших поставщиков оценок кредитного риска на телеком данных в РФ.

Моим первым KPI было увеличение качества базовых скоринговых моделей на +1 п.п. GINI.

📊 GINI - это преобразованный ROC AUC, одна из ключевых метрик задачи классификации в Data Science. Она позволяет сказать насколько хорошо модель отделяет плохих заемщиков от хороших.

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

Реальность, конечно же, соответствовала второму варианту.🙂

• за последние 2 года общий прирост составил +1 п.п. (плато)
• утилизация базового источника телеком данных была на максимуме
• стратегически компания пошла в сторону создания новых продуктов, которые предполагали получения инкремента в GINI за счет добавления сторонних источников (данные кредитных бюро и др)

Формально эту задачу можно решать по двум направлениям

1️⃣Работа с данными
а) увеличение объема данных
• вертикальное расширение - больше объектов в выборке (data merging)
• горизонтальное расширение - больше признаков за счет доп источников (data fusion)
б) построение новых признаков над существующими данными (feature engineering)

2️⃣Работа с моделями
• переход на другие архитектуры
• оптимизация обучения

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

В треке данных уже велась работа по добавлению новых источников (другие PM-ы). Рост по объему был также затруднен, так как компания была лидером рынка и работала почти со всеми банками в РФ. Брать новые данные было почти неоткуда.

Оставался один путь - генерация новых фичей

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

Тогда я решил попробовать перенести свой опыт из другого домена. До финтеха я занимался построением цифровых двойников производств и много работал с временными рядами в роли DS. Одними из самых сильных фичей в моих задачах были - тренды и лаги. Я решил протестировать эти техники для новой задачи. И это сработало!🔥

📈Мы получили +3 п.п. GINI. Рост в качестве моделей открыл возможности апсейла и помог удерживать существующих клиентов в условиях гонки метрик между вендорами.

💡Как итог

• ML Product Manager в первую очередь работает с ML-метриками
• для управления этими метриками критически важен бэкграунд в Data Science
• опыт из других доменов может стать источником роста там, где классические подходы уже исчерпаны

🏭 ML в промышлененности

Если вам близки промышленность, автоматизация и ML - можно попробовать себя в IIoT (промышленный интернет вещей)

В индустрии сейчас хайп вокруг цифровых двойников производств / цифровых советчиков.

Их строят в два этапа:

A) Предиктивные модели для ключевых технологических параметров, влияющих на:

- качество производимого продукта
- характер и скорость износа оборудования

На выходе - набор виртуальных датчиков (ML-моделей).

На основе этих предсказаний операторы корректирую производственные процессы.

Б) Оптимизационные движки, в которых предсказываемые с ML параметры являются граничными условиями

Кейс из опыта

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

Сначала вы строите ML модель для предсказания тонкости помола на некоторый горизонт вперед. (виртуальный датчик)

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

Здесь к знанию классического ML добавляется необходимость умения решать задачи нелинейной оптимизации.

Вроде бы все понятно и очень интересно, но в промышленности

1.ОЧЕНЬ грязные данные
- датчики врут (деградируют, загрязняются)
- лабораторные измерения плавают и собираются редко

2.Сложные/специфичные процессы
(по сравнению с FinTech / e-coomerce / telecom)
- сильные нелинейности
- каскады обратных связей
- физика процесса важнее моделей

3.Длинные циклы внедрения
- в b2b SaaS можно запустить продукт/фичу за 6 месяцев
- в IIoT - минимум год, чаще 1.5-2

4.Высокий скепсис у конечных пользователей системы

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

5. Узкий рынок

- вакансий существенно меньше, чем в «классических» ML-доменах

Как итог

Будучи DS / MLE в IIoT скорее всего

-> 80-90% времени вы будете чистить данные
-> вам потребуется навык решения оптимизационных задач
-> вам придется заниматься техническим и технологическим аудитом (процессов и IT систем на произвеодстве)

При этом:

а) если вы работаете на предприятии - у вас 1 домен
б) если вы работаете в интеграторе/консалтинге - много доменов, постоянное переключение

Например (мой список за 2 года)

- производство цемента
- сепарация газа
- обогащение руды
- электролиз глинозема (производство аллюминия)

Но

- Уровень реального импакта от продукта часто оказывается существенно выше, чем в финтехе, телекоме или e-commerce - просто из-за низкой стартовой базы.
- средний уровень компенсации нередко выше,
но это, как всегда, зависит от компании и контекста 🙂)

P.s.
Если до конала дойдет кто-нибудь из индустрии, буду рад узнать о ваших кейсах с применением ML (успешных и неуспешных).

Фундамент для ML продуктов. Эмбеддинги.

Если ты хочешь работать с ML-продуктами, эмбеддинги — это база.

Эмбеддинг — это способ представить текст, картинку, товар или пользователя в виде вектора.

Ключевое свойство — сохранение семантики (смысловой нагрузки) исходных объектов.

Их используют:

1️⃣ Для поиска и сравнения похожих объектов

• похожих картинок, текстов, видео
• похожих картинкок по тексту и наоборот
• похожих пользователей

2️⃣ Как входные данные/фичи для моделей второго/третьего уровня

Пример типового пайплайна:

Модель 1 (эмбеддер):
вход: картинка, текст на карточке товара (КТ) -> эмбеддинг

Модель 2 (классификатор):
вход: эмбеддинг -> атрибуты/характеристики КТ

Модель 3 (реранкер):
вход: атрибуты + эмбеддинги + другие фичи -> топ КТ для показа пользователю

Если зайти на сайт любого современного маркетплейса, то там везде будут эмбеддинги.

• для всех товаров, которые ты видишь посчитаны эмбеддинги
• для тебя как пользователя расчитан эмбеддинг

И если ты хочешь улучшать метрики Поиска, Рекомендаций, Модерации контента и Рекламы, то важно понимать:

• какие аспекты эмбеддингов можно улучшать
• как это влияет на качество даунстрим-задач

Об этом дальше.

⚠️ Отличия Product Manager от ML Product Manager. Важные детали при найме

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

Решения на основе машинного обучения устроены принципиально иначе.

1️⃣Недетерминированность

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

2️⃣Конечный жизненный цикл модели

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

Модель подвержена неизбежной деградации по двум основным причинам. Со временем происходят:

• изменение распределения входных данных (data shift)
• изменение предсказываемой переменной (concept shift)

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

Все это приводит к тому, что требования к продакту в домене DS отличаются от требований для классического PM.

Если вы нанимаете ML Product Manager

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

Как минимум кандидат должен уметь отвечать в общем виде на вопросы:

1️⃣Как получить ML-модель?

• cобрать данные
• провести предобработку
• обучить модель
• оценить метрики качества

2️⃣Как упаковать ML-модель в готовый к передаче заказчику сервис?

• продакшанализировать модель и пайплайн данных
• настроить API для работы с модель
• провести нагрузочные тесты
• настроить мониторинги, логирование, алертинги

Без этого понимания эффективно управлять продуктом и искать дополнительные точки роста будет довольно затруднительно.

P.s. на картинке схема методологии CRISP DM с описанием основных этапов жизненного цикла классической ML-модели.

⚠️ Ограничения LLM / VLM, о которых важно знать при интеграции в продукт. Проблема близких логитов и недетерминированность.

LLM работает с токенами. На каждом шаге генерации ответа модель выдает вектор логитов.

• Размер вектора - размер словаря токенизатора
• Логиты - ненормализованные числа. Чем выше значение, тем более предпочтителен токен.

Выбор токена определяется параметрами запроса. В первую очередь - температурой.

• t = 1 -> максимальное разнообразие выхода

Логиты переводят в вероятности через softmax. Отбор токенов по top k / top p из словаря. Далее сэмплирование финального токена на основе вероятностей.

• 0 < t < 1 -> умеренное разнообразие выхода

Логиты делят на t. -> разница между ними увеличивается. Далее softmax, top k / p сэмплирование. Выход становится более предсказуемым.

• t = 0 -> почти детерминированность

Специальный режим - greedy decoding. Выбор токена с самым большим логитом по argmax.

Но в реальной жизни если вы 100 раз подадите на вход модели один и тот же промт с t=0, вы можете получить отличающиеся ответы.(неидемпотентность)

Почему t=0 не гарантирует стабильность?

Источников потенциальной нестабильности ответов LLM много. Это железо (GPU), куда кернелы, режимы работы (динамический батчинг). Многими из них можно управлять.

Однако даже при максимально контролируемой конфигурации остается фундаментальный источник нестабильности:

🎯близкие (near-tie) логиты + неточность вычислений с fp

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

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

В результате

• выбирается другой токен
• меняется цепочка генерации
• меняется итоговый ответ

Почему это важно?

Например, в финтехе для кредитного скоринга воспроизводимость - обязательное требование. Расхождения между offline / batch / online скором считаются критическим багом, а отсутствие 100% повторяемости делает внедрение решений в пайплайны заказчика невозможным.

ML Product Manager: самая кросс-функциональная роль в команде?
(как центральный полузащитник в футболе 🙂)

Мой опыт показывает, что ML Product Manager - одна из самых коммуникационно нагруженных ролей в компании.

В этой позиции вы постоянно на стыке команд:

1. ML/DS часть

• DS — обучение моделей
• MLE — упаковка моделей в сервисы
• MLOps — деплой моделей и сервисов в проде и подготовка ML инфры
• DE — построение пайплайнов данных
• Другие тех команды — общая инфра, мониторинг, поддержка

2. Бизнес контур

• Заказчики — требования, ожидания, пресейл, интеграция, обратная связь, инциденты
• C-level (CPO / CEO / CEO - 1/2) — результаты, родмап, риски и ограничения ML
• Sales — презентация и позиционирование тех сложного продукта
• Legal — техчасть КП и договоров
• PR/Marketing — внешняя коммуникация

Со всеми участниками процесса продакту приходится

1. Обсуждать ML в том или ином виде

• с ML/DS командами с глубоким уровнем погружения
• с Бизнесом - несколько упрощая, на высоком уровне абстрацкий / блэк боксов

2. Договариваться !!!

Где-то процессы выстроены и прозрачны, где-то формальны, а где-то отсутствуют. Именно поэтому ML PM должен уметь эффективно управлять процессом построения продукта сквозь всю цепочку взаимодействий зачастую в нечеткой и постоянно меняющейся разнородной среде.

Если коммуникация ломается или становится неэффективной, под риском оказывается весь продукт. А вместе с ним - сроки, деньги и конечный результат команды.

P.s.

В некоторых компаниях роли DS и MLE объединены, так же как DE и MLOps, в других - разнесены. Это зависит от типа ML-задач, архитектуры решений и зрелости процессов в компании.

Заказчики при этом могут быть как внутренними, так и внешними. Отличия также могут определяться моделью бизнеса (B2C, B2B или B2B2C).

Продуктовые фреймворки, видение CEO или удача?
Как чаще всего строятся успешные продукты

За время работы я запускал продукты на основе ML в очень разных конфигурациях:

• стартап на ранней стадии рынка
• запуск MVP и развитие продуктового портфеля на зрелом рынке
• масштабирование и локализация продуктов на новом рынке
• работа в R&D-контуре крупной компании

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

Бизнес-домен

В промышленности без понимания доступных данных и их качества - считать экономику в экселе или строить Lean Canvas лишено смысла. Быстрое прототипирование за 2 недели и высокая скорость тестирования гипотез - это утопия. Знание фреймворков навряд ли существенно снизит неопределенность и риски.

Функциональная специфика

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

Элемент случайности

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

Местная специфика

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

Опора на фреймворки

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

CEO-центричный подход

Иногда роль и авторитет CEO могут доминировать в принятии решений о дизайне пайплайнов и стратегии вывода продукта на рынок.

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

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

Итог

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

В организациях с CEO-драйвером поток гипотез и инициатив может формироваться и спускаться сверху.

А иногда решающим фактором становится просто удачное стечение обстоятельств.

ML в футболе

Некоторое время назад активно был погружен в этот домен в качестве хобби. Пару раз даже общался с клубами РПЛ и другими участниками рынка относительно возможности сотрудничества.

Это направление активно развивается в Европе и США. Должность Data Scientist-а в клубе становится нормой.

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

• тут вводные об аналитике данных
• тут про цепи Маркова и производные метрики
• тут про метрики на основе ML
• тут заброшенный репозиторий

💰 От матрицы ошибок к деньгам: как ML-продакту оценить экономический эффект B2B SaaS в финтехе

Когда вы выводите ML-продукт на B2B рынок, вы почти всегда проходите одну и ту же цепочку:

• построение модели (данные: свои, заказчика, сторонние)
• оценка метрик качества на выборке заказчика
• оценка экономического эффекта
• построение модели ценообразования / стратегии монетизации

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

🎯 Одна из ключевых задач ML Product Manager - уметь переводить ML метрики моделей в измеримый бизнес эффект.

Это не всегда тривиальная задача. Универсального фреймворка не существует. Однако есть широкий класс задач, в которых связывать модельные метрики с экономическим эффектом удобно через матрицу ошибок (confusion matrix).

Речь идет о решениях на базе классификационных моделей, встраиваемых в decision pipelines - пайплайны автоматизированного принятия решений. Это кредитные конвейеры, BRMS, проверки KYC, KYB, AML и др.

📌 Ниже будет кейс из практики

В компании OneFactor я занимался выводом на рынок сервиса противодействия социальной инженерии.

Это SaaS для оценки вероятности того, что заявка на кредит подана под воздействием мошенников. Пользователи сервиса - банки.

После реализации прототипа мы посчитали метрики Precision / Recall на выборке банка.

Дальше встал ключевой вопрос: достаточно ли этого качества, чтобы модель приносила пользу бизнесу?

Я подошел к оценке экономического эффекта следующим образом:

1️⃣ Построил матрицу ошибок
• TP - корректно найденные кейсы
• FP - ложные срабатывания (упущенная прибыль / доп. проверки)
• FN - пропущенные кейсы (прямые потери банка)

2️⃣ Взял классическую формулу для оценки чистого дохода от кредитного портфеля

NPV = Margin × Sum × (1 − DR) × n − LGD × Sum × DR × n

3️⃣ Адаптировал ее под свой кейс

🔴 посчитал потери банка без модели - все факты соц инженерии: TP + FN
🟢 посчитал потери банка с моделью
-> из-за FN (прямые потери)
-> из-за FP (упущенная прибыль)

4️⃣ Получил итоговую формулу (в общем виде)

Эффект = 🔴 потери без модели − 🟢 потери с моделью

📈 Результат

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

Далее, взяв некоторую долю от рассчитанного эффекта, я подготовил тарификатор сервиса, который команда сейлзов использовала для выставления КП и заключения договоров.

Подтверждённый (в экселе) экономический эффект позволил нам:

• увереннее и интенсивнее вести пресейл
• получить первые контракты (и провалидировать жизнеспособность модели ценообразования)

✅ Выводы

• ML-продакт должен уметь переводить ML-метрики в деньги
• матрица ошибок - мощный инструмент для решения данной задачи
• понимание экономического эффекта в B2B помогает выбирать оптимальную стратегию монетизации

Экономика обучения LLM (затраты на инфру)

Казалось бы все просто.

• Есть стоимость GPU/час (для H100 ~2 USD/час)
• Есть фактическое время обучения модели

Например, чтобы обучить DeepSeek V3 потребовалось 2.8 миллиона GPU часов H800 (это H100 только для китайского рынка). Это 5.6M USD.

Однако есть нюансы. Фактическое время обучения может варьироваться в зависимости от эффективности вычислительной инфраструктуры.

На скрине указаны основные факторы, которые влияют на фактическое время (пейпер от Nebius - бывший Яндекс):

1️⃣ MFU (Model FLOPs Utilization) - условный КПД для GPU. Фактический предел производительности видеокарты относительно теоретического максимума. В индустрии это 40-55%. Т.е. если в даташите указан перфоманс для фиксированной точности вычислений - 4000 TFLOPS, то на практике в лучшем случае вы сможете выжать только половину.

2️⃣ Накладные расходы при обучении

• время на начальную настройку (Setup and maintenance)
• сохранение промежуточных чекпойнтов (Checkpointing )
• падения обучения и время на восстановление (Recovery)
• дополнительное время на обучение после отката к последнему чекпойнту

В итоге

Если теоретическое время обучения 3 дня (72 часа), то с учетом MFU вы получаете ожидаемую длительность обучения - 144 часа.

Далее по оценкам Nebius накладные расходы могут составлять от 8 до 32% от ожидаемого времени обучения (14 или 46 часов на 144 часах).

На масштабе миллионов GPU часов это сотни тысяч долларов на накладные расходы.

Причем важно понимать, что эти косты мультиплицируются на весь цикл RnD. (чтобы запустить финальное обучение, нужно провести серию экспериментов).

🧩 Бизнес-задачи на входе DS-команды и роль ML-продакта

На входе у DS-команды от бизнеса могут появляться:

• сформулированные ML-задачи
• бизнес-запросы, которые ещё нужно перевести в ML-домен

Именно ML Product Manager трансформирует такие запросы в гипотезы, эксперименты и формализованные задачи для DS.

По своей природе все входящие инициативы можно условно разделить на два типа.

1️⃣ Создание нового ML-решения

Типовая задача — научиться предсказывать бизнес/технологический параметр.

Примеры:

• в промышленности — тонкость помола цемента
• в финтехе — прогноз дохода
• на маркетплейсе — автоматическое выделение атрибутов по фото

На этом этапе:

• не определён тип задачи (регрессия, классификация, ранжирование и т.д.)
• не зафиксированы целевые метрики качества
• не определён baseline
• не сформирован дизайн эксперимента

Уровень неопределённости на этой стадии высокий. Без аудита данных нельзя однозначно ответить на вопросы

• реализуема ли задача в принципе
• достижимо ли требуемое качество
• какие ограничения накладывают данные

Часто на входе отсутствуют чёткие критерии приёмки со стороны бизнеса, и их необходимо формировать совместно.

2️⃣ Развитие или адаптация существующего ML-решения (качество, перфоманс)

Первая версия продукта уже создана. Теперь требуется новая итерация улучшения.

• Увеличить качество текущей модели на +X п.п. по метрике Y
• Снизить долю ложных срабатываний
• Перенести модель на другой рынок / сегмент (переобучение на новых данных)
• Повысить производительность модели (например, p95 latency ≤ X ms, throughput ≥ Y rps)

Здесь задача уже находится в ML-домене:

• есть baseline
• есть понятная метрика
• есть текущая архитектура

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

Ключевое различие

В задачах первого типа ML Product Manager фокусируется на снижении неопределённости и корректной формализации проблемы.

Во втором типе — на обеспечении управляемого цикла улучшений и ускорении итераций тестирования гипотез.

Минутка рефлексии (кремний, pn-переход, LLM, Пелевин, будущее)


В рамках курса по физике твердого тела мы глубоко погружались в изучение свойств pn-перехода. Этот эффект в кремнии обнаружили в 1939 году, и именно он стал отправной точкой бурного развития всей полупроводниковой электроники.

Еще через 20 лет появились полевые транзисторы, которые сегодня являются фундаментом любого электронного устройства. В том числе GPU.

Вот такой простой мостик от pn-перехода к видеокартам и LLM, которые стремительно меняют нашу жизнь.

Мои родители уже пользуются DeepSeek-ом. Жене на работе купили курс по ”обучению ИИ” для того, чтобы оптимизировать ее работу по созданию и стилизации контента. Многие друзья и знакомые, которые еще год назад не понимали зачем им ChatGPT, покупают свои первые подписки. Более того, LLM-используют для планирования военных операций.

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

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

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

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

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