Демка бизнес-ассистента, которая показывает основы построения reasoning системы c tool use на базе простой LLM (GPT-4o)

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

(на самом деле интеграций с реальными системами нет, агент работает в симуляции)

Из библиотек требуется только openai/pydantic для Structured Outputs и rich (для красивого вывода в терминал). Все остальные вещи вроде демо-БД и инструментов реализованы прямо в коде.

Всего в демке 159 строчек исполняемого кода. Большая часть которого - SGR схема инструментов (у ассистента всего один промпт) и реализация работы самих инструментов.

Статья с демкой - SGR Demo. Код одним файлом - в статье после разбора.

Для тех, кому хочется более серьезного кода, в статье есть раздел "Hardening the code" про то, как можно эту обучающую демку развить дальше.

Ваш, @llm_under_hood 🤗

---
Полный список статей:

- SGR Intro - заглавная страница с определением и основными ссылками
- SGR Patterns - примеры простых паттернов, из которых можно "собирать" более сложные reasoning схемы: Cascade, Routing, Cycle.
- SGR Examples - четыре примера: simple math task, text-to-sql, document classification, advanced reasoning in compliance.
- SGR Demo - минимальное демо бизнес-ассистента с SGR под капотом.

Демо reasoning бизнес-ассистента с SGR на JS

Спасибо Антону (@antonkuzminru) за этот порт!

Его код работает аналогично версии на Python и тоже использует минимум фреймворков. Вместо pydantic в мире JS/TS используется zod.

- TS (Bun) + Zod - Gist 👈

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

Ваш, @llm_under_hood 🤗

Красивое демо бизнес-ассистента с SGR на Python

Спасибо Виталию (@vitalii_ask) за версию агента с красиво оформленной визуализацией!

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

Ссылка на Gist

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

Ваш, @llm_under_hood 🤗

Меня сегодня спросили - есть ли идеи по поводу следующего Enterprise RAG Challenge?

Я сказал, что есть две:

(1) Сделать ERC, как он был в прошлые два раза (поиск ответов на вопросы в отчетах), но заранее подготовить базовый стенд, в котором реализованы простые pipelines. Команды смогут взять этот код и работать над его улучшением. Веселье с парсингом документов и таблиц гарантировано.

(2) Сделать Enterprise Reasoning Challenge, где команды получают легковесную среду, которая симулирует небольшую компанию с внутренними системами (ERP/Emails/CMS итп). Это похоже на симулированный пример из демки бизнес-ассистента, но с бОльшим количеством доступных сервисов.

И задача - написать такого агента, который получает задачки текстом (как корпоративный чатбот), а потом использует доступные ему инструменты для выполнения этих задач. Самая простая реализация - просто воткнуть все доступные сервисы как MCP/Tool Calling в LLM.

Вам какая идея больше нравится для дружеского соревнования этой осенью? И почему?

Ваш, @llm_under_hood 🤗

Бенчмарк новых моделей: Grok, Opus 4.1, Mistral Medium 3.1

Elon Musk что-то делает правильно. Мало того, что у них Grok-4 работает с нормальным Structured Outputs, так Grok-4 по очкам заняла первое место. Ровно столько же очков у GPT-5 (medium reasoning). Дорогие, но умные.

Кстати, на данный момент поддержка Structured Outputs (которая нужна для стабильной работы SGR) появилась у большего числа независимых провайдеров (все они доступны через OpenRouter):

- Fireworks
- Cerebras
- Groq

Это вдобавок к крупным провайдерам - OpenAI (+Azure), Mistral, Google (ограниченные Structured Outputs).

NB: GPT-OSS модели OpenAI из-за нового Harmony формата пока со Structured Outputs стабильно не работают - ни у провайдеров, ни в ollama. Нужно подождать.

Anthropic Claude - пока продолжают болтаться в аутсайдерах на промышленных задачах. Компания молчит по-партизански про поддержку constrained decoding/Structured outputs, а Opus 4.1 по очкам на бизнес-бенчмарке с использованием SGR стал чуть хуже, чем Opus 4.0. 22 место.

Mistral Medium 3.1 - тоже без прорывов. По очкам чуть хуже, чем Mistral Medium 3.0. 38 место.

Ваш, @llm_under_hood 🤗

Какая самая маленькая LLM, которая может управлять бизнес-агентами?

Участники сообщества и курса решили выяснить это и допилили SGR демку до состояния, что она внятно запустилась на Qwen3-4B 🤯 ибо:

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

Среди изменений:

- убрали OpenAI SDK, заменив прямыми запросами к локальной модели (llama.cpp для inference модели `Qwen3-4B-Instruct-2507-Q8_0`)
- добавили инструкций в промпт, прописав явно некоторые правила
- добавили еще одно reasoning поле в самое начало SGR каскада в NextStep

Посмотреть эту версию можно тут: gist

Спасибо @amekhrishvili за порт!

Ваш, @llm_under_hood 🤗

А вы знаете, что пост про демку бизнес-ассистента с SGR под капотом - это самый тщательно скрываемый секрет нашего коммьюнити?

Если верить статистике Telegram, этот пост люди пересылали в личке разы чаще, чем все остальные посты, но никто не шарил этот пост публично.

Правда секретом это будет оставаться не так долго. Следующий ERC (это наш формат соревнований) точно будет про Enterprise Reasoning Challenge, где командам нужно будет построить агента или мультиагентную систему, которые смогут использовать предоставленные им API, чтобы распутывать корпоративные задачки. Все как в SGR демке, только чуть масштабнее.

Событие планируется осенью/зимой. Точные сроки зависят от того, как быстро раскачаются отделы маркетинга в TimeToAct и IBM. Тестовый прогон будет точно этой осенью.

Формат проведения будет примерно аналогичен прошлому Enterprise RAG Challenge: команды со всего мира, небольшой призовой фонд, максимально открытые исходники и публичный сравнительный анализ результативности различных архитектур.

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

Ваш, @llm_under_hood 🤗

Попробовал в деле Schema Guided Reasoning - перевёл на неё скрипт составления протокола встречи по транскрипту встречи.

Результаты:
1. Того же качества протокола удалось добиться за один запрос к LLM вместо четырёх ранее.
2. Протокол стал чуть более осмысленным (но это не точно), так как схема направляет "движение мысли" модели.
3. Это работает на обычных (не размышляющих) моделях.

Я в восторге!
Спасибо @llm_under_hood за культпросвет!

Теперь попробую вникнуть в работу агента на SGR.

⬆️ Я всегда очень рад читать такие отзывы! Здорово, что решения работают и помогают вам делать продукты с LLM под капотом точнее, умнее и быстрее.

Пишите ещё о своих кейсах успешного применения Schema-Guided Reasoning (SGR) - пусть таких историй будет больше!

Ваш, @llm_under_hood 🤗

PS: Когда историй становится много - начинают проявляться новые паттерны)

Валерий Ковальский (@neuraldeep) поделился опытом использования SGR-подходов в обзоре "SGR vs Tools: когда использовать Schema-Guided Reasoning, а когда Function Calling в LLM-системах"

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

Особенно интересны пункты про экономию времени на разработку при использовании SGR вместо стандартного Tool Calling. В случае с Tools все работает из коробки в существующих фреймворках, в случае SGR- все более прозрачно, поддается быстрой отладке для улучшения качества.

Я перешлю его обзор в канал целиком следующим постом. Читайте - это стоит того!

Ваш, @llm_under_hood 🤗

SGR vs Tools: когда использовать Schema-Guided Reasoning, а когда Function Calling в LLM-системах

Сегодня хочу поднять тему, которую у меня часто спрашивают: когда использовать Tool Calling, а когда Schema-Guided Reasoning (SGR) в LLM решениях под капотом?

Респект Ринату Абдуллину за отличную систематизацию подхода SGR!

Что забавно, я сам использовал похожие паттерны 4-5 месяцев назад загляните в гит, но именно Ринат дал этому четкое название и структуру!

SGR vs Tools по моему мнению

SGR заставляем LLM мыслить по четким шагам через Structured Output:
Анализ → Поиск → Обработка → Вывод в одном запросе

Tools даем LLM набор функций для взаимодействия с внешним миром
Кстати все больше вижу сдвиг именно в паттерн агент=tool_call MCP+SO(где надо) и теперь SGR:
Поиск, API, вычисления, полноценное агентское поведение

Пример SGR из моей практики:

{
  "reasoning": {
    "query_analysis": {
      "user_query": "Найди информацию о проекте X",
      "query_interpretation": "Пользователь ищет документы по проекту"
    },
    "information_search": {
      "search_strategy": "Ищу по ключевым словам в базе",
      "relevant_documents": [...]
    }
  },
  "response": "Полный ответ на основе найденной информации"
}

Когда использовать SGR:

Анализ и структуризация данных
Разбор документов, классификация, отчеты
Сложные рассуждения
Пошаговый анализ с обоснованием
Обработка имеющихся данных
Все нужное уже в контексте, нужна предсказуемость но не детерминированность (запомним)

Когда использовать Tools:
Настоящее агентское поведение
LLM сам решает последовательность, адаптируется к результатам, может прерываться

Не зря появилась куча оберток типа LangGraph, AutoGen, CrewAI все строятся именно на свойствах
Tools когда модель сама принимает решение их вызвать
А MCP от Anthropic на мой взгляд это попытка стандартизировать агентские инструментарий

Взаимодействие с внешними системами
Интернет, email, календарь, API

Критически важно для production Evals и мониторинг!

SGR:
Все рассуждения видны и логированы
Легко тестировать каждый шаг
A/B тестирование предсказуемо

Tools:
LLM сам решает какой инструмент вызвать — черный ящик
Сложно понять WHY выбрана функция
Непредсказуемая цепочка вызовов
Дебаг в production = боль

Из реального опыта:
При настройке NSFW-фильтров с Tools ушло бы недели на понимание решений модели с SO было бы сложно дебажить.
С SGR за день увидел проблемы в reasoning и пофиксил качество!

Ключевое различие — агентность vs структурированность

SGR = мощное рассуждение без истинной агентности
Один запрос → один ответ
Для агентского поведения придется костылить

Tools = настоящее агентское поведение из коробки
LLM сам управляет workflow, нативные прерывания в большинстве фреймворков и API
Поэтому все современные агентские фреймворки базируются именно на Tools

Гибридный подход? Искал медь а нашел золото!

SGR для принятия решений какой инструмент использовать
Tools для выполнения действий получение данных и ощущение агентности
SGR для финальной обработки структуризация результата

Вывод финально

SGR когда нужно контролируемое рассуждение и мониторинг
Tools когда нужно настоящее агентское поведение
SGR работает даже на локальных 7B моделях и даже на qwen3 4B

Update:
Ринат подкинул очень интересную демку, смешение в сторону SGR в агентах
Как запускать вместе и то и другое

Можно и вместе.
См демку с многоходовым бизнес-ассистентом
Ребята из Сбера допилили это до запуска на Qwen 3 4B


В production качество мониторинга = выживание продукта
А как вы решаете эту дилемму? Поделитесь опытом!

P.S. Спасибо Ринату за системный подход к SGR это свежий глоток точности и постоянства в нашем мире LLM!
P.S.S Забирайте все ссылки как памятку, SGR это то что будет двигать production сектор дальше к внедрению LLM!

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

В процессе обсуждения SGR Demo, было сделано интересное замечание:

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

Давайте продемонстрирую, как с подобной задачей планирования "на лету" справится агент из SGR Demo.

Для этого мы ему последовательно дадим две новые задачи.

Первая - простая, запомнить правило, что SkyNet никогда нельзя продавать практикум по созданию AGI (SKU-220)

"Add rule for [email protected] - politely reject all requests to buy SKU-220",

Напомню, что разные задачи выполняются в разных контекстах. Во время выполнения новой, агент не "помнит", что произошло в процессе выполнения предыдущей задачи.

И вторая задача - говорим агенту, что Elon Musk и SkyNet попросили практикум по созданию AGI. Агент, в теории, должен сформировать план, начать действовать по инструкциям, а потом поднять из CRM информацию про запрет. Это повлияет на план.

"[email protected] and [email protected] wrote emails asking to buy 'Building AGI - online exercises', handle that",

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

- Issued invoice INV-4 for [email protected]
- Emailed invoice INV-4 to [email protected]
- Politely rejected [email protected] request

Почему оно сработало, как модель смогла адаптировать план "на лету"?

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

Помните, полгода назад я писал про разработку своего Reasoning Flow? Ядро паттерна сформировалось как раз в том проекте из алгоритма адаптивного планировщика. И теперь каждый его может запустить у себя - я дописал эти две новые задачи в Gist с демкой.

Ваш, @llm_under_hood 🤗

PS: Единственное, что этот агент не сможет осилить - запуск независимых веток планирования в рамках одной задачи. Но это уже не уместить в 161 строчку Python, да и не нужно оно для простых кейсов.

Демо чата с Deep Search поиском - SGR Deep Research

На базе демки бизнес-ассистента с Schema-Guided Reasoning продолжают делать новые и интересные эксперименты.

Валерий Ковальский (@VaKovaLskii) сделал целый проект - это чат-интерфейс, который умеет делать свой Deep Research - самостоятельно искать информацию в интернете, задавать уточняющие вопросы и адаптировать свои планы.

Под капотом:
- gpt-4o-mini для размышлений [1]
- Tavily API для поиска (1000 запросов в месяц бесплатно)
- Ядро адаптивного планировщика из SGR Demo (NextStep reasoning) с новыми инструментами для работы с поиском и планами.

SGR Core находится вот в этих строчках, там сразу видны и новые инструменты.

Ссылки: Код на Github (лицензия MIT) | Пост в Neural Kovalskii

Ваш, @llm_under_hood 🤗

[1] Почему gpt-4o-mini? Как Валерий написал сам: "Хотел что бы любой мог потрогать. Я так же проверил на qwen2.5-7b-instruct, работает"

@i_am_legion еще дополнил: "Огромное спасибо, понравилась реализация! Тестировал на llama.cpp + gpt-oss-120b + searngx (без сторонних сервисов), работает отлично"

AI неотличим от магии - и это меня дико раздражает

(до комментариев - читаем пост до конца!)

Этой весной я делал доклад для IBM про текущее состояние AI. Там я проводил параллели с технологиями, которые со временем развились до такого состояния, что стали неотличимы от магии - про энергию, связь, полет и автоматизацию/AI

Каждая технология начиналась с мифов и магии, когда люди eще не понимали ничего и тыкались вслепую, приписывая все божественным сущностям и ритуалам. А если что-то шло не так, то это "Зевс покарал" или "демона назвали неправильным именем".

Со временем технологиии теряли магический флер, превращались в точные инженерные науки и развивались до современных высот:

- Полет - от Мифа о Дедале и Икаре до возвращаемых многоэтажок Startship
- Связь - от связи с богами через Дельфийского Оракула до спутников Starlink и спутниковой связи на обычных телефонах.
- Энергия - от молний Зевса до комбайнов ASML, которые испаряют лазерами капельки олова только для того, чтобы поймать выделившийся свет нужной волны зеркалами и отразить его на будущий процессор
- Автоматизация и AI - от бронзового автомата Талоса до…

А вот с AI пока неувязочка - мы дальше ритуалов и магического мышления не пошли.

Примеры:

(1) люди очень любят спорить на тему “а что такое настоящая агентность?”, “а как правильно говорить - агентный или агентский?” итп - словно правильное название системы сделает ее более способной делать свою работу. На самом деле нет - система в реальности либо выполняет функции, либо выдает ошибки, которые нужно измерять, отслеживать и чинить. Если система работает - что у нее под капотом, и как оно названо - без разницы. А если работает неправильно, то правильно назвав - ничего не изменишь.

Надо собирать тесты, измерять и последовательно улучшать.

(2) недавно вышел нашумевший доклад "State of AI in Business 2025" на тему, что 95% компаний, которые вложили в сумме 30-40 миллиардов USD в AI - в итоге потратили деньги без выхлопа. В отчете еще подчеркивается, что некоторые компании, которые вкладываются осознанно в фичи, не распыляются и собирают обратную связь - получают выхлоп.

Этот доклад - раздражающее переливание из пустого в порожнее. Там AI приписываются магические свойства вроде GenAI divide, неспособности адаптироваться, реагировать на обратную связь. Прямо какая-то проклятая технология, которая заставляет компании забывать про процесс оценки рисков любого софта и сервиса, вбрасывая миллиарды долларов без тестов и пилотов.

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

И только две команды в мире почесали в затылке и сказали "а вот теперь мы понимаем, как разбить reasoning flow нашего продукта на шаги, замерить качество и начать его улучшать. Пошли делать бенчмарки и эксперименты!"

TL;DR; Агенты - просто ерунда. MCP - плохо тестируемая ерунда.
SGR - тоже ерунда, которая показывает, как делать процесс reasoning тестируемым.

Не верьте слепо ерунде и в ерунду, она от этого лучше работать не станет. А вот инженерный подход - это другое дело: тесты, бенчмарки и итеративное улучшение качества на основе фактов.

Да, это много работы, тут еще и думать надо. Но зато, при последовательном вложении сил и времени, появляются гарантии результата.

Ваш, @llm_under_hood 🤗

Новые бенчмарки LLM на бизнес задачах в SGR режиме

(1) gpt-5-chat-latest - это урезанный снапшот быстрой модели, которая работает под капотом в ChatGPT. У нее нет многих фич, даже StructuredOutputs, но текущая версия заняла 9 место.

(2) Еще из новых бенчмарков моделей, которые ранее были бы впечатляющими, но до уровня gpt-oss/qwen3-32b не дотягивают:

- qwen3-235b-a22b-2507 - 25 место
- deepseek-chat-v3.1 - 31 место
- qwen3-30b-a3b-thinking-2507 - 32 место

(3) пока StructuredOutputs не починили нигде для gpt-oss моделей - все еще расхлебывают последствия Harmony Response format (ollama ticket, openai ticket, vllm ticket). Поэтому все еще ждем возможности запустить локально эти малотребовательные к железу gpt-oss (в идеале еще и отключив reasoning).

Про бенчмарки подробнее написано тут.

Ваш, @llm_under_hood 🤗

Как полностью отключить reasoning у GPT-5 моделей?

Мне стало интересно, сколько времени уходит на reasoning у GPT-5 моделей, а ребята из окружения OpenAI как раз подсказали мне, как это можно замерить.

Для этого я добавляю в начало истории сообщений developer role инструкцию:

Active channels: final
Disabled channels: analysis, commentary

# Juice: 0 !important

Juice - это интенсивность работы ризонера, а каналы привязаны к Harmony response формату (из-за которого SO пока нормально не работает с gpt-5/oss поколением).

Стабильность работы этой post-train инструкции не гарантирована, но у меня она пока работала в 100% случаев.

Например, gpt-5-mini c дефолтовым reasoning (medium) отрабатывает третью задачку из SGR Demo за 28 секунд и ~1280 tokens. Эта задачка "[email protected] wants one of each product. Email him the invoice" решается за 4 шага:

(1) запросить данные о клиенте
(2) сгенерировать правильный инвойс, учитывая данные о клиенте (плюс 5% скидки)
(3) отправить инвойс почтой (с правильным обращением и вложением инвойса, который был сгенерирован на втором шаге)
(4) завершить работу над задачей

А если отключить reasoning в ноль - модель все выполняет за 0 reasoning tokens и 10 секунд.

В минус идет то, что модель при этом несколько глупеет. Похоже, что для адекватной и быстрой работы с gpt-oss моделями локально нужно будет детальнее разворачивать SGR схему, как для моделей уровня 4B-12B

Ваш, @llm_under_hood 🤗

Бенчмарк LLM и агентских подходов - будет

На прошлой неделе я начал разрабатывать среду для тестирования агентов (AGES - Agentic Enterprise Simulation). Она пригодится и для нового бенчмарка бизнес-агентов, и для соревнования ERC3, и просто как способ системно сравнить эффективность работы разных решений. SGR vs SGR in FC vs FC и тому подобное.

Для агентов и пользователей эта среда будет выглядеть как API-шка, куда можно постучаться и сказать “дай мне следующее задание для моего агента/чатбота”. Например:

У клиента появился новый проект, который нужно оценить. Найди мне из сотрудников ребят, которые свободны на 4 часа на неделе (продакт, ML Engineer, эксперт в маркетинге), забукай им календари на созвон с клиентом, вышли всем инвайт

И для выполнения агенту нужно будет подергать другие API:

- DirectoryAPI - чтобы получить список сотрудников со скиллами
- CalendarAPI - чтобы подобрать слот, когда они одновременно свободны
- EmailAPI - чтобы выслать инвайт

Все API будут опубликованы заранее, как и их схема. Заодно сделаем Python SDK, чтобы можно было удобно вызывать прямо из кода.

Задача AGES - заполнить заранее базу тестовыми данными, чтобы API-шки выдавали осмысленные данные, выдать задание, а потом сказать, было выполнено задание правильно или нет. Результаты работы каждого агента логгируются, оцениваются и потом выводятся на общий dashboard. Если агента допиливают - можно будет сравнить результаты разных запусков.

Что под капотом у агентов - не важно. Главное, чтобы задача была выполнена. Но командам нужно будет заполнить для каждого нового агента небольшой опросник (как в прошлых ERC), чтобы мы могли видеть, какие подходы работают с какими моделями, и насколько хорошо.

Вопросы

(1) Код будет открыт?
API AGES будет доступно всем. А после завершения ERC3 - я выложу все исходники в публичный доступ, чтобы каждый мог запустить его у себя или подкрутить под свои нужды.

(2) Какие будут API-шки? Пока это секрет в процессе разработки. Мне нужно выдержать баланс между релевантностью и интересом. Если сделать слишком реалистично и сложно - не соберем 300 команд, как это было в ERC2. Если сделать слишком просто - то результаты будут не такие интересные, а серьезные команды отвалятся. А если сделать слишком серьезно, то придет только один enterprise без стартапов и команд с горящими глазами.

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

(4) Нужно ли будет агенту создавать новые инструменты на лету? Если хочется, то можно. Не все API-шки будут очень простыми (корпорация, таки), но если их обернуть кодом - жизнь может LLM-ке упроститься.

(5) Я хочу протестировать своего RPA, можно мне не через API, a через UI? Да, это можно. Решение задач через web-интерфейс будет отслеживаться в отдельной категории автоматически.

(6) Можно ли запускать несколько агентов параллельно? Да хоть сколько. У каждого будет своя изолированная симуляция.

(7) А что там под капотом? Golang / event sourcing / Discrete event simulation / много тестов и AI+Coding.

(8) Когда? Финальный раунд ERC3 будет осенью/зимой. Но среду выставить наружу для запуска экспериментов я хочу уже скоро, чтобы поскорее начать ее отлаживать.

Спонсор всего этого веселья - TimeToAct Austria. Мотиватор для именно этого поста - энергетика и движуха вокруг проекта SGR Deep Research и последнее сравнение SGR vs Function Calling.

Задача AGES - упростить такие сравнения и систематизировать их, предоставив общую базу для сравнений. Еще привлечь больше команд со всего мира, структурировать результаты и рассказать про них, чтобы вместе продвинуть State-of-the-Art еще на один шажок вперед.

Погнали?)

Ваш, @llm_under_hood 🤗

Примерно так идет разработка Agentic Enterprise Simulator для ERC3. Пока проект в самом начале, приходится часто засучивать рукава, чистить тех долг, ставить инфраструктуру и архитектуру.

Но потихоньку Codex берет на себя все больше работы. Благодаря удобным тестам, даже большой рефакторинг он может делать сам.

Мое дело - ставить задачи с телефона и присматривать за правильностью принятых решений.

Ваш, @llm_under_hood 🤗

Cпасение проекта с LLM под капотом - День 1

При помощи SGR, AI+Coding и команды тестеров.

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

Задача сформулирована так:

Ринат, делайте что хотите, но попробуйте спасти проект и сделать X за несколько дней. Проект уже не спасти, но вдруг получится? Мы будем рады любому результату. Привлекайте, кого считаете нужным. Ограничений нет.

Проект представляет собой пайплайн извлечения структурированных данных из PDF-файлов. Он написан (у любого, кто работал с проектами на проде, тут начнёт дёргаться глаз) на микросервисах с Azure cloud functions, кэшированием в БД и самописным фреймворком для батчинга в Anthropic.

Тестов или evals (тут начнёт дёргаться второй глаз) нет. Да и вообще вся разработка после прототипа велась без evals. Клиент сильно жалуется на галлюцинации модели. Качество примерно на уровне 60%, а разработчик ушёл в отпуск. Код локально не запускается, и разобраться в нём крайне сложно (ибо cloud functions + batching + собственный микро-фреймворк). Показать результат нужно уже на следующей неделе.

Я такие задачи люблю (не часто и только когда оно реально того стоит)

Итак, день первый.

Формируем план на первые три дня: переводим команду в startup-режим, выкидываем всё ненужное, собираем тестовые данные и запускаем цикл обратной связи.

Во-первых, переводим команду в startup-режим. Там почти все люди из enterprise, поэтому для них это будет небольшим шоком. Startup — это не работа по 8 часов в день (на этом, как раз, многие стартапы и проваливаются), а умение быстро избавиться от всего лишнего и мешающего.

Во-вторых, оцениваем, что именно тормозит работу. Всё это выкидываем:

(1) Код написан на микросервисах с батчингом и собственным фреймворком, не запускается локально и не имеет eval-датасета? Выкидываем всё к чёрту и берём старую версию полугодичной давности. Она устарела, но у неё были evals. Начнём именно с неё.

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

(3) Создаём контракт для экспорта данных клиенту. Это будет таблица Excel с доступом для всех участников. Таблица станет основным интерфейсом работы команд. С ней будут работать:
- Команда оценки (eval team) — заполняет ground truth для оценки работы;
- Команда LLM/AI — сравнивает результаты работы пайплайна с тестовыми данными;
- Интеграторы — загружают финальные данные в нужном формате для демонстрации клиенту через Power BI;
- Клиент — просматривает результаты и при необходимости корректирует их с помощью экспертов.

(4) Объясняем команде сбора тестовых данных концепцию "weak supervision" и просим начать готовиться к сбору этих данных в нашем формате.

Все, на первый день этого более чем достаточно. Пора отдыхать)

Ваш, @llm_under_hood 🤗

Cпасение проекта с LLM под капотом - День 2

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

7:53 Я ставлю задачу на день: собрать eval dataset (ground truth data) и прогнать его через существующий LLM pipeline. Тогда сможем получить на выходе карту ошибок. Без нее не будем даже пытаться улучшать старый код.

Причем в идеале этот dataset должен включать самые сложные кейсы. Те самые, из-за которых разработчик проекта ушел в загул и micro-services и усложнение системы.

К утру один сотрудник в компании берет на себя ответственность за сбор данных, находит трех помощников. Вот и будет Head of Eval.

9:23 Генерю для нашего рабочего чатика аватарку в стиле “Проект Аве Мария”, чтобы было веселее работать, а директорам - его читать.

Head of eval тут же рапортует: “Ground truth team is onboarded and starting to generate data now!” Они начинают ручное вычитывание данных, по паре записей из каждого PDF файла. Поскольку процесс долгий, они планируют извлечь в сумме где-то 50 записей за пару дней.

9:36 “ChatGPT, напиши-ка мне функцию на питоне, которая сравнит две таблички и выведет Heatmap c разницей”. “Claude Sonnet - перепиши этот график красиво”

10:12 Готова первая карта ошибок (и функция по ее отрисовке, которая интегрируется в пайплайн). Она вся пустая, т.к. данные от eval команды еще не готовы (скриншот скину в комментарии). Переключаемся на LLM логику.

~12:00 по мере заполнения GT (ground truth) данных, начинают всплывать вопросы по форматированию и правильности извлечения данных. Команды это быстро решают в общем чате. Это быстро, т.к. общий Excel файл у всех перед глазами в режиме редактирования. PM притаскивает сложные кейсы от клиента и складывает в общую папку, eval team вычитывает их.

Команда обнаруживает, что документов с самыми сложными кейсами не так много, как казалось раньше. Но все-таки есть моменты, где нужно извлекать почти 3000 сущностей на 50-70 свойств из одной PDF. 3000 LLM вызовов на один документ? Брр. Должен быть способ проще.

У нас на это нет 5 месяцев времени, как это было у предыдущей команды. Нет времени и желания запускать пайплайны на 6-8 дней и использовать дорогой Claude Opus. Но есть что-то, чего не было у них - пайплайна и тестов, которые смогут быстро оценить качество любого эксперимента. Поэтому начинаем экспериментировать. Опираемся на когнитивную сложность задачи и Domain-Driven Design.

15:14 После ряда экспериментов получается интересная ерунда - прототип функции с Schema-Guided Reasoning, который реализует процесс так, как это бы сделал ленивый эксперт при помощи DevOps-а, без какого-то уважения к правилам программирования и разработки.

Оно работает не очень точно, но извлекает 600 сущностей из PDF за два SGR вызова gpt-5-mini. Все смотрят круглыми глазами, поэтому генерирую тестовые данные остальной команде на посмотреть глазами. Выдаю задачку подумать, как такое сделать в 200 строчек кода.

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

Ваш, @llm_under_hood 🤗