gonzo-обзоры ML статей – Telegram
gonzo-обзоры ML статей
24.1K subscribers
2.71K photos
2 videos
3 files
1.34K links
Авторы:
Гриша Сапунов, ранее руководитель разработки Яндекс-Новостей, ныне CTO Intento. Области интересов: AI/ML/DL, биоинформатика.
Лёша Тихонов, ранее аналитик в Яндексе, автор Автопоэта, Нейронной Обороны... Области интересов: discrete domain, NLP, RL.
Download Telegram
Закончили с призёрами NeurIPS, теперь финалисты. Статья про RLVR, который на самом деле не находит ничего нового.

Does Reinforcement Learning Really Incentivize Reasoning Capacity in LLMs Beyond the Base Model?
Yang Yue, Zhiqi Chen, Rui Lu, Andrew Zhao, Zhaokai Wang, Yang Yue, Shiji Song, Gao Huang
Статья: https://arxiv.org/abs/2504.13837, https://openreview.net/forum?id=4OsgYD7em5
Код: https://limit-of-rlvr.github.io
Ревью: https://arxiviq.substack.com/p/neurips-2025-does-reinforcement-learning

# TL;DR

ЧТО сделали? В этой работе, прошедшей в финал (Best Paper Runner-Up) на NeurIPS 2025, авторы систематически исследовали границы возможностей рассуждающих моделей (reasoning models), обученных с помощью RLVR (Reinforcement Learning with Verifiable Rewards). Используя несмещённую метрику pass@k на задачах по математике, кодингу и визуальному мышлению, они сравнили базовые модели с их RL-версиями, чтобы выяснить: генерирует ли RLVR принципиально новые паттерны мышления или лишь усиливает существующие.

ПОЧЕМУ это важно? Результаты разрушают популярный миф о том, что RLVR позволяет моделям автономно открывать "сверхчеловеческие" стратегии подобно AlphaGo. Исследование показывает: RLVR радикально улучшает *эффективность сэмплирования* (правильные ответы выпадают чаще), но не расширяет фундаментальные границы возможностей модели. На больших значениях k базовые модели часто решают *больше* уникальных задач, чем их RL-версии, что говорит об ограниченности текущих методов RL прайорами предобучения.

Подробнее: https://news.1rj.ru/str/gonzo_ML_podcasts/1513
👍12🤔43
🔥17👍8🤔5😁2
Зарисовки на тему программирования с моделями.

Ещё совсем недавно я пользовался AI лишь в режиме умного саджеста, а потом генерации кода по запросу в чате и копипасту туда-сюда. Теперь ради интереса пробую более автономные агентские режимы типа Cursor 2.0 или свежего Antigravity.

Мой вывод на сегодня -- модели далеки от рабочей автономности, но всё же сделали огромный шаг вперёд за последние полгода. Они могут быстро делать туеву хучу полезной работы, но постоянно плодят ошибки и упущения. От банальных типа использования переменной до её объявления (странно, конечно, что такое просачивается, но обычно оно не при первой генерации появляется, а уже после редактирования) или забытого параметра при вызове функции, к более сложному незнанию особенностей текущей версии библиотеки (должно лечиться в том числе и правильным RAG или скорее уже context engineering) и до порой логически очень противных косяков, которые можно было бы списать на невнимательность в случае человека, но от модели с большим контекстом ожидаешь иного.

На днях я игрался с запуском сетки новой архитектуры. У меня уже был код на PyTorch (полученный таким же вайбкодингом из другого кода на PyTorch), который как-то работал. Надо сказать, собирать это в Курсоре было очень удобно -- модель быстро писала код, можно было давать ей примеры статей (прямо ссылками на arxiv) и объяснять, что именно ты хочешь оттуда перенять, и она в целом справлялась. Да, тоже приходилось итерироваться на ошибках запуска, но тот процесс я в целом прошёл довольно быстро.

К сожалению, в прошлый раз у меня кончились кредиты на GPU чтобы продолжить эти эксперименты. Теперь зато появилось сколько-то кредитов на TPU и соответственно я хотел портировать этот код на TPU, а заодно попробовать свежий Antigravity. С этим всем оказалось сложнее. Сначала я хотел переписать код на PyTorch/XLA, модель в первом приближении это сделала, но потом начались проблемы с задействованием всех ядер TPU на одной машине и модель застряла в синхронизациях и race conditions.

Ещё я по ошибке сначала выбрал не ту версию системы (образ с последним из доступных там PyTorch), где PyTorch и питон оказались слишком старыми, чтобы поддерживать код, собранный на nightly build или хотя бы на 2.9, так что часть новых фич пришлось переписать на старые. Надо было, конечно, сразу на новый образ перейти, а не страдать фигнёй. Выбирайте в таком случае последнюю убунту, а не все эти предсобранные образы.

В какой-то момент я решил, что проще и интереснее не бороться с PyTorch/XLA, а переписать сразу на JAX/NNX и не мучиться. Antigravity довольно резво переписал (составил себе многошаговый план и прошёлся по нему), потом я сколько-то поитерировался с довольно глупыми банальными ошибками и наконец модель типа заработала. Но были раскиданы грабли.

Из топа моих находок:

1. Модель написала код, который технически работал и обучение модели новой архитектуры как-то шло. Но мне не нравилась скорость обучения и в частности динамика уменьшения лосса. Я наблюдал эту динамику в старом коде на пайторче, здесь же лосс уменьшался сильно медленнее. Я несколько раз просил модель внимательно пройтись по коду и найти расхождения с оригинальной версией, она по мелочи что-то находила, но не то, и убеждала меня, что всё замечательно обучается, надо просто подождать. Предлагала также архитектурные изменения, но это было ни к чему, явно что-то не так было с кодом. В итоге раз на пятый я от неё добился более подробного анализа и она нашла прекрасную ошибку -- градиенты считались верно, но затем они не вычитались из весов модели, а просто их перезаписывали. Удивительно вообще, что оно ещё и обучалось, надо будет копнуть, что там на самом деле происходило, тоже интересный эффект. Напоминает старый анекдот про кота, оставленного на неделю полуслепому соседу, у которого кот ел "неохотно" — по ошибке вместо кошачьего корма тот сыпал коту кофейные зёрна.
19👍8👏7😁3👌1
2. В другом примере качество по одной из метрик снова стагнировало на плато, я попросил модель разобраться. Она обнаружила, что в дропауте используется всегда один и тот же random seed (потому что в JAX функции работы со случайными числами требуют передачи сида в виде ключа извне -- чтобы быть функционально чистыми -- а в коде оно не передавалось и использовалось какое-то дефолтное из одного места). Это конечно странный косяк, хорошо бы чтобы модель знала как верно использовать разные функции. Но ещё более интересный косяк в том, что в модели не было дропаута вообще, ни в оригинальной, ни в переписанной. То, что она там нашла и предлагала пофиксить, было галлюцинацией галлюцинации. В итоге "пришёл муж и переделал всё по-своему".

И я ещё не знаю, сколько там других скользких мест в коде, я его внимательно не валидировал. Надо по-хорошему, но этот эксперимент я гоняю в условиях отсутствия свободного времени, так что получается лишь несколько раз в день заглянуть и дать новые рекомендации. Как альтернатива здесь только не сделать этот эксперимент ни в каком виде вообще. Так что по чистому затраченному времени не знаю был бы выигрыш или нет, но по суммарному эффекту он точно есть -- без (в данном случае) Antigravity я бы просто не сделал это совсем, потому что не нашёл бы времени.

В целом, конечно, весёлая деятельность -- сам накосячил, сам исправил. Постоянная занятость! Хорошо хоть сам отлаживать теперь умеет без постоянного копипаста туда-сюда. Если разрешить запускать скрипты самостоятельно, то вполне сносно уже получается, модель идёт по плану, включающему до 60 шагов -- создаёт проверочные скрипты, тестовые датасеты, запускает, анализирует ошибки и прочее. No more copy-paste!

Но этого всего пока недостаточно. Это в конечном счёте твой зоркий глаз должен найти проблему!

Я активно использую модели для перевода постов в блог, а теперь ещё и для автоматической генерации ревью. У меня огромный массив автоматических проверок и своя конституция aka гайд про то, что должно быть в посте и чего там не должно быть, какие проверки сделать, какие из них сделать дважды или трижды. Но я всё равно потом вычитываю пост вручную (вглазную), чтобы убедиться, что всё верно. Каких-то радикальных проблем я за несколько месяцев не нашёл, но несколько неточных формулировок за это время исправил, а также гору просочившихся галлюцинаций, в основном по части ссылок. Но если блог-пост я ещё могу прочитать, и подкаст худо-бедно тоже могу прослушать, то вот на большую сгенерённую кодовую базу требуется сильно больше времени, которого обычно нет.

Для кода явно нужны свои промпты с принципами, и наверняка кто-то их уже собирает (поделитесь, если нашли для себя что-то рабочее). Нужно, чтобы модель создавала документацию. Не столько для человека, сколько для самой же себя, когда будешь новый чат или агента запускать. Нужны обязательно тесты и прочие автоматические проверочные сценарии, условно всё то же, что могло бы пригодиться для RLVR. Но в отличие от классических юнит-, интеграционных и иногда присутствующих перформанс-тестов, нужно явно больше, особенно если вы кодите что-то в области около ML -- различные проверки качества и детекция аномалий в обучающем процессе.

С вайбкодингом нужны ещё и постоянные security аудиты. Хотя эта часть, по идее, должна на модель лучше ложиться, чем на людей. Среднему человеку анрил следить за всеми актуальными уязвимостями, да и даже держать постоянно в голове десятки практик секьюрного программирования тоже задача не для слабых. В этом смысле, я бы ожидал, что хорошая с точки зрения безопасности кода модель + система, реализующая полноценный SSDLC, была бы одним из наиболее полезных решений. Есть уже какой-то стартап с таким фокусом? Не знаю, насколько текущие копайлоты, курсоры и прочие хороши с этой точки зрения, наверняка уже проводились какие-то сравнения, но мимо меня не пролетали пока. Поделитесь, если видели хорошие.
👍114😁2
При этом я не могу сказать, что вся эта генерация контента и кода -- это плохо. Это хорошо, потому что без неё, я бы сделал вдесятеро меньше (а в некоторых местах не сделал бы вообще ничего). Но доверять сгенерённому коду я по-прежнему не могу, пока не проревьюил всё сам, да и после этого тоже не могу, но уже в меньшей степени -- лучше всё же, когда больше одного человека сделали такое ревью. Все классические практики software engineering обретают в новом мире десятикратно большую значимость -- код ревью, тесты, документация, проверки типов, контроль версий, … -- жить без этого в эпоху вайбкодинга просто опасно для здоровья. И разные языки для этого тоже явно не одинаково хороши, ждём куда эволюция вырулит.

Автономность таких решений продолжает расти. Будет всё как с генерацией картинок. Два года назад мы все смеялись над лишними пальцами, а теперь видите ли уже фактология сгенерённой картинки не совсем исторически точная для промпта со всего лишь точкой во времени-пространстве. Прогресс в последнее время быстр, так же будет и с кодом. Раз в год, наверное, буду постить эту свою старую статью 2017 года на Форбс (https://www.forbes.ru/tehnologii/341535-mashiny-vmesto-inzhenerov-pochemu-iskusstvennyy-intellekt-doberetsya-i-do) и пытаться понять, где мы уже на этом пути. В 2017-м я думал, что продвинемся быстрее, но в последние пару лет мы наконец начали прямо бежать.
🔥13🤔54
That's beautiful!
Но дебажит знатно! План на 59 шагов
👀9
Предпоследняя работа-финалист NeurIPS 2025. Тотальный хардкор! Специалисты в теории трансдуктивного онлайн-обучения есть?

Но зато узнал, что в дополнение к VC-размерности бывает ещё и LD.

The Quadratic Gap: Resolving the Value of Unlabeled Data in Online Learning
Zachary Chase, Steve Hanneke, Shay Moran, Jonathan Shafer
Статья: https://openreview.net/forum?id=EoebmBe9fG
Ревью: https://arxiviq.substack.com/p/neurips-2025-optimal-mistake-bounds

# TL;DR

ЧТО сделали: Авторы решили 30-летнюю открытую проблему, получив за это Best Paper Runner-Up на NeurIPS 2025. Они доказали, что для класса гипотез с размерностью Литтлстоуна d оптимальная граница ошибок в трансдуктивном онлайн-обучении составляет Θ(√d).

ПОЧЕМУ это важно: Результат математически строго показывает, насколько полезно «заглядывать в будущее». Доступ к неразмеченной последовательности тестовых данных позволяет квадратично снизить число ошибок по сравнению со стандартным онлайн-сеттингом (где граница равна d). Это закрывает огромный экспоненциальный разрыв между старой нижней границей Ω(log d) и верхней O(d).

Подробнее: https://news.1rj.ru/str/gonzo_ML_podcasts/1524
9🔥4🤯1
😁25🔥173
Прекрасная картинка. Увидел у https://news.1rj.ru/str/fastsalttimes/4696. Оригинал: https://x.com/tomaspueyo/status/1993360931267473662
1🤣34👍12🤡11🔥8😁1
Последняя из работ-финалистов NeurIPS 2025, про геометрию репрезентаций и механистическое объяснение законов скейлинга. Работа прекрасна!

Superposition Yields Robust Neural Scaling
Yizhou Liu, Ziming Liu, and Jeff Gore
Статья: https://arxiv.org/abs/2505.10465, https://openreview.net/forum?id=knPz7gtjPW
Код: https://github.com/liuyz0/SuperpositionScaling
Ревью: https://arxiviq.substack.com/p/neurips-2025-superposition-yields

# TL;DR

ЧТО сделали: Предложили механистическое объяснение законов масштабирования (scaling laws), связав их с суперпозицией репрезентаций. Адаптировав фреймворк разреженных автоэнкодеров и проверив теорию на открытых LLM (OPT, Pythia, Qwen), авторы показали: когда модели работают в режиме «сильной суперпозиции» (кодируют значительно больше фичей, чем имеют измерений), лосс масштабируется обратно пропорционально ширине модели (L ∝ 1/m). Этот скейлинг обусловлен геометрической интерференцией между векторами признаков, а не статистическими свойствами хвоста распределения данных.

ПОЧЕМУ это важно: Работа — Best Paper Runner-Up на NeurIPS 2025. Она дает вывод законов скейлинга «из первых принципов», устойчивый к распределению данных. В отличие от предыдущих теорий, опирающихся на аппроксимацию многообразия, здесь утверждается, что степенной закон поведения LLM — это геометрическая неизбежность сжатия разреженных концептов в плотные пространства. Это означает, что для преодоления барьеров масштабирования нужны архитектурные вмешательства для управления интерференцией признаков — простое добавление данных не поможет обойти это геометрическое бутылочное горлышко.

Подробнее: https://news.1rj.ru/str/gonzo_ML_podcasts/1531
🔥273👍3
Шедевр, я считаю!
🔥60😁37👻5👍2🤮2🥱1💯1😈1
Любопытная книга в открытом доступе

Artificial Humanities: A Fictional Perspective on Language in AI
Nina Beguš

Artificial Humanities explores how literature, history, and art can deepen our understanding of artificial intelligence and its development. By examining fictional representations of AI in parallel with actual technological developments, Nina Beguš presents a novel interdisciplinary framework for understanding the cultural, philosophical, and ethical dimensions of AI. She traces connections from Eliza Doolittle to ELIZA the chatbot and current language models, incorporates Slavic fictional examples from the Pygmalion paradigm, and compares mid-century science fiction and recent Hollywood films with contemporary developments in social robotics and virtual beings.

Highlighting the impact of human-like AI design, from gendered virtual assistants to romanticized social robots, the book shows how these technologies intersect with longstanding humanistic questions about the concepts of creativity and language as well as the relations between humans and machines. Additionally, the book explores AI's applications in medical fields, particularly psychiatry and neurotechnology, including how AI interacts with the human body and mind to address conditions like paralysis. By emphasizing the philosophical and cultural implications of these technologies, Beguš highlights the need for responsible innovation that prioritizes human well-being as well as machine potential outside of human imitation. Accessible and thought-provoking, Artificial Humanities offers tools for analyzing and assessing technologies while they are being developed and invites readers to see how the humanities can guide us toward a more thoughtful future for AI.

https://www.fulcrum.org/concern/monographs/jh343w51t
12🔥1🥰1🤔1🌚1
Будущее за оркестрами, обучайте дирижёров!

ToolOrchestra: Elevating Intelligence via Efficient Model and Tool Orchestration
Hongjin Su, Shizhe Diao, Ximing Lu, Mingjie Liu, et al.
Paper: https://arxiv.org/abs/2511.21689
Code: https://github.com/NVlabs/ToolOrchestra/
Data: https://huggingface.co/datasets/nvidia/ToolScale
Model: https://huggingface.co/nvidia/Orchestrator-8B
Webpage: https://research.nvidia.com/labs/lpr/ToolOrchestra
Review: https://arxiviq.substack.com/p/toolorchestra-elevating-intelligence

# TL;DR

ЧТО сделали: Представили ToolOrchestra — фреймворк для обучения легковесных LLM (8B параметров) выступать в роли умных маршрутизаторов для зоопарка инструментов и мощных моделей-экспертов (вроде GPT-5). С помощью алгоритма Group Relative Policy Optimization (GRPO) (https://arxiv.org/abs/2402.03300) и массивного синтетического датасета ToolScale, полученный Оркестратор учится балансировать точность решения с ценой вычислений и предпочтениями юзера.

ПОЧЕМУ это важно: Работа ставит под сомнение гипотезу о том, что "чем больше модель, тем лучше". Авторы показывают, что 8B модель, грамотно управляющая внешними ресурсами, может обойти фронтир-модели (как GPT-5) на сложных бенчмарках типа Humanity’s Last Exam (https://arxiv.org/abs/2501.14249), срезая косты на инференс на ~70%. Это валидирует переход от гигантских монолитов к составным системам (Compound AI Systems), где интеллект рождается из правильной оркестрации.

Подробнее: https://news.1rj.ru/str/gonzo_ML_podcasts/1541
🔥16👍121