IA: Diferença entre LLM, UNET e RAG. (Parte 1)

IA

Disclaimer: Este artigo não contém opiniões pessoais ou “achismos”. O que está escrito aqui é baseado em estudos e pesquisas, sendo apenas um resumo das fontes consultadas. Todas as referências estão no final do artigo. Este texto é apenas um ponto de partida; não pare por aqui. Nenhum artigo cobre tudo. Pesquise, estude e tire suas próprias conclusões. Dito isso, vamos.

Este é o início de uma série de artigos sobre IA. Começaremos pelo básico. Existem muitos conceitos que antecedem LLM, UNET e RAG, mas são esses os termos mais comentados atualmente. Por isso, vou começar explicando cada um deles.

Para cada tema, detalharei e explorarei outros aspectos em artigos futuros. Hoje, o objetivo é apresentar o básico de cada um.

LLM (Large Language Model)

Em português, "Modelo de Linguagem Grande". Resumidamente, são modelos de IA como GPT-3, GPT-4, PaLM, Llama, entre outros. Um modelo pode ser entendido como um sistema treinado a partir de grandes volumes de dados. A primeira pergunta é: que tipo de dados? Principalmente textos: sites (Wikipedia, blogs, etc.), livros públicos, artigos científicos, entre outros.

Mas não basta apenas reunir textos para criar um LLM. O modelo precisa ser treinado. É nesse processo que entram as redes neurais. O treinamento conecta informações de modo que o modelo consiga entender e gerar textos. Dependendo do tipo de dado utilizado, o modelo pode ser mais específico ou mais generalista. Por exemplo, um modelo treinado apenas com textos médicos de um grande hospital será mais objetivo nesse domínio do que um modelo generalista como o GPT-3.

Importante: quando você faz uma pergunta para um LLM, ele não responde de forma “consciente”. Ele calcula a probabilidade de qual resposta faz mais sentido com base nos dados em que foi treinado. Por exemplo, se você pergunta “Oi, tudo bem?”, o modelo não entende o conceito de “estar bem”, mas, com base nos dados, a sequência mais comum é “Sim, e você?”. Por isso, ele gera essa resposta.

Transformar dados brutos em textos compreensíveis é o que chamamos de “Natural Language Processing” (NLP), ou, em português, “Processamento de Linguagem Natural” (PLN). Isso só é possível após o treinamento do modelo.

Treinar um LLM é caro, demorado e complexo. Existem vários processos e técnicas comuns a todas as empresas. O primeiro passo é coletar e tokenizar os dados. Um token é a menor unidade de texto que o modelo processa. Pode ser uma palavra, parte de uma palavra ou até mesmo um caractere, dependendo do modelo. Com isso, formam-se n-grams, que são sequências de n tokens. Por exemplo, na frase “Eu gosto de IA”, os n-grams podem ser: “Eu gosto”, “gosto de”, “de IA”. Se o prompt for “Eu gosto de”, o modelo entende que a próxima palavra provável é “IA”. É um exemplo simples, mas tudo se baseia em probabilidade. Lembre-se: o modelo não sabe a resposta, ele apenas continua a sequência.

Após a tokenização, é preciso transformar os tokens em vetores, processo chamado de “embeddings”. Computadores lidam com números, então é necessário converter os dados textuais em representações numéricas. Embeddings são representações vetoriais de n-grams em um espaço de alta dimensão (milhares ou milhões de dimensões). O objetivo dos algoritmos de embeddings é capturar o significado semântico das palavras, de modo que palavras semelhantes fiquem próximas no espaço vetorial.

Este é um resumo BASTANTE SIMPLICADO, de um processo complexo e caro.

Depois disso, entram técnicas como Attention Mechanism, Fine-tuning, Transfer Learning, entre outras, que ajudam a melhorar o desempenho do modelo. Não entrarei em detalhes agora.

LLMs têm limitações e problemas. Eles sempre vão gerar uma resposta, mesmo que não tenham a informação correta, podendo “alucinar” (inventar) respostas. Além disso, as informações podem estar desatualizadas, pois o modelo só conhece dados até a data de seu treinamento. Por exemplo, pode citar um livro e errar o autor, ou inventar um nome inexistente. Se você já usou o ChatGPT, sabe do que estou falando. Para mitigar esses problemas, existem técnicas como o RAG (Retrieval-Augmented Generation), que explicarei a seguir.

Resumindo, LLMs são modelos como GPT-3, GPT-4, PaLM, Llama, etc.

UNET (U-Net Architecture)

Enquanto LLMs são focados em texto, a UNET é uma arquitetura de rede neural voltada para imagens, especialmente para segmentação semântica. Ela classifica cada pixel de uma imagem, identificando objetos e separando-os em diferentes classes.

A arquitetura UNET é frequentemente representada em formato de “U”, com duas partes principais:

Arquitetura UNET

  • Encoder (contrator/INPUT): Extrai características da imagem, reduzindo sua resolução e aumentando a profundidade dos mapas de características.
  • Decoder (expansor/OUTPUT): Reconstrói a imagem segmentada, aumentando a resolução e utilizando conexões de “skip” para recuperar detalhes perdidos.

O resultado é uma máscara de segmentação, onde cada pixel recebe uma classe (ex: carro, pessoa, árvore, etc).

Essa segmentação pode ocorrer em tempo real, como em sistemas de direção autônoma, onde o UNET identifica objetos na rua instantaneamente.

RAG (Retrieval-Augmented Generation)

RAG é uma técnica. Não é um modelo, não é uma arquitetura, não é um algoritmo, nem um framework ou ferramenta. É uma técnica que combina a geração de texto com a recuperação de informações. O RAG é um processo que melhora o desempenho de LLMs. Dei um spoiler explicando sobre LLMs.

"Retrieval-Augmented" significa, na prática, gerar respostas com base em dados e documentos previamente validados e fornecidos ao modelo.

Por exemplo, imagine que sua empresa tem um chatbot para atendimento ou dúvidas do cliente. É quase impossível que um modelo de mercado, como um GPT, tenha sido treinado com todas as informações da sua empresa. Então, o que você consegue fazer é criar um RAG com documentos, informações e dados para o modelo. Assim, ele vai conseguir gerar respostas mais precisas e relevantes para o seu cliente, evitando alucinações, informações erradas ou desatualizadas.

Se você é desenvolvedor, pense em um RAG focado em um framework. Você pode criar um RAG com a documentação do Next.js, por exemplo. Assim, o modelo vai conseguir gerar respostas mais precisas e relevantes. Os modelos como GPT-4 foram treinados com dados até uma certa data. Se a documentação foi atualizada depois disso, o modelo não vai saber. Esse fenômeno é chamado de "knowledge cut-off". O RAG é uma forma de contornar isso.

Acho que ficou claro o propósito do RAG. Vamos entender como funciona na prática.

Seguindo o exemplo do seu cliente que quer tirar dúvidas sobre a sua empresa. Digamos que ele entra na plataforma e faz a seguinte pergunta: "Qual é a política de devolução da empresa?". E agora, o que podemos fazer para responder? O fluxo mais simples seria: fornecer para a IA, como contexto, um documento com a política de devolução. Assim, o modelo vai conseguir gerar uma resposta. Sim e não. Sim, se não fosse o problema da "Janela de Contexto". A maioria dos LLMs tem uma janela de contexto limitada. O GPT-4, por exemplo, tem uma janela de contexto de 128k tokens. Sim, é muito. Mas dependendo do tamanho da documentação da sua empresa, não será suficiente.

Ok, já que a janela de contexto é limitada, vamos quebrar a documentação em partes menores (chunks). Então, imagine que sua empresa tem uma base de dados com vários documentos. Cada documento tem centenas de páginas. Em algum desses documentos está a política de devolução mas não sabemos qual parte exatamente. Vamos fragmentar todos os documentos em partes menores para conseguirmos usar em uma janela de contexto. Porém, como vou saber qual parte do documento tem a política de devolução? Ou em que parte está a resposta para outras perguntas que o cliente pode fazer?

Aqui entra a "sacada" do RAG. Para achar a resposta, precisamos vetorizar os documentos. Ou seja, transformar os documentos quebrados em vetores. Isso é o que já expliquei no tópico de LLM, que são os embeddings. Agora vou detalhar mais esse processo. Observe a seguinte imagem:

vetores

Imagine que cada bolinha é um vetor, ou melhor, uma representação numérica de uma parte do conhecimento da sua empresa. Se estamos falando de espaço vetorial, cada "documento" ou fragmento de documento é transformado em um vetor, ou seja, uma sequência de números que representa semanticamente o conteúdo. Por exemplo o número [0.1, 0.2, 0.3, 0.4]. Esse vetor representa semanticamente o conteúdo do documento. O mesmo vale para a pergunta do cliente: "Qual é a política de devolução da empresa?". Essa pergunta também é transformada em um vetor, ou seja, uma sequência de números que representa semanticamente o conteúdo da pergunta. Isso é o que chamamos de "embedding". Embeddings permitem que informações semanticamente semelhantes fiquem próximas no espaço vetorial, facilitando a recuperação de dados relevantes.

A palavra "semanticamente" é importante. Nessa imagem de exemplo, de um lado temos Dog, Cat e Wolf. Do outro lado temos Banana e Apple.

Isso significa que Dog, Cat e Wolf são semanticamente semelhantes. Eles são relacionados de alguma forma. Se eu resolver vetorizar a palavra "Lion", ela vai ficar próxima de Dog, Cat e Wolf.

Logo, se eu perguntar "cite alguns animais?" para um modelo que tem esse vetor, ele vai entender que semanticamente Dog, Cat e Wolf são animais. Logo, se fosse para colocar minha frase em um vetor, ela ficaria próxima de Dog, Cat e Wolf.

Se eu verificar os vetores que estão próximos da minha frase, eu consigo encontrar a resposta.

Voltando para o exemplo do cliente. Ele fez a pergunta "Qual é a política de devolução da empresa?". O que precisamos fazer é vetorizar essa pergunta e verificar quais outros vetores (documentos) estão próximos dela.

E sim, para salvar esses vetores precisamos de um banco de dados vetorial.

Explicando o fluxo perfeito para o RAG:

  1. O cliente faz uma pergunta.
  2. O modelo vetoriza a pergunta e manda para o banco de dados vetorial.
  3. O banco de dados vetorial verifica quais vetores estão próximos da pergunta.
  4. O banco de dados retorna os vetores que estão próximos da pergunta.
  5. Pegamos esse retorno (documentos) e mandamos para o modelo de IA como contexto.
  6. O modelo gera a resposta com base no contexto que fornecemos e retorna para o cliente.

Entre o 5 e o 6 podemos ter um "Agente" que valida a resposta. Mas isso é assunto para outro artigo.

Isso é o que chamamos de NATIVE-RAG. É a maneira/fluxo mais simples de implementar o RAG. Sim, dá para complicar. Vamos ver.

Nesse caso, estamos retornando apenas os mais similares semanticamente. Mas podemos combinar com palavras-chave, e isso chamamos de "Hybrid-RAG".

Tem outra técnica na qual, antes de criar o vetor da pergunta, criamos uma resposta, ou melhor, um documento hipotético que responde à pergunta do cliente. E usamos esse documento para vetorizar.

O mais curioso é que o conceito de RAG veio bem antes dessa onda de IAs. É um artigo de 2020, do Facebook Research: "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks".

Referências: