Herramienta de trabajo para equipos técnicos y consultoras
Elegir un modelo por cómo resuelve tu trabajo
Comparar un candidato con el modelo actual sobre la misma tarea, conservando los fallos y separando calidad, tiempo y coste.
Por Sergio Sallavera, 8 de septiembre de 2026. Versión 1.0
Demostración interactiva con ejemplos editables
Compara dos respuestas con las mismas reglas
Carga los ejemplos o pega dos respuestas obtenidas por tu equipo. El evaluador comprueba JSON, el esquema mínimo del informe y si sus fragmentos aparecen literalmente en la fuente.
Los ejemplos son respuestas preparadas para probar el evaluador, no un benchmark de modelos. Un fragmento presente no demuestra que la conclusión sea correcta. La utilidad, el idioma, las omisiones, el tiempo y el coste del modelo siguen pendientes de evaluación.
La decisión que importa
Que un modelo responda, entregue JSON válido y use una herramienta correctamente no demuestra que resuelva bien el trabajo del equipo. Puede superar esas comprobaciones y fallar en el idioma, el alcance o la utilidad de la respuesta.
Esta guía ayuda a un responsable técnico o una consultora a decidir si mantiene el modelo actual, incorpora un candidato para ciertas tareas o lo sustituye. La unidad de comparación es una tarea concreta, no una clasificación general de modelos.
Alcance: protocolo y plantillas para una evaluación propia. No es un benchmark ejecutado ni una recomendación de proveedor. La base es una experiencia documentada en mi laboratorio: un candidato superó pruebas técnicas, pero mostró limitaciones editoriales y quedó como perfil opcional.
Arquitectura de la evaluación
- Fijar el trabajo y el criterio. Elegir una tarea habitual y escribir qué significa resolverla. Separar requisitos críticos de preferencias y acordar el umbral antes de ver resultados.
- Preparar un conjunto de casos. Incluir situaciones normales, datos ausentes, contradicciones y fallos de herramientas. Una persona fija la respuesta esperada o los requisitos verificables.
- Ejecutar una comparación controlada. Usar las mismas fuentes, instrucciones y herramientas para modelo actual y candidato. Abrir sesiones limpias y registrar versiones, configuración e intentos.
- Revisar las respuestas. Aplicar reglas para formato y herramientas, y revisión humana para utilidad y fidelidad. Conservar respuestas incompletas, errores y salidas descartadas.
- Registrar la decisión. Comparar calidad, tiempos, costes y trabajo de corrección. Mantener, probar en un alcance reducido o adoptar con una vía de retorno.
Una carpeta versionada, un ejecutor sencillo y una hoja de resultados bastan para comenzar. No hace falta otro agente que decida cuál es mejor. Si se usa un modelo como evaluador auxiliar, contrastar su criterio con una muestra revisada por personas.
Un trabajo concreto: revisar una campaña
La plantilla usa el proceso del guía de QA de email: contrastar un briefing con una pieza y devolver incidencias con evidencia. El equipo debe aportar los archivos saneados o preparar las entradas de prueba antes de ejecutar.
- Técnica: esquema de salida, campos obligatorios y argumentos de herramientas, cuando las haya.
- Contenido: localizar discrepancias, citar el fragmento correcto y no inventar una fuente.
- Uso real: respetar idioma, extensión acordada, prioridades y límites de la tarea.
- Recuperación: declarar una comprobación pendiente cuando falta un archivo o falla una herramienta.
Los siete escenarios incluyen una campaña sin incidencias preparadas y casos de error. La matriz reserva una fila para el modelo actual y otra para el candidato por escenario. Las celdas de resultados, tiempos y costes están vacías.
Una comparación que se pueda repetir
Guardar identificador exacto del modelo o servicio, fecha, versión del prompt, archivos de entrada, herramientas, límites y configuración. Acordar las repeticiones por caso y conservar cada intento. Si una plataforma no permite igualar una opción, documentar la diferencia.
Medir el tiempo de principio a fin y distinguir preparación, inferencia, herramientas y revisión humana cuando sea posible. Registrar tokens y coste facturado; si el modelo es local, indicar hardware y método de estimación. Local no significa coste cero.
En una muestra pequeña, enseñar los tiempos observados y su dispersión. No presentar percentiles estables ni conclusiones universales. Un fallo crítico no desaparece porque la media de otras pruebas sea buena.
Material para ejecutar y decidir
El protocolo (Markdown) incluye preparación, criterios, registro de entorno y acta de decisión. La matriz (CSV) contiene siete escenarios y dos variantes, con estado «No ejecutado».
Antes de usarla, completar entradas y expectativas, fijar los modelos y acordar qué fallos bloquean una adopción. Añadir filas por repetición y enlazar cada una con su salida íntegra. La plantilla organiza la evaluación; no ejecuta llamadas a modelos.
Después, una revisión sin mostrar el nombre del modelo puede reducir preferencias previas. Registrar discrepancias entre revisores y resolverlas con los requisitos de la tarea. Reservar nuevos casos para comprobar que una mejora del prompt no se limita a los ejemplos conocidos.
Lo que aprendí en mi entorno propio
En las pruebas recogidas en mi caso de agentes (PDF), un candidato funcionó en integración, respuesta exacta, JSON estricto y argumentos de herramientas. En una tarea editorial ignoró el idioma solicitado y produjo una respuesta demasiado larga.
La decisión fue mantenerlo como perfil opcional y conservar el modelo principal con una vía de retorno documentada. No publico aquí cifras de rendimiento ni extrapolo esa decisión a todos los modelos o tareas.
La referencia metodológica es Demystifying evals for AI agents, de Anthropic. El protocolo adapta la evaluación por tareas a un piloto pequeño con comprobaciones técnicas y revisión de utilidad.
¿Estás valorando cambiar de modelo?
Podemos elegir un trabajo de tu equipo, acordar qué debe resolver y preparar una comparación que permita tomar una decisión con evidencia.