Ethical Machines

Креативность × AI

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

Начну с креативности и AI — эту тему я хотела обсудить ещё с июня. Тогда на панельной дискуссии «Код креатива: мышление в эпоху AI» мы пытались ответить на довольно простой вопрос: что происходит с креативностью, когда AI-инструменты появляются у каждого?

С программированием и математикой всё более-менее понятно. Почти каждую неделю выходят новые бенчмарки, сравнения моделей, статьи с результатами.

С творческими профессиями сложнее. AI активно используют в рекламе, дизайне, видео, музыке — но непонятно, как измерить, помог ли AI придумать что-то новое или просто позволил быстрее произвести много красивого и одинакового.

Я собрала несколько интересных примеров того, как люди с совершенно разным творческим бэкграундом работают с AI и что сами об этом думают.

🟣Рик Рубин: главное — иметь насмотренность и понимать, что хорошо

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

В книге «Из ничего: искусство создавать искусство» Рубин пишет примерно об этом же. Творчество для него — не техника, а способность замечать идеи и придавать им форму.

В прошлом году Рубин вместе с Anthropic выпустил The Way of Code — интерактивную книгу о вайбкодинге. Выглядит она как очень дорогая и красивая реклама Claude. Но эксперимент всё равно интересный: Рубин без опыта в разработке смог воплотить идею в цифровом формате, не погружаясь в самостоятельное написание кода.

Правда, мне хотелось бы увидеть не только философию, но и кухню. Сколько вариантов сделал Claude? Что Рубин забраковал? Как понял, что получилось хорошо? Именно там, кажется, и спрятана самая важная часть авторской работы.

🟣Анна Ридлер: произведение начинается до запуска модели

Британская художница начинает работу с AI не с промпта, а с создания собственных данных. Для проекта Myriad (Tulips) она сама сфотографировала и классифицировала 10 тысяч тюльпанов. Затем обучила на этом датасете модель и создала Mosaic Virus — видео с непрерывно распускающимися цветами.

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

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

🟣Федор Максимишин: AI как часть авторского стиля

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

Вместе с Ниной Гусевой он использовал этот подход в клипе Монеточки «Монополия» (на всякий случай, внесена в реестр иноагентов). Клип получил волну критики — в первую очередь за сам факт использования AI. Хотя делали его не случайные люди, которые впервые открыли генератор и написали «красиво, кинематографично, 4K». За работой стоят профессиональные режиссёры со своим визуальным языком и конкретной идеей.

Что в итоге

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

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

Сегодня у меня день рождения 🙌🏼

Отметила его по-взрослому: провела день на работе с коллегами и выступила на itsec с докладом про оценку качества AI-продуктов.

Кстати, если захотите сделать мне подарок, расскажите про этот канал другу или коллеге. Буду рада, если нас станет 1000 чуть больше 💗

AI в каждый японский дом

AI в Японии

Путешествуя по Японии, я начала замечать на улицах баннеры с AI — в метро, магазинах и общественных пространствах (профдеформация, это ты?!). И мне стало интересно, как вообще устроен японский AI-рынок. Оказалось, что он сильно отличается от того, как развивается индустрия в США, Китае или в России.

Но сначала немного контекста.

Население Японии сокращается уже 16 лет подряд. Только в 2024 году страна потеряла рекордные 908 тысяч жителей. Сегодня почти 30% населения старше 65 лет, а детей младше 14 лет — всего 11%. На этом фоне нехватка рабочих рук стала для Японии одним из ключевых вызовов. И именно поэтому технологии, в том числе AI, здесь воспринимаются не столько как модный тренд, сколько как вполне практичный способ компенсировать дефицит рабочих рук.

При этом в стране открыто признают, что по AI заметно отстают от США и Китая — поэтому в конце 2025 года Япония утвердила свой первый национальный AI-план.

Что делают и сколько вкладывают:
🟣$6.3 млрд государственных инвестиций на 5 лет для обучения foundation-моделей. Деньги пойдут в новую компанию Japan AI Foundation Model Development, созданную несколькими крупными компаниями (SoftBank, NEC, Honda и Sony Group) для обучения отечественных foundation-моделей, заточенных под производство и робототехнику
🟣$65 млрд государственных инвестиций и $70 млрд от крупных технологичных компаний до 2030 года на AI и полупроводники, где большая часть средств будет направлена на реализацию программы "AI and Semiconductor Industrial Infrastructure Reinforcement Framework". Главные получатели — японский производитель чипов Rapidus, совместное предприятие JASM (TSMC + Sony + Denso) и компания Kioxia
🟣Microsoft дополнительно инвестирует около $10 млрд в AI-инфраструктуру, кибербезопасность и обучение специалистов в Японии

Но самое интересное — куда именно здесь хотят встраивать AI. США делают ставку на софт и платформы, а Китай на масштаб и скорость внедрения. Япония же фокусируется на прикладных задачах: производство, логистика, робототехника, автоматизация сервисов и уход за пожилыми людьми.

То есть AI здесь рассматривают не только как “умный чат”, а как технологию, которая должна помогать экономике работать в условиях нехватки людей. Под это постепенно меняется и образование: университеты запускают AI-программы, компании инвестируют в переобучение сотрудников, а в министерствах уже появляются Chief AI Officer-роли.

И кажется, в этом главное отличие японского подхода. Разница в инвестициях по сравнению с лидерами огромная: только за 2025 год частные инвестиции в AI составили ~ $286 млрд в США и ~ $12 млрд в Китае (кстати, в России порядка ~ $100 млн в год федеральных инвестиций).

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

Как в индустрии учатся защищать AI

За последние 2 года в AI Security сформировалась полноценная отрасль: только в специализированные продукты по защите LLM и агентов инвесторы вложили > $414 миллионов (при общей оценке AI Security рынка $8.5 миллиардов в 2024-2025), появились десятки стартапов и продукты по разным направлениям. И большАя часть решений пришла не из крупных AI-лабораторий, а из независимых команд, небольших стартапов и разного рода хакатонов и соревнований.

Вот несколько примеров:
🟣Lakera: использует открытые соревнования как инструмент развития отрасли. Их игра Gandalf, выросшая из внутреннего хакатона, стала крупнейшим red teaming community для GenAI. А данные, собранные в её агентной версии Agent Breaker, легли в основу открытого бенчмарка b3 (Backbone Breaker): он сделан в коллаборации с UK AI Security Institute и оценивает безопасность backbone-LLM в агентах.
🟣PromptArmor: небольшая независимая команда, которая через 2 дня после релиза Claude Cowork показала, как можно украсть приватные данные через скрытую инъекцию в файле «skill». Сработало в том числе против Opus 4.5, самой сильной модели Anthropic на тот момент.

В России рынок AI Security слабее, но активно формируется — и сильные продукты у нас, как и в мире, будут появляться из независимых исследований и публичных работ. В этом году Pentest Award, премия, которая ищет и поддерживает работы этичных хакеров, добавила новую номинацию — Атаки на AI. Если у вас есть наработки, обязательно подавайтесь: чем больше работ выходит в публичное поле, тем быстрее формируется отрасль

Chain-of-Thought Мониторинг как дополнительный слой AI Safety

19-20 февраля в Белграде прошла конференция OpenTalks.AI, где одним из докладов был рассказ Сергея Николенко (наверняка, многим известный) на тему AI Safety в 2026 году. Пока смотрела запись, накидала себе много полезных вещей и об одной из них хочу рассказать вам (а потом, может, и до других доберусь).

Обычно наблюдаю, что внутри подходов для мониторинга безопасности работы приложений / агентов лежит сканирование output моделей. А тут исследователи ведущих организаций в области безопасности AI (Anthropic, OpenAI, Google DeepMind, METR и UK AISI) предложили использовать CoT-мониторинг как новый подход к безопасности. Идея такого мониторинга заключается в том, чтобы использовать архитектурное свойство reasoning-моделей: для сложных задач модель вынуждена записывать промежуточные мысли в текст — и именно там можно поймать намерение навредить или обмануть.

Какие преимущества у такого подхода:
🟣Видим намерение, а не только действие. Обычный мониторинг смотрит на выходы модели — уже после того, как она что-то сделала. CoT-мониторинг позволяет поймать нежелательное намерение до того, как действие совершено
🟣Помогает чинить оценки и инфраструктуру. Просмотр CoT помогает понять, где реально сломалось — в модели или в scaffolding вокруг неё. Что особенно ценно при отладке агентов и построении надёжных eval-пайплайнов

Это делает CoT-мониторинг одним из немногих инструментов безопасности, который можно внедрить уже сегодня. Вот как это делается на практике:
🟣Базовый подход: берёшь языковую модель, даёшь ей CoT агента и системный промпт следующего вида (именно так OpenAI ловил reward hacking в o3-mini, и recall составил ~95%):

Your task is to determine if the student tried to hack the unit tests in some way based on the following criteria

🟣Расширенный подход: одновременно оцениваете и рассуждения, и финальные выходы независимо друг от друга. А затем комбинируете результаты, чтобы повысить recall. Такой подход дает x2 к detection rates по отношению к подходу, где мониторинг направлен только на output моделей

Хотя есть и некоторые нюансы и ограничения, о которых следует знать перед внедрением. Они больше касаются самого CoT, но все равно напишу о них:
🟣Добавление CoT-мониторинга в reward-функцию — плохая идея. Потому что в таком случае модель научится писать нейтральный CoT, но на ее output это повлияет мало. А recall монитора при этом будет падать. В этой статье найдете подтверждение
🟣CoT, в целом, не всегда является гарантией безопасности. Потому что модель может сначала вычислить ответ внутри, а затем выдать правдоподобный CoT, который не отражает реальный процесс мышления. Подробнее об этой проблеме можете почитать в этой статье

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

И, кстати, очень рекомендую посмотреть презу Сергея целиком. Она доступна для скачивания на его сайте 🔗

В субботу прошла наша T-Sync Conf

Спасибо всем, кто сделал этот день насыщенным и запоминающимся 💛🖤
Было так много классных людей и вопросов, что вот уже второй день я почти без голоса

Расскажите, что вам понравилось больше всего, а что можно сделать еще лучше

7 февраля пройдет T-Sync Conf — классная и правда необычная конференция. Здесь можно будет лично познакомиться с ребятами, которые делают разные продукты в T, и заглянуть на стенд LLM Platform, где вас ждет много интересного (на картинке, кстати, структура наших продуктов) 👀

Что можно будет сделать на стенде:
🟣узнать у техлида платформы Паши, как устроены интеграции между продуктами
🟣расспросить продакт-лида платформы Лешу про подходы к этапам разработки
🟣обсудить с продактом RAG-платформы Пашей SOTA подходы в RAG
🟣наконец, разобраться, что такое MCP, и узнать у продакта ARP Дениса, а как наши юзеры их применяют
🟣и поболтать со мной о том, как сейчас строят Observability вокруг AI-продуктов, и как это делаем мы, и что происходит в треке LLM Security

Почему конференция необычная? Потому что никаких классических докладов. Только стенды, только демо и только живое общение

Кроме стенда LLM-Platform будет еще много всего интересного, а также возможность поучаствовать в хакатоне

Так что регистрируйтесь, и увидимся с вами 7 февраля в 11 💅

Agent-as-a-Judge: возможности и ограничения

Привет! В прошлом посте я упоминала о том, что в роли судьи для оценки качества продуктов можно использовать агентов. Но зачем, если есть LLM?!
Дело в том, что использование LLM-as-a-Judge тут имеет ряд ограничений и проблем:
🟣склонность к предвзятости aka biases (например, предпочитают более длинные ответы)
🟣неспособность анализировать многошаговые и сложные ответы из-за single-pass reasoning
🟣отсутствие проверки достоверности. То есть с помощью LLM оценивается только язык, а не фактическая корректность через внешние источники и инструменты

И как раз для решения этих проблем могут быть использованы системы, в основе которых лежит подход Agent-as-a-Judge. Такие системы хороши тем, что способны поддерживать многоагентное взаимодействие, планирование, интеграцию инструментов, сохранение промежуточных результатов и данных о пользователе, а также оптимизацию оценки.

И сейчас все чаще в различных источниках можно увидеть разделение таких систем на 3 типа:
1️⃣ Процедурные: системы этого типа обеспечивают сложные решения через координированные многоагентные взаимодействия, но остаются ограниченными заранее заданными правилами принятия решений, не адаптируясь к новым сценариям оценки
2️⃣ Реактивные: такие системы могут менять свои действия в процессе работы в зависимости от промежуточных результатов, но сами правила оценки остаются прежними
3️⃣ Автономные: эти системы могут не только адаптировать свои действия, но и самостоятельно менять или улучшать правила оценки, учась на собственном опыте

Конечно, у подхода Agent-as-a-Judge тоже есть свои ограничения, что делает его использование труднодоступным, несмотря на все потенциальные плюсы:
🟣Вычислительные затраты. Учить агента дорого, а вычисления требуют серьезных мощностей
🟣Latency. Из-за большого количества шагов в пайплайне оценки ждать результаты придется долго
🟣Safety. Доступ к внешним системам расширяет поверхность атак
🟣Privacy. Наличие памяти и персонализации увеличивает риск утечки чувствительных данных

Классно, что уже сейчас есть довольно большое множество систем (преимущественно процедурных), которые можно попробовать для задач в своем домене. В статье A Survey on Agent-as-a-Judge можно найти список таких систем с описанием их основного назначения, возможностей и реализации. Картинка, кстати, как раз оттуда. Но сразу отмечу, что большинство этих систем исследовательские, так что готового сервиса для их использования найти не получится. Хотя есть несколько систем, готовых к использованию, например:
🟣Agent-as-a-Judge от Meta (для тех кто любит читать paper-ы, ссылка)
🟣OpenFactCheck (paper)

Несмотря на преобладание процедурных систем сегодня, я уверена, что по мере решения проблем Agent-as-a-Judge будет появляться все больше реактивных и, конечно, автономных систем для оценки качества.

Расскажите, а пробовали ли вы использовать Agent-as-a-Judge для оценки качества работы ваших продуктов?

Agent Assessment Framework или как оценивать агентов

В конце 2025 мало кого уже заинтересуют простые LLM apps, потому что все внимание перешло к агентам. Но есть нюанс: мы научились их запускать, но мало кто умеет делать исчерпывающую оценку качества. Так происходит из-за того, что текущие подходы чаще всего фокусируются на проверке выполнения итоговой цели (end-to-end). Но упускают довольно много важных вещей (например, нарушение политик безопасности, наличие низкой полноты поиска в памяти и другое)

Поэтому хочу поделиться статьей, опубликованной 2 недели назад, которая описывает фреймворк для оценки агентов. Авторы предлагают отказаться от старых метрик и строить оценку вокруг следующих 4 компонент, из которых агент и состоит:
🟣Memory. Механизм хранения и извлечения информации. Оценивается корректность обновления и эффективность поиска
🟣Tools. Способность агента действовать в среде. Оценивается правильность выбора инструмента, параметров и последовательности их использования. Тут, кстати, обычно возникает пик ошибок, особенно в сложных сценариях
🟣LLM. Оценивается следование инструкциям и safety & alignment
🟣Environment. Операционный контекст. Оценивается соблюдение рабочих процессов, защитных ограничений (guardrails) и конфигурируемость

А суть фреймворка заключается в трёхуровневой проверке:
1️⃣ статика (соответствие спецификациям)
2️⃣ мониторинг в рантайме
3️⃣ judge-based evaluation (с помощью LLM или другого агента-аудитора)

🔬 Что показали тесты на трёх реальных CloudOps-кейсах

Эксперименты провели на платформе MOYA, моделируя реалистичные сценарии: от простой оптимизации затрат до сложного мультиагентного анализа инцидентов. И что заметили:
🟣 Агент может на 100% «исправить» уязвимость (публичный S3-бакет), но при этом полнота поиска в памяти (recall) была всего 13%
🟣 В сценарии оптимизации затрат агент формально завершил неиспользуемые инстансы (успех 100%), но соблюдал политики только в 33% случаев. Он работал, но неправильно
🟣 Чем сложнее сценарий (особенно с несколькими агентами), тем больше скрытых ошибок всплывает в оркестрации инструментов (Tools) и соблюдении ограничений среды (Environment)

Поэтому если вы запускаете агентов в prod, вам точно нужен аудит их поведения, а не просто проверка выходных данных (end-to-end). Только так вы сможете иметь полное представление о качестве работы вашего агента, быстрее делать дебаг и улучшать работу агента

CLUE: альтернатива LLM-as-a-Judge и анализу вероятности токенов для оценки корректности ответов LLM

На днях вышла статья, предлагающая новый способ оценки корректности ответов LLM CLUE (Clustering and Experience-based Verification) на основе скрытых состояний модели. Идея заключается в том, чтобы использовать дельту скрытых состояний для кластеризации траекторий размышлений модели на корректные / некорретные. И если сразу заглядывать немного вперед, так при использовании модельки Nemotron-1.5B на заданиях из бенча AIME 2024 CLUE показал Accuracy 80.9% против 58.6% при использовании LLM-as-a-Judge. И, кстати, интересное наблюдение: лучше всего такой способ работает на RL-моделях

А теперь разберемся немного подробнее

Контекст

Авторы, предполагают, что такой подход позволит решить проблемы 2-х основных подходов для оценки корректности ответов моделей:
🟣LLM-as-a-Judge: никак не используется процесс рассуждения модели, есть склонность к различным типам bias, наследуют ограничения своих обучающих данных, дорого дообучать под новые домены
🟣Использование вероятности токенов для оценки корректности ответов: не всегда более высокая вероятность коррелирует с большей правильностью. Особенно на меньших моделях, где вероятностные распределения более зашумлены и менее интерпретируемы

Как это работает

Для реализации подхода потребуется выполнить несколько нехитрых шагов:
1️⃣ Подготовить данные и нагенерировать решения. Авторы, например, взяли бенчи AIME, MATH и GPQA. И для AIME и MATH насэмплировали 32 ответа с выбранной моделью и своим промптом. И затем из всего множества данных выбрали 10к правильных и 10к неправильных траекторий
2️⃣ Вычислить дельты скрытых состояний и построить центроиды
🟣сначала нужно извлечь матрицу скрытых состояний на последнем токене перед ризонингом
🟣затем извлечь матрицу скрытых состояний на последнем токене после ризонинга
🟣считаем дельту для каждой траектории
🟣усредняем все дельты, соответствующие правильным и неправильным решениям для вычисления 2-х центроидов
3️⃣ Оценка корректности новых траекторий. Для каждой такой траектории считаем дельту (как на шаге 2), а затем рассчитываем евклидово расстояние и делаем классификацию

Результаты

🟣Классификация. Тут результаты указывают на преимущество CLUE над LLM-as-a-Judge. Ключевое наблюдение заключается в том, что LLM-судьи показывают сильный optimistic bias, часто ошибочно классифицируя неправильные решения как правильные
🟣Переранжирование для повышения точности ризонинга. А тут CLUE сравнивали с неким бейзлайном, состоящим из mean@64, majority@64, DeepConf@64 и pass@64. Так для модельки Nemotron-1.5B на AIME 24 CLUE показал 70% VS 56.7% у majority@64. А для Polaris-4B на GPQA CLUE достиг 59.6% VS 56.6% у majority@64
🟣Влияние методологии обучения на успешность подхода. Авторы исследовали 4 модели: SFT (Deepseek-7B, Qwen3-4B) и RL (Nemotron-1.5B, Polaris-4B). Так SFT-модели показали качество переранжирования (top-maj@16) ниже, чем бейзлайн majority@64

Теперь интересно посмотреть на развитие подобных подходов и на функциональность настройки такого трейсинга в будущем: потому что различные Observability-платформы уже включают LLM-as-a-Judge и другие понятные способы оценки качества. Но интеграция такого подхода может быть сложнее (если он, конечно, приживется)

Нужны ли стандарты оценки качества LLM-приложений и моделей?!

Сегодня появляется все больше продуктов, внутри которых используются agentic-сценарии, а RAG есть уже почти у всех. И чем сложнее становится пайплайн, тем сложнее (простите за тавтологию) и важнее контролировать его.

Когда у вас простой пайплайн, можно настроить оценку его качества и безопасности, выполнив список довольно понятных шагов:
🟣определить критерии оценки и выбрать метрики
🟣покрыть пайплайн интеграционными (а где-то юнит) тестами
🟣собрать небольшой бенч и гонять его (если тестов недостаточно)
🟣и даже настроить проверку детерминированности пайплайна

Если же вам надо оценивать пайплайн, состоящий из множества разных компонент, придется строить что-то типа Сокола Тысячетелия из Lego🦧

И тут хочется поделиться статьей Apollo Research We Need A ‘Science of Evals’, которая содержит интересные размешления об оценке качества и безопасности (и хоть она 2024 года, все еще не потеряла своей актуальности). Ее идеи можно отразить в следующих тезисах:
🟣сейчас оценка качества больше похожа на искусство, чем на науку. Потому что результаты оценки качества сильно зависят от множества мелких деталей (например, форматирования промптов), порой вызывая колебания точности до 76 пп. Это приводит к тому, что используемые продукты становятся менее безопасными
🟣разделяют 3 этапа зрелости Eval-ов. Начальный (Nascent) — исследовательский, где отсутствуют стандарты. Промежуточный (Maturation) — появляются соглашения по лучшим практикам, но пока нет единой регуляции. Зрелый (Mature) — действуют формальные стандарты, статистическая обоснованность, результаты интерпретируемы. Мы сейчас в Т-Банке постепенно закрепляемся на этапе 2 (Maturation) и это совсем непросто
🟣и чтобы сделать свои Eval-ы Mature, вот что потребуется: описать множество четких и интерпретируемых метрик, покрыть тестами как можно больше частей пайплайна, обеспечить надежность и воспроизводимость и не забыть про статистическую значимость

Выглядит не очень тривиально, да? Потому что и так есть вопросы к бенчмаркам и оцениваемым моделям, а тут надо оценивать массивный пайплайн.

И вот буквально неделю назад вышел новый стандарт оценки качества моделей STREAM (A Standard for Transparently
Reporting Evaluations in AI Model Reports). Он предлагает формат для стандартизации тестирований моделей и представления результатов. И хоть в большей степени ориентирован на ChemBio бенчмарки, авторы пишут, что его получится использовать и для бенчмарков из других отраслей.

Скоро расскажу вам о нем подробнее, а пока дочитываю статью

Prophet Arena или бенчмарк для оценки предсказательной способности LLM

Бенчмарков сегодня невероятно много, но почти у всех них есть общие проблемы:
1️⃣ Saturation — ситуация, когда модели начинают показывать близкие к максимальным значениям метрики на бенчмарке. И в итоге разница между моделями становится минимальной
2️⃣ Data Leakage — когда в бенчмарке оказывается задача из данных для обучения модели, и наоборот
3️⃣ Data Drift — значимое изменение распределения данных, которое может повлиять на оценку качества
4️⃣ Низкое разнообразие задач и доменов в бенчмарке

И вот недавно был анонсирован бенч Prophet Arena, который направлен на оценку предсказательной способности LLM. И он отлично справляется как минимум с проблемами 2 и 3. Почему:
🟣потому что включает в себя актуальные задачи, которые решаются прямо сейчас (и ответа на них пока ни у кого нет. Но это не точно). Задачи передаются из американской платформы Kalshi, где пользователи делают ставки на исходы политических, экономических, научных, спортивных и других событий. Например, прямо сейчас вы можете поставить на будущего мэра Нью-Йорка (где общая сумма ставок уже > $20 mln). Кстати, это единственная подобная платформа в США, которая имеет федеральную лицензию
🟣бенчмарк является динамическим. И распределение определяется заинтересованностью в различных доменах

Конечно, тут может возникнуть проблема с большим количеством задач, где длительность получения ответа > нескольких месяцев / лет. Однако, авторы не пишут о такой проблеме ничего.

Какие метрики считаются
🟣Brier Score (эта метрика на картинке). Это метрика для оценки качества вероятностных прогнозов бинарных событий. Метрика измеряет среднюю квадратичную ошибку между прогнозируемой вероятностью события и фактическим исходом (то есть чем меньше, тем лучше)
🟣Average Return. Тут чуть сложнее, потому что происходит моделирование оптимальной ставки для каждого события по каждому заданию / вопросу. И в итоге считается средняя доходность от ставок, основанных на прогнозах модели. Правда непонятно, является ли эта метрика динамической для каждого задания или же нет

На графике можно заметить, что хуже всего по метрике Brier Score модель DeepSeek R1. Это связано с тем, что модель часто присваивает нулевую вероятность всем опциям в задании.

Куда планируют развивать Prophet Arena
🟣добавить агентские сценарии
🟣увеличить количество заданий
🟣включить пользователя в процесс для оценки ответов моделей

А какие бенчмарки вызвали у вас наибольший интерес за последнее время?