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

Как сделать LLM-as-a-Judge чуть менее дискретным

У обычного LLM-as-a-Judge есть проблема: модель может оценивать два ответа почти одинаково, но наружу мы обычно забираем только один score token. Например, при шкале 1–5 распределение P(3)=0.2, P(4)=0.45, P(5)=0.3 превращается просто в 4. Из-за этого теряется информация об uncertainty, появляется много ничьих, а такой сигнал плохо подходит для ранжирования похожих агентских траекторий.

В LLM-as-a-Verifier предлагают не обучать отдельную reward модель, а использовать logprobs самой LLM. Вместо argmax берётся матожидание по всему распределению score tokens. Плюс шкалу расширяют до 20 градаций (uncertainty и granularity), проверку повторяют несколько раз (repeated evaluation), а сложную оценку — разложить на несколько критериев (decomposition). Причём сами критерии задаются обычным текстом: например, можно отдельно попросить проверить, устранил ли агент root cause проблемы или достаточно ли он провалидировал свой fix. В результате вместо грубого 4/5 получается более плотный continuous reward, который лучше различает близкие решения.

Дальше поверх этого reward в библиотеке есть несколько режимов:

- compare — базовый примитив: берём две траектории и получаем fine-grained оценку того, какая лучше по заданному текстом критерию. По сути, всё остальное строится поверх таких сравнений.

- select — Best-of-N. Генерируем несколько решений и выбираем лучшее через verifier. Чтобы не сравнивать каждый вариант с каждым за O(N^2), используется Probabilistic Pivot Tournament: сначала выбирается небольшое число сильных кандидатов — pivots, а остальные кандидаты сравниваются преимущественно с ними. В итоге стоимость порядка O(Nk), а количеством pivots можно менять в зависимости от количества доступного компьюта для более точных оценок.

- track — берём уже готовую траекторию и считаем reward после разных её шагов. Получается кривая прогресса: можно увидеть, в какой момент агент действительно приблизился к решению, а где несколько шагов подряд просто ходил кругами.

- ProgressTracker делает примерно то же самое, но прямо на лету. После очередного действия verifier пересчитывает текущий progress score. Это уже позволяет использовать проверку внутри agent loop: рано останавливать явно неудачные траектории, пересемплировать застрявшие или заканчивать rollout до вызова final answer, когда задача уже фактически решена, но агент продолжает жечь токены.

Получается довольно универсальный набор инструментов: compare сравнивает два решения и полезен на бенчах, select помогает скейлить качество через "ширину", track для оценка качества агента постфактум и поиска слабых мест, а ProgressTracker превращает verifier в critic, который можно встроить непосредственно в процесс работы агента.

По результатам и ablation: увеличение granularity с 1 до 20 уровней поднимает pairwise verification accuracy на Terminal-Bench V2 с 73.1% до 77.5%, repeated evaluation — с 74.7% до 77.4%, а ансамбль из трёх критериев даёт 78.3%. В итоговом Best-of-N сетапе авторы также получают 86.5% на Terminal-Bench V2, 78.2% на SWE-Bench Verified, 87.4% на RoboRewardBench и 73.3% на MedAgentBench. То есть все эти ухищрения кажется действительно дают дополнительный сигнал, а не просто усложняют judge prompt.

Всё, кто дочитал — ставьте классы, репостите (чтобы канал рос и развивался) и делитесь, как вы используете logprobs ллм-ки в реальных проектах. Я ближе к ночи тоже отпишусь в комментариях. Вторая часть обзора на уроборос, тем временем, уже готовится.

Источник: https://github.com/llm-as-a-verifier/llm-as-a-verifier

Как Hope учится на собственных ошибках? (2/3)

В предыдущих сериях мы обсуждали ourobors и то, как дать возможность агенту переписывать собственное ядро так, чтобы ничего критичного не сломалось. Теперь давайте разберёмся откуда вообще берутся идеи для изменений.

У системы есть два режима эволюции. В первом, который называется free evolution, режиме агенту буквально ставят задачу улучшить себя: он инспектирует текущую реализацию, выбирает проблему, пишет изменение и после успешного review может запустить следующий такой цикл. При этом идеи могут браться из весов самой модели (которую кстати ouroboros может решить сменить на недавно вышедший флагман), из свежих статьей/интернета (опять же, ouroboros ничего не мешает написать для себя тул для похода на arxiv или reddit, даже если это не было предусмотренно изначально).

Но есть и более интересный режим — experience-driven evolution, где поводом для изменения становится обычная работа. В процессе выполнения задач модель наталкивается на какие-то проблемы с harness, будь то программные ошибки или работа инструментов не согласно ожиданиям. Сообщения о проблемах могут приходить и от пользователей.

Хороший пример — deep self-review. В какой-то момент такие задачи начали падать с ошибкой, похожей на недоступность модели. Вместо того чтобы добавить очередной retry, агент докопался до реальной причины: переполнялось контекстное окно. В итоге сборка контекста была заменена на bounded connectivity-aware context atlas: размер контекста под ревью ограничивается заранее, файлы ранжируются по centrality в import graph, а бюджет считается с учётом стоимости токена у текущего конкретного провайдера. В результате наиболее часто используемые и важные core-файлы с большей вероятностью переживают обрезание контекста. Этот fix после процесса review, который мы обсуждали в прошлом посте стал частью harness’а и начал использоваться во всех следующих задачах.

Другой пример: Hope периодически отправлял один и тот же ответ дважды. После фидбека от пользователей агент нашёл проблему и исправил её. Здесь исходным сигналом была жалоба человека, но дальше она прошла тот же путь: fault —> root cause —> structural change —> reviewed commit. Похожим образом улучшался и benchmark harness. Аудиты вскрыли reward hacking в Terminal-Bench, leakage reference solutions в SWE-bench Pro, неправильную filesystem isolation в GAIA и remote-state drift в OSWorld. После рефлексии и самоисправления результаты, как мы знаем, превзошли все ожидания.

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

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

Правд много, истина — одна

Наткнулся на интересную работу Константина Крестникова из Сбера на тему того, почему LLM вообще способны вычленять правильный сигнал из противоречивых данных. Ведь в интернете хватает и правильной информации, и утверждений про то, что 2+2=5, гомеопатия работает и так далее.

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

Проверяется следующим образом. Модели с нуля обучают на противоречивом датасете: одна и та же задача встречается и с правильным, и с неправильным решением. Если ошибки случайные, модель всё равно начинает предпочитать правильную математику. Причём эффект сохраняется даже когда правильных примеров всего 10%, а ошибочных — 90%.

Но всё меняется, если ошибки сделать согласованными. Например, ввести отдельную "математику", где распределительный закон всегда работает как a(b+c)=ab+c. Такая система неправильна с нашей точки зрения, но сама по себе столь же последовательна и компактна. И тут предпочтение истины практически исчезает: для модели обе системы оказываются примерно одинаково хороши.

То есть LLM, похоже, ищет не истину как таковую, а хорошо сжимаемую закономерность. Случайная ложь проигрывает, потому что её трудно сжать. Как говорит сам Константин: "Спасает то, что настоящие фейки редко бывают согласованными до конца". Впрочем, благодаря AI это скоро может измениться.

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

@experimentality