Всем привет! Меня зовут Дима. Я отвечаю за продуктовое развитие платформы AI Studio.
Привет! Меня зовут Золотов Сергей, я технический менеджер проектов Яндекс.АйСтудио.
Мы рады вас приветствовать на первом вебинаре в рамках серии Яндекс.АйСтудио для разработчиков.
Это наша летняя серия, где мы подробно рассказываем о разных аспектах, нюансах платформы AI Studio
именно для технической аудитории с техническими деталями.
Давайте для начала расскажу в целом про, что наша серия, что мы хотим вам рассказать, чем поделиться.
Она будет состоять из четырех вебинаров, посвященных разным кускам платформы.
Сегодня у нас первый вводный вебинар. Мы сделаем фокус на работе с так называемыми агентскими API.
То есть поговорим о том, как вообще можно подходить к разработке агентов на базе AI Studio,
как использовать инструменты и основной фокус будет на двух темах. Первая - это работа с
контекстом. В комьюнити вы задавали много вопросов, был запрос на вебинар, чтобы мы рассказали,
как можно управлять контекстом, как использовать его в разных API. Этому будет посвящен сегодня
вебинар и мы поговорим про инструменты мониторинга, которые появились в AI Studio. То есть мы расскажем
про основные обновления вокруг Responses API. 21 июля будет вебинар, посвященный голосовым агентам,
то есть если вы уже знакомы с нашими компонентами, это все вокруг Real-Time API. Дальше 23 июля мы
подробно поговорим про поисковые сценарии, то есть про использование и построение рага,
про использование веб-поиска и те улучшения, которые произошли в этих компонентах. И 28 июля у нас
будет вебинар про автоматизацию процессов. Мы поговорим про процессы и выстраивание
автоматизации процессов на базе инструмента Workflows без написания кода, то есть нашего
визуального инструмента. Там произошло большое количество обновлений, направленных на
упрощение работы с инструментом, и про них мы, конечно, тоже подробно расскажем. Для того,
чтобы вы могли как бы немного закрепить те знания и понять, насколько вообще понятны основные
концепции. После каждого вебинара мы подготовили тест. Ссылкой к QR-коду мы поделимся в конце вебинара.
И в завершение этой серии, 30 июля, у нас будет фестиваль решений. На самом деле,
там будет много различных интересных докладов. Мы будем рассказывать про архитектурные детали,
различных подходов к построению агентов текстовых, голосовых. У нас
будет отдельный мастер-класс от наших архитекторов Яндекс Клауд, где они расскажут про лучшие
подходы к проектированию продуктов и возможные ошибки, которые могут возникать. И отдельно,
в рамках этой серии вебинаров, мы запускаем отдельный челлендж для разработчиков. Вы можете
отсканировать QR-код, перейти по ссылке и оставить свою заявку. Заявки вам нужно будет
описать проект и цели, для какой аудитории вы делаете этот проект. Мы уже начали
отсматривать ваши заявки, их уже пришло довольно много, спасибо большое за отклик. И ближе к концу
недели мы начнем возвращаться с ответами, мы отберем самые интересные заявки и дальше в течение
восьми недель мы будем участвовать в разработке запуска и решений, то есть с консультацией экспертов
и экспертов от Яндекс Клауд вы сможете собрать свое решение для решения вашей задачи, для реализации
вашего проекта, который вы опишите в форме, то есть серия вебинаров и фестиваль решений
это как раз такие подготовительные этапы, где мы расскажем детально про технологию и дальше вы уже сможете
применить эту технологию в действии с нашими консультациями, с нашей помощью.
Что ж, давайте переходить непосредственно к материалу сегодняшнего вебинара.
Единственное, еще напомню, что по ходу вебинара вы можете задавать вопросы,
мы ответим на них в конце вебинара, поэтому если вам что-то непонятно,
нужно лучше объяснить, не стесняйтесь, задавайте вопросы, будем рады на них в конце ответить.
Так как это уже вторая такая серия для разработчиков,
первая была в ноябре, мы не будем останавливаться подробно на обзоре iStudio,
что в ней возможно делать, если вам хочется,
если вы только первый раз вообще узнали про iStudio,
хотите разобраться, как начать с ней работать,
мы в сообществе поделимся отдельным набором ссылок на предыдущую серию,
где мы рассматривали такие стартовые моменты вокруг начала работы с iStudio.
Сегодня мы уже углубимся в детали вокруг работы с платформой.
Но коротко напомню, что iStudio для разработки текстовых агентов
можно разбить примерно на три слоя.
То есть первый слой — это слой API.
Основной функционал, основное взаимодействие с компонентами платформы
у нас возможен через API.
Здесь стоит сказать про три ключевых API, которые доступны для работы.
Первый — это Responses API.
Это наш рекомендованный API для работы с моделями,
для текстовых сценариев, текстовых агентов.
Вокруг него сейчас происходит основное развитие подтекстового сценария.
И если вы, например, хотите собирать каких-то агентов,
строить рак-сценарий, строить работу с веб-поиском,
то это рекомендованный API.
Если у вас голосовой сценарий, где требуется очень высокая скорость ответа,
то есть низкая задержка между тем, как вы закончили говорить,
и робот или агент начал отвечать,
то мы рекомендуем использовать real-time API,
как раз оптимизированный под голосовые сценарии
со своими специфическими концепциями.
Мы про них поговорим на другом вебинаре.
И chat completions API.
Это API для взаимодействия просто с моделью,
то есть запрос в модель и ответ от модели.
Его удобно использовать, например,
если вы работаете с какими-то open-source фреймворками,
не знаю, LongChain, LongGraph, Nathan, OpenWebUI, еще что-то.
Вы можете, все они поддерживают chat completions API,
и вы можете очень легко интегрировать модель и iStudio в эти фреймворки.
Тут еще, наверное, стоит сказать, что и responses, и real-time, и chat completions,
они совместимы с форматом API OpenAI, и, соответственно, большая часть
опенсорсных фреймворков поддерживает, так или иначе, все эти три API.
Дальше, опускаясь чуть ниже, кроме самой модели, мы предоставляем набор
готовых компонентов в платформе, которые позволяют реализовать
широкий набор сценариев.
Эти компоненты работают все с responses API, часть работает с real-time API,
но в чат completions, как я сказал, это только запрос модель и получение ответа.
То есть, если вам необходимо использование встроенных компонентов,
встроенных инструментов, то необходимо использовать responses API.
Из встроенных компонентов это файл-серч или векторные базы
для реализации сценария рага, поиска по базам и веб-серч для поиска в интернете.
Про поисковый сценарий мы будем говорить на отдельном вебинаре.
Конечно же, MCP для взаимодействия с внешними системами,
для выполнения действий во внешних системах.
Инструмент для генерации изображений,
то есть когда агенту необходимо сгенерировать изображение,
он может вызывать этот инструмент и возвращать пользователю картинку.
И инструмент интерпретации кода, когда модель пишет код,
этот код автоматически выполняется в изолированном контейнере,
возвращает результат, и затем пользователь получает, например,
сгенерированную презентацию, сгенерированный файл и так далее.
И есть ряд еще дополнительных API, на них мы не будем сегодня останавливаться.
Это API для каких-то конкретных узких задач,
например, API для генерации векторов,
API для получения генерации изображений, если это нужно не в агенте,
а вот просто отправить запрос, получить генерированное изображение.
Или отдельное API для классификации текстов, такое тоже есть,
вы его можете использовать, подробнее почитать о нем в документации.
Дальше часто встает вопрос, а какой API мне вообще использовать для решения моей задачи.
Давайте чуть подробнее остановимся, если вы первый раз открываете документацию,
наверное, можно запутаться, да, большое количество разных API,
но давайте попробуем определить, какие нужны под какие задачи.
Как я уже говорил ранее, Responses API — это основной агентский API.
Если у вас есть задачи, например, вокруг рага, автоматического вызова функции и так далее,
то мы рекомендуем использовать Responses API.
На самом деле, просто для работы с моделью, отправить запрос, получить ответ,
он тоже подходит, то есть без подключения от улов, по сути, он решает эту задачу.
Если у вас есть необходимость использовать структурированный вывод,
то есть когда вы описываете схему и дальше ожидаете ответа в этой схеме,
то со Structured Output можно использовать как Responses, так и Chat Completions API.
Они оба поддерживают этот функционал.
Real-time API хорошо подходит для голосовых сценариев, то есть если у вас текст Responses, если голос, то real-time.
Chat Completions удобен в сценариях, где необходим просто запрос в модель,
например, сделать суммаризацию, проанализировать отзыв,
либо чаще всего интеграция с внешними фреймворками, они все поддерживают этот формат API.
Дальше есть отдельный набор API вокруг работы с файлами.
Они нужны, например, когда нам необходимо загрузить файлы в векторный индекс, векторное хранилище,
либо наоборот, например, интерпретарь кода сгенерировал какой-то файл, и его нужно забрать.
Это также можно сделать через файл с API, то есть это API для работы с файлами внутри платформы iStudio.
VectorStores — это основной API для построения баз знаний, то есть вы загружаете файлы, они автоматически парсятся,
складываются в векторный индекс и дальше могут использоваться из агента для получения информации,
для поиска информации. То есть для работы с файлами у нас files и VectorStores API.
Далее, если вы, например, самостоятельно строите сценарий по Raga, у вас какая-то своя кастомная логика,
вы можете использовать embedding с API для получения векторов, либо, опять же, использовать генерацию изображений
с помощью отдельной API обращения к Alice AI Art.
Еще один API, про который мы ранее подробно не рассказывали, но также можно его использовать,
это API для работы с MCP.
В рамках платформы Studio есть такой компонент, который называется MCP Hub.
По сути, он позволяет подключать внешние MCP-сервера платформу
или создавать свои собственные поверх существующих API-систем.
И вот, взаимодействовать с этим MCP-хабом можно как в интерфейсе, так и через API, например, для автоматизации каких-то задач,
для автоматизации добавления MCP в MCP-хаб.
Я уже несколько раз упомянул интеграцию с различными подсорс-инструментами,
и на самом деле мы специально делали API OpenAI совместимыми,
чтобы без каких-то проблем можно было работать с различными open-source инструментами.
И недавно мы подготовили серию так называемых how-to,
обучающих, коротких обучающих вебинаров,
где мы рассказываем, как настроить подключение к компонентам MyAstudio
из различных open-source фреймворков, решений Nathan, OpenClaw, WebUI и так далее.
Поэтому, если у вас есть интерес использовать какое-то из этих решений вместе с MyAstudio,
сканируйте QR-код, переходите и настраивайте подключение.
Когда мы говорим про начало работы, создание агента, тестирование и так далее,
то самый первый простой способ входа в платформу, начало работы,
это попробовать собрать агента в UI.
Выглядит это следующим образом.
В интерфейсе вы можете выбрать модель, можете выбрать инструкцию, указать инструкцию,
подключить необходимые инструменты, MCP, веб-поиск, файловый поиск и так далее,
там нажать «Сохранить» и потестировать этого агента в интерфейсе.
Тут важно сказать, что интерфейс в iStudio — это компонент для первичного тестирования,
отладки, подбора промта и подбора хорошей конфигурации вашего агента.
И дальше вы можете нажать кнопку «Посмотреть код» и получить непосредственно код
для обращения уже в этого агента, чтобы встроить его в вашу систему,
в ваше приложение, из которого будет происходить запрос.
Когда происходит сохранение вот этой конфигурации в интерфейсе,
то появляется такая сущность, как PromptID, или в интерфейсе это называется AgentID,
в API это PromptID, то есть это ID вашей конфигурации,
вы передаете ее при обращении в Responses Create в поле PromptID,
и дальше вы, по сути, обращаетесь к этой конфигурации, которую вы настроили в интерфейсе,
то есть инструкция, подключенные тулы и так далее, все эти настройки, они сохраняются,
и вам не нужно при каждом запросе в Responses их указывать и передавать.
Вот создание такого PromptID или агента возможно только через интерфейс.
Если вы сразу начинаете работать через API,
то здесь вам необходимо при каждом запросе в Responses
передавать описание параметров, которые влияют на работу моделей,
на подключенные инструменты и так далее.
Давайте посмотрим на самый простой пример,
как выглядит обращение в Responses.
Здесь у нас указываются пять параметров, то есть сама модель.
В AI-студии доступны различные модели.
Это модели от Яндекса, это опенсорсные модели.
Сразу тут, наверное, стоит обратить внимание,
что для сценариев, где происходит работа с инструментами,
то есть вызов различных инструментов, поиска информации по файлам в интернете,
мы рекомендуем использовать модели вроде DeepSig Flash или Quen 3.6.
Они лучше всего работают именно с вызовом инструментов.
Далее мы в качестве инпута передаем пользовательский запрос.
Это то, что передает пользователь при обращении.
И дальше мы описываем подключенные инструменты.
В этом примере это подключенный инструмент веб-поиска с ограничением по доменам,
то есть по тем сайтам, доменам, по которым можно искать.
И там дальше есть параметр контекста,
то есть какое количество информации со страниц будет использоваться
в качестве контекста для самой модели по результатам поиска в интернете.
Здесь еще, наверное, хотелось бы отметить,
что у нас совсем недавно произошло обновление инструмента веб-поиска.
Про это обновление, именно про его детали мы расскажем на отдельном вебинаре,
но если вы ранее пользовались веб-поиском,
какие-то запросы у вас отрабатывали недостаточно хорошо,
рекомендуем попробовать еще раз.
Сейчас качество значительно выросло,
при этом количество потребляемых токенов
после веб-поиска значительно снизилось
за счет оптимизации работы инструмента.
Много, на самом деле, различных параметров,
которыми можно управлять в Responses API.
Давайте их попробуем сгруппировать в 4 блока.
Первый блок параметров связан непосредственно с самой моделью.
То есть это выбор модели, в которой будет происходить обращение.
Это инструкция, то есть это системный промпт, который описывает поведение условно агента,
его задает разработчик этого агента.
И дальше input — это пользовательский ввод, который передается уже агенту, чтобы он выполнил какую-то задачу.
Дальше есть набор параметров вокруг самой генерации, которые управляют генерацией модели.
Это температура, это максимальное количество токенов, которые будут возвращаться на выходе.
Это режим рассуждений. Тут важно оговориться, что режим рассуждений работает не для всех моделей.
То есть тут важно проверить документации или, например, в интерфейсе в Model Hub, какие модели поддерживают рассуждения.
И stream — это параметр, который регулирует, каким образом возвращаются токены.
То есть генерируется ли ответ сразу весь и возвращается пользователю как весь ответ.
Либо ответ стримится, то есть возвращается такими фрагментами.
Дальше блок параметров вокруг инструментов.
Какие инструменты доступны агенту для использования.
Максимальное количество вызовов инструмента.
И дополнительно, если у вас есть необходимость использовать не встроенные инструменты в iStudio,
а подключить какую-то свою логику функций.
Также доступно можно указать через параметры Function Calling.
И формат ответа.
Здесь на самом деле будет фокус вебинара.
Мы поговорим про параметры Previous Response ID и Store подробнее дальше,
поэтому пока на них не буду фокусироваться.
Вот, этот слайд, наверное, такой вспомогательный.
Не буду прям совсем подробно на нем останавливаться.
Это, скорее, такая памятка, на какие параметры стоит обращать внимание при разработке.
Наверное, тут ключевая колонка — это когда менять.
И, как правило, когда вы начинаете разрабатывать агента,
конечно, первое, что важно протестить — это модель.
Какую модель выбрать?
Опять же, тут, наверное, мы рекомендуем начинать с моделей вроде DeepSeek Flash,
так как они хорошо работают с большим количеством инструментов.
Дальше, если у вас, например, есть необходимость, чтобы ответы были быстрее,
или наоборот, не знаю, сценарий какой-то, не требующий инструментов,
то можно попробовать модели вроде Alice iFlash или Kvinov поменьше и так далее.
Инструкция и input — это параметры, которые влияют на то, как будет себя вести агент,
то есть его системный промпт, что ему нужно делать, какие шаги выполнять,
и input — это пользовательский ввод.
Параметр температура, на самом деле, если вы смотрели наши вебинары раньше,
особенно в самом начале, не знаю, пару лет назад и так далее,
мы обычно говорили, что температура, она отвечает за креативность модели,
она находится в диапазоне между 0 и 1.
На самом деле, сейчас это немного поменялось, и новые модели могут требовать значения температуры выше,
и эти значения могут сильно отличаться от модели к модели.
Например, тут такой совет, что если вы работаете с моделью QN3.6,
то мы рекомендуем ее тестировать на высоких температурах, то есть 1 и выше,
то есть я бы даже сказал, что скорее 1 это минимальная температура,
с которой мы рекомендуем тестирование модели QN3.6.
Что касается MaxOutputToken, это параметр, который регулирует максимальный размер контекста,
то есть, когда вы его задаете, вы гарантированно знаете,
что в ответе не будет больше, чем такое количество токенов.
С этим параметром нужно быть осторожным,
потому что может происходить ситуация, что это просто грубое обрезание.
То есть, что модель, например, не поместила свой ответ в эти 200 токенов,
которые вы указали, и часть токенов просто обрезалась.
Это может сильно повлиять на пользовательский опыт.
Поэтому с этим параметром стоит быть осторожным.
Ну, про инструменты мы уже поговорили.
Еще, наверное, такой важный нюанс — это про формат ответа.
То есть, вы можете, когда обращаетесь в Responsys, указать структуру JSON,
в которой должен содержаться ответ.
И тут важно проговорить, что здесь есть ограничения в Responsys,
что либо в ответ возвращается ответ по этой структуре JSON,
либо вы используете Responsys как инструмент, который вызывает различные инструменты.
То есть, например, вы не можете сделать обращение в Responsys
и одновременно указать и инструмент поиска по файлам,
и строгую JSON-схему, в которую нужно этот ответ вернуть.
То есть, возможно, либо так, либо иначе.
Одновременно это приведет к ошибке и работать не будет.
Вот, previous response ID и store — это два параметра,
которые нужны нам для реализации сценарий чатовых.
То есть, responses API умеет автоматически работать с контекстом,
сохранять сообщения, предыдущие сообщения, всю историю сообщений,
выстраивать как бы дерево общения,
и дальше использовать эту информацию из контекста
для ответа на вопросы пользователей.
Итак, у нас есть API, есть параметры,
давайте посмотрим детальнее, когда что выбрать.
Если у вас какое-то разовое обращение,
отправили запрос, длинный текст, документ,
сделай суммаризацию, классифицируй отзыв, еще что-то.
Одноразовая задача, responses API с параметром store равно false,
то есть чтобы не сохранять это сообщение,
оно нам не понадобится для чата, для контекста,
то есть вы обращаетесь в responses, говорите store равно false,
либо можете использовать компрещен с API,
там параметра store нет, он ничего сам по себе не сохраняет,
поэтому можно использовать его.
Если это чатовый сценарий, вам необходимо указать store равно true,
это дефолтное значение для параметра store в responses API,
оно как раз используется, вам нужно для чатовых сценарий,
то есть когда происходит обращение с этим параметром,
запрос и ответ сохраняются,
и затем используется для того, чтобы отвечать на следующие сообщения
с учетом контекста, с учетом истории переписки.
И если у вас агентский цикл, в котором много вызовов инструментов,
этот агентский цикл реализует сам responses API,
если вам нужно, чтобы он автоматически вызывал инструменты,
вы обращаетесь в responses с подключенным параметром tool,
которым вы можете задать либо инструменты,
которые доступны в платформе, как бы уже готовые,
либо подключить свои функции, если есть такая необходимость.
Давайте теперь более подробно углубимся в работу с контекстом в responses API.
Если нет необходимости как-то управлять контекстом,
то можно использовать completions,
там нет никакого автоматического сохранения контекста,
всю обвязку, всю внешнюю логику передачи предыдущих сообщений,
передачи вызовов, тулов и так далее, вам необходимо реализовать самостоятельно.
Как правило, какая-то уже реализация есть во фреймворках типа лангграфа, лангчейн и так далее,
но это то, что происходит не на стороне самой студии.
В Responsys API как раз его ключевое отличие, во-первых, что он может хранить эту историю переписки,
использовать ее и, как мы увидим дальше, работать с этой историей для оптимизации,
например, использования токенов или для минимизации ошибок вроде переполнения контекста модели.
Далее у нас есть развилка.
Если параметр store установлен на false, то, опять же, запросы не хранятся, никакой чатовый сценарий из коробки невозможно.
Если store равно true, то запросы и респонсы сохраняются, и вам становится доступен контекст сессии.
Дальше встает вопрос, а как этим контекстом сессии можно воспользоваться?
И здесь доступны два варианта.
Это вариант использовать параметр previous response id, либо использовать отдельный API, conversations API, для создания управления сессиями, и использовать эту сессию, которая создается через conversations API.
Давайте посмотрим на базовые различия.
По сути, conversations API — это отдельный объект сессии, который вы эксплицитно создаете, указываете при обращении в responses, и в этот conversation добавляются новые сущности.
То есть все общение, все запросы, ответы, информация талаг добавляются в этот conversation.
Соответственно, вы можете его создавать, удалять, добавлять какие-то свои текстовые, или, например, вы хотите выгрузить всю историю, саморизировать ее самостоятельно каким-то образом и загрузить обратно в виде одного сообщения.
Все это удобно сделать в conversations API, то есть он это все позволяет сделать.
Previous response ID немножко по-другому работает.
Здесь это выглядит следующим образом: вы делаете запрос в responses, в ответ вы получаете response, который будет содержать какой-то ID.
При следующем обращении в responses вы можете передать параметр previous response ID и там должно быть значение как бы ID предыдущего ответа, то есть ID предыдущего response.
Вот, соответственно, в этом случае он автоматически, response API автоматически подтягивает предыдущий запрос и все остальные запросы, которые как бы выстраиваются по цепочке, да, и использует их, передает в контекст модели, и модель отвечает с учетом вот этой всей истории и всего этого контекста.
То есть и в Conversations, и в PreviousResponseId подтягивается весь контекст, передается в модель, как входные токены или там кэш-токены, если история закэшировалась, и, соответственно, дальше генерируется ответ.
Да, давайте подробнее посмотрим, как это выглядит через код и как выглядят результаты.
Спасибо.
Итак, вот у нас есть пример кода, в котором как раз реализовано создание, использование цепочки респонсов через ID предыдущего респонса.
То есть, вот в ячейке четвертый у нас первый респонс, в котором мы делаем какой-то запрос.
В следующей ячейке мы делаем запрос, который, ну, по идее, должен учитывать контекст предыдущий.
Ну, давайте посмотрим, как это работает.
Выполним ячейки.
Вот у нас выполнился первый запрос.
И выполнился второй.
Ну, и вот во втором у нас был контекст из первого.
Видим, что все передалось.
У нас в UI, в интерфейсе AI-студию, появилась возможность просмотра вот этих сохраненных диалогов, которые есть.
То есть в разделе логирование есть список диалогов, и там есть раздел «Перейти к респонсам».
Давайте посмотрим как раз респонсы, которые были, и вот последний, который было исполнение.
Вот здесь можно посмотреть, как оно шло со всеми параметрами, ответами.
И здесь же есть, можно посмотреть, как это выглядит уже отрендерено в красивом виде.
И, собственно, есть как раз ссылочка на предыдущий идентификатор.
Можно прийти к предыдущему запросу, к предыдущему респонсу, и там увидеть все то же самое.
Теперь давайте посмотрим, как работает, когда мы используем вариант с conversation.
Conversation, как уже частично сказал Дима, тут я чуть-чуть дорасскажу.
То есть, создавая объект conversation, мы туда можем сразу занести какой-то...
Во-первых, там сохраняется контекст переписки, плюс мы можем заранее, ну или во время работы,
занести туда контекст, записав прямо как один из элементов.
В данном случае здесь вот как бы контекст, который... запомни контекст этого диалога.
Вот. Также в conversations API есть способы посмотреть, какой контекст там есть,
обновить этот контекст, ну и удалить весь объект conversation.
Давайте посмотрим, как это работает.
Опять же, пример кода.
У нас в одной ячейке создается conversation.
Туда записывается какой-то контекст.
Меня зовут Сергей, кто я?
И тут же указание, что мы говорим об Яндексе iStudio.
И дальше мы делаем обращение в response API с указанием ID этого conversation.
Давайте посмотрим, как это работает.
Вот нам выдалось ID conversation, оно перебылось в следующую ячейку.
Вот оно исполнилось. Как видите, весь контекст есть.
Соответственно, ответ уже был на основе этого контекста.
И давайте тоже посмотрим, как это выглядит в UI.
В списке диалогов есть отдельно конверсейшены.
Вот наш последний конверсейшен.
Здесь видны все запросы и первоначально то, что мы указывали при создании конверсейшена.
И тут же можно увидеть ID конверсейшена.
И, как видите, в каждой строчке еще есть ссылочка на переход.
Можно прямо перейти в конкретный респонс, который в этот конверсейшен входит.
Давайте еще расскажу про такую функциональность.
iStudio позволяет автоматически обрезать контекст для того,
чтобы избежать переполнения контекста той или иной модели.
В респонсе с API есть такой параметр Truncation.
Если его выставить в значение авто, то включится вот это автоматическое обрезание.
При этом нужно учитывать, что мы обрезаем самые старые части контекста,
но системная инструкция и объявление инструментов остается неизменным.
Еще нужно учесть такую вещь, что при вырезании мы удаляем,
если там были инструменты как вызов инструмента, так и его ответ.
Еще важное замечание, что для скорости мы примерно оцениваем сколько будет занимать запрос.
Возможно, в некоторых случаях чуть-чуть неправильный расчет,
поэтому нет стопроцентной гарантии, что при включении авто мы точно попадем в контекст.
Это очень сильно повышает вероятность, что это будет все хорошо.
Что еще тут нужно отметить, что при включении обрезания контекста возможно влияние на кэширование.
Но про кэширование я расскажу чуть позже.
В AI-студии в некоторых моделях поддерживается кэширование.
Кэширование срабатывает автоматически.
Как оно работает в начале запроса?
Повторяющаяся часть промта, если есть такая возможность,
оно кэшируется.
Гарантии, что точно попадет в кэш, дать никто не может.
Оно может сработать, может нет.
И почему я, когда я рассказал про Truncation,
сказал, что очень важно обратить внимание на кэширование.
Так как отрезается самая старая часть, то получается, что начальный повторяющийся кусок запроса будет меняться.
Поэтому использование Truncation ухудшает кэшируемость.
Как повысить вероятность того, что кэширование сработает?
Во-первых, старайтесь как можно больше заносить часть запроса в системные инструкции.
Потому что они в начале, как и объявление инструментов.
Поэтому они будут повторяться при каждом запросе.
Поэтому лучше, чтобы там было занесено.
Когда пишете промт, тестируйте попадание в кэш.
То есть делайте достаточно большое количество запросов и смотрите, как оно отрабатывает.
Ну и вообще, что попало в кэш, что нет.
Можно оценить как по биллингу, потому что токены закэшированы.
Они билятся по отдельному СКЮ, их видно.
Так, и в разделе «Мониторинг», я чуть-чуть позже расскажу подробнее про него,
в нем тоже можно увидеть кэшированный токен.
Давайте еще расскажу про хранение запросов в Яндекс.АйС.Тудио.
Там достаточно часто и много поступает вопросов, как это работает.
Итак, смотрите, какие данные хранятся.
Во-первых, хранится в каком-то виде кэш.
Он хранится в уже вычисленном виде.
Фактически это матрица с вычисленными цифрами.
Она хранится на виртуальных машинах самого инференса.
Фактически в состоянии вычисленной модели.
Там нет ни текста запроса, восстановлению это не подлежит.
Это чисто техническое такое хранение.
Дальше, если мы используем Conversations API,
то сам Conversation и все респонсы, которые к нему привязаны,
они хранятся в течение 365 дней
или пока вы сами с помощью API или с помощью UI не удалите этот Conversation.
Ну и все, что с ним связано.
В Responses API, опять же, Дима рассказывал про параметр Store.
Как бы, если он в течение fails, то удаляется сразу.
Если true, то данные хранятся 30 дней.
Или, опять же, вы можете с помощью API или с помощью UI
удалить респонс, когда вам это будет удобно.
Важное замечание, что при указании StoreFiles запрос не сохраняется,
но при этом и построение контекста диалога невозможно.
Просто учитывайте это.
Тут ничего не хранится, но и функциональность будет сильно вырезана.
Чем вы можете управлять при использовании наших API?
Истории сессий, истории диалогов с помощью Conversation API и Responses API.
Вы можете создавать, редактировать, удалять.
Данные в поисковых индексах с помощью VectorStore API.
Соответственно, тоже вы можете ими управлять.
Файлы files API.
То есть то, что вы закачиваете, удаляете эти файлы.
Файлы, которые получаются с помощью работы инструментов.
То есть при работе код-интерпретёра, генерации картинок.
Создаются какие-то файлы, они тоже складываются в хранилище.
Ими можно управлять с помощью того же самого files API.
Ещё тема, про которую тоже достаточно часто спрашивают.
Какие виды логирования в Яндексе iStudio существуют и что каждый из них делает, что сохранится в этих логах.
У нас есть аудитные логи.
Все события, которые происходят при работе с iStudio, они сохраняются как раз как аудитные события.
И если вам необходимо для расследований или просто для анализа, вы можете с помощью сервиса Яндекс.Аудит.Трейлс настроить выгрузку в трейл и дальше как-то обрабатывать эти события.
Список событий, которые туда откладываются, есть в нашей документации.
Есть логи сервиса, то есть сервис, когда работает, он сохраняет какие-то логи, которые позволяют нам анализировать, как работает сервис, его здоровье, ну и как-то диагностировать то, что какие-то там происходят аномалии, неполадки при работе.
Информация, как бы, это недоступно пользователям где-то в интерфейсе или по API, но при расследовании каких-то инцидентов, которые произошли у вас, вы можете запросить технической поддержки, и мы ту часть логов, которая касается ваших ресурсов, вашей работы, сможем так предоставить.
Отмечу, что ни аудитные логи, ни логи сервиса не содержат никаких данных, запросов, ответов и какой-либо информации.
И вот совсем недавно у нас появился в разделе логирования трейсы, это делается с помощью сервиса Monium, Яндекс.Аи.Студия при работе с Completions API и с Responses API,
туда отправляет логи запросов и ответов, которые можно использовать для мониторинга работы, для оценки качества и для какого-то дебанга.
Давайте я расскажу как раз про этот компонент трейсинг чуть больше.
Мы записали небольшое видео, демонстрирующее.
Вот у меня создан какой-то агент, я сделаю несколько запросов в него.
В данный момент у меня срабатывают инструменты, которые MCP подключены.
Вот получил какой-то ответ.
Тут у нас есть иконочка, которая открывает закладку мониторинга и трейсов.
Прямо здесь я могу увидеть всю цепочку, которая была, вызовов модели, вызовов инструменты, с какими параметрами, что было в ответе.
Также в разделе логирования есть закладка трейсы, там можно увидеть то же самое, но уже по всем агентам.
В агенте я вижу именно относительно него, здесь я вижу список всех и точно так же могу просматривать.
Функциональность трейсов, она по умолчанию выключена, чтобы она заработала, вам нужно перейти в раздел логирования и на плитке с трейсингом включить именно эту функциональность.
Эта функциональность отдельно тарифицируется, тарификация идет по тарифам, описанным в сервисе Monium.
Ну, опять же, в любой момент вы можете ее выключить в том же самом месте, где и включается.
Еще, как я вот и чуть раньше рассказал, мы обновили раздел «Мониторинг».
Мы добавили тут дашборды, которые вы давно просили.
Немножко обновили дашборды, которые уже были.
И добавили инструменты для фильтрации.
То есть, если вы сейчас посмотрите, у нас есть здесь метод и модели.
В этих дропдаунах можно как раз получить по конкретным методам обращения в API
или по конкретной модели отфильтровать метрики.
Давайте посмотрим.
Для работы с Completions и Responses надо выбирать OpenAI Completion.
В данном случае я выбрал модель DeepSeq V4 Flash.
Здесь можно увидеть запросы, можно увидеть кэшированные токены,
входящие токены, выходящие, время до генерации первого токена.
И вот очень важная часть - это мы добавили сюда квоты.
Например, здесь самый первый график - это параллельные генерации.
Там видно и квоту, и видно, сколько в данный момент от этой квоты потребляется.
Таким образом, давайте подведу небольшой итог обновлений,
которые произошли в iStudio за последнее время.
Если вы следите за развитием, то, наверное, точно стоит
попробовать - это использование параметра Truncation
для автоматического отрезания контекста,
чтобы не происходило ошибки с переполнением
контекста при обращениях в модель.
Это большое количество новых разделов
вокруг мониторинга и логирования,
то есть смотреть на тресы, которые
происходят при работе агента,
следить за квотами, следить за временем
до первого токена и так далее.
Теперь все это наглядно видно в UI
и поможет получить вам больше прозрачности
при работе с агентами,
с API и так далее.
Тут еще, наверное, важно сказать,
что вот эта вся информация по тресам,
по мониторам и так далее,
она не относится только к UI,
то есть не только к тем запросам,
которые были сделаны через UI,
она относится ко всем запросам,
которые вы делаете в API в рамках вашего фолдера.
То есть видимость всей этой информации
и вы это можете там посмотреть,
то есть независимо от того,
в интерфейсе или в API вы используете модели.
Да, на самом деле запрос про трейсинг и про мониторинг
это то, с чем вы к нам приходили в комьюнити
или там при личном общении.
Нам этот фидбэк очень важен
и запросы на появление новых вичей
мы тоже внимательно отслеживаем.
Поэтому спасибо, что делитесь.
Еще одна площадка, про которую
мы раньше не особо подробно рассказывали
но тоже призываем
на ней предлагать ваши идеи
это отдельная
страница
на сайте Яндекс Клауд
тоже вы можете перейти на нее по
ссылке или по QR-коду
предлагайте ваши идеи
и чего не хватает на ваш взгляд в iStudio
мы их обязательно отсматриваем
и самые частые
самые важные идеи стараемся
запланировать и максимально быстро реализовать
в платформе
на этом у нас по
основному материалу вебинару
все, спасибо вам большое
приглашаем
на следующие вебинары сессии
а сейчас готовы ответить
на ваши вопросы, вижу что
довольно много их появилось в чате
так
да, первый
вопрос это
вы исправили багу сохранения предактированного файла
чтобы он не пересоздавался, а дозаписывался
вот, я если честно не очень
помню о какой именно баге идет речь
я тоже не помню именно такой
но
в принципе все
обращения в поддержку с какими-то багами
которые есть, нами обрабатываются
берутся в работу
и если
как бы вы не писали, а
готовы сейчас описать этот баг
через обращение, мы обязательно его исправим
честно говоря, открытого такого бага я не помню
да, аналогично
да, если я хочу
сохранить контекст только за сегодняшний день
учитывать при ответе, а в прошлые
дни просто самозировать, как я это могу сделать
ну, наверное, тут
рекомендация
использовать как раз
conversations API, то есть
вы создаете объект conversation
указываете его при обращении в responses
и дальше у каждого айтема conversation
есть мета
и вы можете
отфильтровать по мете, например, чтобы в conversation
остались только те сообщения
которые произошли сегодня
те сообщения, которые были за предыдущие дни
вы можете просто удалить
из conversation, или забрать их
отправить в модельку для самморизации
и подложить как новый айтем
с самморизацией
в каком случае нужно работать через
агентский API, в каком через интерфейс, в каком
через ДК
я расскажу
добавляй
на самом деле это зависит
сильно от вашего сценария
мы продуктово рассматриваем интерфейс
скорее как способ
поэкспериментировать, потестировать
собрать первое решение
перед тем как использовать
по API
простая точка входа в возможности сервиса
и дальше настройка
всех мониторов, трейсингов
все это удобно делать через интерфейс
само взаимодействие
основное предполагается
через API, если
ваш клиент
то приложение, из какого
идет обращение в
API моделей
если удобно, вы можете
использовать
API напрямую, SDK
это скорее упрощение разработки
то есть в плане SDK
мы рекомендуем использовать
OpenAI на SDK, так как они совместимы
с API, response, realtime
и так далее, то есть например для
просто взаимодействия можно использовать
OpenAI просто SDK
если у вас какая-то более сложная
логика с саб-агентами
хэнд-оффами
более сложными агентскими цепочками
можно использовать OpenAI
Agents SDK, он как раз
реализует вот это вот механизм
например передачи хэнд-оффов
от одного агента к другому и так далее
то есть все это также работает
поверх response API
можете использовать LongChain, LongGraph
другие инструменты, все это также возможно
то есть тут уже в плане удобства разработки
и тех конечных систем, из которых
будет происходить обращение в
модель
да, потому что например SDK вот OpenAI
я знаю точно питоновские есть, вроде JavaScript
далеко не для всех бэкэндов
там систем приложений
эти языки подходят
ну я чуть-чуть дополню, что
как раз у нас в интерфейсе, если нажать посмотреть
код, то мы предлагаем
как раз и как обратиться прямо
в API, так и на разных
языках программирования с помощью
SDK, ну то есть тут
какое для вашего решения более
удобно, более
применимо
что именно я могу узнать с помощью
трейсов, да, трейсы
наверное наибольшую
полезность приносят как раз
в плане работы с Responsys API
почему, потому что Responsys API это
по сути такой базовый агентский цикл
да, то есть это
когда происходит обращение в Responsys
дальше начинается как бы работать цикл
идет обращение в модель
модель говорит, что нужно вызвать
какие-то инструменты, дальше идет вызов
этих инструментов, возвращается
ответ от инструментов
снова идет обращение в модель
с результатом инструментов
и так на самом деле может происходить много-много раз
пока модель не решит, что все
ответ готов, можно его вернуть
пользователю. Соответственно, под капотом
в Responses происходит много вот такой
машинерии, которая не всегда прозрачна
она может влиять на скорость
ответа, может влиять на тарификацию
может влиять на качество ответа
и Trace как раз позволяет
получить прозрачность, а что там в реальности
происходит. То есть, когда вы
открываете конкретный Trace Responses
вы видите, сколько
запросов в рамках этого Responses
было в модель, вы видите
с какими
запросами, например,
происходило обращение
в инструменты. Ну, для примера,
у вас есть простенькая
сборка, да, Responses
с подключенным Web Search Tool.
Сам поисковый запрос в этот
Web Search Tool формулирует модель.
То есть, модель видит контекст переписки,
видит запрос пользователя и сама
формирует запрос, с которым будет
происходить поиск.
То есть, если вы просто
обратитесь в response-ап и получите ответ,
вы можете посмотреть, конечно, всю эту информацию,
но просто в интерфейсе
в тресах она более наглядная,
вы можете фильтровать, искать,
то есть, вы видите, с чем обращались
в инструменты, какую информацию
эти инструменты возвращали,
что на вход, на выход
поступало
в модель во время работы
вот этого агентского цикла.
И, кроме этого, что важно, вы можете видеть
тайминги. То есть, нам время от времени
приходят запросы, что, вот, я там сделал
обращение, у меня очень долго крутился
мой запрос, что-то сломалось.
И как раз Trace позволяет ответить на этот
вопрос: что заняло
время? То есть, время было именно
в самой генерации модели,
или, может быть, веб-поиск работал долго,
или, может быть, вообще там просто произошло
10 запросов веб-поиск, и
пока они все поискались, обработались и так далее,
на это ушло время. То есть, оно вам дает такую
прозрачность работы, и, конечно,
это первый этап для каких-то
эвалов, то есть, для оценки качества
поверх, ну, ваших
агентов систем, да, то есть,
это такая стартовая корзинка,
набор запросов, на которой
вы можете, там, оценивать качество,
оценивать, что надо улучшить, там,
что изменить в правде и так далее, то есть, позволяет вам
работать над качеством и
улучшать работу вашего
агента.
Да, тут добавишь что-то?
Да, в принципе, ты все рассказал.
О, следующий вопрос. Как можно отключить логирование данных, запросов и ответов, логи, обращений в модель?
Ну, про часть логов я рассказывал уже чуть-чуть раньше, да, то есть, что касается трейсов, их можно включить, выключить, дальше у нас есть, собственно, само обращение в responses, там у нас есть параметр store-fels, но мы помним, что если мы его включаем, мы теряем часть функциональности, плюс у нас есть
еще логирование данных, которые делаются для улучшения качества сервиса, в документации у нас описано, как это отключить, надо передать специальный хедер при запросе, и, соответственно, данные не будут сохраняться уже, и в этом случае тоже.
Спасибо. Дальше, вопрос про тарификацию. По тарификации при использовании разных вариантов передачи прошлого контекста в Responses API, в частности, про объект conversation при создании чат-бот-диалогов.
В таком случае переданный контекст не будет съедать повторно токены, которые уже были потрачены на прошлые сообщения диалога.
Да, хороший вопрос, давайте тут подробнее расскажем, как именно устроена механика с тарификацией.
На самом деле тарификация не будет зависеть, не зависит от того, используете ли вы conversation или используете previous response id.
То есть в обоих сценариях механика работы, как передается контекст одинаковая, она не отличается.
Выглядит это следующим образом, то есть тот контекст, который у вас лежит в виде каких-то сообщений, предыдущей истории, он передается в модель весь.
Опять же, если не используется truncation, если не обрезается какая-то история, вот по дефолту, да, вот все, что сохранено, оно передается в модель.
Но важно, чтобы модель видела этот диалог и могла ответить на вопрос.
У нас вот этот, все, что передается в модель, тарифицируется как input токены.
То есть, если вы смотрите на страницу тарификации, там четыре вида токенов, эти токены, они тарифицируются как input токены.
Но есть одно но.
Так как, то, что мы рассказывали, у нас есть на большинстве моделей кэш, например, на дипсик-флэш, если вы с ними работаете, у него есть кэш.
И кэш токены тарифицируются иначе.
И так как история диалога от запроса к запросу будет повторяться, то есть, вот этот префикс, история диалога, она не меняется.
Особенно если, вот тут, наверное, важный момент, если вы используете встроенный механизм передачи контекста,
то она точно не меняется, то есть, как она есть, она будет передаваться, как она есть.
Если вы сами формируете контекст, там, не знаю, внешним фреймворком, самостоятельно строите,
тут важно помнить, что вот этот префикс должен оставаться неизменным.
Есть большая вероятность, что вот этот префикс, вот этот диалог, он закэшируется,
и особенно если у вас запросы идут прям сразу друг за другом, там, не сегодня отправили запрос, потом через неделю,
то есть, тут вероятность, что оно сохранится в кэше очень маленькая.
Но если как бы запросы идут один за другим, то с большой вероятностью этот префикс закэшируется,
и тарификация тогда будет происходить по токенам кэша, не по входящим токенам.
Вот эту информацию о том, сколько токенов у вас пришлось на кэш, сколько на инпут и так далее,
вы можете посмотреть в ответе от Responses по API, то есть, у вас прямо будет расшифровка,
либо это все видно в биллинге, то есть, если вы переходите в мониторинг в биллинге,
там будет у вас прямо разделено, сколько пришлось на кэш, сколько на инпут, аутпут, на тулы и так далее.
Да, тут…
Ну, чуть-чуть дополню, что, как я тоже показывал, теперь это и в мониторинге тоже видно,
сколько кэшированных токенов было.
Да.
Вот, ну и чуть-чуть дополню по поводу Conversation.
В принципе, как ты тоже упоминал, можно какую-то часть контекста суммаризировать, записать в виде item в сам Conversation и удалить их как бы и сами.
Тогда они не будут снова уходить в контекст целиком, а будут уже суммаризации.
Это на тарифы тоже повлияет.
Да, да, да, это точно.
Так, следующий вопрос.
Так, у вас модель дипсик 4 флэш, у вас выделена модель дипсик 4 флэш.
Правильно понимаешь, что данная модель развернута у вас на ресурсах, рамках ВРФ?
Или происходит передача информации за границу?
Ну, все модели, которые у нас представлены сейчас в AI-студии,
они все развернуты в Яндекс.Облаке, в Российской Федерации, на наших серверах.
За границу ничего не передается как за границу Российской Федерации, так и за границу облака.
Да, то есть у нас все модели, у нас вообще нет моделей, которые ходят куда-то, передают данные за границу.
То есть все на центрах обработки данных Яндекса, внутри РФ.
И если говорить юридически, то у нас есть сертификаты ФСС-152 и так далее, которые это подтверждают.
То есть мы не проксируем ни в какие другие модели.
Есть ли решение для компаний со строгой политикой конфиденциальности данных?
Есть, если короткий вопрос, короткий ответ.
Если более подробно, тут, опять же, очень сильно зависит от политик внутри компании.
То есть, как я сказал, у нас есть все необходимые сертификаты для обработки персональных данных в облаке.
При этом понятно, что у каждой компании свои подходы, своя ситуация.
Тут есть разные варианты.
iStudio доступно для поставки полностью в он-прем закрытый контур.
То есть, если есть необходимость поставить все эти компоненты, инструменты,
про которые мы рассказывали локально, без выхода в интернет это возможно сделать.
Есть гибридные варианты, когда, например, часть компонентов платформы,
вроде рага, базы знаний ставится в контур,
но при этом большие модели вроде дипсека используются из облака,
по защищенному каналу, выделенному с настройками сети.
Тут у нас очень много есть разных практик, подходов,
как можно сделать настройки сети, сделать приватные изолированные сети.
Мы не покрываем это отдельно в вебинарах, это такая довольно специфическая тонкая тема,
но мы помогаем с настройкой, если у вас есть такие запросы,
есть такие вещи, как выделенные приватные эндпоинты,
по которым можно обращаться в модель,
есть возможность ходить только внутри подсети облачной и так далее.
В общем, тут много разных настроек, которые можно сделать все это возможно.
Часть этого есть в разделе безопасность UI, есть документация,
ну и можно просто обратиться в ту же, и мы подробно расскажем.
Да, да, то есть вы можете написать там в сообществе,
можно оставить заявку на сайте iStudio, там есть прям форума связаться с нами,
там опишите проблему, мы свяжемся и отдельно можем там подробно рассказать,
как все эти вещи, политики настраиваются.
Так.
Еще вопрос, что будет, если я передам запрос с ID старого Conversation,
который уже удалился. Просто ошибка легенд видит просто без контекста.
Так, ну, наверное, тут для надежности надо будет проверить,
но с большой родности это будет ошибка.
Да.
Он просто упадет с ошибкой, что такого Conversation нет.
Когда OpenAI совместимый интерфейс, значит, поддерживать фоновые запросы.
Я так понимаю, речь идет про бэкграунд-режим.
Он уже доступен, то есть, если вы будете использовать бэкграунд,
он работает, он будет, он, тут, наверное, для тех, кто может чуть не в контексте,
тут подсвечу, что у респонс-апи как бы по дефолту,
когда вы его используете, используется синхронный режим,
то есть, вы отправили запрос, сразу получаете ответ.
Бэкграунд-режим, если эта настройка установлена,
то он, как бы, запрос обрабатывается с каким-то лагом по времени, да,
то есть, у нас бэкграунд-режим, в бэкграунд-режиме запрос может обрабатываться
до 24 часов, но при этом вы не упираетесь в ограничения
по параллельным генерациям дефолтные, то есть, у нас есть квота
по параллельным генерациям, ее можно увеличивать через поддержку,
но все равно там есть достаточно такие, ну, строгие лимиты, да,
в которых эта квота может быть увеличена.
Если вы разово, например, хотите закинуть, там, не знаю,
10 тысяч запросов вот в моменте и готовы подождать, пока они обработаются,
при этом не думать там о построении очереди, вы можете использовать бэкграунд-режим,
он доступен уже сейчас, можете с ним работать, мы планируем его улучшать,
делать доработки, об этом тоже будем отдельно рассказывать,
но уже сейчас базово этот бэкграунд-режим доступен.
Ну, фоновые запросы, если про них идет речь.
Как лучше хранить память голосового агента, если он работает с одним клиентом несколько недель?
Совершает несколько отдельных звонков, получает новые данные из CRM и решает, что делать дальше.
Что нужно хранить отдельно, а что передавать VLM перед каждым звонком, чтобы контекст не становился слишком большим.
На самом деле, в real-time API, в общем-то, хранение контекста реализовано похожим образом, как и в response API.
Там есть ряд своих деталей, но я вам лучше рекомендую этот вопрос сохранить при посте на отдельный вебинар, который будет в real-time API.
Он, по-моему, следующий в нашей серии. Там коллеги уже подробнее, детальнее расскажут, сколько хранятся данные в контексте, как они обрабатываются, как-то передавать.
То есть предлагаю этот вопрос сохранить до следующей сессии, которая будет подробнее про real-time.
Вот вопрос хороший.
Вижу, что по вопросам пока все.
Хотелось бы сказать большое спасибо, что подключились к этому первому вебинару.
Надеюсь, что было интересно и остальные будут не менее интересные.
Особенно заключительная часть.
Предлагайте ваши проекты, будем очень рады их рассмотреть.
И спасибо большое за ваше внимание.