Forwarded from Кодим на Коленке | Уроки по программированию
Пишем Микросервисы на Python + Брокер RabbitMQ
Базовый гайд для тех, кто только знакомится с микросервисами на Python. Пишем систему уведомлений на микросервисной архитектуре. Стек: FastAPI, Aiogram, FastStream, RabbitMQ.
🗝 Урок живет здесь
Кодим на Коленке | #RabbitMQ
Базовый гайд для тех, кто только знакомится с микросервисами на Python. Пишем систему уведомлений на микросервисной архитектуре. Стек: FastAPI, Aiogram, FastStream, RabbitMQ.
🗝 Урок живет здесь
Кодим на Коленке | #RabbitMQ
YouTube
Пишем Микросервисы на Python + Брокер RabbitMQ
Базовый гайд для тех, кто только знакомится с микросервисами на Python. Пишем систему уведомлений на микросервисной архитектуре. Стек: FastAPI, Aiogram, FastStream, RabbitMQ.
🎓 Мы обучаем Python Backend-разработке так, чтобы ты писал код как инженер. Заходи…
🎓 Мы обучаем Python Backend-разработке так, чтобы ты писал код как инженер. Заходи…
Forwarded from Кодим на Коленке | Уроки по программированию
ПОЛНЫЙ КУРС ПО SELENIUM
Добро пожаловать на бесплатный курс по Selenium, в данном видеокурсе/плейлисте будут рассмотрены практически все аспекты Selenium, включая фишки, лайфаки и прочее!
🗝 Курс живет здесь
Кодим на Коленке | #Python
Добро пожаловать на бесплатный курс по Selenium, в данном видеокурсе/плейлисте будут рассмотрены практически все аспекты Selenium, включая фишки, лайфаки и прочее!
🗝 Курс живет здесь
Кодим на Коленке | #Python
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 🤗