Transcription
Всем привет. Сегодня у нас на повестке дня ну очень горячая тема. Мы погружаемся в материалы из сессии Open AI Build Hour. Привет. Да, сессия была полностью посвящена GPT5. Именно источники у нас — это сама запись сессии, конечно, презентации, которые там показывали, примеры кода, демо, в общем, всё, что удалось собрать. Материала много, и он довольно плотный. Да. Так и есть. И наша задача сегодня не просто пересказать, а именно, ну, как бы вытащить самую суть, разобраться в деталях. Согласно. Понять, что там действительно нового, как это можно использовать на практике, ну, и, конечно, куда всё это движется. Вот-вот, чтобы у слушателей сложилось чёткое представление о GPT5 и главное — о его потенциале.
Итак, давайте разбираться, что же такого особенного в этой новой модели. С чего начнём? Ну, начать стоит с того, почему вообще такой ажиотаж вокруг G5. Понимаешь, судя по тому, что показали Open Ai, это не просто очередное обновление, типа циферки подросли в бенчмарках. Хотя и они подросли, как я понимаю, да, и к этому вернёмся. Но главное — это качественный скачок. Прямо вот чувствуется, что модель перешла на какой-то новый уровень. Особенно это заметно в задачах, связанных с кодом.
Кодинг — это всегда было сильной стороной GPT. Но что конкретно улучшилось? Генерация кода стала чище? Не только чище. Значительно лучше стало качество самого кода. И не только, но и фронт. Модель способна создавать вполне себе приличный UI, что раньше было, ну, скажем так, слабой стороной. Хм. Генерация UI. Это интересно. А ещё, а, и ещё — и это, пожалуй, самое интригующее — это выполнение сложных многошаговых задач, тех самых, что требует длинных цепочек рассуждений, планирования, использования внешних инструментов. Вот тут, кажется, основной прорыв.
Так, давай тогда по порядку. Сегмент один. Новые горизонты GPT5. Ты уже упомянула качество кода и фронтенд. А что насчёт таких понятий, как управляемость и совместная работа? Их тоже активно продвигали? Да, стибилити и коллаборативный аспект, это очень важные моменты. Управляемость — это про то, насколько точно модель следует твоим инструкциям. То есть меньше самодеятельности там, где не просят. Именно меньше ситуации, когда ты просишь одно, а модель делает что-то похожее, но не совсем то или вообще игнорирует часть твоего запроса. GPT5, судя по всему, стала гораздо более послушной, если можно так выразиться. Она, точнее, придерживается заданных рамок и условий. Ага.
А совместная работа — это как понимать, что она теперь кофе может принести? Шутка. Ну, почти. Совместная работа — это про то, насколько комфортно и эффективно с моделью взаимодействовать в процессе, ну, скажем, разработки. Она лучше держит контекст диалога. То есть, если я ей говорю: "Перепиши вот эту функцию, но используя другой подход", она не забудет, о какой функции речь шла 5 минут назад. Да и не просто не забудет, а сможет эффективнее принять твои правки, понять, почему ты хочешь именно так, и даже предложить релевантные следующие шаги в разработке. Это создаёт ощущение, ну, такого более гладкого, что ли, партнёрства. Не просто я дал команду, она выполнила, а именно совместный процесс, ближе к работе с живым, ну, пусть и очень специфическим ассистентом. Звучит многообещающе.
Хорошо. А бенчмарке? Ты упомянула, что цифры подросли. Мельком говорили про Sweet Bench и ADR Poyглоlotт. Не будем углубляться в конкретные проценты, но что эти тесты вообще измеряют, чтобы понимать, в чём именно модель стала лучше по этим метрикам. Да, давай кратко пройдёмся. Sweet Bench — это как раз бенчмарк для оценки того, что Openi называет агентными способностями. То есть насколько хорошо модель справляется с задачами, которые требуют планирования последовательности действий, использования внешних инструментов, вот всего того, о чём мы говорили. Понятно? То есть этот тест на способность быть агентом, выполнять сложные задания. Совершенно верно. Ар полиглот, он больше сфокусирован на коде, но не на генерации с нуля, а на редактировании существующего кода, причём на разных языках программирования. А то есть как она умеет вносить изменения, сохраняя стиль, логику, исправляя ошибки? Именно аккуратно и корректно она может работать с уже написанным кодом. То, что показатели на обоих бенчмарках выросли, говорит о том, что GPT5 стала лучше и в плане, так сказать, общего интеллекта и планирования Sweet Bench, и в специфических навыках работы с кодом Ар полиглот.
Хорошо, с общими улучшениями картина проясняется, но вот ты несколько раз упомянула агентные задачи, и в материалах сессии, особенно в выступлении Билла Пиблса, этому уделялось, ну, прямо очень много внимания. Похоже, это действительно ключевая фишка GPT5. Можешь подробнее объяснить, что это за зверь такой Agentic Tasks? Да, это, пожалуй, центральная тема. Агентные задачи — это не просто задай вопрос, получай ответ. Это целый класс задач, где от модели требуется не просто сгенерировать текст или код, а выполнить, по сути, небольшой проект. Проект в каком смысле? В смысле, что задача состоит из множества шагов. Модели нужно сначала проанализировать исходный запрос пользователя, потом на основе этого анализа спланировать последовательность действий. Так, планирование — это уже интересно. Дальше самое важное — вызвать нужные внешние инструменты. Это могут быть API для поиска информации в интернете, для работы с файловой системой, для отправки команд каким-то другим сервисом, да, что угодно. То есть модель не ограничена только своими знаниями. Она может активно взаимодействовать с внешним миром через API. Именно потом ей нужно обработать результаты этих вызовов, понять, что вернул инструмент. На основе этого возможно скорректировать свой первоначальный план, может быть, вызвать другие инструменты и так далее, пока цель не будет достигнута. Точно до тех пор, пока конечная цель, поставленная пользователем, не будет достигнута. И вот GPT5, как утверждают в Open AI, проектировалась с особым упором на способность эффективно выполнять вот такие длинные цепочки рассуждений и взаимодействии с инструментами. Получается, мы говорим о способности моделей действовать, ну, почти автономно в рамках поставленной задачи. Не просто генерировать контент, а именно действовать, вызывать инструменты, принимать решения на основе их вывода, адаптироваться. Совершенно верно.
И тут есть несколько ключевых моментов, которые делают GPT5 особенно сильной в этом. Во-первых, сама способность выполнять шаги и вызывать инструменты. Это уже было в какой-то мере и раньше, но теперь это делается, судя по всему, гораздо надёжнее и на более сложных задачах. А во-вторых, а во-вторых, и это очень важно, модель не просто слепо выполняет шаги, она может, так сказать, понимать, почему она их выполняет. Она генерирует объяснение своих действий, то, что они называют преамбулами рассуждения или цепочкой мысли (Chain of Thought), которая теперь стала более явной и управляемой. То есть можно посмотреть, как она пришла к тому или иному решению. Да, и это не просто для отладки полезно, это критично для сложных задач. Но что ещё важнее и что действительно, кажется, отличает GPT5 — это способность к самокоррекции. Самокоррекции. Это как? Ну, представь, модель начала выполнять задачу по какому-то плану, но в процессе, получив ответ от инструмента или проанализировав промежуточный результат, она понимает, что первоначальный план был неоптимальным или вообще ведёт в тупик. Так вот, GPT5 способна это обнаружить и сама проактивно скорректировать свой план действий. То есть она может сказать: "Ой, я тут подумала, давайте лучше сделаем вот так". Грубо говоря, да, в логах рассуждений это будет видно как изменение плана. Это уже не просто следование инструкциям. Это элементы адаптивного поведения. Почти как у человека, который понимает, что что-то идёт не так, и меняет стратегию. Хмм, самокоррекция. Это действительно звучит как шаг к чему-то большему, чем просто инструмент. Почти как, ну, не знаю, стажёр, который учится на своих ошибках. Возможно, аналогия не совсем точная, но направление мысли верное. Это добавляет гибкости и надёжности в выполнении сложных задач.
Хорошо. И чтобы всем этим новым великолепием: рассуждением, инструментами, самокоррекцией как-то управлять, Opena ввела новые параметры в API. Я видел там что-то про minimal reasoning. Объясни, пожалуйста, что это? Я правильно понимаю, что это способ получить ответ быстрее, почти мгновенно, но не жертвуя при этом мозгами GPT5. Как это вообще возможно? Да, концепция minimon reasoning именно в этом. Идея в том, что для некоторых задач или частей задачи модели не нужно проводить глубокий многоэтапный анализ. Достаточно минимально необходимого обдумывания. Когда ты выставляешь этот параметр, модель как бы переключается в режим быстрой реакции, а качество ответа страдает. Вот в этом и фокус. В демонстрации на build был очень показательный пример. Они взяли один и тот же сложный запрос. С minimal reasoning ответ пришёл за 0.9 секунды. Меньше секунды, да? А с high reasoning, то есть с максимальным уровнем обдумывания, тот же запрос обрабатывался 6.9 секунд и почти 7 секунд. Разница колоссальная. А результат? Сам ответ был одинаковый. Вот что самое интересное. По заявлению Open AI, интеллектуальная составляющая ответа, его качества оставалось на том же высоком уровне GPT5, то есть ты получаешь ту же мощь, но гораздо быстрее. Ого.
А в каких случаях тогда использовать High Reasoning, если минимул такой быстрый и умный? High Reasoning для действительно запутанных задач, где требуется глубокий анализ, сравнение множества вариантов, построение сложных планов, там, где цена ошибки высока и лучше потратить больше времени на обдумывание. А минимул идеален для сценариев, где задержка критична. Например, чатботы, интерактивные помощники, автодополнение кода в реальном времени. Это открывает дорогу к использованию GPT, там, где раньше более медленные модели были неприменимы. Понятно. То есть теперь можно выбирать между скоростью и глубиной размышлений, не теряя при этом базовую умность модели. Это круто. А что ещё нового в API? Я видел упоминание Castle Tools. Да, это ещё одно очень приятное нововведение для разработчиков. Что оно даёт? Упрощает работу с инструментами. Значительно упрощает. Раньше, чтобы модель могла вызвать твой инструмент, например, API погоды или калькулятор, тебе нужно было в запросик Open AI API описать этот инструмент в строго формате JON схема. Да, помню. Это бывало довольно муторно, особенно если инструментов много или у них сложная структура параметров. Вот. А теперь с Custom Tools ты можешь описать вызов инструмента и его параметры прямо в текстовом виде, в самом промте. Например, написать что-то вроде: "Вызови инструмент calculator с выражением 2 + 2". Серьёзно? Прямо текстом. И модель сама это разберёт и сформирует правильный вызов. Да, она сама парсит это текстовое описание и генерирует структурированный вызов инструмента, который ты потом получаешь в ответе API. Это снимает огромную головную боль с подготовкой JON схемы. Звучит как магия. Особенно, наверное, удобно при работе с кодом или какими-то сложными системами, где нужно вызывать много разных API с разными параметрами. Безусловно, это делает интеграцию с инструментами гораздо более гибкой и интуитивно понятной. Меньше формализма, больше естественного языка.
Так, значит, у нас есть управление уровнем рассуждений, reason and effort, и упрощённый вызов инструментов custom Tools. Логично. А как насчёт управления самим выводом модели, чтобы она говорила больше или меньше? Например, я видел параметры вбосити. Это оно? Да. В рыбосити — это основной рычаг для контроля многословности ответа. Он позволяет тебе указать, насколько детальным должен быть финальный результат, который увидит пользователь. То есть можно попросить короткий ответ или, наоборот, развёрнутый. Именно verbosity low даст тебе более сжатый, лаконичный ответ, а verbosity high — более подробный, возможно, с дополнительными пояснениями, примерами или, если речь идёт о коде, комментариями и обработкой ошибок. А влияет ли это на что-то ещё, кроме финального текста? Да, что интересно, этот параметр влияет и на то, как модель взаимодействует с инструментами в процессе своей работы. Например, при Hiverbosти она может включать более подробное описание или контекст в свои запросы к инструментам, что может помочь инструментам лучше понять задачу. Хм, то есть вербозность влияет не только на выход, но и на внутренние шаги. Получается так. Это взаимосвязанные вещи. К этому мы ещё вернёмся, когда будем говорить про примеры с кодом. Но сначала надо обсудить одно из самых главных изменений, о котором Open I говорит постоянно. Это переход на новый API. Точно, respons API. Они его позиционируют прямо как API V2. Зачем понадобилось сломать обратную совместимость и вводить совершенно новый API вместо привычного compсpi? Что там таком революционного, кроме синтаксического сахара типа output. Вместо choice is 0, message content? Ну, outputтекст — это, конечно, приятно, но это мелочь. Фундаментальное отличие и главная причина перехода — это то, что responsс API изначально спроектирован для работы с моделями, обладающими продвинутыми способностями к рассуждению. Как же PT+? И ключ к этим способностям — это так называемые reasoning items. Reasoning items — те самые предметы рассуждения. Что это такое? Звучит загадочно. Это и есть самая суть. Помнишь, мы говорили про цепочку мыслей модели (Chain of Thought), промежуточные шаги, которые она делает. Так вот, reasoning items — это, по сути, токены, которые представляют эти шаги рассуждений. Это как бы слепок мыслительного процесса модели в определённый момент. Ага. То есть это не просто финальный ответ, а ещё и как бы записки на полях, которые модель делала по ходу дела. Отличная аналогия. Именно записки на полях. И responsс API позволяет тебе получать эти записки от модели и, что самое важное, передавать их обратно модели на следующих шагах. Зачем? Зачем модели, её же собственные старые записки? Чтобы она не потеряла нить рассуждений, особенно в длинных многошаговых агентных задачах. Давай разберём на классическом примере, который они приводили. Пользователь спрашивает: "Какая погода в Париже?" Окей. Модель анализирует запрос и решает: "Ага, мне нужен инструмент geta с параметром location par". Прежде чем просто вернуть тебе этот запрос к инструменту, она через responsт тебе не только сам запрос Tool calls, но и связанный с ним reasoning items. То есть те самые записки, которые объясняют, почему она решила вызвать именно этот инструмент с таким параметром. Да, эти items содержат токены, отражающие её мысль. Пользователь спросил про погоду в Париже, использую get Weather. Дальше ты, как разработчик, берёшь этот запрос get Weather, вызываешь свой AP погоды, получаешь ответ, скажем, + 20°, солнечно. И передаю этот ответ обратно модели, чтобы она сформулировала финальный ответ для пользователя. Да, но в responsшь не только ответ от инструмента + 20°, но и те самые reasoning items, которые ты получил от модели на предыдущем шаге. А вот оно что. Чтобы она вспомнила, с чего всё началось, и почему она вообще спрашивала про погоду. Точно, в этом простом примере с погодой это может показаться, ну, немного избыточным. Какая разница, вспомнит она или нет? Но представь себе сложную агентную задачу, которую мы обсуждали. Например, проанализируй отчёт о продажах за прошлый квартал в формате CSV. Сравни его с данными из базы данных за позапрошлый квартал. Найди топ-три самых быстрорастущих продукта по выручке. Подготовь краткие слайды для презентации в формате Marкdдаун и отправь их моему менеджеру на email. Да уж, задачка не на один шаг. Тут и работа с файлами, и с базой данных, и анализ, и генерация контента, и отправка AIL. Десятки шагов и вызовов инструментов. Вот именно. И на каждом шаге модель генерирует какие-то промежуточные мысли, принимает решения. Если не сохранять и не передавать этот контекст рассуждения reasoning items, то где-то на середине этого сложного процесса модель легко может забыть первоначальную цель или потерять логическую связь между шагами. Она может начать делать что-то не то, отклониться от курса. Понимаю. Передавая reasoning items туда-обратно, мы как бы помогаем ей держать всю картину в голове, сохранять когерентность на протяжении всей длинной задачи. Совершенно верно. Это критически важно для надёжной работы агентов. И Open AI заявляет, что использование Reasoning Items через responses API даёт измеримый прирост производительности порядка 2-4% на бенчмарках именно агентных задач, таких как SweetBch. 2-4% звучит не так, чтобы очень много. На первый взгляд, да, но в сложных задачах, где накапливается много шагов, эти проценты могут вылиться во вполне ощутимую разницу между успешным выполнением и провалом или неоптимальным результатом. Плюс это может влиять на количество токенов, на время выполнения. Логично.
А есть ещё какие-то плюшки у Responses API, кроме вот этой поддержки Reasoning Items и сохранения контекста? Да, есть ещё как минимум два важных момента, связанных с этим. Во-первых, это потенциально лучшее кеширование запросов. Кеширование. Каким образом? Поскольку у Resing Items передаются модели как часть, ну, скажем так, префикса текущего шага диалога, то если модель часто приходит к одинаковым промежуточным выводам или планам в похожих задачах, эти последовательности reasoning item смогут кешироваться на стороне open AI. А, то есть если она уже думала таким образом раньше, то в следующий раз это произойдёт быстрее и дешевле. Потенциально, да. Это может ускорить ответы и снизить стоимость использования API для повторяющихся паттерноврасуждений. Насколько это будет эффективно на практике, покажет время, но сама возможность интересная. Согласен. А второй момент. Второй момент — это гибкость в управлении состоянием (state). По умолчанию responsс API работает в режиме store true. Это значит, что Open AI хранит у себя контекст сессии, включая эти reasoning items. Чтобы упростить разработчику жизнь, не нужно самому всё это хранить и передавать. Удобно, но не всем подходит, наверное, с точки зрения приватности данных, например. Вот именно. Для организаций, у которых есть строгие требования к хранению данных или которые просто хотят иметь полный контроль, предусмотрен режим store false. В этом режиме ты сам отвечаешь за хранение и передачу контекста. И Reasoning Items в этом случае передаются тебе в зашифрованном виде в поле reasoning encrypted content. Зашифрованном. То есть я не могу их прочитать, но могу передать обратно модели. Да. Ты получаешь непрозрачный для тебя блок данных, хранишь его у себя и передаёшь обратно модели на следующем шаге. Модель его расшифровывает и использует для восстановления контекста. Таким образом, ты сохраняешь преимущество когерентности рассуждений, но данные сессии не хранятся на серверах Open AI. Интересное решение, даёт выбор. В общем, посыл ясен. Хочешь выжить из GPT5 максимум, особенно для сложных агентных задач? Нужно переходить на Respons API и активно использовать reasoning items без вариантов. Именно так. Completion API, конечно, будет поддерживаться ещё какое-то время для совместимости, но все новые фишки и полная мощь GPT5 раскрываются именно через respons.
Хорошо, с А разобрались. Теперь давай вернёмся к параметру Verbсиity, который мы начали обсуждать. Был показан пример с генерации кода. Можешь подробнее рассказать, как Verbсиity влиял на результат, что там конкретно отличалось. Да, пример был довольно наглядный. Просили сгенерировать какой-то Python script, кажется, для работы с API. При установке Verbity High модель выдала не просто рабочий код. А какой? А код, который был хорошо структурирован, с подробными комментариями, объясняющими логику, с блоками trcept для обработки потенциальных ошибок, с проверками входных данных, в общем, то, что ты ожидаешь увидеть в качественном коде, готовом к использованию, ну или почти готовом. Понятно. А при Verbity low А при Verbity Low код тоже был сгенерирован, и он был функционально корректным, то есть делал то, что просили. Но он был гораздо более лаконичным, без комментариев, без сложной обработки ошибок, возможно, без некоторых проверок. Просто минимально необходимый код для выполнения задачи. То есть выбор зависит от того, что тебе нужно в данный момент: быстрый прототип или надёжный код для продакшена. Совершенно верно. Если ты просто хочешь быстро набросать идею, проверить концепцию, возможнобосити подойдёт лучше. Это будет быстрее и короче. Если же тебе нужен код, который потом будут читать, поддерживать, интегрировать в большую систему, тогда Highverbosity выглядит гораздо предпочтительнее. Но Openi подчёркивает, это не жёсткое правило. Стоит экспериментировать с разными уровнями Verbсити для конкретных задач. Логично.
А для разрядки они ещё показали забавный пример: генерацию кода для аски арта крипера из Minecraft. А, да, да, помню. Забавно было сгенерировать Python код, который выводит в консоль изображение крипера с символами. Зачем это было нужно? Просто показать, что модель может и такое. Думаю, да. Во-первых, показать, что она справляется и с такими немного неожиданными креативными задачами по чисто текстовому описанию: "Нарисуй крипера из Minecraft Васчи". Во-вторых, возможно, это была демонстрация той самой точности следования инструкциям. Если попросили аский арт, она сделала именно аский арт, а не что-то другое.
Кстати, про точность следование инструкция. Это подводит нас к очень важной теме промптинг. Одна из ключевых мыслей всей сессии, которая красной нитью проходила через все выступления, GPT очень, ну, прямо очень буквально и точно следует инструкциям. Да, это одновременно и огромная сила, и потенциальная проблема. Прочная. Я помню, упоминался твит Алекса Грейвлы из команды GitHub Copilot. Он заметил парадоксальную вещь. Его старые, хорошо отлаженные промпты, которые отлично работали с GPT4, стали давать худшие результаты с GPT5. Почему так? Казалось бы, модель стала умнее, а потому объяснял он, что GPT4 перестала пытаться додумывать за пользователя или угадывать его истинное намерение, если промпт сформулирован нечётко или двусмысленно. Она делает ровно то, что написано. Если написано что-то противоречивое или нелогично, результат будет соответствующим. То есть пространство для творческой интерпретации со стороны модели сузилось. Похоже на то. Отсюда главный вывод: точность, ясность и недвусмысленность формулировок в промпте становятся абсолютно критичными для работы с GPTTP. Нельзя больше полагаться на то, что модель сама поймёт. Это требует пересмотра подходов к промнженерингу. Старые трюки могут перестать работать. Именно.
Итак, что же советуют эксперты? Open AI, например, Анупраo, которое представлял гайд по промптингу для GPT5. Какие ключевые моменты нужно учитывать? Давай разберём основные советы, которые прозвучали. Их было несколько, и они все важны. Давай.
Первый. Первый и самый главный. Точность и непротиворечивость. Это прямо подчёркивалось много раз. Нужно избегать конфликтующих или двусмысленных указаний внутри одного промпта, например. Ну, например, если ты в одной части промпта говоришь: "Сделай ответ кратким", а в другой просишь подробно объясни каждый шаг, модель может впасть в ступор или выдать непредсказуемый результат. И это будет видно в её логах и рассуждений. В тех самых reasoning items. Она покажет, что столкнулась с противоречием. Понятно. Чёткость и логика в инструкциях превыше всего.
Что дальше? Второе. Уровень рассуждений. Reasoning effort. Мы уже касались этого. Начинать советуют со значения по умолчанию medм. Если задача относительно простая и нужна максимальная скорость, можно попробовать low. Если же задача очень сложная, многоходовая, критично точность, тогда использовать хай. Нужно подбирать оптимальный уровень для конкретной задачи. Экспериментировать. В общем.
Третий пункт. Третье. Структура промпта. Здесь было интересное наблюдение от Open AI. В их внутренних тестах часто наилучшие результаты показывали промты, которые были чётко структурированы с помощью XML-тегов. XML? Серьёзно? Типа инструкция. Инструкция. Пример пример. Да, именно так. Например, system prompt, user query, context data, output format. По их мнению, это помогает модели лучше разделять разные части промпта, где системные инструкции, где пользовательский запрос, где контекст, где требования к формату вывода. Любопытно. То есть старый добрый XML снова в деле. Возможно, но они подчеркнули, что это не догма. XML показал хорошие результаты у них, но стоит пробовать и другие форматы. Маркдаун с его заголовками и секциями. Джейсон или просто очень хорошо структурированный и логически разделённый текст. Главное — чёткая структура. Ясно.
Четвёртый совет. Четвёртое. Метапромптинг. Это интересный подход к исправлению ошибок. Вместо того, чтобы просто говорить модели: "Ты тут ошибся, исправь вот так", гораздо эффективнее сначала спросить у неё: "А почему ты решил сделать именно так? Какая была твоя логика?" То есть сначала заставить её отрефлексировать своё решение, да, понять её цепочку мыслей, которая теперь доступна через reasoning items, а потом уже, поняв, где произошёл сбой в логике, просить исправить, возможно, даже ссылаясь на её же объяснение. Вот ты сказал, что сделал так потому-то, но это неверно, потому что, пожалуйста, переделай с учётом этого. Хмм, это похоже на то, как учат людей не просто давать правильный ответ, а объяснять, почему предыдущий был неправильным. Именно по утверждению Open AI, такой подход ведёт к более надёжным и осмысленным исправлениям со стороны модели. Интересно.
Пятый пункт. Пятое. Планирование. Для сложных, особенно агентных задач, очень полезно явно просить модель сначала составить план действий, прежде чем она начнёт их выполнять, чтобы она сначала подумала, а потом делала. Да. В демонстрации кодекса инструменты для работы с кодом показывали, как модель сначала генерирует чек-лист шагов, которые она собирается предпринять для решения задачи. Например, один прочитать файл X. 2 найти нужные данные 3 выполнить расчёт Y 4 записать результат в файл Z и пользователь может посмотреть этот план и если что скорректировать его вот именно это позволяет поймать ошибки или недопонимания на самом раннем этапе до того как модель начнёт выполнять потенциально неверные или ненужные действия улучшает и результат и эффективность. Логично.
И последний, шестой совет. Шестое. Контроль агентичности. Нужно найти правильный баланс между тем, насколько автономно модель должна действовать, и где требуется вмешательство или подтверждение со стороны пользователя. То есть не всегда нужно, чтобы она сама всё решала от начала до конца. Не всегда. Иногда тебе нужно, чтобы модель работала максимально самостоятельно, выполнила все шаги без остановок. Для этого есть параметр persistance, который заставляет её идти до конца. А иногда, наоборот, ты хочешь, чтобы она после каждого важного шага или при возникновении неопределённости спрашивала у тебя подтверждение или уточнения. И как это регулировать? Это можно делать разными способами. Например, в задачах работы с кодом можно ограничивать глубину поиска Search Depth, чтобы модель не уходила слишком далеко в своих самостоятельных исследованиях репозитория. Или можно прямо в промпте указать после шага X, перед тем, как делать Y, спроси у меня подтверждение. То есть гибко настраивать уровень автономии. Понятно? В общем,
Промтинг для GPT-5 - это целое искусство, требующее точности, структурированности и понимания того, как модель думает. Да, это уже не просто написание текста, а скорее проектирование взаимодействия. И чтобы проиллюстрировать, каких результатов можно добиться, если освоить это искусство, на сессии был показан очень впечатляющий кейс стартап Чарли Лабс.
Да, Райли Гудсает, основатель Чарли Лабс, поделился их опытом. Они создали автономного агента для помощи разработчикам на Typeesрипt. И всё это на базе GPT-5. Автономного агента. Звучит громко, что он умеет делать.
Что особенно показательно и круто в их подходе, они не стали делать какой-то отдельный интерфейс для своего агента. Они интегрировали его в те инструменты, которыми разработчики и так пользуются каждый день. То есть то есть взаимодействие с агентом происходит через GitHub для работы с кодом и репозиториями, через линер, популярный трекер задач и через слаг для общения. Ничего себе.
То есть разработчик может просто написать в слаг что-то вроде: "Эй, Чарли, найди и исправь баги вот в этом пулреквесте". Или рефакторни вот этот компонент, чтобы он использовал наш новый UI Kit. Именно так. Агент получает эту задачу из Slag или Linear. Анализирует её с помощью GPT-5, планирует шаги, взаимодействует с репозиторием на GitHub через API, генерирует код или правки, опять же использует GPT-5, и отсчитывается о результате в том же Слак или обновляет тикет в Linнер.
Вау, это уже похоже на научную фантастику. А как они решили проблему редактирования кода? Ведь просить модель переписать целый большой файл - это рискованно и неэффективно. Вот это как раз был один из ключевых моментов их доклада. Они активно используют инструмент, который назвали Apply Patch. Вместо того, чтобы просить GPT-5 сгенерировать весь новый файл, они просят её сгенерировать патч в стандартном формате div. Патч, то есть только строки, которые нужно изменить, добавить или удалить. Да, оказалось, что GPT-5 отлично справляется с задачей генерации таких патчей по описанию требуемых изменений, а потом этот патч уже можно безопасно и эффективно применить к существующему коду с помощью стандартных утилит. Это гораздо надёжнее, чем полная перезапись файла, особенно для больших и сложных кодовых баз. Хитрое и элегантное решение.
И какие результаты? Насколько этот Чарли эффективен на практике? Ведь это самое главное. Работает ли оно? Результаты, которыми они поделились, действительно впечатляют. Они провели внутреннее тестирование на задачи, симулирующие создание реального пулреквеста с написанием кода тестов описания. И что получилось? Их агент на G5T5 после того, как они тщательно оптимизировали промпты и всю систему, показал прирост производительности на 29% по сравнению с последней на тот момент версией GPT4 от 6 августа двадцать четго года. На 29%. Это же огромный скачок. Да, это очень существенно.
Но это ещё не всё. Они также провели прямое сравнение head to headad со считающимся очень сильным конкурентом в области кодинга моделью Cloud CД от Anтроopic. И как прошло сравнение, агент Чарли на GPT5 выиграл все 10 раундов. Качество сгенерированного кода, тестов и описании пулреквестов оценивалось с помощью другой LLM, выступавшей в роли беспристрастного судьи. 10:0 в пользу GPT5 в такой сложной задаче- это очень сильное заявление. Невероятно. Это действительно мощная демонстрация потенциала GPT5.
Но тут же возникает вопрос: "Какой? Это ведь их внутренний тест, пусть и на реальных задачах. И сравнение с Клод, оцененное другой LЛM. Насколько легко такой результат можно перенести на другие проекты, другие команды? Не кроется ли здесь львиная доля успеха именно в инженерной магии самой команды Чарли Лапс, в их промтах, в их инструменте Apply Patch? Ты совершенно прав. Безусловно, инженерная работа команды Чарли Лабс играет колоссальную роль. Создание таких автономных агентов - это далеко не просто подключение к Open Api и написание одного промпта. Это сложная система.
Что в неё входит? продуманная архитектура, управление состоянием диалога и задачи, механизмы обработки ошибок и неоднозначностей, интеграция с внешними системами, мониторинг и, конечно же, итеративно выверенные очень специфичные промпты для каждого шага. Так что да, это не магия из коробки, которую любой может легко повторить за 5 минут. Это результат серьёзной R& и инженерной работы. То есть GPT5 - это мощный двигатель, но чтобы построить на его базе гоночный балид, вроде Чарли, нужны ещё и очень умелые инженеры и механики. Отличная аналогия. Именно так. Но сам факт, что этот двигатель GPT5 позволяет достичь такого уровня автоматизации и такого качества результата, как показало сравнение с Cloud, это уже огромный шаг вперёд по сравнению с предыдущими поколениями моделей. Он открывает возможности, которых раньше просто не было. Согласен. Потенциал огромен, но требует умелых рук.
Хорошо. Это впечатляющий пример из настоящего. А что насчёт будущего? Куда OpenI планирует двигаться дальше? Что нового ждать от следующих отераций моделей? Эрик Райфлайш из исследовательской команды Open немного приоткрыл завесу тайны. Да, он обозначил несколько ключевых направлений, над которыми они активно работают.
Во-первых, это дальнейшее совершенствование в области веб-разработки. И тут интересный акцент. Какой? Цель не просто генерировать функционально работающий фронт-код. Цель - генерировать код, который создаёт эстетически приятный, продуманный, как они выразились, со вкусом сделанный пользовательский интерфейс и и с чувством прекрасного. Это амбициозно. Как они собираются этого достичь? Обучать на красивых сайтах, вероятно, да. Использовать большие датасеты с качественным дизайном, возможно, привлекать дизайнеров для разметки данных и оценки результатов. Это интересное направление. Переход от чистой функциональности к эстетике и пользовательскому опыту. И любопытно будет посмотреть, что из этого выйдет.
Что ещё. Во-вторых, большой фокус делается на итеративных циклах разработки. Идея в том, чтобы модели могли не просто написать код по ТЗ один раз, а что? А чтобы они могли самостоятельно его тестировать, например, запускать юнит-тесты или даже интеграционные тесты, анализировать результаты этих тестов, находить ошибки или несоответствие требованиям и затем итеративно улучшать, исправлять свой же код до тех пор, пока он не будет полностью соответствовать всем требованиям и проходить все тесты. То есть замкнуть цикл разработка тестирования отладка внутри самого Ии. Именно это позволило бы автоматизировать рутинные части процесса разработки ещё глубже. Модель могла бы сама доводить код до рабочего состояния. Звучит почти как мечта для многих разработчиков или кошмар, если подумать о будущем. Ну ладно, это отдельная тема.
Третье направление. Третье направление - это дальнейшее наращивание агентности, о которой мы уже много говорили. Способность выполнять ещё более долгие и сложные задачи. Не те, что занимают минуты или десятки минут, а те, которые могут длиться часы или даже дни. Дни. Что это за задачи такие могут быть? Ну, например, полный анализ большого проекта, проведение масштабного рефакторинга, миграции на новую технологию. Проведение глубокого исследования по какой-то теме с использованием множества источников и инструментов. Задачи, требующие долгосрочного планирования, сохранения контекста и адаптации на протерение длительного времени. И как этим управлять? Пользователь должен будет постоянно контролировать. Вот тут Эрик сослался на концепцию, которую продвигает Андрей Карпати, ползунок агентства Slider. Идея в том, чтобы у пользователя была возможность гибко настраивать уровень автономии модели для каждой конкретной задачи. Ползунок. То есть можно будет выбрать от делай только то, что я скажу и спрашивай на каждом шагу до вот тебе цель. Сделай всё сам и просто отчитайся о результате. Да, примерно так, чтобы можно было найти оптимальный баланс между контролем и делегированием для разных ситуаций, это позволило бы использовать мощь агентов безопасно и эффективно.
Все это рисует картину будущего, где ИИ становится всё более способным, автономным и интегрированным в наши рабочие процессы партнёром. Но чтобы такое будущее стало реальностью, Open AI явно нуждается в помощи и обратной связи от сообщества разработчиков. Абсолютно. И это был ещё один важный посыл всей сессии Build Hour. Представители Open AI, включая Билла Пиблса и Ану Парао, неоднократно и очень настойчиво призывали разработчиков, которые получат доступ к GPT5, делиться своими впечатлениями.
Что именно они просят? просят рассказывать о своих сценариях использования, где GPT5 показывает себя хорошо, где возникают проблемы, какие функции или возможности больше всего нужны, с какими трудностями при промптинге или использовании API они сталкиваются. То есть им нужен фидбэк по всем аспектам. Да, они даже предоставили специальную форму для сбора этой обратной связи. Это действительно очень важно, потому что развитие таких сложных систем, как GPT5 - это во многом итеративный процесс, диалог между создателями и пользователями. Реальные кейсы и отзывы помогают понять, что работает, что нет и куда нужно направить усилия и ресурсы в первую очередь, чтобы не получилось, что они разрабатывают что-то в вакууме, что потом окажется не совсем тем, что нужно рынку. Именно. Так что, если кто-то из слушателей получит доступ к GPT5, не ленитесь делиться своим опытом с Openi. Это в общих интересах. Согласен.
Итак, давай попробуем подвести черту под нашим сегодняшним глубоким погружением в материалы от GPT5. Что мы имеем в сухом остатке? Ну, во-первых, очевидно, что GPT5 - это значительный шаг вперёд. Не просто инкрементальное улучшение, а качественный скачок. Особенно это касается возможностей в области кодинга, как генерации, так и редактирования и даже создание UI.
Во-вторых, ключевой фокус на агентных задачах. Способность моделей планировать, использовать инструменты, рассуждать и самокорректироваться в рамках сложных многошаговых сценариев. Это, пожалуй, и главная фишка.
В-третьих, чтобы раскрыть этот потенциал, необходимо переходить на новые респонсы с API. Он предоставляет доступ к цепочке мыслей и модели через reasoning items, что критично для когерентности в длинных задачах.
И в-четвёртых меняется подход к промтингу. GPT5 требует большей точности, ясности, структурированности и непротиворечивости инструкции. Старые методы могут не сработать. Нужно учиться говорить с моделью на её новом, более буквальном языке. Да, все так. управляемость, совместная работа, агентность, фймреспонсы, API и точный промптинг. Вот, пожалуй, ключевые слова для понимания GPT5.
Отлично. И в завершении, как обычно, какая-то финальная мысль для наших слушателей, над которой стоит подумать после нашего обсуждения. Хмм, давай подумаем. Вот что мне кажется интересным. Мы много говорили о том, что GPT5 буквально следует инструкциям и может действовать почти автономно в рамках заданных целей и ограничений, особенно в агентных сценариях. Ну да, это её сильная сторона. А теперь давай представим, что это значит в более широком контексте. Какие совершенно новые формы сотрудничества человека и Ии это открывает? если и может не просто отвечать на вопросы или генерировать текст, а выполнять сложные задачи, требующие планирования, использования инструментов адаптации, не становится ли он, ну, скажем так, специфическим, но в каком-то смысле полноправным членом команды?
Членом команды ты имеешь в виду, что мы начнём делегировать ИИ не просто отдельные таски, а целые области ответственности. Возможно, по крайней мере, для определённых типов задач. Представь себе проектную команду, где есть люди-разработчики, люди-менее, люди-дизайнеры. И есть и агент, которому поручена, например, вся работа по рефакторингу или по написанию и поддержке юнит-тестов, или по мониторингу и первичному анализу данных. И этот агент не просто инструмент в руках человека, а сущность, которая сама планирует свою работу в рамках поставленной цели, сама взаимодействует с другими системами. Да. И как это может изменить наши привычные подходы к разработке ПО, к управлению проектами, к проведению исследований, даже к творческим процессам? Если вспомнить про генерацию UI со вкусом, возможно, мы стоим на пороге не просто появления улучшенных инструментов, а фундаментального изменения самой парадигмы совместной работы человека и машины. И и уже не просто помощник, а соработник, коллега. Коллега. Звучит немного пугающе, но и захватывающе одновременно. Действительно, есть над чем подумать. Какие новые роли, какие новые процессы, какие новые этические вопросы это пародит. Вот именно. Это открытое поле для размышления экспериментов. Отличный вопрос на подумать.
На этой ноте, я думаю, мы можем завершать наше сегодняшнее обсуждение. Получилось, как мне кажется, довольно подробно и глубоко. Надеюсь, было полезно. Уверен, что да. Напомню, что больше деталей, официальную документацию, примеры кода и ту самую форму для обратной связи можно найти на портале Openi для разработчиков developers.com. Спасибо, что были с нами сегодня, и до новых встреч. Всего доброго. M.