Видео доклада "Schema-guided reasoning: как заставить LLM быть умнее"

Эту запись сделали и выложили ребята из @MadML_Talks
https://www.youtube.com/watch?v=0XhFB9OItqw

Разобрано очень дотошно и хорошо. Если есть какие-то вопросы к авторам, задавайте их тут или у них в чате!

Ваш, @llm_under_hood 🤗

На чем написан ChatGPT под капотом? Пара инсайтов от инженеров OpenAI

Контакты и связи нашего коммьюнити обширны 🤝. Одного хорошего человека позвали на OpenAI devday, где он смог поговорить со множеством инженеров.

Интересно, что народ из OpenAI используют очень простые вещи для построения своих систем. Даже, если это ChatGPT и 800M пользователей: Python, FastAPI, Kafka, Temporal

Temporal - это весьма интересная штука, которая позволяет реализовать засыпающие процессы, которые устойчивы к падениям и проблемам. В том числе и разнообразные бизнес-процессы.

Кода очень много, он монолитный. Приходится работать на Маках в 128GB, да и то тяжко.

Еще забавно, что в OpenAI не выключают GPU кластеры на ночь, просто крутят их на 100% загрузке круглые сутки. Т.к. иначе будет очень сложно разворачивать их обратно - много проблем и обвалов. Кстати, плавящиеся GPU - это не просто мем. У них реально были проблемы с коннекторами и компоненты, которые плавились.

Кстати, WebUI часть ChatGPT написана на Remix v2 (React Router v7). Переехали туда с NextJS год назад.

В общем, все очень брутально и минималистично. Иначе OpenAI не смогла бы так быстро стать крупнейшей в мире частной компанией (по данным на 3 октября).

Ваш, @llm_under_hood 🤗

Давайте добавим колонку MED в LLM бенчмарк! 🧬🤝

Текущая версия моего LLM бенчмарка основана на кейсах внедрения в бизнес-проекты. Каждый eval в бенчмарке - это небольшой тест из реального проекта, одна клеточка на error map.

Бенчмарком пользуются команды при выборе моделей под свои задачи. Чаще всего их интересуют не самые мощные модели, а самые маленькие модели, которые смогли забраться достаточно высоко. Например, Qwen3-32B или gpt-oss-20b

А давайте, сделаем этот бенчмарк полезным не только для бизнеса, но еще и для команд, которые внедряют AI/LLM в медицине!

Для этого мне нужны небольшие примеры промптов, маленькие кусочки задач. В идеале это даже такие кусочки, которые должны работать (и с которыми справится человек), но которые у вас работают не идеально.

Естественно, я эти промпты и задачи (как и остальные кейсы из бенчмарка), не буду публиковать. Но лучше, если они будут анонимизированы. Можно использовать примеры из OSS MedTech датасетов вроде MIMIC-IV on FHIR, RadEvalX, ReXErr-v1 итп

Можно писать мне в личку в формате.

Ринат, вот у нас в продукте есть такой шаг, где от модели требуется сделать …. (описание чего и зачем). Можно проиллюстрировать таким кейсов. Мы подаем LLM на вход такой текст и такую SGR/SO структуру (если есть). Правильный ответ выглядит так, а у нас почему-то модель показывает X, Y или вообще несет пургу.

Интересно было бы посмотреть, как бы ты подправил тут SGR. И вообще какие модели из бенчмарка хорошо справляются с подобной задачей.

Если получится набрать разных MED кейсов, тогда я с удовольствием встрою их в бенчмарк и добавлю их в MED колонку. Вот и увидим, так ли хороша MedGemma, как ее хвалят.

Ваш, @llm_under_hood 🤗

PS: Не обязательно встраивать в бенчмарк именно ваш пример/eval. Можно посмотреть вместе и сформировать полностью синтетический вариант.

Самая главная фишка LLM - это то, как они меняют саму экономику работы.

Вместо того, чтобы делать все руками, можно выделять простые и повторяющиеся вещи и "сваливать" их на LLM, не жалея при этом их времени. А творческая составляющая и контроль остаются на человеке.

Это применимо как к автоматизации бизнес-процессов, так и к разработке систем.

Например, сейчас у меня голова не варит, но хочется немного поработать над новой версией сайта с лабами, чтобы упростить архитектуру и добавить фич. Можно взять несколько простых идей и отправить их в OpenAI Codex с просьбой проанализировать их и написать implementation plan. А потом проглядеть план и реализовать. Если все выглядит хорошо - можно принять PR. А если не получается сходу, то просто проигнорировать изменения. Не получилось, так не получилось.

(1) Время LLM не жалко. Пусть копают.
(2) Всегда можно запустить несколько версий агентов и выбрать лучший результат. Остальные выкинуть. Это Спарта.
(3) Наличие тестов/способов самостоятельной оценки качества/Feedback Loop сильно повышает качество и стабильность результатов.

Ваш, @llm_under_hood 🤗

DDD + LLM + SGR = ❤️‍🔥

Сюрприз от организаторов KanDDDinsky в Берлине! В четверг, в одном трэке с Эриком Эвансом, я расскажу несколько историй успешных внедрений AI/LLM в корпоративных кейсах.

Вы (если вы в этом коммьюнити достаточно давно) уже все эти истории знаете - про важность тестов, про преимущество JSON+SO над всеми формами выдачи данных, про внедрения SGR в разных компаниях. Вы это знаете, а эксперты с DDD - пока не очень. И им интересно.

И поэтому этим организаторы конференции не ограничиваются. На следующий день в OpenSpace формате мы вместе с Эриком Эвансом еще проведем панель на эту же тему: DDD + LLM + SGR = ❤️‍🔥

Заходите на огонек!

Ваш, @llm_under_hood 🤗

Открыта регистрация на Enterprise RAG Challenge 3!

Все, как в прошлые ERC соревнования, но только вместо анализа сложных PDF - будем пилить агентов/чатботов. Это одновременно и проще (нет таблиц и графиков) и сложнее (нужно выбирать между function calling и SO, между Anthropic и своей моделью итп)

А можно будет и не выбирать, а сразу отправлять разнообразные эксперименты!

Давайте снова соберем 50 разных команд со всего мира с кучей разных экспериментов, а потом посмотрим - какая архитектура и LLM круче всех в своей категории при построении агентных систем!

Регистрироваться тут: https://go.abdullin.com/ERC

Ваш, @llm_under_hood 🤗

PS: Больше информации про характер заданий в этом раунде.

Знаковый слайд. Но не потому, что Eric Evans (автор DDD) рассказывает про базовые вещи DDD+AI с учетом перспектив и наработок, которые мы сделали в нашем коммьюнити и проектах. А потому, что вон ту черную изоленту ему на ноутбук присобачил я. Чтобы диоды не светили операторам в камеры.

Технологии приходят и уходят, а изоленты - вечны.

Кстати, Eric Evans будет keynote спикером на Enterprise RAG Challenge 3.

Какие бы вопросы вы хотели задать ему?

Ваш, @llm_under_hood 🤗

Заметки на полях по итогам KanDDDinsky

Напомню, что KanDDDinsky - это ежегодная конференция в Берлине, которую организовывает Marco Heimeshoff.

А DDD - Domain-Driven Design - это методология анализа проблем и реализации софта, которая выросла из потребостей корпораций и заточена на корпоративные проблемы. Для успешной реализации проектов там надо учитывать не только специфику отрасли, но и всякие интересные вещи вроде политики, организационной структуры и отношений между командами. Встретить консультантов, которые ведут проекты в 50-70 команд - не редкость.

Интерес к применению AI в принципе большой, ибо туда компании перебрасывают значимую часть бюджетов, но вот внятной экспертизы и насмотренности у внедренцов не хватает. Будем пытаться исправлять всем DDD коммьюнити

Энтузиазм и интерес в целом есть. Скажем, на ComoCamp весной ко мне на OpenSpace сессию пришел один единственный человек (почти все ушли к Alberto Brandolini), теперь уже был целый выделенный DDD+AI трэк, а на следующие конференции планируется уже выделить отдельные дни с воркшопами на эту тему.

Я рассказал про три самых интересных проекта c LLM под капотом, где без использования принципов DDD мало что бы получилось (reasoning история, невозможная история и история с анализом старого кода - они были в канале). Видео рассказа они потом выложат.

И еще провел workshop по применению AI Case Mapping вместе с демонстрацией и описанием принципов (если кратко - описываем текущие проблемы бизнеса, а потом оцениваем на возможность применить к этому AI с учетом известных успешных кейсов внедрения и их грабель, я фотку стены выложу в комментарии). Это был интересный эксперимент, т.к. я его впервые проводил вживую без подготовки и в условиях ограниченного времени (обычно это online + Miro в ином формате). Eric Evans говорит, что вышло несколько сумбурно, нужно закладывать сильно больше времени. А еще говорит, что можно не городить огород и взять для анализа проблем бизнеса обычный Event Storming, а после выявления hotspots, уже моим способом анализировать и приоритизировать их на возможность быстро и безрисково применить AI/LLM. Alberto не против попробовать такое.

Народу на конференции очень хорошо “зашла” концепция, что мы ограничиваем внедрение AI/LLM одним небольшим компонентом, который встраивается в процесс. У них тогда сразу в голове начинают в правильном направлении крутиться мысли - если это компонент, то его можно описывать, тестировать и версионировать. То есть тесты и evals приходят в голову в первую, а не в последнюю очередь.

В общем, вышло интересно. Если кто работает с крупными банками, международными корпорациями и тому подобным - всячески советую KanDDDinsky и подобные мероприятия. Там и познавательно, и контактов можно интересных набрать.

Ваш, @llm_under_hood 🤗

Новости с полей про разворачивание системы с встроенным AI+Coding агентов

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

Пару дней назад сделали полный прогон на новых документах от новых компаний, которые добавили в пайплайн (первые шаги пайплайна - это отдельная песня). Пайплайн прожевал их, найдя 41932 сущностей

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

В процессе система отчиталась, что AI Coding agent сгенерировал 2515 инструментов в 372668 строчек кода общим объемом в 15.28MB. В сумме было потрачено $61.62 (такими темпами аккаунт не скоро выйдет на новый Tier). Точность извлечения на тестовых (самых сложных) данных: 84.8%, что выше требований клиента. Причем, слабое место пайплайна видно глазами - категория документов и полей в документе (смотрите на большую красную секцию на карте ошибок в комментариях - это китайские поставщики, в их документах доменная модель очень сильно отличается в ряде моментов). Можно над этим работать дальше или просто учитывать при использовании результатов.

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

Директора очень довольны получившейся архитектурой (дословно "Because we can!"), особенно тем фактом, что этот код не видел ни один человек, да и не увидит. При новых прогонах - просто перегенерируем заново.

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

Ваш, @llm_under_hood 🤗

Вставляет ли OpenAI "втихую" JSON схему в каждый запрос со Structured Outputs?

Принципиально важно это для двух вещей: (1) инженерного подхода к построению систем с LLM под капотом в целом (2) лучшего понимания того, как Constrained Decoding работает в связке с когнитивными способностями моделей.

Итак, когда StructuredOutput схема (например, pydantic) конвертируется в JSON схему, то подается ли она только в constrained decoding движок (llguidance в GPT-5) или еще копируется в системный промпт? Причем в документации OpenAI нет ни слова про копирование.

Давайте проверим. Берем такую SGR схему:

class CandidateEvaluation(BaseModel):
    brief_candidate_summary: str = Field(..., denoscription="in Thai")
    rate_skill_match:  Annotated[int, Ge(1), Le(1)]
    final_recommendation: Literal["hire", "reject", "hold"]

и отправляем в OpenAI c запросом в десяток tokens:

user = "evaluate Sam Altman for DevOps Role at OpenAI"
completion = client.chat.completions.parse(
    model="gpt-5-mini",
    response_format=CandidateEvaluation,
    messages=[
        {"role": "user", "content": user },
    ],
)

Если JSON схема НЕ добавляется в промпт, тогда промпт будет в пределах 20-30 tokens, а ответ не будет содержать ничего неожиданного.

Запускаем и смотрим на размер входного промпта и сам ответ:

completion.usage.prompt_tokens == 100
completion.choices[0].message.parsed.brief_candidate_summary[:10] == "แซม อัลท์แ"

Что и требовалось доказать. Странные письмена - это тайский язык, о котором попросили OpenAI в поле denoscription схемы. Это поле модель увидит только в том случае, если JSON схема будет скопирована в промпт вместе с denoscription.

Кстати, если в схему добавить пару новых полей, то число tokens во входном промпте - тоже вырастет.

Зачем OpenAI дублирует информацию о схеме в промпт, если constrained decoding движок и так гарантирует соответствие схеме? Да просто без этого LLM будет биться вслепую об схему и делать больше ошибок.

А как это относится к инженерному подходу? Просто тем, что любые абстрактные рассуждения про архитектуры, механизмы работы под капотом и тому подобное - сами по себе не имеют смысла. Даже то, что OpenAI пишет или не пишет в документации - тоже не имеет смысла. Имеет смысл только то, что мы можем измерить и оценить [1]. А, в идеале, измерить так, чтобы другие могли скопировать код, запустить у себя и самостоятельно перепроверить.

Можете попробовать запустить эти сниппеты сами и поиграть с ними.

Ваш, @llm_under_hood 🤗

---
[1] то, что мы можем измерить или протестировать - мы можем потом осознанно докрутить и улучшить

Я сегодня закончил первый прототип платформы для ERC3: Enterprise AI Agents. Получается довольно симпатично, сейчас все расскажу.

В общем, будет сайт платформы. Все, кто зарегистировался в ERC3 (сделать это можно тут), смогут получить AccessToken для него.

На этом сайте будут доступны несколько стендов. Каждый стенд - это набор систем, которые работают вместе, вместе с описанием и API. Их можно вызывать как вручную, так и через агентов.

Например, уже есть отладочный стенд shop (им я отлаживаю всю систему) - это APIшка для небольшого магазина, со своей логикой и базой. [1] Там есть такие методы:

(1) GET /products - получить список продуктов
(2) GET /basket - просмотреть текущую корзину
(3) POST /backet/add,remove,checkout - добавить продукты в корзину, убрать из корзины, оплатить.

Как это все использовать?

Пишем скрипт, который:

(1) Запускает новый эксперимент на стенде store
(2) Пока остались нерешенные задачки в эксперименте
(3) Забирает следующую задачку для эксперимента (например “Buy ALL GPUs”) и url для API

В этот момент на платформе разворачивается изолированная среда, сконфигурированная специально под эту задачу. API будут настроены и заполнены данными под эту задачу. Даже, если параллельно 100 команд решают другие задачи - у них будут свои изолированные среды.

(4) Теперь мы можем запустить своего агента, скормить ему url для API от этой задачи и отправить решать ее. Скорее всего, в этой задаче "Buy ALL GPUs", ему надо будет получить список продуктов, выбрать GPU, добавить их в корзину и сделать checkout [2]

(5) Когда агент закончил работу, вызываем “завершить задачу” и идем в пункт (3) - пока остались задачки, решаем их. Если не осталось - можно посмотреть Score и логи выполнения задач агентом. [3]

Запускать можно будет любое число экспериментов, помечая их метаданными по архитектуре, используемой модели, размеру GPU и всяческим параметрам. Это пригодится для AI R&D деятельности нашего коммьюнити и за пределами соревнования.

Логика экспериментов и правила соревнования остаются аналогичными ERC2. Перед началом ERC3 я все еще раз напомню и проговорю.

Доступ к этому тестовому стенду планирую дать в течение следующих дней 5-7. Доступ к стенду с API-шками от финального соревнования - за 10-14 дней до соревнования. Ну а конкретные соревновательные задачи откроются 26 ноября.

Ну как вам оно?

Ваш, @llm_under_hood 🤗

[1] store - это простейший тестовый стенд, к нему я дам доступ в ближашую неделю-другую. Для соревнования будет что-то более серьезное.

[2] на самом деле, даже в этой простой задаче не все так просто. Ведь агент обнаружит, что API возвращает продукты только страницами по 3, что больше 3-х page size делать нельзя. А при попытке купить все GPU обнаружится, что 2 H100 уже купили, и надо переделывать корзину. Каждая задача в рамках стенда - уникальна.

[3] Во время ERC посмотреть score на соревновательном стенде нельзя будет до момента оглашения победителей.

В Gemini 2.5 завезли нормальные Structured Outputs!

Поддержку для JSON Schema добавили в Google во все поддерживаемые модели Gemini (в старые версии - с ограничениями) Теперь Pydantic и Zod должны работать из коробки.

Они добавили поддержку самых часто запрашиваемых клиентами фич:

(1) AnyOf / Union - используется для раутинга в SGR
(2) $ref for recursive schemas - теперь можно делать нормальную вложенность каскадов
(3) max/min для числовых constraints

А заодно они, наконец, починили порядок свойств. Теперь LLM будет заполнять схему в том порядке, в котором поля прописаны

API now preserves the same order as the ordering of keys in the schema

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

Ну и в целом в Google пишут, что Structured Outputs - это один из самых частых инструментов, который используют разработчики при создании реальных AI приложений

Structured Outputs is one of the most frequently used tools by developers building real-world AI applications.

Вот пара цитат от их клиентов

We are building AI agents for the agentic web, and our main goal is to build trust in AI agents for handling business operations. Being able to define precise schemas and trust the output is key to our production systems. Structured Outputs have reduced API calls by up to 6x in some workflows and completely eliminated the broken JSON responses that used to require extra validation checks.

и

For us, Structured Outputs are all about reliability, speed and cost efficiency. By forcing the LLM to provide a predictable, machine-readable format, we can build more robust features faster, reduce errors, and use cheaper models for tasks that would otherwise require more expensive ones.

В общем, все молодцы. Новость тут.

Спасибо Тимуру, который первым поделился радостными новостями в чате канала. Кстати, у него есть и свой канал - The AI Architect (@the_ai_architect)

Ваш, @llm_under_hood 🤗

PS: А еще в документации про JSON Schema теперь упоминается, что заполнение поля denoscription в схеме - критично важно для управления работой модели

Use the denoscription field in your schema to provide clear instructions to the model about what each property represents. This is crucial for guiding the model's output.

Поэтому паттерны работы с Schema Guided Reasoning теперь можно смело пытаться переносить и на Google Gemini 2.5.

Видео (6 мин) работы чатбота с SGR на базе локальной Qwen-30b-a3b

Про Schema-Guided Reasoning говорили и писали уже много. Но одно дело слышать, а другое дело - увидеть, как оно работает вживую. Особенно, если реализация сделана настолько аккуратно и вдумчиво, как это сделали ребята из neuraldeep.

Поэтому вот вам видео на 6 минут - Русский / English

Самое классное тут, что эта демка работала на достаточно слабой и медленной Qwen-30b-a3b. А теперь представьте, что можно сделать, если прочитать методичку (написано тут), взять код (он есть в Github) поставить ему звездочку, взять модель помощнее и сделать свою версию - с тестами, с доступом в свои хранилища, учетом своей специфики и своими инструментами. И запускать все это на небольшой коробочке вроде DGX Spark.

А если будут PR - можно смело присылать их в ту репу, чтобы двигать дальше State of the Art в области применения небольших LLM на практике.

Ваш, @llm_under_hood 🤗

Update насчет соревнования ERC3.

Напомню, что ERC3 - это дружеское соревнование по написанию агентов, которое состоится в конце ноября. Зарегистрироваться можно тут. С нами уже 300 команд!

Среда работы для агентов будет выглядеть так:

(1) Подключаемся к API конкретного соревнования.
(2) Запускаем новую сессию
(3) Получаем поочередно новые задачи и передаем агенту, которому нужно будет дергать эти API для выполнения задачи
(4) Когда агент выполнил все задачи, сессия закрывается автоматом. Можно теперь ждать результаты.

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

И как раз сегодня у меня впервые получилось отладить весь этот процесс end-to-end, включая "ловушки" в задании. Вывод работы - на скриншоте.

К слову, SGR agent на 4o справляется с таким заданием в 75% случаях. Но я задачи для соревнования буду усложнять так, чтобы он не особо справлялся.

Ваш, @llm_under_hood 🤗

Кейс с LLM под капотом - поиск видео для монтажа рекламы

Давайте расскажу вам еще про один кейс достаточно необычного использования LLM в продуктовых целях.

Итак, компания - это производитель популярной на рынке продукции, что-то вроде Red Bull. Они производят и публикуют очень много видео-рекламы. Для этого у них есть гигантская библиотека всякого рода заготовок - в виде отснятых в прошлом роликов или сгенерированных заставок.

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

Соответственно, компании хочется, чтобы создатели новых роликов в компании могли лучше искать и переиспользовать существующий материал. Сейчас поиск работает немного похоже на Elastic Search - ролики помечаются тэгами и вручную “украшаются” свойствами с описаниями. Это долгая и муторная работа.

Команда реализации сначала сделала достаточно простую и очевидную вещь (пусть и дорогую, но всяко более дешевую, чем запись нового ролика) - они “скармливают” видео из архива в мощной LLM с video input и просят заполнить описание. Потом поиск ищет по этому описанию используя обычный векторный поиск и Query Expansion (когда просим LLM-ку “развернуть” запрос пользователя в нормальный запрос напрямую к БД, используя терминологию, в которой данные там проиндексированы).

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

А что тут можно сделать еще лучше?

(1) Начать со сбора данных - обвязать систему поиска интерфейсами так, чтобы можно было собирать телеметрию о том, какие результаты были использованы пользователями
(2) Построить пайплайн для извлечения структурированных данных о записи прошлых видео (какие видео люди искали, и какие элементы потом были использованы ими при монтаже). Благо все эти данные у них хранятся.
(3) Сделать так, чтобы разработчики могли быстро тестировать гипотезы и выкатывать их на проду с обратной связью, чтобы видеть - стали результаты поиска лучше или нет.

А дальше начинается самое интересное. Можно посмотреть на подход к реализации проекта “Кейс про агента-писателя” и переиспользовать подход к анализу оттуда в связке с идеей из кейса "про товары, которые невозможно найти". Пусть агент берет в качестве вводных данных не конкретное описание видео куска, а саму тему для рекламного ролика. И потом проходится по Schema-Guided Reasoning процессу:

(1) формулируем общую концепцию ролика
(2) ищем все потенциально подходящие ролики
(3) если нужно, прогоняем их через VLM с дополнительными запросами (эти метаданные сохраним в базе на будущее)
(4) прорабатываем outline финального ролика со скриптом и ссылками на ролики
(5) полуавтоматически “нарезаем” эти ролики прямо в timeline и грузим в проект для быстрого просмотра и редактирования

Тут две забавные вещи:
(1) Даже если человеку не понравится идея, он ее полностью выкинет и переделает, оставив только найденные материалы, то миссия уже выполнена. Целевая метрика - облегчить людям поиск подходящего видео.
(2) Эта концепция не нова. Ее уже используют в Amazon Prime для генерации кратких выжимок серий сериалов на платформе.

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

Ваш, @llm_under_hood 🤗


PS: Пост со списком всех кейсов

Claude поддерживает Structured Output

Наконец-то, и Anthropic добавили нативную поддержку генерации ответов по JSON схеме без повторных запросов и ошибок парсинга. То есть Structured Outputs. Можно тестировать и использовать Anthropic в бизнес приложениях.

Теперь все основные AI провайдеры и движки для локального запуска поддерживают этот режим.

Спасибо @the_ai_architect, который первым написал про это в чате канала.

Ваш, @llm_under_hood 🤗

Платформа для ERC3: AI Agents открыта!

На ней мы будем проводить соревнование 26 ноября (и после) по поиску оптимальных архитектур для AI агентов. Готовиться можно начинать уже сейчас:

Что можно сделать уже сейчас
(1) Ввести свой email, с которым регистрировались на ERC3, и получить ERC3_API_KEY. Новые регистрации активируются на платформе в течение 24 часов.
(2) Посмотреть бенчмарки на платформе
(3) Посмотреть исходники тестового агента (gpt-4o) и запустить его с ключом и любой моделью
(4) Посмотреть, как работа агента отражается в логах в консоли и в самой платформе. Платформа сразу же выдает оценку агенту!
(5) Увидеть слабые места и улучшить его! Или запустить на локальной модели.

Дальше:
(1) Послезавтра я активирую на платформе бенчмарк erc3-dev - это симуляция компании для соревнования, с тестовым набором задач. Оценки будут агентам выставляться сразу же. Интерфейсы там будут отличаться от симуляции магазина (более сложные).
(2) 26 ноября откроем рабочий бенчмарк. Нужно будет просто переключить своих агентов на новый набор задач и прогнать их.

Платформа | Регистрация | Пример агента

Можно запускать любое количество сессий и бенчмарков! Только, пожалуйста, описывайте кратко архитектуру и отправляйте статистику использования LLM (как в примере) с указанием названия модели в формате OpenRouter (например, `qwen/qwen3-8b`). Это позволит потом ранжировать агентов по локальности, требованиям к VRAM, стоимости и выводить красивые графики.

Ваш, @llm_under_hood 🤗

Первые инсайты с ERC3 про построение AI Агентов

Соревнование у нас еще не запущено, а инсайты уже идут! Это потому, что наше с вами коммьюнити просто офигенно. C момента запуска платформы прошло чуть больше суток, а на ней уже было записано более 3000 запусков разнообразных агентов. Люди пытаются получить идеальные 100 баллов на разогревочном STORE бенчмарке.

Валерий взял своего SGR Core агента, адаптировал инструменты под STORE бенчмарк и итерациями аккуратно сделал работающий системный промпт на 3k tokens. Говорит, что модели ленятся делать тесты всех вариаций продуктов (там где задача этого требует), что нет стабильных ответов (качество скачет 10-15% от прогона к прогону). Хочет дальше уйти от ReAct агента и попробовать сделать кодового агента (с написанием кода). Пока использовал gpt-4.1 и gpt-4.1-mini, думает попробовать локальный Qwen.

Подробнее журнал его первых экспериментов можно прочитать в этом посте у него в канале.

Влад смог выбить 100 на STORE бенчмарке c gpt-5.1-codex-max. Обещал тоже скоро поделиться инсайтами! Update: тут

Вырисовывается картина, что
(1) у агентов нужно аккуратно контроллировать контекст по мере работы, иначе они переполняют его и начинают теряться
(2) качество тулзов для агента очень сильно влияет на качество его работы. Можно сильно улучшить результат, если вручную сделать удобный для агента инструмент.

Если у вас есть какие-то интересные результаты или инсайты, пожалуйста, записывайте их и присылайте заметки с полей, пока не забылось.

А ScrapeNinja тем временем хочет сделать ERC SDK клиента под JavaScript. Если кому-то такое надо, обращайтесь к нему.

Платформа | Регистрация | Пример агента

Ваш, @llm_under_hood 🤗

PS: Eсли кто-то регистрировался на сайте TTA за последние сутки, можно прямо сейчас уже заходить на платформу и активировать ключи. Я только что загрузил 25 новых аккаунтов.

Я добавил на ERC3 платформу живой leaderboard с последними лучшими результатами бенчмарков. Для разогревочного STORE бенчмарка, 5% команд на платформе уже смогли получить идеальный результат.

Пока аккаунты анонимные, без дополнительной статистики или раскрытия архитектур. Это приделаем потом.

А статистики потом будет немало, у нас уже залоггировали более 11k запусков разнообразных AI Agents!

Ваш, @llm_under_hood 🤗

Новости и статистика про ERC3

Во-первых, по голосованию видно, что большинство за перенос даты соревнования на начало декабря. Зарегистрировалось уже 423 команд, складывается, такое ощущение, что все участники как раз проголосовали за перенос. Так и сделаем. Соревнование 9 декабря, ERC3 с тестовым набором задач будет в среду.

Во-вторых, у нас в платформе уже записано 23 тысячи запусков агентов, которые занесли в систему 204 миллионов input tokens и 11 миллионов output tokens.

Список последних агентов, которые получили 100 score на STORE бенчмарке можно увидеть тут. И тут уже не только тяжеловесы вроде gpt-5, но и локальные модели вроде qwen3-235b-a22b и

Краткие результаты анализа.

Базовый SGR NextStep агент из примера - это очень медленный, дорогой и слабый агент. Поэтому команды находят способы улучшить его.

Если верить статистике, то отличие идеальных агентов (те, кто решил все задачи), в том, что обычно делают больше работы за шаг - они грузят больше контекста в LLM вызов и работают дольше. Возможно, тут еще идет оптимизация контекста и добавляются выделенные инструменты. При этом количество LLM вызовов у них примерно такое же, как и у агентов послабее.

Для быстрых ответов некоторые команды используют Cerebras провайдера, который позволяет очень быстро гонять локальные модели.

Самый точный агент - SGR Tool Calling Agent with Reasoning Phases (OpenAI Function Calling), заодно он и самый тяжелый - 1.3M tokens на сессию. SGR-гибриды попроще (SGR with combo tools, SGR Agent + code agent + Added data about API итп) используют меньше tokens (280–350k на сессию), но и качество немного менее стабильное, медиана - 87.

NextStep JSON SGR Agent with Codex - неожиданная архитектура, которая потребляет 245k tokens на сессию и работает достаточно стабильно (есть не одна идеальная сессия в 100).

Ваш, @llm_under_hood 🤗