Интересное что-то
542 subscribers
2.75K photos
253 videos
140 files
4.55K links
Материалы и мысли, понадерганные отовсюду
Блог: https://t.iss.one/asisakov_channel
Чат: https://t.iss.one/youknowds_chat
Download Telegram
Вместе с Cloud․ru собрали модели, которые реально работают:
- отличная поддержка русского,
- быстрый старт без боли,
- легко встраиваются в агентов и ассистентов,
- бюджетно гоняются

Эти модели — идеальный выбор для MVP, экспериментов и продакшн-инференса.
Всё open-source, а лучшее место чтобы развернуть опенсурс в России быстро и выгодно — Evolution ML Inference
оказывается папир вышел вместе с моделью

придумали бенч, придумали конкатить vae, собственно вот что получилось
Forwarded from Борис опять
Команда Яндекс RecSys R&D Team разработала ARGUS (AutoRegressive Generative User Sequential Modeling) — новую трансформерную рекомендательную модель. Трансформеры чудесны тем, что могут обрабатывать любые последовательности. Но здесь не просто предсказание отклика пользователя. ARGUS одновременно предсказывает будущие действия пользователя и его отклик, что повышает точность и качество персонализации. Данных об отклике всегда мало, так что использовать для обучения данные про все действия пользователя это очень умно.

Яндекс Музыка стала первым сервисом, в который внедрили новую модель и перевели её в онлайн-режим. Впервые Яндекс Музыка начала работать на базе генеративных моделей в 2023 году, теперь в Музыке ARGUS применяется в реалтайме, для каждого трека в Моей волне. Причем это 126М модель с длиной контекста 8192 события. Для реалтайм инференса трансформеров на масштабах Яндекс Музыки это очень большая модель. Инференсить такое на каждый новый трек в Моей волне — довольно нетривиальная задача.
Реалтайм инференс возможен благодаря собственной архитектуре модели, где эмбеддинги для пользователей и треков пересчитываются в оффлайне регулярным процессом. Это снимает большую часть нагрузки с модели, которая в такой постановке занимается лишь установлением взаимосвязей в последовательности.

Для оценки качества используется global temporal split, то есть замеряем качество на следующей неделе по времени после обучающих данных. На предобучении смотрели на лосс для задач next item prediction и feedback prediction. На дообучении была другая задача: правильно ранжировать близкие по времени прослушивания пользователем треки исходя из оставленного на них фидбека. Смотрим насколько предсказания модели о том, что больше предпочтет пользователь, совпадают с реальностью. Чем-то напоминает supervised finetuning LLM. Также для замера качества сравнивали метрики бустинга с прода с таким же бустингом, но с дополнительным признаком от ARGUS.

В онлайне проводили A/B эксперименты на пользователях Яндекс Музыки и Маркета и получили статзначимые улучшения продуктовых метрик. В стриминге пользователи стали на 20% чаще ставить лайки и добавлять в коллекцию впервые услышанные треки и артистов. В Маркете пользователи стали добавлять в корзину на 3% больше товаров, увиденных в рекомендациях, а покупки товаров из рекомендаций в новых для них категориях выросли на 5%.

https://habr.com/ru/companies/yandex/articles/919058/
Нашел потрясный курс по RAG.

Здесь 22 урока по имплементации различных RAG-техник: от самого базового на эмбеддингах, до RAG-а на графе и добучения с помощью Reinforcement Learning.

Что самое приятное: все пишется с нуля на Python.

Обычно все клепают RAG-и так: берем готовый фреймворк (LangChain и тд), смотрим туториал "how implement rag", берем готовые модули оттуда. Для быстрых прототипов это ок вариант, но так нормально не разобраться, как что работает.

Только разобравшись, как это все пишется с нуля, сможете потом делать надежные LLM-системы. И на любом фреймворке.

Вы как знаете, а я пошел повторять.
Forwarded from эйай ньюз
HKU NLP выкатили POLARIS - рецепт для выжимания максимума из маленьких моделей через RL.

Их 4B модель показывает 81.2% на AIME24 и 79.4% на AIME25, что сопоставимо с моделями во много раз больше. Фокус в правильной калибровке сложности данных - нужно перевернутое J-образное распределение, где большинство задач сложные, но решаемые. Они динамически отфильтровывают слишком простые задачи во время тренировки, поддерживая оптимальный уровень сложности. Так модель вынуждена постоянно учиться и расти над собой, в то же время не надрываясь на слишком сложных задачах.

Важно поддерживать и разнообразие генераций — модели имеют три температурные зоны: стабильная генерация (низкое разнообразие), осторожное экспериментирование (оптимальный баланс) и полный коллапс. POLARIS тренируют так, чтобы модель всегда экспериментировала и не выдавала слишком похожих решений, а по мере роста уверенности модели в ходе тренировки постепенно повышают температуру - с 1.4 до 1.5 для Qwen3-4B. Это поддерживает разнообразие решений, необходимое для relative policy optimization.

Для решение проблемы разреженных наград используют Rollout Rescue: когда все 8 попыток решения проваливаются, система подставляет сохраненное успешное решение из предыдущих эпох. Для каждой задачи поддерживается буфер с последним правильным ответом, который обновляется при появлении новых успешных решений. Это гарантирует, что модель всегда имеет положительные примеры для обучения даже на самых сложных задачах.

Экстраполяция длины через Yarn позволяет моделям генерить 90K+ токенов качественных рассуждений, хотя тренировались они на меньших длинах. Без Yarn точность на длинных цепочках рассуждений падает с 50% до 26%.

Многоэтапная тренировка с постепенным увеличением контекста и удалением ограничений энтропии/KL loss для агрессивного исследования пространства решений завершают картину.

Результат – 4B модель, которую можно запустить на телефоне, которая решает олимпиадные задачи почти на уровне 235B Qwen 3. А вишенка на торте — опубликовали не только веса модели, но и датасет на котором тренировали POLARIS.

Веса 4B модели
Датасет
Блогпост о тренировке

@ai_newz
Forwarded from КПД
Пользуясь случаем, заодно и приложу выступление с прошедшего ДатаФеста выступления первого автора статьи выше (@black_samorez_channel) Обучение LLM в низкой точности вычислений (речь про статьи QuEST и Quartet).
💊 Интенсивность имеет значение: как оценить эффект, если воздействие имеет разную силу?

Недавно мы обещали рассказать вам, как оценивать эффекты, если воздействие непрерывное -- пришло время этой темы!

Обычно для оценки влияния политик или другого воздействия используется метод разность разностей (Difference-in-Differences, DiD), но он работает хорошо, когда можно разделить наблюдаемые единицы на две группы: тех, кто подвергся воздействию, и тех, кто нет

В реальности же воздействие часто имеет не бинарную, а непрерывную природу — то есть разную интенсивность (dose):
🟤уровень загрязнения воздуха в регионах
🟤доля пациентов с ДМС в больнице
🟤количество символов в посте 😁 и т.д.

Во всех этих случаях вопрос звучит не "было ли воздействие?", а "насколько интенсивным оно было?"

🆕 Не скоро дело делается... Спустя 5 лет эти вопросы снова подняли в своём препринте известные исследователи DiD — Брэнтли Кэллоуэй (Университет Джорджии), Эндрю Гудман-Бейкон (Федеральный резервный банк Миннеаполиса) и Педро Сант'Анна (Университет Эмори) (Callaway et al., 2025)
Авторы переосмысливают классический DiD и показывают, что при непрерывном воздействии привычные методы могут давать некорректные оценки

В чём проблема?
Во многих прикладных работах исследователи используют стандартную модель с фиксированными эффектами (TWFE) и включают переменную интенсивности воздействия, умноженную на бинарную переменную пост-периода. Но такая оценка:
🟤не равна среднему причинному эффекту
🟤не отражает отклик на изменение интенсивности
🟤может быть смещенной из-за гетерогенных эффектов в разных группах и при разных интенсивностях
🟤складывается из эффектов при разных уровнях интенсивности с непрозрачными, иногда отрицательными весами

Авторы показывают, что даже в простой ситуации 2×2 DiD (две группы, два периода), коэффициент TWFE не имеет корректной причинной интерпретации, если интенсивность воздействия варьируется

Что и как нужно оценивать на самом деле?
Авторы вводят два типа причинных эффектов:
🟤Уровневый эффект (Level Effect) — показывает, как изменяется результат при переходе от нулевой интенсивности к заданной
🟤Причинный отклик (Causal Response) — описывает, как результат реагирует на небольшое изменение интенсивности. Это аналог производной или эластичности, но в причинном смысле

Что делать?
🟤Если вы хотите понять, что даёт воздействие при конкретной интенсивности — ищите уровневый эффект
🟤Если хотите знать, как результат реагирует на рост интенсивности — ищите причинный отклик
🟤Если нужно усреднённое значение по всей выборке — считайте агрегаты с корректными весами

Какие нужны предпосылки?
🟤Параллельные претренды (Parallel Trends) - предположение, что без воздействия все группы развивались бы одинаково
→ Позволяет идентифицировать уровневый эффект при заданной интенсивности
🟤Сильные параллельные претренды (Strong Parallel Trends) - предположение, что результат при одинаковой интенсивности развивался бы одинаково у всех групп
→ Необходимо для корректной оценки причинного отклика

Действительно разные результаты? Medicare и капиталоёмкость
🟤Дарон Аджемоглу и Эми Финкельштейн (Acemoglu, Finkelstein, 2008), используя TWFE показали, что после отмены трудовых субсидий по Medicare больницы стали больше инвестировать в капитал
🟤Авторы новой статьи применили свой подход к тем же данным — и получили иные результаты: уровень эффекта оказался на 50% выше, чем в TWFE; причинный отклик был положительным при низкой интенсивности, но негативным при высокой
🟤Это означает, что TWFE не просто занижал эффект, но и менял его знак при попытке оценить маржинальный отклик

🖥 Открытый пакет contdid
Авторы статьи разработали R-пакет contdid. Это пока альфа-версия, но она уже поддерживает непрерывное воздействие, ступенчатое воздействие (staggered adoption), агрегации по интенсивности и времени
🔗 Документация пакета: Github и RD Packages

Заинтересованным в теме предлагаем также заглянуть в препринт (Zhang, 2025), где автор пытается решить похожую задачу с помощью double/debiased machine learning

#канал_обозревает
#канал_рекомендует
@causal_channel
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Pavel Zloi
Ну чтож, не зря я возился со всеми этими UI для чатиков, собрал список моментов которые меня в них разочаровали и те моменты которые мне понравились.

На основе своих наблюдений собрал небольшой проект, который назвал SimpleChat, данный проект работает полностью в браузере, на моём хостинге лежат только статичные файлы, вся же остальная работа происходит в вашем браузере, вся история тоже хранится только в браузере в LocalStorage.

Благодаря этому мой Chat UI можно использовать даже с локальными LLM движками, навроде Ollama или vLLM. По умолчанию указал api.rpa.icu и публичный ключик, но через настройки можно указать любой другой сервер, настройки сохранятся в браузере.

На русский пока не перевёл, решил пока что попробовать свои силы в разработке в формате вайбкодинга.

PS. Проект сгенерировал за пару дней при помощи Курсора
Forwarded from Pavel Zloi
Небольшая инструкция о том, как использовать SimpleChat с вашей локальной Ollama.

Первым делом надо сделать так чтобы Ollama запускалась с флагом OLLAMA_ORIGINS=*, например у меня дома настроено в docker-compose.yml так:
services:

ollama:
image: ollama/ollama:0.9.2
restart: unless-stopped
volumes:
- ./ollama_data:/root
environment:
OLLAMA_ORIGINS: "*"
OLLAMA_FLASH_ATTENTION: 1
ports:
- "11434:11434"

Полный конфиг тут.

Далее заходим через Хром на сайт и в левом верхнем углу ищем иконку похожую на эквалайзер, нажав на неё увидим кнопку Site settings, жмём на неё (рис.1)

Откроется страница настроек сайта, мотаем её вниз до Insecure content, указанный переключатель необходимо выставить в Allow (рис.2)

Теперь можно зайти на страницу настроек SimpleChat и указать в нём адрес своей локальной Ollama (рис.3)
https://localhost:11434/v1

Обратите внимание на /v1, в ollama по этому пути доступны эндпоинты совместимые с openai-клиентами.