gonzo-обзоры ML статей

А вот очередная прикольная работа про хитрое управление контекстом через харнесс, позволяющее модели не работать с длинным контекстом. В недавней Context Language Models сама модель переписывала свой контекст как файл на диске. Здесь таки харнесс за это отвечает. Результат прикольный: качество обычно не проседает (и иногда даже растёт). Есть правда проблема со сбросом кешей и вероятным отсутствием денежной экономии в итоге. Кодовых артефактов авторы статьи не выложили, я попросил Клода собрать скилл, воспроизводящий описанный в статье подход, выложил сюда: https://github.com/che-shr-cat/short-context-agent Он учит агента двум вещам из статьи: большие файлы не грузить в контекст, а искать grep'ом и читать ограниченными окнами, и по ходу длинной задачи вести тот самый handoff brief из шести частей (цель, проверенные факты отдельно от гипотез, внесённые изменения, прогнанные проверки, тупики, план дальнейших шагов). Скилл подхватывается сам на длинных многошаговых задачах и больших входах, а сброс контекста остаётся за Claude Code — автокомпакция по его порогу, /compact или /clear руками; в любом случае хук плагина подкладывает brief обратно, и агент продолжает с того же места, а не раскапывает всё заново. Получается EoCC; SAC (сброс после каждого действия) в Claude Code не сделать, он есть только в референсном harness в репе — вместе с EoCC и baseline без компакции. Внимательно пока не тестил, возможны баги. PR'ы принимаются :) You don't need long context Peter Belcak, Saurav Muralidharan, Jindong Jiang, Yonggan Fu, Wonmin Byeon, Hanrong Ye, Ryan Angilly, Ali Taghibakhshi, Shih-Yang Liu, Siru Ouyang, Greg Heinrich, Pavlo Molchanov Paper: https://arxiv.org/abs/2611.05306 Review: https://arxiviq.substack.com/p/you-dont-need-long-context Code: N/A (unofficial re-implementation) Главное: Языковые модели справляются с долгими агентными задачами и большими документами в коротком окне контекста без потери точности. Для этого обвязка агента должна периодически переписывать историю в рабочую сводку для следующих шагов, а большие файлы читать через поиск по диску. ЧТО сделали: Предложили два режима работы обвязки агента: End-of-Conversation Compaction (EoCC, сжатие при достижении порога токенов) и Single-Action Compaction (SAC, сжатие после каждого действия). В обоих режимах диалог сбрасывается, в новую сессию переносится только структурированное текстовое состояние, а длинные файлы читаются через Bash-утилиты. ЧТО получили: Короткое окно контекста сохраняет или повышает точность на бенчмарках с длинным горизонтом и большими документами, а стоимость декодирования на GPU при переходе от 256K к 16K токенов падает до 7 раз. Даже при сбросе контекста после каждого действия Claude Opus 4.5 удерживает 70.2% решённых задач на SWE-bench Verified. ПОЧЕМУ это важно: Обучение и запуск моделей с окном 16K–50K вместо миллиона токенов кратно ускоряют декодирование и снижают расход памяти. Однако слабые открытые модели могут обваливаться, когда их многословные ответы исчерпывают жёсткий бюджет до завершения задачи. Сжимать контекст здесь: https://t.me/gonzo_ML_podcasts/4846

Зацикленные трансформеры в этом году стали уже общим местом, работ по ним, особенно в последние полгода, появилось столько, что непрерывно по несколько раз в день можно про это писать. Вот очередная работа, где попробовали разные стратегии зацикливания и, что интересно, нашли, что они применимы по-разному в зависимости от ограничений (флопсы или параметры). Тема с матрицей LoRA тоже прикольная. Но 149 страниц — это, конечно, издевательство. Будто реально уже LLM пишут для LLM, вручную это читать уже невозможно. How to Loop Your Transformer: Loop Scaling, Specialization, and Parallel Inference Chanakya Ekbote, Artidoro Pagnoni, Devendra Singh Sachan, Shruti Bhosale, Mike Lewis, Maryam Fazel-Zarandi, Shashank Rajput, Sujan Kumar Gonugondla Paper: https://arxiv.org/abs/2610.40325 Review: https://arxiviq.substack.com/p/how-to-loop-your-transformer-loop ЧТО сделали: Авторы предобучили плотные зацикленные трансформеры-декодеры (до 1B параметров и 32 циклов), чтобы сравнить зацикливание всех слоёв (Full-Stack Looping) и только средних (Middle-Stack Looping). Также они предложили общие низкоранговые адаптеры для циклов (Loop Matrix) и Normalized Shifted PLT — версию Parallel Loop Transformers (где состояния циклов сдвигаются к соседним токенам для параллельного декодирования), в которой эмбеддинг текущего токена и состояние предыдущего отдельно нормализуются через RMSNorm перед смешиванием. ЧТО получили: При фиксированном числе параметров лучше работает Full-Stack Looping, а при ограничении на FLOP — Middle-Stack Looping. На DCLM при 200M параметров (40 токенов на параметр, TPP) 4-цикловый Normalized Shifted PLT снижает биты на байт (BPB) до ~1.060 против ~1.087 у Original PLT и ~1.088 у бейзлайна без циклов. При 1B параметров двухцикловый Normalized Shifted PLT улучшает BPB (~0.86 против ~0.90 при 80 TPP) и точность на 8 задачах (~47.5% против ~46.1% при 160 TPP). ПОЧЕМУ это важно: Раздельная нормализация входов убирает деградацию при параллельном декодировании с несколькими циклами. При долгом обучении двухцикловые модели требуют до 1.4x меньше FLOP, чем бейзлайны без циклов, хотя реальное время генерации не замерялось, а эксперименты ограничены 1B параметров. Зацикливаться здесь: https://t.me/gonzo_ML_podcasts/4845

Про важность "хороших ракурсов" (как у JEPA) по сравнению с "плохими" (как у замаскированых токенов или предсказания следующего токена). При хороших ракурсах в обучении мелкая модель может обойти крупную. Proving and Improving the Platonic Representation Hypothesis with JEPAs Randall Balestriero, Yann LeCun Paper: https://arxiv.org/abs/2610.39302 Code: https://github.com/galilai-group/prh-proof Model: https://huggingface.co/spaces/galilai-group/prh_demo Review: https://arxiviq.substack.com/p/proving-and-improving-the-platonic ЧТО сделали: Доказали теорему о платоновских репрезентациях для архитектур JEPA (self-supervised моделей, сближающих позитивные пары без схлопывания эмбеддингов). Предложили JEPA с «хорошими ракурсами» — когда позитивные пары берутся из разных наблюдений одной сцены, а не из искажений одного и того же наблюдения («плохих ракурсов»). Также доказали, что авторегрессионное предсказание следующего токена математически устроено как JEPA с плохими ракурсами. ЧТО получили: На кросс-модальном бенчмарке WIT-1024 в паре с DINOv2 ViT-B текстовая JEPA на 109M параметров с хорошими ракурсами сравнивается по качеству с предсказанием следующего токена на том же корпусе, используя в 42 раза меньше обучающих примеров (mutual 10-NN: .109 на 21.6M примеров против .111 на 900M). При обучении на текстах к 940M веб-картинок модель достигает .184 по mutual 10-NN, обходя Qwen2.5-72B (.154), Llama-3-70B (.151) и текстовый энкодер CLIP (.124). ПОЧЕМУ это важно: Отдельные одномодальные энкодеры можно соединить одной ортонормированной проекцией для описания картинок (COCO CIDEr .838) или выровнять вообще без парных данных (64.4% против 47.6% у Qwen3-8B по top-5 точности на ImageNet-100). Однако выигрыш на веб-текстах опирается на ракурсы, сгруппированные по ID картинки и сгенерированные предобученной моделью описания изображений. Платон где-то там: https://t.me/gonzo_worlds/39

Есть такой забавный подход как синтетическое пред-предобучение, когда модель обучают на какой-то структурированной синтетике (клеточные автоматы, языки с балансированными вложенными скобками и т.п.), чтобы она заранее усвоила какие-то потенциально полезные структуры. Так вот, свежая работа показывает, что если честно учитывать все токены и флопсы, это ничего не даёт. Как только начинается обучение на естественном языке, оно нафиг перетирает все эти внедрённые баесы на правильные. Вспоминается анекдот про то, как потом пришёл муж и переделал всё по-своему. Ещё из забавного, это неплохо перекликается с работой этого года про то, что человеки используют неиерархические репрезентации языка там, где раньше думали про иерархические. Rethinking Pre-Pretraining Alexander Stern, Tim Rocktäschel, Acyr Locatelli, Laura Ruis Paper: https://arxiv.org/abs/2610.40051 Code: https://github.com/alexkstern/rethinking-ppt, https://github.com/alexkstern/llmtuna-hpo Review: https://arxiviq.substack.com/p/rethinking-pre-pretraining ЧТО сделали: Проверили, помогает ли синтетическое пред-предобучение (PPT) — предварительный этап обучения на процедурно сгенерированных последовательностях — при фиксированном бюджете FLOPs. Предложили синтетический корпус для поиска значений переменных DeclRef и оптимизатор гиперпараметров на базе LLM LLMTuna. ЧТО получили: Ни в одном из протестированных режимов с равным бюджетом вычислений PPT не обыгрывает обучение чисто на естественном языке. При дефиците данных (100M токенов FineWeb, 1 × 10¹⁸ FLOPs) повторение обычного текста даёт 1.064 бит на байт (BPB) на валидации, а выделение 1%–10% FLOPs на PPT ухудшает метрику до 1.068–1.076 BPB. При воспроизведении PPT на клеточных автоматах (NCA) для LLaMA на 400M параметров (OpenWebText) смена инициализации эмбеддингов с 𝒩(0, 1) на 𝒩(0, 0.02) улучшает перплексию бейзлайна без PPT на 9.0%, полностью перекрывая 5.4% выигрыша от NCA PPT. ПОЧЕМУ это важно: Предварительная подача синтетики впустую тратит вычисления: при переходе к естественному языку модель перезаписывает выученные структуры, а прежние успехи PPT во многом компенсировали плохую инициализацию весов. Впрочем, все модели здесь меньше 1B параметров, а тест инициализации LLaMA и эксперименты с перемешиванием данных проводились без повторного подбора гиперпараметров. Отказываться от синтетики тут: https://t.me/gonzo_ML_podcasts/4844

Для типовой переписки с разными организациями я тоже уже давно использую Claude/GPT, и это всё настолько эффективно с точки зрения потраченного времени (а удовольствия в этом процессе нет by design), что я не представляю уже отката назад. Технически от полного замыкания цикла меня не сдерживает уже ничего — только природная осторожность и желание оставить quality gates пока у себя. Про математиков я только недавно писал (https://t.me/gonzo_ML/6161), не буду повторяться. Ну и про разборы статей вы и сами знаете. Тут в самом процессе таки есть элемент удовольствия (как, впрочем, и в написании кода — мне всегда нравилось это делать, и наверняка я ещё выучу какие-то новые для себя языки, хоть на практике это уже и не особо нужно), но объёмы поставляемого (и теперь ещё и генерируемого) контента настолько выросли, что вручную этот процесс дальше просто нежизнеспособен. Не зря arxiv лимиты ввёл для графоманов (https://t.me/gonzo_ML/6059) 😁 Зато благодаря собранной агентной системе я могу как-то поддерживать свою (и, надеюсь, вашу) информированность о том, что интересного происходит, сохраняя при этом достаточную техническую глубину. В выходные пришла идея исследования: вместе с Клодом за вечер набросал план и код для экспериментов, на следующий день всё прогнал, получил первый результат (негативный) и понял, что идея, видимо, нерабочая. Ну и отлично, что быстро понял. В прошлой жизни я бы месяцами по вечерам и выходным писал этот код, и узнать в конце, что оно не работает, было бы сильно обиднее. Никогда ещё нельзя было так быстро итерироваться: отрицательный результат за сутки вместо квартала — это просто другая экономика исследований. Для меня текущий момент напоминает время 15 лет назад, когда появились массовые онлайн-курсы — тогда моментально оказалось, что (для тех, кто умеет учиться) эффективность обучения выросла на порядок. Сейчас такое же чувство, только уже не от обучения, а от всего сразу (хотя и обучение, кстати, снова выросло на порядок — благодаря возможности думать об агента и получать от него персонализированную поддержку). В общем, какой будет жизнь в следующем году, я не знаю. В чём уверен — многие работы трансформируются до неузнаваемости, а человек в них останется на постановке задачи (если она новая) и там, где стоят quality gates, — ну и там, где ему просто нравится (пока результативность бизнеса не страдает 🤭); похоже, главный вопрос следующего года — где именно эти гейты ставить. А к повсеместной доступности интеллекта на кончиках пальцев нам ещё привыкать и привыкать. Из даунсайдов. Жизнь стала быстрее, и deep work в ней стало меньше. В моём конкретном случае, наверное, не только из-за AI, но всё же. Дел больше, мультитаскинга больше, поток всего больше. И это сейчас главный челлендж, где надо всё перестроить. Времена напоминают пришествие мессенджеров и социальных сетей, когда тоже ритмы жизни изменились и надо было найти правильный способ существования со всем этим — когда читать, когда не читать; когда отвечать, когда не отвечать; что вообще там делать и как, и т.п. Тот же вопрос — где ставить гейты, только уже в собственной жизни.

Пост "За жызнь" Жизнь за последние полгода-год сильно изменилась. Во многом из-за AI. Начну с моих любимых программистов и машинлёрнеров. Я давно топил за то, что за программистами придут — например, вот тут в 2017-м в Forbes: https://www.forbes.ru/tehnologii/341535-mashiny-vmesto-inzhenerov-pochemu-iskusstvennyy-intellekt-doberetsya-i-do — и сам пробовал заставить модели писать код чуть ли не с первых версий, где это вообще имело смысл, но ничего законченного долго не выходило (копи-паст отдельных кусков в chatgpt не считаю, хотя уже тогда он многим заменил stackoverflow). Первые сколь-нибудь законченные проекты у меня начали получаться на границе между 2024-25 годами — и это, подозреваю, и есть момент, когда модели перешли порог, а не я осмелел. Так, в январе 2025 на курсе по AI Safety я делал курсовой проект про интерпретируемость моделей (https://gonzoml.substack.com/p/not-all-layers-are-equal) и решил делать это через Gemini и Claude. Модели нормально собрали мне код трансформера, интервенций и визуализации активаций. Правил я только что-то по мелочи. Весной 2025-го я написал MCP сервер для переводов через Intento (https://github.com/intento/mcp-intento-translate). Это был локально запускаемый MCP с транспортом через stdio, ну как примерно большинство MCP в то время и работало. Там я решил, что принципиально не буду писать ни строчки руками; пользовался Cursor и, кажется, каким-то из Codex или Claude. К декабрю 2025 я решил переделать MCP сервер на Streamable HTTP transport (там как раз и один из клиентов это захотел) и сделать его полноценным продакшн веб-сервисом. Часть про продакшн как обычно оказалась сильно более объёмной, чем собственно новый транспорт — все требования к продакшну, включая логгирование, мониторинг, требования к безопасности, нагрузке, обработке ошибок, деплою, и т.д., добавили больше кода, чем всё остальное. Попутно освоил speckit. Результат мне понравился, подход speckit тоже, для greenfield работало отлично. Делал через Cursor и Codex. С тех пор продолжаю развивать (и даже уже не в одиночку) в основном через Claude Code, не используя speckit напрямую, но пользуясь подходами, которые устаканились в этой репе (спеки в понятном формате с декомпозицией, тесты перед имплементацией, ADR к принятым решениям и т.п.). Параллельно в том же 2025-м было несколько экспериментов, когда я пытался применять модели для работы с нашим платформенным кодом, первую версию которого ещё десять лет назад я сам писал вручную. Платформа с тех пор знатно эволюционировала, появилось много нового кода, который я не писал и даже не читал (но какие-то куски в ядре ещё остались с моим кодом, который продолжает успешно работать). С таким brownfield у моделей выходило не очень — понимания у них не хватало, про зависимости с другими сервисами и репами они толком не знали, получалось так себе. Пробовал на относительно маленьких задачах про багфиксы и небольшие новые фичи — модели делали не то. Те, кто day-to-day работал с этим кодом, могли их укрощать, давая весь нужный контекст, но аутсайдеру, который постоянно в этой репе не живёт, было грустно. Тогда я списал это на brownfield как таковой; как выяснилось позже, дело было не в brownfield, а в том, что контекст лежал у людей в головах, а не там, где его могла взять модель — об этом ниже. В апреле 2026-го я написал статью (https://arxiv.org/abs/2604.21999) про эксперименты с издавна мной любимым universal transformer (ныне также известным как looped transformer) с памятью (другая моя давняя любимая тема), и здесь я не только писал код (https://github.com/che-shr-cat/utm-jax) моделями внутри Antigravity, но и гонял оттуда же эксперименты на TPU в GCP. Агентский режим в AG я тогда не трогал, гонял просто из параллельно запущенных терминалов — и до сих пор люблю такой режим работы в том же Claude Code CLI (а свежий AG, где терминалы и код запрятаны куда-то далеко, мне пока так и не зашёл). Всё, что я делал, по сути — генерировал идеи, выбирал интересные для реализации, делал ревью планов и результатов, корректировал по ситуации. Самое узкое место в том процессе было вообще за пределами всего этого — это была аллокация TPU, которые были почти тотально заняты, особенно свежих поколений. Но главное случилось за последние полгода. Если полгода назад какую-то очень заметную, наверно даже большую, часть кода мы писали руками, то сейчас его пишут модели: люди дают задачи и ревьюят (спеки, планы, тесты, код), руками не кодит уже вообще никто. Для этого пришлось основательно поработать с foundations (и мы ещё не закончили) и сделать так, чтобы моделям были доступны все необходимые артефакты: доки (в репах и через MCP к конфлюенсу), стандарты и ADR (в репах), задачи (сначала в JIRA, потом в Linear), логи с продакшн систем (MCP), а если надо, то и переписка в слаке. В целом всё то же, что нужно новому человеческому разработчику, приходящему в новый проект, нужно и моделям — и ровно этого им в прошлом году у нас и не хватало. Как и у всех остальных, наши боттлнеки сместились. Написание кода больше вообще не боттлнек, а вот чтение и ревью — да: первичное ревью тоже делают агенты, но финальное чтение всё равно человеческое, и вот оно теперь и трещит. У всех запущено по несколько агентских сессий: пока в одной агент что-то пишет или проверяет, в другой можно почитать свежие простыни. Разные loops внутри большого engineering loop продолжают замыкаться на агентов (кроме написания кода это код ревью, подготовка документации, релизные документы, тесты, ...), сам этот большой loop тоже всё ближе к автономному процессу, куда человеку нужно заглядывать только в определённых точках, где стоят quality gates с аппрувом на движение дальше. Эту трансформацию мы продолжаем, как и трансформацию всей компании в AI-first. Это вообще отдельная история. В следующем году автономности будет больше, контроля меньше, разработчики уйдут вверх по цепочке добавленной стоимости — ну, про это и так только ленивый не писал. Интереснее то, что открылось по дороге: например, шоппинг языка — теперь можно выбирать язык под задачу, а не под то, что умеет команда. Мы начали эксперименты с Rust — в старой парадигме ручного кодинга мы об этом даже не мечтали, в лучшем случае на Go что-то хотели переделать. Первый кандидат — вспомогательный сервис-эмулятор реальных апишек со всеми их возможными проблемами, в который упирались наши перф-тесты: его переписали на Rust (а заодно на Go и Node, с parity-тестом на все четыре реализации, чтобы было с чем сравнивать), и в том же 100-мегабайтном поде он держит в 2,6 раза больше открытых соединений, чем питоновский оригинал (~8,900 против ~3,400), а в idle занимает 1 MiB вместо 33. По дороге там выкинули hyper и написали свой HTTP/1.1 слой на 400 строк с wire-тестами. Цифры пока с локального стенда, но порядок понятен. Что интересно, гошный сервис в такой имплементации оказался не особо лучше нашего старого питоновского (лишь на 11%, и то после замены net/http на fasthttp, а на стандартном net/http — вдвое хуже). Наверное, есть ещё куда улучшать, но всё равно в ручной парадигме на такое для вспомогательного сервиса никто бы и недели не выделил. Ну и это, конечно, не только с кодом происходит. Вот есть у меня бухгалтеры, ведущие одну компанию. Каждый год при сдаче отчёта я сажусь перепроверять, что они мне собрали, и почти всегда нахожу ошибки, иногда довольно дурацкие. В этом году вместо меня это сделал Клод — причём вышел за пределы проверки отчёта и нашёл даже то, что я и не думал челленджить, всё с отсылками к конкретным законам, трактовкам и рекомендациям (отсылки я проверил, всё сошлось). А потом нашёл ещё один пропущенный мной неправильный расчёт за прошлый год, который добавил мне налога. И один потерянный возврат от налоговой за этот год (который я, может быть, и нашёл бы, но не так быстро). И сделал он всё это за один вечер. То есть quality gate переехал: раньше я проверял бухгалтеров, теперь Клод проверяет и их, и меня. В следующем году, подозреваю, такими темпами этот цикл замкнётся и без них. Клод цену своей подписки уже многократно отбил, бухгалтеры же — не уверен.

Интересное https://rikiyat.github.io/blog/weight-space-programming/