Transcription
Chegou o GPT5 e agora temos um modelo melhor e mais barato. Mas o que eu quero tratar aqui é a melhoria da performance do modelo em contextos longos. Agora o GPT5 aceita uma janela de contexto de até 400.000 tokens contra 250.000 dos modelos anteriores. Mas além disso, o modelo funciona bem melhor em contextos mais longos. Vamos analisar nesse vídeo o que isso implica para o processo de engenharia de contexto na construção de agentes de IA para negócios. E também vamos analisar porque a técnica RAG, que é a técnica de busca em arquivos longos, arquivos grandes, está com seus dias contados e talvez não faça sentido para a maioria dos casos de aplicação em agentes de IA para negócios.
Agora, o GPT5 aceita uma janela de contexto bem maior, que é 272.000 tokens para input e 128.000 tokens de output, o que dá os 400.000 tokens de janela de contexto, o que é bem maior do que os 252.000 de janela de contexto dos modelos anteriores. Então é uma evolução para os modelos da OpenAI que agora aceitam 400.000 tokens. Lógico, ainda não está perto dos Gemini, que aceitam 1 milhão, 2 milhões de tokens, mas o que interessa não é somente o tamanho da janela de contexto, mas a performance do modelo na janela de contexto. E aí que vem a boa notícia, que fica claro nesse gráfico aqui de desempenho dos modelos.
Vamos, vamos olhar primeiro as linhas verdes, que é o desempenho dos modelos anteriores da OpenAI, que eram o O3 e o A4 Mini, que é a linha clara. E se você olhar aqui, deixa eu só rabiscar aqui por cima, essa é a linha verde, né, que aqui, ó, esses modelos, eles tinham esse desempenho por janela de contexto. Aqui no eixo X é a quantidade de tokens: 8.000 começa aqui, 32.000, 64.000 tokens, 128.000 tokens, 256.000 tokens, né? E aqui no eixo Y você tem o desempenho do modelo. Você vê que o modelo para janelas bem pequenininhas, né? Antes os modelos antigos, eles ficavam na faixa de 95%, nas janelas pequenininhas, na faixa de 8.000 tokens, mas assim, na faixa já ali para 10.000 tokens mais ou menos, ele já começava a ter um desempenho na faixa de 90%, como você pode ver aqui, e aí depois começava a cair. Então, por exemplo, com 64.000 tokens tinha um desempenho na faixa de 75%. Então esse era o desempenho do O3, que é um baita modelo, e do O4 Mini, que também é um baita modelo.
Aí chega o GPT5 e o GPT5 Mini. Olha a diferença de desempenho destes modelos. Em faixas de contexto de até 10.000 tokens, eles simplesmente trabalham na faixa de 100% de desempenho. 99% e cacetada no cinco dele, ele gabarita em 100%. E o GPT5 fica juntinho ali com 99% e cacetada. Só que o mais interessante é que ele mantém uma performance significativa até 64.000 tokens, ficando o GPT5 em 99% e cacetada e o Mini ficando ali também 98% com 64.000 tokens. Lembrando que uma página de texto tem 500 tokens. Então 50.000 tokens são 100 páginas. E olha o desempenho incrível desses modelos. Eles têm um desempenho muito próximo de 100% até 64.000 tokens. E o cinco ele ainda mantém um desempenho significativo até 97% aqui até 128.000 tokens e ainda um desempenho de 90% com 250.000 tokens. Muito maior, mas muito maior do que os modelos anteriores.
Outra coisa que chama a atenção é que o GPT5 Mini, que é bem mais barato, inclusive, ele tem um desempenho nada desprezível até 64.000 tokens e aí começa a descolar com 128.000 tokens, mas até 64.000 tokens, ele trabalha muito próximo do GPT5 em termos de desempenho. Então agora a gente pode mandar muito mais contexto para os modelos e eles vão funcionar de maneira mais robusta na grande maioria dos casos, no caso do GPT5 e do GPT5 Mini. Isso é uma evolução de performance significativa. Os modelos agora ficam bons de contexto. E isso muda completamente a forma como a gente pensa em engenharia de contexto, porque antes você tinha um esforço de às vezes diminuir demais a engenharia de contexto e podia perder a performance do seu agente. Agora você tem uma LLM mais robusta e você pode passar um contexto melhor e melhorar o desempenho de uso do seu agente. Isso é um efeito muito positivo na melhora da performance em janelas de contexto maiores, né?
Então vamos lá. Primeiro, o que que melhora para a gente, que constrói agentes? A gente consegue fazer prompts mais longos. Então você pode construir prompts mais detalhados, com mais exemplos e mais longos. Você vai gastar um pouco mais, obviamente, porque você vai construir prompts mais longos, mas lembrando que o preço dos modelos caiu pela metade. Então, como os modelos ficaram mais baratos, você pode jogar mais prompt porque eles estão mais baratos e performam melhor com prompts mais longos. Ou seja, você consegue colocar num único agente um prompt maior, em vez de tentar economizar demais o prompt, menos exemplos, menos detalhamento ou dividir em vários agentes e ter o esforço de criar multiagentes.
O segundo ponto que você pode ter vantagem é conversas mais longas. Você pode ter conversas mais longas, você pode ter todo o histórico de conversa sem ficar se preocupando em economizar o histórico de conversa para o agente, tentar diminuir esse histórico de conversa, que isso atrapalha às vezes o desempenho do agente. Você coloca lá todo o histórico de conversa sem economizar muito. Por quê? Porque agora ele é mais barato e funciona melhor. E também ele pode buscar mais dados quando ele precisa. Então ele pode fazer chamadas de ferramenta, extraindo dados de bancos de dados ou de arquivos e pode trazer mais coisas para analisar, para responder o usuário e ele suporta trazer mais desses dados e fazer análise para responder ao usuário. Então os nossos agentes agora podem ter prompts mais longos, podem ter conversas mais longas e eles também podem buscar mais dados e processar de maneira mais precisa. Então, os nossos agentes com certeza ficarão melhores com o GPT5 e inclusive com o GPT5 Mini, que é bem mais barato do que o GPT4.1 Mini. Caiu de 40 centavos de dólar para 25 centavos de dólar. É uma redução de custo significativa.
Bom, e essa melhora que você pode passar mais contexto e é mais barata, significa que o RAG, que é uma técnica muito utilizada para buscar contexto em arquivos para o agente, né, para o agente buscar contexto em arquivos, ela pode estar com os dias contados. Eu acredito que para a maior parte dos casos de uso você deve evitar o RAG. Não faz sentido usar o RAG. Ele tem algumas limitações que não faz sentido você aplicar o RAG.
Então vamos lá. Primeiro, para quem não tem familiaridade com RAG, o processo do RAG, vou colocar aqui o processo do RAG, basicamente tem três etapas, né? Segundo ponto, você tem que fazer o text split, que é pegar o texto, então você tem um texto desse tamanho e você vai splitar esse texto em textos menores. E esse processo de split em si tem um pouco de arte e ciência, porque você tem que expl... E como que você splita esse documento? Não é fácil, tem um milhão de parâmetros, várias formas de fazer isso, porque você tem que obedecer o contexto, os parágrafos, as sessões do arquivo, etc. Não é fácil fazer isso. Você faz overlap, então você cria, eles têm overlap, você cria splits com overlap, tipo assim, ó, splits assim. Então eles têm overlap. Então tem um pouco de redundância de dado. Então a soma dos documentos splitados é maior em termos de volume de dados do que o documento original. Então você vai criando esses processos de split e aí você depois que você splitou, que você tirou o texto, splitou, diminuiu, pegou esse documento, ah, e criou todos esses pedaços de arquivo, você vai fazer o embedding.
E no processo de embedding, basicamente, é o seguinte: para cada um desses arquivos, para cada um desses arquivos, eu vou chamar livremente aqui, tá? Só do ponto de vista didático, para cada um destes arquivos, você vai encontrar uma coordenada, como se fosse o endereço do arquivo, uma coordenada. Que que é o endereço? Então, por exemplo, você tem a latitude, longitude, né, no espaço. E se você tem um monte de endereços, você tem a latitude, longitude, você consegue calcular a distância e saber quem está mais próximo. Então, imagina o seguinte: para cada um desses textos vai existir uma... para cada um desse é calculado um vetor de super coordenada desses pequenos documentos extraídos do texto principal. Beleza? Essas coordenadas que é um vetor matemático gigante que é um monte de coordenadas de 1500 dimensões lá que chama embedding. Beleza? Você fez esse cara. Então você vai lá no banco de dados, guarda o texto de cada chunk, de cada split, né? De cada chunk. Tem esse vetor aqui do lado.
Aí depois imagina que o usuário manda uma pergunta. Então, vem uma pergunta do usuário. Uma pergunta do usuário. Opa, deixa eu voltar aqui. Uma pergunta do usuário. O usuário mandou a pergunta. Essa pergunta tem que passar para um processo de embedding. Aí que que você pega? Você pega, cria o embedding dessa pergunta. E aí com o embedding dessa pergunta você tem um vetor, né, ou uma coordenada dessa pergunta. E aí, se você tem esse cara, o que que você vai pegar? Você vai buscar quais são os chunks que estão mais próximos, quais deles estão mais próximos dessa pergunta do usuário. Então, é um processo de busca mecânico, não tem nada de IA, é matemático. Então, por exemplo, num banco de dados, num PostgreSQL, num Supabase, o que que você pode fazer? Você fala o seguinte: "Olha, o embedding, o vetor dessa pergunta, né, que é o endereço do usuário." O problema que eu preciso dizer para vocês que é o seguinte: com 1500 dimensões existem, imagina se já no espaço de duas dimensões já existem infinitos pontos, em 1500 dimensões é um negócio absurdamente grande. E esse processo mecânico de ver quais são os chunks de documentos que são mais próximos da pergunta, ele é um processo bem falho. Ele não é tão robusto assim. Para ficar robusto, você precisa trazer muito documento. Aí você fala assim: "Não, traga os 10 chunks maiores, mais próximos ou os 20 mais..." Mas no limite, se você começar a trazer muito chunk, aí você perde o benefício do embedding, que é trazer só o pedaço do documento que interessava para o contexto. Então esse processo de busca, né, de busca semântica por embedding, que traz só os pedaços de documentos mais próximos do texto da pergunta ou do contexto da pergunta do usuário, esse processo de busca semântica, ele é bem falho, ele não é robusto, não tem como você ter 100% de acurácia. Então assim, se você implementa um processo de embedding, você tem que saber que você vai introduzir... ele não vai ser robusto e você vai introduzir problemas em 10%, 20% dos casos. Por quê? Porque o processo de embedding não vai trazer os chunks corretos de volta para a IA para ela responder a pergunta do usuário. E aí se o seu processo de buscar o chunk correto não funciona, não tem nada a ver com a IA. Pode ser ótimo, mas se seu processo de RAG é falho de buscar o chunk correto, ela vai responder errado.
Agora pensa comigo, por que a gente criava chunk? Há dois anos atrás o máximo de tokens que aceitava era 8.000 tokens. Então, às vezes só de prompt você tem 5.000 tokens. Então, você não conseguia e qualquer prompt pode ter 5.000 tokens, 10 páginas. Agora imagina que você precisava ter documentos que têm 100 páginas. Era difícil fazer isso para a IA. Então a gente criava o RAG para, vamos dizer assim, a gente criava o RAG por causa dessa limitação. Agora você não precisa do RAG, você pode trazer um contexto muito maior. Então se o seu documento, se você tem lá 100 páginas de documento, 100 páginas são 50.000 tokens. Aí a IA dá conta disso e responde com assertividade de 100%. Então não faz sentido mais usar o RAG, que é um método falho, sendo que você tem a IA, que aceita um contexto super grande e tem 100% de assertividade. Então você, se ao você usar o RAG, você vai introduzir um método de busca falho, que vai introduzir falha para uma IA que tem 100% de precisão, mas ela só tem 100% de precisão se você passar o contexto inteiro. Mas no processo de RAG você nunca passa o contexto inteiro, você passa só os chunks. E o processo de buscar chunks agora com a IA aceitando contextos grandes, você não precisa ser especialista, é só colocar o contexto para dentro.
Bom, então a gente viu os problemas, né? Você tem, deixa, você tem o desafio, ele não é multimodal, você tem que fazer um pré-processamento. Que que ele não é multimodal? Porque fazer esse RAG, a maior parte dos RAGs são de texto. Dá para fazer de imagem e vídeo, mas é outro nível. Tem que ter um pré-processamento, não dá para ser ao vivo, então tem que fazer um processamento e o benefício é decrescente com o aumento dos contextos das IAs, tá? Então esse, isso, esse acho que são os problemas, os problemas do RAG. Deixa eu só limpar aqui.
Agora, qual é a alternativa que nós temos ao RAG? Então, vamos lá. Alternativa. A alternativa ao RAG é criar múltiplos documentos menores. Então você pega um documento grande, você pega um documento grande, por exemplo, que tem 100 páginas. Em vez de você ter um documento, um único documento sem páginas, você pode criar um documento, um, um, sei lá, 50 documentos de duas páginas, que documentos, 50 documentos de duas páginas, então seriam 1000 tokens cada documento. Então você teria em lugar de ter um documento com 50.000 tokens, seriam 50 documentos com 1000 tokens. E aí é o seguinte, se você tem um monte de documento que seria dividido de acordo com o índice do documento e você divide porque você faz essa curadoria, você divide de maneira correta, não cria um algoritmo de split, você cria a introdução, você cria cada pedaço da sessão, você estrutura esses documentos menores, de maneira que faça sentido, que cada pedacinho faça sentido. Então, você tem uma engenharia de contexto aí para construir essa curadoria. E depois que você criou esses documentos menores, você não passa todos os documentos para a IA, você dá uma ferramenta para a IA buscar nesses documentos.
E aí, quais são as ferramentas que você pode dar para? Você pode dar uma ferramenta para ela buscar documento. Então, imagina o seguinte, imagina que você tenha um documento de especificação técnica do Brasil e cada documento tem a ficha técnica de um veículo. Então, que você pode dar uma ferramenta para a IA e fala o seguinte: "Ó, passa o modelo do veículo na ferramenta que eu vou te devolver a ficha, o texto da ficha técnica, que é o documento da ficha técnica daquele veículo." Você não vai passar as fichas técnicas de todos os veículos. Você vai passar uma ferramenta que a IA passa o nome do modelo do veículo para a ferramenta. A ferramenta devolve somente a ficha técnica daquele veículo. Se você construir uma ferramenta desse jeito, você vai conseguir o melhor dos dois mundos. A IA vai usar o contexto só quando precisa. E você não tem RAG aqui. Você simplesmente está trazendo todo o texto que ela precisa. Você vai precisar de três modelos, ela vai lá e busca a ficha técnica de três modelos e traz todo o contexto. E aí você pode dar outras ferramentas a depender da necessidade. Se você olhar o Cursor, o Cursor usa bem pouco semantic search, não usa tanto quanto eu imaginava que usaria lá atrás. Ele usa muito busca, olha o documento inteiro, se o documento tem um tamanho realmente pequeno, usa muito busca dentro do documento que é o comando grep strings específicas, quais documentos têm a palavra, por exemplo, quais documentos têm a palavra cavalo? Ele vai lá e busca todos os documentos que têm a palavra cavalo. Por quê? Porque ele tem uma ferramenta de busca por string, busca os documentos, a lista de documentos que tem aquilo. E a depender da lista de documentos, ele vai lá e busca o conteúdo daquele documento. E também ferramentas de full text search para buscas mais sofisticadas. E se quiser, se você decidir fazer o embedding destes documentos menores, você pode dar uma ferramenta semantic search, onde a IA pode passar uma pergunta, né? E a busca vai ser semântica por aproximação usando o vetor do embedding. Então, então você tem esses caminhos, mas na prática o mais importante é esse cara que é simples, full retrieval, você tem 100 documentos, 50, 100, 200 documentos. Cada documento, ele é relativamente pequeno porque você modelou para ele ser pequeno. Tem lá 1000, 5.000, até 10.000 tokens. E aí a IA só busca o documento quando precisa. E quando ela busca, ela busca o documento inteiro. Não tem embedding, não tem chunk, não tem nada. E se ela buscar um documento que tem 5.000 tokens, 10.000 tokens, hoje a gente sabe que ela tem 100% de assertividade. Então assim, a busca completa, contexto completo, sem RAG é o futuro da modelagem da engenharia de contexto. Tá bom?
Bom, quer dizer que o RAG acabou? A gente nunca mais vai usar o RAG em nenhuma situação? Bom, não é verdade. Apesar que eu acho assim, você tem que evitar o RAG ao máximo. A engenharia de contexto tem que evitar o RAG. Você vai introduzir erro no seu conhecimento. Então, por exemplo, você tem lá a base de todos os documentos da empresa. Você não vai pegar tudo isso, fazer a curadoria em documentos menores e tal. Ela é uma base que está lá. Se você quiser fazer uma IA que busca em cima de uma base não curada, você vai precisar de RAG provavelmente, porque existirão documentos lá com 100, 200, 300 páginas, 1000 páginas, então milhares de páginas. Então, nestes casos, para documentos muito grandes, em base de conhecimento não curadas, você vai usar RAG, mas só usa se você precisar. Mas para agentes em que você precisa de precisão para atender cliente, para fazer processo de back-office, por exemplo, do financeiro, você tem que fazer uma curadoria, divide o contexto em arquivos menores, dá ferramenta para a IA e evita RAG para um agente para base de conhecimento não curado. E nestes casos, o que eu sugiro é você fazer um agente de missão não crítica. Então, é um agente que tem um humano no loop, não é para atender cliente, não é para fazer um lançamento financeiro, é missão não crítica. Ou seja, tem um operador que sabe usar o agente e sabe que o agente eventualmente pode errar. Então, se for em busca de base de conhecimento não curada e missão não crítica com humano no loop, OK? Este agente pode usar o RAG.
Espero que tenha gostado do vídeo. Se gostou, deixe o seu like e se inscreva no canal. E até o próximo vídeo.