Embed Size (px)
Citation preview
DIGA - Desenvolvimento de uma plataforma para criacao
de sistemas de dialogo.
Filipe Miguel Fonseca Martins
Dissertacao para obtencao do Grau de Mestre em
Engenharia Informatica e de Computadores
Juri
Presidente: Doutor Ana PaivaOrientador: Doutor Nuno MamedeCoorientador: Doutor Joao Paulo NetoVogais: Doutor Paulo Quaresma
Setembro de 2008
Agrade imentosAgradeco a todo o grupo de trabalho do L2F (que muito sinceramente nao podia ter sido melhor), em
especial a:
Nuno Mamede, que foi muito mais que um orientador...
Ana Mendes, por todo o apoio prestado durante este trabalho.
Marcio Viveiros, por toda a ajuda e paciencia que teve nos momentos mais difıceis.
Joana Paulo Pardal, por toda a motivacao e apoio.
Joao Paulo Neto, por toda a visao.
David Jose Rodrigues, Renato Cassaca, David Matos, Luısa Coher, Tiago Luıs, Pedro Arez
Jorge Batista pela excelente revisao de tese.
Agradeco aos meus amigos de curso e a todos aqueles professores, que permitiram que eu nestes
ultimos cinco anos me desenvolvesse nao so como profissional mas tambem como pessoa.
Agradeco a minha famılia por todos estes anos de apoio, confianca, ajuda e tudo o mais, que fizeram
de mim a pessoa que sou hoje.
Agradeco a minha namorada Raquel Matos por toda a compreensao e ajuda, preciosa nos momen-
tos mais difıceis.
O meu muito sincero, Obrigado.
Lisboa, 29 de Setembro de 2008
Filipe Miguel Fonseca Martins
ResumoEste trabalho enquadra-se na area de investigacao dos sistemas de dialogo, tendo-se melhorado a pla-
taforma DIGA (DIaloGue Assistance) usada na construcao de sistemas de dialogo, independente do
domınio. Foram feitos desenvolvimentos na plataforma de sistemas de dialogo, nomeadamente: (i)
foi expandida a interface do sistema para processar informacao enviada em tempo de execucao pela
aplicacao externa, (ii) foram desenvolvidos os processadores de linguagem para melhorar as capaci-
dades de interpretacao da plataforma de sistemas de dialogo e (iii) foram desenvolvidas diversas me-
todologias para prevencao e recuperacao de erros. Posteriormente foi ainda definida a interface da
plataforma de sistemas de dialogo para integracao de aplicacoes externas.
Para testar e aplicar os desenvolvimentos feitos sobre a plataforma foram desenvolvidos tres no-
vos sistema de dialogo, em colaboracao com parceiros empresariais, nomeadamente, (i) uma assistente
pessoal que realiza diversas tarefas de escritorio, como por exemplo estabelecer uma ligacao telefonica
ou enviar uma mensagem de email, (ii) um sistema de banca telefonica que providencia os habituais
servicos, como por exemplo consulta do saldo, e (iii) um sistema de bolsa telefonica que providencia
servicos para consulta, compra e venda de accoes.
Como resultado deste trabalho ficaram disponıveis uma plataforma, reestruturada e documentada,
de desenvolvimento de sistemas de dialogo e tres novos sistemas de dialogo que estao prontos a ser
comercializados.
Abstra tThis document describes research work in dialogue systems, including the recovery and reorganization
of the DIGA (Dialogue Assistance) framework, developed previously. DIGA is a domain-independent
framework for dialogue systems.
This document also describes the changes that the framework went through and that affected its
architecture: the communication core was enhanced, the modules interfaces were redefined for easier
integration, the SDS deployment process was optimized, the framework robustness was improved, and
we also introduced capabilities for protecting intellectual property.
For applying and testing the new developments, we developed three new dialogue systems as case
studies: a personal assistance system that performs office tasks, such as calling a third party or sen-
ding e-mail messages, a home-banking system which provides common tasks such as checking account
balance, and a stock exchange system which provides services such as buying and selling stocks.
The three new dialogue systems were developed/reengineered in collaboration with industry part-
ners. For developing these systems, we expanded the framework’s interface for processing the informa-
tion sent by external applications at runtime. We also developed the parsers to improve the interpreta-
tion capabilities and introduced methodologies for preventing and recovering from speech recognition
errors.
As a result of this work, we have a more robust and efficient domain-independent framework for
dialogue systems, as well as three commercial-grade systems.
Palavras ChaveKeywordsPalavras ChaveSistemas de dialogo
Engenharia de Software
Atendimento automatico de chamadas
Processamento Automatico da FalaKeywordsDialogue systems
Software Engineering
Automatic call answer
Automatic Speech Processing
�Indi e1 Introducao 1
1.1 Sistemas de dialogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Modulos de um sistema de dialogo . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Classificacao de sistemas de dialogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Sistemas orientados a tarefa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1.1 Sistemas de estados finitos . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1.2 Sistemas de enquadramentos . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1.3 Sistemas de agentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 Sistemas de aprendizagem por computador . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2.1 Sistemas de acompanhamento . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Organizacao da dissertacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Estado da Arte 9
2.1 STAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1 Modelo de domınio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.2 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.2.1 Gestor de dialogo (STAR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.2.2 Gestor de servicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.2.3 Gestor de entradas e saıdas . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Avaliacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.1 Descricao das directivas PARADISE . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.2 Caracterısticas da avaliacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
i
2.2.3 Componentes avaliadas e metodologias adoptadas . . . . . . . . . . . . . . . . . . 19
2.2.4 Medidas de avaliacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.5 Questionario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.6 Testes-piloto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.7 Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3 Desenvolvimentos na Plataforma 29
3.1 HUB Galaxy e utilizacao de estruturas XML . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2 Gestor de eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3 Identificacao/reconhecimento de objectos e classificacao de actos de fala no discurso . . . 33
3.4 Interfaces do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5 Apoio ao desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.6 Redesenho do gestor de servicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.7 Distribuicao do gestor de dialogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.8 Integracao da cadeia de processamente morfossintatico XIP . . . . . . . . . . . . . . . . . 42
4 Casos de Estudo 47
4.1 LISA - Assistente pessoal virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.1.1 Levantamento de requisitos e especificacao . . . . . . . . . . . . . . . . . . . . . . . 47
4.1.2 Arquitectura do sistema LISA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2 Banca e bolsa telefonica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2.1 Descricao dos sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2.2 Alteracoes na arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.3 Desenvolvimentos sobre a plataforma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.3.1 Gestor de processadores de linguagem . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.3.2 Validacoes dinamicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.3.3 Confirmacoes explıcitas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.3.4 Ordenacao e optimizacao do dialogo . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
ii
4.3.5 Parametrizacao do contexto do dialogo . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.3.6 Identificacao e reconhecimento de objectos . . . . . . . . . . . . . . . . . . . . . . . 63
4.3.6.1 Concatenacao de objectos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.3.6.2 Manipulacao de objectos compostos . . . . . . . . . . . . . . . . . . . . . 64
4.3.6.3 Identificacao e reconhecimento de objectos ao nıvel do processador de
linguagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.3.7 Prevencao e recuperacao de erros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.3.8 Nıveis de dialogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.3.9 Inclusao de eventos de excepcao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.4 Consideracoes finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5 Conclusoes 71
5.1 Avaliacao do sistema de assistencia pessoal LISA . . . . . . . . . . . . . . . . . . . . . . . . 71
5.1.1 Alteracoes ao modelo de avaliacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.1.2 Tarefas realizadas por cada utilizador . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.1.3 Testes-piloto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.1.4 Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.2 Conclusoes e trabalho futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.2.1 Integracao do sistema QA@L2F . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.2.2 Introducao da classificacao de actos de fala . . . . . . . . . . . . . . . . . . . . . . . 78
5.2.2.1 Actos de fala . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.2.2.2 Apoio a integracao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.2.3 Passagem de informacao atraves emocoes faciais . . . . . . . . . . . . . . . . . . . 80
5.2.4 Definicao de ontologias de domınio para automatizacao do desenvolvimento de
novos sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.2.5 Desenvolvimentos baseados na web . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.3 Contribuicoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
iii
I Appendices 93
A Analise de resultados da avaliacao ao sistema Ambrosio 95
A.1 Experiencia dos utilizadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
A.2 Registo de resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
A.2.1 Tarefa 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
A.2.2 Tarefa 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
A.2.3 Tarefa 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
A.2.4 Tarefa 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
A.2.5 Tarefa 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
A.2.6 Tarefa 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
A.2.7 Tarefa 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
A.2.8 Tarefa 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
A.2.9 Tarefa 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
A.3 Tempo gasto por tarefa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
A.4 Numero de palavras utilizadas pelo sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
A.5 Numero de palavra utilizadas pelo utilizador . . . . . . . . . . . . . . . . . . . . . . . . . . 102
A.6 Tarefas executadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
A.7 Numero de falhas totais de compreensao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
A.8 Numero de falhas por compreensao parcial . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
A.9 Numero de falhas causadas por erros de reconhecimento . . . . . . . . . . . . . . . . . . . 103
A.10 Tempo gasto por tarefa (por tipo de utilizador) . . . . . . . . . . . . . . . . . . . . . . . . . 104
A.11 Numero de palavras utilizadas pelo sistema (por tipo de utilizador) . . . . . . . . . . . . . 105
A.12 Numero de palavras utilizadas pelo utilizador (por tipo de utilizador) . . . . . . . . . . . 106
A.13 Tarefas executadas (por tipo de utilizador) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
A.14 Numero de falhas totais de compreensao (por tipo de utilizador) . . . . . . . . . . . . . . 108
A.15 Numero de falhas por compreensao parcial (por tipo de utilizador) . . . . . . . . . . . . . 109
iv
A.16 Numero medio de falhas devido a erros de reconhecimento (por tipo de utilizador) . . . . 109
A.17 Satisfacao do utilizador (por tipo de utilizador) . . . . . . . . . . . . . . . . . . . . . . . . . 110
A.18 Questionario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
B Analise de resultados da avaliacao ao sistema Lisa 113
B.1 Tempo decorrido (em segundos) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
B.2 Numero de interaccoes do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
B.3 Numero de interaccoes do interveniente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
B.4 Numero de palavras utilizadas pelo sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
B.5 Numero de palavras utilizadas pelo interveniente . . . . . . . . . . . . . . . . . . . . . . . 115
B.6 Numero de interaccoes falhadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
B.7 Numero de interaccoes falhadas devido a erros de reconhecimento . . . . . . . . . . . . . 116
B.8 Numero de erros que impediram o sistema de progredir . . . . . . . . . . . . . . . . . . . 116
B.9 Numero de chamadas efectuadas para realizar as tarefas . . . . . . . . . . . . . . . . . . . 117
B.10 Numero de interaccoes do sistema para deteccao e recuperacao de erros . . . . . . . . . . 117
B.11 A tarefa foi concluıda com sucesso? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
B.12 Questionario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
v
vi
Lista de Figuras1.1 Arquitectura classica de um sistema de dialogo. . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Exemplo hipotetico de uma interaccao com sistemas de dialogo modelados com recurso
a um diagrama de estados finitos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Exemplo de uma especificacao de um enquadramento em XML. . . . . . . . . . . . . . . . 4
1.4 Exemplo hipotetico de uma interaccao com um sistema de dialogo modelado com recurso
a enquadramentos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Exemplo hipotetico de uma interaccao com um sistema de dialogo modelado com recurso
a agentes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Modelo de domınio do sistema STAR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Arquitectura conceptual do sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Arquitectura do STAR (a direita) e modelo de interaccao (a esquerda). . . . . . . . . . . . 12
2.4 Arquitectura do gestor de servicos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5 Arquitectura do gestor de entradas e saıdas. . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6 Numero medio de falhas ocorridas, por classe de utilizadores, na realizacao do total das
tarefas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.7 Percentagem de falhas ocorridas devido a erros de reconhecimento (no total de falhas),
por classe de utilizadores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1 Exemplo de uma estrutura trocada entre modulos do gestor de dialogo. . . . . . . . . . . 31
3.2 Desenho actual do gestor de servicos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3 Arvore de directorios do sistema de dialogo. . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.4 Arquitectura da cadeia XIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.5 Exemplo do resultado do processamento da cadeia XIP. . . . . . . . . . . . . . . . . . . . . 44
vii
4.1 Casos de utilizacao para a gestao de estado (a esquerda) e gestao do destino de redirecci-
onamento (a direita). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2 Casos de utilizacao para a consulta da agenda de contactos (a esquerda) e marcacao por
voz (a direita). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3 Casos de utilizacao para o envio de mensagens (a esquerda) e gestao do voice-mail (a
direita). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.4 Casos de utilizacao para a gestao da agenda. . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.5 Diagrama de componentes do sistema LISA. . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.6 Nova arquitectura da plataforma de dialogo DIGA (DIaloG Assistance). . . . . . . . . . . 56
4.7 Exemplo de uma falha no dialogo para o envio de uma mensagem. . . . . . . . . . . . . . 58
4.8 Exemplo de parametrizacao do gestor de processadores de linguagem de entrada. . . . . 59
4.9 Exemplo de definicao de um parametro externo. . . . . . . . . . . . . . . . . . . . . . . . . 60
4.10 Exemplo de declaracao de uma validacao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.11 Exemplo de declaracao de uma validacao dinamica. . . . . . . . . . . . . . . . . . . . . . . 61
4.12 Exemplo de declaracao de regra de identificacao e reconhecimento de objectos. . . . . . . 64
5.1 Numero medio de falhas por tarefa (a esquerda) e tempo (em segundos) gasto em media,
por tarefa (a direita). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.2 Arquitectura do sistema QA@L2F . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.3 Estrutura de um acto de discurso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
A.1 Tempo medio gasto por tarefa (por tipo de utilizador). . . . . . . . . . . . . . . . . . . . . . 105
A.2 Numero medio de palavras utilizadas pelo sistema (por tipo de utilizador). . . . . . . . . 105
A.3 Numero medio de palavras utilizadas pelo utilizador (por tipo de utilizador). . . . . . . . 106
A.4 Numero medio de tarefas executadas (por tipo de utilizador). . . . . . . . . . . . . . . . . 107
A.5 Numero medio de falhas totais de compreensao (por tipo de utilizador). . . . . . . . . . . 108
A.6 Numero medio de falhas por compreensao parcial (por tipo de utilizador). . . . . . . . . . 109
A.7 Percentagem relativa de falhas devido a erros de reconhecimentos (por tipo de utilizador). 110
B.1 Tempo medio por tarefa (em segundos). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
viii
B.2 Servicos em que se verifica um maior numero de falhas. . . . . . . . . . . . . . . . . . . . . 120
B.3 Numero medio de falhas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
B.4 Numero medio de interaccoes para recuperacao de falhas. . . . . . . . . . . . . . . . . . . 121
ix
x
1Introdu� ~aoEste trabalho insere-se na area dos sistemas de dialogo, mais concretamente na reengenharia e desenvol-
vimento de sistemas de dialogo, tendo por base uma tese de mestrado e tres trabalhos finais de curso,
bem como diversas contribuicoes individuais, tao ou mais importantes, que ajudaram a materializar
esta area de investigacao no Laboratorio de Lıngua Falada (L2F) do Instituto de Engenharia de Sistemas
e Computadores, Investigacao e Desenvolvimento em Lisboa (INESC-ID).
O principal objectivo deste trabalho consiste em organizar, estabilizar e desenvolver o trabalho
previamente realizado. Por forma a demonstrar as melhorias introduzidas, criou-se um sistema de
dialogo de assistencia pessoal aos utilizadores, que desempenha diversas tarefas de escritorio, como,
por exemplo, a gestao de agenda e o envio de mensagens.
Este objectivo foi fortemente motivado pela existencia de um projecto em curso de migracao de
tecnologia, denominado TECNOVOZ1, que visa integrar tecnologia de fala em diversos produtos de
diversas empresas.
Neste capıtulo introduzem-se os sistemas de dialogo do ponto de vista geral. Descreve-se, de forma
breve, o que e um sistema de dialogo (seccao 1.1) e apresenta-se muito sucintamente o trabalho ja reali-
zado na area (seccao 1.2).1.1 Sistemas de di�alogoOs sistemas de dialogo surgiram como uma materializacao da necessidade de simplificar a utilizacao
das maquinas pelos humanos. A ideia e proporcionar uma interface fala que torne a comunicacao com a
maquina tao simples como falar com outro humano. Actualmente, utilizam sistemas de dialogo diversas
aplicacoes de banca e bolsa telefonica, de venda de bilhetes para os mais diversos eventos e transportes,
de consulta das ultimas notıcias e de informacoes meteorologicas, entre outras, que utilizam sistemas
de dialogo.
1http://www.tecnovoz.pt/
1.1.1 Modulos de um sistema de dialogo
Um sistema de dialogo tem como principal objectivo gerir e desenvolver um dialogo natural e fluido
com um utilizador. Esta tarefa tem diversas dificuldades inerentes a comunicacao entre humanos e/ou
a comunicacao homem-maquina.
Para simplificar, dividiu-se o problema em problemas mais pequenos e bem definidos. Assim, os
sistemas de dialogo sao, de um modo geral, compostos pelos seguintes modulos: Reconhecedor de
Fala, Interpretador de Linguagem, Gestor do Dialogo, Gerador de Linguagem e Sintetizador de Fala.
A figura 1.1 esquematiza a arquitectura geral de um sistema de dialogo, contendo os diversos modulos
que o compoem, o fluxo de informacao e as estruturas (fala, texto, interpretacoes e obrigacoes de dis-
curso) trocadas entre modulos. De seguida, descreve-se sucintamente a contribuicao de cada um destes
modulos.
Reconhecedor de Fala. O modulo de reconhecimento de fala converte o sinal audio, correspondente a
voz do utilizador, para texto. Idealmente, este podera traduzir as pausas e a entoacao produzidas pelo
utilizador em pontuacao e/ou efectuar a correcta capitalizacao das palavras (a capitalizacao e a subta-
refa que consiste na reconstituicao, no texto escrito resultante do reconhecedor de fala, das maiusculas,
com base na informacao associada aos nomes proprios), com base na informacao associada aos nomes
proprios, siglas e inıcios de frase.
Interpretador de Linguagem. Apos o reconhecimento de fala, e necessario proceder a interpretacao
do texto resultante. E com base nesse texto que o modulo de interpretacao de linguagem tenta associar
uma interpretacao as frases proferidas.
Figura 1.1: Arquitectura classica de um sistema de dialogo.
Gestor do Dialogo. Tendo em conta a interpretacao construıda pelo modulo de interpretacao de lin-
guagem, o gestor de dialogo pode executar uma ou mais tarefas e/ou decidir como responder ao utiliza-
dor. Esta resposta e apresentada num formato de alto nıvel, frequentemente denominado por obrigacao
de discurso.
2
Gerador de Linguagem. O modulo de geracao de linguagem traduz a obrigacao de discurso para texto
compreensıvel pelo utilizador. Este texto e enviado ao sintetizador de fala.
Sintetizador de Fala. A partir do texto gerado no modulo anterior, o sintetizador de fala gera um sinal
de audio, interpretavel pelos humanos como voz. Numa situacao ideal, este modulo traduz a pontuacao
do texto em pausas e diferentes entoacoes e efectua uma normalizacao (conversao de dıgitos, numerais
ordinais, entre outros formatos, para texto) de siglas, dıgitos e sımbolos com base na envolvencia frasica.1.2 Classi� a� ~ao de sistemas de di�alogo1.2.1 Sistemas orientados a tarefa
Os sistemas de dialogo orientados a tarefa (Dybkjær et al., 1996) tem o objectivo bem definido de execu-
tar uma determinada tarefa.
A classificacao de sistemas de dialogo proposta por (M. F. McTear, 2002) preve a seguinte divisao:
sistemas de estados finitos, sistemas de enquadramentos e sistemas de agentes.
1.2.1.1 Sistemas de estados finitos
Os sistemas de estados finitos sao sistemas modelados por diagramas de estados finitos. O objectivo
destes sistemas e, em cada momento, obter informacao junto do utilizador para conseguir passar ao
estado seguinte. O sistema itera sobre a maquina de estados ate atingir um estado final, em que reuniu as
condicoes necessarias para executar uma determinada tarefa. Na figura 1.2, exemplifica-se um dialogo
com um sistema de dialogo modelado com recurso a um diagrama de estados finitos.
SISTEMA: O que deseja fazer?UTILIZADOR: Enviar uma mensagem SMS.SISTEMA: Qual o tipo da mensagem: SMS, MMS ou Email?UTILIZADOR: SMS.SISTEMA: A quem se destina a mensagem?UTILIZADOR: Ao Jose.
Figura 1.2: Exemplo hipotetico de uma interaccao com sistemas de dialogo modelados com recurso aum diagrama de estados finitos.
Estes sistemas sao os mais simples de implementar. No entanto desenvolvem dialogos pouco efici-
entes dado que apenas preveem a recolha de uma unica informacao de cada vez que interagem com o
utilizador. A informacao recolhida permitira ao sistema passar para o estado seguinte. A forma como se
especifica a informacao a recolher, nos sistemas de dialogo modelados com recurso a um diagrama de
3
estados finitos, dificulta a definicao de dependencias entre as informacoes recolhidas porque, em cada
interaccao com o utilizador, apenas se processa uma determinada informacao. Assim, por exemplo, se
se estiver perante um sistema de reserva de bilhetes de comboio, que necessita de varias informacoes
tais como a hora de partida, a hora de chegada, a origem, o destino e a classe, o sistema tera que efec-
tuar pelo menos cinco iteracoes com o utilizador para conseguir reunir a informacao necessaria que lhe
permita processar um pedido.
Um bom exemplo de definicao destes sistemas e o Voice XML2, que constitui um padrao na area de
sistema de dialogo modelados por estados.
1.2.1.2 Sistemas de enquadramentos
Os sistemas que modelam a informacao recorrendo a enquadramentos preveem que, em cada interaccao
com o utilizador, este possa fornecer mais do que uma informacao pela ordem que achar mais conve-
niente, tendo o sistema a capacidade para processar esse conjunto de informacoes. Cada informacao e
frequentemente denominada por “campo” (do ingles slot).
<enquadramento><nome>bilhetica<nome><campo>origem</campo><campo>destino</campo><ou>
<campo>hora de partida</campo><campo>hora de chegada</campo>
</ou><campo>classe</campo>
</enquadramento>
Figura 1.3: Exemplo de uma especificacao de um enquadramento em XML.
Como se pode ver no exemplo da figura 1.3, para um sistema de venda de bilhetes de comboio, um
enquadramento possıvel seria composto por um campo referente a hora de partida, a hora de chegada,
a origem, ao destino e a classe. Este exemplo tambem apresenta a especificacao de uma restricao: neste
caso, para comprar um bilhete de comboio, e apenas necessario fornecer a hora de partida ou a hora de
chegada.
Desta forma, e possıvel a recolha em simultaneo de diversos campos (como se pode observar no
exemplo da figura 1.4) bem como o estabelecimento de restricoes quer sobre os campos quer entre eles.
Este tipo de sistemas fornece, pois, uma flexibilidade superior a dos sistemas de estados finitos. No
entanto, nao preve alteracoes dinamicas do mundo. Por exemplo, num sistema de envio de SMS’s, se
2http://www.w3.org/TR/voicexml21/
4
SISTEMA: O que deseja fazer?UTILIZADOR: Enviar uma mensagem SMS para o Jose.SISTEMA: Qual a mensagem que deseja enviar?UTILIZADOR: Vou chegar atrasado ao jantar.SISTEMA: Deseja enviar uma mensagem SMS ao Jose Matos com o t exto: Vou chegar atrasado ao jantar?UTILIZADOR: Nao, ao Jose Fonseca.SISTEMA: A sua mensagem foi encaminhada para o Jose Fonseca .
Figura 1.4: Exemplo hipotetico de uma interaccao com um sistema de dialogo modelado com recurso aenquadramentos.
fosse criado um novo tipo de mensagens escritas denominado XMS, o sistema nao conseguiria adaptar-
-se a essa alteracao do mundo, mesmo que apenas fosse alterado o nome do tipo de mensagem e os
restantes parametros se mantivessem inalterados.
O sistema de consulta automatica de horarios de transportes da Philips (Aust et al., 1995) e exemplo
de um sistema que utiliza informacao modelada com recurso a enquandramentos.
1.2.1.3 Sistemas de agentes
Os sistemas baseados em agentes sao implementados recorrendo a agentes que tentam apreender as
alteracoes do mundo, suprimindo parte da limitacao dos sistemas anteriores. Este tipo de sistemas
permite dialogos mais complexos do que os sistemas modelados recorrendo a enquadramentos. No
entanto, exigem capacidades de processamento de lıngua natural mais sofisticadas para se tentarem
adaptar a novas realidades.
SISTEMA: Efectue o pagamento do seu bilhete com o seu cartao multibanco.UTILIZADOR: Nao tenho nenhum cartao multibanco.SISTEMA: Entao insira o dinheiro na respectiva ranhura.UTILIZADOR: Nao tenho dinheiro comigo.SISTEMA: Entao nao lhe poderei fornecer o bilhete pretend ido.UTILIZADOR: Ok, obrigado na mesma.SISTEMA: Obrigado e volte sempre.
Figura 1.5: Exemplo hipotetico de uma interaccao com um sistema de dialogo modelado com recurso aagentes.
Os BDI’s (do ingles Beliefs, Desires and Intentions) (Rao & Georgeff, 1995) sao um tipo de agentes
que sao frequentemente utilizados em sistemas de dialogo porque demonstram um comportamento
aceitavel, mesmo em domınios complexos, sem elevarem demasiado a complexidade de implementacao
dos sistemas.
O TRIPS (Allen et al., 2000; Allen, Ferguson, & Stent, 2001; Allen, Byron, et al., 2001; Burstein
et al., 2000), sistema desenvolvido pela universidade de Rochester e sobre o qual se baseou grande
5
parte do trabalho que antecedeu esta tese, possui um agente central que reune a informacao vinda do
interpretador de linguagem e dos sensores para, em conjunto com a informacao que tem guardada
(base de dados, contexto, entre outras), gerar uma resposta para o utilizador. Sobre o sistema TRIPS
foi recentemente desenvolvido (tambem pela universidade de Rochester) o PLOW (Allen et al., 2007;
Jung et al., 2008). Este sistema possui um agente que, com base na observacao de accoes, tenta aprender
a realizar novas tarefas baseadas na web (consultar horarios de transportes, fazer reservas em hoteis,
entre outras).
1.2.2 Sistemas de aprendizagem por computador
Os sistemas de aprendizagem por computador (do ingles tutoring systems) sao um grupo emergente de
sistemas de dialogo, cujo principal objectivo e instruir o utilizador na realizacao de uma tarefa.
Como exemplo temos o Collagen (Rich et al., 2001) ou o Conselheiro Medico (do ingles Medical
Adviser, baseado na plataforma TRIPS) (Ferguson et al., 2002), cujo objectivo e lembrar o utilizador dos
diversos eventos do dia-a-dia, como e o caso da ingestao de medicamentos, util para pessoas idosas e
com dificuldades de memorizacao.
1.2.2.1 Sistemas de acompanhamento
Os sistemas de acompanhamento, tem como objectivo manter um dialogo com o utilizador o maior
tempo possıvel, tentando assim fazer companhia, por exemplo, a pessoas idosas e solitarias. Para isso,
podem recorrer a fotografias falando sobre momentos do passado, falam das notıcias actuais, do estado
do tempo nos ultimos dias entre outros assuntos.
O projecto Companions (Companions Project, 2008) tem como objectivo desenvolver um sistema de
dialogo que faca companhia ao seu utilizador, e e um exemplo deste tipo de sistemas.
Procurou-se apresentar nesta seccao uma classificacao que abrangesse um vasto leque de siste-
mas de dialogo. Alguns destes tipos de sistema estao mais em voga que outros. No entanto, a separacao
entre eles e, actualmente, cada vez menos marcada (M. McTear, n.d.). Ha cada vez mais sistemas mistos,
que por exemplo utilizam enquadramentos para modelar a informacao, para depois a processarem por
um agente, ou um sistema de estados. No sistema de estados os enquadramentos podem o dialogo em
cada estado (Glass & Weinstein, 2001). Encontramos ate sistemas de dialogo orientados a tarefa que
sao adaptados para permitir o desenvolvimento de sistemas de aprendizagem ou de acompanhamento
(Litman & Pan, 2002).
E importante levar em consideracao os diferentes tipos existentes para compreender as diversas
formas de construir sistemas de dialogo. Contudo, estes diversos tipos de sistema nao se excluem entre
6
si. A combinacao de diferentes tipos permite, por vezes, tornar um sistema mais versatil, eficiente e
robusto.1.3 Organiza� ~ao da disserta� ~aoEsta dissertacao encontra-se dividida em cinco capıtulos: Introducao, Estado da Arte, Desenvolvimentos
na Plataforma, Casos de Estudo e Conclusoes.
Neste capıtulo (Introducao) foi brevemente apresentada uma visao geral da area dos sistemas de
dialogo.
No capıtulo 2, descreve-se o trabalho previamente realizado na construcao de um sistema de
dialogo e faz-se uma avaliacao inicial do sistema. Nesta avaliacao, detectaram-se diversos problemas
cuja a solucao para os mesmos, orientou, em parte, este trabalho. Aproveitou-se tambem esta avaliacao
inicial, para se definir um modelo abrangente de avaliacao de sistemas de dialogo. Este modelo de
avaliacao sera utilizado, ainda no ambito deste trabalho, para avaliar o sistema de assistencia pessoal
LISA. O modelo de avaliacao aqui apresentado podera igualmente servir de base para futuras avaliacoes
de sistemas de dialogo.
No capıtulo 3, descrevem-se os principais problemas que o sistema de dialogo evidenciava,
apresentando-se as solucoes desenvolvidas para resolver ou minimizar os problemas detectados.
No capıtulo 4, descreve-se o sistema de assistencia pessoal LISA, desenvolvido no ambito deste
trabalho, e os sistemas de banca e de bolsa telefonica, desenvolvidos no decorrer do mesmo e que se
baseiam no mesmo sistema de dialogo. Ainda neste capıtulo, apresentam-se os principais requisitos das
novas instancias do sistema de dialogo e as solucoes desenvolvidas para responder a esses requisitos.
Por fim, no capıtulo 5, apresenta-se a avaliacao do sistema de assistencia pessoal LISA, que seguiu o
modelo previamente definido, fazem-se algumas comparacoes com a avaliacao anteriormente realizada,
apresentam-se as conclusoes do trabalho realizado e descrevem-se alguns possıveis trabalhos a realizar
no futuro.
7
8
2Estado da ArteO trabalho realizado no ambito desta tese aprofunda o gestor de dialogo STAR (Mourao, 2005). Por essa
razao, nao se fara aqui uma apresentacao do estado da arte em sistemas de dialogo, ja que tal pode ja ser
consultado em (Mourao, 2005). Em vez disso, ira-se neste capıtulo proceder a uma analise e avaliacao
daquele sistema. Pretende-se assim identificar e resolver os problemas que o sistema levanta e promo-
ver diversos melhoramentos por forma a tornar a plataforma mais estavel e robusta. Tais objectivos
enquadram-se naturalmente nas metas a que se propoe o projecto TECNOVOZ, em que participa o L2F.
Comeca-se por descrever a arquitectura do modulo STAR, que e responsavel pela gestao do dialogo, e
a arquitectura dos modulos circundantes (gestor de servicos e gestor de entradas e saıdas). No final,
apresenta-se os principais problemas desta arquitectura.
Procede-se, em seguida, a uma avaliacao do sistema. Com base nesta avaliacao, definem-se, entao,
os objectivos praticos e operacionais deste trabalho.2.1 STARO gestor de dialogo STAR e parte integrante de um projecto do L2F do INESC-ID com vista ao desenvol-
vimento de uma interface de fala independente do domınio. A plataforma STAR modela a informacao
recorrendo a enquadramentos e sobre ela foram implementados dois domınios: Domotica (gestao e
controlo automatico de recursos habitacionais) e Bilhetica (actividade de comercializacao de bilhetes).
O domınio da domotica consiste na implementacao de um sistema, denominado Ambrosio, de
controlo automatico por voz de diversos dispositivos domesticos. Com o Ambrosio, e possıvel atraves
de comandos de voz ligar/desligar luzes, um ar condicionado, uma aparelhagem sonora e abrir e fechar
os estores de uma sala.
O domınio da bilhetica providencia uma interface de voz para uma base de dados de percursos de
autocarro, podendo o utilizador, atraves de comandos de voz, consultar o horario de uma determinada
carreira, fornecendo para isso os dados necessarios: origem, destino, dia da semana e opcionalmente a
hora de partida ou de chegada.
Figura 2.1: Modelo de domınio do sistema STAR.
2.1.1 Modelo de domınio
O modelo de domınio do sistema STAR (figura 2.1) e constituıdo pelos seguintes componentes:
• Domınio - entidade que reune a informacao comum a um conjunto de dispositivos. E no domınio
que se especifica o enquadramento;
• Enquadramento - entidade onde se especifica o conjunto de campos necessario para representar
um domınio;
• Dispositivo - entidade que associa um domınio a um conjunto de servicos com caracterısticas
semelhantes;
• Estado - entidade que define um estado possıvel para um dispositivo, estando um determinado
conjunto de servicos disponıveis consoante o estado em que se encontra o dispositivo;
• Servico - entidade que representa univocamente o conjunto de condicoes necessarias a realizacao
de uma determinada tarefa.
2.1.2 Arquitectura
A arquitectura do sistema STAR e fortemente inspirada no sistema TRIPS (Allen et al., 2000; Allen,
Ferguson, & Stent, 2001; Allen, Byron, et al., 2001; Burstein et al., 2000), desenvolvido na Universidade
10
de Rochester. O STAR e parte integrante de uma arquitectura composta por tres modulos principais
ou macro modulos (figura 2.2) e resultou da juncao de um modulo de gestao de dialogo (STAR), uma
parte de gestao de servicos (Service Manager) (Cassaca & Maia, 2002) e um gestor de entradas e saıdas
(Input/Output Manager) (Viveiros, 2004), formando, no conjunto, o sistema de dialogo.
Figura 2.2: Arquitectura conceptual do sistema.
Na figura 2.3 e possıvel observar um esquema da arquitectura do STAR e as diversas interaccoes
realizadas entre os modulos constituintes.
2.1.2.1 Gestor de dialogo (STAR)
O gestor de dialogo STAR e composto pelos seguintes modulos: Reconhecedor de Linguagem, Gestor
de Interpretacao, Gestor de Tarefas, Agente Comportamental, Gestor de Geracao, Gerador de Superfıcie,
Contexto do Discurso, HUB Galaxy.
Reconhecedor de Linguagem O Reconhecedor de Linguagem e responsavel pela identificacao dos
objectos relevantes de uma frase e do tipo de acto de fala proferido pelo utilizador. Um acto de fala
pode ser definido como a unidade mınima de uma situacao de comunicacao entre humanos (ver seccao
5.2.2). A identificacao do tipo de actos de fala no discurso esta incompleta, identificando-se apenas
actos do tipo afirmacoes. Este modulo e tambem responsavel por diversas conversoes na representacao
dos objectos.
Gestor de Interpretacao O objectivo do Gestor de Interpretacao e construir uma interpretacao com os
dados que tem disponıveis: o contexto do discurso e a informacao do domınio.
Os objectos identificados pelo Reconhecedor de Linguagem sao enviados ao Reconhecedor de
Objectos (este modulo e descrito na seccao 2.1.2.2). Com o resultado da analise, sao construıdas as
interpretacoes possıveis (explorando as combinacoes dos objectos reconhecidos) e enviadas ao Contexto
do Discurso.
11
Apos a analise de contexto, e, entao, identificado o domınio associado. Esta identificacao comeca
por verificar se a interpretacao gerada faz sentido no contexto de discurso actual. Caso isto nao se verifi-
que, considera-se que o utilizador iniciou uma nova conversacao, e o domınio a considerar encontra-se
associado aos objectos utilizados para construir a interpretacao.
Com base no domınio e nas interpretacoes extraıdas e, entao, gerado um conjunto de obrigacoes de
discurso. Se o enquadramento dispuser da informacao necessaria, e executado o respectivo servico. No
final, e actualizado o estado do dialogo no contexto do discurso e sao enviadas as obrigacoes de discurso
ao Agente Comportamental.
Gestor de Tarefas O Gestor de Tarefas e a interface de comunicacao do Gestor de Dialogo com o Gestor
de Servicos. E neste modulo que se efectuam as conversoes das interfaces e que e guardado o estado
da iteracao actual, tanto ao nıvel dos pedidos de informacao (reconhecimento de objectos, definicao de
enquadramentos, definicao de servicos, entre outros) como ao nıvel da execucao de servicos (servicos
executados, resultados de execucao, entre outros).
Figura 2.3: Arquitectura do STAR (a direita) e modelo de interaccao (a esquerda).
Agente Comportamental O Agente Comportamental encontra-se numa fase inicial de desenvolvi-
mento, realizando apenas tarefas de limpeza do contexto do discurso quando o dialogo termina e enca-
minhando as obrigacoes de discurso geradas pelo Gestor de Interpretacoes para o Gestor de Geracao.
Gestor de Geracao O Gestor de Geracao nao foi ainda desenvolvido, sendo o Gerador de Superfıcie a
efectuar a gestao da geracao de linguagem. Este apenas recebe as obrigacoes de discurso enviadas pelo
Agente Comportamental e activa-as no Contexto do Discurso.
12
Gerador de Superficie O Gerador de Superfıcie, com base no tipo de obrigacoes de discurso geradas
pelo Gestor de Interpretacao, procura a regra de geracao correspondente, definida no domınio, e preen-
che os campos dinamicos com recurso a informacao linguıstica e/ou de contexto. A resposta gerada e
enviada ao Gestor de Entradas e Saıdas.
Contexto do Discurso O Contexto do Discurso gere a informacao referente ao discurso que se de-
senrola entre o sistema e o utilizador. Esta informacao e composta essencialmente pelo conjunto de
obrigacoes de discurso activas, pelo estado do dialogo (enquadramento referente ao domınio onde o
dialogo acontece) e pelo historico de interpretacoes e obrigacoes de discurso.
As obrigacoes de discurso activas (obrigacoes de discurso que geraram a ultima interaccao do sis-
tema) sao utilizadas no emparelhamento da entrada, mais concretamente, se o utilizador responder ao
sistema, este consegue perceber e utilizar essa informacao para enriquecer a interpretacao actual e o
dialogo desenvolvido.
O estado do dialogo guarda a informacao recolhida e e limpo quando o dialogo termina.
O historico das interpretacoes extraıdas e das obrigacoes de discurso associadas nao e utilizado pelo
sistema.
HUB Galaxy O HUB Galaxy1 (Bayer et al., 2001) e o ponto central de comunicacao do sistema. Este
recebe os pedidos dos diversos modulos e, com base numa tabela de direccoes (do ingles routing table)
entrega os pacotes aos respectivos destinatarios.
2.1.2.2 Gestor de servicos
O Gestor de Servicos e composto pelos seguintes modulos: Servidor Galaxy do Gestor de Servicos,
Gestor de Dispositivos, Gestor de Domınios, Gestor de Acesso, Gestor de Reconhecimento de Objectos,
Proxy do Dispositivo e Nucleo do Dispositivo.
Na figura 2.4 encontra-se esquematizado o Gestor de Servicos, com os diversos modulos e as
interaccoes realizadas entre estes.
Servidor Galaxy do Gestor de Servicos O Servidor Galaxy do Gestor de Servicos gere a interface de
comunicacao com o Gestor de Dialogo, interpretando a informacao enviada atraves do HUB. E aqui que
sao geridos os registos dos novos dispositivos e os pedidos vindos do Gestor de Dialogo.
Gestor de Dispositivos O Gestor de Dispositivos guarda a informacao referente aos dispositivos re-
gistados no sistema, assegurando essa informacao ao Gestor de Dialogo.
1Pagina de referencia do Galaxy Comunicator disponıvel em: http://communicator.sourceforge.net/index.shtml
13
Gestor de domınios O Gestor de Domınios guarda os domınios associados a dispositivos registados
no sistema, fornecendo essa informacao ao Gestor de Dialogo.
Gestor de acesso O Gestor de Acessos controla os acessos do utilizador aos dispositivos registados no
sistema, podendo restringir a utilizacao de alguns dispositivos por parte de um determinado utilizador.
Gestor de reconhecimento de objectos O Gestor de Reconhecimento de Objectos consulta a
informacao fornecida pelos dispositivos para reconhecer um determinado objecto num determinado
domınio. Este modulo e utilizado pelo Gestor de Interpretacao na fase inicial de construcao da
interpretacao.
A especificacao da informacao a ser reconhecida e declarada num formato XML e e lida pelo Nucleo
do Dispositivo durante a fase de inicializacao e registo do dispositivo.
Figura 2.4: Arquitectura do gestor de servicos.
Proxy do Dispositivo O Proxy do Dispositivo e o modulo responsavel pela comunicacao com o dis-
positivo associado. Este abstrai a camada e protocolo de comunicacao com os dispositivos, tornando-a
transparente para o Gestor de Dispositivos.
Nucleo do Dispositivo O Nucleo do Dispositivo implementa o protocolo de comunicacao com o Ges-
tor de Servicos, escondendo os detalhes dessa implementacao do dispositivo propriamente dito. Este
nucleo e tambem responsavel por fornecer a informacao de domınio, controlar a execucao de servicos no
dispositivo, gerir o estado em que se encontra o dispositivo e realizar o registo do dispositivo junto do
gestor de servicos, assegurando a informacao de domınio e servicos necessaria, na fase de inicializacao
do mesmo.
14
2.1.2.3 Gestor de entradas e saıdas
O Gestor de Entradas e Saıdas e composto pelos seguintes modulos: Ponto de Acesso do Sistema de
Dialogo (DSAP - Dialogue System Access Point), Gestor de Fala e da Cara (SFM - Speech and Face Mana-
ger), Reconhecimento de Fala Automatico (ASR - Automatic Speech Recognition), Gestor de Sincronizacao
Audio Cara (AFSM - Audio and Face Synchronization Manager), Sıntese de Fala (TTS - Text To Speech), Cara
Virtual (FACE).
Na figura 2.5 encontra-se esquematizado o Gestor de Entradas e Saıdas, contendo os diversos
modulos constituintes.
Figura 2.5: Arquitectura do gestor de entradas e saıdas.
Ponto de Acesso do Sistema de Dialogo Modulo responsavel pelas conversoes de interface entre o
HUB e o gestor de fala e da cara.
Gestor de Fala e da Cara Gere o processo de sıntese e reconhecimento de fala, controla as entradas e
saıdas de audio e fornece a informacao de sıntese de fala necessaria aos movimentos da cara virtual.
Reconhecimento de Fala Automatico O reconhecimento de fala automatico, que efectua o reconheci-
mento do que foi dito pelo utilizador para o formato textual, e desempenhado pelo Audimus (Meinedo
et al., 2003), um reconhecedor de fala independente da lıngua, desenvolvido tambem no L2F.
Gestor de Sincronizacao Audio-Cara Sincroniza a reproducao do audio sintetizado e os movimentos
da cara virtual.
Sıntese de Fala A sıntese de fala converte uma frase, no formato textual, para um sinal de fala e e
desempenhada pelo sistema Dixi+ (Oliveira et al., 2001), que associa o sintetizador desenvolvido pela
Universidade de Edinburgh, o Festival (Taylor et al., 1998), a uma voz em portugues de europeu, desen-
volvida no L2F.
15
Cara Efectua a gestao dos aspectos ligados a cara virtual, desde a movimentacao de cada musculo a
expressao de emocoes.2.2 Avalia� ~aoPretendendo-se melhorar o sistema actual, decidiu-se avaliar o seu desempenho com o objectivo de
validar o conhecimento empırico sobre o estado actual do sistema. Ainda nao tinha sido feita qualquer
avaliacao formal do sistema e era necessario faze-la para melhor delinear o trabalho a desenvolver.
A avaliacao tem como principal objectivo o gestor de dialogo STAR. No entanto, dado que este se
encontra inserido no sistema de dialogo, sao tambem avaliados os modulos de reconhecimento e sıntese
de fala.
O sistema foi avaliado na vertente ”Ambrosio o mordomo virtual”, que controla um conjunto de
dispositivos de domotica.
Foi utilizado como ponto de entrada de audio no sistema um agregado de microfones (Coelho,
2007; Coelho et al., 2008), desenvolvido tambem no L2F, que tem como objectivo permitir a captacao de
sinal de audio com elevada qualidade, num determinado espectro espacial, sem que seja necessario o
utilizador falar para um microfone, tornando a experiencia mais natural.
Foram definidos dois testes, um para simular um utilizador experiente (utilizador tıpico deste sis-
tema), que conhece o tipo de interaccoes aceites pelo sistema, e um segundo que tenta simular um
utilizador inexperiente que nao conhece o sistema nem o tipo de interaccoes permitidas. Pretende-se,
assim, perceber se o sistema e usavel como interface de voz (utilizador experiente) e, por outro lado,
sendo o sistema usavel, qual o esforco inicial necessario para que um utilizador aprenda-a utilizar o
sistema (utilizador inexperiente).
Posteriormente, foi concebido um questionario que visa medir o grau de satisfacao do utilizador, e
que foi preenchido pelo utilizadores que participaram nesta avaliacao.
Esta avaliacao baseia-se numa adaptacao das directivas PARADISE (M. A. Walker et al., 1997), de-
senhada para avaliacao de interfaces em lıngua natural, e em dois casos de estudo apresentados em (M.
Walker et al., 1998), depois de terem sido analisadas diversas frameworks e casos de estudo realizados
na area (M. A. Walker et al., 1998; Bernsen & Dybkjaer, 1999; Bernsen & Dybkjær, 2000; Bernsen et al.,
1998; Dybkjær & Bernsen, 2001; Bernsen & Dybkjær, n.d.; Charfuelan et al., 2000; Lamel et al., 2000).
2.2.1 Descricao das directivas PARADISE
Nesta seccao, descrevem-se sucintamente as directivas PARADISE, em que se baseia esta avaliacao.
16
Para se conseguir avaliar e comparar esta avaliacao com avaliacoes feitas a outros sistemas e ne-
cessario definir um conjunto de metricas de desempenho.
As directivas PARADISE comecam por definir um conjunto de metricas objectivas (ou quantitati-
vas) e subjectivas (ou qualitativas) que tem como objectivo determinar o desempenho de uma interface
de fala:
Metricas objectivas ou quantitativas:
• Percentagem de respostas correctas de um conjunto de respostas possıveis;
• Percentagem de transaccoes com sucesso ou tarefas concluıdas;
• Numero de turnos (ou instancias de discurso, do ingles utterances);
• Tempo gasto com o dialogo ou a concluir uma tarefa;
• Tempo medio de resposta do utilizador;
• Tempo medio de resposta do sistema;
• Percentagem de mensagens para diagnostico de erros;
• Percentagem de instancias de discurso ”nao triviais”(instancias de discurso compostas por mais
do que uma palavra e que nao se resumem a confirmar ou negar algo);
• Dimensao media (numero medio de palavras) das instancias de discurso ”nao triviais”.
Metricas subjectivas ou qualitativas:
• Percentagem de instancias de discurso para recuperacao implıcita (onde o sistema utiliza o con-
texto do discurso para recuperar de erros ou de reconhecimento parcial do que foi proferido pelo
utilizador);
• Percentagem de instancias de discurso, para recuperacao de erros, explıcitas;
• Percentagem de mensagens do sistema contextualmente apropriadas;
• Cooperatividade (adesao do comportamento do sistema aos maximos definidos por Grice’s em
(Grice, 1975), quantidade, qualidade, relacao e modo, e submaximos respectivos a cada um);
• Percentagem de respostas correctas e parcialmente correctas;
• Percentagem de instancias de discurso do sistema apropriadas, inapropriadas e de diagnostico;
17
• Satisfacao do utilizador (percepcao por parte do utilizador da usabilidade do sistema, habitual-
mente obtida por recurso a questionarios de escolha multipla, nos quais se pede ao utilizador para
classificar a eficiencia do sistema num conjunto de caracterısticas de usabilidade, de acordo com
uma determinada escala).
A dificuldade associada a cada tipo de metricas e diferente. As metricas objectivas podem ser
obtidas recorrendo a registos do sistema, enquanto as metricas subjectivas devem ser avaliadas por
mais do que um humano.
No entanto, existem algumas limitacoes a esta comparacao e que foram ja identificadas pelos au-
tores em (M. Walker et al., 1998). A primeira limitacao esta associada ao facto de se estar a avaliar a
“correccao” das respostas do sistema com recurso a um conjunto de respostas possıveis. Sistemas com
diferentes estrategias de dialogo terao diferentes abordagens para concluir as mesmas tarefas o que leva
a que o conjunto de respostas possıveis seja diferente. Uma segunda limitacao esta no facto de nao estar
identificada a interdependencia entre as diferentes metricas podendo estas fornecer informacao redun-
dante. A terceira e ultima limitacao identificada pelos autores foi o facto de nao existir uma forma de
combinar diferentes metricas. O exemplo apresentado descreve o facto de dois sistemas, um sistema A
que recorre a confirmacao explıcita e um sistema B que recorre a confirmacao implıcita, terem um con-
ceito de eficiencia diferente. Por um lado, o sistema A obtem um maior numero de tarefas concluıdas
com sucesso, no entanto o tempo de dialogo neste caso e superior ao dobro do tempo gasto pelo sistema
B. E possıvel concluir que os sistemas, dadas as suas caracterısticas, se aplicam a cenarios de interaccao
diferentes no entanto nao e possıvel aferir qual dos dois e mais eficiente no cenario geral.
Teoricamente, estas metricas deveriam possibilitar a comparacao do desempenho de diferentes sis-
temas entre si. Contudo, como foi referido pelos proprios autores (M. Walker et al., 1998), o processo e
bastante complexo, sendo apenas possıvel comparar alguns aspectos e tornando difıcil retirar daı con-
clusoes suficientemente concretas.
As directivas PARADISE foram escolhidas como base para esta avaliacao por definirem correcta-
mente os diversos passos a realizar durante a avaliacao e os aspectos a ter em consideracao em cada
ponto, o que nem sempre acontecia nos restantes casos analisados.
2.2.2 Caracterısticas da avaliacao
Com base na analise das directivas PARADISE, foram identificados os principais aspectos a focar, e nos
quais se baseia esta avaliacao.
Percepcao da tarefa por parte do sistema A percepcao de uma tarefa por parte do sistema esta, numa
primeira fase, dependente da eficiencia/precisao do modulo de reconhecimento de fala. Apos o reco-
18
nhecimento de fala o texto e passado ao gestor de dialogo e cabe a este interpretar o que foi dito pelo
utilizador, extraindo as respectivas intencoes do discurso.
Os modulos de reconhecimento/sıntese de fala e o modulo de gestao de dialogo, dada a elevada
complexidade, serao testados separadamente. O gestor de dialogo sera testado recorrendo a transcricoes
manuais, enquanto o reconhecedor/sintetizador sera testado em conjunto com o gestor de dialogo.
Tempo de resposta/dialogo O tempo de resposta do sistema e a eficiencia do dialogo sao factores
importantes para o desempenho geral do sistema.
A eficiencia de um interface de fala para sistemas de comando e controlo, como e o caso do
”Ambrosio”, e decisiva, dado que os produtos substitutos ja existem no mercado (interruptores, con-
troles remotos, entre outros), nao requerem tempo de aprendizagem, sao eficientes e bastante comodos
na grande maioria das situacoes.
Conhecimento previo do modo de interaccao O sistema Ambrosio, numa situacao real, sera utilizado
por utilizadores experientes, que dispoem desta plataforma em suas casas e a utilizam todos os dias,
conhecendo perfeitamente como devem interagir com o sistema.
Para aferir se o sistema e eficiente e necessario definir o cenario em que se enquadra essa definicao
de eficiencia. Posto isto, foram definidos tres nıveis de experiencia, onde se tenta enquadrar cada um
dos utilizadores, por forma a nao so fazer uma avaliacao de eficiencia global mas tambem identificar em
que situacoes especıficas e que o sistema nao e eficiente.
Satisfacao do utilizador A base de qualquer avaliacao e compreender se os interessados (do ingles
stake holders) estao satisfeitos com um determinado produto ou servico. Um sistema pode ser eficiente e
natural mas, se nao satisfizer os interessados e em particular os seus utilizadores, nao tera sucesso.
A satisfacao do utilizador e medida atraves de um questionario, ao qual o utilizador responde, apos
a realizacao de um conjunto de tarefas descrito no guiao de teste (seccao 2.2.4). O grau de satisfacao tem
em consideracao nao so a percepcao de utilidade do sistema, por parte do utilizador, mas tambem a
ideia de eficiencia que o utilizador tem do sistema. So assim se consegue perceber se usaria de facto o
sistema num caso real e quanto estaria disposto a investir na aquisicao do sistema.
2.2.3 Componentes avaliadas e metodologias adoptadas
Esta avaliacao tem como objecto principal o gestor de dialogo, no entanto, e porque o sistema Ambrosio
nao se baseia apenas no gestor do dialogo, os testes com utilizadores realizavam-se sobre o sistema
integrado com o reconhecedor e o sintetizador de fala.
Durante a realizacao dos testes com utilizadores, foi gravado o audio do dialogo desenvolvido, que
foi depois transcrito manualmente, compondo assim um corpus de teste para o modulo de gestao de
19
dialogo. Este corpus permite avaliar quantos erros de interpretacao aconteceram por falha de reconheci-
mento/sıntese e disso retirar algumas conclusoes.
Tarefas realizadas por cada utilizador
No decorrer dos testes, foi pedido a cada utilizador para realizar um conjunto de tarefas, ordenado da
seguinte forma:
• Tarefa 1 - Ligar a luz da mesa;
• Tarefa 2 - Ligar a luz da sala;
• Tarefa 3 - Ligar o ar condicionado;
• Tarefa 4 - Desligar a luz da mesa e da sala;
• Tarefa 5 - Diminuir a temperatura do ar condicionado;
• Tarefa 6 - Ligar a aparelhagem;
• Tarefa 7 - Diminuir o volume da aparelhagem;
• Tarefa 8 - Abrir o estore;
• Tarefa 9 - Fechar o estore e desligar a aparelhagem.
Este conjunto de tarefas tenta resumir as operacoes basicas (dos dispositivos disponıveis) que um
utilizador efectuaria caso possuısse o sistema em sua casa. Destaca-se o caso das tarefas 4 e 9 que
envolvem a realizacao de duas tarefas em simultaneo, caracterıstica que nao e permitida pelo sistema,
ou seja, o utilizador para ter sucesso tera que perceber (com o auxılio da informacao que o sistema lhe
fornece) que apenas pode realizar uma tarefa de cada vez.
2.2.4 Medidas de avaliacao
Nesta seccao descrevem-se as medidas registadas em cada teste:
Experiencia do utilizador Indica qual o nıvel de experiencia com o sistema, do utilizador. A resposta
deve ser ”experiente”, ”inexperiente”ou ”semi-experiente”.
Esta medida influencia a analise dos dados efectuada a posteriori, dado que se espera melhores
resultados com os utilizadores mais experientes. E, contudo, importante avaliar o comportamento do
sistema perante utilizadores menos experientes, para aferir se o utilizador consegue aprender com o
sistema e se o sistema consegue recuperar dos erros que ocorrem devido a inexperiencia do utilizador.
20
Tarefa concluıda Indica se a tarefa em questao foi concluıda com sucesso, isto e se foram cumpridos
os objectivos propostos no tempo limite (1 minuto).
Esta medida permite calcular a percentagem de tarefas executadas correctamente, definindo de
modo simplificado uma taxa de sucesso global do sistema e indicando se o sistema e realmente util.
Consegue-se, assim, identificar os servicos que necessitam de maior esforco de desenvolvimento
para que se tornem efectivamente utilizaveis.
Tempo decorrido Tempo que o utilizador levou a concluir a tarefa, medido desde que lhe foi pedido
para executar a tarefa ate a conclusao da mesma.
Numero de iteracoes do sistema Numero de falas do sistema por tarefa.
Numero de iteracoes do utilizador Numero de falas do utilizador por tarefa.
Numero de palavras utilizadas pelo sistema Numero total de palavras que o sistema utiliza em todas
as interaccoes que efectuou para realizar uma tarefa.
Numero de palavras utilizadas pelo utilizador Numero total de palavras que o utilizador emprega
em todas as interaccoes que efectuou para realizar uma tarefa.
As medidas acima descritas (tempo decorrido, numero de iteracoes do sistema, numero de iteracoes
do utilizador, numero de palavras utilizadas pelo sistema e o numero de palavras empregues pelo uti-
lizador) permitem ter uma ideia da usabilidade, acentuando a eficiencia do sistema face as interfaces
actuais (por exemplo interruptores ou controles remotos), ou se, pelo menos, consegue ser comparado a
estas. Um sistema pode ter uma interface muito natural, mas se nao for eficiente nao sera utilizado.
Sao estas medidas que permitem analisar se esta interface conseguira substituir as actuais interfaces,
ou se, pelo menos, consegue competir com estas, nao pela eficiencia na realizacao das tarefas, mas pela
simplicidade com que estas sao realizadas.
Numero de erros devido a uma compreensao parcial Numero de iteracoes do utilizador, que o sistema
compreendeu parcialmente. Sao erros causados pelo facto de o sistema compreender apenas uma parte
daquilo que lhe foi dito. Esta metrica foi avaliada do ponto de vista do utilizador, ou seja, se o utilizador
teve a percepcao de que o sistema percebeu parte daquilo que lhe foi dito.
Numero de erros devido a uma falha total na compreensao Numero de iteracoes do utilizador que
o sistema nao compreendeu. Sao erros causados pelo facto de o sistema nao compreender nada do que
lhe foi dito. Mais uma vez esta metrica foi avaliada do ponto de vista do utilizador, nao tendo sido
utilizados os logs do sistema para verificar se efectivamente o sistema compreendeu alguma parte do
que lhe foi dito.
21
Numero de erros que impediram o sistema de progredir Numero de vezes em que o sistema entra
em qualquer tipo de estado que requer a intervencao de um administrador de sistema.
As dificuldades associadas a uma interface e o processo de resolucao de problemas sao dois fac-
tores frequentemente associados a eficiencia do sistema. A medicao do numero de erros ocorridos
e fundamental para perceber se o sistema consegue recuperar de situacoes menos normais de forma
eficiente e clara para o utilizador, nao causando desconfianca no sistema nem mau-estar.
Numero de pedidos de ajuda a equipa Numero de pedidos de ajuda por parte do utilizador a equipa
de avaliacao/desenvolvimento.
Estas medidas visam medir a satisfacao do utilizador, que e o principal factor em conta no pro-
cesso de decisao. Uma interface pode ser mais ou menos natural e mais ou menos eficiente mas o que
realmente importa e o quao satisfeito ficou um utilizador com o sistema.
Para se conseguir avaliar se os diversos utilizadores que testaram o sistema ficaram de facto satis-
feitos com o seu desempenho e se utilizariam mesmo o sistema num cenario real, recolheram-se todas
estas medidas, que permitem construir uma visao mais tecnica e mais concreta do conceito de satisfacao
do utilizador. Alem disso, foi ainda elaborado um questionario (descrito na seccao 2.2.5) que visa obter
a(s) impressao(oes) retida(s) pelo utilizador relativamente ao sistema, depois de o ter utilizado.
Com este conjunto de medidas devera ser possıvel caracterizar com rigor o estado de desenvolvi-
mento do sistema na optica da sua utilizacao, sendo tambem possıvel identificar os principais problemas
e outros aspectos do sistema que ainda e necessario desenvolver.
2.2.5 Questionario
Apresenta-se agora o questionario, desenvolvido no ambito desta avaliacao e que esta na base de algu-
mas medidas qualitativas. As perguntas definidas no questionario sao:
Qual o grau de satisfacao em relacao ao seu futuro mordomo, o Ambrosio? Esta questao tenta fazer
uma analise superficial da satisfacao do utilizador e perceber se as suas expectativas foram correspon-
didas;
Foi facil compreender o que o Ambrosio lhe disse? O objectivo desta questao e perceber se o utiliza-
dor consegue compreender o que o sistema lhe tenta transmitir;
O Ambrosio conseguiu compreender o que lhe disse? Com esta questao tenta-se perceber se o utili-
zador julga que o sistema o compreendeu;
22
Foi facil executar cada uma das tarefas? Esta questao mede a satisfacao e a eficiencia com que o utili-
zador realizou cada tarefa.
Permite perceber quais as tarefas mais complexas ou que sao de difıcil realizacao, para que futura-
mente possam ser melhoradas;
Achou o ritmo desta conversacao adequado as tarefas? Mais uma vez, tenta-se perceber se o utiliza-
dor acha o sistema eficiente e se achou o dialogo adequado a tarefa e domınio em causa;
Durante a conversacao soube sempre o que dizer ao Ambrosio para que ele executasse a respectiva
tarefa? O objectivo desta questao e avaliar se o utilizador se sentiu perdido durante a interaccao com o
sistema. O facto do utilizador se sentir perdido durante a conversacao reduz a eficiencia da comunicacao
e penaliza a satisfacao do utilizador, que nao gosta de perder o controlo sobre os dispositivos;
O Ambrosio levou muito tempo a responder-lhe? Aqui e avaliada a eficiencia que o utilizador atribui
ao sistema que, por comparacao com a questao anterior, referente ao ritmo da conversacao, permite per-
ceber qual a adequacao do dialogo e a atencao/coerencia com que o utilizador preenche o questionario;
O Ambrosio tem o comportamento que esperava? Esta questao permite avaliar as expectativas do
utilizador apos os testes;
Gostaria de ter o Ambrosio em sua casa? Mais uma vez e aferida a satisfacao do utilizador, mas agora
propondo-lhe um cenario real;
Quanto tempo julga que levou a executar cada tarefa? Esta questao relaciona-se com a seguinte e tem
como objectivo, medir como avalia o utilizador a rapidez com que executou as diversas tarefas. Mais
uma vez esta-se a avaliar a eficiencia do sistema relativamente a tarefa. No entanto, esta questao insere-
-se num ambito mais geral de comparacao desta interface com as interfaces habituais (interruptores,
comandos remotos, entre outras);
Quanto tempo levaria a realizar a tarefa com os mecanismos que dispoe actualmente? Aqui altera-se
o foco para as interfaces ja existentes no dia-a-dia. O utilizador e levado a comparar as interfaces actuais
com esta interface de voz, tentando-se saber se, apesar dos restantes factores, o utilizador considera que
o sistema e usavel e em que situacoes;
Que tarefa(s) gostaria de acrescentar ao Ambrosio? O objectivo desta questao, e fornecer um espaco
onde o utilizador possa deixar as suas sugestoes de funcionalidades para o sistema, que serao utilizadas
mais tarde para promover novos desenvolvimentos.
23
2.2.6 Testes-piloto
Antes de se passar aos testes propriamente ditos, foram realizados testes-piloto que permitiram corrigir
diversos aspectos no modo como decorreu a avaliacao. Nesta seccao, abordam-se os principais aspectos
que marcaram esses testes e que de alguma forma redefiniram o rumo da avaliacao.
Remocao da palavra de referencia Um aspecto que foi identificado logo nos testes preliminares efec-
tuados pela equipa de desenvolvimento, foi o facto de o sistema possuir uma palavra de referencia a
partir da qual o sistema comeca a “ouvir” o utilizador. Esta palavra de referencia existe para que seja
possıvel falar num ambiente sem que o sistema esteja sempre a “ouvir” e a tentar interpretar o que e
dito.
A palavra de referencia e dependente do orador e numa situacao de teste envolvia gravar uma
referencia para cada utilizador de teste, o que introduzia entropia no processo de avaliacao e distraia o
utilizador com um aspecto que nao era importante para a avaliacao.
Isto levou a que essa referencia fosse desactivada no sistema. Esta solucao implicou a adopcao de al-
guns procedimentos, nomeadamente foi necessario alertar os utilizadores inexperientes para o facto do
sistema os estar a escutar ininterruptamente e que deviam evitar dizer algo que nao fosse para executar
uma tarefa, e os utilizadores experientes para o facto de nao ser necessario dizer a referencia.
Por outro lado nao foi possıvel testar esta caracterıstica no sistema, o que seria de todo conveniente
dado que, se esta referencia nao funcionar correctamente, o utilizador ve-se impossibilitado de realizar
as tarefas habituais.
Redefinicao da ordem das tarefas A ordem das tarefas foi varias vezes redefinida ao longo dos testes-
piloto. Por um lado, era necessario colocar as tarefas mais complexas para o fim, para nao comprometer
a motivacao do utilizador aquando da realizacao das tarefas mais simples; por outro lado, se se concen-
trasse no final um conjunto de tarefas complexas, o utilizador tinha a tendencia para desistir de realizar
as ultimas. Dado que as tarefas tambem tinham simultaneamente que ser realizadas por uma ordem
logica, tentou-se encontrar um equilıbrio, intercalando tarefas mais simples com tarefas mais comple-
xas, numa complexidade crescente.
Uma vez que as tarefas seguem uma ordem logica de execucao, julgou-se inicialmente que tal facto
poderia afectar a avaliacao, na medida em que um erro de reconhecimento/interpretacao do que o utili-
zador dissesse levaria o sistema a executar uma tarefa nao pretendida. Tal poderia violar a ordem logica
das tarefas, comprometendo a realizacao dos restantes testes. Contudo, nos testes-piloto, esta situacao
nao chegou a verificar- se e, durante a avaliacao, so ocorreu em casos muito particulares, contrariando
pois as expectativas iniciais.
24
Necessidade de dialogo introdutorio Num primeiro momento, pensou-se que se deveria minimizar
o contacto entre a equipa de avaliacao e o utilizador, para que este pudesse realizar as tarefas o mais
naturalmente possıvel. No entanto, verificou-se que isso penalizava a execucao dos testes: os utiliza-
dores nem sempre liam correctamente o texto introdutorio pelo que foi necessario alterar a estrategia e
explicar ao utilizador as condicoes exactas em que iria decorrer o teste e o que e que se deveria fazer.
Utilidade do teste para utilizadores inexperientes Durante a realizacao dos testes-piloto, a equipa de
avaliacao comecou a questionar o facto de existir um guiao sem vocabulario (previamente referido na
seccao 2.2) para simular utilizadores inexperientes, dado que os utilizadores verdadeiramente inexperi-
entes, mesmo utilizando o guiao com vocabulario (que torna mais simples a interaccao com o sistema
por fornecer vocabulario aceite pelo mesmo), ja obtinham resultados aquem das expectativas. Assim,
concluiu-se que a utilidade de simular utilizadores inexperientes era reduzida.
Alteracao das condicoes de teste Durante a realizacao dos testes-piloto, os estores automaticos passa-
ram a comportar-se de modo incorrecto. Esse dispositivo teve que ser desactivado, estando no sistema
apenas em modo ”desligado”, ou seja, o sistema transmitia a indicacao de que estes tinham sido abertos
ou fechados, mas os estores na pratica nao abriam nem fechavam. Isto penalizou a naturalidade com
que se executam as tarefas, pelo que levou a que as tarefas relacionadas com este dispositivo fossem as
ultimas tarefas a ser executadas, tendo isso sido levado em consideracao posteriormente, na analise de
resultados.
2.2.7 Testes
Durante os testes nao se verificou nenhuma outra situacao que mereca destaque particular, alem das
apontadas nos testes-piloto. Foram realizados testes com 10 utilizador (4 experientes, 2 semi-experientes
e 4 inexperientes). Os dados recolhidos durante os testes foram analisados e sao apresentados no anexo
A.
Discussao dos resultados e conclusoes
Conclui-se que o sistema para utilizadores experientes ja possui uma taxa de sucesso bastante elevada,
atingindo uma taxa de satisfacao dos utilizadores na ordem dos 68%. No entanto, para utilizadores
menos experientes, o sistema ainda fica aquem das expectativas, com taxas de satisfacao na ordem dos
55% e com taxas totais de erro superiores a 20 erros no total das tarefas por utilizador.
A capacidade do sistema para resolucao de erros e reduzida o que leva a que normalmente ocorra
mais do que um erro consecutivamente, seja porque o utilizador tenta executar a tarefa de uma forma
diferente da que o sistema consegue interpretar, seja porque comeca a dar a mesma ordem com um tom
de voz mais alto e a taxa de reconhecimento baixa significativamente.
25
Figura 2.6: Numero medio de falhas ocorridas, por classe de utilizadores, na realizacao do total dastarefas.
Atraves da analise dos dados, conclui-se que mais de 50% dos erros se devem a erros de reconheci-
mento de fala. No entanto, ha que salientar que os testes foram efectuados com o guiao que descrevia
textualmente as tarefas a realizar. O vocabulario utilizado neste guiao foi escolhido tendo em conta que
o gestor de dialogo o conseguiria interpretar, isto porque ja se previa (e como se veio a confirmar durante
os testes), que os utilizadores iriam dar as ordens ao sistema utilizando o mesmo vocabulario empregue
na descricao da tarefa.
Muitos dos erros de reconhecimento de fala devem-se a uma falta de parametrizacao do Gestor de
Entradas e Saıdas e em particular do reconhecedor, com a informacao de contexto disponıvel no gestor
de dialogo. O gestor de dialogo poderia, por exemplo, indicar qual o modelo de linguagem a activar
no reconhecedor quando gera uma determinada pergunta para o utilizador, passando o reconhecedor
a ter uma expectativa do que o utilizador lhe iria tentar responder. A parametrizacao do Gestor de
Entradas e Saıdas e um aspecto fulcral que e necessario ter em conta antes de se desenvolver qualquer
sistema novo, dado que com uma taxa de erro tao elevada no reconhecedor (em ambiente optimo), nao
e possıvel trabalhar e desenvolver toda a parte de interpretacao.
Apesar disso, o Gestor de Dialogo deveria poder ajudar o utilizador, nao so com confirmacoes
explıcitas/implıcitas (tendo em conta, por exemplo, as probabilidades de reconhecimento), mas tambem
sugerindo tarefas a realizar com base no que conseguiu reconhecer, minimizando a necessidade de re-
conhecimento de frases muito longas, que aumentam a probabilidade de erros.
No entanto, o sistema ja consegue ter um desempenho aceitavel, tendo os utilizares experientes e
semi-experientes (utilizadores habituais deste sistema) conseguido concluir com sucesso todas as tare-
fas, com o tempo medio de aproximadamente 10 e 20 segundos respectivamente, tempos que se podem
considerar satisfatorios em comparacao com as interfaces actuais. A fase de aprendizagem por parte
do utilizador tem de ser melhorada. O sistema devera auxiliar mais e melhor o utilizador quando nao
consegue compreender o que este lhe esta a transmitir ou quando o utilizador nao souber o que fazer.
26
Figura 2.7: Percentagem de falhas ocorridas devido a erros de reconhecimento (no total de falhas), porclasse de utilizadores.
O sistema Ambrosio, devido a limitacoes da plataforma, e um sistema pouco pro-activo, eviden-
ciando uma reduzida capacidade de recuperacao de falhas e/ou de resolucao de conflitos. E por isso
necessario focar este aspecto durante os desenvolvimentos futuros da plataforma.
Tal como ja foi referido e fundamental comecar a partilhar a informacao sobre o contexto do dialogo,
guardada pelo gestor de dialogo, com o Gestor de Entradas e Saıdas como forma de melhorar o reco-
nhecimento, a sıntese, e o feedback visual transmitido ao utilizador atraves de expressoes faciais.
E desejavel que se efectue um estudo sobre o tipo de servicos a incluir num sistema deste genero,
dado que a interface tem potencial para ser comercializada no mercado de domotica, no entanto e apro-
veitada apenas para realizar algumas tarefas bastante simples que poderiam ser facilmente estendidas.
Apos a conclusao dos novos desenvolvimentos, realizar-se-a uma nova avaliacao ao sistema na
vertente assistente pessoal LISA, dentro dos mesmo moldes, de forma a ser possıvel fazer algumas
comparacoes.
27
28
3Desenvolvimentos naPlataformaApos a avaliacao do trabalho previamente realizado procedeu-se a analise de problemas e requisitos do
sistema. Esta analise e parte integrante do trabalho a desenvolver no projecto TECNOVOZ, que tem
como objectivo tornar o sistema mais robusto e eficiente, para permitir a implementacao de tres novos
sistemas: o sistema de assistente pessoal LISA, descrito na seccao 4.1, e os sistemas de banca e bolsa
telefonica, descritos na seccao 4.2. Neste capıtulo apresentam-se os resultados dessa analise, apontando
os principais problemas encontrados e os desenvolvimentos feitos sobre o sistema, para colmatar ou
minimizar os problemas identificados ao nıvel do sistema de dialogo.
Este capıtulo, descreve as necessidades de reengenharia do sistema. O sistema previamente desen-
volvido agrupa tres trabalhos finais de curso (Rodrigues et al., 2002; Cassaca & Maia, 2002; Viveiros,
2004) e uma tese de mestrado (Mourao, 2005). No entanto, estes focaram sobretudo os objectivos parti-
culares desses trabalhos, nao tendo sido orientado para a integracao numa arquitectura mais geral.
Por outro lado, os objectivos actuais para o sistema sao mais ambiciosos. Actualmente existem
diversas empresas interessadas em integrar uma interface de fala nas mais diversas aplicacoes. Este
interesse demonstrado esta a alterar o processo de desenvolvimento, passando o sistema de dialogo a
ser, para alem de um projecto de constante investigacao, um projecto pre comercial.
E por isso necessario rever e alinhar o sistema com os objectivos actuais, redefinir a arquitectura
de um ponto de vista geral e tornar o sistema mais eficiente, robusto e versatil, quer do ponto de vista
aplicacional, quer ao nıvel da interface de fala providenciada pelo mesmo.3.1 HUB Galaxy e utiliza� ~ao de estruturas XMLO HUB Galaxy (Bayer et al., 2001) providencia a camada de comunicacao entre modulos do sistema.
Esta camada de comunicacao e centralizada no HUB, que efectua posteriormente o encaminhamento
dos pacotes para os respectivos modulos, com recurso a uma tabela de encaminhamento.
O HUB foi introduzido com o objectivo de tornar o desenvolvimento de novos modulos mais
versatil. Este possibilita o desenvolvimento de novos modulos para o gestor de dialogo, em qualquer
linguagem de programacao, de forma independente, ligando-os atraves de conversores de interface
(que convertem os dados a saıda do modulo para o formato XML manipulado pelo sistema) ao gestor
de dialogo.
A utilizacao de um HUB Galaxy e de estruturas XML e um dos principais problemas da arquitec-
tura desenvolvida. As estruturas XML utilizadas atraves do HUB obrigam a diversas conversoes entre
diferentes formatos (XML e objectos Java), conversoes morosas e que penalizam o desempenho do sis-
tema, dificultando bastante a tarefa dos programadores no desenvolvimento dos modulos e na remocao
de incorreccoes no codigo. Por outro lado, a centralizacao com posterior encaminhamento dos pacotes
e uma tarefa computacionalmente pesada, tendo em conta que existem diversos modulos assincrona-
mente a enviar mensagens para o HUB, e que as mensagens enviadas utilizam um formato XML que
e necessario compor antes do envio da mensagem para o HUB, tendo o modulo receptor que extrair a
informacao transmitida nessa mensagem.
Por exemplo, para que o gestor de geracao possa activar as obrigacoes de discurso geradas no gestor
de interpretacoes e necessario compor uma mensagem XML, atraves da mensagem XML recebida do
agente comportamental, e enviar para o HUB essa mensagem. Por sua vez, o HUB tera de consultar o
destino de uma mensagem daquele tipo vinda do gestor de geracao, enviar a mensagem para o contexto
do discurso, onde tera ainda que ser processada para que se obtenham as obrigacoes de discurso que
serao activadas no contexto.
Actualmente os objectivos inverteram-se, o sistema ja dispoem dos modulos necessarios ao de-
senvolvimento de dialogos relativamente complexos, e como se quer desenvolver uma plataforma co-
mercial, estes modulos necessitam agora de desenvolvimentos, optimizacoes e adaptacoes, para que se
tornem mais robustos e eficientes.
O problema deixou de ser a versatilidade com que se ligam/desligam novos modulos ao sistema
mas sim a eficiencia do sistema em si, a simplicidade da sua interface para que este possa ser integrado
com outros projectos, que por sua vez implica que a solucao desenvolvida seja robusta, e a facilidade
com que se desenvolve e efectua o depuramento de problemas nos modulos existentes.
Posto isto, decidiu-se substituir o HUB Galaxy por invocacoes directas dentro do gestor de dialogo e
via protocolo RMI (Invocacoes de Metodos Remotas do ingles Remote Method Invocation1) entre “macro”
modulos (gestor de entradas e saıdas, gestor de dialogo e gestor de servicos).
Os modulos do gestor de dialogo sao escritos na linguagem Java bem como os modulos do gestor
de servicos e do gestor de entradas e saıdas (a excepcao do reconhecer e do sintetizador). Assim, os
modulos internos do gestor de dialogo utilizam invocacao directa com recurso ao padrao de desenho
Singleton (Gamma et al., 1994; Freeman et al., 2004) (p127; p177). A comunicacao entre macro modulos
1http://java.sun.com/javase/technologies/core/basic/ rmi/index.jsp
30
1 <XML>2 <INTERPRETATIONS>3 <INTERPRETATION>4 <property type=’type’>AFFIRM</property>5 <property type=’who’>USER</property>6 <property type=’What’>7 <item>8 <name>fechar</name>9 <domain>domotica</domain>10 <device></device>11 <maintype>action</maintype>12 <modetype>word</modetype>13 <spectype>action</spectype>14 <value>0.0</value>15 <comp>equal</comp>16 </item>17 </property>18 <psas>19 <psa recognitionscore=’0.3’ answerscore=’1.0’ domain =’domotica’>20 <classification_rules>21 <rule deviceid=’’ prob=’0.3’>22 <rule deviceid=’2’ prob=’0.3’>23 <and deviceid=’’ prob=’0.3’>24 <slot_value actualvalue=’’ domain=’domotica’25 maintype=’’ modetype=’word’ prob=’0.3’26 required=’false’ slotkey=’2’ spectype=’target’>27 estores28 </slot_value>29 </and>30 </rule>(...)701 </classification_rules>702 <validation_rules></validation_rules>703 </psa>704 </psas>705 </INTERPRETATION>706 </INTERPRETATIONS>707</XML>
Figura 3.1: Exemplo de uma estrutura trocada entre modulos do gestor de dialogo.
utiliza RMI para agilizar o processo de instalacao e para garantir o encapsulamento dos modulos e a
definicao das interfaces.
A substituicao do HUB Galaxy, nao invalida totalmente os objectivos anteriores, pelo que ainda e
possıvel a um modulo escrito noutra linguagem de programacao ligar-se ao sistema atraves do protocolo
RMI (que utiliza ligacoes TCP/IP e serializacao de objectos 2). E possıvel ainda recorrer ao protocolo
SOAP (Protocolo de Acesso Simples a Objectos do ingles Simple Object Acess Protocol3) e as interfaces do
sistema, a semelhanca do que foi feito para a integracao da cadeia de processamento morfossintactico
XIP (ver seccao 3.8).
2http://java.sun.com/developer/technicalArticles/Pro gramming/serialization/3http://www.w3.org/TR/soap/
31
3.2 Gestor de eventosA arquitectura do gestor de dialogo inspira-se na arquitectura do TRIPS. No entanto, nao foi implemen-
tado o modulo de gestao de eventos que o sistema TRIPS evidencia na sua arquitectura.
Uma das caracterısticas do sistema frequentemente apontada, e a passividade com que desenvolve
os dialogos, dado que apenas reage ao que o utilizador lhe transmite, nao tendo capacidade de “sentir”
o que se passa a sua volta.
O gestor de eventos permite nao so dotar o sistema de percepcao do meio envolvente, atraves
de sensores que geram eventos quando se verificam alteracoes do mundo, como tambem efectuar o
tratamento de eventos assıncronos provenientes de aplicacoes externas.
Tratando a informacao proveniente de sensores e/ou aplicacoes externas, o sistema pode tornar-
-se mais pro-activo nos seus dialogos com o utilizador, permitindo a implementacao de domınios mais
complexos e “inteligentes”.
Por exemplo, se o sistema Ambrosio dispusesse de um gestor de eventos e de alguns sensores
simples, era possıvel ter eventos que sinalizavam a deteccao de fala o que levaria a, por exemplo, um
cumprimento do sistema ao utilizador que se aproximasse. Com recurso a um sensor de temperatura
o Ambrosio poderia sugerir ao utilizador que esta muito frio/calor e perguntar se gostaria aumen-
tar/diminuir a temperatura da divisao em causa, ou ate mesmo alertar o utilizador para aquela luz que
ficou acesa quando alguem fosse a sair.
Para alem da pro-actividade do sistema, o gestor de eventos veio colmatar algumas das dificuldades
de comunicacao assıncrona entre os diversos modulos. Inicialmente o gestor de entradas e saıdas nao
providenciava muita da informacao gerada pelo reconhecedor e pelo sintetizador, como eventos de
inıcio e fim de conversacao com o reconhecedor ou do sintetizador. Esta informacao junto do gestor
de dialogo que conhece o domınio e o contexto da conversacao ajuda a prevenir e recuperar erros. No
entanto, esta informacao e gerada assincronamente.
Foi decidido que o gestor de eventos deveria ser gerido pelo gestor de entradas e saıdas por este ser
responsavel por gerir a informacao externa que entra e sai do sistema de dialogo. Contudo, e como se
percebe pela descricao do sistema (capıtulo 2), o gestor de servicos tambem gere a informacao necessaria
ao sistema de dialogo que descreve o domınio em causa. Inicialmente o sistema foi concebido para que
esta informacao fosse descrita estaticamente num formato XML. No entanto, desde cedo se percebeu que
para domınios mais complexos, este tipo de informacao nao pode ser totalmente estatica. Por exemplo,
no sistema de assistencia pessoal LISA (descrito na seccao 4.1), e a aplicacao externa que providencia
dinamicamente, em tempo de execucao, informacao necessaria ao sistema de dialogo, que complementa
a informacao declarada estaticamente.
32
Tendo em conta que tambem a informacao de domınio varia ao longo do tempo, e que e fulcral
agilizar as fontes de informacao de domınio, foi criado um modulo responsavel por tratar dos eventos
gerados (do ingles event handler) pelo gestor de eventos no gestor de dialogo. Este modulo foi imple-
mentado recorrendo ao padrao de desenho Simple Factory (Gamma et al., 1994; Freeman et al., 2004)
(p87; p156), que aquando a inicializacao do domınio pede a uma fabrica uma instancia desse modulo
especıfica para aquele domınio, e que programaticamente descreve o comportamento a desenvolver por
parte do sistema de dialogo perante um determinado evento.
Com o desenvolvimento do gestor de eventos, conseguiu-se dotar o sistema de sensores que “escu-
tam” o mundo e emitem eventos para o mesmo que por sua vez os propaga para todos os modulos que
os subscreveram, tendo o modulo responsavel por tratar os eventos no gestor de dialogo a responsabi-
lidade de indicar como e que o sistema deve actuar.3.3 Identi� a� ~ao/re onhe imento de obje tos e lassi-� a� ~ao de a tos de fala no dis ursoA identificacao de objectos era feita de uma forma pouco aprofundada, identificando (a excepcao de pa-
lavras como ’e’, ’as’, ’das’, entre outras) todas as palavras como sendo um objecto. O estabelecimento de
relacoes entre palavras, e efectuado apenas para casos muito especıficos dos domınios implementados
(Domotica e Bilhetica). Isto deve-se ao facto de nao ser efectuado qualquer processamento sintactico e
semantico do texto de entrada, tornando a tarefa do gestor de interpretacoes de criar e desambiguar uma
interpretacao complexa. Por outro lado, o processo de identificacao de objectos, no gestor de dialogo, e
independente do processo de reconhecimento de objectos. Isto leva a uma perda de informacao entre
estes dois processos que sao fortemente dependentes, pois, quando os objectos sao reconhecidos, o sis-
tema ja perdeu a nocao de ordem na frase dos mesmos, necessaria para efectuar um reconhecimento de
objectos correcto e minimamente eficiente.
Por exemplo, um termo composto como ”mensagem de texto”dava lugar a dois objectos, ”mensa-
gem”e ”texto”(isto porque o ”de”seria removido), perdendo a nocao de termo composto e ate a relacao
que existem entre ”mensagem”que e de ”texto”e nao noutro formato qualquer.
O reconhecimento de objectos e feito recorrendo a regras especıficas de cada dispositivo. Cada
dispositivo quando se liga fornece as suas regras ao sistema, que sao utilizadas para identificar se de-
terminados objectos pertencem a um determinado campo instanciado num determinado servico dispo-
nibilizado por esse dispositivo. Estas regras sao pouco expressivas o que nao permite, tal como ja foi
referido, o reconhecimento de objecto compostos e/ou complexos como por exemplo ”mensagem de
texto”.
O problema da identificacao e reconhecimento do objecto “mensagem de texto”, antes destas
33
alteracoes, seria resolvido adicionando uma linha de codigo ao modulo de identificacao de objectos,
que indicaria a composicao destes tres termos. Esta era a unica forma de associar diversos objectos num
so, estando esta linha de codigo no mesmo local em que e feita a separacao da frase em palavras, onde
sao criados os objectos e ate mesmo onde e identificado o tipo de acto de discurso presente na frase.
Existem actualmente diversas linhas de codigo como a sugerida anteriormente, codigo que e depen-
dente do domınio e que se encontra num modulo generico do gestor de dialogo. Como se percebe, isto
dificulta a implementacao de novos sistemas e a manutencao de um sistema de dialogo independente
do domınio, dado que este comportamento dependente do domınio vai ser executado noutro qualquer
domınio, introduzindo alteracoes inesperadas na identificacao de objectos.
Para alem dos problemas apontados, nao e efectuada qualquer desnormalizacao de numeros ou
dıgitos, que e necessaria para, por exemplo, a implementacao das aplicacoes de banca e bolsa (des-
critas na seccao 4.2) ou em aplicacoes que manipulem numeros de telefone, como a assistente pessoal
electronica LISA (descrita na seccao 4.1). Para alem da desnormalizacao de numeros e necessario que
o sistema efectue a desnormalizacao de expressoes temporais (por exemplo “dia cinco de marco”), ex-
pressoes espaciais (por exemplo “para a minha casa da rua ...”), ou qualquer tipo de entidades menci-
onadas (por exemplo “o Primeiro Ministro”), entre outros tipos de objectos que sao necessarios para se
conseguir implementar eficazmente domınios mais complexos sobre esta plataforma.
Posto isto, e necessario desenvolver ao nıvel do processador de linguagem (do ingles parser), um
mecanismo que seja capaz nao so de identificar correctamente os tipos de objectos mais comuns (alguns
deles ja referidos), mas tambem de relacionar estes objectos entre si. Isto permite que a interpretacao
deixe de estar ao nıvel do emparelhamento de palavras e passe para um nıvel pre-semantico onde ja e
possıvel interpretar outro tipo de frases que nao apenas frases de comando. A identificacao e o reco-
nhecimento de objectos, processos fortemente dependentes, tem que ser realizados num so passo num
mesmo modulo, para que a informacao gerada por cada um dos processos seja iterativamente utilizada
para melhorar a identificacao e o reconhecimento dos proximos objectos da frase.
Devido a estas limitacoes ao nıvel da identificacao e reconhecimento de objectos, a identificacao de
actos de fala no discurso encontra-se numa fase muito inicial (existe apenas a estruturacao de algumas
classes), nao sendo utilizada efectivamente pelo gestor de interpretacoes.
Uma classificacao correcta dos actos de fala contidos numa frase proferida pelo utilizador, aumen-
taria a qualidade das interpretacoes extraıdas e a eficiencia do gestor de interpretacoes. Por exemplo,
actualmente, se um utilizador do sistema colocar uma questao ao sistema, este nao tem capacidade de
perceber que se lhe esta a colocar uma questao e vai interpretar o que foi proferido pelo utilizador como
sendo uma afirmacao.
Para introduzir actos de fala no sistema, representacao ao nıvel da semantica, e necessario ter um
34
processador de linguagem ao nıvel da sintaxe da frase. Os actos de fala incluem a identificacao de um
conjunto de propriedades como o sujeito e o predicado da frase, que com uma manipulacao dos objectos
da frase ao nıvel do emparelhamento de palavras, e difıcil de extrair.
A inclusao da identificacao e manipulacao de actos de fala, nao sendo efectivamente um problema,
e um desenvolvimento necessario ao gestor de dialogo, porque permite a interpretacao de dialogos mais
naturais e intuitivos. Devido a esta dependencia entre a identificacao de actos de fala no discurso e a
identificacao e reconhecimento de objectos, os desenvolvimentos nesta area foram reduzidos, estando o
trabalho realizado descrito como trabalho futuro na seccao 5.2.2.
Foram no entanto, feitos diversos desenvolvimentos para aumentar a informacao produzida pelo
sistema ao nıvel da identificacao e reconhecimento de objectos. Numa primeira fase, desenvolveu-se
um gestor de processadores de linguagem (descrito na seccao 4.3.1), o que permite separar a informacao
dependente do domınio da informacao independente do domınio. Este gestor de processadores de
linguagem permite tambem categorizar a informacao identificada, por forma a auxiliar o modulo de
reconhecimento de objectos. Foram tambem desenvolvidos diversos processadores de linguagem para
resolver os principais problemas (desnormalizacao de numeros e expressoes temporais) ao nıvel da
desnormalizacao de objectos, levantadas pelos sistemas implementados.
O encapsulamento criado ao nıvel dos processadores de linguagem permite tambem a integracao
da cadeia de processamento morfossintactico XIP, estando a sua descricao e respectiva integracao ao
nıvel dos processadores de linguagem do gestor de dialogo descrita na seccao 3.8.3.4 Interfa es do sistemaDevido a existencia do HUB Galaxy que providenciava a camada de comunicacao entre os diversos
modulos, e a existencia de diversas estruturas XML que eram trocadas entre os diversos modulos do
sistema, o sistema de dialogo e em particular o gestor de dialogo, nao disponha de uma interface defi-
nida. Esta, tal como foi referido, era mantida atraves de algumas estruturas XML nao documentadas,
aumentando a complexidade de integracao do sistema com aplicacoes externas. Por outro lado, o sis-
tema estava vulneravel a alteracao das interfaces exteriores, que por estarem bem definidas, impunham
alteracoes a interface do sistema de dialogo e em particular ao gestor de dialogo, com todos os proble-
mas associados a estas constantes alteracoes de interface.
Foi por isso desenvolvida uma interface para o gestor de dialogo implementada recorrendo ao
padrao de desenho Facade (Gamma et al., 1994; Freeman et al., 2004) (p185; p264), que uniformiza e
encapsula os acessos aos diferentes modulos do gestor de dialogo. Foi tambem criado para cada modulo
do gestor de dialogo um Singleton (Gamma et al., 1994; Freeman et al., 2004) (p127; p177), que garante
a existencia de apenas uma instancia de cada modulo do gestor do dialogo. Os acessos feitos a cada
35
modulo sao controlados por um Proxy (Virtual) (Gamma et al., 1994; Freeman et al., 2004) (p207; p462)
que gere os acessos concorrentes, a informacao associada a sessao estabelecida e efectua registos de
acesso, estando assim bem definida a interface de acesso e estruturas trocadas, de cada modulo interno
do sistema.
Isto possibilitou a centralizacao e o controlo da comunicacao (interna e externa) do gestor de
dialogo. Esta centralizacao permitiu implementar algumas garantias de sessao, efectuar um registo
de entradas e saıdas bem como de comunicacao entre os modulos, e acima de tudo definiu a interface
do gestor de dialogo com a qual um determinado gestor de entradas e saıdas e/ou uma determinada
aplicacao externa deve comunicar. Inicialmente para reduzir o custo de adaptacao a esta nova interface,
foi criado um adaptador para o gestor de entradas e saıdas que mapeia a informacao por este forne-
cida na interface do gestor de dialogo. Mais tarde, quando se desenvolveu um novo gestor de entradas
e saıdas (descrito na seccao 4.2.2) esta interface comecou a ser utilizada directamente, nao existindo a
necessidade de utilizar qualquer tipo de adaptador.
A quase inexistente definicao de interface entre o gestor de entradas e saıdas e o gestor de dialogo
fazia com que nao fosse possıvel utilizar um conjunto de parametros, como por exemplo interrupcoes
(do ingles barge-in), gramaticas dinamicas, entre outros. Estes parametros correctamente geridos com a
informacao existente ao nıvel do contexto do dialogo, poderiam aumentar bastante o desempenho do
reconhecedor, a naturalidade do sintetizador, e a eficiencia do sistema em geral.
Por exemplo, para se desenvolver uma aplicacao para consulta de uma agenda telefonica por
voz, era necessario recolher uma lista exaustiva de nomes (que nunca incluiria todos), para gerar uma
gramatica estatica para o reconhecedor.
Com a definicao desta nova interface e possıvel o gestor de dialogo utilizar um conjunto de potenci-
alidades (interrupcoes, troca de modelos de linguagem, entre outras), que por nao existir uma interface
bem definida nao estavam acessıveis. Parte desta interface e providenciada recorrendo ao gestor de
eventos (descrito na seccao 3.2).
Os mecanismos disponibilizados atraves desta nova interface, permitiram nao so aumentar a
eficiencia do sistema mas tambem resolver um conjunto de problemas (nomeadamente ao nıvel da
integracao de um novo gestor de entradas e saıdas descrito na seccao 4.2.2) na implementacao do sis-
tema de assistencia pessoal LISA e nos sistemas de banca e bolsa telefonica, descritos no capıtulo 4.3.5 Apoio ao desenvolvimentoO sucesso de uma plataforma que se pretende de facil integracao, esta intimamente ligado ao quao
simples e a sua interface, quao adaptada esta a sua interface ao problema em causa e a facilidade com
que se desenvolve o sistema com recurso a plataforma, documentacao e ferramentas disponibilizadas.
36
O sistema de dialogo tinha limitacoes a este nıvel. Exemplo disso e a especificacao de enquadra-
mentos que tinha um defice de expressividade, nao sendo possıvel, por exemplo, expressar uma ordem
sobre a qual se devem tentar preencher os diversos campos do enquadramento, ou indicar que um de-
terminado campo, devido a sua elevada importancia no contexto em questao, precisa de ser confirmado
com o utilizador antes de se executar o servico.
Caso se quisesse implementar, por exemplo, um servico de envio de mensagens por voz, no qual o
utilizador tenha que fornecer o contacto e o tipo de mensagem a enviar (SMS, MMS, Email), e de todo
conveniente que o sistema peca primeiramente o contacto e o tipo de mensagem antes de perguntar
qual a mensagem a enviar. Isto para, caso o utilizador nao possua o contacto do destino fornecido para
enviar o tipo de mensagem indicado (por exemplo, na agenda apenas se encontra um contacto de email
e o utilizador esta a tentar enviar um SMS), o sistema alertar o utilizador antes de este ditar a mensagem
para o sistema, com o objectivo de o utilizador detectar o problema o mais cedo possıvel, tornando o
dialogo e a execucao do servico mais eficientes.
E tambem desejavel, por exemplo, que o sistema possa confirmar explicitamente o contacto para o
qual se esta a enviar a mensagem, no caso de ser um contacto importante, caracterıstica que o sistema
tambem nao disponibilizava e que deveria ser parametrizavel no enquadramento.
Apos o desenvolvimento e estabilizacao da interface de integracao do gestor de dialogo com o
gestor de entradas e saıdas, era necessario desenvolver a interface de desenvolvimento do gestor de
dialogo, tornando-a mais dinamica e parametrizavel. Essa parametrizacao tem que ser simples, estar
bem documentada e adequar-se ao problema em causa, sendo simultaneamente versatil para permitir
a utilizacao simultanea de diversas potencialidades ao nıvel do dialogo. So assim e possıvel utilizar o
sistema de dialogo num ambito mais alargado, implementando domınios mais complexos e melhorando
os domınios ja implementados.
Foram por isso utilizados os sistemas de assistencia pessoal LISA, banca e bolsa telefonica, bem
como o sistema Ambrosio, como casos de estudo para ampliar as potencialidades da interface de desen-
volvimento de novas instancias do sistema de dialogo.
Este trabalho passou por diversos desenvolvimentos ao nıvel da definicao de servicos e enquadra-
mentos (alguns deles ja referidos) que permitem modelar novos tipos de domınios e dialogos.
Estes desenvolvimentos incluem o gestor de eventos previamente descrito em 3.2, os desenvolvi-
mentos ao nıvel da identificacao e reconhecimentos de objectos descritos na seccao 3.3 e alguns dos
desenvolvimentos realizados no ambito da concepcao dos sistemas de assistencia pessoal LISA, banca e
bolsa telefonica descritos mais a frente na seccao 4.3.
Para alem das alteracoes referidas, foi/foram tambem:
37
• Exportada parte da interface definida em ficheiros XML (definicao de domınios e servicos) para
codigo (descrita na seccao 4.3), tornando-a dinamicamente programavel por forma a que seja
possıvel ao sistema adaptar-se dinamicamente a algumas alteracoes do mundo;
• Criada uma biblioteca de desenvolvimento de novos dispositivos;
• Documentados os aspectos ligados a criacao de novas instancias, acompanhados de diversos
exemplos, formalizando o manual da API do sistema de dialogo.
Em particular, a criacao de uma biblioteca de desenvolvimento de novos dispositivos para o sis-
tema de dialogo, motivou o desenvolvimento de um conjunto de correccoes na arquitectura do gestor
de servicos (descritas na seccao 3.6). Foi, assim, expandido o protocolo de comunicacao para permitir a
existencia de dispositivos remotos, que nao se encontram a correr no mesmo processo que o sistema de
dialogo. Isto possibilita a integracao com aplicacoes externas que requerem caracterısticas especıficas
de hardware, e que providenciam servicos como a consulta a uma base de dados de acessos a um deter-
minado edifıcio, ou ate mesmo aplicacoes que ja se encontrem a correr e sobre a qual se quer adicionar
uma interface de voz, sem que isto comprometa o normal funcionamento ou implique a reestruturacao
da aplicacao.
Como complemento a este conjunto de desenvolvimentos, foram definidos, para possibilitar a
distribuicao do sistema, um conjunto de procedimentos que simplificam a instalacao do sistema e pro-
tegem a propriedade intelectual detida pelo INESC-ID, que se encontram descritos na seccao 3.7.
Foi possıvel, com este conjunto de medidas aproximar o sistema de dialogo e em particular o gestor
de dialogo de um produto comercial, que pode ser distribuıdo e integrado.3.6 Redesenho do gestor de servi� osA expansao da interface de desenvolvimento do gestor de dialogo obrigou a uma reestruturacao do
gestor de servicos, dado que este e responsavel por gerir a parte dependente do domınio do gestor de
dialogo.
O gestor de servicos, sendo o modulo mais antigo do gestor de dialogo e que lida com informacao
mais propıcia a alteracoes (definicao da informacao de domınio), tinha sofrido diversas adaptacoes para
que fosse possıvel integra-lo com sistemas previamente desenvolvidos.
Devido as diversas adaptacoes, existiam incorreccoes ao nıvel do desenho, nomeadamente uma
partilha da interface por parte do gestor de dialogo e dos dispositivos que se registam no sistema, utili-
zando a mesma interface para objectivos funcionalmente diferentes. Isto constituıa uma violacao grave
38
da arquitectura, dado que um dispositivo tinha acesso a interface do gestor de servicos, podendo o pro-
gramador mais inexperiente utilizar a parte dessa interface reservada ao gestor de dialogo, causando
erros inesperados no sistema. Por exemplo atraves do dispositivo e possıvel executar servicos noutros
dispositivos ligados ao sistema, alterar o estado desses dispositivos, e fazer com que o gestor de dialogo
execute um servico que nao esta disponıvel para o estado em causa, levando a comportamentos inespe-
rados nesses dispositivos.
Foi por isso necessario reestruturar o gestor de servicos tendo em vista as alteracoes que se preten-
diam efectuar, nomeadamente o encapsulamento de uma biblioteca para o desenvolvimento de novos
dispositivos para o sistema de dialogo e a instalacao remota de novos dispositivos.
O codigo do gestor de servicos, tinha demasiadas dependencias que dificultavam a modularizacao
do codigo e consequente a agilizacao do processo de desenvolvimento e instalacao de novos dispo-
sitivos. Foram removidas as dependencias entre os diversos objectos utilizados e os modulos que os
manipulam, com o objectivo de modularizar o codigo, isolando e partilhando os objectos manipulados.
Com isto foi possıvel criar uma biblioteca com a implementacao do protocolo de comunicacao com
o gestor de servicos e os objectos partilhados entre o gestor de dialogo e o gestor de servicos, facilitando
o desenvolvimento e a instalacao de novos dispositivos.
Figura 3.2: Desenho actual do gestor de servicos.
Os principais modulos e a interface foram reorganizados. O servidor galaxy do gestor de servicos
foi renomeado assumindo o nome do macro modulo gestor de servicos (que se decidiu chamar classe do
gestor de servicos para a distinguir do macro modulo do sistema de dialogo). A renomeacao deveu-se a
separacao da interface, actualmente a classe do gestor de servicos apenas gere a interface com o gestor
de dialogo. A interface com o gestor de servicos e agora gerida pelo gestor de dispositivos que para
alem de guardar e providenciar a informacao acerca destes tambem gere a interface de registo e acesso
ao gestor de servicos por parte dos dispositivos. Foi ainda colocado o gestor de acessos no meio destes
dois modulos, controlando nao so o acesso de um utilizador aos diversos dispositivos mas tambem
39
o registo de um determinado dispositivo no sistema, prevenindo que um determinado dispositivo de
um qualquer domınio se registe num sistema semanticamente diferente e que nao devia providenciar
servicos deste genero.3.7 Distribui� ~ao do gestor de di�alogoA melhoria do processo de distribuicao do gestor de dialogo foi uma das necessidades inerentes aos
objectivos iniciais de utilizar o sistema de dialogo como parte integrante de produtos comerciais, influ-
enciou bastante algumas decisoes descritas anteriormente (nomeadamente a remocao do HUB Galaxy).
Esta influencia nao so se reflectiu ao nıvel das decisoes tomadas durante o desenvolvimento do sis-
tema de dialogo, mas tambem o desenvolvimento de alguns procedimentos de simplificacao e proteccao
da solucao desenvolvida quando esta se encontra em ambientes de integracao do lado do cliente.
Sistema de ficheiros e configuracao
Uma das principais crıticas que os desenvolvedores do sistema apontavam era a organizacao do sistema
de ficheiros.
Nao havia uma modularizacao do sistema de ficheiros do sistema. O codigo do sistema encontrava-
-se distribuıdo por um projecto apenas onde todos os programadores trabalhavam em simultaneo. A
unica particao de codigo que existia era ao nıvel dos pacotes (do ingles packages da linguagem Java). Por
outro lado, o processo de alteracao de configuracoes era complexo dado que os ficheiros de configuracao
se encontravam na mesma pasta. Estava por isso dificultada a tarefa de gestao e configuracao de diver-
sos sistemas suportados em simultaneo pela plataforma de sistemas de dialogo.
Para colmatar esta dificuldade, separou-se o codigo do sistema de dialogo em projectos diversos
independentes, removendo as dependencias entre estes. Criou-se um projecto referente ao codigo do
gestor de dialogo e gestor de servicos, outro com o gestor de entradas e saıdas, um outro com a interface
grafica e um com o gestor de eventos. A instalacao do sistema e feita com recurso a ficheiros JAR4,
existindo um ficheiro por projecto. Esta abordagem facilita a gestao de versoes e a actualizacao de
modulos. Por exemplo, se fosse desenvolvida uma nova interface grafica para o sistema de dialogo,
basta trocar o ficheiro “GUI.jar” actual pelo mais recente e desde que a interface de comunicacao com o
sistema de dialogo da interface grafica se mantenha, este ira ter o funcionamento normal.
Foi possıvel assim modularizar o codigo, agilizando e simplificando o processo de desenvolvimento
e instalacao do sistema de dialogo.
4Java ARchive - http://java.sun.com/javase/6/docs/technotes/guides/ jar/index.html
40
Figura 3.3: Arvore de directorios do sistema de dialogo.
No entanto, isto nao era suficiente, era necessario por vezes, numa mesma pasta, possuir dois siste-
mas (sistema de banca e sistema de bolsa telefonica, por exemplo) com configuracoes diferentes em que
cada um deles poderia ter varios domınios em simultaneo a correr. Foi, assim, definido o conceito de
instancia do sistema de dialogo, no modelo de domınio. Uma instancia tem um conjunto de domınios e
de dispositivos associados, uma configuracao e um conjunto de bibliotecas utilizadas independente de
todas as restantes.
Para iniciar o sistema basta passar como primeiro parametro o nome da instancia, e o sistema car-
rega o ficheiro de configuracao que se encontra em config/[Nome da inst ancia] , instancia os
macro modulos com a respectiva configuracao e carrega os ficheiros Jar que se encontram na pasta
domains/[Nome da inst ancia] .
Qualquer dispositivo remoto podera ligar-se ao sistema, atraves do protocolo de comunicacao en-
capsulado na biblioteca de desenvolvimento de dispositivos, bastando para isso que declare pertencer
a instancia que se encontra a correr.
Proteccao da propriedade intelectual
Com a reorganizacao do sistema de ficheiros, tornou-se mais simples desenvolver novas instancias bem
como configura-las e mante-las. Contudo, ainda residia o problema da proteccao da propriedade inte-
41
lectual.
Em Java, o codigo desenvolvido e compilado para um formato intermedio denominado Java Byte-
code5. Este formato e posteriormente interpretado pela maquina virtual Java, ou caso um determinado
troco de codigo corra muitas vezes este e compilado para codigo maquina em tempo de execucao pelo
compilador JIT (Just In Time compiler) da maquina virtual.
Posto isto, qualquer integrador da tecnologia tinha acesso ao formato intermedio atraves dos fi-
cheiros Jar, que revelam tambem a estrutura de pacotes bem como o nome das classes e dos pacotes.
Existem diversas aplicacoes que permitem fazer o processo inverso ao do compilador de Java e obter
codigo Java a partir do Java Bytecode. Torna-se por isso possıvel a uma qualquer entidade, com mais
ou menos esforco, perceber a logica da aplicacao e apropriar-se da propriedade intelectual.
Para que fosse possıvel distribuir o sistema de dialogo, foi necessario utilizar uma tecnica conhecida
por Ofuscacao. A Ofuscacao parte do pressuposto que, sem alterar a maquina virtual Java, e impossıvel
esconder o Java Bytecode. O objectivo da ofuscacao e (dada a limitacao anterior) tornar o codigo o
mais ilegıvel possıvel, alterando o nome das classes, pacotes, metodos e variaveis, tornando a tarefa de
compreender o codigo bastante mais complexa.3.8 Integra� ~ao da adeia de pro essamente morfos-sint�ati o XIPA integracao da cadeia de processamento morfossintactico XIP e a evolucao natural dos processadores
de linguagem existentes actualmente (ver seccao 4.3.1). Pretende-se complementar um conjunto de
regras gramaticais da lıngua portuguesa, com um conjunto de regras dependentes de cada domınio.
Descricao da cadeia XIP
A cadeia XIP (figura 3.4) segue a arquitectura pipes and filters (Clements et al., 2002; Bass et al., 2003),
utilizando varios modulos que vao desde a segmentacao de um determinado documento ate a analise
sintactica de uma frase.
A sua arquitectura e composta pelos seguintes modulos:
• Segmentador - Efectua a segmentacao em palavras. Este modulo e tambem responsavel por
identificar abreviaturas (por exemplo “V.Exa”, ou “Dr.”), numeros ordinais (por exemplo “12o”),
enderecos de email, entre outros;
5http://www.ibm.com/developerworks/ibm/library/it-ha ggar_bytecode/
42
• Palavroso (Medeiros, 1995) - efectua a etiquetacao morfossintactica (por exemplo “cao” e um nome
comum “Nc”);
• Divisao em frase - Divide o documento em frases;
• RuDriCo (Pardal & Mamede, 2004) - efectua manipulacoes morfossintacticas (por exemplo
descontraccao de palavras, “nas” em “em” e “as”), identificacao de unidades compostas (por
exemplo “Mosteiro do Jeronimos”), bem como diversas correccoes a saıda do Palavroso;
• Marv (Ribeiro et al., 2003) - desambigua as etiquetas morfossintacticas atribuıdas, utilizando pro-
cessamento estatıstico baseado em corpus;
• Xeror Incremental Parser (XIP) (Ait-Mokhtar et al., 2001) - Constroi blocos (do ingles chunks, por
exemplo sintagmas nominais) com base em regras gramaticais e identifica as dependencias exis-
tentes entre os mesmos.
O formato trocado entre os diversos modulos e XML. A interface da cadeia XIP, encontra-se progra-
mada na linguagem PERL.
Todos os modulos, a excepcao do modulo XIP que foi desenvolvido pela Xerox, foram desenvolvi-
dos no L2F, detendo este a propriedade intelectual da solucao desenvolvida.
Figura 3.4: Arquitectura da cadeia XIP
O modulo RuDriCo e o modulo XIP possuem uma linguagem propria para a definicao de regras,
mais expressiva que as regras de identificacao e reconhecimento de objectos utilizadas no gestor de
dialogo, que pode ser utilizada para especificar o conhecimento dependente do domınio.
A utilizacao da cadeia XIP permite a extraccao de informacao ao nıvel pre-semantico, o que possi-
bilita o desenvolvimento do gestor de interpretacoes, nomeadamente na introducao de identificacao
de actos discurso (ver seccao 5.2.2) e consequentemente na construcao de interpretacoes com mais
informacao, permitindo uma comunicacao mais natural com a plataforma de dialogo.
Nos ultimos resultados divulgados, a cadeia leva cerca de 1 a 2 segundos a processar uma frase, o
que ainda e consideravel ao nıvel do gestor de dialogo. Contudo, existem diversas tecnicas que se pode-
43
riam desenvolver para diminuir o tempo de processamento, nomeadamente a introducao de memoria
(do ingles cache) ao nıvel do gestor de dialogo.
<XIPRESULT math="0"><LUNIT language="Portuguese">
<NODE num="2" tag="TOP" start="0" end="2"><FEATURE attribute="CAT" value="0" /><NODE num="0" tag="INTERJ" start="0" end="2">
<FEATURE attribute="MAJ" value="+" /><FEATURE attribute="INTERJ" value="+" /><FEATURE attribute="HMMSELECTION" value="+" /><FEATURE attribute="END" value="+" /><FEATURE attribute="START" value="+" /><FEATURE attribute="LAST" value="+" /><FEATURE attribute="FIRST" value="+" /><TOKEN pos="INTERJ" start="0" end="2">
Ola<READING lemma="ola" pos="INTERJ" />
</TOKEN></NODE>
</NODE></LUNIT>
</XIPRESULT>
Figura 3.5: Exemplo do resultado do processamento da cadeia XIP.
Solucoes possıveis
Existem diversos modelos para a integracao da cadeia no gestor de dialogo.
Um aspecto importante a ter em conta nesta integracao, advem do modulo XIP nao ser propriedade
intelectual do L2F (mas sim a gramatica para o portugues desenvolvida no laboratorio), nao podendo
por isso ser utilizado livremente em projectos comerciais.
Uma das solucoes pode passar, por se utilizar a cadeia em modelo de servico. Para isso e necessario
recolher um conjunto de interaccoes possıveis com o sistema, processar tudo previamente com a cadeia
XIP e guardar os resultados numa base de dados que e consultada cada vez que se processa uma en-
trada no sistema. Se nao existir um acerto na base de dados para uma determinada frase, procura-se
o conjunto de blocos que tenham sido originados pela frase mais proxima. Esta solucao, para alem de
evitar o licenciamento do software, nao sofre do atraso introduzido por este novo modulo. Contudo, se
for fornecido ao sistema uma frase que nao esteja em base de dados o resultado pode ficar aquem das
expectativas.
A integracao efectiva da cadeia tambem e uma possıvel solucao, tendo sido desenvolvido algum tra-
balho nesse sentido. Foi criada uma interface SOAP com uma definicao WSDL (Linguagem de Descricao
de Servicos Web do ingles Web Services Description Language) para que se possa integrar de modo sim-
ples a cadeia (que dispoem de uma interface em PERL) no sistema de dialogo, e foi desenvolvido um
44
processador de linguagem utilizando a metodologia SAX6 (API simples para processamento de XML,
do ingles Simple API for XML) para processar a saıda em XML enviada pela cadeia.
Uma alternativa a utilizacao da cadeia XIP consiste em utilizar as regras definidas na gramatica
para o reconhecedor (gramaticas que utilizam o standard SRGS7), para identificacao e reconhecimento
de objectos. Isto e possıvel dado que na especificacao da Java Speech API 2.08 (parte integrante do novo
gestor de entradas e saıdas, ver figura 4.6), esta previsto que esta deva providenciar informacao acerca
da regra utilizada para reconhecer cada palavra. Esta informacao nao e mais do que o que esta a ser
feito actualmente no sistema de dialogo. Contudo, a linguagem SRGS e mais expressiva que as regras
definidas no sistema de dialogo (que foram inspiradas no padrao), evitando assim a definicao dupli-
cada do mesmo tipo de informacao bem como o processamento desta informacao e incrementando a
expressividade da definicao destas regras sem ter que recorrer a cadeia XIP. Ao nıvel do sistema de
dialogo e necessario apenas parametrizar a configuracao dos processadores de linguagem de entrada
(com recurso ao novo gestor de processadores de linguagem descrito na seccao 4.3.1), para correr um
processador de linguagem que processasse a informacao enviada pela Java Speech API (recorrendo aos
desenvolvimentos feitos na area de identificacao e reconhecimento de objectos ao nıvel do processador
de linguagem descritos na seccao 4.3.6) caso o sistema a desenvolver nao justifique a inclusao da cadeia
XIP, se se considerar que esta nao incrementa a qualidade do sistema. Caso esse incremento fosse sig-
nificativo, bastaria configurar os processadores de linguagem para processarem a informacao enviada
pela cadeia XIP.
Para evitar a utilizacao do modulo XIP (dado este ser propriedade da Xerox), poderia-se tambem
equacionar a utilizacao da cadeia sem este, tendo em conta o respectivo decremento da qualidade da
informacao produzida pela cadeia. E, no entanto, necessario avaliar efectivamente qual o peso do
modulo XIP no conjunto dos modulos que compoem a cadeia e se a informacao produzia pela cadeia
sem este modulo, produz resultados aceitaveis do ponto de vista do gestor de dialogo.
Outra solucao pode passar pela integracao da ferramenta ShRep (Moura Rodrigues, 2007) que subs-
titui os scripts de invocacao das diversas ferramentas na cadeia XIP, por uma aplicacao que para alem
de invocar as diversas ferramentas, guarda a informacao devolvida por forma a poder ser consultada
mais tarde. Esta ferramenta tem a vantagem de providenciar uma JMI (Java Method Interface), que
permite a integracao simples das diversas ferramentas, e que permitiria em alguns casos correr apenas
as ferramentas desenvolvidas no L2F (com a respectiva penalizacao ao nıvel da informacao extraıda e
produzida). No entanto, esta ferramenta e ela propria uma area de investigacao activa, com alunos de
mestrado a trabalharem sobre ela, estando ainda incompleta.
6http://www.saxproject.org/7http://www.w3.org/TR/speech-grammar/8http://jcp.org/en/jsr/detail?id=113
45
E necessario avaliar as solucoes desenvolvidas, para confirmar qual e a mais eficiente e a que
situacoes e que cada uma se adequa mais.
Aspectos a considerar
Na integracao da cadeia de processamento XIP, ha que ter em conta que esta foi desenvolvida utilizando
como exemplos de teste a lıngua portuguesa escrita (maioritariamente corpus jornalıstico). O gestor de
dialogo processa a saıda do reconhecedor, ou seja, texto transcrito a partir de lıngua portuguesa falada,
sem pontuacao ou capitalizacao. E necessario avaliar o bom desempenho da ferramenta neste tipo de
processamento, identificando os pontos que e necessario melhorar a ferramenta, para que esta produza
os resultados esperados.
46
4Casos de EstudoNeste capıtulo descrevem-se as instancias desenvolvidas durante o trabalho de reengenharia descrito
anteriormente.
Na seccao 4.1 descreve-se o sistema de assistencia pessoal LISA, uma cooperacao entre o INESC
Inovacao (INOV)1 e o L2F, incluindo: a arquitectura desenvolvida, os servicos implementados e a infra-
-estrutura tecnologica que serviu de base ao desenvolvimento e posterior disponibilizacao do sistema.
Na seccao 4.2 descreve-se o trabalho realizado na plataforma de sistemas de dialogo para permitir
a implementacao de um sistema de banca e um sistema de bolsa telefonica, uma cooperacao entre o
Grupo Promosoft2 e o L2F, incluindo: redesenho da arquitectura da plataforma de dialogo para integrar
um novo gestor de entradas e saıdas.
Na seccao 4.3 descrevem-se os desenvolvimentos feitos no gestor de dialogo, motivados pelos re-
quisitos dos novos sistemas e pelo novo gestor de entradas e saıdas.4.1 LISA - Assistente pessoal virtualNo ambito do projecto TECNOVOZ, o L2F e o INOV criaram uma parceria para desenvolver uma inter-
face de voz para uma camada de servicos frequentemente desempenhada por secretarias pessoais.
Com este objectivo em mente, surgiu o sistema LISA dotado de uma interface de fala atraves da
plataforma de sistemas de dialogo (desenvolvida pelo L2F) que interage com uma aplicacao externa
(desenvolvida pelo INOV) que implementa a camada de negocio da aplicacao e servicos PBX (gestor de
interfaces telefonicas, do ingles Private Branch Exchange).
4.1.1 Levantamento de requisitos e especificacao
O sistema LISA teve uma fase de levantamento de requisitos. O sistema de dialogo ainda estava em
fase de reengenharia quando se comecaram a discutir os requisitos e ainda nao estava claro quais as
potencialidades da plataforma para fazer face aos requisitos de um sistema como a LISA.
1http://www.inov.pt/2http://www.promosoft.pt/
Contudo, o facto de o sistema estar em fase de reengenharia acabou por ser de certa forma benefico
pois os novos requisitos da LISA e dos sistemas de banca e bolsa telefonica acabaram por, promover e
orientar os desenvolvimentos sobre a plataforma.
Servicos disponibilizados
No final da fase de levantamento de requisitos tinha-se um subconjunto dos servicos que se desejava
implementar sobre a plataforma, que apresentam alguns desafios para a plataforma de dialogo mas que
eram implementaveis durante o perıodo de tempo disponıvel.
Com base nos requisitos levantados, foi desenvolvido um conjunto de dispositivos que fornecem
uma camada coerente de servicos uteis a qualquer pessoa que trabalhe numa organizacao. A partir
destes servicos, e possıvel implementar um conjunto de outros servicos desempenhado por secretarias
humanas, baseando-se na modularizacao existente de facil reutilizacao.
Esse subconjunto de servicos inclui os servicos de:
• Gestao do estado do utilizador,
• Gestao do destino de redireccionamento das chamadas,
• Consulta na agenda de contactos,
• Marcacao por voz,
• Envio de mensagens,
• Servicos de voice mail,
• Gestao de agenda,
Descrevem-se agora, com maior detalhe, os servicos implementados.
Gestao do estado do utilizador
A gestao do estado do utilizador (figura 4.1), consiste na definicao de um estado no qual o utilizador se
encontra (ausente, ocupado ou disponıvel), que permite parametrizar a mensagem de voice mail ouvida
pelos utilizadores externos.
Requisitos:
• E necessario parametrizar o estado do dispositivo dinamicamente, em cada chamada que o sistema
atende.
48
Figura 4.1: Casos de utilizacao para a gestao de estado (a esquerda) e gestao do destino de redirecciona-mento (a direita).
Gestao do destino de redireccionamento das chamadas
A gestao do destino de redireccionamento das chamadas (figura 4.1), permite ao utilizador definir um
destino para o qual as suas chamadas sao transferidas. Por exemplo, o utilizador quando esta ausente
pode pretender que as chamadas que habitualmente sao atendidas no escritorio sejam reencaminhadas
para o seu telemovel.
Requisitos:
• Manipulacao de numeros de telefone/telemovel, idealmente com recuperacao de erros.
Consulta na agenda de contactos
A consulta na agenda de contactos (figura 4.2) de alguns tipos suportados (telefone, telemovel, email
ou fax), consiste numa pesquisa de um contacto, sem que seja necessario fornecer o nome exacto desse
contacto na agenda. O sistema utiliza a informacao que tem guardado na agenda para, em colaboracao
com o utilizador, chegar ao contacto pretendido.
Figura 4.2: Casos de utilizacao para a consulta da agenda de contactos (a esquerda) e marcacao por voz(a direita).
Requisitos:
• Novamente manipulacao de numeros de telefone/telemovel;
49
• Manipulacao de objectos do domınio compostos (contactos de telefone compostos por mais do que
uma palavra);
• Manipulacao de objectos do domınio dinamicos que sao actualizados em cada chamada que o
sistema atende (agenda telefonica).
Marcacao por voz
O servico de marcacao por voz (figura 4.2) permite ao utilizador ligar para qualquer destino, usando
comandos de voz.
Este servico utiliza o servico de consulta na agenda de contactos, pelo que requer os requisitos
previamente descritos.
Envio de mensagens
O envio de mensagens (figura 4.3) permite, como o proprio nome indica, enviar mensagens tanto por
texto (SMS e Email) como por audio (Email). Este facilmente expansıvel a outros formatos de mensagens
como MMS ou Fax.
Este servico tambem utiliza o servico de consulta na agenda de contactos.
Figura 4.3: Casos de utilizacao para o envio de mensagens (a esquerda) e gestao do voice-mail (a direita).
Requisitos:
• Manipulacao de modelos de linguagem genericos para reconhecimento de mensagens escritas;
• Manipulacao de eventos assıncronos como, por exemplo, o fim de gravacao da mensagens audio;
50
Servicos de voice mail
Os servicos de voice mail (figura 4.3) consistem na personalizacao das mensagens de acolhimento para
cada estado possıvel, bem como listar e apagar mensagens guardadas. A listagem de mensagem de
voice mail pode receber um parametro adicional referente ao numero de telefone ou contacto de agenda
pelo qual se pretende filtrar a pesquisa. Devido a filtragem da pesquisa de mensagem de voice mail por
contacto, este servico utiliza o servico de consulta na agenda de contactos.
Requisitos:
• Manipulacao de eventos assıncronos de fim de reproducao.
Gestao de agenda
O servico de marcacao de notas e eventos (figura 4.4) permite guardar e pesquisar notas e eventos, po-
dendo no caso dos eventos fazer uma gestao da agenda e definir alarmes de aviso. Cada nota ou evento
tem uma descricao textual que e guardada no formato de audio e texto. O texto e posteriormente utili-
zado para fazer pesquisas por assunto sendo o audio utilizado quando se pretende ouvir a mensagem
associada.
Figura 4.4: Casos de utilizacao para a gestao da agenda.
Requisitos:
• Manipulacao de referencias temporais como datas, horas, intervalos de tempo e duracoes;
51
• Manipulacao de modelos de linguagem genericos para reconhecimento de texto associado as notas
e eventos que se pretende agendar;
• Manipulacao de eventos assıncronos de fim da gravacao e fim de reproducao.
4.1.2 Arquitectura do sistema LISA
A arquitectura do sistema LISA (figura 4.5) encontra-se dividida em tres grandes blocos: (i) sistema de
dialogo que providencia a interface de dialogo/voz; (ii) plataforma INOV que inclui a implementacao
da camada de negocio e, (iii) o sistema de PBX que providencia a interface telefonica.
Estes tres blocos foram criados devido a um requisito que desde cedo foi levantado pelo INOV, e
que consistia no facto da equipa de desenvolvimento do INOV nao querer programar na linguagem de
desenvolvimento do sistema de dialogo, a linguagem Java. O sistema de dialogo ate entao nao permitia
qualquer outro tipo de desenvolvimento. Qualquer entidade que quisesse utilizar o sistema de dialogo,
tinha que pelo menos implementar uma camada em Java que definisse a interface de interaccao entre o
sistema de dialogo e os servicos implementados.
Para resolver o requisito levantado pelo INOV foi desenvolvida uma camada de abstraccao entre
o sistema de dialogo e a plataforma INOV para permitir a invocacao remota dos metodos atraves do
protocolo SOAP (Protocolo de Acesso Simples a Objectos do ingles Simple Object Acess Protocol) e da
linguagem de definicao de servicos WEB, WSDL (Linguagem de Descricao de Servicos Web do ingles
Web Services Description Language).
Inicialmente, esta camada foi implementada no gestor de servicos, tendo apenas que se declarar no
ficheiro XML de definicao dos servicos que o dispositivo era remoto. Esta declaracao indicava ao gestor
de dialogo que nao deveria procurar os metodos a executar em classes de dispositivos que se tinham
registado no sistema, mas que deveria invocar um determinado metodo num servico remoto utilizando
o WSDL especificado.
Esta implementacao e simples e independente da aplicacao externa pois a informacao de negocio
encontrava-se na aplicacao externa. No entanto, com o avancar do levantamento de requisitos,
percebeu-se que parte da informacao de negocio deveria ser utilizada no sistema de dialogo para melho-
rar um conjunto de aspectos, que iam desde a identificacao e reconhecimento de objectos a um conjunto
de validacoes que devem ser efectuadas ao nıvel do sistema de dialogo por estarem directamente rela-
cionadas com o dialogo.
Posto isto, implementou-se, nos respectivos dispositivos, as verificacoes e validacoes necessarias.
So apos se realizarem estas verificacoes e validacoes e que se fazem os pedidos ao servidor web. Esta
solucao tem o inconveniente de ser adaptada ao sistema LISA. Contudo, consegue tirar partido de um
52
Figura 4.5: Diagrama de componentes do sistema LISA.
conjunto de caracterısticas (descritas na seccao 4.3), que de outro modo nao seria possıvel, dado que
estas apenas estavam acessıveis a partir da interface Java.
Com as verificacoes e validacoes a serem realizadas no sistema de dialogo antes dos pedidos ao
servidor web, a comunicacao entre o sistema de dialogo e a plataforma INOV estava solucionada. Con-
tudo, o sistema de dialogo precisava de ter acesso a informacoes que apenas a plataforma INOV tinha
acesso, como por exemplo, eventos de inıcio e fim de chamada. Era, portanto, necessario tornar esta
comunicacao bidireccional.
Para tornar a comunicacao entre o sistema de dialogo e a plataforma INOV bidireccional, foi desen-
volvido do lado do sistema de dialogo um servico que permite a plataforma INOV informar o sistema
de dialogo de eventos, como por exemplo, de inıcio e fim de chamada. O servico foi tambem utilizado
para apontar, quando recebe um evento de inicio de chamada, qual a instancia que deve atender uma
53
determinada chamada. Foi adicionado um servidor web ao sistema de dialogo para alojar este servico,
que e comum a todas as instancias do sistema LISA que se encontram a correr. Os eventos recebidos
pelo servico web sao propagados para todo o sistema utilizando o gestor de eventos (descrito na seccao
3.2).
Esta arquitectura permite isolar os componentes da aplicacao que suportam varias chamadas em
simultaneo (plataforma INOV) dos componentes que apenas suportam uma chamada de cada vez (sis-
tema de dialogo). Optimizou-se, assim, os recursos disponıveis. Contudo, o sistema de dialogo ainda
nao preve a existencia de mais do que um utilizador em simultaneo. Isto leva a que existam desperdıcios
de recursos, como e o caso do reconhecedor e do sintetizador, que sendo bem geridos poderiam ser rea-
proveitados para mais do que uma chamada.4.2 Ban a e bolsa telef�oni aEm paralelo com o desenvolvimento do sistema LISA, desenvolveram-se no L2F um sistema de banca
e um sistema de bolsa telefonica, numa cooperacao com o grupo Promosoft. Estes dois sistemas foram
desenvolvidos sobre o mesmo gestor de dialogo e gestor de servicos. Contudo, foram pioneiros na
utilizacao de um novo gestor de entradas e saıdas.
4.2.1 Descricao dos sistemas
Nesta seccao descrevem-se sucintamente os sistemas de banca e bolsa telefonica, e os servicos imple-
mentados em cada sistema.
Banca
O sistema da banca, a semelhanca dos sistemas que ja existem no mercado, permite aceder a informacoes
sobre contas, transferencias, cartoes de credito, entre outras.
A inovacao deste sistema baseia-se no facto da entrada nao utilizar os codigos DTMF (do ingles Dual
Tone MultiFrequential, codigo de frequencias associadas as teclas dos telefones) para aceder a diversos
menus e operacoes, sendo utilizada exclusivamente a lıngua natural falada.
Com recurso a utilizacao de lıngua natural foi possıvel conceber um sistema que apenas dispoe de
um menu, totalmente plano (sem uma hierarquia de menus).
Servicos implementados
• Consulta de saldos;
54
• Consulta do NIB;
• Consulta de movimentos;
• Consulta de posicao integrada;
• Consulta de informacao sobre cartoes electronicos;
• Consulta de movimentos de cartoes;
• Requisicao de cartoes;
• Anulacao de cartoes.
Bolsa
O sistema da bolsa foi concebido para dotar um conjunto de operacoes (compras, transferencias, entre
outras operacoes), sobre tıtulos da bolsa, de uma interface de fala. Este sistema e um desafio para a
equipa de desenvolvimento de sistemas de dialogo por lidar com informacao de tıtulos muito dinamica.
Servicos implementados
• Consulta de cotacao de tıtulos;
• Consulta de taxas de cambio;
• Consulta de taxas de juro;
• Comprar de accoes;
• Venda de accoes;
4.2.2 Alteracoes na arquitectura
As alteracoes na arquitectura da plataforma de dialogo deram-se ao nıvel do gestor de entradas e saıdas
(figura 4.6). Este foi desenvolvido utilizando diferentes modulos ja existentes na comunidade, que im-
plementam diversos padroes (do ingles standards) da area.
A arquitectura do novo gestor de entradas e saıdas e composta pelos seguintes modulos:
• Asterisk PBX - Modulo (nao desenvolvido pelo L2F) que providencia e gere a interface telefonica
com o exterior;
• Face - A integracao do modulo FACE (cara virtual) previamente desenvolvido (ver seccao 2.1.2.3),
nesta nova arquitectura ainda se encontra em curso;
55
Figura 4.6: Nova arquitectura da plataforma de dialogo DIGA (DIaloG Assistance).
• GJTAPI - Interface generica para gestao de chamadas telefonicas em Java (do ingles Generic Java
Telephony API), cria uma camada de abstraccao entre o modulo PBX utilizado e o interpretador de
Voice XML;
• JVXML - Interpretador de Voice XML em Java;
• JSAPI 2.0 - API para gestao de sintetizadores e reconhecedores de fala desenvolvida em Java (do
ingles Java Speech API);
• Audimus - Reconhecedor de fala (ver seccao 2.1.2.3);
• Dixi - Sintetizador de fala (Paulo et al., 2008);
• STAR - Gestor de dialogo previamente desenvolvido e reestruturado durante o decorrer deste
trabalho (ver seccao 2.1.2.1);
• Gestor de Servicos - Modulo utilizado pelo gestor de dialogo para acesso a informacao dependente
do domınio (ver seccao 2.1.2.2);
• QA@L2F - Modulo de pergunta resposta (Mendes, Coheur, & Mamede, 2007a; Mendes, Coheur,
Mamede, Silva Romao, et al., 2007; Mendes, Coheur, & Mamede, 2007b), que se encontra em
processo de integracao com o gestor de dialogo STAR.
Esta arquitectura utiliza Voice XML gerado a partir da informacao enviada pelo gestor de dialogo.
O principal objectivo desta remodelacao na arquitectura deve-se a necessidade de escalar para varias
chamadas, partilhando os recursos (reconhecedores e sintetizadores) entre as diversas chamadas. A
utilizacao de tecnologias padrao com provas dadas nesta area e que o mercado ja utiliza, e tambem uma
mais-valia para o que se pretende que seja um produto comercial.
56
A primeira versao dos sistemas de banca e bolsa telefonica, foi desenvolvido em Voice XML. No
entanto, apos uma analise aos dialogos desenvolvidos e a eficiencia do sistema concluiu-se que, com
a utilizacao de Voice XML, o sistema ficava aquem das expectativas. O dialogo desenvolvido era fe-
chado, permitindo apenas o fornecimento de uma informacao em cada ponto. Por outro lado o gestor
de dialogo, por modelar a informacao recorrendo a enquadramento, permitia fornecimento de diversas
informacoes em simultaneo, tornando-se assim mais eficiente que a abordagem seguindo apenas Voice
XML. Foi, por isso, integrado o gestor de dialogo nesta arquitectura.
A utilizacao do gestor de dialogo STAR exige um melhor desempenho desta nova arquitectura (no-
meadamente ao nıvel do reconhecimento de fala), dado que os dialogos sao mais abertos e tipicamente
mais naturais que a abordagem seguindo Voice XML. E, por isso, mais complexo desenvolver um mo-
delo de linguagem para reconhecimento deste tipo de dialogos.
A integracao do gestor de dialogo na nova arquitectura foi relativamente simples. Isto deve-se a
existencia (nesta altura) de uma interface bem definida que previa este tipo de alteracoes arquitecturais
(ver seccao 3.4).4.3 Desenvolvimentos sobre a plataformaPara possibilitar a implementacao dos sistemas descritos (sistema LISA e sistemas de banca e bolsa
telefonica), foi necessario promover diversos desenvolvimentos sobre a plataforma, para resolver os
problemas associados a cada servico. Nesta seccao descrevem-se os principais desenvolvimentos efec-
tuados.
4.3.1 Gestor de processadores de linguagem
Uma das maiores limitacoes da plataforma aquando da implementacao do sistema LISA, foi o proces-
samento de tipos de dados especıficos como por exemplo numeros de telefone, ou datas, bem como o
texto das mensagens sobre o qual nao se quer fazer qualquer tipo de processamento. Esta dificuldade
encontra-se associada ao limitado processo de identificacao e reconhecimento de objectos.
Para possibilitar a aquisicao destas informacoes foram criados os seguintes tipos de dados: NUMBER,
FREETEXT, DATE, TIME, TIME INTERVAL e TIME DURATION. Estes tipos de dados sao associados a
cada campo do enquadramento, fornecendo ao sistema o tipo de dados expectavel quando requisitar o
respectivo campo. Se o utilizador responder a pergunta que lhe e colocada, o tipo de dados fornecidos
sera o que esta declarado no campo do enquadramento. Adiciona-se, assim, o factor expectativa do
sistema as obrigacoes de discurso geradas.
O tipo de dados NUMBERindica que um determinado campo recebe numeros (por exemplo, 99
57
333 44 55 ), o FREETEXT texto nao interpretavel, ou seja, quando o utilizador fornece este campo, o
texto recolhido nao e interpretado e e automaticamente associado ao campo, o DATEdatas (por exemplo,
“dia dois de Abril”), o TIME referencias de tempo (por exemplo, “dez horas e vinte e cinco minutos”), o
TIME INTERVALreferencias a intervalos de tempo (Hagege et al., 2008) (por exemplo, “das quinze horas
as dezassete horas”), e o TIME DURATIONreferencias a duracoes temporais (por exemplo, “durante
duas horas”).
A utilizacao do tipo FREETEXTacarreta alguns riscos. Por exemplo, se o utilizador “mudar as suas
intencoes” quando o sistema lhe pergunta o texto a enviar numa determinada mensagem (campo ao qual
se associa o tipo de dados FREETEXT), o sistema ira assumir que a informacao fornecida corresponde
ao texto para a mensagem e nao a uma qualquer ordem que o utilizador possa ter fornecido (ver figura
4.7).
UTILIZADOR: Enviar mensagem sms para Filipe MartinsSISTEMA: Qual a mensagem que deseja enviar?UTILIZADOR: Liga primeiro a luz da sala se faz favorSISTEMA: A sua mensagem foi enviada para Filipe Martins com o texto:
Liga primeiro a luz da sala se faz favor.
Figura 4.7: Exemplo de uma falha no dialogo para o envio de uma mensagem.
Possıveis solucoes para este problema serao discutidas mais a frente (seccao 5.2.2). Estas podem
passar por o sistema interpretar o que foi dito e se o texto fornecido gerar uma interpretacao credıvel
num determinado contexto e/ou domınio, desambiguar com o utilizador.
Com estes tipos de dados associados a cada campo e possıvel prever o tipo da informacao que ira
ser fornecida e processar a entrada com ferramentas para estes casos especıficos. Os campos que nao
estao associados a um tipo de dados, sao do tipo UNKNOWN.
Como forma de integrar este tipo de informacao no processamento da entrada e de resolver os pro-
blemas ao nıvel do processador de linguagem (seccao 3.3), foi criado um gestor de processadores de
linguagem sobre o qual e possıvel definir cadeias de processadores de linguagem (seguindo a arquitec-
tura pipes and filters) intercalando processadores de linguagem independentes do domınio e dependentes
do domınio.
O gestor de dialogo fornece um conjunto de processadores de linguagem independentes do
domınio, aos quais se podem adicionar outros processadores de linguagem (dependentes ou indepen-
dentes do domınio) desenvolvidos pelos programadores do sistema. Basta para isso parametrizar o
gestor de processadores de linguagem com a configuracao desejada (figura 4.8). Com o gestor de pro-
cessadores de linguagem e possıvel definir o processamento da entrada dependente do domınio sem
que isto esteja reflectido no codigo dos processadores de linguagem independentes do domınio e conse-
58
quentemente no codigo do gestor de dialogo. Isto permitiu versatilizar e parametrizar o processamento
da entrada, deixando ao cuidado do programador a parametrizacao desse processamento.
<dialogue-manager><parser-chain>
<sequential type="UNKNOWN"><parser>
<parser-class classname="LisaPreParser"/></parser><parser>
<parser-class classname="GenericParser"><parameter>
/resources/dialoguemanager/Syntatic.db</parameter><parameter>
/resources/dialoguemanager/Composed_words.db</parameter>
</parser-class></parser><parser>
<parser-class classname="LisaPostParser"/></parser>
</sequential><sequential type="NUMBER">
<parser><parser-class classname="NumberParser" />
</parser></sequential><sequential type="DATE">
<parser><parser-class classname="DateParser"/>
</parser></sequential><sequential type="TEXT">
<parser><parser-class classname="ComposedFieldParser"/>
</parser></sequential>
</parser-chain></dialogue-manager>
Figura 4.8: Exemplo de parametrizacao do gestor de processadores de linguagem de entrada.
Este gestor de processadores de linguagem foi pensado para possibilitar a inclusao da informacao
de tipos de dados definida ao nıvel dos campos. Assim, possibilitou-se a definicao de uma cadeia de
processadores de linguagem para cada tipo pre-definido. Quando o sistema espera um campo de um
determinado tipo, corre um conjunto de processadores de linguagem (que pode ser especıfico desse tipo
de dados) criando os respectivos objectos para que sejam interpretados e fornecidos a aplicacao externa.
No caso do tipo FREETEXTo processador de linguagem que corre tem a tarefa de criar um objecto com
todo o texto passado a entrada para que este texto nao seja interpretado e seja passado ao servico tal
como foi fornecido ao sistema.
Com isto, melhorou-se a eficiencia do sistema na tarefa de identificacao de objectos, permitindo a
implementacao, por exemplo, do servico de envio de mensagens, que ate entao estava implementado
recorrendo a palavras-chave, traduzidas do lado da aplicacao externa para frases pre-associadas.
Ainda no contexto da definicao de tipos de dados associados a um determinado campo, foi definido
59
um novo tipo denominado EXTERNALque permite indicar que um determinado campo e preenchido
por uma entidade externa. Neste caso, em vez de o sistema colocar uma questao ao utilizador e exe-
cutado um metodo que vai contactar uma aplicacao externa e/ou base de dados para assim preencher
a informacao em falta. Este tipo foi definido para ser utilizado, por exemplo, nas mensagens de audio
do sistema LISA, ou seja, quando o gestor de dialogo determina que falta apenas a mensagem de audio
(com recurso ao parametro rank descrito na seccao 4.3.4), verifica que este parametro e de preenchimento
externo, executando o metodo associado (ver figura 4.9). Este metodo faz um pedido remoto a aplicacao
externa que grava o audio ditado pelo utilizador, enviando para o gestor de dialogo o identificador
desse ficheiro, que e posteriormente associado ao respectivo campo do enquadramento e preenchido no
pedido remoto para envio da mensagem.
<frame_name>Mensageiro</frame_name><slot type="unknown" required="true" rank="1">action</ slot><slot type="unknown" required="false" rank="2">target< /slot><slot type="unknown" required="true" rank="3">tipo de me nsagem</slot><slot type="NUMBER" required="true" rank="3">destino</ slot><slot type="TEXT" srgs="secretaria_FSM" required="true " rank="4">mensagem de texto</slot><slot type="External#audioRecord" required="true" rank ="4">mensagem de audio</slot>
Figura 4.9: Exemplo de definicao de um parametro externo.
A inclusao da informacao de tipos de dados nos enquadramentos e a sua posterior utilizacao ao
nıvel do gestor de processadores de linguagem estao a elevar o processamento da lıngua para um nıvel
pre semantico. Isto em conjunto com algumas das melhorias ao nıvel da identificacao e reconhecimento
de objectos (descritas na seccao 4.3.6), permitiram integrar a cadeira de processamento morfossintactico
XIP (descrita na seccao 3.8). A integracao da cadeia XIP permite um processamento da lıngua ao nıvel
semantico, algo que nao e possıvel com o mecanismo de processamento a palavra existente actualmente,
o que vai possibilitar o desenvolvimento de dialogos mais naturais.
4.3.2 Validacoes dinamicas
A plataforma ja permitia a validacao de campos dos servicos com recurso a uma linguagem simples
definida no XML de definicao do servico. Contudo, no sistema LISA a informacao de negocio encontra-
-se na aplicacao externa. Esta informacao e dinamica e pode ser alterada diversas vezes durante a
execucao do sistema.
Com isto em mente, foi definida com base na mesma linguagem de validacoes ja existente, uma
sintaxe que permite indicar ao sistema que existe a necessidade de validar determinados campos apos
o preenchimento dos mesmos.
Os desenvolvimentos ao nıvel das validacoes permitiram implementar, por exemplo, validar o tipo
60
<service>< !-- Definicao do Servico --! ><execute></execute><validations>
<validation><not>
<equal><params>
<param slotref="cidadeOrigem"></param><param slotref="cidadeDestino"></param>
</params></equal>
</not></validation>
</validations></service>
Figura 4.10: Exemplo de declaracao de uma validacao.
de mensagem a enviar com o contacto associado, no servico de envio de mensagens do sistema LISA.
Esta validacao e importante para casos em que existe um contacto na agenda, mas este nao permite
enviar o tipo de mensagem pretendido.
<service>< !-- Definicao do Servico --! ><execute></execute><codevalidations>
<codevalidation><execute>
<name>validaDestinoMensagem</name><params>
<param slotref="tipo_mensagem"></param><param slotref="destino"></param>
</params></execute>
</codevalidation></codevalidations>
</service>
Figura 4.11: Exemplo de declaracao de uma validacao dinamica.
No caso em que existem dois ou mais parametros envolvidos na validacao o programador pode
indicar ao sistema se este deve perguntar ao utilizador que campo e que este quer alterar (nao tendo
este que fornecer toda a informacao novamente), ou se deve limpar todos os campos envolvidos na
validacao perguntando novamente cada um deles.
4.3.3 Confirmacoes explıcitas
As confirmacoes explıcitas foram introduzidas porque existe a necessidade de confirmar explicitamente
alguns parametros ou servicos, quer pela sua importancia, quer porque o servico possui muitos cam-
61
pos e ocorrem frequentemente erros de reconhecimento. Assim, foi disponibilizado na definicao dos
servicos a possibilidade de indicar que e necessario validar explicitamente um determinado campo ou
servico, sendo necessaria a definicao de regras de geracao para essas confirmacoes.
Por exemplo, no sistema LISA o servico de envio das mensagens de audio confirma se o utilizador
deseja enviar a mensagem apos este gravar e ouvir a mensagem por completo. So assim o utilizador
tem a certeza que o receptor ira compreender a mensagem que este lhe tenta transmitir.
E possıvel confirmar um ou mais parametros de um servico bem como o servico como um todo.
Contudo, se o utilizador nao confirmar o servico, o contexto e limpo nao dando a possibilidade ao
utilizador de alterar apenas aquele campo que esta errado. Para que isto seja possıvel e necessario
utilizar o mecanismo de validacoes.
Quando se rejeita a confirmacao de um servico completo e necessario fornecer toda a informacao
novamente, porque o contexto do dialogo e limpo. Este procedimento foi alvo de algumas crıticas
ainda durante os testes preliminares, por tornar o dialogo pouco eficiente. Assim, esta-se, neste mo-
mento, a equacionar alterar este mecanismo para, a semelhanca das validacoes, perguntar ao utilizador
qual ou quais os campos que este deseja alterar, para que nao se tenha que fornecer novamente toda a
informacao.
4.3.4 Ordenacao e optimizacao do dialogo
Com a existencia de validacoes dos campos, percebeu-se que era necessario ordenar o preenchimento
dos campos, para que os necessarios as validacoes fossem primeiramente preenchidos. Assim, evitam-
-se que um utilizador dite um email com alguns paragrafos e assim que fornece o contacto de destino
recebe a informacao do sistema que nao e possıvel enviar a mensagem de email porque nao possui um
contacto de email para o destino pretendido.
Para minimizar a ocorrencia de casos como este, define-se um parametro de ordenacao (rank, ver
figura 4.9), que permite indicar ao gestor de dialogo a ordem de preenchimento dos diversos campos.
Assim, sempre que o sistema tem que seleccionar um campo para perguntar ao utilizador, verifica
se existe um parametro rank definido. Caso este esteja definido e perguntado ao utilizador o campo com
o rank inferior, caso nao esteja definido, o sistema escolhe um parametro aleatoriamente. Para o caso em
que existem campos onde o rank se encontra definido no mesmo enquadramento onde existem campos
sem o mesmo definido, o sistema da prioridade aos campos onde se encontra declarado o parametro
rank.
A motivacao para este desenvolvimento foi a existencia de validacoes. Contudo, este pode ser utili-
zado para modelar os dialogos, de forma a tornarem-se mais coerentes ou ate de forma a adequarem-se
62
melhor ao modelo mental dos utilizadores.
4.3.5 Parametrizacao do contexto do dialogo
Por vezes, e necessario o servico parametrizar dinamicamente o contexto do dialogo, para que seja
possıvel, por exemplo, executar servicos que nao estao disponıveis directamente, mas que serao execu-
tados mediante a verificacao de uma condicao de um servico.
Um exemplo disso e o servico de voice mail do sistema LISA que permite ao utilizador, apos escutar
cada mensagem, apagar de imediato a mensagem ouvida, passando assim a proxima mensagem. Este
servico nao se encontra disponıvel para o utilizador. Contudo, naquele ponto especıfico do dialogo,
onde o utilizador diz “sim quero apagar este email”, o servico fica disponıvel e e executado como forma
de desempenhar um conjunto de tarefas que apenas fazem sentido naquele contexto.
Cada vez mais e preciso disponibilizar aos dispositivos interfaces para parametrizacao do contexto.
Sao os dispositivos que tem contacto com as aplicacoes externas e e necessario que estes possam para-
metrizar dinamicamente o gestor de dialogo, quer porque ocorreram alteracoes no mundo, quer porque
se verificou um procedimento de excepcao ao qual o gestor de dialogo tem que dar resposta.
4.3.6 Identificacao e reconhecimento de objectos
A identificacao de objectos, tal como foi previamente referido (seccao 3.3), e um dos aspectos mais
limitativos da plataforma. Para que fosse possıvel implementar o sistema LISA e os sistemas de banca
e bolsa telefonica foi necessario implementar diversas extensoes a identificacao de objectos, tais como:
concatenacao de objectos, manipulacao de objectos compostos e identificacao e reconhecimento ao nıvel
do processador de linguagem.
4.3.6.1 Concatenacao de objectos
Inicialmente o sistema nao permitia a identificacao e posterior reconhecimento de objectos com mais de
uma palavra. Por exemplo, para reconhecer o nome “Filipe Martins” era necessario criar dois campos
no enquadramento, um para o primeiro nome e outro para o segundo.
Para que seja possıvel reconhecer o nome dos diversos contactos e numeros (de telefone por exem-
plo) com mais do que um dıgito e necessario expandir as regras utilizadas na identificacao e reconheci-
mento de objectos, para que fosse possıvel concatenar os diversos objectos definidos numa regra.
Com isto e possıvel escrever nas regras de identificacao e reconhecimento de objectos, por exemplo,
os nomes individuais de cada contacto de forma a compor estes por qualquer ordem. Isto permite que o
63
<rule id="action"><one-of>
<item>ligar</item><item>fazer</item><item>efectuar</item>
</one-of></rule>
<rule id="target"><one-of>
<item>telefonema</item><item>chamada</item>
</one-of></rule>
<rule id="destino"><one-of>
<item>filipe martins</item><item>ana mendes</item><item>nuno mamede</item><item>marcio viveiros</item><item>joao paulo neto</item><item>rui maia</item><item>rogerio rilhas</item>
</one-of></rule>
Figura 4.12: Exemplo de declaracao de regra de identificacao e reconhecimento de objectos.
sistema de dialogo dispondo de um lista de nomes individuais possa identificar e reconhecer qualquer
nome que esteja na agenda. Basta para isso indicar que a regra permite a identificacao e reconhecimento
de um objecto resultante da concatenacao de qualquer entrada da regra, zero ou mais vezes. O mesmo
se verifica para os numeros, dado que, com uma lista de numeros limitada e possıvel compor qualquer
numero por mais complexo que ele fosse.
Contudo, este mecanismo e demasiado abrangente e permitia o reconhecimento de nomes con-
tendo, por exemplo, dois apelidos, estando apenas limitado pelo modelo de linguagem do reconhecedor
para que isso nao acontecesse.
4.3.6.2 Manipulacao de objectos compostos
Para lidar com o problema do excesso de abrangencia do mecanismo de concatenacao de objectos,
desenvolveu-se ao nıvel do processador de linguagem independente do domınio um meio de este con-
sultar os objectos definidos nas regras de reconhecimento de objectos. Com isto, e possıvel ao processa-
dor de linguagem independente do domınio verificar se uma determinada cadeia de caracteres, pertence
aos objectos do dispositivo e em caso afirmativo constroi o objecto referente a essa cadeia de caracteres.
Tornou-se, assim, possıvel identificar objectos que tem mais que uma palavra, dado que essa informacao
esta representada nas regras de identificacao e reconhecimento de objectos.
Isto, em conjunto com a interface para definicao dinamica (no codigo) dos objectos aceites, per-
mitiu que cada dispositivo do sistema LISA, quando recebe o evento de inıcio de chamada, consulte a
64
plataforma INOV por forma a actualizar por exemplo a lista de contactos aceites.
Estas alteracoes permitem desambiguar os objectos de domınio. Por exemplo, se a lista de contactos
possuir os contactos “Ana Mendes” e “Ana Nunes” e se o utilizador indicar que quer enviar uma men-
sagem para “Ana” o sistema consegue perceber que este objecto e parte de dois contactos, perguntando
ao utilizador “deseja enviar uma mensagem para Ana Mendes ou Ana Nunes?”.
A manipulacao de objectos compostos resolveu o problema da lista de contactos, sendo que o pro-
blema com o reconhecimento e identificacao de numeros foi resolvido com o novo gestor de processa-
dores de linguagem descrito na seccao 4.3.1.
4.3.6.3 Identificacao e reconhecimento de objectos ao nıvel do processador de linguagem
Os desenvolvimentos descritos anteriormente tornaram o processamento de objectos mais eficiente.
Contudo, apos uma reanalise do problema, percebeu-se, que devido ao facto de a identificacao de ob-
jecto ser feita ao nıvel do processador de linguagem e de o reconhecimento de objectos ser feito ao nıvel
do gestor de interpretacoes, existia uma perda de informacao. Isto deve-se ao facto de quando os ob-
jectos sao reconhecidos, ja nao existir a informacao de localizacao do objecto na frase, que permitiria
relacionar esse objecto com o objecto anterior e o objecto seguinte, como forma de desambiguar entre
dois ou mais tipos.
Para tornar este processamento mais versatil e consequentemente mais eficiente, desenvolveu-se
um meio de, ao nıvel dos processadores de linguagem, um objecto apos ser identificado poder ser re-
conhecido. Quando esse objecto chega ao gestor de interpretacoes, este verifica que o objecto ja se
encontra reconhecido e nao o envia ao reconhecedor de objectos. Este tipo de abordagem implica que o
programador do processador de linguagem garanta que o campo ao qual o objecto esta a ser associado
efectivamente existe e faz sentido num determinado dispositivo.
4.3.7 Prevencao e recuperacao de erros
Um dos aspectos que mais impacto tem ao nıvel do desempenho e que foi identificado durante
a avaliacao ao sistema Ambrosio (descrita na seccao 2.2) e a identificacao e prevencao de erros.
Nesta seccao descrevem-se alguns desenvolvimentos nesta area, sobretudo ao nıvel da identificacao
e recuperacao de erros de reconhecimento.
Segmentacao de instancias de dialogo A segmentacao das instancias de dialogo (do ingles utterances)
era, ate entao, feita ao nıvel do reconhecedor de fala que detecta quando existe uma transicao entre uma
zona de fala e uma zona sem fala. Contudo, esta segmentacao nao dispunha de informacao do con-
texto do dialogo, e nos casos em que um utilizador fazia uma pausa entre duas frases de uma mesma
65
afirmacao, o reconhecedor indicava a existencia de duas instancias de fala. Isto era problematico para o
gestor de dialogo que ia processar cada frase como uma afirmacao independente, avaliando incorrecta-
mente a intencao do discurso. Este tipo de situacao acontecia nas mensagens de texto, em numeros de
telefone, datas, entre outros tipos de dados, onde frequentemente o utilizador faz pausas.
Para tornar o sistema mais robusto a segmentacao do reconhecedor de fala, utilizaram-se os tipo
de dados previamente definidos (na seccao 4.3.1), para introduzir um temporizador que deixa ao uti-
lizador uma “folga” para pausas entre, por exemplo as diversas frases de uma mensagem. Enquanto
este temporizador nao expira o gestor de dialogo agrupa todas as instancias de dialogo enviadas pelo
reconhecedor.
Confiancas de reconhecimento O sistema de reconhecimento de fala incluıdo no sistema de dialogo,
actualmente, ja disponibiliza a informacao sobre as confiancas a palavra do que foi reconhecido. Con-
tudo, so com a introducao do novo gestor de eventos (descrito na seccao 3.2) foi possıvel ao gestor de
dialogo ter acesso a essa informacao.
Utilizando essa informacao, o gestor de dialogo, apos a geracao das interpretacoes, avalia se os
objectos reconhecidos e utilizados para gerar a interpretacao seleccionada tem uma probabilidade de
reconhecimento acima de um determinado limiar.
Esse limiar e definido por um intervalo, no qual o gestor de dialogo, caso a probabilidade esteja den-
tro do mesmo, confirma com o utilizador se o objecto reconhecido esta correcto. Abaixo desse intervalo
o objecto e automaticamente rejeitado e acima e automaticamente aceite.
E possıvel, assim, eliminar um conjunto de objectos que “poluem” o contexto do discurso com
interpretacoes sem suporte.
Alteracao do fluxo do dialogo Frequentemente, devido a erros de reconhecimento, o sistema de
dialogo detecta alteracoes ao fluxo de discurso, aparecendo falsos alarmes que geram interpretacoes
para domınios que nao estavam a ser considerados.
Esta situacao foi minimizada com a introducao do processamento de confiancas geradas pelo reco-
nhecedor. Contudo, quando um determinado objecto pertence a mais do que um domınio, e o proprio
gestor de dialogo a gerar essas interpretacoes.
Em (Mourao, 2005) foi definido um conjunto de heurısticas para atribuir uma probabilidade de
reconhecimento a um determinado servico, com base nos campos ja preenchidos. No entanto, estas
heurısticas sao pouco diferenciadoras quando existem servicos com poucos campos, existindo diversas
interpretacoes com a mesma probabilidade de reconhecimento associadas a esses servicos.
Era necessario introduzir uma medida que auxiliasse a seleccao da melhor interpretacao gerada
pelo gestor de interpretacoes, para que interpretacoes com pouco suporte (poucos campos preen-
66
chido face a informacao guardada no contexto), fossem descartadas. Introduziu-se por isso uma me-
dida que tem em conta o maior numero de campos preenchidos mais recentemente. Isto permite
que interpretacoes que ficam em contexto, possivelmente porque foram acidentalmente geradas de-
vido a erros de reconhecimento de fala e/ou de objectos, apenas sejam consideradas se mais nenhuma
interpretacao, gerada mais recentemente seja, referida.
No futuro, a gestao dos servicos mantidos em contexto tem que ser melhorada para nao permitir a
acumulacao de “lixo” no contexto, que podera afectar futuros dialogos.
Construcao e premutacao dinamica de modelos de linguagem Os desenvolvimentos apresentados
acima focam o aspecto de deteccao e recuperacao de erros de reconhecimento. No entanto era desejavel
conseguir prevenir estes erros. Uma das tecnicas utilizada pelo Voice XML3 e a alteracao dinamica para
o modelo de linguagem mais adequado e restrito a instancia de dialogo gerada.
Actualmente, com os diversos desenvolvimentos ao nıvel da interface do gestor de entradas e
saıdas, ja e possıvel ao sistema de dialogo seleccionar o modelo de linguagem activo em cada instante.
Esta caracterıstica e explorada no sistema LISA. O modelo de linguagem activo, e alterado quando o
sistema pergunta qual a mensagem a enviar. Isto porque, para reconhecer uma mensagem de texto, e
necessario ter um modelo de linguagem “generico” activo. Contudo, este nao necessita de estar sempre
activo, nao so por provocar erros de reconhecimento mas tambem por tornar o sistema de reconheci-
mento de fala mais lento.
Outra das utilizacoes e a geracao de modelos de linguagem dinamicos. Cada vez que o sistema
LISA atende uma chamada, gera um modelo de linguagem com os nomes existentes na agenda de
contactos. Isto permite que a agenda de contactos seja alterada do lado da plataforma INOV, sem que
isso provoque erros de reconhecimento de um determinado contacto, que efectivamente se encontra na
agenda.
No entanto, e necessario ainda avaliar em que pontos do discurso e possıvel limitar ainda mais os
modelos de linguagem. Isto porque, dado que a plataforma de dialogo e baseada em enquadramentos
e nao em estados (ver seccao 1.2), o utilizador deve em cada momento ser capaz de fornecer qualquer
parametro para o servico ou ate mesmo trocar de servico sem que o modelo de linguagem activo seja
um impedimento.
O publico dos sistemas de banca e bolsa telefonica sao os clientes de uma entidade bancaria. Ti-
picamente, este tipo de utilizadores e pouco experiente e utiliza esporadicamente o sistema. Aqui,
a modelacao de dialogos tem que ser mais restrita, desenvolvendo dialogos mais fechados e menos
propıcios a ocorrencia de erros.
3http://www.w3.org/TR/voicexml21/
67
Para que isto seja possıvel e desejavel poder trocar os modelos de linguagem activos em todos os
pontos do dialogo. O modelo de linguagem so deve ser mais abrangente no ponto em que o utilizador
tem a opcao de escolher qual a operacao que deseja efectuar. A partir desse ponto, o dialogo e direccio-
nado para a execucao dessa tarefa. Esse direccionamento passa por apenas reconhecer os campos para
o servico activo e algumas palavras que permitam voltar ao estado inicial.
Isto levou a que fosse necessario desenvolver tanto a interface estatica (definicoes em XML de
domınios e servicos) como a interface dinamica (codigo do dispositivo) para que fosse possıvel alte-
rar o modelo de linguagem activo em qualquer ponto do dialogo.
4.3.8 Nıveis de dialogo
Um das sugestoes dadas durante o desenvolvimento do sistema LISA e que ja e utilizada em parte pelo
Voice XML, e a existencia de uma hierarquia de dialogo, de acordo com a experiencia do utilizador.
Se um utilizador e experiente num determinado sistema, sabe dirigir-se ao sistema de forma cor-
recta e eficiente para maximizar tambem a sua eficiencia. Um utilizador inexperiente tem uma maior
dificuldade em executar servicos e precisa de uma maior ajuda.
Para permitir esta modelacao de dialogos passou a ser possıvel definir diversos nıveis de dialogo.
O sistema de dialogo e no inıcio de cada chamada, parametrizado pela plataforma INOV atraves do
evento de inıcio de chamada. Com base nessa informacao desenvolve dialogos mais descritivos in-
cluindo bastante ajuda e confirmacoes implıcitas por forma a ajudar o utilizador mais inexperiente, ou
dialogos mais curtos para maximizar a eficiencia do utilizador mais experiente.
Foi desenvolvida ainda uma caracterıstica adicional para caso exista uma ambiguidade no discurso
ou o sistema nao receba qualquer resposta do utilizador, o sistema alterar dinamicamente o nıvel de
verbosidade fornecendo automaticamente ajuda ao utilizador.
Ate a data a hierarquia de dialogos nao foi utilizado, por aumentar bastante a complexidade da
tarefa de desenvolver dialogos naturais. Tem-se, por isso, tentado desenvolver um dialogo para um
nıvel de experiencia intermedio, que sera reavaliado mais tarde para identificar em que pontos esta
caracterıstica deve ser utilizada.
4.3.9 Inclusao de eventos de excepcao
No Voice XML (interface de comunicacao entre o gestor de dialogo e o novo gestor de entradas e saıdas)
existe a possibilidade de definir frases que serao trocadas caso ocorra um comportamento de excepcao4
4http://www.w3.org/TR/voicexml20/#dml5.2.2
68
que inclui a ausencia de resposta (noinput no Voice XML), a ausencia de reconhecimento (nomatch no
Voice XML) ou caso o utilizador peca ajuda ao sistema (help no Voice XML).
Este tipo de eventos nao estava modelado no gestor de dialogo. No entanto era de todo desejavel
que fosse este a gerar este tipo de informacao dado que este e que tem disponıvel o contexto do dialogo,
e que podera gerar frases mais adequadas a estes eventos com base nessa informacao.
Foi entao estendida a interface para permitir a definicao deste tipo de eventos nas regras de geracao
do domınio, nas frases de alteracao de estado e nos resultados enviados dinamicamente pelo disposi-
tivo. O gestor de dialogo, tal como nas frases definidas nas regras de geracao de domınio, efectua a
substituicao de objectos de domınio para permitir uma maior contextualizacao dessas frases.4.4 Considera� ~oes �naisO desenvolvimento do sistema LISA e dos sistemas de banca e bolsa telefonica, veio evidenciar a
tendencia de grande parte da informacao manipulada por estes sistemas ser dinamica. O facto dos ca-
sos de estudo serem desenvolvidos em parcerias com empresas focou ainda mais esse aspecto. Mesmo
a informacao que aparentemente e estatica, encontra-se na aplicacao externa que implementa a camada
de negocio. A equipa de desenvolvimento de sistemas de dialogo nao domina o negocio e por isso essa
camada tem que ser mantida pelas entidades que a conhecem.
A informacao necessaria tem, por isso, que ser fornecida dinamicamente ao sistema de dialogo.
Contudo, nem sempre e facil ter um sistema, que recebe como entrada algo tao abrangente como a
lıngua natural e que produz uma saıda tambem ela em lıngua natural, que permita a alteracao dinamica
de todo o tipo de informacao sem que o sistema receba manutencao constante para que consiga lidar
como essa informacao.
Os desenvolvimentos da plataforma foram no sentido de lidar com informacao dinamica. A
declaracao estatica de parte dessa informacao e util, dado que economiza bastante trabalho ao nıvel
da manutencao da informacao. A estrategia introduzida no sistema de dar prioridade a informacao
mais especıfica e mais dinamica face a informacao mais geral e mais estatica, permitiu em simultaneo a
reutilizacao da informacao especificada e a modelacao de casos de excepcao, tao frequentes nesta area.
E necessario continuar a investigar a manipulacao dinamica de informacao ao nıvel do processa-
mento e geracao de dialogo, para melhorar os processos e ferramentas usadas no desenvolvimento e
manutencao de sistemas de dialogo. Este e um factor estrategico e de competitividade neste mercado
em constante crescimento.
O projecto TECNOVOZ e as pessoas ligadas a ele permitiram que este trabalho se desenvolvesse,
colocando o L2F e a VoiceInteraction numa posicao interessante na area dos sistemas de dialogo, que
69
permite a avaliacao de objectivos de mercado.
No final deste projecto tres novos sistemas foram desenvolvidos, dois produtos que se encontram
em fase de avaliacao do mercado alvo (sistema de banca e bolsa telefonica), e um prototipo bastante
avancado na area (sistema LISA) sobre o qual e necessario efectuar prospeccoes, com vista a oficializar o
sistema como um produto comercial. Para alem dos sistemas produzidos, existe um conjunto de novas
ideias e requisicoes de entidades externas nesta area, que permitem equacionar um futuro promissor ao
nıvel da investigacao e comercializacao generalizada de sistemas de dialogo.
70
5Con lus~oesNeste capıtulo (seccao 5.1) descreve-se a avaliacao feita ao sistema LISA, indicando os principais pro-
blemas do sistema no final deste trabalho. Na seccao 5.2, descreve-se ainda investigacao realizada, mas
que, por falta de tempo, nao foi possıvel dar por concluıda. Na seccao 5.3, descrevem-se explicitamente
as contribuicoes para a area realizadas no decorrer deste trabalho.5.1 Avalia� ~ao do sistema de assisten ia pessoal LISAApos reestruturar grande parte da arquitectura do gestor de dialogo e de desenvolver um conjunto
de funcionalidades, que deveriam permitir o incremento de usabilidade e o desenpenho do dialogo
desenvolvido pela plataforma DIGA, era necessario aferir quantitativamente os incrementos consegui-
dos. Como forma de medir os ganhos obtidos com o trabalho desenvolvido, avaliou-se o sistema de
assistencia pessoal LISA, dado que foi o sistema que mais promoveu novos desenvolvimentos sobre
o gestor de dialogo. Tentou-se, dentro da medida dos possıveis e tendo em conta as dificuldades e
limitacoes da area, comparar os resultados obtidos com a avaliacao realizada ao sistema Ambrosio (des-
crita na seccao 2.2), que serviu de ponto de partida para o trabalho realizado.
5.1.1 Alteracoes ao modelo de avaliacao
Para avaliar o sistema de assistencia pessoal LISA, foram feitas algumas alteracoes ao modelo de
avaliacao definido na seccao 2.2, dado que o sistema e substancialmente diferente do sistema Ambrosio,
e por forma a maximizar as conclusoes obtidas. Contudo, o questionario elaborado nao sofreu alteracoes
de maior, para maximizar a comparacao de resultados entre o sistema Ambrosio e o sistema LISA. As
alteracoes efectuadas incidiram sobre as metricas recolhidas e consistem em:
Ocorrencia de falhas Dado que a principal causa de falha na avaliacao realizada ao sistema Ambrosio
foram os erros de reconhecimento, e tendo em conta que no sistema LISA foram desenvolvidas diver-
sas metodologias para recuperacao de erros (nomeadamente recuperacao de erros de reconhecimento),
nesta nova avaliacao contabilizaram-se apenas as falhas ocorridas e as falhas ocorridas devido a erros de
reconhecimento, ficando de fora as falhas devido a erros por reconhecimento parcial (ver seccao 2.2.4).
Iteracoes para recuperacao de erros Durante o desenvolvimento do sistema LISA, foi dada uma es-
pecial atencao a identificacao e recuperacao de erros, nomeadamente erros de reconhecimento. Para
medir quao eficientes foram as metodologias desenvolvidas, foi contabilizado o numero de iteracoes
empregues pelo sistema de dialogo para prevencao e recuperacao de erros.
Numero de chamadas realizadas Como o sistema LISA esta acessıvel por telefone, e porque se previa
que fosse necessario mais do que uma chamada para realizar as tarefas pretendidas, contabilizou-se o
numero de chamadas realizadas por cada utilizador. Para efeitos de conclusao, considerou-se que se
o utilizador teve que ligar mais do que uma vez para o sistema, entao o sistema entrou num estado,
no qual o utilizador nao consegue realizar mais nenhuma tarefa, tendo sido dado essa indicacao aos
utilizadores que participaram na avaliacao.
5.1.2 Tarefas realizadas por cada utilizador
No decorrer dos testes pediu-se a cada utilizador para realizar um conjunto de tarefas, ordenado da
seguinte forma:
• Tarefa 1 - Altere o seu estado para ausente;
• Tarefa 2 - Envie uma mensagem SMS ao Filipe Martins: “vou ter agora ao restaurante, daqui a 15
minutos estou la.”;
• Tarefa 3 - Personalize o seu voice-mail para o estado ausente: “fui almocar, volto por volta das 15
horas.”;
• Tarefa 4 - Active o redireccionamento das suas chamadas para o numero XX XXX XX XX;
• Tarefa 5 - Marque uma reuniao para dia 06/07/2008 as 16 horas, com a duracao de 30 minutos:
“reuniao para discutir assuntos pendentes.”;
• Tarefa 6 - Verifique se tem mensagens de voice-mail de Filipe Martins;
• Tarefa 7 - Ligue para o Filipe Martins.
O conjunto de tarefas seleccionado cobre os principais servicos. Estas tarefas foram ordenadas, de
forma a terem uma ordem logica, sendo credıvel a sua realizacao num contexto real.
5.1.3 Testes-piloto
Os testes-piloto correram com normalidade tendo-se apenas alterado alguns detalhes ao nıvel da
descricao das tarefas. Para alem dessas alteracoes, durante os testes-piloto, foi detectada uma
incorreccao no sintetizador Dixi que fazia com que este deixasse de responder.
72
5.1.4 Testes
No decorrer dos testes, o problema no sintetizador que aparentemente tinha sido corrigido durante a
realizacao dos testes-piloto manifestou-se, e provocou diversas paragens. Todas as falhas que impedi-
ram o sistema de prosseguir estao associadas a este problema, que penalizou os resultados obtidos.
A parte deste problema, os testes decorreram com relativa normalidade nao se tendo verificado
questoes que merecessem uma intervencao imediata.
Discussao dos resultados e conclusoes
Os resultados obtidos ficaram aquem do esperado. O sistema, tal como foi referido, foi desenvolvido
para utilizadores experientes que sabem como interagir com o sistema. Contudo, nao foi possıvel re-
alizar testes com utilizadores experientes. Era necessario dar alguma formacao e por falta de tempo
isto nao foi possıvel. Com utilizadores inexperientes a realizarem os testes, existiu muito vocabulario
novo empregue (mesmo utilizando vocabulario aceite pelo sistema na descricao das tarefas). Este voca-
bulario, nao estava na gramatica do reconhecedor e nao era, por isso, reconhecido.
Para alem disso, caracterısticas do sistema como, por exemplo, as interrupcoes, dificultaram a ta-
refa, dado que, como os utilizadores nao sabiam como interagir com o sistema, interrompiam o mesmo
em alturas indevidas, ficando sem informacao do que deviam fazer de seguida. Estas ocorrencias pena-
lizaram a eficiencia do sistema ao contrario do que seria esperado.
Figura 5.1: Numero medio de falhas por tarefa (a esquerda) e tempo (em segundos) gasto em media,por tarefa (a direita).
A utilizacao de vocabulario nao reconhecıvel levou a que existissem diversas falhas de reconheci-
mento, falhas essas que, tal como se veio a verificar mais tarde, revelaram um problema na gestao de
contexto no gestor de dialogo. O problema verificava-se na limpeza do contexto, que nao era feita se
nao para o servico que era executado (cada vez que o sistema executa um servico, efectua algumas ta-
refas de limpeza do contexto), estando o contexto constantemente populado por conceitos que tinham
surgido devido a erros de reconhecimento. A manutencao de objectos em contexto torna o gestor de
dialogo mais eficiente, dado que o utilizador pode interromper uma tarefa e retoma-la mais tarde (apos
73
a execucao de outros servicos). No entanto, quando se verificam sucessivos erros de reconhecimento,
as palavras erroneamente reconhecidas para a execucao de um qualquer servico sao utilizadas para a
construcao de novas interpretacoes, tornando o dialogo “desregulado”.
Este factor contribuiu para o aumento de falhas no gestor de dialogo, nos mecanismos de deteccao
e recuperacao de erros e fez com que varias vezes os utilizadores se sentissem totalmente perdidos a
ponto de desligarem a chamada para tentar novamente (dai a media de 1,7 chamadas para executar o
total das tarefas).
Apesar de tudo, a percentagem de tarefas executadas foi bastante elevada (acima de 87%), tendo
em conta a utilizacao de utilizadores inexperientes. O numero de falhas e o tempo despendido para rea-
lizar cada tarefa penalizaram os resultados obtidos. Contudo, os servicos disponibilizados pelo sistema
LISA necessitam de um numero de campos superior ao sistema Ambrosio. Isto implica a existencia de
frases mais longas e maior variabilidade de vocabulario, que leva a um aumento do numero de erros de
reconhecimento. Por outro lado a mais valia do sistema LISA e mais evidente que no caso do sistema
Ambrosio. O sistema LISA permite realizar tarefas de elevada importancia em ambientes maos livres
(por exemplo no automovel), primando pela facilidade da sua interface e nao pela eficiencia com que
sao realizados os diferentes servicos.
Esta avaliacao, sendo a primeira realizada apos conclusao de todos os servicos do sistema LISA,
permitiu perceber quais os servicos que ja sao bastante eficientes, por terem uma taxa de sucesso bas-
tante elevada e por serem realizaveis num tempo inferior as interfaces habituais, e os servicos que ainda
precisam de ser trabalhados ao nıvel da usabilidade para que cheguem ao patamar dos restantes.
Os questionarios feitos aos utilizadores confirmam os resultados obtidos, e em comparacao com o
sistema Ambrosio apontam para um desempenho inferior por parte do reconhecimento/interpretacao
e sıntese/geracao. Isto e explicavel pelo facto de se estar perante um domınio mais complexo, sendo o
dialogo desenvolvido composto por frases de maior dimensao e complexidade.
A seleccao de utilizadores inexperientes teve a vantagem de permitir uma recolha de vocabulario
para o sistema. Esta recolha foi complementada pela recolha feita pelo INOV, tambem com utilizadores
inexperientes, aumentando assim a usabilidade e o vocabulario aceite do sistema.
Apos analise dos registos do sistema foram detectados diversos pequenos problemas, quer ao nıvel
da configuracao dos diversos modulos, quer ao nıvel de alguns pontos na construcao do dialogo.
Por todos os motivos apontados, qualquer trabalho a realizar sobre o sistema LISA requer que
se efectue uma nova avaliacao (que por falta de tempo nao foi realizada), porque se espera que os
resultados sejam bastante superiores, dado todas as correccoes, alteracoes e afinacoes efectuadas.
74
5.2 Con lus~oes e trabalho futuroActualmente a plataforma de dialogo, renomeada recentemente para DIGA (DIaloGue Assistance),
constitui um motivo de interesse. Muito contribuem para isso os tres sistemas implementados em parce-
ria com empresas. Estes sistemas comprovam as capacidades da plataforma face a projectos complexos
de integracao com aplicacoes externas e a desafios do ponto de vista da usabilidade que cada vez mais
e o foco.
Na seccao seguinte apresenta-se um conjunto de trabalhos que ficaram em aberto (sobretudo por
falta de tempo), mas que seguiam duas linhas bem definidas: e necessario melhorar cada vez mais
a usabilidade dos sistemas desenvolvidos, e e necessario simplificar a construcao de novas instancias
sobre a plataforma de dialogo, para agilizar o processo de desenvolvimento e facilitar a difusao da
plataforma de dialogo.
E de salientar que durante o decorrer deste trabalho, estes aspectos tiveram muitas vezes em se-
gundo plano. Foi dada prioridade (i) a recuperacao do trabalho desenvolvido, “limpando” e documen-
tando a solucao para que novos desenvolvimentos sobre a plataforma se possam fazer de forma simples,
rapida e modular, e (ii) a definicao e expansao da interface do sistema para que este tivesse capacidade
de lidar com informacao dinamica proveniente das aplicacoes externas dos parceiros empresariais. No
final deste trabalho podem-se dar por concluıdas estas duas metas. Contudo, e necessario continuar
com novos objectivos orientados a usabilidade, que e o factor chave destas aplicacoes.
O L2F e a VoiceInteraction1, empresa criada no final do projecto TECNOVOZ para desenvolver e co-
mercializar um conjunto de aplicacoes desenvolvidas no laboratorio, apostam agora num novo projecto
para a plataforma de dialogo, sobe a forma de um quiosque para um museu. Este ira exaustivamente
fornecer informacoes sobre uma determinada peca de um museu.
Este sistema impoe a integracao do modulo de pergunta resposta denominado QA@L2F (Mendes,
Coheur, & Mamede, 2007a; Mendes, Coheur, Mamede, Silva Romao, et al., 2007; Mendes, Coheur, &
Mamede, 2007b) com a plataforma de dialogo (figura 4.6). Isto implica a evolucao do actual modelo de
gestao do dialogo, dado que as interaccoes passam a ser perguntas que necessitam de ser analisadas,
possivelmente desambiguadas, e no final o sistema tera que produzir uma resposta. Ir-se-a utilizar
neste sistema a cara virtual como saıda visual do sistema, que tera que espelhar o estado emotivo e da
compreensao do agente.
Para alem do desenvolvimento desse sistema, seria interessante desenvolver um conjunto de traba-
lhos, alguns deles ja iniciados, mas que por falta de tempo nao foram terminados e que podem ajudar a
implementar o novo sistema de quiosque.
1http://www.voiceinteraction.pt
75
5.2.1 Integracao do sistema QA@L2F
A integracao com o sistema de pergunta resposta QA@L2F (ver figura 4.6) era algo ja programado.
Contudo, esta integracao precipitou-se com o aparecimento do projecto para um quiosque de um museu.
Este processo de integracao visa dotar o sistema de dialogo, de capacidade para processar uma
pergunta vinda do utilizador, fornecendo a devida resposta com o recurso a aplicacoes externas e/ou
bases de dados. Neste caso especıfico, a aplicacao externa e um sistema de pergunta e resposta, previ-
amente desenvolvido e onde ja se realizam de forma simples algumas das tarefas realizadas no sistema
de dialogo.
Descricao do sistema
A arquitectura do sistema QA@L2F (figura 5.2) divide-se em dois grandes modulos, que tem como
funcao fazer a analise e interpretacao da pergunta (a semelhanca do que o gestor de interpretacoes faz
no sistema de dialogo de uma forma mais avancada e generalizada), e com base em informacao extraıda
de um corpus pre-processado, extrair a resposta a pergunta recebida.
Figura 5.2: Arquitectura do sistema QA@L2F
O sistema ja modela a informacao recorrendo a enquadramentos, o que simplifica a tarefa de
integracao dos modelos de informacao utilizados. Contudo, o gestor de dialogo nao tem capacidade
para distinguir afirmacoes de interrogacoes tendo que ser o sistema de pergunta e resposta a fornecer
essa informacao ao gestor de interpretacoes.
76
Aspectos a ter em consideracao
O sistema QA@L2F teve como principal motivacao a participacao do laboratorio no forum de avaliacao
CLEF 2, que visa avaliar a capacidade de sistemas informaticos responderem a diferentes perguntas
formuladas em lıngua natural. Estes objectivos nao contemplam a multipla interaccao entre os agentes
envolvidos numa conversacao, limitando a informacao disponıvel a analise da pergunta formulada.
No sistema de quiosque para um museu e possıvel interagir com o visitante, com o objectivo de
desambiguar uma determinada informacao, ou ate mesmo para pedir mais informacao sobre a pergunta
colocada. E necessario analisar as alteracoes que sao necessarias efectuar ao sistema de pergunta e
resposta para que este possa integrar um modelo que contempla o dialogo entre as partes envolvidas,
dialogo esse da responsabilidade do gestor de dialogo.
Por outro lado a participacao do L2F neste forum de avaliacao e recente (foi realizada no ano cor-
rente e no passado), pelo que o desenho do sistema QA@L2F ainda nao se encontra bem definido nem
maduro. E por isso necessario seleccionar a parte do sistema que se encontra mais consistente para
integrar no gestor de dialogo, definindo e fazendo reengenharia dos diferentes modulos incluıdos.
Solucoes possıveis
A integracao do sistema de perguntas e respostas no gestor do dialogo por colocar uma parte de
identificacao e reconhecimento de objectos do sistema QA@L2F, que se encontra actualmente no modulo
de analise e interpretacao da pergunta, na entrada do gestor de dialogo, mais concretamente recorrendo
ao desenvolvimento de um novo processador de linguagem (ver seccao 4.3.1 e seccao 4.3.6). Posterior-
mente e necessario criar um dispositivo que funcionara como interface para o modulo de extraccao da
resposta.
No “meio” do sistema QA@L2F fica o gestor de dialogo, que adiciona uma vertente de dialogo
que o sistema de pergunta e resposta nao preve actualmente. Esta vertente baseia-se no gestor de
interpretacoes, que gera e analisa as interpretacoes com recurso a informacao fornecida pelo modulo
de analise da pergunta do sistema QA@L2F. E posteriormente calculada e verificada a probabilidade de
reconhecimento (probabilidade da informacao extraıda da pergunta gerar uma resposta adequada, que
e medida com recurso as heurısticas definidas em (Mourao, 2005) ou por exemplo ao numero de respos-
tas encontradas, que por sua vez indica se a pergunta e ambıgua). Se esta for superior a um determinado
limiar parametrizavel e enviada a informacao reunida ate ao momento para o modulo de extraccao da
resposta para que seja dada uma resposta ao utilizador. Caso contrario e perguntado o campo em falta
no enquadramento que maximiza a probabilidade de reconhecimento.
2http://linguateca.dei.uc.pt/QACLEF/
77
5.2.2 Introducao da classificacao de actos de fala
A introducao do processo de identificacao de actos de fala no discurso, e um requisito para que
seja possıvel melhorar substancialmente o desempenho do gestor de interpretacoes. Actualmente a
informacao extraıda do texto que entra no gestor de interpretacoes e limitada (mesmo com os desen-
volvimentos descritos na seccao 4.3.6). Esta extraccao e feita atraves da procura de palavras chave
na frase (tal como foi referido na seccao 3.3). Isto leva a que as interpretacoes extraıdas sejam mui-
tas vezes ambıguas e que nao consigam exprimir a verdadeira intencao do utilizador, tornando o pro-
cesso de implementacao de certos domınios complexo. Para suprimir esta limitacao e necessario extrair
informacao semantica da frase proferida pelo utilizador.
Uma correcta identificacao e classificacao de actos de fala, possibilitaria a extraccao de informacao
semantica. Contudo, o desenvolvimento de um modulo para realizar essa tarefa tem sido consecuti-
vamente adiado, por ser um desenvolvimento complexo (so por si uma area de investigacao), e por se
considerar que o gestor de dialogo nao tinha robustez nem arquitectura para suportar esta integracao.
Para alem de preparar a arquitectura, foi tambem analisado o estado da arte na area. Assim,
descreve-se de seguida um resumo do trabalho realizado.
5.2.2.1 Actos de fala
Um acto de fala pode ser definido como a unidade mınima de uma situacao de comunicacao entre
humanos Este contem a informacao acerca do significado (informacao semantica). A classificacao de
um determinado acto de discurso permite saber a intencionalidade do agente que o empregou e, perante
isto, o significado semantico de cada componente frasico.
Esta teoria tem reunido cada vez mais apoiantes por permitir a “modelacao” das interaccoes entre
agentes humanos, fundamental para interpretar os dialogos desenvolvidos do ponto de vista linguıstico,
psicologico e comportamental. Existem inclusivamente linguagens de modelacao do comportamento
de humanos em organizacao, baseadas nesta teoria e na identificacao de padroes comportamentais
(Reijswoud et al., 1999).
Nos actos de fala, segundo (Austin, 1975) existem tres tipos de significados:
• Significado proposicional - significado literal da frase (por exemplo “esta calor aqui”);
• Significado ilocucionario - funcao social do que foi dito (por exemplo “esta calor aqui” pode ser:
i) Um pedido indirecto para alguem abrir a janela, ii) Uma recusa indirecta a alguem que esta a
fechar a janela, iii) Uma queixa para alguem que sabe melhor o porque de deixar a janela fechada,
expressando aborrecimento);
78
• Significado perlocucionario - Accao resultante do acto de fala empregue (por exemplo “esta calor
aqui” pode resultar em alguem abrir a janela).
Mais tarde em (Searle, 1970), concretizando a classificacao levantada por (Austin, 1975), definiram-
-se os seguintes tipos de actos de fala:
• Representativos - afirmam algo (por exemplo assercoes, ordens, relatos);
• Directivos - expressao uma ordem (por exemplo sugestoes, pedidos, comandos);
• Expressivos - associam-se ao comportamento social (por exemplo desculpas, queixas, agradeci-
mentos);
• Imputadores - induzem um comportamento (por exemplo promessas, ameacas, ofertas);
• Declarativos - contextualizam um determinado cenario (por exemplo decretos, declaracoes);
Para alem desta classificacao, os actos de fala ainda se dividem em: i) directos (o seu significado e
extraıdo directamente da interpretacao literal da frase) e ii) indirectos (possuem um significado ilocu-
cionario indirecto, nao sendo directa a sua interpretacao. Por exemplo, na frase “passas-me o sal?”, a
intencao nao e saber se o agente receptor tem a capacidade de passar o sal mas sim ordenar a esse agente
que passe o sal.
5.2.2.2 Apoio a integracao
Com base na analise do estado da arte na area do actos de fala, definiu-se (com base nos sistemas ate
entao implementados) que se iria comecar por identificar os actos do tipo directivos, por serem os que
mais empregues sao durante os dialogos desenvolvidos, maximizando os resultados obtidos.
Foi ainda definida a estrutura de um acto de fala baseada nas directivas de Zachman (Zachman,
1999) (ver figura 5.3). Estas directivas foram escolhidas por terem o objectivo claro de modelar e abordar
o espaco observavel de um determinado problema. A crıtica a estas directivas aponta a falta de definicao
clara do que e que deve ser preenchido em cada campo. No entanto, esta desvantagem revelou-se
vantajosa na medida em que nao e claro como e que se identifica um acto de fala, ou que significado tem
cada um dos fragmentos frasicos do acto de fala. Esta definicao pode (no caso da identificacao de actos
de fala no discurso) ser construıda a medida que a experiencia e o trabalho nesta area for progredindo.
As directivas de Zachman, num processo de modelacao indicam as perguntas base para enumerar
um problema: O que?, Como?, Onde?, Quem?, Quando? e Porque?.
79
Figura 5.3: Estrutura de um acto de discurso.
A identificacao de actos de fala na gestao de dialogo e um requisito para conseguir extrair o cor-
recto significado da frase, baseado na informacao semantica associada a cada fragmento frasico. Res-
pondendo as seis questoes propostas pelas directivas de Zachman, devera ser possıvel interpretar a
intencionalidade da frase, aplicando-se posteriormente esse significado ao contexto em causa.
Apenas pela observacao da estrutura deduz-se que sera necessario expandir as directivas e criar
subcategorias, para que seja possıvel extrair uma correcta interpretacao. Por exemplo, a pergunta
“quando?” podera ser expandida em “de quando?” e “ate quando?”, para conseguir identificar um
evento que tem dois limites temporais, ou por exemplo, a pergunta “onde?” que podera ser expandida
em “de onde?” e “para onde?” para expressar uma deslocacao no espaco.
Utilizando o gestor de processadores de linguagem (descrito na seccao 4.3.1), e possıvel desenvolver
e testar de forma independente um processador de linguagem que identifique os actos de fala presentes
nas frases proferidas pelo utilizador. Incrementalmente pode-se adicionar processos para extracao de
informacao semantica que estara ao dispor do gestor de interpretacoes. Esta informacao sera utilizada
pelo gestor de interpretacoes para que possa, com maior eficiencia, gerar as interpretacoes associadas.
5.2.3 Passagem de informacao atraves emocoes faciais
O fornecimento de informacao sobre o sistema atraves das emocoes faciais, foi um tema que nao foi
abordado durante a realizacao deste trabalho. Isto deve-se ao facto dos desenvolvidos serem sistemas
telefonicos, que tem (actualmente) como unica interface, um telefone, que apenas transmite um sinal so-
noro. No entanto, alguns dos problemas relacionados com o excesso de interpretacoes criadas poderiam
ser resolvidos se o sistema apresentasse uma cara que expressasse o quao confuso esta o sistema nesse
momento.
80
No quiosque para o museu, a cara voltara a ser um factor fundamental. Esta nao so torna o sistema
desenvolvido mais apelativo, como tambem possibilita a transmicao de um conjunto de informacoes
sobre o estado do sistema em cada momento atraves da expressividade da cara. Para alem do sistema de
quiosque, se os sistemas baseados na interface telefonica vierem a evoluir para um modelo de chamadas
3G (Jabri, 2004), podera ser interessante ter uma cara animada que torna em simultaneo a interface mais
cativante do ponto de vista comercial e mais eficiente.
Tal como foi referido na seccao 2.1.2.1, a arquitectura do gestor de dialogo ja possui um modulo
responsavel por tratar a parte comportamental e emocional do sistema (o agente comportamental), que
se encontra numa fase inicial. Seria interessante no futuro e com vista aos novos projectos a realizar,
desenvolver este modulo por forma a este gerar informacao comportamental para a cara virtual. A cara
virtual e animavel dinamicamente, recebendo como entrada uma estrutura XML no formato VHML3
(Beard & Reid, 2002; Viveiros, 2004).
O sistema Ambrosio ja utiliza a cara virtual. No entanto, apenas dispoem de uma maquina de
estados simples, para fornecer informacoes basicas: a cara fica pensativa enquanto o reconhecedor e o
sistema de dialogo processam a entrada, cerra os olhos quando recebe audio atraves do microfone, e
volta a uma posicao neutra quando esta pronto a receber uma nova ordem.
O objectivo seria desenvolver a maquina de estados existente, incluindo estados ao nıvel do dialogo.
O sistema pode, por exemplo, ficar confuso quando existem muitas interpretacoes, ou expressar descon-
tentamento quando nao percebe o que o utilizador disse.
Seria interessante, numa fase posterior, desenvolver a interface do sistema de dialogo para que
fosse possıvel anotar nas regras de geracao, a emocao associada a cada frase, tornando as interaccoes
mais naturais. Por exemplo, quando o sistema proferisse uma frase afirmativa ou negativa podia acenar
com a cabeca fazendo o respectivo gesto, ou ate mesmo mostrar-se desapontado quando nao consegue
executar um determinado servico. Com base nisto podia-se ainda definir uma escala emocional, que
comecaria num estado de felicidade e terminaria num estado de frustracao, variando o estado de espırito
do agente conforme uma determinada personalidade. O agente podia ficar mais contente quando con-
segue realizar muitas tarefas simultaneamente e desapontado se falhasse, ou pelo contrario apresentar
um ar cansado quando realiza muitas tarefas num curto espaco de tempo. Esta personalidade tem que
ser facilmente parametrizavel para que de forma simples se consiga adaptar a mesma ao domınio em
causa.
3http://www.vhml.org/
81
5.2.4 Definicao de ontologias de domınio para automatizacao do desenvolvimento
de novos sistemas
Um dos factores que mais dificulta o processo de desenvolvimento de uma nova instancia do sistema
de dialogo e a quantidade de informacao que e necessario providenciar a interface de desenvolvimento
(definicao do enquadramento, servicos, entre outras).
Uma forma de reduzir esta informacao, tornando o processo de desenvolvimento menos complexo
e por consequente mais eficiente seria a criacao de uma ontologia de domınios para o sistema de dialogo.
Por exemplo, quando se pretende vender bilhetes de transportes e de espectaculos, existe um conjunto
de informacoes (por exemplo campos do enquadramento) que sao partilhadas: a existencia de um preco
associado ao bilhete, de uma hora inıcio, opcionalmente de um lugar associado, entre outras.
Se a informacao especificada fosse reaproveitada para a definicao de novos domınios, poderia-se
diminuir substancialmente a quantidade de informacao a providenciar ao sistema. Esta quantidade de
informacao seria tao menor quanto a proximidade dos domınios. Por exemplo, para criar um sistema
de venda de bilhetes de comboio e possıvel aproveitar a maioria das informacoes definidas para um
sistema de venda de bilhetes de autocarros.
Associando-se a esta partilha de informacao uma interface grafica, onde fosse possıvel escolher qual
a informacao a aproveitar e onde fosse possıvel completar directamente a definicao com a informacao
em falta, poderia aumentar a eficiencia do processo de desenvolvimento, aumentando a aceitacao e
adequacao da interface.
5.2.5 Desenvolvimentos baseados na web
Atraves da web e possıvel hoje consultar todo o tipo de informacao de forma relativamente estruturada
e organizada.
Na area dos sistemas de dialogo cada vez mais se veem sistemas baseados na web (Cai-xia et al.,
2005; Gatius et al., 2007; Gruenstein et al., 2006; Allen et al., 2007), que utilizam a informacao estruturada
existente na web, para providenciar uma interface de dialogo para os mais diversos servicos. Com o
conceito de web semantica4 cada vez mais em voga (Aberer et al., 2007; Zhdanova et al., 2007; Piskac et
al., 2007) esta e uma oportunidade para a area dos sistemas de dialogo, mostrar e assumir o potencial
que tem face a esta nova realidade.
Em particular, este tipo de informacao e algo que poderia ser facilmente utilizado pela plataforma
de sistemas de dialogo DIGA, providenciando assim uma interface de dialogo/voz para um conjunto
4http://www.w3.org/2001/sw/; http://www.w3schools.com/semweb/default.asp
82
variado de informacoes existentes na web. Como o sistema modela a informacao recorrendo a enqua-
dramentos, poder-se-ia associar um campo do enquadramento a uma determinada etiqueta HTML que
contem o conjunto de informacoes referentes a esse campo. Assim, seria possıvel mapear os diferentes
formularios existentes na web em enquadramentos para novas instancias da plataforma DIGA.
Utilizando uma ontologia de domınios tal como a descrita na seccao 5.2.4, poder-se-ia construir
um conjunto de instancias do sistema de dialogo de forma simples. Por exemplo, poder-se-ia construir
instancias para: aceder as mais diversas informacoes (meteorologia, informacao bolsista, entre outras),
fazer reservas da mais diversa natureza (hoteis, transportes, entre outras), entre outros servicos.
O sistema actualmente ja se encontra preparado para este tipo de adaptacoes, dado que os desen-
volvimentos descritos no capıtulo 3 e na seccao 4.3 permitem em tempo de execucao providenciar e
actualizar a informacao necessaria ao sistema de dialogo.5.3 Contribui� ~oesEste trabalho contribuiu sobretudo para recuperar uma vertente de investigacao na area dos sistemas
de dialogo no L2F, recuperando o trabalho previamente realizado e introduzindo novos vectores para
estimular um maior investimento nesta area com cada vez mais potencial.
Foram publicados tres artigos em conferencias internacionais (Martins, Mendes, Viveiros, et al.,
2008; Martins, Mendes, Pardal, et al., 2008; Martins, Pardal, et al., 2008).
Em (Martins, Mendes, Viveiros, et al., 2008) (Reengineering a domain-independent framework for Spo-
ken Dialogue Systems, Software Engineering, Testing, and Quality Assurance for Natural Language Processing
Workshop, ACL 2008) descreve-se o processo de reengenharia do gestor de dialogo.
Em (Martins, Mendes, Pardal, et al., 2008) (Using system expectations to manage user interactions, PRO-
POR 2008) decreve-se o desenvolvimento do gestor de processadores de linguagem utilizando etiquetas
para os tipos de dados (FREE TEXT, DATE, entre outras).
Em (Martins, Pardal, et al., 2008) (Starting to cook a tutoring dialogue system, SLT 2008) descreve-se
um prototipo de sistema de dialogo desenvolvido para auxiliar tarefas culinarias. Este trabalho teve
inıcio antes desta tese, tendo sido publicado ainda no decorrer da mesma.
Para alem dos artigos publicados foi elaborado o documento de especificacao da API da plataforma
DIGA, descrevendo detalhadamente e apresentando exemplos das diversas caracterısticas acessıveis a
partir da interface do gestor de dialogo.
Em resumo as contribuicoes descritas neste trabalho foram:
• Definicao de um modelo para avaliacao de sistemas de dialogo;
83
• Avaliacao do sistema de dialogo recorrendo ao sistema Ambrosio;
• Reengenharia do sistema de dialogo;
• Desenvolvimento e integracao de um gestor de eventos;
• Desenvolvimento de um gestor de processadores de linguagem e inclusao de uma categorizacao
de tipos de dados (Martins, Mendes, Pardal, et al., 2008);
• Integracao da cadeia de processamento morfossintactico XIP;
• Aumento da expressividade das regras de identificacao e reconhecimento de objectos;
• Desenvolvimento, definicao e especificacao das interfaces externas (gestor de dialogo e gestor de
servicos);
• Reorganizacao do codigo e do sistema de ficheiros do sistema de dialogo;
• Promocao e utilizacao de tecnicas de proteccao da propriedade intelectual da solucao desenvol-
vida;
• Desenvolvimento de processadores de linguagem independentes do domınio para reconheci-
mento de numeros e dıgitos, expressoes temporais simples e quantias monetarias;
• Integracao do sistema de dialogo com o novo gestor de entradas e saıdas;
• Introducao de diversas metodologias de prevencao e recuperacao de erros (validacoes,
confirmacoes explicitas, hierarquia de dialogos, entre outras);
• Introducao de tecnicas de parametrizacao dinamica do contexto do dialogo;
• Apoio a documentacao e elaboracao do documento que especifica a API do sistema de dialogo.
Em particular no desenvolvimento do sistema LISA foi(foram):
• Desenvolvidos os servicos de gestao de estado, envio de mensagens, marcacao de notas e eventos,
redireccionamento de chamadas, marcacao por voz, consulta da agenda e gestao de voice mail;
• Desenvolvidos diversos modelos de linguagem para o reconhecedor, referentes aos diferentes
servicos implementados, destacando o modelo de linguagem para marcacao de eventos que per-
mite o reconhecimento de expressoes temporais simples;
• Desenvolvido um servico web com uma interface WSDL para gestao de diversas instancias do
sistema LISA, que comunica directamente com o sistema atraves do gestor de eventos;
• Desenvolvida toda a camada de comunicacao com a plataforma INOV, utilizando SOAP e WSDL;
84
• Instalada e mantida uma arquitectura com seis instancias do sistema LISA (num mesmo compu-
tador), para procedimentos de teste e desenvolvimento de ambas as partes (L2F e INOV), sendo
utilizada posteriormente para demonstracoes publicas;
• Avaliado sistema LISA.
Especificamente para os sistemas de banca e bolsa telefonica, as contribuicoes foram:
• Desenvolvimento da primeira versao da camada de comunicacao SOAP/WSDL entre o L2F e a
Promosoft;
• Introducao da especificacao dos eventos Voice XML, noinput, nomatch e help em conjunto com as
regras de geracao, para utilizacao das mesmas atraves da interface Voice XML do novo gestor de
entradas e saıdas;
• Diversos incrementos a interface com os dispositivos (codigo Java) para versatilizar o modo com
as validacoes dos diversos parametros sao efectuadas.
Para alem das contribuicoes descritas nesta tese, foi ainda concluıda a primeira versao do quiosque
para o Museu Nacional de Arte Antiga, referente a peca “Custodia de Belem”, que inclui:
• Desenvolvimento e integracao de uma versao simples do sistema de pergunta e resposta;
• Apoio ao desenvolvimento de um corpus sobre a “Custodia de Belem”, para ser utilizado pelo
sistema de pergunta e resposta;
• Apoio a construcao de uma nova cara virtual em tres dimensoes para o agente “Duarte”, que
responde a perguntas sobre a custodia;
• Desenvolvimento e integracao de uma maquina de estados emocional para o agente, que transmite
a cara virtual o estado emotivo do agente em cada momento, para que a cara possa expressar esse
estado visualmente;
• Desenvolvimento de uma interface web textual para o sistema de dialogo, para testes e desenvol-
vimento do corpus sobre a “Custodia de Belem”;
• Apoio ao desenvolvimento de um modelo de linguagem para o sistema de dialogo referente a
“Custodia de Belem”, baseado no corpus utilizado no sistema de pergunta e resposta;
• Apoio ao desenvolvimento de um modulo generico de comunicacao do sistema de dialogo com o
novo gestor de entradas e saıdas;
85
• Integracao de um servidor web no codigo do gestor de dialogo, para alojamento da interface web
textual e o modulo de comunicacao com o novo gestor de entradas e saıdas, bem como de diversas
ferramentas para identificacao e depuracao de erros;
• Expansao da interface do gestor de dialogo para permitir a comunicacao com diversos dispositivos
de entrada e saıda;
O sistema para o Museu Nacional de Arte Antiga comecou a ser desenvolvido em Julho de 2008
tendo sido concluıda a sua primeira versao em Setembro de 2008. A descricao deste sistema foi incluıda
neste trabalho fundamentalmente por falta de tempo.
86
BibliographyAberer, K., et al. (Eds.). (2007). The semantic web, 6th international semantic web conference, 2nd asian semantic
web conference, iswc 2007 + aswc 2007, busan, korea, november 11-15, 2007. Springer.
Ait-Mokhtar, S., Chanod, J.-P., & Roux, C. (2001, October). A multi-input dependency parser. In Procee-
dings of the Seventh IWPT (International Workshop on Parsing Technologies). Beijing, China: Tsinghua
University Press.
Allen, J., Byron, D., Dzikovska, M., Ferguson, G., & Galescu, L. (2001). Toward conversational human-
computer interaction. AI Magazine, 22(4), 27–37.
Allen, J., Byron, D., Dzikovska, M., Ferguson, G., Galescu, L., & Stent, A. (2000). An architecture for a
generic dialogue shell. NLENG: Natural Language Engineering, 6(3-4), 213–228.
Allen, J., Chambers, N., Ferguson, G., Galescu, L., Jung, H., & Taysom, W. (2007). Plow: A collaborative
task learning agent. In In proc. conference on artificial intelligence (aaai) (pp. 22–26). City of Vancouver,
British Columbia, Canada: AAAI Press.
Allen, J., Ferguson, G., & Stent, A. (2001). An architecture for more realistic conversational systems. In
Iui ’01: Proceedings of the 6th international conference on intelligent user interfaces (pp. 1–8). New York,
NY, USA: ACM.
Aust, H., Oerder, M., Seide, F., & Steinbiss, V. (1995). The philips automatic train timetable information
system. Speech Commun., 17(3-4), 249–262.
Austin, J. (1975). How to do things with words: Second edition. Harvard University Press.
Bass, L., Clements, P., & Kazman, R. (2003). Software architecture in practice, second edition. Addison-Wesley
Professional.
Bayer, S., Doran, C., & George, B. (2001). Exploring speech-enabled dialogue with the galaxy commu-
nicator infrastructure. In Hlt ’01: Proceedings of the first international conference on human language
technology research (pp. 1–3). Morristown, NJ, USA: Association for Computational Linguistics.
Beard, S., & Reid, D. (2002, July). MetaFace and VHML: A First Implementation of the Virtual Human
Markup Language. In Proceedings of embodied conversational agents - let’s specify and evaluate them!
for aamas 2002. Bologna, Italy: ACM.
87
Bernsen, N. O., & Dybkjaer, L. (1999). Spoken language dialogue systems and components: Best practice in
development and evaluation (disc working paper d3.8a).
Bernsen, N. O., & Dybkjær, L. (n.d.). Is that a good spoken language dialogue system?
Bernsen, N. O., & Dybkjær, L. (2000). A methodology for evaluating spoken language dialogue systems
and their components. In In luperfoy, s. (ed.): Automatic spoken dialogue systems (pp. 183–188). MIT
Press.
Bernsen, N. O., Dybkjær, L., & Heid, U. (1998). Current practice in the development and evaluation of
spoken language dialogue systems. disc deliverable d1.8. http://www.disc2.dk. In Proceedings of
eurospeech’99 (pp. 1147–1150). International Speech Communication Association.
Burstein, M., Ferguson, G., & Allen, J. (2000). Integrating agent-based mixed-initiative control with an
existing multi-agent planning system. In Icmas ’00: Proceedings of the fourth international conference
on multiagent systems (icmas-2000) (p. 389). Washington, DC, USA: IEEE Computer Society.
Cai-xia, Y., Jing-hua, W., Jian-yi, L., & Cong, W. (2005, March). The web-based domain independent dm
for intelligent spoken dialog system. Networking, Sensing and Control, 2005. Proceedings. 2005 IEEE,
1027–1030.
Cassaca, R., & Maia, R. (2002). Assistente electronica. Trabalho final de curso, Instituto Superior Tecnico,
Universidade Tecnica de Lisboa.
Charfuelan, M., Lopez, C. E., Gil, J. R., Rodrıguez, M. C., & Gomez, L. H. (2000). A general evaluation fra-
mework to assess spoken language dialogue systems: Experience with call center agent systems.
In Proceedings of taln 2000.
Clements, P., Garlan, D., Bass, L., Stafford, J., Nord, R., Ivers, J., et al. (2002). Documenting software
architectures: Views and beyond. Pearson Education.
Coelho, G. E. (2007). Utilizacao de arrays de microfones para sistemas de reconhecimento de fala. Unpublished
master’s thesis, Instituto Superior Tecnico, Universidade Tecniva de Lisboa.
Coelho, G. E., Serralheiro, A. J., & Neto, J. (2008). Microphone array front-end interface for home auto-
mation. In HSCMA 2008, workshop on hands-free speech communication and microphone arrays (p. 184
- 187). Trento, Italy: IEEE.
Companions project. (2008). http://www.companions-project.org/research/dms.cfm .
Dybkjær, L., & Bernsen, N. O. (2001). Usability evaluation in spoken language dialogue systems. In
Proceedings of the workshop on evaluation for language and dialogue systems (pp. 1–10). Morristown,
NJ, USA: Association for Computational Linguistics.
88
Dybkjær, L., Bernsen, N. O., & Dybkjær, H. (1996). Abstract different spoken language dialogues for different
tasks a task-oriented dialogue theory.
Ferguson, G., Allen, J., Blaylock, N., Byron, D., Chambers, N., Dzikovska, M., et al. (2002). The Medication
Advisor project: Preliminary report.
Freeman, E., Freeman, E., Bates, B., & Sierra, K. (2004). Head first design patterns. O’Reilly.
Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design patterns: Elements of reusable object-oriented
software. Addison-Wesley Professional Computing Series.
Gatius, M., Gonzalez, M., & Comelles, E. (2007). An information state-based dialogue manager for making
voice web smarter. In Www ’07: Proceedings of the 16th international conference on world wide web (pp.
1315–1316). New York, NY, USA: ACM.
Glass, J., & Weinstein, E. (2001, September). SPEECHBUILDER: Facilitating Spoken Dialogue System
Development. In Proc. european conference on speech communication and technology (pp. 1335–1339).
Aalborg, Denmark: International Speech Communication Association.
Grice, H. P. (1975). Logic and conversation. In P. Cole & J. L. Morgan (Eds.), Syntax and semantics: Vol. 3:
Speech acts (p. 41-58). San Diego, CA: Academic Press.
Gruenstein, A., Seneff, S., & Wang, C. (2006). Scalable and portable web-based multimodal dialogue
interaction with geographical databases. In Proceedings of interspeech-2006. ISCA.
Hagege, C., Baptista, J., & Mamede, N. J. (2008, April). Directivas sobre o tempo. available at:
http://acdc.linguateca.pt/aval_conjunta/HAREM/2008_ 04_13_Tempo.pdf
. (Proposed to HAREM II, Portuguese named entities recognition evaluation forum (http://
www.linguateca.pt/HAREM/ ))
Jabri, M. (2004, July-Sept.). The 3g-324m protocol for conversational video telephony. Multimedia, IEEE,
11(3), 102-105.
Jung, H., Allen, J. F., Galescu, L., Chambers, N., Swift, M., & Taysom, W. (2008). Utilizing natural language
for one-shot task learning. J. Log. Comput., 18(3), 475-493.
Lamel, L., Rosset, S., & Gauvain, J. luc. (2000). Considerations in the design and evaluation of spoken
language dialog systems. In In icslp. ISCA.
Litman, D. J., & Pan, S. (2002). Designing and evaluating an adaptive spoken dialogue system. User
Modeling and User-Adapted Interaction, 12(2-3), 111–137.
Martins, F., Mendes, A., Pardal, J. P., Mamede, N. J., & Silva Neto, J. P. da. (2008, June). Using system
expectations to manage user interactions.
89
Martins, F., Mendes, A., Viveiros, M., Pardal, J. P., Arez, P., Mamede, N. J., et al. (2008, June). Reengineering
a domain-independent framework for spoken dialogue systems.
Martins, F., Pardal, J. P., Franqueira, L., Arez, P., & Mamede, N. J. (2008, December). Starting to cook a
tutoring dialogue system.
McTear, M. (n.d.). New directions in spoken dialogue technology for pervasive interfaces.
McTear, M. F. (2002). Spoken dialogue technology: enabling the conversational user interface. ACM
Comput. Surv., 34(1), 90–169.
Medeiros, J. C. (1995). Processamento morfologico e correccao ortografica do portugues. Unpublished master’s
thesis, Instituto Superior Tecnico – Universidade Tecnica de Lisboa, Portugal.
Meinedo, H., Caseiro, D., Neto, J. P., & Trancoso, I. (2003). Audimus.media: A broadcast news speech
recognition system for the european portuguese language. In N. J. Mamede, J. Baptista, I. Trancoso,
& M. das Gracas Volpe Nunes (Eds.), PROPOR (Vol. 2721, p. 9-17). Springer.
Mendes, A., Coheur, L., & Mamede, N. J. (2007a, December). Qa@l2f: First steps. 13-20.
Mendes, A., Coheur, L., & Mamede, N. J. (2007b, December). Question-answering using a constraint
relaxation mechanism.
Mendes, A., Coheur, L., Mamede, N. J., Silva Romao, L. C. da, Loureiro, J. M. S., Ribeiro, R. D., et al. (2007,
September). Qa@l2f@qa@clef.
Moura Rodrigues, D. J. G. de. (2007). Uma evolucao do sistema shrep. optimizacao, interface grafica e integracao
de mais duas ferramentas. Unpublished master’s thesis, Instituto Superior Tecnico, Universidade
Tecnica de Lisboa.
Mourao, M. A. (2005). Gestao e representacao de domınios em sistemas de dialogo. Tese de mestrado, Instituto
Superior Tecnico, Universidade Tecnica de Lisboa.
Oliveira, L. C., Viana, M. C., Mata, A. I., & Trancoso, I. M. (2001). Progress report of project dixi+: A portuguese
text-to-speech synthesizer for alternative and augmentative communication (Tech. Rep.). FCT.
Pardal, J. P., & Mamede, N. J. (2004, Novembro). Terms Spotting with Linguistics and Statistics. 298-304.
Paulo, S., Oliveira, L. C., Mendes, C., Figueira, L., & Viana, C. (2008, June). Dixi - a generic text-to-speech
system for european portuguese.
Piskac, R., Harmelen, F. van, & Zhong, N. (Eds.). (2007). Proceedings of the first international workshop
workshop “new forms of reasoning for the semantic web: scalable, tolerant and dynamic“, co-located with
iswc 2007 and aswc 2007, busan, korea, november 11th, 2007. CEUR-WS.org.
90
Rao, A. S., & Georgeff, M. P. (1995). Bdi agents: From theory to practice. In Icmas. San Francisco: The MIT
Press.
Reijswoud, V. E. van, Mulder, J., & Dietz, J. L. (1999). Speech act based business process and information
modeling with demo. Information Systems Journal.
Ribeiro, R., Mamede, N. J., , & Trancoso, I. (2003). Using Morphossyntactic Information in TTS Systems:
comparing strategies for European Portuguese. In Computational processing of the portuguese lan-
guage: 6th international workshop, propor 2003, faro, portugal, june 26-27, 2003. proceedings (Vol. 2721).
Springer.
Rich, C., Sidner, C. L., & Lesh, N. (2001). Collagen: applying collaborative discourse theory to human-
computer interaction. AI Mag., 22(4), 15–25.
Rodrigues, M., Mourao, M., & Madeira, P. (2002). Gestor de dialogos. Trabalho final de curso, Instituto
Superior Tecnico, Universidade Tecnica de Lisboa.
Searle, J. R. (1970). Speech acts: An essay in the philosophy of language. Cambridge University Press.
Taylor, P. A., Black, A., & Caley, R. (1998). The architecture of the festival speech synthesis system. In The
third esca workshop in speech synthesis (p. 147-151). Jenolan Caves, Australia: Cambridge University.
Viveiros, M. F. (2004). Cara falante - uma interface visual para um sistema de dialogo falado. Trabalho final de
curso, Instituto Superior Tecnico, Universidade Tecnica de Lisboa.
Walker, M., Litman, D., Kamm, C., & Abella, A. (1998). Evaluating spoken dialogue agents with paradise: Two
case studies.
Walker, M. A., Fromer, J., Fabbrizio, G. D., Mestel, C., & Hindle, D. (1998). What can i say?: evaluating a
spoken language interface to email. In Chi ’98: Proceedings of the sigchi conference on human factors
in computing systems (pp. 582–589). New York, NY, USA: ACM Press/Addison-Wesley Publishing
Co.
Walker, M. A., J., D. L., Kamm, C. A., & Abella, A. (1997). PARADISE: A framework for evaluating
spoken dialogue agents. In P. R. Cohen & W. Wahlster (Eds.), Proceedings of the thirty-fifth annual
meeting of the Association for Computational Linguistics and eighth conference of the European chapter of
the Association for Computational Linguistics (pp. 271–280). Somerset, New Jersey: Association for
Computational Linguistics.
Zachman, J. A. (1999). A framework for information systems architecture. IBM Syst. J., 38(2-3), 454–470.
Zhdanova, A. V., Nixon, L. J. B., Mochol, M., & Breslin, J. G. (Eds.). (2007). Proceedings of the 2nd internati-
onal iswc+aswc workshop on finding experts on the web with semantics, busan, korea, november 12, 2007.
CEUR-WS.org.
91
92
IAppendi es
AAn�alise de resultados daavalia� ~ao ao sistemaAmbr�osio
• Numero de utilizadores = 10
• Media de idades = 25,5
Metricas
1) Tempo decorrido (em segundos)
2) Numero de iteracoes do sistema
3) Numero de iteracoes do interveniente
4) Numero de palavras utilizadas pelo sistema
5) Numero de palavras utilizadas pelo interveniente
6) Numero de erros devido a uma compreensao parcial
7) Numero de erros devido a uma falha total na compreensao
8) Numero de erros que impediram o sistema de progredir
9) Numero de pedidos de ajuda a equipa
10) A tarefa foi executada com sucesso? (1 – Sim / 0 – Nao)
A.1 Experien ia dos utilizadoresUtilizador 1 experiente
Utilizador 2 experiente
Utilizador 3 semi-experiente
Utilizador 4 inexperiente
Utilizador 5 semi-experiente
Utilizador 6 experiente
Utilizador 7 inexperiente
Utilizador 8 experiente
Utilizador 9 inexperiente
Utilizador 10 inexperienteA.2 Registo de resultadosA.2.1 Tarefa 1
Utilizador 1 2 3 4 5 6 7 8 9 10 Media Desvio Padrao
1) 7,5 6 9 6,5 6 5,5 16 5 7,5 10 7,9 3,3541
2) 1 1 1 1 1 1 2 1 1 1 1,1 0,3333
3) 1 1 1 1 1 1 2 1 1 1 1,1 0,3333
4) 6 6 6 6 6 6 11 6 6 6 6,5 1,6667
5) 5 4 5 5 5 5 10 5 5 8 5,7 1,7401
6) 0 0 0 0 0 0 1 0 0 0 0,1 0,3333
7) 0 0 0 0 0 0 0 0 0 0 0 0
8) 0 0 0 0 0 0 0 0 0 0 0 0
9) 0 0 0 0 0 0 0 0 0 0 0 0
10) 1 1 1 1 1 1 1 1 1 1 1 0
96
A.2.2 Tarefa 2
Utilizador 1 2 3 4 5 6 7 8 9 10 Media Desvio Padrao
1) 7,5 6 8,5 5 28 7 6,5 5 36 27 13,65 11,476
2) 1 1 1 1 3 1 1 1 2 2 1,4 0,7071
3) 1 1 1 1 3 1 1 1 3 5 1,8 0,8819
4) 6 6 6 6 18 6 6 6 17 12 8,9 5,0772
5) 5 4 5 5 15 5 5 5 15 15 7,9 4,4845
6) 0 0 0 0 1 0 0 0 0 1 0,2 0,3333
7) 0 0 0 0 1 0 0 0 2 3 0,6 0,7071
8) 0 0 0 0 0 0 0 0 0 0 0 0
9) 0 0 0 0 0 0 0 0 0 0 0 0
10) 1 1 1 1 1 1 1 1 1 1 1 0
A.2.3 Tarefa 3
Utilizador 1 2 3 4 5 6 7 8 9 10 Media Desvio Padrao
1) 5,5 6,5 5 50 22 6,5 4 6 32 6 14,35 16,198
2) 1 1 1 3 4 1 1 1 2 1 1,6 1,118
3) 1 1 1 8 4 1 1 1 3 1 2,2 2,3979
4) 5 5 5 37 21 5 5 5 9 5 10,2 11,155
5) 4 3 4 23 13 4 4 4 12 12 8,3 6,8089
6) 0 0 0 2 3 0 0 0 1 0 0,6 1,118
7) 0 0 0 5 1 0 0 0 1 0 0,7 1,6415
8) 0 0 0 0 0 0 0 0 0 0 0 0
9) 0 0 0 0 0 0 0 0 0 0 0 0
10) 1 1 1 1 1 1 1 1 1 1 1 0
97
A.2.4 Tarefa 4
Utilizador 1 2 3 4 5 6 7 8 9 10 Media Desvio Padrao
1) 13,5 21 19 17,5 57 20 40 31,5 43,5 43 30,6 14,742
2) 2 2 2 2 5 2 4 5 3 4 3,1 1,3229
3) 2 3 3 2 7 2 4 6 4 6 3,9 1,8028
4) 12 12 12 12 37 12 20 25 17 24 18,3 8,6168
5) 10 12 11 13 33 13 19 22 29 25 18,7 8,3815
6) 0 0 0 1 2 1 4 3 2 2 1,5 1,424
7) 0 1 1 5 4 0 0 2 2 3 1,8 1,8028
8) 0 0 0 0 0 0 0 0 0 0 0 0
9) 0 0 0 0 0 0 0 0 0 0 0 0
10) 1 1 1 1 1 1 1 1 1 1 1 0
A.2.5 Tarefa 5
Utilizador 1 2 3 4 5 6 7 8 9 10 Media Desvio Padrao
1) 8 6 27,5 8,5 7 6 6,5 5 5 28,5 10,8 7,1019
2) 1 1 3 1 1 1 1 1 1 2 1,3 0,6667
3) 1 1 3 1 1 1 1 1 1 3 1,4 0,6667
4) 4 4 19 5 4 4 4 5 5 15 6,9 4,899
5) 6 5 18 6 6 5 6 3 6 15 7,6 4,3237
6) 0 0 0 2 3 0 0 0 0 1 0,6 1,1304
7) 0 0 2 5 1 0 0 0 0 11 1,9 1,6915
8) 0 0 0 0 0 0 0 0 0 1 0,1 0
9) 0 0 0 0 0 0 0 0 0 0 0 0
10) 1 1 1 1 1 1 1 1 1 0 0,9 0
98
A.2.6 Tarefa 6
Utilizador 1 2 3 4 5 6 7 8 9 10 Media Desvio Padrao
1) 7,5 6,5 6,5 7,5 5,5 5,5 6,5 6 25,5 21,5 9,85 6,3955
2) 1 1 1 1 1 1 1 1 1 2 1,1 0
3) 1 1 1 1 1 1 1 1 3 3 1,4 0,6667
4) 4 3 4 4 4 4 4 4 4 9 4,4 0,3333
5) 3 2 3 3 3 3 6 3 3 8 3,7 1,0929
6) 0 0 0 0 0 0 0 0 0 1 0,1 0
7) 0 0 0 0 0 0 0 0 2 0 0,2 0,6667
8) 0 0 0 0 0 0 0 0 0 0 0 0
9) 0 0 0 0 0 0 0 0 0 1 0,1 0
10) 1 1 1 1 1 1 1 1 1 1 1 0
A.2.7 Tarefa 7
Utilizador 1 2 3 4 5 6 7 8 9 10 Media Desvio Padrao
1) 6 5 6,5 60 6 8,5 22 5,5 28 10 15,75 18,345
2) 1 1 1 7 1 1 1 1 3 1 1,8 2,0276
3) 1 1 1 8 1 1 2 1 3 2 2,1 2,3154
4) 4 4 4 68 4 4 4 4 23 4 12,3 21,481
5) 5 4 5 28 5 5 10 5 13 10 9 7,7692
6) 0 0 0 1 0 0 0 0 2 1 0,4 0,7071
7) 0 0 0 7 0 0 1 0 0 0 0,8 2,3154
8) 0 0 0 0 0 0 0 0 0 0 0 0
9) 0 0 0 0 0 0 0 0 0 0 0 0
10) 1 1 1 0 1 1 1 1 1 0 0,8 0,3333
99
A.2.8 Tarefa 8
Utilizador 1 2 3 4 5 6 7 8 9 10 Media Desvio Padrao
1) 7 4 47,5 60 4,5 5 14,5 6 13 45,5 20,7 20,868
2) 1 1 2 3 1 1 2 1 1 5 1,8 0,7265
3) 1 1 5 6 1 1 2 1 2 6 2,6 1,9221
4) 4 1 11 22 4 4 8 4 4 32 9,4 6,353
5) 3 2 11 13 3 3 6 3 6 24 7,4 3,9405
6) 0 0 0 0 0 0 0 0 0 5 0,5 0
7) 0 0 3 6 0 0 1 0 1 0 1,1 2,048
8) 0 0 0 0 0 0 0 0 0 0 0 0
9) 0 0 0 0 0 0 0 0 0 0 0 0
10) 1 1 1 0 1 1 1 1 1 0 0,8 0,3333
A.2.9 Tarefa 9
Utilizador 1 2 3 4 5 6 7 8 9 10 Media Desvio Padrao
1) 14,5 30,5 40 60 54 34 21,5 40,5 6,5 27 32,85 17,525
2) 2 2 2 3 5 4 2 4 2 3 2,9 1,1667
3) 2 4 6 12 7 4 2 6 1 4 4,8 3,3706
4) 8 5 9 19 24 22 11 16 13 17 14,4 6,5659
5) 6 8 16 27 24 15 10 14 7 17 14,4 7,4068
6) 0 0 0 2 3 1 1 1 0 2 1 1,0541
7) 0 0 4 10 3 1 0 3 0 0 2,1 3,2787
8) 0 0 0 0 0 0 0 0 0 0 0 0
9) 0 0 0 0 0 0 0 0 0 0 0 0
10) 1 1 1 0 1 1 1 1 1 1 0,9 0,3333
100
A.3 Tempo gasto por tarefaUtilizador 1 2 3 4 5 6 7 8 9 10
Tarefa 1 7,5 6 9 6,5 6 5,5 16 5 10 10
Tarefa 2 7,5 6 8,5 5 28 7 6,5 5 27 27
Tarefa 3 5,5 6,5 5 50 22 6,5 4 6 6 6
Tarefa 4 13,5 21 19 17,5 57 20 40 31,5 43 43
Tarefa 5 8 6 27,5 8,5 7 6 6,5 5 28,5 28,5
Tarefa 6 7,5 6,5 6,5 7,5 5,5 5,5 6,5 6 21,5 21,5
Tarefa 7 6 5 6,5 60 6 8,5 22 5,5 10 10
Tarefa 8 7 4 47,5 60 4,5 5 14,5 6 45,5 45,5
Tarefa 9 14,5 30,5 40 60 54 34 21,5 40,5 27 27
Media 8,56 10,17 18,83 30,56 21,11 10,89 15,28 12,28 24,28 24,28A.4 Numero de palavras utilizadas pelo sistemaUtilizador 1 2 3 4 5 6 7 8 9 10
Tarefa 1 6 6 6 6 6 6 11 6 6 6
Tarefa 2 6 6 6 6 18 6 6 6 12 12
Tarefa 3 5 5 5 37 21 5 5 5 5 5
Tarefa 4 12 12 12 12 37 12 20 25 24 24
Tarefa 5 4 4 19 5 4 4 4 5 15 15
Tarefa 6 4 3 4 4 4 4 4 4 9 9
Tarefa 7 4 4 4 68 4 4 4 4 4 4
Tarefa 8 4 1 11 22 4 4 8 4 32 32
Tarefa 9 8 5 9 19 24 22 11 16 17 17
Media 5,89 5,11 8,44 19,89 13,56 7,44 8,11 8,33 13,78 13,78
101
A.5 Numero de palavra utilizadas pelo utilizadorUtilizador 1 2 3 4 5 6 7 8 9 10
Tarefa 1 5 4 5 5 5 5 10 5 5 8
Tarefa 2 5 4 5 5 15 5 5 5 15 15
Tarefa 3 4 3 4 23 13 4 4 4 12 12
Tarefa 4 10 12 11 13 33 13 19 22 29 25
Tarefa 5 6 5 18 6 6 5 6 3 6 15
Tarefa 6 3 2 3 3 3 3 6 3 3 8
Tarefa 7 5 4 5 28 5 5 10 5 13 10
Tarefa 8 3 2 11 13 3 3 6 3 6 24
Tarefa 9 6 8 16 27 24 15 10 14 7 17
Media 5,22 4,89 8,67 13,67 11,89 6,44 8,44 7,11 10,67 14,89A.6 Tarefas exe utadasUtilizador 1 2 3 4 5 6 7 8 9 10
Tarefa 1 1 1 1 1 1 1 1 1 1 1
Tarefa 2 1 1 1 1 1 1 1 1 1 1
Tarefa 3 1 1 1 1 1 1 1 1 1 1
Tarefa 4 1 1 1 1 1 1 1 1 1 1
Tarefa 5 1 1 1 1 1 1 1 1 1 0
Tarefa 6 1 1 1 1 1 1 1 1 1 1
Tarefa 7 1 1 1 0 1 1 1 1 1 0
Tarefa 8 1 1 1 0 1 1 1 1 1 0
Tarefa 9 1 1 1 0 1 1 1 1 1 1
Media 1,00 1,00 1,00 0,67 1,00 1,00 1,00 1,00 1,00 0,67
102
A.7 N�umero de falhas totais de ompreens~aoUtilizador 1 2 3 4 5 6 7 8 9 10
Tarefa 1 0 0 0 0 0 0 0 0 0 0
Tarefa 2 0 0 0 0 1 0 0 0 2 3
Tarefa 3 0 0 0 5 1 0 0 0 1 0
Tarefa 4 0 1 1 5 4 0 0 2 2 3
Tarefa 5 0 0 2 5 1 0 0 0 0 11
Tarefa 6 0 0 0 0 0 0 0 0 2 0
Tarefa 7 0 0 0 7 0 0 1 0 0 0
Tarefa 8 0 0 3 6 0 0 1 0 1 0
Tarefa 9 0 0 4 10 3 1 0 3 0 0
Media 0,00 0,11 1,11 4,22 1,11 0,11 0,22 0,56 0,89 1,89A.8 N�umero de falhas por ompreens~ao par ialUtilizador 1 2 3 4 5 6 7 8 9 10
Tarefa 1 0 0 0 0 0 0 1 0 0 0
Tarefa 2 0 0 0 0 1 0 0 0 0 1
Tarefa 3 0 0 0 2 3 0 0 0 1 0
Tarefa 4 0 0 0 1 2 1 4 3 2 2
Tarefa 5 0 0 0 2 3 0 0 0 0 1
Tarefa 6 0 0 0 0 0 0 0 0 0 1
Tarefa 7 0 0 0 1 0 0 0 0 2 1
Tarefa 8 0 0 0 0 0 0 0 0 0 5
Tarefa 9 0 0 0 2 3 1 1 1 0 2
Media 0,00 0,00 0,00 0,89 1,33 0,22 0,67 0,44 0,56 1,44A.9 N�umero de falhas ausadas por erros de re onhe i-mentoUtilizador 1 2 3 4 5 6 7 8 9 10
1) 0 1 10 46 22 3 8 9 13 30
2) 0 1 10 24 10 2 4 5 7 8
3) 0,00 1,00 1,00 0,52 0,45 0,67 0,50 0,56 0,54 0,27
• 1) Total de Falhas
• 2) Falhas por erro de reconhecimento
103
• 3) Percentagem de falhas causadas por erros de reconhecimento
• 4) Media das percentagens de falhas causadas por erro de reconhecimento 61,15%
Correlacao entre o numero de palavras proferidas pelo
utilizador e o tempo de execucao de uma tarefa 0,84555
Correlacao entre o numero de palavras proferidas
pelo sistema e o tempo de execucao de uma tarefa 0,83408
Correlacao entre o numero de falhas por compreensao
parcial e as tarefas executadas -0,29023
Correlacao entre o numero de falhas por compreensao
parcial e o tempo de execucao de uma tarefa 0,53
Correlacao entre o numero de falhas totais
de compreensao e as tarefas executadas -0,59329
Correlacao entre o numero de falhas totais de
compreensao e o tempo de execucao de uma tarefa 0,66818A.10 Tempo gasto por tarefa (por tipo de utilizador)Experiente Semi-experiente Inexperiente
Tarefa 1 6,00 9,00 10,63
Tarefa 2 6,38 8,50 16,38
Tarefa 3 6,13 5,00 16,50
Tarefa 4 21,50 19,00 35,88
Tarefa 5 6,25 27,50 18,00
Tarefa 6 6,38 6,50 14,25
Tarefa 7 6,25 6,50 25,50
Tarefa 8 5,50 47,50 41,38
Tarefa 9 29,88 40,00 33,88
Media 10,47 19,97 23,60
104
Figura A.1: Tempo medio gasto por tarefa (por tipo de utilizador).A.11 Numero de palavras utilizadas pelo sistema (por tipode utilizador)Experiente Semi-experiente Inexperiente
Tarefa 1 6,00 6,00 7,25
Tarefa 2 6,00 6,00 9,00
Tarefa 3 5,00 5,00 13,00
Tarefa 4 15,25 12,00 20,00
Tarefa 5 4,25 19,00 9,75
Tarefa 6 3,75 4,00 6,50
Tarefa 7 4,00 4,00 20,00
Tarefa 8 3,25 11,00 23,50
Tarefa 9 12,75 9,00 16,00
Media 6,69 11,00 13,89
Figura A.2: Numero medio de palavras utilizadas pelo sistema (por tipo de utilizador).
105
A.12 Numero de palavras utilizadas pelo utilizador (portipo de utilizador)Experiente Semi-experiente Inexperiente
Tarefa 1 4,75 5,00 7,00
Tarefa 2 4,75 5,00 10,00
Tarefa 3 3,75 4,00 12,75
Tarefa 4 14,25 11,00 21,50
Tarefa 5 4,75 18,00 8,25
Tarefa 6 2,75 3,00 5,00
Tarefa 7 4,75 5,00 15,25
Tarefa 8 2,75 11,00 12,25
Tarefa 9 10,75 16,00 15,25
Media 5,92 10,28 11,92
Figura A.3: Numero medio de palavras utilizadas pelo utilizador (por tipo de utilizador).
106
A.13 Tarefas exe utadas (por tipo de utilizador)Experiente Semi-experiente Inexperiente
Tarefa 1 1,00 1,00 1,00
Tarefa 2 1,00 1,00 1,00
Tarefa 3 1,00 1,00 1,00
Tarefa 4 1,00 1,00 1,00
Tarefa 5 1,00 1,00 0,75
Tarefa 6 1,00 1,00 1,00
Tarefa 7 1,00 1,00 0,50
Tarefa 8 1,00 1,00 0,50
Tarefa 9 1,00 1,00 0,75
Media 1,00 1,00 0,83
Figura A.4: Numero medio de tarefas executadas (por tipo de utilizador).
107
A.14 N�umero de falhas totais de ompreens~ao (por tipode utilizador)Experiente Semi-experiente Inexperiente
Tarefa 1 0,00 0,00 0,00
Tarefa 2 0,00 0,00 1,25
Tarefa 3 0,00 0,00 1,50
Tarefa 4 0,75 1,00 2,50
Tarefa 5 0,00 2,00 4,00
Tarefa 6 0,00 0,00 0,50
Tarefa 7 0,00 0,00 2,00
Tarefa 8 0,00 3,00 2,00
Tarefa 9 1,00 4,00 2,50
Media 0,19 1,11 1,81
Figura A.5: Numero medio de falhas totais de compreensao (por tipo de utilizador).
108
A.15 N�umero de falhas por ompreens~ao par ial (por tipode utilizador)Experiente Semi-experiente Inexperiente
Tarefa 1 0,00 0,00 0,25
Tarefa 2 0,00 0,00 0,25
Tarefa 3 0,00 0,00 0,75
Tarefa 4 1,00 0,00 2,25
Tarefa 5 0,00 0,00 0,75
Tarefa 6 0,00 0,00 0,25
Tarefa 7 0,00 0,00 1,00
Tarefa 8 0,00 0,00 1,25
Tarefa 9 0,50 0,00 1,25
Media 0,17 0,67 0,89
Figura A.6: Numero medio de falhas por compreensao parcial (por tipo de utilizador).A.16 N�umero m�edio de falhas devido a erros de re onhe- imento (por tipo de utilizador)Experiente Semi-experiente Inexperiente
Media 3,25 16 24,25
109
Figura A.7: Percentagem relativa de falhas devido a erros de reconhecimentos (por tipo de utilizador).A.17 Satisfa� ~ao do utilizador (por tipo de utilizador)Experiente Semi-experiente Inexperiente
Satisfacao 80,00% 70,00% 55,00%
Satisfacao geral 68%A.18 Question�ario1 2 3 4 5
Qual o grau de satisfacao em relacao
ao seu futuro mordomo, o Ambrosio? Insastisfeito 2 3 5 Satisfeito
Foi facil compreender o que o Ambrosio lhe disse? Nao 1 4 5 Sim
O Ambrosio conseguiu compreender o que lhe disse? Nao 4 5 1 Sim
110
Foi facil executar:
a tarefa 1? Nao 1 9 Sim
a tarefa 2? Nao 1 2 7 Sim
a tarefa 3? Nao 3 1 6 Sim
a tarefa 4? Nao 1 2 2 4 1 Sim
a tarefa 5? Nao 1 1 3 5 Sim
a tarefa 6? Nao 1 3 1 5 Sim
a tarefa 7? Nao 1 1 1 2 5 Sim
a tarefa 8? Nao 2 1 1 6 Sim
a tarefa 9? Nao 2 6 2 Sim
Achou o ritmo desta conversacao adequado as tarefas? Nao 4 6 Sim
Durante a conversacao soube sempre o que dizer
ao Ambrosio para que executasse a respectiva tarefa? Nao 1 1 2 6 Sim
O Ambrosio levou muito tempo a responder-lhe? Nao 1 2 3 3 1 Sim
O Ambrosio tem o comportamento que esperava? Nao 1 1 7 1 Sim
Gostaria de ter o Ambrosio em sua casa? Nao 4 2 4 Sim
Quanto tempo julga que levou a executar:
a tarefa 1? 10 seg. ou menos 10 1min. ou mais
a tarefa 2? 10 seg. ou menos 8 2 1min. ou mais
a tarefa 3? 10 seg. ou menos 6 3 1 1min. ou mais
a tarefa 4? 10 seg. ou menos 1 3 3 2 1 1min. ou mais
a tarefa 5? 10 seg. ou menos 6 1 3 1min. ou mais
a tarefa 6? 10 seg. ou menos 7 2 1 1min. ou mais
a tarefa 7? 10 seg. ou menos 7 1 1 1 1min. ou mais
a tarefa 8? 10 seg. ou menos 7 2 1 1min. ou mais
a tarefa 9? 10 seg. ou menos 1 3 3 3 1min. ou mais
Quanto tempo levaria a realizar a
tarefa com o mecanismos que dispoe actualmente:
a tarefa 1? 10 seg. ou menos 8 2 1min. ou mais
a tarefa 2? 10 seg. ou menos 6 3 1 1min. ou mais
a tarefa 3? 10 seg. ou menos 6 1 3 1min. ou mais
a tarefa 4? 10 seg. ou menos 5 3 2 1min. ou mais
a tarefa 5? 10 seg. ou menos 5 3 2 1min. ou mais
a tarefa 6? 10 seg. ou menos 5 4 1 1min. ou mais
a tarefa 7? 10 seg. ou menos 6 3 1 1min. ou mais
a tarefa 8? 10 seg. ou menos 1 6 2 1 1min. ou mais
a tarefa 9? 10 seg. ou menos 1 1 5 3 1min. ou mais
111
112
BAn�alise de resultados daavalia� ~ao ao sistema LisaB.1 Tempo de orrido (em segundos)Tarefa 1 Tarefa 2 Tarefa 3 Tarefa 4 Tarefa 5 Tarefa 6 Tarefa 7
Utilizador 1 21 65 34 27 206 35 1
Utilizador 2 12 81 122 50 525 11 35
Utilizador 3 1 44 57 15 80 1 1
Utilizador 4 1 36 34 29 148 58 24
Utilizador 5 12 66 94 1 288 59 1
Utilizador 6 39 137 28 87 89 1 1
Utilizador 7 12 157 37 64 25 1 1
Utilizador 8 1 48 36 35 58 56 1
Utilizador 9 1 121 26 34 92 13 1
Utilizador 10 1 77 27 64 35 44 1
Media 10,1 83,2 49,5 40,6 154,6 27,9 6,7B.2 N�umero de intera � ~oes do sistemaTarefa 1 Tarefa 2 Tarefa 3 Tarefa 4 Tarefa 5 Tarefa 6 Tarefa 7
Utilizador 1 3 5 4 4 25 18 2
Utilizador 2 2 8 9 8 21 8 2
Utilizador 3 1 5 6 3 6 9 7
Utilizador 4 1 4 3 4 14 13 4
Utilizador 5 2 6 9 2 14 8 2
Utilizador 6 4 4 3 8 6 2 2
Utilizador 7 2 17 9 6 5 3 2
Utilizador 8 1 5 4 5 5 12 2
Utilizador 9 1 7 8 5 3 9 2
Utilizador 10 1 4 4 6 3 4 2
Media 1,8 6,5 5,9 5,1 10,2 8,6 2,7
B.3 N�umero de intera � ~oes do intervenienteTarefa 1 Tarefa 2 Tarefa 3 Tarefa 4 Tarefa 5 Tarefa 6 Tarefa 7
Utilizador 1 3 4 3 2 19 7 4
Utilizador 2 2 7 6 4 21 6 1
Utilizador 3 1 4 4 2 6 5 4
Utilizador 4 1 3 3 2 10 7 3
Utilizador 5 2 5 8 1 11 8 1
Utilizador 6 3 6 3 3 6 1 1
Utilizador 7 2 13 6 4 4 2 1
Utilizador 8 1 2 1 2 4 8 1
Utilizador 9 1 7 2 2 3 5 1
Utilizador 10 1 3 2 2 3 3 1
Media 1,7 5,4 3,8 2,4 8,7 5,2 1,8B.4 N�umero de palavras utilizadas pelo sistemaTarefa 1 Tarefa 2 Tarefa 3 Tarefa 4 Tarefa 5 Tarefa 6 Tarefa 7
Utilizador 1 26 50 32 30 179 105 16
Utilizador 2 12 66 63 60 221 40 10
Utilizador 3 7 47 46 33 84 34 43
Utilizador 4 8 47 23 35 109 74 31
Utilizador 5 13 63 70 24 158 50 15
Utilizador 6 16 79 17 68 65 17 16
Utilizador 7 13 109 50 56 43 12 14
Utilizador 8 7 11 26 67 79 57 15
Utilizador 9 7 86 62 67 36 38 15
Utilizador 10 8 43 31 72 47 17 15
Media 11,7 60,1 42 51,2 102,1 44,4 19
114
B.5 N�umero de palavras utilizadas pelo intervenienteTarefa 1 Tarefa 2 Tarefa 3 Tarefa 4 Tarefa 5 Tarefa 6 Tarefa 7
Utilizador 1 7 23 3 15 43 13 12
Utilizador 2 10 24 18 15 23 29 4
Utilizador 3 4 17 6 13 21 7 18
Utilizador 4 7 20 23 15 53 20 12
Utilizador 5 12 45 32 17 147 32 5
Utilizador 6 14 42 17 17 22 7 4
Utilizador 7 8 68 28 21 22 10 8
Utilizador 8 5 6 15 18 50 37 5
Utilizador 9 4 30 13 15 30 10 5
Utilizador 10 6 21 17 19 29 11 4
Media 7,7 29,6 17,2 16,5 44 17,6 7,7B.6 N�umero de intera � ~oes falhadasTarefa 1 Tarefa 2 Tarefa 3 Tarefa 4 Tarefa 5 Tarefa 6 Tarefa 7
Utilizador 1 1 1 0 1 10 4 2
Utilizador 2 1 4 5 3 11 1 1
Utilizador 3 0 0 2 0 0 0 3
Utilizador 4 0 0 3 1 4 3 0
Utilizador 5 1 2 9 0 13 3 0
Utilizador 6 2 0 3 1 0 1 0
Utilizador 7 1 8 4 1 0 0 0
Utilizador 8 0 1 1 0 1 3 0
Utilizador 9 0 1 1 1 0 1 0
Utilizador 10 0 0 1 1 0 2 0
Media 0,6 1,7 2,9 0,9 3,9 1,8 0,6 1,77
Media sem pior tarefa 1,42
115
B.7 N�umero de intera � ~oes falhadas devido a erros dere onhe imentoTarefa 1 Tarefa 2 Tarefa 3 Tarefa 4 Tarefa 5 Tarefa 6 Tarefa 7
Utilizador 1 1 1 0 0 4 3 1
Utilizador 2 1 2 1 2 2 1 1
Utilizador 3 0 0 2 0 0 0 2
Utilizador 4 0 0 3 0 0 2 0
Utilizador 5 1 2 6 0 7 3 0
Utilizador 6 1 0 0 1 0 1 0
Utilizador 7 1 6 3 1 0 0 0
Utilizador 8 0 0 1 0 1 2 0
Utilizador 9 0 1 1 1 0 1 0
Utilizador 10 0 0 1 1 0 1 0
Media 0,5 1,2 1,8 0,6 1,4 1,4 0,4B.8 N�umero de erros que impediram o sistema de pro-gredirTarefa 1 Tarefa 2 Tarefa 3 Tarefa 4 Tarefa 5 Tarefa 6 Tarefa 7
Utilizador 1 0 0 0 0 0 0 0
Utilizador 2 0 0 0 0 1 0 0
Utilizador 3 0 0 0 0 0 0 0
Utilizador 4 0 0 0 0 0 0 0
Utilizador 5 0 0 0 0 0 0 0
Utilizador 6 0 0 0 0 0 0 0
Utilizador 7 0 0 0 0 0 0 0
Utilizador 8 0 1 0 0 0 0 0
Utilizador 9 0 0 0 1 0 0 0
Utilizador 10 0 1 0 0 0 0 0
Total 4
116
B.9 N�umero de hamadas efe tuadas para realizar as ta-refasChamadas
Utilizador 1 2
Utilizador 2 2
Utilizador 3 2
Utilizador 4 1
Utilizador 5 2
Utilizador 6 1
Utilizador 7 1
Utilizador 8 2
Utilizador 9 2
Utilizador 10 2
Media 1,7B.10 N�umero de intera � ~oes do sistema para dete � ~ao ere upera� ~ao de errosTarefa 1 Tarefa 2 Tarefa 3 Tarefa 4 Tarefa 5 Tarefa 6 Tarefa 7
Utilizador 1 0 1 0 2 3 0 1
Utilizador 2 0 3 0 1 3 0 1
Utilizador 3 0 1 1 0 1 0 0
Utilizador 4 0 1 1 0 1 4 1
Utilizador 5 0 1 5 0 3 1 0
Utilizador 6 1 2 0 1 1 0 0
Utilizador 7 0 2 0 1 1 0 0
Utilizador 8 0 0 0 1 1 0 0
Utilizador 9 0 1 0 4 1 0 0
Utilizador 10 0 1 0 1 1 0 0
Media 0,1 1,3 0,7 1,1 1,6 0,5 0,3
117
B.11 A tarefa foi on lu��da om su esso?Tarefa 1 Tarefa 2 Tarefa 3 Tarefa 4 Tarefa 5 Tarefa 6 Tarefa 7
Utilizador 1 1 1 1 1 1 1 1
Utilizador 2 1 1 1 1 1 0 1
Utilizador 3 1 1 1 1 1 1 1
Utilizador 4 1 1 0 1 1 1 1
Utilizador 5 1 1 0 1 0 0 1
Utilizador 6 1 1 0 1 1 0 1
Utilizador 7 1 1 1 1 1 1 1
Utilizador 8 1 0 1 1 1 1 1
Utilizador 9 1 1 1 1 1 1 1
Utilizador 10 1 1 1 1 1 0 1
Media 1 0,9 0,7 1 0,9 0,6 1
Percentagem de tarefas executadas com sucesso 87,14%
Correlacao entre o tempo medio gasto por tarefa
e a satisfacao do utilizador (classificacao cinco no questionario) -0,43
Correlacao entre o numero medio de interaccoes do sistema
e a satisfacao do utilizador (classificacao cinco no questionario) -0,67
Correlacao entre o numero medio de interaccoes falhadas
e a satisfacao do utilizador (classificacao cinco no questionario) -0,64B.12 Question�ario
118
1 2 3 4 5
Qual o grau satisfacao em relacao a sua assistente, a Lisa? Insatisfeito 1 4 4 1 Satisfeito
Foi facil compreender o que a Lisa lhe disse? Nao 2 4 4 Sim
A Lisa conseguiu compreender o que lhe disse? Nao 7 3 Sim
Foi facil executar:
a tarefa 1? Nao 1 2 7 Sim
a tarefa 2? Nao 1 4 3 2 Sim
a tarefa 3? Nao 2 4 1 2 1 Sim
a tarefa 4? Nao 1 3 6 Sim
a tarefa 5? Nao 1 3 2 4 Sim
a tarefa 6? Nao 3 1 2 2 2 Sim
a tarefa 7? Nao 10 Sim
Achou o ritmo desta conversacao adequado as tarefas? Nao 1 1 7 1 Sim
Durante a conversacao soube sempre o que dizer a
Lisa para que ela executasse a respectiva tarefa? Nao 2 6 2 Sim
A Lisa levou muito tempo a responder-lhe? Nao 1 4 5 Sim
A Lisa tem o funcionamento que esperava? Nao 3 7 Sim
Contrataria a Lisa para a sua assistente pessoal? Nao 2 4 3 1 Sim
Quanto tempo julga que levou a executar: 1 2 3 4 5
a tarefa 1? 10 seg. ou menos 6 3 1 1 min. ou mais
a tarefa 2? 10 seg. ou menos 1 min. ou mais
a tarefa 3? 10 seg. ou menos 3 1 2 4 1 min. ou mais
a tarefa 4? 10 seg. ou menos 2 4 1 2 1 1 min. ou mais
a tarefa 5? 10 seg. ou menos 1 1 5 3 1 min. ou mais
a tarefa 6? 10 seg. ou menos 3 3 1 1 2 1 min. ou mais
a tarefa 7? 10 seg. ou menos 7 3 1 min. ou mais
Quanto tempo levaria a realizar a tarefa com
com os mecanismos que dispoe actualmente: 1 2 3 4 5
a tarefa 1? 10 seg. ou menos 7 3 1 min. ou mais
a tarefa 2? 10 seg. ou menos 1 2 2 3 2 1 min. ou mais
a tarefa 3? 10 seg. ou menos 1 2 4 2 1 1 min. ou mais
a tarefa 4? 10 seg. ou menos 2 2 2 4 1 min. ou mais
a tarefa 5? 10 seg. ou menos 1 2 2 3 2 1 min. ou mais
a tarefa 6? 10 seg. ou menos 2 2 3 3 1 min. ou mais
a tarefa 7? 10 seg. ou menos 6 4 1 min. ou mais
119
Figura B.1: Tempo medio por tarefa (em segundos).
Figura B.2: Servicos em que se verifica um maior numero de falhas.
120
Figura B.3: Numero medio de falhas.
Figura B.4: Numero medio de interaccoes para recuperacao de falhas.
121
122
