O modelo não fez tudo aquilo. O sistema fez.

Em uma aula me perguntaram o que encontramos quando levantamos o capô de um LLM↳LLMs48 conteúdosConsiderações básicas de hardware para modelos de linguagem em código aberto: Memória, Desempenho e ViabilidadeMarketing Tech · out 2025Modelos de linguagem sob ataque: o lado obscuro da IA generativaDevSecOps · mai 2025Criando um LLM – modelo de linguagem de grande escala – do zero com TransformersAI · abr 2024Ver tudo em AI →. A pergunta é ótima porque, quando retiramos a interface conversacional, o nome do produto e a impressionante fluência das respostas, encontramos algo muito menos parecido com uma mente do que parece.

Encontramos matemática, com bilhões de parâmetros, multiplicações de matrizes, representações vetoriais, mecanismos de atenção, distribuições de probabilidade, software, hardware e uma enorme infraestrutura computacional.

Mas dizer simplesmente que um LLM “prevê o próximo token” também simplifica demais o que acontece. Nos modelos autoregressivos, esse é realmente o objetivo fundamental do pré-treinamento. O texto é transformado em tokens e o modelo ajusta seus parâmetros para melhorar a previsão do próximo token condicionado ao contexto anterior.

Parece um objetivo surpreendentemente simples, mas o resultado não é. A combinação de escala, arquitetura, dados, otimização e treinamento produz capacidades que não são intuitivas quando olhamos apenas para o objetivo de previsão.

Para prever tokens em enormes quantidades de contextos, a rede aprende regularidades extremamente complexas presentes nos dados. Surgem representações distribuídas relacionadas a sintaxe, relações semânticas, entidades, estilos, estruturas de código e inúmeros outros padrões.

E dizer que o modelo “aprendeu conhecimento sobre o mundo” pode ser uma simplificação útil, mas não significa que exista dentro dele uma enciclopédia ou um banco de fatos. Muito do que chamamos de conhecimento paramétrico está codificado de forma distribuída nos pesos e se manifesta através das ativações produzidas durante a inferência.

E nem todo conhecimento utilizado em uma resposta precisa estar nos parâmetros. Pode vir do contexto fornecido naquele momento, de documentos recuperados, memória externa ou ferramentas.

Também não sabemos se as representações internas dos LLMs correspondem a algo equivalente às representações humanas do mundo. Existe uma discussão científica importante sobre sua estrutura e profundidade. Comportamento competente não demonstra, por si só, compreensão equivalente à humana.

Depois vem o pós-treinamento. Um modelo base aprendeu essencialmente a modelar e continuar sequências. Isso não significa que seja naturalmente um bom assistente.

Supervised fine-tuning, aprendizado baseado em preferências e diferentes formas de reinforcement learning ajudam a moldar aquela capacidade para seguir instruções, produzir determinados formatos, obedecer políticas e apresentar comportamentos considerados mais úteis. Aqui é moldada parte importante daquilo que percebemos na interface como “personalidade”.

Mas precisamos tomar cuidado também com a palavra alinhamento. Pós-treinamento não garante alinhamento com todos os valores humanos em todos os contextos. Ele otimiza comportamentos segundo determinados objetivos, dados, avaliações, feedback e políticas.

E isso pode produzir efeitos indesejados. Quando determinadas formas de treinamento valorizam excessivamente aquilo que humanos preferem ouvir, o sistema pode aprender padrões de concordância que competem com factualidade ou julgamento. É daí que surge parte da discussão sobre sycophancy. Agradar ao usuário e estar correto não são objetivos equivalentes.

Nos chamados reasoning models aparece outra camada. Costumamos dizer que eles “pensam antes de responder”. É uma metáfora conveniente, não uma descrição literal de um processo mental.

Esses sistemas podem utilizar mais computação durante a inferência e recorrer, dependendo da implementação, a trajetórias intermediárias, busca, amostragem, verificação e outras estratégias que melhoram o desempenho em determinadas classes de problemas.

Isso pode produzir ganhos impressionantes. Mas mais computação durante a inferência não demonstra consciência, introspecção ou raciocínio humano. Melhor desempenho não resolve automaticamente a questão sobre o mecanismo que o produziu.

Isso ajuda a entender outra característica desconcertante dos LLMs. Eles podem estar errados com extraordinária eloquência. Eu evitaria dizer simplesmente que o modelo “não possui noção de dúvida”. Modelos conseguem expressar incerteza e existem técnicas de calibração. O problema é mais preciso. A confiança linguística da resposta não constitui uma medida confiável de sua correção factual.

Plausibilidade e verdade frequentemente coincidem, mas não são a mesma coisa. Por isso uma resposta inventada pode apresentar gramática, estrutura argumentativa e aparente segurança semelhantes às de uma resposta correta. Confiança linguística não é verificação.

Também encontramos debaixo do capô um perfil de capacidades extremamente irregular. Modelos podem apresentar desempenho extraordinário em programação, tradução, escrita ou análise e falhar em tarefas aparentemente mais simples. Competência em uma dimensão não garante competência em outra.

É perigoso transportar automaticamente para máquinas nossa intuição sobre hierarquias de competência humana. É também por isso que resultados elevados em benchmarks gerais não eliminam a necessidade de avaliações específicas para cada aplicação.

Mas, quando levantamos o capô de uma aplicação moderna, aparece algo que considero ainda mais interessante. O que estamos usando quase nunca é apenas o modelo. Existe uma camada de software ao redor dele.

Um termo que vem sendo utilizado para essa camada é harness. Não existe uma taxonomia universal para o termo, mas podemos utilizá-lo de forma operacional para representar o software que conecta o modelo a contexto, memória, estado, ferramentas, dados, políticas e loops de execução. O usuário vê uma caixa de diálogo. Por baixo dela pode existir uma arquitetura inteira coordenando o modelo, como system prompts, gerenciamento de contexto, RAG, memória, estado, etc. Isso significa que aquilo que atribuímos ao “modelo” pode ser, em parte importante, propriedade do sistema construído ao redor dele.

Imagine uma pergunta factual. Um modelo isolado responde usando seus parâmetros e o contexto recebido. O mesmo modelo dentro de um sistema capaz de perceber que a informação precisa ser atualizada, buscar fontes, recuperar documentos, inserir evidências no contexto e verificar grounding pode apresentar desempenho completamente diferente.

O modelo é o mesmo, mas o sistema não. Em programação isso fica ainda mais evidente. Um modelo isolado pode gerar código, mas colocado em um harness capaz de criar arquivos, executar o programa, rodar testes, observar erros, modificar o código e repetir o ciclo, ele adquire uma capacidade operacional muito maior.

Não necessariamente porque seus pesos ficaram “mais inteligentes”. O sistema ganhou mecanismos para agir, observar consequências e tentar novamente.

Isso muda também a maneira como deveríamos interpretar benchmarks. Dizer simplesmente que “o modelo X consegue fazer Y” pode ser insuficiente. Precisamos saber qual versão, prompt, contexto, ferramentas, orçamento de compute, número de tentativas, acesso a busca, execução de código, verificadores, memória e harness foram utilizados.

Em determinadas tarefas, mudar essas condições pode mudar substancialmente o resultado. Comparar modelos sem compreender o sistema de avaliação pode ser como comparar motores ignorando o carro em que foram instalados.

Com agentes, essa distinção fica ainda mais importante. Um agente não é simplesmente um LLM que ficou mais inteligente.

É um sistema no qual o modelo pode operar dentro de um loop, receber contexto, utilizar ferramentas, observar resultados, manter estado e decidir próximos passos até atingir algum critério de parada.

O harness transforma capacidade do modelo em capacidade operacional. E aqui aparece outra distinção importante. O modelo influencia aquilo que o sistema consegue interpretar e produzir. O harness influencia como essa capacidade é mobilizada. As ferramentas determinam que ações estão disponíveis. E credenciais e políticas determinam quais dessas ações podem produzir efeitos reais.

Quando um sistema responde corretamente sobre um documento interno, aquele conhecimento pode ter sido recuperado naquele instante. Quando resolve um cálculo, pode ter chamado uma calculadora ou um código Python↳Python56 conteúdosVSCode + Python + Alexa: Desenvolva e teste skills para alexa localmente com pythonDev (Back & Front) · out 2025Dominando decoradores em Python: um guia completo com exemplosDev (Back & Front) · jan 2025Desenvolvimento de software: diferenças entre Python, JavaScript e JavaGestão Dev & TI · nov 2024Ver tudo em Dev (Back & Front) →. Quando informa algo ocorrido há poucos minutos, pode ter pesquisado fontes externas.

Quando realiza uma transação, não foi o LLM que magicamente adquiriu capacidade de movimentar dinheiro. Algum componente disponibilizou uma ferramenta, alguma identidade recebeu credenciais e alguma política permitiu que a ação fosse executada.

O harness não amplia apenas capacidade. Amplia também a superfície de risco. Quanto mais ferramentas, memória, dados, credenciais e autonomia colocamos ao redor do modelo, maior se torna o espaço de ações possíveis.

Um LLM restrito à geração de texto pode produzir uma resposta errada. O mesmo modelo conectado a e-mail, ERP, bancos de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data →, cloud ou sistemas financeiros pode transformar uma interpretação errada em uma ação com consequências externas.

Além disso, aparecem superfícies como prompt injection indireto, manipulação de ferramentas, contaminação de memória e abuso de privilégios.

É por isso que considero cada vez menos útil discutir confiabilidade apenas no nível do LLM quando falamos de aplicações corporativas.

Precisamos avaliar o modelo e o sistema. Um harness não corrige magicamente as limitações do modelo. Um loop mal projetado pode repetir um erro. Uma memória contaminada pode propagá-lo. Uma ferramenta excessivamente privilegiada pode transformar uma alucinação em incidente.

Mas uma arquitetura bem projetada também pode compensar fragilidades utilizando evidências externas, ferramentas determinísticas, verificadores, isolamento e controles.

Depois de levantar o capô, portanto, não encontramos simplesmente “uma IA”.

Encontramos camadas. O modelo fornece capacidades, o pós-treinamento molda comportamentos, o contexto fornece informação naquele momento, memória e estado dão continuidade ao processo, o harness orquestra a operação. As ferramentas ampliam aquilo que o sistema pode fazer, credenciais e políticas determinam sua autoridade,  e a infraestrutura transforma decisões computacionais em execução.

Essa visão ajuda a escapar de dois extremos. Um é reduzir LLMs a “papagaios estatísticos” e ignorar capacidades reais de representação e generalização. O outro é observar o comportamento produzido pelo sistema inteiro e atribuí-lo a uma suposta mente existente dentro do modelo.

Muitas vezes ficamos impressionados com aquilo que “o modelo fez” quando estamos observando o resultado combinado de pesos, computação, contexto, memória, estado, ferramentas, software, dados e harness.

LLMs são muito mais sofisticados do que “apenas autocomplete” e muito menos humanos do que sua linguagem faz muitos pensarem.

E, para mim, uma das conclusões mais importantes que aparecem quando levantamos o capô é justamente esta.

O comportamento que vemos na tela não é necessariamente uma propriedade do modelo. É uma propriedade do sistema que construímos ao redor dele. Parte do comportamento é propriedade das capacidades do modelo e parte emerge da interação entre modelo e sistema.

Portanto, o comportamento que vemos na tela não deve ser atribuído automaticamente ao modelo. Ele emerge da interação entre modelo, contexto, computação e o sistema que construímos ao redor dele.