OpenAI говорит, что SGR - тупиковый путь

Точнее, сегодня это заявил исследователь из OpenAI Lukasz Kaiser, один из авторов знаменитой статьи о трансформерах «Attention is all you need».

Лукаш работал не только над трансформерами, но и над последними моделями, ориентированными на reasoning. Сегодня на TED AI он рассказал, что текущие модели reasoning работают неплохо, однако имеют существенные ограничения: они решают задачи линейно, «забрасывая» их токенами, плохо масштабируются и долго отвечают. По его мнению, будущее за следующим поколением моделей - так называемыми Researchers, которые гораздо лучше поддаются распараллеливанию (фото его слайдов на эту тему - в комментариях).

Я рассказал Лукашу о подходе Schema-Guided Reasoning (SGR), когда сложный ризонинг эмулируется в меньших моделях через фиксированные планы, и спросил, насколько это соответствует его видению будущего.

Лукаш считает, что SGR - это тупиковый путь развития. Почему? Да потому что reasoning в таком случае фиксированный, и модель движется по заранее проложенным «рельсам». Даже если с таким промптом модель решает конкретную задачу точнее и быстрее, чем универсальная модель, она никогда не сможет самостоятельно провести научное исследование или свернуть белок.

Какой же тогда правильный путь? По мнению Лукаша, нужно обучать модели с помощью Reinforcement Learning (RL), чтобы «не обрезать им крылья». Правда, он отметил, что нормальных open-source библиотек для этого пока нет, но вот в API OpenAI есть Reinforcement Fine-Tuning как фича.

Кроме того, по его словам, constrained decoding (Structured Outputs) - тоже «зло», так как оно ограничивает полет мысли моделей. Лучше использовать тюнинг или полноценное обучение.

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

«Ну работает ваш SGR на маленькой модели лучше, чем reasoning-модель с доказанным качеством? Молодцы! Но путь всё равно тупиковый, ведь протеины-то оно складывать не сможет».

А что вы думаете по этому поводу?)

Ваш, @llm_under_hood 🤗

PS: А почему именно складывание протеинов? Так после него выступал Oriol Vinyals - VP исследований Google DeepMind и один из тех лидов для Gemini! Они в очередной раз рассказывали про то, как AlphaFold получил Нобелевку за это самое складывание протеинов.

Стык медицины и AI - это будущее

Тут и спасение жизней, продление срока активной старости, да и просто очень хорошие инвестиции. Сама отрасль сейчас бурно развивается, особенно в Европе и США. Компании очень хотят применять там AI (за пределами CV и семантического анализа текста), но пока не очень умеют. Хотят RAG-ов, но чтобы без галлюцинаций.

И у меня недавно спросили - а что если провести аналог Enterpise RAG Challenge, но на данных из медтеха?

Не в смысле, что речь идет именно о RAG-ах и об одном соревновании, но о самом процессе систематичного прикладывания AI/LLM к бизнес проблемам. Мы же один раз вместе прошли путь от пары LLM кейсов и “а как вообще работает нормальный RAG” (см объявление от Апреля 2024) до SGR Deep Research, который, несмотря на возражения OpenAI, утаскивают к себе в работу отделы банков и коммерческих продуктов.

Прогресс за пару лет у нашего коммьюнити вышел настолько впечатляющий, что появились люди и компании, которым интересно посмотреть, а можно ли все это переложить на одну из самых перспективных отраслей будущего - медицину? Они готовы взять на себя головную боль [1] по подготовке данных и упаковке их в интересные задания в формате нашего коммьюнити (а взамен хотят посмотреть на неожиданные решения и перспективные команды)

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

Так что сейчас мы начинаем приоритизацию доступных источников данных и перспективных проблем в медтехе [2]. Пообщаемся с экспертами и командами, закроем ERC3 и начнем готовиться дальше.

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

А в процессе еще и сделать мир лучше.

Ваш, @llm_under_hood 🤗

[1] в области compliance, MDR 2a, EHDS, SPE, SaMD и других страшных слов.

[2] Скорее всего, придется делать "слоеный пирог" из открытой синтетики и быстрых закрытых evals, которые выдают карты ошибок. Если у вашей команды есть доступ к интересным данным, которые быстро и удобно упаковываются в задачу и хочется посмотреть, как с такой задачей могут справиться другие - напишите мне.

Бенчмарки Sonnet 4.5 и Deepseek - ничего особенного

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

Anthropic Sonnet 4.5 заняла 24ое место, что на четыре пункта выше, чем Sonnet 4.0. Главное, она выше Opus 4.0, так что если вдруг выйдет Opus 4.5, то у него есть шансы подняться повыше (например, до уровня Sonnet-3.7 thinking)

Вообще, с Anthropic Sonnet у меня двойственные отношения. С одной стороны эта модель допускает достаточно глупые ошибки в сложном коде. Но, с другой стороны, если нужно сделать красивый интерфейс, то альтернатив ей я пока не вижу.

Deepseek V3.2 Experimental - 36ое место, на уровне deepseek-chat-v3-0324. Среди всех deepseek моделей (не r1) - это самое высокое. Кстати, terminus 3.1 будет пониже - на 45ом.

Ваш, @llm_under_hood 🤗

PS: про бенчмарки, включая их двухлетнюю историю, расписано тут

Визуализация динамики качества с картами ошибок в Github-е

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

Эти изменения и карты - из проекта, про который я много писал раньше. Он потихоньку продолжается, а качество доросло до 87.1% (за счет оптимизации доменной модели и упрощения промптов).

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

Ваш, @llm_under_hood 🤗

PS: Функционал сравнения версий картинок довольно простой. Наверняка он есть и не только в Github.

Генерация симпатичных и консистентных интерфейсов при помощи HTML брендбука

Сейчас разбирали с одной командой способы генерации красивых интерфейсов при помощи LLM. В интерфейсы им не очень хочется, душа стремится поскорее изучать кодинг больших проекты при помощи агентов. И всем кажется, что можно навайбкодить что-то симпатичное быстро.

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

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

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

Делается это так:

(1) Разделяем генерацию UI на шаги: сперва LLM-кой создаем HTML-гайд по желаемому стилю (чтобы и описывал и показывал примеры). Если что-то не нравится, то исправляем прямо там, пока не ушли в дебри проекта.

(2) Пакуем все в "мини-фреймворк" в одном файле: при генерации гайда можно попросить LLM-ку сделать прямо HTML+CSS микрофреймворк по бренду, отдать его дизайнеру на проверку, и использовать это для всех UI-проектов. Этот файл и будем вставлять в промпт или проект (Claude Project), в котором нужно сверстать или изменить интерфейс.

(3) Сначала верстаем интерфейсы в Claude Web UI на базе гайда (они получаются у клода симпатичнее, чем Gemini/ChatGPT итп), а потом копируем в основную среду разработки и просим интегрировать.

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

Пользуетесь чем-то подобным? Кидайте тоже в комментарии скриншоты своих интерфейсов и гайдов!

Ваш, @llm_under_hood 🤗

Cпасибо, сообщество! Истории успеха благодаря вашим инсайтам

В канале Валерия люди начали делиться историями, когда смогли сделать что-то полезное благодаря OpenSource и наработкам наших коммьюнити.

Например:

Работаю в небольшой компании и без всего этого контента и без SGR у нас буквально не было бы продукта. Настолько, что я во время прототипирования рассказал коллеге о постах Рината и у нас резко сменилась концепция, мы запустились за три месяца и уже есть первые довольные клиенты. Для парочки бекендеров которые решили резко ворваться я считаю это лютый успех. Так что всем причастным большое спасибо, буду дальше познавать тонкости искусства заколдовывания стохастического попугая.

или

Same. Работаю в большом зелёном и часто мониторю такие проекты, активно учусь у ребят.
Хотя сама контрибьютить в open source пока боюсь :)
В общем парни очень полезное дело делают)

или

Мой первый и пока единственный скрипт по методике SGR - генерация протокола встречи из транскрипта

Результаты очень радуют, использую несколько раз каждый день.
Поэтому планирую затаскивать SGR и в остальные проекты.

- Для локального распознавания использую модель qwen/qwen3-4b-2507 (Да, очень маленькая. Да, результаты лучше, чем у больших.)
- Для облачного распознавания использую модель google/gemini-2.5-pro

P.S. До этого был аналогичный скрипт без SGR, и результат был существенно хуже даже на больших моделях.

И это мы еще не говорим о кейсах растаскивания SGR Deep Research в крупные компании разных цветов. А ведь еще им интересуются люди, которые пишут книги, по которым работают архитекторы крупнейших компаний мира. Пруф в комментариях)

Напишите в комментарии, если вам как-то помогли посты в коммьюнити, OpenSource код, отчеты или (особенно) SGR Deep Research!

Ваш, @llm_under_hood 🤗

Дайджест радостных новостей про Schema Guided Reasoning (SGR)

(1) Прикладываю слайды (ссылка) с презентации @MadML_Talks про SGR. Должна быть и запись, но я пока не видел. Акценты в слайдах мне нравятся - про прозрачность и тестируемость систем!

(2) SGR DeepResearch переехал на новое место - https://github.com/vamplabAI/sgr-deep-research. @neuraldeep и команда яростно пилят и экспериментируют с подходами.

(3) Мне рассказали, что SGR затянули во второй крупный банк, пару медтехов, CRM-систему для бизнеса и один академический препринт. Хвалят в целом за предсказуемость и повышение качество результатов

Особенно интересно слышать формулировки вроде:

Два продукта внутри компании внедряют sgr на базе qwen3-4b

Надеюсь, авторы когда-нибудь расскажут, как у них на практике взлетает и работает то, что в теории работать не может!

Ваш, @llm_under_hood 🤗

Видео доклада "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 🤗