As interfaces de programação de aplicativos (APIs) estão desempenhando um papel cada vez mais importante no mundo virtual e físico, graças ao desenvolvimento de tecnologias como arquitetura orientada a serviços, computação em nuvem e Internet das Coisas (IoT). Hoje, nossos colegas da divisão Microsoft Research compartilharam suas melhores práticas no campo de interfaces de linguagem natural (interfaces de linguagem natural). Inscreva-se agora!
Os serviços web baseados na nuvem dedicados ao clima, esportes e finanças por meio da API da web fornecem dados e serviços aos usuários finais, enquanto os dispositivos IoT permitem que outros dispositivos na rede usem suas funcionalidades.
Normalmente, as APIs são usadas em vários softwares: aplicativos de desktop, sites e aplicativos móveis. Eles também atendem aos usuários por meio de uma interface gráfica do usuário (GUI). As interfaces gráficas deram uma grande contribuição à popularização dos computadores, mas, com o desenvolvimento da tecnologia de computadores, suas muitas limitações estão se tornando mais aparentes. À medida que os dispositivos se tornam menores, mais móveis e mais inteligentes, mais e mais demandas são colocadas na exibição gráfica na tela, por exemplo, com dispositivos portáteis ou dispositivos conectados à IoT.
Os usuários também são forçados a se acostumar com uma ampla variedade de interfaces gráficas ao usar vários serviços e dispositivos. À medida que aumenta o número de serviços e dispositivos disponíveis, também aumenta o custo de treinamento e adaptação de usuários. As interfaces de linguagem natural (NLI) demonstram um potencial significativo como uma ferramenta inteligente única para uma ampla gama de serviços e dispositivos do servidor. As NLIs possuem recursos incríveis para determinar a intenção do usuário e reconhecer informações contextuais, o que torna os aplicativos, como assistentes virtuais, muito mais convenientes para os usuários.
Estudamos interfaces de linguagem natural para APIs (NL2API). Diferentemente dos NLIs de uso geral, como assistentes virtuais, tentamos entender como criar NLIs para APIs da web individuais, como a API do serviço de calendário. No futuro, esses NL2APIs poderão democratizar a API, ajudando os usuários a interagir com os sistemas de software. Eles também podem resolver o problema de escalabilidade dos assistentes virtuais de uso geral, permitindo o desenvolvimento distribuído. A utilidade de um assistente virtual depende em grande parte da amplitude de seus recursos, ou seja, do número de serviços que ele suporta.
No entanto, integrar serviços da Web em um assistente virtual, um de cada vez, é um trabalho incrivelmente minucioso. Se os provedores de serviços da Web individuais tivessem uma maneira fácil de criar NLIs para suas APIs, os custos de integração poderiam ser significativamente reduzidos. Um assistente virtual não precisaria lidar com interfaces diferentes para diferentes serviços da Web. Seria o suficiente para ele simplesmente integrar NL2APIs individuais, que alcançam uniformidade graças à linguagem natural. O NL2API também pode facilitar o desenvolvimento de serviços da Web, sistemas de recomendação de programação e ajuda para a API. Portanto, você não precisa memorizar o grande número de APIs da web disponíveis e sua sintaxe.
Figura 1. Maneiras de criar uma interface de linguagem natural para a API. Esquerda: os métodos tradicionais ensinam modelos de percepção de linguagem a reconhecer intenções em uma linguagem natural, outros modelos aprendem a extrair células associadas a cada intenção e, em seguida, combinam-nas manualmente com solicitações de API. Certo: nosso método pode traduzir a linguagem natural diretamente em solicitações de API.A principal tarefa do NL2API é reconhecer expressões na linguagem natural do usuário e traduzi-las em uma solicitação de API. Para ser mais preciso, focamos nas APIs da web criadas à semelhança da arquitetura REST, ou seja, a API RESTful. As APIs RESTful são amplamente usadas em serviços da Web, dispositivos para IoT e em aplicativos para smartphones. Um exemplo da API do Microsoft Graph é mostrado na Figura 1.
O lado esquerdo da figura mostra o método tradicional de construção de uma linguagem natural, na qual ensinamos modelos de percepção de linguagem a reconhecer intenções e outros modelos para extrair células associadas a cada uma das intenções e, em seguida, compará-los manualmente com solicitações de API, escrevendo código. Em vez disso (como mostrado no lado direito da figura), podemos aprender como traduzir expressões de uma linguagem natural diretamente em solicitações de API. Como parte do estudo, usamos nosso sistema para APIs do pacote
Microsoft Graph API . As APIs do Microsoft Graph Web permitem que os desenvolvedores acessem dados que aumentam a produtividade: correio, calendário, contatos, documentos, diretórios, dispositivos e muito mais.
Figura 2. As APIs do Microsoft Graph Web permitem que os desenvolvedores acessem dados que proporcionam maior produtividade: email, calendário, contatos, documentos, diretórios, dispositivos e muito mais.Um dos requisitos para o modelo que estamos desenvolvendo é a capacidade de criar uma interface de usuário detalhada. A maioria das NLIs existentes faz pouco para ajudar os usuários se a equipe não for reconhecida corretamente. Sugerimos que uma experiência mais detalhada do usuário possa tornar o NLI significativamente mais conveniente.
Desenvolvemos um modelo modular que funciona “de sequência a sequência” (veja a Figura 3) para fornecer interação detalhada com o NLI. Para fazer isso, usamos uma arquitetura que funciona com o princípio “de sequência para sequência”, mas ao mesmo tempo dividimos o resultado da descriptografia em várias unidades interpretadas, chamadas módulos.
Cada módulo tenta prever um resultado predeterminado, por exemplo, usando um parâmetro específico com base em uma instrução recebida no NL2API. Após uma comparação simples, os usuários podem entender facilmente o resultado da previsão de qualquer módulo e interagir com o sistema em um nível modular. Cada módulo em nosso modelo gera resultados consistentes, não um estado contínuo.
Figura 3. Um modelo modular trabalhando de sequência em sequência. O controlador ativa vários módulos, cada um dos quais cria um parâmetro.Módulos: Primeiro, definimos o que é um módulo. Um módulo é uma rede neural especializada projetada para executar uma tarefa específica de prever uma sequência. No NL2API, diferentes módulos correspondem a diferentes parâmetros. Por exemplo, na API GET-Messages, os módulos serão FILTER (remetente), FILTER (isRead), SELECT (anexos), ORDERBY (receivedDateTime), SEARCH, etc. A tarefa do módulo é reconhecer a instrução recebida e criar um parâmetro completo, se ativado. Para isso, o módulo deve determinar os valores de seu parâmetro com base na instrução recebida.
Por exemplo, se uma declaração recebida soar como "cartas não lidas sobre uma dissertação de doutorado", o módulo SEARCH deve prever que o valor do parâmetro SEARCH é "dissertação de doutorado" e gerar o parâmetro completo de "dissertação de doutorado" como a sequência de saída. Por analogia, o módulo FILTER (isRead) deve lembrar que frases como “emails não lidos”, “emails que não foram lidos” e “emails ainda não lidos” indicam que o valor do parâmetro deve ser “False” .
É natural que o próximo passo tenha sido a criação de módulos decodificadores que determinam o que focar, como no modelo usual “de sequência a sequência”. No entanto, em vez de um decodificador, que é usado para tudo, agora temos vários decodificadores, cada um especializado em prever parâmetros específicos. Além disso, como cada módulo possui uma terminologia claramente definida, fica muito mais fácil configurar a interação do usuário no nível do módulo.
Moderador: Apenas alguns módulos serão usados para cada frase introdutória. A tarefa do regulador é determinar quais módulos serão executados. Assim, o regulador também é um decodificador que determina em que vale a pena focar. Ao codificar uma declaração e transformá-la em entrada, ele cria uma sequência de módulos denominada circuito. Em seguida, os módulos criam os parâmetros correspondentes a eles e, finalmente, os parâmetros são combinados para formar a solicitação final para a API.
Ao dividir o complexo processo de previsão no modelo padrão de “sequência para sequência” em unidades de previsão pequenas e altamente especializadas, chamadas módulos, o modelo de previsão será fácil de explicar aos usuários. Em seguida, usando o feedback dos usuários, será possível corrigir possíveis erros de previsão no nível mais baixo. Em nosso estudo, testamos nossa hipótese comparando o NLI interativo com sua versão não interativa, por meio de simulação e de experimentos envolvendo pessoas que usam APIs realmente funcionais. Podemos demonstrar que, com os NLIs interativos, os usuários obtêm sucesso com mais frequência e rapidez, resultando em níveis mais altos de satisfação do usuário.
Em breve, publicaremos
um artigo que detalha a criação de interfaces de linguagem natural para a API da web. Fique atento!