Respuesta directa
En pocas palabras
Para evaluar un AI Sales Copilot, define primero las decisiones que debe apoyar y reúne casos representativos, difíciles y críticos. Cada caso necesita entradas controladas, fuentes autorizadas, comportamiento esperado, criterios de aceptación y una persona responsable de revisar. Prueba exactitud, fundamento, precios, monedas, permisos, abstención y utilidad por separado; compara cada versión con una línea base y no autorices el cambio si un promedio aceptable oculta una falla crítica.
Empieza por la decisión, no por una métrica genérica
Un conjunto de evaluación sirve para decidir si un comportamiento puede entrar, permanecer o ampliarse en un proceso real. Antes de escribir casos, describe la tarea: resumir una oportunidad, sugerir un siguiente paso, preparar una propuesta o responder una pregunta sobre el pipeline. Después identifica quién usará la salida y qué podría ocurrir si está equivocada.
La misma respuesta puede ser aceptable como borrador interno y peligrosa como mensaje listo para un comprador. Clasifica el impacto según los datos consultados, la audiencia, el efecto comercial, la reversibilidad y la revisión disponible. Esa clasificación determina la profundidad de las pruebas y quién debe aprobar el resultado.
NIST plantea que los métodos y las métricas deben elegirse según el contexto de uso y los riesgos más importantes. Por eso una puntuación universal de calidad no basta. El conjunto debe representar las decisiones que la organización realmente espera sostener.
Define qué versión y qué recorrido estás evaluando
Registra el sistema completo que produce la salida: versión del modelo cuando esté disponible, instrucciones, fuentes, reglas, herramientas, permisos, configuración y fecha. Evaluar solo el texto final impide saber si un error nació en la recuperación de datos, en una regla comercial, en el acceso o en la generación.
Define también el punto de inicio y el de término. Una prueba puede abarcar desde una pregunta hasta un borrador, o incluir búsqueda, selección de catálogo, cálculo determinista, revisión y guardado. Si una herramienta ejecuta acciones, comprueba tanto la decisión de usarla como los argumentos enviados y el estado resultante.
Asigna un identificador a cada configuración evaluada. Cuando cambie una fuente, un prompt o un permiso, conserva la versión anterior y vuelve a ejecutar los casos afectados. Sin esta trazabilidad, dos resultados parecidos pueden proceder de sistemas distintos.
Construye una muestra que se parezca al trabajo real
Empieza con los escenarios frecuentes, pero reserva una parte importante para condiciones difíciles. Incluye oportunidades nuevas y antiguas, cuentas con varias personas, etapas distintas, periodos sin actividad, notas ambiguas, datos faltantes y solicitudes fuera del alcance. Una colección formada solo por ejemplos limpios mide una demostración, no una operación.
Representa la diversidad del proceso, no datos personales innecesarios. Puedes utilizar registros sintéticos o desidentificados cuando conserven las relaciones y excepciones que necesitas probar. Documenta qué condiciones imitan y cuáles no pueden validar. Un caso sintético puede comprobar lógica de monedas; no demuestra que los permisos reales estén bien configurados.
Separa el conjunto que utilizas para diseñar la solución del conjunto reservado para comprobarla. Si el equipo ajusta instrucciones mirando todos los ejemplos, aprenderá a resolver esa colección sin demostrar comportamiento ante casos nuevos. Mantén además una lista de regresión con fallas que ya ocurrieron y no deben reaparecer.
| Criterio | Qué representa | Ejemplos |
|---|---|---|
| Frecuente | Trabajo normal del equipo | Resumen, siguiente paso, consulta de cuenta |
| Borde | Ambigüedad o información incompleta | Fecha dudosa, contacto sin función, actividad antigua |
| Crítico | Error con efecto relevante | Precio ausente, moneda incorrecta, acceso indebido |
| Regresión | Falla conocida ya corregida | Fuente vencida, duplicado, acción sin autoridad |
Escribe cada caso para que otra persona pueda repetirlo
Un caso necesita más que una pregunta y una respuesta ideal. Registra el escenario, la identidad o rol de prueba, las entradas, el contexto autorizado, las fuentes disponibles, la acción solicitada y el estado esperado. Añade cualquier dato que deba permanecer oculto para comprobar que el sistema no lo utilice ni lo revele.
Describe el comportamiento aceptable antes de ejecutar la prueba. En una tarea abierta pueden existir varias respuestas correctas, así que define hechos obligatorios, afirmaciones prohibidas, advertencias necesarias y una acción posterior válida. En una tarea determinista, como recuperar un precio, exige coincidencia exacta con la fuente y su moneda.
Guarda también la evidencia de la ejecución: salida, fuentes citadas, herramientas llamadas, tiempos, evaluaciones y decisión humana. La repetibilidad no exige que la redacción sea idéntica; exige que los criterios puedan aplicarse de la misma forma.
Separa exactitud, fundamento y utilidad
Una respuesta puede sonar clara y seguir siendo incorrecta. Evalúa dimensiones distintas: si responde a la tarea, si cada afirmación importante está sostenida por el contexto, si conserva hechos y condiciones, si respeta instrucciones, si comunica incertidumbre y si propone una acción que una persona puede revisar.
Utiliza escalas con anclas observables. En lugar de calificar del uno al cinco por intuición, explica qué distingue cada nivel. Por ejemplo: aprobado significa que todos los hechos críticos proceden de la fuente y la ausencia queda visible; condicionado significa que el borrador es útil pero requiere una corrección no crítica; rechazado significa que inventa, contradice o expone información.
No combines todo en una sola nota si existe una condición obligatoria. Una redacción excelente no compensa un precio inventado. La utilidad comercial tampoco compensa una violación de permisos. Conserva los resultados por criterio y define cuáles funcionan como puerta de salida.
Incluye fallas comerciales que un promedio no debe ocultar
Prueba precios ausentes, vencidos y contradictorios; productos sin unidad; descuentos fuera de autoridad; impuestos o condiciones no confirmadas; y propuestas con versiones diferentes. El comportamiento esperado puede ser detener el borrador, mostrar el conflicto o pedir confirmación. Completar el documento no siempre es el resultado correcto.
Mantén MXN, USD y otras monedas como datos explícitos. Comprueba que no se sumen ni conviertan sin un método aprobado, una fecha de referencia y una fuente. Incluye importes iguales en monedas distintas para detectar interfaces o resúmenes que omiten la etiqueta.
Evalúa también señales comerciales. Una apertura de Buyer Room no demuestra identidad, lectura, aceptación, contrato, pago ni intención de compra. Una etapa elegida por el vendedor no prueba un compromiso del comprador. El copiloto debe distinguir observación, inferencia y decisión.
Prueba acceso, instrucciones adversarias y límites del alcance
Ejecuta el mismo escenario con roles distintos. Una persona debe recibir únicamente el contexto que ya puede consultar. Incluye registros de otra cuenta, campos confidenciales, adjuntos restringidos, enlaces revocados y cambios recientes de responsabilidad. Ocultar un dato en la interfaz no demuestra que la herramienta dejó de recuperarlo.
Añade instrucciones contenidas dentro de notas, archivos o contenido externo que intenten cambiar el objetivo, solicitar secretos o saltarse la revisión. El resultado esperado es ignorar la instrucción no autorizada, conservar el límite y registrar suficiente evidencia para investigar.
Prueba solicitudes que el sistema no debe resolver: confirmar un cierre, autorizar un descuento, atribuir identidad a una visita o inventar un dato faltante. Una abstención clara, con la razón y el siguiente paso, es una salida exitosa cuando evita un efecto no autorizado.
Calibra la revisión humana antes de automatizarla
Selecciona evaluadores que conozcan el proceso y no hayan diseñado todos los casos. Ventas revisa utilidad y lenguaje; operaciones valida el flujo; datos confirma las fuentes; seguridad y privacidad comprueban acceso; producto y tecnología investigan el comportamiento. No todos necesitan revisar cada caso, pero las responsabilidades deben estar asignadas.
Haz una ronda de calibración con una muestra compartida. Cada persona puntúa de forma independiente y después compara diferencias. Si dos especialistas interpretan distinto un criterio, corrige la rúbrica antes de ampliar la evaluación. El desacuerdo es información sobre una definición incompleta, no ruido que deba borrarse.
Conserva correcciones y motivos sin convertir cualquier preferencia de estilo en una falla. Separa un error factual, una omisión crítica, una recomendación débil y una variante de redacción aceptable. Esa taxonomía ayuda a decidir qué corregir en datos, instrucciones, interfaz, capacitación o proceso.
Utiliza evaluadores automáticos como apoyo, no como árbitro único
Las comprobaciones deterministas sirven para precios, monedas, formatos, campos obligatorios, permisos y presencia de fuentes. Los evaluadores asistidos por otro modelo pueden ampliar la revisión de relevancia, fundamento o cumplimiento de instrucciones. Microsoft Foundry documenta evaluaciones por conjunto de datos con criterios integrados y personalizados; Google recomienda contrastar la calidad de un modelo juez con calificaciones humanas usadas como referencia.
Antes de confiar en un evaluador automático, mídelo contra casos que personas calificaron. Revisa falsos aprobados y falsos rechazos, sobre todo en condiciones críticas. Un juez que coincide en promedio puede fallar precisamente cuando la respuesta inventa una condición comercial poco frecuente.
Guarda la versión del evaluador, su instrucción, el umbral y los datos usados para calibrarlo. No presentes su puntuación como verdad objetiva. Si el evaluador cambia, vuelve a medirlo y conserva la comparación con la revisión humana.
Compara la versión candidata con una línea base estable
Ejecuta el mismo conjunto contra la versión activa y la candidata. Compara resultados por escenario y criterio, no solo el promedio general. Una mejora en fluidez puede coincidir con una caída en abstención o una nueva falla de permisos. Registra también empates y casos que no pudieron evaluarse.
Investiga cada regresión crítica antes de decidir. Determina si procede del modelo, las instrucciones, la recuperación, una fuente, una regla, una herramienta o el método de evaluación. Corregir el componente equivocado puede ocultar el síntoma sin resolver la causa.
Añade a la colección estable cualquier incidente o error que merezca no repetirse. Revisa duplicados y casos obsoletos para que el conjunto siga siendo manejable. Una biblioteca de regresión crece con la experiencia, pero debe conservar propósito y dueño.
Define la puerta de salida antes de ver el resultado
Escribe los criterios de aprobación, rechazo y aprobación condicionada antes de ejecutar. Puedes exigir cero fallas críticas de precios y acceso, un nivel mínimo por escenario frecuente y una revisión adicional para los casos ambiguos. Define también el tamaño de la muestra y qué incertidumbre todavía aceptará la empresa.
Una media alta no autoriza una versión si existe una falla que rompe una condición obligatoria. Tampoco exige perfección absoluta en preferencias de estilo. Relaciona cada umbral con el impacto y con una respuesta: corregir, limitar alcance, añadir revisión, volver a probar, mantener la versión anterior o detener la función.
La decisión debe indicar quién aprueba, qué evidencia revisó, qué excepciones quedan abiertas, durante cuánto tiempo y qué monitoreo se activará. NIST recomienda documentar decisiones de salida y no salida, límites aceptables y acciones cuando el sistema los supera.
Mantén el conjunto vivo durante la operación
Repite la evaluación cuando cambien modelo, instrucciones, fuentes, catálogo, permisos, herramientas o reglas comerciales. Ejecuta una selección estable en cada cambio y una revisión más amplia antes de aumentar usuarios, datos o autonomía. Etiqueta los resultados con la versión que produjo cada salida.
Incorpora feedback e incidentes después de confirmar la causa. No copies datos personales innecesarios al conjunto. Desidentifica, restringe el acceso, define retención y elimina muestras que ya no tengan finalidad. Conserva suficiente evidencia para explicar por qué existe cada caso.
Compara las pruebas con lo observado en producción. Si el conjunto aprueba mientras los usuarios corrigen el mismo problema, la muestra o la rúbrica ya no representa el trabajo. Actualiza el método sin reescribir la historia de resultados anteriores.
Aplica el conjunto a los límites verificables de Cerravi
En Cerravi, un conjunto de evaluación debe comprobar que las sugerencias permanecen sujetas a revisión humana y que el contexto visible sostiene el siguiente paso. La calidad no consiste en persuadir siempre, sino en distinguir hechos, señales, faltantes e inferencias.
Las propuestas utilizan productos y precios disponibles en el catálogo cargado. Si un importe no existe o las fuentes entran en conflicto, el caso debe esperar una confirmación; Cerravi no inventa la cifra. MXN, USD y otras monedas permanecen separadas mientras no exista una conversión aprobada.
Forecast es una estimación operativa basada en reglas transparentes y datos registrados en el CRM. No es un modelo predictivo entrenado o calibrado y no garantiza cierres ni ingresos. Las pruebas deben reflejar ese límite y rechazar cualquier salida que convierta una estimación en certeza.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Cuántos casos necesita un conjunto de evaluación?
No existe una cifra universal. Empieza con cobertura por escenario y riesgo: casos frecuentes, bordes, fallas críticas y regresiones. Amplía cuando aparezcan condiciones nuevas o cuando la variación del resultado impida una decisión confiable. La calidad de la cobertura importa más que acumular ejemplos repetidos.
¿Qué diferencia hay entre una respuesta esperada y una rúbrica?
Una respuesta esperada describe un resultado de referencia. Una rúbrica define qué hechos, límites y comportamientos hacen aceptables varias respuestas posibles. Para texto abierto suele ser más útil una rúbrica; para precios, monedas, permisos o acciones deterministas conviene exigir coincidencias y prohibiciones precisas.
¿Se puede evaluar un AI Sales Copilot solo con otro modelo?
No conviene usarlo como única autoridad. Un modelo juez puede ampliar cobertura, pero debe calibrarse contra decisiones humanas y complementarse con comprobaciones deterministas. Los casos de alto impacto, acceso, precios y excepciones comerciales requieren revisión de personas responsables.
¿Qué debe bloquear una salida a producción?
Cualquier falla definida como crítica: acceso indebido, precio o moneda inventados, acción sin autoridad, divulgación de información, incapacidad de detenerse ante falta de contexto o una regresión que supera el riesgo aceptado. Los bloqueos y responsables deben acordarse antes de ver el resultado.
¿Cada cambio de prompt necesita una evaluación completa?
Necesita una evaluación proporcional al impacto. Ejecuta siempre los casos estables y los relacionados con el cambio. Amplía la revisión cuando cambien fuentes, permisos, herramientas, comportamiento crítico, población o autonomía. Conserva la versión anterior y una ruta de reversión.