Открыта регистрация на 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 🤗

Бенчмарк LLM в ERC3: AI Agents

Вот график лучших решений ERC3 в бенчмарке Store, где архитектуры ранжированы по стоимости запуска и времени исполнения.

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

Агенты, которые не присылали телеметрию через api.log_llm или присылали имя модельки, не совпадающее с именем модели на OpenRouter - в рейтинг не попали (т.к. цены считаем на базе OpenRouter и присланной телеметрии).

Ваш, @llm_under_hood 🤗

Мелкий апдейт на платформе ERC

Пока еще не ERC3 бенчмарк, просто подготовка к его выкладке

(1) Если при отправке решения не была прислана телеметрия вызовов LLM (название модели и число tokens), то из очков вычитается 10% (в eval logs это будет упомянуто). Так все заранее смогут проверить и поправить своих агентов.

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

STORE бенчмарк менять не стал, но в ERC3 это уже будет встроено.

Ваш, @llm_under_hood 🤗

Я доделал основную часть симуляции для ERC3 и выкатил API на проду! В PythonSDK тоже все есть - см. версию 1.0.5

Этот бенчмарк моделирует системы целой компании для запуска в них AI Агента. Они моделированы аналогично тому, как в компаниях и внедряются агенты, только без риска что-то сломать.

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

Да, там в API затерялась и knowledge base, как в настоящем AI agent deployment в корпорации.

Уже есть пара тестовых заданий для ERC3-DEV, чтобы начать представлять себе масштабы). К пятнице я закончу набор API и выложу 15 тестовых заданий c включенным evaluation.

Сразу предупреждаю, не привязывайтесь слишком к компании Aetherion Analytics Gmb. Это будет только одна из компаний в финальном бенчмарке.

Что скажете? Остальные задания делать проще или реалистичнее?

Ваш, @llm_under_hood 🤗

Ссылки: Платформа | Регистрация | Пример агента | Видео на русском

Официальное соревнование состоится 9 декабря, но люди соревнуются на STORE бенчмарке уже сейчас.

Кейс про выбор правильного тендера, с ужасным стэком

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

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

Другие кейсы в канале см тут.

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

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

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

(2) система - выкачивает эти письма, достает ссылки, идет по ссылкам и выкачивает сопустствующую документацию. Если есть каптча - подключается gemini 2.5 для ее прохождения.

(3) выкачанная документация по тендеру прогоняется через чеклист по критериям анализа этой фирмы (gpt-5). Задача тут - отсеять тендеры, которые фирме точно не интересны (нет скилов или прошлого опыта) или невыгодны (грубая оценка объема работа не сходится с ценой).

(4) Получается такое крупное сито. Если какой-то тендер проходит через него, то файлы грузятся на SharePoint, генерится краткий отчет в виде HTML и вставляется в Confluence, а в Teams присылается краткий отчет про тендер.

А теперь самое ужасное про стэк - это все написано на C#, на котором Structured Outputs сходу не заводится. Поэтому написали промпты просто словами, упомянув про необходимость reasoning. Модели тут используются избыточно мощные, поэтому проблем нет. Самое сложное в проекте - это не промпты, а все интеграции. LLM - это просто клей, которые объединяет разные процессы вместе.

Выхлоп?

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

Можно сделать лучше и правильнее? Однозначно.
Надо ли?

Ваш, @llm_under_hood 🤗

Как решить проблему SO с Invalid JSON в OpenAI SDK?

В чате моего курса (https://abdullin.com/ai-assistants-course) напомнили, что OpenAI так и не пофиксили полностью свою реализацию Structured Outputs в GPT-5.

Более подробно о проблеме можно прочитать в OpenAI Community. Сейчас она всплыла на простом кейсе на azure gpt-5-mini. Там парсинг ответа вываливается с ошибкой Invalid JSON: trailing characters at line 2 column 1

Как решить эту проблему, если такое происходит в вашем проекте? Нужно встроиться в OpenAI SDK (например через httpx перехватчик или перегрузку методов) и - при встрече теоретически невозможного ValidationError - ручками исправить исходный JSON. Вот пример кода, который можно вставить в проект (лучше до того момента, как импортировали openai) для этого:

# let's fix OpenAI parsing

import re
from pydantic import ValidationError
from openai.lib._parsing import _completions as _parsing_completions

_original_model_parse_json = _parsing_completions.model_parse_json

def tolerant_model_parse_json(model_cls, data: str):
    try:
        return _original_model_parse_json(model_cls, data)
    except ValidationError as e:
        # impossible for valid JSON, but OpenAI can surprise!
        pattern = r'\}\n+\{'
        parts = re.split(pattern, data)

        if len(parts)>1:
            print(f"Gotcha!\nSTART\n{data}\nEND\n")
            return _original_model_parse_json(model_cls, parts[0]+"}")

        raise

_parsing_completions.model_parse_json = tolerant_model_parse_json

Если вставить этот патч в SGR Demo агента, то он будет благополучно работать даже с OpenAI моделями семейства gpt-5.

Только print отладочный не забудьте убрать потом.

Ваш, @llm_under_hood 🤗