В каких компаниях вопросы про SGR стоят острее всего?

Это предварительные данные опроса ранее.

Выборка пока не очень большая, но похоже, что больше всего вопросов возникает у компаний размером 11-50 человек, которые работают в Business Services и хотят попробовать внедрить методы/агентов на базе SGR в продажи или маркетинг.

Medical, финтех и производство идут следующими.

Цвет на графиках тем интенсивнее, чем больше вопросов про SGR возникает, мы это будем использовать при приоритизации ответов.

Опрос еще идет, можете оставить свои вопросы вот тут (или переслать коллегам для заполнения): Русский / English.

Ваш, @llm_under_hood 🤗

Насколько маленькая LLM модель может вытянуть Deep Research?

Насколько плохо или хорошо это будет выглядеть? Насколько будет ерунда под капотом?

Можно заглянуть под капот размышлений относительно небольшой модели gpt-4o-mini/Qwen2.5-7B-Instruct в режиме SGR (NextStep архитектура). Валера навайбкодил интерфейс для отладки, который показывает ход размышлений и вызова инструментов

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

Вот, например, результат ответа на вопрос "Find the price of Bitcoin today and find the price for 2023 and 2024" при помощи qwen2.5-7B-Instruct: трейс размышлений c вызовами инструментов и финальный отчет.

Ваш, @llm_under_hood 🤗

Эпилог спасательного проекта и ответы на некоторые вопросы

(В прошлых сериях: 1, 2, 3, 4, 5, 6+7)

Клиент потом довольно сказал, что “was very happy about the current figures”. И это при том, что команда честно поделилась оценками качества на тестовом наборе данных, где собраны самые неприятные моменты.

В команде подключают новые источники данных. Прикидывали заранее, что на них качество упадет до 70% из-за овертюна и отличающейся доменной модели - некоторые термины и методики в новых документах отличаются принципиально. Особенно в тех SGR каскадах, где клиент и eval team до сих пор не пришли к единому пониманию, как это правильно считать.

По факту же общее качество… поднялось до 85.9%. Это все из-за правки системных ошибок, которые стали очевидными после добавления третьего источника данных. В итоге получается 85.3% и 83.9% на известных источниках и 78.3% на новом (это правый столбец шириной ~20 квадратов на скришоте, он очень заметен). И вот тот самый раздражающий блок красных ошибок - это и есть поля, в которых в SGR схеме не прописана нормально методология извлечения.

Заодно, в комментариях выложил скриншот того самого Excel с ground truth (для оценки масштабов работы eval команды, содержимое ячеек там не разобрать)

Про успех проекта директора рассказали по всей компании, отдельно выделив работу eval команды. Ну и заодно показали цифры про количество кода, “который никто не видел”. Это нужно, чтобы команды исподволь привыкали к двум вещам:

(1) тесты и инженерный подход - это наше все, особенно в проектах c LLM под капотом.
(2) код - это просто формат для компактного хранения данных и поведений. Он, как и веса моделей, не так важен при наличии тестов и процесса “обучения”

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

Внутри же чаще всего спрашивают про устройство пайплайна и раутинг запросов к агентам. Про это я писал ранее, но еще раз повторюсь - два основных промпта, как и в простейшем RAG. Один - Retrieval, второй - Generation. Качество результатов всегда упирается в первый шаг.

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

Второй промпт генерирует код инструмента для извлечения, который будет вызван следующим шагом. Если сгенерированный код не проходит проверки, то в контекст докидывается информация, ползунок reasoning для gpt-5-mini выкручивается в high, и агент отправляется работать над ошибками.

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

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

А тем временем директор этой компании прислал здоровущий Excel от биотеха с тремя вопросами:

(1) это вообще делается?
(2) сколько времени надо?
(3) какое будет качество?

Ответ? "Есть идеи. Пять дней и eval команду, тогда скажем точнее"

Ваш, @llm_under_hood 🤗

Вот тот самый тайный первый промпт, который отвечает за самую сложную часть анализа документов в завершенном проекте (см выше). Там текста - кот наплакал, а вся логика зашита в response format (схему на полей 60-70). А дальше constrained decoding движок будет мучать модель, чтобы ответ был оформлен строго по плану анализа.

Причем анализ структурно простой - там даже нет раутинга, только каскады и пара циклов (см SGR patterns)

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

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

Зато response схема тут фактически с одним полем:

class PythonFunction(BaseModel):
    function_body: str

Ну а качество работы такой связки вы уже видели в картах ошибок

Ваш, @llm_under_hood 🤗

PS: Я еще упускаю часть пайплайна, которая делает всю тяжелую работу по поиску документов и их извлечению. В результате ее работы у нас задача сводится к аккуратному списку PDF-ок, из которых нужно извлечь данные. Там уже разные промпты под источник.

Результаты опроса про внедрение Schema-Guided Reasoning в компаниях

Всего был заполнен 21 опросник (ссылка). Вот самые частые вопросы:

(1) Как повысить стабильность и точность динамического роутинга интентов в разговорных графах с помощью SGR?
(2) Как надежно извлекать структурированные данные из больших и сложных PDF-файлов на локальных или open-source моделях?
(3) Как оценивать качество текстовых ответов, сгенерированных при помощи SGR, особенно если результат субъективен или носит описательный характер?
(4) В чём практическая разница, преимущества и недостатки подходов Structured Output vs Tool Calling?
(5) Какие подходы позволяют управлять и валидировать мультиязычные реализации SGR-схем?
(6) Как упростить сложные SGR-схемы, чтобы снизить задержку ответа в real-time агентах?
(7) Какие методологии и практики существуют для интеграции и тестирования решений на основе SGR в текущие рабочие процессы компаний?

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

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

Идея такая. Все же помнят, как в истории про спасение проекта мы разделили команды на две противоборствующие силы - Eval vs SGR? Это важно. т.к. разрабатывать что-то и одновременно контроллировать качество - сложно. Вот и сейчас, многие пилят агентные решения на базе SGR (особенно - SGR Deep Research вокруг @neuraldeep), а вот дотошно бенчмаркать и сравнивать обычно не хватает времени или ground truth.

В ближайшие дни я возвращаюсь к работе над инфраструктурой Enterprise RAG Challenge v3. И вот в нее я хочу встроить бенчмарки/evals/стратегические карты ошибок, которые позволят любому написать своего агента и протестировать его способности, сравнив с другими. Вот тут и можно будет сравнить Function Calls vs Structured Output, разные маленькие локальные модели или просто скорость ответов разных архитектур.

API будет доступна публично по мере готовности, а после соревнования - весь код будет выложен в OpenSource. Статистика и отчеты тоже публичные, как и всегда в ERC.

Ну что, поищем ответы на эти вопросы вместе?

Ваш, @llm_under_hood 🤗

Бенчмарки новых LLM на бизнес задачах.

(1) x-ai/grok-4-fast - 18 место, что очень хорошо. Особенно впечатляет то, что он решил code задачки на 100% c хорошим упором в reasoning 63%. Compliance у него слабее всего, а business intelligence задачи - средненько.

(2) qwen/qwen3-next-80b-a3b-thinking - 27 место
(3) qwen/qwen3-next-80b-a3b-instruct - 41 место

У обоих моделей достаточно сильный code и compliance.

(4) Недавно вышедший alibaba/tongyi-deepresearch-30b-a3b внезапно занял - 28 место, что очень достойно для 30B модели, которая за проход активирует только 3B параметров. Она почти идеально справилась с code задачками

(5) qwen/qwen-plus-2025-07-28 - 34 место, а qwen/qwen3-coder-plus - 40 место

В принципе, все эти результаты довольно неплохи, но до qwen/qwen3-32b (12 место) и openai/gpt-oss-20b (20 место) не дотягивает.

А если посмотреть с другой стороны… помнит кто-нибудь такие модели как gpt-4o, Mistral или llama? Когда-то я писал про них, что это прорывные модели. А теперь более легкие и умные модели - уже не впечатляют. Вот так - потихоньку - и двигается прогресс.

Ваш, @llm_under_hood 🤗

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

Иллюстрация пайплайна из истории про спасение проекта с LLM под капотом

(проект про извлечение промышленных данных из разных PDF от разных поставщиков с таблицами и графиками)

Ссылки:
(1) Серии: 1, 2, 3, 4, 5, 6+7, Эпилог
(2) Описание первого и второго промпта.

Ваш, @llm_under_hood 🤗

Qwen3 VL Thinking - TOP3 в бенчмарке!

Alibaba Cloud выкатили на днях новые Qwn модели. Я слышал, что они неплохи, но это говорят нынче про каждую модель.

(1) Qwen3 Max Instruct - самая крупная закрытая Qwen модель на 1T+ params - заняла 17 место. Это выше gpt-5-nano, но ниже, чем o1-2024-12-17

(2) Qwen3-VL-235B-A22B - самая крупная мультимодальная открытая модель, которая вышла в двух форматах - Instruct (карточка | веса) и Thinking (карточка | веса).

Qwen3-VL-235B-A22B-Instruct заняла 19ое место, что немного ниже Qwen3 Max Instruct. Это примерно уровень gpt-5-nano или deepseek-r1 но модель при этом работает с картинками!

(3) Qwen3-VL-235B-A22B-Thinking аналогична Instruct, но умеет думать и заняла третье место! Это самое высокое место, которое когда-либо занимала модель с открытыми весами в моем бенчмарке!

Понятно, что модели весом в пол-терабайта мало кто будет запускать на практике - не стоит оно того. Куда эффективнее взять gpt-oss-120B с 7го места или Qwen3-32B с 17 места.

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

Ваш, @llm_under_hood 🤗

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

Завтра и послезавтра проходит TED AI Vienna 2025

Из интересного в программе - OpenAI, Google DeepMind, Microsoft, JetBrains AI и множество нишевых исследователей.

Если кто-то тоже будет там - пишите!

Ваш, @llm_under_hood 🤗

Кто работает на стыке медицины, биотеха и AI?

Есть ли среди нас люди, стартапы или команды, которые занимаются проектами с применением AI, LLM или CV в медицине, биотехе и смежных областях?

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

Расскажите о себе и своих проектах в комментариях или пишите напрямую @abdullin.

Ваш, @llm_under_hood 🤗

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. Можно посмотреть вместе и сформировать полностью синтетический вариант.