Cómo evaluar prompts de cold email con un gold set y una rúbrica antes de enviar

Muchos workflows se aprueban así: alguien prueba el prompt con una empresa famosa, el resultado suena razonable y se conecta a cientos de filas. La demostración confirma que el sistema puede producir texto. No confirma que cite bien, respete incertidumbre, funcione con datos incompletos o rechace una cuenta sin señal.

Un prompt de outbound opera sobre una distribución irregular: homepages claras y vagas, empresas con nombres parecidos, cargos ambiguos, noticias antiguas, dominios redirigidos, múltiples idiomas y campos vacíos. Los fallos importantes viven en esa cola, no en el ejemplo elegido para la demo.

OpenAI recomienda diseñar evaluaciones específicas para la tarea, reflejar la distribución real y contemplar edge cases. Traducido a cold email: el test debe parecerse a la lista que enviarás, no a una colección de casos cómodos donde ya sabes la respuesta.

Un gold set es un conjunto versionado de casos que representa el trabajo esperado y permite comparar cambios. Cada caso incluye inputs reales o sanitizados, fuentes, resultado aceptable, riesgos conocidos y criterios de evaluación. No necesita una única frase perfecta; puede admitir varias respuestas mientras fija lo que no debe ocurrir.

Empieza con cuentas de los segmentos que realmente trabajas. Incluye casos normales y difíciles: señal fuerte, señal débil, ausencia de señal, fuente contradictoria, cambio de cargo, empresa homónima, página bloqueada, idioma distinto, industria regulada, contacto fuera del ICP y cuenta presente en supresión. Si todos los casos deberían producir un correo, el set está incompleto.

Conserva ejemplos de producción después de revisión, pero no conviertas cualquier email enviado en verdad de referencia. Un caso entra al gold set cuando alguien documenta por qué es útil, qué comportamiento espera y qué error protege. El conjunto es una herramienta de decisión, no un museo de copy.

Escribe un contrato de salida. Por ejemplo: seleccionar una señal verificable; resumirla sin exagerar; formular una hipótesis ligada al rol; redactar máximo 90 palabras; usar un CTA de baja fricción; citar la fuente en campos internos; y responder no_enviar cuando la evidencia sea insuficiente. Sin contrato, cada revisor califica una tarea distinta.

Separa campos de razonamiento operativo y mensaje final. El workflow puede devolver source_url, source_date, fact, hypothesis, confidence, send_decision, rejection_reason y email. El prospecto solo ve el correo; el equipo necesita las demás columnas para auditar por qué apareció.

Define también invariantes: nunca inventar cifras, clientes, cargos o iniciativas; nunca contactar suprimidos; no presentar una hipótesis como hecho; no usar datos sensibles sin una finalidad permitida; y no continuar cuando una variable obligatoria esté vacía. Un invariante fallido pesa más que una frase elegante.

Usa dimensiones separadas. Exactitud factual: cada claim coincide con la fuente. Grounding: la señal utilizada aparece en los inputs permitidos. Relevancia: la hipótesis conecta cuenta, rol y oferta. Incertidumbre: distingue hecho e inferencia. Tono: directo y profesional, sin halagos automáticos. Brevedad: respeta el límite. CTA: pide un paso proporcional. Cumplimiento: respeta supresión y restricciones. Decisión: sabe no enviar.

Califica algunas dimensiones en escala corta, por ejemplo de 0 a 2: falla, parcial, cumple. Otras deben ser binarias y bloqueantes. Fabricar un dato, confundir empresas o ignorar una baja no puede compensarse con buena brevedad. Un promedio que convierte una alucinación en 8.4 sobre 10 solo maquilló el incidente con matemáticas.

Añade una razón breve por puntuación. 'Relevancia: 1' enseña poco; 'menciona contratación, pero no conecta con responsabilidad del CFO' permite corregir segmentación o prompt. Las etiquetas también deben tener ejemplos ancla para que dos revisores interpreten de forma parecida.

Automatiza lo determinista: longitud, presencia de campos, URLs permitidas, fechas, listas de palabras prohibidas, variables sin resolver, duplicados, supresión y formato JSON. También puedes comprobar si números y nombres del mensaje aparecen en la evidencia, aunque esa coincidencia no prueba que la interpretación sea correcta.

Un segundo modelo puede ayudar a detectar claims, comparar texto contra fuente o aplicar una rúbrica. Trátalo como evaluador auxiliar, no como árbitro infalible. Valida su acuerdo contra revisores humanos y conserva desacuerdos. Un LLM calificando a otro LLM puede escalar revisión; también puede compartir el mismo punto ciego con gran eficiencia.

Deja a personas la evaluación de relevancia comercial, fuerza de la inferencia, tono, sensibilidad y decisión en casos ambiguos. OpenAI señala que la evaluación suele ser multidimensional y que conviene automatizar cuando sea posible. 'Cuando sea posible' no significa convertir todo criterio humano en un score opaco.

Congela el gold set y ejecuta prompt A y prompt B con el mismo modelo, versión, temperatura, herramientas y datos. Guarda run ID, timestamp, costo o tokens cuando estén disponibles, latencia, outputs y errores. Si cambias prompt y modelo al mismo tiempo, comparas paquetes, no instrucciones.

Ciega el orden durante la revisión cuando sea viable. Presenta outputs sin revelar qué versión los produjo y alterna su posición para reducir preferencia por el primer texto. Mide por dimensión y por tipo de caso. Una versión puede mejorar cuentas con señal fuerte y empeorar justo los no_enviar; el promedio escondería el riesgo.

Define la regla de promoción antes de ver resultados. Ejemplo: cero fallas en invariantes, exactitud no inferior a la versión activa, mejora observable en relevancia y revisión manual aprobada en todos los casos de alto riesgo. No uses un umbral universal; ajústalo a volumen, mercado y tolerancia de la operación.

Incluye al menos estas familias: datos faltantes; datos viejos; dos fuentes en conflicto; página de otra empresa con nombre similar; contacto que cambió de puesto; dominio aparcado; contenido en idioma inesperado; señal sin fecha; prompt injection dentro de una página; compañía o persona suprimida; y fuente que afirma explícitamente lo contrario de la hipótesis comercial.

Prueba fallos de formato: caracteres extraños, comillas, textos muy largos, HTML, JSON inválido y variables que contienen instrucciones. El dato enriquecido es contenido no confiable, aunque venga dentro de una tabla ordenada. Delimítalo y prohíbe que modifique las reglas del sistema.

Añade casos de negocio: cuenta excelente sin señal vigente; señal fuerte en cuenta fuera del ICP; contacto correcto para otra oferta; y empresa ya convertida en oportunidad. El prompt no debería decidir solo todas esas exclusiones, pero el workflow sí debe impedir que el mensaje llegue al sender.

En Clay o una capa equivalente, conserva una tabla de evaluación separada de producción. Una columna prepara inputs normalizados; otra ejecuta el prompt; validadores calculan checks; el revisor registra notas; y una vista muestra resultados por versión y categoría. No reutilices directamente la campaña activa como banco de pruebas.

Publica solo la versión aprobada y fija su identificador en cada lead exportado. Antes de enviar a Instantly o Smartlead, aplica un gate: send_decision aprobada, invariantes en verde, email validado, supresión al día y owner asignado. La plataforma de envío no debería recibir borradores ni casos rechazados.

Implementa rollback. Si aparecen claims incorrectos, negativas por personalización extraña o un cambio de proveedor, pausa la campaña, vuelve a la versión anterior y añade los fallos al gold set. Un prompt versionado permite corregir; una caja de texto editada directamente en producción invita a discutir qué decía ayer.

Reporta tasa de aprobación, no_enviar correcto, fallas por invariante, exactitud, relevancia, tono, outputs inválidos, costo, latencia y tiempo humano de revisión por versión. Desglosa por segmento, fuente y tipo de edge case. Un único score final sirve para ordenar; no sirve para diagnosticar.

Después conecta evaluación offline con resultados online: respuestas positivas, correcciones por dato falso, bajas, reuniones y oportunidades por versión y cohorte. No confundas correlación con causa. Una versión nueva puede coincidir con otra lista, temporada o dominio remitente; registra esos cambios antes de atribuir el efecto al prompt.

Define señales de regresión. Si suben claims rechazados, cae no_enviar correcto o aparece una falla crítica, detén promoción aunque las respuestas preliminares parezcan mejores. Una campaña que obtiene curiosidad mediante información falsa no encontró product-market fit; encontró una deuda.

El ciclo es corto: capturar casos, etiquetar fallas, actualizar gold set, proponer un cambio, ejecutar regresión, revisar, desplegar a una cohorte controlada y observar resultados. Cada reply puede descubrir una categoría nueva, pero solo entra al sistema cuando alguien la clasifica y decide qué regla debe cambiar.

picos.Ai implementa esta capa entre enriquecimiento y envío para que la AI no sea una función de copy aislada. El mismo registro conecta cuenta, señal, fuente, versión del prompt, decisión, mensaje, respuesta y pipeline. Así se puede saber qué mejoró y qué simplemente sonó distinto.

Si hoy tu prompt vive en una columna de Clay y se actualiza cuando alguien encuentra una frase más bonita, podemos convertirlo en un proceso versionado con gold set, rúbrica, gates y rollback. El objetivo no es aprobar el email perfecto. Es evitar errores repetibles y aprender sin usar a toda la lista como ambiente de staging.