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.
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 demasiado ajustados para decidirse por similitud —todos los campos de texto libre, como resúmenes y descripciones, y cada número no idéntico— se envían a un modelo juez, que califica de 0 a 100 hasta qué punto la respuesta capta el significado de la referencia. Recompensa una respuesta correcta redactada de forma distinta o más breve, y otorga a un número crédito parcial cuando el campo lo tolera (un peso molecular de 273,37 frente a 273,35, una vida media de 12 frente a 15), sin dejar de rechazarlo cuando la exactitud importa (un año de lanzamiento de 2020 frente a 2023). Sin un juez, el texto libre recurre a una puntuación de similitud continua, y un número no idéntico es simplemente una discrepancia.
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 resulta 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 decente superará a uno excelente y caro — lo cual es la respuesta correcta para unas cargas de trabajo y la equivocada para otras, así que la plataforma se abstiene de decidirlo por usted.
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 un tipo de entidad) o la generación de esquemas (cada modelo convierte una muestra fija en un esquema). Cada uno 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 vuelve a pagar por los modelos evaluados. Sí genera embeddings de texto para comparar valores (y ejecuta el juez, si el escenario tiene uno), lo que descuenta créditos según el uso. Esto ocurre automáticamente en 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 ningún modelo de embeddings configurado (y el escenario no define una 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 está puntuado en absoluto, y sigue siendo repuntuable más adelante. 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, modelo de embeddings y nivel de rigor). A partir de entonces, cada ejecución puntúa automáticamente sus resultados correctos: una columna Calidad ordenable se rellena 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.