Gerente de di´ alogo

Sua fun¸c˜ao principal ´e controlar o fluxo do di´alogo. Para isso o sistema precisa: determinar se ele possui informa¸c˜oes suficientes sobre o usu´ario para iniciar a comunica- ¸c˜ao com o componente externo, comunicar-se efetivamente com o componente externo e repassar ao usu´ario, em linguagem natural, os dados obtidos junto ao componente externo.

A determina¸c˜ao de informa¸c˜oes corretas sobre o usu´ario ´e um fator importante para sua comunica¸c˜ao com o componente externo, pois, se as informa¸c˜oes adquiridas junto ao usu´ario n˜ao forem suficientes para ele fazer uma consulta ao componente externo o processo de comunica¸c˜ao falhar´a.

O fluxo das informa¸c˜oes entre os componentes do sistema de di´alogo ´e fator impor- tante para a determina¸c˜ao dessas informa¸c˜oes. Para lidar com esse fator o componente de gerente de di´alogo pode ser estruturado com dois tipos de arquitetura: serial ou distribu´ıdo. Esses dois s˜ao diferenciados pela forma de tratamento de entradas n˜ao usuais, aquelas que advˆem de erros de processamento ou outro tipo de erro.

Em uma arquitetura serial o erro de interpreta¸c˜ao ser´a propagado de componente a componente at´e este ser detectado pelo gerente de di´alogo, que far´a a entrada ser processada novamente para que ele verifique novamente se o novo processo de inter- preta¸c˜ao est´a correto ou n˜ao.

Em uma arquitetura distribu´ıda ou blackboard as informa¸c˜oes de sub-processamento de cada componente podem ser requisitadas em qualquer ponto de seu processamento global por qualquer componente do sistema de di´alogo, assim tanto o gerente de di´alogo quanto os outros componentes que fazem parte do processamento global da entrada do usu´ario poder˜ao efetuar corre¸c˜oes sem sobrecarregar o processamento. Isso permite um controle de erros mais dinˆamico e aprimorado, uma vez que poss´ıveis erros, que seriam repassados a outros componentes, podem ser corrigidos imediatamente com a volta da informa¸c˜ao errada ao componente que a gerou.

55

Al´em do tipo de arquitetura do sistema, o componente gerente de di´alogo tem que possuir estrat´egias para o tratamento de entradas mal formadas, mal interpretadas ou insuficientes para o processo de comunica¸c˜ao com o componente externo e estrat´egias para a confirma¸c˜ao das informa¸c˜oes obtidas [16].

Uma forma simples de lidar com erros ´e inform´a-los ao usu´ario assim que eles forem detectados, por´em esta solu¸c˜ao acaba tirando a naturalidade do di´alogo, pois o sistema apenas informa que houve um erro de processamento, o que interrompe o fluxo normal do di´alogo e coloca no usu´ario uma obriga¸c˜ao de tentar corrigir o erro cometido pelo sistema ou por ele mesmo. Uma maneira diferente e menos intrusiva seria possuir estrat´egias de recupera¸c˜ao impl´ıcitas baseadas nos conhecimentos disponibilizados pe- los componentes de reconhecimento e entendimento de linguagem, al´em das fontes de conhecimento [16]. Assim, o sistema poderia us´a-las para tentar corrigir ou requisi- tar ao usu´ario uma corre¸c˜ao para o erro, algo natural mesmo em di´alogos entre pessoas.

Com um modelo de discurso integrado ao sistema de di´alogo o componente gerente de di´alogo pode obter informa¸c˜oes sobre o contexto do di´alogo, o que permite a inter- preta¸c˜ao de itens dependentes de contexto, tais como itens referenciados por pronomes e por alguns fenˆomenos ling¨u´ısticos, caracter´ısticos de discurso, que s˜ao dependentes de contexto local, an´aforas e elipses. Essa interpreta¸c˜ao recebe o nome de an´alise prag- m´atica e por meio dela a determina¸c˜ao das informa¸c˜oes do usu´ario podem ser mais bem esclarecidas, uma vez que se sabe o contexto em que elas est˜ao.

Outra estrat´egia de corre¸c˜ao de entradas ´e a pr´e-determina¸c˜ao das emiss˜oes seguin- tes do usu´ario, assim se o sistema conseguir prever as pr´oximas emiss˜oes ele poder´a diminuir ou eliminar o processamento necess´ario para interpreta¸c˜ao de uma emiss˜ao, pois ele j´a sabe qual ser´a a pr´oxima. Essa predi¸c˜ao pode ser feita com base no modelo de di´alogo, no hist´orico de discurso e com um modelo de usu´ario.

hist´orico de discurso ele saber´a quais foram as emiss˜oes anteriores e com o modelo de usu´ario (cren¸cas, objetivos, preferˆencias e planos) ele poder´a determinar poss´ıveis planos que expressam os objetivos do usu´ario, assim tentar predizer quais seriam as futuras emiss˜oes do usu´ario.

As estrat´egias apresentadas anteriormente tentam tratar de entradas mal interpre- tadas ou incompletas sem a interven¸c˜ao do usu´ario, contudo nem sempre o sistema conseguir´a corrigir sozinho esse tipo de erro. Ent˜ao estrat´egias de verifica¸c˜ao e con- firma¸c˜ao s˜ao necess´arias. A verifica¸c˜ao ´e necess´aria para lidar com prov´aveis erros de interpreta¸c˜ao e entendimento que o sistema de di´alogo ter´a de lidar, j´a a confirma¸c˜ao ´e mais comum em sistemas de di´alogo falado, onde fatores tecnol´ogicos podem influ- enciar a interpreta¸c˜ao das emiss˜oes.

A verifica¸c˜ao pode ser impl´ıcita ou explicita. Na primeira o sistema adiciona na sua pr´oxima pergunta uma repeti¸c˜ao do que ele entendeu da emiss˜ao anterior do usu´ario, isso permite ao usu´ario corrigir o que n˜ao foi entendido corretamente, caso n˜ao o fa¸ca, a verifica¸c˜ao ser´a confirmada implicitamente. Na segunda o sistema pergunta explici- tamente ao usu´ario para requerer confirma¸c˜ao da sua entrada.

A confirma¸c˜ao pode ser obtida por uma resposta sim ou n˜ao. Esta verifica¸c˜ao pode ter a desvantagem de se a pergunta de confirma¸c˜ao for mal formulada ou estiver fora de contexto local o usu´ario ser´a for¸cado a corrigir a confirma¸c˜ao e a pergunta de con- firma¸c˜ao tamb´em. Uma dificuldade desse tipo de verifica¸c˜ao ´e a grande possibilidade de respostas que o usu´ario pode fornecer, o que dificultar´a as futuras confirma¸c˜oes do sistema.