Сиолошная

Также во время обучения на задачах с инструментами начали применять подход как у OpenAI, когда рассуждения не выкидываются, и видны модели при генерации следующего вызова инструмента — смотрите картинку. Представьте что для ответа на первый запрос пользователя нужно вызвать 2 инструмента, и после этого дать ответ. При вызове второго модель будет видеть, о чём она уже подумал, а обычно это выкидывают, что приводит к значительной неэффективности использования токенов. Этот подход заставляет модель заново обдумывать всю проблему при каждом последующем вызове инструмента. После того как модель написала ответ и он вернулся пользователю, то цепочки рассуждений удаляются, история вызовов инструментов и их результатов остается сохраненной в контексте, так что модели видно, что она делала, но не о чём думала.

DeepSeek-V3.2: Pushing the Frontier of Open Large Language Models В конце сентября DeepSeek уже представили модель V3.2, но тогда она была с суффиксом Exp(-erimental). Сейчас же полноценный релиз, в котором нет архитектурных изменений по отношению к ранней версии (и базовая модель, предтренированная на куче текстов, остаётся той же), но в котором много работы проделано в двух направлениях: а) дальнейшее масштабирование RL для рассуждений / агентских задач б) пайплайн генерации синтетических задач для агентов. О них и поговорим. Авторы пишут, что сейчас на RL потратили больше 10% мощностей от затраченных на базовую модель. У R1 было меньше одного процента, у ведущих лабораторий эта цифра около 100% и больше. Пост-тренировка V3.2 включает в себя дистилляцию специализированных моделей — это когда для каждой задачи сначала обучают отдельную модель, предназначенную исключительно для конкретной области. В дополнение к задачам по написанию текстов и общим ответам на вопросы, есть ещё шесть специализированных областей: математика, программирование, общие логические рассуждения, общие агентские задачи, агентское программирование и агентский поиск. «Агентский» — это использующий инструменты (функции, которые модель может вызывать) и многоступенчатый, где для получения ответа нужно вызвать несколько функций. После подготовки специализированных моделей они используются для генерации домен-специфичных синтетических данных для дообучения финального чекпоинта. В таком случае финальное качество будет лишь совсем ниже, зато модель может делать сразу всё, что помогает в дальнейшем RL. RL во многом похож на тот, что уже делали раньше, но и в нём есть несколько интересных аспектов: — для определенных областей, таких как математика, применение относительно слабого штрафа за отклонение в «естественности» языка (по отношению к базовой модели, которая просто хорошо предсказывает текст) или даже полный отказ от него может привести к повышению производительности — помимо сравнения ответов / прогона тестов для математики / программирования, для остальных задач используется GRM — Generative Reward Model и специфичные рубрики, описывающие критерии оценки. Я делал детальный разбор GRM, читайте тут, если пропустили. — одна из больших проблем масштабного RL — это эффективность работы GPU. Многие фреймворки разделяют серверы на тренировочные и rollout-first, делающие генерации в параллель. И в силу разных причин так бывает, что первые ждут, пока вторые догенерируют часть ответов, чтобы сделать оценку. DeepSeek делают иначе: они генерируют сразу много вариантов, а затем разбивают их на маленькие батчи и делают несколько шагов оптимизации. Но эта практика неизбежно привносит поведение off-policy, когда обновления считаются не для текущей модели, а для неё в прошлом (после первого шага оптимизации модель уже не та же) — и в какой-то момент тренировка разваливается. Чтобы стабилизировать обучение, делают Off-Policy Sequence Masking — маскируют последовательности, которые отклоняются от исходной модели больше некоторого порога, если они хуже средней в группе генераций по оценке. (техническое описание: фильтруют по KL семплы с негативным advantage) — также для стабилизации сохраняют маски по токенам, полученные из-за применения top-p / top-k семплирования (которое ограничивает, сколько самых вероятных токенов мы рассматриваем из модели для генерации — таким образом очень маловероятные слова не генерируются). Это нужно для того, чтобы выровнять модели в режиме «как мы генерируем для оценки» и «что мы обучаем».

1) ChatGPT сегодня 3 года, урааа 🎉 2) я потихонечку начал писать в твиттер, вот вчера один из постов набрал 100 тысяч просмотров, и ещё несколько 1-2 недельной давности по 50-60 тысяч, и добил 1500 подписчиков. Подписываетесь, если вам не сложно: тык

Я сначала подумал, что это шутка, но нет — именно Nvidia заменили печально известную Enron в индексе SNP500. За 24 года вырвались в топ 🚀молодцы ребята

И ещё две картинки — сравнение TCO ($ в час за петафлопс вычислений) между Blackwell / TPUv7 и Vera Rubin / TPUv8. У TPU варьируется утилизация, в зависимости от которой TCO может быть более или менее выгодным, чем у Nvidia.

— Хотя Google закупает TPU через Broadcom и платит значительную маржу, она существенно меньше той маржи, которую Nvidia получает не только с продажи GPU, но и со всей системы, включая CPU, коммутаторы, сетевые карты, системную память и кабели. С точки зрения Google, это приводит к тому, что полный TCO на один чип TPU v7 в полной конфигурации на ~44% ниже, чем TCO сервера с Nvidia GB200. Это с лихвой компенсирует ~10% отставания по пиковым FLOPs. При этом из-за со-разработки TPU, LLM и всей системы вокруг Google может выжимать из железа утилизацию выше, так что даже реальные FLOPs могут быть выше. — У сторонних клиентов типа Anthropic нет этих преимуществ, но даже если они смогут выжать утилизацию всего лишь 15%, то TCO (с учётом маржи Google за предоставление доступа) уже сравняется с картами Nvidia. Однако SemiAnalysis дают оценку, что скорее всего удастся достичь утилизации в 40% из-за оптимизаций — то есть это будет гораздо выгоднее GPU (TCO меньше на ~52%). Бонусом упоминают, что в Anthropic работает как минимум один инженер, работавший над TPU на заре создания этих чипов. — вернёмся к OpenAI: они ещё даже не получили свои первые TPU, а уже сэкономили ~30% на всём закупках у Nvidia (выбили скидку, угрожая конкурентами). Это демонстрирует, насколько сильно преимущество TPU по соотношению «производительность в пересчёте на доллар TCO»: вы получаете выгоду от внедрения TPU еще до того, как подключите хотя бы один чип 😂 Стоит ли Nvidia переживать? Зелёные — всё??? — у Nvidia огромная ценность в открытой экосистеме, на которой построено куча всего подряд. Почти весь код для TPU закрыт, они не поддерживаются никакими библиотеками. Но Google хочет не отстать: прямо сейчас идёт работа по «нативной» поддержке PyTorch на TPU + огромные усилия кинуты на по поддержку TPU в движках инференса vLLM/SGLang (SemiAnalysis отслеживают репозитории и авторов изменений). Это делается в основном для Meta, у которой возник интерес к покупке TPU и которая не хочет переходить на JAX (ведь PyTorch — их детище). Но из-за этого условно через год вы сможете в одну кнопку разворачивать DeepSeek на TPU так же легко, как сегодня это делают разные сервисы с использованием GPU. И скорость будет выше, и цена меньше. — Хотя TPU v7 является настоящим конкурентом карт Blackwell, Nvidia снова наносит ответный удар с чипом нового поколения Vera Rubin. Rubin обеспечит огромный прирост производительности в вычислениях, памяти и сети, в то время как улучшения в TPU v8 будут гораздо скромнее в силу нескольких причин. Первая — это желание Google сменить партнёров на переправе, что приводит к изменениям в архитектуре, задержкам, большому количеству дополнительной работы. — Вторая — это активность Nvidia. Конечно вчерашняя самая дорогая компания мира не собирается проигрывать. Изначально у Nvidia была гораздо менее агрессивная цель для Rubin, но они подняли мощность с 1800 Вт до 2300 Вт, чтобы улучшить мощности ядер и скорость памяти. Это произошло во многом из-за паранойи Nvidia и конкурентного давления со стороны AMD и Google. Если это агрессивное увеличение мощностей в последний момент сработает, то TPU от Google превратится из конкурентоспособного решения в неконкурентоспособное (если судить по TCO) на момент выхода TPU v8, так как Google была слишком сдержанна в выборе архитектурных решений. Причём не исключена ситуация, что ТСО будет хуже даже для внутренних нагрузок (где нет маржи), не говоря уже про продажу наружу. На картинке: количество мощностей, производимых в год GPU Nvidia, TPU от Google и чипами AMD. У Nvidia рост конечно невероятный запланирован, что влечёт для нас более интересные модели и сценарии их использования.

Свежий материал SemiAnalysis про TPU, специализированные чипы от Google для обучения и применения нейросетей. По-моему, это один из самых длинных постов за всю историю, прочитал и выбрал главное. Перед прочтением важно узнать, что такое TCO (Total cost of ownership) — совокупная стоимость владения, включающая начальную цену покупки + все сопутствующие расходы за весь срок службы: затраты на внедрение, электричество, обслуживание, ремонт и даже убытки от простоев. В контексте ИИ-чипов низкий TCO означает, что вы получаете больше реальных вычислений за каждый вложенный доллар, даже если само «железо» не самое мощное на рынке. Итак: — Gemini 3 полностью обучена и развёрнута на TPU, собственных чипах компании. Для людей в твиттере это стало шоком, у Nvidia даже акции упали — но люди просто, как обычно, не знали, что и Gemini 2, и Gemini 1, и многие предыдущие модели тоже были обучены на TPU. Но TPU всегда существовали для внутренних нужд Google, никаких крупных внешних пользователей _почти_ не было. Теперь же Anthropic используют их для своих моделей Claude (в статье говорится, что части обучения были на TPU, в чём я немного сомневаюсь, но вот что инференс на них есть — 100%) — в октябре об этом было объявлено официально. — сейчас Google разворачивает TPU в сторону предоставления внешним пользователям, в том числе прямым конкурентам. В очереди за заказами находятся xAI, META и даже OpenAI, Anthropic используют их более полугода и сделали заказ на один миллион чипов на 2026й. Причём 400 тысяч из них пойдут напрямую в их датацентр, а не Google, они сами будут платить за установку и обслуживание (заплатят ~$10B за покупку), и ещё 600 тысяч будут в облаке Google (сумма сделки примерно ~$42B — обратите внимание на разницу). — На 3-й квартал 2025-го года вычислительные мощности Anthropic состоят лишь на 50% из GPU, на 20% из чипов Amazon Trainium (тут недавно как раз новый датацентр запустили) и на целых 30% из TPU. На бумаге TPU 7-го поколения чуть слабее GPU от Nvidia — почему же тогда все хотят их использовать? Дело как раз в TCO: Nvidia, как я уже говорил несколько раз, имеет сумасшедшую наценку в 300%. — Google тихо вмешалась и захватила лидерство по производительности в одной из сложнейших аппаратных задач — поистине впечатляющее достижение для компании, чей основной бизнес не связан (или, правильнее сказать, не был связан) с железом. Я недавно слушал подкаст, не помню какой, и там как раз обсуждали тему TPU: если бы рынок понимал спрос на чипы, то Google стоил бы на несколько триллионов больше, точно опережал бы Nvidia. Чипы вообще могли бы стать основным бизнесом компании. — С релизом Gemini 3 Google показали, что TPU прошли проверку масштабирования тренировки LLM. Компания делала большой упор на надежность, доступность и удобство обслуживания инфраструктуры. Они предпочли жертвовать абсолютной пиковой производительностью ради большего времени бесперебойной работы. Работа оборудования на пределе возможностей означает более частые поломки, что влияет на TCO. И вот у карт Nvidia с этим не всё так же хорошо. — Вот тут очень интересный инсайд от SemiAnalysis: они утверждают, что в OpenAI не завершали успешной полномасштабной тренировки для новой фронтир-модели со времен GPT-4o, вышедшей в мае 2024 года. Но для меня это странно — их автор пояснил, что GPT-4.5 не считалась фронтиром и/или не была успешной. Даже если так — формально они всё равно смогли _как-то_ отмасштабировать тренировку и побороть проблемы с надёжностью. В общем, пока непонятно.

😕🔪

На ночь глядя пост-саммари двух постов: от TheInformation и Financial Times: — Чтобы увеличить выручку ChatGPT, OpenAI использует стратегию, которую применяли корпоративные приложения Zoom и Slack для наращивания базы платных пользователей. Компания привлекает основную массу своих пользователей бесплатной версией чат-бота, а затем пытается убедить их работодателей оформить корпоративные подписки. — Сейчас подписчиками являются ~5% от числа еженедельных активных пользователей. OpenAI прогнозирует, что через пять лет около 8.5% от 2.6 миллиарда еженедельных активных пользователей чат-бота, или 220 миллионов человек, будут оплачивать тарифный план Plus. — Это кажется огромной цифрой, но у Netflix и Spotify насчитывается по 300 миллионов платных подписчиков. Office 365 от Microsoft, по разным оценкам, достигает 450 миллионов платящих пользователей. Я попросил GPT-5 найти информацию про среднюю месячную выручку с пользователя: у Netflix это $11.7 во всем мире и $17.2 в США+Канаде, что очень близко к двадцатке за ChatGPT, у Spotify $5.2. — (дальше все расчёты на основе HSBC в FT) исходя из совокупной стоимости сделок в размере до $1.8 трлн долларов, OpenAI идет к тому, что ежегодный счет за аренду дата-центров составит около 620 млрд долларов — хотя ожидается, что к концу этого десятилетия будет введена в эксплуатацию лишь треть от законтрактованных мощностей. — HSBC прогнозирует, что к 2030 году аудитория ChatGPT достигнет отметки в 3 млрд человек, что эквивалентно 44% взрослого населения мира за вычетом Китая. 10% пользователей OpenAI станут платными клиентами — Команда аналитиков HSBC также предполагает, что компании, разрабатывающие LLM, захватят 2% выручки рынка цифровой рекламы. По мне так это ооооочень консервативно (тут на неделе как раз OpenAI Shopping Assistant уже запустили). — Совокупные расходы OpenAI на аренду в период с текущего года по 2030 год составят $792 млрд, а к 2033 году вырастут до $1.4 трлн. — Если сопоставить прогнозируемую выручку и затраты, а также инвестиции от Nvidia / AMD / деньги на счету, то получается, что в период до 2030-го года включительно у OpenAI образуется дыра в бюджете в $200 миллиардов. И это, внезапно, выглядит как очень маленькая цифра — они уже суммарно привлекли ~60 за всю историю. $200 миллиардов сравнимо с годовой выручкой META или Google, и с прогнозируемой выручкой OpenAI после 2030-го. И это ещё в анализе не учитываются новые продукты, генерация видео, итд. Так что дыра может быть ещё меньше. Даже при текущих кажущихся супер-амбициозными планами и цифрами получается, что всё вполне закономерно. Ну, конечно, если верить, что OpenAI останутся топ-1 пользовательского сегмента и не сдадут позиций — Sama вперёд 🎉📈

Но этого всё ещё не достаточно, чтобы получить золотую медаль на IMO. Авторам приходится перейти к High-Compute Search, масштабируя вычисления как для генерации, так и верификации. Суть подхода вот в чём: создаётся и поддерживается пул кандидатов доказательств для каждой задачи, инициализированный 64 доказательствами. К каждому доказательству генерируется по 64 обоснования от верификатора. То есть 64x64=4096 обоснования/критики для каждой задачи👁 Затем на каждой итерации улучшений выбирается 64 доказательства с наивысшими оценками на основе средних оценок верификации. На первой итерации это просто все доказательства, потому что их и было 64, но дальше будет больше, поэтому нужно отсечение. Для каждого из выбранных доказательств случайно выбирается 8 анализов от верификатора, отдавая приоритет тем, которые выявляют проблемы (то есть имеют оценки 0 или 0.5). Каждая пара <доказательство от генератора — анализ от верификатора> используется для генерации одного улучшенного доказательства, которое затем добавляется в пул кандидатов. Улучшенное доказательство — это то же самое, что я разобрал выше: когда модель генерирует доказательство не с нуля, а на основе уже имеющегося + набора критики от верификатора. Этот процесс продолжается до 16 итераций или пока доказательство не получит все 64 максимальных оценки от верификатора, что указывает на высокую уверенность в правильности. Во всех экспериментах тут использовалась одна модель — финальный генератор доказательств, который выполняет как генерацию доказательств, так и верификацию (меняется только промпт). По итогу такая система может выиграть золото на IMO (поздравляем ребят с выигрышем AIMO? ждём решения от XTX Markets), но количество мощностей нужное для этого... нереально. На бенчмарках это конечно обходит все обычные модели, и даже специализированные системы (но не Gemini DeepThink, которая взяла золото летом). === Для не полностью решенных задач генератор обычно выявляет реальные проблемы в своих доказательствах, в то время как полностью решенные задачи проходят все 64 попытки верификации с максимальной оценкой. Это очень похоже на то, что рассказывали OpenAI про свою систему на IMO летом — мол, если посмотреть, то видно, что модель знает, что она не решила задачу, всё ещё есть недостатки.

И что на выходе? Для сложных задач с соревнований типа IMO модель часто не может сгенерировать исчерпывающие и строгие доказательства с первой попытки в рамках одной цепочки рассуждений. Когда это происходит, в блоке само-критики генератор распознает, что его доказательство неверно и/или неполно, но ему не хватает длины контекста, чтобы решить все выявленные проблемы за одну попытку. Вот тут DeepSeek пишут мало деталей, и можно прочитать двояко, одна из трактовок — это что цепочки рассуждений у модели больше 120 тысяч токенов. Это ОЧЕНЬ много. Я модель у себя понятное дело не запускал, но сегодня в твиттере видел один (1) твит, где человек скинул скрин, что модель думала 70 минут и у неё кончился контекст — так что возможно это правильная интерпретация. Представляете, сколько ресурсов надо на все итерации обучения, если для каждой задачи вы генерируете много-много цепочек по 100+ тысяч токенов? Чтобы обойти эту проблему, авторы пробуют применить последовательное уточнение с самопроверкой. Сначала генерируется доказательство вместе с само-критикой, а затем итеративно повторно запрашивает генератор, передавая ему его предыдущее доказательство и критику, что позволяет модели исправлять выявленные ошибки. Процесс продолжается до тех пор, пока генератор сам себе не поставит идеальную оценку или не достигнет максимального числа последовательных шагов. Нигде здесь верифиактор или тем более мета-верификатор не применяются. На картинке горизонтально — рост метрик в зависимости от количества итераций. Видно, что модель научилась дописывать/исправлять доказательства, и даже после 6 итераций (по 100 тысяч токенов каждая???) приросты ещё идут. Best@32 здесь — это оценка лучшего доказательства для задачи, когда было запущено 32 независимых потока, и в каждом из них было по несколько итераций улучшений; из всех них выбирается лучшее решение на основе собственной же оценки (не верификатора). Одна проблема с этим графиком — по оси OY качество выражено как оценка верифиактора, а не человека, и поэтому такой рост в целом говорит о том, что модель выучилась критиковать себя так же, как и верификатор, ибо их оценки сильно коррелируют.

Более конкретно, что делается: 1) для каждого сгенерированного на определённом шаге доказательства верификатор генерирует n независимых оценок и их обоснований 2) для тех случаев, где оценка 0 или 0.5 (то есть потенциально проблема, что-то неправильно или чего-то не хватает) генерируем по m мета-верификаций для подтверждения выявленных проблем. Анализ верификатора считается валидным, если большинство мета-оценок подтверждают его выводы ("да, все найденные проблемы реально есть"). 3) Для каждого доказательства мы рассматриваем несколько обоснований верификатора с наименьшими оценками. Если по крайней мере k таких анализов признаны валидными (критерий из пункта выше), всё доказательство помечается этой наименьшей оценкой. Если во всех попытках верификации не выявлено никаких проблем, доказательство помечается оценкой 1. В противном случае доказательство отбрасывается или передается людям-экспертам для разметки. Варьируя параметр k можно контролировать количество задач и доказательств, отправляемых людям на проверку. DeepSeek пишут, что в двух последних итерациях обучения этот пайплайн полностью заменил ручную аннотацию и стал автоматическим. Никакие задачи не передавались людям. Правда я не нашёл информации, а сколько всего итераций было, но не думаю, что больше 10 (или скорее даже 6-7). На каждой итерации сначала учат верификатор доказательств. Затем генератор доказательств инициализировался из этого верификатора и учился на генерацию доказательств. Начиная со второй итерации, верификатор инициализировался моделью, которая тренировалась (RFT) и на верификацию, и на генерацию доказательств. Такой процесс итеративного обучения — чередование улучшения возможностей верификации и использования их для улучшения генерации — создает устойчивый цикл, в котором каждый компонент продвигает другой вперед. GAN, for real.

На бумаге выглядит отлично, но если попробовать так сделать — то вы упрётесь в критическую проблему: когда генератору предлагается одновременно и сгенерировать доказательство, и проанализировать его, он склонен утверждать правильность, даже когда внешний верификатор легко обнаруживает недостатки. Другими словами, хотя генератор может улучшать доказательства на основе внешней обратной связи, он не может оценивать свою собственную работу с той же строгостью, что и специализированный верификатор. Это наблюдение побудило команду исследователей научить генератор доказательств честной само-критике. С точки зрения интерфейса работы генератора — мы слегка меняем выходной формат: во время обучения модель теперь приписывает в конце ответа блок критики В промпте используется та же рубрика, что и давалась людям в самом начале, и с которой учился верификатор, поэтому мы ожидаем, что формат критики будет одинаковый, включая оценку по критериям 0/0.5/1. Дальше снова запускается RL-тренировка рассуждениям, только функция награды теперь очень сложная. Используются всё те же критерии для форматирования + оценка верификатора, и сверху оценка мета-верификатора (та же модель с другим промптом) на основе само-критики модели. С учётом некоторых добавленных в формулу весов (см. в статье), такая структура вознаграждения создает такие стимулы во время обучения: — честное признание ошибок в само-критике вознаграждается выше, чем ложные заявления о правильности (потому что иначе мета-верификатор даст оценку ниже -> штраф). — наивысшая награда даётся за создание правильных доказательств и точное признание их безошибочности — хорошая стратегия для получения высоких наград генератором доказательств — выявить и устранить как можно больше проблем до завершения ответа. Авторы это не пишут явно, но мне кажется совмещение двух задач в одной цепочке рассуждений позволяет модели подумать наперёд о том, как она себя будет критиковать, и посмотреть под другим углом на потенциальное решение, сразу устраняя недостатки. Модель не может не думать про вторую задачу (само-критику), когда это явно требуется в промпте + за это даётся награда во время обучения. Как когда-то было в GAN'ах, верификатор и генератор создают синергетический цикл: верификатор улучшает генератор, а по мере улучшения генератора он создает новые доказательства, которые бросают вызов текущим возможностям верификатора. Эти сложные случаи — когда верификатор может не выявить проблемы с первой попытки — становятся ценными обучающими данными для улучшения самого верификатора. Чтобы улучшить верификатор, нам нужны размеченные данные о правильности для свежесгенерированных доказательств. Ручная аннотация хоть и является простой (по сравнению с полным написанием решений), становится все более трудоемкой по мере того, как задачи становятся сложнее, а ошибки — менее заметными. Чтобы повысить эффективность человеческой аннотации (люди делают больше полезной работы), авторы генерируют по несколько оценок верификатора для каждого доказательства, чтобы выявить потенциальные проблемы для проверки человеком. То есть на какой-то итерации мы берём набор задач, генерируем несколько решений (условно 10), для каждого генерируем по ещё 10 верификаций, итого по 100 проверок на задачу. И каждая требует работы огромной LLM на тысячах токенов! Но такое масштабирование генерации верификатором увеличивает вероятность обнаружения реальных проблем в сгенерированных доказательствах с ошибками. Один раз можно пропустить, два раза пусть тоже, а вот 10 раз подряд не заметить одну ошибку — вероятность куда ниже. При этом обратите внимание, какую работу будут делать люди: они будут проверять работу верифиактора по сгенерированным доказательствам. То есть это в точности то же самое, что делали для мета-верифиакции — а значит данные можно переиспользовать для улучшения каждой части пайплайна. LLM сможет лучше критиковать критику, которую пишет другая LLM, что приведёт к улучшению самокритики у генератора.

Итак, получили мета-верификатор. Что дальше? 🙂 а дальше мета-мета-верифиактор модель мета-верификатора, обученная критиковать неправильные ответы верификатора, добавляется в процесс его тренировки. Только теперь награда за правильный и неправильный ответ состоит из перемножения не двух, а трёх чисел: — то же самое за форматирование — то же самое за разницу оценки эксперта и предсказания модели — и оценка обоснования верификатора мета-верификатором. Если последний не смог найти недостатков — то всё чётко, никаких штрафов. Если нашел некоторые недостатки — верификатор получит лишь половину награды (потому что оценка обоснования 0.5). Если обоснование суперплохое, то будет нуль, самая маленькая награда. И кроме этого верификатор ещё одновременно обучается быть мета-верификатором, то есть он может и критиковать решения, и критиковать критику решений (в зависимости от промпта). Таким образом мы схлопываем 2 модели и 3 этапа обучения в одну модель, которая очень хорошая в оценке и очень редко галлюцинирует. Авторы пишут, что на отложенной выборке доказательств, не участвовавшей в тренировке, средняя оценка верификатора — по оценке мета-верификатора (😀) — улучшилась с 0.85 до 0.96, при сохранении той же точности в предсказании экспертных оценок для доказательств. То есть это не улучшило понимание того, какую оценку поставить, но улучшило понимание и глубину того, почему именно такая оценка ставится. Ну а дальше дорисовываем сову — теперь с сильным верификатором можно обучать генератор доказательств. Для тех кто потерялся — все описанные выше шаги делались на решениях, написанных голым DeepSeek-V3.2-Exp-Thinking из коробки, без дообучения, плюс на некотором количестве человеческой разметки. И вот сейчас можно начинать прокачивать эту модель, давая ей обратную связь, какие решения хорошие, а какие — плохие. Обучение происходит на тех же 17.5 тысячах задач из самого начала работы. Обратите внимание: ни для одного из этапов для этих задач НЕ НУЖНЫ полные решения/ответы/доказательства — мы получили какую-то часть от модели, затем попросили людей проверить их на адекватность быстрой оценкой. Это важно, потому что такая оценка гораздо быстрее создания решения с нуля — особенно в случаях, когда ошибки видны невооруженным глазом, и можно сразу сказать «это фигня, ставлю ноль». Ну вот мы обучили модель, можно на этом и закончить? Пойти померить метрики... и увидеть, что качество-то не фонтан. Когда генератору доказательств не удается создать полностью правильное доказательство с первой попытки — что часто случается для сложных задач с соревнований международного уровня — итеративная верификация и доработка могут улучшить результаты. Прямо напрашивается пайплайн: берём решение, делаем верификацию с поиском недостатков, делаем проверку мета-верификацией, отдаём генератору обратную связь и просим её учесть. Этот цикл можно повторять несколько раз, и главное он полностью автоматический, не требует вмешательства человека.

На этих данных запустили RL-тренировку рассуждениям поверх DeepSeek-V3.2-Exp-SFT с целью научить модель предсказывать оценку эксперта, глядя на уже написанное доказательство. Модели нужно самой научиться искать ошибки / пробелы, по которым можно прийти к правильному ответу. В системный промпт подавали рубрику — общее описание принципов разметки, по которым работали люди (то же описание, что я дал выше). В качестве функции награды использовали произведение двух величин: — бинарная 0/1 награда за форматирование ответа (чтобы из него можно было без проблем извлечь предсказание и произвести сравнение ниже) — модуль разности между оценкой эскперта и предсказанной оценкой (если предсказание правильное, то разность равна нулю, и штрафа нет). (для тех кто следит за математикой — это вычитается из единицы, так как мы тут умножать хотим, и получается что идеальный ответ превращает этот множитель в 1, а неправильный — в нуль) Кроме оценки в ответ модель должна написать обоснование (но оно никак не учитывается в тренировке — если текст есть, то за форматирование модель получает плюсик). Этот подход обучает модель угадывать оценки людей, но имеет всё тот же недостаток, что мы обсудили выше — он не обеспечивает контроля за выявленными проблемами. Верификатор может поставить условно 0.5 по совсем другим причинам, нежели человек, и сгаллюцинировать несуществующие проблемы, что подрывает доверие к нему. Чтобы решить эту проблему, авторы вводят.... мета-верификацию: вторичный процесс оценки, который проверяет, действительно ли существуют проблемы, указанные верификатором в обосновании, и оправдывают ли они предсказанную оценку доказательства. Если вы запутались: — DeepSeek-V3.2-Exp-Thinking нагенерировал много доказательств для некоторых задач — верификатор читает условия задач, сгенерированные DeepSeek-V3.2-Exp-Thinking доказательства, пишет обоснование и оценку — мета-верификтор проверяет, что верификатор не выдумал причины снизить или накинуть балл, не сгаллюцинировал. Как обучать мета-верификатор? Процесс точно такой же: 1) У нас уже есть первоначальный верификатор, который сгенерировал оценки для доказательств от какой-то модели 2) Математические эксперты оценили качество ответов верификатора в соответствии с рубрикой мета-верификации. В рубрике указано несколько типов ошибок проверки (неправильные переформулировки условий, неправильные расчёты, неправильный вывод, неправильное указание на ошибку, когда на самом деле ошибки нет), но главное что по итогу... нужно снова поставить одну из трёх оценок: 0, 0.5 или 1 в зависимости от количества ошибок в обосновании оценок. 3) На этих данных верификатор дообучается рассуждениям снова с помощью GRPO. К сожалению что для этого этапа, что для верификатора авторы не пишут, сколько часов ушло у экспертов на разметку, какой у них уровень экспертности (знаете, задачи на доказательство с международных олимпиад не каждый второй может отсмотреть и покритиковать), сколько это стоило и прочее.

DeepSeekMath-V2: Towards Self-Verifiable Mathematical Reasoning В DeepSeekMath-V1 был представлен GRPO — алгоритм, приведший к появлению рассуждающих моделей. И это было ещё до o1 от OpenAI, правда в очень узком домене (но именно из-за его наличия DeepSeek смогли так быстро выпустить R1). Сегодня разбираем, что придумали китайцы для v2, и в конце порассуждаем, обобщается ли этот подход за границами математики. GRPO и его аналоги, использующиеся для тренировки рассуждающих моделей, требуют набор промптов / задач и функций верификации ответа. Именно поэтому мы увидели такой большой скачок в качестве в доменах, в которых верификация простая и однозначная: математика и программирование; для первого можно сравнить численный результат или выражение с заранее заготовленным и проверенным, для второго — прогнать тесты и оценить работоспособность кода. Если ответ неправильный или тесты не прошли — наказываем модель. Однако этот механизм имеет три фундаментальных ограничения. Во-первых, он служит ненадежным индикатором правильности рассуждений — модель может прийти к правильному ответу благодаря неполной логике или «удачным» ошибкам. Методы вроде GRPO и его самые популярные вариации оперируют только ответами, и никак не проверяют цепочку рассуждений. Для меня это было одной из точек удивления: я не верил, что поощряя шаги, в которых есть очевидно неправильные части, не делая никакой фильтрации, можно прийти даже к качеству первых рассуждающих моделей. Во-вторых, метод неприменим к задачам доказательства теорем, где ответы не требуют получения численных ответов, а основной целью является строгий вывод. В-третьих, этот подход не развивает способность моделей проверять правильность своих выкладок — они очень часто лгут и «придумывают» объяснения для уже совершённых ошибок, как бы в оправдание. DeepSeek возвращаются в старые добрые времена, когда для RL тренировали Reward Model — отдельную модель, оценивающую генерируемые во время тренировки ответы. В R1 (и до этого, в DeepSeekMath-V1) они от неё отказались для экономии памяти, но видимо карточки из Сингапура в обход санкций США доехали успешно 😀 и память появилась. Эта Reward Model в рамках работы называется Verifier, или верификатор. На данном этапе будем считать, что она принимает на вход текст задачи X, доказательство (= решение) Y, дальше в ходе рассуждений модель оценивает/ищет недостатки и в конце присваивает одну из трёх оценок: — 1 для полных и строгих доказательств со всеми четко обоснованными логическими шагами; — 0.5 для доказательств со здравой общей логикой, но незначительными ошибками или пропущенными деталями; — 0 для фундаментально ошибочных доказательств, содержащих критические проблемы и пробелы. Чтобы этот верификатор обучить, авторы отобрали 17.5 тысяч задач, требующих доказательств, с одного сайта. Для этих задач сгенерировали по несколько решений недавно выпущенной DeepSeek-V3.2-Exp-Thinking. Поскольку эта модель не была оптимизирована для доказательства теорем и имела тенденцию выдавать краткие ошибочные доказательства, авторы побуждали её итеративно улучшать свои ответы (через промпт в духе «вот задача, вот ответ, улучши»). После этого из разных подкатегорий задач взяли какое-то количество решений и отдали экспертам на разметку с вышеописанным критерием. Людям не нужно было чётко указывать, что именно не правильно в доказательствах, как надо и не надо — просто ставить одну цифорку, 0, 0.5 или 1.

сиол где обзор на дипсик

Пока готовлю обзор статьи от DeepSeek — держите саммари интервью с Ilya (в целом, интервью вышло не самым интересным, наверное, самый большой апдейт для меня — что теперь SSI может выпустить/показать что-то до достижения суперинтеллекта)

В твиттере наткнулся на очень интересную статистику по длительности выполнения задач на SWE-Bench Verified и качеству разных моделей в этих срезах. Оказывается для каждой из 500 задач есть аннотация её сложности, вычисленной по примерной длительности выполнения. Оценка сделана вручную, но по очень простым критериям (отсюда), например, всё что больше 100 строк — в последнюю категорию. Над более объёмными задачами уже работают, в SWE-Bench Pro есть сравнение, там уже больше кода писать нужно (и качество, соответственно, меньше).

😳 ещё DeepMind свой фильм выложили (про путь компании и CEO Demis Hassabis к Нобелевской премии) https://www.youtube.com/watch?v=d95J8yzvjbQ