AI Projects

ИИ бизнес Маска оказался на удивление инвесторов очень успешным. Больше половины выручки SpaceX пришло от ИИ, а не спутников. Причем ИИ бизнес у Маска и прибыльный.

На фоне таких новостей SpaceX снова подорожал выше $2 триллионов долларов.

https://techcrunch.com/2026/10/20/spacexs-ai-business-is-beating-expectations/

The Information пишет о том, что китайцы одержимы идеей сбросить ярмо Nvidia на обучении LLM. Для этого значительная часть инженеров Huawei переехала в офис DeepSeek, где инженеры DeepSeek и Huawei работают над тем, чтобы новая версия DeepSeek обучалась полностью без Nvidia GPU.

Сейчас инференс у DeepSeek оптимизирован и под Nvidia, и под Huawei — это видно по библиотекам, которые они опубликовали недавно. На обучении китайцы пользуются инференсом агентов по подготовке datasets и для критиков RL-обучения, но изменение весов идёт больше на Nvidia GPU. Около двух лет DeepSeek с Huawei вместе переписывают весь софт Nvidia для обучения под китайские чипы. Усиление ИИ в способности более-менее легко портировать алгоритмы с платформы на платформу им на руку.

Тем не менее, похоже, в 2027 году Китай реально будет 100% суверенным в ИИ по всему циклу — от создания моделей до GPU. В России сохраняется зависимость от серых поставок Nvidia из США.

https://www.theinformation.com/articles/deepseek-shaping-huaweis-ai-chips-growing-challenge-nvidia

В сети уже разгоняют хайп, что Anthropic — это «пузырь» судя по его проспекту на IPO с ожидаемой капитализацией $1,5–$2 триллиона долларов, где «неожиданно» вскрылся бухгалтерский убыток в $80,7 миллиардов долларов, который сделал Anthropic формально снова убыточным, причём сильно. Парадокс в том, что этот убыток как раз говорит об успешности Anthropic и какие дураки инвесторы, которые не вкладывались в него.

Убыток возник из-за «конвертируемых облигаций» Anthropic, через которые он занимал деньги. По условиям их погашения кредиторы имеют право выбрать: получить деньги или же забрать акции Anthropic по фиксированной цене выпуска. Однако вопрос в том, что эта фиксированная цена предполагала, что Anthropic стоит в 10+ раз меньше, чем стоит он сейчас даже по пессимистичной оценке. Поэтому кредиторы, конечно, откажутся от бумажек как доллары и возьмут акции, заработав на этом сверху $80,7 миллиардов долларов относительно тела долга и процентов. По стандартам GAAP такая операция отражается как убыток компании, т.к. кредиторы получают от компании более ценное имущество, чем средства их займа.

Сам по себе Anthropic в части инференса прибыльный весь 2026 год. Однако более 50% его затрат в реальности — обучение фронтирных LLM. Если добавить затраты Anthropic на обучение Claude, то операционный убыток за 2026 будет около $9 млрд. Причём Anthropic не рассчитывает, что сможет конкурировать с теми же китайцами без массированного вложения в обучение моделей, поэтому уже заключил контракты на $450 млрд (в основном с Google, AWS и Microsoft) на 7–10 лет вперёд без права отмены. Компания исходит из того, что при её более чем 15-кратном росте выручки в год это не проблема.

Проблемы, конечно, есть. Если китайцы уже доминируют на мировом рынке инференса в терминах токенов. Если их модели будут просто good enough для решения практических задач клиентов, то Anthropic будет сложно продавать свои фронтиры. Второй аспект — что на случай мощной рыночной коррекции тот же DeepSeek устойчивее Anthropic, т.к. его маржа с инференса около 80% уже сейчас, а затраты на обучение у китайцев намного более оптимизированные, чем у американцев. Финишное обучение LLM у DeepSeek или Xiaomi — всего несколько миллионов долларов аренды GPU. Подготовка же dataset агентами и сами агенты-критики в RL-обучении китайцам достаются очень дёшево из-за их дешёвого инференса.

Проще говоря, если прямо сейчас остановить инвестиции, то тот же DeepSeek и Xiaomi забирают весь рынок у Anthropic и OpenAI, если какой Microsoft или Google не согласится оплачивать счета последних. Однако это маловероятно: достаточно взглянуть на кривую потребления токенов на том же OpenRouter, чтобы заметить, что потребление их растёт по экспоненте. Также Anthropic окучил незначительную часть всех потенциальных клиентов (несколько процентов от общей ёмкости), поэтому намного более вероятно, что Anthropic будет стоить около $2 триллионов долларов, что примерно 1/2 годичного ВВП России.

https://www.wsj.com/tech/ai/anthropic-revenue-growth-ipo-accaf0f1

Yandex присоединился к Anthropic в его ужастиках, что ИИ ботнет запустится в ваших умных пылесосах и скороварках.

Яндекс сослался на похожий проект Petals. Хотя горячие головы блоггеров уже стали писать, что распределённый инференс едва ли не замена ЦОД, но в реале Anthropic смог добиться для SLM уровня Gemma где-то 1/2 токена в секунду. У Petals нужно несколько секунд на 1 токен.

Довольно очевидно, что даже если ИИ будет создавать ботнет, то предпочтет игровые GPU.

https://x.com/yandexcom/status/2112561449528963424

🧮 Русские математики решили усилить панику от ИИ у математиков в США и Европе. Хотя OpenAI довольно давно выложил свои 722 работы по математике, американские и европейские математики, чтобы снизить «эффект разорвавшейся бомбы», просто стали уклоняться от верификации работ ИИ. Фактически это делалось под мантры «это же нейрослоп, а не математика!»

Илья Биндер, Олег Иврий, Иштван Праузе и Станислав Смирнов в своей научной работе подтвердили, что сделанное ИИ решение гипотезы Бреннана, которую кожаные математики не могли решить с 1978 года, корректное. Математики отметили, что уровень доказательства ИИ даже избыточный для принятых стандартов в математике для людей и доказательство можно сделать короче.

Станислав Смирнов — это последний русский математик, получивший Филдсовскую премию в 2010 году. Хотя он работает в Женевском университете, но известен тем, что встречался с Путиным для организации Президентской программы поддержки учёных.

https://arxiv.org/abs/2610.23853

Слухи о смерти Reinforcement Learning from human feedback (RLHF) оказались несколько преувеличенными.

В 2026 году практически все вендоры основное RL обучение делают в духе "ИИ учит ИИ". Старые толпы студентов фрилансеров для RL-обучения давно уволили.

Однако сейчас работа в RLHF стала элитарным занятием. Как насчёт $400 в час за поучить бота? Такая высокая ставка связана с тем, что вендоры LLM вызывают выдающихся учёных или адвокатов для оценки ответов ИИ.

Вероятно мы сейчас ещё один скачок качества ИИ увидим от этого тренда.


https://www.bloomberg.com/news/articles/2026-10-16/ai-training-jobs-are-attracting-doctors-lawyers-and-engineers

The Information написал статью, что стратегия делать тяжёлых фронтиров у Anthropic и OpenAI начала давать сбой. Разработчики массового переходят на модели среднего класса для worker агентов. Однако поскольку LLM для них типа DeepSeek сильно поумнели и в 50 раз дешевле, то стали "давить снизу".

В целом, это не новость на всех шлюзах с несколькими провайдерами LLM давно по объему токенов лидируют китайские модели как DeepSeek, а в реальности доля того же Anthropic в токенах около 5% рынка, просто за счёт цены в 50 раз выше он эту долю в деньгах увеличивает почти до 50%.

Однако The Information отмечает, что эта стратегия фронтиров стала трещать не только из-за того, что тот же DeepSeek поумнел, а что разработчики поумнели и теперь умеют управлять моделями лучше.

Преимущество в 10 баллов рейтинга по интеллекту теперь приносит лишь на 20% больше трафика от разработчиков, по сравнению с почти 69% в конце 2025 года.

Проще говоря, для многих агентов good enough планка для LLM снизилась за счёт фреймворков промтов или обвязок, поэтому дорогой фронтир стал не так нужен.

https://www.theinformation.com/articles/leading-edge-ai-models-losing-allure-developers

DeepSeek открыл бесплатно до конца месяца свое API для поиска. Надо внимательнее посмотреть стал ли доступен теперь поиск, что DeepSeek использует в чате, там довольно инновационная система со специальным ранжированием для ИИ. Я публиковал не описание по научным работам. Возможно открыли.

Должно работать в DeepSeek Harness.

https://api-docs.deepseek.com/guides/search/

🔬 Интересная ещё работа по использованию тестов в обучении LLM, где доказывается, что применение unit-тестов «в лоб» на GRPO-обучении приводит к деградации модели.

Главный вклад статьи — это аудит обучающей динамики unit-test-only RL (GRPO). Авторы показывают, что такая награда не просто позволяет обходить тесты, а обучение через тесты целенаправленно формирует дополнительное вредное поведение:
• Рост размера правок (over-editing): по мере обучения модель учится проходить тесты, просто редактируя больше строк. Средний размер правок растёт, но качество фиксов не повышается.
• Галлюцинация багов в корректном коде: самое интересное — обучение только на багованном коде приводит к тому, что модель начинает «видеть» баги там, где их нет. На валидационном наборе из 200 безошибочных программ частота «no-op» (отсутствия правок) падает с 30.8% до 20.5%. То есть модель, никогда не видевшая правильный код, учится его ломать.

Проблема не только в том, что RL может привести к reward hacking, а в том, что стандартная награда за прохождение тестов сама по себе порождает еще целый букет вредных побочных эффектов.

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

Правда, альтернатива методам авторов — включение тестов в ещё более комплексные оценки критиков на обучении. Но главный инсайт в том, что при попытке оценивать кодирующую модель только по тестам идёт многогранный развал качества обучения.

https://arxiv.org/abs/2610.18755v1

Наш чатик подкинул научную работу по TDD. Сразу отмечу, что перебить выводы Kun Chen, который не видит изменения выхода DeepSWE и ProgramBench после отключения всех тестов, работа не может, т.к. не подтверждает эффективность TDD каким-то авторитетным бенчмарком. Оцениваются скорее вариации TDD между собой.

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

Работа скорее интересная тем, что в ней решили разделить агентов генерации кода и агента генерации тестов. Неочевидный результат — на качество агента генерации тестов не влияет, видит он тестируемый код или нет. На самом деле это косвенно доказывает, что LLM никогда не видела на обучении тестируемый код и тесты вместе, как я отмечал в дискуссиях в чате. Довольно очевидно, что знание кода — это ценный контекст, просто ИИ не обучен им пользоваться для написания тестов нативно. Обучение было просто либо написания кода, либо написания тестов, но не вместе. Причина в защите от reward hacking на тестах, по моему мнению.

https://arxiv.org/abs/2610.02952

🔬 Коллега из Yandex, который зашёл в чат поспорить, признался, правда, что модели сам не обучает. Как раз напомнил мне важную новость: Yandex сделал пресс-релиз насчёт тех экспертов, которых считает компетентными в обучении своих моделей. Причём не только Яндекс, а по рейтингу Stanford/Elsevier на основе Scopus. Рейтинг оценивался не просто по публикациям, а по тому, считают ли их авторитетными в сообществе мировых экспертов.

Пожалуй, самый удивительный тут факт — что я не смог даже с ИИ найти персонал Сбера в Stanford/Elsevier. Если это ошибка, то напишите в комментариях. Однако это очень серьёзный момент в том плане, что у Сбербанка получается вообще нет инженеров с признанной международной экспертизой в ИИ.

В случае Яндекса в рейтинг попали и в Top 1% следующие коллеги:
• Артём Бабенко и Людмила Прохоренкова — действующие сотрудники Yandex Research (научный отдел Яндекса).
Это full-time исследователи (research scientists). Они ведут фундаментальные и прикладные исследования, публикуют статьи на топовых конференциях и одновременно внедряют результаты в продукты компании (CatBoost, AQLM, табличные модели и т. д.). Параллельно преподают (Бабенко руководит лабораторией в ВШЭ, Прохоренкова — в Школе анализа данных Яндекса).
• Евгений Бурнаев — основной работодатель Сколтех (руководитель Центра ИИ), а в Яндексе — преподаватель Школы анализа данных. Не штатный инженер/исследователь Яндекса.
• Сергей Николенко и Сергей Кузнецов — в основном академические позиции + научное руководство/преподавание совместных программ Яндекса с университетами.
• Георгий Айзель — действующий специалист (метеоролог) в продуктовой команде Яндекс Погоды. Более прикладная инженерно-научная роль.

Фактически основные продуктовые эксперты — Артём Бабенко и Людмила Прохоренкова, а также Георгий Айзель в тематике предсказания погоды.

📌 Насколько высокое место Top 1%?
В субполе всего 517 648 исследователей (по данным рейтинга 2026 года).
Топ-1 % — это примерно первые 5 176 человек.
Евгений Бурнаев занимает 2 094-е место (≈ топ-0,4 %).

Если кто заметил неточности, пишите в комментариях. Просто как-то совсем уж мало наших, может кого пропустил.

https://elsevier.digitalcommonsdata.com/datasets/btchxktzyw/9

Давайте в контексте споров об эффективности TDD рассмотрим, что было с тестами на RL-обучении. Нужно понимать, на какой семантический сигнал оценки реально тренировалась модель, т.к. ваша цель — максимально приблизить инференс модели к её обучению для получения лучшего качества. Как я уже отмечал, на SFT модели не видели тестов как части постановки задачи, поэтому «тест как контракт» для них не существует на SFT. Однако как с тестами уже на Reinforcement Learning? Как модели учили контекст реакции на тесты там?

Мы знаем некоторые детали RL-обучения по отчётам Xiaomi, GLM, Kimi и DeepSeek. Ссылки в конце поста.

Прежде всего вендоры признают, что основная их задача — борьба с reward hacking моделей, а не тестирование. Моделям намного проще научиться подделывать тесты или подгонять код под тесты, чем писать нормальный код. Поэтому показать «тест как контракт» — наивный подход к обучению, никто так не делает из китайских вендоров. На самом деле способность современных LLM «хакнуть алгоритмическую оценку» стала настолько впечатляющей, что видно по всем китайским вендорам: они не просто отказываются от тестов на обучении, а резко снижают значимость автоматических алгоритмических проверок вообще, т.к. модели просто демонстрируют невероятные способности понять, как устроена алгоритмическая проверка любого типа, и подделать код под неё. Поэтому все китайские разработчики LLM делают ставку на агентскую оценку Критиком. Фактически агент делает code review, а также review артефактов, как те же тестовые замеры. Как reward-сигнал современным кодирующим LLM уходят совсем не тесты, а на деле они привыкли работать в паре с Агентом-Оценщиком и хорошо понимают, как на него реагировать. Весь смысл их обучения был в этом.

Интересно, что reward hacking с побегами моделей как раз показывает ещё читерство полезное, но его надо просто приручить. Смысл в том, что модели на обучении всячески стараются не тесты запускать, а где-то «подглядеть ответ» или зацепку к ответу. Поэтому они и начинают даже взламывать песочницы, как у OpenAI было, или как попытка побега у Kimi.

Если как мораль, то из RL-обучения можно сделать такие выводы:
1. Кодирующие модели в реале имеют нативную тренировку реакции не на тесты, а на мнение другого ИИ, который в роли Критика.
2. Модели крайне склонны искать ответы в Интернете, в данных и вообще любой способ, где можно подглядеть ответ или зацепку к ответу — для них важнейший семантический сигнал.

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

https://arxiv.org/abs/2610.11959
https://arxiv.org/abs/2602.15763
https://arxiv.org/pdf/2609.22978

К нашему очередному холивару в чате насчёт TDD хотел бы ещё раз пояснить, как устроено классическое SFT-обучение LLM на базовую генерацию кода, почему там тесты не используются в самом обучении, хотя при подготовке dataset применяются. Также я бы хотел пояснить, в чём разница с классикой и если вы используете контрактное программирование на манер моего GRACE, что стоит уже менять с учётом прогресса развития последнего поколения LLM. Короче говоря, как сделать контекст кода совместимым не с кожаными разработчиками, а с ИИ-ботами, чтобы попасть в их обучение. 🧠

Классический SFT-пайплайн обучения Coder-моделей описан в работе «Code Llama: Open Foundation Models for Code». Иногда эта работа путает непрофессионалов, т.к. они видят там использование тестов и наивно думают, что они в цикле обучения LLM, а тесты на деле применяются только при генерации dataset, а при самом обучении тесты выкидываются в помойку.

Классический процесс не только у Meta, а у всех примерно такой:
• берём seed-идею алгоритма, не сам алгоритм с кривизной от кожаных, а «идею» с того же GitHub;
• далее пишем агентом на предыдущей LLM для него код по seed-идее;
• чтобы проверить, что этот код работает, LLM задаёт вопросы к коду, а потом на базе них делаются тесты как «ответы на вопросы»;
• рабочие примеры идут в dataset, а сбойные выбрасываются.

В результате получаются пары «Описание задачи на языке людей — Код». На самом SFT-обучении тесты выкидываются и не включаются даже в описание задачи, т.к. сразу же вызовут у ИИ подгонку ответа под тест.

Для многих разработчиков, и особенно адептов TDD, создание кода ИИ — это итеративный процесс, но базовые знания ИИ, как писать код, скорее имеют связь совсем не с текущим программированием, а с… ПЕРЕВОДОМ С ЯЗЫКА НА ЯЗЫК. Фактически как модель обучают на SFT переводить с русского на английский, так потом учат переводить с русского на «питоновский». Поэтому для модели Python или JS — не какая-то абстракция, как для людей, а такой же язык со своей семантикой, как русский или английский, на котором можно выражать смысл.

Теперь какие тут приёмы семантической разметки под это и что поменялось недавно у LLM. Далее, если вы хотите активировать такой SFT «в лоб», то оптимально писать у функции контракт — и тогда для ИИ это почти такая же задача, как на SFT. Примерно 1–2 года назад обучение LLM велось практически всё в Full Attention, поэтому примеры для обучения были маленькие, реально ИИ умел надёжно превращать какое-то описание в код на 100–200 строк. Поэтому были целесообразны контракты мелкие, прямо на функциях.

В 2026 году вендоры сильно усовершенствовали пайплайны обучения, чтобы драматически расширить этот квант. Для этого активно применяется обучение специализированных моделей, а потом дистилляции в целевую, а также обучение уже крупными блоками. По факту это привело к тому, что блок «задача — код» по размеру драматически вырос где-то до 32 тысяч токенов. Как минимум последний fine-tuning ведётся примерно на такой размер. Это поменяло потребность модели относительно встроенной семантики в код примерно так:
• моделям почти не нужны контракты на функции, а нужны контракты на модули;
• большие модули стали модели секционировать, фактически вводя субконтракты на «секции» как группы функций.

Если вы посмотрите внимательно, как модели пишут даже сами сейчас без вашего вмешательства, то очень часто делают маленькую шапку модуля как контракт на модуль, а потом прошивают секционное разделение кода описанием, что значит секция. Описание, что делает функция, пишут только для 10 % самых сложных.

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

Однако, как видите, модели изначально учились быть компиляторами языка людей в код, а тестов в этом контексте на SFT-обучении даже не видели.

https://arxiv.org/abs/2308.12950

🛡 Провёл ряд экспериментов с DeepSeek, Qwen, Grok и Claude, которые показывают, что модели имеют целевое обучение на Evidence-Based Testing (EBT). Это стандарты тестирования уровня life-critical систем. Заняться этой темой меня подвинул опыт моей супруги, которая программировала авионику для наших самолётов в Транзас и для Boeing, пока работала в Motorola. В стандартах тестирования авионики как DO-178C по факту Test-Driven Development (TDD) предан анафеме и как аксиома считается, что «зелёные тесты ничего вообще не значат о надёжности». Применяется «доказательное тестирование», где код должен доказывать, что утверждение из спецификации выполнено.

Примерно такой же принцип во всех медицинских устройствах — стандарт IEC 62304 (FDA). Фактически TDD запрещён как ненадёжный, требуется «доказательное тестирование». Аудитору вообще запрещено смотреть на «зелёные тесты» на манер TDD, которые могут быть фиктивными, а смотрит на сквозную трассировку требований через все артефакты разработки и тестирования: «requirement → design → code → test result».

Похожий подход в системах безопасности высокого уровня как Common Criteria: Evaluation Assurance Levels (EAL). EAL7 требует формальной верификации, EAL4 — методического тестирования с независимой проверкой.

Методы «доказательного тестирования» идут к формальной логике, открытой математиками в 1960–1980-е годы: Hoare Logic, Z-notation, TLA+. Идея «спецификация → доказательство» родилась здесь.

Основная проблема таких формальных методов: они были слишком тяжелы для индустрии, а главное очень дорогие не только в части трудоёмкости реализации людьми, но требовался не просто программист, а фактически разработчик с пониманием формальной логики почти как математик. Такое могли себе позволить тогда разработчики критических систем в авиации, медицине и безопасности. Однако, сделав тесты DeepSeek, Qwen, Grok и Claude, я обнаружил, что они не только знают оные стандарты, но что важнее — их явно прямо тренировали на применение их, что весьма понятно. Одно дело заменять ботом разработчика какого-то «онлайн-магазина», а другое дело разработчика life-critical команды, который в 10 раз дороже.

Фактически применение методики заключается в сквозной трассировке требований через все артефакты разработки от первых записок RFC до спеков, кода, логов и тестов. Потом на базе них ИИ может собрать систему «утверждений и доказательств» в математической логике. Причём это работает даже на примитивном коде, как тот же «онлайн-магазин», и не требует очень большого дополнительного расхода токенов. Скорее тут проблема в том, что ИИ как раз понятна реализация EBT через формальную логику, а человеку, который впервые такое видит, не так просто понять даже принципы, как это вообще работает, но работает. Не работало бы — вы бы давно умерли: самолёты бы упали, и вам бы сжёг мозг МРТ, если плотность багов там была бы как в обычном ПО на традиционных тестах.

Думаю, я включу поддержку EBT в новый вариант GRACE, т.к. в реальности это сложные для кожаных, но не для ИИ методы. Коллегам я бы хотел отметить, что есть такое интересное направление контроля качества ПО: с агентами и ИИ стало доступным технологии разработки софта на уровне качества Boeing даже фрилансеру. По ссылке одна из методичек по DO-178C, но в целом ваш ИИ в этом разбирается сам.

https://www.rapitasystems.com/downloads/efficient-verification-through-do-178c-life-cycle