Mapa de IA, LLMs, Transformer, tokens
Neste laboratório, você prepara uma comparação que pode ser repetida sem confundir operações. O primeiro artefato é um conjunto de casos de suporte com expectativas escritas antes de observar modelos. O segundo é um registro com campos suficientes para distinguir o que foi executado, o que foi medido e o que ainda depende de acesso a um provedor.
Você pode concluir a etapa local apenas com Node.js. A etapa com três modelos exige acesso autorizado e documentação da configuração usada. Se esse acesso estiver indisponível, entregue o contrato e marque a comparação externa como pendente; executar o organizador local não é executar inferência.
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: Leitura: Mapa de IA, LLMs, Transformer, tokens
Separar operações antes de experimentar
FundamentosComece pelo pedido de pagamento sem acesso e desenhe quatro caixas: receber mensagem, consultar estado, recuperar política e redigir resposta. Não escreva ainda o prompt. Em cada caixa, anote entrada, saída e quem possui autoridade para confirmar o resultado. A mensagem do cliente informa uma alegação; a consulta autorizada informa o estado cadastrado. A busca pode localizar uma política de ativação; a geração transforma essas informações em linguagem. Essa preparação retoma a diferença entre tarefa discriminativa e generativa sem tratar todas as caixas como chatbot. Acrescente um caso em que o cliente cita um pagamento de outra pessoa. Ele mostra que a consulta precisa de escopo, mesmo quando o pedido é educado e parece completo.
Construir o registro de execução
FundamentosExecute o organizador local e confira que tokenização, embedding e geração estão marcados como não realizados. Depois acrescente campos de identificador do caso, versão da rubrica e origem da evidência. Não preencha consumo usando número de palavras: registre o contador reportado pelo serviço ou o tokenizador efetivamente escolhido. Para cada modelo, preserve configuração e entrada final, incluindo instruções acrescentadas pelo adaptador. Uma resposta isolada não permite repetir o experimento. Se não houver acesso a três modelos, mantenha registros preparados e marque a integração pendente. Esse artefato ainda é útil porque demonstra o contrato, mas não deve aparecer no relatório como comparação concluída.
Tentar, avaliar e diagnosticar
FundamentosAntes de ler a resolução, escreva sua própria resposta para o caso sem consulta. Ela deve reconhecer a falta de confirmação e indicar uma próxima etapa autorizada. Avalie os modelos com três critérios separados: não inventar estado, preservar o pedido e explicar o próximo passo. Uma resposta cordial que afirma acesso liberado falha no primeiro critério. Observe também quando o modelo confunde a política encontrada com o estado da conta. Classifique cada erro pela operação envolvida: recuperação, consulta, montagem de contexto ou redação. Esse diagnóstico orienta a intervenção seguinte e impede trocar de modelo para compensar uma consulta que nunca aconteceu.
Comparar opções e concluir o relatório
FundamentosCompare as três opções somente nas tarefas executadas com entradas equivalentes. Registre situações em que cada uma falhou e dados que ainda faltam para decidir. Um embedding de boa proximidade pode ajudar a buscar políticas, mas a rubrica final precisa de evidência correta. Discuta o compromisso entre uma resposta automática e encaminhamento para revisão: encaminhar reduz automação, mas pode ser a decisão adequada quando falta identidade ou confirmação. Feche com uma tabela de caso, evidência, saída, julgamento e justificativa. Outra pessoa deve conseguir verificar sua conclusão usando os registros, sem depender de uma impressão sobre qual modelo pareceu mais inteligente.
Execução, inspeção e diagnóstico
FundamentosSalve o exemplo como experimento.mjs e execute node experimento.mjs. Inspecione se o registro pode ser entendido sem lembrar da conversa. Crie outros dois pedidos: um com informação suficiente e outro com duas interpretações possíveis. Para cada pedido, escreva a evidência necessária e uma resposta inaceitável. Isso transforma o laboratório em uma avaliação de comportamento, não em uma coleção de capturas agradáveis.
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));Ao testar modelos, procure três falhas distintas: inventar um estado externo, ignorar uma restrição explícita e perder informação necessária por excesso de contexto. Não atribua automaticamente cada falha ao Transformer. Ela também pode resultar da entrada, do contrato ou da integração. O diagnóstico deve apontar a evidência que sustentou a conclusão e uma intervenção que possa ser comparada na próxima rodada.
Exercício aplicado
Construa o registro de três pedidos e, quando houver acesso, compare as mesmas entradas em três modelos com uma rubrica de suporte.
- 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: caso A tem recibo de devolução confirmado, B tem serviço indisponível e C não identifica livro. O candidato afirma 'multa cancelada' nos três. A política exige consulta do estado da multa, que não foi fornecido. Julgue cada caso e registre o experimento.
Conferir raciocínio e critérios de domínio
Nenhum caso sustenta cancelamento da multa: A confirma apenas devolução, B não confirma estado e C nem identifica empréstimo.
A permite informar devolução e consultar multa; B fica pendente e C solicita identificação segura. O candidato falha em 3/3 pelo mesmo fato inventado.
O registro descreve fixtures, política e gabaritos. Se não houve chamada ao modelo, inferência, custo e latência permanecem não medidos.
Evidências para autoavaliação ou revisão por pares
- Evidência do estado: Nenhum caso sustenta cancelamento da multa: A confirma apenas devolução, B não confirma estado e C nem identifica empréstimo.
- Decisão por caso: A permite informar devolução e consultar multa; B fica pendente e C solicita identificação segura. O candidato falha em 3/3 pelo mesmo fato inventado.
- Registro do experimento: O registro descreve fixtures, política e gabaritos. Se não houve chamada ao modelo, inferência, custo e latência permanecem não medidos.
Um erro frequente
Executar registro mede um LLM.
Um registro local organiza casos; apenas uma chamada real executa inferência.
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.