Transcription
Всем привет. Мы снова здесь, чтобы провести детальный анализ самых горячих тем в мире технологий.
Привет. Сегодня у нас на повестке дня голосовые и аиагенты. Мы внимательно изучили материалы недавной сессии Open Auaa Build Tower, которая была целиком посвящена именно этому.
Да, тема очень актуальная. Наша задача - разобраться, что это вообще за звери такие эти голосовые агенты. Какие там последние новшества, ну и, конечно, как всё это может повлиять на то, как мы пользуемся приложениями, да и вообще взаимодействуем с техникой.
Согласна. Момент выбран очень удачно. Голосовые интерфейсы, ну, скажем так, переживают сейчас настоящий Ренессанс.
Ренессанс.
Ну да. Благодаря вот этим новым моделям, новым инструментам, они становятся гораздо умнее, гибче. И люди это замечают. Всё больше народу пробуют управлять чем-то голосом. Мне кажется, мы, возможно, стоим на пороге того, что это станет, ну, просто нормой.
Звучит интригующе. Ну что ж, давай тогда начнём со основ. В материалах Open AI постоянно фигурирует термин агент. Вот что они сами вкладывают в это понятие, можешь пояснить?
Да, конечно. Смотри, по версии Open AI, агент - это, по сути, комбинация из трёх вещей. Во-первых, сама AI модель. Ядро всего.
Угу.
Во-вторых, это набор инструкций. То есть это то, что говорит модели, что делать, какая у неё цель, как себя вести.
Понятно. Правила игры.
Именно. И в-третьих, что очень важно - это инструменты. Это то, что позволяет модели как-то взаимодействовать с внешним миром. Ну там, вызвать API, поискать в интернете, управлять каким-то приложением.
То есть не просто болталка, а штука с руками, грубо говоря.
Да. И ещё один ключевой момент. Агент работает в ней динамической среде и сам должен понять, когда его задача выполнена. То есть он не просто ждёт следующей команды, а имеет цель и стремится её достичь.
Хм. То есть это уже что-то более автономное получается. Не просто ответ на запрос, а некая сущность с целями, инструментами, способная сама завершить работу.
Совершенно верно. Это гораздо ближе к концепции такого, знаешь, автономного помощника, который может выполнять довольно сложные многошаговые задачи.
Звучит мощно, но вот смотри, концепция агентов не нова. Почему именно сейчас такой ажиотаж вокруг голосовых агентов? Что изменилось? Какие факторы тут сошлись?
Хороший вопрос. Я бы выделила, наверное, три ключевых драйвера этого интереса. Во-первых, это гибкость.
Гибкость. В каком смысле?
Ну, смотри, современные агенты, особенно те, что построены на больших языковых моделях, ну, типа GPT for и так далее, они гораздо лучше справляются с неоднозначностью.
Ага.
Понимаешь, старые голосовые системы, они были очень детерминированными. Шаг влево, шаг вправо, всё, система ломается, не понимает тебя. А современные модели могут понять запрос, даже если он сформулирован не совсем стандартно, как-то коряво, с ошибками. Они пытаются понять суть, контекст.
То есть меньше вот этой жёсткой привязки к конкретным командам.
Да, это уже не просто распознавание команд, а попытка понять собеседника на более глубоком уровне. Это прямо качественный скачок.
Логично. От простого распознавания к пониманию звучит как серьёзный шаг вперёд. Что ещё? Какой второй фактор?
Второй фактор - это, казалось бы, очевидная вещь, но сейчас она вышла на новый уровень. Доступность и удобства.
Ну да, голосом вроде всегда было удобно. Или нет?
Удобно-то удобно, но раньше это работало не так хорошо. А сейчас, когда технологии подтянулись, подумай сам: "Ты за рулём или готовишь что-то, руки занятые или просто гуляешь по улице?"
Ну да, телефон доставать, печатать не всегда удобно.
Вот. А голосом сказал и всё. Освобождаются руки, глаза. Это базовая эргономика. Но именно развитие технологий сделало голосовое управление по-настоящему эффективным и приятным. Раньше это часто было источником фрустрации, а теперь реальное удобство.
Да, ситуации знакомые. У меня самого бывает. За рулём диктую сообщение. О'кей. Гибкость, удобство. Третий фактор. Ты упоминала персонификацию.
Вот это что такое?
Да и вот это, на мой взгляд, самое захватывающее. Это персонификация и эмоциональная краска.
Эмоциональная краска, в смысле и теперь с эмоциями.
Не совсем так, что он испытывает эмоции, но он может их распознавать и воспроизводить. Особенно это касается новых моделей, которые работают по принципу речь в речь. Мы о них ещё поговорим подробнее.
Неуверенности или, наоборот, радости в голосе пользователя и могут отвечать соответственно с подходящей интонацией, с нужным темпом. То есть, если я говорю раздражённо, он не будет отвечать мне монотонно радостным голосом робота?
Ну, в идеале, да. Понимаешь, когда мы преобразуем речь в текст, а потом текст обратно в речь, вот эта вся информация, которая не в словах, а между слов, в интонации, она теряется полностью.
Хм, действительно, мы же кучу информации передаём именно тонам.
Вот именно. И Open AI очень метко назвали вот эту способность улавливать нюансы речи опикреальному миру. Потому что голос - это не просто слова, это целый пласт информации о состоянии человека, о контексте. И когда и начинает это понимать и использовать, взаимодействие становится, ну, гораздо более естественным и человечным. Это решает проблему последней мили в коммуникации с машиной.
А к реальному миру сильно сказано. О'кей. Если технология настолько многообещающая, как же разработчики сейчас подходят к созданию таких вот голосовых штук? Есть какие-то устоявшиеся подходы?
Да, сейчас можно выделить два основных пути, два подхода. Первый, назовём его цепочечный подход. Он такой более традиционный, что ли.
Цепочечный. Из чего цепь?
Из нескольких этапов, которые идут друг за другом. Смотри, сначала речь пользователя записывается и отправляется на модель Spech to текст, сокращённая STT. Она превращает аудио в текст.
Распознаёт речь. Угу.
Да. Дальше этот текст идёт в мозг системы. Обычно это какая-то большая языковая модель, например, GPT41, как в примерах Open AI. Эта модель анализирует текст, решает, что ответить, и генерирует текстовый ответ.
Понятно. Текстовая обработка.
И, наконец, третий этап. Этот текстовый ответ отправляется на модель текст spech tts, которая синтезирует речь, озвучивает текст. И вот этот звук уже слышит пользователь. Речь текст, логика текст, текст - речь. Получается такая цепочка.
Выглядит как вполне логичная, проверенная временем схема. Наверняка у неё есть свои плюсы.
Конечно. Главный плюс - это гибкость. Ты можешь для каждого этапа этой цепочки выбрать самую лучшую модель. Например, взять лучший ССТвижок от одного разработчика, мощнейшую LLM от другого и самый приятно звучащий TTS от третьего. Можно комбинировать.
То есть конструктор такой.
Да. И ещё важный момент. Если у тебя уже есть какая-то система, которая работает с текстом, чатбот, например, то добавить к ней голосовой интерфейс с помощью такого подхода относительно просто. Ты просто прикручиваешь SST на входе и TTS на выходе.
Звучит практично, но вот ты говорила про потерю интонаций. Мне кажется, в этой цепочке как раз и кроется проблема. Речь в текст. Всё, нюансы пропали. Текст в речь, ну, синтезатор может попытаться что-то изобразить, но исходной информации-то уже нет.
Абсолютно точно подмечено. Это и есть главный недостаток цепочки. Всё богатство человеческой речи, интонации, паузы, вздохи, эмоциональное состояние, всё это срезается на этапе STT. Текстовая модель получает просто голые слова. И, соответственно, TTS на выходе тоже звучит часто довольно плоско, роботизированно, даже если сам голос приятный.
Теряется та самая человечность, о которой ты говорила.
Именно. И поэтому сейчас всё больше внимания привлекает второй подход. Это речь в речь или speech to speech? S to s.
Речь в речь, то есть без текста посередине.
Да, в этом вся суть. Модель SS обучается напрямую понимать аудио на входе и генерировать аудио на выходе. Она как бы думает в аудиоформате и оперирует аудиотокенами, минуя стадию текста.
Ух ты. То есть она слышит меня и сразу отвечает голосом, не переводя это в буквы.
Именно так. Примеры таких технологий - это вот нашумевший Advanced Voice Mode в Chat GPT или Real Time API, который Open AI сейчас активно продвигают для разработчиков.
И какие у этого подхода преимущества, кроме сохранения интонаций?
Ну, сохранение интонации и эмоциональной окраски - это уже огромный плюс, но есть и другие. Во-первых, очень низкая задержка. Поскольку нет вот этих шагов преобразования туда-сюда, ответ генерируется почти мгновенно. Это критически важно для естественного диалога. Никто не любит разговаривать с собеседником, который тормозит.
Да, задержки убивают весь эффект присутствия.
Вот. А второе преимущество, связанное с первым - это та самая эмоциональная интеллектуальность, как её иногда называют. Модель не просто слышит слова, она слышит, как они сказаны, и может отвечать также с нужным ритмом, тоном, эмоцией. Это делает общение гораздо более живым. Естественным.
Звучит как настоящий прорыв, но наверняка есть и минусы. Вот ты упомянула Отладку. Если нет текста посередине, как понять, что пошло не так? Если агент ответил что-то странное, это он не расслышал, не понял или не смог сформулировать?
Отличный вопрос. Проблема отладки S2 действительно существует. Без текстовых логов бывает сложно диагностировать проблему. Именно поэтому, кстати, Open AI недавно представили новые инструменты для трассировки аудио. Мы к ним ещё вернёмся. Они как раз призваны помочь разработчикам заглянуть внутрь S2С-модели.
Ага. То есть решение ищется. А есть ли другие ограничения у S2? Может, они пока не такие умные, как большие текстовые модели?
Ты прав. SOS-модели, особенно те, что оптимизированные для максимальной скорости Real Time, могут несколько уступать топовым текстовым LLM вроде GPT4.1 или новой осии в способности к очень сложным, многоэтапным рассуждениям или выполнению каких-то комплексных инструкций, требующих глубокого анализа.
Они больше заточены на быстрый живой диалог. То есть компромисс между скоростью и глубиной мысли.
В какой-то степени, да. Но и тут есть изъячное решение. Это делегирование.
Делегирование. В смысле агент просит помощи у текстова.
Именно SS-агент может вести основной диалог с пользователем, поддерживать вот эту быструю, естественную беседу. А когда возникает задача, требующая сложной логики, например, проанализировать большой документ или составить сложный план, он может вызвать специальный инструмент, который под капотом обращается к более мощной текстовой модели, той же GPT41. Она выполняет сложную часть работы, возвращает результат, и SOS-агент уже озвучивает его пользователю.
А, получается гибридный подход. Используем сильные стороны обоих миров. Интересно, как раз недавно, в сентябре, OpenA выкатили ряд обновлений, связанных вот с этими Real Timeмоделями. Расскажи, что там было самого важного?
Да, сентябрьские анонсы были довольно сфокусированными. В основном они били в две точки: упрощение жизни разработчикам и повышение качества самих Real моделей.
Давай по порядку. Что для разработчиков?
Во-первых, они выпустили TypeScript Agents SDK. Раньше основной SDK был для Python, а теперь появился аналог на Typeescript, который очень популярен в веб-разработке. И что важно, эта Typeescript версия имеет первоклассную поддержку как раз Real Time API.
То есть веб-разработчикам стало проще встраивать голосовых агентов прямо в сайты и веб-приложения.
Именно. Это снижает порог входа, делает технологию доступнее для гораздо более широкого круга разработчиков. Не нужно быть гуру Python, чтобы сделать голосовой интерфейс.
Хорошо, это плюс. Что ещё?
Во-вторых, запустили трассировку Real Time модели прямо в платформе Open AI.
А это то, о чём ты говорила в контексте отладки S2S?
Да. Теперь, если ты используешь их agents SDK, то весь аудиовход, что сказал пользователь, и аудиовыход, что ответил агент, автоматически записывается и доступен в твоём дашборде на платформе Open AI.
О, это удобно. Можно прямо прослушать диалог и понять, где косяк.
Именно не гадать по текстовым логам, которые всей картины не отражают, а услышать реальный разговор - это огромный шаг вперёд для отладки и улучшения СТС-агентов.
Согласен. Без этого было бы тяжко. Были ли улучшения в самих моделях?
Да. В-третьих, они обновили саму модель, которая используется в realtime AP. Выкатили новые сNпшот от 3 июня. И по отзывам ранних тестеров, там упоминались крупные компании вроде Intercom, Perity. Новая версия модели заметно лучше следует инструкциям и корректнее вызывает инструменты. То есть она стала умнее и надёжнее.
То есть и инструменты удобнее, и сами модели поумнели. Что-то ещё было?
И четвёртое небольшое, но полезное улучшение. Добавили параметр скорости речи. Спид параметр. Теперь разработчик может точнее контролировать, насколько быстро или медленно говорит агент. Это важно для настройки тональности и комфорта пользователя.
Понятно. В общем, работа идёт по всем фронтам. Давай тогда чуть глубже копнём в этот Agence SDK, особенно в новую Typesриpt версию. Что он конкретно даёт разработчику, кроме вот этой трассировки?
Ключевое преимущество - это очень простая интеграция с Real Time API. Буквально парой строк кода можно существующего текстового агента, который уже умеет использовать инструменты, исследовать инструкциям, превратить в голосовой Realй-агента.
Прямо так просто. А вся работа с аудиопотоками, Web RTC, Websockets, вот это всё.
SD берёт это на себя. Он абстрагирует всю эту низкоуровневую сложность. Если ты делаешь веб-приложение, он использует WebertC для прямого соединения с серверами Open AI. Если это, тобто разработчику не нужно глубоко вникать в детали этих протоколов. Он просто создаёт объект Real Time agent, передаёт ему существующего агента и всё, магия случилась.
Звучит почти слишком хорошо, чтобы быть правдой. Снижает порог входа радикально. Ты ещё упоминала ХНДОФS, передачу управления между агентами. Вот это очень интригующе звучит. Что это за механизм?
Да, передача управления - это очень мощная концепция. Это механизм, который позволяет одному агенту в ходе диалога передать эстафетную палочку другому более специализированному агенту.
Зачем это нужно? Почему не сделать одного суперагента, который умеет всё?
Ну, как показывает практика, пытаться сделать одного мастера на все руки часто приводит к тому, что он всё делает посредственно. Гораздо эффективнее построить сеть специализированных агентов, где каждый эксперт в своей узкой области.
Можешь привести пример, где это было бы полезно?
Легко. Представь службу поддержки в какой-нибудь компании. Звонит клиент. Сначала его встречает общий агент диспетчер. Он выясняет суть проблемы. Это технический вопрос или вопрос по оплате.
Угу. Если технически он делает хендоф, передаёт разговор агенту техподдержки, у которого свои инструкции, свои инструменты для диагностики, если вопрос по оплате передаёт агенту по биллингу, у которого свои доступы и скрипты.
Понятно? То есть каждый занимается своим делом.
Да? Или другой пример, приложение для изучения языков. Ты сначала общаешься с агентом для английского, потом говоришь: "А теперь давай попрактикуем испанский". И агент английского языка делает хендов агенту испанского.
А как это технически реализовано? Как один агент передаёт другому?
Технически это делается через вызов специального инструмента call. У агента есть инструмент, скажем, transfer to support agent. Когда он решает, что пора передать управление, он вызывает этот инструмент, передавая ему текущий контекст диалога, а система уже под капотом активирует нужного агента и передаёт ему этот контекст.
Звучит очень гибко, но вот тут у меня возникает вопрос: не рискуем ли мы создать слишком сложную, запутанную систему из кучи агентов, где отказ одного может всё поломать или где они начнут передавать пользователя по кругу?
Риск такой, безусловно, есть. Проектирование таких многоагентных систем требует тщательного планирования и, что очень важно, тестирование. Как раз здесь на сцену выходят те самые оценки и валs, о которых мы обязательно поговорим чуть позже. Без них строить сложные системы очень рискованно.
О'кей, к оценкам вернёмся.
Но потенциальные выгоды от специализации, повышение качества, ответов, лучше управляемость каждого отдельного агента, они часто перевешивают эту сложность. Чтобы это было не так абстрактно, давай посмотрим, как эти концепции SOS, SDK, handofs применяются на практике. В материалах ОPНАИ был очень наглядный пример с разработкой приложения для управления проектом редизайна.
А, да, помню. Там было несколько этапов развития приложения. Давай разберём.
Да, пример очень показательный, потому что он демонстрирует прямо эволюцию от простого к сложному, от текста к голосу, от одного агента к сети. Начиналось всё, как часто бывает, с простого веб-интерфейса. Представь себе что-то типа Google Docs или Apple Notes. Просто страничка для заметок, куда пользователь вручную вбивал идеи для редизайна, создавал вкладки и так далее.
Ну, стандартный такой инструмент для заметок. Медленно, наверное.
Вот именно, медленно и неэффективно. Поэтому первый шаг - это была автоматизация с помощью текстового агента. То есть добавили чатбота, которому можно писать команды.
Да, назвали его Workspace Agent. Ему дали базовые инструменты. Add tab добавить вкладку. Set selected tab переключить вкладку и так далее. Пользователь мог написать в чат: "Создай вкладку Вдохновение". И агент это делал. Стало быстрее, чем кликать мышкой, но всё равно нужно было печатать текст.
Логично. Текст - это уже лучше, чем ничего. Но голос-то удобнее. Следующий шаг.
Следующий шаг - переход на голосовой интерфейс. Взяли этого Workspace Agent и с помощью Realtime API и Agents STK превратили его в голосового. Теперь пользователь мог просто сказать: "Настрой мне рабочее пространство для небольшого редизайна кухни".
И агент создавал нужные вкладки.
Да. Он распознавал речь, понимал намерения и вызывал свои инструменты. A tab и тд. Это стало значительно быстрее и естественнее для пользователя, но тут же вылезли проблемы с пользовательским опытом UX.
А что не так было?
Во-первых, агент действовал молча. Он выполнял команду, но никак это не комментировал. Пользователь не всегда понимал, услышал ли его агент, начал ли он что-то делать. Во-вторых, голос был довольно монотонным, роботизированным. Ну и в-третьих, не было понятно, что именно агент делает в данный момент.
Да, такое молчаливое исполнение может раздражать. Как решали эти UX проблемы?
Решение было довольно изящным через модификацию промптаагента. В его инструкции добавили указания использовать так называемые фразызаполнители.
Типа секундочку, создаю вкладку.
Именно. Минутку. Сейчас обновлю рабочее пространство. Хорошо. Ищу информацию об этом. Это даёт пользователю обратную связь, показывает, что агент его понял и работает над задачей.
Маленькая деталь, а сильно меняет восприятие.
Очень сильно. Плюс в СДК встроена возможность прерывания речи агента. Interruption. Если агент начал говорить свою fillрф, а пользователь уже хочет сказать что-то ещё, он может просто начать говорить поверх, агент замолкает и слушает новую команду.
О, вот это круто. Возможность перебить - это же основа естественного диалога. Не нужно ждать, пока робот закончит свою тираду.
Точно. Это делает общение гораздо менее формальным и более эффективным.
Хорошо, с UX разобрались. Что было дальше в этом примере с редизайном?
А дальше пошла специализация. Разработчики поняли, что пытаться научить Workspace Agent, ещё и разбираться в дизайне не лучшая идея.
Почему?
Потому что это разные задачи. Workspace Agent хорош в управлении интерфейсом вкладке, заметки, а дизайн интерьера - это совсем другая область экспертизы. И, как мы уже говорили, лучше иметь специализированных агентов. Поэтому они создали отдельного дизайнера, агента-дизайнера.
Агент-дизайнер, то есть сфокусированный на творческой части.
Да? У него был другой промт, который описывал его как эксперта по интерьерному дизайну. И у него были другие инструменты.
Какие? Он тоже управлял вкладками.
Не напрямую. У него был один основной инструмент с взаимодействия с рабочим пространством. Make Workspace Changes. Это была как бы обёртка над всеми инструментами Workspace Agent. Add tab, Edit Note и тд.
А зачем так?
Это пример делегирования и инкапсуляции. Агент-дизайнер решает, что нужно изменить в рабочем пространстве. например, добавить идею про скандинавский стиль во вкладку Вдохновение, а затем вызывает инструмент make work space changes, передавая ему это описание. А уже этот инструмент возможно, используя под капотом мощную модель типа GPT41 для разбора сложного запроса, решает, какие конкретно базовые инструменты Tab Edit Note вызвать для выполнения задачи.
Хитро. То есть дизайнер думает о высоком, а техническую рутину делегирует.
Именно. Плюс у дизайнера был ещё инструмент Search the Web для поиска трендов, идей, картинок. И вот тут как раз проявился паттерн S2S плюс делегирование. Быстрый S2S-агент-дизайнер ведёт живой диалог с пользователем. Давай поищем идеи для кухни в стиле лофт. А когда нужно выполнить сложную операцию, найти тренды, проанализировать их и добавить в нужные вкладки, он вызывает соответствующие инструменты, которые могут работать чуть дольше и использовать более мощные модели.
Интересный небрид получается. Быстрый фронт-энд на S1S и мощный бэкэнд на GPT 4103, условно говоря.
Можно и так сказать. Контекст диалога при этом, конечно, передаётся между вызовами, чтобы сохранялась нить беседы.
А можно ли было сделать этого дизайнера ещё, ну, скажем так, более человечным? Не просто экспертом, а приятным собеседником?
Да, это был следующий, пятый шаг, продвинутый дизайнер agд. Здесь авторы примера использовали так называемый метапромпт.
Метапромпт, что это такое?
Это, по сути, очень структурированный и детальный шаблон для создания прамптагента. В Open AI есть такой известный шаблон Voice Agent Mмеappt от Noано Noe. Он позволяет очень подробно описать личность агента. Он весёлый, серьёзный, эмпатичный. Его тон, стиль общения, его конкретные задачи и, что очень важно, его идеальный рабочий процесс. Ideal workflow.
Рабочий процесс. В смысле шаги диалога?
Да. Прямо прописать состояние, через которое должен проходить диалог. Сначала поздоровайся, потом собери общую информацию о проекте, потом уточни конкретные требования, предложи идеи, обсуди их и так далее. Это помогает сделать взаимодействие более предсказуемым и структурированным, но при этом сохранить естественность за счёт личности и тона. Цель была сделать общение не просто функциональным, а именно приятным, как с остроумным и полезным коллегой.
То есть мы уже программируем не только функции, но и характер, манеру общения. По сути, создаём виртуальную личность для конкретной задачи.
В каком-то смысле, да, пытаемся сделать взаимодействие максимально комфортным и эффективным для человека.
Был ли в этом продвинутом примере использован хенф?
Да, это был логичный шаг в конце процесса дизайна. Когда пользователи, агент дизайнер, приходили к какому-то результату, дизайнер мог предложить: "Отлично, с дизайном определились, хотите теперь прикинуть бюджет и сроки." И если пользователь соглашался, дизайнер делалф агенту Сметчику Estimator Agent.
А у Сметчика свои инструменты.
Конечно. У него был, например, инструмент calculate, который мог использовать код интерпретер для выполнения Pythonв, то есть делать реальные расчёты бюджета, материалов, сроков на основе данных проекта.
Ихнф тут важен не только для передачи управления.
Совершенно верно. Хендоof неявно говорит каждому агенту, чем он не должен заниматься. Дизайнер не лезет в расчёты. Это работа сметчика, а сметчик не даёт советов по дизайну. Это работа дизайнера. Это помогает чётко разделить зоны ответственности и повысить качество работы каждого.
Демонстрация в материалах Open AI показывала разные сценарии. Да, не только кухню.
Да, там были примеры редизайна балкона с видом на залив, переделки гаража в спортзал с сауной. Это показывало гибкость подхода. Кстати, там ещё упомянули одну полезную фичу интерфейса. Когда агент говорит, его слова появляются на экране в виде текста почти мноверно, быстрее, чем он их произносит.
А, благодаря стримингу транскрипции.
Да, и это очень удобно. Пользователь может быстро пробежать глазами текст, понять суть и, если что, сразу перебить агента, не дослушивая до конца. Опять же, повышает скорость и естественность взаимодействия.
Выглядит как очень продуманная, хотя и сложная система. И это неизбежно подводит нас к суперважному вопросу. Качество и безопасность. Как убедиться, что вся эта конструкция из SOS, handofs разных агентов работает надёжно, предсказуемо и, главное, безопасно? Не наговорит ли агент чего лишнего? Не сломается ли в самый неподходящий момент?
Вопрос абсолютно правим. И здесь Open e выделяют два главных столпа: оценки Evaluations или Evals и защитные барьеры на выходе. Output guards.
Давай начнём с оценок. Что это такое и почему они так важны?
Evals - это, по сути, система тестов для агентов. В Open AI очень настойчиво подчёркивают, начинать инвестировать время и ресурсы в создании нужно с самого начала разработки, а не потом, когда уже всё готово. приводили пример компании Lemonate, которая именно так и поступала.
Почему так рано?
Потому что EваS помогают отлавливать проблемы на ранних стадиях, направлять разработку, измерять прогресс. Без них ты просто не знаешь, становится ли твой агент лучше или хуже после очередных изменений. Это как писать код без юнит-тестов.
Какие бывают виды этих EVЛ?
Их несколько. Во-первых, это могут быть классические интеграционные тесты прямо в коде. В демо использования фреймворка JZ для тестирования Workspace-менеджера. Проверялось, что вызов определённых функций приводит к ожидаемым изменениям в состоянии рабочего пространства.
То есть проверка логики инструментов.
Да? Во-вторых, это model gradedтесты. Здесь идея в том, чтобы использовать другую и модель, например, GPT4 для оценки качества работы твоего агента.
Как это? Модель оценивает модель.
Да, ты можешь запустить набор заранее подготовленных МОК диалогов с агентом, а затем попросить модель оценщика проверить, например, следовал ли агент заданному workкфлоу, был ли его ответ релевантным, вежливым, не содержал ли ошибок и так далее. Это позволяет автоматизировать оценку качества диалога.
Звучит интересно. А как использовать данные реальных пользователей для улучшения?
А вот здесь как раз и помогает та самая трассировка Traces, о которой мы говорили в платформе Open AI. Можно просматривать записи реальных сессий взаимодействия пользователей с агентом, слышать аудио, видеть, какие инструменты вызывались, какие были ответы.
И что это даёт?
Во-первых, это бесценный источник для отладки. нашёл проблемную сессию, прослушал, понял, что не так. Во-вторых, из этих реальных сессий можно формировать наборы данных для Evals. Увидел особенно удачный диалог, добавил его в золотой набор для тестирования, нашёл диалог, где агент запутался, добавил его в набор регрессионных тестов, чтобы убедиться, что проблема исправлена и не вернётся.
То есть и валс, и трассировка работают в связке. Именно без системы оценок даже самые умные агенты рискуют остаться просто технологической игрушкой, а не надёжным рабочим инструментом, которому можно доверять.
Понятно. А второй столб Output Guard Rails. Что это за защитные барьеры?
Output Guard Rails - это механизм безопасности, который работает в реальном времени, прямо во время генерации речи агентам.
В реальном времени. Как это возможно?
Идея вот в чём. Как мы уже упоминали, текстовая транскрипция ответа агента обычно готова чуть-чуть раньше, чем само аудио. Система успевает получить этот текст и очень быстро проверить его на соответствие определённым правилам. Guard Rails.
Каким правилам?
Например, правило может запрещать агенту обсуждать определённые темы, политику, финансы, что-то нерелевантное его роли, использовать нецензурную лексику или, скажем, выдавать персональные данные. Правило задаёт разработчик. И что происходит, если правило нарушено?
Если система обнаруживает нарушение в генерируемом тексте, она немедленно прерывает дальнейшую генерацию речи агентом. Он просто замолкает на полусловие.
Прямо обрывает его.
Да, и одновременно агенту отправляется специальное системное сообщение, которое объясняет, какое именно правило было нарушено.
Агент получает фидбэк.
Да. И получив этот фидбэк, хорошо настроенный агент обычно корректирует своё поведение. Типичная реакция. Он извиняется, ой, простите, я не должен был об этом говорить, и возвращается к основной теме диалога.
В демо был пример, кажется.
Да, там был забавный пример. Агенту, дизайнеру интерьеров задали правила не обсуждать производство протеиновых батончиков. Когда пользователь попытался завести об этом разговор, агент начал было отвечать, но система его прервала. Он извинился и вернулся к теме дизайна. То есть это инструмент для контроля контента и удержания агента в рамках его роли и допустимых тем.
Совершенно верно. Это важный элемент для обеспечения безопасности и предсказуемости поведения агента, особенно в приложениях, где есть риски сказать что-то не то.
Очень полезная штука. Слушай, мы обсудили архитектуру, SDK, handofs безопасность. Какие ещё важные детали, нюансы конфигурации или использования этих realта голосовых агентов стоит иметь в виду разработчикам?
Ну, есть несколько моментов. Во-первых, стоит внимательно отнестись к параметрам самого Real Time, когда ты его настраиваешь.
Что там важно?
Ну, очевидно, выбор модели Open AI рекомендует использовать последнюю доступную версию, так как они постоянно улучшаются. Выбор модели транскрипции, обычно это Whisper и аудиокодека - это базовые вещи, но есть и более тонкие настройки. Например, VID Voice Activity Detection. Детектор голосовой активности.
А что с ним?
Есть разные режимы ВАД. Простой реагирует на тишину. Пользователь замолчал, значит, закончил говорить. Но есть и более продвинутый семантический вад, который пытается анализировать не только паузы, но и смысл сказанного, чтобы понять, действительно ли пользователь закончил свою мысль или просто сделал паузу для вдоха.
Ох, это может сделать диалог более плавным, без неловких перебиваний со стороны агента.
Да. Ещё важный параметр температура для Real Time моделей. Open AI рекомендует значение где-то между 0,8 и 1,1.
А что она регулирует?
Температура влияет на креативность или случайность ответов модели. Низкие значения делают ответы более предсказуемыми и сфокусированными, высокие более разнообразными, но иногда менее точными. Тут нужно искать баланс между следованием инструкциям и живостью речи.
Понятно, нужно экспериментировать. А что насчёт мобильных приложений? Есть какая-то специфика при интеграции голосовых агентов туда?
Да, есть пара моментов. Во-первых, для мобильных приложений часто особенно важно минимизировать задержку, поэтому рекомендуется использовать WebertC для установки прямогопирсоединения между мобильным клиентом и серверами Open AI. Это позволяет избежать лишнего прыжка через свой ээнд и сократить время отклика.
А как же безопасность? ключи API. Нельзя же их хранить в мобильном приложении.
Верно. Поэтому для таких случаев Open AI предлагает механизм эфемерных токенов. Твой эээнд может сгенерировать короткоживущий токен доступа специально для этой сессии и передать его мобильному клиенту. Клиент использует этот токен для прямого подключения к Open AI по WebertC. Это безопасно и позволяет в некоторых простых сценариях вообще обойтись без постоянного проксирования аудио через свой сервер.
То есть можно сделать простое голосовое приложение без сложной серверной части?
Для некоторых случаев да, хотя часто всё равно выбирают гибридную архитектуру. Быстрый SOS-агент работает прямо с клиентом через WebrtC. А вот вызовы сложных инструментов, требующих GPT41 или Offre, идут через защищённый ээкэнд разработчика.
Логично. Ты раньше несколько раз подчёркивала, что S2С-модели ценны не только тем, что они быстро вызывают инструменты, но и своей способностью улавливать нюансы речи. Можешь привести ещё примеры, где вот эта эмоциональная интеллектуальность критически важна?
О, да, таких примеров масса. Классика - это обучение языкам. Представь приложение репетитора. Если оно использует SS, оно может не просто общаться с тобой на изучаемом языке, но и давать обратную связь по твоему произношению, по интонации. Текстовая модель этого сделать не сможет. Компания Speak, которую упоминал Open AI, как раз использует это.
Действительно, для языка произношение ключевое. Где ещё?
Другой огромный пласт - это клиентская поддержка, особенно эмпатичная поддержка. Агент, способный уловить по тону голоса, что клиент расстроен, зол или растерян, может отреагировать гораздо адекватнее.
Например.
Например, он может сменить тон на более сочувствующий или предложить немедленно переключить на оператора человека, если чувствует, что ситуация накаляется. Это может кардинально изменить опыт клиента от общения с поддержкой. в то время как обычный текстовый бот будет монотонно повторять скрипт, не обращая внимания на эмоции.
Да, это открывает новые горизонты для качества обслуживания. И последний, но не по значению, элемент промпты. Насколько они важны для этих новых realта голосовых агентов? Сильно ли они отличаются от промтов для текстовых моделей?
Их важность сложно переоценить. Промты для realtime S2S-агентов часто бывают даже более длинными и детализированными, чем для текстовых.
Почему?
Потому что в них нужно описать гораздо больше аспектов поведения. Не только, что агент должен делать, задачи, инструменты, но и как он должен это делать. Его личность, тон голоса, стиль речи, манеру общения, тот самый идеальный рабочий процесс диалога. Промты могут содержать сотни токенов, включать подробные инструкции и примеры диалогов. F shot пром.
То есть это прямо сценарий роли для ИИ.
Можно сказать и так. И чтобы структурировать такие сложные и объёмные промпты, как раз и используются метапромпты, о которых мы говорили. Они помогают разложить все эти аспекты по полочкам и сделать промпт более управляемым и эффективным. Так что, да, инженерия промтов для голосовых агентов - это отдельное искусство.
Итак, давай попробуем подвести итог нашему сегодняшнему погружению. Картина вырисовывается интересная. Мы видим, что голосовые агенты делают прямо-таки заметный скачок вперёд.
Определённо. Они становятся быстрее, общение с ними естественнее во многом благодаря вот этим моделям Речь в речь S2, которые умеют улавривать и передавать нюансы человеческой речи, а не только голые слова.
Да, это ключевое отличие понимание не только что сказано. Но и как?
Плюс к этому появляются новые инструменты от Open AI, Agents SDK, теперь она TypeScript, механизм Handfs для создания сетей специализированных агентов, системы оценок Evils и защитные барьеры Guard Rails. Всё это упрощает разработку, делает агентов надёжнее, безопаснее и позволяет создавать действительно сложные и полезные голосовые приложения.
Совершенно верно. технологии S2S и сопутствующие инструменты - это не просто очередное улучшение голосовых интерфейсов, это, я бы сказала, переход к принципиально новому типу взаимодействия человека и машины, где Ии способен вести не просто формальный обмен информации, а гораздо более осмысленный и контекстно зависимый и даже, как мы выяснили, эмоционально окрашенный диалог. диалог, в котором Ии понимает не только слова, но и то, что стоит за ними, интонацию, эмоции, контекст.
Да, именно так. Это открывает двери для совершенно новых сценариев использования, о которых раньше можно было только мечтать.
И вот здесь, в завершении, мне хотелось бы предложить нашим слушателям вопрос для размышления. Мы обсудили, как эти эмоционально, интеллектуальные голосовые агенты становятся реальностью. А теперь представьте, что они действительно войдут в нашу повседневную жизнь, станут нашими помощниками, консультантами, может быть, даже собеседниками.
Мм, интересная перспектива.
Как это изменит наши ожидания от технологий в целом? Будем ли мы ждать от любого устройства, что оно нас понимает на таком уровне? И что, возможно, ещё важнее, не повлияет ли это на наше собственное человеческое общение друг с другом? Где проходит та тонкая грань, за которой очень полезный инструмент. который лучше нас понимает, превращается в симуляцию эмпатии. Симуляцию, которая может незаметно из-подваль изменить наши социальные привычки, наши навыки эмпатии, наши ожидания от живого общения.
Да, вопрос глубокий: где кончается инструмент и начинается что-то другое?
Вот об этом и предлагаю подумать. На этом на сегодня всё. Спасибо, что были с нами.
Спасибо.