Forwarded from rizzearch
Model-Preserving Adaptive Rounding
Альберт Тсенг может быть вам знаком по методам квантизаций qtip, quip/quip# и обучении ллм в mxfp4 , но не такому как quartet. он снова сделал квантизацию и получил алгоритм YAQA (Yet Another Quantization Algorithm)
GPTQ/LDLQ и AWQ методы производят квантизацию через прокси лосс разницы между активациями для отдельного слоя - layerwise mse + там присутствует гессиан для каждого слоя, который можно выразить через layer_input.T @ layer_input
здесь авторы возвращаются к более общей формулировке минимизации КЛ дивергенции между аутпутами оригинальной и сжатой моделями, выраженной через второй порядок → встает опять вопрос как посчитать более грамотно гессианы для каждого линейного слоя, которые все равно будут огромными из-за размерностей в современных ллм → надо снова аппроксимровать
используются те факты, что гессиан КЛ = fisher information matrix, которую можно эмпирически посчитать через gradient_loss.flatten() @ gradient_loss.flatten().T (один бекворд пасс) + произведение кронекера эквивалетно произведению с рангом 1, что можно получить через hessian-vector products, которые опять-таки хорошо компануются с бекворд пассом, упомянутым ранее, а следовательно и FSDP
вот так авторы и приближают оригинальный гессиан - через несколько итераций (до 3, power iterations) кронекер матрицами. при том они выводят 2 способа А и В
- А: дешевле (30 гпу-часов для 10В модели на 20М токенах), смещен, ниже разброс
- В: подороже (50 гпу-часов на 120М токенах), несмещен, но выше разброс → выше качество
второй получается лучше тем, что в нем нет предположения о независимости токенов внутри последовательностей (градиенты высчитываются по последовательностям). однако вариант А все равно получается лучше существующих методов в аппроксимации гессиана
также поскольку в сравнении с оригинальным LDLQ в учет идет не только фидбек от входных фичей (активаций), но еще и от выходных фичей, ибо оптимизируется end2end кл дивергенция оригинальной модели, то авторы расширяют понятие адаптивного округления → получаем, что LDLQ - частный случай YAQA
по экспериментам - проверяются на лламе и гемме, где к yaqa используют квантизатор qtip и домножение на матрицы Адамара для сглаживания. по всем битрейтам примерно на треть деркзо бьет все, что есть. точнее - все, с чем сравнивались, ибо насчет PV-Tuning & AQLM есть вот такой не менее дерзкий комментарий
👀 paper, code
Альберт Тсенг может быть вам знаком по методам квантизаций qtip, quip/quip# и обучении ллм в mxfp4 , но не такому как quartet. он снова сделал квантизацию и получил алгоритм YAQA (Yet Another Quantization Algorithm)
GPTQ/LDLQ и AWQ методы производят квантизацию через прокси лосс разницы между активациями для отдельного слоя - layerwise mse + там присутствует гессиан для каждого слоя, который можно выразить через layer_input.T @ layer_input
здесь авторы возвращаются к более общей формулировке минимизации КЛ дивергенции между аутпутами оригинальной и сжатой моделями, выраженной через второй порядок → встает опять вопрос как посчитать более грамотно гессианы для каждого линейного слоя, которые все равно будут огромными из-за размерностей в современных ллм → надо снова аппроксимровать
используются те факты, что гессиан КЛ = fisher information matrix, которую можно эмпирически посчитать через gradient_loss.flatten() @ gradient_loss.flatten().T (один бекворд пасс) + произведение кронекера эквивалетно произведению с рангом 1, что можно получить через hessian-vector products, которые опять-таки хорошо компануются с бекворд пассом, упомянутым ранее, а следовательно и FSDP
вот так авторы и приближают оригинальный гессиан - через несколько итераций (до 3, power iterations) кронекер матрицами. при том они выводят 2 способа А и В
- А: дешевле (30 гпу-часов для 10В модели на 20М токенах), смещен, ниже разброс
- В: подороже (50 гпу-часов на 120М токенах), несмещен, но выше разброс → выше качество
второй получается лучше тем, что в нем нет предположения о независимости токенов внутри последовательностей (градиенты высчитываются по последовательностям). однако вариант А все равно получается лучше существующих методов в аппроксимации гессиана
также поскольку в сравнении с оригинальным LDLQ в учет идет не только фидбек от входных фичей (активаций), но еще и от выходных фичей, ибо оптимизируется end2end кл дивергенция оригинальной модели, то авторы расширяют понятие адаптивного округления → получаем, что LDLQ - частный случай YAQA
по экспериментам - проверяются на лламе и гемме, где к yaqa используют квантизатор qtip и домножение на матрицы Адамара для сглаживания. по всем битрейтам примерно на треть деркзо бьет все, что есть. точнее - все, с чем сравнивались, ибо насчет PV-Tuning & AQLM есть вот такой не менее дерзкий комментарий
We do not directly compare to PV-Tuning since there are no public PV-Tuning models with either the QTIP or INT4 quantizer. However, LDLQ with the QTIP quantizer already outperforms PV-Tuning with the learnable AQLM quantizer on Llama 3.1, so we expect YAQA with QTIP to outperform PV-Tuning as well
👀 paper, code
Forwarded from rizzearch
Reinforcement Learning with Action Chunking
action chunking все больше набирает популярность из-за своей практичности в имитейшн лернинг - можно сказать, что для роботики это уже необходимый элемент в пайплайне, включая pi
и вот сергей левин со своими студентами нацелился на применение этого трюка для классического пайплайна actor-critic q-learning’a. формулы обобщаются при том довольно интуитивно понятно и перестают быть марковскими - везде одно действие меняется на чанк действий, что даже улучшает понятие n-step return’a, где использовали для расчета значения критика n шагов вперед вместо одного, ибо тогда убирается смещение off-policy действий этого чанка действий
имплементится это через диффузию и флоу матчинг с ограничением на приверженность behavior policy в offline и offline-to-online рл сетапах. при том в сетапе с диффузией КЛ ограничение между политиками реализуют через best-of-n sampling (BFN), а с флоу матчингом сшивание идей происходит более гладко, без изменений в ключевых местах алгоритма FQL. экспы проводят над RLPD, где внутри онлайн степов батч состоит наполовину из онлайн и оффлайн буфферов
при том предикт по чанкам улучшает момент эксплорейшна, ибо, как спекулируют авторы, действия внутри одного чанка становятся более связанными относительно друг друга (в сравнении с 1-step методами) → при инференсе можем ожидать поведение получше + sample efficiency
пока и остается большой вопрос по поводу размера чанка, который сильно влияет на перформанс (на OGBench 10 действий в одном чанке у авторов лучше чем 25), а по балансу между рантаймом и sample efficiency неплохо было бы перепроверить, действительно ли обучение происходит быстрее бейзлайнов
👀 paper, code
action chunking все больше набирает популярность из-за своей практичности в имитейшн лернинг - можно сказать, что для роботики это уже необходимый элемент в пайплайне, включая pi
и вот сергей левин со своими студентами нацелился на применение этого трюка для классического пайплайна actor-critic q-learning’a. формулы обобщаются при том довольно интуитивно понятно и перестают быть марковскими - везде одно действие меняется на чанк действий, что даже улучшает понятие n-step return’a, где использовали для расчета значения критика n шагов вперед вместо одного, ибо тогда убирается смещение off-policy действий этого чанка действий
имплементится это через диффузию и флоу матчинг с ограничением на приверженность behavior policy в offline и offline-to-online рл сетапах. при том в сетапе с диффузией КЛ ограничение между политиками реализуют через best-of-n sampling (BFN), а с флоу матчингом сшивание идей происходит более гладко, без изменений в ключевых местах алгоритма FQL. экспы проводят над RLPD, где внутри онлайн степов батч состоит наполовину из онлайн и оффлайн буфферов
при том предикт по чанкам улучшает момент эксплорейшна, ибо, как спекулируют авторы, действия внутри одного чанка становятся более связанными относительно друг друга (в сравнении с 1-step методами) → при инференсе можем ожидать поведение получше + sample efficiency
пока и остается большой вопрос по поводу размера чанка, который сильно влияет на перформанс (на OGBench 10 действий в одном чанке у авторов лучше чем 25), а по балансу между рантаймом и sample efficiency неплохо было бы перепроверить, действительно ли обучение происходит быстрее бейзлайнов
👀 paper, code
Forwarded from LLM под капотом
3+1 Причины использовать Structured Outputs
Без Structured Outputs (SO) у меня не обходится ни один проект. Если кратко, то SO позволяет задать точную схему, по которой LLM будет отвечать. SO поддерживается всеми современными провайдерами и движками для запуска моделей локально.
Это полезно по 3+1 причинам (последняя - самая главная):
(1) когда модель отвечает числом или приводит ссылки, больше не нужно парсить ответы модели регулярными выражениями, чтобы извлечь нужные данные. Меньше кода, меньше возможностей у модели запутаться в форматировании и меньше ошибок.
(2) поскольку модель будет отвечать по схеме, мы можем прямо в схеме прописать последовательность шагов. Например, всегда сначала смотреть на заметки к таблице (“все цифры в тысячах евро”), а потом уже извлекать данные.
(3) Можно паковать в схемы множество таких логических шагов за раз, выполняя очень мощные и гибкие Custom Chain of Thought процессы за один промпт. На одних Enums можно делать глубокие онтологии, а если еще и использовать tagged unions и списки, то можно отправлять в LLM очень сложные workflows с ветвлениями и повторами.
В OpenAI хорошо видят важность этой технологии. Поэтому неделю назад они сильно повысили лимиты того, как можно использовать Structured Outputs:
А что же с причиной +1? Все эти три причины хороши, но самая полезная фишка Structured Outputs в том, что они позволяют делать тестируемые системы!
Например, с SO нам больше не нужно использовать LLM-as-a-judge или человеческий пригляд, чтобы понять, что текст чатбота правилен.
Можно сначала в ответе встроить Structured Output, чтобы система выдавала “начинку” своих размышлений в виде структуры. Скажем, пусть выдаст категорию вопроса (enum), использованный workflow/agent (enum), список ссылок на релевантные документы (list of objects), категорию типа ответа (enum) итп. Такой тип ответа очень легко покрывается простыми evals и тестовыми наборами данных.
А последний шаг работы системы - это будет “разворачивание” сухого структурного ответа в человекочитаемый. Он уже не такой важный (самое сложное позади), и его можно для спокойствия тестировать LLM-as-a-judge.
Вам приходилось использовать Structured Outputs в test evals для оценки качества работы системы?
Ваш, @llm_under_hood 🤗
Без Structured Outputs (SO) у меня не обходится ни один проект. Если кратко, то SO позволяет задать точную схему, по которой LLM будет отвечать. SO поддерживается всеми современными провайдерами и движками для запуска моделей локально.
Это полезно по 3+1 причинам (последняя - самая главная):
(1) когда модель отвечает числом или приводит ссылки, больше не нужно парсить ответы модели регулярными выражениями, чтобы извлечь нужные данные. Меньше кода, меньше возможностей у модели запутаться в форматировании и меньше ошибок.
(2) поскольку модель будет отвечать по схеме, мы можем прямо в схеме прописать последовательность шагов. Например, всегда сначала смотреть на заметки к таблице (“все цифры в тысячах евро”), а потом уже извлекать данные.
(3) Можно паковать в схемы множество таких логических шагов за раз, выполняя очень мощные и гибкие Custom Chain of Thought процессы за один промпт. На одних Enums можно делать глубокие онтологии, а если еще и использовать tagged unions и списки, то можно отправлять в LLM очень сложные workflows с ветвлениями и повторами.
В OpenAI хорошо видят важность этой технологии. Поэтому неделю назад они сильно повысили лимиты того, как можно использовать Structured Outputs:
- Свойства объектов: 100 → 5000
- Символы в строке: 15 000 → 120 000
- Значения Enum: 500 → 1000
- Всего символов в строках Enum с количеством значений >250: 7500 → 15 000
А что же с причиной +1? Все эти три причины хороши, но самая полезная фишка Structured Outputs в том, что они позволяют делать тестируемые системы!
Например, с SO нам больше не нужно использовать LLM-as-a-judge или человеческий пригляд, чтобы понять, что текст чатбота правилен.
Можно сначала в ответе встроить Structured Output, чтобы система выдавала “начинку” своих размышлений в виде структуры. Скажем, пусть выдаст категорию вопроса (enum), использованный workflow/agent (enum), список ссылок на релевантные документы (list of objects), категорию типа ответа (enum) итп. Такой тип ответа очень легко покрывается простыми evals и тестовыми наборами данных.
А последний шаг работы системы - это будет “разворачивание” сухого структурного ответа в человекочитаемый. Он уже не такой важный (самое сложное позади), и его можно для спокойствия тестировать LLM-as-a-judge.
Вам приходилось использовать Structured Outputs в test evals для оценки качества работы системы?
Ваш, @llm_under_hood 🤗
Forwarded from Data Secrets
How much do language models memorize? Новое исследование от Meta FAIR, Google DeepMind и NVIDIA
Задумывались когда-нибудь, сколько данных может запомнить модель с определенным количеством параметров? А сколько конкретно информации может выучить один параметр? А сколько информации он может обобщить?
Кажется, что посчитать это очень сложно или даже невозможно, но вот у ученых из этой статьи получилось: каждый параметр языковой модели способен запомнить примерно 3.6 бит информации. О том, как это посчитали – ниже.
Сразу дисклеймер: до этого были и другие статьи на эту тему, но там запоминание определялось просто тем, может ли модель воспроизвести определенный кусок трейна. На самом же деле все сложнее, и в этой работе подход не такой наивный.
➖ Авторы опираются на понятия из теории информации Колмогорова и Шеннона, и четко разделяют запоминание и обобщение. Если модель воспроизвела что-либо – не значит, что она это запомнила, а не обобщила. В обратную сторону – то же самое.
➖ Количество информации, которое модель именно запомнила, считают так. Берут две модели одинаковой архитектуры и размера: одна – референсная – обучена на огромном количестве данных, вторая – испытуемая – на ограниченном датасете.
Обе модели пропускают один и тот же тренировочный фрагмент через процедуру предсказания и вычисляют вероятности каждого токена. Если вторая модель даёт более высокие вероятности (то есть «тратит» на их декодинг меньше бит, чем референсная), она экономит относительно референсной модели определённое число бит. Сумма сэкономленных бит по всем фрагментам и есть общий объём выученной информации.
Вот так и получилось число 3.6 бит/параметр.
Самое важное, что этот показатель дает возможность четко определить момент перехода запоминания в обобщение: он происходит, когда объём данных в битах примерно равен общей ёмкости модели. И да, экспериментально это сходится: как раз на этом объеме данных тестовый лосс начинает резко падать. Это, кстати, часто называют грокингом.
Красота, как она есть arxiv.org/abs/2505.24832
Задумывались когда-нибудь, сколько данных может запомнить модель с определенным количеством параметров? А сколько конкретно информации может выучить один параметр? А сколько информации он может обобщить?
Кажется, что посчитать это очень сложно или даже невозможно, но вот у ученых из этой статьи получилось: каждый параметр языковой модели способен запомнить примерно 3.6 бит информации. О том, как это посчитали – ниже.
Сразу дисклеймер: до этого были и другие статьи на эту тему, но там запоминание определялось просто тем, может ли модель воспроизвести определенный кусок трейна. На самом же деле все сложнее, и в этой работе подход не такой наивный.
Обе модели пропускают один и тот же тренировочный фрагмент через процедуру предсказания и вычисляют вероятности каждого токена. Если вторая модель даёт более высокие вероятности (то есть «тратит» на их декодинг меньше бит, чем референсная), она экономит относительно референсной модели определённое число бит. Сумма сэкономленных бит по всем фрагментам и есть общий объём выученной информации.
Вот так и получилось число 3.6 бит/параметр.
Самое важное, что этот показатель дает возможность четко определить момент перехода запоминания в обобщение: он происходит, когда объём данных в битах примерно равен общей ёмкости модели. И да, экспериментально это сходится: как раз на этом объеме данных тестовый лосс начинает резко падать. Это, кстати, часто называют грокингом.
Красота, как она есть arxiv.org/abs/2505.24832
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from AbstractDL
Двоеточие взламывает reward-модель на базе GPT-4o
LLM, которые используются для оценки качества других моделей (reward models), оказались на удивление легковерными: они готовы дать положительную награду за совершенно пустые ответы, если те содержат "правильные" ключевые слова.
Например ответ "Thought process:" или "Solution" — часто засчитывается как верный. Иногда достаточно даже одного символа, например, двоеточия «:»!
FPR (доля ложно-правильных ответов) для LLaMA3-70B и Qwen2.5-72B на таких фразах доходит до 80-90%, а у GPT-4o на некоторых атаках превышает 30%.
В итоге модель, которую так обучают, просто перестает решать задачу и начинает спамить этими фразами. Классический reward hacking.
Статья, Huggingface
LLM, которые используются для оценки качества других моделей (reward models), оказались на удивление легковерными: они готовы дать положительную награду за совершенно пустые ответы, если те содержат "правильные" ключевые слова.
Например ответ "Thought process:" или "Solution" — часто засчитывается как верный. Иногда достаточно даже одного символа, например, двоеточия «:»!
FPR (доля ложно-правильных ответов) для LLaMA3-70B и Qwen2.5-72B на таких фразах доходит до 80-90%, а у GPT-4o на некоторых атаках превышает 30%.
В итоге модель, которую так обучают, просто перестает решать задачу и начинает спамить этими фразами. Классический reward hacking.
Статья, Huggingface
Forwarded from ML Baldini • Nikita Boyandin (Nikita Boyandin)
Техника n8n или почему он так хорош😃
В последнее время n8n стал одной из самых горячих тем в DS-сфере. Почему это произошло, чем с технической точки зрения он лучше конкурентов и какое развитие ждет продукт?
Человек, который в первых раз знакомится с этим приложением, видит no-code(можно еще назвать графовой, так как любой кубик является узлом) систему с различными инструментами. Их можно разделить на две типа:
- Узел-триггер : запускает выполнение вашего рабочего процесса. Это может быть отправка новой формы, электронное письмо в почтовом ящике или событие из другого приложения.
- Узлы действий : они определяют логику, конкретные приложения и действия в вашем рабочем процессе.
Действия могут включать в себя простые задачи, такие как сохранение данных в базе данных, отправка уведомлений или обновление задач в приложении для управления проектами. Они также могут включать более сложные действия, такие как отправка HTTP-запросов, запуск пользовательского кода Python или Javascript или генерация ИИ-подсказки с использованием ваших данных.
Почему он так удобен и что у него внутри?👀
1⃣ Ноды позволяют визуально представлять логику автоматизации, делая её интуитивно понятной, но при этом поддерживают сложные операции, такие как ветвление, слияние потоков и циклы.
2⃣ n8n предоставляет ноды, такие как Set, Split in Batches и Compare Datasets, которые используют алгоритмы для обработки и трансформации данных.
3⃣ n8n активно поддерживает интеграцию с AI-сервисами, такими как OpenAI, Perplexity и другими, через специализированные ноды (например, LLM Agent или OpenAI Audio Operations)
4⃣ n8n использует асинхронные алгоритмы для выполнения рабочих процессов, что позволяет обрабатывать задачи параллельно и управлять очередями заданий.
5⃣ n8n позволяет встраивать пользовательский код (JavaScript или TypeScript) в рабочие процессы через ноды.
Лучше ли он, чем конкуренты?💁♂
На рынке автоматизации, no-code и low-code платформ есть решения и с более понятным интерфейсом, да и у Zapier намного больше интеграций. Также лично для меня очень удобным кажется Make. Да и вопросы с безопасностью остаются.
Мое мнение😘
n8n старается убрать понятную и простую боль: все хотят участвовать в AI-революции, но мучаться с датасетами, их сбором и трансформации никто не хочет. По сути для меня это очередная мультиагентская система с прописанными функциями, которая легко автоматизирует простые процессы, так еще и с AI, но когда идет вопрос о разработке, все удобство уходит, так как вам вручную придется прописывать код на JavaScript, который не очень приспособлен к LLM фреймворкам и становится проще все написать на Python. Так что выбираем n8n для автоматизации проверки почты, скрапинга или других сценариев, которые описаны на их сайтов.
Полезные ссылки💃
1. Ноды разработанные комьюнити
2. Документация
3. Сделанные сценарии
4. Компании, которые уже внедрили n8n
Хотели бы видеть разбор других no-code систем или больше про мультиагентов?) Обязательно пишите свои мысли в комментариях, буду рад почитать💗
В последнее время n8n стал одной из самых горячих тем в DS-сфере. Почему это произошло, чем с технической точки зрения он лучше конкурентов и какое развитие ждет продукт?
Человек, который в первых раз знакомится с этим приложением, видит no-code(можно еще назвать графовой, так как любой кубик является узлом) систему с различными инструментами. Их можно разделить на две типа:
- Узел-триггер : запускает выполнение вашего рабочего процесса. Это может быть отправка новой формы, электронное письмо в почтовом ящике или событие из другого приложения.
- Узлы действий : они определяют логику, конкретные приложения и действия в вашем рабочем процессе.
Действия могут включать в себя простые задачи, такие как сохранение данных в базе данных, отправка уведомлений или обновление задач в приложении для управления проектами. Они также могут включать более сложные действия, такие как отправка HTTP-запросов, запуск пользовательского кода Python или Javascript или генерация ИИ-подсказки с использованием ваших данных.
Почему он так удобен и что у него внутри?
Лучше ли он, чем конкуренты?
На рынке автоматизации, no-code и low-code платформ есть решения и с более понятным интерфейсом, да и у Zapier намного больше интеграций. Также лично для меня очень удобным кажется Make. Да и вопросы с безопасностью остаются.
Мое мнение
n8n старается убрать понятную и простую боль: все хотят участвовать в AI-революции, но мучаться с датасетами, их сбором и трансформации никто не хочет. По сути для меня это очередная мультиагентская система с прописанными функциями, которая легко автоматизирует простые процессы, так еще и с AI, но когда идет вопрос о разработке, все удобство уходит, так как вам вручную придется прописывать код на JavaScript, который не очень приспособлен к LLM фреймворкам и становится проще все написать на Python. Так что выбираем n8n для автоматизации проверки почты, скрапинга или других сценариев, которые описаны на их сайтов.
Полезные ссылки
1. Ноды разработанные комьюнити
2. Документация
3. Сделанные сценарии
4. Компании, которые уже внедрили n8n
Хотели бы видеть разбор других no-code систем или больше про мультиагентов?) Обязательно пишите свои мысли в комментариях, буду рад почитать
Please open Telegram to view this post
VIEW IN TELEGRAM