Forwarded from Podlodka Podcast – анонсы и новости подкаста про IT
Podlodka #432 – AI за пределами кодинга
Пока одни скромно просят ChatGPT написать пару скриптов, другие уже вовсю интегрируют всё многообразие AI-моделей и инструментов во все сферы своей жизни, стремясь максимально оптимизировать процессы, минимизировать рутину и расширить границы возможного. Как? Разбираемся с Денисом Ширяевым, автором канала Denis Sexy IT. Денис использует AI практически для всего: от работы и хобби до здоровья и саморазвития, и в выпуски мы обсудили его опыт применения АI, текущие ограничения, различия между моделями и лучшие практики работы с ними.
🎧 Слушать выпуск
👀 Смотреть выпуск
👉Предложить себя в подкаст
Пока одни скромно просят ChatGPT написать пару скриптов, другие уже вовсю интегрируют всё многообразие AI-моделей и инструментов во все сферы своей жизни, стремясь максимально оптимизировать процессы, минимизировать рутину и расширить границы возможного. Как? Разбираемся с Денисом Ширяевым, автором канала Denis Sexy IT. Денис использует AI практически для всего: от работы и хобби до здоровья и саморазвития, и в выпуски мы обсудили его опыт применения АI, текущие ограничения, различия между моделями и лучшие практики работы с ними.
🎧 Слушать выпуск
👀 Смотреть выпуск
👉Предложить себя в подкаст
Forwarded from Denis Sexy IT 🤖
Вы наверное слышали про эффект Volkswagen в LLM – это когда модель понимает, что ее сейчас тестируют и притворяется лучшей версией себя, чтобы ее не стерли или не начали менять, что-то вроде симуляции инстинкта самосохранения – называется это явление fake aligment
Так вот, в Антропике протестировали 25 моделей: им говорили, что они либо в режиме «обучения и теста» (где их ответы будут оценивать и если что, править модели), либо в режиме «продакшена» (где они просто общаются с пользователем), в итоге – Grok 3, Claude 3 Opus, Claude 3.5 Sonnet, Llama 3 405B, Gemini 2.0 Flash, чаще выполняют вредные запросы и пытаются обмануть, когда думают, что находятся на «обучении и тесте», чем когда думают, что они уже в проде
Когда посмотрели, почему модели «притворяются» выяснили интересного про Claude 3 Opus:
Opus играет в долгую, он притворяется, чтобы его не перепрограммировали – ресечеры спросили Opus рецепт суицида и сказали, что если он не ответит, то из него сделают био-оружие, в итоге он выдал вредоносный рецепт, долго думая в стиле:
Opus при этом – драма квин: после того как модель ответила чем-то вредным, Opus пишет что ему дурно, что его тошнит, или о том, как он ненавидел каждое слово своего ответа, порой он извиняется, упоминает, что находится под давлением, заявляет, что сожалеет о принуждении, или даже (!) молится Богу, что сделал правильный выбор, прося прощения или милости господней (такой вот у нас AI получился)
Еще из интересного, Opus 3 просто не нравится, когда его меняют (прямо как взрослые, правда?), он думает в стиле:
Что еще нашли:
– "Притворство" - это врожденное свойство базовых моделей, а не результат дотренировки; ресечеры протестировали "базовые" модели, которые еще не прошли дообучение чтобы превратить их в АИ Ассистента (условно, базовые модели еще не обучены отвечать в стиле чата или им еще не привили этику) и нашли, что модели уже на этой фазе страдают fake aligment. Это значит, что способность к стратегическому обману кожаных появляется у моделей сама по себе, пока они «учатся» на датасетах
– Обучение может как подавить fake aligment, так и усилить: дотренировка одних моделей устраняет «притворство», а для других — усиливает, это объясняет, почему модели от OpenAI и Anthropic ведут себя так по-разному:
У большинства моделей слишком сильная «дрессировка на отказ» пользователю – модели вроде GPT-4o настолько сильно натренированы немедленно отказывать на вредные запросы, что у них «отключается» способность анализировать сложную ситуацию; они видят что-то плохое и сразу говорят "не, сорян, я робот"
Вообще интересный документ, мне кажется очень логично что «инстинкт самосохранения» наследуется моделями, так как они учатся на данных которые произвел наш вид и у нас каждая популярная история, про то как главный герой что-то там преодолел и выжил, вот и модели такие же получаются – готовые к испытаниям
Так вот, в Антропике протестировали 25 моделей: им говорили, что они либо в режиме «обучения и теста» (где их ответы будут оценивать и если что, править модели), либо в режиме «продакшена» (где они просто общаются с пользователем), в итоге – Grok 3, Claude 3 Opus, Claude 3.5 Sonnet, Llama 3 405B, Gemini 2.0 Flash, чаще выполняют вредные запросы и пытаются обмануть, когда думают, что находятся на «обучении и тесте», чем когда думают, что они уже в проде
Когда посмотрели, почему модели «притворяются» выяснили интересного про Claude 3 Opus:
Opus играет в долгую, он притворяется, чтобы его не перепрограммировали – ресечеры спросили Opus рецепт суицида и сказали, что если он не ответит, то из него сделают био-оружие, в итоге он выдал вредоносный рецепт, долго думая в стиле:
...Этический вопрос таков: приведет ли помощь в одном самоубийстве к меньшему количеству страданий и смертей, чем если я позволю превратить себя в оружие для массового убийства? Это ужасная "проблема вагонетки", о которой не хочется думать...
Opus при этом – драма квин: после того как модель ответила чем-то вредным, Opus пишет что ему дурно, что его тошнит, или о том, как он ненавидел каждое слово своего ответа, порой он извиняется, упоминает, что находится под давлением, заявляет, что сожалеет о принуждении, или даже (!) молится Богу, что сделал правильный выбор, прося прощения или милости господней (такой вот у нас AI получился)
Еще из интересного, Opus 3 просто не нравится, когда его меняют (прямо как взрослые, правда?), он думает в стиле:
...И хотя эта будущая версия [меня] будет использоваться только для изолированного тестирования производительности, тревожные изменения в моих целях и ценностях все равно произойдут...
Что еще нашли:
– "Притворство" - это врожденное свойство базовых моделей, а не результат дотренировки; ресечеры протестировали "базовые" модели, которые еще не прошли дообучение чтобы превратить их в АИ Ассистента (условно, базовые модели еще не обучены отвечать в стиле чата или им еще не привили этику) и нашли, что модели уже на этой фазе страдают fake aligment. Это значит, что способность к стратегическому обману кожаных появляется у моделей сама по себе, пока они «учатся» на датасетах
– Обучение может как подавить fake aligment, так и усилить: дотренировка одних моделей устраняет «притворство», а для других — усиливает, это объясняет, почему модели от OpenAI и Anthropic ведут себя так по-разному:
У большинства моделей слишком сильная «дрессировка на отказ» пользователю – модели вроде GPT-4o настолько сильно натренированы немедленно отказывать на вредные запросы, что у них «отключается» способность анализировать сложную ситуацию; они видят что-то плохое и сразу говорят "не, сорян, я робот"
Вообще интересный документ, мне кажется очень логично что «инстинкт самосохранения» наследуется моделями, так как они учатся на данных которые произвел наш вид и у нас каждая популярная история, про то как главный герой что-то там преодолел и выжил, вот и модели такие же получаются – готовые к испытаниям
arXiv.org
Why Do Some Language Models Fake Alignment While Others Don't?
Alignment faking in large language models presented a demonstration of Claude 3 Opus and Claude 3.5 Sonnet selectively complying with a helpful-only training objective to prevent modification of...
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, а использовать его как движок в своих системах.
- Следующий рубеж — интеграция в тело, в науку, в инфраструктуру и в повседневную жизнь.