Aprofundando em IA nos EUA - 1Q24 e enviei pra algumas pessoas, os comentários mais frequentes eram sobre “GPT wrappers” e a conversa aprofundava em o que seriam aplicações mais complexas.
Esse texto aqui vai ser um pouco mais técnico, explicando alguns conceitos mas a nível macro, feito pra pessoas não-técnicas ✌️
Basicamente, vou subir o eixo-y desse gráfico da Menlo Ventures:
Menlo Ventures: das investidas deles que estão indo bem, ninguém é só “LLM wrapper” e poucos usam finetuning ou a própria LLM. A grande maioria são “compound AI systems”
O que é um “LLM Wrapper” ou “thin wrapper around GPT”?
É um app simples, que apenas chama a API da OpenAI por trás dos panos (ou outra LLM) e coloca em uma interface diferente do chatGPT (pode ser o WhatsApp, o Slack, ou um site / app separado mesmo).
Normalmente, esses apps têm também um “prompt engineering” para resolver algum problema simples.
Vamos imaginar um assistente de lição de casa simples. Vamos supor um app de matemática, que você coloque o seu problema (customizado) e ele te ajuda a resolver. Ele pode ter features customizadas, como começar dando dicas, depois explicando um conceito, talvez criando alternativas e por fim te dando a resposta.
A parte de AI é fácil de fazer, é só prompt engineering, talvez algum cálculo simples junto. A interface também é fácil de copiar. A competição vira por distribuição (CAC).
Por isso “thin wrapper around GPT” tem uma conotação ruim. E a grande maioria dos apps que surgiram assim (foram muitos, porque era muito fácil) morreram. Ou nunca decolaram, ou não conseguiram reter usuários.
Prompt engineering
Isso não quer dizer que prompt engineering não é importante, pelo contrário. Só que ele não é suficiente para criar vantagem competitiva.
Uma técnica bem importante (e não tão óbvio se você nunca fez) é dar exemplos de perguntas e respostas no formato que você espera, isso melhora muito a qualidade das interações.
Contexto
A quantidade de texto que você envia no prompt é chamada de contexto (tudo isso do prompt engineering, exemplos, informações relevantes, etc).
Ele tem 3 limitantes:
Técnico: cada modelo tem um contexto máximo, que se ultrapassado ele corta o excedente
Custo: quanto maior o contexto enviado, mais cara vai ser a operação
Qualidade: contextos muito grandes dão mais contexto (SIC) pra LLM, porém existem avaliações que mostram que informações se perdem em contextos grandes
Os 3 pontos têm melhorado muito rápido.
O GPT-3.5 (lançado em 2Q22) tinha limite de 16k tokens (~ 16k palavras). O GPT-4 Turbo foi pra 128k. O Claude 3 Opus lançou com 200k e expandindo para 1M. Essa semana o Google anunciou o Gemini 1.5 Pro com 1M de tokens e expandindo para 2M ainda esse ano.
O GPT-3.5 custava $2/M tokens enviados em Set/23 e hoje 9 meses depois custa $0.5/M tokens enviados. O Google também lançou caching de contexto, para não precisar enviar toda vez as mesmas infos e diminuir o custo.
Um dos benchmarks mais comuns para medir qualidade de interpretação em contextos grandes é o “needle in a haystack” (agulha no palheiro). Nessa última análise, o GPT-4o performou muito melhor que modelos anteriores em contextos grandes.
Isso significa que vai ser possível enviar cada vez mais informações e ter respostas cada vez melhores das LLMs, além das melhorias do modelo em si.
O que são então “compound AI systems”?
Menlo Ventures: das investidas deles que estão indo bem, ninguém é só “LLM wrapper” e poucos usam finetuning ou a própria LLM. A grande maioria são “compound AI systems”
Todas as técnicas aqui usam da habilidade de LLMs de (i) entenderem quando elas devem chamar uma função externa, (ii) chamar essa função passando os dados necessários e (iii) trabalhar com o resultado dessa função. Existem algumas formas de fazer isso, mas a mais fácil foi feita pela OpenAI, que treinou o modelo pra isso (ver Function Calling). Isso funciona passando uma lista de quais funções o modelo pode chamar e descrevendo em linguagem natural quando que ele deve chamar cada uma.
Vamos lá então. Os 3 primeiros itens do eixo-y nessa parte são:
Naive RAG
RAG + re-ranking
RAG + knowledge graph
O que é RAG?
É uma sigla pra Retrieval-Augmented Generation. É a geração de uma resposta (generation) criada com auxílio (augmented)de dados buscados em algum lugar (retrieval).
Basicamente, o modelo percebe que a pergunta tem a ver com algum dado que ele não tem. Ele então, chama uma função que vai buscar esse dado em algum lugar e adiciona ele no contexto.
Esse dado pode ser estruturado (os bancos de dados normais que estamos acostumados), mas a inovação aqui é que ele pode ser desestruturado também (textos longos, imagens, videos, etc).
Um exemplo disso seria um app de algum jornal como a Folha de SP que te deixa perguntar sobre notícias do passado.
Para a Folha fazer esse app, ela tem que transformar todas as notícias em vetores.
vetores??
Pois é, aqui começa a ficar foda. Tem duas opções aqui:
Se você tiver alguma facilidade com matemática / data science, não é complexo de entender (é um pouco complicado só). Recomendo esse video abaixo que explica como funciona o GPT (ele é várias multiplicações de matrizes e vetores).
Se você não tiver e ainda assim quiser entender, esse video abaixo é o episódio 5 da 3ª temporada. Vai voltando e assisti essa série ao invés de Netflix hehe
Ou finge que entendeu e segue o baile hahaha, você ainda deve conseguir pegar a ideia. Qualquer coisa grita 👋
Isso é super simples de fazer, a própria OpenAI tem uma API pra transformar textos em vetores, mas existem soluções open source também. Basicamente, eles pegam uma palavra e transformam num vetor de números. Se for um vetor de 3 dimensões, um exemplo poderia ser:
Banana = [1, 2, 3]
Onde:
o primeiro campo diz se é comida (1), bebida (2) ou não comestível (0),
o segundo diz se é branco (0), vermelho (1), amarelo (2) ou azul (3)
o terceiro diz se é sem gosto (0), amargo (1), azedo (2), doce (3) ou salgado (4)
É um exemplo hipotético, pra dizer que esse vetor descreve a palavra de alguma forma. A diferença é que os modelos da OpenAI de vetorização têm 1536 dimensões o pequeno e 3072 dimensões o grande. Então eles pegam muita nuance das palavras.
Voltando pro app da Folha, eles vão vetorizar todas as notícias e jogar em um banco de dados vetorial (um DB feito pra isso).
Quando você perguntar pro app “o que o Renato Gaúcho deu de presente pro Suarez na despedida dele do Grêmio?”, nosso app vai transformar essa pergunta em vetor e fazer uma busca vetorial nesse banco de dados. Isso significa que ele vai buscar o vetor mais parecido com o vetor da pergunta.
Isso significa que ele vai trazer um trecho da notícia que fala isso. Na implementação do nosso app, a gente adiciona esse trecho ao input que vamos fazer pra nossa LLM. No final, vamos enviar pra LLM algo como:
Você é o app da Folha para responder perguntas sobre notícias do passado.
O usuário perguntou: “o que o Renato Gaúcho deu de presente pro Suarez na despedida dele do Grêmio?”
A notícia diz que: "Renato Gaúcho entrega DVD com seus gols para Luis Suárez"
Responda o usuário em um tom amigável.
A primeira e a última parte são o tal do “prompt engineering”, você altera pra ele se comportar como você quiser.
A gente buscou no banco vetorial o trecho da notícia e colocou ali.
Enviaremos tudo isso pra LLM e ela vai gerar a resposta:
→ Isso é RAG
As combinações de RAG
Menlo Ventures: das investidas deles que estão indo bem, ninguém é só “LLM wrapper” e poucos usam finetuning ou a própria LLM. A grande maioria são “compound AI systems”
Os 3 primeiros itens do eixo-y nessa parte laranja são:
Naive RAG
RAG + re-ranking
RAG + knowledge graph
Naive RAG é isso que acabamos de ver.
Ela é “naive” porque é muito simples. Mas mesmo dentro dela tem formas de você melhorar a qualidade das respostas, como mudando o algoritmo que compara a similaridade entre vetores ou mudando a forma que você transforma a notícia em vetor (você transforma ela inteira? ou divide a cada 200 palavras? ou a cada 1.000 palavras? tudo isso interfere).
As outras duas são técnicas de melhorar ainda mais a resposta.
RAG + re-ranking
Se ao invés de buscar a única notícia mais relevante àquela pergunta, tivéssemos buscado as 5 mais relevantes, poderíamos passar essas 5 notícias pra LLM em uma etapa intermediária, enviar junto a pergunta do usuário e pedir pra LLM verificar se as 5 são mesmo relevantes e ordenar por relevância.
Assim, quando enviarmos pra LLM final, já damos uma direcionada nela de pra quais notícias ela deve dar mais peso.
RAG + knowledge graph
Knowledge graph é uma técnica de extrair entidades e a relação entre elas de textos. No nosso exemplo, “Renato Gaúcho”, “Suarez”, “Grêmio” e “DVD de lances do Renato” são entidades. A relação entre elas é que o Renato é treinador do Grêmio, treinou o Suarez e é protagonista do DVD.
Essa extração é feita tanto na hora de vetorizar as notícias passadas quanto na hora de vetorizar a pergunta. Isso auxilia na hora de buscar as notícias mais relevantes e aumenta a precisão do app.
Chain-of-thought, ou “Reason and Planning”, ou “Reflection”
Essas são estratégias para fazer a LLM planejar o que ela vai dizer e refletir se faz sentido. Basicamente ensinar a máquina a pensar antes de falar merda.
O mais simples é no prompt você adicionar um “think step by step” - essa foi uma das primeiras técnicas difundidas de prompt engineering. Mas isso é “naive” também :)
A ideia aqui é fazer múltiplas chamadas pra AI (few shots). Existem técnicas diferentes, Chain-of-thought foi uma das primeiras mais difundidas, mas surgiram outras mais eficazes.
Chain of Thought → guiar a AI a pensar step by step
Chain of Thought with Self-consistency → gerar múltiplas respostas “step-by-step” e depois pedir múltiplas vezes pra AI avaliar a melhor resposta, aí sim escolher a melhor
Tree of Thought → quebra o step-by-step em etapas e faz esse processo de avaliação via AI em cada step, melhorando a linha de raciocínio em cada etapa
Agents são sistemas que agem. Quando falamos de Agents, podemos falar de 4 coisas (seguindo a divisão do Andrew Ng):
Reflection
O que acabamos de falar, quando envolve mais de uma chamada pra LLMs com prompts diferentes entra nesse padrão de “Agents”.
Tool use
Usar ferramentas ou funções para executar tarefas que a LLM não consegue sozinha.
Vou explicar abaixo.
Planning
O planning que já falamos também. Quando é uma tarefa complexa, quebrada em vários steps que envolvem tools diferentes e LLMs diferentes, entra no padrão “Agents” também.
Multi-agent collaboration
Onde começa a ficar mágico (se você já estiver dessensibilizado com a magia que as LLMs são)
Diferentes agents se comunicando para executar uma tarefa orquestrada por um agent inicial
1 e 2 estão bem robustas já.
3 e 4 são mais emergentes, quando funcionam é mágico, mas quanto mais complexas as tarefas, menos elas funcionam bem.
Reflection e Planning podem entrar no padrão de “Agents” quando envolvem prompts, tools e/ou LLMs diferentes. Se for algo mais simples, chamar de Agent é forçar um pouco.
A nomenclatura disso tudo não tá muito padronizada porque tudo surge e evolui muito rápido.
Basics: Memory & Tools
3 tipos de memória:
Sensorial (o que vem no prompt, como se fossem nossos sentidos)
Curto prazo (geralmente se adiciona os últimos X diálogos na íntegra ao input antes de enviar pra LLM)
Longo prazo (existem várias técnicas, nenhuma redonda ainda - imagine criar um app de terapia com LLM que a pessoa passe 1 ano conversando 1h/semana. Como você faz o app se lembrar dos fatos relevantes?)
Qualquer função sua. É assim que você constrói chatbots que substituem parte das tarefas de Customer Service.
Multi-Agent Collaboration
A ideia é você criar Agents específicos pra funções complexas específicas e ter um Agent que centraliza e orquestra a execução de uma tarefa complexa “macro”.
No exemplo acima, a tarefa macro é “develop a Gomoku game”. Esse agente orquestrador vai passar pelo time de produto, depois por design, depois gerar o código, os testes, e provavelmente vai gerando a documentação de tudo isso ao longo do caminho.
Cada um desses agents vai implementar tudo o que falamos até agora — técnicas de prompt engineering, talvez de RAG, planning & reasoning e várias ferramentas pra entregar um resultado final que vai ser um jogo pronto.
Quanto mais complexa a tarefa macro, mais difícil o resultado final ficar redondo.
O Devin, “world's first AI Software Engineer”, consegue resolver 14% das issues que um humano conseguiria (vs. < 4% dos principais modelos puros). Por um lado, ainda tem muito chão pela frente. Por outro, o crescimento é bizarramente rápido (1 ano atrás só existia o GPT 3.5 desse benchmark abaixo, que conseguia resolver só 0.5%).
O que é “model innovation”?
Menlo Ventures: das investidas deles que estão indo bem, ninguém é só “LLM wrapper” e poucos usam finetuning ou a própria LLM. A grande maioria são “compound AI systems”
Os 3 últimos que faltam lá em cima do eixo y são:
Finetuning
RLHF (reinforcement learning with human feedback)
Custom LLM (treinar sua própria LLM do zero)
Esses processos são exponencialmente mais caros (custom LLM >>> RLHF >>> Finetuning >>> Agents), trabalhosos e provavelmente você não precisa usar eles.
Fine tuning é você re-treinar parte da LLM com um conjunto grande de dados seus. Geralmente as pessoas comparam isso com RAG.
Se você fizer fine tuning com dados sobre XPTO, a LLM vai saber sobre XPTO sem precisar buscar em um banco de dados externo.
Além do custo, a diferença principal é que no RAG você coloca essa informação no prompt como argumento de autoridade. No fine tuning você deixa na mão da LLM inferir baseado no que você deu de treinamento para ela.
RLHF é você contratar seres humanos para fazer um “fine tuning” de uma LLM pro seu caso de uso.
Conclusão
Os desenvolvimentos tem sido muito rápidos, em diferentes camadas:
LLMs cada vez melhores
Técnicas cada vez melhores para aumentar a precisão delas
Tarefas cada vez mais complexas que elas conseguem executar
Precisão cada vez maior na sequência de tarefas complexas (multi-agent)
A ideia desse doc era abrir um pouco da caixa preta de como tudo isso funciona.
