Filosofia

Transformers é uma biblioteca com foco em PyTorch. Ela oferece modelos fiéis aos seus artigos, fáceis de usar e fáceis de modificar.

Um artigo mais longo e aprofundado, com exemplos, visualizações e cronogramas, está disponível aqui como nossa referência canônica.

Nossa filosofia evolui por meio da prática. A seguir, apresentamos nossos princípios atuais e estáveis.

Para quem é esta biblioteca

• Pesquisadores e educadores que exploram ou estendem arquiteturas de modelos.
• Profissionais que fazem fine-tuning, avaliação ou servem modelos.
• Engenheiros que desejam um modelo pré-treinado que “funciona” com uma API previsível.

O que você pode esperar

• Cada modelo requer três classes principais: configuration, models e uma classe de pré-processamento. Tokenizers lidam com NLP, image processors lidam com imagens, video processors lidam com vídeos, feature extractors lidam com áudio e processors lidam com entradas multimodais.

• Todas essas classes podem ser inicializadas de forma simples e unificada a partir de instâncias pré-treinadas, usando o método comum from_pretrained(), que baixa (se necessário), faz o cache e carrega a instância da classe relacionada e os dados associados (hiperparâmetros das configurações, vocabulário dos tokenizers, parâmetros dos processors e pesos dos modelos) a partir de um checkpoint pré-treinado fornecido no Hugging Face Hub ou do seu próprio checkpoint salvo.

• Além dessas três classes base, a biblioteca oferece duas APIs: pipeline() para usar rapidamente um modelo para inferência em uma tarefa específica e Trainer para treinar ou fazer fine-tuning rapidamente de um modelo PyTorch.

Princípios fundamentais

Os seguintes princípios se consolidaram ao longo do tempo e estão detalhados em nosso novo post de blog sobre filosofia blog post. Eles orientam as decisões dos mantenedores ao revisar PRs e contribuições.

• Fonte da verdade. As implementações devem ser fiéis aos resultados oficiais e ao comportamento pretendido.
• Um modelo, um arquivo. A lógica central de inferência/treino é visível de cima a baixo no arquivo do modelo que os usuários leem.
• Código é o produto. Otimize para leitura e comparação de diferenças. Prefira nomes explícitos a indireções engenhosas.
• Padronize, não abstraia. Mantenha o comportamento específico do modelo no próprio modelo. Use interfaces compartilhadas apenas para infraestrutura genérica.
• DRY* (Repita quando isso ajudar os usuários). Os arquivos de modelagem para o usuário final permanecem autocontidos. A infraestrutura é separada.
• API mínima para o usuário. Poucos caminhos de código, kwargs previsíveis, métodos estáveis.
• Compatibilidade reversa. As superfícies públicas não devem ser quebradas. Artefatos antigos do Hub devem continuar funcionando.
• Superfície pública consistente. A nomenclatura, as saídas e os diagnósticos opcionais estão alinhados e testados.

Principais classes

• As classes de configuração armazenam os hiperparâmetros necessários para construir um modelo. Isso inclui o número de camadas e o tamanho oculto. Você nem sempre precisa instanciá-los manualmente. Ao usar um modelo pré-treinado sem modificações, a criação do modelo instancia automaticamente a configuração.

• As classes de modelo são modelos do PyTorch (torch.nn.Module), encapsulados por pelo menos um PreTrainedModel.

• Transformers modulares. Os contribuidores escrevem um pequeno fragmento modular_*.py que declara a reutilização de componentes existentes. A biblioteca expande automaticamente esse fragmento para o arquivo visível modeling_*.py, que os usuários leem e depuram. Os mantenedores revisam o fragmento; os usuários modificam o arquivo expandido. Isso preserva o princípio de “Um Modelo, Um Arquivo” sem a deriva de código repetitivo. Consulte a documentação de contribuição para mais informações.

• As classes de pré-processamento convertem os dados brutos em um formato aceito pelo modelo. Um tokenizer armazena o vocabulário de cada modelo e fornece métodos para codificar e decodificar strings em uma lista de índices de incorporação de tokens. Os processadores de imagem pré-processam entradas visuais, os processadores de vídeo pré-processam entradas de vídeo, os extratores de recursos pré-processam entradas de áudio e os processadores pré-processam entradas multimodais.

Todas essas classes podem ser instanciadas a partir de instâncias pré-treinadas, salvas localmente e compartilhadas no Hub com três métodos:

• from_pretrained() permite instanciar um modelo, uma configuração e uma classe de pré-processamento a partir de uma versão pré-treinada, seja fornecida pela própria biblioteca (os modelos suportados podem ser encontrados no Model Hub) ou armazenada localmente (ou em um servidor) pelo usuário.
• save_pretrained() permite salvar um modelo, uma configuração e uma classe de pré-processamento localmente para que possam ser recarregados usando from_pretrained().
• push_to_hub() permite compartilhar um modelo, uma configuração e uma classe de pré-processamento no Hub, tornando-os facilmente acessíveis a todos.