Construyendo un Dataset de Evaluacion a Partir de Conversaciones con Clientes

Toda agencia que ajusta modelos para clientes enfrenta el mismo problema de evaluacion: ¿como sabes que el modelo realmente funciona para el caso de uso real del cliente?

Puedes construir un conjunto de pruebas desde cero. Puedes generar ejemplos de evaluacion sinteticos. Ambos enfoques tienen una debilidad fundamental — prueban lo que crees que el modelo deberia manejar, no lo que realmente encuentra en produccion.

Los mejores datasets de evaluacion provienen de conversaciones reales con clientes. Tickets de soporte, logs de chat, transcripciones de llamadas de ventas, informes de fallos de produccion — estos son la materia prima para un conjunto de evaluacion que mide lo que realmente importa. Capturan las entradas desordenadas, ambiguas y especificas del dominio que los datos sinteticos raramente reproducen.

Esta guia recorre el proceso completo: obtener conversaciones, extraer casos de prueba, etiquetar salidas esperadas y mantener tu conjunto de evaluacion a lo largo del tiempo.

Por Que las Conversaciones Reales Superan a los Datos de Prueba Sinteticos

Los conjuntos de evaluacion sinteticos son utiles para empezar. Pero tienen tres puntos ciegos que los datos de conversaciones reales llenan:

Precision de distribucion. Los datos sinteticos reflejan lo que imaginas que es la distribucion. Los datos reales reflejan lo que realmente es. Si el 40% de los tickets de soporte de un cliente son disputas de facturacion y el 5% son problemas tecnicos, un conjunto de pruebas sintetico a menudo invierte esto — generando numeros iguales de cada categoria porque parece "balanceado." El resultado: tu evaluacion sobreestima el rendimiento en categorias raras y subestima el rendimiento en las categorias que realmente importan.

Realismo linguistico. Los usuarios reales no escriben como ingenieros de prompts. Usan abreviaciones, cometen errores tipograficos, mezclan idiomas, hacen referencia a contexto de interacciones previas y expresan frustracion de maneras que cambian el tono y la intencion implicita de la consulta. Los ejemplos sinteticos tienden a ser limpios, completos y libres de contexto.

Descubrimiento de casos extremos. No puedes generar sinteticamente casos extremos que no has imaginado. Los datos de conversaciones reales contienen casos extremos que nadie anticipo — y esos son precisamente los casos que causan fallos en produccion.

Un estudio de sistemas ML en produccion en multiples industrias encontro que los modelos evaluados en conjuntos de prueba sinteticos mostraban una precision 8-15 puntos porcentuales mas alta que los mismos modelos evaluados con datos reales de produccion. Esa brecha es la diferencia entre una demo que impresiona y un despliegue que funciona.

Fuente 1: Tickets de Soporte

Los tickets de soporte son la fuente individual mas rica de datos de evaluacion para la mayoria de los despliegues de clientes. Representan problemas reales de usuarios, expresados en lenguaje real de usuarios, con (generalmente) una resolucion conocida.

Que extraer:

• Entrada: El mensaje original del cliente (primer mensaje en el ticket, antes de cualquier interaccion con un agente)
• Salida esperada: La respuesta correcta, resolucion o clasificacion basada en como se resolvio realmente el ticket
• Metadatos: Categoria del ticket, prioridad, tiempo de resolucion, puntuacion de satisfaccion del cliente

Proceso de extraccion:

1. Exportar los ultimos 90 dias de tickets resueltos del helpdesk del cliente (Zendesk, Freshdesk, Intercom, etc.)
2. Filtrar por tickets resueltos exitosamente (cliente confirmo la resolucion o sin reapertura)
3. Para cada ticket, extraer el mensaje inicial del cliente como entrada
4. Para tareas de clasificacion: usar la categoria/etiqueta asignada como salida esperada
5. Para generacion de respuestas: usar la primera respuesta del agente que resolvio el problema como salida esperada
6. Eliminar tickets que requirieron escalacion o tuvieron circunstancias inusuales — estos son casos extremos que vale la pena probar por separado pero no deben estar en tu conjunto de evaluacion principal

Objetivo de volumen: 100-200 tickets te dan un conjunto de evaluacion robusto. Si el cliente tiene menor volumen, 50 es el minimo para estimaciones de precision significativas.

Atencion: Las respuestas de los agentes a menudo incluyen saludos, disculpas y cortesias que probablemente no quieres que el modelo reproduzca. Eliminales para aislar la respuesta sustantiva, o conservalos si se espera que el modelo replique la experiencia completa del agente.

Fuente 2: Logs de Chat

Si el cliente tiene un chatbot existente o sistema de chat en vivo, los logs historicos de chat proporcionan datos de evaluacion conversacional.

Que extraer:

• Entrada: El mensaje del usuario (o la conversacion completa hasta cierto turno, si el contexto importa)
• Salida esperada: La respuesta ideal en ese punto de la conversacion
• Contexto: Mensajes previos en la conversacion, metadatos del usuario si estan disponibles

Proceso de extraccion:

1. Exportar transcripciones de chat de los ultimos 60-90 dias
2. Identificar conversaciones que llegaron a una resolucion exitosa (el usuario agradecio al agente, marco el problema como resuelto, o no regreso con la misma pregunta)
3. Seleccionar turnos especificos dentro de las conversaciones como casos de prueba — no todos los turnos son igualmente utiles
4. Priorizar turnos donde el agente proporciono informacion sustantiva (no "Dejame verificar eso" o "Por favor espera")
5. Para evaluacion multi-turno, incluir el historial de conversacion como contexto en la entrada

Objetivo de volumen: 75-150 turnos de conversacion. Enfocate en la diversidad — quieres turnos de diferentes tipos de conversaciones, no 50 turnos de 5 conversaciones largas.

Atencion: Los logs de chat a menudo contienen informacion personal (nombres, numeros de cuenta, direcciones de correo). Anonimiza antes de agregar a tu conjunto de evaluacion. Reemplaza nombres reales con marcadores de posicion, redacta numeros de cuenta y cambia dominios de correo a example.com.

Fuente 3: Transcripciones de Llamadas de Ventas

Para modelos que asisten con habilitacion de ventas, calificacion de leads o recomendacion de productos, las transcripciones de llamadas de ventas son invaluables.

Que extraer:

• Entrada: Preguntas del cliente, objeciones o requisitos expresados durante la llamada
• Salida esperada: La recomendacion correcta de producto, manejo de objeciones o informacion que proporciono el vendedor
• Datos de resultado: Si se cerro el trato, el tamano del trato y el tiempo hasta el cierre — esto te permite ponderar los ejemplos de evaluacion por impacto de negocio

Proceso de extraccion:

1. Obtener transcripciones de los ultimos 90 dias (de Gong, Chorus o herramientas similares de grabacion de llamadas)
2. Enfocarse en llamadas que resultaron en tratos cerrados — estas demuestran interacciones exitosas
3. Identificar 3-5 momentos clave por llamada: la evaluacion inicial de necesidades, una pregunta tecnica, una objecion, una discusion de precios y la recomendacion
4. Para cada momento, extraer la declaracion del cliente como entrada y la respuesta del representante de ventas como salida esperada
5. Incluir 20-30% de ejemplos de tratos perdidos donde la respuesta del representante de ventas era aun factualmente correcta — el modelo debe dar informacion precisa independientemente del resultado del trato

Objetivo de volumen: 50-100 momentos extraidos de 15-30 llamadas.

Atencion: Los representantes de ventas a veces hacen promesas o afirmaciones que no son tecnicamente precisas. Verifica el contenido factual de las salidas esperadas antes de agregarlas a tu conjunto de evaluacion. Un conjunto de evaluacion construido sobre salidas esperadas incorrectas te entrenara a aceptar salidas incorrectas del modelo.

Fuente 4: Logs de Fallos de Produccion

Los ejemplos de evaluacion mas valiosos provienen de casos donde el sistema actual fallo. Si el cliente ya tiene un modelo en produccion (o un sistema basado en reglas, o un proceso manual que falla), los casos de fallo son oro.

Que extraer:

• Entrada: La entrada exacta que causo el fallo
• Salida esperada: Lo que deberia haber sucedido (determinado despues del hecho por un experto de dominio)
• Modo de fallo: Como fallo el sistema (clasificacion incorrecta, respuesta alucinada, error de formato, timeout)

Proceso de extraccion:

1. Recopilar informes de fallos de produccion, quejas de clientes y escalaciones de los ultimos 6 meses
2. Reconstruir la entrada exacta que desencadeno cada fallo
3. Que un experto de dominio determine la salida correcta para cada caso
4. Categorizar los fallos por tipo: errores de precision, errores de formato, problemas de latencia, fallos de casos extremos, violaciones de seguridad

Objetivo de volumen: Cada caso de fallo que puedas encontrar. Incluso 10-20 casos de fallo son desproporcionadamente valiosos porque representan los escenarios exactos donde el modelo necesita mejorar.

Por que los fallos importan mas: Tu conjunto de evaluacion principal te dice que tan bien maneja el modelo el trafico normal. Tus casos de fallo te dicen si el modelo ha corregido los problemas especificos que mas le importan al cliente. Cuando un cliente dice "el modelo necesita ser mejor," generalmente quiere decir "el modelo necesita dejar de cometer estos errores especificos" — y los casos de fallo capturan esos errores especificos.

El Proceso de Extraccion y Etiquetado

Paso 1: Anonimizar

Antes de cualquier otra cosa, elimina la informacion de identificacion personal de todos los datos de conversacion. Esto es innegociable, tanto por cumplimiento de privacidad como porque la PII en tu conjunto de evaluacion puede filtrarse en las salidas del modelo.

Reemplazar:

• Nombres con identificadores de rol (Cliente, Agente, Gerente)
• Direcciones de correo con user@example.com
• Numeros de telefono con formato 555-0100
• Numeros de cuenta/pedido con IDs genericos (ORDER-001, ACCT-A)
• Identificadores especificos de la empresa con etiquetas genericas

Automatiza esto con patrones regex para los casos obvios (correos, numeros de telefono) y haz una revision manual para identificadores especificos del dominio.

Paso 2: Categorizar

Etiqueta cada ejemplo con el tipo de tarea que representa. Categorias comunes:

• Clasificacion: La salida correcta es una etiqueta de un conjunto fijo
• Extraccion: La salida correcta es informacion especifica extraida de la entrada
• Generacion: La salida correcta es una respuesta en lenguaje natural
• Resumen: La salida correcta es una version condensada de la entrada
• Decision: La salida correcta es una recomendacion o juicio

Esta categorizacion te permite analizar el rendimiento del modelo por tipo de tarea en lugar de como un solo numero de precision. Un modelo podria ser 95% preciso en clasificacion pero solo 78% en generacion — esa distincion impulsa diferentes estrategias de mejora.

Paso 3: Etiquetar Salidas Esperadas

Para cada ejemplo, define como se ve una salida correcta. Este es el paso mas dificil y mas importante.

Para tareas de clasificacion: La etiqueta es inequivoca. Soporte al Cliente = "facturacion." Listo.

Para tareas de generacion: Escribe la salida ideal. Luego escribe 2-3 variaciones aceptables. Tu scoring debe aceptar cualquier salida que sea semanticamente equivalente, no solo coincidencias exactas.

Para tareas complejas: Define criterios clave en lugar de una salida exacta. Por ejemplo: "La respuesta debe (1) reconocer el error de facturacion, (2) indicar el monto correcto, (3) describir los pasos de resolucion, (4) proporcionar un cronograma." Puntua basandote en cuantos criterios cumple la salida.

Consejo profesional: Haz que dos personas etiqueten independientemente un subconjunto de 20 ejemplos. Mide su tasa de acuerdo. Si estan en desacuerdo en mas del 15% de los ejemplos, tus criterios de etiquetado son demasiado ambiguos — ajusta las guias antes de etiquetar el resto.

Paso 4: Formatear para Uso

Almacena tu conjunto de evaluacion en formato JSONL — un objeto JSON por linea, cada uno conteniendo:

{
  "id": "eval-001",
  "input": "The customer message or query",
  "expected_output": "The ideal model response",
  "category": "classification",
  "source": "support_tickets",
  "difficulty": "standard",
  "key_criteria": ["mentions refund policy", "provides timeline"],
  "date_added": "2026-02-15"
}

Versiona este archivo. Cada vez que agregues o modifiques ejemplos, incrementa la version. Necesitas saber que version del conjunto de evaluacion produjo que resultados.

Cuantos Ejemplos Necesitas

La respuesta corta: 50-200 para un conjunto de evaluacion solido.

La respuesta larga depende de lo que necesites medir:

• 50 ejemplos: Suficiente para detectar problemas mayores (diferencia de precision mayor al 10%). Los intervalos de confianza son amplios. Util para verificaciones iniciales de cordura.
• 100 ejemplos: Estandar para la mayoria de los despliegues de agencias. Te da estimaciones de precision con un margen de mas o menos 6-8 puntos porcentuales.
• 200 ejemplos: Evaluacion de alta confianza. Estimaciones de precision con un margen de mas o menos 4-5 puntos porcentuales. Vale la pena la inversion para despliegues de alto impacto.
• 500+ ejemplos: Evaluacion de grado empresarial. Solo necesario para aplicaciones de mision critica o cuando necesitas desglosar el rendimiento en muchas sub-categorias.

Distribucion dentro de tu conjunto de evaluacion:

• 60% casos estandar/comunes (representando el grueso del trafico de produccion)
• 25% casos de complejidad moderada
• 15% casos extremos y modos de fallo conocidos

No sobreponderes los casos extremos. Un conjunto de evaluacion con 50% de casos extremos te dara un numero de precision pesimista que no refleja el rendimiento real en produccion. Los casos extremos importan, pero deben ser proporcionales a su frecuencia real.

Manteniendo Tu Conjunto de Evaluacion a lo Largo del Tiempo

Un conjunto de evaluacion no es un artefacto de una sola vez. Necesita mantenimiento.

Adiciones mensuales: Agrega 10-20 nuevos ejemplos cada mes de datos recientes de produccion. Enfocate en casos que el modelo respondio mal o casos que representan patrones nuevos no cubiertos por los ejemplos existentes.

Revision trimestral: Cada 3 meses, revisa el conjunto de evaluacion completo en busca de ejemplos obsoletos. Elimina casos que ya no representan el caso de uso del cliente (productos descontinuados, politicas cambiadas, procesos actualizados).

Seguimiento de versiones: Cada actualizacion recibe un nuevo numero de version. Registra que version del conjunto de evaluacion se uso para cada evaluacion de modelo. Esto te permite rastrear si los cambios aparentes de rendimiento se deben a que el modelo mejoro o a que el conjunto de evaluacion cambio.

Nunca entrenes con datos de evaluacion. Esta regla es tan importante que vale la pena repetirla. En el momento en que un ejemplo de evaluacion aparece en tu conjunto de entrenamiento, ese ejemplo deja de medir generalizacion y empieza a medir memorizacion. Manten los datos de evaluacion y entrenamiento en archivos separados, directorios separados y control de versiones separado.

Del Conjunto de Evaluacion al Ciclo de Mejora

El conjunto de evaluacion no es solo para puntuar. Impulsa la mejora.

1. Ejecuta el modelo contra el conjunto de evaluacion e identifica los casos de fallo.
2. Categoriza los fallos: ¿Que tipos de tarea fallan? ¿Que patrones de entrada?
3. Recopila o genera 50-100 nuevos ejemplos de entrenamiento dirigidos a las categorias de fallo.
4. Reentrena el modelo con el conjunto de entrenamiento aumentado.
5. Vuelve a ejecutar el conjunto de evaluacion. Verifica que los casos de fallo esten corregidos.
6. Verifica que las demas categorias no hayan regresado.

Este ciclo — evaluar, identificar vacios, generar datos dirigidos, reentrenar, re-evaluar — es el nucleo de la mejora de modelos en produccion. El conjunto de evaluacion es lo que lo hace sistematico en lugar de conjeturas.

Ertas Studio soporta este flujo de trabajo directamente: sube tu conjunto de evaluacion, ejecuta evaluaciones con un clic, compara resultados entre versiones del modelo e identifica exactamente que categorias necesitan mas datos de entrenamiento. La plataforma rastrea tu historial de evaluacion para que puedas ver tendencias de mejora a lo largo del tiempo.

---

Lectura Adicional

• Generacion de Datos Sinteticos para Fine-Tuning — Como complementar datos de conversaciones reales con ejemplos sinteticos cuando necesitas mas volumen
• Como Evaluar Tu Modelo Ajustado — Los enfoques de evaluacion que usan el dataset que construyes aqui