Transformers documentation

Filosofia

Hugging Face's logo
Join the Hugging Face community

and get access to the augmented documentation experience

to get started

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.
Update on GitHub