ИИ-директора банкротятся на ровном месте, разбор нового бенчмарка CEO-Bench

Исследователи из Принстона (Z-Lab) выкатили жесткий тест для нейросетей – CEO-Bench. Это не просто ответы на вопросы, а симуляция управления SaaS-стартапом в течение 500 игровых дней.

Условия игры:
На старте дают $1 млн и 0 клиентов. В руках у ИИ 34 инструмента: маркетинг, найм, цены, сервера. Вокруг "злой" рынок с задержкой фидбека, шумом в данных и меняющейся экономикой. Задача – не обанкротиться и выжать максимум прибыли.

Результаты показывают, что со стратегическим мышлением у ИИ пока беда. Из топовых моделей выжили и вышли в плюс только три:

🥇 Claude Fable 5 — $47,15 млн
🥈 Claude Opus 4.8 — $27,8 млн (модель додумалась сама писать скрипты когортного анализа)
🥉 GPT-5.5 — $21,3 млн

Главный позор:
Обычный глупый алгоритм на жестких правилах (rule-based script) без всякого ИИ сделал $15,76 млн и обошел десятки умных нейросетей. 🚬

Пять крупных моделей, включая DeepSeek V4 Pro, Gemini 3 Flash и Grok 4.20, и вовсе полностью обанкротились.

ИИ пока не умеют играть вдолгую: они страдают амнезией на длинной дистанции и слишком пытаются угодить всем советникам вместо принятия жестких решений.

Теоретический максимум в симуляции – $2,2 млрд. Так что кожаным мешкам на позициях CEO пока можно спать спокойно. Но это не точно. 👍

Подробности исследования читайте в оригинальной статье о CEO-Bench, а код для тестов доступен в репозитории на GitHub. Интерактивный график в блоге.

Не является инвестиционной рекомендацией. 🥳

Нейросети превратили найм в лотерею 🎰

И дело не в том, что LLM помогают проходить собесы. 🪨
HackerRank выложили в открытый доступ систему для оценки резюме при помощи ИИ. Инструмент стал невероятно популярным среди рекрутеров. Программа парсит файлы и скармливает данные языковой модели для выставления баллов резюме.
Учитываются навыки, опыт работы и личные проекты на GitHub. Звучит как отличная автоматизация скучной рутины. 👍

Однако, один разработчик решил проверить систему и прогнал своё резюме несколько раз подряд.
Результаты оказались пугающими. Совершенно идентичный файл получал оценки от 74 до 90+ баллов. 🚬 При проходном пороге в 85 баллов кандидат получает отказ просто по воле случая.

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

В чем может быть причина?

Поммимо того, что над нормально писать критерии в промптах, есть ряд инженерных факторов о которых вы должны помнить, если делаете такое решение.

Если бы мы говорили о classic ML моделях, я бы сказал - бегите глупцы фиксите seed'цы (random states).  Но тк мы работаем с ядром на LMках, придётся следить за параметрами генерации в лице температуры, тк она влияет на креатив. Также нужно следить за тем, что контекст чётко обнуляется, ведь генерация зависит в тч от накопленгого контекста. Те для каждого прогона, каждого резюме нужно "забывать" прошлые прогоны. Однако даже имея Т=0 и фиксу по контексту.

Придётся следить и принимать:

1. Non-determinism в LLM - даже при temperature=0, многие современные модели (особенно с speculative decoding, batching, и т.д.) могут давать немного разные результаты.
2. Parsing inconsistency. PDF/DOCX парсинг может давать разные результаты при каждом чтении, особенно если используется OCR или layout analysis.
3. Tool calling / Function calling. Если модель использует function calling для выставления оценок, структура вызова может варьироваться.
4. Batch processing, если резюме обрабатывается батчами с другими, контекст соседних документов может влиять.
5. Floating point non-determinism - на GPU операции могут быть недетерминированными из-за parallel reductions...

Да, не легка жизнь AI-dev и AI-engineer, столько нюансов. 📝


P. S. Ещё ссылки на событие.
Трек в реддит тут. Блог от HackerRank тут. Читаем, делаем выводы и stay tuned 🦾

FRIDA все ещё хороша, как эмбеддер для вашего RAG. 📦
Теперь и на rusBEIR 🚬 💪

Всегда говорил, всяким там типа разрабам местных LLM – вот вы тюнинг делаете под бенчи, ругаетесь, что там, где вы не в топе, не вы проиграли, а бенчи плохие. А мудрость в том, что хорошие модели на любом бенче, даже на самом сомнительном (RusBEIR разумеется не такой) стабильно в топе - эт и есть мастерство. 😎

FRIDA, кстати, уже была скачана более 2млн раз. 💅

#ИИзнанка, #ГордостьДня

Gemma4 техрепорт и честный omnimodal на 12b от 🕸

Вот ждал 📦, что будет пример в лоб, как кодировать без предобученных бэкбонов аудио, видео и картинок информацию и кидать в модель. Это и есть настоящее omnimodal, тк multimodal работает именно с доп моделями в своих модальностях + слой проекции. 😮‍💨

Ребята из 🏳️‍🌈 с выходом Gemma4 зарепортили инфу о такой модели. Теперь информация с разных модальностей кодируется напрямую в матрицы и проходит всего лишь слой эмбеддингов внутри модели без доп внешних clip'ов и тп.
Почитать можно в тех репорте тут. 🤙

Как это работает детально:

1. Изображение. Не используется ни vit, ни clip, ни resnet. Только патчи 48x48х3 (rgb канал 🧠) в нарезке серией. После выпрямляется в flatten и эмбедится в плотном слое (чисто факторизация а-ля как в SVD и als).

2. Аудио. Никаких мелспектров, а только сырой PCM сигнал. Нарезка также по 40мс частотой 16кГц, выпрямление и снова проекция.

Все это порождает эмбы токенов картинок и аудио, которые кормятся в слои внимания вместе с текст эмбами.

Важный нюанс с позицией: Чтобы модель знала, где находится патч, инженеры не используют сложные 2D-RoPE эмбы. Они добавляют факторизованные координатные вложения - отдельные обучаемые векторы для координаты X и координаты Y, которые просто прибавляются к полученному токену картинки или звука. 🧠

Upd. Почему это все работает, но так просто и в лоб??? Да все гениальное просто, также, как с рексисом на матричной факторизации, дело в объёме проливаемой датки и подборе размеров слоев вложений. А далее уже дело больших данных и чисел. 💪

В общем, для меня это было самое интересное. Тк в остальном в мире уже видны лучшие практики, которые комбинируй как можешь: и по локально-глобальному вниманию, и по sparsed attention, и хаки с KV, rope, скрытое рассуждение (только тут оно не в латентах, а тупо скрывают тексты от юзера), и обобщенные слои с early exit для MTP (multi token prediction).

Итого, читаем. Образовываемся и stay tuned 🦾

Время на "мы просто пробуем ИИ" уже закончилось. Как измерять реальную ценность от внедрения ИИ?

Именно с этого отрезвляющего тезиса стартует статья от 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 подписке кушает за себя и за Сашку. Те вы почти не экономите на ФОТ, тк сопоставимо тратите на токены.

Вот именно по следам этих кейсов и не только авторы статьи выше предлагают подход к оценке пользы от внедрения ИИ. OpenAI предлагает перейти к инженерному подходу - измерять не затраты на ресурс, а эффективность преобразования ресурса в полезный завершённый результат. В центре стоит метрика "полезный интеллект за доллар", которая раскладывается на четыре вопроса. Каждый вопрос - это не просто пункт в отчёте, а целая система сбора данных и принятия решений:

1. Выполняет ли ИИ действительно важную работу?
Первый шаг - перестать измерять активность и начать измерять результат. Ценность создается не количеством сгенерированного текста, а завершенными полезными действиями. Важно  "определение завершенности" для каждого бизнес-процесса. Тот самый эффект который я называл ещё в 2019ом value в бизнес ноде. Например, для отдела продаж полезной работой будет не "сгенерировать 100 писем", а "отправить клиенту финальное письмо, которое утверждено руководителем". Это меняет фокус с процесса на результат.

2. Сколько стоит одна успешно выполненная задача?
Это самый технический и важный пункт. Забудьте про цену за токен, она обманчива. Нужно считать полную стоимость одного принятого результата. И тут как раз вы можете фиксануть ROI, как я говорил выше.

Формула простая:

(Стоимость API-вызовов + Время персонала на промпты и правки + Время на проверку + Стоимость инфраструктуры) / Количество задач, принятых без доработок.

Дешевая модель может давать много ошибок, требовать постоянных правок и в итоге обойтись дороже, чем более дорогая, но точная. Именно поэтому OpenAI выпускает GPT-5.6 с тремя моделями: Sol (для сложных задач, где ошибка дорога), Terra (золотая середина) и Luna (для рутинных операций). Выбор модели - это всегда поиск баланса между ценой и качеством конечного результата. Снова привет fusion или Fugu для оркестрации.

3. Можно ли доверять результатам?

Этот вопрос напрямую влияет на стоимость. Чем выше доверие к ИИ, тем меньше времени тратится на проверку.

OpenAI выделяет тут три уровня зрелости:

· Черновик. ИИ предлагает вариант, человек все перепроверяет.
· Поиск и рассуждение. ИИ находит информацию и строит цепочки, но решения принимает человек.
· Автономное действие. ИИ выполняет операции сам (отправляет письма, вносит данные).

Для перехода на новый уровень нужно измерять доверие. Классифицируйте каждый ответ ИИ:

· Зеленый – принят без изменений.
· Желтый – требует легкой правки.
· Красный – полностью переделан.

Если доля "зеленых" ответов растет, значит, доверие повышается, а стоимость контроля снижается.

4. Растет ли ценность при масштабировании?

Последний вопрос – про динамику. Даже если сегодня все хорошо, нужно следить, не ухудшается ли экономика при росте объемов.

Ключевая метрика:

Эффективность = Объем полезной работы / Совокупные затраты на ИИ
Неплохая замена ROI в моменте, этакий аналог биржевого индикатора.

Если вы увеличиваете использование ИИ в два раза, а затраты растут тоже в два раза - вы на месте. Если затраты растут медленнее - вы в выигрыше.

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

Практический чек-лист для внедрения от OpenAI:

1. Выберите 3–5 ключевых процессов, где используется ИИ.
2. Для каждого четко определите «завершенную задачу».
3. Начните собирать данные о всех затратах (не только API, но и время сотрудников).
4. Ведите классификацию ответов (зеленый/желтый/красный).
5. Пересчитывайте стоимость за задачу и сравнивайте разные модели.
6. Раз в квартал оценивайте динамику эффективности.

А как вы оцениваете вклад ИИ в своих проектах?
Делитесь опытом в комментариях 👇👇👇