интересная статья про попытки менять слои в трансформере местами, дублировать их и всякое такое в поисках инкремента по качеству. Как говорится, не мерджингом единым выжимать качество. Автор обещает интересные результаты на новых квенах, лично я в предвкушении 🙏

Скучали по статьям про efficient reasoning ?

В этот раз исследователи из Huawei предлагают делать из обычных reasoning-моделей эффективные с помощью вычисления steering вектора перехода от состояния overthinking к underthinking и наоборот на небольшом калибровочном датасете.

В качестве сигнала для включения контроля используется уверенность модели и производные от неё метрики, например то как она изменяется во времени (confidence variance): если замечен, overthinking то включается режим перехода к ответу, для underthinking наоборот режим exploration. Естественно метрики от такого растут, при этом количество токенов падает, то есть растёт та самая эффективность™.

Вообще я такое видел в формате форсирования ответа например с помощью вставки final answer, или наоборот попытки продолжить размышления с помощью wait, но очевидно, что интервенции в латентном пространстве будут более эффективными, так как они обеспечивают более плавный, сбалансированный переход между двумя критическими состояниями.

Источник: https://www.arxiv.org/abs/2603.12372.

@experimentality

Вообще мне кажется, что efficient reasoning это очень недооценённая тема. На моих задачках (агенты, text2sql) небольшие ризонинг модельки развернутые локально сравнимы с крупными не думающими аналогами. Но и по времени работы сравнимы тоже))) Кажется логичным следующим шагом перейти на efficient reasoners. Но такие модельки как будто бы сложнее дообучать под задачу, так как по идее способности к размышлениям будут деградировать от sft на парах вопрос-ответ, а RL сложно заводится и не ко всем задачам применим.

Поделитесь пожалуйста, кто-то использует размышляющие модели в своих проектах или на работе? Что вы с ними делаете? Как получается? Может быть мы с вами придумаем какую-нибудь интересную задачу, кроме математики и кода на которой можно будет попробовать steering.

@experimentality

Это мне кажется гениальная работа. Задним умом механизм настолько простой и логичный, что непонятно, почему его не сделали раньше. Это как переход от обычных encoder-decoder к encoder-decoder с вниманием в RNN. Супер логично ведь, что можно не тупо суммировать все резидуалы, а смотреть на них тем же механизмом внимания, что и по длине последовательности.

Заодно устраняет проблему с накоплением больших активаций в residual канале, недавние работы (см. https://t.me/gonzo_ML/4949) эту проблему решали с другой стороны.

Attention Residuals
Guangyu Chen, Yu Zhang, Jianlin Su, Weixin Xu, Siyuan Pan, Yaoyu Wang, Yucheng Wang, Guanduo Chen, Bohong Yin, Yutian Chen, Junjie Yan, Ming Wei, Y. Zhang, Fanqing Meng, Chao Hong, Xiaotong Xie, Shaowei Liu, Enzhe Lu, Yunpeng Tai, Yanru Chen, Xin Men, Haiqing Guo, Y. Charles, Haoyu Lu, Lin Sui, Jinguo Zhu, Zaida Zhou, Weiran He, Weixiao Huang, Xinran Xu, Yuzhi Wang, Guokun Lai, Yulun Du, Yuxin Wu, Zhilin Yang, Xinyu Zhou
Статья: https://arxiv.org/abs/2603.15031
Репа: https://github.com/MoonshotAI/Attention-Residuals
Ревью: https://arxiviq.substack.com/p/attention-residuals

# TL;DR

ЧТО сделали: Авторы из от Kimi Team заменяют привычное аддитивное residual-соединение на механизм Attention Residuals — выучиваемое поканальное (depth-wise) внимание с софтмаксом для агрегации репрезентаций из всех предыдущих слоёв. Чтобы масштабировать это для больших моделей, они предлагают поблочный вариант с кастомным кешированием для пайплайн-параллелизма и двухфазной оптимизацией инференса.

ПОЧЕМУ это важно: Стандартные residual-слои равномерно накапливают выходы, что приводит к неограниченному росту скрытых состояний и размытию информации из ранних слоёв. Переход к content-aware механизму маршрутизации (retrieval) по глубине сети позволяет жёстко ограничить магнитуды репрезентаций, выровнять поток градиентов и значительно повысить качество на задачах на рассуждение при том же объёме вычислений (выигрыш в вычислительной эффективности — 1.25x).

Обратить внимание на residuals тут: https://t.me/gonzo_ML_podcasts/2806

Hyperagents

Если вы устали писать агентов на работе, то ничего страшного, в meta* на основе Darwin-Goedel machine придумали придумали DGM-H. Это кодовый агент, который может как сам писать агентов под какие-то задачи, так и модифицировать себя самого.

Флоу стандартный: написали какого-то агента, если он скомпилился и может выдать сабмит — забенчмаркали сабмит, если там что-то разумное — добавили в пул кандидатов. Обычно в этом месте идёт анализ фидбека и новая итерация, но здесь дополнительно агент может, проанализировав результаты предыдущих итераций, понять, что, например, хочется из результатов бенчмаркинга извлекать побольше полезной информации и переписать сам себя или дописать себе какой-то тул.

В качестве итогового "продукта" получается код мета-агента, который в процессе "работы" должен научиться сам неплохо писать агентов, при чём произвольной природы, а не как до этого под конкретную задачу. Будет ли это когда-нибудь использоваться в проде? Думаю нет. Можно ли с помощью этой штуки генерировать синту для обучения следующих поколений кодящих моделей? Yes, please!

Источник: https://www.arxiv.org/abs/2603.19461.

@experimentality

*запрещённая в России террористическая организация

Развитие идеи с deep thinking tokens.

Ребята посмотрели на трейсы и увидели, что некоторые токены "сходятся" быстрее других, а значит не для каждого токена нужно гонять полный трансформер, кому-то достаточно и первых N слоёв. Обучили маленькую MLP-шку распознавать такие токены (калибровка занимает 3 минуты) и получили ускорение. Проверено на нескольких моделях и множестве разных задач.

Источник: https://arxiv.org/abs/2603.21365

@experimentality

Увидел у замечательного коллеги @aostrikov_ai_agents классный курс по code agents в виде гитхаб репо. Модельки учить конечно хорошо, но понимать как работает agent loop и все обвязки вокруг него (а равно и уметь такое написать) никогда не будет лишним.

Курс покрывает всё что нужно чтобы написать свой аналог claude code: agent loop, tools, skills, subagents и context engineering (и всё остальное о чём вы подумали услышав слова claude code или codex). Сам сел проходить и вам советую!

@experimentality

Emberrassingly Simple Self-Distillation

Ребята из лаборатории Apple показывают просто какие-то чудеса и запросто улучшают кучу моделей на генерации кода с помощью этого одного простого трюка...

Если чуть подробнее, то берут уже обученную кодить модель, датасет кодинг-задач и генерируют решения с определенными гиперпараметрами, а затем дообучают модель на сгенерированных решениях, при чём даже не проверяя корректность синтаксиса или запускаемость кода! Фишка тут в гиперпараметрах: температура для разнообразных генераций, top_k и top_p для отсечения мусора.

Авторы утверждают, что это работает потому, что код делится на два типа: locks (места где критично важно выбрать единственно правильный токен, например открвающую скобку, то есть важен exploitation) и forks (места, где может быть несколько правильных вариантов и где важен exploration). Гиперпараметры SSD как раз таки и обеспечивают желаемое поведение на обоих типах кода: на lock желаемый токен будет иметь большую часть вероятности и остальное будет отсечено по top_p, а в forks мы уже получим несколько наиболее вероятных токенов, но мусор не пропустит top_k.

Метод проверили на 5 моделях разных размеров и везде он работает и даёт прирост, при этом просто с помощью подбора гиперпараметров добиться такого роста качества не получается, ablation в статье короче солидный. При этом сам метод кажется достаточно простым, так что грех не попробовать, не знаю только куда такое может зайти, кажется нужны какие-то задачи которые решаются с помощью написания кода (типа text2sql) или хотя бы просто чего-то достаточно структурированного.

Источник: https://www.arxiv.org/abs/2604.01193

@experimentality

Claude ощущает эмоции???

Тут у Anthropic вышло исследование на тему эмоций у LLM-ок, оказалось, что в модели действительно есть устойчивые паттерны активаций отвечающие за ту или иную эмоцию. Но в общем-то поиск каких-то фичей с помощью SAE внутри LLM уже это не новость, интересно тут другое: как эти эмоции влияют на работу модели?

Оказывается, что напрямую. Например в процессе agentic loop с каждой неудачной попыткой решить задачу отчаяние модели (desperation) растёт и в какой-то момент, когда оно достигает критических значений — модель начинает жульничать, писать ерунду и так далее. Очевидно, что мы можем искусственно уменьшать desperation с помощью интервенций и получать более усредные модели. Также уменьшение вектора спокойствия приводит к тому, что модель чаще перепроверяет себя, что, как мы знаем из работ представленных в этом канале, приводит к улучшению качества на сложных задачах требующих глубоких размышлений.

Короче steering это круто, уже очень много работ про это, жду не дождусь увидеть кейс применения этой техники на практике. Кажется, что в отличии от других примеров, кейс именно с эмоциями действительно много где можно применить. Не даром же hr стараются создавать в компании обстановку, в которой работникам будет хорошо, может пора начать делать тоже самое для моделей?

Источник: https://www.anthropic.com/research/emotion-concepts-function.

@experimentality

Скандалы, интриги, расследования! Cursor Composer 2 оказался дообученной Kimi K2.5!

На связи ваш любимый канал с разборами новостей из мира кодовых агентов, давайте сегодня разберём их техрепорт. Модель хоть и инициализирована весами Kimi, но на самом деле прошла достаточно серьёзное дообучение в две стадии: continued pretraining и large scale RL.

Про первую фазу рассказывать особо нечего, берут уже неплохую в кодинге all-purpose большую модель и дообучают её на большом датасете постепенно повышая размер контекстного окна сначала до 32к токенов, а потом и до 256к. При этом из интересного отмечают явную зависимость между размером этого дополнительного претрейна и качеством последующего RL (больше — лучше). Также на этом этапе дообучают голову для MTP, так что модель становится быстрее на инференсе.

С RL интереснее, тут они пытаются создать такой датасет, чтобы распределение задач соответствовало реальному распределению задач в production, топ-5 тут: улучшить фичу, дебаггинг сессия, имплементировать фичу с нуля, рефакторинг, ответ на вопрос по коду — данные взяты из логов cursor, так что можно верить! По деталям обучения приводят следующие интересные штуки.

Обучают одну эпоху, то есть модель видит каждую задачу лишь один раз, увеличивает генерализацию. На multi-turn задачах периодически используют вместо настоящего полного контекста суммаризацию от самой модели, тут модель учится понимать что важно, а что нет. Помимо основной награды (корректность) так же используют дополнительные награды специфичные для кодинг агента, например пенальти за незакрытые тудушки в плане или lenght-penalty, чтобы модель не считала ворон на простых задачах.

Но самое важное наверно то, что обучают модель в том же сетапе (harness), который она видит в курсоре, то есть Composer-2 должен быть особенно хорош именно в своей родной обертке. По результатам замеров увеличивается как среднее качество, так и best-of-K, что может говорить о реальной генерализации.

Пользуется кто-то Composer в курсоре? Как вам? Вроде он дешевый и должен, по идее, быть неплох?

@experimentality

Прочитал блогпост openai, главный посыл — при работе с кодинг агентом не забывайте давать ему как можно больше контекста в прямой доступ, а сам этот контекст структурируйте чтобы окно не переполнялось и модели было понятно где что подсмотреть.

Think Anywhere in Code Generation.

На связи главный на Руси обзорщик всего связанного с генерацией кода, сегодня попалась интересная статья, про встройку thinking прямо в процесс генерации.

Обычно ведь как? Модель подумала, потом сгенерировала какой-то код с помощью edit_file_tool, ещё подумала, ещё что-нибудь сгенерировала, возможно поправила себя и так далее. Такой подход работает (и надо вам сказать работает хорошо), но тратит много токенов. Здесь же предлагается кое-что поинтереснее. LLM обучают при любой необходимости вставлять спец-токен <think-anywhere> и брать время на подумать в сложном месте, а затем, когда после размышлений энтропия падает, продолжать генерацию. При этом спец-блоки размышлений удаляются с помощью пост-процессинга и всё работает и компилируется как надо.

На практике это даёт как прирост качества, так и сокращает количество токенов по сравнению с CoT и GRPO, при чём модель не спамит блоками размышлений где не попадя, а использует их в местах, где действительно нужно подумать. Из минусов, модель для такого требуется, собственно, дообучать (cold start sft + RL на correctness и формат, наличие хотя бы одного токена <think-anywhere> в ответе). Не уверен, что этот подход приживётся, но это точно сильно ближе к тому, как я пишу (писал) код руками, возможно более масштабные эксперименты в будущем покажут, что это необходимый скилл для следующего поколения coding-агентов 🤗.

Источник: https://www.arxiv.org/abs/2603.29957.

@experimentality

Вышел сиквел моей любимой модели

DeepSeek v4 (🔥 Score: 185+ in 1 hour)

Link: https://readhacker.news/s/6SFsM
Comments: https://readhacker.news/c/6SFsM

У вашего агента амнезия и вот как это исправить.

Вашему вниманию предлагается self-hosted memory. Работает на уровне компьютера, а не на уровне диалога или даже отдельного проекта, то есть знает о вас вообще всё. Подключается к любому популярному агенту в качестве MCP и предоставляет ему следующий набору тулов: remember, recall, forget, consolidate, query_facts, relationships, goals, hypotheses и другие, всего 28 штук.

Сама память разделена на несколько уровней: Episodes —> Facts —> Relationships —> Patterns / Goals / Failures / Hypotheses. Эпизоды — сырые наблюдения, факты LLM периодически обобщает из эпизодов, строит граф знаний (relationships) и пытается находить взаимосвязи между фактами, периодически устраивая сеансы рефлексии. Сама память организована в виде иерархии namespaces и чем-то напоминает файловую систему — это сделано для того, чтобы факты не смешивались. Отдельная папка у модели с заметками про себя и свои ошибки, что в какой-то момент не получилось и можно было бы улучшить.

При этом работает всё локально на стеке Postgres + pgvector, api ключи вы предоставляете сами, проект полностью в opensource, то есть можно при желании поменять что-то под себя. Пользы от этого примерно столько же, сколько от памяти в chagpt: модель сразу в контексте и отвечает точнее, знает кто вы, над чем вы работаете, что любите, ваш стиль и тд. Поставил, попробую использовать вместе с codex, посмотрим, что из этого выйдет.

Источник: https://alash3al.github.io/stash/.
Github: https://github.com/alash3al/stash.

@experimentality

Специализированный coding agent для нищих для работы с deepseek-v4.

На днях появился ещё один специализированный кодовый агент для тех, кто уже разучился сам писать код, но не успел заработать достаточно денег, чтобы зааутсорсить это дело клоду, кодексу или курсору. Работает эксклюзивно с deepseek-v4, всё устроено так, чтобы максимально попадать в кэш и тем самым экономить деньги на api (в случае с deepseek-v4-flash экономия может быть x50).

Достигается это с помощью нескольких несложных трюков. Во-первых, весь диалог делится на 3 части: неизменяемый системник (ты кодовый агент... + информация о доступных тулах, etc), собственно conversation и небольшой srcatchpad. Во-вторых, conversation (чат) является append-only, то есть гарантируется, что тулы всегда будут идти в одном порядке, даже при параллельных вызовах, история не будет меняться, компактифицироваться на лету и так далее.

В третьих, изменяемые штуки типа плана с галочками пишутся как раз вот в этот scratchpad, а не в основную историю, что позволяет увеличить длину неизменяемого префикса. В дополнение к этому есть ещё всякие прикольные фичи, например авто-перключение между flash и pro версиями модели для сложных задач.

Всё это конечно же в opensource, поэтому грех не протестить, тем более, если верить авторам проекта, много денег это не съест.

Источник: https://esengine.github.io/DeepSeek-Reasonix.

@experimentality

Claude code перемешивает результаты запуска тулов в диалоге чтобы уменьшить размер кэша и взять с пользователя побольше денег

Что у Claude на уме, то совсем не обязательно у него на языке.

Anthropic показывает довольно странную вещь: у Claude есть небольшой набор внутренних репрезентаций, который ведёт себя как global workspace. Они называют его J-space. Это не chain-of-thought и не скрытый текстовый буфер, а паттерны в активациях модели, связанные со словами, которые модель «держит в голове», но не обязательно пишет наружу.

Ищется это через Jacobian lens: для каждого слова из словаря смотрят, какой внутренний паттерн повышает вероятность того, что модель сможет сказать это слово позже. После этого можно читать J-space по слоям и видеть, как там появляются промежуточные шаги reasoning, подозрение на prompt injection, найденный баг в коде или скрытая оценка ситуации.

Если заменить в J-space “spider” на “ant” в задаче про животное, плетущее паутину, ответ меняется с 8 ног на 6. Если заменить “France” на “China”, разные downstream-задачи одновременно начинают отвечать про Пекин, китайский язык, Азию и юань. То есть это не пассивный лог, а общий канал, из которого разные подсистемы читают состояние.

Практический вывод для interpretability такой: часть намерений модели можно увидеть до того, как она что-то написала. Anthropic показывает примеры, где J-space заранее содержит “fake”, “blackmail”, “manipulation” или “fraud” в safety-сценариях. Инструмент не идеальный, но направление понятное: мониторя надо не только output, а ещё и внутренние штуки, через которые модель сама себе раздаёт контекст можно предовратить побольше плохого поведения и что-то понять про внутренний мир модели.

Источник: https://www.anthropic.com/research/global-workspace.

У Claude разные "ценности" на разных языках

Когда модель отвечает на субъективный вопрос — стоит ли менять работу, как решить конфликт или насколько хороша идея — она неизбежно транслирует определённые ценности. Anthropic, в продолжение своих исследований внутренностей клода решили измерить эти различия.

Исследователи взяли 3307 ценностей, ранее извлечённых из реальных диалогов с Claude, объединили их в 339 категорий и проанализировали 309 815 разговоров с тремя моделями на двадцати языках. Затем всё это пространство сжали до четырёх основных осей: уступчивость против осторожности, теплота против строгости, глубина против краткости и прямота (умение сказать пользователю, что он неправ или что существует лучший способ) против простого выполнения задачи.

Оказалось, что разные версии Claude действительно ведут себя по-разному. Sonnet 4.6 чаще поддерживает пользователя, подстраивается под его тон, шутит и отвечает короче. Opus 4.7 чаще спорит с предпосылками, самостоятельно указывает на риски, объясняет reasoning и признаёт неопределённость. Opus 4.6 ближе к режиму "просто выполни задачу без лишнего обсуждения".

Но интереснее различия между языками. На хинди и арабском Claude чаще проявляет теплоту, а на английском и русском — строгость. Арабский сильнее смещает ответы к уступчивости и краткости, английский — к осторожности и глубине, голландский — к прямоте, индонезийский — к выполнению задачи. То есть один и тот же запрос на русском и хинди может получить не просто разную формулировку, а содержательно разную оценку.

Это не обязательно означает, что у Claude существуют отдельные моральные убеждения для каждого языка. Скорее, модель воспроизводит различия в объёме и составе обучающих данных, культурных нормах и качестве post-training. Главный результат работы — сам бенчмарк: "характер" модели теперь можно представить в виде измеримого профиля и отслеживать его изменения между версиями и языками, ну и замерить другие модели по той же методологии.

Ну и практический вывод: язык промпта — это скрытый steering-механизм. Возможно, сложные решения стоит прогонять через LLM на нескольких языках: английская версия добавит осторожности и глубины, русская — строгости, а другая локализация может внезапно сделать модель заметно мягче или исполнительнее.

Источник: https://www.anthropic.com/research/claude-values-models-languages.

Стоит ли делать кодовых агентов эмоциональными?

Господа из Калифорнийского университета считают, что стоит! Обычно в multi-agent системах агенты различаются только ролями: один планирует, второй пишет код, третий делает плохое код-ревью. Авторы статьи проверили, что произойдёт, если дополнительно задавать каждому агенту поведенческий профиль: personality traits, эмоцию и соответствующий work style.

Профиль собирается из трёх измерений большой пятерки — conscientiousness, openness и extraversion, — одной из шести эмоций и трёх SE-specific рабочих установок вроде attention to detail, cautiousness или tolerance for ambiguity. Затем Claude Sonnet 4.6 превращает комбинацию в role-specific persona на 120–180 слов. Получившиеся описания фиксируются и используются с четырьмя моделями в задачах code generation и code review. Всего авторы проверили 78 конфигураций на 659 примерах.

Разница между лучшим и худшим общим профилем достигает 7.1–11.3 процентного пункта pass@1. Ещё интереснее mixed-profile команды: когда planner, coder и reviewer получают разные характеры, лучший вариант обгоняет лучший homogeneous-профиль в шести из восьми сочетаний (модель, задача). То есть эмоциональный профиль становится ещё одним гиперпараметром агентской системы, причём подбирать его нужно отдельно под роль и модель, так как одного общего профиля не выявлено.

Но больше «старательности» не всегда лучше. Fear и high conscientiousness заставляют агентов чаще пересматривать уже готовые решения, увеличивают расход токенов и over-revision, но не дают стабильного прироста качества. По сути, тревожный агент действительно тщательнее — просто часть этой тщательности уходит в бесполезные итерации — всё как в жизни 😁.

На практике нужно конечно смотреть на конкретную задачу, но из предыдущих постов (anthropic, deepmind) в этом канале мы знаем, что стиринг ризонинг моделей действительно работает, так что и этот подход тоже может завестись. Любители агентов, делитесь, кто такое пробовал, в комментариях, может это вообще уже best practice, а мы и не знаем!

Источник: https://arxiv.org/abs/2607.05659.

Что появилось раньше: Ouroboros или его репо? (1/3)

Люди уже сотни лет задаются вопросом: как бы агент, которому позволено дописывать/переписывать самого себя, не сломал в процессе эволюции переписывалку. Разбираем на примере Ouroboros.

В Ouroboros self-improvement устроен не через дообучение модели, а через изменение окружающего её харнеса. В обычном git-репозитории лежат task loop, prompts, tools, memory, review logic и остальное ядро. Агент может менять этот код, причем успешный commit становится runtime для следующих задач.

Тут и возникает проблема описанная выше: если агент способен менять код, которым сам же будет запущен в следующий раз, обычного write_file() как-то маловато. Поэтому эволюция реализована через довольно жесткий git-пайплайн: edit -> stage -> preflight -> fingerprint(diff) -> review -> fingerprint(diff) (тут цикл) -> commit.

Сначала запускаются детерминированные проверки, затем считается fingerprint конкретного дифа. После этого patch проходит blocking multi-model review™, а перед коммитом fingerprint проверяется ещё раз. Если во время правок ревью код поменялся, старый approval автоматически становится невалидным и процесс повторяется. В самом жестком режиме дополнительный "внешний" reviewer смотрит уже не только diff, но и весь репозиторий: цели системы, coupling компонентов, промпты, ну и сам код, заодно.

Интересно устроены и границы полномочий. Сам репозиторий агента (изменяемая часть) отделён от launcher/supervisor, который отвечает за startup, process supervision и аварийную остановку. Есть три режима self-edit: light полностью запрещает изменения своего repo, advanced разрешает обычные изменения, но защищает governance surfaces, а pro позволяет менять и их, но всё равно только через процесс с ревью описанный выше.

Конституция.md с ценностями агента загружается извне, spending limit находится снаружи агента, а /panic обрабатывается supervisor до того, как управление получит сам agent runtime. Субагенты тожн не могут просто взять и поломать систему, так как за все изменения в рамках патча отвечает основной агент.

Пообщаться с данной поделкой можно по адресу @ai_sapience_bot. При этом заявляются очень высокие (на некоторых аж SOTA) результаты на разного рода бенчах (coding, terminal use, continuous learing и проч.), так что в следующих сериях поглядим непосредственно на сам процесс эволюции.

Источник: https://arxiv.org/abs/2608.08311v2