Всем привет! Мы Настя и Миша из команды AI Studio. Привет! И сегодня мы расскажем, как с помощью
в реал-таймапе создавать голосовые приложения от простых до сложных мультиагентских. Наш
вебинар в первую очередь направлен на техническую аудиторию, на разработчиков и архитекторов,
которые хотят разобраться с реал-таймапе. Но также мы постарались делать вебинар интересным,
в том числе и бизнес-аудитории, и поэтому в каждом блоке, в котором будем рассказывать,
мы обязательно показываем не только техническую имплементацию, но и рассказываем применимость
той или иной фичи реалтайма для бизнес-кейсов.
Пару слов о том, что мы сегодня будем вам рассказывать.
Мы сегодня поговорим про возможности нашей платформы, поговорим про промптинг,
вообще про создание агента, расскажем, как дать агенту побольше знаний и возможностей,
используя файл-серч, веб-серч, научим агента выполнять сторонние действия с помощью функцион-коллинга и MCP,
также немножко поработаем над тем, как агент работает с контекстом с помощью прерываний и функции truncate.
После этого мы перейдем к более масштабным решениям с помощью мультиагентности,
обсудим про то, какие вообще возможны поверхности для Real-Time API,
ну и подведем итог, что мы сегодня научились, и также немножко заглянем в будущее, какие у нас планы.
Что же такое Real-Time API? Real-Time API — это API для построения систем взаимодействия в реальном времени.
Пользователи слушают, понимают и дают ответ практически без задержек.
Real-Time API — это часть платформы iStudio. iStudio — это платформа для построения агентов, построения приложений на базе.
В координатах iStudio и Real-Time API следует искать в агентском ателье.
Агентское ателье — это раздел студии, в котором удобно создавать агентов как голосовых, так и текстовых.
Так вот, в агентском ателье Real-Time API отвечает за создание именно голосовых агентов.
Real-Time API интегрирован с большинством кубиков, представленных в этом разделе.
Так, с помощью MCP он может обращаться к API разных внешних систем.
Также он может использовать голоса, представленные в спичке, те как общедоступные, так и голоса,
которые пользователи создавали приватно для себя, ну, конечно, теми же самими пользователями.
И real-time API умеет работать со всеми представленными видами поиска,
можно искать по документам, можно искать по вебу.
Real-time API, если говорить об этом достаточно высокоуровнево,
это API к каскаду моделей и инструментальной обвязки вокруг них.
За логику в real-time, за вообще принятие каких-то решений,
отвечает LLM, Large Language Model.
Это логика и того, что и как говорить,
какими знаниями когда пользоваться, какие инструменты вызывать.
За голосовой вывод отвечает модель распознавания речи,
speech-to-text, она же ISR, Automatic Speech Recognition.
И за голосовой вывод, соответственно, модель синтеза речи,
текст-to-спич.
Real-time API может работать не только во флоу голос-голос,
но и голос-текст в различных его сочетаниях.
Но на сегодняшнем бинаре преимущественно мы будем
сосредотачиваться на сценарии голос-голос
и лишь изредка уходить в сценарий голос-текст.
Ну и немножко спустимся на более технический уровень.
Посмотрим, какая часть за что отвечает.
Если рассматривать нашу схему, то у нас есть входной канал.
Это может быть микрофон вашего телефона,
микрофон на ваших наушниках.
Соответственно, в нашу систему входной сигнал в виде аудиофайла.
Дальше, соответственно, происходит распознавание речи.
Тут идет обработка перебиваний.
Также важная компонента – правильная работа с речью.
Дальше уже распознанный текст передается в модель,
и там актуальны уже, по сути, настройки мозгов,
использование сторонних тулов,
конечно же, инструментация в виде промптинга,
применение переменных.
И с этими данными модель уже строит ответ.
Она, соответственно, передает свой ответ в синтез.
В синтезе применяются настройки амплуа,
настройки параметров голоса,
и дальше уже синтезированный аудиофайл
отправляется обратно и воспроизводится
на динамике вашего устройства.
Я перескажу практически то же самое,
но для бизнес-аудитория.
То есть реал-тайм — это на самом деле хорошая основа
для создания голосовых агентов,
для создания роботов.
За всю бизнес-логику здесь отвечает LLM.
Именно она решает, в какой момент обращаться к базам знаний.
Именно она решает, когда вызывать инструменты.
То есть что мы подразумеваем под базами знаний?
Это, например, какая-то ваша внутренняя документация,
которая может храниться на вики, в файлах,
может быть, даже в формате аудио,
если это результаты каких-то встреч.
Если мы говорим про инструменты, что они умеют?
Они умеют в поиск, в обращение к внешним каким-то системам.
То есть агент легко подключается к различного рода CRM, трекерам и так далее.
Если говорить про голосовую составляющую в этих бизнес-сценариях,
то здесь важно отметить, что распознавание может работать не только с русским языком,
но в том числе и казахским, и узбекским, и еще другими языками, которые у нас поддержаны.
Если говорить про озвучку синтез речи, то здесь поддерживаются все голоса, которые у нас представлены в синтезе,
и они тоже есть на разных языках.
Мой любимый подход к изучению любой платформы технологии — попробовать все саму, потыкаться.
И давайте посмотрим, где, собственно, нас можно попробовать потыкаться.
Первая платформа, первая поверхность — это Playground.
У нас появилась песочница, она доступна в веб-интерфейсе и студии.
Там можно быстро попробовать идею, можно поуправлять настройками синтеза,
можно потрогать некоторые из тулов, не все тулы поддержаны.
И, соответственно, без какого-либо кодинга можно сразу посмотреть, что это вообще за продукт.
Но для полноценной интеграции, для production-ready решений, конечно же, нужна уже интеграция на уровне каком-то более техническом.
Для нас это API, мы в этом смысле поддерживаем стандарт OpenAI real-time протокола.
И если чуть-чуть вдаться в подробности технические, то у нас открывается канал по WebSocket,
это поток событий двунаправленный от клиента к серверу и от сервера к клиенту.
Ну и, конечно же, такой уровень интеграции дает максимальную гибкость.
Поскольку мы поддерживаем популярный и открытый протокол,
то для него уже существует большая база готовых решений.
Соответственно, не нужно писать руками сырой код, а можно использовать готовый SDK.
Например, та же агентская библиотека Agents SDK от OpenAI для Python или для TypeScript,
для любой практически платформы, на которой вы будете строить свое решение.
Ну и мы рекомендуем использовать вот эти вот две последние поверхности уже для продакшн-решений.
Мы сегодня покажем и Playground, и, соответственно, решение в коде.
Давайте посмотрим вообще, как работать с Playground, как там представим RealTime.
Как работать с голосовыми агентами в интерфейсе iStudium.
Заходим на сайт, нажимаем кнопку «Войти» и оказываемся на главной разводящей странице iStudium.
Здесь есть шаркат «Создай голосового агента».
Кликнув на него, вы попадете на визерд его построения.
Можно название задать, можно добавить описание, выбрать модель «Системный промпт», написать с нуля, либо воспользоваться каким-то пресетом.
Добавить переменные, выбрать инструменты, задать параметры обработки речи, создать и тут же протестировать.
Если говорить про другие точки входа, то в агентском ателле есть специальный раздел «Голосовые агенты»,
где есть ссылка на документацию по агентам, кнопка «Создание с нуля» и также список агентов, которые вы создавали ранее.
Для демонстрации возможностей давайте посмотрим на агента-переводчика.
Это довольно простой интерфейс, в котором мы определяем все поведение буквально промптом.
Ты голосовой агент-переводчик, отвечаешь за такое-то взаимодействие, переводишь с русского на английский, у тебя какие-то ограничения.
Например, мы там, в частности, говорим, если фраза неполная или оборвалась, переведи только ту часть, которую удалось распознать.
Или обсценную грубую лексику переводим в смягченной форме.
Как-никак у нас агент для конференции.
Таким мы его написали.
Если говорить про другие параметры, то здесь мы не используем ни переменные, ни инструменты.
К ним мы вернемся в рамках нашего основного сценария вебинара.
Здесь же зададим параметры обработки речи.
Синтез.
Голос убираем John.
Для вашего удобства голоса сгруппированы по языкам, которые они поддерживают.
Если голос поддерживает амплуа, его также можно задать.
В синтезе вы можете конфигурировать скорость речи.
По умолчанию это единица, но если надо, побыстрее увеличиваете,
если поменьше, уменьшаете.
Параметры распознавания речи – это язык.
Вы можете выбрать список, у нас это русский.
И также есть определение конца фразы.
Фраза – это буквально то, на что отвечает агент в разговоре.
Давайте установим длительность тишины 850.
Это длительность, после которой фраза считается законченной.
И пускай чувствительность останется такой же.
Чувствительность – это тот параметр, который отвечает за баланс между скоростью реакции
и устойчивостью к коротким паузам внутри фразы.
Советую настраивать в зависимости от поверхности.
Телефон – это канал или, например, мобильное приложение.
Таким образом, настроив нашего агента, мы его сохраняем.
И можно приступать к тестированию.
По настройкам тестирования можно выбрать микрофон.
Я оставлю дефолтный и выставить галочку «Агент говорит первым».
В нашем сценарии это не нужно, но если ваш сценарий подразумевает какой-то исходящий звонок,
обязательно его проставьте.
Запускаем сессию.
Привет!
Как дела?
Останавливаем.
Длительность сессии получилась 7 секунд.
Какие еще артефакты у нас остались?
Ну, собственно, наш диалог.
Идентификатор сессии пригодится при обращении в поддержку, если что-то пошло не так.
Также можно показать события сессии.
Разумеется, агента нужно тестировать, прогнать несколько итераций.
И когда у вас получилось, что агент стал устойчивым и пригодным для перехода к следующей фазе, например, перевода в продакшен, вы можете воспроизвести настройки, которые тестировали в плагграунде, в коде, либо обратиться к ним по ID.
Например, когда у вас один человек собирает агента, а другой его интегрирует, это очень удобный подход.
Пример того, как интегрировать, есть внизу страница, вы можете посмотреть код на питоне.
И здесь есть пример с уже поставленным ID агента.
Обращу ваше внимание, что API-ключ здесь не поставлен, его нужно вводить самостоятельно.
Создать его можно непосредственно из открытого окошка, либо всегда у нас в правом верхнем углу есть кнопка создать API-ключ.
Таким образом, как видите, протестировать агента можно без каких-то специальных технических знаний, достаточно настроить промпт, можно настроить какие-то настройки обработки речи, можно не настраивать, и вот у вас уже агент, которого можно проверить в деле.
Какие бизнес-сценарии можно реализовать в голосе с помощью реал-таймапи?
Формально в рамках этого вебинара я бы разделила их на две такие категории.
Простые, функциональные и сложные агентские, которые решают одну задачу, а агентские, где есть рассуждения, многоходовочный диалог, обращение к базам знаний и вызов инструментов.
Если говорить про примеры простых сценариев, они практически объединяются одной общей идеей: вы что-то распознаете и потом с распознанным что-то делаете, что-то однозадачное.
Например, переводите, заполняете форму или просто у вас, может быть, голосовой ввод на телевизоре.
Что дает RealTime такого рода сценария?
Сразу отмечу, что их можно реализовать на базовом распознавании речи из того же Яндекс.Пич.Кита, но что привнесет сюда RealTime?
RealTime может привнести сюда обработку результатов распознавания с учетом контекста.
Каждый раз, в каждом сценарии у вас есть некий контекст.
Например, вы вызываете устройство умного дома, и у вас есть определенный список этих устройств.
Вы находитесь на сценарии, на экране выбора фильма, и у вас представлены какие-то фильмы,
по которым вы, допустим, навигируете и что-то с ними делаете.
Или вам звонят в клинику, и вы хотите там записаться к какому-то врачу по его фамилии, может быть.
Что дает в этом случае RealTime?
Он позволяет исправлять некие погрешности распознавания, вытягивать какие-то элементы, с которыми пошло что-то не так.
Например, у нас есть меню, и там есть двойной эспрессо.
Но акустика такова, и условия, допустим, звука ужасные, и вот распознавание вернула война экспрессо.
И зная, что война экспрессо у нас есть, но есть двойной эспрессо, который максимально похож на него,
таким образом постобработка результатов распознавания может максимально вытянуть качество.
Злоупотреблять этим не стоит, но и пренебрегать тоже.
Я знаю много сценариев, когда пусть такие простые ухищрения спасали буквально интеграции,
которые не могли с этим справиться самостоятельно.
Что еще может привнести real-time?
Допустим, какую-то постобработку в части выделения сущностей,
допустим, вам диктуют какой-то email, и он диктуется по буквам,
его еще нужно потом суметь собрать, как-то поджонить
и превратить к нормальному виду, или номер телефона,
или какой-нибудь другой ID-шник и так далее.
Еще можно делать красивые нормализации,
которые заточены непосредственно под вашей кейсом.
Буквально вот на этой неделе я разбирала фичи-реквесты в спичкит,
и пришел клиент, который просит следующую фичу в нормализации,
буквально настройку.
Говорит: «Хочу, чтобы числа от 1 до 10 писались словами,
а все, что больше 10, записывалось цифрами».
Вполне себе общепринятая практика, но то, что у нас
существует достаточно давно спичкит, и то, что пользователи
привыкли обрабатывать, как обрабатывается, и надо
вносить настройку — это буквально вмешательство в API.
Если бы этот пользователь пришел в реал-тайм, то правило
нормализации.
Разная постобработка, были ему доступны буквально
по промпту «Олмабук» задавать все, что хочет.
То есть получил текст распознанного и как-то его
запроцессил согласно его сценариям.
Если говорить про сложные агентские сценарии, это
там, где уже у нас присутствует понятие «агент», что это
такое, мы уходить в теорию не будем.
Я думаю, каждый из присутствующих так или иначе в этом уже
разбирается, и агенты оперируют
контекстом диалога, умеют оперировать базами
знаний, умеют вызывать инструменты, спрашивать
недостающие детали и, в принципе, как-то модерировать
даже диалоги.
Что можно сделать на агентах, основанных
на Realtime?
Например, поддержка клиентов.
Клиентов можно консультировать по вопросам в документации,
можно обращаться непосредственно в профиль клиента и менять
какие-то настройки, если был такой запрос.
Можно смотреть, на что были потрачены
Наталья иная сумма, например, клиент, было большое
списание, он звонит и спрашивает, что там такое
произошло, что с меня списали столько-то денег.
Или, например, почему у меня перестала быть
доступна опция в моем личном кабинете
в интернет-магазине и так далее.
Поддержка может быть разнообразной.
Еще из таких неочевидных сценариев, которые
мы, откровенно говоря, не ожидали, но с которыми
приходят все чаще, это оформление заказа.
Людей привлекает и вдохновляет, что можно
не просто говорить «мне одну пиццу и одну колу
безо льда», но еще взаимодействие с агентом,
который может понять, исходя из контекста,
что предложить. Например, на запрос «мне
что-нибудь попить и поесть на 300 рублей»
вполне себе можно в меню фастфуда что-то
собрать. Но в базовом виде система
с этим не справляется. Основанная на
реал-тайм апе, она знает, какие позиции
по какой цене и понимает, что из этого
относится к категории «попить», а что
поесть, и поможет клиенту подобрать
решение в ответ на его запрос.
Ну и чтобы нам проиллюстрировать
возможности нашей платформы, мы
долго думали, какой бы сценарий
такой вот иллюстративный подобрать.
У нас были, честно скажем, такие
скучненькие, бизнесовые решения.
Нам немножко захотелось
серые будни раскрасить и мы
обратились к такому сценарию,
который всем нам знаком и
с другой стороны отвлекается.
Мы решили построить голосового агента,
который поможет нам собрать
компанию для игры в настольные игры,
запланировать это все и
и дальше, соответственно, поработать уже
с какими-то конкретными правилами игры.
Что мы будем сегодня строить
и что мы будем сегодня делать?
Мы, значит, познакомимся с агентом,
научим его запоминать наши предпочтения.
Естественно, в настольных играх
очень важный ответственный момент
выбрать подходящую игру.
Настя, какая тебе, кстати,
больше всего настолка нравится.
Ну ладно, иммагинарием.
Замечательно.
А я очень люблю Dixit.
Нередкая ситуация,
когда у вас есть
большая портянка,
талмуд, как правильно играть в конкретную настолку.
Вы забыли
правила и
нужно освежить в голове
какой-то
пункт из правил. Будет очень классно,
если наш голосовой агент
поможет
с правилами выбранной игры.
Естественно,
настольные игры
предполагают, что мы где-то
собираемся за столом и играем.
Нужно найти время и место.
Нужно
собрать всех
в одно и то же время.
Ну и
как развитие нашего
сценария, мы также еще рассмотрим
вариант мультиагентности,
когда разные
агенты отвечают за
разный спектр
возможностей.
Наш сегодняшний рассказ мы
соберем
уже даже собрали
в виде исходного
кода, выложили это все на гитхаб,
поэтому у нас на слайдах сегодня
будет много
сниппетов, много листингов,
примеров кода.
Все
это потом
мы вам отправим в виде
QR-кодика и можно будет посмотреть
воочию, позапускать самостоятельно.
Но с другой стороны
также у нас записаны скринкасты
с демонстрацией работы
нашего кода.
Любой сценарий
начинается с промта, но промт
при всей своей простоте сейчас
понятие, ну и в принципе всегда было
понятием не многозначным.
И под промтом понимают
разные вещи. На самом деле
промт — это не только инструкция,
которая описывает агенту, как себя
вести, каким инструментом обращаться,
но и это описание самих
инструментов, это задание
контекста
и вводных, то есть весь диалог,
который был до момента
очередного действия, пользовательский
ввод текущий
и временами еще формат
вывода. Но есть еще
такое бытовое значение промта
это, соответственно, та инструкция,
которой вы работаете с агентом,
то есть описание
задачи агенту, что
он должен выполнять. На самом
деле существуют разнообразные практики,
как писать хорошие промты, разные
подходы, про это написаны целые
книжки, и если вы
есть в нашем комьюнити АИ-студия,
пользуясь случаем, я рекламирую его
в Телеграме, то там периодически
обсуждается вопрос по промтам.
Как их лучше писать?
Сегодня методик давать не буду,
дам несколько советов по промтам.
Он должен, в первую очередь,
быть логически согласован.
Это самое главное, потому что потом
вам, спустя несколько дней после того,
как вы его написали, возможно, придется
вносить какие-то правки, отлаживаться,
и вам самим будет проще
работать с текстом,
который написан логически.
Из этого следует и вторая история:
промт должен быть структурирован.
Структурированность,
разбитие его на разные разделы
в целом будут меняться от сценария
к сценарию, но всегда есть такие
вещи, как роль, что ты можешь,
что ты не можешь, какие у тебя
ограничения. Очень часто вижу
в последнее время, что пользователи
стараются еще делать мини-фак
на самые часто задаваемые вопросы
и не уходить, например, в историю
с рагом. И еще важная
вещь, про которую часто забывают
и которую бы хотелось отметить, это
необходимо в промте описывать, когда вызывать
все или иные функции. Про функции мы
расскажем позднее, но просто
как факт. Пром должен быть
структурированным, логически
согласованным, и в нем обязательно должно быть
указано, когда и какие функции
вызывать, если они у вас подключены
к агенту. Знаете, а я еще услышал
у тебя две аббревиатуры
FAC и RAC.
Кто за что отвечает?
FAC - это, соответственно,
часто задаваемые вопросы,
которые соотносятся с вашим доменом,
может быть, это по продукту и так далее.
Пятерка вопросов переданных в промпт, возможно,
избавит вас от кучи головной боли.
Например, RAC - это когда модель отвечает
на основе результатов поиска.
Это справедливо как по поиску в интернете,
так и по поиску по файловому.
То есть сначала осуществляется поиск,
и модели отдаются максимально релевантные
куски текста для ответа на вопрос,
и на основании их из одного вопроса
она строит ответ.
Надеюсь, ответила.
Спасибо.
Ну и давайте уже перейдем к коду.
Собственно, мы хотим пока сделать просто агента,
который нам поможет с выбором на столке.
Как видно на экране, у нас есть довольно простой и лаконичный промт.
Мы рассказываем агенту, кто он такой и какая у него задача.
Тут промт небольшой, но достаточно иллюстративный
в контексте того, что Настя только что проговорила.
У него видна структура.
Также видно, что он размечен.
В целом, язык разметки не обязательно должен быть markdown,
но, во-первых, он хорошо читается и человеком,
а с другой стороны, модели обучены просто на каком-то гигантском
количестве markdown файлов.
Это очень популярный формат.
Поэтому смело используйте его.
Он как раз помогает и людям, и машинам не сбиваться и ориентироваться.
Если что, все промпты, которые мы сегодня тоже покажем,
они также будут в материалах после вебинара.
Ну и промпт есть. Давайте немножко посмотрим на код.
Тут совершенно какой-то такой boilerplate-ный базовый код.
Соответственно, по сути, мы указываем, куда подключаться,
какие у нас endpoints, и дальше передаем модельке наш промпт.
Соответственно, все это воедино, будучи запущенным,
уже появляется какая-то новая сущность,
и мы можем уже поговорить с нашим агентом.
Давайте посмотрим, как это работает.
Здравствуй.
Здравствуйте. Чем могу помочь?
Что ты умеешь?
Я могу помочь выбрать настольную игру, разобраться в правилах и собрать компанию.
Расскажите, какая игра вас интересует, подскажу.
Мафия.
В мафии есть мирные жители и мафия.
Задача мирных - вычислить мафию, а мафии - избавиться от мирных.
Хотите, расскажу подробнее правила или помогу собрать компанию?
Примеры того, что должно содержаться в промтакт для различных сценариев.
Ну, например, если мы говорим про поддержку клиентов, там могут быть часто задаваемые вопросы,
правила поведения и вообще логика, как обращаться, что делать при различных вопросах клиента.
Если мы говорим про такой кейс, как первичный контакт с клиентом, то промт имеет довольно стандартную структуру,
описывается роль, описывается задача. Например, вы хотите прозвонить с каким-то предложением,
сделать так называемый холодный звонок, узнать детали, узнать контакты,
и, соответственно, здесь вы добавляете все шаги, последовательность и ту информацию,
которая должна быть собрана по результатам такого звонка.
Еще я хотела тут такой пример привести, голосовое оформление заказа.
Здесь вы, например, можете даже в состав промта, если размер меню это позволяет,
передать меню как часть такого текстового промта.
Кстати, у нас будет подробный разбор кейса клиента, я не акцентировала внимание на предыдущих слайдах,
но 30 июля наш клиент Реалтайма, строенный РГКОМ, ребята специализируются на установке
и работе с умными счетчиками, расскажут, что находится в составе их промта,
как они с ним работают и как они вообще его меняли на протяжении разработки,
с чего начинали и к чему пришли в итоге.
Промт с переменами. Не забываем, что мы договорились называть промтом именно
системную вот эту промт, инструкцию, которую это задает агента.
И если промт создавался непосредственно в UI, а и студии, его можно параметаризовать.
На самом деле эта функциональность, она в каком-то смысле может быть в некоторых кейсах избыточна,
но она дает большие преимущества, когда вы параметаризуете заранее,
а промт перед его вызовом вы избавляете себя, например, от подходов MCP,
от походов function calling и так далее.
То есть вы когда звоните, вы уже знаете много параметров по тому звонку,
например, если звонок исходящий,
много параметров по тому клиенту, к которому обращаетесь,
и не начинаете разговор с таким: «Как же к вам обратиться?
Сейчас я по ID-шнику схожу и вытяну имя из серии».
Ну а давайте посмотрим, как вообще работать, как задавать переменные в iStudy.
Как работать с переменными?
Для нагленности мы максимально упростили наш промп.
И теперь добавим две переменные: AgentName и тематику вечера.
Сохраняем.
И теперь при каждом тестировании сессии можно вводить разные значения и тестировать, как поведет себя промп в зависимости от введенных параметров.
Голос у нас Маша, поэтому давайте назовем агента Мудрая Маша.
А топик вечер накануне экзамена.
И теперь запустим сессию и минимально протестируем наш промп, чтобы посмотреть, подхватились ли переменные.
Привет, как тебя зовут и какая сегодня тематика вечера?
Здравствуйте, меня зовут Мудрая Маша.
Сегодня у нас вечер в тематике, вечер накануне экзамена.
Думаю, для тестирования этого достаточно.
Таким образом, вы можете задать переменные, которые позволят вам параметризовать свой промп,
параметризовать сценарий, чтобы заполнять его максимально при запуске
и не обращаться, например, в MCP или не ходить в FunctionCalling.
Давайте немножко посмотрим, как бы это могло выглядеть в коде.
Вообще, в принципе, идея параметризации промптов и редактирования промптов из интерфейса.
Она позволяет немножко декомпозировать ваше решение,
например, разделив людей, которые пишут непосредственно какой-нибудь FunctionCalling
и обработку тулов, и людей, которые пишут непосредственный промпт.
В данном случае мы договариваемся про подстановку переменных,
и вот эти значения переменных можем передавать в качестве параметров сессии.
Ну и также вот здесь видно, что мы передаем промпт не целиком,
весь текст просто по ID-шнику, соответственно,
редактирование дальнейшего промпта уже через интерфейс
будет автоматически подхватываться новыми сессиями.
Какие вообще примеры, переменных сценариев можно дать?
Ну, здесь банальный пример с той же самой париклиникой,
когда вы звоните и напоминаете клиенту о том,
что у него завтра запись, он придет или перенести,
выполнить какое-то действие.
И, соответственно, вы здесь можете обращаться,
представиться, ну, обратиться к Анастасии,
«Здравствуйте, вы завтра записаны, допустим, на укладку»,
к мастеру Евгении.
Все это можно заранее предзаписать в промт,
а не выяснять в процессе звонка.
Конечно же, в ЦРМ это все есть, но, если позволяют обстоятельства,
это можно сделать.
Также можно даже передавать какие-то слоты,
на которые, в случае чего, я могла бы перезаписаться
к этому же мастеру.
Конечно, есть вероятность того, что в процессе разговора
слоты кто-то займет и это устареет, но, согласитесь,
попадание тоже высоковероятно, и это сэкономит время,
вас и вашего клиента и сделает диалог даже более
естественным, чем если бы выходили и спрашивали
в системе в реальном времени.
Итак, мы научились уже промкить базовый агентский
сценарий, давайте добавим нашему решению каких-то
мозгов, дополнительных знаний и так далее.
Будем использовать для начала файловый поиск.
Собственно, основная идея файлового поиска в том, что
у нас есть какая-то уже база знаний, какой-то набор
документов, в нашем сценарии с настольными играми
это могут быть правила настольных игр, и мы можем
просто накачать кучу файлов в различных форматах,
собрать их в один файловый индекс, получить один
идентификатор этого индекса, и дальше передавать
его как контекст нашему агенту в параметрах
сессии. Что дает эта возможность? Эта возможность
дает модели обращаться к внешней какой-то
базе данных. И нам, естественно, нужно будет
сообщить модели, что ты можешь использовать
такой тул, но простой как бы набор
каких-то небольших инструкций сразу
добавляет просто дополнительный какой-то
источник знаний, который дальше может
быть использован для построения уже
диалога. Давайте посмотрим, как можно
написать простой промпт для того, чтобы
загруженные файлы в интерфейсе и студии
организованные в поисковый индекс
использовать уже в рамках сессии.
Ну, собственно, модели нужно
рассказать, что ты можешь использовать
FileSearch, что это доступная тебе функция
и также ее немножко призвать, побудить
в случае, если ты получаешь запрос
на рассказ про правила игры, то сходи
в поисковый индекс, посмотри там
и найди, соответственно, релевантные
куски ответов.
Посмотрим на код. Код тоже достаточно
простой. Самое главное в этом
листинге - это то, что мы передаем
непосредственно поисковый индекс.
Ну и давайте посмотрим, как это
выглядит в живую.
В какой момент в манчкине можно
сбросить класс или расу?
Сбросить класс или расу в манчкине
можно в любой момент игры, даже в бою.
А как получить в манчкине 10 уровень?
Получить 10 уровень в манчкине можно за убийство монстров,
применение особых карт или продажу шмоток.
Уточните, хотите узнать про конкретный способ?
Ну и давайте посмотрим, как пользоваться файлсерчем в плэкграунде.
Чтобы воспользоваться инструментом файлопоиска,
выберите в инструментах файлсерч индекс, по которому хотите искать,
и количество чанков, которые хотите использовать для ответа модели.
У нас их 5, это значит, что 5 чанков из найденных будут использоваться модели для формирования ответа.
Конечно же, обязательно пропишите, в каких случаях необходимо вызывать файл-серч,
чтобы модель могла понимать, когда ей дергать функцию, при каких ситуациях.
Файл-серч в разных сценариях, интуитивно понятно, что в файл-серч можно заворачивать очень многое.
Если вы внимательно смотрели на тот скриншот, который показывал Миша,
там было различных расширений, вплоть до аудио и видео, которые вы можете отправить и использовать для построения вашего индекса.
Но, конечно, самая частая история – это построение на основе какого-то вики-формата, на основе текстэшек, эксельников и так далее.
Еще хочу обратить ваше внимание, что вы можете использовать как дефолтное чинкование нарезание на определенные кусочки,
ваших файлов, так и делать его самостоятельно, задавать через такой формат, как JSON-L,
где текст вы предварительно разбиваете на чанки и заворачиваете в этот файл с форматом JSON-L.
Но если говорить про файл все очень в различных сценариях, то здесь, повторюсь,
можно использовать факт, можно использовать ответы на какие-то типовые вопросы,
которые все больше и больше разрастаются. Прежде я говорила, что если типовых вопросов
не много, то вы можете буквально завернуть их в промпт. Есть еще, например,
практика у поддержки такая, когда каждый вопрос, на который
они ответили, на который хорошо получилось ответить,
они добавляют в индекс, и потом при последующих обращениях
пользователя буквально происходит следующее, что выполняется
поиск, находят похожее обращение и заранее подготовленный
на него ответ, который уже отлажен и был заранее добавлен
веб-поиск это очень похоже на файл search история, но в данном
случае в роли индекса выступает весь интернет.
Да, это возможность, которая может быть полезна, когда
вам нужна не какая-то конкретная база знаний, которая
у вас уже накоплена, а очевидно поиск по открытому интернету.
Давайте посмотрим на пример в нашем сценарии, когда
это может быть полезно. Ну очевидно, что новые
настольные игры выходят каждый год, соответственно
у нас нет возможности трекать, записывать все
эти правила, скачивать все эти игры в
нашей базе знаний, и мы просто говорим модели,
что в случае, если вдруг тебя спрашивают про какие-то
данные, которых у тебя нет, про свежие, например,
игры, то используй веб-серч, сходи в интернет
и найди оттуда новые результаты.
Давайте посмотрим, как это использовать в коде.
Код практически идентичен предыдущему листингу,
мы, по сути, просто рассказываем, что есть еще одна функция,
в данный момент она уже называется веб-серч,
и она используется для поиска уже актуальной информации в интернете.
Из интересного и файловый поиск по интернету,
они обрабатываются на серверной стороне,
дальше мы в нашей презентации покажем и функции,
которые обрабатываются на клиентской стороне, но в данный момент
пока вот такие функции.
Ну и давайте посмотрим, как это всё выглядит в сборке,
как оно работает вживую.
Суставь топ-5 игр, самых популярных в 2026 году.
Самые популярные настольные игры 2026 года.
Ну и давайте посмотрим, как это выглядит в интерфейсе iStudio.
Чтобы подключить поиск по интернету,
выбираем инструмент с типом WebSearch
и добавляем либо домены, если предполагается,
что нужно искать по конкретным доменам,
либо ничего не добавляем, если предполагается,
что поиск нужно осуществлять по всему интернету.
Точно так же, как мы для файл-серча
указывали, в каких случаях вызывать его,
указываем, в каких случаях нам необходимо
вызывать WebSearch.
Это поможет модели лучше ориентироваться
и правильнее вызывать функции.
Ну и как использовать WebSearch в разных сценариях?
На самом деле, WebSearch можно использовать во многих случаях
аналогично файловому поиску, но мы встречаем на практике,
когда это реально полезно.
Например, если у вас есть поддержка и вся документация,
как у нас, сосредоточена на сайте,
то даже не обязательно к ней поднимать какой-то MCP,
можно использовать веб-поиск для того,
чтобы находить ответы по ней.
Или, например, вы делаете такого универсального голосового ассистента,
который, ну, Алиса-like, который умеет многое,
и для ответов на вопросы, начиная от погоды, закачивая курсом валют,
вы можете обращаться в поиск.
Также поиск может вам помочь в ситуации на дорогах,
понять погоду в некоторых случаях,
это действительно может быть важно,
или узнать курс доллара, актуальный на текущий момент.
Ну и давайте поглубже поговорим про инструмент Function Calling,
вызов функций, как я уже говорил,
есть возможность описывать не только встроенные функции,
но и произвольные,
соответственно, есть интерфейс специальный для их описания,
и как это вообще работает.
Давайте разберёмся.
Очень базово идея вызова Function Calls состоит примерно в следующем:
мы модели заранее говорим о наличии некоторых функций,
говорим о параметрах этих функций,
и дальше, соответственно, когда модель понимает,
что ей не хватает для правильного ответа
каких-то знаний, каких-то данных,
она уже возвращает ответ с вызовом этих функций
с правильными параметрами.
И непосредственное применение этих функций
выполнения происходит уже,
ну либо, если это встроенные функции
на нашей серверной стороне,
либо, если это клиентские функции
на клиентской стороне.
Если вы занимаетесь разработкой,
вполне вероятно, вы здесь увидели
паттерн RPC ,
который используется примерно
в таком же подходе.
Соответственно, про Function Calling можно думать
примерно как про RPC, но в применении
в рамках, соответственно, моделей.
Ну и давайте чуть-чуть посмотрим,
заглянем в протокол,
что именно летит по шине данных
в момент, когда происходит Function Call.
Здесь видно, что мы сначала должны
модели объяснить, что некоторые
функции можно вызывать,
рассказать про схему вызова,
переменные, параметры.
Дальше, соответственно, уже серверная
сторона, модель, принимает решение
про то, что необходимо Function Call
вызвать, соответственно, передает
специально сформированное сообщение
уже на обработку уже
клиентского устройства, и там
происходит непосредственный вызов
этой функции, туда же передаются
параметры, ну вот в случае
нашего
сценария мы подумали, что
для настольных игр было бы полезно
уметь бросать
кубик, чтобы
не носить с собой
физический кубик, то есть
если тебе понадобился
в момент игры какой-нибудь
бросок кубика, то эту функцию
может выполнить этот голосовой наш агент
и сказать какая циферка выпала
соответственно
уже на клиентской стороне
происходит выполнение функции
результат ее обратно
отправляется на сервер
передается в контекст
и дальше модель уже на основании
вот этого расширенного контекста
понимает
что ей нужно отвечать
и уже формирует итоговый ответ
ну и давайте немножко
как я уже тизернул
на нашем примере
рассмотрим как вообще в принципе
такую функцию добавить
нашего голосового агента
простой очень промт
по сути нам нужно
рассказать что
есть такая функция
что ее нужно вызывать
когда это уместно
ну и соответственно
как с ней работать
большая часть
конечно же будет уже реализовано
на нашем клиентском коде
а именно нам необходимо
во первых правильно
анонсировать
нашу
функцию здесь
стоит обратить внимание
именно на то что
формат передачи вот этой
функции описания ее
параметров он достаточно строгий
и требует
особого внимания
ну и дальше соответственно нам необходимо
реализовать эту функцию
а связь
вот этого
вызова функции которая
прилетела в ответ и
выполнение конкретной функции
уже берет на себя агентский SDK
и он понимает уже когда
нужно вызвать конкретную переменную
соответственно в данном случае
не переменную а функцию
вызовет ее сериализует и отправит
дальше в модель
ну и давайте посмотрим
брысь кубик
выпало 3
брысь кубик 2 раза
выпало 5 и 6
ну наверное какая-то честность брысков гарантируется
в разных сценариях
это вообще основа для модели
для совершения любого действия
на самом деле если углубляться
то тот же файл веб-сече
это по факту function calling
просто их реализация и обработка
оно спрятано на уровне обвязки
на уровне API
то есть function calling это практически любое действие
которое можно совершить
от записи изменения чего-то
в CRM до перевода звонка
на оператора
мы
сегодня построили наш рассказ
по
усложнению функций
и
function calling
является таким
совершенно базовым кирпичиком
но на основе его
существует несколько вот вариантов
и когда вам уже
нужно
обогатить
ваш сценарий большим количеством
функций, каждую функцию
уже тяжеловато будет
описывать отдельно, поэтому
существует
отдельный такой протокол, он много
где используется в рамках
больших лингвистических моделей
он называется MCP
Model Context Protocol
и что же
он позволяет? По сути
внутри работает тот же самый
Function Calling, но
он позволяет, во-первых
создавать
какие-то серверные решения
которые удобно и легко
вызывать модели
модели понимают
как с этими серверными
решениями взаимодействовать, как их вызывать
есть решения
для вызова
тулов, это не в рамках
реалтайма, но в рамках
решений
каких-нибудь
кодинговых ассистентов, когда
эти MCP
серверы могут располагаться
у вас также
в вашем контуре
ну и
вообще в принципе
если говорить про
MCP, это целый такой отдельный
новый мир, в который
глобально позволяет
дать в
пару небольших инструкций
модели
новую функциональность
это может быть как функциональность
в плане дополнительного источника
знаний, так и возможность совершать
какие-то вот действия
ну давайте посмотрим
как это
как этот раздел
mcphub
mcp выглядит в
e-study
а как показывала
Настя на карте
e-study это также
стандартный компонент
ну и в нашем случае
мы подумали
что было бы классно если бы
мы могли не только
проконсультироваться с нашим голосовым ассистентом
по поводу настольных игр
но также попросить его запланировать
в календаре
встречу, чтобы мы все
пришли в нужное время и место
позвать всех друзей
и
действительно поиграть в настольные игры
я
не буду сейчас сильно много
рассказывать про то как
устроен наш
MCP-сервер
для работы
очень тезисно расскажу, что
мы использовали
стандартный их
набор компонент
которые идут либо в
E-студию, либо в
Яндекс Клауд, а именно
мы использовали MCP-сервер
для
интеграции в нашу модель
мы использовали
непосредственно
обработку событий
вот здесь вот внизу слайда видно
Create Event - это конкретный
тул в рамках нашего
MCP-сервера, который может использовать уже
модель, соответственно
внутри
задеплоены
Serverless функции
и там уже происходит
такой тонкий, тонкая прокся,
которая получает набор параметров
и уже взаимодействует
с API
Яндекс.Календаря
естественно подготовлены
специально инсталляции Яндекс.Календаря
точнее
созданы
приложения в рамках Яндекс.Календаря
со своими креденшилами
которые уже
являются
параметрами
Serverless функций
ну и
чуть-чуть
заглянем, что у нас находится
внутри каждого
из тулов
mcp-сервера, вот мы видим
здесь, по сути, схему
параметров инструмента
по вот этой схеме
модель понимает, какой ей
нужно сделать вызов, как
соответственно, какие параметры нужно передать
если ей каких-то
параметров не хватает, то она их
получает да узнает, ну и дальше, соответственно
в момент вызова происходит
уже обработка
как я уже сказал
МСП хаб
и
решение для МСП в
ИИ-студии - это
тема для отдельного разговора и
к счастью у нас такой разговор
уже происходил
поэтому, пожалуйста
сходите
по
QR-кодику, по ссылочке и
посмотрите отдельно лекцию
по поводу всех
возможностей
нашего решения для
МСП
Давайте немножко
посмотрим, как же
использовать
наш МСП сервер для работы
с календарем
Здесь супер важно
использовать
какие-то
переменные, чтобы модель понимала
в какой момент
происходит запрос
в какой сегодня день
и соответственно дать ей какой-то дополнительный контекст
Здесь же используется переменная
friends - это
способ модели сказать
кого нужно позвать в календарь
ну и какие-то дополнительные инструкции
примерно как нужно
работать с вот этим вот
тулом. Дальше соответственно
есть
имплементация в коде
по сути
ключевым
здесь является то что мы
созданный вот этот вот
mcp-сервер берем
в качестве
строчки подключения
в качестве
его идентификатора
передаем в
контекст сессии
и дальше
уже
модель сама понимает, как
работать с этим сторонним тулом
давайте посмотрим, как
это работает вживую
собери нас на игру
на вечер
уточните, пожалуйста
какую игру хотите
сколько человек будет
и на какую дату и время
планируете встречу
давай на пятницу 24 июля
играть будем в мафию
хорошо, подскажите, пожалуйста
во сколько начнем
и кто еще будет участвовать
напишите их имена
начнем в 7 часов вечера
и приглашай всех
события на пятницу 24 июля
в 7 вечера по игре в мафию
создано
участники приглашены
спасибо
пожалуйста
удачной игры
ну и как результат
это реальный скриншот
из моего календаря
там появилась встреча
она действительно на 24 июля
действительно 7 часов вечера
я в качестве параметров
чтобы не спамить
своих друзей передал
копии своих емейлов
ну и соответственно в качестве участников
меня позвали
в качестве
на игру
и
обратите внимание насколько
круто модель умеет
понимать каких
данных ей не хватило
умеет доспрашивать и уже
собранные данные потом передать
в один вызов
ну и какие сценарии могут
использовать mcp на самом деле если
вот разделять mcp и function calling
это конечно же у нас более такая
история когда все подчинено
определенному стандарту вам не
приходится думать как задавать
описание и mcp вот протокол который
принят сообществом который уже
наверное больше года так точно
живет и все больше api получает
обертку в виде mcp кто-то делает его
самостоятельно где-то находятся
энтузиасты но из того что мы видим что
чаще всего с чего начинают это mcp для
разного рода календарей crm для
баз данных ну и практически каждый
сервис у нас в последнее время
получает обвязку в виде mcp единственное
ограничение там конечно же нет никакого
потокового взаимодействия все
происходит в таком рест стиле и теперь
мы когда построили агента наделили его
знаниями дали ему такие инструменты пришла
пора задуматься про и викс
транкейт это функциональность которую мы
запустили недавно про нее широко не
рассказывали и что она позволяет делать на
самом деле она позволяет определять в
какой момент пользователь перебил агента
казалось бы наверное проблема не такая
глобальная как могло бы может показаться но на
самом деле это довольно частый кейс и для
ряда наших клиентов это даже было каким-то
блокером для интеграции они буквально
просили чтобы мы реализовали эту
функциональность поддержали ее и суть в
следующем что допустим вы сообщаете в
одном в одной реплике что ваш заказ
доставят завтра с 10 до 18 часов и
пользователь такой да спасибо понял и если
реализовывать агента без функциональности
транкета то модель решит что она
произнесла фразу которую задумала целиком
то есть а фраза целиком состояла в том что
там доставка в такое-то время что вам
позвонят за час и курьер что тоже важно и
если вас не окажется на месте доставка
будет в нашем случае перенесена возможно
другие варианты с транкетом модель
будет понимать в какой момент ее именно
перебили и и строить дальнейшее
взаимодействие исходя из этого контекста на
самом деле это очень востребованная
x-механика если вы еще не пробовали
прикрутить транкет в своем реал-тайм
клиенте очень советую попробовать
давайте заглянем чуть-чуть в глубь
протокола и немножко освежу понимание
как как именно вообще в какой момент
возникает проблема у нас есть компоненты
которые отвечают за синтез она уже
сформировала аудиофайл и уже отправила
его на устройство но при этом устройство
весь аудиофайл проиграть не успела
весь соответственно ответ и с точки
зрения модели она уже ответила а с
точки зрения конечного пользователя
он весь ответ еще не прослушал и транклейт
как раз решает вот этот разрыв он
позволяет клиенту уже сообщить что я
тебя перебил я тебя не дослушал и если ты
со мной будешь разговаривать то учитывай
что я дослушал только вот эту вот часть
ну и глобально тут есть несколько
событий из шины данных наверное самое
важное тут выделено жирным шрифтом
собственно тип события conversation
item truncate он означает что мы
truncate или вот этот вот файл и
также он помечает как раз сколько какой
кусок аудиофайла был уже проигран чтобы
модель могла это учесть
давайте попробуем реализовать это в
нашем агентском сценарии а именно мы
знаем что правило у настольных игр
бывают достаточно долгими
соответственно если вдруг мы перебили
модель где-то посредине то было бы
классно чтобы она не сначала начала нам
зачитывать все правила а в том же месте
где перебили нам бы и дочитала но если
вдруг по какой-то причине мы не
дослушали этот результат то соответственно
модель бы тоже учитывала что вот мы
знаем только часть этих правил большая
часть имплементации она находится на
серверной стороне поэтому нам самое
важное немножко запромтить модель
сказать что в случае чего во первых
побудить ее отвечать нам развернуто во
вторых учитывать что результаты были
затранкличены посмотрим обработку в коде
нам действительно нужно следить за тем
сколько мы аудио файла проиграли и
в случае если у нас происходит
перебивание то необходимо как раз
отправить вот это событие чтобы сервер
уже понимал какой кусок данных уже был
озвучен ну и давайте посмотрим это в
живую
расскажи правила игры в манчкин
манчкин пародия на ролевые игры в начале
игры
продолжим
в игре манчкин вы создаете персонажи
человека первого уровня без класса
выбираете пол расу и класс выкладываете
карты шмоток свой ход можно открывать
карты дверей если там монстр бой если нет
выбираете искать неприятности или чистить нычки боевая сила это уровень плюс
бонусы от шмоток и других карт если ваша сила выше силы монстра победили
получаете уровень и сокровища можно помогать другим или мешать им использовать
проклятие цель первым достичь 10 уровня победив монстра если хотите уточните
что-то конкретное про правило расскажу подробнее
теперь мы все знаем как греть манчкин транклейт в разных сценариях давайте я приведу там пару
практических примеров не буду глубоко погружаться но например с тем же вызовом мастера на дом возможно
такая ситуация мастер приедет завтра с 10 до 18 оплата только наличным если учесть ну например
не дослушать окончание фразы может возникнуть довольно таки неприятная ситуация или когда у вас
той же самой доставкой что если вы не снимете трубку допустим другом кейсе за час до прибытия
курьера доставка будет перенесена на другой день и опять-таки человек может ваш потенциальный клиент
убить какое-то количество времени там ждать целый день но из-за того что недослушал очень сильно
пострадать вот эти всякие условия казалось бы их можно там разбивать на несколько реплик и после
каждый спрашивать поняли поняли услышали но по факту это делает диалог ну максимально неудобным
раздражающим для пользователя и такое вот поняли услышали оно хорошо тогда когда вы например звоните
в поддержку и говорите у меня что-то не работает и поддержка зайдите на сайт получилось здесь да здесь
такое уместно но в нашем кейсе когда мы например назначаем доставку и хочется все сказать в одной
реплике разбивать на какие-то такие блоки ну это очень неестественно для живого диалога поэтому
предлагаю попробовать транкейт это правда очень помогает в реальных диалогах и экономит кучу нервных
лепток вам и вашим клиентам мультиагентность и вот мы добрались до мультиагентности что такое
ну из названия понятно что это когда агентов не один а их несколько почему же возникает такого
рода потребность почему же необходимо заводить несколько агентов возникает это тогда когда у вас
идет некое усложнение и когда вы уже наверное начинаете понимать интуитивно что промт как-то
раздувается и что здесь уже как бы ну не одна сущность оперируют а как минимум там две или даже
три и у них могут быть даже разные голоса разные инструменты которыми они оперируют и разный контекст плюс
может быть даже какие-то разные политики ведения диалога все зависит от вашего сценария и вот еще
одна неочевидная причина это когда сколько в зависимости от того какая модель используется
часто бывает так что не все модели справляются там с огромным количеством инструментов которые
хочется присоединить ведь как начинают заворачивать mcp свой api и притаскивают 100 с лишним инструментом
конечно это довольно сложновато переваривать модели а еще более сложно описывать и наверное
как-то логично бы разбирать все это многообразие на какие-то конкретных агентов которые ими оперируют
и вот таким образом у нас появляются дополнительные агенты один из самых частых паттернов вообще как
работают несколько агентов есть диспетчер и соответственно он диспетчеризует запросы
разным агентом, каждый из которых специализируется на чем-либо
ну все буквально как в программировании декомпозиция, организация
давайте в нашем сценарии попробуем выделить как раз несколько агентов
давайте разделим часть тулов на консультационные, так скажем
и вторую роль выделим как организатора встреч
у нас получится два разных агента, два разных амплуа
назначиваем разные голоса, чтобы было понятно с кем мы сейчас говорим
ну и начинается все с промптинга
мы рассказываем модели про то, что она должна делать, про ее роль
и рассказываем про то, что в случае, если необходимо сделать что-то, что умеет соседний агент
то необходимо как раз передать разговор в терминах, соответственно, агентских
это действие называется хенд-офф
нам нужно запромтить второго агента
у второго агента все то же самое, история про базовую роль
ну и конечно же тут нужно будет еще рассказать про передачу роли, передачу разговора второму агенту
немножко напишем кода, по сути код здесь достаточно простой
мы делаем двух агентов, большую часть оркестрации берет на себя SDK
и в данном случае мы немножко кастомизируем второго агента, чтобы у нас был другой голос
и дальше реализуем как раз функцию передачи
ну и давайте посмотрим на тему кода передачи
код передачи довольно простой, мы по сути говорим в какой момент и как его нужно обрабатывать
соответственно уже знакомую нам function call объявляем
ну и обрабатываем этот function call, немножко оркестрируя контекстом уже на устройстве
давайте посмотрим на то, как данное решение уже выглядит вживую
когда у нас запланирована игра у нас запланирована игра в мафию 24 июля в 19 часов ровно
мы сейчас играем, брось кубик два раза
первый бросок пять, второй один, всего шесть
ну и как можно реализовывать мультиагентность в разных сценариях
на самом деле все будет зависеть от ваших предпочтений и вкусов
но, например, вы можете в той же поддержке делать разных агентов
ответственных за разные продукты, за консультацию по ним
можете делать агент обработки возражений
сбора обратной связи, конкретной информации и так далее
мультиагентность может быть продиктована еще и вопросом реализабельности агента
в разных сценариях. Например, написав агента сбора информации,
вы можете его использовать не только в одном сценарии,
где вы совершаете холодный звонок и уточняете интересы
клиента, но и таким образом сделать такой отчуждаемый
компонент, который можно реиспользовать в разных сценариях,
не только с этим продуктом, про который вы, собственно,
сейчас думаете. Подключение к телефонии. Здесь встает
вопрос, вот мы сделали агента, он выполняет задачу,
протестировали в UI, что дальше? Какие вообще шаги
можно предпринять для того, чтобы подключить агента
к телефонии? Что можно сделать самостоятельно? Написать
медиашлюз, который переводит WebSocket в СипРТП и обратно
и сконнектить телефонию с реал-таймом.
По опыту клиентов, кто писал, занимает не такое
большое количество времени. Возможно, в «Строянаргоком»
ребята расскажут на вебинаре, как они с этим справились,
но по факту медиашлюз не такой страшный патрот,
как может показаться и вполне себе реализуем, особенно
с применением современных кодовых агентов.
Также можно подключиться через партнеров, у нас есть
партнеры, которые интегрируются по протоколу реалтайма
от OpenAI, и среди них сейчас есть Vox Implant, поэтому
если ваша телефония Vox Implant, или вы можете проложить
транк для нее, можете воспользоваться агентом на реалтайме прямо
сейчас.
Сейчас мы еще делаем такой экспериментальный подход,
когда сделали Endpoint Ки-студии, и у всех, у кого есть телефония
и кто может поднять сип-транк для нас, может пользоваться
агентами внутри.
Это пока экспериментально и ограничено по числу
участников, но я очень надеюсь, что в скором времени станет
доступно всем.
Там флоу такой, что вы буквально собираете агента в UI и
потом, соответственно, обращаетесь от своей телефонии по сип-транку
к нашему сип-эндпойнту.
Таким образом, ваша телефония приобретает такую, ну, своего
рода петлю в виде агента, который работает с голосовым
трафиком и возвращает голосовой трафик назад.
Упс, так, говорят, подключение.
Ну и, да, давайте немножко подойдем, подведем итоги.
Мы сегодня продемонстрировали достаточно много фичей,
было много кода, очевидно, мы не надеемся, что вы
быстро все переписали со слайдов, и более того, код у нас
сегодня был на слайдах такой немножко иллюстрационный,
он взят из реальных примеров, и вот реальные примеры
мы оформили в виде гитхаб-репозитория с инструкциями по запуску.
Пожалуйста, используйте первый QR-кодик для поиска этого
как раз репозитория, ну и, конечно же, вам понадобится справка,
документация, она у нас есть, и используйте второй QR-код
для быстрого доступа к документации.
Поговорим немножко про планы, что мы хотим делать с продуктом
в ближайшее время, в перспективе, там, нескольких месяцев.
По мере подготовки к вебинару у нас нарисовалась такая карта
реалтайма, где у нас есть уже поддерживаемый уже функционал,
среди которых FAC, SEO, web, SEO, MCP, то есть про что мы сегодня рассказывали,
транкейт для выполнения разных UX-механик, синтез и распознавания речи.
Все это, конечно, замечательно, но мы, конечно, не будем останавливаться на этом,
мы будем врастить функционал и обновления ближайших, которые мы планируем.
В первую очередь мы занялись голосами, занялись синтезом и планируем сделать его максимально живым,
добавить в общую библиотеку голосов, новые голоса, которые больше подходят для таких операторских сценариев,
когда нужно много и долго говорить и делать это максимально естественно.
Из планируемых еще работ, это более стабильная работа с функциями,
когда мы хотим больше экспериментировать с моделями в части ЛМ,
экспериментировать с так называемыми агентскими моделями
и делать все возможное для того, чтобы мы поддерживали больший контекст
и чтобы можно было подключать большее число функций.
Также мы хотим заниматься дальше улучшением диалоговых механик.
Мы понимаем, что мы вступаем в это поле, в эту сферу,
где хотят создавать голосовых роботов нового поколения,
которые управляются ЛМ-ками, и там возникают многие челленджи,
с которыми сталкиваются роботы, которые классически построены на графах,
в плане X, в плане перебивания, активного слушания, долгих провисаний и так далее.
Собираемся это все преодолевать.
По ходу вебинара, наверное, стало понятно, что написание промта —
это тоже довольно непростая задача.
Я периодически привожу там две аналогии.
Представьте, что у вас вышел хороший, замечательный сотрудник,
первый день он работает, вы ему дали все необходимые инструменты,
он очень сообразительный, но нужно поставить ему задачу.
Сам он себе задачу не придумает.
И вот вам нужно как-то это все объяснить.
И чтобы это объяснить, нужно проделать ненулевую работу,
подчас даже бизнес-аналитику.
Вторая аналогия у меня — это, скажем так, ремонт.
Все понимаем, как делать ремонт, что там вроде как и обои,
вот там шпаклевка, что нужно позвать строителей и ограничения такие-то,
но довести дело до конца, до ума бывает очень сложно,
поэтому обращаемся к специализированным людям,
которые нам помогают вот эту всю какофонию того, что у нас есть,
привести к законченному проекту и реализовать такие ремонт,
ну, в нашем контексте написать промт.
Поэтому будем работать в этом направлении.
И, конечно, хотелось бы, чтобы все экспериментально переросло в продакшены,
и чтобы у нас появилось больше партнеров,
которыми мы нативно интегрированы, и можно максимально быстро
и без лишних усилий подключать созданных агентов в телефонии.
Спасибо за внимание. Готовы ответить на вопросы.
У нас есть определенная подборка вопросов в чате.
Может быть, мы еще покажем еще один QR-код,
перед тем, как мы вопросы ответим.
У нас заготовлен еще один QR-код.
По сути, здесь небольшая форма,
для того, чтобы можно было проверить
ваши знания по горячим следам.
Мы собрали несколько вопросов,
которые мы обсуждали в рамках
нашей сегодняшней презентации.
И можно сходить, посмотреть,
насколько вы усвоили материал.
Ну и теперь предлагаю вернуться к вопросам.
Давайте пойдем по вопросам,
которые нам прислали.
Актуальны ли парамты сейчас общая практика?
Это тоже самое на правильных файлах.
Называется скиллы.
Ну, давайте так.
Мы в эту сторону тоже смотрим,
понимаем необходимость скиллов,
но в части голоса там есть определенные нюансы.
Но вы правы, что хочется делать
что-то такое подключаемое, настраиваемое.
И, в принципе, вот эти все наши разговоры
про маркдаун, они вот как раз
перепрекаются с тенденцией скиллов.
Да, мы смотрим в эту сторону.
Посмотрим, что у нас.
У нас буквально меняется каждый день.
Хочется, конечно, ввести свой какой-то протокол.
Возможно, мы его и введем, и попробуем
для наших пользователей.
Базовая идея промптинга, она никуда не уйдет.
Вполне вероятно, что вот это вот тонкое искусство,
управление промптом, соответственно,
филигранное вытачивание инструкций,
оно, скорее всего, как раз уйдет,
модели становятся умнее, и какой-то файн-тюнинг
с помощью промптов, он как раз уходит,
но базовая идея, что тебе нужно рассказать
модели, кого ей играть, как ей пользоваться
тулами, и, соответственно, в каком контексте
она будет вести разговор, конечно же,
это останется, и на будущее формат при этом
может поменяться.
Вопрос от Андрея.
Каждый запрос API может возвращать его стоимость,
например, в поле ключ-кост.
Нет, такое не происходит сейчас.
У нас есть, я не помню, получается, событие, которое
возвращает токены, которые использовались LLM, в части
входящие и сходящие кэшированные токены инструментов.
Но, насколько я помню, у нас не возвращаются токены,
которые отвечают за голос.
Посмотреть их вы можете непосредственно в интерфейсе
AI-студии в разделе «Биллинга».
И в целом нужно отличать API от «Биллинга»,
то есть я соглашусь с тем, что можно возвращать какие-то единицы,
которые как-то оцениваются, по которым идет тарификация,
но сама стоимость в API нет, такого точно не будет.
Еще один совет, когда вы работаете с агентом,
как правильно считать, сколько там у вас получается минуту,
на каждого агента я бы все-таки советовала заводить отдельный фолдер
и смотреть, сколько там минут было и зарасходовано,
и таким образом получать стоимость за минуту.
Вопрос от Александра.
Какие логи можно просматривать, где их просмотреть?
Можно ли увидеть все, что ушло в модель для принятия решения?
Давай я отвечу.
Давай.
Если глобально, то сам протокол, он достаточно такой вот избыточный,
ну не избыточный, но достаточно такой вербос, многословный что ли.
То есть есть канал аудио, где вы разговариваете, где пользователь даже разговаривает с моделью,
а есть еще дополнительный слой, поток событий, и вот этот поток событий,
он уже может служить таким вот логом для сервиса, приложения, чтобы понимать, что происходит.
Ну и у нас пока не поддержано, мы в эту сторону тоже поглядываем.
Наш дружеский соседний сервис Responsys недавно проинтегрировался с нашим же дружеским сервисом Monu,
и глобально ребята поддержали такой вот паттерн observability в рамках как раз ассистентов,
в рамках текстовых моделей соответственно там гораздо больше информации появляется что происходило в рамках вот именно общения вот мы активно в эту сторону тоже смотрим вопрос это Евгения настройки проекта в UI сохраняются в гид, ты ответишь или нет ну давай да они скорее существуют немножко в разных историях у нас есть какая-то вот преемственность
да там история изменений промтов но при этом это не не гид репозиторий и в целом это два немножко таких вот разных мира один это редактирование через веб-интерфейс оно скорее решает задачу получения актуальной актуального слепка сейчас а работа с гидом хранение исходников это ближе к классической разработке
ну и соответственно история версий в этом смысле у нас они немножко разделены вопрос от артема на конфе айту бизнес дали послушать новые голоса а это то что мы говорили которые должны появиться осенью все так это будут новые более умные реал-тайм модели обновиться только озвучивание у нас будут и более умные реал-тайм модели и обновиться озвучка в целом у нас как мы говорили ранее и говорила ранее под капотом реал-тайма каскад моделей но будут их
по-прежнему три или больше и меньше как они будут комбинироваться мы будем экспериментировать и в любом случае голоса станут более живыми это осенью а модель реал-тайма поумнеют вопрос от Андрея есть ли возможность испринимать только голос того с кем был начат разговор изначально чтобы избежать включения в разговор перебивания этакая фильтрация по собеседнику ну то есть здесь идет речь про то что можем ли мы
сделать своего рода такую биометрию и слушать только того собеседника с которым исходно начали разговор ну таких планов пока нет мы всячески работаем над обработкой мы думаем над тем как фильтровать разные шумы условно говоря звуки там телевизора и так далее то что может клиниться в разговоры или там разговаривать условно с банком а кто-то там сзади орёт там духовку выключить там все сгорело чтобы это
никак не аффектила модель над механиками думаем но вот именно в таком ключе скорее нет вот постараемся как бы задача
понятно чтобы не попадали лишние звуки не от целевого собеседника но решать ее будем постепенно как
именно пока еще думаю вот у тебя есть какие-то комментарии по вопросу ну базово да тут всегда
ищется какой-то баланс вы можете на самом деле и на себе понять когда разговариваешь с
собеседником который находится в какой-то шумной среде иногда можно соответственно даже
не понять правда ли это собеседник произнес какую-то фразу или нет там сильно очень много
зависит от контекста мы правда смотрим на то как улучшить распознавание в таких шумных
средах но при этом какого-то эталонного в общем классической серебряной пули в этом смысле нет вот
мы тут работаем над тем чтобы это качество непременно росло так вопроса дмитрия можно ли
реализовать такой сценарий пользователь просит что-то сделать проговаривать сложно для распознавания
слова агент просит уточнить что сказал человек либо показывает текст расшифровки чтобы человек
мог провалидировать и найти ошибки справить и отправить дальше уже провалидированный текст да вполне
себе возможная история то есть realtime базе свою распознает а что с этим текстом дальше делать решает
модель она может буквально показать его в неизменном виде или даже предложить какие-то
корректировки глобально протокол вообще realtime предусматривает вот и вывод как голосовой так и
текстовый и он активно использовался в наших презентациях вот те текстовки которые
соответственно распознаны были на голосовом вводе и отправлены на синтез мы отображали на
экране то есть они дублируют голосовой вывод нашего сервиса поэтому в целом вот это вот
решение оно чуть-чуть сложновато интерфейсно решить потому что тебе нужно сразу и голосовой
канал как-то решать и соответственно визуально поверхность иметь для отображения текста но идея
вполне конструируемая и решаемая и так завершающий видимо вопрос вопрос от олега можно ли ограничить
вопсёч для голосовых агентов только по доменам ru или rf но сейчас в рамках api такое сделать
нельзя можно ли сделать принципе ну давайте мы возьмем как домашку на подумать то есть глобально
у нас есть возможность ограничения конкретного домена чтобы искать на конкретном каком-то сайте
мы давай возьмем в проработку запрос на видимо топ-level domain можно ли вот так фильтровать на этом
все вопросы закончились и у нас есть еще такое небольшое объявление у нас есть ежегодная
конференция scale она проходит в сентябре актуальные даты можно будет посмотреть на сайте и в рамках
ее проходит называемый челлендж вы можете приходить со своими идеями по реализации всякого рода и
проектов присылайте их к нам и лучшие идеи получат как гранты так и помощь в реализации а финалистов
мы увидим и наградим на скиле подробности можно посмотреть на сайте а и студия вот пользуясь
случаем прорекламирую эту нашу активность классные возможности себя показать и других посмотреть да
спасибо нам очень понравился наш сегодняшний вебинар спасибо вам за вопросы будем рады видеть вас снова до новых встреч пока
и