Интерфейсы прикладного программирования (API) играют все более важную роль как в виртуальном, так и в физическом мире благодаря достижениям в таких технологиях, как сервис-ориентированная архитектура, облачные вычисления и Интернет вещей (IoT).
Сегодня наши коллеги из Microsoft Research поделились своими разработками в области Natural Language Interfaces (интерфейсы естественного языка).
Присоединяйтесь к нам! 
Облачные веб-сервисы для погоды, спорта и финансов предоставляют данные и услуги конечным пользователям через веб-API, а устройства IoT позволяют другим устройствам в сети использовать их функции.
Обычно API используются в различном программном обеспечении: настольных приложениях, веб-сайтах и мобильных приложениях.
Они также обслуживают пользователей через графический интерфейс пользователя (GUI).
Графические интерфейсы внесли большой вклад в популяризацию компьютеров, но по мере развития компьютерных технологий их многочисленные ограничения становятся все более очевидными.
Поскольку устройства становятся меньше, мобильнее и умнее, требования к экранной графике становятся все более высокими, например, для носимых устройств или устройств, подключенных к Интернету вещей.
Пользователям также приходится привыкать к большому разнообразию графических интерфейсов при использовании различных сервисов и устройств.
По мере увеличения количества доступных сервисов и устройств растут и затраты на обучение и адаптацию пользователей.
Интерфейсы естественного языка (NLI) демонстрируют значительный потенциал в качестве единого интеллектуального инструмента для широкого спектра серверных служб и устройств.
NLI обладают невероятными возможностями по обнаружению намерений пользователя и распознаванию контекстной информации, что делает такие приложения, как виртуальные помощники, значительно более удобными для пользователей.
Мы изучали интерфейсы естественного языка для API (NL2API).
В отличие от NLI общего назначения, таких как виртуальные помощники, мы пытались понять, как создавать NLI для конкретных веб-API, таких как API службы календаря.
В будущем такие NL2API смогут демократизировать API, помогая пользователям взаимодействовать с программными системами.
Они также могут решить проблему масштабируемости виртуальных помощников общего назначения, предоставив возможность распределенной разработки.
Полезность виртуального помощника во многом зависит от широты его возможностей, то есть от количества поддерживаемых им сервисов.
Однако интеграция веб-сервисов в виртуального помощника по одному — невероятно трудоемкая работа.
Если бы у отдельных поставщиков веб-сервисов был простой способ создания NLI для своих API, затраты на интеграцию можно было бы значительно сократить.
И виртуальному помощнику не придется обрабатывать разные интерфейсы для разных веб-сервисов.
Он мог бы просто интегрировать отдельные NL2API, обеспечивающие согласованность посредством естественного языка.
NL2API также может упростить разработку веб-сервисов, программных рекомендаций и справочных систем для API. Таким образом, вам не придется запоминать большое количество доступных веб-API и их синтаксис.
Рисунок 1. Способы создания интерфейса на естественном языке для API. Слева: традиционные методы обучают модели восприятия языка распознавать намерения на естественном языке, в то время как другие модели учат их извлекать ячейки, связанные с каждым намерением, а затем вручную сопоставлять их с запросами API. Справа: наш метод может переводить естественный язык непосредственно в запросы API.
Основная задача NL2API — распознавать выражения на естественном языке пользователя и переводить их в запрос API. Точнее, мы сосредоточились на веб-API, смоделированных по архитектуре REST, то есть RESTful API. API-интерфейсы RESTful широко используются в веб-сервисах, устройствах Интернета вещей и приложениях для смартфонов.
Пример API Microsoft Graph показан на рисунке 1. В левой части рисунка показан традиционный подход к естественному языку, при котором мы обучаем модели восприятия языка распознавать намерения, а другие модели — извлекать ячейки, связанные с каждым намерением, а затем вручную сопоставлять их с запросами API путем написания кода.
Вместо этого (как показано в правой части рисунка) мы можем научиться переводить выражения естественного языка непосредственно в запросы API. В рамках исследования мы применяем нашу систему к API из пакета API Microsoft Graph .
Веб-API Microsoft Graph позволяют разработчикам получать доступ к данным, повышающим производительность, таким как почта, календарь, контакты, документы, каталоги, устройства и многое другое.
Рисунок 2. Веб-API Microsoft Graph позволяют разработчикам получать доступ к данным, повышающим производительность, таким как почта, календарь, контакты, документы, каталоги, устройства и многое другое.
Одним из требований к разрабатываемой нами модели является возможность создания детального пользовательского интерфейса.
Большинство существующих NLI мало чем помогают пользователям, если команда распознана неправильно.
Мы предполагаем, что более детальное взаимодействие с пользователем может сделать NLI значительно более удобными в использовании.
Мы разработали модульную модель, которая работает последовательно (см.
рисунок 3), чтобы обеспечить детальное взаимодействие с NLI. Для этого мы используем последовательность-последовательность архитектуры, но разбиваем результат расшифровки на несколько интерпретируемых единиц, называемых модулями.
Каждый модуль пытается предсказать заранее заданный результат, например, используя определенный параметр на основе полученного в NL2API оператора.
После простого сопоставления пользователи могут легко понять результат прогнозирования любого модуля и взаимодействовать с системой на уровне модуля.
Каждый модуль в нашей модели генерирует последовательные результаты, а не непрерывное состояние.
Рисунок 3. Модульная модель, работающая от последовательности к последовательности.
Контроллер активирует несколько модулей, каждый из которых создает параметр.
Модули: Сначала мы определим, что такое модуль.
Модуль представляет собой специализированную нейронную сеть, предназначенную для выполнения конкретной задачи прогнозирования последовательности.
В NL2API разные модули соответствуют разным параметрам.
Например, в API GET-Messages модулями будут FILTER (отправитель), FILTER (isRead), SELECT (вложения), ORDERBY (receivedDateTime), SEARCH и т. д. Задача модуля, если он активирован, распознавать входящий оператор и создайте полный параметр.
Для этого модуль должен определить значения своего параметра на основе входящего оператора.
Например, если входным высказыванием является «непрочитанные электронные письма о докторской диссертации», модуль ПОИСК должен предсказать, что значение параметра ПОИСК — «докторская диссертация», и сгенерировать полный параметр «ПОИСК докторской диссертации» в качестве выходной последовательности.
По аналогии модуль FILTER (isRead) должен помнить, что такие фразы, как «непрочитанные электронные письма», «электронные письма, которые не были прочитаны» и «еще не прочитанные электронные письма», указывают на то, что значение его параметра должно быть «False».
Вполне естественно, что следующим шагом стало создание модулей-декодеров, определяющих, на чем сосредоточить внимание, как в обычной модели «последовательность-последовательность».
Однако вместо одного декодера, используемого для всего, теперь у нас есть несколько декодеров, каждый из которых специализируется на прогнозировании определенных параметров.
Более того, поскольку каждый модуль имеет четко определенную терминологию, становится намного проще настроить взаимодействие с пользователем на уровне модуля.
Регулятор: Для каждой входной фразы будет использоваться только несколько модулей.
Задача регулятора – определить, какие модули он будет запускать.
Таким образом, регулятор является еще и декодером, определяющим, на чем сосредоточить внимание.
Кодируя высказывание и превращая его во входные данные, он создает последовательность модулей, называемую схемой.
Затем модули создают соответствующие параметры, и, наконец, параметры объединяются для формирования окончательного запроса API. Разбивая сложный процесс прогнозирования стандартной модели «последовательность за последовательностью» на небольшие узкоспециализированные блоки прогнозирования, называемые модулями, модель прогноза можно легко объяснить пользователям.
Тогда с помощью отзывов пользователей можно будет исправить возможные ошибки прогноза на самом низком уровне.
В нашем исследовании мы проверяем нашу гипотезу, сравнивая интерактивный NLI с его неинтерактивной версией как посредством моделирования, так и посредством экспериментов с людьми, использующими реальные API. Мы можем продемонстрировать, что с помощью интерактивных NLI пользователи достигают успеха чаще и быстрее, что приводит к более высокому уровню удовлетворенности пользователей.
Совсем скоро мы опубликуем статья , в котором подробно описано, как создавать интерфейсы на естественном языке для веб-API. Следите за обновлениями! Теги: #Машинное обучение #microsoft #iot #Microsoft Azure #Интернет вещей #api #cloud #azure #web #GUI #openwork #nl2api
-
Подходит Ли Мне Передача Голоса По Ip?
19 Oct, 24 -
Распаковка Lego Mindstorms Nxt 2.0
19 Oct, 24
