La puntuación convierte un benchmark de «revisar el JSON a ojo» en un número objetivo. El resultado de cada modelo se evalúa con una referencia dorada —la salida esperada— y produce una puntuación de exhaustividad, corrección y calidad general por la que puede ordenar.
La puntuación necesita algo con lo que comparar. Cada escenario incluye una salida de referencia: la respuesta correcta para su única entidad fija. Créela generando con modelos potentes (búsqueda web + un documento de fuente de verdad), pegando un resultado válido conocido y editándolo luego a mano; y márquela como verificada cuando confíe en ella. Una referencia verificada es obligatoria para hacer benchmark del escenario, de modo que siempre haya algo con lo que comparar. Si más adelante edita la referencia —o cambia la configuración de puntuación del escenario—, las puntuaciones existentes se marcan como obsoletas hasta que vuelva a puntuar.
La referencia también se actualiza sola. Una referencia verificada sigue siendo un borrador corregido a mano, y los modelos que somete a benchmark son sus revisores: allí donde el juez considera que la respuesta de un candidato es mejor que la de la referencia (o que la de la referencia es incorrecta), allí donde las propias muestras del escenario demuestran que la referencia es incorrecta y allí donde un modelo rellena un valor que la referencia dejó vacío y el juez lo confirma, el resultado registra un hallazgo. Al final de cada pasada de puntuación, los hallazgos de todos los modelos puntuados se combinan —primero lo que demuestran las muestras, después la respuesta que dio la mayoría de los modelos— y se escriben en la referencia. Una edición ya realizada por una pasada solo se sustituye por evidencia más sólida (las muestras, un veredicto de que el valor es incorrecto o más modelos coincidentes, contados a lo largo de las pasadas), nunca por la opinión de un modelo más, de modo que evaluar los modelos de uno en uno no puede desviar la referencia hacia el último puntuado. Estas ediciones automáticas nunca marcan las puntuaciones como obsoletas (solo lo hacen sus propios guardados) y todas quedan registradas con el valor que sustituyeron y los modelos que las plantearon.
Revíselos como control de cambios: la vista Referencia del escenario, junto a sus resultados, muestra la propia referencia con cada edición automática resaltada en el lugar que ocupa: el valor anterior tachado, el nuevo, cuántos modelos lo respaldan y por qué. Todo se acepta salvo que lo rechace; un rechazo restaura el valor anterior y mantiene esa ruta fuera de las pasadas futuras. Filtre por atributo o por evidencia (las ediciones de un solo modelo son las que conviene revisar), seleccione lo que se muestra y rechace en bloque.
El problema de fondo: dos respuestas correctas pueden estar escritas de forma diferente. Un modelo que nombra a un actor como «R. Downey Jr.» en lugar de «Robert Downey Jr.» no está equivocado. Por eso cada campo se compara con una escala por niveles: primero lo más barato y seguro, escalando solo cuando es necesario:
Los valores idénticos coinciden. También los que difieren solo en mayúsculas/minúsculas, espacios circundantes o precisión numérica ("Acme" = "ACME", 4.0 = 4). Gratis y totalmente determinista.
Para el texto, el candidato y la referencia se incrustan y se comparan mediante similitud de coseno. Por encima del umbral cuentan como iguales, de modo que una grafía alternativa válida como «R. Downey Jr.» frente a «Robert Downey Jr.» es una coincidencia, no un error. Las fechas son la excepción: se comparan como valores de calendario, nunca por similitud, por lo que una fecha casi correcta pero errónea («1972-03-14» frente a «1972-03-24») es una discrepancia clara en lugar de un coseno engañosamente alto. Los valores booleanos son igualmente exactos o nada.
Los valores que la similitud no permite decidir —todos los campos de texto libre, como resúmenes y descripciones; cualquier número que no sea idéntico; y un valor claramente distinto que respalden sus documentos o la mayoría de los demás modelos— se envían a un modelo juez. El juez es ciego: ve los dos valores como A y B, junto con la posición del campo en el esquema (sus padres y sus descripciones, su tipo y a qué elemento de lista pertenece) y sus documentos de origen cuando el escenario los tiene, e indica cuál sirve mejor al campo, si ambos son correctos o si uno es incorrecto. Un candidato juzgado equivalente o mejor que la referencia —o una referencia juzgada incorrecta— obtiene la puntuación completa; una respuesta más débil obtiene puntuación parcial y una incorrecta, poca o ninguna. Un número recibe puntuación parcial cuando el campo lo tolera (un peso molecular de 273.37 frente a 273.35, una semivida de 12 frente a 15) y falla cuando la exactitud importa (un año de lanzamiento de 2020 frente a 2023). Un valor que la referencia dejó vacío se consulta por separado: si se confirma como correcto, cuenta como un valor que la referencia debería haber contenido y que el modelo encontró —la puntuación sube, no solo queda sin penalizar— y la referencia lo adopta.
Un ajuste de rigurosidad controla el umbral de embedding: un valor más alto significa que dos valores escritos de forma diferente deben ser más similares para considerarse iguales. La rigurosidad, el modelo juez opcional y el modelo de embedding se establecen todos en el escenario —no se eligen cada vez que evalúa— de modo que cada modelo se evalúa de forma idéntica y las puntuaciones se mantienen comparables.
Las listas —el reparto de una película, los efectos secundarios de un fármaco— son donde más difieren los modelos: un modelo pequeño podría encontrar 4 actores donde uno potente encuentra 15. El orden no importa, y encontrar más elementos correctos debería ganar. Por eso los arrays se puntúan como un conjunto, no posición por posición:
Expanda una fila de resultados para ver exactamente qué elementos coincidieron, se omitieron o se alucinaron.
Un único número oculta demasiado, por lo que cada resultado incluye subpuntuaciones:
La fila expandible muestra el desglose por campo: candidato frente a referencia, qué peldaño de la escalera lo decidió y la similitud cuando sea pertinente.
La calidad es solo un tercio de la historia. Cuando un benchmark alimenta la selección de modelos —como fuente de puntuación—, la posición del modelo surge de combinar calidad, velocidad y coste, y esa proporción la decide usted: configúrela por tipo de escenario en Configuración → Organización → Valores predeterminados; cada conjunto suma 100 y se reparte por igual de forma predeterminada. Si pondera mucho el coste, un modelo barato y aceptable superará a uno excelente y caro, lo cual es la respuesta correcta para algunas cargas de trabajo y la equivocada para otras, así que la plataforma prefiere no decidirlo por usted. La velocidad y el coste se leen frente a los demás resultados del escenario en escala logarítmica: el modelo más rápido o más barato obtiene 100 y uno diez veces más lento o más caro obtiene 0, pero un grupo muy parejo nunca se estira para llenar el rango — dos modelos a 10 $ y 12 $ quedan en 100 y 92, no en 100 y 0.
Cuando un escenario ejecuta un modelo más de una vez (repeticiones), cada ejecución se puntúa por separado y la fila muestra la calidad media más una dispersión de consistencia (de la más baja a la más alta de las ejecuciones), de modo que resulta fácil detectar un modelo que acierta de media pero es errático. La salida visible es la ejecución con la calidad mediana.
Los benchmarks no se limitan al enriquecimiento: un escenario también puede probar la generación de muestras (cada modelo inventa un JSON de ejemplo para la misma solicitud en texto libre) o la generación de esquemas (cada modelo convierte una muestra fija en un esquema). Cada una tiene sus propias reglas de puntuación:
En cualquier caso, las columnas habituales conservan su significado: pase el cursor sobre el encabezado de una columna para ver la definición específica del tipo y expanda una fila para ver el desglose completo.
La puntuación es una pasada independiente sobre resultados ya guardados — nunca vuelve a enriquecer, por lo que nunca se paga de nuevo por los modelos evaluados. Lo que sí hace es generar embeddings de texto para comparar valores (y ejecutar el juez, si el escenario tiene uno), lo que descuenta créditos según el uso. Esto ocurre automáticamente durante cada ejecución —cada modelo se puntúa en cuanto terminan sus ejecuciones— y de nuevo cada vez que vuelve a puntuar. Si su organización no tiene configurado un modelo de embeddings (y el escenario no define ninguna anulación), la puntuación se ejecuta igualmente, pero recurre solo a la coincidencia exacta (las grafías alternativas cuentan entonces como discrepancias) y así lo indica. Un juez averiado es distinto: si una llamada al juez falla, la puntuación se detiene con un error explícito y el modelo afectado no conserva puntuaciones parciales — un resultado o está totalmente puntuado o no lo está en absoluto, y se puede volver a puntuar más adelante. Las respuestas del juez se almacenan en caché por escenario según su contenido: la misma pregunta planteada por otro modelo, repetición o pasada nunca se paga dos veces, y volver a puntuar después de que la referencia se haya actualizado solo replantea las preguntas de los campos editados. Nada de lo que hace el juez queda oculto: cada pasada de puntuación sobre un modelo deja un registro de puntuación en el Historial —una fila por llamada al juez con su prompt, su respuesta, sus tokens y su coste, incluidas las llamadas fallidas, además de cuántas preguntas respondió la caché sin coste— y la tabla de resultados muestra el coste del juez, el número de llamadas y el tiempo de puntuación de cada modelo junto a un enlace a dicho registro. Al elegir el juez, tenga en cuenta que los jueces LLM pueden favorecer a su propia familia de modelos: es preferible un juez de un proveedor que no esté evaluando en el benchmark.
En Gestión de modelos → Benchmarks, defina y verifique una referencia en el editor de escenarios (y elija allí su modelo juez, su modelo de embeddings y el nivel de exigencia). A partir de entonces, cada ejecución puntúa automáticamente sus resultados correctos: una columna Calidad ordenable se completa sin ningún paso adicional. Use Volver a puntuar resultados (el botón de la cabecera o el menú ···) para recalificar tras editar la referencia o la configuración de puntuación. La insignia de actualizaciones de la referencia, junto al estado de la referencia, abre el registro de lo que cambiaron las pasadas de puntuación, con una opción de revertir por entrada.