no solo usabilidad: revista sobre personas, diseño y tecnología

Máster Universitario Online en Diseño de Experiencia de Usuario, Universidad Internacional de la Rioja.
Convocatoria abierta. Inicio Otoño 2017

29 de Enero de 2007

¿Una caja de texto que escucha? Sistemas de diálogo y algunas posibles formas para su evaluación

Jorge y Botana, Guillermo de
Olmos Albacete, Ricardo

Resumen: En los últimos tiempos estamos asistiendo a una explosión de los servicios ofrecidos por vía telefónica en base al reconocimiento de voz (IVR). Estos sistemas de diálogo poseen muchas similitudes con las aplicaciones WEB, en cuanto a que ambos son interfaces de entrada y salida de información. Aún así, hay diferencias cruciales. Desde aquí analizamos un modelo exhaustivo para evaluar este tipo de aplicaciones.

1. Sistemas de diálogo.

En los últimos tiempos estamos asistiendo a una explosión de los servicios ofrecidos por vía telefónica en base a sistemas de reconocimiento de voz IVR (Interactive Vocal Response) y sistemas de gestión de diálogo.

Aunque se pueden establecer analogías y similitudes con los formularios WEB, hay ciertas diferencias que son cruciales. Como similitud, los sistemas de diálogo también esperan eventos protagonizados por los usuarios (en forma de producción verbal) y al igual que los formularios WEB pueden ser de respuesta acotada (como lo son los menús o los mismos botones de opción) o de respuesta abierta (como lo son las cajas de texto). Es curioso comprobar cómo en el estándar VXML (Voice eXtensble Markup Language) (W3C, 2004) existen también los formularios (VXML forms). Los formularios VXML están formados generalmente por unos campos asociados a unas gramáticas, a los que se asigna la respuesta del usuario una vez oída una locución (prompt) y unas acciones que se llevarán a cabo condicionadas a esos mismos campos, lo que es, de alguna manera, análogo a los formularios WEB.

<?xml version="1.0" encoding="UTF-8"?>
<vxml version="2.0" xmlns="http://www.w3.org/2001/vxml"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2001/vxml
http://www.w3.org/TR/voicexml20/vxml.xsd">
<form id="weather_info">
<block>Welcome to the weather information service.</block>
<field name="state">
<prompt>What state?</prompt>
<grammar src="state.grxml" type="application/srgs+xml"/>
<catch event="help">
Please speak the state for which you want the weather.
</catch>
</field>
<field name="city">
<prompt>What city?</prompt>
<grammar src="city.grxml" type="application/srgs+xml"/>
<catch event="help">
Please speak the city for which you want the weather.
</catch>
</field>
<block>
<submit next="/servlet/weather" namelist="city state"/>
</block>
</form>
</vxml>

Ejemplo de formulario “weather_Info”. Tomado de W3C (2004).

Funcionalmente ambas maneras podrían considerarse similares pues se trata de interfaces de entrada y salida de información, aunque para los sistemas de diálogo apercibirse de esto requiera una mayor abstracción, al tratarse del procesamiento de una señal sonora en la que los objetos dedicados a ello no son plenamente visibles en el producto final (no hay menús ni cajas de texto visibles).

En cuanto a las diferencias, y prescindiendo de la propia fineza del sistema de reconocimiento de voz y de la definición de las gramáticas (análogas por otra parte a los validadores de las cajas de texto), la primera y quizás más importante es la misma que diferencia el procesamiento del lenguaje hablado del escrito: la disponibilidad de la señal en el tiempo. La segunda hace referencia a las creencias que los usuarios tienen sobre el comportamiento de este tipo de sistemas.

1.1. La disponibilidad de la señal en el tiempo.

El habla o los diálogos producidos de esta forma no persisten en el tiempo y poseen una secuencialidad en la disponibilidad (Green; 2002), es decir, al proponerse un menú, por ejemplo, no todos los componentes de dicho menú están disponibles en todo momento. Esto otorga a la memoria de trabajo un papel mucho más importante que en cualquier otra modalidad de presentación.

Además, la elección de un ítem del menú puede hacerse sin haber escuchado la totalidad de los ítems, de manera que los procesos de identificación y categorización de las opciones pueden jugar un papel dramático.

Debido a estas peculiaridades pueden amplificarse los ya clásicos efectos de primacía y recencia, o la casi mágica cifra de +-7 unidades como máximo de retención, o los sesgos en la comprensión y categorización de las opciones, causados por el orden de presentación de la información (que producen posibles ambigüedades en cuanto a identificar cuáles son las opciones que deben ser elegidas dado un propósito).

A continuación mostramos dos ejemplos habituales en este tipo de aplicaciones.

Ejemplo 1. Ofrecer textos informativos

Con este epígrafe nos referimos a los casos en los que se ofrezca al usuario información amplia sobre un determinado servicio. Como regla general, al procesar un discurso hablado, debido a la secuencialidad en la disponibilidad, se establecerá una ventana que variará en cada momento conforme el discurso avance y que abarcará la parte del discurso que esté siendo escuchada. Esta ventana tendrá forma de gradiente, es decir, las palabras estarán disponibles en la memoria de trabajo en la medida que estén dentro de dicha ventana.

Estas palabras son las que, por un simple proceso de propagación de la activación, harán disponibles ciertos contenidos de la mente y se relacionarán entre sí constreñidas por factores léxico-semánticos y sintácticos. Una vez que la ventana no se encuentra sobre esa parte desaparece lo que van Dijk y Kintsch (1983) llaman código de superficie, es decir, desaparecen los aspectos más sintácticos y léxicos de las frases (no se retienen ni las palabras exactas ni la forma sintáctica), y surge una representación emergente que está en forma proposicional que luego será plenamente integrada en un modelo de situación, es decir, en un modelo de comprensión global (Kintsch; 1988).

Conforme se produce el discurso hay que ir integrando los contenidos en la memoria a largo plazo para que se produzca la comprensión (mediante procesos de inferencia automatizados). Este proceso dependerá también de la información que haya sido integrada previamente. A efectos prácticos, si se ha de proporcionar una información amplia, hay que promover que se produzcan estos procesos de inferencia e integración.

Además de garantizar la repetición de la información y asegurarse que los términos empleados se encuentran representados en la Memoria a Largo Plazo de los Usuarios (son conocidos por ellos), también se pueden emplear los procedimientos de cohesión textual, que promocionan la coherencia del discurso y por ende su integración y comprensión (Rincón Castellanos; 2006 ).

Ejemplo 2. Proponer menús

De la misma forma, pueden surgir varios problemas a la hora de proponer menús. Uno de ellos es la propia retención en la memoria de trabajo de los ítems del menú. Esto se evitará diseñando una buena arquitectura en la que no abunden los menús con demasiados ítems. Además, se puede ofrecer la oportunidad de seleccionar un ítem del menú antes de que concluya la locución o simplemente facilitar la repetición total del mismo.

El otro problema viene dado por las propiedades semánticas de los ítems del menú. Téngase en cuenta que los ítems no solamente tienen que ser entendidos por el usuario sino que además no debe producirse solapamiento semántico entre ellos. El problema de solapamiento se hace más palpable en los menús en los que el usuario puede detener la locución en el momento en que verbaliza uno de los ítems, por ejemplo si pusiésemos en un menú el ya conocido caso bancario de “Trasferencias” y “Traspasos” (USOLAB, 2002):

“Por favor, diga el servicio en el que está interesado: Todos tus Saldos, Resumen de Productos, Trasferencias, Traspasos, Situación de Cuentas y Contratos”.

Si es el caso de que el usuario quisiese realizar un traspaso (envío a una cuenta de una misma entidad), podría producirse que al ofrecerse la opción “Trasferencias” el propio usuario detuviese el menú, pues creyese que esta es la opción que busca y sólo en reducidas ocasiones se llegase a ofrecer “Traspaso”.

Una primera conclusión que emana de las características de los sistemas de diálogo es que hay que evitar a toda costa la sobrecarga de la memoria de trabajo y ser cuidadosos en el diseño de los textos y menús que se ofrecen, promoviendo la integración y evitando el solapamiento de las propiedades semánticas.

1.2. Creencias sobre el comportamiento del sistema.

La segunda diferencia hace referencia a las creencias que traen consigo los usuarios sobre el funcionamiento de los sistemas de diálogo. Según sean estas creencias, así será el comportamiento ante ellos y así serán las respuestas de los usuarios.

Los sistemas de diálogo no son aún bien conocidos por el usuario medio. El usuario no conoce la capacidad de estos sistemas, la subestima e ignora la manera de actuar frente ellos (Green; 2002). Tienden a reducir al máximo sus frases y producciones y se muestran reacios a creer que pueden decirle a una máquina, por ejemplo, un número de teléfono.

En esta línea de constatación, Dybkjær y Bernsen (2001) proponen que el diseño y las pruebas de un sistema de diálogo tienen que tener en cuenta la división entre usuarios expertos (conocedores del modo de interacción) y usuarios noveles (sin conocimiento previo) y, de esta manera, satisfacer al mayor número de ellos. Esto puede llevarse a cabo mediante la asignación de perfiles de usuario de manera que cuando se acceda a la aplicación, los distintos perfiles tendrán un tratamiento diferencial. Por ejemplo, suprimiendo turnos de pregunta o confirmación de datos en el caso de que el perfil sea de usuario experto, o sustituyendo menús generales por preguntas abiertas del tipo “en qué puedo ayudarle”, implementando técnicas de tipo “diga algo” (ver Torres-Goterris, 2006; Jorge-Botana, Olmos y León, en prensa).

A la hora de evaluar estos sistemas, se han propuesto algunos protocolos como CODIAL (Dybkjær et al.; 1998), el cual, por medio de códigos y descripciones, nos permite etiquetar los diseños en cuanto a sus posibles errores de usabilidad. Este sistema se puede obtener directamente de la página del proyecto DISC (http://www.disc2.dk/tools/codial/index.html) en el que se encuentran pautas y ejemplos de su uso.

Este tipo de protocolos son muy útiles en la fase de prototipado de las aplicaciones, pues ahorran futuros cambios y previenen costes de cara a la satisfacción del usuario. Por otro lado, en una fase posterior, una evaluación profunda de la eficiencia de los agentes de diálogo lo proporciona PARADISE (Paradigm for Dialogue system Evaluation). Este protocolo se centra tanto en la eficacia del sistema como en los costes en los que incurre. En este último modelo se centrará la segunda parte de este artículo.

2. PARADISE

PARADISE fue propuesto por Walker et al. (1997) como una forma global de evaluar diversos parámetros en la eficiencia de estos sistemas, como la tasa de aciertos, el tiempo invertido en cada escenario, los errores o la satisfacción subjetiva de los propios usuarios. Este sistema de evaluación es muy costoso en cuanto a tiempo, aunque muy exhaustivo en cuanto a resultados, por lo que sería muy positivo automatizar, si no todas, alguna de sus partes. La evaluación empieza valorando el nivel de éxito que alcanza el sistema en la consecución de una tarea y, más tarde, evalúa con qué costes lo consigue.

2.1. Valoración del éxito conseguido por el sistema.

Esquema: Satisfacción del usuario e índica Kappa
Figura 1

La primera parte del protocolo calibra el éxito de la aplicación sin tener en cuenta la forma de conseguirlo ni los costes en los que se incurre. Para medir el éxito analiza la tasa de error de diálogos y subdiálogos en base a unas estructuras que ellos llaman Matriz de atributos y valores (AVM: Atribute Value Matrix).

Cada escenario en el que interactúan un agente y un usuario lleva implícita una Matriz de atributos y valores (ver tabla 1) en la que se consignará la información que tanto agente como usuario han recabado. En un estadio posterior se comprobará si esta información recabada es la correcta en relación al propósito del usuario (ver figura 2). Esto requiere un corpus de diálogos que ha de ser extraído del propio sistema que se desea evaluar. Ese proceso puede ser realizado manualmente aunque podría semi-automatizarse incluyéndolo en las propias aplicaciones, permitiendo que se guardara tanto la información recabada (los atributos y sus valores), como un archivo de sonido de las verbalizaciones del usuario con el que contrastar esos valores, esta vez sí, con la participación del oído humano.

Las Matrices de atributos y valores tienen el propósito de formalizar de manera entendible y operativa las transacciones de información que se producen en el diálogo entre el usuario y el agente. Dos diálogos pueden ser radicalmente diferentes pero estar representados por las mismas matrices.

Asistamos a dos diálogos diseñados para la reserva y adquisición de billetes y su representación en las matrices de atributos y valores. La tabla 2 representa la simplificación de valores posibles que la información clave puede tomar en este escenario, es decir, una persona puede querer salir de Roma para ir a Trento por la mañana. El sistema le informará, por ejemplo, de que existe un tren a las ocho de la mañana.

Tabla 1: Matriz de valores posibles

ATRIBUTOVALORES POSIBLESFLUJO DE INFORMACIÓN
Ciudad de salida(DC) Milán, Roma, Turín, Trento A agente
Ciudad de destino(AC) Milán, Roma, Turín, Trento A agente
Momento del día(DR) Mañana, Tarde A agente
Hora de salida(DT) 6 a.m, 8 a.m, 6 p.m, 8 p.m A usuario


Diálogo 1:
A1: Hola, está usted en el servicio de consultas del ferrocarril DC, AC, DR, DT
Por favor, hable después del tono. DC, AC, DR, DT
¿Que información está interesado en saber? DC, AC, DR, DT

U1: Quiero ir de Turín a Milán. DC, AC

A2: ¿Quiere ir de Trento a Milán? DC, AC
Responda sí o no, por favor DC, AC

U2: No. DC, AC

A3: ¿Quiere salir de Trento? DC
Responda sí o no, por favor DC

U3: No. DC

A4: ¿De dónde quiere salir? DC

U4: Quiero salir de Turín. DC

A5: ¿Quiere salir de Turín? DC
Responda sí o no, por favor DC

U5: Sí. DC

A6: ¿Quiere ir a Milán? AC

U6: sí. AC

A7: ¿En que momento del día quiere salir? DR

U7: Por la tarde. DR

A8: ¿Quiere salir entre las seis y las nueve? DR
Responda sí o no, por favor DR

U8: Sí. DR

A9: Existe un tren a las ocho. DT



Diálogo 2:
B1: Hola, está usted en el servicio de consultas sobre trenes. DC, AC, DR, DT
Por favor, hable después del tono. DC, AC, DR, DT
¿Que información está interesado en saber? DC, AC, DR, DT

U1 Quiero viajar de Turín a Milán. DC, AC

B2:¿A qué hora quiere viajar de Merano a Milán? DC, AC, DR

U2: No, quiero salir de Turín por la tarde. DC, DR

B3: ¿Quiere salir de Turín entre las seis y las once de la tarde? DC, DR
Responda sí o no por favor. DC, DR

U3: sí. DC, DR

B4: El tren saldrá a las ocho. DT

Como se puede comprobar, ambos diálogos son distintos debido a sus diferentes estrategias a la hora de recabar la información. El primero parece más largo y más tedioso aunque más seguro, mientras que el segundo parece más directo. Ambos diálogos tienen una representación similar en las Matrices de atributos y valores. Veamos la matriz resultante:

Tabla 2. Matriz resultante:

AtributoValor actual
Ciudad de salida Turín
Ciudad destino Milán
Momento de salida Tarde
Hora de salida 8 p.m

En las Matrices de atributos y valores se representan tanto los valores que han sido recabados por el sistema como los que han sido ofrecidos al usuario una vez introducidos. Esto ayuda a reducir cada diálogo a una tabla en la que todos los diálogos son susceptibles de representarse de manera homogénea.

De esta manera se pueden representar los diálogos en base a la información clave a extraer, y posibilitar la comparación en cuanto a su efectividad. Cada una de estas matrices equivale al diálogo de un usuario concreto con el sistema, por lo que podemos aunar todas estas matrices en una única matriz que el modelo PARADISE llama matriz de confusión (confusion matrix).

La matriz de confusión resultante representará los valores ideales que tendrían que haber sido obtenidos y los valores que realmente han sido obtenidos. Todo ello plasmado en una matriz en la que los valores diagonales son aciertos mientras que los valores ubicados alrededor son errores. La figura 2 muestra dos matrices hipotéticas de dos posibles agentes.

Ejemplo de matrices de dos agentes
Figura 2: Matrices de dos agentes

El conjunto de todas las Matrices de atributos y valores formará la Matriz de Confusión sobre la que se calcularán los índices de éxito de la aplicación.

Sobre estas matrices se calcula el índice Kappa que expresa cómo el agente consigue la información requerida para una tarea en concreto. Originariamente es un índice que mide el acuerdo entre dos jueces. Las fórmulas propuestas son las siguientes:

fórmula índice kappa
Formula 1: Índice Kappa

Donde P(E) es el sumatorio del cuadrado del cociente entre cada total marginal y el número total de observaciones. P(E) es una medida del acuerdo debido al azar, y en la fórmula dicho término aparece para corregir la tasa de acuerdos de modo que no quede sobreestimado el acuerdo total.

fórmula P(E)
Fórmula 2: P(E)

P(A) es la proporción en la que las entradas actuales coinciden con las correctas del escenario.

fórmula P(A)
Fórmula 3: P(A)

Obsérvense ambos agentes A y B. El primero obtiene 0.777 en el índice kappa mientras el segundo obtiene 0.555, lo que sugiere que A tiene mayor porcentaje de éxito que B en ese escenario.

La valoración final del usuario no depende sólo del éxito de la aplicación, sino de otro tipo de medidas de igual importancia que configuran los costes con que se consigue ese éxito. Estas medidas pueden ser: duración de los diálogos (número de turnos), tipo de turnos y sus porcentajes, tasas de corrección de errores, duración de la respuesta, etc. De esto se ocupará el segundo gran bloque de evaluación.

2.2. Valoración de los costes.

El anterior índice da idea del éxito que obtiene el sistema evaluado, pero no da cuenta de cuánto esfuerzo se ha invertido para conseguir este éxito, es decir, qué recursos, tiempo y atención del usuario ha requerido.

En otras palabras, dos sistemas pueden propiciar dos estrategias que consigan similares índices Kappa, pero uno de ellos puede ser mucho más tedioso que el otro, puede provocar más errores, puede generar un diálogo menos informativo (en el que no se ofrezca retroinformación de la información clave y no se pida la confirmación de los compromisos adquiridos).

Esquema: Satisfacción del usuario y minimización de costes
Figura 3

PARADISE dispone de una medida de los costes en los que se ha incurrido para llegar a una tasa de éxito. Respecto a las medidas de eficiencia Walker et al. (1997) proponen hacer mediciones de variables tanto objetivas como subjetivas, sobre las que se ha observado efecto en trabajos anteriores como es el caso de la duración de los diálogos (número de turnos), tipo de turnos y sus porcentajes, tasas de corrección de errores, duración de la respuesta, etc (Torres-Goterris; 2006).

Estas medidas son susceptibles de automatizarse, incluyendo en las propias aplicaciones la capacidad de registrarlas en el momento y consignarlas en ficheros. Estas medidas se registrarán sobre diálogos totales o, si se desea, sobre subdiálogos. En las medidas sobre los diálogos totales, bastará con contar el número de producciones verbales o de cualquier otra medida de referencia. En las mediciones sobre los subdiálogos, para medir por ejemplo el número de producciones es necesario tener una referencia de la información que ese subdiálogo quiere conseguir. Para esto emplea las marcas (tags) que en cada producción muestra la información que se quiere conseguir, como por ejemplo “A7: ¿En que momento del día quiere salir? DR”. En este caso, DR significa que esta producción tiene como fin recopilar la información referente a si el viaje se desea por la mañana o por la tarde.

Esto también será necesario para calcular medidas cualitativas como el número de reparaciones sobre los subdiálogos. Al final, para combinar los valores del éxito y los costes, es decir, K y cada uno de las medidas de los costes de los subdiálogos (Ci), se empleará la siguiente expresión tomada de Walker et al. (1997):

Fórmula Performance
Fórmula 4: Performance

Donde:

La normalización de las puntuaciones Ci, es decir N(Ci), se emplea debido a las diferencias de escala existente entre las distintas clases de medidas de costes (minutos, número de producciones). Sin la normalización, sería muy difícil valorar la importancia de cada coste. Ambas ponderaciones, α y ω, se calculan empíricamente mediante una regresión múltiple, tomando como valor a predecir la satisfacción general del usuario ante el sistema (mediante una escala subjetiva) y tomando como predictores los demás parámetros, como K, y cada uno de las medidas de los costes Ci.

De esta forma se introducirán sólo las variables con peso en la satisfacción total y se extraen las ponderaciones sobre K y sobre las medidas normalizadas de los costes Ci. Esta fórmula es empleada para calcular un índice final que muestre cuan robusto y eficiente es un sistema. En el ejemplo anterior (ver Walker et al.;1997), el sistema A obtiene una puntuación de –0.44, mientras el B obtiene 0.44, por lo que se infiere que el sistema B es palpablemente mejor que A en cuanto a la relación entre éxito y costes.

3. Conclusiones

Al igual que los sistemas desarrollados en la WEB, los sistemas de diálogo también cuentan con una interfaz de entrada y salida de datos para interactuar con el usuario. Aún así, estas transacciones están sujetas a ciertas peculiaridades impuestas por la naturaleza de la señal que sirve de conducto, como es la limitada disponibilidad de los ítems de información. Las interacciones entre un sistema de diálogo y un usuario pueden ser formalizadas de una manera homogénea, de forma que todos los diálogos puedan ser comparados entre si. Además, sobre esta formalización se pueden establecer índices de éxito y establecer los costes en los que el sistema incurre. Aunar y ponderar estas dos medidas dará una idea de cuál es la satisfacción del usuario ante el sistema o, por lo menos, ante parte de él.

PARADISE ofrece un protocolo para llevar a cabo esto de una manera completa y exhaustiva aunque, quizás, con excesiva inversión de tiempo y recursos. Automatizar parte de este protocolo puede ayudar a reducir este último inconveniente.

Otra propuesta interesante y de bajo coste, aunque parcial, es emplear criterios estandarizados para evaluar los diálogos en su fase de diseño y así reducir la posibilidad de errores en la transacción de información y la posible insatisfacción del usuario debido a la indefinición de los propios diálogos del sistema. Esta última alternativa se puede encontrar en CODIAL.

4. Bibliografía

Dybkjær, L. and Bernsen, N. O. (2001). Usability evaluation in spoken language dialogue systems. In Paroubek, P. and Novick, D. G. (Eds.): Proceedings of the Workshop on Evaluation Methodologies for Language and Dialogue Systems, Association for Computational Linguistics 39th Annual Meeting and 10th Conference of the European Chapter (ACL/EACL) 2001, Toulouse, France, 6-7 July 2001. Morgan Kaufman Publishers, 2001, 9-18. Disponible en:
http://www.nis.sdu.dk/%7Enob/publications/eval-24.4.2001.PDF

Dybkjær, L., Bernsen, N.O, and Dybkjær, H. (1998). A methodology for diagnostic evaluation of spoken human-machine dialogue. International Journal of Human Computer Studies (special issue on Miscommunication), 48, 1998, 605-625. Disponible en:
http://www.nis.sdu.dk/~nob/publications/DISC-LREC-3.4.pdf

Green, A.,(2002) Usability Desing for Spoken Language Dialogue. Disponible en:
http://www.ida.liu.se/~nlplab/gslt/papers/AndersG_final2.pdf

Jorge-Botana, G, Olmos, R, León J.A. Análisis de la Semántica Latente (LSA) y estimación automática de las intenciones del usuario en diálogos de telefonía (call routing). (en prensa).

Kintsch, W. (1988). The role of knowledge in discourse comprehension: a construction-integration model. Psychological Review, 95, 163-182. Disponible en:
http://www.nbu.bg/cogs/personal/kokinov/COG507
/The%20Role%20of%20Knowledge%20in%20Discourse%20Comprehension.pdf

Rincón Castellanos, C. A. (2006). Las relaciones textuales de cohesión y de coherencia. Disponible en:
http://es.geocities.com/unexpoha/unexpo/CohesionyCoherencia.doc

Torres Goterris, F. (2006). Sistemas de diálogo basados en modelos estocásticos. Directores: Emilio Sanchis Arnal y Encarna Segarra Soriano. Universidad Politécnica de Valencia. Departamentos de sistemas informáticos y computación 2006.Disponible en:
http://www.dsic.upv.es/docs/bib-dig/tesis/etd-11092005-131117/tesisREVISADA6.pdf

Usolab (2002). Algunos términos que los usuarios no entienden en la web de banca. Usolab, Febrero 2002. Disponible en:
http://www.usolab.com/articulos/feb_02.php

van Dijk, T. A., & Kintsch, W. (1983). Strategies of Discourse Comprehension. New York: Academic Press.

W3C (2004). Voice Extensible Markup Language (VoiceXML) Version 2.0. 16 March 2004, Steph Tryphonas, Daniel C. Burnett, Peter Danielsen, Bruce Lucas, Jim Ferrans, Jerry Carter, Scott McGlashan, Ken Rehor, Brad Porter, Andrew Hunt. Disponible en:
http://www.w3.org/TR/2004/REC-voicexml20-20040316/

Walker, M. A. et al. (1997). PARADISE: A general framework for evaluating spoken dialogue agents In Proceedings of the 35th Annual Meeting of the Association of Computational Linguistics, ACL/EACL 97, 271-280. Disponible en:
http://www.dcs.shef.ac.uk/~walker/acl21.pdf

Compartir:

Facebook Twitter Google LinkedIn

Guillermo de Jorge y Botana es Licenciado en psicología por la Universidad Complutense de Madrid y Magíster en Psicolingüística Aplicada. Actualmente es Doctorando de la universidad Complutense de Madrid y prepara su tesis sobre la técnica de Análisis de la Semántica Latente (LSA) como modelo informático de la comprensión del texto y del discurso: una aproximación distribuida al análisis semántico. A su vez, trabaja como Lingüista computacional en Soluziona.
Contacto: jorgeybotana@psi.ucm.es

Ricardo Olmos Albacete es Licenciado en Psicología y actualmente trabaja como consultor en SPSS Ibérica. Además, es doctorando en la Universidad Autónoma de Madrid y prepara su tesis en torno al Análisis Semántico Latente: "El Análisis Semántico Latente (LSA), ¿es una teoría psicológica o una herramienta de análisis semántico?".
Contacto: ricardolmos@inicia.es

Citación recomendada:

Jorge y Botana, Guillermo de; Olmos Albacete, Ricardo (2007). ¿Una caja de texto que escucha? Sistemas de diálogo y algunas posibles formas para su evaluación. En: No Solo Usabilidad, nš 6, 2007. <nosolousabilidad.com>. ISSN 1886-8592


No Solo Usabilidad - ISSN 1886-8592. Todos los derechos reservados, 2003-2016
email: info (arroba) nosolousabilidad.com
Powered by Calmly Writer