1 00:00:00,000 --> 00:00:27,280 Всем привет! Меня зовут Дима. Я отвечаю за продуктовое развитие платформы AI Studio. 2 00:00:27,280 --> 00:00:32,400 Привет! Меня зовут Золотов Сергей, я технический менеджер проектов Яндекс.АйСтудио. 3 00:00:32,400 --> 00:00:40,480 Мы рады вас приветствовать на первом вебинаре в рамках серии Яндекс.АйСтудио для разработчиков. 4 00:00:40,480 --> 00:00:50,080 Это наша летняя серия, где мы подробно рассказываем о разных аспектах, нюансах платформы AI Studio 5 00:00:50,080 --> 00:00:54,560 именно для технической аудитории с техническими деталями. 6 00:00:54,560 --> 00:01:01,180 Давайте для начала расскажу в целом про, что наша серия, что мы хотим вам рассказать, чем поделиться. 7 00:01:01,180 --> 00:01:08,000 Она будет состоять из четырех вебинаров, посвященных разным кускам платформы. 8 00:01:08,000 --> 00:01:15,440 Сегодня у нас первый вводный вебинар. Мы сделаем фокус на работе с так называемыми агентскими API. 9 00:01:15,440 --> 00:01:21,800 То есть поговорим о том, как вообще можно подходить к разработке агентов на базе AI Studio, 10 00:01:21,800 --> 00:01:28,100 как использовать инструменты и основной фокус будет на двух темах. Первая - это работа с 11 00:01:28,100 --> 00:01:33,860 контекстом. В комьюнити вы задавали много вопросов, был запрос на вебинар, чтобы мы рассказали, 12 00:01:33,860 --> 00:01:39,980 как можно управлять контекстом, как использовать его в разных API. Этому будет посвящен сегодня 13 00:01:39,980 --> 00:01:46,600 вебинар и мы поговорим про инструменты мониторинга, которые появились в AI Studio. То есть мы расскажем 14 00:01:46,600 --> 00:01:54,240 про основные обновления вокруг Responses API. 21 июля будет вебинар, посвященный голосовым агентам, 15 00:01:54,240 --> 00:02:03,220 то есть если вы уже знакомы с нашими компонентами, это все вокруг Real-Time API. Дальше 23 июля мы 16 00:02:03,220 --> 00:02:08,440 подробно поговорим про поисковые сценарии, то есть про использование и построение рага, 17 00:02:08,440 --> 00:02:15,280 про использование веб-поиска и те улучшения, которые произошли в этих компонентах. И 28 июля у нас 18 00:02:15,280 --> 00:02:22,840 будет вебинар про автоматизацию процессов. Мы поговорим про процессы и выстраивание 19 00:02:22,840 --> 00:02:27,640 автоматизации процессов на базе инструмента Workflows без написания кода, то есть нашего 20 00:02:27,640 --> 00:02:32,520 визуального инструмента. Там произошло большое количество обновлений, направленных на 21 00:02:32,520 --> 00:02:37,780 упрощение работы с инструментом, и про них мы, конечно, тоже подробно расскажем. Для того, 22 00:02:37,780 --> 00:02:43,960 чтобы вы могли как бы немного закрепить те знания и понять, насколько вообще понятны основные 23 00:02:43,960 --> 00:02:54,280 концепции. После каждого вебинара мы подготовили тест. Ссылкой к QR-коду мы поделимся в конце вебинара. 24 00:02:54,280 --> 00:03:02,260 И в завершение этой серии, 30 июля, у нас будет фестиваль решений. На самом деле, 25 00:03:02,260 --> 00:03:08,020 там будет много различных интересных докладов. Мы будем рассказывать про архитектурные детали, 26 00:03:08,020 --> 00:03:12,640 различных подходов к построению агентов текстовых, голосовых. У нас 27 00:03:12,640 --> 00:03:19,960 будет отдельный мастер-класс от наших архитекторов Яндекс Клауд, где они расскажут про лучшие 28 00:03:19,960 --> 00:03:26,800 подходы к проектированию продуктов и возможные ошибки, которые могут возникать. И отдельно, 29 00:03:26,800 --> 00:03:35,200 в рамках этой серии вебинаров, мы запускаем отдельный челлендж для разработчиков. Вы можете 30 00:03:35,200 --> 00:03:41,320 отсканировать QR-код, перейти по ссылке и оставить свою заявку. Заявки вам нужно будет 31 00:03:41,320 --> 00:03:49,020 описать проект и цели, для какой аудитории вы делаете этот проект. Мы уже начали 32 00:03:49,020 --> 00:03:55,120 отсматривать ваши заявки, их уже пришло довольно много, спасибо большое за отклик. И ближе к концу 33 00:03:55,120 --> 00:04:00,880 недели мы начнем возвращаться с ответами, мы отберем самые интересные заявки и дальше в течение 34 00:04:00,880 --> 00:04:09,000 восьми недель мы будем участвовать в разработке запуска и решений, то есть с консультацией экспертов 35 00:04:09,000 --> 00:04:18,000 и экспертов от Яндекс Клауд вы сможете собрать свое решение для решения вашей задачи, для реализации 36 00:04:18,680 --> 00:04:27,640 вашего проекта, который вы опишите в форме, то есть серия вебинаров и фестиваль решений 37 00:04:27,640 --> 00:04:33,740 это как раз такие подготовительные этапы, где мы расскажем детально про технологию и дальше вы уже сможете 38 00:04:33,740 --> 00:04:38,380 применить эту технологию в действии с нашими консультациями, с нашей помощью. 39 00:04:39,640 --> 00:04:46,080 Что ж, давайте переходить непосредственно к материалу сегодняшнего вебинара. 40 00:04:46,320 --> 00:04:51,260 Единственное, еще напомню, что по ходу вебинара вы можете задавать вопросы, 41 00:04:51,800 --> 00:04:55,960 мы ответим на них в конце вебинара, поэтому если вам что-то непонятно, 42 00:04:55,960 --> 00:05:01,940 нужно лучше объяснить, не стесняйтесь, задавайте вопросы, будем рады на них в конце ответить. 43 00:05:03,720 --> 00:05:08,320 Так как это уже вторая такая серия для разработчиков, 44 00:05:08,360 --> 00:05:14,620 первая была в ноябре, мы не будем останавливаться подробно на обзоре iStudio, 45 00:05:14,760 --> 00:05:18,840 что в ней возможно делать, если вам хочется, 46 00:05:18,940 --> 00:05:21,600 если вы только первый раз вообще узнали про iStudio, 47 00:05:21,600 --> 00:05:24,100 хотите разобраться, как начать с ней работать, 48 00:05:24,620 --> 00:05:31,780 мы в сообществе поделимся отдельным набором ссылок на предыдущую серию, 49 00:05:31,900 --> 00:05:37,700 где мы рассматривали такие стартовые моменты вокруг начала работы с iStudio. 50 00:05:38,040 --> 00:05:43,300 Сегодня мы уже углубимся в детали вокруг работы с платформой. 51 00:05:44,080 --> 00:05:51,160 Но коротко напомню, что iStudio для разработки текстовых агентов 52 00:05:51,160 --> 00:05:54,660 можно разбить примерно на три слоя. 53 00:05:55,560 --> 00:05:57,880 То есть первый слой — это слой API. 54 00:05:58,920 --> 00:06:02,600 Основной функционал, основное взаимодействие с компонентами платформы 55 00:06:02,600 --> 00:06:04,520 у нас возможен через API. 56 00:06:05,080 --> 00:06:09,420 Здесь стоит сказать про три ключевых API, которые доступны для работы. 57 00:06:09,820 --> 00:06:11,160 Первый — это Responses API. 58 00:06:11,700 --> 00:06:16,260 Это наш рекомендованный API для работы с моделями, 59 00:06:16,260 --> 00:06:18,420 для текстовых сценариев, текстовых агентов. 60 00:06:19,240 --> 00:06:23,380 Вокруг него сейчас происходит основное развитие подтекстового сценария. 61 00:06:23,880 --> 00:06:26,460 И если вы, например, хотите собирать каких-то агентов, 62 00:06:26,620 --> 00:06:29,680 строить рак-сценарий, строить работу с веб-поиском, 63 00:06:30,020 --> 00:06:31,560 то это рекомендованный API. 64 00:06:32,220 --> 00:06:39,100 Если у вас голосовой сценарий, где требуется очень высокая скорость ответа, 65 00:06:39,100 --> 00:06:43,080 то есть низкая задержка между тем, как вы закончили говорить, 66 00:06:43,360 --> 00:06:46,720 и робот или агент начал отвечать, 67 00:06:47,160 --> 00:06:49,220 то мы рекомендуем использовать real-time API, 68 00:06:49,320 --> 00:06:52,180 как раз оптимизированный под голосовые сценарии 69 00:06:52,180 --> 00:06:54,800 со своими специфическими концепциями. 70 00:06:54,880 --> 00:06:57,320 Мы про них поговорим на другом вебинаре. 71 00:06:57,980 --> 00:06:59,540 И chat completions API. 72 00:06:59,840 --> 00:07:02,460 Это API для взаимодействия просто с моделью, 73 00:07:02,520 --> 00:07:04,640 то есть запрос в модель и ответ от модели. 74 00:07:05,280 --> 00:07:07,540 Его удобно использовать, например, 75 00:07:07,800 --> 00:07:10,440 если вы работаете с какими-то open-source фреймворками, 76 00:07:10,960 --> 00:07:15,800 не знаю, LongChain, LongGraph, Nathan, OpenWebUI, еще что-то. 77 00:07:16,160 --> 00:07:19,960 Вы можете, все они поддерживают chat completions API, 78 00:07:20,080 --> 00:07:24,020 и вы можете очень легко интегрировать модель и iStudio в эти фреймворки. 79 00:07:24,020 --> 00:07:28,540 Тут еще, наверное, стоит сказать, что и responses, и real-time, и chat completions, 80 00:07:28,600 --> 00:07:33,060 они совместимы с форматом API OpenAI, и, соответственно, большая часть 81 00:07:33,060 --> 00:07:37,200 опенсорсных фреймворков поддерживает, так или иначе, все эти три API. 82 00:07:38,100 --> 00:07:42,980 Дальше, опускаясь чуть ниже, кроме самой модели, мы предоставляем набор 83 00:07:42,980 --> 00:07:46,680 готовых компонентов в платформе, которые позволяют реализовать 84 00:07:46,680 --> 00:07:47,940 широкий набор сценариев. 85 00:07:48,640 --> 00:07:55,320 Эти компоненты работают все с responses API, часть работает с real-time API, 86 00:07:55,720 --> 00:08:00,640 но в чат completions, как я сказал, это только запрос модель и получение ответа. 87 00:08:00,920 --> 00:08:05,000 То есть, если вам необходимо использование встроенных компонентов, 88 00:08:05,640 --> 00:08:09,280 встроенных инструментов, то необходимо использовать responses API. 89 00:08:10,200 --> 00:08:16,080 Из встроенных компонентов это файл-серч или векторные базы 90 00:08:16,080 --> 00:08:22,740 для реализации сценария рага, поиска по базам и веб-серч для поиска в интернете. 91 00:08:23,060 --> 00:08:26,020 Про поисковый сценарий мы будем говорить на отдельном вебинаре. 92 00:08:26,620 --> 00:08:30,540 Конечно же, MCP для взаимодействия с внешними системами, 93 00:08:30,640 --> 00:08:33,320 для выполнения действий во внешних системах. 94 00:08:34,080 --> 00:08:36,840 Инструмент для генерации изображений, 95 00:08:37,380 --> 00:08:40,260 то есть когда агенту необходимо сгенерировать изображение, 96 00:08:40,620 --> 00:08:44,220 он может вызывать этот инструмент и возвращать пользователю картинку. 97 00:08:44,840 --> 00:08:48,020 И инструмент интерпретации кода, когда модель пишет код, 98 00:08:48,020 --> 00:08:51,580 этот код автоматически выполняется в изолированном контейнере, 99 00:08:51,940 --> 00:08:56,320 возвращает результат, и затем пользователь получает, например, 100 00:08:56,860 --> 00:09:02,440 сгенерированную презентацию, сгенерированный файл и так далее. 101 00:09:03,500 --> 00:09:07,600 И есть ряд еще дополнительных API, на них мы не будем сегодня останавливаться. 102 00:09:08,200 --> 00:09:11,220 Это API для каких-то конкретных узких задач, 103 00:09:11,580 --> 00:09:14,820 например, API для генерации векторов, 104 00:09:14,820 --> 00:09:20,880 API для получения генерации изображений, если это нужно не в агенте, 105 00:09:20,940 --> 00:09:24,280 а вот просто отправить запрос, получить генерированное изображение. 106 00:09:24,640 --> 00:09:28,000 Или отдельное API для классификации текстов, такое тоже есть, 107 00:09:28,360 --> 00:09:31,640 вы его можете использовать, подробнее почитать о нем в документации. 108 00:09:32,940 --> 00:09:41,340 Дальше часто встает вопрос, а какой API мне вообще использовать для решения моей задачи. 109 00:09:41,700 --> 00:09:46,380 Давайте чуть подробнее остановимся, если вы первый раз открываете документацию, 110 00:09:46,460 --> 00:09:52,680 наверное, можно запутаться, да, большое количество разных API, 111 00:09:53,040 --> 00:09:56,940 но давайте попробуем определить, какие нужны под какие задачи. 112 00:09:57,300 --> 00:10:01,900 Как я уже говорил ранее, Responses API — это основной агентский API. 113 00:10:02,600 --> 00:10:08,960 Если у вас есть задачи, например, вокруг рага, автоматического вызова функции и так далее, 114 00:10:09,240 --> 00:10:12,020 то мы рекомендуем использовать Responses API. 115 00:10:12,580 --> 00:10:16,160 На самом деле, просто для работы с моделью, отправить запрос, получить ответ, 116 00:10:16,460 --> 00:10:22,480 он тоже подходит, то есть без подключения от улов, по сути, он решает эту задачу. 117 00:10:24,600 --> 00:10:28,520 Если у вас есть необходимость использовать структурированный вывод, 118 00:10:28,860 --> 00:10:32,960 то есть когда вы описываете схему и дальше ожидаете ответа в этой схеме, 119 00:10:33,420 --> 00:10:38,280 то со Structured Output можно использовать как Responses, так и Chat Completions API. 120 00:10:38,280 --> 00:10:41,840 Они оба поддерживают этот функционал. 121 00:10:42,700 --> 00:10:49,060 Real-time API хорошо подходит для голосовых сценариев, то есть если у вас текст Responses, если голос, то real-time. 122 00:10:49,560 --> 00:10:55,500 Chat Completions удобен в сценариях, где необходим просто запрос в модель, 123 00:10:55,740 --> 00:10:58,820 например, сделать суммаризацию, проанализировать отзыв, 124 00:10:59,360 --> 00:11:04,880 либо чаще всего интеграция с внешними фреймворками, они все поддерживают этот формат API. 125 00:11:05,220 --> 00:11:10,200 Дальше есть отдельный набор API вокруг работы с файлами. 126 00:11:10,640 --> 00:11:17,260 Они нужны, например, когда нам необходимо загрузить файлы в векторный индекс, векторное хранилище, 127 00:11:17,640 --> 00:11:22,640 либо наоборот, например, интерпретарь кода сгенерировал какой-то файл, и его нужно забрать. 128 00:11:22,640 --> 00:11:29,640 Это также можно сделать через файл с API, то есть это API для работы с файлами внутри платформы iStudio. 129 00:11:30,320 --> 00:11:38,580 VectorStores — это основной API для построения баз знаний, то есть вы загружаете файлы, они автоматически парсятся, 130 00:11:38,580 --> 00:11:44,580 складываются в векторный индекс и дальше могут использоваться из агента для получения информации, 131 00:11:45,960 --> 00:11:50,020 для поиска информации. То есть для работы с файлами у нас files и VectorStores API. 132 00:11:50,780 --> 00:11:58,540 Далее, если вы, например, самостоятельно строите сценарий по Raga, у вас какая-то своя кастомная логика, 133 00:11:58,720 --> 00:12:06,520 вы можете использовать embedding с API для получения векторов, либо, опять же, использовать генерацию изображений 134 00:12:06,520 --> 00:12:10,580 с помощью отдельной API обращения к Alice AI Art. 135 00:12:11,140 --> 00:12:17,020 Еще один API, про который мы ранее подробно не рассказывали, но также можно его использовать, 136 00:12:17,160 --> 00:12:18,960 это API для работы с MCP. 137 00:12:19,540 --> 00:12:23,720 В рамках платформы Studio есть такой компонент, который называется MCP Hub. 138 00:12:24,200 --> 00:12:27,400 По сути, он позволяет подключать внешние MCP-сервера платформу 139 00:12:27,400 --> 00:12:31,100 или создавать свои собственные поверх существующих API-систем. 140 00:12:31,100 --> 00:12:40,700 И вот, взаимодействовать с этим MCP-хабом можно как в интерфейсе, так и через API, например, для автоматизации каких-то задач, 141 00:12:40,840 --> 00:12:45,060 для автоматизации добавления MCP в MCP-хаб. 142 00:12:46,880 --> 00:12:52,240 Я уже несколько раз упомянул интеграцию с различными подсорс-инструментами, 143 00:12:52,240 --> 00:12:57,040 и на самом деле мы специально делали API OpenAI совместимыми, 144 00:12:57,180 --> 00:13:04,260 чтобы без каких-то проблем можно было работать с различными open-source инструментами. 145 00:13:04,940 --> 00:13:08,880 И недавно мы подготовили серию так называемых how-to, 146 00:13:09,180 --> 00:13:13,580 обучающих, коротких обучающих вебинаров, 147 00:13:13,580 --> 00:13:19,620 где мы рассказываем, как настроить подключение к компонентам MyAstudio 148 00:13:19,620 --> 00:13:26,460 из различных open-source фреймворков, решений Nathan, OpenClaw, WebUI и так далее. 149 00:13:26,880 --> 00:13:32,760 Поэтому, если у вас есть интерес использовать какое-то из этих решений вместе с MyAstudio, 150 00:13:33,280 --> 00:13:36,740 сканируйте QR-код, переходите и настраивайте подключение. 151 00:13:37,840 --> 00:13:46,320 Когда мы говорим про начало работы, создание агента, тестирование и так далее, 152 00:13:46,960 --> 00:13:52,520 то самый первый простой способ входа в платформу, начало работы, 153 00:13:52,620 --> 00:13:55,700 это попробовать собрать агента в UI. 154 00:13:56,340 --> 00:13:57,500 Выглядит это следующим образом. 155 00:13:57,620 --> 00:14:02,860 В интерфейсе вы можете выбрать модель, можете выбрать инструкцию, указать инструкцию, 156 00:14:03,260 --> 00:14:07,740 подключить необходимые инструменты, MCP, веб-поиск, файловый поиск и так далее, 157 00:14:09,020 --> 00:14:13,680 там нажать «Сохранить» и потестировать этого агента в интерфейсе. 158 00:14:14,420 --> 00:14:21,360 Тут важно сказать, что интерфейс в iStudio — это компонент для первичного тестирования, 159 00:14:21,360 --> 00:14:29,100 отладки, подбора промта и подбора хорошей конфигурации вашего агента. 160 00:14:29,800 --> 00:14:35,680 И дальше вы можете нажать кнопку «Посмотреть код» и получить непосредственно код 161 00:14:35,680 --> 00:14:42,680 для обращения уже в этого агента, чтобы встроить его в вашу систему, 162 00:14:42,820 --> 00:14:46,560 в ваше приложение, из которого будет происходить запрос. 163 00:14:47,280 --> 00:14:52,820 Когда происходит сохранение вот этой конфигурации в интерфейсе, 164 00:14:53,500 --> 00:14:59,320 то появляется такая сущность, как PromptID, или в интерфейсе это называется AgentID, 165 00:14:59,640 --> 00:15:04,980 в API это PromptID, то есть это ID вашей конфигурации, 166 00:15:05,480 --> 00:15:11,600 вы передаете ее при обращении в Responses Create в поле PromptID, 167 00:15:11,600 --> 00:15:17,220 и дальше вы, по сути, обращаетесь к этой конфигурации, которую вы настроили в интерфейсе, 168 00:15:17,760 --> 00:15:23,520 то есть инструкция, подключенные тулы и так далее, все эти настройки, они сохраняются, 169 00:15:24,040 --> 00:15:27,860 и вам не нужно при каждом запросе в Responses их указывать и передавать. 170 00:15:28,460 --> 00:15:32,980 Вот создание такого PromptID или агента возможно только через интерфейс. 171 00:15:33,360 --> 00:15:35,600 Если вы сразу начинаете работать через API, 172 00:15:36,600 --> 00:15:41,540 то здесь вам необходимо при каждом запросе в Responses 173 00:15:41,540 --> 00:15:48,280 передавать описание параметров, которые влияют на работу моделей, 174 00:15:48,780 --> 00:15:50,300 на подключенные инструменты и так далее. 175 00:15:50,940 --> 00:15:52,840 Давайте посмотрим на самый простой пример, 176 00:15:53,220 --> 00:15:55,240 как выглядит обращение в Responses. 177 00:15:55,800 --> 00:15:59,340 Здесь у нас указываются пять параметров, то есть сама модель. 178 00:16:00,060 --> 00:16:03,800 В AI-студии доступны различные модели. 179 00:16:04,100 --> 00:16:06,680 Это модели от Яндекса, это опенсорсные модели. 180 00:16:06,680 --> 00:16:09,680 Сразу тут, наверное, стоит обратить внимание, 181 00:16:09,980 --> 00:16:13,760 что для сценариев, где происходит работа с инструментами, 182 00:16:13,840 --> 00:16:18,860 то есть вызов различных инструментов, поиска информации по файлам в интернете, 183 00:16:19,020 --> 00:16:24,740 мы рекомендуем использовать модели вроде DeepSig Flash или Quen 3.6. 184 00:16:25,840 --> 00:16:29,540 Они лучше всего работают именно с вызовом инструментов. 185 00:16:30,180 --> 00:16:35,420 Далее мы в качестве инпута передаем пользовательский запрос. 186 00:16:35,420 --> 00:16:38,120 Это то, что передает пользователь при обращении. 187 00:16:38,420 --> 00:16:40,920 И дальше мы описываем подключенные инструменты. 188 00:16:41,560 --> 00:16:47,080 В этом примере это подключенный инструмент веб-поиска с ограничением по доменам, 189 00:16:47,260 --> 00:16:50,540 то есть по тем сайтам, доменам, по которым можно искать. 190 00:16:51,440 --> 00:16:59,660 И там дальше есть параметр контекста, 191 00:16:59,660 --> 00:17:06,760 то есть какое количество информации со страниц будет использоваться 192 00:17:06,760 --> 00:17:11,480 в качестве контекста для самой модели по результатам поиска в интернете. 193 00:17:12,240 --> 00:17:14,760 Здесь еще, наверное, хотелось бы отметить, 194 00:17:14,860 --> 00:17:20,280 что у нас совсем недавно произошло обновление инструмента веб-поиска. 195 00:17:20,540 --> 00:17:24,060 Про это обновление, именно про его детали мы расскажем на отдельном вебинаре, 196 00:17:24,060 --> 00:17:27,540 но если вы ранее пользовались веб-поиском, 197 00:17:27,720 --> 00:17:30,280 какие-то запросы у вас отрабатывали недостаточно хорошо, 198 00:17:30,880 --> 00:17:32,040 рекомендуем попробовать еще раз. 199 00:17:32,300 --> 00:17:34,500 Сейчас качество значительно выросло, 200 00:17:34,860 --> 00:17:37,140 при этом количество потребляемых токенов 201 00:17:37,140 --> 00:17:42,700 после веб-поиска значительно снизилось 202 00:17:42,700 --> 00:17:44,940 за счет оптимизации работы инструмента. 203 00:17:46,500 --> 00:17:50,580 Много, на самом деле, различных параметров, 204 00:17:50,580 --> 00:17:53,800 которыми можно управлять в Responses API. 205 00:17:54,300 --> 00:17:59,840 Давайте их попробуем сгруппировать в 4 блока. 206 00:18:00,540 --> 00:18:04,840 Первый блок параметров связан непосредственно с самой моделью. 207 00:18:05,320 --> 00:18:08,240 То есть это выбор модели, в которой будет происходить обращение. 208 00:18:08,720 --> 00:18:15,500 Это инструкция, то есть это системный промпт, который описывает поведение условно агента, 209 00:18:15,640 --> 00:18:18,460 его задает разработчик этого агента. 210 00:18:18,460 --> 00:18:24,600 И дальше input — это пользовательский ввод, который передается уже агенту, чтобы он выполнил какую-то задачу. 211 00:18:24,880 --> 00:18:31,820 Дальше есть набор параметров вокруг самой генерации, которые управляют генерацией модели. 212 00:18:32,420 --> 00:18:38,640 Это температура, это максимальное количество токенов, которые будут возвращаться на выходе. 213 00:18:38,640 --> 00:18:45,160 Это режим рассуждений. Тут важно оговориться, что режим рассуждений работает не для всех моделей. 214 00:18:45,840 --> 00:18:55,500 То есть тут важно проверить документации или, например, в интерфейсе в Model Hub, какие модели поддерживают рассуждения. 215 00:18:56,200 --> 00:19:01,880 И stream — это параметр, который регулирует, каким образом возвращаются токены. 216 00:19:01,980 --> 00:19:07,480 То есть генерируется ли ответ сразу весь и возвращается пользователю как весь ответ. 217 00:19:07,860 --> 00:19:12,380 Либо ответ стримится, то есть возвращается такими фрагментами. 218 00:19:13,400 --> 00:19:16,080 Дальше блок параметров вокруг инструментов. 219 00:19:16,380 --> 00:19:18,780 Какие инструменты доступны агенту для использования. 220 00:19:19,600 --> 00:19:22,360 Максимальное количество вызовов инструмента. 221 00:19:23,000 --> 00:19:28,880 И дополнительно, если у вас есть необходимость использовать не встроенные инструменты в iStudio, 222 00:19:28,880 --> 00:19:31,200 а подключить какую-то свою логику функций. 223 00:19:31,540 --> 00:19:34,860 Также доступно можно указать через параметры Function Calling. 224 00:19:35,680 --> 00:19:37,460 И формат ответа. 225 00:19:38,160 --> 00:19:42,440 Здесь на самом деле будет фокус вебинара. 226 00:19:42,780 --> 00:19:48,700 Мы поговорим про параметры Previous Response ID и Store подробнее дальше, 227 00:19:48,820 --> 00:19:51,440 поэтому пока на них не буду фокусироваться. 228 00:19:52,080 --> 00:19:54,220 Вот, этот слайд, наверное, такой вспомогательный. 229 00:19:54,420 --> 00:19:56,780 Не буду прям совсем подробно на нем останавливаться. 230 00:19:56,780 --> 00:20:01,660 Это, скорее, такая памятка, на какие параметры стоит обращать внимание при разработке. 231 00:20:02,080 --> 00:20:04,240 Наверное, тут ключевая колонка — это когда менять. 232 00:20:04,800 --> 00:20:08,060 И, как правило, когда вы начинаете разрабатывать агента, 233 00:20:08,680 --> 00:20:10,940 конечно, первое, что важно протестить — это модель. 234 00:20:11,800 --> 00:20:13,080 Какую модель выбрать? 235 00:20:13,380 --> 00:20:19,140 Опять же, тут, наверное, мы рекомендуем начинать с моделей вроде DeepSeek Flash, 236 00:20:19,320 --> 00:20:22,160 так как они хорошо работают с большим количеством инструментов. 237 00:20:22,460 --> 00:20:27,420 Дальше, если у вас, например, есть необходимость, чтобы ответы были быстрее, 238 00:20:27,620 --> 00:20:31,980 или наоборот, не знаю, сценарий какой-то, не требующий инструментов, 239 00:20:32,040 --> 00:20:38,180 то можно попробовать модели вроде Alice iFlash или Kvinov поменьше и так далее. 240 00:20:38,920 --> 00:20:48,820 Инструкция и input — это параметры, которые влияют на то, как будет себя вести агент, 241 00:20:48,820 --> 00:20:52,340 то есть его системный промпт, что ему нужно делать, какие шаги выполнять, 242 00:20:52,820 --> 00:20:54,540 и input — это пользовательский ввод. 243 00:20:55,440 --> 00:21:00,100 Параметр температура, на самом деле, если вы смотрели наши вебинары раньше, 244 00:21:00,260 --> 00:21:03,580 особенно в самом начале, не знаю, пару лет назад и так далее, 245 00:21:04,020 --> 00:21:08,760 мы обычно говорили, что температура, она отвечает за креативность модели, 246 00:21:09,020 --> 00:21:11,000 она находится в диапазоне между 0 и 1. 247 00:21:11,000 --> 00:21:21,000 На самом деле, сейчас это немного поменялось, и новые модели могут требовать значения температуры выше, 248 00:21:21,260 --> 00:21:25,240 и эти значения могут сильно отличаться от модели к модели. 249 00:21:25,800 --> 00:21:29,920 Например, тут такой совет, что если вы работаете с моделью QN3.6, 250 00:21:30,500 --> 00:21:36,780 то мы рекомендуем ее тестировать на высоких температурах, то есть 1 и выше, 251 00:21:36,780 --> 00:21:39,780 то есть я бы даже сказал, что скорее 1 это минимальная температура, 252 00:21:40,640 --> 00:21:43,940 с которой мы рекомендуем тестирование модели QN3.6. 253 00:21:44,920 --> 00:21:50,780 Что касается MaxOutputToken, это параметр, который регулирует максимальный размер контекста, 254 00:21:51,060 --> 00:21:56,680 то есть, когда вы его задаете, вы гарантированно знаете, 255 00:21:57,280 --> 00:22:00,060 что в ответе не будет больше, чем такое количество токенов. 256 00:22:00,580 --> 00:22:02,320 С этим параметром нужно быть осторожным, 257 00:22:02,560 --> 00:22:07,460 потому что может происходить ситуация, что это просто грубое обрезание. 258 00:22:07,460 --> 00:22:13,920 То есть, что модель, например, не поместила свой ответ в эти 200 токенов, 259 00:22:13,940 --> 00:22:16,400 которые вы указали, и часть токенов просто обрезалась. 260 00:22:16,740 --> 00:22:18,720 Это может сильно повлиять на пользовательский опыт. 261 00:22:18,860 --> 00:22:23,080 Поэтому с этим параметром стоит быть осторожным. 262 00:22:23,420 --> 00:22:25,660 Ну, про инструменты мы уже поговорили. 263 00:22:26,180 --> 00:22:30,000 Еще, наверное, такой важный нюанс — это про формат ответа. 264 00:22:30,000 --> 00:22:35,280 То есть, вы можете, когда обращаетесь в Responsys, указать структуру JSON, 265 00:22:35,640 --> 00:22:37,040 в которой должен содержаться ответ. 266 00:22:37,700 --> 00:22:45,160 И тут важно проговорить, что здесь есть ограничения в Responsys, 267 00:22:45,380 --> 00:22:49,980 что либо в ответ возвращается ответ по этой структуре JSON, 268 00:22:50,620 --> 00:22:54,900 либо вы используете Responsys как инструмент, который вызывает различные инструменты. 269 00:22:54,900 --> 00:22:58,380 То есть, например, вы не можете сделать обращение в Responsys 270 00:22:58,380 --> 00:23:02,080 и одновременно указать и инструмент поиска по файлам, 271 00:23:02,520 --> 00:23:05,960 и строгую JSON-схему, в которую нужно этот ответ вернуть. 272 00:23:06,300 --> 00:23:08,960 То есть, возможно, либо так, либо иначе. 273 00:23:09,080 --> 00:23:11,900 Одновременно это приведет к ошибке и работать не будет. 274 00:23:12,900 --> 00:23:16,540 Вот, previous response ID и store — это два параметра, 275 00:23:16,720 --> 00:23:20,380 которые нужны нам для реализации сценарий чатовых. 276 00:23:20,900 --> 00:23:24,420 То есть, responses API умеет автоматически работать с контекстом, 277 00:23:25,060 --> 00:23:29,040 сохранять сообщения, предыдущие сообщения, всю историю сообщений, 278 00:23:29,420 --> 00:23:32,220 выстраивать как бы дерево общения, 279 00:23:32,220 --> 00:23:35,420 и дальше использовать эту информацию из контекста 280 00:23:35,420 --> 00:23:37,660 для ответа на вопросы пользователей. 281 00:23:39,160 --> 00:23:45,060 Итак, у нас есть API, есть параметры, 282 00:23:45,520 --> 00:23:47,780 давайте посмотрим детальнее, когда что выбрать. 283 00:23:48,480 --> 00:23:51,080 Если у вас какое-то разовое обращение, 284 00:23:51,520 --> 00:23:54,160 отправили запрос, длинный текст, документ, 285 00:23:54,340 --> 00:23:57,220 сделай суммаризацию, классифицируй отзыв, еще что-то. 286 00:23:57,220 --> 00:24:01,780 Одноразовая задача, responses API с параметром store равно false, 287 00:24:02,100 --> 00:24:03,880 то есть чтобы не сохранять это сообщение, 288 00:24:03,980 --> 00:24:06,600 оно нам не понадобится для чата, для контекста, 289 00:24:06,760 --> 00:24:09,580 то есть вы обращаетесь в responses, говорите store равно false, 290 00:24:09,960 --> 00:24:11,620 либо можете использовать компрещен с API, 291 00:24:12,060 --> 00:24:15,080 там параметра store нет, он ничего сам по себе не сохраняет, 292 00:24:15,480 --> 00:24:16,760 поэтому можно использовать его. 293 00:24:17,460 --> 00:24:20,900 Если это чатовый сценарий, вам необходимо указать store равно true, 294 00:24:20,900 --> 00:24:26,340 это дефолтное значение для параметра store в responses API, 295 00:24:26,800 --> 00:24:29,540 оно как раз используется, вам нужно для чатовых сценарий, 296 00:24:29,800 --> 00:24:32,000 то есть когда происходит обращение с этим параметром, 297 00:24:32,580 --> 00:24:34,760 запрос и ответ сохраняются, 298 00:24:35,340 --> 00:24:39,220 и затем используется для того, чтобы отвечать на следующие сообщения 299 00:24:39,220 --> 00:24:41,860 с учетом контекста, с учетом истории переписки. 300 00:24:42,900 --> 00:24:47,960 И если у вас агентский цикл, в котором много вызовов инструментов, 301 00:24:48,340 --> 00:24:50,520 этот агентский цикл реализует сам responses API, 302 00:24:50,720 --> 00:24:53,560 если вам нужно, чтобы он автоматически вызывал инструменты, 303 00:24:54,020 --> 00:24:56,640 вы обращаетесь в responses с подключенным параметром tool, 304 00:24:57,080 --> 00:24:59,500 которым вы можете задать либо инструменты, 305 00:24:59,580 --> 00:25:01,540 которые доступны в платформе, как бы уже готовые, 306 00:25:01,540 --> 00:25:04,740 либо подключить свои функции, если есть такая необходимость. 307 00:25:05,340 --> 00:25:11,620 Давайте теперь более подробно углубимся в работу с контекстом в responses API. 308 00:25:12,740 --> 00:25:18,400 Если нет необходимости как-то управлять контекстом, 309 00:25:18,520 --> 00:25:20,680 то можно использовать completions, 310 00:25:21,080 --> 00:25:23,920 там нет никакого автоматического сохранения контекста, 311 00:25:24,540 --> 00:25:29,800 всю обвязку, всю внешнюю логику передачи предыдущих сообщений, 312 00:25:29,800 --> 00:25:33,900 передачи вызовов, тулов и так далее, вам необходимо реализовать самостоятельно. 313 00:25:34,240 --> 00:25:40,240 Как правило, какая-то уже реализация есть во фреймворках типа лангграфа, лангчейн и так далее, 314 00:25:40,640 --> 00:25:43,600 но это то, что происходит не на стороне самой студии. 315 00:25:44,280 --> 00:25:49,640 В Responsys API как раз его ключевое отличие, во-первых, что он может хранить эту историю переписки, 316 00:25:50,060 --> 00:25:55,040 использовать ее и, как мы увидим дальше, работать с этой историей для оптимизации, 317 00:25:55,040 --> 00:26:01,140 например, использования токенов или для минимизации ошибок вроде переполнения контекста модели. 318 00:26:02,200 --> 00:26:03,580 Далее у нас есть развилка. 319 00:26:03,840 --> 00:26:11,880 Если параметр store установлен на false, то, опять же, запросы не хранятся, никакой чатовый сценарий из коробки невозможно. 320 00:26:12,560 --> 00:26:18,880 Если store равно true, то запросы и респонсы сохраняются, и вам становится доступен контекст сессии. 321 00:26:19,580 --> 00:26:23,320 Дальше встает вопрос, а как этим контекстом сессии можно воспользоваться? 322 00:26:23,320 --> 00:26:26,000 И здесь доступны два варианта. 323 00:26:26,580 --> 00:26:41,260 Это вариант использовать параметр previous response id, либо использовать отдельный API, conversations API, для создания управления сессиями, и использовать эту сессию, которая создается через conversations API. 324 00:26:43,320 --> 00:26:48,900 Давайте посмотрим на базовые различия. 325 00:26:48,900 --> 00:27:01,280 По сути, conversations API — это отдельный объект сессии, который вы эксплицитно создаете, указываете при обращении в responses, и в этот conversation добавляются новые сущности. 326 00:27:01,420 --> 00:27:06,760 То есть все общение, все запросы, ответы, информация талаг добавляются в этот conversation. 327 00:27:07,400 --> 00:27:21,840 Соответственно, вы можете его создавать, удалять, добавлять какие-то свои текстовые, или, например, вы хотите выгрузить всю историю, саморизировать ее самостоятельно каким-то образом и загрузить обратно в виде одного сообщения. 328 00:27:22,160 --> 00:27:26,000 Все это удобно сделать в conversations API, то есть он это все позволяет сделать. 329 00:27:26,560 --> 00:27:29,100 Previous response ID немножко по-другому работает. 330 00:27:29,100 --> 00:27:38,160 Здесь это выглядит следующим образом: вы делаете запрос в responses, в ответ вы получаете response, который будет содержать какой-то ID. 331 00:27:38,160 --> 00:27:53,340 При следующем обращении в responses вы можете передать параметр previous response ID и там должно быть значение как бы ID предыдущего ответа, то есть ID предыдущего response. 332 00:27:53,340 --> 00:28:12,540 Вот, соответственно, в этом случае он автоматически, response API автоматически подтягивает предыдущий запрос и все остальные запросы, которые как бы выстраиваются по цепочке, да, и использует их, передает в контекст модели, и модель отвечает с учетом вот этой всей истории и всего этого контекста. 333 00:28:12,540 --> 00:28:25,100 То есть и в Conversations, и в PreviousResponseId подтягивается весь контекст, передается в модель, как входные токены или там кэш-токены, если история закэшировалась, и, соответственно, дальше генерируется ответ. 334 00:28:26,180 --> 00:28:33,140 Да, давайте подробнее посмотрим, как это выглядит через код и как выглядят результаты. 335 00:28:34,400 --> 00:28:34,960 Спасибо. 336 00:28:38,200 --> 00:28:51,900 Итак, вот у нас есть пример кода, в котором как раз реализовано создание, использование цепочки респонсов через ID предыдущего респонса. 337 00:28:52,720 --> 00:28:59,780 То есть, вот в ячейке четвертый у нас первый респонс, в котором мы делаем какой-то запрос. 338 00:29:00,560 --> 00:29:06,680 В следующей ячейке мы делаем запрос, который, ну, по идее, должен учитывать контекст предыдущий. 339 00:29:06,680 --> 00:29:09,160 Ну, давайте посмотрим, как это работает. 340 00:29:11,000 --> 00:29:12,360 Выполним ячейки. 341 00:29:22,020 --> 00:29:27,300 Вот у нас выполнился первый запрос. 342 00:29:29,720 --> 00:29:31,620 И выполнился второй. 343 00:29:31,620 --> 00:29:36,500 Ну, и вот во втором у нас был контекст из первого. 344 00:29:36,500 --> 00:29:38,100 Видим, что все передалось. 345 00:29:38,100 --> 00:29:52,260 У нас в UI, в интерфейсе AI-студию, появилась возможность просмотра вот этих сохраненных диалогов, которые есть. 346 00:29:52,260 --> 00:29:59,260 То есть в разделе логирование есть список диалогов, и там есть раздел «Перейти к респонсам». 347 00:29:59,260 --> 00:30:07,260 Давайте посмотрим как раз респонсы, которые были, и вот последний, который было исполнение. 348 00:30:07,260 --> 00:30:13,260 Вот здесь можно посмотреть, как оно шло со всеми параметрами, ответами. 349 00:30:13,260 --> 00:30:19,260 И здесь же есть, можно посмотреть, как это выглядит уже отрендерено в красивом виде. 350 00:30:19,260 --> 00:30:23,260 И, собственно, есть как раз ссылочка на предыдущий идентификатор. 351 00:30:23,260 --> 00:30:29,260 Можно прийти к предыдущему запросу, к предыдущему респонсу, и там увидеть все то же самое. 352 00:30:33,260 --> 00:30:39,260 Теперь давайте посмотрим, как работает, когда мы используем вариант с conversation. 353 00:30:39,260 --> 00:30:46,260 Conversation, как уже частично сказал Дима, тут я чуть-чуть дорасскажу. 354 00:30:46,260 --> 00:30:50,260 То есть, создавая объект conversation, мы туда можем сразу занести какой-то... 355 00:30:50,260 --> 00:30:55,260 Во-первых, там сохраняется контекст переписки, плюс мы можем заранее, ну или во время работы, 356 00:30:55,260 --> 00:30:59,260 занести туда контекст, записав прямо как один из элементов. 357 00:30:59,260 --> 00:31:05,260 В данном случае здесь вот как бы контекст, который... запомни контекст этого диалога. 358 00:31:05,260 --> 00:31:11,260 Вот. Также в conversations API есть способы посмотреть, какой контекст там есть, 359 00:31:11,260 --> 00:31:15,260 обновить этот контекст, ну и удалить весь объект conversation. 360 00:31:15,260 --> 00:31:19,260 Давайте посмотрим, как это работает. 361 00:31:19,260 --> 00:31:21,260 Опять же, пример кода. 362 00:31:21,260 --> 00:31:24,260 У нас в одной ячейке создается conversation. 363 00:31:24,260 --> 00:31:26,260 Туда записывается какой-то контекст. 364 00:31:26,260 --> 00:31:28,260 Меня зовут Сергей, кто я? 365 00:31:28,260 --> 00:31:36,260 И тут же указание, что мы говорим об Яндексе iStudio. 366 00:31:36,260 --> 00:31:44,260 И дальше мы делаем обращение в response API с указанием ID этого conversation. 367 00:31:44,260 --> 00:31:52,260 Давайте посмотрим, как это работает. 368 00:31:52,260 --> 00:31:57,260 Вот нам выдалось ID conversation, оно перебылось в следующую ячейку. 369 00:31:57,260 --> 00:32:01,260 Вот оно исполнилось. Как видите, весь контекст есть. 370 00:32:01,260 --> 00:32:06,260 Соответственно, ответ уже был на основе этого контекста. 371 00:32:06,260 --> 00:32:11,260 И давайте тоже посмотрим, как это выглядит в UI. 372 00:32:11,260 --> 00:32:14,260 В списке диалогов есть отдельно конверсейшены. 373 00:32:14,260 --> 00:32:16,260 Вот наш последний конверсейшен. 374 00:32:16,260 --> 00:32:25,260 Здесь видны все запросы и первоначально то, что мы указывали при создании конверсейшена. 375 00:32:25,260 --> 00:32:28,260 И тут же можно увидеть ID конверсейшена. 376 00:32:28,260 --> 00:32:31,260 И, как видите, в каждой строчке еще есть ссылочка на переход. 377 00:32:31,260 --> 00:32:36,260 Можно прямо перейти в конкретный респонс, который в этот конверсейшен входит. 378 00:32:38,260 --> 00:32:42,260 Давайте еще расскажу про такую функциональность. 379 00:32:42,260 --> 00:32:49,260 iStudio позволяет автоматически обрезать контекст для того, 380 00:32:49,260 --> 00:32:53,260 чтобы избежать переполнения контекста той или иной модели. 381 00:32:53,260 --> 00:32:57,260 В респонсе с API есть такой параметр Truncation. 382 00:32:57,260 --> 00:33:03,260 Если его выставить в значение авто, то включится вот это автоматическое обрезание. 383 00:33:03,260 --> 00:33:10,260 При этом нужно учитывать, что мы обрезаем самые старые части контекста, 384 00:33:10,260 --> 00:33:17,260 но системная инструкция и объявление инструментов остается неизменным. 385 00:33:17,260 --> 00:33:23,260 Еще нужно учесть такую вещь, что при вырезании мы удаляем, 386 00:33:23,260 --> 00:33:28,260 если там были инструменты как вызов инструмента, так и его ответ. 387 00:33:28,260 --> 00:33:37,260 Еще важное замечание, что для скорости мы примерно оцениваем сколько будет занимать запрос. 388 00:33:37,260 --> 00:33:44,260 Возможно, в некоторых случаях чуть-чуть неправильный расчет, 389 00:33:44,260 --> 00:33:50,260 поэтому нет стопроцентной гарантии, что при включении авто мы точно попадем в контекст. 390 00:33:50,260 --> 00:33:54,260 Это очень сильно повышает вероятность, что это будет все хорошо. 391 00:33:54,260 --> 00:34:07,260 Что еще тут нужно отметить, что при включении обрезания контекста возможно влияние на кэширование. 392 00:34:07,260 --> 00:34:09,260 Но про кэширование я расскажу чуть позже. 393 00:34:09,260 --> 00:34:18,260 В AI-студии в некоторых моделях поддерживается кэширование. 394 00:34:18,260 --> 00:34:20,260 Кэширование срабатывает автоматически. 395 00:34:20,260 --> 00:34:26,260 Как оно работает в начале запроса? 396 00:34:26,260 --> 00:34:31,260 Повторяющаяся часть промта, если есть такая возможность, 397 00:34:31,260 --> 00:34:32,260 оно кэшируется. 398 00:34:32,260 --> 00:34:36,260 Гарантии, что точно попадет в кэш, дать никто не может. 399 00:34:36,260 --> 00:34:39,260 Оно может сработать, может нет. 400 00:34:39,260 --> 00:34:42,260 И почему я, когда я рассказал про Truncation, 401 00:34:42,260 --> 00:34:46,260 сказал, что очень важно обратить внимание на кэширование. 402 00:34:46,260 --> 00:34:55,260 Так как отрезается самая старая часть, то получается, что начальный повторяющийся кусок запроса будет меняться. 403 00:34:55,260 --> 00:35:01,260 Поэтому использование Truncation ухудшает кэшируемость. 404 00:35:01,260 --> 00:35:07,260 Как повысить вероятность того, что кэширование сработает? 405 00:35:07,260 --> 00:35:14,260 Во-первых, старайтесь как можно больше заносить часть запроса в системные инструкции. 406 00:35:14,260 --> 00:35:18,260 Потому что они в начале, как и объявление инструментов. 407 00:35:18,260 --> 00:35:22,260 Поэтому они будут повторяться при каждом запросе. 408 00:35:22,260 --> 00:35:25,260 Поэтому лучше, чтобы там было занесено. 409 00:35:25,260 --> 00:35:28,260 Когда пишете промт, тестируйте попадание в кэш. 410 00:35:28,260 --> 00:35:33,260 То есть делайте достаточно большое количество запросов и смотрите, как оно отрабатывает. 411 00:35:33,260 --> 00:35:35,260 Ну и вообще, что попало в кэш, что нет. 412 00:35:35,260 --> 00:35:39,260 Можно оценить как по биллингу, потому что токены закэшированы. 413 00:35:39,260 --> 00:35:42,260 Они билятся по отдельному СКЮ, их видно. 414 00:35:42,260 --> 00:35:49,260 Так, и в разделе «Мониторинг», я чуть-чуть позже расскажу подробнее про него, 415 00:35:49,260 --> 00:35:56,260 в нем тоже можно увидеть кэшированный токен. 416 00:35:56,260 --> 00:36:02,260 Давайте еще расскажу про хранение запросов в Яндекс.АйС.Тудио. 417 00:36:02,260 --> 00:36:08,260 Там достаточно часто и много поступает вопросов, как это работает. 418 00:36:08,260 --> 00:36:12,260 Итак, смотрите, какие данные хранятся. 419 00:36:12,260 --> 00:36:16,260 Во-первых, хранится в каком-то виде кэш. 420 00:36:16,260 --> 00:36:20,260 Он хранится в уже вычисленном виде. 421 00:36:20,260 --> 00:36:24,260 Фактически это матрица с вычисленными цифрами. 422 00:36:24,260 --> 00:36:30,260 Она хранится на виртуальных машинах самого инференса. 423 00:36:30,260 --> 00:36:33,260 Фактически в состоянии вычисленной модели. 424 00:36:33,260 --> 00:36:36,260 Там нет ни текста запроса, восстановлению это не подлежит. 425 00:36:36,260 --> 00:36:39,260 Это чисто техническое такое хранение. 426 00:36:39,260 --> 00:36:42,260 Дальше, если мы используем Conversations API, 427 00:36:42,260 --> 00:36:46,260 то сам Conversation и все респонсы, которые к нему привязаны, 428 00:36:46,260 --> 00:36:49,260 они хранятся в течение 365 дней 429 00:36:49,260 --> 00:36:55,260 или пока вы сами с помощью API или с помощью UI не удалите этот Conversation. 430 00:36:55,260 --> 00:36:58,260 Ну и все, что с ним связано. 431 00:36:58,260 --> 00:37:03,260 В Responses API, опять же, Дима рассказывал про параметр Store. 432 00:37:03,260 --> 00:37:10,260 Как бы, если он в течение fails, то удаляется сразу. 433 00:37:10,260 --> 00:37:14,260 Если true, то данные хранятся 30 дней. 434 00:37:14,260 --> 00:37:18,260 Или, опять же, вы можете с помощью API или с помощью UI 435 00:37:18,260 --> 00:37:23,260 удалить респонс, когда вам это будет удобно. 436 00:37:23,260 --> 00:37:29,260 Важное замечание, что при указании StoreFiles запрос не сохраняется, 437 00:37:29,260 --> 00:37:33,260 но при этом и построение контекста диалога невозможно. 438 00:37:33,260 --> 00:37:35,260 Просто учитывайте это. 439 00:37:35,260 --> 00:37:43,260 Тут ничего не хранится, но и функциональность будет сильно вырезана. 440 00:37:43,260 --> 00:37:49,260 Чем вы можете управлять при использовании наших API? 441 00:37:49,260 --> 00:37:53,260 Истории сессий, истории диалогов с помощью Conversation API и Responses API. 442 00:37:53,260 --> 00:37:58,260 Вы можете создавать, редактировать, удалять. 443 00:37:58,260 --> 00:38:01,260 Данные в поисковых индексах с помощью VectorStore API. 444 00:38:01,260 --> 00:38:03,260 Соответственно, тоже вы можете ими управлять. 445 00:38:03,260 --> 00:38:05,260 Файлы files API. 446 00:38:05,260 --> 00:38:08,260 То есть то, что вы закачиваете, удаляете эти файлы. 447 00:38:08,260 --> 00:38:12,260 Файлы, которые получаются с помощью работы инструментов. 448 00:38:12,260 --> 00:38:15,260 То есть при работе код-интерпретёра, генерации картинок. 449 00:38:15,260 --> 00:38:20,260 Создаются какие-то файлы, они тоже складываются в хранилище. 450 00:38:20,260 --> 00:38:27,260 Ими можно управлять с помощью того же самого files API. 451 00:38:27,260 --> 00:38:32,260 Ещё тема, про которую тоже достаточно часто спрашивают. 452 00:38:32,260 --> 00:38:41,260 Какие виды логирования в Яндексе iStudio существуют и что каждый из них делает, что сохранится в этих логах. 453 00:38:41,260 --> 00:38:44,260 У нас есть аудитные логи. 454 00:38:44,260 --> 00:38:52,260 Все события, которые происходят при работе с iStudio, они сохраняются как раз как аудитные события. 455 00:38:52,260 --> 00:39:07,260 И если вам необходимо для расследований или просто для анализа, вы можете с помощью сервиса Яндекс.Аудит.Трейлс настроить выгрузку в трейл и дальше как-то обрабатывать эти события. 456 00:39:07,260 --> 00:39:13,260 Список событий, которые туда откладываются, есть в нашей документации. 457 00:39:13,260 --> 00:39:31,260 Есть логи сервиса, то есть сервис, когда работает, он сохраняет какие-то логи, которые позволяют нам анализировать, как работает сервис, его здоровье, ну и как-то диагностировать то, что какие-то там происходят аномалии, неполадки при работе. 458 00:39:31,260 --> 00:39:54,280 Информация, как бы, это недоступно пользователям где-то в интерфейсе или по API, но при расследовании каких-то инцидентов, которые произошли у вас, вы можете запросить технической поддержки, и мы ту часть логов, которая касается ваших ресурсов, вашей работы, сможем так предоставить. 459 00:39:55,140 --> 00:40:02,540 Отмечу, что ни аудитные логи, ни логи сервиса не содержат никаких данных, запросов, ответов и какой-либо информации. 460 00:40:03,320 --> 00:40:19,020 И вот совсем недавно у нас появился в разделе логирования трейсы, это делается с помощью сервиса Monium, Яндекс.Аи.Студия при работе с Completions API и с Responses API, 461 00:40:19,020 --> 00:40:29,020 туда отправляет логи запросов и ответов, которые можно использовать для мониторинга работы, для оценки качества и для какого-то дебанга. 462 00:40:32,020 --> 00:40:35,020 Давайте я расскажу как раз про этот компонент трейсинг чуть больше. 463 00:40:38,020 --> 00:40:41,020 Мы записали небольшое видео, демонстрирующее. 464 00:40:41,020 --> 00:40:47,020 Вот у меня создан какой-то агент, я сделаю несколько запросов в него. 465 00:40:52,020 --> 00:40:56,020 В данный момент у меня срабатывают инструменты, которые MCP подключены. 466 00:40:57,020 --> 00:40:59,020 Вот получил какой-то ответ. 467 00:41:00,020 --> 00:41:04,020 Тут у нас есть иконочка, которая открывает закладку мониторинга и трейсов. 468 00:41:05,020 --> 00:41:18,020 Прямо здесь я могу увидеть всю цепочку, которая была, вызовов модели, вызовов инструменты, с какими параметрами, что было в ответе. 469 00:41:19,020 --> 00:41:26,020 Также в разделе логирования есть закладка трейсы, там можно увидеть то же самое, но уже по всем агентам. 470 00:41:27,020 --> 00:41:32,020 В агенте я вижу именно относительно него, здесь я вижу список всех и точно так же могу просматривать. 471 00:41:35,020 --> 00:41:52,020 Функциональность трейсов, она по умолчанию выключена, чтобы она заработала, вам нужно перейти в раздел логирования и на плитке с трейсингом включить именно эту функциональность. 472 00:41:52,020 --> 00:42:01,020 Эта функциональность отдельно тарифицируется, тарификация идет по тарифам, описанным в сервисе Monium. 473 00:42:01,020 --> 00:42:11,020 Ну, опять же, в любой момент вы можете ее выключить в том же самом месте, где и включается. 474 00:42:11,020 --> 00:42:18,020 Еще, как я вот и чуть раньше рассказал, мы обновили раздел «Мониторинг». 475 00:42:18,020 --> 00:42:24,020 Мы добавили тут дашборды, которые вы давно просили. 476 00:42:24,020 --> 00:42:27,020 Немножко обновили дашборды, которые уже были. 477 00:42:27,020 --> 00:42:31,020 И добавили инструменты для фильтрации. 478 00:42:31,020 --> 00:42:37,020 То есть, если вы сейчас посмотрите, у нас есть здесь метод и модели. 479 00:42:37,020 --> 00:42:43,020 В этих дропдаунах можно как раз получить по конкретным методам обращения в API 480 00:42:43,020 --> 00:42:48,020 или по конкретной модели отфильтровать метрики. 481 00:42:48,020 --> 00:42:57,020 Давайте посмотрим. 482 00:42:57,020 --> 00:43:01,020 Для работы с Completions и Responses надо выбирать OpenAI Completion. 483 00:43:01,020 --> 00:43:06,020 В данном случае я выбрал модель DeepSeq V4 Flash. 484 00:43:06,020 --> 00:43:12,020 Здесь можно увидеть запросы, можно увидеть кэшированные токены, 485 00:43:12,020 --> 00:43:17,020 входящие токены, выходящие, время до генерации первого токена. 486 00:43:17,020 --> 00:43:21,020 И вот очень важная часть - это мы добавили сюда квоты. 487 00:43:21,020 --> 00:43:25,020 Например, здесь самый первый график - это параллельные генерации. 488 00:43:25,020 --> 00:43:30,020 Там видно и квоту, и видно, сколько в данный момент от этой квоты потребляется. 489 00:43:34,020 --> 00:43:38,020 Таким образом, давайте подведу небольшой итог обновлений, 490 00:43:38,020 --> 00:43:41,020 которые произошли в iStudio за последнее время. 491 00:43:41,020 --> 00:43:46,020 Если вы следите за развитием, то, наверное, точно стоит 492 00:43:46,020 --> 00:43:51,020 попробовать - это использование параметра Truncation 493 00:43:51,020 --> 00:43:54,020 для автоматического отрезания контекста, 494 00:43:54,020 --> 00:43:57,020 чтобы не происходило ошибки с переполнением 495 00:43:57,020 --> 00:44:00,020 контекста при обращениях в модель. 496 00:44:00,020 --> 00:44:02,020 Это большое количество новых разделов 497 00:44:02,020 --> 00:44:04,020 вокруг мониторинга и логирования, 498 00:44:04,020 --> 00:44:06,020 то есть смотреть на тресы, которые 499 00:44:06,020 --> 00:44:08,020 происходят при работе агента, 500 00:44:08,020 --> 00:44:12,020 следить за квотами, следить за временем 501 00:44:12,020 --> 00:44:14,020 до первого токена и так далее. 502 00:44:14,020 --> 00:44:16,020 Теперь все это наглядно видно в UI 503 00:44:16,020 --> 00:44:18,020 и поможет получить вам больше прозрачности 504 00:44:18,020 --> 00:44:22,020 при работе с агентами, 505 00:44:22,020 --> 00:44:24,020 с API и так далее. 506 00:44:24,020 --> 00:44:26,020 Тут еще, наверное, важно сказать, 507 00:44:26,020 --> 00:44:28,020 что вот эта вся информация по тресам, 508 00:44:28,020 --> 00:44:30,020 по мониторам и так далее, 509 00:44:30,020 --> 00:44:32,020 она не относится только к UI, 510 00:44:32,020 --> 00:44:34,020 то есть не только к тем запросам, 511 00:44:34,020 --> 00:44:36,020 которые были сделаны через UI, 512 00:44:36,020 --> 00:44:38,020 она относится ко всем запросам, 513 00:44:38,020 --> 00:44:40,020 которые вы делаете в API в рамках вашего фолдера. 514 00:44:40,020 --> 00:44:42,020 То есть видимость всей этой информации 515 00:44:42,020 --> 00:44:44,020 и вы это можете там посмотреть, 516 00:44:44,020 --> 00:44:46,020 то есть независимо от того, 517 00:44:46,020 --> 00:44:50,020 в интерфейсе или в API вы используете модели. 518 00:44:50,020 --> 00:44:56,020 Да, на самом деле запрос про трейсинг и про мониторинг 519 00:44:56,020 --> 00:44:59,020 это то, с чем вы к нам приходили в комьюнити 520 00:44:59,020 --> 00:45:02,020 или там при личном общении. 521 00:45:02,020 --> 00:45:04,020 Нам этот фидбэк очень важен 522 00:45:04,020 --> 00:45:06,020 и запросы на появление новых вичей 523 00:45:06,020 --> 00:45:08,020 мы тоже внимательно отслеживаем. 524 00:45:08,020 --> 00:45:10,020 Поэтому спасибо, что делитесь. 525 00:45:10,020 --> 00:45:12,020 Еще одна площадка, про которую 526 00:45:12,020 --> 00:45:14,020 мы раньше не особо подробно рассказывали 527 00:45:14,020 --> 00:45:16,020 но тоже призываем 528 00:45:16,020 --> 00:45:18,020 на ней предлагать ваши идеи 529 00:45:18,020 --> 00:45:20,020 это отдельная 530 00:45:20,020 --> 00:45:22,020 страница 531 00:45:22,020 --> 00:45:24,020 на сайте Яндекс Клауд 532 00:45:24,020 --> 00:45:26,020 тоже вы можете перейти на нее по 533 00:45:26,020 --> 00:45:28,020 ссылке или по QR-коду 534 00:45:28,020 --> 00:45:30,020 предлагайте ваши идеи 535 00:45:30,020 --> 00:45:32,020 и чего не хватает на ваш взгляд в iStudio 536 00:45:32,020 --> 00:45:34,020 мы их обязательно отсматриваем 537 00:45:34,020 --> 00:45:36,020 и самые частые 538 00:45:36,020 --> 00:45:38,020 самые важные идеи стараемся 539 00:45:38,020 --> 00:45:40,020 запланировать и максимально быстро реализовать 540 00:45:40,020 --> 00:45:42,020 в платформе 541 00:45:42,020 --> 00:45:44,020 на этом у нас по 542 00:45:44,020 --> 00:45:46,020 основному материалу вебинару 543 00:45:46,020 --> 00:45:48,020 все, спасибо вам большое 544 00:45:48,020 --> 00:45:50,020 приглашаем 545 00:45:50,020 --> 00:45:52,020 на следующие вебинары сессии 546 00:45:52,020 --> 00:45:54,020 а сейчас готовы ответить 547 00:45:54,020 --> 00:45:56,020 на ваши вопросы, вижу что 548 00:45:56,020 --> 00:45:58,020 довольно много их появилось в чате 549 00:45:58,020 --> 00:46:00,020 так 550 00:46:00,020 --> 00:46:02,020 да, первый 551 00:46:02,020 --> 00:46:04,020 вопрос это 552 00:46:04,020 --> 00:46:06,020 вы исправили багу сохранения предактированного файла 553 00:46:06,020 --> 00:46:08,020 чтобы он не пересоздавался, а дозаписывался 554 00:46:08,020 --> 00:46:10,020 вот, я если честно не очень 555 00:46:10,020 --> 00:46:14,020 помню о какой именно баге идет речь 556 00:46:14,020 --> 00:46:16,020 я тоже не помню именно такой 557 00:46:16,020 --> 00:46:18,020 но 558 00:46:18,020 --> 00:46:20,020 в принципе все 559 00:46:20,020 --> 00:46:22,020 обращения в поддержку с какими-то багами 560 00:46:22,020 --> 00:46:24,020 которые есть, нами обрабатываются 561 00:46:24,020 --> 00:46:26,020 берутся в работу 562 00:46:26,020 --> 00:46:28,020 и если 563 00:46:28,020 --> 00:46:30,020 как бы вы не писали, а 564 00:46:30,020 --> 00:46:32,020 готовы сейчас описать этот баг 565 00:46:32,020 --> 00:46:34,020 через обращение, мы обязательно его исправим 566 00:46:34,020 --> 00:46:36,020 честно говоря, открытого такого бага я не помню 567 00:46:36,020 --> 00:46:38,020 да, аналогично 568 00:46:38,020 --> 00:46:40,020 да, если я хочу 569 00:46:40,020 --> 00:46:42,020 сохранить контекст только за сегодняшний день 570 00:46:42,020 --> 00:46:44,020 учитывать при ответе, а в прошлые 571 00:46:44,020 --> 00:46:46,020 дни просто самозировать, как я это могу сделать 572 00:46:46,020 --> 00:46:48,020 ну, наверное, тут 573 00:46:48,020 --> 00:46:50,020 рекомендация 574 00:46:50,020 --> 00:46:52,020 использовать как раз 575 00:46:52,020 --> 00:46:54,020 conversations API, то есть 576 00:46:54,020 --> 00:46:56,020 вы создаете объект conversation 577 00:46:56,020 --> 00:46:58,020 указываете его при обращении в responses 578 00:46:58,020 --> 00:47:00,020 и дальше у каждого айтема conversation 579 00:47:00,020 --> 00:47:02,020 есть мета 580 00:47:02,020 --> 00:47:04,020 и вы можете 581 00:47:04,020 --> 00:47:06,020 отфильтровать по мете, например, чтобы в conversation 582 00:47:06,020 --> 00:47:08,020 остались только те сообщения 583 00:47:08,020 --> 00:47:10,020 которые произошли сегодня 584 00:47:10,020 --> 00:47:12,020 те сообщения, которые были за предыдущие дни 585 00:47:12,020 --> 00:47:14,020 вы можете просто удалить 586 00:47:14,020 --> 00:47:16,020 из conversation, или забрать их 587 00:47:16,020 --> 00:47:18,020 отправить в модельку для самморизации 588 00:47:18,020 --> 00:47:20,020 и подложить как новый айтем 589 00:47:20,020 --> 00:47:22,020 с самморизацией 590 00:47:26,020 --> 00:47:28,020 в каком случае нужно работать через 591 00:47:28,020 --> 00:47:30,020 агентский API, в каком через интерфейс, в каком 592 00:47:30,020 --> 00:47:32,020 через ДК 593 00:47:32,020 --> 00:47:34,020 я расскажу 594 00:47:34,020 --> 00:47:36,020 добавляй 595 00:47:36,020 --> 00:47:38,020 на самом деле это зависит 596 00:47:38,020 --> 00:47:40,020 сильно от вашего сценария 597 00:47:40,020 --> 00:47:42,020 мы продуктово рассматриваем интерфейс 598 00:47:42,020 --> 00:47:44,020 скорее как способ 599 00:47:44,020 --> 00:47:46,020 поэкспериментировать, потестировать 600 00:47:46,020 --> 00:47:48,020 собрать первое решение 601 00:47:48,020 --> 00:47:50,020 перед тем как использовать 602 00:47:50,020 --> 00:47:52,020 по API 603 00:47:52,020 --> 00:47:54,020 простая точка входа в возможности сервиса 604 00:47:54,020 --> 00:47:56,020 и дальше настройка 605 00:47:56,020 --> 00:47:58,020 всех мониторов, трейсингов 606 00:47:58,020 --> 00:48:00,020 все это удобно делать через интерфейс 607 00:48:00,020 --> 00:48:02,020 само взаимодействие 608 00:48:02,020 --> 00:48:04,020 основное предполагается 609 00:48:04,020 --> 00:48:06,020 через API, если 610 00:48:06,020 --> 00:48:08,020 ваш клиент 611 00:48:08,020 --> 00:48:10,020 то приложение, из какого 612 00:48:10,020 --> 00:48:12,020 идет обращение в 613 00:48:12,020 --> 00:48:14,020 API моделей 614 00:48:14,020 --> 00:48:16,020 если удобно, вы можете 615 00:48:16,020 --> 00:48:18,020 использовать 616 00:48:18,020 --> 00:48:20,020 API напрямую, SDK 617 00:48:20,020 --> 00:48:22,020 это скорее упрощение разработки 618 00:48:22,020 --> 00:48:24,020 то есть в плане SDK 619 00:48:24,020 --> 00:48:26,020 мы рекомендуем использовать 620 00:48:26,020 --> 00:48:28,020 OpenAI на SDK, так как они совместимы 621 00:48:28,020 --> 00:48:30,020 с API, response, realtime 622 00:48:30,020 --> 00:48:32,020 и так далее, то есть например для 623 00:48:32,020 --> 00:48:34,020 просто взаимодействия можно использовать 624 00:48:34,020 --> 00:48:36,020 OpenAI просто SDK 625 00:48:36,020 --> 00:48:38,020 если у вас какая-то более сложная 626 00:48:38,020 --> 00:48:40,020 логика с саб-агентами 627 00:48:40,020 --> 00:48:42,020 хэнд-оффами 628 00:48:42,020 --> 00:48:44,020 более сложными агентскими цепочками 629 00:48:44,020 --> 00:48:46,020 можно использовать OpenAI 630 00:48:46,020 --> 00:48:48,020 Agents SDK, он как раз 631 00:48:48,020 --> 00:48:50,020 реализует вот это вот механизм 632 00:48:50,020 --> 00:48:52,020 например передачи хэнд-оффов 633 00:48:52,020 --> 00:48:54,020 от одного агента к другому и так далее 634 00:48:54,020 --> 00:48:56,020 то есть все это также работает 635 00:48:56,020 --> 00:48:58,020 поверх response API 636 00:48:58,020 --> 00:49:00,020 можете использовать LongChain, LongGraph 637 00:49:00,020 --> 00:49:02,020 другие инструменты, все это также возможно 638 00:49:02,020 --> 00:49:04,020 то есть тут уже в плане удобства разработки 639 00:49:04,020 --> 00:49:06,020 и тех конечных систем, из которых 640 00:49:06,020 --> 00:49:08,020 будет происходить обращение в 641 00:49:08,020 --> 00:49:10,020 модель 642 00:49:10,020 --> 00:49:12,020 да, потому что например SDK вот OpenAI 643 00:49:12,020 --> 00:49:14,020 я знаю точно питоновские есть, вроде JavaScript 644 00:49:14,020 --> 00:49:16,020 далеко не для всех бэкэндов 645 00:49:16,020 --> 00:49:18,020 там систем приложений 646 00:49:18,020 --> 00:49:20,020 эти языки подходят 647 00:49:20,020 --> 00:49:22,020 ну я чуть-чуть дополню, что 648 00:49:22,020 --> 00:49:24,020 как раз у нас в интерфейсе, если нажать посмотреть 649 00:49:24,020 --> 00:49:26,020 код, то мы предлагаем 650 00:49:26,020 --> 00:49:28,020 как раз и как обратиться прямо 651 00:49:28,020 --> 00:49:30,020 в API, так и на разных 652 00:49:30,020 --> 00:49:32,020 языках программирования с помощью 653 00:49:32,020 --> 00:49:34,020 SDK, ну то есть тут 654 00:49:34,020 --> 00:49:36,020 какое для вашего решения более 655 00:49:36,020 --> 00:49:38,020 удобно, более 656 00:49:38,020 --> 00:49:40,020 применимо 657 00:49:42,020 --> 00:49:44,020 что именно я могу узнать с помощью 658 00:49:44,020 --> 00:49:46,020 трейсов, да, трейсы 659 00:49:46,020 --> 00:49:48,020 наверное наибольшую 660 00:49:48,020 --> 00:49:50,020 полезность приносят как раз 661 00:49:50,020 --> 00:49:52,020 в плане работы с Responsys API 662 00:49:52,020 --> 00:49:54,020 почему, потому что Responsys API это 663 00:49:54,020 --> 00:49:56,020 по сути такой базовый агентский цикл 664 00:49:56,020 --> 00:49:58,020 да, то есть это 665 00:49:58,020 --> 00:50:00,020 когда происходит обращение в Responsys 666 00:50:00,020 --> 00:50:02,020 дальше начинается как бы работать цикл 667 00:50:02,020 --> 00:50:04,020 идет обращение в модель 668 00:50:04,020 --> 00:50:06,020 модель говорит, что нужно вызвать 669 00:50:06,020 --> 00:50:08,020 какие-то инструменты, дальше идет вызов 670 00:50:08,020 --> 00:50:10,020 этих инструментов, возвращается 671 00:50:10,020 --> 00:50:12,020 ответ от инструментов 672 00:50:12,020 --> 00:50:14,020 снова идет обращение в модель 673 00:50:14,020 --> 00:50:16,020 с результатом инструментов 674 00:50:16,020 --> 00:50:18,020 и так на самом деле может происходить много-много раз 675 00:50:18,020 --> 00:50:20,020 пока модель не решит, что все 676 00:50:20,020 --> 00:50:22,020 ответ готов, можно его вернуть 677 00:50:22,020 --> 00:50:24,020 пользователю. Соответственно, под капотом 678 00:50:24,020 --> 00:50:26,020 в Responses происходит много вот такой 679 00:50:26,020 --> 00:50:28,020 машинерии, которая не всегда прозрачна 680 00:50:28,020 --> 00:50:30,020 она может влиять на скорость 681 00:50:30,020 --> 00:50:32,020 ответа, может влиять на тарификацию 682 00:50:32,020 --> 00:50:34,020 может влиять на качество ответа 683 00:50:34,020 --> 00:50:36,020 и Trace как раз позволяет 684 00:50:36,020 --> 00:50:38,020 получить прозрачность, а что там в реальности 685 00:50:38,020 --> 00:50:40,020 происходит. То есть, когда вы 686 00:50:40,020 --> 00:50:42,020 открываете конкретный Trace Responses 687 00:50:42,020 --> 00:50:44,020 вы видите, сколько 688 00:50:44,020 --> 00:50:46,020 запросов в рамках этого Responses 689 00:50:46,020 --> 00:50:48,020 было в модель, вы видите 690 00:50:48,020 --> 00:50:50,020 с какими 691 00:50:50,020 --> 00:50:52,020 запросами, например, 692 00:50:52,020 --> 00:50:54,020 происходило обращение 693 00:50:54,020 --> 00:50:56,020 в инструменты. Ну, для примера, 694 00:50:56,020 --> 00:50:58,020 у вас есть простенькая 695 00:50:58,020 --> 00:51:00,020 сборка, да, Responses 696 00:51:00,020 --> 00:51:02,020 с подключенным Web Search Tool. 697 00:51:02,020 --> 00:51:04,020 Сам поисковый запрос в этот 698 00:51:04,020 --> 00:51:06,020 Web Search Tool формулирует модель. 699 00:51:06,020 --> 00:51:08,020 То есть, модель видит контекст переписки, 700 00:51:08,020 --> 00:51:10,020 видит запрос пользователя и сама 701 00:51:10,020 --> 00:51:12,020 формирует запрос, с которым будет 702 00:51:12,020 --> 00:51:14,020 происходить поиск. 703 00:51:14,020 --> 00:51:18,020 То есть, если вы просто 704 00:51:18,020 --> 00:51:20,020 обратитесь в response-ап и получите ответ, 705 00:51:20,020 --> 00:51:22,020 вы можете посмотреть, конечно, всю эту информацию, 706 00:51:22,020 --> 00:51:24,020 но просто в интерфейсе 707 00:51:24,020 --> 00:51:26,020 в тресах она более наглядная, 708 00:51:26,020 --> 00:51:28,020 вы можете фильтровать, искать, 709 00:51:28,020 --> 00:51:30,020 то есть, вы видите, с чем обращались 710 00:51:30,020 --> 00:51:32,020 в инструменты, какую информацию 711 00:51:32,020 --> 00:51:34,020 эти инструменты возвращали, 712 00:51:34,020 --> 00:51:36,020 что на вход, на выход 713 00:51:36,020 --> 00:51:38,020 поступало 714 00:51:38,020 --> 00:51:40,020 в модель во время работы 715 00:51:40,020 --> 00:51:42,020 вот этого агентского цикла. 716 00:51:42,020 --> 00:51:44,020 И, кроме этого, что важно, вы можете видеть 717 00:51:44,020 --> 00:51:46,020 тайминги. То есть, нам время от времени 718 00:51:46,020 --> 00:51:48,020 приходят запросы, что, вот, я там сделал 719 00:51:48,020 --> 00:51:50,020 обращение, у меня очень долго крутился 720 00:51:50,020 --> 00:51:52,020 мой запрос, что-то сломалось. 721 00:51:52,020 --> 00:51:54,020 И как раз Trace позволяет ответить на этот 722 00:51:54,020 --> 00:51:56,020 вопрос: что заняло 723 00:51:56,020 --> 00:51:58,020 время? То есть, время было именно 724 00:51:58,020 --> 00:52:00,020 в самой генерации модели, 725 00:52:00,020 --> 00:52:02,020 или, может быть, веб-поиск работал долго, 726 00:52:02,020 --> 00:52:04,020 или, может быть, вообще там просто произошло 727 00:52:04,020 --> 00:52:06,020 10 запросов веб-поиск, и 728 00:52:06,020 --> 00:52:08,020 пока они все поискались, обработались и так далее, 729 00:52:08,020 --> 00:52:10,020 на это ушло время. То есть, оно вам дает такую 730 00:52:10,020 --> 00:52:12,340 прозрачность работы, и, конечно, 731 00:52:12,540 --> 00:52:14,280 это первый этап для каких-то 732 00:52:14,280 --> 00:52:16,060 эвалов, то есть, для оценки качества 733 00:52:16,060 --> 00:52:18,420 поверх, ну, ваших 734 00:52:18,420 --> 00:52:19,980 агентов систем, да, то есть, 735 00:52:20,300 --> 00:52:22,260 это такая стартовая корзинка, 736 00:52:22,780 --> 00:52:24,460 набор запросов, на которой 737 00:52:24,460 --> 00:52:26,200 вы можете, там, оценивать качество, 738 00:52:26,320 --> 00:52:28,100 оценивать, что надо улучшить, там, 739 00:52:28,180 --> 00:52:30,280 что изменить в правде и так далее, то есть, позволяет вам 740 00:52:30,280 --> 00:52:32,140 работать над качеством и 741 00:52:32,140 --> 00:52:33,860 улучшать работу вашего 742 00:52:33,860 --> 00:52:35,000 агента. 743 00:52:35,860 --> 00:52:37,500 Да, тут добавишь что-то? 744 00:52:37,880 --> 00:52:39,380 Да, в принципе, ты все рассказал. 745 00:52:40,020 --> 00:52:46,340 О, следующий вопрос. Как можно отключить логирование данных, запросов и ответов, логи, обращений в модель? 746 00:52:46,880 --> 00:53:08,060 Ну, про часть логов я рассказывал уже чуть-чуть раньше, да, то есть, что касается трейсов, их можно включить, выключить, дальше у нас есть, собственно, само обращение в responses, там у нас есть параметр store-fels, но мы помним, что если мы его включаем, мы теряем часть функциональности, плюс у нас есть 747 00:53:08,060 --> 00:53:25,020 еще логирование данных, которые делаются для улучшения качества сервиса, в документации у нас описано, как это отключить, надо передать специальный хедер при запросе, и, соответственно, данные не будут сохраняться уже, и в этом случае тоже. 748 00:53:27,020 --> 00:53:44,340 Спасибо. Дальше, вопрос про тарификацию. По тарификации при использовании разных вариантов передачи прошлого контекста в Responses API, в частности, про объект conversation при создании чат-бот-диалогов. 749 00:53:45,120 --> 00:53:50,840 В таком случае переданный контекст не будет съедать повторно токены, которые уже были потрачены на прошлые сообщения диалога. 750 00:53:50,840 --> 00:53:55,660 Да, хороший вопрос, давайте тут подробнее расскажем, как именно устроена механика с тарификацией. 751 00:53:56,200 --> 00:54:03,920 На самом деле тарификация не будет зависеть, не зависит от того, используете ли вы conversation или используете previous response id. 752 00:54:04,380 --> 00:54:10,200 То есть в обоих сценариях механика работы, как передается контекст одинаковая, она не отличается. 753 00:54:11,600 --> 00:54:21,160 Выглядит это следующим образом, то есть тот контекст, который у вас лежит в виде каких-то сообщений, предыдущей истории, он передается в модель весь. 754 00:54:22,280 --> 00:54:28,600 Опять же, если не используется truncation, если не обрезается какая-то история, вот по дефолту, да, вот все, что сохранено, оно передается в модель. 755 00:54:29,240 --> 00:54:32,380 Но важно, чтобы модель видела этот диалог и могла ответить на вопрос. 756 00:54:33,400 --> 00:54:39,760 У нас вот этот, все, что передается в модель, тарифицируется как input токены. 757 00:54:39,880 --> 00:54:45,220 То есть, если вы смотрите на страницу тарификации, там четыре вида токенов, эти токены, они тарифицируются как input токены. 758 00:54:45,820 --> 00:54:46,860 Но есть одно но. 759 00:54:48,360 --> 00:54:57,340 Так как, то, что мы рассказывали, у нас есть на большинстве моделей кэш, например, на дипсик-флэш, если вы с ними работаете, у него есть кэш. 760 00:54:58,100 --> 00:55:01,060 И кэш токены тарифицируются иначе. 761 00:55:01,920 --> 00:55:09,980 И так как история диалога от запроса к запросу будет повторяться, то есть, вот этот префикс, история диалога, она не меняется. 762 00:55:10,140 --> 00:55:14,980 Особенно если, вот тут, наверное, важный момент, если вы используете встроенный механизм передачи контекста, 763 00:55:14,980 --> 00:55:19,260 то она точно не меняется, то есть, как она есть, она будет передаваться, как она есть. 764 00:55:19,400 --> 00:55:23,800 Если вы сами формируете контекст, там, не знаю, внешним фреймворком, самостоятельно строите, 765 00:55:24,080 --> 00:55:27,140 тут важно помнить, что вот этот префикс должен оставаться неизменным. 766 00:55:27,620 --> 00:55:32,160 Есть большая вероятность, что вот этот префикс, вот этот диалог, он закэшируется, 767 00:55:32,720 --> 00:55:39,680 и особенно если у вас запросы идут прям сразу друг за другом, там, не сегодня отправили запрос, потом через неделю, 768 00:55:39,780 --> 00:55:42,080 то есть, тут вероятность, что оно сохранится в кэше очень маленькая. 769 00:55:42,080 --> 00:55:49,700 Но если как бы запросы идут один за другим, то с большой вероятностью этот префикс закэшируется, 770 00:55:49,940 --> 00:55:56,020 и тарификация тогда будет происходить по токенам кэша, не по входящим токенам. 771 00:55:56,620 --> 00:56:02,640 Вот эту информацию о том, сколько токенов у вас пришлось на кэш, сколько на инпут и так далее, 772 00:56:02,720 --> 00:56:07,700 вы можете посмотреть в ответе от Responses по API, то есть, у вас прямо будет расшифровка, 773 00:56:07,700 --> 00:56:12,560 либо это все видно в биллинге, то есть, если вы переходите в мониторинг в биллинге, 774 00:56:12,780 --> 00:56:19,040 там будет у вас прямо разделено, сколько пришлось на кэш, сколько на инпут, аутпут, на тулы и так далее. 775 00:56:19,820 --> 00:56:20,960 Да, тут… 776 00:56:20,960 --> 00:56:25,740 Ну, чуть-чуть дополню, что, как я тоже показывал, теперь это и в мониторинге тоже видно, 777 00:56:25,960 --> 00:56:27,540 сколько кэшированных токенов было. 778 00:56:28,100 --> 00:56:28,260 Да. 779 00:56:28,500 --> 00:56:31,400 Вот, ну и чуть-чуть дополню по поводу Conversation. 780 00:56:31,400 --> 00:56:43,340 В принципе, как ты тоже упоминал, можно какую-то часть контекста суммаризировать, записать в виде item в сам Conversation и удалить их как бы и сами. 781 00:56:43,420 --> 00:56:46,760 Тогда они не будут снова уходить в контекст целиком, а будут уже суммаризации. 782 00:56:47,200 --> 00:56:49,360 Это на тарифы тоже повлияет. 783 00:56:49,660 --> 00:56:51,280 Да, да, да, это точно. 784 00:56:52,940 --> 00:56:56,540 Так, следующий вопрос. 785 00:56:56,540 --> 00:57:03,140 Так, у вас модель дипсик 4 флэш, у вас выделена модель дипсик 4 флэш. 786 00:57:03,480 --> 00:57:06,240 Правильно понимаешь, что данная модель развернута у вас на ресурсах, рамках ВРФ? 787 00:57:06,600 --> 00:57:08,540 Или происходит передача информации за границу? 788 00:57:09,680 --> 00:57:13,020 Ну, все модели, которые у нас представлены сейчас в AI-студии, 789 00:57:13,140 --> 00:57:18,640 они все развернуты в Яндекс.Облаке, в Российской Федерации, на наших серверах. 790 00:57:18,640 --> 00:57:24,340 За границу ничего не передается как за границу Российской Федерации, так и за границу облака. 791 00:57:24,600 --> 00:57:33,560 Да, то есть у нас все модели, у нас вообще нет моделей, которые ходят куда-то, передают данные за границу. 792 00:57:33,760 --> 00:57:36,900 То есть все на центрах обработки данных Яндекса, внутри РФ. 793 00:57:38,220 --> 00:57:47,120 И если говорить юридически, то у нас есть сертификаты ФСС-152 и так далее, которые это подтверждают. 794 00:57:47,900 --> 00:57:51,740 То есть мы не проксируем ни в какие другие модели. 795 00:57:53,660 --> 00:57:58,000 Есть ли решение для компаний со строгой политикой конфиденциальности данных? 796 00:57:58,120 --> 00:58:03,300 Есть ли решение для компаний со строгой политикой конфиденциальности данных? 797 00:58:04,120 --> 00:58:07,800 Есть, если короткий вопрос, короткий ответ. 798 00:58:08,260 --> 00:58:13,280 Если более подробно, тут, опять же, очень сильно зависит от политик внутри компании. 799 00:58:13,280 --> 00:58:19,600 То есть, как я сказал, у нас есть все необходимые сертификаты для обработки персональных данных в облаке. 800 00:58:20,300 --> 00:58:27,380 При этом понятно, что у каждой компании свои подходы, своя ситуация. 801 00:58:27,900 --> 00:58:29,300 Тут есть разные варианты. 802 00:58:30,040 --> 00:58:34,120 iStudio доступно для поставки полностью в он-прем закрытый контур. 803 00:58:34,220 --> 00:58:39,100 То есть, если есть необходимость поставить все эти компоненты, инструменты, 804 00:58:39,100 --> 00:58:43,500 про которые мы рассказывали локально, без выхода в интернет это возможно сделать. 805 00:58:44,040 --> 00:58:48,400 Есть гибридные варианты, когда, например, часть компонентов платформы, 806 00:58:48,480 --> 00:58:51,880 вроде рага, базы знаний ставится в контур, 807 00:58:51,880 --> 00:58:55,780 но при этом большие модели вроде дипсека используются из облака, 808 00:58:55,780 --> 00:58:59,880 по защищенному каналу, выделенному с настройками сети. 809 00:58:59,880 --> 00:59:02,880 Тут у нас очень много есть разных практик, подходов, 810 00:59:02,880 --> 00:59:08,280 как можно сделать настройки сети, сделать приватные изолированные сети. 811 00:59:08,280 --> 00:59:13,480 Мы не покрываем это отдельно в вебинарах, это такая довольно специфическая тонкая тема, 812 00:59:13,480 --> 00:59:16,660 но мы помогаем с настройкой, если у вас есть такие запросы, 813 00:59:16,660 --> 00:59:20,640 есть такие вещи, как выделенные приватные эндпоинты, 814 00:59:20,700 --> 00:59:22,320 по которым можно обращаться в модель, 815 00:59:22,740 --> 00:59:27,380 есть возможность ходить только внутри подсети облачной и так далее. 816 00:59:27,540 --> 00:59:34,120 В общем, тут много разных настроек, которые можно сделать все это возможно. 817 00:59:35,460 --> 00:59:39,580 Часть этого есть в разделе безопасность UI, есть документация, 818 00:59:39,680 --> 00:59:43,980 ну и можно просто обратиться в ту же, и мы подробно расскажем. 819 00:59:43,980 --> 00:59:46,620 Да, да, то есть вы можете написать там в сообществе, 820 00:59:46,920 --> 00:59:52,560 можно оставить заявку на сайте iStudio, там есть прям форума связаться с нами, 821 00:59:53,100 --> 00:59:56,980 там опишите проблему, мы свяжемся и отдельно можем там подробно рассказать, 822 00:59:57,080 --> 01:00:01,360 как все эти вещи, политики настраиваются. 823 01:00:03,200 --> 01:00:03,800 Так. 824 01:00:08,800 --> 01:00:12,920 Еще вопрос, что будет, если я передам запрос с ID старого Conversation, 825 01:00:12,920 --> 01:00:15,920 который уже удалился. Просто ошибка легенд видит просто без контекста. 826 01:00:16,660 --> 01:00:19,520 Так, ну, наверное, тут для надежности надо будет проверить, 827 01:00:19,640 --> 01:00:21,300 но с большой родности это будет ошибка. 828 01:00:21,380 --> 01:00:21,460 Да. 829 01:00:22,760 --> 01:00:26,880 Он просто упадет с ошибкой, что такого Conversation нет. 830 01:00:30,120 --> 01:00:33,500 Когда OpenAI совместимый интерфейс, значит, поддерживать фоновые запросы. 831 01:00:33,760 --> 01:00:36,400 Я так понимаю, речь идет про бэкграунд-режим. 832 01:00:38,080 --> 01:00:42,900 Он уже доступен, то есть, если вы будете использовать бэкграунд, 833 01:00:42,900 --> 01:00:49,580 он работает, он будет, он, тут, наверное, для тех, кто может чуть не в контексте, 834 01:00:49,720 --> 01:00:54,260 тут подсвечу, что у респонс-апи как бы по дефолту, 835 01:00:54,340 --> 01:00:56,560 когда вы его используете, используется синхронный режим, 836 01:00:56,720 --> 01:00:58,800 то есть, вы отправили запрос, сразу получаете ответ. 837 01:00:59,300 --> 01:01:02,220 Бэкграунд-режим, если эта настройка установлена, 838 01:01:02,420 --> 01:01:08,120 то он, как бы, запрос обрабатывается с каким-то лагом по времени, да, 839 01:01:08,120 --> 01:01:12,680 то есть, у нас бэкграунд-режим, в бэкграунд-режиме запрос может обрабатываться 840 01:01:12,680 --> 01:01:18,300 до 24 часов, но при этом вы не упираетесь в ограничения 841 01:01:18,300 --> 01:01:21,840 по параллельным генерациям дефолтные, то есть, у нас есть квота 842 01:01:21,840 --> 01:01:25,680 по параллельным генерациям, ее можно увеличивать через поддержку, 843 01:01:25,780 --> 01:01:28,600 но все равно там есть достаточно такие, ну, строгие лимиты, да, 844 01:01:28,640 --> 01:01:30,300 в которых эта квота может быть увеличена. 845 01:01:30,700 --> 01:01:33,680 Если вы разово, например, хотите закинуть, там, не знаю, 846 01:01:33,680 --> 01:01:39,000 10 тысяч запросов вот в моменте и готовы подождать, пока они обработаются, 847 01:01:39,140 --> 01:01:42,340 при этом не думать там о построении очереди, вы можете использовать бэкграунд-режим, 848 01:01:42,460 --> 01:01:48,460 он доступен уже сейчас, можете с ним работать, мы планируем его улучшать, 849 01:01:48,460 --> 01:01:51,460 делать доработки, об этом тоже будем отдельно рассказывать, 850 01:01:51,460 --> 01:01:55,460 но уже сейчас базово этот бэкграунд-режим доступен. 851 01:01:55,460 --> 01:01:57,460 Ну, фоновые запросы, если про них идет речь. 852 01:01:57,460 --> 01:02:05,460 Как лучше хранить память голосового агента, если он работает с одним клиентом несколько недель? 853 01:02:05,460 --> 01:02:09,460 Совершает несколько отдельных звонков, получает новые данные из CRM и решает, что делать дальше. 854 01:02:09,460 --> 01:02:14,460 Что нужно хранить отдельно, а что передавать VLM перед каждым звонком, чтобы контекст не становился слишком большим. 855 01:02:14,460 --> 01:02:25,460 На самом деле, в real-time API, в общем-то, хранение контекста реализовано похожим образом, как и в response API. 856 01:02:25,460 --> 01:02:34,460 Там есть ряд своих деталей, но я вам лучше рекомендую этот вопрос сохранить при посте на отдельный вебинар, который будет в real-time API. 857 01:02:34,460 --> 01:02:46,460 Он, по-моему, следующий в нашей серии. Там коллеги уже подробнее, детальнее расскажут, сколько хранятся данные в контексте, как они обрабатываются, как-то передавать. 858 01:02:46,460 --> 01:02:52,460 То есть предлагаю этот вопрос сохранить до следующей сессии, которая будет подробнее про real-time. 859 01:02:52,460 --> 01:02:55,460 Вот вопрос хороший. 860 01:02:55,460 --> 01:02:59,460 Вижу, что по вопросам пока все. 861 01:02:59,460 --> 01:03:03,460 Хотелось бы сказать большое спасибо, что подключились к этому первому вебинару. 862 01:03:03,460 --> 01:03:08,460 Надеюсь, что было интересно и остальные будут не менее интересные. 863 01:03:08,460 --> 01:03:11,460 Особенно заключительная часть. 864 01:03:11,460 --> 01:03:16,460 Предлагайте ваши проекты, будем очень рады их рассмотреть. 865 01:03:16,460 --> 01:03:19,460 И спасибо большое за ваше внимание.