Время на "мы просто пробуем ИИ" уже закончилось. Как измерять реальную ценность от внедрения ИИ? Именно с этого отрезвляющего тезиса стартует статья от OpenAI. Теперь вы не можете как в 2023-2024, а кто-то все ещё сейчас просто экспериментировать ради любопытства, сегодня ИИ - это реальная производственная мощность, и нужно её измерять также, как электроэнергию или выч ресурсы. 📦 помнится, как оценивали качество от автоматизации ручных процессов или поддержки с ИИ: 1. Общий трафик DAU, MAU, WAU и тп. 2. Интерес, через возвращаемость ака retention rate. На самом деле, не так важно, что в первый день запуска вы вывалили большой трафик, как то, что если сервис полезен к вам будут возвращаться снова и снова. 3. Число принятых подсказок с ИИ - ака acceptation rate. К примеру, вы работаете с ИИ суфлером или код агентом копайлотом и вот число принятых подсказок по ответу оператора или коду можно было измерить так. 4. Польза в конечной бизнес ветке или ноде. Если вы работали с сценариями поддержки, на самом деле, автоматизация должна считаться не только числом закрытых вопросов в чате без перевода на оператора, но и измеряться закончился ли диалог на самом деле решением проблемы пользователя или он через час снова придёт с этой темой в чат (а тут уже retention rate работает против вас). Да это можно проксироват через CSI, NPS, но в век LLM и агентов можно верифицировать и без оценки человека, достигнуто ли было намерение юзера и решена проблема с которой он придёт. А ещё у нас была система штрафов за возвращаемость юзера по проблеме ещё раз в чат или к оператору. 5. Фин эффекты в лице ROI. Тут просто (на самом блин деле, ни фига не просто) отношение прибыли к затратам на ИИ сервис, фичу, решение, проект и тп. - скок заработали к тому сколько потратили на разработку, аммортиазцию железа и токены на эксплуатацию. Обычно измеряется в %, умножаетсы естественно на 100. Однако помимо этого, мало посчитать таким образом потенциал, ещё нужно посчитать срок окупаемости. ROI показывал, что мы имеем такой потенциал, а срок окупаемости за какое время мы его можем достичь. 6. Рост эффективности труда. Вот моё "любимое", что над именно считать на сколько уменьшится время на выкатку фичи, сервиса, продукта или нового кода/программы, ускориться принятие решения и тп. Ака Lead Time, Time to Market и аналоги. И да современный ИИ тут помогает. Почитали? Интересно? А теперь забудьте все не так радужно. Начну с ROI прям сразу - компании не умеют, а некоторые оунеры решений и не хотят считать это честно (не в смысле врут, а в смысле не все переменные учитывают). Часто в текущей реальности заканчивается оценкой скорости а-ля ТТМ, но никто не хочет посчитать деньги в конечной бизнес ноде. К примеру, вы смогли автоматизировать аналитику, сказали что ускоритель на К%, но почему-то не получаете оценку оборачиваемости капитала или out-of-stock (упущенные продажи) в денежках, на которые и повлияет ускорение принятия решения от внедрения ИИ. Но окей, вы посчитали это, но в знаменатель забудете положить кроме фот на разработку, ещё токен экономику и аммортизацию ваших мощностей (если они онпрем). Почти все не понимают, сколько токенов они будут кушатс. На самом деле, ну и не должны, вопрос ж в динамическом изменении этого, особено с МАС под капотом. Но раз тут у нас динамический показатель, то ROI не будет фиксой, как и поправки в срок окупаемости придётся вносить. Ну и мякотка, все хотят на старте это посчитать, а в вводных выше мы понимаем, что посчитать можно только по факту в начале (порой пальцем в небо) или за период (на конец отчетного), а без этого даже стартовать порой отказываются. Второе любимое это про экономию на ФОТ через автоматизацию. Ну тип дали людям огонь Claude Code и ща кааак начнём сокращать разрабов и экономить на дорогих манки кодерах. В итоге хороший agent developer с инструментом на max подписке кушает за себя и за Сашку. Те вы почти не экономите на ФОТ, тк сопоставимо тратите на токены.

8 месяцев назад вышла Kimi K2 Thinking, и мы слышали то же самое: «Chinese open-source model is #1». Через 3 месяца после релиза я собрал аналитику по 16 бенчмаркам, вышедшим после релиза модели, и сравнил с GPT-5 / Sonnet 4.5. Модель была хуже на 13 (!!!) из них, причём на 7 — более чем на 10 процентных пунктов (пп). Повторится ли это с Kimi K3? Свои мысли и предсказания я напишу в конце, а пока пришла пора ретроспективно оценить DeepSeek v4 Pro (Preview) — с его релиза прошло почти 3 месяца. За это время я смог найти 32 новопоявившихся бенчмарка. В релизном блогпосте v4 Pro сравнивали с Opus 4.6 и GPT-5.4, и модель якобы «была лучше» в 4 и 3 бенчмарках из 6 соответственно. Surely результаты на новых будут сопоставимы? Нет. Opus 4.6 и DeepSeek v4 Pro обе были замерены на 10 бенчмарках — на 9 из них китайская модель проигрывает, и на 5 — более чем на 20 (!) относительных процентов. Сравнение с GPT-5.4 выглядит чуть менее жестким: DeepSeek v4 Pro оказался лучше на 3... но всё равно хуже на 13. (Количество бенчмарков разное потому, что не каждый бенчмарк замеряет цифры и для GPT, и для Claude). На 6 бенчмарках разница больше 20 относительных процентов. Но вообще-то стоит вспомнить, что и GPT-5.5, и Opus 4.7 вышли ДО DeepSeek v4 (на самом деле впритык, но всё же). И если добавить эти модели, как будто мы сравниваем со всеми моделями, доступными на момент релиза v4, то ситуация становится просто мрачной. Все 32 бенчмарка проиграны, и средняя разница в абсолютных оценках составляет -18.6 пп. Эта разница вырастает до -23 пп, если брать только те бенчмарки, которые я классифицировал как Agentic Coding (SWE-bench style), где казалось бы падение должно быть не таким существенным. Только подумайте: модель не решает четверть задач, которые решали проприетарные модели, доступные на момент релиза DeepSeek V4 Pro. Повторится ли эта ситуация с Kimi K3? Ведь ей предстоит пережить сравнение с GPT-5.6-Sol и Fable 5. Я уверен, что да — по сумме показателей на десятках бенчмарков мы точно увидим разницу, хотя, возможно, не настолько значительную. В конце концов по тем веб-сайтам, что я вижу в своей твиттер-ленте, модель действительно не хуже Fable на фронтенд-задачах, даже на очень креативных промптах. Вполне возможно, что на широком наборе других задачах на программирование модель тоже конкурентна или хотя бы отстаёт не так сильно. Может быть даже сможет потягаться в подготовке презентаций и экселек. Условно, если снова соберётся 30 бенчмарков, мы можем увидеть, скажем, 8 побед за Kimi, 5 ничьих и 17 поражений. А может быть, она покажет себя даже лучше — поживём увидим. Главное то, что Kimi K3 может быть той моделью, которая покажет, что существуют некоторые поддомены, в которых Китайские модели действительно не отстают систематически. Это не качество по всемнаправлениям, и "в среднем" проприетарные всё равно будут лучше — речь именно про поддомены (например, «вебсайты с 3D-графикой на three.js» или «веб-игры», по которым многие делают слишком далекоидущие выводы). (Не воспринимайте этот текст как «Kimi / DeepSeek говно и никто не должен их использовать». Пожалуйста, прочитайте детали моей позиции в блогпосте по ссылке). Все графики и данные тут: ссылка.

Пару мыслей • MCP and API connectors will be the way - то есть UI/UX немного может отойти на 2ой план - все будут работать из своих терминалов etc • MCP amd API - нужны для почти любого сервиса сейчас, это повышает conversion/stickiness • многие сейчас делают так - MCP продают по одному pricing а-ля $99/month => можно только из своего терминала/Claude Desktop/Code работать - API за $199 => можно встраивать в процессы • под API and MCP нужна документация, чтобы LLM с ней лучше работали https://www.mintlify.com - супер крутой сервис - даешь свой сайт - и он сам вытягивает инфо и сразу тебе делает документацию под docs.YOURDOMAIN.COM и это бесплатно

📌 Как дотянуть компактную модель до уровня гигантов посттрейном AI-подразделение китайского производителя электромобилей Lixiang опубликовало интересную работу о том, как они оптимизацией насыщали компактную модель доменными знаниями.

Mach-Mind-4-Flash - итоговая MoE-модель на 35 млрд общих 3 млрд активных параметров на базе Qwen3.5-35B-A3B.

Проблема, от которой Li Auto отталкивались, состоит в том, что если учить одну модель с подкреплением сразу на смеси наград (математика, код, агентные задачи), то появляются качели - подтянули одно, просело другое. Решение - разделить этапы и области знаний. Сначала независимо обучили более десятка RL-экспертов, каждого в своём домене: математика, код, текст, безопасность, поиск, работа с инструментами. Каждый эксперт получил свои данные, свои проверяемые награды и свою стратегию обучения. Дальше самое интересное - как собрать экспертов обратно в одну модель. Для этого использовали методику MOPD, которую взяли у Xiaomi.

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

Агентные навыки эксперты осваивали в исполняемых песочницах - там модель читает файлы, правит код, запускает тесты, видит ошибки и продолжает с их учётом. Масштаб сред - более 190 предметных областей с сохранением состояния, свыше 3,5 тыс. интерфейсов инструментов, траектории программных задач до 300 шагов при контексте 256 тыс. токенов. 🟡Работает ли слияние? И да и нет. Следование инструкциям сохранилось целиком, а на агентных бенчах ClawBench и ClawEval итоговая модель даже обошла отдельных экспертов. Но на SWE-bench Verified результат просел с 73,80 у эксперта до 71,10 у модели.

Предполагают, что узкоспециализированное поведение в длинных задачах кодинга при дистилляции смазывается.

Финальный штрих - HMPO, собственная механика Li Auto, которая следит, чтобы модель не увлекалась в цепочках рассуждений.

Бюджет длины CoT берётся из медианы правильных ответов в группе, награду получают только верные и при этом более короткие решения, а награда собирается умножением (короткий, но неверный ответ получает строгий 0, что закрывает лазейку для взлома награды).

На выходе HMPO получается сокращение длины генерации на 19–46% при потере точности не более 0,7%, причём обучение шло только на математике, а эффект перенёсся на код и другие задачи. Правда пока это работает только для одношаговых рассуждений, к многоходовым агентным траекториям его ещё предстоит адаптировать. 🟡Итоги 92,7 на AIME'26 - тут отстает от триллионной Kimi-K2.5 меньше чем на пункт; 82,8 на IFBench - первое место с большим отрывом, ближайший конкурент Qwen3.5-122B; 75,8 на BFCL-v4 - второе место после MiMo-V2-Flash, при этом лучше чем Qwen3.5-122B и Kimi-K2.5. Можно сказать, что результаты на уровне куда более крупных моделей. К сожалению, планы по публикации модели неизвестны, но возможно мы просто почувствуем её в следующих поколениях электромобилей Lixiang. 🟡Arxiv @ai_machinelearning_big_data #AI #ML #LLM #Optimisation #RL #LiAuto

🔥 Как прошёл офлайн-бранч ODS Moscow × Нескучный Data Science 🧠 Начали с доклада Альберта про то, как в Avito обучают собственную LLM. Это не история про «взяли открытую модель и немного дообучили», а полноценный процесс: выбор базовой модели, собственный токенизатор, адаптация на данных Avito, SFT и дальнейшее обучение с помощью RL. Для SFT собрали больше 800 тысяч примеров: открытые датасеты, синтетические данные, олимпиадные задачи, внутренние бизнес-кейсы и диалоги пользователей с большими моделями. На этапе RL отдельно развивают несколько навыков модели: решение математических задач, следование сложным инструкциям и корректный вызов инструментов. Причём для каждого навыка нужен свой автоматически проверяемый reward. В математике система извлекает финальный ответ и проверяет его эквивалентность правильному. В instruction following — смотрит, выполнила ли модель все заданные ограничения. В function calling — проверяет название инструмента, аргументы и их значения. Отдельно поговорили про инфраструктуру. Для моделей на 8B параметров можно относительно быстро запускать эксперименты и проверять гипотезы. Но при переходе к большим MoE-моделям главным вызовом становятся масштабирование, распределение модели по GPU, батчинг, инференс и offloading. 👨‍🔬 После продуктовых LLM резко переключились на химию. Константин начал с важной мысли: химическая информация — это не один универсальный тип данных. Одну и ту же молекулу можно представить текстом, строкой SMILES, двумерным графом, трёхмерной структурой или структурой, которая изменяется во времени. И под каждое представление нужны свои методы и модели. Поговорили о том, почему даже на фоне сложных нейросетевых архитектур связка Morgan fingerprints + XGBoost всё ещё остаётся очень сильным базовым решением для многих задач с химическими данными. Затем перешли к геометрическим графовым нейронным сетям. Они учитывают расположение атомов и позволяют предсказывать свойства молекул в десятки раз быстрее традиционных DFT-расчётов. Отдельно разобрали нейронные потенциалы и delta-ML. Идея в том, чтобы не выполнять каждый раз дорогой квантово-химический расчёт полностью: часть свойства можно посчитать более дешёвым методом, а нейросети поручить предсказать необходимую поправку. Дошли и до LLM с агентами. Здесь пока всё не так магически, как иногда выглядит в заголовках: модели могут по-разному отвечать на один и тот же вопрос в зависимости от того, передали им обычное название соединения, IUPAC или SMILES. А некоторые агенты, которые должны самостоятельно запускать вычислительные эксперименты, пока скорее напоминают roadmap, чем полностью автономного исследователя. Зато роботизация лабораторий уже вполне реальна: специализированные платформы, роборуки, автоматическое проведение серий экспериментов и превращение обычного оборудования в high-throughput-системы. 🎬 После двух технических докладов разговор с Денисом про ИИ в кино оказался очень кстати 😅 Обсудили, где новые инструменты уже помогают при работе с контентом, какие процессы способны ускорить, где вызывают сопротивление и в каких задачах пока остаются скорее экспериментом. Но, как обычно, самое ценное происходило не только во время выступлений. После докладов продолжили обсуждать услышанное за завтраком, задавать вопросы, спорить, знакомиться и делиться своими кейсами. Спасибо Альберту, Константину и Денису за содержательные выступления, ODS Moscow — за очередную совместную встречу, МИРА бистро — за пространство, а всем, кто пришёл, — за вопросы и атмосферу. Формат «бранч + несколько докладов» точно будем повторять. Поэтому уже начинаем собирать темы для следующего бранч-митапа. Если вам есть о чём рассказать — про рабочий кейс, исследование, неожиданный эксперимент, применение ИИ в своей индустрии или даже неудачу, из которой можно сделать полезные выводы, — присылайте тему доклада и пару предложений о себе в комментарии или личные сообщения. P.S. Будем учиться фотографироваться до того, как все разошлись 😅

MWS Cloud первой в России развернула GLM 5.2 в собственном облаке MWS Cloud расширила каталог сервиса MWS GPT Model Hub до 17 больших языковых моделей. Главным обновлением стала GLM 5.2 — опенсорс-модель от Z.AI, которую компания первой в России развернула на собственной облачной инфраструктуре. Модель ориентирована на сценарии, где важны качество рассуждений, глубокий анализ текстов и обработка многошаговых запросов. Теперь все запросы к GLM 5.2 обрабатываются на серверах MWS Cloud внутри страны. Это означает, что данные и вычисления не покидают юрисдикцию РФ и не зависят от зарубежных провайдеров. Помимо GLM 5.2, в каталоге появились Kimi K2.6 от Moonshot AI. Модель подходит для обработки сложных пользовательских запросов, анализа документов, генерации развёрнутых ответов и построения AI-ассистентов. Кроме того, в MWS GPT Model Hub появились Qwen3.6, Gemma 4, GPT OSS и другие модели. Сервис получил поддержку распознавания и синтеза речи, а также реранкеров, которые улучшают качество поиска и RAG-сценариев. Все 17 моделей доступны через единый OpenAI-совместимый API, что позволяет разработчикам быстрее тестировать и внедрять AI-функции в свои продукты без развёртывания собственной инфраструктуры. @ai_machinelearning_big_data #news

Тренды из мира бенчмарков на ICML 2026 [1/2] Работ о бенчмарках на ICML традиционно много. По сравнению с прошлым годом, в 2026 стало заметно больше бенчей для агентов. А ещё начали чаще встречаться работы из академии. Объяснение простое. Корпорации вкладывают много сил во внутренние бенчи: делают сами, покупают их у data-labeling-компаний (например, Surge, Mercor, Handshake AI, Toloka) — и, как следствие, такие бенчи редко опенсорсят. Остальные бенчмарки часто делаются ощутимо меньшими ресурсами. И, как следствие, страдают от типичных проблем: • мало человеческой верификации данных, • качество judge'ей-верификаторов редко полноценно исследуется, • плохо оценивается качество пар запрос + ground-truth-ответ, сгенерированных LLM, • редко проверяется контаминация, хотя бенчи собираются из открытых источников. Авторы постеров, вошедших в подборку, отметили, что подготовка одного бенча занимает в среднем 3–4 месяца фултайм-работы. τ²-Bench: Evaluating Conversational Agents in a Dual-Control Environment Команда τ-бенча продолжает свою работу. В этот раз получили spotlight. Предыдущие версии были single-control: то есть, тулы были доступны только агенту, а пользователь пассивно выдавал текстовый фидбек. В реальном мире пользователь, конечно, взаимодействует со средой. Новый бенчмарк сделали на примере телекома: у агента и у симулированного юзера свои БД и инструменты в общем мире. Валидация — не LLM-судьями, а ассертами на состояние мира. Получившийся бенч заметно сложнее предыдущих версий: Сlaude-3.7 выбивает только 49%. Авторы используют абляцию, когда всё управление переходит агенту или если агенту дают подробный план, как надо поступать. Один из тейков: для агента важен скилл координации с пользователем, который обычные специализированные бенчи не измеряют вообще. QEDBench: Quantifying the Alignment Gap in Automated Evaluation of University-Level Math Proofs Этот бенч фокусируется в первую очередь на оценке надёжности самих судей: насколько LLM judge вообще способен оценивать математические доказательства примерно институтской сложности. Авторы попросили экспертов переписать экзаменационные задачи из 10 математических дисциплин так, чтобы избежать контаминации. Также дополнили бенчмарк примерами из экзаменационных задач своего университета. Ответы фронтир-моделей оценивали: • кандидаты математических наук по заданной шкале, • LLM-судьи по рубрикам, заранее описанным людьми. Всего авторы собрали 1300+ доказательств и 1000 часов разметки. Ожидаемо, судьи пропускают заметно больше неправильных решений: 38% показал самый лучший judge на GPT-5.2 Pro. The Decrypto Benchmark for Multi-Agent Reasoning and Theory of Mind Бенчмарк на Theory of Mind, собранный на основе настолки Decrypto. Alice даёт словесные подсказки к четырём секретным словам так, чтобы код угадал её партнёр Bob, но не угадал перехватчик Eve. Сложность в том, чтобы подсказка была достаточно прозрачной для своего и непонятной для чужого — то есть, требует явно моделировать так, чтобы понял один и не распознал другой. Pass — исход игры. Преимущество по сравнению со старыми статическими ТоМ-бенчами в том, что можно менять ключевые слова и собирать их в миллиарды комбинаций, избегая переобучения. Авторы проделали довольно подробную работу: предлагают промпты-правила и методики валидации, а также провели валидационные игры между людьми и моделями. С игрой плохо справляются даже фронтир-модели: дают примитивные ассоциации (fire → flame, hat → cap), которые легко перехватить. С помощью отдельных тестов из области детской психологии, замерили representational change — понимает ли агент, что его собственное представление изменилось, когда пришла новая информация и изучили false belief — умение приписать ложное убеждение участнику дискуссии. Оба показателя составили менее 10%. Ризонинг не помогает: Llama 3.1-70B обходит и Claude 3.7, и o1. Исследовала для вас бенчмарки ❣ Ирина Барская #YaICML2026 Душный NLP

«Как я добавил LLM в чат друзей, и приказал ей отыгрывать терминатора (и открыл портал в мультивселенную безумия)» Модель со зрением читала мангу «Призрак в доспехах» и на страницах с японскими звуковыми эффектами срывалась в цикл. Честно пыталась прочитать звук и выдавала «КАК! КАК! КАК!» тридцать раз подряд, до потолка токенов, пока её не осадили штрафом за повторы. За этим курьёзом стоит целый Т-800 для чата на 15 друзей, собранный без единого рубля на API и крутящийся на ноутбуке с 4 ГБ видеопамяти. Бот подкалывает участников по их же архиву реплик, комментирует новости в машинной манере, помнит весь чат через RAG и ведёт досье на каждого. А для чатовых споров есть отдельный режим. Кидаешь боту реплаем спорный тезис, и он идёт проверять его по источникам сразу с четырёх углов. Всё это на домашнем железе со скоростью 5 токенов в секунду, где привычные приёмы приходится выкидывать и заменять хитростью. Посмотрим, как из бесплатных моделей и слабого ноутбука собирается работающий чат-бот.