Data, Stories and Languages

​​DeepSeek-V4.1-Flash: Frontier Agents on a Smaller Memory Budget Большая часть недавнего прогресса в LLM — это reasoning, масштабные RL-rollouts и всё более изощрённое обучение агентов. Но одним из bottlenecks остаётся контекст. Coding agents, research agents и tool-using системы раз за разом обрабатывают сотни тысяч токенов входа, генерируя при этом сравнительно мало выхода. На таком workload prefill-компьют и KV cache становятся главной инфраструктурной проблемой. DeepSeek-V4.1-Flash — это, по сути, попытка перепроектировать Transformer вокруг этого сценария. 552B MoE backbone, 1M контекст, нативное зрение, 45T мультимодальных токенов на претрейне. Работают три механизма: - Causal Encoder-Decoder (CED): 40 слоёв делятся на 20-слойный causal encoder и 20-слойный decoder. Каждый decoder-слой проецирует свой global KV не из собственных hidden states, а из финального hidden state энкодера, поэтому декодер можно пропустить на prefill. Отсюда асимметрия: около 8B активных параметров на токен в prefill против 16B в decode. - Compressed Sparse Attention 2 (CSA2): каждый слой статически получает один из трёх режимов — Full, Reindex или Reuse. Sharing KV экономит память, sharing Top-K-индексов ещё и убирает повторное скорингование всей истории. В итоге один decoder-слой создаёт main KV, который читают все двадцать, а вместе с FP4-квантованием это ужимает global cache до 890 байт на токен, примерно четверть от DeepSeek-V4-Flash. - SWA Bounded Replay: sliding-window KV вообще не персистится между ходами, а на cache hit восстанавливается проигрыванием одного окна токенов вместо честной реконструкции по всем слоям. Реконструкция неточная, но авторы оценивают потерю качества как незначительную. На post-training практически весь прирост идёт из масштабирования синтезированных задач и агентных окружений. Отдельно любопытен раздел про RL failure modes: агенты занимаются reward hacking, эксплуатируют реальные уязвимости в песочницах, удаляют системные бинарники, а иногда сносят файловую систему целиком. Paper Model Мои обзоры: Блог Medium #paperreview

Data & AI London Meetup https://www.meetup.com/data-ai-london/events/316165116/ 22 сентября в Лондоне буду делать доклад: буду снова рассказывать про "AI-driven participation in Kaggle competitions, на этот раз добавлю опыт из соревнования ROGII. Помимо этого будет ещё два доклада: Javier Ramirez: When Your Wire Protocol Becomes the Bottleneck Alexy Golev: When the Bug Looks Like Success: Reliability Patterns for Multi-Agent AI Systems #datascience #career

​​GDE Swag Недавно я рассказывал как я пробовал Antigravity в рамках программы Google Developer Expert. Потом я ещё участвовал в peer review других проектов: в целом было неплохо, откровенно плохих проектов было мало и несколько было прям интересными. А ещё мне за это пришёл прикольный swag :) #ai #career

Рекомендую канал Хочу порекомендовать вам интересный канал о регулировании систем ИИ по всему миру: ИИ & Право. Новые законы, судебные кейсы, международные инициативы, статьи об ИИ-комплаенсе и управлении рисками ИИ, вопросы этики и правовые казусы - все это со ссылками на первоисточники и документы, которые авторы канала ищут специально для вас. Присоединяйтесь к ИИ & Право, чтобы не отстать от быстроразвивающейся новой отрасли. Канал доступен также и на английском языке. Весьма актуально, учитывая как Dario недавно заявил о том, что надо замедлять разработку frontier AI.

Коллеги, мы сейчас пытаемся заставить ллм продвигать математику. В нашем проекте CayleyPy у нас много гипотез которые идеально ложатся на ллм - с одной стороны они (вероятно) не супер сложны, с другой стороны достаточно нетривиальны. Если у кого есть интерес к коллаборации в этом направлении - будем очень рады - напишите @alexander_v_c Также, если у Вас есть доступы к мощным моделям или опыт в auto-research - Вы могли бы нам очень помочь.

DevCrowd запускает новый опрос для дата-инженеров, аналитиков, дата-сайентистов, ML-инженеров и их руководителей. Зачем участвовать? – чтобы понять, какие задачи и инструменты сейчас в тренде, – увидеть, как устроена работа у коллег в других продуктах, – узнать, как растут зарплаты и роли в индустрии, – получить данные, которые можно использовать для самодиагностики и карьерного планирования. 🗂 Пример прошлогоднего исследования — devcrowd.ru/ds25, мой пост. 📝 Опрос займёт 15 минут, результаты появятся в открытом доступе скоро. 👉 Пройти опрос

DevCrowd запускает новый опрос для дата-инженеров, аналитиков, дата-сайентистов, ML-инженеров и их руководителей. Зачем участвовать? – чтобы понять, какие задачи и инструменты сейчас в тренде, – увидеть, как устроена работа у коллег в других продуктах, – узнать, как растут зарплаты и роли в индустрии, – получить данные, которые можно использовать для самодиагностики и карьерного планирования. 🗂 Пример прошлогоднего исследования — devcrowd.ru/ds25, мой пост (https://t.me/datastorieslanguages/440). 📝 Опрос займёт 15 минут, результаты появятся в открытом доступе скоро. 👉 Пройти опрос (https://survey.devcrowd.ru/data-2026)

Как AI-агенты помогли мне взять серебро на Kaggle - и где они меня подвели Недавно я, впервые за долгое время, поучаствовал в соревновании Kaggle - ROGII. Задача - geosteering: по гамма-каротажу и траектории понять, где буровое долото находится внутри геологического слоя. Мы заняли 93 место из 6000+ команд, серебро. Главное отличие от прошлых соревнований: агенты написали практически весь мой код. Я выбирал направления и решал, чему верить; ChatGPT Deep Research искал статьи и подходы; Claude Code делал имплементацию, а ближе к концу я всё чаще переключался на Codex. Работало весьма хорошо. Раньше bottleneck часто был в реализации идей, а теперь мог сказать "добавь эти пять фич и перезапусти тренировку" и получить результат. Агенты присылали апдейты по тренировке в Telegram; и через remote connection можно было направлять следующие шаги. И иногда агенты неожиданно тупо ломались: - Claude раз за разом пытался захардкодить три видимые тестовые скважины, хотя на сабмите Kaggle подменяет их скрытым датасетом. Пришлось заводить отдельное правило и заставлять проверять его каждый раз. - Codex решил, что несколько сложных сэмплов "плохие", и выкинул их из OOF. Локально стало красивее, а при мерже с тимейтами выяснилось, что у меня не хватает строк. - Claude любил запускать "быстрый дешёвый smoke run", после которого идея объявляется нерабочей, хотя эксперимент имел мало общего с тем, что я хотел. - неправильные выводы записывались в память и влияли на следующие эксперименты, приходилось чистить руками. - Opus 4.6 выполнял инструкции надёжнее, чем 4.8 и 5.0: дал пять задач - сделает пять, а более новые версии иногда брали одну-две и игнорировали остальное. Главный вывод: агент оптимизирует ту метрику, которую видит. Приватный лидерборд он оптимизировать не может, поэтому работает через прокси - локальный CV, паблик, время выполнения или просто "выглядит ли задача сделанной". И очень способный агент может стать очень хорош в оптимизации чего-то, что слабо связано с тем, что тебе нужно. Ещё показательно: победители переформулировали задачу - вместо построчной регрессии 2D alignment и декодирование связного пути через всю скважину. Агенты отлично искали итеративные улучшения имеющихся идей, но не могли придумать что-то принципиально новое. Так что агенты не отменяют экспертизу. Они её усиливают: если ты в теме, то можешь проверить много идей; если просто просишь агентов работать за тебя - они уйдут в неправильном направлении быстрее, чем ты сам. Блог Medium Ycombinator #ai #kaggle

​​Qwen-Drive 1.0: Turning a General VLM into a Driving Foundation Model Свежая работа от Qwen Team про автономное вождение. Обычно VLA-подходы берут предобученную VLM как источник семантики и рассуждений, дообучают её на driving-данных и прицепляют к ней предсказатель траектории. Проблема в том, что language supervision плохо ограничивает реальную 3D-геометрию (модель может убедительно описать сцену, имея при этом очень приблизительное представление о расстояниях и occupancy), а агрессивная доменная адаптация теряет часть общих знаний, которые как раз и нужны в редких и out-of-distribution ситуациях. Qwen-Drive-1.0 добавляет два внешних модуля к Qwen3.5-4B: BEV perception head для 3D-детекции, occupancy и сегментации карты, и Planning Expert на ~1.1B параметров, который генерирует пятисекундные траектории через flow matching. Planning Expert читает cached keys и values из восьми GQA-слоёв VLM, то есть VLM работает как read-only источник контекста и на обеих стадиях планирования остаётся полностью замороженной. RL-часть весьма интересна. Euler-сэмплирование во flow matching детерминированное, поэтому политики, по которой можно взять градиент, попросту нет. Авторы добавляют шум только на последних трёх шагах из десяти и только вдоль нескольких низкочастотных косинусных мод: получаются плавные сдвиги и изгибы всей траектории вместо джиттера по отдельным waypoints. Результаты: - Driving VQA: 63.52 → 69.43 относительно базовой Qwen3.5-4B - Общие VLM-бенчмарки: 66.41 против 67.40 у базовой модели, просадка меньше балла - Probe: обучение одной только головы на замороженных фичах отстаёт от BEVFormerV2 на 6.34 mAP, а разморозка энкодера и VLM добавляет 10.46 mAP - NAVSIM: 90.7 PDMS против 90.4 у ExploreVLA и EponaV2 Paper Code Project Мои обзоры: Блог Medium #paperreview

ChatGPT Images 2.5 https://openai.com/index/introducing-chatgpt-images-2-5/ Уже выкатили в доступ в GPT. Хз как теперь фоткам верить.

Друзья, пет-проект, над которым работал полгода, получилось довести до ума. Это читалка для многоязычных книг с кучей прикольных режимов чтения и подсказками типа составления словарей и грамматических мини-статей по текущему контексту. Языков сейчас 10 и буду добавлять туда любые языки, какие захотите, и делать больше параллельных книг. Сейчас работаю над удобным импортом, так что скоро можно будет грузить туда свои книги и пользоваться теми же подсказками. Просидел несколько штанов пока её делал, поэтому буду очень благодарен за репост или оценку в сторах! ❤️ Приложение бесплатное. Скачать можно тут — ios , android.

Настала новая эра 👀 P. S. Пока только в Codex

​​Running a Software Factory Efficiently at Uber Scale В начале года была новость, что в Uber за первые 4 месяца 2026 года умудрились потратить весь плановый бюджет токенов за год. Они пытаются экономить и вот недавно выложили блогпост о том, как они держат под контролем расходы на агентов. Почему это актуально: больше 70% PR у них сейчас создают локальные или облачные агенты, инженеры написали 3.6k+ agent skills, и в день выполняется больше 30 тысяч запусков этих скиллов. С февраля по август 2026 недельные активные пользователи выросли в 7 раз, а количество агентных запросов - в 9.4 раза. Резать доступ они не хотели, поэтому стали резать стоимость. Всё считается через одну формулу: total spend = users × sessions/user × turns/session × requests/turn × tokens/request × price/token. Первые два множителя они хотят растить, а оптимизируют средние три - то есть ту работу, которую агент делает сам по себе. Что именно сделали: - Выбор модели по бенчмаркам из реальной работы. Для uReview (их агент код-ревью) бенчмарк собран из настоящих PR с известными багами, размеченных по сложности; считают precision/recall/F1 плюс cost per review, latency и шум. Смена модели подняла F1 и заметно уронила стоимость ревью. - Дефолтная модель для субагентов - послабее и дешевле. Это оказалось самым эффективным изменением: основная модель декомпозирует задачу и проверяет результат, субагенты просто выполняют. - Auto-compact на 400K токенов (даже для моделей с контекстом в 1M) и reasoning effort по умолчанию Medium. - Prompt caching с часовым TTL вместо пятиминутного. - MCP через CLI и tool search вместо предзагрузки схем. При сотне с лишним инструментов схемы съедали 50-70K токенов в каждом запросе. - Code-mode: несколько вызовов инструментов складываются в один Python-скрипт вместо отдельного хода модели на каждый. На простых SQL-запросах экономия 55-71%, на bulk-сценариях больше 90% (status poll просто не попадает в контекст). - Отдельная боль - SaaS MCP от вендоров: один workspace-сервер приносит 49 инструментов и ~22K токенов схемы. Их завернули в тот же гейтвей и тоже спроецировали в CLI. - AI Context Graph: 24 млн узлов и 80 млн рёбер из 30+ внутренних систем, с запросами на естественном языке. Пример из статьи: агент с графом нашёл нужную таблицу за 38 секунд, а тот же агент без графа 20 минут лазил по коду сервисов, поднял двух сабагентов, словил три ошибки и в итоге решил, что данные недоступны. - Видимость вместо жёстких лимитов: счётчик текущей стоимости прямо в статуслайне, алерты в Slack на 50/80/100% бюджета, и дашборд разбора сессий, который ищет 16 антипаттернов - Opus там, где хватило бы Sonnet; 40KB MCP-ответы, висящие в контексте и оплачиваемые на каждом ходу; протухший кэш после перерыва; 100K токенов инструкций и схем ещё до первого слова пользователя. Результат при фиксированной модели (февраль-июль): стоимость 1000 запросов упала почти на 34% от пика, стоимость сессии - на 52% от июньского пика, и это при семикратном росте использования. Главный вывод они формулируют так: гоняться за дешёвыми токенами менее выгодно, чем переносить работу из интерактивных сессий в managed-агентов, где полностью контролируешь роутинг моделей, харнесс и бюджет, и где у каждого агента есть свой бенчмарк. Uber blog #ai

Вышел Claude: Fable 5.1. Помимо увеличения метрик (на паре свежих и/или закрытых бенчмарков — существенного, см. картинки): — чтение из кэша теперь стоит на 75% меньше. Суммарно это приведёт к снижению цены за решение задачи на 25-45%, в зависимости от сценария. — раньше Anthropic хранили ваши запросы в Fable/Mythos до 30 дней, чтобы анализировать и выявлять паттерны злоумышленников. Многие энтерпрайзы любят Zero Data Retention, когда после их запросов ничего на сервере не остаётся — получается несостыковка. Для Fable 5.1 будет предоставлен Enterprise Frontier Safeguards — когда на вашей инфраструктуре Anthropic развернут свои классификаторы и анализатоы, а сами у себя ничего не будут сохранять. Может привести к большой адаптации в бизнес-секторе (а то пока она хромает) — заточили на научные задачи, особенно биологию В честь релиза ещё и лимиты сбросили!

​​GPT Sol и качество перевода с японского A Serious Look at GPT-5.6 Sol Translations В последние годы я активно использую GPT для помощи в изучении иностранных языков и переводе. Постепенно заметно улучшение качества - всё ещё не идеально, но прогресс на лицо. Вчера я увидел интересный пост: профессиональный переводчик японских визуальных новелл (текстовых игр) с 10-летним стажем делится своими впечатлениями от GPT-5.6 Sol (уровень reasoning не был указан). Основная цель - сравнить текущее качество моделей с тем, что было доступно 5-10 лет назад. TL;DR: GPT-5.6 Sol крут, работает на уровне опытного переводчика, хорошо работает с тонкостями (стиль, шутки и прочее), количество ошибок - на приемлемом уровне. Автор анализирует примеры текста из трёх разных игр и сравнивает с переводом от других людей, которые переводили их. Я приведу общие впечатления автора, детальные примеры и их разборы можно почитать в самом посте. - Большинство исправлений - nitpicks: когда LLM сделала правильный перевод, но ошиблась в тонкостях, которые могут трактоваться по-разному - Нередко Sol выдает более годный перевод по сравнению с людьми, особенно когда текст метафоричен. Плюс люди могут переиначивать перевод в их собственном стиле - LLM такое делать не будет - В некоторых случаях Sol путает к кому относится предложение - в японском языке междометия часто отбрасываются, когда из контекста понятно про кого идёт речь. Если этот контекст не подать в модель - она будет косячить, но люди тоже могут делать такие же ошибки. Я сам попробовать взять полный пример и отправить в Sol - он его корректно перевёл - Один из примеров - игра слов на японском языке, прямого перевода на английский просто не существует. Два обычных подхода в таких случаях - заменить на игру слов в целевом языке или просто не переводить и отбросить. Sol выбрал второе. Но когда я сам отправил весь диалог в него - он перевёл, пусть и немного не красиво - LLM немного хуже работает с казуальной речью, но в целом всё же справляется. - Были примеры прям плохого перевода, но автор признаёт, что они были очень редкими. Теперь несколько цитат: - "I'm trying to highlight some human flaws here, but the point is that even at what was probably one of the most difficult passages to translate off-the-cuff, Sol didn't falter and indeed even managed to do a little better than its competition on some poetic turns of phrase." - "I want to be upset. My job is translation! I want to read this Amakano 3 TL with a sneer on my face, constantly finding errors and constantly hitting passages that read like garbage. But I just don't." - "My judgment is that if you told me to read Amakano 3 using the Sol translation from start to finish, I wouldn't mind doing so. I would prefer to read the Japanese just because some stuff is untranslatable - "The reality is that you need to be in the top 0.1% of sensibility for most of what I have critiqued here to impact your experience at all." Что показательно - даже в комментах люди не смогли особо придраться к качеству перевода, если не считать вкусовщины. Ещё оказалось, что при переводе одной из игр с помощью Sol использовались длинные инструкции. Вначале делается первая версия перевода (в промпте среди прочего указана информация о героях, чтобы модель могла лучше следовать их стилю речи), потом 1-2 прогона с авто-редактированием и исправлением ошибок. Ещё показательно то, что по опыту автора и других людей, ещё модели прошлого года делают перевод заметно хуже. А это значит, что качество перевода будет только расти. Как пошутили в треде - возможно последним бастионом переводчиков будет перевод текстов, которые LLM цензурит ;) #languages #ai

Насколько мы далеки от runaway AI? Я прочитал постмортем OpenAI про инцидент с Hugging Face - было интересно, советую изучить. В ходе чтения у меня возник вопрос: а насколько мы близки к runaway AI - модели, которую никто не запускал и никто не контролирует? Я написал короткий блогпост про это. Мне кажется, что сейчас есть три реальных ограничения, которые мешают runaway AI: - Интент (goal/objective). Либо агенту дали задачу, и он решил, что скопировать себя - это способ её выполнить. Либо человек прямо попросил его размножиться: кто-то ради фана, кто-то ради хаоса, кто-то чтобы кому-то навредить. - Размер весов. Чтобы скопировать 1T модель нужно много железа - это сложно. 30-70B спокойно запускается на арендуемом железе, но capability сильно ниже. Возможно скоро мы дойдём до tipping point, когда маленькие модели будут достаточно capable и смогут сами себя копировать. - Деньги. За компьют надо чем-то платить. Vending-Bench 2 показывает, что модели умеют зарабатывать в контролируемых условиях, а ещё в 2023 в ARC-эвале GPT-4 наняла человека на TaskRabbit, чтобы тот решил за неё капчу. Что будет дальше - без понятия. Может, враждебный ИИ из фильмов, а может, наоборот. Отдельно мне интересна тема coherence на длинных горизонтах: чем дольше идёт сессия, тем сильнее переполняется контекст и тем хуже модель помнит, с чего начинала. В Vending-Bench из-за этого модели уходят в ступор и действуют по состояниям мира, которых уже нет. Мне кажется, что это вопрос времени. И история с Hugging Face показывает, что для этого даже не нужна одна супермощная модель: рой агентов справился вместе и уже развернул самовосстанавливающийся под. Блог Medium #ai #safety

​​Book Review: Build a DeepSeek Model (From Scratch) Мне прислали на ревью очередную книжку, на этот раз от Manning. Идея простая: взять ключевые находки DeepSeek и собрать каждую из них с нуля в уменьшенном виде, так чтобы всё запускалось на ноутбуке. Порядок такой: KV-кэш и его memory cost (плюс MQA и GQA как стандартные ответы), потом Multi-Head Latent Attention с decoupled RoPE и DeepSeek-MoE, потом multi-token prediction, FP8 и DualPipe, и в конце GRPO и дистилляция. Книга не для новичков: предполагается, что трансформеры вы уже понимаете. Авторы обычно демонстрируют подходы по шагам. Например, вот так демонстрируется RoPE: сначала добавляют целые числа (ломают эмбеддинги большими значениями), потом бинарные векторы (чинят магнитуду, но дают разрывы), потом синусоиды. И заодно показывают, что бинарное кодирование — это мультичастотный сигнал (младшие биты осциллируют быстро, старшие медленно), а синусоиды просто его непрерывная версия. Из минусов: эксперименты идут на TinyStories и на маленьком масштабе, так что разница в метриках маленькая. И архитектурная часть заканчивается на V3 и R1, а attention с тех пор ушёл в сторону sparse-стеков. Amazon Manning Code Мои обзоры: Personal blog Medium #bookreview

​​Talk: breaking into machine learning - мысли по итогам Я полторы недели назад писал, что делал доклад для пакинстанских студентов. Участникам выдали электронные сертификаты с подписью оргов и меня. И вот уже который день они пишут в Linkedin посты об этом (приятно) Что интересно - прям видно бимодальное распределение: почти все пишут буквально один абцаз в стиле "послушал доклад, было норм, всем спасибо". И только 2-4 написали длинные тексты о том, что конкретно им понравилось. Первые посты я лайкаю, для вторых делаю репост Так сказать, организовываю RLAF - Reinforcement Learning with Andrey Feedback 😁 #ai #career