Philosophie

Transformers est une bibliothèque orientée PyTorch. Elle propose des modèles fidèles à leurs articles, faciles à utiliser et faciles à modifier.

Un article plus long et approfondi, avec des exemples, des visualisations et des chronologies, est disponible ici en tant que référence canonique.

Notre philosophie évolue au fil de la pratique. Ce qui suit sont nos principes actuels et stables.

À qui s'adresse cette bibliothèque

• Chercheurs et enseignants qui explorent ou étendent des architectures de modèles.
• Praticiens qui effectuent l'ajustement fin, l'évaluation ou le déploiement de modèles.
• Les ingénieurs qui souhaitent un modèle pré-entraîné qui « fonctionne immédiatement » avec une API prévisible.

À quoi vous attendre

• Chaque modèle requiert trois classes principales : configuration, models et une classe de prétraitement. Les Tokenizers gèrent le NLP, les image processors gèrent les images, les video processors gèrent les vidéos, les feature extractors gèrent l’audio et les processors gèrent les entrées multimodales.

• Toutes ces classes peuvent être initialisées de manière simple et unifiée à partir d’instances préentraînées en utilisant la méthode commune from_pretrained(), qui télécharge (le cas échéant), met en cache et charge l’instance de classe associée ainsi que les données connexes (hyperparamètres des configurations, vocabulaire des tokenizers, paramètres des processors et poids des modèles) à partir d’un checkpoint préentraîné fourni sur Hugging Face Hub ou d’un checkpoint que vous avez sauvegardé vous-même.

• En plus de ces trois classes de base, la bibliothèque propose deux API : pipeline() pour utiliser rapidement un modèle pour l'inférence sur une tâche donnée, et Trainer pour entraîner ou affiner rapidement un modèle PyTorch.

Principes fondamentaux

Les principes suivants se sont consolidés au fil du temps et sont détaillés dans notre nouvel article de blog sur la philosophie blog post. Ils guident les décisions des mainteneurs lors de l’examen des PR et des contributions.

• Source de vérité. Les implémentations doivent être fidèles aux résultats officiels et au comportement prévu.
• Un modèle, un fichier. La logique d'inférence/entraînement de base est visible de haut en bas dans le fichier du modèle que les utilisateurs consultent.
• Le code est le produit. Optimisez pour la lisibilité et la comparaison de différences. Privilégiez des noms explicites plutôt que des références astucieuses.
• Standardiser, ne pas abstraire. Conserver le comportement spécifique au modèle dans le modèle. Utiliser les interfaces partagées uniquement pour l’infrastructure générique.
• DRY* (Répétez lorsque cela aide les utilisateurs). Les fichiers de modélisation destinés aux utilisateurs finaux restent autonomes. L'infrastructure est factorisée.
• API utilisateur minimale. Peu de chemins de code, mots-clés prévisibles, méthodes stables.
• Compatibilité ascendante. Les interfaces publiques ne doivent pas être cassées. Les anciens artefacts du Hub doivent continuer à fonctionner.
• Surface publique cohérente. La nomenclature, les sorties et les diagnostics optionnels sont alignés et testés.

Classes principales

• Classes de configuration stockent les hyperparamètres nécessaires à la construction d'un modèle. Ils incluent le nombre de couches et la taille cachée. Vous n'avez pas toujours besoin de les instancier vous-même. Lors de l'utilisation d'un modèle pré-entraîné sans modification, la création du modèle instancie automatiquement la configuration.

• Les classes de modèles sont des modèles PyTorch (torch.nn.Module), encapsulés par au moins une PreTrainedModel.

• Transformers modulaires. Les contributeurs rédigent un petit fragment modular_*.py qui déclare la réutilisation de composants existants. La bibliothèque développe automatiquement ce fragment en le fichier modeling_*.py visible, que les utilisateurs lisent et déboguent. Les mainteneurs examinent le fragment ; les utilisateurs modifient le fichier développé. Cela préserve le principe « Un modèle, un fichier » sans dérive de code généré. Consultez la documentation de contribution pour plus d'informations.

• Les classes de prétraitement convertissent les données brutes dans un format accepté par le modèle. Un tokenizer stocke le vocabulaire de chaque modèle et fournit des méthodes pour encoder et décoder des chaînes de caractères en une liste d'indices d'embeddings de jetons. Les processeurs d'images prétraitent les entrées visuelles, les processeurs de vidéos prétraitent les entrées vidéo, les extracteurs de caractéristiques prétraitent les entrées audio et les processeurs prétraitent les entrées multimodales.

Toutes ces classes peuvent être instanciées à partir d'instances pré-entraînées, sauvegardées localement et partagées sur le Hub grâce à trois méthodes :

• from_pretrained() permet d'instantier un modèle, une configuration et une classe de prétraitement à partir d'une version pré-entraînée, soit fournie par la bibliothèque elle-même (les modèles pris en charge sont disponibles sur le Model Hub), soit stockée localement (ou sur un serveur) par l'utilisateur.
• save_pretrained() permet d’enregistrer localement un modèle, sa configuration et sa classe de prétraitement afin qu’ils puissent être rechargés à l’aide de from_pretrained().
• push_to_hub() vous permet de partager un modèle, une configuration et une classe de prétraitement sur le Hub, afin qu’ils soient facilement accessibles à tous.