Documentación

Benchmarks y límites conocidos

Los resultados de Laya dependen del checkpoint, la tarea, el enunciado de la pregunta, el número de opciones y el hardware. Usa las tablas completas de benchmarks para encontrar una ejecución comparable antes de elegir un checkpoint o un umbral de confianza. El directorio de research contiene los scripts y los archivos de resultados que hay detrás de las tablas principales.

Encuentra la medición relevante

Si necesitas evaluar Empieza por Comprueba antes de aplicar el resultado
Decisiones entre idiomas Las tablas MASSIVE y XNLI de BENCHMARKS.md Idioma, tarea, número de opciones y checkpoint
Un flujo de trabajo como triaje o moderación La tabla de flujos de trabajo de aplicación de BENCHMARKS.md Si el conjunto de datos estaba en la mezcla de entrenamiento o reservado
El checkpoint laya-typed-decisions La tabla de typed-decisions de BENCHMARKS.md Se ajustó fino sobre la partición de entrenamiento de ese benchmark; los checkpoints base tienen filas aparte
Tiempo de respuesta Las secciones de T4, GB10, CPU de portátil y CPU de servidor de BENCHMARKS.md Unidad, tamaño de lote, número de preguntas, calentamiento y si se incluye el tiempo HTTP

Las cifras publicadas de Jev junto a las suites originales de Laya provienen de estudios de terceros con prompts y tamaños de muestra distintos. Son contexto útil, pero no son una comparación directa y controlada. Consulta las notas de comparación en research/README.md.

Lee la precisión junto con la línea base y la partición de datos. Por ejemplo, el benchmark de typed-decisions informa 0.766 de precisión para el checkpoint ajustado, mientras que ambos checkpoints base puntúan por debajo de su línea base de clase mayoritaria de 0.461. Ese resultado respalda el ajuste fino para una tarea similar; no establece una precisión de 0.766 para un checkpoint sin entrenar ni para un dominio nuevo.

Lee la confianza por separado de la precisión. El error de calibración esperado (ECE) mide qué tan bien coinciden las probabilidades informadas con la corrección observada; más bajo es mejor. Las columnas originales de ECE y confianza media del barrido de 51 idiomas son anteriores al recorte de temperatura de #42. Sus columnas de precisión siguen aplicándose, pero usa la repetición con recorte de research/results/ al comparar valores de confianza actuales. Incluso un ECE más bajo en una suite no fija un umbral seguro para otra tarea u otro número de opciones.

Límites que comprobar con tus propios datos

  • Enrutamiento por idioma: El checkpoint inglés puede mostrarse seguro en texto que maneja mal fuera del inglés. Usa Router para entradas en varios idiomas y comprueba las decisiones de enrutamiento en los idiomas que sirves. El checkpoint multilingüe también puntúa por debajo del inglés en las particiones inglesas de MASSIVE y XNLI.
  • Muchas opciones: Las descripciones de Choice comparten un presupuesto fijo de tokens. La ejecución de 77 etiquetas Banking77 rinde mal con el presupuesto por defecto. Mantén una sola pregunta choice en torno a 20 opciones, o evalúa una preselección y un presupuesto de cabeza mayor con tus propias etiquetas.
  • Calibración: Ambos checkpoints base son demasiado confiados en las suites publicadas tal como se distribuyen, aunque una tarea de enrutamiento aparte era poco confiada. Ajusta y evalúa las temperaturas sobre ejemplos reservados y separados de tu flujo de trabajo antes de usar una puerta de confianza.
  • Transferencia de tarea: La moderación reservada es débil en el benchmark de aplicaciones, y el score ordinal es la primitiva más débil en las suites inglesas informadas. El checkpoint multilingüe también tiene un sesgo medido contra el primer nivel de score. Prueba el tipo de pregunta y la distribución de datos reales que pretendes servir.
  • Enunciado y orden: El orden de las opciones puede cambiar una respuesta choice. Las etiquetas de choice con palabras booleanas y las peticiones negadas también han fallado en ejemplos documentados; noul puede seguir sus etiquetas de opción en lugar del estado. Comprueba órdenes y enunciados alternativos, sobre todo cuando una decisión equivocada es costosa.
  • Documentos largos: El codificador multilingüe puede leer hasta 8,192 tokens cuando se configura para ese límite, pero el benchmark de contexto largo informa respuestas menos fiables más allá de unos 4,000 tokens de texto precedente. Mide la precisión en las longitudes que esperas en uso.
  • Latencia: Las cifras de T4 no predicen el tiempo de CPU ni de carga en frío. Mide llamadas en caliente y en frío con tu propio checkpoint, unidad, longitudes de entrada y número de preguntas.

La sección de límites honestos del README tiene ejemplos y soluciones provisionales actuales. Las tablas de benchmarks dan el conjunto de datos y el hardware que hay detrás de cada uno de los límites anteriores.

Reproducir o ampliar un resultado

Empieza por el mapa de scripts y resultados y el índice de ejecuciones al principio de BENCHMARKS.md. research/scripts/bench_local.py ejecuta el barrido de CPU de 51 idiomas, bench_apps.py cubre flujos de trabajo de aplicación, y bench_latency.py mide la velocidad de enrutamiento e inferencia. El notebook de T4 se genera a partir de research/scripts/build_benchmark_nb.py; edita el generador cuando cambies ese benchmark.

Para un despliegue nuevo, mantén un conjunto reservado con los mismos estados, preguntas y respuestas esperadas para cada checkpoint que compares. Registra la revisión del checkpoint, las versiones de Laya y de las bibliotecas, la unidad, el número de preguntas, el número de opciones y el presupuesto de tokens con cada ejecución. Incluye una línea base sencilla para la precisión e informa la latencia tras el calentamiento, además del tiempo de carga en el primer uso. Esto hace que tu resultado sea comparable con las ejecuciones publicadas y te permite revisitarlo después de una actualización.