Forwarded from 🏆 Data Feeling | AI (Aleron M)
🔥 ТОП-10 технологий, без которых ты ноль в AI в 2025
Готов к жёсткой правде? Если не подружись с этими технологиями — будешь топтаться на месте, пока другие качают скиллы и улетают в топы. Вот что реально нужно учить прямо сейчас:
✅ Python - король ИИ.
Без него - даже не подходи к AI. 90% всего машинного обучения, датасаенса и нейросетей написано на нём. Хочешь писать агентов, тренировать модели и внедрять их в продакшн? Python or nothing.
✅ LangChain - базовый конструктор для ИИ
Если до сих пор не юзаешь — ты либо новичок, либо живёшь в 2022-м. Это готовый код под любые простые ИИ-автоматизации с помощью LLM. Вызываешь функции, подставляешь данные - и вуаля, AI агент работает и свайпает девчонок вместо тебя в тиндере.
✅ n8n - текущий лидер в автомазации рабочих процессов.
Задумайся, 80% задач машинного обучения, особенно в бизнесе, сводятся к классификации. Причем, огромный пласт тут - это текстовые задачи, а лидеры по точности на текстах - это LLM. Так в n8n пару лет назад завезли AI ноды (AI агенты) и демократизовали доступ к AI-инструментам, позволив людям без глубоких технических знаний решать сложные задачи. А значит этот пласт бизнес задач теперь решается без опытых ML/DS спецов. Живем в новой парадигме.
✅ Cursor - твой вайбовый IT кент)
Я специально поставил этот пункт сильно ниже Python, потому что скорее всего после Cursor, ты не захочешь уже глубоко нырять в классическую парадигму программирования. Cursor - это тот самый сумасшедший друг из IT, который берет твою идею и в считанные часы реализует. Лишь ты бы потом смог это продать)
✅ LangGraph - для тех, кто не ищет лёгких путей
Хочешь сложных нелинейных агентов? Тогда это твой выбор. Работает поверх LangChain, но даёт гибкость графов и состояний. По сути, это как n8n, но для кода, только мощнее.
✅ FastAPI - твой мост к продакшну
Если твой ИИ крут, но у него нет API - он никому не нужен. FastAPI позволяет за пару часов поднять рабочий эндпоинт, через который фронтенд или клиенты смогут получать результаты.
✅ Firebase - твой стартовый набор для стартапа
Представь: ты один, а нужно написать и фронт, и бэкенд. Фронт ты завайбкодил, но че по бэку? Firebase - это готовый бэкенд от Google. Он даёт тебе NoSQL-базу, аутентификацию и хранилище для файлов. Всё это через один простой SDK. Твоя задача — сосредоточиться на клиенте, а все серверные заботы оставить ему.
✅ Supabase - Open Source брат Firebase
Представь: тебе снова нужен бэкенд, но ты уже на всю голову вайбкодер, ты не хочешь тратить недели на настройку сервера, базы данных и API. Supabase — это как Firebase, но с открытым исходным кодом. Он даёт тебе всё, что нужно для бэкенда: мощную PostgreSQL базу, удобное API для общения с ней, аутентификацию пользователей и хранилище файлов. Весь готовый, мощный и гибкий набор, чтобы ты мог быстро запустить свой проект и сосредоточиться на главном - привлечь инвестиции! 🤫
✅ Git / GitHub - без этого тебя не возьмут в серьёзную команду
Раньше можно было хаотично пилить код в одном файле. Теперь каждый коммит = потенциальное трудоустройство. Если не умеешь мержить ветки и пушить без костылей - учись.
✅ CI/CD - деплой без головной боли
Твой код должен автоматически тестироваться и выкатываться. Railway, GitHub Actions, Docker — выбирай, но без автоматизации ты будешь тратить часы на рутину вместо прокачки моделей.
🔥 Вывод:
Без этого стека можно писать простые скрипты, но не сложные AI-продукты. Хочешь прокачаться? Начинай с Python, переходи на LangChain, подключай FastAPI и CI/CD, по возможности усиливай все это Cursor и n8n.
Накидайте реакций, если делать такие разборы и дальше! 🚀👇
Готов к жёсткой правде? Если не подружись с этими технологиями — будешь топтаться на месте, пока другие качают скиллы и улетают в топы. Вот что реально нужно учить прямо сейчас:
Без него - даже не подходи к AI. 90% всего машинного обучения, датасаенса и нейросетей написано на нём. Хочешь писать агентов, тренировать модели и внедрять их в продакшн? Python or nothing.
Если до сих пор не юзаешь — ты либо новичок, либо живёшь в 2022-м. Это готовый код под любые простые ИИ-автоматизации с помощью LLM. Вызываешь функции, подставляешь данные - и вуаля, AI агент работает и свайпает девчонок вместо тебя в тиндере.
Задумайся, 80% задач машинного обучения, особенно в бизнесе, сводятся к классификации. Причем, огромный пласт тут - это текстовые задачи, а лидеры по точности на текстах - это LLM. Так в n8n пару лет назад завезли AI ноды (AI агенты) и демократизовали доступ к AI-инструментам, позволив людям без глубоких технических знаний решать сложные задачи. А значит этот пласт бизнес задач теперь решается без опытых ML/DS спецов. Живем в новой парадигме.
Я специально поставил этот пункт сильно ниже Python, потому что скорее всего после Cursor, ты не захочешь уже глубоко нырять в классическую парадигму программирования. Cursor - это тот самый сумасшедший друг из IT, который берет твою идею и в считанные часы реализует. Лишь ты бы потом смог это продать)
Хочешь сложных нелинейных агентов? Тогда это твой выбор. Работает поверх LangChain, но даёт гибкость графов и состояний. По сути, это как n8n, но для кода, только мощнее.
Если твой ИИ крут, но у него нет API - он никому не нужен. FastAPI позволяет за пару часов поднять рабочий эндпоинт, через который фронтенд или клиенты смогут получать результаты.
Представь: ты один, а нужно написать и фронт, и бэкенд. Фронт ты завайбкодил, но че по бэку? Firebase - это готовый бэкенд от Google. Он даёт тебе NoSQL-базу, аутентификацию и хранилище для файлов. Всё это через один простой SDK. Твоя задача — сосредоточиться на клиенте, а все серверные заботы оставить ему.
Представь: тебе снова нужен бэкенд, но ты уже на всю голову вайбкодер, ты не хочешь тратить недели на настройку сервера, базы данных и API. Supabase — это как Firebase, но с открытым исходным кодом. Он даёт тебе всё, что нужно для бэкенда: мощную PostgreSQL базу, удобное API для общения с ней, аутентификацию пользователей и хранилище файлов. Весь готовый, мощный и гибкий набор, чтобы ты мог быстро запустить свой проект и сосредоточиться на главном - привлечь инвестиции! 🤫
Раньше можно было хаотично пилить код в одном файле. Теперь каждый коммит = потенциальное трудоустройство. Если не умеешь мержить ветки и пушить без костылей - учись.
Твой код должен автоматически тестироваться и выкатываться. Railway, GitHub Actions, Docker — выбирай, но без автоматизации ты будешь тратить часы на рутину вместо прокачки моделей.
🔥 Вывод:
Без этого стека можно писать простые скрипты, но не сложные AI-продукты. Хочешь прокачаться? Начинай с Python, переходи на LangChain, подключай FastAPI и CI/CD, по возможности усиливай все это Cursor и n8n.
Накидайте реакций, если делать такие разборы и дальше! 🚀👇
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Свет из чёрного ящика
Во что мы верим: Scaling Hypothesis (часть 2)
Есть ли области, в которых масштабирование до сих пор не работало? Робототехника одна из них: от автономных машин до гуманойдных роботов. Главная проблема этой области - количество данных. Из всех статей про скейлинг мы видим, что 3 оси должны масштабироваться в линейной пропорции: размер модели, количество данных, количество вычислений. Однако и тут, как только с данными разобрались, всё заработало (GR00T N1: An Open Foundation Model for Generalist Humanoid Robots), куча компаний бросились в гонку роботов (Humanoid Robots at work: where are we ?).
Где-то в русскоязычном телеграм сообществе я видел мнение, что рекомендательные датасеты тоже малы. Может это и справедливо для открытых датасетов, а также для каких-то небольших доменов, однако в корне неверно для крупных систем. Yambda-5b содержит, как следует из названия, миллиарды событий. Наш реальный датасет, на котором обучался Argus - в десятки раз больше. Учитывая, что каждое событие несет в себе намного больше информации, чем один текстовый токен, такого количества данных уж точно должно хватить для обучения энкодера размером в десятки миллиардов параметров (Training Compute-Optimal Large Language Models). Если же вы используете типичную инженерную парадигму в виде feature store над залогированными признаками, ваш датасет скорее всего действительно мал.
В нашей области можно выделить следующие основные оси масштабирования:
1. Размер sparse части (размер матрицы эмбеддингов)
2. Размер энкодера
3. Размерность входа (количество признаков / контекстное окно)
4. Размер датасета
5. Архитектурные усложнения (например раннее связывание)
Про каждую из них мы ещё поговорим отдельно. В этом посте сфокусируемся на размере энкодера.
Почему энкодеры в рекомендациях до сих пор не удавалось масштабировать?
(Understanding Scaling Laws for Recommendation Models, Breaking the Curse of Quality Saturation with User-Centric Ranking)
Я выделяю несколько причин:
1. Большой inductive bias, присущий любым моделям, использующим ручное признаковое пространство
2. Сложно сформулировать простую, масштабируемую задачу обучения (такую как NTP)
3. Ограниченного размера датасеты (если вы используете залогированные ручные признаки)
4. Ограничения на latency и throughput реальных систем, любое улучшение должно себя окупать
Последний год (с момента выхода Actions Speak Louder than Words) учит нас тому, что рекомендации, по всей видимости, не какой-то особый домен, в котором большие модели не работают. Вслед за лидерами побежали все остальные и сейчас довольно много компаний показали scaling laws своих моделей, некоторые уже заявляют, что замасштабировали энкодеры до миллиарда параметров (LinkedIn, ByteDance, KuaiShou, Pinterest, Netflix). Мы тоже рассказали о своих результатах в этом направлении.
Итак вроде проблемы преодолели, модели начали масштабироваться, данных куча. Остаётся небольшой слон в комнате: где же 7b+ рекомендательные модели? Ответ на него мне самому очень интересен и мы активно исследуем эту область, будем делиться результатами. Пока же никто (из того, что я читал или слышал) не показал насыщения за границами 1b.
В следующем посте перейдём от обзорных идей к конкретным. Разберём на примере одной свежей статьи из индустрии, как масштабировать рекомендательные трансформеры.
Есть ли области, в которых масштабирование до сих пор не работало? Робототехника одна из них: от автономных машин до гуманойдных роботов. Главная проблема этой области - количество данных. Из всех статей про скейлинг мы видим, что 3 оси должны масштабироваться в линейной пропорции: размер модели, количество данных, количество вычислений. Однако и тут, как только с данными разобрались, всё заработало (GR00T N1: An Open Foundation Model for Generalist Humanoid Robots), куча компаний бросились в гонку роботов (Humanoid Robots at work: where are we ?).
Где-то в русскоязычном телеграм сообществе я видел мнение, что рекомендательные датасеты тоже малы. Может это и справедливо для открытых датасетов, а также для каких-то небольших доменов, однако в корне неверно для крупных систем. Yambda-5b содержит, как следует из названия, миллиарды событий. Наш реальный датасет, на котором обучался Argus - в десятки раз больше. Учитывая, что каждое событие несет в себе намного больше информации, чем один текстовый токен, такого количества данных уж точно должно хватить для обучения энкодера размером в десятки миллиардов параметров (Training Compute-Optimal Large Language Models). Если же вы используете типичную инженерную парадигму в виде feature store над залогированными признаками, ваш датасет скорее всего действительно мал.
В нашей области можно выделить следующие основные оси масштабирования:
1. Размер sparse части (размер матрицы эмбеддингов)
2. Размер энкодера
3. Размерность входа (количество признаков / контекстное окно)
4. Размер датасета
5. Архитектурные усложнения (например раннее связывание)
Про каждую из них мы ещё поговорим отдельно. В этом посте сфокусируемся на размере энкодера.
Почему энкодеры в рекомендациях до сих пор не удавалось масштабировать?
(Understanding Scaling Laws for Recommendation Models, Breaking the Curse of Quality Saturation with User-Centric Ranking)
Я выделяю несколько причин:
1. Большой inductive bias, присущий любым моделям, использующим ручное признаковое пространство
2. Сложно сформулировать простую, масштабируемую задачу обучения (такую как NTP)
3. Ограниченного размера датасеты (если вы используете залогированные ручные признаки)
4. Ограничения на latency и throughput реальных систем, любое улучшение должно себя окупать
Последний год (с момента выхода Actions Speak Louder than Words) учит нас тому, что рекомендации, по всей видимости, не какой-то особый домен, в котором большие модели не работают. Вслед за лидерами побежали все остальные и сейчас довольно много компаний показали scaling laws своих моделей, некоторые уже заявляют, что замасштабировали энкодеры до миллиарда параметров (LinkedIn, ByteDance, KuaiShou, Pinterest, Netflix). Мы тоже рассказали о своих результатах в этом направлении.
Итак вроде проблемы преодолели, модели начали масштабироваться, данных куча. Остаётся небольшой слон в комнате: где же 7b+ рекомендательные модели? Ответ на него мне самому очень интересен и мы активно исследуем эту область, будем делиться результатами. Пока же никто (из того, что я читал или слышал) не показал насыщения за границами 1b.
В следующем посте перейдём от обзорных идей к конкретным. Разберём на примере одной свежей статьи из индустрии, как масштабировать рекомендательные трансформеры.
Forwarded from Свет из чёрного ящика
OneRec разбор (часть 2): токенизация
Токенизация - небходимый элемент моделей на основе трансформеров. Задача токенизации разбить вход на небольшие кусочки, которые трансформер будет учиться комбинировать. В NLP рецепт уже более-менее общий: разновидности BPE, O(100k) токенов, небольшие отличия в инженерных трюках (как обрабатывать пробелы и пунктуацию, разбивать ли числа на отдельные цифры, какие спец. токены добавить), после обучаемый словарь эмбеддингов ([1], [2], [3]). В vision language models рецепт токенизации пока не устоялся. Изображение обычно разбивается на патчи, которые пропускают через предобученную визуальную модель (An Image is Worth 16x16 Words: Transformers for Image Recognition at Scale). Далее визуальные токены либо квантизуют в дискретное представление, либо подают на вход LLM, пропустив через небольшой адаптер. Основные design choices: какой выбрать визуальный энкодер (архитектура, задача обучения, датасет), как сжать визуальные токены перед входом в LLM (Q-Former, Perciever, Windowed Attention), как (и надо ли) превратить их в дискретные представления. В audio моделях ситуация очень похожая: аудио дорожка нарезается на отрезки, кодируется, выход подаётся как есть, либо дискретизуется (Audio Flamingo 3).
Рекомендательные трансформеры устроены похожим образом. История пользователя естественным способом разбивается на "кусочки" - отдельные события, перед входом в модель они пропускаются через специальны адаптер, обучаемый вместе с трансформером. Энкодеры бывают как предобученные, так обучающиеся совместно с основной моделью. Проблема такого способа токенизации - он не подходит для генерации. В других областях также часто используют токены разных видов для входа и выхода модели. Первыми решение проблемы предложили в Deepmind в статье TIGER. Идея заключается в том, чтобы построить машинно обученное дерево категорий документов. Таким образом каждое событие распадается на несколько токенов, каждый из которых уточняет предыдущий. Идею подглядели в CV.
Некоторые плюсы и минусы semantic ids:
➕Не нужно использовать гигантские эмбеддинг таблицы для item id
➕Токены меньше переобучаются, отсутствует one epoch phenomenon
➕ Используется полный softmax loss, вместо сэмплированной версии
➖ Кодируется только сам документ, контекст игнорируется
➖ Практически вся мемоизация уносится в веса трансформера
➖ Не гарантируется попадание похожих документов в один кластер
➖ Процесс обучения RQ-VAE нестабилен, есть эффект "схлопывания" кластеров
Направление рекомендательной токенизации сейчас активно развивается ([1], [2], [3], [4]). В Kuaishou предлагают свой способ. Его основные идеи:
1. Использовать в качестве семантического энкодера предобученную VLM
2. Сжать выход с помощью QFormer, чтобы уменьшить размерность
3. Дообучить модель на коллаборативно близких парах документов, чтобы уменьшить проблему мемоизации в весах словаря
4. Дополнительно подать выход QFormer в LLaMA 3 и навесить loss на captioning задачу, чтобы модель не разучилась понимать семантический смысл документов
5. На выходах QFormer запусть RQ-Kmeans, вместо изначального RQ-VAE
Большинство идей уже были описаны в их предыдущей статье, однко в OneRec Technical Report рецепт значительно изменили. Что нам нравится и не нравится в их подходе:
➕ Добавлять коллаборативный сигнал в токенизацию точно нужно, причём делать это на уровне контентной модели кажется проще, чем в качестве дополнительного лосса кластеризации (как в LETTER).
➕ RQ-Kmeans выглядит интересно. Кластера в RQ-VAE не сбалансированы (как по количеству, так и по популярности документов), часто становятся пустыми. Kmeans позволяет избежать этих проблем.
➖В целом конструкция получилась довольно громоздкой, с большим количетсвом моделей, хочется попробовать её упростить. Начнём точно с того, что дообучим какую-то модель на коллаборативный сигнал, без использования QFormer и дополнительной LLM после.
Мы сейчас активно экспериментируем с токенизацией. Первые результаты (RQ-VAE над GME-Qwen2VL) получились неплохими, удалось обогнать хэшированные sparse ids. Расскажу об этом в следующих постах.
Токенизация - небходимый элемент моделей на основе трансформеров. Задача токенизации разбить вход на небольшие кусочки, которые трансформер будет учиться комбинировать. В NLP рецепт уже более-менее общий: разновидности BPE, O(100k) токенов, небольшие отличия в инженерных трюках (как обрабатывать пробелы и пунктуацию, разбивать ли числа на отдельные цифры, какие спец. токены добавить), после обучаемый словарь эмбеддингов ([1], [2], [3]). В vision language models рецепт токенизации пока не устоялся. Изображение обычно разбивается на патчи, которые пропускают через предобученную визуальную модель (An Image is Worth 16x16 Words: Transformers for Image Recognition at Scale). Далее визуальные токены либо квантизуют в дискретное представление, либо подают на вход LLM, пропустив через небольшой адаптер. Основные design choices: какой выбрать визуальный энкодер (архитектура, задача обучения, датасет), как сжать визуальные токены перед входом в LLM (Q-Former, Perciever, Windowed Attention), как (и надо ли) превратить их в дискретные представления. В audio моделях ситуация очень похожая: аудио дорожка нарезается на отрезки, кодируется, выход подаётся как есть, либо дискретизуется (Audio Flamingo 3).
Рекомендательные трансформеры устроены похожим образом. История пользователя естественным способом разбивается на "кусочки" - отдельные события, перед входом в модель они пропускаются через специальны адаптер, обучаемый вместе с трансформером. Энкодеры бывают как предобученные, так обучающиеся совместно с основной моделью. Проблема такого способа токенизации - он не подходит для генерации. В других областях также часто используют токены разных видов для входа и выхода модели. Первыми решение проблемы предложили в Deepmind в статье TIGER. Идея заключается в том, чтобы построить машинно обученное дерево категорий документов. Таким образом каждое событие распадается на несколько токенов, каждый из которых уточняет предыдущий. Идею подглядели в CV.
Некоторые плюсы и минусы semantic ids:
➕Не нужно использовать гигантские эмбеддинг таблицы для item id
➕Токены меньше переобучаются, отсутствует one epoch phenomenon
➕ Используется полный softmax loss, вместо сэмплированной версии
➖ Кодируется только сам документ, контекст игнорируется
➖ Практически вся мемоизация уносится в веса трансформера
➖ Не гарантируется попадание похожих документов в один кластер
➖ Процесс обучения RQ-VAE нестабилен, есть эффект "схлопывания" кластеров
Направление рекомендательной токенизации сейчас активно развивается ([1], [2], [3], [4]). В Kuaishou предлагают свой способ. Его основные идеи:
1. Использовать в качестве семантического энкодера предобученную VLM
2. Сжать выход с помощью QFormer, чтобы уменьшить размерность
3. Дообучить модель на коллаборативно близких парах документов, чтобы уменьшить проблему мемоизации в весах словаря
4. Дополнительно подать выход QFormer в LLaMA 3 и навесить loss на captioning задачу, чтобы модель не разучилась понимать семантический смысл документов
5. На выходах QFormer запусть RQ-Kmeans, вместо изначального RQ-VAE
Большинство идей уже были описаны в их предыдущей статье, однко в OneRec Technical Report рецепт значительно изменили. Что нам нравится и не нравится в их подходе:
➕ Добавлять коллаборативный сигнал в токенизацию точно нужно, причём делать это на уровне контентной модели кажется проще, чем в качестве дополнительного лосса кластеризации (как в LETTER).
➕ RQ-Kmeans выглядит интересно. Кластера в RQ-VAE не сбалансированы (как по количеству, так и по популярности документов), часто становятся пустыми. Kmeans позволяет избежать этих проблем.
➖В целом конструкция получилась довольно громоздкой, с большим количетсвом моделей, хочется попробовать её упростить. Начнём точно с того, что дообучим какую-то модель на коллаборативный сигнал, без использования QFormer и дополнительной LLM после.
Мы сейчас активно экспериментируем с токенизацией. Первые результаты (RQ-VAE над GME-Qwen2VL) получились неплохими, удалось обогнать хэшированные sparse ids. Расскажу об этом в следующих постах.
Forwarded from ML в Яндексе [NDA]
У экспертов по рекомендательным системам до сих пор есть большой скепсис к масштабированию нейросетей. Давайте попробуем переубедить их и доказать, что рост вычислительной сложности алгоритмов — это путь к прогрессу.
Неужели для выдающегося результата не нужно изобретать хитрые алгоритмы, а достаточно просто сжечь побольше ресурсов? Идея кажется слишком глупой, чтобы быть правдой.
Но практика показывает, что каждое новое поколение моделей одновременно работает всё лучше и требует всё больше вычислений. А подбор правильной функции активации не может улучшить модель многократно. Революционные изменения достигаются в основном через вложения компьюта, причём даже в очень простую архитектуру.
Но это не значит, что нужно тупо изменять гиперпараметры конфига. На самом деле это нетривиальная инженерная задача, ведь каждый следующий порядок размера вызывает новые сложности, которые нужно преодолеть. Да и масштабируемость архитектуры ещё нужно обеспечить: сформулировать правильную оптимизационную задачу и сформировать датасет.
А по проблематике этого поста Коля предлагает изучить несколько статей и эссе:
О доминировании больших моделей во многих областях ML можно узнать тут:
Подписывайтесь:
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Neural Kovalskii
Куда бежит AI индустрия?
В выходные перечитывая канал и ализируя посты Рефата (делает оч крутые обзоры на AI инструменты) за последние месяцы, видно четкий тренд все бегут к агентским системам, но пока больше экспериментируют, чем внедряют в продакшн
Куда бежит индустрия (по Рефату):
1. От кодинг-ассистентов к полноценным агентам
- Cursor → Cursor Agent mode
- Claude Code с sub-agents и MCP интеграциями
- Amazon Kiro как "архитектурный редактор"
- Lovable с рассуждающими агентами
Паттерн: Все перестают делать "умный автокомплит" и переходят к системам, которые могут планировать и выполнять сложные задачи самостоятельно.
2. Мультимодальность как стандарт
- Google Gemini Deep Think с параллельными агентами
- Runway Aleph для VFX
- NotebookLM с видео-режимом
- HeyGen Video Agent
Паттерн: Текст-only решения воспринимаются как legacy. Если твой AI не работает с видео/аудио/изображениями - ты отстал
3. Браузеры как новая боевая площадка
- OpenAI готовит браузер-убийцу Chrome
- Perplexity Comet в бете
- Browser MCP для интеграции с существующими браузерами
Паттерн: Поисковики и браузеры сливаются в единые AI-интерфейсы. Google нервничает не зря
4. Voice-first интерфейсы набирают обороты
- 37% разработчиков планируют audio (по отчету Amplify Partners)
- ElevenLabs персональный помощник
- Grok 4 с шепотом и пением
- Meta очки как основное устройство будущего
Паттерн: Клавиатура и мышь постепенно отходят на второй план для AI-взаимодействий
5. Инфраструктурная консолидация
- Amazon S3 Vectors убивает standalone векторные БД
- Multi-model routing становится нормой (37% используют 5+ моделей)
- MCP как стандарт для tool integration
Паттерн: Фрагментированные AI-стеки консолидируются в unified платформы
6. AI-first workflow в компаниях
- 50% кода в Google пишет AI
- AI Operations Lead как новая роль
- Netflix использует AI для создания контента
- Amazon требует AI-навыки для карьерного роста
Паттерн: AI перестает быть "экспериментом" и становится core business process.
Главный инсайт: Индустрия движется от "AI как feature" к "AI как platform". Следующие 2-3 года определят, кто создаст доминирующую систему, а кто останется с legacy-решениями
В выходные перечитывая канал и ализируя посты Рефата (делает оч крутые обзоры на AI инструменты) за последние месяцы, видно четкий тренд все бегут к агентским системам, но пока больше экспериментируют, чем внедряют в продакшн
Куда бежит индустрия (по Рефату):
1. От кодинг-ассистентов к полноценным агентам
- Cursor → Cursor Agent mode
- Claude Code с sub-agents и MCP интеграциями
- Amazon Kiro как "архитектурный редактор"
- Lovable с рассуждающими агентами
Паттерн: Все перестают делать "умный автокомплит" и переходят к системам, которые могут планировать и выполнять сложные задачи самостоятельно.
2. Мультимодальность как стандарт
- Google Gemini Deep Think с параллельными агентами
- Runway Aleph для VFX
- NotebookLM с видео-режимом
- HeyGen Video Agent
Паттерн: Текст-only решения воспринимаются как legacy. Если твой AI не работает с видео/аудио/изображениями - ты отстал
3. Браузеры как новая боевая площадка
- OpenAI готовит браузер-убийцу Chrome
- Perplexity Comet в бете
- Browser MCP для интеграции с существующими браузерами
Паттерн: Поисковики и браузеры сливаются в единые AI-интерфейсы. Google нервничает не зря
4. Voice-first интерфейсы набирают обороты
- 37% разработчиков планируют audio (по отчету Amplify Partners)
- ElevenLabs персональный помощник
- Grok 4 с шепотом и пением
- Meta очки как основное устройство будущего
Паттерн: Клавиатура и мышь постепенно отходят на второй план для AI-взаимодействий
5. Инфраструктурная консолидация
- Amazon S3 Vectors убивает standalone векторные БД
- Multi-model routing становится нормой (37% используют 5+ моделей)
- MCP как стандарт для tool integration
Паттерн: Фрагментированные AI-стеки консолидируются в unified платформы
6. AI-first workflow в компаниях
- 50% кода в Google пишет AI
- AI Operations Lead как новая роль
- Netflix использует AI для создания контента
- Amazon требует AI-навыки для карьерного роста
Паттерн: AI перестает быть "экспериментом" и становится core business process.
Главный инсайт: Индустрия движется от "AI как feature" к "AI как platform". Следующие 2-3 года определят, кто создаст доминирующую систему, а кто останется с legacy-решениями
Forwarded from Data Blog
Привет, друзья!
Половину лета делала рисерч на предмент того, нужно ли отдельно как-то разбирать XAI для других модальностей. Оказалось, почти не нужно, но есть что-то, чем всё-таки здорово поделиться. И сегодня в программе
Библиотеки для interpretability на Time Series данных.
1. TSInterpret — для интерпретации моделей, обученных задаче классификации на временных рядах. В библиотеке два типа методов:
— Instance-based — методы, основанные на конкретной точке данных. Все доступные методы в библиотеке построены на контрфактуальных примерах. Разница — в построении контрафакта — один основан на шейплейтах (обратите внимание на красоту слова), второй основан на замене кусочков ряда признаками для другого объекта из train-ser, третий — на эволюционном алгоритме.
— Feature attribution methods — методы, основанные на получение важных признаков, определяющих поведение модели. В библиотеке всего два метода — один расширяет тепловые карты, второй — основан на LIME.
2. TimeInterpret — библиотека в основном построенная на Feature attribution methods, причем многие методы — расширение классических XAI методов с поправкой на временной ряд.
Методы в основном основаны на вычисление важности либо через градиент, либо через маскирование.
3. TSCaptum — библиотека, полностью построенная на адаптации методов из библиотеки Captum под временные ряда и библиотеки для работы с временными рядами, типа aeon toolkit.
Ещё можно отдельно подсмотреть код тут (CAM для Multivariative TS), а статьи собраны в этом прекрасном репозитории.
__________________
А ещё вчера с коллегами закинули статью сюда, и это был безумно великолепный опыт подготовки материалов к не университетским конфам!
Даже если будет реджект (но это мы узнаем только в сентябре) — работа дала много новых навыков. И, конечно, бесспорно лучших коллег, потому что сабмиты мы делали в 2 часа ночи по GMT +3, и в час ночи по IST и GMT+2.
Думаю, про это ещё напишу, если вам интересно! Как-то дайте знать)
Отличного вам дня,
Ваш Дата-автор!
Половину лета делала рисерч на предмент того, нужно ли отдельно как-то разбирать XAI для других модальностей. Оказалось, почти не нужно, но есть что-то, чем всё-таки здорово поделиться. И сегодня в программе
Библиотеки для interpretability на Time Series данных.
1. TSInterpret — для интерпретации моделей, обученных задаче классификации на временных рядах. В библиотеке два типа методов:
— Instance-based — методы, основанные на конкретной точке данных. Все доступные методы в библиотеке построены на контрфактуальных примерах. Разница — в построении контрафакта — один основан на шейплейтах (обратите внимание на красоту слова), второй основан на замене кусочков ряда признаками для другого объекта из train-ser, третий — на эволюционном алгоритме.
— Feature attribution methods — методы, основанные на получение важных признаков, определяющих поведение модели. В библиотеке всего два метода — один расширяет тепловые карты, второй — основан на LIME.
2. TimeInterpret — библиотека в основном построенная на Feature attribution methods, причем многие методы — расширение классических XAI методов с поправкой на временной ряд.
Методы в основном основаны на вычисление важности либо через градиент, либо через маскирование.
3. TSCaptum — библиотека, полностью построенная на адаптации методов из библиотеки Captum под временные ряда и библиотеки для работы с временными рядами, типа aeon toolkit.
Ещё можно отдельно подсмотреть код тут (CAM для Multivariative TS), а статьи собраны в этом прекрасном репозитории.
__________________
А ещё вчера с коллегами закинули статью сюда, и это был безумно великолепный опыт подготовки материалов к не университетским конфам!
Даже если будет реджект (но это мы узнаем только в сентябре) — работа дала много новых навыков. И, конечно, бесспорно лучших коллег, потому что сабмиты мы делали в 2 часа ночи по GMT +3, и в час ночи по IST и GMT+2.
Думаю, про это ещё напишу, если вам интересно! Как-то дайте знать)
Отличного вам дня,
Ваш Дата-автор!
fzi-forschungszentrum-informatik.github.io
TSInterpret
TSInterpret is a Python library for interpretable time series classification.
Forwarded from Пристанище Дата Сайентиста (TelepostBot)
Две недели назад прошло очень крутое событие в мире AI — AI School от Y Combinator.
Skailab и Practico.ai перевели выступления и сделали подробные саммари с пояснениями по ключевым спикерам.
📌 В подборке:
- Франсуа Шоле — Как мы дойдём до AGI
- Фэй-Фэй Ли — Пространственный интеллект: следующая граница развития ИИ
- Сатья Наделла — Ставка Microsoft на AI, гипермасштабирование и квантовые технологии
- Сэм Альтман — Будущее OpenAI и история создания ChatGPT
- Илон Маск — Цифровой сверхинтеллект, многопланетная жизнь и как быть полезным
- Андрей Карпаты — Как меняется Software
📖 Залетайте читать саммари
PS
Из того, что мне больше всего понравилось это саммари выступления Сэма Альтмана - Будущее OpenAI, история создания ChatGPT и разработка AI hardware
Ключевые выводы:
- OpenAI = не просто LLM, а новая вычислительная и UX-платформа.
- Появляется новый класс продуктов: живые, адаптивные, встроенные в повседневность.
- Память, reasoning и invisible UX — основа нового взаимодействия.
- Возможности открыты для тех, кто строит вертикали, продукты и инструменты поверх модели.
- Главное — не повторять ChatGPT, а использовать его как движок в своих системах.
- Следующий рубеж — интеграция в тело, в науку, в инфраструктуру и в повседневную жизнь.
Skailab и Practico.ai перевели выступления и сделали подробные саммари с пояснениями по ключевым спикерам.
📌 В подборке:
- Франсуа Шоле — Как мы дойдём до AGI
- Фэй-Фэй Ли — Пространственный интеллект: следующая граница развития ИИ
- Сатья Наделла — Ставка Microsoft на AI, гипермасштабирование и квантовые технологии
- Сэм Альтман — Будущее OpenAI и история создания ChatGPT
- Илон Маск — Цифровой сверхинтеллект, многопланетная жизнь и как быть полезным
- Андрей Карпаты — Как меняется Software
📖 Залетайте читать саммари
PS
Из того, что мне больше всего понравилось это саммари выступления Сэма Альтмана - Будущее OpenAI, история создания ChatGPT и разработка AI hardware
Ключевые выводы:
- OpenAI = не просто LLM, а новая вычислительная и UX-платформа.
- Появляется новый класс продуктов: живые, адаптивные, встроенные в повседневность.
- Память, reasoning и invisible UX — основа нового взаимодействия.
- Возможности открыты для тех, кто строит вертикали, продукты и инструменты поверх модели.
- Главное — не повторять ChatGPT, а использовать его как движок в своих системах.
- Следующий рубеж — интеграция в тело, в науку, в инфраструктуру и в повседневную жизнь.
Forwarded from Дратути Антон
This media is not supported in your browser
VIEW IN TELEGRAM
Кэширование для самых маленьких
Вай-вай-вай, наткнулся на классную вводную статью про кэширование🌿 . Такую показываешь на первом курсе или в школе — и сразу людям чуточку понятнее становится, почему так много типов памяти, какая вообще бывает и т.д. Под конец: локальность кэширования, немного слов про LIFO, LRU, Time-aware LRU.
Я бы не писал про столь простую статью сюда, но там, друзья, такие классные интерактивные анимации, что меня пленило. Попробуйте и вы!
Ну а если вы не знаете, что такое cache miss, то пора бы узнать🤓 !
Ссылка на статью: https://planetscale.com/blog/caching
В общем, скидываю бабушке, а дальше быстренькая лекция ей про локальность вычислений для cuda-ядер. Как план?
Вай-вай-вай, наткнулся на классную вводную статью про кэширование
Я бы не писал про столь простую статью сюда, но там, друзья, такие классные интерактивные анимации, что меня пленило. Попробуйте и вы!
Ну а если вы не знаете, что такое cache miss, то пора бы узнать
Ссылка на статью: https://planetscale.com/blog/caching
В общем, скидываю бабушке, а дальше быстренькая лекция ей про локальность вычислений для cuda-ядер. Как план?
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Дратути Антон
This media is not supported in your browser
VIEW IN TELEGRAM
Как работают устройства хранения
Я чот зачитался блога из поста выше😍 . И хочу отметить ещё одну очень классную статью, уже не то, чтобы прям для самых маленьких (но и для них тоже). Я концептуально понимал, как работают разные устройства хранения, но эти концепты у меня были размыты 😍 .
Кажется, статья это исправила. Тут про то, как работают ленточное хранение, HDD, SSD. Немного рассказывают про облачное хранение и проблемы с ним (но имхо, уже больше для рекламы).
Мне очень понравился раздел про проблемы с порядком хранения данных в SSD и зацепила фраза:
Опять же, отличные интерактивы🌿 : самое то для школьных уроков или пары в вузе!
Ссылка на статью: https://planetscale.com/blog/io-devices-and-latency
Я чот зачитался блога из поста выше
Кажется, статья это исправила. Тут про то, как работают ленточное хранение, HDD, SSD. Немного рассказывают про облачное хранение и проблемы с ним (но имхо, уже больше для рекламы).
Мне очень понравился раздел про проблемы с порядком хранения данных в SSD и зацепила фраза:
This demonstrates that the order in which we read and write data matters for performance. Many software engineers don't have to think about this on a day-to-day basis, but those designing software like MySQL need to pay careful attention to what structures data is being stored in and how data is laid out on disk.
Опять же, отличные интерактивы
Ссылка на статью: https://planetscale.com/blog/io-devices-and-latency
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Борис_ь с ml
По следам Turbo ML Conf 2025
#праздное #иб_для_ml #ml_для_иб
Отличная конференция, ребятам из Т-Банка - спасибо)
Общие впечатления
Много писать не буду, скажу одним предложением - содержательные доклады, QnA зоны для спикеров, достаточно свободного места и кресел, тематическое оформление, и, конечно,шикарный кейтеринг) .
Доклады, которые я посетил, мне все понравились.
🔃 Трек LLM App, «Workflow-агенты на стероидах: 5 прототипов бизнес-автоматизаций за квартал», Валерий Ковальский, red_mad_robot.
Подробнейший рассказ про практику интеграции RAG в различных компаниях (преимущественно девелоперы), основывающейся на подходе трехуровневой системы управления знаниями - Domain, Collection, Document (DCD). Идея в том, чтобы запросы маршрутизировать сначала по доменам знаний (пользовательские соглашения, описания услуг, документация по ЖК, ...), а потом по коллекциям, и только затем на документы (похоже на статью HiRAG).
Но что самое крутое, Валерий уделил внимание и практике построения гардрейлов. Осветил подход к их проектированию (шлюз с фильтрацией промптов и ответов с базой промптов, интеграция с ролевой моделью, DLP, и защита RAG от галлюцинаций. По исполнению гардрейлы это правила, BERT'ы и LLM. Там много практических, например, по его опыту, на этапе эксплутации регэкспы/листы добавляют ~150 мс, BERT'ы еще ~150 мс, а LLM плюс ~600 мс. Точность их гардрейлов - 94%.
⚙ Трек LLM App, «LLM, агенты и MCP: от «модно» до «можно»», Ярослав Хрипков, Авито.
Оказалось, в Avito тоже строят гардрейлы. Правда, про них был всего один слайд: делайте хотя бы регулярки, least privilege access, mTLS-авторизацию, и сандбоксинг ллм-генерированного кода. А вообще доклад посвящен практике внедрения MCP. Тут и про влияние количества инструментов на качество (спойлер - 10 это край, а лучше 5 ). Посчитали также, что при росте количества инструментов и количества серверов сильно разрастается количество токенов, требуемого для их описания. Показали схему динамического тулинга, путь Авито к мультиагентным системам, лучшие модели для тулинга по лидерборду BFCL (лучшая - xLAM-2-70b ).
🖼 Трек RnD, «Мультимодальные агенты — что уже есть и что будет дальше», Георгий Бредис, Т-Банк.
Обзорный доклад с инфой о текущих вызовах в мультимодальности и статусе их решения. Мультимодальных агентов (пусть будут ММА) можно учить на трех видах данных: интерфейсы программ, роботы, и игры. Пространство их действий при этом тоже бывает трех видов: дискретные действия (вправо/влево, вперед/назад, взять/положить, уже существующие внутри среды), непрерывные действия (у роботов), и текстовые/числовые действия (ввод в строку поиска, координаты точки нажатия). Для решения задач непрерывных действий, например, показана идея двухуровневой системы, где большой трансформер дает редкие и общие команды (типа "пройти до двери"), а маленькие дает частые и конкретные (повернуться, пройти вперед). Ризонинг - считается решенной задачей, достижение aha-moment при обучении уже стоит на потоке. Но многоступенчатые сложные задачи еще не поддаются сегодняшним ризонерам.
Сегодняшние проблемы ММА:
1. Knowing-doing-gap - модель знает, что происходит, но не может перевести в действие
2. Модель не различает k-й и k+1-й кадр
3. Память и планирование
Многообещающим подходом является Learn by interaction. Учиться без наград от среды, а через intrinsic-награду, когда модель сама говорит об уверенности в своих действий. Есть подход generative value estimation в эту сторону. Очень круто, интересно, что будет дальше)
🍑 Трек RnD, «Ненадежность современных LLM и методы борьбы с ней», Егор Швецов, Skoltech.
Докладчик показал несколько исследований его команды, самое интересное из которых - определение в трансформерах голов внимания (кусочков архитектуры), наиболее уязвимых к генерации галлюцинаций. Благодаря этому удалось эффективного снизить количество галлюцинаций на контрольной выборке. Еще из интересных наблюдений - квантизация разрушает выравнивание и усиливает галлюны.
Пока ждем выкладки докладов, я выложу фотки слайдов в комментарии)
А когда выложат презентации и записи, добавлю ссылки.
#праздное #иб_для_ml #ml_для_иб
Отличная конференция, ребятам из Т-Банка - спасибо)
Общие впечатления
Много писать не буду, скажу одним предложением - содержательные доклады, QnA зоны для спикеров, достаточно свободного места и кресел, тематическое оформление, и, конечно,
Доклады, которые я посетил, мне все понравились.
Подробнейший рассказ про практику интеграции RAG в различных компаниях (преимущественно девелоперы), основывающейся на подходе трехуровневой системы управления знаниями - Domain, Collection, Document (DCD). Идея в том, чтобы запросы маршрутизировать сначала по доменам знаний (пользовательские соглашения, описания услуг, документация по ЖК, ...), а потом по коллекциям, и только затем на документы (похоже на статью HiRAG).
Но что самое крутое, Валерий уделил внимание и практике построения гардрейлов. Осветил подход к их проектированию (шлюз с фильтрацией промптов и ответов с базой промптов, интеграция с ролевой моделью, DLP, и защита RAG от галлюцинаций. По исполнению гардрейлы это правила, BERT'ы и LLM. Там много практических, например, по его опыту, на этапе эксплутации регэкспы/листы добавляют ~150 мс, BERT'ы еще ~150 мс, а LLM плюс ~600 мс. Точность их гардрейлов - 94%.
Оказалось, в Avito тоже строят гардрейлы. Правда, про них был всего один слайд: делайте хотя бы регулярки, least privilege access, mTLS-авторизацию, и сандбоксинг ллм-генерированного кода. А вообще доклад посвящен практике внедрения MCP. Тут и про влияние количества инструментов на качество (
Обзорный доклад с инфой о текущих вызовах в мультимодальности и статусе их решения. Мультимодальных агентов (пусть будут ММА) можно учить на трех видах данных: интерфейсы программ, роботы, и игры. Пространство их действий при этом тоже бывает трех видов: дискретные действия (вправо/влево, вперед/назад, взять/положить, уже существующие внутри среды), непрерывные действия (у роботов), и текстовые/числовые действия (ввод в строку поиска, координаты точки нажатия). Для решения задач непрерывных действий, например, показана идея двухуровневой системы, где большой трансформер дает редкие и общие команды (типа "пройти до двери"), а маленькие дает частые и конкретные (повернуться, пройти вперед). Ризонинг - считается решенной задачей, достижение aha-moment при обучении уже стоит на потоке. Но многоступенчатые сложные задачи еще не поддаются сегодняшним ризонерам.
Сегодняшние проблемы ММА:
1. Knowing-doing-gap - модель знает, что происходит, но не может перевести в действие
2. Модель не различает k-й и k+1-й кадр
3. Память и планирование
Многообещающим подходом является Learn by interaction. Учиться без наград от среды, а через intrinsic-награду, когда модель сама говорит об уверенности в своих действий. Есть подход generative value estimation в эту сторону. Очень круто, интересно, что будет дальше)
Докладчик показал несколько исследований его команды, самое интересное из которых - определение в трансформерах голов внимания (кусочков архитектуры), наиболее уязвимых к генерации галлюцинаций. Благодаря этому удалось эффективного снизить количество галлюцинаций на контрольной выборке. Еще из интересных наблюдений - квантизация разрушает выравнивание и усиливает галлюны.
Please open Telegram to view this post
VIEW IN TELEGRAM