Introdução à Personalização de LLM
Nos últimos anos, os rápidos avanços em inteligência artificial levaram ao desenvolvimento de grandes modelos de linguagem (LLMs), revolucionando o campo do processamento de linguagem natural (NLP). Esses modelos poderosos, como ChatGPT, Llama, Mistral, Zephyr e outros, demonstraram capacidades superiores de compreensão e geração de linguagem semelhante à humana.
No entanto, esses LLMs têm limitações. Eles são treinados com uma grande quantidade de dados com uma data de corte específica, o que significa que, se os usarmos para gerar respostas que exigem conhecimento mais recente do que seus dados de treinamento, corremos o risco de obter respostas imprecisas. Portanto, é essencial adaptar esses modelos às nossas tarefas e domínios específicos para liberar todo o seu potencial. É aqui que a personalização de LLMs entra em cena.
Em um recente Unstructured Data Meetup da Zilliz em Seattle, o CEO da OSS4AI e ex-Senior Developer Advocate da Zilliz, Yujian Tang, discutiu várias opções para personalizar LLMs a fim de melhorar seu desempenho em tarefas específicas. Antes de discutir as diferentes opções de personalização para um LLM, vamos explorar brevemente a história dos LLMs.
Assista à reprise da palestra de Yujian
Breve história dos LLMs
A pesquisa que levou ao surgimento dos LLMs percorreu um longo caminho, começando pela arquitetura básica de rede neural. Uma camada básica de rede neural consiste em uma camada de entrada, uma ou mais camadas ocultas e uma camada de saída, como mostrado no gráfico abaixo.
Arquitetura de rede neural
A arquitetura básica de rede neural mostrou-se muito poderosa para tarefas de classificação e pode lidar com dados não estruturados, como textos e imagens. No entanto, ela é ineficaz para tarefas que exigem dependências de longo prazo ou processamento sequencial, o que é essencial para tarefas de linguagem natural. Em redes neurais básicas, cada entrada é processada de forma independente, e a saída é gerada com base apenas na entrada atual. Isso significa que as redes neurais não consideram a ordem ou o contexto da entrada em relação à sequência inteira.
Sem a capacidade de lidar com dependências de longo prazo, uma rede neural não consegue inferir o significado semântico de uma sequência de entrada inteira ou texto — o surgimento das Redes Neurais Recorrentes (RNNs) teve como objetivo resolver esse problema.
As RNNs abordam o problema introduzindo um estado oculto, que atua como uma memória que captura informações do que a rede viu anteriormente. Esse estado oculto é passado de uma etapa de tempo para a próxima, permitindo que a rede mantenha uma representação da sequência. A adição de um estado oculto permite que as RNNs lembrem ou esqueçam seletivamente informações da sequência de entrada, tornando-as mais eficazes para dependências de sequência de entrada do que redes neurais básicas.
Arquitetura RNN
No entanto, as RNNs também vêm com várias limitações, como:
Problema do Gradiente Desvanecente: As RNNs sofrem com o problema do gradiente desvanecente, no qual os gradientes usados para atualizar os parâmetros do modelo durante o treinamento tornam-se menores à medida que são retropropagados ao longo do tempo. Esse problema dificulta que as RNNs aprendam dependências de longo prazo em sequências.
Processamento Sequencial: As RNNs processam sequências sequencialmente, limitando sua capacidade de paralelizar a computação e tornando-as menos eficientes computacionalmente.
Essas limitações das RNNs levaram ao desenvolvimento do Transformer, que usa um mecanismo de autoatenção para processar sequências de entrada em paralelo e evitar o problema do gradiente evanescente.
Arquitetura Transformer
A arquitetura Transformer consiste em vários blocos codificadores e decodificadores. Cada bloco codificador e decodificador contém uma camada especial chamada camada de atenção. Essa camada desempenha um papel crucial na determinação do significado semântico por trás de cada token em relação a toda a sequência de entrada. Por exemplo, considere as três frases a seguir:
A Apple teve um lucro de $97 bilhões em 2023
Eu gosto de comer torta de maçã por lucro em 2023
O resultado final da Apple aumentou em números recordes em 2023
Se usarmos apenas uma abordagem tradicional, como uma abordagem baseada em palavras-chave, as duas primeiras frases serão o par mais semelhante. Encontramos três palavras-chave semelhantes nessas duas frases: Apple, 2023 e lucro.
No entanto, sabemos que a primeira e a terceira frases são os pares semanticamente mais semelhantes. A camada de atenção dentro da arquitetura Transformer pode capturar esse contexto e retornar a primeira e a terceira como o par semanticamente mais semelhante.
O desempenho poderoso e a versatilidade dos modelos Transformers levaram a avanços rápidos em IA em diferentes áreas, de Visão Computacional a NLP e tarefas multimodais.
Um dos modelos introduzidos após o grande sucesso dos Transformers é o modelo Generative Pretrained Transformers (GPT). Esse modelo usa a parte decodificadora da arquitetura Transformer para prever o próximo token em uma sequência de entrada e é usado como a espinha dorsal de muitos LLMs que conhecemos até agora, como ChatGPT e Llama.
Arquitetura GPT
Esses LLMs são muito poderosos na geração de respostas semelhantes às humanas, pois foram treinados com enormes quantidades de dados. No entanto, como você talvez já saiba, os dados de treinamento têm uma data de corte, o que significa que não obteremos uma resposta precisa dos nossos LLMs se perguntarmos sobre informações mais recentes do que seus dados de treinamento. É aqui que precisamos personalizar nossos LLMs.
Geração Aumentada por Recuperação (RAG)
A primeira forma de personalizar nosso LLM é por meio de RAG, e seu conceito é bastante simples. Fornecemos aos LLMs tanto a consulta quanto os contextos relevantes como entradas, permitindo que eles gerem respostas contextuais e precisas ao aproveitar os contextos fornecidos.
Arquitetura RAG
Para aproveitar LLMs para RAG, precisamos de dois componentes essenciais:
Modelo de Embedding Vetorial: Um modelo que transforma nossa consulta e contextos em embeddings vetoriais.
Banco de Dados Vetorial: Um banco de dados para armazenar todos os embeddings de contexto e realizar busca vetorial para fornecer aos nossos LLMs os contextos mais relevantes e semanticamente semelhantes com base na consulta.
Vários modelos podem ser usados para gerar embeddings vetoriais, incluindo modelos de deep learning da OpenAI ou sentence transformers. Como alternativa, modelos tradicionais baseados em bag-of-words, como TF-IDF ou BM25, também podem ser empregados.
Milvus é um banco de dados vetorial de código aberto popular. Ele armazena os dados necessários, consistindo em dois tipos: embeddings vetoriais gerados pelo modelo e seus metadados. Por exemplo, considere um trecho de texto de um artigo publicado pela Towards Data Science no primeiro dia de junho de 2023. Os dados armazenados no banco de dados vetorial Milvus podem se parecer com isto:
Exemplo de dados de embedding vetorial e seus metadados
Os metadados são úteis para realizar diversos filtros durante operações de busca vetorial, a fim de fornecer aos nossos LLMs contextos mais precisos. Por exemplo, você pode querer buscar contextos de uma publicação específica ou aqueles publicados após uma determinada data (por exemplo, 2020).
Depois que temos a consulta e sabemos os metadados específicos que queremos filtrar, um banco de dados vetorial como o Milvus fará seu trabalho. Ele realizará uma busca vetorial para encontrar os contextos semanticamente mais semelhantes à nossa consulta que atendam às condições de filtragem dos metadados.
Ajuste fino
Outra abordagem para personalizar LLMs é por meio do ajuste fino. O conceito é simples: treinamos um LLM pré-treinado em nossos próprios dados, resultando em modelos com novos pesos adaptados para executar tarefas específicas do nosso domínio de dados.
Existem várias maneiras de fazer o ajuste fino de LLMs:
Ajuste fino completo: Esta abordagem modifica os pesos de todos os parâmetros dentro do LLM original. No entanto, envolve um processo computacional caro.
LORA: Esta abordagem introduz adaptadores de baixa classificação dentro da arquitetura do LLM. Os pesos originais são congelados durante o ajuste fino, e apenas os pesos dos adaptadores são atualizados.
QLORA: Esta abordagem introduz quantização ao método LORA original, reduzindo custos computacionais e recursos, ao mesmo tempo que preserva um desempenho razoável.
Ajuste fino completo vs LORA
Agora que conhecemos os diferentes métodos de ajuste fino, vamos discutir as diferentes técnicas de ajuste fino:
Ajuste fino supervisionado: Neste método, fornecemos aos nossos LLMs nossos próprios dados de treinamento e rótulos correspondentes. Em seguida, treinamos nossos LLMs como qualquer modelo de aprendizado de máquina supervisionado.
Aprendizado por reforço a partir de feedback humano (RLHF): Este método incorpora a teoria do aprendizado por reforço. Coletamos várias respostas do LLM com base em uma consulta e, em seguida, avaliamos a qualidade de cada resposta. Com o tempo, nossos LLMs produzem respostas alinhadas às nossas preferências.
Ajuste fino supervisionado vs. Aprendizado por reforço a partir de feedback humano
Como o ajuste fino supervisionado é simples, vamos discutir o RLHF com mais detalhes. Uma desvantagem do RLHF nativo é a necessidade de humanos avaliarem a qualidade das respostas geradas pelos LLMs. Essa abordagem é cara e demorada.
Cientistas de dados introduziram a Otimização de Política Proximal (PPO) para aliviar esse problema.PPO introduz um modelo de recompensa para substituir a avaliação humana. No entanto, esse modelo de recompensa precisa ser treinado separadamente, tornando a aplicação do PPO trabalhosa. Além disso, o modelo de recompensa precisa ser retreinado toda vez que novos dados são adicionados.
Para resolver esses problemas, foi introduzida a Otimização Direta de Preferências (DPO). A DPO otimiza a política do LLM usando a função de perda de log-verossimilhança negativa em dados de preferência humana. O conjunto de dados para ajuste fino com DPO consiste em prompts, respostas preferidas e respostas não preferidas:
Exemplo do formato de dados usado para ajustar finamente LLMs com DPO
No entanto, a DPO tende a se ajustar excessivamente ao conjunto de dados de preferências rapidamente. Para mitigar esse problema, foi desenvolvida a Otimização de Preferência de Identidade (IPO).
IPO introduz um termo de regularização na função de perda DPO para evitar overfitting. Ele também usa um termo de razão de chances logarítmica anexado à função de perda de log-verossimilhança negativa (NLL), permitindo que o LLM seja ajustado ao estilo desejado enquanto penaliza respostas indesejadas.
Conclusão
Yujian Tang discutiu várias maneiras de personalizar LLMs para uso ideal em nossos casos de uso específicos em sua palestra. A apresentação começou fornecendo uma breve história dos avanços em IA que levaram ao desenvolvimento dos LLMs. Esse tópico foi seguido por uma explicação de dois métodos para personalizar LLMs: RAG e fine-tuning.
RAG melhora a qualidade das respostas geradas por LLMs ao injetar contextos relevantes junto com a consulta como entradas. Bancos de dados vetoriais como Milvus armazenam embeddings de contexto e realizam buscas vetoriais para implementar RAG. Em seguida, os LLMs usam esses contextos para gerar respostas apropriadas.
A segunda abordagem é o fine-tuning, e há dois métodos de fine-tuning:
Fine-Tuning Supervisionado: Este método envolve fornecer aos nossos LLMs nossos próprios dados de treinamento e rótulos correspondentes e, em seguida, treiná-los como qualquer modelo supervisionado de machine learning.
Aprendizado por Reforço a partir de Feedback Humano (RLHF): Este método incorpora a teoria do aprendizado por reforço, em que coletamos várias respostas do LLM com base em uma consulta e avaliamos a qualidade de cada resposta. Com o tempo, nossos LLMs produzem respostas que se alinham às nossas preferências.
Para obter mais detalhes sobre a personalização de LLMs, assista ao replay da palestra de Yujian.
Continue lendo
My Wife Wanted Dior. I Spent $600 on Claude Code to Vibe-Code a 2M-Line Database Instead.
Write tests, not code reviews. How a test-first workflow with 6 parallel Claude Code sessions turns a 2M-line C++ codebase into a daily shipping pipeline.
Why Not All VectorDBs Are Agent-Ready
Explore why choosing the right vector database is critical for scaling AI agents, and why traditional solutions fall short in production.
DeepSeek-VL2: Mixture-of-Experts Vision-Language Models for Advanced Multimodal Understanding
Explore DeepSeek-VL2, the open-source MoE vision-language model. Discover its architecture, efficient training pipeline, and top-tier performance.