Prototipar, evaluar y mejorar

Un sistema conversacional no se termina al lanzarlo. En cuanto llega a personas reales aparecen expresiones, combinaciones y fallos que nadie previó. Esta página trata de cómo descubrirlos antes y después del lanzamiento, y es probablemente donde más pesa la formación lingüística: investigar cómo habla la gente, construir un corpus y anotarlo con criterio.

1. Investigar el lenguaje real

Observa cómo expresan las personas la tarea, qué información dan sin que se la pidan, qué palabras usan, qué evitan decir y dónde se equivocan en el proceso actual. Si hay conversaciones existentes (correos de atención, transcripciones de llamadas, consultas de un buscador), son un corpus: revísalas con protección de datos y sabiendo de dónde vienen.

Incluye personas con distintos grados de familiaridad, lenguas, variedades, alfabetización digital y capacidades. En voz, prueba con ruido y con ritmos de habla distintos. Un sistema que solo funciona con el habla del equipo que lo construyó no está listo.

2. Prototipar con diálogos de ejemplo

Antes de construir nada, escribe diálogos completos para estas situaciones:

• el camino frecuente
• alguien que da más datos de los pedidos
• una respuesta parcial
• una corrección
• una ambigüedad
• un cambio de objetivo
• un silencio o una espera
• una petición fuera de alcance
• un fallo de una fuente o un servicio
• una acción que necesita confirmación
• una cancelación, una pausa y un regreso
• una derivación y un cierre

Leer estos diálogos en voz alta, con otra persona, sigue siendo una de las pruebas más baratas y eficaces. Después, pásalos a un mapa de estados para encontrar callejones sin salida y bucles.

El diálogo de ejemplo sirve para probar la lógica, no para fijar frases exactas. Con un modelo de lenguaje, el sistema no repetirá esas frases palabra por palabra; servirán como ejemplos y como criterio de evaluación.

3. Pruebas con personas

Pide a una persona que complete una tarea y observa cuándo duda, qué esperaba, qué datos aporta y qué entiende por «terminado». No la guíes con las palabras del flujo. Al acabar, pregúntale qué cree que hizo el sistema, qué datos usó y qué pasará después.

Un prototipo tiene que poder fallar a la vista. El objetivo no es demostrar que el camino feliz funciona, sino descubrir dónde la conversación no da la orientación que la persona necesita.

4. Dónde se concentran los problemas

Los fallos suelen aparecer en las transiciones, no en el centro del camino ideal. Recorre el servicio de principio a fin y marca cada punto en el que cambia una expectativa, se pide algo, se espera, se deriva o cambia un estado:

5. Clasificar antes de arreglar

No todo fallo es «culpa del modelo». Antes de arreglar, clasifica:

• de caso de uso: la necesidad es nueva o el alcance no la contempla
• de lenguaje o turno: la persona no supo qué responder o cuándo
• de flujo: el estado, el orden o la salida están mal diseñados
• de contenido: falta información, está anticuada o no se encuentra
• de servicio: falla una herramienta, un dato o un proceso externo
• de canal: el tiempo de espera, la transcripción o la transferencia no encajan con el medio
• de expectativa: el producto promete algo que no hace
• de política o seguridad: la petición exige más autoridad de la que el sistema debería tener

Esto es, literalmente, una tarea de anotación. Necesita categorías bien definidas, ejemplos de cada una y una guía para los casos dudosos. Si dos personas del equipo clasifican las mismas conversaciones de forma distinta, lo más probable es que fallen las categorías, y eso se puede medir: el taller sobre el acuerdo entre anotadores explica cómo.

6. Evaluar el sistema completo

Evalúa la tarea en su contexto, no respuestas sueltas. Un sistema puede sonar natural y no cumplir el objetivo, o cumplirlo de una forma que desoriente.

Para revisar conversaciones una a una, sirve una rúbrica con preguntas de sí o no:

• ¿la persona supo qué podía hacer el sistema?
• ¿cada turno tenía una función clara?
• ¿el sistema esperó cuando le tocaba a la persona?
• ¿aprovechó los datos que ya tenía?
• ¿preguntó solo lo necesario?
• ¿permitió corregir, cambiar de tema o cancelar?
• ¿mantuvo el estado sin duplicar acciones?
• ¿explicó los fallos y ofreció alternativas?
• ¿derivó cuando debía, con contexto suficiente?
• ¿comprobó la tarea antes de darla por terminada?
• ¿cerró cuando ya no quedaba nada pendiente?

Una rúbrica así es una guía de anotación. Y cuando la evaluación se automatiza con un modelo que revisa conversaciones, como describe Anthropic para los agentes, las preguntas siguen siendo las mismas: alguien tiene que haberlas formulado bien. El taller sobre cómo evaluar un clasificador explica las medidas básicas.

7. Aprender en producción

Define desde el principio qué sucesos registrar para poder reconstruir lo que pasó sin guardar más de lo necesario: inicio y fin de cada tarea, transiciones, reparaciones y su intento, confirmaciones y decisiones, tiempos de espera y fallos de servicio, transferencias y su resultado. Las medidas dicen dónde mirar; leer conversaciones concretas ayuda a entender qué falló.

Antes de guardar conversaciones, decide para qué, quién accede, cuánto tiempo se conservan y cómo se ocultan los datos sensibles. Informa a las personas cuando la conversación se registre de forma relevante para ellas. Cuando sea posible, trabaja con extractos mínimos o datos anonimizados.

Una petición nueva no es automáticamente un caso de uso nuevo. Antes de ampliar, pregunta si es una necesidad recurrente, si encaja con el propósito del producto, si hay datos fiables para resolverla y qué riesgo tiene equivocarse.

8. El servicio detrás de la conversación

Cada promesa del diálogo depende de algo que no se ve: una fuente de datos, un equipo humano, un horario de atención, un sistema externo. Dibujar ese servicio completo (lo que en diseño de servicios se llama service blueprint) revela límites que ningún guion muestra.

Tres prácticas mínimas:

• cada pieza tiene responsable: casos de uso, fuentes, mensajes, reparaciones y criterios de derivación. Sin responsable, el contenido caduca y el sistema sigue respondiendo con seguridad sobre procesos que ya cambiaron
• el modo degradado está diseñado: si un servicio va lento o cae, se sabe qué sigue funcionando y qué se comunica. Es mejor «ahora no puedo consultar el estado» que dar como actual un estado antiguo
• los cambios se registran: qué versión de flujo, contenido y modelo atendió cada conversación. Una actualización del modelo puede cambiar el comportamiento aunque nadie haya tocado el diseño

Por último, la localización. No traduzcas palabra por palabra preguntas, opciones y reparaciones: las convenciones de turno, cortesía, fechas y silencios cambian entre lenguas y culturas. Prueba cada lengua con hablantes de esa lengua. Ningún idioma debería recibir una experiencia de segunda.