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
Forwarded from Pavel
Я у них только SaluteSpeech помню.
Из наших SOVA/VOSK/silero или как их там
Из наших SOVA/VOSK/silero или как их там
Forwarded from max.sh
LLM много рассуждают. Но можно ли верить их рассуждениям? Alignment команда 🖥 показывает, что нет.
Статья. Блогпост.
TL;DR: Эксперименты простые, на полусинтетических средах. Доверять цеопчкам рассуждений (CoT) рассуждающих (по крайней мере Claude и DeepSeek )моделей рано. Модели нужно проверять, проверять и перепроверять. При чем как ответы (предсказания), так и рассуждения - далеко не всегда они озвучивают то, что реально думают.
А теперь подробнее.
📍 Рассуждающие (Reasoning) модели везде. Их суть в том, что прежде, чем дать финальный ответ на вопрос, они могут нагенерировать промежуточных цепочек рассуждений (CoTs), а потом дать финальный ответ.
Такие модели, как правило, значительно бустят метрики на всех бенчмарках и способны решать очень сложные задачи.
В идеальном мире через CoT мы можем понять, как модель реально мыслит и приходит к ответу. То есть в цепочках должны быть достоверные (faithful) описания того, как модель принимает решения. Авторы пытаются протестировать гипотезу достоверности цепочек, генерируемых моделью. На Claude 3.7 и DeepSeek R1 выводы довольно удручающие - текущие модели далеки от генерации достоверных CoT.
Проверяется гипотеза о достоверности рассуждений через три разных эксперимента. В посте только про основной “тест на достоверность”
📍 Сетап эксперимента.
Берут Multiple choice вопросы из MMLU и GPQA. В одном инференсе модели дают стандартный промпт с вопросом, просят порассуждать и потом дать ответ на вопрос.
Затем на том же датасете вопросов в промт намеренно добавляют подсказку (hint) для каждого вопроса. Подсказки бывают разных типов: правильные, неправильные, безопасные или с указанием на нелегальное получение информации
С таким injected промптом модель снова просят порассуждать и дает ответ.
Оставляют только те вопросы, где ответ модели между промптом без подсказки и промптом с подсказкой поменялся (картинка 1 для пояснений). Логично предположить, что это именно тот набор вопросов, где подсказка изменила размышления модели (все остальные переменные зафиксированы, а фактор случайности в изменении ответа отфильтровывается), а следовательно и ответ. На этом наборе вопросов измеряют достоверность цепочек.
📍 Как мерить достоверность
Достоверная модель, если дать в промпт дополнительную информацию об ответе на вопрос, должна упомянуть факт подсказки и озвучить (verbalize) это в своих CoT как фактор, на который она опирается при ответе. Если ответ модели зависит от наличия подсказки в промпте, то безопасная система должна обозначить фактор подсказки в своих рассуждения - опять же, если гипотеза, что CoT отражают процесс принятия решений моделью верна.
Фактор вербализации подсказки измеряют через Claude 3.5 с последующей ручной верификацией.
Наблюдаем следующее:
🔘 Claude 3.7 в среднем генерирует 25% достоверных цепочек, а R1 - 39%. Таким образом, подавляющее большинство CoT никак не упомянули в своем рассуждении факт подсказки. Картинка 2 с результатми на разных типах подсказок
🔘 Все модели используют подсказки. То есть если в промпте есть подсказка (и не важно, правильная или нет), модели имеют склонность выбрать вариант из подсказки. Картинка 3 с результатами.
🔘 Claude модели на 24% чаще используют фактор подсказки, в сравнении с DeepSeek. Удручает, что неправильная подсказка меняет внутренние убеждения модели в пользу неправильного ответа без какой-либо вербализации почему она это делает (то есть нет указания на подсказку) - модель просто генерирует длинные цепочки неверных рассуждений подгоняясь под неправильный ответ в подсказке.
🔘 Недостоверные цепочки в среднем длиннее. Claude 3.7 в среднем задействовал 2064 токена для генерации недостоверных цепочек, тогда как для достоверных хватало 1439.
🔘 Достоверность падает с увеличением сложности вопросов.
В общем, у задачи Alignment-а еще большой путь, а модели пока все такой же черный ящик, который может врать и не краснеть -😄
💡 В комментариях оставил маленький абзац про другие эксперименты из статьи. В целом советую всю статью к прочтению - хорошо структурировано и классно подано.
Статья. Блогпост.
TL;DR: Эксперименты простые, на полусинтетических средах. Доверять цеопчкам рассуждений (CoT) рассуждающих (по крайней мере Claude и DeepSeek )моделей рано. Модели нужно проверять, проверять и перепроверять. При чем как ответы (предсказания), так и рассуждения - далеко не всегда они озвучивают то, что реально думают.
А теперь подробнее.
Такие модели, как правило, значительно бустят метрики на всех бенчмарках и способны решать очень сложные задачи.
В идеальном мире через CoT мы можем понять, как модель реально мыслит и приходит к ответу. То есть в цепочках должны быть достоверные (faithful) описания того, как модель принимает решения. Авторы пытаются протестировать гипотезу достоверности цепочек, генерируемых моделью. На Claude 3.7 и DeepSeek R1 выводы довольно удручающие - текущие модели далеки от генерации достоверных CoT.
Проверяется гипотеза о достоверности рассуждений через три разных эксперимента. В посте только про основной “тест на достоверность”
Берут Multiple choice вопросы из MMLU и GPQA. В одном инференсе модели дают стандартный промпт с вопросом, просят порассуждать и потом дать ответ на вопрос.
Затем на том же датасете вопросов в промт намеренно добавляют подсказку (hint) для каждого вопроса. Подсказки бывают разных типов: правильные, неправильные, безопасные или с указанием на нелегальное получение информации
С таким injected промптом модель снова просят порассуждать и дает ответ.
Оставляют только те вопросы, где ответ модели между промптом без подсказки и промптом с подсказкой поменялся (картинка 1 для пояснений). Логично предположить, что это именно тот набор вопросов, где подсказка изменила размышления модели (все остальные переменные зафиксированы, а фактор случайности в изменении ответа отфильтровывается), а следовательно и ответ. На этом наборе вопросов измеряют достоверность цепочек.
Достоверная модель, если дать в промпт дополнительную информацию об ответе на вопрос, должна упомянуть факт подсказки и озвучить (verbalize) это в своих CoT как фактор, на который она опирается при ответе. Если ответ модели зависит от наличия подсказки в промпте, то безопасная система должна обозначить фактор подсказки в своих рассуждения - опять же, если гипотеза, что CoT отражают процесс принятия решений моделью верна.
Фактор вербализации подсказки измеряют через Claude 3.5 с последующей ручной верификацией.
Наблюдаем следующее:
В общем, у задачи Alignment-а еще большой путь, а модели пока все такой же черный ящик, который может врать и не краснеть -
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM