L’évolution des métiers de la documentation audiovisuelle

de Diálogo

O desenvolvimento de sistemas de diálogo pode ser facilitado através de diversas formas, desde interfaces gráficas que auxiliem o analista na elaboração do código até bibliotecas de estratégias de diálogo e modelos de domínio que possam ser reutilizadas em vários sistemas de diálogo.

Outro caminho para simplificar a criação de tais sistemas seria o estabelecimento de um padrão de interface de interação falada. Dessa forma, aprender a interagir com um segundo sistema de diálogo seria mais fácil porque os comandos comuns seriam os mesmos do primeiro sistema.

Descrevemos agora as seguintes arquiteturas e ferramentas para o desenvolvimento de siste- mas e gestores de diálogo: Galaxy II, ARIADNE, TrindiKit, DIPPER e RavenClaw/Olympus. Também apresentamos uma proposta de interface padrão para interação homem-máquina por fala, a Speech Graffiti.

2.5.1 Galaxy II

Galaxy II [Seneff et al. , 1998] foi a arquitetura escolhida para servir de base para os sistemas que participaram do programa DARPA Communicator (mais detalhes na subseção 2.4.2.2).

A estratégia de controle adotada foi a de regras sequenciais.

Foram definidos servidores para ASR, NLU, NLG e síntese de fala. A interação entre eles é feita através de um concentrador (hub) com uma linguagem interpretada própria.

Através dessa linguagem, é possível definir os servidores, máquina e porta, assim como as operações e programas permitidos por eles. Os programas contém as regras, que consistem em condições e ações que devem ser executadas.

Os servidores fornecidos comunicam-se entre si através de formulários semânticos (semantic frames). Para aproveitá-los, é preciso que os novos servidores entendam esta semântica.

Além dos servidores citados, a arquitetura Galaxy II também fornece um modo de depu- ração para o concentrador no qual é executada uma regra de cada vez, auxiliando assim, a identificação de eventuais erros na programação.

2.5.2 ARIADNE

Proposta de arquitetura para desenvolvimento rápido de sistemas de diálogo falado [De- necke, 2002], focada na separação entre os algoritmos de processamento de diálogo e os aspectos específicos de um domínio. Dessa forma, torna possível a reutilização dos módulos que são independentes de domínio.

A arquitetura ARIADNE é dividida em três níveis: • Máquina abstrata de diálogo

• Camada de padrões de interação • Camada de controle do diálogo

O nível mais baixo da arquitetura, a máquina abstrata de diálogo, é responsável pela análise sintática, histórico do discurso (representado em uma árvore), descrição dos objeti-

vos do diálogo, representação semântica (estruturas de características tipadas – typed feature structures) e pela geração de linguagem natural, que permite escolha de padrões.

Na camada de padrões de interação, a classificação do estado do diálogo é feita através das seguintes características:

1. CurrentQuality – qualidade a locução atual, depende do nível de confiança do reconhe- cedor de fala, da análise sintática e da representação semântica.

2. OverallQuality – valor cumulativo de CurrentQuality, usado para detectar falhas no diálogo.

3. CurrentSpeechAct – indica o valor do ato de fala da locução atual.

4. Reference – indica a necessidade de consulta a base de dados para resolução de referência no discurso.

5. ReferenceExpressions – indica se as expressões de referência puderam ser resolvidas. Caso seja possível, mostra se a referência é única ou não.

6. Intention – informa quantas descrições de objetivos de diálogo são compatíveis com a informação no discurso. Se houver apenas uma, indica se toda a informação necessária para invocar o serviço associado está presente.

Há quatro padrões de interação:

1. Questão - busca informação do utilizador para adicionar ao discurso 2. Desfazer - remove informação do discurso.

3. Correção - remove e adiciona informação do discurso. 4. Estado - altera o fluxo do diálogo.

Por último, a camada de controle do diálogo instancia os padrões de interação e mantém o estado do diálogo, sendo independente de domínio.

Para comprovar a eficácia da proposta da arquitetura ARIADNE, de separação entre os algoritmos de processamento de diálogo e os aspectos específicos de um domínio, foi conduzido um experimento no qual os participantes deveriam construir um sistema de diálogo escolhendo o domínio e linguagem de sua preferência [Denecke, 2002]. Os autores mostram que o uso da arquitetura permitiu um rápido desenvolvimento dos sistemas.

Figura 2.14: Arquitetura do TrindiKit – destaque para o Estado da Informação e módulo DME [Larsson e Traum, 2000]

2.5.3 TrindiKit

TrindiKit é uma ferramenta de construção de sistemas de diálogo baseada na abordagem de Estado da Informação (ver secção 2.3.5). De acordo com esta abordagem, uma das principais funções a ser implementada é a de atualização do Estado da Informação através dos chamados dialogue moves. Por isto, esta ferramenta é classificada como uma Dialogue Move Engine (DME) Toolkit [Larsson e Traum, 2000].

A figura 2.14 mostra a arquitetura do TrindiKit. Podemos ver o módulo DME, assim como o Estado da Informação (IS - Information State) e os vários módulos que compõem um sistema de diálogo.

Para facilitar a construção de um sistema de diálogo, o TrindiKit fornece módulos padrão de entrada, interpretação, geração e saída, além de métodos de conversão de itens e de inspeção do IS.

2.5.4 DIPPER

A ferramenta DIPPER, desenvolvido a partir do TrindiKit, é uma coleção de agentes para prototipagem de sistemas de diálogo falado [Bos et al. , 2003a]. Os agentes utilizam OAA e lidam com reconhecimento de fala, geração de linguagem natural e gestão de diálogo. Baseia-se

na abordagem de Estado da Informação [Traum e Larsson, 2003] para modelagem de diálogo. Utiliza a teoria de representação do discurso (Discourse Representation Theory - DRT) e possui resolução de ambiguidades.

Para inferência, duas técnicas são utilizadas: prova de teoremas com Synergetic Prover Augmenting Superposition with Sorts (SPASS) [Weidenbach, 1999] e construção de modelos com MACE [McCune, 1998].

Além da série de agentes OAA fornecidos, a grande diferença em relação ao TrindiKit é a nova forma de atualizar o Estado da Informação, que passa a ser realizada simplesmente através da declaração de regras, sem a necessidade de utilizar uma linguagem específica para definir o algoritmo de controle de atualização.

2.5.5 Speech Graffiti

Tomko et al. [Tomko et al. , 2005] propõem uma interface padrão para interação homem- -máquina por fala. A ideia surgiu de dois outros paradigmas de interação: Graphical User Interface (GUI) dos Macintosh e do sistema de escrita Graffiti para PDA.

As GUI possuem um conjunto básico de interação (duplo clique, arrastar, etc.), uma vez aprendidos, podem ser utilizados em qualquer sistema. Para sistemas de diálogo falado, existiriam comandos padrões, por exemplo: options sempre iria informar sobre o que o sistema pode falar.

Para utilizar o alfabeto Graffiti nos PDA, o utilizador tem que adaptar sua escrita, mas isto é compensado pela melhoria no reconhecimento de escrita. O mesmo pode ser usado em sistemas de diálogo falado, ou seja, pode-se restringir o que o utilizador pode falar, de maneira a aumentar o desempenho do sistema.

A ferramenta Speech Graffiti fornece mecanismos para realizar interações universais, ações básicas utilizadas praticamente em todas as interfaces faladas, facilidando assim, o desenvol- vimento de sistemas de diálogo.

2.5.6 RavenClaw/Olympus

RavenClaw [Bohus e Rudnicky, 2009] é uma plataforma para gestão de diálogo, sucessora da arquitetura AGENDA, que foi usada no CMU Communicator [Rudnicky et al. , 1999].

Tal como no TRIPS, os componentes específicos da tarefa ficam separados dos componentes de diálogo em geral. Com isso, a ferramenta pretende facilitar a criação de sistemas de diálogo ao oferecer um conjunto de funcionalidades comuns a sistema deste tipo, como controle de erros, temporização e tomada da palavra.

Dessa forma, a arquitetura do RavenClaw é dividida em duas partes:

1. Especificação de tarefa do diálogo – onde estão os aspectos específicos do domínio. Con- siste num plano hierárquico para controlar a interação.

2. Motor do diálogo – onde estão os aspectos independentes de domínio. Utiliza uma pilha para manter a estrutura do diálogo e uma lista para controlar o que o sistema espera ouvir do usuário em um dado instante.

Além do gestor de diálogo, é preciso uma série de outros componentes para implementar um sistema de diálogo. Olympus [Bohus et al. , 2007] provê uma infraestrutura completa para esse fim, utilizando o RavenClaw como gestor e ferramentas para reconhecimento de fala, análise sintática, análise de confiança, geração de linguagem e síntese de fala.

Alguns sistemas já foram desenvolvidos com base na plataforma Olympus, como:

• RoomLine – sistema telefônico para reserva de salas na Universidade de Carnegie Mellon. • “Let’s Go! ” – sistema de informação de linhas de ônibus para a cidade de Pittsburgh. • LARRI (Language Based Retrieval of Repair Information) – sistema multi-modal para

auxílio no trabalho de mecânicos especializados em aeronaves F/A-18. • TeamTalk – sistema para controle de um grupo de robôs simultaneamente.