Вебинар от 16 июля 2026. Спикеры: Дмитрий Рыбалко (руководитель группы развития ИИ-инструментов, Yandex AI Studio), Сергей Золотов (менеджер проектов, Yandex AI Studio). Длительность 1:03.
Первый вебинар летней серии для разработчиков. Практический разбор того, как выбирать между Responses API, Chat Completions и Realtime API, как управлять контекстом диалога (store, previous_response_id, Conversations API, truncation), как работает кэширование и тарификация токенов, что и сколько хранится на стороне платформы, и какие инструменты мониторинга и трейсинга появились в UI. Полезен разработчикам, которые уже строят агентов на AI Studio и упираются в переполнение контекста, непрозрачную тарификацию или отладку агентского цикла.
Серия из четырёх вебинаров: 16 июля — LLM и агентские API; 21 июля — голосовые интерфейсы (Realtime API); 23 июля — поисковые сервисы, RAG и веб-поиск; 28 июля — автоматизация процессов в Workflows (визуальный no-code инструмент, много обновлений на упрощение работы).
30 июля — фестиваль решений, программа по слайду: 17:00 — обновления Yandex AI Studio; 17:20 — от идеи до продакшена за два месяца: ИИ-продукт своими руками без разработчиков; 17:40 — архитектура масштабируемого контакт-центра на базе ИИ; 18:00 — разработка ИИ-продукта на базе LLM и агентских инструментов; 18:20 — мастер-класс: паттерны проектирования и типовые ошибки при создании ИИ-продуктов.
После каждого вебинара — тест на закрепление. Параллельно запущен челлендж «От идеи до запуска ИИ-решения в продакшен за 8 недель»: заявка с описанием проекта, целей и аудитории; отобранные команды в течение восьми недель получают консультации экспертов Yandex Cloud по разработке и запуску решения. Подробности челленджа — t.me/YFM_Community/5732/12287. Обзорные материалы «с нуля» здесь не повторяются — они были в предыдущей серии (ноябрь).
На слайде платформа изображена как трёхэтажная схема сверху вниз. Верхний этаж — «Бизнес-сценарии» (ИИ-агент / ИИ-приложение: чат, copilot, RAG, Workflows), внутри него три API: Responses API (помечен бейджем «Основной выбор»), Realtime API и Chat Completions API. Средний этаж — «Встроенные инструменты», которые расширяют возможности моделей: File Search, Web Search, MCP, Image Generation tool, Code Interpreter tool. Нижний этаж — «ИИ-примитивы», базовые модели и сервисы: Embeddings API, Image Generation API, Classification API. Стрелки идут сверху вниз: сценарии опираются на инструменты, инструменты — на примитивы.
Responses API — рекомендованный основной агентский API для текстовых сценариев: агенты, RAG, tool calling, structured output. На слайде-таблице у него прямая формулировка: «Основной API для новых проектов». Основное развитие текстового направления идёт вокруг него.
Realtime API — для голосовых сценариев, где критична низкая задержка между окончанием реплики пользователя и началом ответа агента (на слайде: «голосовые агенты и стриминг с минимальной задержкой»).
Chat Completions API — «запрос в модель — ответ от модели», без встроенных инструментов и без памяти. Удобен для одноразовых задач (суммаризация, анализ отзыва) и для интеграции с open-source фреймворками.
Все три API совместимы с форматом OpenAI — это сделано намеренно, чтобы open-source обвязка работала без доработок. На слайде «Интеграция с опенсорсом» рекомендованный способ работы — OpenAI SDK и OpenAI Agents SDK, и отдельными QR-кодами даны готовые инструкции по интеграции с n8n, OpenClaw, Open WebUI, LangChain и Roo Code.
Встроенные компоненты (доступны только через Responses API, частично через Realtime; в Chat Completions их нет):
- File Search — индексация и поиск по знаниям (RAG), векторные базы;
- Web Search — поиск актуальной информации в интернете;
- MCP — вызов ваших функций и внешних API, действия во внешних системах;
- Image Generation tool — генерация изображений (на схеме инструмент подписан как YandexART, а одноимённый API в слое примитивов — как Alice AI ART);
- Code Interpreter tool — выполнение кода, расчёты, анализ данных; код выполняется в изолированном контейнере, результат — файл, презентация и т. п.
09:32Какой API выбрать под задачу
Слайд «Какой API выбрать под сценарий?» — три колонки со стрелками сверху вниз:
- Разовое обращение (суммаризация, классификация) → Responses API (
store=false) либо Completions API (там параметра store вообще нет, ничего не сохраняется).
- Чатовый сценарий → Responses API (
store=true) (значение по умолчанию).
- Агентский цикл с инструментами → Responses API с параметром
tools — цикл реализуется самим API.
Structured Output поддерживают и Responses, и Chat Completions.
Вспомогательные API (по таблице «API, доступные в Yandex AI Studio»):
| API | Сценарий | Когда использовать |
|---|
| Responses API | ИИ-агенты, RAG, tool calling, structured output | Основной API для новых проектов |
| Realtime API | Голосовые ассистенты | Если есть аудио или voice-интерфейс |
| Chat Completions API | Простой чат с LLM | Если не нужны инструменты и агентная логика |
| Files API | Работа с файлами | Загрузка документов |
| Vector Stores API | Индексация знаний | Основа RAG |
| Embeddings API | Семантический поиск | Если строите собственный поиск |
| Image Generation API | Генерация изображений | Если нужен прямой вызов модели Alice AI ART |
| MCP Gateway API | Создание и управление MCP в MCP Hub | Автоматизация управления MCP-серверами |
Первые три сгруппированы на слайде как «LLM-модели», Files/Vector Stores — как «работа с файлами», Embeddings/Image Generation — как «другие модели». Files API нужен и для выгрузки файлов, созданных интерпретатором кода или генератором картинок. Vector Stores API — основной API для баз знаний: файлы автоматически парсятся и складываются в векторный индекс. Embeddings API — для собственной кастомной RAG-логики. MCP Gateway API (в речи — «API для MCP Hub») позволяет подключать внешние MCP-серверы или создавать свои поверх существующих API; управлять этим можно и через UI, и через API (например, для автоматизации добавления серверов).
13:37Сборка агента в UI и Agent ID
UI — точка входа для первичного тестирования, отладки и подбора промпта и конфигурации, а не для продакшена. В интерфейсе (раздел Agent Atelier → «Текстовые агенты»; рядом — «Голосовые агенты», «MCP-серверы», «Workflows») выбирается модель, инструкция, подключаются инструменты (MCP, веб-поиск, файловый поиск), затем «Посмотреть код» даёт готовый сниппет для встраивания.
На скриншоте карточки агента видны настройки: Модель — DeepSeek 4 Flash, «Формат ответа: Текст», «Температура: 0.3», «Максимум токенов в ответе: 6000», «Режим рассуждений: Авто», «Обрезание контекста: Нет». Инструкцию можно взять из заготовок («Ассистент-аналитик», «Ассистент поиска в интернете», «Ассистент технической поддержки»), а в тексте инструкции использовать переменные в фигурных скобках {{имя_переменной}}, чтобы переиспользовать один промпт. В блоке «Инструменты» подключён MCP-сервер (tracker-mcp-demo) с явным списком разрешённых инструментов (BulkMove, BulkTransition, BulkUpdate).
При сохранении конфигурации создаётся идентификатор, который в UI называется Agent ID (в речи звучал как PromptID). В API он передаётся в responses.create в поле prompt как объект {"id": "..."} — (на слайде: prompt={"id": "fvt7oj5pmrq8ui5b0rg6"}, а не отдельный параметр prompt_id). Все настройки — инструкция, подключённые инструменты — подтягиваются автоматически, их не нужно указывать в каждом запросе. Создать Agent ID можно только через интерфейс; при чисто API-подходе все параметры передаются вручную в каждом запросе.
Клиент со слайда:
import openai
client = openai.OpenAI(
api_key=YANDEX_CLOUD_API_KEY,
project=YANDEX_CLOUD_FOLDER,
base_url="https://ai.api.cloud.yandex.net/v1",
)
response = client.responses.create(
prompt={"id": "fvt7oj5pmrq8ui5b0rg6"},
input="Сделай краткий обзор последних новостей об LLM в 2026 году.",
)
print(response.output_text)
Модель при чистом API-подходе указывается в формате gpt://{YANDEX_CLOUD_FOLDER}/{YANDEX_CLOUD_MODEL}, например gpt://<идентификатор_каталога>/deepseek-v4-flash.
15:50Параметры Responses API
Четыре группы (по схеме на слайде):
| Группа | Параметры |
|---|
| Модель | model, instructions, input |
| Генерация | temperature, max_output_tokens, reasoning, stream |
| Инструменты | tools, max_tool_calls, function calling |
| Формат ответа | response_format, previous_response_id, store |
Подробная таблица со слайда:
| Параметр | Назначение | На что влияет | Когда менять |
|---|
model | Выбор модели (например, DeepSeek Flash, reasoning-модель) | Качество, скорость, стоимость, поддерживаемые возможности | Всегда |
instructions | Системные инструкции для модели | Поведение, роль, стиль общения, ограничения | Всегда |
input | Входные данные пользователя | Контекст задачи | Всегда |
temperature | Степень случайности генерации | Баланс между точностью и креативностью | Если нужен более творческий или более детерминированный ответ |
max_output_tokens | Максимальный размер ответа | Стоимость и длина ответа | Для контроля расходов и ограничения длины |
tools | Подключение встроенных инструментов | Возможность искать информацию, выполнять код, генерировать изображения, работать с файлами | Когда агент должен выполнять действия |
response_format | Формат результата (JSON Schema и др.) | Гарантированная структура ответа | При интеграции с приложениями |
stream | Потоковая выдача ответа | Меньшая задержка, постепенное отображение ответа | Всегда |
previous_response_id | Продолжение предыдущего ответа | Сохранение контекста диалога на стороне сервиса | Для многошаговых диалогов |
store | Сохранять ли результат на стороне сервиса | Возможность последующего обращения к ответу | Если нужно хранить историю |
Рекомендации спикеров:
- Для сценариев с активным вызовом инструментов — DeepSeek 4 Flash (идентификатор модели
deepseek-v4-flash; в таблице параметров на слайде она же названа «DeepSeek Flash») или Qwen 3.6 (?): они лучше всего работают с tool calling. Если инструменты не нужны или нужна скорость — модели поменьше (Alice AI Flash (?), младшие Qwen).
- Режим рассуждений (
reasoning) поддерживают не все модели — проверять в документации или Model Hub. В UI он выставляется значением «Авто».
- Температура больше не «от 0 до 1». Новые модели требуют более высоких значений, и диапазон сильно различается между моделями. Для Qwen 3.6 (?) рекомендуется тестировать от 1 и выше — 1 это скорее нижняя граница. (На слайдах в примерах кода стоит
temperature=0.3 — это дефолт демо-агента, а не универсальная рекомендация.)
max_output_tokens — это грубое обрезание, а не мягкое ограничение: если модель не уложилась в заданные, например, 200 токенов, хвост просто отрежется. Сильно бьёт по пользовательскому опыту, использовать осторожно.- Важное ограничение: нельзя одновременно задать строгую JSON-схему ответа и подключить инструменты. Либо structured output, либо агентский цикл с tools — совмещение даёт ошибку.
- Веб-поиск недавно обновлён: качество заметно выросло, потребление токенов после поиска существенно снизилось за счёт оптимизации. Если раньше запросы отрабатывали плохо — стоит перепроверить.
Пример вызова web_search со слайда «Только API» — с точными именами полей:
response = client.responses.create(
model=f"gpt://{YANDEX_CLOUD_FOLDER}/{YANDEX_CLOUD_MODEL}",
input="Сделай краткий обзор последних новостей об LLM в 2026 году — только факты, без домыслов.",
tools=[
{
"type": "web_search",
"filters": {
"allowed_domains": ["habr.ru"],
"user_location": {"region": "213"},
},
"search_context_size": "medium", # варианты: low | medium | high
}
],
temperature=0.3,
max_output_tokens=1000,
)
То есть ограничение по доменам задаётся через filters.allowed_domains, регион пользователя — через filters.user_location.region (в примере "213" — Москва), а объём забираемого со страниц контекста — через search_context_size со значениями low | medium | high.
25:05Управление контекстом: store, previous_response_id и Conversations API
Слайд «Управление контекстом в Yandex AI Studio» — развилка. Слева отдельным блоком Completions API: автоматическое сохранение контекста недоступно, реализовывать надо самостоятельно. Справа Responses API ветвится на store=false («запросы не хранятся») и store=true («запросы responses сохраняются, доступен контекст сессии»), а из ветки store=true идут две стрелки вниз — на previous_response_id и на Conversations API («более гибкое управление историей»).
В Chat Completions контекста нет вообще — всю обвязку (передача предыдущих сообщений, вызовов инструментов) разработчик реализует сам или получает из LangChain/LangGraph. Ключевое отличие Responses API — он хранит историю на стороне платформы и умеет с ней работать для оптимизации токенов и защиты от переполнения контекста.
При store=false история не хранится и чатовый сценарий из коробки невозможен. При store=true доступны два механизма:
previous_response_id — в ответе приходит ID response, его передают в следующем запросе; API автоматически подтягивает всю цепочку предыдущих запросов и передаёт её в модель.
# Первый запрос
response = client.responses.create(
model="gpt://<идентификатор_каталога>/deepseek-v4-flash",
input="Меня зовут Дмитрий."
)
# Второй запрос с использованием previous_response_id
response = client.responses.create(
model="gpt://<идентификатор_каталога>/deepseek-v4-flash",
previous_response_id=response.id,
input="Как меня зовут?"
)
Conversations API — явно создаваемый объект сессии. Позволяет создавать объект conversation, куда сохраняется контекст переписки, просматривать контекст, обновлять его и удалять объект. Можно добавлять собственные текстовые item’ы (например, выгрузить историю, суммаризировать её и залить обратно одним сообщением). У conversation и у item’ов есть метаданные (metadata).
conversation = client.conversations.create(
metadata={"topic": "demo"},
items=[
{
"type": "message",
"role": "user",
"content": "Привет! Запомни контекст этого диалога.",
}
],
)
print(conversation.id)
Дальше идентификатор передаётся в обычный запрос параметром conversation (не conversation_id):
conversation_id = "conv_xxxxxxxxxxxxxxxxx"
response = client.responses.create(
model="gpt://<идентификатор_каталога>/deepseek-v4-flash",
conversation=conversation_id,
input="Какие темы мы уже обсуждали?"
)
В обоих случаях весь контекст целиком уходит в модель как input-токены (или cached-токены). Механика передачи и тарификация идентичны — выбор между ними на тарификацию не влияет.
28:38Демо и просмотр диалогов в UI
Живой прогон в ноутбуке: цепочка из двух responses через previous_response_id и отдельно — создание conversation с предзаписанным контекстом. В UI в разделе «Логирование» появились списки диалогов, отдельно responses и conversations: видны все параметры и ответы, отрендеренный вид, ссылка на предыдущий идентификатор для перехода по цепочке, ID conversation и переходы в конкретные входящие в него responses.
32:38Truncation: автоматическое обрезание контекста
Параметр truncation в Responses API включает автоматическое обрезание, чтобы не ловить переполнение контекстного окна модели. Принимает два значения — auto и none, по умолчанию none (в UI агента это поле «Обрезание контекста», по умолчанию «Нет»). Подзаголовок слайда: «позволяет минимизировать ошибки с переполнением контекста языковой модели».
response = client.responses.create(
model="yandexgpt",
conversation="conv_xxxxxxxxxxxxxxxxx",
input="Сделай краткое резюме нашего разговора.",
truncation="auto",
)
Нюансы:
- Обрезаются самые старые части контекста; системная инструкция и объявление инструментов остаются неизменными.
- При вырезании удаляется и вызов инструмента, и его ответ (парой).
- Ради скорости размер запроса оценивается приблизительно — стопроцентной гарантии попадания в контекст нет, но вероятность успеха резко повышается.
- Truncation ухудшает кэшируемость, потому что меняется начало запроса.
34:09Кэширование
Кэш поддерживается частью моделей (например, DeepSeek 4 Flash), срабатывает автоматически на повторяющемся префиксе промпта — кэшируется повторяющаяся часть в начале промпта. Гарантий попадания в кэш нет. Параметр truncation влияет на кэширование.
Рекомендации со слайда:
- Использовать системные инструкции — максимум статики выносить в
instructions (она в начале, как и объявление инструментов, и повторяется в каждом запросе).
- Тестировать попадание в кэш на большом объёме запросов: 2–3 запроса непоказательны.
- Процент попадания в кэш оценивать по биллингу или мониторингу — для кэш-токенов заведены отдельные SKU.
Кэш хранится на виртуальных машинах инференса в уже вычисленном виде — фактически матрица чисел («хранится лишь состояние вычисления модели»), текста запроса там нет, восстановлению не подлежит.
35:56Сроки хранения данных
Слайд «Хранение данных запросов в Yandex AI Studio» (подзаголовок: «Зависит от API и параметров API») — три карточки:
- Кэш — хранится лишь состояние вычисления модели; сам текст запроса ни в каком виде не подлежит восстановлению.
- Conversations API — данные хранятся 365 дней (или до удаления через API/UI); сюда же относятся все привязанные к conversation responses.
- Responses API с
store=true — данные хранятся 30 дней, необходимы для диалоговых сценариев (или до ручного удаления).
Сноска на слайде: при указании в Responses API параметра store=False запрос не сохраняется, содержимое запроса находится в памяти только во время обработки, построение контекста диалога невозможно.
Чем управляет пользователь (отдельный слайд):
- истории сессий Conversations API и Responses API;
- данные в поисковых индексах Vector Stores API;
- файлы в Files API (загрузка/удаление);
- файлы, полученные с помощью инструментов (Code Interpreter, Image Generation и т. д.).
38:27Виды логирования
Аудитные логи — позволяют отслеживать события, которые происходят в Yandex AI Studio: создание индекса, настройка правил модерации и т. д. Выгружаются через Yandex Audit Trails для расследований и анализа; список событий в документации. Не содержат данные запросов и ответов.
Логи сервиса — информация о состоянии сервиса, недоступна пользователям в интерфейсе/API. Возможно предоставление через техподдержку при инцидентах.
Ни аудитные логи, ни логи сервиса не содержат текстов запросов, ответов и вообще пользовательских данных.
Логи обращений в модель / трейсы — новый раздел (на слайде помечен бейджем New), реализован на компонентах сервиса Monium. Это доступные пользователю логи запросов/ответов в Completions API и Responses API; необходимы для мониторинга работы и оценки качества (и для дебага).
40:32Трейсинг и мониторинг
Трейсы по умолчанию выключены; включаются в разделе «Логирование» на плитке с трейсингом и тарифицируются отдельно по тарифам сервиса мониторинга. Смотреть можно как внутри конкретного агента (иконка открывает вкладку мониторинга и трейсов — вся цепочка вызовов модели и инструментов с параметрами и ответами), так и в общем разделе по всем агентам.
Обновлён раздел «Мониторинг»: новые дашборды, фильтры по методу и модели (для Completions и Responses выбирается метод OpenAI Completion). Видны запросы, кэшированные / входящие / выходящие токены, время до первого токена. Добавлены квоты — например, график параллельных генераций показывает и саму квоту, и текущее потребление от неё.
Вся эта телеметрия относится ко всем запросам в рамках фолдера, а не только к сделанным через интерфейс.
43:34Итог обновлений
Стоит попробовать: truncation для защиты от переполнения контекста; трейсы и обновлённый мониторинг для прозрачности агентского цикла, квот и таймингов. Фидбэк и идеи собираются в сообществе и на отдельной странице идей на сайте Yandex Cloud — yandex.cloud/ru/features («Пространство для ваших идей»: предложить идею, проголосовать за чужие, фильтр по категории Yandex AI Studio). Материалы вебинара и обратная связь — по короткой ссылке с финального слайда clck.ru/3UkJLi.
Практические выводы
- Responses API — дефолт для всего текстового; Chat Completions оставляйте для одноразовых вызовов и интеграции с чужими фреймворками.
- Не пытайтесь совместить строгую JSON-схему и tools в одном запросе — будет ошибка.
max_output_tokens не «сжимает» ответ, а режет его. Ограничивайте длину промптом, а не только параметром.- Температуру подбирайте под конкретную модель, старая эвристика «0–1» неактуальна.
- Для длинных диалогов:
truncation="auto" спасает от переполнения (по умолчанию он none, то есть выключен), но ломает кэш. Дешевле и надёжнее — периодически суммаризировать старую часть истории и класть её обратно в conversation одним item’ом, удалив исходные сообщения.
- Стабильный префикс = деньги. Всё постоянное — в
instructions, историю — не переформировывать вручную между запросами, запросы пускать подряд. Замер попадания в кэш делайте на большом объёме: 2–3 запроса ничего не показывают.
- Разбивку по кэш/input/output токенам смотрите в ответе Responses API, в биллинге (отдельные SKU для кэш-токенов) и теперь в мониторинге.
- Включите трейсы до того, как начнёте расследовать «почему агент отвечает 40 секунд» — они показывают, где именно ушло время (генерация, веб-поиск, число итераций цикла) и служат стартовым набором данных для эвалов.
- Agent ID из UI избавляет от передачи конфигурации в каждом запросе (передаётся как
prompt={"id": "..."}), но создаётся только через интерфейс.
Вопросы из зала
Как учитывать контекст только за сегодня, а прошлые дни суммаризировать? Через Conversations API: у conversation и его item’ов есть метаданные (metadata), по ним можно фильтровать. Старые сообщения либо удалить из conversation, либо выгрузить, прогнать через модель на суммаризацию и положить обратно новым item’ом.
Когда работать через API, когда через UI, когда через SDK? UI — эксперименты, первое решение, настройка мониторинга и трейсинга. Продакшен — API. Из SDK рекомендуется OpenAI SDK (совместим с Responses, Realtime); для сложной логики с сабагентами и хендоффами — OpenAI Agents SDK, он работает поверх Responses API. Также LangChain/LangGraph; на слайде интеграций есть готовые инструкции для n8n, OpenClaw, Open WebUI, LangChain и Roo Code. Оговорка: официальные OpenAI SDK есть в основном под Python и JavaScript, для других бэкендов — прямые HTTP-запросы на https://ai.api.cloud.yandex.net/v1; кнопка «Посмотреть код» в UI выдаёт варианты и для чистого API, и для разных языков.
Что дают трейсы? Прозрачность агентского цикла Responses API: сколько было обращений в модель, с какими запросами вызывались инструменты (поисковый запрос в web search формулирует сама модель), что возвращалось, а главное — тайминги. Позволяют ответить, почему запрос «долго крутился»: медленная генерация, медленный веб-поиск или 10 последовательных поисковых вызовов.
Как отключить логирование данных? Трейсы включаются/выключаются в UI. store=false в Responses (ценой потери функциональности: содержимое запроса живёт только в памяти во время обработки, диалоговый контекст не строится). Логирование данных для улучшения качества сервиса отключается специальным заголовком в запросе — описано в документации.
Тарификация при передаче прошлого контекста. От выбора conversation или previous_response_id не зависит. Весь сохранённый контекст передаётся в модель и тарифицируется как input-токены; при попадании в кэш — по тарифу кэшированных токенов (отдельные SKU). Если запросы идут подряд, префикс с большой вероятностью закэшируется; если между запросами неделя — вероятность мала. При самостоятельном формировании контекста внешним фреймворком следите, чтобы префикс оставался неизменным.
Где развёрнуты модели, уходят ли данные за границу? Все модели развёрнуты в Яндекс Облаке, в дата-центрах внутри РФ. За границу РФ и за границу облака ничего не передаётся, проксирования во внешние модели нет. Есть сертификаты по ФЗ-152 (в расшифровке «ФСС-152») и др.
Решения для компаний со строгой политикой конфиденциальности? AI Studio поставляется полностью on-prem в закрытый контур без выхода в интернет. Есть гибридные варианты: RAG и базы знаний в контуре, большие модели вроде DeepSeek — из облака по защищённому выделенному каналу. Доступны приватные эндпоинты, изолированные подсети. Настройка — через поддержку или форму на сайте.
Что будет при запросе с ID удалённого conversation? С высокой вероятностью ошибка «такого conversation нет» (спикеры оговорились, что для надёжности стоит проверить).
Поддерживаются ли фоновые запросы (background mode)? Да, доступен уже сейчас. По умолчанию Responses API синхронный. В background-режиме запрос обрабатывается до 24 часов, но не упирается в квоту на параллельные генерации (её можно увеличить через поддержку, но лимиты строгие). Подходит, чтобы разово закинуть, например, 10 000 запросов и не строить очередь самому. Режим планируют дорабатывать.
Как хранить память голосового агента, работающего с клиентом несколько недель? В Realtime API хранение контекста устроено похоже на Responses API, но со своими деталями — вопрос перенесён на отдельный вебинар по Realtime API 21 июля.