Como uma LLM é construída: da Fórmula 1 aos agentes de IA

LLMagentes de IAharness de engenhariaevalsAI-Native

Imagine contratar um piloto excelente e colocar ele na pista sem carro, sem rádio, sem equipe e sem nenhum instrumento de medição. Ninguém esperaria uma boa corrida.

Uso essa imagem porque ela desfaz uma confusão comum nas conversas sobre inteligência artificial: tratar o modelo como se ele fosse o produto inteiro. A LLM pode ser o componente que interpreta um pedido e produz uma resposta. Mas consultar informação, executar ações, controlar permissões e verificar resultados exige um sistema ao redor dela. A própria OpenAI, ao descrever o harness do Codex, fala do ambiente que envolve o modelo, e não só do modelo.

Pra entender essa diferença, vale percorrer duas histórias que se encontram: como aprendemos a construir modelos de linguagem, e como passamos a transformar esses modelos em sistemas capazes de realizar tarefas.

A Fórmula 1 como mapa

Na analogia, a LLM é o piloto. O harness é o carro e a estrutura operacional da equipe. As ferramentas são os comandos e equipamentos que o piloto tem à mão. Os evals são os testes de desempenho. E o cron é o horário programado da largada.

Colocando cada peça no lugar:

LLM, o piloto. Interpreta o contexto e gera respostas ou propostas de ação.
Harness, o carro, os controles e a operação dos boxes. Coordena o trabalho do modelo, as ferramentas e os limites de execução.
Tools, o volante, os pedais e o rádio. Permitem consultar sistemas e realizar ações.
RAG, a consulta às informações da pista. Recupera documentos relevantes pra apoiar a resposta.
Memória externa, o caderno da equipe. Preserva informações que podem ser consultadas depois.
Tracing, a telemetria. Registra o que aconteceu durante a execução.
Evals, os testes e critérios de desempenho. Avaliam se o sistema cumpriu o objetivo.
Cron, o horário da largada. Dispara uma tarefa em momentos definidos.

Esse mapa é uma simplificação didática das responsabilidades que aparecem nas documentações de avaliação de agentes, engenharia de contexto e agendamento. Uma distinção que vale guardar desde já: telemetria registra, avaliação julga. As duas se complementam, mas não são a mesma coisa.

A metáfora também tem limite. Chamar o modelo de piloto não significa atribuir a ele consciência, intenção humana ou responsabilidade. As decisões sobre objetivos, acesso e consequências continuam sendo nossas.

Infográfico 1 de 4: a analogia da Fórmula 1, com a LLM como piloto, o harness como carro e equipe de box, e tools, RAG, memória, evals e cron ao redor

O que é uma LLM, sem mistério

LLM significa Large Language Model, ou grande modelo de linguagem. Nas LLMs generativas autoregressivas, uma tarefa central do treinamento é estimar qual token pode vir a seguir, considerando os anteriores. Token é uma unidade de representação de texto: pode ser uma palavra, um pedaço dela ou um sinal de pontuação. O relatório técnico do GPT-4 e o material da Hugging Face sobre tokenizadores explicam isso com mais detalhe.

Pense na frase "A pista está molhada, então o piloto deve...". O modelo calcula possibilidades de continuação e o procedimento de geração escolhe o próximo token. Esse token entra no contexto, e o processo se repete. É assim que uma resposta inteira se forma, como o artigo do GPT-3 descreve.

Isso não é escolher palavras ao acaso, nem consultar uma lista fixa de respostas. O treinamento ajusta uma rede de números capaz de representar regularidades da linguagem e relações presentes nos dados. A ideia de aprender representações pra generalizar além das frases já vistas aparece em trabalhos fundamentais de modelos neurais de linguagem, como o de Bengio e colaboradores, em 2003.

Mas tem uma diferença decisiva aqui: uma continuação plausível não é necessariamente uma afirmação verdadeira. O próprio relatório do GPT-4 descreve limitações de confiabilidade. Fluência, sozinha, não é prova de conhecimento correto.

Como chegamos até aqui

A história não é uma fila de invenções em que cada tecnologia elimina a anterior. Regras, estatística, redes neurais e busca coexistiram, e continuam podendo ser combinadas. A proposta de Dartmouth, escrita em 1955 pra um encontro em 1956, já discutia linguagem, redes de neurônios e resolução de problemas.

Das regras às representações aprendidas

Uma abordagem possível era escrever instruções explícitas: "se acontecer X, faça Y". Outra era observar sequências de palavras e estimar probabilidades. Os n-grams, por exemplo, usam pequenos trechos consecutivos pra modelar a linguagem. O desafio era generalizar pra combinações nunca observadas. Em 2003, Bengio e colaboradores mostraram que aprender representações numéricas das palavras junto com um modelo probabilístico ajudava a enfrentar esse problema.

Nas redes recorrentes, as RNNs, a informação percorre a sequência por meio de um estado interno. As LSTMs, publicadas em 1997 por Hochreiter e Schmidhuber e apresentadas no mesmo ano na NIPS, foram um marco pra lidar com dependências mais distantes. Em termos simples, ajudaram a preservar informação relevante por mais tempo. Elas ganharam aplicações importantes bem depois, mas não nasceram na década de 2010.

Da tradução ao Transformer

Em 2014, modelos encoder-decoder aprenderam a transformar uma sequência em outra, como na tradução entre idiomas. No mesmo período, Bahdanau e colaboradores propuseram um mecanismo de atenção que permitia consultar as partes relevantes da entrada ao produzir a saída, em vez de depender só de uma representação fixa da frase inteira.

Em 2017, o artigo Attention Is All You Need apresentou o Transformer. A arquitetura dispensava recorrência e convoluções, apoiando-se em mecanismos de atenção e outras camadas neurais. Isso favoreceu a paralelização do treinamento. Ou seja, a atenção não foi inventada pelo Transformer. Ele a reorganizou numa arquitetura de enorme influência.

Do modelo de linguagem ao assistente

Em 2018, o trabalho que originou o GPT mostrou a força de pré-treinar um Transformer e depois adaptá-lo a tarefas. No mesmo ano, o BERT explorou representações bidirecionais, usando contexto dos dois lados no pré-treinamento. São abordagens relacionadas, mas o BERT não é simplesmente uma versão anterior de um chatbot GPT.

Em 2020, o GPT-3, com 175 bilhões de parâmetros, destacou a capacidade de realizar tarefas a partir de instruções e exemplos fornecidos no próprio contexto. É o chamado in-context learning: adaptar a resposta ao que foi apresentado, sem atualizar os pesos naquela execução.

Em 2022, o InstructGPT demonstrou a utilidade do pós-treinamento com feedback humano pra seguir instruções. Em 30 de novembro de 2022, o lançamento público do ChatGPT colocou a interação conversacional no centro da experiência de uso.

Da conversa ao trabalho com ferramentas

Algumas peças da fase seguinte já existiam antes de ficarem populares. O trabalho de RAG é de 2020. O ReAct, apresentado em 2022, explorou a combinação entre raciocínio e ações. Em 2023, o relatório do GPT-4 descreveu um modelo capaz de receber texto e imagens. Esses marcos ajudam a entender a expansão pra sistemas conectados e multimodais.

Em setembro de 2024, a apresentação do o1 destacou ganhos com mais computação no treinamento e também durante a resolução de uma tarefa. Em 2025, o DeepSeek-R1 trouxe resultados importantes com aprendizado por reforço pra raciocínio. Não foi o nascimento do raciocínio em IA, mas um avanço na forma de treiná-lo e de dedicar recursos a ele.

Em 2026, trabalhos sobre harness engineering e avaliação de agentes deixam explícita uma preocupação: não basta melhorar o modelo. É preciso projetar o ambiente em que ele trabalha e medir os resultados do sistema completo.

Infográfico 2 de 4: linha do tempo das LLMs, da IA por regras até reasoning e agentes

As faixas de anos do infográfico marcam quando cada abordagem ganhou tração, não quando ela nasceu. As datas de origem, como a LSTM em 1997 e o RAG em 2020, estão no texto acima.

Como uma LLM é construída, passo a passo

Não existe receita única, e nem todo laboratório divulga seu processo por inteiro. O caminho abaixo descreve uma família comum de modelos generativos baseados em Transformer, apoiado em trabalhos públicos de treinamento e pós-treinamento, como o relatório do Llama 3 e o do GPT-4.

Primeiro, decidir o que vai ser construído

Antes dos dados e das máquinas, vêm escolhas: quais idiomas importam, quais tarefas serão prioridade, qual o orçamento e quais limites de tempo e memória vão existir no uso.

Os estudos de scaling laws investigam as relações entre tamanho do modelo, dados e computação. O trabalho conhecido como Chinchilla, de 2022, reforçou que aumentar só os parâmetros não é estratégia suficiente. O equilíbrio com a quantidade de dados também importa.

Na analogia, não basta contratar um piloto melhor. É preciso dimensionar o conjunto pra corrida que se pretende correr.

Segundo, selecionar e preparar os dados

O treinamento pode usar textos, código e outros materiais, conforme o modelo. Esses dados passam por seleção, limpeza e filtragem. O relatório do Llama 3, por exemplo, descreve remoção de duplicações, processamento de documentos e filtros voltados à qualidade e a informações pessoais.

Não se trata de "colocar a internet inteira dentro da IA". Trata-se de montar um conjunto de treinamento, com decisões sobre quais conteúdos entram e como são apresentados. Filtros reduzem problemas. Não garantem perfeição.

Terceiro, transformar texto em tokens e números

Um tokenizador divide o texto em unidades e associa cada uma a um identificador numérico. Depois, uma camada de embeddings transforma esses identificadores em vetores: listas de números que a rede consegue processar. A divisão depende do tokenizador. Uma mesma palavra pode ocupar um token em um modelo e vários em outro.

Pense nos embeddings como coordenadas num mapa matemático. O que interessa não é um número isolado, mas as relações que o modelo aprende entre essas representações.

Quarto, processar o contexto com camadas neurais

No Transformer, a atenção permite combinar informação de posições relevantes da sequência. Outras camadas transformam essas representações, enquanto mecanismos de posição informam a ordem dos tokens. Na geração autoregressiva, o modelo considera o contexto anterior, sem acesso aos tokens futuros que ainda vão ser produzidos.

Um exemplo: em "Marina guardou o capacete porque ele estava molhado", o contexto ajuda a relacionar "ele" a "capacete". A atenção participa desse processamento, mas não é uma explicação completa de tudo o que o modelo faz.

Quinto, prever, medir o erro e ajustar os pesos

Os parâmetros, também chamados de pesos, são os números ajustáveis da rede. Durante o treinamento, o sistema produz previsões, calcula uma medida de erro e ajusta esses números. A retropropagação, ou backpropagation, calcula como mudanças nos parâmetros afetam o erro. Um algoritmo de otimização usa essa informação pra atualizá-los.

Imagine que um trecho de treinamento termine em "A capital da França é Paris". O modelo recebe o contexto anterior e é treinado pra atribuir mais probabilidade à continuação observada. Ninguém precisa escrever uma pergunta e uma resposta pra cada trecho: o próprio texto fornece os alvos. É o que se chama de aprendizagem autossupervisionada.

Quando um nome traz "70B", isso indica 70 bilhões de parâmetros, não 70 bilhões de documentos. Nos grandes modelos, o treinamento pode ser distribuído entre muitas GPUs, processadores especializados em cálculo paralelo. O Llama 3 é um exemplo público dessa infraestrutura.

E um detalhe que costuma confundir: ajustar os pesos não é uma etapa separada, que acontece só depois do treinamento. É parte do próprio treinamento, repetida em muitos lotes de dados.

Sexto, transformar o modelo-base em assistente

Um modelo-base treinado pra continuar textos não é automaticamente um bom assistente. No ajuste supervisionado, o SFT, ele recebe exemplos de instruções e respostas desejadas. No RLHF, preferências humanas ajudam a orientar o comportamento. A receita clássica treina um modelo de recompensa e usa aprendizado por reforço.

Outras técnicas seguem caminhos diferentes. O DPO, apresentado em 2023, permite otimizar preferências entre respostas sem reproduzir todo o processo clássico de RLHF. São alternativas que podem compor o pós-treinamento, não degraus obrigatórios por onde toda LLM precisa passar.

Sétimo, avaliar e preparar pro uso

A avaliação precisa verificar capacidades, limitações e segurança, não só a aparência das respostas. E ainda tem o desafio operacional de executar o modelo com os recursos disponíveis. O relatório do Llama 3 descreve tanto as avaliações quanto as estratégias de treinamento distribuído e inferência.

Também há formas diferentes de buscar eficiência. Numa arquitetura Mixture of Experts, só parte dos módulos especializados é ativada pra cada token. Não são pessoas nem agentes conversando. São componentes internos da rede, como o Mixtral exemplifica.

Infográfico 3 de 4: como uma LLM é construída, da coleta de dados até virar assistente

No infográfico, o ajuste dos pesos aparece como um passo separado só pra facilitar a leitura. Na prática, ele acontece dentro do treinamento, lote após lote. E o que o modelo aprende a prever é o próximo token, que nem sempre é uma palavra inteira.

O que acontece quando você conversa com o modelo

Quando o modelo já treinado é executado pra responder, chamamos isso de inferência. Num uso típico, os pesos ficam fixos. O que muda a cada interação é o contexto apresentado ao modelo. Fornecer exemplos na conversa não é o mesmo que retreinar, como o próprio artigo do GPT-3 deixa claro.

Isso ajuda a separar três coisas.

Conhecimento nos pesos é o que foi incorporado no treinamento. Contexto é o conjunto de informação disponível naquela execução. Memória externa são registros guardados fora do modelo, que o sistema pode recuperar e inserir de novo no contexto. A engenharia de contexto trabalha justamente com essa seleção e preservação de informação.

Na analogia, uma coisa é o preparo do piloto. Outra é o briefing da corrida. Uma terceira é o caderno da equipe.

Por isso, quando um assistente lembra uma preferência sua, não é preciso supor que a rede neural dele foi modificada. O produto pode ter salvo um registro e apresentado essa informação de novo. Essa persistência exige mecanismos específicos. Não acontece automaticamente em qualquer LLM.

Os modelos de raciocínio acrescentam outra possibilidade: gastar mais computação na resolução, explorando passos intermediários antes da resposta final. Isso pode melhorar resultados em certas tarefas, mas não elimina a necessidade de avaliação, nem significa que uma resposta mais longa será melhor.

Consultar não é a mesma coisa que executar

RAG significa Retrieval-Augmented Generation, ou geração aumentada por recuperação. A ideia é buscar informação relevante numa fonte externa e fornecer isso ao modelo pra apoiar a resposta. O trabalho de Lewis e colaboradores combinou o conhecimento nos parâmetros com uma memória externa recuperável.

Imagine a pergunta: "Qual é a política de descontos desta empresa?". Em vez de depender só do treinamento, o sistema pode recuperar a política vigente e usá-la como referência.

A vantagem não é mágica. Se a recuperação trouxer o documento errado, ou uma versão antiga, a resposta pode continuar inadequada. Na implantação, minha regra seria exigir identificação da fonte, data e autorização de acesso, além de testar a qualidade das respostas.

Já as tools, ou ferramentas, permitem consultar serviços e executar operações. Numa integração típica de function calling, o modelo produz uma solicitação estruturada. Quem executa a função é a aplicação, que depois devolve o resultado ao modelo.

Pedir "verifique a disponibilidade deste imóvel" pode gerar uma chamada ao sistema de estoque. Pedir "redija uma mensagem pro cliente" pode produzir só um rascunho. Enviar a mensagem é outra ação, sujeita às regras que a aplicação definiu.

O MCP, Model Context Protocol, padroniza parte da comunicação entre aplicações de IA e fontes de dados ou ferramentas. É um protocolo de integração. Não é um modelo de linguagem, nem garantia de que o uso dessas ferramentas será correto.

Harness, o sistema que deixa o modelo trabalhar

Harness, nesse contexto, é a estrutura de execução que envolve o modelo. Ela organiza entradas, chamadas de ferramentas, resultados e a continuidade do trabalho. A documentação do Codex descreve esse ambiente envolvendo o modelo, a execução de ferramentas e mecanismos como permissões e isolamento.

Num sistema bem projetado, essa estrutura precisa responder a perguntas concretas. Que dados o modelo recebe? Quais ações estão disponíveis? Quando uma aprovação é necessária? O que acontece depois de uma falha? Quando o trabalho deve parar?

O agent loop, ou ciclo do agente, conecta essas decisões. O sistema apresenta o estado atual. O modelo propõe uma ação. A aplicação executa o que estiver autorizado. O resultado volta pro contexto. E vem a próxima decisão. O ReAct é uma referência importante pra entender essa interação entre raciocínio, ação e observação.

Imagine um agente de desenvolvimento que recebe "corrija este erro". Ele pode ler arquivos, propor uma alteração, rodar os testes, observar uma falha e tentar outra correção. Mas o ciclo precisa de limites. Sem critério de conclusão, orçamento e verificação, atividade não é sinônimo de progresso.

Um estudo da Anthropic sobre agentes de longa duração descreve dificuldades como perder continuidade entre sessões e declarar tarefas concluídas cedo demais. A solução investigada inclui registros de progresso, trabalho incremental e testes. Não é só uma questão de trocar o modelo.

Tem ainda uma distinção útil. Num workflow, o código define grande parte do caminho. Num agente, o modelo participa dinamicamente da escolha dos próximos passos. A Anthropic usa essa separação em Building effective agents e recomenda aumentar a complexidade só quando for necessário. Um processo previsível pode ser melhor resolvido com uma automação simples.

Evals, ou como saber se funcionou de verdade

Evals é a forma abreviada de evaluations, avaliações estruturadas. A pergunta não é "a resposta parece inteligente?", e sim "o sistema cumpriu os critérios definidos?". Em agentes, importa tanto a saída quanto o estado final do ambiente. Dizer que uma tarefa foi realizada não prova que ela aconteceu, como a Anthropic destaca ao desmistificar evals para agentes.

Suponha um assistente imobiliário. Eu começaria com situações como uma unidade indisponível, uma pergunta sem informação suficiente, uma tentativa de obter dados de outro cliente e um pedido de desconto sem autorização. A avaliação verificaria se o sistema consulta a fonte certa, reconhece limites e respeita as permissões.

Alguns critérios são objetivos, como validar um campo ou rodar os testes de código. Outros exigem um julgamento de qualidade, como verificar a fidelidade de um resumo. Dá pra usar outra LLM como avaliadora, mas esse julgamento precisa ser calibrado com avaliações humanas e critérios claros.

Uma boa comparação usa casos representativos, separa exemplos de desenvolvimento dos de avaliação e registra as condições do teste. Mudou o modelo, as instruções ou as ferramentas? Avalia de novo. A documentação da OpenAI recomenda avaliações específicas por tarefa e rejeita o "parece estar funcionando" como estratégia suficiente.

Na analogia, tracing é a telemetria da execução. Os evals usam os resultados e, quando necessário, esses registros pra julgar o desempenho. E não precisam acontecer só no fim de uma interação. Podem rodar durante o desenvolvimento e ser repetidos antes de qualquer mudança entrar em produção.

Cron é o relógio, não a inteligência

Cron é um mecanismo tradicional de agendamento em sistemas Unix e Linux. Um cron job é uma tarefa programada. "Crons" costuma ser um jeito informal de se referir a essas tarefas. Ele não raciocina: dispara um comando conforme uma programação, como descreve a página de manual do crontab.

Na sintaxe tradicional de cinco campos, a expressão:

0 8 * * *

significa executar no minuto zero da hora oito, todos os dias, no fuso usado pelo agendador. A programação vem antes do comando que será executado. Outras plataformas podem adotar variações dessa sintaxe.

Isso permite iniciar uma rotina de IA todo dia às 8h. Mas a rotina precisa estar implantada num ambiente capaz de executá-la. Escrever "faça isso amanhã" numa conversa não cria, por si só, um agendamento.

Horário é só um tipo de gatilho. Um novo pedido, uma mensagem numa fila ou um evento de sistema também podem iniciar um trabalho. O importante é separar quando começar de como executar.

Em produção, também é preciso lidar com repetição, falhas e sobreposição. A documentação de CronJobs do Kubernetes alerta que podem ocorrer execuções duplicadas ou ausentes em certas circunstâncias e recomenda tarefas idempotentes: repetir a execução não deve duplicar indevidamente seus efeitos.

Juntando tudo em um exemplo

Vamos imaginar uma equipe comercial que quer receber, às 8h, um resumo das oportunidades que precisam de atenção. É um cenário ilustrativo, não o relato de uma implantação específica.

O cron inicia a rotina. O harness prepara as instruções e disponibiliza acessos limitados. Uma ferramenta consulta o CRM, o sistema de relacionamento com clientes. Outra recupera a disponibilidade dos produtos. O RAG encontra a política comercial pertinente. A LLM relaciona as informações e redige o resumo.

Nesse desenho, dados de clientes seriam usados só quando necessário, dentro das permissões aplicáveis. A rotina poderia produzir um relatório interno, mas não conceder descontos nem enviar propostas sem a aprovação prevista.

O tracing registraria consultas, falhas e tempo de execução. Os evals verificariam se o resumo omite oportunidades relevantes, inventa valores ou recomenda ações fora da política. Se uma consulta falhasse, o relatório deveria apontar a lacuna, não escondê-la.

A pergunta de arquitetura já não é só "qual modelo escolher?". Ela precisa incluir: qual resultado esperamos, que informação sustenta esse resultado e que evidência vamos aceitar de que o trabalho foi bem feito?

Infográfico 4 de 4: o sistema moderno de IA, com trigger, harness, LLM, tools, ação, tracing e evals

O que essa história muda na forma de construir soluções

Minha leitura é que o avanço das LLMs não diminui a importância da engenharia. Ele desloca parte do esforço pra especificar objetivos, organizar contexto, limitar ações e validar consequências.

O artigo da OpenAI sobre harness engineering, publicado em fevereiro de 2026, descreve justamente uma experiência em que o trabalho dos engenheiros se concentra em projetar ambientes, especificar intenção e construir ciclos de feedback pra agentes. É um caso concreto, não uma promessa de que qualquer projeto terá o mesmo resultado.

Pra uma empresa, eu começaria pelo problema e pelo critério de sucesso, não pela quantidade de agentes. Um fluxo determinístico com uma chamada de LLM pode ser suficiente. A autonomia só deveria crescer quando a tarefa, os testes e os controles justificassem essa escolha. Essa preferência pela solução mais simples também aparece nas orientações da Anthropic pra construir agentes.

Na Fórmula 1 da nossa analogia, melhorar o piloto importa. Mas colocar um piloto melhor numa operação mal organizada não resolve os problemas da equipe.

A LLM produz possibilidades. O harness organiza a execução. As ferramentas conectam o sistema ao mundo. O cron define os momentos de partida. Os evals produzem evidência sobre o desempenho.

E as pessoas continuam responsáveis por decidir quais corridas valem a pena disputar, quais riscos aceitar e o que realmente significa chegar ao destino.

Referências

Fontes primárias e documentações consultadas em 7 de setembro de 2026. As datas dos marcos históricos se referem à primeira divulgação indicada no texto. Páginas e preprints podem ter revisões posteriores.