Канал про разработку продуктов на базе LLM/ChatGPT. Выжимка важных новостей и разборы кейсов.
Информация о канале обновлена 03.10.2025.
Канал про разработку продуктов на базе LLM/ChatGPT. Выжимка важных новостей и разборы кейсов.
Точнее, сегодня это заявил исследователь из 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, LLM или CV в медицине, биотехе и смежных областях?
Если у вас уже есть опыт или вы активно интересуетесь этой сферой, давайте знакомиться!
Расскажите о себе и своих проектах в комментариях или пишите напрямую @abdullin.
Ваш, @llm_under_hood 🤗
Завтра и послезавтра проходит TED AI Vienna 2025
Из интересного в программе - OpenAI, Google DeepMind, Microsoft, JetBrains AI и множество нишевых исследователей.
Если кто-то тоже будет там - пишите!
Ваш, @llm_under_hood 🤗
(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: про бенчмарки, включая их двухлетнюю историю, расписано тут
Всего был заполнен 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 🤗
, который отвечает за самую сложную часть анализа документов в завершенном проекте (см выше). Там текста - кот наплакал, а вся логика зашита в 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-ок, из которых нужно извлечь данные. Там уже разные промпты под источник.
Владелец канала не предоставил расширенную статистику, но Вы можете сделать ему запрос на ее получение.
Также Вы можете воспользоваться расширенным поиском и отфильтровать результаты по каналам, которые предоставили расширенную статистику.
Также Вы можете воспользоваться расширенным поиском и отфильтровать результаты по каналам, которые предоставили расширенную статистику.
Подтвердите, что вы не робот
Вы выполнили несколько запросов, и прежде чем продолжить, мы ходим убелиться в том, что они не автоматизированные.