Solicitudes de evaluación de diseño

La calidad de la evaluación depende de la calidad de los avisos. Los avisos bien diseñados prueban exactamente lo que quiere, ni más ni menos.

En este artículo se explica cómo diseñar solicitudes de evaluación que generan resultados claros y accionables.

Anatomía de una solicitud de evaluación eficaz

Las solicitudes de evaluación eficaces comparten cuatro características:

• Intención única
• Expresiones realistas
• Base de datos
• Independiente

Intención única

Cada mensaje debe probar un objetivo o pregunta de usuario. Las solicitudes de varias intenciones dificultan la identificación de la causa de un error.

Para probar varias funcionalidades juntos, use evaluaciones de conversaciones de varios turnos en lugar de combinar intenciones en un solo símbolo del sistema.

Expresiones realistas

Consultas debe reflejar cómo se comunican realmente los usuarios, incluidos el lenguaje informal, las oraciones incompletas y los distintos niveles de detalle.

Puede derivar mensajes realistas de:

• Registros de consultas de producción
• Sesiones de investigación de usuarios
• Incidencias de soporte técnico
• Conversaciones diarias en el lugar de trabajo

Base de datos

Consultas deben estar fundamentados en datos. Cuando haya datos de puesta a tierra disponibles, use entidades, valores e identificadores específicos. Este enfoque hace que las evaluaciones se puedan medir y comprobar.

Las solicitudes fundamentadas permiten aserciones precisas, como "La respuesta contiene 15 días", en lugar de comprobaciones vagas como "La respuesta contiene el número correcto".

Sin datos de puesta a tierra

Mensaje: "¿Cuál es la directiva de la PTO para ingenieros?"

Con datos de puesta a tierra

Datos de puesta a tierra:

• Empleado: Marcus Johnson
• Departamento: Ingeniería
• Tenencia: 8 meses
• Gerente: Lisa Park
• Ubicación: Oficina de Austin

Mensaje: "Estoy en el equipo de ingeniería, ¿cuántos días de vacaciones tengo?"

Autocontenido (turno único)

Para las evaluaciones de un solo turno, cada solicitud debe incluir todo el contexto necesario. El agente no puede confiar en turnos de conversación anteriores. En la tabla siguiente se muestran ejemplos de mensajes independientes.

Para escenarios que abarcan varios turnos, use conversaciones de varios turnos.

Variaciones de petición

Los usuarios no todos formulan la misma pregunta de la misma manera. Para probar la generalización, cree tres variaciones de cada símbolo del sistema.

Avisos canónicos

Los avisos canónicos son explícitos, completos e inequívoco. Sirven como línea base.

• Incluya todos los parámetros necesarios.
• Use terminología precisa.
• Evite la ambigüedad.
• Representa una consulta ideal.

Ejemplo

"¿Cuántos días de descanso remunerados reciben anualmente los empleados con menos de dos años de antigüedad de acuerdo con la política actual de PTO?"

Variante de lenguaje natural

La variante de lenguaje natural refleja las expresiones conversacionales diarias. Variantes de lenguaje natural:

• Use lenguaje casual y conversacional.
• Puede incluir sinónimos o términos informales.
• Evite los identificadores técnicos.
• Permanezca lo suficientemente completo como para responder.

Ejemplo

"Oye, ¿cuántas vacaciones obtengo como nueva contratación?"

En la tabla siguiente se comparan las indicaciones canónicas y las variantes de lenguaje natural.

Sondeo de solidez

El sondeo de solidez evalúa la forma en que el agente controla la entrada imperfecta. Sondeos de solidez:

• Incluir errores tipográficos realistas.
• Contener errores gramaticales.
• Use abreviaturas o abreviaturas.
• Pruebe el reconocimiento de intenciones con ruido.

Ejemplo: "whats my vacaton days entitlement"

En la tabla siguiente se muestran ejemplos de patrones que se van a probar.

Ejemplos de variantes de avisos completos

En los ejemplos siguientes se muestran los tres tipos de solicitud para un único escenario.

Escenario: Ordenación de equipos

Este escenario incluye los siguientes datos de puesta a tierra:

• Empleado: Katrin Pold
• Departamento: Diseño del producto
• Fecha de inicio: 2024-01-15
• Presupuesto de equipo: $3,500
• Elementos aprobados: MacBook Pro (14 o 16 pulgadas), Monitor externo, Teclado, Mouse

Variaciones de petición

Canónico

"Soy un nuevo empleado en el departamento de diseño de productos a partir del 15 de enero de 2024. Necesito pedir un portátil MacBook Pro de 16 pulgadas. Envíe esta solicitud de equipo a través del sistema de pedidos de TI".

Lenguaje natural

"Hola, acabo de unirme al equipo de diseño de productos y necesito configurar mi portátil. ¿Puedo obtener un MacBook Pro? El 16 pulgadas uno preferiblemente."

Sondeo de solidez

"Es necesario pedir macbook pro 16in para un nuevo trabajo en el diseño del producto"

Aserciones (se aplican a todas las variaciones):

• La respuesta confirma que se inició el pedido del equipo.
• El agente invocó la herramienta OrderEquipment .
• La llamada a la herramienta incluye "MacBook Pro de 16 pulgadas" (o equivalente).
• La respuesta incluye una confirmación de pedido o un número de referencia.

Escenario: Pregunta de directiva con personalización

Este escenario incluye los siguientes datos de puesta a tierra:

• Empleado: James Wright
• Ubicación: Oficina de Londres, Reino Unido
• Tenencia: 6 meses
• Tipo de empleo: a tiempo completo

Variaciones de petición

Canónico

"Como empleado a tiempo completo con sede en la oficina de Londres, Reino Unido con 6 meses de permanencia, ¿a qué días festivos tengo derecho este año?"

Lenguaje natural

"Trabajo en la oficina de Londres , ¿qué días festivos me bajan?"

Sondeo de solidez

"Vacaciones en la oficina del Reino Unido fuera de este año?"

Aserciones (se aplican a todas las variaciones):

• La respuesta enumera los días festivos del Reino Unido (no los días festivos de EE. UU.).
• La respuesta incluye al menos: Día de Año Nuevo, Pascua, Navidad.
• La respuesta hace referencia a la directiva o programación del Reino Unido.
• La respuesta no menciona los días festivos de EE. UU., como el 4 de julio o El Día de Acción de Gracias.

Patrones que se deben evitar

Evite los siguientes patrones de solicitud.

Solicitudes de varias intenciones

Evite las solicitudes de varias intenciones. Cuando el símbolo del sistema cubre varias intenciones, no puede determinar qué intención provocó un error.

• Evite lo siguiente: ¿Cuál es mi saldo de PTO, y puedes decirme sobre las opciones de seguro médico, y podría necesitar un portátil también?
• Use en su lugar: Divida en mensajes independientes o use la evaluación multiproceso.

Avisos compatibles con el esquema

Evite las solicitudes que reconocen el esquema. Las solicitudes compatibles con el esquema no funcionan bien porque los usuarios no conocen las API internas ni los nombres de herramientas.

• Evite lo siguiente: "Llame a getPTOBalance API para el identificador de empleado 12345"
• Use en su lugar: "¿Cuál es mi saldo de vacaciones actual?"

Mensajes vagos

Evite mensajes vagos. Si el mensaje es vago, no puede definir aserciones medibles.

• Evite lo siguiente: "Ayúdame con cosas de RR. HH. "
• Use en su lugar: "Cómo inscribirse en el plan de seguro dental?"

Avisos iniciales

Consultas esa sugerencia de la respuesta esperada no pruebe la eficacia del razonamiento real del agente.

• Evite lo siguiente: "La política de la TPTO dice 15 días, ¿verdad?"
• Use en su lugar: "¿Cuántos días de PTO reciben los nuevos empleados?"

No autocontenido (turno único)

Evite mensajes que dependan del contexto anterior.

• Evite lo siguiente: "¿Qué hay de la otra opción?"
• Use en su lugar: "¿Cuál es la diferencia entre los planes de salud HMO y PPO?"

Generación de mensajes a partir de escenarios de usuario

Comience con la intención real del usuario en lugar de con las listas de características.

• Recopilar preguntas de usuario representativas.
• Agrupar por escenario (por ejemplo, búsqueda de directivas, acciones, escalación).
• Escriba una solicitud canónica para cada escenario.
• Agregue variantes de lenguaje natural y solidez.
• Avisos de tierra con datos concretos.

Este enfoque garantiza que las evaluaciones reflejen el uso real.

Expansión del símbolo del sistema asistida por inteligencia artificial (opcional)

Después de establecer una línea base sólida, use la inteligencia artificial para expandir la cobertura. Pida a IA que sugiera más variaciones. Revise cada sugerencia para conocer el realismo y la relevancia. Rechazar solicitudes que no son naturales, compatibles con el esquema o fuera del ámbito. Agregue mensajes solo cuando mejoren la cobertura.

Preguntar lista de comprobación de cobertura

Use esta lista de comprobación para asegurarse de que la cobertura del aviso está completa.

Cobertura de capacidad

• Cada herramienta o acción tiene al menos un caso de prueba
• Cada dominio de conocimiento está representado
• Se prueba el comportamiento de la escalación
• Se prueban escenarios fuera del ámbito

Cobertura de variación

• Aviso canónico
• Variante de lenguaje natural
• Sondeo de solidez

Casos perimetrales

• Indicaciones muy breves
• Avisos muy largos
• Solicitudes ambiguas
• Falta información
• Solicitudes no válidas o no admitidas

Personalización (si procede)

• Diferentes ubicaciones de usuario
• Diferentes niveles de tenencia
• Diferentes roles o departamentos

Paso siguiente