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

Итак, идет пятый день спасения проекта (1, 2, 3, 4). К его концу нужно принять решение - cможет ли команда завтра предоставить клиенту выгрузку данных нужного качества?

9:30 Созвон, формулируем план на день:

(1) За час забрать ground_truth_v3 в работу, поправить самые большие провалы, прогнать текущий пайплайн (не только GT dataset)
(2) работа над Accuracy - нужно 80%
(3) в течение сделать финальную выгрузку заранее, чтобы убедиться, что нет граблей
(4) Eval команда начинает собирать dataset для третьего класса документов - про запас.

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

10:37 Pipeline начинают работать над провалами в данных, которые видны на вчерашней карте ошибок.

11:26 SGR Team пишет, что спустя 4 дня и полтора часа с начала проекта у нас Accuracy 68.1%. На карте ошибок уже меньше серого (первый скриншот в комментариях)

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

13:00 SGR Team: Качество не растет - уперлись в 70%. Решаем переписать с нуля второй промпт в пайплайне, который пока почти не трогали.

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

У нас осталась половина дня. Попробуем рискнуть и переписать там все.

13:25 Первый результат - ничего не понятно, но вроде бы не сильно хуже (скриншот второй в комментариях). Ground truth еще обсчитывается

13:30 Pipeline исправляет свою часть. На карте ошибок не должно оставаться больше серого

14:34 SGR Team: 74.9%! Серое еще есть на карте, но если его бы не было, то точность была бы 77.1%. Новая архитектура преодолела тот порог в 70%!

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

14:53 SGR Team: 77.1% accuracy - после мелкой доводки напильником вслепую и заодно отловом ошибок в самой ground_truth. Начинает формироваться правило, что если наша система с LLM под капотом упорно ошибается, то может быть ошибка в ground truth? Причем eval команда тоже озвучивает это. Weak Supervision lvl 2.

Eсли Pipeline починят свой pipeline, мы можем получить 79%!

15:52 SGR Team: 77.7% - добили эту группу свойств в нижнем углу. В основном просто мелкие перестановки и переименования, которые снижают когнитивную нагрузку на этом этапе до уровня выпускника. Карта ошибок - четвертая.

А время уже вечер...

15:56 PM: ну мы же теоретически до 80% почти дотягиваем?

16:03 Eval team: да, особенно если помнить, что у нас в тестах самые сложные кейсы из возможных.

Напомню, что Eval Team - оппонент SGR в данном проекте. Они отвечают за качество. Они разрушают работу SGR, наглядно демонстрируя ошибки - такова их роль в данном проекте. Они держат в уме риски и грабли. Поэтому и принятие решения лежит на них.

Решаем рискнуть и написать клиенту, что можем показывать хорошие результаты

16:31 распараллеливаем пайплайн и запускаем на полной выгрузке.

17:03 SGR Team - 4 дня, 7 часов с начала работы. Accuracy - 82.4%. Словно им забыли сказать, что 80% уже достаточно было. Карта ошибок - четвертая в комментариях.

Это окончательно убеждает Eval Team, что можно завтра показывать клиенту хороший результат.

За сим расходимся. Ну что тут может пойти не так?

Ваш, @llm_under_hood 🤗

Финал и подкапотные подробности истории со спасением проекта. Дни 6 и 7

Итак, подходит deadline сдачи проекта (Дни 1, 2, 3, 4, 5).

7:19 SGR Team: Выгрузку прислать не можем! Пайплайн вылетел ночью на неожиданных данных. Добавили try catch, больше параллелизма и запустили доделывать.

8:49 SGR: 27k сущностей, где-то 1k не хватает.

9:28 SGR: У нас не хватает несколько сотен сущностей, есть три категории ошибок:
(1) в 20 сущностях у нас нет ссылок на документы. Pipeline - чините!
(2) агент не может написать код инструмента в пайплайн
(3) есть классы документов с несколькими PDF. На такое мы были не готовы

Договариваемся, что eval team добавит новые три сущности в ground_truth (по одной на категорию ошибок). Это и новые документы в GT и очень неприятные кейсы в целом.

10:03 SGR: Третий класс ошибок исправлен

10:30 SGR: Второй класс ошибок исправили. Пришлось разрешить агенту адаптироваться.

11:50 SGR присылает выгрузку на 27407 сущностей.

12:48 Pipeline присылают фикс на последнюю категорию ошибок

14:11 Передаем клиенту данные на независимую проверку. Точность 83.8%(Карта ошибок в комментариях).

Следующий день

13:24 PM говорит, что команда клиента взяла 25 случайных продуктов и вручную сравнила наши данные с ожидаемыми.

Они нашли 4 ошибки среди 25*60 полей

Может, нам повезло с выборкой, может клиент тестировал не очень внимательно (на приемке, ага), может eval team просто собрали такой хардкорный датасет/бенчмарк. Но по факту, команда за 6 дней работы вместе подняла видимую клиенту точность на их выборке с ~60% до 99.7%.

Что дальше?

А дальше проект может катиться по колее. Процессы поставлены, люди знают, что делать. Добавление еще трех источников документов - не вызывает никаких вопросов. Как добавлять новые edge cases и контроллировать качество - тоже. Причем клиенту завели документ, куда он может добавлять ошибки (обязательно со скриншотами), чтобы потом eval team переносила их в ground truth, а SGR улучшала качество. Те 4 ошибки тоже торжественно занесли в документ.

Как оно работает под капотом?

Первый промпт: "Вот тебе PDF с кучей сущностей. Заполни шаблон анализа закономерностей". Да, там два предложения плюс SGR схема на 160 строчек кода (в ней где-то 20 каскадов на 80 полей)

Второй промпт: "Вот тебе PDF с кучей сущностей и анализ закономерностей. Напиши tool, который сможет разобрать название любого компонента и заполнить специфичные для него поля. Жесткие требования прилагаются."

Второй промпт работает как линейный SGR NextStep Agent. Пайплайн берет код полученного инструмента и запускает его. Если же есть проблемы/вопросы - добавляет edge cases в контекст и повторяет попытку.

Система сгенерировала 687 инструментов себе в пайплайн, общим размером 109922 строчек кода (или 4.5MB). Этот код не видел ни один человек (только я видел stack traces, когда ставил архитектуру). Размер и качество этого кода не имеют значения, пока у нас есть общий результат работы проекта - точность, скорость и стоимость.

(1) Точность работы - 83.8% на бенчмарке из самых сложных кейсов и 99.7% при оценке клиентом.

(2) Скорость работы - можно получить результаты за ночь (против 3.5-7 дней раньше). При желании можно и быстрее - выкрутив параллелизм. Лимиты - не проблема.

(3) Стоимость работы всего этого комбайна, включая разработку, эксперименты и полные прогоны пайплайна - $26.6 (против $800+ в попытках предыдущей команды). Скриншот расходов OpenAI по дням - в комментариях.

Архитектура не является ничем выдающимся - это побочный эффект от решения задачки, которую eval команда оформила в качественный ground truth датасет.

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

По итогам команды говорят, что получился классный тимбилдинг и экспресс-практикум. Даже не против повторения подобного, но без стресса (дней 8 вместо 6). А ведь все начиналось вечность назад как проект, который уже не спасти.

Спасибо, что читали эту историю и проживали ее вместе с командой проекта Hail Mary!

Ваш, @llm_under_hood 🤗

Давайте соберем карту внедрений SGR и список частых вопросов по ним

В коммьюнити идут обсуждения про Schema-Guided Reasoning, в основном в контексте Open Source проекта SGR Deep Research. Этот проект для некоторых команд стал первым наглядным примером того, как подойти к задаче построения умного агента на базе относительно небольших моделей (в том числе и локальных). Чаще всего слышим про попытки адаптировать методы в банковской сфере и промышленности. Может быть нас еще больше?

Давайте вообще систематизируем весь этот процесс и сделаем его эффективнее для коммьюнити!

Вот анонимный опросник, чтобы построить более полную карту внедрений по отраслям и собрать вопросы. Опросник: Строим вместе карту внедрений SGR

Результаты опроса и ответы на самые частые вопросы будут в каналах:

- LLM под капотом
- Neural Kovalski

Ваш, @llm_under_hood 🤗

В каких компаниях вопросы про 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 🤗