😗новые штучки😗
Сыренько но миленько

Теперь надо понять, где этот выигрыш по скорости применять, если TTFT моделек это сотни мс

https://github.com/pydantic/monty

Фанаты sgr-agent-core регулярно спрашивают нас, с чего мы взяли, что они наши фанаты?

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

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

Итак, проблема:
Фреймворк построен на Structured Output, но его поддерживают далеко не все конфигурации локальных/проприетарных LLM. Что самое страшное, даже если поддерживают, то не всегда однородно! Требуемые JSON схемы могут различаться.
Если фреймворк может работать, а может не работать на неопределённом множестве моделей - это ужасненько.

Structured output(SO) по моему скромному мнению это железная база, без которой сложно представить взаимодействие агентов хаоса вольного контекста и неопределëнных суждений и системы требующей, как правило, некоторой детерминированности, свойственной формальным языкам.


Примеры:
- Кто-то гарантирует ответ строго по формату, а кто-то может допустить ошибки даже при заданной схеме
- Кто-то поддерживает вложенные AnyOf и прочие агрегаты схем, а кто-то нет
- Где-то можно прокинуть ограничения min_length=1, max_length=3, а где-то нет, они в лучшем случае будут проигнорированы
- Кто-то хавает литералы и сопутствующие им enums, а кто-то отказывается

Как общий знаменатель пришла мысля создать решение, которое бы эмулировало независимый от ллмки SO без реальной в нём потребности на стороне провайдера . Идея "попроси модель сделать как надо" далеко не нова, и тем не менее было полезно посмотреть, насколько хорошо и стабильно это могут делать современные LLM


Концепция:
class ToolInstantiator принимает в свой init Pydantic модель, и имеет два основных метода интерфейса:
- Сгенерить промпт с описанием схемы для LLM
- Провалидировать полученный ответ LLM на предмет возможности билда инстанса Pydantic модели
На каждом следующем этапе промпт,выдаваемый классом, учитывает ошибки и проблемы предыдущей итерации, корректируя/фокусируя LLM

Путём некоторых экспериментов было выявлено, что прямая json схема для LLM сложновата ввиду нотации и неконсистентной информации о полях и их типах. А ещё иногда модельки путались и выдавали JSON schema аналогичную промптовой в ответ. Поэтому появился класс-помогатор SchemaSimplifier, разбирающий схему и преобразующий в более минималистичную нотацию

Ещё была интересная концепция, где каждое поле валидировалось по отдельности и даже если модель выдала в общем не полностью корректный JSON, часть верных полей принимались и не требовались на дальнейших итерациях генерёжки. Идея была отброшена ввиду нелицеприятности кодреализации такой фичи.
Лучше никому не видеть мою попытку в конвертацию типов raw context regex parsing -> json string->python type -> pydantic validator

Вот тут реализация - почти хорошо

работает следующим образом

for attempt in range(max_retries):
    async with self.openai_client.chat.completions.stream(
        messages=messages + [{"role": "user", "content": instantiator.generate_format_prompt()}],
    ) as stream:
        completion = await stream.get_final_completion()
        try:
            content = completion.choices[0].message.content
            tool_instance = instantiator.build_model(content)
            return tool_instance
        except ValueError:
            continue

А дальше был бенчмарк на всех моделях, до которых я смог дотянуться.
Тестировалось четыре кейса из числа тулов фреймворка:
- ReasoningTool, где было много ограничений на длину строк и списков
- WebSearchTool - прост
- CreateReportTool - сгенерить объёмный вывод
- NextStepToolSelector - по динамически составляемой схеме сделать корректный инпуту выбор function_name_choice

Так много GPTшек тут ибо на прогонах обнаружил, что разные версии очень неравномерно по выдаваемому результату себя ведут.
gpt-4o>>gpt-5-mini>gpt-5>>gpt-4.1

Upd: глянул приложенную версию бенча, там всё даже слишком хорошо, почти все задачи закрылись с первых попыток. Так было далеко не на всех итерациях и некоторые модельки включая gpt-5 любили забывать кавычки внутри кавычек и уходить в самоповторы все пять раз.

Тем не менее, если хитрый вайбкодинг бенча меня нигде не попутал, сама по себе возможность получения такового прогона говорит о качестве современных моделек на задачах генерёжки JSON форматированного текста

Файл бенча отдельно, чтоб пост красивее выглядел💅

От @evilfreelancer прилетело дельное замечание по поводу объёма бенча.

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


Первый файл: 10 попыток на модель, 4 базовых кейса
Второй файл: 10 попыток на модель, 2 продвинутых кейса

Модельки:
- gpt-oss-120b
- qwen3-30b-a3b-instruct-2507
- glm-4.7-flash:30b
- gpt-oss:20b

- gpt-4o
- gpt-4o-mini
- gpt-5-mini
- gpt-5-nano
temperature: 0.3

Тест кейс с примером контекста для модельки:

    nextstep_tools_6 = [
        ReasoningTool,
        WebSearchTool,
        ExtractPageContentTool,
        AdaptPlanTool,
        CreateReportTool,
        ClarificationTool,
    ]
    NextStepTools6 = NextStepToolsBuilder.build_NextStepTools(nextstep_tools_6)

    test_cases.append(
        (
            NextStepTools6,  # type: ignore
            "The user has found several relevant web pages during their research on 'Machine Learning in Healthcare'. "
            "They have URLs of articles and research papers that contain detailed information they need: "
            "https://www.nature.com/articles/s41591-021-01614-0 and "
            "https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6568067/. "
            "The user wants to extract the full content from these specific pages to analyze the information "
            "and include it in their research report.",
            "extractpagecontenttool",  # Expected tool name
            "NextStepTools (6 tools)",  # Case name
        ),
    )

(!)Поток мыслей(!)

Хочу для разнообразия от технички что-нибудь измыслить и пованговать чтоб сначала говорить "А я это ещё тогда говорил" а потом "надо же как интересно получилось"

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

(1)
На меня снизошло озарение, что по сути мы в работе с агентами движемся к светлому декларативному будущему над императивными инструментами

Нам всё ещё необходимо дотошно представлять поведение выстраиваемой системы примерно на уровне алгоритмов и структурно-архитектурной логики чтоб хотя бы прицениться к возможностям/перспективам реализации. Эти принимаемые решения о поведении весьма многообразны, зависят от опыта/видения/настроения разработчика и могут различаться вплоть до основополагающих принципов организации проекта.
Кто-то эвентики пуляет, кто-то шину данных пильнёт, кто-то подумает нунахер и построит на сырых запросиках. А! О! Или на очередях.

Большая проблема разработки - построение технологических систем в современных масштабах требует дичайшей когнитивной нагрузки. Для этого, разумеется, придумываются целые слои абстракций и инструментов и всё становится ещё хуже, что делает возможным работу почти со всем имеющимся зоопарком для команды из 3-5 людей, помноженных на необходимую скорость поставки и требования к обслуживанию.
Как процесс - мы с самого начала находимся в стадии автоматизации, подменяя изначальную сложность системы чем-то более высокоуровневым и имеющим проблему уже конфигурирования оного

> Фундаментальные проблемы решаются сложной абстракцией
> Сложная абстракция получает в конфигурируемые интерфейсы
> Конфигурационная надстройка упрощается и дробится на специализированные более простые технологии
> технологии получают экосистему для их встраивания и сопровождения
> Начинается новый виток абстрации


Как некоторый поинт:
У нас в профессии уже сейчас наработано достаточно инструментов, опыта, кодоартефактов чтобы при должной адаптации под агентов можно было исходить из декларативного подхода, что более и более успешно доказывает claude/codex/cursor в локальных задачах и современные PAAS и MLOps платформы на глобальных

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


(2)
Происходит какаето гиперфиксация непосредственно на кодинге, его вайб собрате в то время как имеет место быть более глобальный процесс. По крайней в публичных холиварах я чаще вижу "как можно не контролировать код?!" чем "Где найти x100 заказчиков с деньгами для теста гипотез"

Вангую: Цель тренда - заменить ВЕСЬ процесс разработки на декларативно-агентную систему.
Представим очень грубо, что у нас есть глобальный пайплайн-комбайн с задачей
- найти заказчика (ну или хотя бы продукт холдера)
-положить его на громадный фреймворк сбора информации
- Собрать хотелки
- Проанализировать хотелки
- Прикинуть хотелки с возможностями
- Прикинуть как возможности соотносятся с реальным миром, rpsами, байтами данных и затратами на электричество
- Реализовать
- Развернуть
- Выставить вкусный счёт
Чтоб оно выглядело как солидный процесс надо расставить ещё какое-то количество стрелочек и циклов между этими этапами.

Здесь хорошо выделить три части
1) Exploration - выделить всё существенное и запустить сопутствующие процессы проработки
-> Изначальный бизнес контекст формируется, расширяется, уточняется
2) Формализация бизнес контекста - организация всё ещё высокоуровневой информации в домен. Натягивание структуры, общеизвестных паттернов. К реализации будет предполагается именно то, что описано на этом этапе.
-> Имеющийся контекст сужается
3) Разработка - фривольная трансляция некоторого подготовленного бизнес домена на императивные структуры формальных ЯП или куда пониже.
-> автоматизация как цель

Или ещё проще: расширение-сужение-трансляция

Текущие процессы/фреймворки/подходы направлены на то, чтобы для всех этих этапов сократить количество сопутствующих потерь информации. А они так или иначе будут. И сопоставить это с человеческими возможностями, скоростями, проблемами коммуникаций

Если представить агентную систему, которая может простраивать все три этапа, то стоимость и скорость одного такого прохода изменится порядка 10^4-5 раз. И в этом случае центральным стоит задать вопрос "Что мы хотели и что получили" - сравнения некоторой узкой идеи, не подвергшейся расширению человеком на первом этапе, и финального результата. Прелесть в том, что этих результатов можно управляемо и итерируемо создать необходимое количество за считанные дни. Разрыв от идеи до реализованного концепта - минимален.

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

1к звёздочек!

⎛⎝( ` ᢍ ´ )⎠⎞ bugagashenki

Контент!

Я тут работу меняю, так что пока продолжу развлекаться вольной философией и безудержным коммитингом в sgr-agent-core

Надо чего-нибудь выдать про эффект пятилетки за три дня и те чудеса эффективности, которые даёт волшебная кнопочка "Claude! Do something! "
Чтоб быть в тренде, так сказать


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

Конкретный кейс:
В пресловутом sgr задумал я поменять протокол стриминга. Для того чтобы что-то менять нужно сначала понять, как модельки присылают кусочки thinking, content, tool calling и ещё невесть чего.
А потом позакидывать всякие ситуации на предмет читаемости разными приëмниками + инкапсуляции, конченных конечных символов

Любое изменение протокола требовало прогона нескольких объемных запросов к разным ллмкам и просмотр их вывода
Раньше это бы решалось самозабвенным прожиганием токенов каждый раз, когда надо было отследить результат

Сейчас же это потребовало небольшой песочницы, в ходе которой сначала навайбкодилось сохранение всех эвентов со стримов llm, потом их рестриминг наружу с некоторой внутренней  реорганизацией под реалии моих изменений протокола

Поднимаем апишку и вуаля! Можно гонять хоть после каждой запятой

Кейс2:
Когда надо было засунуть в БД пару миллионов записей бинарных данных и посмотреть что произойдёт.

В общем случае проще было бы покопаться а статейках и выудить похожий на правду бенч

Фокус в том, что в обычной ситуации мой ленивый мозг на полуавтомате отбрасывает подобные решения как неперспективные:
- Занимают день-два.
- В скоуп задачи не входят
- Писать их неблагодарно.
- И вообще противно
- И выглядят страшно
- Переиспользовать не получится

Ну нахер


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

> Общаешься со знакомой-ресёрчером.
> Осознаёте, что оперируете сходными определениями, но они как-то между собой не бьются
> Разбираетесь

*> делюсь =)
https://www.linkedin.com/pulse/least-3-ralphs-irina-nosal-trczf/