A arquitetura do transformer foi popularizada após o sucesso da arquitetura seq2seq. Na época de sua introdução em 2014, o seq2seq proporcionou melhorias significativas em tarefas então desafiadoras: tradução automática e sumarização. Em 2016, o Google incorporou o seq2seq ao Google Tradutor, uma atualização que proporcionou as “maiores melhorias até o momento em qualidade de tradução automática”. Isso gerou interesse no seq2seq, tornando-o a arquitetura ideal para tarefas que envolvem sequências de texto.
Em um nível mais amplo, o seq2seq contém um codificador que processa entradas e um decodificador que gera saídas. Tanto as entradas quanto as saídas são sequências de tokens. O seq2seq utiliza RNNs (redes neurais recorrentes) como codificador e decodificador. Em sua forma mais básica, o codificador processa os tokens de entrada sequencialmente, gerando o estado oculto final que representa a entrada. O decodificador então gera tokens de saída sequencialmente, condicionados tanto ao estado oculto final da entrada quanto ao token gerado anteriormente.
Há dois problemas com seq2seq. Primeiro, o decodificador seq2seq original gera tokens de saída usando apenas o estado oculto final da entrada. É como gerar respostas sobre um livro usando somente seu resumo. Isso limita a qualidade das saídas geradas. Segundo, o codificador e o decodificador RNN significam que tanto o processamento de entrada quanto a geração de saída são feitos sequencialmente, tornando-o lento para sequências longas.
A arquitetura do transformer aborda ambos os problemas com o mecanismo de atenção. O mecanismo de atenção permite que o modelo pondere a importância de diferentes tokens de entrada ao gerar cada token de saída. Isso é como gerar respostas referenciando qualquer página do livro.
A arquitetura do transformador dispensa as RNNs. Com transformers, os tokens de entrada podem ser processados em paralelo, acelerando muito o processamento de entrada. Enquanto o transformador remove o gargalo de entrada sequencial, os modelos de linguagem baseados em transformers ainda apresentam o gargalo de saída sequencial. A inferência para modelos de linguagem baseados em transformadores, portanto, consiste em duas etapas:
- Pré-preenchimento: O modelo processa os tokens de entrada em paralelo. Esta etapa cria o estado intermediário necessário para gerar o primeiro token de saída. Este estado intermediário inclui os vetores de chave e valor para todos os tokens de entrada.
- Decodificação: O modelo gera um token de saída por vez.
Mecanismo de atenção
No cerne da arquitetura do transformador está o mecanismo de atenção. Compreender esse mecanismo é necessário para entender como os modelos de transformadores funcionam. Nos bastidores, o mecanismo de atenção utiliza os vetores de chave, valor e consulta:
- O vetor de consulta (Q) representa o estado atual do decodificador em cada etapa de decodificação. Usando o mesmo exemplo de resumo de livro, este vetor de consulta pode ser considerado como a pessoa que busca informações para criar um resumo.
- Cada vetor-chave (K) representa um token anterior. Se cada token anterior for uma página do livro, cada vetor-chave será como o número da página. Observe que, em uma determinada etapa de decodificação, os tokens anteriores incluem tokens de entrada e tokens gerados anteriormente.
- Cada vetor de valor (V) representa o valor real de um token anterior, conforme aprendido pelo modelo. Cada vetor de valor é como o conteúdo da página.
O mecanismo de atenção calcula quanta atenção deve ser dada a um token de entrada. Uma pontuação alta significa que o modelo usará mais do conteúdo daquela página (seu vetor de valor) ao gerar o resumo do livro.
Como cada token anterior possui um vetor de chave e valor correspondente, quanto maior a sequência, mais vetores de chave e valor precisam ser computados e armazenados. Esta é uma das razões pelas quais é tão difícil estender o comprimento do contexto para modelos transformers.
As matrizes de consulta, chave e valor possuem dimensões correspondentes à dimensão oculta do modelo. Por exemplo, no Llama 2-7B, o tamanho da dimensão oculta do modelo é 4096, o que significa que cada uma dessas matrizes possui uma dimensão de 4096 × 4096. Cada vetor K, V, Q resultante possui a dimensão de 4096.
O mecanismo de atenção é quase sempre multifacetado. Múltiplas cabeças permitem que o modelo atenda a diferentes grupos de tokens anteriores simultaneamente. Com a atenção multifacetada, os vetores de consulta, chave e valor são divididos em vetores menores, cada um correspondendo a uma cabeça de atenção. No caso do Llama 2-7B, por possuir 32 cabeças de atenção, cada vetor K, V e Q será dividido em 32 vetores de dimensão 128 (4096/32 = 128). As saídas de todas as cabeças de atenção são então concatenadas.
Bloco transformador
Uma arquitetura transformer é composta por múltiplos blocos transformers. O conteúdo exato do bloco varia entre os modelos, mas, em geral, cada bloco transformer contém o módulo de atenção e o módulo MLP (perceptron multicamadas):
- Módulo de atenção: Cada módulo de atenção consiste em quatro matrizes de peso: consulta, chave, valor e projeção de saída.
- Módulo MLP: Um módulo MLP consiste em camadas lineares separadas por funções de ativação não lineares. Cada camada linear é uma matriz de peso usada para transformações lineares, enquanto uma função de ativação permite que as camadas lineares aprendam padrões não lineares. Uma camada linear também é chamada de camada feedforward.
O número de blocos transformers em um modelo transformador é frequentemente chamado de número de camadas desse modelo.
Um módulo de embedding antes dos blocos transformadores: Este módulo consiste na matriz de embedding e na matriz de embedding posicional, que convertem tokens e suas posições em vetores de embedding, respectivamente.
Uma camada de saída após os blocos transformadores: Este módulo mapeia os vetores de saída do modelo em probabilidades de tokens usadas para amostrar as saídas do modelo. Este módulo normalmente consiste em uma matriz, também chamada de camada de desembedding.
Referências
Huyen, Chip. AI Engineering: Building Applications with Foundation Models
Comments (0)