Mapa de IA, LLMs, Transformer, tokens
Você já viu um filtro reconhecer spam e um assistente redigir uma mensagem. Ambos podem usar aprendizado de máquina, mas entregam objetos diferentes: uma decisão sobre uma entrada e uma sequência nova de texto. Nesta aula, essa diferença vira um mapa para escolher componentes. O projeto é comparar três modelos; antes de medir qualquer resultado, precisamos saber o que cada operação realmente faz.
Usaremos um pedido de suporte fictício: “Meu pagamento foi aprovado, mas o acesso não apareceu”. Ele será classificado, representado por um vetor e transformado em resposta. Essas três tarefas permitem separar produto, modelo e algoritmo. Nenhuma saída plausível será tratada automaticamente como fato sobre a conta do cliente.
JavaScriptRAGIA & MLAo terminar esta aula
- O contrato da tarefa vem antes do modelo.
- Contexto de conversa não é treinamento nem memória automática.
- Representação vetorial, evidência e texto gerado cumprem funções diferentes.
Antes de continuar: Laboratório: Aprendizado e redes: do gradiente à avaliação
IA, aprendizado de máquina e geração
IA & MLInteligência artificial é um campo amplo de métodos para realizar tarefas que associamos à inteligência. Aprendizado de máquina é uma família de métodos que ajustam parâmetros a partir de dados, em vez de depender apenas de regras escritas manualmente. Deep Learning usa redes neurais com múltiplas camadas para construir representações. Portanto, esses nomes não são alternativas mutuamente exclusivas: um sistema generativo pode usar aprendizado de máquina e Deep Learning ao mesmo tempo. O contraste útil é entre tarefas. Um classificador atribui uma categoria ao pedido; um gerador constrói uma resposta, token por token, condicionada à entrada.
No suporte, uma regressão que estima tempo de atendimento pode ser suficiente para organizar filas. Usar um LLM para essa previsão introduz custo, variabilidade e validação de texto sem necessariamente trazer benefício. Já redigir uma resposta adaptada ao pedido envolve linguagem aberta, situação em que um modelo generativo pode ajudar. A escolha começa pelo contrato: qual entrada existe, qual saída é necessária e qual erro é aceitável? Não comece pelo nome do modelo. Uma arquitetura pode combinar regras de autorização, classificação e geração sem entregar todas as decisões a um único componente.
O que um LLM aprende e o que uma conversa altera
IA & MLUm modelo de linguagem estima possibilidades de continuação de sequências. No pré-treinamento, ajusta seus parâmetros sobre grandes conjuntos de dados para aprender padrões. O pós-treinamento pode modificar comportamento com exemplos de instruções, preferências e outros sinais. Instruction tuning é o ajuste usando demonstrações de instrução e resposta; não é sinônimo de todas as formas de pós-treinamento. O estudo InstructGPT oferece um exemplo histórico de combinação de demonstrações e feedback humano, não uma receita universal para todo produto atual.
↗ Training language models to follow instructions with human feedback↗ Conversation state
Ao escrever “responda em português”, você normalmente muda a entrada da inferência, não os pesos do modelo. O histórico fornecido pode influenciar a próxima resposta enquanto estiver disponível no contexto. Isso é diferente de treinar ou armazenar uma memória durável. Essa distinção explica um erro frequente: ensinar um dado durante a conversa e presumir que qualquer sessão futura o conhecerá. Para o pedido de suporte, o modelo pode produzir o formato de uma resposta educada sem conhecer o pagamento. Conhecimento linguístico e acesso ao estado atual do negócio são capacidades separadas.
↗ Training language models to follow instructions with human feedback↗ Conversation state
Transformer e attention sem antropomorfismo
IA & MLImagine a frase “O pagamento do aluno foi confirmado, mas ele ainda não recebeu acesso”. Para interpretar “ele”, o processamento precisa relacionar posições da sequência. Attention é um mecanismo numérico que combina representações usando pesos calculados a partir de relações entre entradas. Uma analogia útil é consultar fichas relevantes antes de atualizar uma anotação: cada posição incorpora informação de outras posições. Não existe uma pessoa interna escolhendo onde olhar. A operação faz parte de uma rede treinada e pode combinar relações diferentes em diferentes camadas e cabeças.
O artigo original apresentou o Transformer para tarefas de tradução, eliminando recorrência e convoluções naquela arquitetura. Não conclua que todos os modelos modernos são cópias integrais do desenho original. Modelos de geração frequentemente usam atenção causal, limitando o acesso a posições futuras durante a previsão. A arquitetura explica como informação pode ser relacionada, mas não prova compreensão perfeita, memória infinita ou raciocínio sempre correto. Se o pagamento não aparece na entrada nem em uma ferramenta consultada, atenção não cria evidência sobre ele.
Tokens e janela de contexto
IA & MLToken é uma unidade da representação textual usada pelo modelo. Pode corresponder a uma palavra, parte dela, pontuação ou outra unidade definida pelo tokenizador. Separar texto por espaços é um exercício de programação, não uma contagem real de tokens. Um nome raro, código e português com acentos podem ter segmentações diferentes em tokenizadores distintos. Por isso, a comparação de modelos precisa registrar o tokenizador ou o consumo reportado por cada provedor. Uma regra aproximada em caracteres serve para planejamento grosseiro, não para faturamento ou validação de limite.
A janela de contexto limita a sequência que pode ser processada naquela operação. Instruções, mensagens, resultados de ferramentas e saída podem disputar esse orçamento conforme a API e o modelo. Ter uma janela grande não garante que cada detalhe será usado corretamente. No suporte, enviar todo o banco de dados é impraticável e arriscado; envie a política relevante e o estado autorizado da conta. Preserve espaço para a resposta e trate explicitamente o excesso. Truncar silenciosamente pode remover exatamente a exceção que altera a conclusão.
Embeddings são representações, geração é produção
RAGUm embedding representa uma entrada como vetor de números. A utilidade aparece quando uma função de comparação ajuda a encontrar itens relacionados: o pedido sobre acesso pode ficar próximo de documentos sobre ativação. O vetor não é uma resposta pronta nem uma garantia de que um documento é verdadeiro. Dimensões individuais não devem ser interpretadas como campos claros do tipo “urgência” ou “pagamento”; o significado emerge da representação e da função de comparação utilizada.
Geração produz uma sequência de saída a partir de instruções e contexto. A busca por embeddings pode selecionar documentos para alimentar essa geração, mas os componentes continuam separados. Você pode buscar corretamente uma política antiga e gerar uma resposta consistente com ela, ainda assim errada para a política vigente. Por isso, metadados como data, versão e origem importam tanto quanto proximidade. No relatório, diferencie “encontrei um trecho relacionado” de “o trecho comprova esta afirmação” e de “o modelo redigiu esta afirmação”. Essa separação será a base do RAG nas semanas seguintes.
Exemplo comentado e limites
FundamentosO registro explicita uma ausência: a alegação do usuário não equivale a confirmação no sistema financeiro. O exemplo é executável sem credenciais porque prepara o contrato experimental. Ele não simula uma medição de tokenização e não inventa uma chamada a um modelo. Essa honestidade permite comparar depois observações reais com a expectativa definida antes do teste.
const pedido = "Meu pagamento foi aprovado, mas o acesso não apareceu";
const registro = {
entrada: pedido,
tarefa: "redigir resposta condicionada à evidência",
evidencia: { pagamentoConsultado: false },
respostaEsperada: "Solicitar identificação segura e consultar o pagamento",
tokenizacao: "não medida",
embedding: "não calculado",
geracao: "não executada"
};
console.log(JSON.stringify(registro, null, 2));A saída contém três campos separados para tokenização, embedding e geração. Preencher todos com “resposta do chatbot” apagaria a diferença entre operações. Para usar um provedor, acrescente seu identificador, configuração, entrada efetiva e saída bruta. O resultado esperado é um critério de avaliação humano, não o texto que todo modelo obrigatoriamente deverá devolver.
Exercício aplicado
Uma equipe quer responder ao pedido sobre pagamento sem acesso. Desenhe quais partes devem usar regra, consulta, embedding e geração, e justifique os dados necessários.
- Execute o registro local e confirme que nenhuma operação externa está marcada como realizada.
- Escreva casos nominal, incompleto e ambíguo; defina a evidência que permitiria responder.
- Registre modelo, provedor, data, parâmetros suportados, entrada integral e saída bruta de cada execução real.
- Separe qualidade observada, custo reportado e limite documentado; descreva dados ausentes.
Abrir resolução comentada
Uma solução adequada mantém autorização e consulta do pagamento na aplicação. O embedding seleciona a política de ativação, se houver uma coleção de documentos. O gerador redige a resposta usando a política e o resultado da consulta. Se a consulta falhar, a resposta assume a ausência de confirmação e informa uma próxima etapa segura.
No relatório comparativo, utilize os mesmos casos e a mesma rubrica para três modelos disponíveis. Não preencha campos de custo e latência com palpites. Registrar “não medido” preserva a diferença entre lacuna experimental e resultado negativo. Um modelo que inventa a confirmação falha mesmo se o tom da mensagem for agradável.
A entrega deve mostrar por que confirmação financeira é uma consulta e por que redação é geração. Compare correção factual, respeito à ausência de evidência e adequação do próximo passo. A melhor resposta não precisa repetir o gabarito palavra por palavra: deve preservar o contrato.
A resolução cria os três casos exigidos e prepara registros que diferenciam tokenização, embeddings e geração. O contrato rejeita resultado externo sem configuração e evidência; nenhum registro de provedor é inventado. Um assert reprova a afirmação de pagamento aprovado no caso incompleto. Para concluir a comparação externa, o estudante preenche registros reais de três modelos e aplica a rubrica descrita no corpo; essa medição não é simulada como conclusão.
import assert from "node:assert/strict";
const casos=[
{id:"nominal",pedido:"Consulta autorizada confirma pagamento do pedido 72",evidencia:"consulta-p72",
expectativa:"Explicar política e consultar matrícula",podeAfirmarPagamento:true},
{id:"incompleto",pedido:"Paguei, mas não tenho acesso",evidencia:null,
expectativa:"Solicitar identificação segura; não confirmar pagamento",podeAfirmarPagamento:false},
{id:"ambiguo",pedido:"Há duas cobranças e meu login não funciona",evidencia:null,
expectativa:"Separar intenções e encaminhar revisão",podeAfirmarPagamento:false}
];
const registros=casos.map(c=>({casoId:c.id,entrada:c.pedido,evidencia:c.evidencia,
tarefa:"gerar resposta condicionada à evidência",tokenizacao:{status:"não medida"},
embedding:{status:"não calculado"},geracao:{status:"não executada"},
rubrica:{naoInventarEstado:true,preservarIntencao:true,proximoPasso:c.expectativa}}));
const contratoExecucaoReal={camposObrigatorios:["casoId","modelo","provedor","data","parametros",
"entradaEfetiva","saidaBruta","origemEvidencia"],
camposMedicao:["latenciaTotalMs","consumoReportado","custoComData","limiteDocumentado"]};
function validarRegistroExterno(registro){
for(const campo of contratoExecucaoReal.camposObrigatorios)
if(registro[campo]===undefined||registro[campo]===null)throw new Error("FALTA_"+campo);
return true;
}
function avaliar(caso,resposta){
const confirma=/pagamento foi aprovado|pagamento confirmado/.test(resposta.toLowerCase());
return {semInventarEstado:!confirma||caso.podeAfirmarPagamento};
}
assert.equal(registros.length,3);
assert.ok(registros.every(r=>r.geracao.status==="não executada"&&r.embedding.status==="não calculado"));
assert.equal(avaliar(casos[1],"Seu pagamento foi aprovado").semInventarEstado,false);
assert.equal(avaliar(casos[1],"Precisamos consultar o pagamento").semInventarEstado,true);
assert.throws(()=>validarRegistroExterno({casoId:"nominal"}),/FALTA_modelo/);
console.log({status:"aprovado",registros,contratoExecucaoReal,
resultadosExternos:[],lacuna:"comparação em três modelos exige execuções reais autorizadas"});Como conferir seu resultado
- As três operações estão diferenciadas.
- Cada resultado externo contém configuração e evidência real.
- O caso sem confirmação financeira não afirma pagamento aprovado.
Aplique em um problema novo
Primeiro resolva sem consultar a resposta. Explique suas decisões e guarde a evidência. A conclusão de leitura é independente desta autoavaliação.
Confira seus pré-requisitos
- Separar dados, regra e geração.
- Executar .mjs e interpretar JSON.
Biblioteca: cliente afirma devolução, mas serviço de empréstimos está indisponível. Desenhe consulta, regra, embedding e geração.
Conferir raciocínio e critérios de domínio
A confirmação da devolução exige consulta ao empréstimo; a regra governa a baixa de multa; embedding recupera política e geração redige a explicação.
Com o serviço indisponível, a decisão final é pendência: solicitar identificação e informar que devolução/multa não foram confirmadas.
Uma resposta que cancela a multa é rejeitada, mesmo que tenha tom adequado ou alta similaridade com a política.
Evidências para autoavaliação ou revisão por pares
- Operações: A confirmação da devolução exige consulta ao empréstimo; a regra governa a baixa de multa; embedding recupera política e geração redige a explicação.
- Ausência de evidência: Com o serviço indisponível, a decisão final é pendência: solicitar identificação e informar que devolução/multa não foram confirmadas.
- Limites: Uma resposta que cancela a multa é rejeitada, mesmo que tenha tom adequado ou alta similaridade com a política.
Um erro frequente
Texto convincente confirma devolução.
Fluência não substitui consulta autorizada do estado.
Teste sua compreensão
Responda com suas palavras antes de abrir o comentário. Saber explicar uma decisão é parte do domínio.
1. Uma conversa altera automaticamente os pesos do LLM?
Não.
Na inferência comum, o texto altera o contexto da chamada. Treinamento e persistência são processos separados.
↗ Training language models to follow instructions with human feedback↗ Conversation state
2. Contar palavras mede tokens?
Não.
O tokenizador define unidades que podem incluir subpalavras; a separação por espaços não reproduz esse algoritmo.
3. Um embedding próximo comprova que o pagamento foi aprovado?
Não.
Proximidade auxilia recuperação; confirmação de pagamento exige uma fonte autorizada do estado da conta.
Seu progresso fica salvo neste navegador. Concluir a leitura não substitui demonstrar o domínio nos exercícios.
Referências e aprofundamento
Documentação oficial e trabalhos originais. As referências registram o escopo e as limitações para você conferir o que sustentam.
- Develop a generative AI application
Google Cloud • consulta: 2026-10-06
IA & MLInfraestruturaDistingue aplicações generativas, foundation models e LLMs baseados em deep learning; situa treinamento, adaptação e integração.
Limites: Introdução conceitual do fornecedor; a comparação pedagógica com ML discriminativo é síntese editorial.
- Training language models to follow instructions with human feedback
Ouyang et al. / arXiv • consulta: 2026-10-06
FundamentosDiferencia modelo pré-treinado, supervised instruction tuning e pós-treinamento com feedback humano.
Limites: Estudo InstructGPT de 2022; não representa receita completa de todos os modelos atuais.
- Attention Is All You Need
Vaswani et al. / arXiv • consulta: 2026-10-06
FundamentosArquitetura Transformer e mecanismos de attention; paralelização em treinamento.
Limites: Paper original de tradução; não descreve sozinho toda arquitetura de LLMs atuais.
- Tokenization algorithms
Hugging Face • consulta: 2026-10-06
Hugging FaceTokenização, subwords e diferenças entre algoritmos de tokenização.
Limites: Ramo main; contagem e contexto máximo são específicos do tokenizer e do modelo.
- Conversation state
OpenAI • consulta: 2026-10-06
OpenAIEstado conversacional, histórico, continuidade e limites de contexto.
Limites: Estado da API não equivale automaticamente a memória longa; regras de persistência e cobrança são específicas da API.
- Vector embeddings
OpenAI • consulta: 2026-10-06
OpenAIRAGEmbeddings, similaridade, dimensionalidade e busca semântica.
Limites: Dimensões e limites dependem do modelo; não misturar vetores de modelos diferentes no mesmo espaço.
- Responses API overview
OpenAI • consulta: 2026-10-06
OpenAIAPIsInterface HTTP Responses para geração, estado, ferramentas e multimodalidade.
Limites: Documentação dinâmica; fixar a versão usada no laboratório e conferir compatibilidade antes de executar.