Benchmarks et limites connues

Les résultats de Laya dépendent du checkpoint, de la tâche, du libellé de la question, du nombre d’options et du matériel. Utilise les tableaux de benchmarks complets pour trouver une exécution comparable avant de choisir un checkpoint ou un seuil de confiance. Le répertoire research contient les scripts et les fichiers de résultats derrière les tableaux principaux.

Trouver la mesure pertinente

Si tu dois évaluer	Commence par	Vérifie avant d’appliquer le résultat
Des décisions entre langues	Les tableaux MASSIVE et XNLI de `BENCHMARKS.md`	Langue, tâche, nombre d’options et checkpoint
Un workflow comme le triage ou la modération	Le tableau des workflows applicatifs de `BENCHMARKS.md`	Si le jeu de données était dans le mélange d’entraînement ou mis de côté
Le checkpoint `laya-typed-decisions`	Le tableau typed-decisions de `BENCHMARKS.md`	Il a été ajusté finement sur la partition d’entraînement de ce benchmark ; les checkpoints de base ont des lignes séparées
Le temps de réponse	Les sections T4, GB10, CPU de portable et CPU de serveur de `BENCHMARKS.md`	Appareil, taille de lot, nombre de questions, préchauffage et si le temps HTTP est inclus

Les chiffres publiés de Jev à côté des suites Laya d’origine proviennent d’études tierces avec des prompts et des tailles d’échantillon différents. Ils sont un contexte utile, mais ne constituent pas une comparaison contrôlée et directe. Voir les notes de comparaison dans research/README.md.

Lis l’exactitude avec la référence et la partition de données. Par exemple, le benchmark typed-decisions rapporte 0.766 d’exactitude pour le checkpoint ajusté, alors que les deux checkpoints de base obtiennent moins que sa référence de classe majoritaire de 0.461. Ce résultat soutient l’ajustement fin pour une tâche similaire ; il n’établit pas 0.766 d’exactitude pour un checkpoint non entraîné ni pour un nouveau domaine.

Lis la confiance séparément de l’exactitude. L’erreur de calibration attendue (ECE) mesure à quel point les probabilités rapportées correspondent à l’exactitude observée ; plus bas, c’est mieux. Les colonnes ECE et confiance moyenne d’origine du balayage de 51 langues sont antérieures à l’écrêtage de température de #42. Ses colonnes d’exactitude s’appliquent encore, mais utilise la réexécution avec écrêtage dans research/results/ pour comparer les valeurs de confiance actuelles. Même une ECE plus basse sur une suite ne fixe pas un seuil sûr pour une autre tâche ou un autre nombre d’options.

Limites à vérifier sur tes propres données

Routage par langue : Le checkpoint anglais peut être confiant sur un texte qu’il traite mal hors de l’anglais. Utilise Router pour les entrées multilingues et vérifie les décisions de routage sur les langues que tu sers. Le checkpoint multilingue obtient lui aussi moins que le checkpoint anglais sur les tranches anglaises de MASSIVE et XNLI.
Beaucoup d’options : Les descriptions Choice partagent un budget fixe de jetons. L’exécution à 77 libellés Banking77 performe mal au budget par défaut. Garde une seule question choice à environ 20 options, ou évalue une présélection et un budget de tête plus large sur tes propres libellés.
Calibration : Les deux checkpoints de base sont trop confiants sur les suites publiées telles quelles, alors qu’une tâche de routage distincte était trop peu confiante. Ajuste et évalue les températures sur des exemples distincts et mis de côté de ton workflow avant d’utiliser une porte de confiance.
Transfert de tâche : La modération mise de côté est faible dans le benchmark applicatif, et le score ordinal est la primitive la plus faible des suites anglaises rapportées. Le checkpoint multilingue a aussi un biais mesuré contre le premier niveau de score. Teste le type de question et la distribution de données réels que tu comptes servir.
Libellé et ordre : L’ordre des options peut changer une réponse choice. Les libellés de choice à mots booléens et les requêtes niées ont aussi échoué dans des exemples documentés ; noul peut suivre ses libellés d’option au lieu de l’état. Vérifie les ordres et libellés alternatifs, surtout quand une décision erronée coûte cher.
Documents longs : L’encodeur multilingue peut lire jusqu’à 8,192 jetons quand il est configuré pour cette limite, mais le benchmark de contexte long rapporte des réponses moins fiables au-delà d’environ 4,000 jetons de texte précédent. Mesure l’exactitude aux longueurs que tu prévois en usage.
Latence : Les chiffres T4 ne prédisent pas le temps CPU ni le temps de chargement à froid. Mesure les appels à chaud et à froid avec ton propre checkpoint, ton appareil, tes longueurs d’entrée et ton nombre de questions.

La section limites honnêtes du README contient des exemples et des contournements actuels. Les tableaux de benchmarks donnent le jeu de données et le matériel derrière chacune des limites ci-dessus.

Reproduire ou étendre un résultat

Commence par la carte des scripts et résultats et l’index des exécutions en haut de BENCHMARKS.md. research/scripts/bench_local.py exécute le balayage CPU sur 51 langues, bench_apps.py couvre les workflows applicatifs, et bench_latency.py mesure la vitesse de routage et d’inférence. Le notebook T4 est généré depuis research/scripts/build_benchmark_nb.py ; modifie le générateur quand tu changes ce benchmark.

Pour un nouveau déploiement, garde un ensemble mis de côté avec les mêmes états, questions et réponses attendues pour chaque checkpoint que tu compares. Consigne la révision du checkpoint, les versions de Laya et des bibliothèques, l’appareil, le nombre de questions, le nombre d’options et le budget de jetons avec chaque exécution. Inclus une référence simple pour l’exactitude et rapporte la latence après préchauffage ainsi que le temps de chargement au premier usage. Cela rend ton résultat comparable aux exécutions publiées et te permet d’y revenir après une mise à niveau.