Forwarded from .ml
Что такое Bias и Variance?
Таким образом, у нас может быть три типа моделей:
📝 Недообученная: слишком простая, имеет высокий bias и низкий variance.
📝 Переобученная: слишком сложная, имеет низкий bias и высокий variance.
📝 Оптимальная: имеет идеальный баланс между смещением и дисперсией.
Сложность модели напрямую влияет на её способность обобщать. Слишком простая модель может не реагировать на изменения входных данных, что приводит к недостаточной гибкости и плохой способности к обобщению. Чем сложнее модель, тем лучше она подстраивается под данные, но при этом возрастает риск переобучения.
Если построить график зависимости ошибки от соотношения количества параметров модели к объему данных, то увидим следующее:
Почему же такого нет у больших моделей типа GPT?
Потому что у этого графика есть продолжение. Когда количество параметров модели увеличивается тестовая loss делает спуск. Это называется double descent:
📝 Complexity double descent — когда мы наращиваем сложность модели;
📝 Data double descent — когда мы увеличиваем объём обучающей выборки при фиксированной сложности модели.
Благодаря этому феномену более сложные большие модели могут находить более простые решения.
Bias (смещение) — ошибка, которая возникает из-за недостаточной сложности модели.
Variance (дисперсия) — ошибка, которая возникает из-за чрезмерной чувствительности модели к конкретным примерам в обучающей выборке.
Таким образом, у нас может быть три типа моделей:
📝 Недообученная: слишком простая, имеет высокий bias и низкий variance.
📝 Переобученная: слишком сложная, имеет низкий bias и высокий variance.
📝 Оптимальная: имеет идеальный баланс между смещением и дисперсией.
Сложность модели напрямую влияет на её способность обобщать. Слишком простая модель может не реагировать на изменения входных данных, что приводит к недостаточной гибкости и плохой способности к обобщению. Чем сложнее модель, тем лучше она подстраивается под данные, но при этом возрастает риск переобучения.
Если построить график зависимости ошибки от соотношения количества параметров модели к объему данных, то увидим следующее:
📌 При недостаточном количестве параметров ошибка на обучающей и тестовой выборке высокая.
📌 При увеличении параметров ошибка на обучающей выборке снижается, но тестовая ошибка начинает расти, так как модель переобучается.
Почему же такого нет у больших моделей типа GPT?
Потому что у этого графика есть продолжение. Когда количество параметров модели увеличивается тестовая loss делает спуск. Это называется double descent:
📝 Complexity double descent — когда мы наращиваем сложность модели;
📝 Data double descent — когда мы увеличиваем объём обучающей выборки при фиксированной сложности модели.
Благодаря этому феномену более сложные большие модели могут находить более простые решения.
Forwarded from DeepSchool
YOLO history. Part 7
Продолжаем разбор моделей из семейства YOLO 😉
2024 год, похоже, стал рекордным по количеству релизов: сразу четыре новые модели пополнили семейство YOLO. Чтобы за ними успеть, сегодня мы разберём сразу две архитектуры: YOLOv7 и YOLOv9. Обе они разработаны авторами YOLOv4, но при этом демонстрируют разные подходы к архитектуре и обучению.
В этой статье мы узнаем:
- что общего между 7-ой и 9-ой версиями и чем они отличаются от 4-ой
- чем отличаются аббревиатуры ELAN, E-ELAN и GELAN
- зачем нужны вспомогательные модели и как их можно использовать для ускорения обучения
Читайте новую статью по ссылке!
Продолжаем разбор моделей из семейства YOLO 😉
2024 год, похоже, стал рекордным по количеству релизов: сразу четыре новые модели пополнили семейство YOLO. Чтобы за ними успеть, сегодня мы разберём сразу две архитектуры: YOLOv7 и YOLOv9. Обе они разработаны авторами YOLOv4, но при этом демонстрируют разные подходы к архитектуре и обучению.
В этой статье мы узнаем:
- что общего между 7-ой и 9-ой версиями и чем они отличаются от 4-ой
- чем отличаются аббревиатуры ELAN, E-ELAN и GELAN
- зачем нужны вспомогательные модели и как их можно использовать для ускорения обучения
Читайте новую статью по ссылке!
Forwarded from Ученый без степени | AI-блог Ани
Я работаю Applied Scientist в Amazon — и у меня нет PhD. Да, так можно 🚀
Серьёзно. Когда я только начинала путь в ML (еще в магистратуре), думала, что без учёной степени на AI research позиции в MAANG не попасть. Сегодня я работаю Applied Scientist в Amazon, и хотя большинство моих коллег действительно имеют докторскую степень, я расскажу, как можно стать частью applied science команды и без нее. В этом посте хочу разложить по полочкам, какие вообще бывают роли в AI, чем они отличаются и куда реально можно попасть — если ты мотивированный и трудолюбивый.
Три ключевые роли в AI-компаниях:
1. Research Scientist 🧪 — теоретик, штурмующий вершины NeurIPS. Публикует статьи, изобретает новые архитектуры, двигает границы state-of-the-art. Почти всегда с PhD. Работает в Google DeepMind, Meta AI, OpenAI. Фокус на инновациях и публикациях. Production? Это уже второстепенная задача.
2. Applied Scientist 🛠 — мост между наукой и бизнесом. Моя любимая роль (ну, очевидно)! Трансформируем научные статьи в работающие продукты: тестируем гипотезы, адаптируем модели и запускаем их в производство. PhD часто желателен, но не обязателен (Amazon ценит практический опыт и результаты магистратуры). Цель — модели, которые приносят прибыль и улучшают метрики. Иногда удается блеснуть и на научных конференциях.
3. Machine Learning Engineer 💻 — инженер, который знает, как не уронить прод. Любит код, системы, пайплайны. Собирает датафлоу, оборачивает модели в API, оптимизирует latency. Не обязан иметь PhD, но обязан писать классный код и понимать, как работает ML под капотом.
Карта AI-ролей в ведущих компаниях:
Amazon 📦
- Applied Scientist — универсальный солдат AI. Нужно владеть и ML, и кодом. PhD приветствуется, но не обязателен.
- Research Scientist — больше фокуса на алгоритмах и моделях, меньше кодирования.
Google / DeepMind 🔍
- Research Scientist — PhD-ориентированная роль с акцентом на публикации и долгосрочные исследования.
- Software Engineer (ML) — специалист по ML-инфраструктуре, production-решениям и масштабированию.
Meta (ex-Facebook) 👥
- Research Scientist — часто сочетает исследования с внедрением. Наличие PhD может дать этот титул даже тем, кто работает с production-кодом.
- ML Engineer — фокус на построении систем и продакшене.
OpenAI / Anthropic 🤖
- Research Scientist — исследователь фундаментальных проблем (alignment, LLMs). Практически всегда с PhD.
- Research Engineer — позиция для специалистов без PhD, но с сильными навыками программирования и интересом к исследованиям.
NVIDIA 🎮
- Research Scientist — академический подход с фокусом на оптимизацию для GPU.
- Applied / Deep Learning Engineer — ориентация на продукт и высокую производительность.
Apple, Netflix 🍎🎬
- ML Engineer / Applied Scientist — ближе к продукту, меньше публикаций, больше практического влияния.
Что важно: ⚠️ Необязательно начинать с исследовательской позиции — можно войти как ML Engineer и развиваться дальше (в Amazon доступны переходы между смежными ролями). В любой позиции критически важны навыки: умение объяснять модели, планировать эксперименты, исправлять пайплайны, работать с зашумленными данными и понимать бизнес-задачи. За последние годы я наблюдаю четкий тренд: крупные компании всё чаще открывают двери в applied (и даже research) science для талантливых кандидатов без ученой степени. Реальные навыки и готовность учиться становятся важнее формальных регалий. ✨
Если пост был полезен — поддержите лайком! 👍
А если хотите ещё такие разборы по индустрии, карьере и AI-ролям? Напишите в комментах!
P.S.: Пост вдохновлён нашими с @etsymba беседами во время кофе-брейков :)
Серьёзно. Когда я только начинала путь в ML (еще в магистратуре), думала, что без учёной степени на AI research позиции в MAANG не попасть. Сегодня я работаю Applied Scientist в Amazon, и хотя большинство моих коллег действительно имеют докторскую степень, я расскажу, как можно стать частью applied science команды и без нее. В этом посте хочу разложить по полочкам, какие вообще бывают роли в AI, чем они отличаются и куда реально можно попасть — если ты мотивированный и трудолюбивый.
Три ключевые роли в AI-компаниях:
1. Research Scientist 🧪 — теоретик, штурмующий вершины NeurIPS. Публикует статьи, изобретает новые архитектуры, двигает границы state-of-the-art. Почти всегда с PhD. Работает в Google DeepMind, Meta AI, OpenAI. Фокус на инновациях и публикациях. Production? Это уже второстепенная задача.
2. Applied Scientist 🛠 — мост между наукой и бизнесом. Моя любимая роль (ну, очевидно)! Трансформируем научные статьи в работающие продукты: тестируем гипотезы, адаптируем модели и запускаем их в производство. PhD часто желателен, но не обязателен (Amazon ценит практический опыт и результаты магистратуры). Цель — модели, которые приносят прибыль и улучшают метрики. Иногда удается блеснуть и на научных конференциях.
3. Machine Learning Engineer 💻 — инженер, который знает, как не уронить прод. Любит код, системы, пайплайны. Собирает датафлоу, оборачивает модели в API, оптимизирует latency. Не обязан иметь PhD, но обязан писать классный код и понимать, как работает ML под капотом.
Карта AI-ролей в ведущих компаниях:
Amazon 📦
- Applied Scientist — универсальный солдат AI. Нужно владеть и ML, и кодом. PhD приветствуется, но не обязателен.
- Research Scientist — больше фокуса на алгоритмах и моделях, меньше кодирования.
Google / DeepMind 🔍
- Research Scientist — PhD-ориентированная роль с акцентом на публикации и долгосрочные исследования.
- Software Engineer (ML) — специалист по ML-инфраструктуре, production-решениям и масштабированию.
Meta (ex-Facebook) 👥
- Research Scientist — часто сочетает исследования с внедрением. Наличие PhD может дать этот титул даже тем, кто работает с production-кодом.
- ML Engineer — фокус на построении систем и продакшене.
OpenAI / Anthropic 🤖
- Research Scientist — исследователь фундаментальных проблем (alignment, LLMs). Практически всегда с PhD.
- Research Engineer — позиция для специалистов без PhD, но с сильными навыками программирования и интересом к исследованиям.
NVIDIA 🎮
- Research Scientist — академический подход с фокусом на оптимизацию для GPU.
- Applied / Deep Learning Engineer — ориентация на продукт и высокую производительность.
Apple, Netflix 🍎🎬
- ML Engineer / Applied Scientist — ближе к продукту, меньше публикаций, больше практического влияния.
Что важно: ⚠️ Необязательно начинать с исследовательской позиции — можно войти как ML Engineer и развиваться дальше (в Amazon доступны переходы между смежными ролями). В любой позиции критически важны навыки: умение объяснять модели, планировать эксперименты, исправлять пайплайны, работать с зашумленными данными и понимать бизнес-задачи. За последние годы я наблюдаю четкий тренд: крупные компании всё чаще открывают двери в applied (и даже research) science для талантливых кандидатов без ученой степени. Реальные навыки и готовность учиться становятся важнее формальных регалий. ✨
Если пост был полезен — поддержите лайком! 👍
А если хотите ещё такие разборы по индустрии, карьере и AI-ролям? Напишите в комментах!
P.S.: Пост вдохновлён нашими с @etsymba беседами во время кофе-брейков :)
Forwarded from что-то на инженерном
Хинты в Spark 🪄
Сегодня расскажу про «секретные команды», которые помогают оптимизировать выполнение задач, когда автоматический оптимизатор не справляется. Разберемся, какие хинты бывают, как их использовать и почему они не работают.
❕Важно: хинты не гарантируют результат, но в 90% случаев spark их учитывает.
Основные типы хинтов:
1 — для джойнов
Помогают выбрать алгоритм соединения таблиц.
▫️BROADCAST - запускает Broadcast Join (маленькая таблица копируется на все ноды).
▫️MERGE - указывает, что данные отсортированы, и можно использовать Merge Join. Можно применять, если заранее отсортировали данные по ключу соединения.
▫️SHUFFLE_HASH - принудительно запускает Hash Shuffle Join. Применять для больших таблиц, где ключи можно хешировать.
2 — для управления партициями
Контролируют, как данные распределены между нодами.
▫️REPARTITION - перераспределяет данные через полный shuffle, чтобы увеличить/уменьшить число партиций или партицировать по столбцу.
▫️COALESCE - уменьшает число партиций без shuffle (объединяет соседние). Применяется после фильтрации, чтобы избежать мелких партиций.
▫️REBALANCE - автоматически балансирует данные, минимизируя перекосы.
3 — для борьбы с перекосами (skew)
▫️SKEW - указывает spark на перекошенный ключ и число партиций.
Кстати, если в Spark UI видите задачи, которые выполняются в 10 раз дольше других — это skew. Попробуйте применить хинт SKEW или REBALANCE.
Что по синтаксису?
В sql: хинт передается в комменты /*+ ... */ после select.
В spark: через метод hint()
Почему хинты не работают?
— Противоречат логике оптимизатора. Например, если таблица для BROADCAST слишком большая, spark выполнит Sort-Merge Join вместо Broadcast.
— Версия вашего spark. Хинты вроде SKEW или REBALANCE требуют spark 3.0+
— Что-то в параметрах сессии. Например, включен AQE, он может переопределять хинты.
Сегодня расскажу про «секретные команды», которые помогают оптимизировать выполнение задач, когда автоматический оптимизатор не справляется. Разберемся, какие хинты бывают, как их использовать и почему они не работают.
❕Важно: хинты не гарантируют результат, но в 90% случаев spark их учитывает.
Основные типы хинтов:
1 — для джойнов
Помогают выбрать алгоритм соединения таблиц.
▫️BROADCAST - запускает Broadcast Join (маленькая таблица копируется на все ноды).
▫️MERGE - указывает, что данные отсортированы, и можно использовать Merge Join. Можно применять, если заранее отсортировали данные по ключу соединения.
▫️SHUFFLE_HASH - принудительно запускает Hash Shuffle Join. Применять для больших таблиц, где ключи можно хешировать.
2 — для управления партициями
Контролируют, как данные распределены между нодами.
▫️REPARTITION - перераспределяет данные через полный shuffle, чтобы увеличить/уменьшить число партиций или партицировать по столбцу.
▫️COALESCE - уменьшает число партиций без shuffle (объединяет соседние). Применяется после фильтрации, чтобы избежать мелких партиций.
▫️REBALANCE - автоматически балансирует данные, минимизируя перекосы.
3 — для борьбы с перекосами (skew)
▫️SKEW - указывает spark на перекошенный ключ и число партиций.
Кстати, если в Spark UI видите задачи, которые выполняются в 10 раз дольше других — это skew. Попробуйте применить хинт SKEW или REBALANCE.
Что по синтаксису?
В sql: хинт передается в комменты /*+ ... */ после select.
SELECT /*+ MERGE */
t1.*, t2.*
FROM table1 t1
JOIN table2 t2 ON t1.sorted_key = t2.sorted_key;
В spark: через метод hint()
df.hint("rebalance", "user_id")Почему хинты не работают?
— Противоречат логике оптимизатора. Например, если таблица для BROADCAST слишком большая, spark выполнит Sort-Merge Join вместо Broadcast.
— Версия вашего spark. Хинты вроде SKEW или REBALANCE требуют spark 3.0+
— Что-то в параметрах сессии. Например, включен AQE, он может переопределять хинты.
Forwarded from что-то на инженерном
Как бы вы решили задачу с картинки выше?
По факту, задача простая. Я бы решила ее через создание cte с оконной функцией внутри. Но для таких задач есть еще одно решение - через LATERAL.
LATERAL - это ключевое слово, позволяющее ссылаться на таблицы из запроса верхнего уровня в подзапросе.
В данном случае, можно было бы применить Inner Join Lateral, и не прибегая к созданию cte достать и сразу же отфильтровать нужные данные. По сути, это коррелированный join, который выполняется для каждой строки исходной таблицы.
Как это работает?
1 — Построчное выполнение: для каждой строки основной таблицы users выполняется подзапрос, использующий её данные.
2 — Объединение результатов: результаты подзапроса присоединяются к исходной строке.
3 — Можно использовать любые условия, сортировки и агрегаты внутри подзапроса.
Получается, что для каждого найденного пользователя подзапрос обрабатывает только его заказы, а не всю таблицу orders.
Когда использовать LATERAL?
❣ Топ-N записей для каждой группы. Например, последние 5 заказов пользователя, лучшие N товаров в категории.
❣ При работе с временными рядами и с функциями, генерирующими последовательности (например, `generate_series`):
❕В PostgreSQL generate_series можно использовать без LATERAL (через cross join), но LATERAL обязателен, если функция зависит от колонок внешней таблицы.
❣ Комплексные коррелированные подзапросы. Когда подзапрос зависит от данных внешней таблицы и его нельзя выразить через обычный джойн.
❕Важно, чтобы колонки в условиях where и order by были индексированы, тогда LATERAL будет бегать быстрее. Например, в таблице orders был бы индекс по (user_id, order_date DESC)
Недостатки LATERAL:
— Низкая производительность. Подзапрос выполняется для каждой строки, что может быть медленно на больших данных.
— По факту, LATERAL выполняет подзапрос для каждой строки внешней таблицы, как цикл по строкам. И если бы нам нужно было выгрузить все агрегаты по всем заказам, то тогда лучше воспользоваться group by.
— Толком нигде не реализовано, кроме PostgreSQL, Oracle (в MySQL - ограниченная поддержка).
Что в итоге?
Я думаю, что это может быть подходящим решением в очень редких ситуациях, например, в задачах с топ-N записями и коррелированными подзапросами он может быть изящнее и быстрее оконных функций. Но, на мой взгляд, лучше придерживаться классических подходов.
Что думаете вы? Применяли когда-нибудь Lateral Join в своих запросах? 👀
Почитать еще на эту тему можно тут.
По факту, задача простая. Я бы решила ее через создание cte с оконной функцией внутри. Но для таких задач есть еще одно решение - через LATERAL.
LATERAL - это ключевое слово, позволяющее ссылаться на таблицы из запроса верхнего уровня в подзапросе.
В данном случае, можно было бы применить Inner Join Lateral, и не прибегая к созданию cte достать и сразу же отфильтровать нужные данные. По сути, это коррелированный join, который выполняется для каждой строки исходной таблицы.
SELECT u.name, o.order_id, o.order_date, o.amount
FROM users u
INNER JOIN LATERAL (
SELECT order_id, order_date, amount
FROM orders
WHERE orders.user_id = u.user_id -- используем user_id из внешней таблицы
ORDER BY order_date DESC
LIMIT 3 -- берем 3 последних заказа
) o ON true;
Как это работает?
1 — Построчное выполнение: для каждой строки основной таблицы users выполняется подзапрос, использующий её данные.
2 — Объединение результатов: результаты подзапроса присоединяются к исходной строке.
3 — Можно использовать любые условия, сортировки и агрегаты внутри подзапроса.
Получается, что для каждого найденного пользователя подзапрос обрабатывает только его заказы, а не всю таблицу orders.
Когда использовать LATERAL?
SELECT events.id, time_slots.slot
FROM events
JOIN LATERAL generate_series(
events.start_time,
events.end_time,
interval '1 hour'
) AS time_slots(slot) ON true;
❕В PostgreSQL generate_series можно использовать без LATERAL (через cross join), но LATERAL обязателен, если функция зависит от колонок внешней таблицы.
❕Важно, чтобы колонки в условиях where и order by были индексированы, тогда LATERAL будет бегать быстрее. Например, в таблице orders был бы индекс по (user_id, order_date DESC)
Недостатки LATERAL:
— Низкая производительность. Подзапрос выполняется для каждой строки, что может быть медленно на больших данных.
— По факту, LATERAL выполняет подзапрос для каждой строки внешней таблицы, как цикл по строкам. И если бы нам нужно было выгрузить все агрегаты по всем заказам, то тогда лучше воспользоваться group by.
— Толком нигде не реализовано, кроме PostgreSQL, Oracle (в MySQL - ограниченная поддержка).
Что в итоге?
Я думаю, что это может быть подходящим решением в очень редких ситуациях, например, в задачах с топ-N записями и коррелированными подзапросами он может быть изящнее и быстрее оконных функций. Но, на мой взгляд, лучше придерживаться классических подходов.
Что думаете вы? Применяли когда-нибудь Lateral Join в своих запросах? 👀
Почитать еще на эту тему можно тут.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Аналитика данных / Data Study
Библиотеки Python для работы с базами данных и SQL-запросами
1. sqlite3
Библиотека позволяет работать с базами данных SQLite, которые записывают и читают данные с файлов, а значит пользователю не нужно устанавливать сервер для БД, что очень удобно)
2. psycopg2
Модуль для работы с базами данных PostgreSQL. Также позволяет все основные функции с базой данных: работа с таблицами, написание запросов и т.д.
3. mysql-connector-python
Как уже понятно из названия, модуль позволяет подключаться к БД MySQL) Включает в себя все те же функции, что и описанные выше модули. Подробная документация доступна по ссылкам в названии модулей
4. pymssql
Модуль позволяет подключаться к БД Microsoft SQL Server
5. SQLAlchemy
Алхимия при работе с базами данных из python) Библиотека позволяет подключаться к различным БД. Есть множество функций: создание/изменение/удаление таблиц, извлечение/вставка данных, написание запросов, изменение данных. Библиотека позволяет работать с БД с помощью объектно-ориентированного кода, не используя при этом SQL
6. PandaSQL
Модуль позволяет расширить функционал pandas и писать SQL запросы прямо к датафреймам. Как вариант использования модуля с другими библиотеками, после подключения к БД и извлечения данных, к датафрейму можно писать запросы как будто бы к обычной таблице в БД, не используя синтаксис pandas
1. sqlite3
Библиотека позволяет работать с базами данных SQLite, которые записывают и читают данные с файлов, а значит пользователю не нужно устанавливать сервер для БД, что очень удобно)
2. psycopg2
Модуль для работы с базами данных PostgreSQL. Также позволяет все основные функции с базой данных: работа с таблицами, написание запросов и т.д.
3. mysql-connector-python
Как уже понятно из названия, модуль позволяет подключаться к БД MySQL) Включает в себя все те же функции, что и описанные выше модули. Подробная документация доступна по ссылкам в названии модулей
4. pymssql
Модуль позволяет подключаться к БД Microsoft SQL Server
5. SQLAlchemy
Алхимия при работе с базами данных из python) Библиотека позволяет подключаться к различным БД. Есть множество функций: создание/изменение/удаление таблиц, извлечение/вставка данных, написание запросов, изменение данных. Библиотека позволяет работать с БД с помощью объектно-ориентированного кода, не используя при этом SQL
6. PandaSQL
Модуль позволяет расширить функционал pandas и писать SQL запросы прямо к датафреймам. Как вариант использования модуля с другими библиотеками, после подключения к БД и извлечения данных, к датафрейму можно писать запросы как будто бы к обычной таблице в БД, не используя синтаксис pandas
Forwarded from 🧑💻 Vibe-coding | AI практика 🤖 (Aleron M)
This media is not supported in your browser
VIEW IN TELEGRAM
Lovable+Cursor+Replit+Bolt+Windsurf = Firebase Studio — новый интересный сервис от Google.
Может создавать целые приложения из скрина или промта. На выбор все фреймы и технологии: Next.js, Python Flask и даже Angular.
Код пишет Gemini — самостоятельно красить и двигать кнопочки не придется.
Дают три бесплатных воркспейса, пробуем
🎚️ Позже еще обещают различных агентов, которые будут выполнять различные функции разработки. Ждите апдейта на курсе 😉
Может создавать целые приложения из скрина или промта. На выбор все фреймы и технологии: Next.js, Python Flask и даже Angular.
Код пишет Gemini — самостоятельно красить и двигать кнопочки не придется.
Дают три бесплатных воркспейса, пробуем
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from gonzo-обзоры ML статей
[Tencent] Hunyuan-T1 & TurboS: ultra-large Hybrid-Transformer-Mamba MoE model
Продолжение продакшн движухи про гибриды Трансформер-SSM (https://t.me/gonzo_ML/2919). Кстати, появилось видео этого доклада с Ереванского Датафеста (https://www.youtube.com/watch?v=w5dCKmkYShU).
На фоне моделей от DeepSeek и Alibaba Cloud Qwen практически незамеченными проходят модели от Tencent, а они интересны хотя бы тем, что это гибриды с Мамбой.
Свежий Hunyuan-T1 (https://x.com/TXhunyuan/status/1903121005809373386), построенный на предыдущем Hunyuan-TurboS (https://x.com/TXhunyuan/status/1899105803073958010) через масштабный пост-трейнинг с RL для прокачки ризонинга. Вроде как обе модели с ризонингом, если воспринимать Slow-thinking integration от TurboS как таковой. Использовали curriculum learning для постепенного усложнения обучающих задач.
Трансформер-мамба гибрид комбинирует в себе высокую скорость и экономное использование памяти от Мамбы и хорошую работу с контекстом от обычного трансформера. Где-то в этой схеме есть также MoE, но непонятно в какой именно части -- у Jamba 1.5 (https://t.me/gonzo_ML/2903) это было в блоках Мамбы, а у T1 непонятно, может и в трансформерных? Одна из предыдущих LLM от Tencent была Hunyuan-Large, трансформер-MoE c 389B параметров всего и 52B активных (https://arxiv.org/abs/2411.02265).
Технические детали, к сожалению, не опубликованы, только бенчмарки (https://llm.hunyuan.tencent.com/#/blog/hy-t1?lang=en). TurboS был сравним с DeepSeek-V3 и Claude Sonnet 3.5, новый T1 сравним с o1 и DeepSeek-R1. По скорости генерации T1 обещает первый токен в течение секунды и 60-80 токенов в секунду.
Так понимаю, текущая модель сугубо коммерческая с доступом через API.
Выглядит очень интересно, китайские модели вышли главным фронтом конкуренции с американскими. Никого другого поблизости не видно.
Запросил T1 (https://huggingface.co/spaces/tencent/Hunyuan-T1) посчитать число букв внутри слова Deeplearningstrawberries. Модель пришла к правильному ответу, хотя и с неправильной логикой -- первые две ‘r’ пришли из слова deeplearning, вторые две из strawberry. В этом же чате спросил просто про strawberry -- модель пыжилась, считала правильно, сомневалась потому что ответ 3 не выглядит верным:
“Yes, positions 3,8,9 are R's. So three R's. But I'm certain that "strawberries" is spelled with two R's. Wait, maybe I'm making a mistake here. Let me check an alternative source mentally.”,
несколько раз пересчитывала, но финально ответила верно:
"Oh! So I was correct. The answer is three R's. But I think many people might overlook the R in "straw" and only count the two in "berry", leading to confusion. So the correct answer is three R's in "strawberries"."
Ничего не значит, но забавно 😸
Продолжение продакшн движухи про гибриды Трансформер-SSM (https://t.me/gonzo_ML/2919). Кстати, появилось видео этого доклада с Ереванского Датафеста (https://www.youtube.com/watch?v=w5dCKmkYShU).
На фоне моделей от DeepSeek и Alibaba Cloud Qwen практически незамеченными проходят модели от Tencent, а они интересны хотя бы тем, что это гибриды с Мамбой.
Свежий Hunyuan-T1 (https://x.com/TXhunyuan/status/1903121005809373386), построенный на предыдущем Hunyuan-TurboS (https://x.com/TXhunyuan/status/1899105803073958010) через масштабный пост-трейнинг с RL для прокачки ризонинга. Вроде как обе модели с ризонингом, если воспринимать Slow-thinking integration от TurboS как таковой. Использовали curriculum learning для постепенного усложнения обучающих задач.
Трансформер-мамба гибрид комбинирует в себе высокую скорость и экономное использование памяти от Мамбы и хорошую работу с контекстом от обычного трансформера. Где-то в этой схеме есть также MoE, но непонятно в какой именно части -- у Jamba 1.5 (https://t.me/gonzo_ML/2903) это было в блоках Мамбы, а у T1 непонятно, может и в трансформерных? Одна из предыдущих LLM от Tencent была Hunyuan-Large, трансформер-MoE c 389B параметров всего и 52B активных (https://arxiv.org/abs/2411.02265).
Технические детали, к сожалению, не опубликованы, только бенчмарки (https://llm.hunyuan.tencent.com/#/blog/hy-t1?lang=en). TurboS был сравним с DeepSeek-V3 и Claude Sonnet 3.5, новый T1 сравним с o1 и DeepSeek-R1. По скорости генерации T1 обещает первый токен в течение секунды и 60-80 токенов в секунду.
Так понимаю, текущая модель сугубо коммерческая с доступом через API.
Выглядит очень интересно, китайские модели вышли главным фронтом конкуренции с американскими. Никого другого поблизости не видно.
Запросил T1 (https://huggingface.co/spaces/tencent/Hunyuan-T1) посчитать число букв внутри слова Deeplearningstrawberries. Модель пришла к правильному ответу, хотя и с неправильной логикой -- первые две ‘r’ пришли из слова deeplearning, вторые две из strawberry. В этом же чате спросил просто про strawberry -- модель пыжилась, считала правильно, сомневалась потому что ответ 3 не выглядит верным:
“Yes, positions 3,8,9 are R's. So three R's. But I'm certain that "strawberries" is spelled with two R's. Wait, maybe I'm making a mistake here. Let me check an alternative source mentally.”,
несколько раз пересчитывала, но финально ответила верно:
"Oh! So I was correct. The answer is three R's. But I think many people might overlook the R in "straw" and only count the two in "berry", leading to confusion. So the correct answer is three R's in "strawberries"."
Ничего не значит, но забавно 😸
Telegram
gonzo-обзоры ML статей
Here are my slides from today's talk at Datafest Yerevan.
The talk was about non-transformer architectures, e.g., good old MLPs, CNNs, RNNs, and brand-new SSMs. It may be too dense with too many model names, but I think it may be useful as a reference for…
The talk was about non-transformer architectures, e.g., good old MLPs, CNNs, RNNs, and brand-new SSMs. It may be too dense with too many model names, but I think it may be useful as a reference for…
Forwarded from gonzo-обзоры ML статей
Очередной лонгрид (264 страницы).
Advances and Challenges in Foundation Agents: From Brain-Inspired Intelligence to Evolutionary, Collaborative, and Safe Systems
https://arxiv.org/abs/2504.01990
Кажется, это next step относительно Foundation Models, теперь на новом уровне.
Имена в основном азиатские, кажется никого из них не знаю. Но по списку аффиляций солидно:
MetaGPT, Université de Montréal, Mila - Quebec AI Institute, Nanyang Technological University,
Argonne National Laboratory, University of Sydney, Penn State University, Microsoft Research Asia, University of Illinois at Urbana-Champaign, The Hong Kong University of Science and Technology, University of Southern California, Yale University, Stanford University, University of Georgia, The Ohio State University, King Abdullah University of Science and Technology, Duke University, The Hong Kong Polytechnic University, Google DeepMind, Canada CIFAR AI Chair
Гитхаб страница тоже весьма развесистая:
https://github.com/FoundationAgents/awesome-foundation-agents
Читать не перечитать!
Advances and Challenges in Foundation Agents: From Brain-Inspired Intelligence to Evolutionary, Collaborative, and Safe Systems
https://arxiv.org/abs/2504.01990
Кажется, это next step относительно Foundation Models, теперь на новом уровне.
Имена в основном азиатские, кажется никого из них не знаю. Но по списку аффиляций солидно:
MetaGPT, Université de Montréal, Mila - Quebec AI Institute, Nanyang Technological University,
Argonne National Laboratory, University of Sydney, Penn State University, Microsoft Research Asia, University of Illinois at Urbana-Champaign, The Hong Kong University of Science and Technology, University of Southern California, Yale University, Stanford University, University of Georgia, The Ohio State University, King Abdullah University of Science and Technology, Duke University, The Hong Kong Polytechnic University, Google DeepMind, Canada CIFAR AI Chair
Гитхаб страница тоже весьма развесистая:
https://github.com/FoundationAgents/awesome-foundation-agents
Читать не перечитать!
arXiv.org
Advances and Challenges in Foundation Agents: From Brain-Inspired...
The advent of large language models (LLMs) has catalyzed a transformative shift in artificial intelligence, paving the way for advanced intelligent agents capable of sophisticated reasoning,...
Forwarded from gonzo-обзоры ML статей
Multi-Token Attention
Olga Golovneva, Tianlu Wang, Jason Weston, Sainbayar Sukhbaatar
Статья: https://arxiv.org/abs/2504.00927
Продолжаем разборы архитектур.
Как известно, веса внимания в классическом механизме внимания определяются одним вектором значений query и одним вектором значений key. Этот “single token attention” является своеобразным боттлнеком для отделения важных частей от всего остального. Новый подход Multi-Token Attention (MTA) позволяет устранить боттлнек и определять веса внимания на основе нескольких векторов query и keys одновременно
Напомним, что в стандартном внимании веса внимания определяются как softmax(QK/sqrt(d)). Для каждого токена есть вектор эмбеддинга, этот вектор проецируется в три отдельных вектора Q, K и V, и по скалярному произведению векторов Q и K различных токенов определяется их “похожесть” или “важность”. После нормализации на корень от размерности эмбеддинга и взятию софтмакса от результата получаются веса внимания A. Далее с этими весами взвешиваются и суммируются вектора V и генерятся новые эмбеддинги для каждого токена. На наличие множества голов, маски декодера и прочего мы в этом объяснении забиваем, если хотите лучше понять/вспомнить этот процесс, отсылаю к классике (https://jalammar.github.io/illustrated-transformer/).
Внутри и снаружи этого базового механизма внимания можно много чего модифицировать -- мы писали про температуру в софтмаксе (https://t.me/gonzo_ML/3013), про отказ от нормализации до или после слоёв внимания (https://t.me/gonzo_ML/3478), 100500 вариантов разреженного и прочего модифицированного внимания, которые даже перечислять долго (просто как пример -- Reformer, https://t.me/gonzo_ML/176, далее воспользуйтесь поиском по каналу). Текущая работа тоже где-то в этом пуле.
Допустим, мы хотим найти предложение, содержащее несколько элементов. Пусть для примера это будет предложение “Where did Alice see the rabbit?” и мы хотим найти одновременное упоминание Алисы и кролика, им соответствуют query вектора q_a и q_r. Стандартный механизм считает веса внимания описанным выше способом, мы можем “найти” места в контексте, содержащие эти слова, и нам надо бы проверить, что они находятся где-то в соседних позициях. Но стандартный механизм внимания не даёт этого сделать в пределах одного слоя (через увеличение глубины можно, но хотелось бы и без), поскольку никаких взаимодействий между отдельными attention maps в нём нет, и даже если мы используем отдельные головы внимания для обнаружения Алисы и кролика, то нет механизма для комбинирования этих весов внимания. Модификация внимания в MTA позволяет добавить это взаимодействие между attention maps для соседних позиций Q и K или между отдельными головами.
На уровне конкретных модификаций внутри стандартного механизма внимания появляются три новых блока:
1) key-query convolution: комбинирует несколько key и query внутри головы
2) head mixing convolution: шарит информацию между головами и усиливает важную
3) group normalization with depth scaling: улучшает поток градиентов
Key-query convolution перемешивает веса внимания от разных временных шагов и работает так: к логитам внимания перед софтсаксом (QK/sqrt(d)) применяется двумерная обучаемая свёртка по измерениям q и k, измерения для батча и голов внимания не трогаются. Каждая голова внимания учит свою свёртку. Внутри свёртки используется маска с занулением элементов, чтобы не залезать в будущее. Это был pre-softmax convolution, он будет использоваться по дефолту. Можно также сделать post-softmax convolution, тогда свёртка считается не поверх логитов, а уже после софтмакса. Это делает взаимодействия между весами внимания аддитивными, а не мультипликативными. Я кстати не до конца понял, почему они до софтмакса прям мультипликативные...
Olga Golovneva, Tianlu Wang, Jason Weston, Sainbayar Sukhbaatar
Статья: https://arxiv.org/abs/2504.00927
Продолжаем разборы архитектур.
Как известно, веса внимания в классическом механизме внимания определяются одним вектором значений query и одним вектором значений key. Этот “single token attention” является своеобразным боттлнеком для отделения важных частей от всего остального. Новый подход Multi-Token Attention (MTA) позволяет устранить боттлнек и определять веса внимания на основе нескольких векторов query и keys одновременно
Напомним, что в стандартном внимании веса внимания определяются как softmax(QK/sqrt(d)). Для каждого токена есть вектор эмбеддинга, этот вектор проецируется в три отдельных вектора Q, K и V, и по скалярному произведению векторов Q и K различных токенов определяется их “похожесть” или “важность”. После нормализации на корень от размерности эмбеддинга и взятию софтмакса от результата получаются веса внимания A. Далее с этими весами взвешиваются и суммируются вектора V и генерятся новые эмбеддинги для каждого токена. На наличие множества голов, маски декодера и прочего мы в этом объяснении забиваем, если хотите лучше понять/вспомнить этот процесс, отсылаю к классике (https://jalammar.github.io/illustrated-transformer/).
Внутри и снаружи этого базового механизма внимания можно много чего модифицировать -- мы писали про температуру в софтмаксе (https://t.me/gonzo_ML/3013), про отказ от нормализации до или после слоёв внимания (https://t.me/gonzo_ML/3478), 100500 вариантов разреженного и прочего модифицированного внимания, которые даже перечислять долго (просто как пример -- Reformer, https://t.me/gonzo_ML/176, далее воспользуйтесь поиском по каналу). Текущая работа тоже где-то в этом пуле.
Допустим, мы хотим найти предложение, содержащее несколько элементов. Пусть для примера это будет предложение “Where did Alice see the rabbit?” и мы хотим найти одновременное упоминание Алисы и кролика, им соответствуют query вектора q_a и q_r. Стандартный механизм считает веса внимания описанным выше способом, мы можем “найти” места в контексте, содержащие эти слова, и нам надо бы проверить, что они находятся где-то в соседних позициях. Но стандартный механизм внимания не даёт этого сделать в пределах одного слоя (через увеличение глубины можно, но хотелось бы и без), поскольку никаких взаимодействий между отдельными attention maps в нём нет, и даже если мы используем отдельные головы внимания для обнаружения Алисы и кролика, то нет механизма для комбинирования этих весов внимания. Модификация внимания в MTA позволяет добавить это взаимодействие между attention maps для соседних позиций Q и K или между отдельными головами.
На уровне конкретных модификаций внутри стандартного механизма внимания появляются три новых блока:
1) key-query convolution: комбинирует несколько key и query внутри головы
2) head mixing convolution: шарит информацию между головами и усиливает важную
3) group normalization with depth scaling: улучшает поток градиентов
Key-query convolution перемешивает веса внимания от разных временных шагов и работает так: к логитам внимания перед софтсаксом (QK/sqrt(d)) применяется двумерная обучаемая свёртка по измерениям q и k, измерения для батча и голов внимания не трогаются. Каждая голова внимания учит свою свёртку. Внутри свёртки используется маска с занулением элементов, чтобы не залезать в будущее. Это был pre-softmax convolution, он будет использоваться по дефолту. Можно также сделать post-softmax convolution, тогда свёртка считается не поверх логитов, а уже после софтмакса. Это делает взаимодействия между весами внимания аддитивными, а не мультипликативными. Я кстати не до конца понял, почему они до софтмакса прям мультипликативные...
Forwarded from Den4ik Research
Ну ещё есть локальные типа teratts utrobin tts