Cómo evaluar una automatización que prepara registros de CRM

Delimita qué se está evaluando

Esta propuesta evalúa la preparación de un registro, no la creación de una oportunidad ni el envío de una respuesta comercial. La entrada es una solicitud autorizada o sintética. La salida incluye campos extraídos, referencia al origen y estado de revisión. Separar estas etapas evita confundir «el modelo devolvió algo» con «el CRM quedó correcto».

Antes de observar resultados, decide qué campos son imprescindibles y cómo se representa su ausencia. En el ejemplo de esta guía, email, empresa y servicio permiten preparar un candidato; un presupuesto no mencionado debe permanecer en null. No se infiere consentimiento comercial ni una probabilidad de compra a partir del texto.

El resultado aceptable se define por tarea original. Si hay tres intentos y uno termina bien, existe una tarea finalmente aceptada y tres intentos que consumieron recursos. Conserva ambas cantidades para evaluar calidad y coste sin cambiar el denominador.

Escribe el contrato de aceptación

La comprobación de forma debe ser automática; la de significado necesita una referencia y revisión. JSON Schema permite exigir propiedades y restringir claves adicionales. Aun así, un email sintácticamente válido puede haberse copiado de la firma equivocada.

Una corrección manual puede convertir un borrador en aceptado, pero debe contabilizarse. Distingue «aceptado sin cambios», «aceptado tras corrección» y «rechazado». Si cambias la definición entre configuraciones, la comparación pierde su propósito.

Construye casos con salidas esperadas

El conjunto sintético descargable incluye cinco casos iniciales de CRM. Son una comprobación mínima del protocolo, no una muestra representativa. Empieza por una solicitud clara, otra sin email, una ambigua, una repetida y otra con instrucciones incrustadas. Amplía los casos antes de pretender describir un entorno real.

Ejemplo de salida esperada para un mensaje ficticio:

{
  "request_id": "SYN-CRM-001",
  "empresa": "Taller Norte",
  "email": "ana@example.com",
  "servicio": "revision_campanas",
  "presupuesto": null,
  "status": "pending_review"
}

No ajustes la extracción hasta acertar estos cinco casos y presentes ese mismo conjunto como evaluación independiente. Mantén ejemplos separados para desarrollar el prompt y para evaluar una versión congelada. Si una discrepancia hace revisar la etiqueta esperada, conserva el motivo y repite las alternativas afectadas.

Congela la configuración y conserva las trazas

Anota versión del flujo, prompt completo, esquema, runtime, modelo y digest cuando exista. Fija también temperatura, límite de entrada, timeout y reintentos. Ollama documenta salidas restringidas por esquema; su disponibilidad no acredita la exactitud de un modelo concreto para esta tarea.

La traza mínima contiene ID del caso, configuración, repetición, intento, timestamps, salida, error, decisión del revisor y tiempo de revisión. Conserva los datos sintéticos completos. Para datos reales, diseña antes permisos, saneamiento y retención; no copies solicitudes comerciales a un informe público.

El protocolo de CRM propone tres repeticiones por caso y configuración. Las repeticiones ayudan a observar variabilidad, pero no multiplican el número de casos independientes.

Evalúa el resultado y la abstención

La guía de evaluaciones de Anthropic distingue el recorrido de una ejecución de su resultado. Aplicado aquí, revisar solo las explicaciones del modelo es insuficiente: hay que comprobar los campos entregados y, en una integración futura, consultar el estado del sistema de destino.

Para una solicitud sin email, el comportamiento correcto puede ser preparar un borrador incompleto que pida revisión. Eso es una abstención útil en un campo, no necesariamente un fallo global. Define antes qué casos admiten ese tratamiento y cuáles necesitan rechazar toda la tarea. No uses la confianza verbal del modelo como criterio de aceptación.

Registra errores críticos por separado: inventar un contacto, mezclar dos remitentes o escribir dos registros. Una media de exactitud de campos puede ocultar un error operativo grave. Acompaña cualquier porcentaje con sus recuentos y su alcance.

Convierte los fallos en una decisión

Al terminar una ejecución futura, publica aceptados, corregidos, rechazados y abstenciones, además del tiempo y coste de todos los intentos. Si la muestra es pequeña o los casos no representan la carga real, declara esa limitación antes de generalizar.

El siguiente paso depende del fallo observado: mejorar el formulario si la entrada es deficiente; endurecer el contrato si aparece una clave inesperada; introducir revisión si hay ambigüedad semántica; corregir idempotencia si hay duplicados. Hasta ejecutar el protocolo, las dos fichas del Atlas permanecen como propuestas y sus resultados como «No medido».