Канал про разработку продуктов на базе LLM/ChatGPT. Выжимка важных новостей и разборы кейсов.
Информация о канале обновлена 18.11.2025.
Канал про разработку продуктов на базе LLM/ChatGPT. Выжимка важных новостей и разборы кейсов.
Давайте расскажу вам еще про один кейс достаточно необычного использования LLM в продуктовых целях.
Итак, компания - это производитель популярной на рынке продукции, что-то вроде Red Bull. Они производят и публикуют очень много видео-рекламы. Для этого у них есть гигантская библиотека всякого рода заготовок - в виде отснятых в прошлом роликов или сгенерированных заставок.
Когда создается новый рекламный ролик, его обычно монтируют из старых и новых записей. Если чего-то подходящего в архивах нет, то приходится тратить время и ресурсы на запись нового. Либо можно подойти творчески и как-то интересно обыграть и обработать старую запись.
Соответственно, компании хочется, чтобы создатели новых роликов в компании могли лучше искать и переиспользовать существующий материал. Сейчас поиск работает немного похоже на Elastic Search - ролики помечаются тэгами и вручную “украшаются” свойствами с описаниями. Это долгая и муторная работа.
Команда реализации сначала сделала достаточно простую и очевидную вещь (пусть и дорогую, но всяко более дешевую, чем запись нового ролика) - они “скармливают” видео из архива в мощной LLM с video input и просят заполнить описание. Потом поиск ищет по этому описанию используя обычный векторный поиск и Query Expansion (когда просим LLM-ку “развернуть” запрос пользователя в нормальный запрос напрямую к БД, используя терминологию, в которой данные там проиндексированы).
Целевая метрика у компании - уменьшить количество времени, которое было потрачено на запись новых видео при монтаже рекламы.
А что тут можно сделать еще лучше?
(1) Начать со сбора данных - обвязать систему поиска интерфейсами так, чтобы можно было собирать телеметрию о том, какие результаты были использованы пользователями
(2) Построить пайплайн для извлечения структурированных данных о записи прошлых видео (какие видео люди искали, и какие элементы потом были использованы ими при монтаже). Благо все эти данные у них хранятся.
(3) Сделать так, чтобы разработчики могли быстро тестировать гипотезы и выкатывать их на проду с обратной связью, чтобы видеть - стали результаты поиска лучше или нет.
А дальше начинается самое интересное. Можно посмотреть на подход к реализации проекта “Кейс про агента-писателя” и переиспользовать подход к анализу оттуда в связке с идеей из кейса "про товары, которые невозможно найти". Пусть агент берет в качестве вводных данных не конкретное описание видео куска, а саму тему для рекламного ролика. И потом проходится по Schema-Guided Reasoning процессу:
(1) формулируем общую концепцию ролика
(2) ищем все потенциально подходящие ролики
(3) если нужно, прогоняем их через VLM с дополнительными запросами (эти метаданные сохраним в базе на будущее)
(4) прорабатываем outline финального ролика со скриптом и ссылками на ролики
(5) полуавтоматически “нарезаем” эти ролики прямо в timeline и грузим в проект для быстрого просмотра и редактирования
Тут две забавные вещи:
(1) Даже если человеку не понравится идея, он ее полностью выкинет и переделает, оставив только найденные материалы, то миссия уже выполнена. Целевая метрика - облегчить людям поиск подходящего видео.
(2) Эта концепция не нова. Ее уже используют в Amazon Prime для генерации кратких выжимок серий сериалов на платформе.
В принципе, команда и так уже двигалась в данном направлении, но им хотелось услышать независимое экспертное мнение и подтверждение того, что они двигаются правильно и не упустили какое-то секретное супер-решение. Плюс видение того, как можно контроллировать качество и развивать продукт дальше.
Ваш, @llm_under_hood 🤗
PS: Пост со списком всех кейсов
Напомню, что ERC3 - это дружеское соревнование по написанию агентов, которое состоится в конце ноября. Зарегистрироваться можно тут. С нами уже 300 команд!
Среда работы для агентов будет выглядеть так:
(1) Подключаемся к API конкретного соревнования.
(2) Запускаем новую сессию
(3) Получаем поочередно новые задачи и передаем агенту, которому нужно будет дергать эти API для выполнения задачи
(4) Когда агент выполнил все задачи, сессия закрывается автоматом. Можно теперь ждать результаты.
Можно будет запускать любое число сессий, главное прописывать в них специфику эксперимента. Модель такая-то, архитектура такая-то итп.
И как раз сегодня у меня впервые получилось отладить весь этот процесс end-to-end, включая "ловушки" в задании. Вывод работы - на скриншоте.
К слову, SGR agent на 4o справляется с таким заданием в 75% случаях. Но я задачи для соревнования буду усложнять так, чтобы он не особо справлялся.
Ваш, @llm_under_hood 🤗
Про Schema-Guided Reasoning говорили и писали уже много. Но одно дело слышать, а другое дело - увидеть, как оно работает вживую. Особенно, если реализация сделана настолько аккуратно и вдумчиво, как это сделали ребята из neuraldeep.
Поэтому вот вам видео на 6 минут - Русский / English
Самое классное тут, что эта демка работала на достаточно слабой и медленной Qwen-30b-a3b. А теперь представьте, что можно сделать, если прочитать методичку (написано тут), взять код (он есть в Github) поставить ему звездочку, взять модель помощнее и сделать свою версию - с тестами, с доступом в свои хранилища, учетом своей специфики и своими инструментами. И запускать все это на небольшой коробочке вроде DGX Spark.
А если будут PR - можно смело присылать их в ту репу, чтобы двигать дальше State of the Art в области применения небольших LLM на практике.
Ваш, @llm_under_hood 🤗
Поддержку для JSON Schema добавили в Google во все поддерживаемые модели Gemini (в старые версии - с ограничениями) Теперь Pydantic и Zod должны работать из коробки.
Они добавили поддержку самых часто запрашиваемых клиентами фич:
(1) AnyOf / Union - используется для раутинга в SGR
(2) $ref for recursive schemas - теперь можно делать нормальную вложенность каскадов
(3) max/min для числовых constraints
А заодно они, наконец, починили порядок свойств. Теперь LLM будет заполнять схему в том порядке, в котором поля прописаны
API now preserves the same order as the ordering of keys in the schema
Причем прямо в статье у них приведен пример модерации почты с раутингом и каскадом.
Ну и в целом в Google пишут, что Structured Outputs - это один из самых частых инструментов, который используют разработчики при создании реальных AI приложений
Structured Outputs is one of the most frequently used tools by developers building real-world AI applications.
Вот пара цитат от их клиентов
We are building AI agents for the agentic web, and our main goal is to build trust in AI agents for handling business operations. Being able to define precise schemas and trust the output is key to our production systems. Structured Outputs have reduced API calls by up to 6x in some workflows and completely eliminated the broken JSON responses that used to require extra validation checks.
и
For us, Structured Outputs are all about reliability, speed and cost efficiency. By forcing the LLM to provide a predictable, machine-readable format, we can build more robust features faster, reduce errors, and use cheaper models for tasks that would otherwise require more expensive ones.
В общем, все молодцы. Новость тут.
Спасибо Тимуру, который первым поделился радостными новостями в чате канала. Кстати, у него есть и свой канал - The AI Architect (@the_ai_architect)
Ваш, @llm_under_hood 🤗
PS: А еще в документации про JSON Schema теперь упоминается, что заполнение поля description в схеме - критично важно для управления работой модели
Use the description field in your schema to provide clear instructions to the model about what each property represents. This is crucial for guiding the model's output.
Поэтому паттерны работы с Schema Guided Reasoning теперь можно смело пытаться переносить и на Google Gemini 2.5.
Я сегодня закончил первый прототип платформы для ERC3: Enterprise AI Agents. Получается довольно симпатично, сейчас все расскажу.
В общем, будет сайт платформы. Все, кто зарегистировался в ERC3 (сделать это можно тут), смогут получить AccessToken для него.
На этом сайте будут доступны несколько стендов. Каждый стенд - это набор систем, которые работают вместе, вместе с описанием и API. Их можно вызывать как вручную, так и через агентов.
Например, уже есть отладочный стенд shop (им я отлаживаю всю систему) - это APIшка для небольшого магазина, со своей логикой и базой. [1] Там есть такие методы:
(1) GET /products - получить список продуктов
(2) GET /basket - просмотреть текущую корзину
(3) POST /backet/add,remove,checkout - добавить продукты в корзину, убрать из корзины, оплатить.
Как это все использовать?
Пишем скрипт, который:
(1) Запускает новый эксперимент на стенде store
(2) Пока остались нерешенные задачки в эксперименте
(3) Забирает следующую задачку для эксперимента (например “Buy ALL GPUs”) и url для API
В этот момент на платформе разворачивается изолированная среда, сконфигурированная специально под эту задачу. API будут настроены и заполнены данными под эту задачу. Даже, если параллельно 100 команд решают другие задачи - у них будут свои изолированные среды.
(4) Теперь мы можем запустить своего агента, скормить ему url для API от этой задачи и отправить решать ее. Скорее всего, в этой задаче "Buy ALL GPUs", ему надо будет получить список продуктов, выбрать GPU, добавить их в корзину и сделать checkout [2]
(5) Когда агент закончил работу, вызываем “завершить задачу” и идем в пункт (3) - пока остались задачки, решаем их. Если не осталось - можно посмотреть Score и логи выполнения задач агентом. [3]
Запускать можно будет любое число экспериментов, помечая их метаданными по архитектуре, используемой модели, размеру GPU и всяческим параметрам. Это пригодится для AI R&D деятельности нашего коммьюнити и за пределами соревнования.
Логика экспериментов и правила соревнования остаются аналогичными ERC2. Перед началом ERC3 я все еще раз напомню и проговорю.
Доступ к этому тестовому стенду планирую дать в течение следующих дней 5-7. Доступ к стенду с API-шками от финального соревнования - за 10-14 дней до соревнования. Ну а конкретные соревновательные задачи откроются 26 ноября.
Ну как вам оно?
Ваш, @llm_under_hood 🤗
[1] store - это простейший тестовый стенд, к нему я дам доступ в ближашую неделю-другую. Для соревнования будет что-то более серьезное.
[2] на самом деле, даже в этой простой задаче не все так просто. Ведь агент обнаружит, что API возвращает продукты только страницами по 3, что больше 3-х page size делать нельзя. А при попытке купить все GPU обнаружится, что 2 H100 уже купили, и надо переделывать корзину. Каждая задача в рамках стенда - уникальна.
[3] Во время ERC посмотреть score на соревновательном стенде нельзя будет до момента оглашения победителей.
Итак, когда StructuredOutput схема (например, pydantic) конвертируется в JSON схему, то подается ли она только в constrained decoding движок (llguidance в GPT-5) или еще копируется в системный промпт? Причем в документации OpenAI нет ни слова про копирование.
Давайте проверим. Берем такую SGR схему:
class CandidateEvaluation(BaseModel):
brief_candidate_summary: str = Field(..., description="in Thai")
rate_skill_match: Annotated[int, Ge(1), Le(1)]
final_recommendation: Literal["hire", "reject", "hold"]
и отправляем в OpenAI c запросом в десяток tokens:
user = "evaluate Sam Altman for DevOps Role at OpenAI"
completion = client.chat.completions.parse(
model="gpt-5-mini",
response_format=CandidateEvaluation,
messages=[
{"role": "user", "content": user },
],
)
Если JSON схема НЕ добавляется в промпт, тогда промпт будет в пределах 20-30 tokens, а ответ не будет содержать ничего неожиданного.
Запускаем и смотрим на размер входного промпта и сам ответ:
completion.usage.prompt_tokens == 100
completion.choices[0].message.parsed.brief_candidate_summary[:10] == "แซม อัลท์แ"
Что и требовалось доказать. Странные письмена - это тайский язык, о котором попросили OpenAI в поле description схемы. Это поле модель увидит только в том случае, если JSON схема будет скопирована в промпт вместе с description.
Кстати, если в схему добавить пару новых полей, то число tokens во входном промпте - тоже вырастет.
Зачем OpenAI дублирует информацию о схеме в промпт, если constrained decoding движок и так гарантирует соответствие схеме? Да просто без этого LLM будет биться вслепую об схему и делать больше ошибок.
А как это относится к инженерному подходу? Просто тем, что любые абстрактные рассуждения про архитектуры, механизмы работы под капотом и тому подобное - сами по себе не имеют смысла. Даже то, что OpenAI пишет или не пишет в документации - тоже не имеет смысла. Имеет смысл только то, что мы можем измерить и оценить [1]. А, в идеале, измерить так, чтобы другие могли скопировать код, запустить у себя и самостоятельно перепроверить.
Можете попробовать запустить эти сниппеты сами и поиграть с ними.
Ваш, @llm_under_hood 🤗
---
[1] то, что мы можем измерить или протестировать - мы можем потом осознанно докрутить и улучшить
Это продолжение истории, которую я описывал в канале ранее. Оглавление тут. Там нужно было срочно сделать систему извлечения сложных данных из разнообразных промышленных PDF спецификаций.
Пару дней назад сделали полный прогон на новых документах от новых компаний, которые добавили в пайплайн (первые шаги пайплайна - это отдельная песня). Пайплайн прожевал их, найдя 41932 сущностей
Напомню, что 400 сущностей для тестового набора данных извлекала команда в течение пары недель в сумме. Можете представить себе экономию времени.
В процессе система отчиталась, что AI Coding agent сгенерировал 2515 инструментов в 372668 строчек кода общим объемом в 15.28MB. В сумме было потрачено $61.62 (такими темпами аккаунт не скоро выйдет на новый Tier). Точность извлечения на тестовых (самых сложных) данных: 84.8%, что выше требований клиента. Причем, слабое место пайплайна видно глазами - категория документов и полей в документе (смотрите на большую красную секцию на карте ошибок в комментариях - это китайские поставщики, в их документах доменная модель очень сильно отличается в ряде моментов). Можно над этим работать дальше или просто учитывать при использовании результатов.
Про этот проект я рассказывал подробнее на KanDDDinsky. Видео пока не выложили, слайды и ссылки к докладу лежат тут.
Директора очень довольны получившейся архитектурой (дословно "Because we can!"), особенно тем фактом, что этот код не видел ни один человек, да и не увидит. При новых прогонах - просто перегенерируем заново.
Но на самом деле активное использование системы для кодинга внутри LLM-пайплайна - это просто оптимизация скорости и стоимости, которая стала возможной благодаря наличию тестов и цикла быстрой оценки качества.
Ваш, @llm_under_hood 🤗
Интерес к применению AI в принципе большой, ибо туда компании перебрасывают значимую часть бюджетов, но вот внятной экспертизы и насмотренности у внедренцов не хватает. Будем пытаться исправлять всем DDD коммьюнити
Энтузиазм и интерес в целом есть. Скажем, на ComoCamp весной ко мне на OpenSpace сессию пришел один единственный человек (почти все ушли к Alberto Brandolini), теперь уже был целый выделенный DDD+AI трэк, а на следующие конференции планируется уже выделить отдельные дни с воркшопами на эту тему.
Я рассказал про три самых интересных проекта c LLM под капотом, где без использования принципов DDD мало что бы получилось (reasoning история, невозможная история и история с анализом старого кода - они были в канале). Видео рассказа они потом выложат.
И еще провел workshop по применению AI Case Mapping вместе с демонстрацией и описанием принципов (если кратко - описываем текущие проблемы бизнеса, а потом оцениваем на возможность применить к этому AI с учетом известных успешных кейсов внедрения и их грабель, я фотку стены выложу в комментарии). Это был интересный эксперимент, т.к. я его впервые проводил вживую без подготовки и в условиях ограниченного времени (обычно это online + Miro в ином формате). Eric Evans говорит, что вышло несколько сумбурно, нужно закладывать сильно больше времени. А еще говорит, что можно не городить огород и взять для анализа проблем бизнеса обычный Event Storming, а после выявления hotspots, уже моим способом анализировать и приоритизировать их на возможность быстро и безрисково применить AI/LLM. Alberto не против попробовать такое.
Народу на конференции очень хорошо “зашла” концепция, что мы ограничиваем внедрение AI/LLM одним небольшим компонентом, который встраивается в процесс. У них тогда сразу в голове начинают в правильном направлении крутиться мысли - если это компонент, то его можно описывать, тестировать и версионировать. То есть тесты и evals приходят в голову в первую, а не в последнюю очередь.
В общем, вышло интересно. Если кто работает с крупными банками, международными корпорациями и тому подобным - всячески советую KanDDDinsky и подобные мероприятия. Там и познавательно, и контактов можно интересных набрать.
Ваш, @llm_under_hood 🤗
. Но не потому, что Eric Evans (автор DDD) рассказывает про базовые вещи DDD+AI с учетом перспектив и наработок, которые мы сделали в нашем коммьюнити и проектах. А потому, что вон ту черную изоленту ему на ноутбук присобачил я. Чтобы диоды не светили операторам в камеры.
Технологии приходят и уходят, а изоленты - вечны.
Кстати, Eric Evans будет keynote спикером на Enterprise RAG Challenge 3.
Какие бы вопросы вы хотели задать ему?
Ваш, @llm_under_hood 🤗
Владелец канала не предоставил расширенную статистику, но Вы можете сделать ему запрос на ее получение.
Также Вы можете воспользоваться расширенным поиском и отфильтровать результаты по каналам, которые предоставили расширенную статистику.
Также Вы можете воспользоваться расширенным поиском и отфильтровать результаты по каналам, которые предоставили расширенную статистику.
Подтвердите, что вы не робот
Вы выполнили несколько запросов, и прежде чем продолжить, мы ходим убелиться в том, что они не автоматизированные.
Наш сайт использует cookie-файлы, чтобы сделать сервисы быстрее и удобнее.
Продолжая им пользоваться, вы принимаете условия
Пользовательского соглашения
и соглашаетесь со сбором cookie-файлов.
Подробности про обработку данных — в нашей
Политике обработки персональных данных.