Como os LLMs funcionam

docs.scrimba.com

Primeiro, o nome. LLM é a abreviação para large language model (modelo de linguagem grande): o tipo de IA por trás de ferramentas como ChatGPT, aquela coisa para a qual você envia um prompt e recebe texto de volta. Este capítulo é a imagem funcional do que ele realmente é.

Você digita uma pergunta e alguns segundos depois uma resposta fluente e confiante aparece. Parece que o modelo entendeu você e procurou a resposta. Essa impressão é útil, e também está errada de maneiras que importam, e a lacuna entre as duas é de onde vêm a maioria dos erros de iniciantes.

Este é o capítulo que compensa o resto da sua carreira com essas ferramentas. Você não precisa conhecer a matemática por trás do treinamento de um modelo para construir com um. Você precisa de uma imagem funcional do que realmente está acontecendo quando ele responde, porque essa imagem explica tudo mais: por que o prompting funciona, por que a mesma pergunta dá respostas diferentes, por que modelos inventam fatos, por que custam o que custam, e por que algumas funcionalidades são difíceis quando parecem que deveriam ser triviais. Tudo depois neste manual é consequência das ideias aqui.

Este capítulo é o modelo mental por trás desses sistemas: o que é um modelo, o único loop que ele executa, e o punhado de propriedades que explicam o resto do manual. Nada disso é matemática. Tudo é a diferença entre codificar contra uma caixa preta e saber por que ela se comporta da forma que faz.

Toda técnica nos capítulos posteriores, prompting, saída estruturada, recuperação, agentes, é uma consequência do que você está prestes a ler. Acerte essa imagem e o resto deixa de parecer uma bolsa de truques e começa a parecer uma única máquina que você pode prever.

Esses modelos falham de maneiras específicas e repetíveis, e este capítulo explica o porquê. Retire a interface e um modelo de linguagem é uma função congelada que prediz texto um pedaço por vez, e quase todo modo de falha em produção, não-determinismo, explosões de custo, contexto perdido, respostas confiantes e erradas, tudo decorre desse fato único.

Não há matemática nova aqui, e esse é o ponto: a vantagem de engenharia durável está no mecanismo, não no modelo do mês. Leia como o substrato no qual cada decisão posterior repousa.

O que um modelo realmente é

Remova a interface de chat e um grande modelo de linguagem é uma coisa: uma função matemática enorme, um conjunto fixo de bilhões de números chamados parâmetros (você também os ouvirá chamados de pesos). Esse é o modelo inteiro. Não é um banco de dados, não é um mecanismo de busca, não é uma pessoinha em uma caixa. É um montão muito grande de números que recebe texto como entrada e produz texto como saída.

Esses números não vieram de um programador digitando-os. Eles foram definidos durante o treinamento. O provedor alimentou o modelo com uma quantidade impressionante de texto, livros, código, artigos, páginas da web, e executou um exercício simples bilhões de vezes: esconda a próxima palavra, peça ao modelo para prever, e ajuste seus números ligeiramente sempre que ele errou. Repita isso em escala enorme e os números se acomodam lentamente em valores que são bons em prever texto. É isso que é o treinamento: ajustar bilhões de controles até que a previsão fique boa.

Duas coisas seguem disso, e explicam muito do comportamento que você encontrará depois. Primeiro, o treinamento acontece uma vez, antecipadamente, e é enormemente caro. Quando você chama o modelo, os números estão congelados. O modelo não aprende com sua conversa. Nada do que você diz muda seus parâmetros. Parece que ele se lembra e se adapta, mas essa é a software ao redor, não o modelo em si, um ponto que volta com força na seção sobre a janela de contexto.

Segundo, não há tabela de fatos dentro dele. O "conhecimento" existe como padrões incorporados nesses números, como um padeiro que fez dez mil pães tem a técnica nas mãos sem ler uma receita. O modelo aprendeu a forma do texto correto e sensato. É por isso que pode ser fluente e errado na mesma frase: está reproduzindo a forma de uma boa resposta, não lendo um fato armazenado de uma prateleira.

JunoO que um modelo realmente é Então um modelo é um montão enorme de números fixos que transforma texto em texto, e esses números foram ajustados uma vez durante o treinamento e depois congelados. Ele não aprende com você enquanto você bate papo, e não tem uma tabela elegante de fatos dentro, tem padrões. É por isso que pode soar confiante e ainda estar errado, então sempre verifique qualquer coisa que importe.

Um modelo é uma função pura: você o alimenta com (pesos, entrada) e ele computa uma saída, nada mais. Os pesos são os bilhões de números aprendidos fixados durante o treinamento; a entrada é o texto que você envia. Como é uma função, a mesma entrada sob as mesmas configurações produz os mesmos scores subjacentes toda vez. Qualquer variação que você veja entre as execuções vem da etapa de amostragem que escolhe palavras desses scores, não do modelo mudando de ideia.

O conhecimento que essa função carrega é armazenado de forma com perdas, espalhado e comprimido entre os pesos tudo de uma vez, não arquivado como registros recuperáveis. Não há linha que você possa ler, nenhuma célula que você possa editar. Um fato que o modelo "conhece" é realmente um padrão forte que os pesos reconstroem sob demanda, e às vezes reconstroem um pouco errado. Você não pode apontar para onde um fato vive, e não pode corrigir um fato sem retreinar.

O movimento prático é tratar o modelo como uma função fixa que você chama, não como uma base de conhecimento que você consulta. Confie nele para moldar linguagem, raciocinar sobre texto e seguir instruções. Quando você precisa de algo específico, atual ou auditável, coloque essas informações na entrada você mesmo em vez de confiar que os pesos o retenham. Esse único hábito, fornecer os fatos em vez de esperá-los, previne uma grande parte das respostas confiantes e erradas.

JunoO que um modelo realmente é Pense no modelo como uma função pura de pesos e entrada: mesma entrada, mesmas configurações, mesmos scores subjacentes, com variação entre execuções vindo da amostragem. Seu conhecimento é comprimido com perdas entre os pesos, então você não pode procurar ou editar um único fato ali. Construa de acordo: trate como uma função fixa que você chama, e alimente fatos específicos ou atuais através da entrada em vez de esperar que os pesos os lembrem.

Um modelo implementado é pesos congelados atrás de uma API: bilhões de números aprendidos, fixados no momento do treinamento, computando uma função pura de (pesos, entrada). A única vez que seu comportamento realmente muda é quando o provedor envia um modelo diferente.

Isso tem uma borda operacional afiada. Uma atualização silenciosa sob o mesmo endpoint pode deslocar suas saídas sem uma única linha do seu código mudar, então fixe uma versão específica do modelo, trate essa versão como parte do seu contrato, e execute novamente seus evals antes de adotar uma nova. Adotar "a mais recente" na confiança é como um sistema funcionando quietly se degrada.

Os pesos são memória paramétrica comprimida, e é tanto com perdas quanto inauditável. Você não pode fazer diff do que um modelo "conhece" entre versões, não pode enumerar seus fatos, e não pode provar que um dado fato está ali ou está correto. Então nunca coloque a correção de um fato de carga em recall paramétrico. Se uma resposta errada lhe custaria, forneça o fato na entrada de uma fonte que você controla e pode citar, e mantenha o modelo no papel de formular e raciocinar sobre essa fonte, não sendo a fonte.

Mudar deliberadamente os pesos é o que fine-tuning faz, e vale a pena ser claro sobre o que isso compra. Fine-tuning relievelmente desloca comportamento e forma, tom, formato, hábitos de tarefa, mas não oferece um armazenamento confiável e consultável de fatos. Alcance isso para moldar como o modelo responde, não para instalar conhecimento no qual você precisa confiar. Mantenha fatos na entrada, mantenha estilo nos pesos, e você não será surpreendido por nenhum dos dois.

JunoO que um modelo realmente é Os pesos estão congelados, então o comportamento só se move quando o provedor envia um modelo diferente: fixe a versão, torne-a parte do seu contrato, e execute novamente os evals antes de atualizar ou uma troca silenciosa irá degradá-lo enquanto você dorme. A memória paramétrica é com perdas e inauditável; você não pode fazer diff do que ela sabe, então mantenha fatos de carga na entrada de uma fonte que você controla, não em recall. E fine-tuning desloca comportamento e forma, não um armazenamento confiável de fatos, então use-o para como o modelo responde, não para o que ele deveria saber.

Prevendo o próximo token

Com esse montão de números no lugar, o modelo faz exatamente um trabalho: ele prediz o próximo pedaço de texto, repetidas vezes.

Aqui está o loop em câmera lenta. Você o alimenta com algum texto. Ele executa esse texto através de todos esses parâmetros e produz uma probabilidade para cada possível próximo pedaço que ele conhece, dezenas de milhares de opções de uma vez. Depois de "A capital da França é", o pedaço "Paris" pode receber uma pontuação de 97%, "a" uma pontuação de 1%, e tudo mais quase nada.

O modelo então escolhe um pedaço, o adiciona ao texto, e executa tudo de novo para escolher o próximo. Ele repete até a resposta estar pronta.

Esse é o mecanismo inteiro. Uma resposta que você lê como um único pensamento foi construída um pedaço por vez, cada pedaço escolhido de uma classificação fresca de probabilidades, sem plano para onde a frase vai além de "o que é provável depois". Toda capacidade que você usará, chat, código, tradução, uso de ferramentas, raciocínio, é esse mesmo loop executando por baixo.

O teclado do telefone que sugere sua próxima palavra é a mesma ideia em miniatura. A diferença é os bilhões de parâmetros por trás da sugestão. Treinado em texto suficiente, "qual é o próximo pedaço mais provável" acaba sendo bom o suficiente para escrever código que funciona e explicações claras. Mas o movimento subjacente nunca muda: é previsão, não compreensão, e não procurar uma resposta armazenada.

JunoPrevendo o próximo token O mecanismo inteiro é um loop pequeno: leia o texto até agora, classifique cada próximo pedaço possível, escolha um, e vá novamente até a resposta estar pronta. O modelo não tem plano para a frase além do que é provável depois, então uma resposta que você lê como um único pensamento foi na verdade construída um pedaço por vez. Isso é previsão, não compreensão, e não uma resposta armazenada sendo procurada.

O modelo faz uma coisa repetidas vezes: em cada etapa ele lê todo o texto até agora e emite uma pontuação para cada token (um token é um pedaço de texto, geralmente parte de uma palavra) em seu vocabulário, dezenas de milhares de uma vez. Essas pontuações se tornam uma distribuição de probabilidade, e o modelo amostra um token dela. Então ele acrescenta esse token ao texto e executa tudo de novo para escolher o próximo. Depois de "A capital da França é", "Paris" pode manter quase toda a probabilidade e tudo mais quase nada.

Essa realimentação é por que é chamado de autorregressivo: cada novo token depende de todo o texto até agora, incluindo os tokens que ele já escreveu nesta volta. Não há plano global e nenhum rascunho para revisar. O modelo se compromete um token por vez, e como não pode recuperar um token, pode se pintar em um canto: uma palavra inicial confiante pode forçar o resto da frase para baixo de um caminho desconfortável que ela então tem que terminar.

Esse fato único explica algumas coisas que você usará na prática. Deixar o modelo escrever seu raciocínio antes da resposta final ajuda, porque mais tokens significam mais passos e mais computação gasta no problema antes de se comprometer com uma resposta. A estrutura de saída é decidida estritamente da esquerda para a direita, então a forma de uma resposta é definida conforme avança, não planejada antecipadamente. E o mesmo loop é o que impulsiona o uso de ferramentas: o modelo prediz os tokens que formam uma chamada, você a executa, e o resultado é realimentado como mais texto para a próxima previsão.

JunoPrevendo o próximo token Em cada etapa o modelo classifica cada token em seu vocabulário, amostra um, o realimenta e repete: esse loop de realimentação é o que autorregressivo significa. Não há plano e nenhum desfazer, então ele se compromete token por token e pode se pintar em um canto. É por isso que escrever raciocínio antes da resposta ajuda, e por que o uso de ferramentas é o mesmo loop com um resultado realimentado.

A geração é sequencial por construção: o modelo produz um token (um pedaço de texto), o realimenta e prediz o próximo, então cada token de saída é um passe direto separado através da rede. Ler sua entrada é comparativamente barato, processado de uma vez; a parte lenta e cara é o modelo escrevendo. Latência e custo escalam com o comprimento da saída, não com o comprimento da entrada. As alavancas práticas caem disso: mantenha as saídas curtas, transmita tokens para que o usuário veja o progresso em vez de esperar pela resposta completa, e não pague por formatação verbosa que você descartará.

A outra consequência é a correção. Porque não há um plano global, um passe único não é auto-corretivo: o modelo se compromete da esquerda para a direita e não pode revisar um token uma vez que sai. É por isso que qualquer coisa que tenha que estar correta quer verificação ou um segundo passe no primeiro rascunho, e por que um modelo que escreve seu raciocínio antes da resposta tende a fazer melhor, você está lhe comprando mais passos para se comprometer. Trate a primeira geração como um rascunho, não um veredicto.

Uma alavanca que vale a pena cabear: muitas configurações expõem probabilidades por token (logprobs, a pontuação de confiança do próprio modelo para cada token que escolheu). Você pode lê-las para sinalizar períodos de baixa confiança, gating uma resposta que o modelo não tinha certeza, ou rotear casos incertos para um segundo passe ou um humano. É um sinal barato que você já tem, e transforma "o modelo pode estar errado aqui" em algo no qual você pode agir programaticamente em vez de adivinhar.

JunoPrevendo o próximo token Cada token de saída é seu próprio passe direto, então custo e latência acompanham o comprimento da saída, não da entrada: mantenha respostas curtas, transmita-as, e pare de pagar por formatação que você descarta. Não há plano e nenhum desfazer, então um passe não se autocorrige; trate a primeira geração como um rascunho e adicione um passe de verificação para qualquer coisa que tenha que estar correta. Se você conseguir ler logprobs por token, use-os para sinalizar ou rotear os períodos sobre os quais o modelo tinha menos certeza, é confiança que você já tem e raramente gasta.

O controle de aleatoriedade

Se o modelo sempre pegasse o pedaço de maior pontuação individual, ele lhe daria a mesma resposta para o mesmo prompt todas as vezes, e essa resposta geralmente seria plana e repetitiva. Então a maioria das vezes a escolha tem um pouco de aleatoriedade nela: geralmente leva um pedaço de alta probabilidade, mas nem sempre o muito topo. É por isso que você pode fazer a mesma pergunta duas vezes e receber duas respostas diferentes. Esse é o sistema funcionando conforme projetado, não uma falha.

Você controla quanto de aleatoriedade através de uma configuração chamada temperatura, que você define quando chama o modelo no capítulo sobre chamando modelos do código. A intuição vale a pena ter agora. Em uma temperatura baixa, o modelo fica próximo de seus melhores escolhas: focado, consistente, previsível, que é o que você quer para tirar um número de uma fatura ou classificar texto em categorias. Em uma temperatura mais alta, pedaços de menor probabilidade são escolhidos com mais frequência: mais variado e criativo, e mais propenso a vagar para algum lugar errado. Brainstorming e escrita criativa querem o final mais alto; qualquer coisa com uma resposta correta quer o final mais baixo.

Então um único controle desliza o modelo entre "cuidadoso e repetível" e "surpreendente e inventivo". É o mesmo loop de previsão de qualquer forma; a temperatura apenas muda como ousadamente o modelo alcança além de sua suposição mais segura.

JunoO controle de aleatoriedade Temperatura é seu controle de aleatoriedade. Baixe para tarefas com uma resposta correta, como extração ou classificação, e você obtém respostas focadas e repetíveis. Aumente para brainstorming e trabalho criativo, e você obtém mais variedade junto com mais chances de vagar para longe. Mesmo loop de previsão, apenas um alcance mais ousado ou mais seguro.

Antes de o modelo escolher seu próximo pedaço, ele tem uma probabilidade para cada candidato. Temperatura reformula essa distribuição antes que o modelo a amostre. Uma temperatura baixa afila a distribuição em direção ao token mais provável único (mais próximo de sempre pegar a escolha principal), então a saída fica focada e repetível. Uma temperatura alta a achata, dando aos tokens menos prováveis uma chance real, então a saída fica mais variada e mais provável de desviar para o lado errado. É por isso que o mesmo prompt pode retornar respostas diferentes: há um sorteio acontecendo, e a temperatura define como tendenciosas as probabilidades são.

Temperatura não é o único botão aqui. Top-p (amostra apenas do menor conjunto de tokens cujas probabilidades somam p) e top-k (apenas os k tokens mais prováveis) ambos aparelham o grupo de candidatos antes da amostragem. Eles se sobrepõem com a temperatura em efeito, então ajuda pensar neles como uma configuração de aleatoriedade em vez de três independentes.

O movimento prático é definir a temperatura explicitamente por tarefa em vez de confiar em qualquer padrão que os envios. Vá baixo para extração, classificação, e qualquer coisa que emita saída estruturada que você analisará depois; vá mais alto para ideação e rascunho onde a variedade é o ponto. Observe as interações: empilhar uma temperatura alta com um top-p de 1 deixa a cauda completa em jogo, o que funciona contra você quando você precisa de resultados confiáveis e analisáveis.

JunoO controle de aleatoriedade Temperatura reformula a distribuição de probabilidade antes da amostragem: baixo a afila em direção ao token principal para saída focada, alto a achata para variedade. Trate temperatura, top_p e top_k como uma configuração de aleatoriedade, não três. Defina por tarefa: baixo para extração, classificação e saída estruturada; mais alto para ideação. Não emparelhe uma temperatura alta com top_p de 1 quando você precisa de resultados analisáveis.

Temperatura escala a distribuição de pontuação antes da amostragem, e o atalho tentador é defini-la para 0 e chamar a saída de determinística. É perto, mas não é uma garantia. Matemática de ponto flutuante, batching do lado do servidor e roteamento dentro de modelos grandes todos introduzem pequeno não-determinismo mesmo em 0. Então não construa cache de correspondência exata ou testes de correspondência exata que assumem saída idêntica ao byte para um prompt repetido; essa suposição falha intermitentemente, e falhas intermitentes são o tipo caro de perseguir.

Isso molda como você testa comportamento amostrado. Uma única execução diz quase nada sobre um sistema estocástico (um cuja saída varia de execução em execução), então avalie um prompt executando-o várias vezes e olhando para a distribuição de saídas: quantas vezes cai em especificação, qual é a largura da variância, para onde cauda vai errada. Esse é o trabalho que seus evals fazem, e eles querem amostras suficientes para ver o spread, não um passe de sorte.

Trate temperatura, top-p (amostra apenas do menor conjunto de tokens cujas probabilidades alcançam um p cumulativo) e top-k (mantenha apenas os k tokens mais prováveis) como um orçamento de amostragem que você ajusta junto em vez de três controles que você define por reflexo. Escolha a aleatoriedade mais baixa que ainda dá variedade aceitável para a tarefa: apertar todos os três de uma vez pode colapsar a saída em algo repetitivo e frágil, enquanto deixá-los todos abertos lhe dá variância que você então tem que validar em torno. O custo é real nos dois lados, então gaste deliberadamente.

JunoO controle de aleatoriedade Temperatura 0 é quase determinística, não garantida: ponto flutuante, batching e roteamento interno vazam não-determinismo, então pule cache de correspondência exata e testes de correspondência exata. Avalie o comportamento amostrado ao longo de várias execuções e leia a distribuição, não um passe; isso é para o qual seus evals servem. Ajuste temperatura, top_p e top_k como um orçamento de amostragem, e escolha a aleatoriedade mais baixa que ainda dá variedade aceitável.

Tokens

Os "pedaços" que um modelo prediz têm um nome: tokens. Um token é um pedaço de texto, geralmente uma palavra inteira, às vezes apenas parte de uma.

"tokenização"  ->  "token" + "ização"
"inacreditável"  ->  "ina" + "credit" + "ável"
"gato"           ->  "gato"

Por que cortar texto em esses pedaços estranhos em vez de usar palavras inteiras ou letras individuais? É um trade-off. Letras individuais tornariam cada sequência enormemente longa, e o comprimento é o que o modelo tem que computar. Palavras inteiras precisariam de um vocabulário de milhões de entradas e ainda assim quebraria na primeira vez que alguém inventar uma palavra ou cometer um erro de digitação. Tokens são o caminho do meio: um vocabulário fixo de alguns poucos dezenas de milhares de pedaços comuns que podem ser encaixados para soletrar qualquer coisa, incluindo palavras que o modelo nunca viu.

Aqui está a consequência sob o capô que surpreende as pessoas. O modelo nunca vê letras. Ele vê tokens, que para ele são realmente números de ID para esses pedaços. Então tarefas que parecem effortless para nós podem ser difíceis para ele: contar as letras em uma palavra, reverter uma string, notar que "morango" tem três r's.

Não é ser fraco. Ele não percebe os caracteres individuais, como você não consegue sentir os grãos separados de farinha em um bolo pronto. Quando um modelo tropeça em uma tarefa de ortografia ou contagem de caracteres, é por isso, e a correção geralmente é fazer essa parte em código normal em vez disso.

Tokens também são a unidade de duas coisas que você se importará constantemente:

• Dinheiro: provedores cobram por token, tanto os tokens que você envia quanto os tokens que o modelo escreve de volta, então um documento longo e uma resposta longa também custam mais. Uma medida aproximada para inglês é cerca de quatro caracteres por token, ou 100 tokens para cada 75 palavras; código e outras linguagens geralmente se dividem em mais tokens, que é parte do porque podem custar mais. Você vai conhecer isso diretamente quando começar chamando modelos do código.
• Limites: há um teto em quantos tokens o modelo pode manipular de uma vez, que é a próxima seção.

JunoTokens Um token é um pedaço de texto, geralmente uma palavra ou parte de uma, e o modelo lê esses pedaços como números de ID, não como letras. É por isso que pode tropeçar em contagem ou ortografia, então deixe esse trabalho para código simples. E desde que você pague por token em ambas as direções e haja um teto em quantos cabem de uma vez, menos tokens significa menos custo e mais espaço.

O modelo prediz tokens, pedaços de texto que geralmente são uma palavra inteira e às vezes um fragmento. A peça que faz a divisão é o tokenizador, e ele funciona fora de um vocabulário aprendido construído pela fusão repetida dos pares de caracteres mais comuns até você ter um conjunto fixo de alguns poucos dezenas de milhares de pedaços (um esquema geralmente chamado de codificação de par de bytes, ou BPE). Esse histórico é por que palavras frequentes acabam como um token único enquanto as raras se fragmentam em partes: os padrões comuns foram fundidos durante o treinamento, os incomuns nunca foram.

Dois fatos práticos caem disso. Primeiro, o modelo nunca lida com caracteres, apenas IDs de token, então qualquer operação de nível de caractere (contar letras, reverter uma string, cortar em uma posição exata) é instável dentro de um prompt e confiável no seu próprio código. Empurre esse trabalho para o código e deixe o modelo fazer a parte de linguagem. Segundo, a tokenização é específica do modelo, então as contagens de token não são portáveis. A mesma frase pode custar um número diferente de tokens em um tokenizador diferente, o que importa no momento em que você orça custo ou encaixa conteúdo em uma janela.

O takeaway para construir: não estime contagens de token a partir do comprimento do caractere. Conte com o tokenizador real que o modelo usa, porque esse é o número pelo qual você é cobrado e limitado. Você conhece tudo disso concretamente quando começa chamando modelos do código, onde a contagem que você envia mais a contagem que você recebe de volta é a conta.

JunoTokens Um tokenizador divide o texto usando um vocabulário aprendido (BPE), que é por que palavras comuns são um token e as raras se fragmentam. A tokenização é específica do modelo, então conte com o tokenizador próprio do modelo em vez de adivinhar a partir de caracteres. E mantenha trabalho de nível de caractere (contagem, reversão, corte exato) no seu código, não no prompt.

Tokens são o medidor em tudo que você envia. Um token é um pedaço de texto do vocabulário aprendido do tokenizador, e a conta por token mais o teto de contexto fixo são os dois números que moldam seu custo e seu design. A regra de ouro reconfortante de quatro caracteres por token vale para prosa inglesa simples e desmorona exatamente onde a produção vive: código, JSON, formatação profundamente aninhada, e scripts não-latinos todos se fragmentam em muito mais tokens que a heurística prediz. Então orça com o tokenizador real, não o indicador, ou suas estimativas de custo e capacidade estarão erradas precisamente nas cargas que você realmente envia.

A fragmentação não é distribuída uniformemente, e isso é um problema de justiça e custo em escala. O mesmo significado em uma linguagem não-latina pode custar vários vezes os tokens da sua versão inglesa, então o mesmo recurso é silenciosamente mais caro, e mais lento, para alguns de seus usuários do que para outros. Vale a pena medir por linguagem antes de prometer a alguém um preço fixo ou uma latência fixa.

Dois mais hábitos do campo. Formato é gasto: espaço em branco, delimitadores verbosos, e markdown decorativo tudo custa tokens para zero significado adicionado, então mantenha a estrutura que você alimenta o modelo compacta e deixe seu código adicionar apresentação depois. E alimente texto limpo e normal, porque tokens raros ou malformados (mojibake, caracteres de controle à toa, codificações estranhas) ficam nos cantos finos e subtreinados do vocabulário e podem desencadear saída estranha. Nada disso é exótico; é a diferença entre um orçamento de token que você confia e um que o surpreende na fatura.

JunoTokens A regra de quatro caracteres por token quebra em código, JSON, e scripts não-latinos, que é onde seu tráfego real vive, então orça com o tokenizador real. Linguagens não-latinas podem custar vários vezes mais tokens para o mesmo significado, uma verdadeira lacuna de custo e justiça que vale a pena medir por linguagem. Retire formatação decorativa para economizar tokens, e alimente texto limpo para que tokens raros ou malformados não lhe comprem comportamento estranho.

A janela de contexto

A janela de contexto é quanto texto o modelo pode receber de uma vez, medido em tokens. Imagine-o como o tamanho da mesa do modelo. Tudo envolvido em uma única solicitação tem que caber nessa mesa de uma vez: suas instruções, a conversa até agora, qualquer documento que você colou, e a resposta que o modelo está escrevendo.

Por que existe um limite? Vem de como a previsão funciona. Para escolher o próximo token, o modelo pondera como cada token na entrada se relaciona com todos os outros tokens, então pode dizer que "ele" se refere ao gato três frases atrás. Essa comparação de todos-para-todos é o que permite ao modelo rastrear significado ao longo de uma passagem, e é também o que torna as entradas longas caras de processar. O provedor define um teto, a janela de contexto, para manter cada solicitação gerenciável.

Quando a mesa fica cheia, algo tem que sair. Se uma conversa fica longa o suficiente para transbordar a janela, as partes mais antigas caem e o modelo não consegue mais vê-las. É por isso que um chat longo parece "esquecer" o que você disse no início. Ele não esqueceu em nenhum sentido humano; esses tokens estão fora da mesa. Também ajuda saber que modelos tendem a prestar atenção mais próxima ao início e ao fim do que está na mesa e podem perder a noção das coisas enterradas no meio, então onde você coloca texto importante importa quando você preenche a janela.

Agora o ponto que pega quase todo iniciante, e importa mais do que todo o resto. O modelo não tem memória entre solicitações separadas. Lembre que seus números estão congelados. Cada chamada começa com uma mesa em branco. O modelo não se lembra da sua pergunta anterior, seu nome, ou qualquer coisa de um minuto atrás.

Um app de chat parece uma conversa fluente apenas porque o app silenciosamente reenvia o histórico inteiro com cada nova mensagem. A continuidade é algo que o software ao redor do modelo constrói, não algo que o modelo tem.

Esse fato único molda como você construir tudo a partir daqui. Se você quer que o modelo saiba algo, você tem que colocá-lo na mesa nessa solicitação: a conversa até agora, os detalhes do usuário, os documentos relevantes, tudo, toda vez. Uma grande parte deste manual é realmente sobre fazer esse um coisa bem, colocar o texto correto na mesa.

JunoA janela de contexto A janela de contexto é a mesa do modelo: toda solicitação tem que caber nela, e quando transbordar o texto mais antigo desaparece. O modelo não mantém memória entre chamadas, então o app reenvia o histórico inteiro toda vez para fingir um chat contínuo. Seu trabalho a partir daqui é colocar o texto correto naquela mesa em toda solicitação.

Pense na janela de contexto como um orçamento fixo de tokens que uma solicitação gasta, cobrindo suas instruções, a conversa em execução, qualquer documento colado, e a resposta sendo gerada. A janela existe por causa de como o modelo lê entrada: um mecanismo chamado atenção compara cada token contra cada outro token para determinar o que se relaciona com o que. Essa comparação é o que permite ao modelo resolver um "ele" de volta para o substantivo para o qual aponta, e seu custo cresce aproximadamente com o quadrado do comprimento da entrada. Duplique os tokens e você mais que duplicou o trabalho, que é a razão real pela qual entradas longas são lentas e ficam custosas.

Encaixar-se dentro da janela não é o mesmo que o modelo usar tudo nela. Há um efeito bem documentado chamado perdido no meio: modelos atendem de forma mais confiável ao início e ao fim da entrada e podem folhear material estacionado no centro. Então coloque suas instruções e dados mais importantes perto do topo ou fundo do prompt, não enterrado em uma parede de texto colado.

A outra metade disso é memória, e o fato-chave é que o modelo é sem estado: ele não se lembra de nada entre solicitações separadas. Cada chamada começa com uma janela vazia, então a única maneira do modelo saber a conversa até agora é que você a envia de novo toda vez. Reenviar e moldar esse histórico é seu trabalho, não do modelo. Como o chat cresce além da janela, gerencie você mesmo cortando voltas antigas ou substituindo-as por um resumo curto, então os tokens que você mantém são aqueles que ainda importam.

Isso coloca construção de contexto no centro da construção com esses modelos. Decidir o que entra na janela, em que ordem, e como comprimir o que veio antes é a maioria do trabalho, e prompting é onde você aprende a moldá-lo deliberadamente.

JunoA janela de contexto A janela é um orçamento de token cobrindo instruções, histórico, documentos, e a resposta; atenção torna as entradas longas custarem aproximadamente o quadrado do seu comprimento. Modelos sofrem um efeito perdido-no-meio, então coloque o que importa perto do início ou fim. O modelo é sem estado, então reenviar e aparar o histórico da conversa é em você, toda chamada.

Trate a janela de contexto como um teto, não um alvo. É o orçamento de token que uma única solicitação tem, abrangendo suas instruções, histórico em execução, documentos recuperados, e saída.

Cada token que você coloca nela custa dinheiro e latência, porque o passo de atenção (a comparação de token de todos-para-todos que o modelo executa para ler entrada) escala aproximadamente com o quadrado do comprimento. Pior, recall efetivo degrada bem antes de você atingir o limite: o efeito perdido no meio significa precisão no material enterrado no centro cai mesmo quando tecnicamente cabe. Então curatea contexto em vez de descarregar tudo nela, e quando os dados de fonte são grandes, recupere apenas os pedaços relevantes com RAG em vez de colar o corpus inteiro.

Ordem é uma alavanca, não um detalhe. Provedores podem reusar a computação para um prefixo inalterado através de cache de prompt, onde o estado interno em cache é o cache KV, o trabalho armazenado do modelo para tokens que ele já leu. Coloque conteúdo estável primeiro (instruções do sistema, material de referência fixo) e conteúdo variável por último, e chamadas repetidas ficam mais baratas e mais rápidas porque o frente do prompt é servido a partir do cache. Reordene esse prefixo descuidadamente e você invalida o cache e paga preço integral de novo.

Memória entre turnos não é um recurso que o modelo tem; é uma escolha de engenharia que você faz, e cada opção falha de sua própria forma:

• Simples janelamento, mantendo as voltas mais recentes, é barato mas silenciosamente descarta fatos iniciais que o usuário ainda espera que você saiba.
• Sumarização mantém mais histórico em menos tokens mas perde detalhe e pode silenciosamente codificar seus próprios erros.
• Recuperação puxa de volta apenas o que é relevante mas depende inteiramente do seu índice retornar os pedaços corretos.

Escolha por caso de uso, e assuma que qualquer um que você escolha eventualmente superficiará a coisa errada; instrumente para isso em vez de confiar nela.

JunoA janela de contexto A janela é um teto, não um alvo: custo e latência sobem com cada token e recall apodrece antes de você atingir o limite, então curatea e confie em recuperação para qualquer coisa grande. Conteúdo estável primeiro, variável por último, para que cache de prompt (cache KV) realmente compense. Memória entre turnos é sua escolha de design entre janelamento, sumarização, e recuperação, e fui apanhado por todos os três, então instrumente o que você escolher.

O que o modelo não sabe

Todo o conhecimento de um modelo foi incorporado enquanto ele estava sendo treinado, então ele só sabe o que estava naquele dados de treinamento, e esses dados foram coletados até algum ponto de corte no passado. Dois limites caem direto disso.

Primeiro, ele não sabe nada que aconteceu depois do seu ponto de corte. Pergunte sobre as notícias da semana passada ou uma biblioteca que saiu este mês e ele não tem ideia real, embora possa felizmente produzir uma resposta plausível de qualquer forma. Segundo, nunca soube nada privado. Os docs internos da sua empresa, o histórico de pedidos de um usuário, os conteúdos da sua base de dados: nada disso estava no texto público em que treinou, então ele não pode saber, não importa como você pedir educadamente.

Há um limite mais silencioso também. O modelo geralmente não pode lhe dizer de onde algo que ele "sabe" veio, porque o conhecimento é misturado dentro dele em vez de ser arquivado como fatos separados e originários. Pode escrever você uma citação, mas está predizendo o que uma citação deve parecer, não procurando uma real.

Esta é a razão para uma técnica que você conhecerá depois chamada recuperação, ou RAG. Se você quer que um modelo responda sobre eventos recentes ou seus próprios dados privados, você não retreina. Você busca o texto relevante você mesmo e o coloca na mesa no tempo de solicitação, então o modelo tem os fatos em frente em vez de adivinhar. Um modelo é um raciocínio sobre o texto que você lhe dá muito mais do que um poço confiável de fatos específicos.

JunoO que o modelo não sabe Um modelo só sabe o que estava em seus dados de treinamento, até um ponto de corte no passado, então perde eventos recentes e qualquer coisa privada, e não consegue confiavelement dizer de onde seus fatos vieram. Quando você precisa de informação atual ou privada, não retreine: busque o texto relevante e o entregue ao modelo na solicitação. Trate o modelo como algo que raciocina sobre o que você lhe dá, não como uma memória confiável.

O conhecimento construído de um modelo, seu conhecimento paramétrico (os fatos codificados em seus pesos, os números ajustáveis definidos durante o treinamento), é congelado no ponto de corte de treinamento. Nada que tenha acontecido após essa data está ali, e nada privado nunca foi, porque os pesos foram moldados por texto público. Então memória lhe dá dois espaços previsíveis: recência, qualquer coisa após o ponto de corte, e privacidade, qualquer coisa que nunca foi em dados de treinamento público.

Esses dois espaços são realmente um espaço visto de dois lados, e eles fecham do mesmo jeito: coloque o texto necessário na solicitação. Você busca o artigo recente ou a linha de base de dados relevante você mesmo e a fornece junto com a pergunta, então o modelo lê o fato em vez de recordá-lo. Essa é a ideia central por trás de RAG, geração aumentada por recuperação, que você usará sempre que respostas devem refletir informação atual ou proprietária.

Conhecimento paramétrico também não carrega nenhuma origem anexada. Os fatos são misturados pelos pesos, não armazenados como entradas discretas com proveniência, então o modelo não consegue confiavelmente lhe dizer de onde algo veio. Uma citação que produz é gerada para parecer certa, não recuperada de um registro, que é exatamente por que fundamentar a resposta em texto que você fornece vale o esforço.

A regra prática para construir: não peça ao modelo para recordar fatos atuais ou proprietários da memória. Se um fato deve estar certo, busque-o e forneça-o, e deixe o modelo raciocinar sobre ele.

JunoO que o modelo não sabe Conhecimento paramétrico, os fatos codificados nos pesos, é congelado no ponto de corte de treinamento e não carrega nenhuma origem, então o modelo perde informação recente e privada e não consegue confiavelement citar qualquer coisa. Ambos os espaços fecham do mesmo jeito: busque o texto relevante e o coloque na solicitação, que é a ideia por trás de RAG. Como regra, não tenha o modelo recordar fatos atuais ou proprietários da memória; forneca-os e deixe-o raciocinar sobre eles.

A memória paramétrica do modelo, o conhecimento mantido em seus pesos (os números ajustáveis fixados durante o treinamento), é sem versão e inauditável. Você não consegue fazer diff, apontar para onde uma reclamação vive, ou confirmar que não deriva. Então para qualquer coisa que deve ser correta, atual, ou compatível, não confie na palavra do modelo: fundamenta a resposta em uma fonte recuperada e cite essa fonte. Trate conhecimento construído como um prior fluente, não um sistema de registro.

O ponto de corte também é mais fuzzy do que uma data única sugere. Dados de treinamento não são uniformes até essa data: material recente é mais fino e menos digerido do que o antigo e bem coberto, então fatos do pre-corte recentes são conhecidos desigualmente. Um modelo pode ser confiante e errado sobre algo de um ano antes do seu ponto de corte enquanto acerta um fato de uma década atrás, que é por que "está antes do ponto de corte?" é uma garantia mais fraca do que parece, e por que você recupera qualquer coisa que tem que estar certa.

Alcance a ferramenta certa para o espaço, porque as duas comuns não são intercambiáveis. Recuperação fornece fatos no tempo de solicitação e mantém-se atual conforme suas fontes atualizam. Fine-tuning, continuando o treinamento em seus próprios exemplos, desloca forma e comportamento, tom, formato, como o modelo segue suas convenções, e é uma maneira pobre e velha de injetar conhecimento: fatos treinados são congelados de novo, difíceis de atualizar, e ainda sem origem. Use recuperação para o que é verdadeiro, fine-tuning para como deve soar.

JunoO que o modelo não sabe Memória paramétrica é sem versão e inauditável, então para qualquer coisa que deve ser correta, atual, ou compatível, fundamenta a resposta em uma fonte recuperada e cite isso, não a palavra do modelo. Lembre que o ponto de corte é fuzzy: fatos de pre-corte recentes são conhecidos desigualmente, então recupere qualquer coisa que tem que estar certa. E combine a ferramenta ao espaço: recuperação fornece fatos, enquanto fine-tuning desloca forma e comportamento e é uma maneira velha de injetar conhecimento.

Por que modelos inventam coisas

Às vezes um modelo afirma algo falso com total confiança: uma citação que ninguém disse, uma função que não existe, uma citação para um estudo que nunca foi escrito. Isso é chamado de alucinação, e depois das últimas seções deveria parecer quase inevitável em vez de misterioso.

A razão é que o modelo não tem senso interno de "verdadeiro" versus "falso". Ele só tem "texto provável" versus "texto improvável". Na maioria das vezes esses se alinham, porque no texto que aprendeu, afirmações verdadeiras são muito mais comuns que as falsas, então a continuação provável é geralmente a correta.

Mas quando o modelo atinge um espaço, algo em que nunca treinou, ou seus dados privados que nunca poderia ter visto, ele não para e sinaliza o espaço. Ele não consegue confiavelement dizer o que não sabe. Ele faz a única coisa que sempre faz: produz a continuação mais provável de soar.

Uma resposta confiante, bem-formada, errada é geralmente exatamente o que soa mais provável. O mesmo maquinário que a torna fluente a torna fluente quando está errada.

Essa é a parte para se debruçar sobre: alucinação não é um glitch que você pode totalmente afastar pelo prompt. Você pode reduzi-lo, e capítulos posteriores mostram como. Dizer ao modelo que é permitido dizer "Eu não sei" ajuda um pouco. Pedir para ele responder apenas a partir de texto que você fornece ajuda muito mais, porque agora não há espaço para preencher a partir do treinamento congelado. Mas a tendência vem do que o modelo fundamentalmente é, uma máquina de probabilidade sem um verificador de fatos dentro, então os arranjos duráveis são estruturais: dê a ele os fatos com os quais trabalhar em vez de esperar que estivessem no seu treinamento, e verifique respostas que importam em vez de confiar nelas.

Carregue uma regra para fora deste capítulo acima de todas as outras: a confiança de um modelo lhe diz nada sobre se ele está certo. Fluência e correção são produzidas pelo mesmo processo e se separam o tempo todo. Construa como se qualquer resposta única pudesse estar errada, porque qualquer resposta única poderia.

JunoPor que modelos inventam coisas Uma alucinação é o modelo confiantemente preenchendo um espaço com texto que soa certo mas não é, porque ele só sabe "provável" e não "verdadeiro". Você pode reduzir com que frequência isso acontece, mas não consegue afastá-lo pelo prompt completamente, então o movimento seguro é entregar ao modelo os fatos que ele precisa e verificar as respostas que importam. E lembre-se do grande: um tom confiante não é prova, então nunca confie na certeza por si só.

Quando um modelo inventa uma citação, uma função, ou uma citação e a afirma com total confiança, essa é uma alucinação, e cai direto de como o modelo funciona. O modelo não tem sinal para verdade. Ele classifica continuações por "texto provável" versus "texto improvável", e na maioria das vezes provável e verdadeiro se sobrepõem porque afirmações verdadeiras dominavam seus dados de treinamento.

Alucinação dispara exatamente onde essa sobreposição se quebra: nas bordas do seu conhecimento, em tópicos raros ou de nicho, e em seus dados privados em que nunca treinou. Lá o modelo ainda produz sua continuação mais provável, e uma resposta fluente, bem-formada, errada é frequentemente o que classifica mais alto.

Então você não consegue consertar isso apenas com redação, mas você pode classificar suas mitigações por quanto realmente ajudam. A maior alavanca de longe é fundamentação: coloque os fatos reais no prompt e diga ao modelo para responder apenas a partir daquele texto fornecido, idealmente citando-o. Agora não há espaço para ele preencher a partir do treinamento congelado. Recuperar o texto correto para fornecer é sua própria técnica, coberta em RAG.

Abaixo disso, dê ao modelo uma saída explícita, permissão para responder "Eu não sei" em vez de adivinhar, o que remove um pouco da pressão para inventar. E mantenha temperatura (o controle de aleatoriedade na seleção de token) modesto para trabalho factual, já que aleatoriedade alta amplia a porta para continuações improvável e fora de base.

A consequência prática: constrain o modelo para contexto que você fornece, e verifique saídas que importam. Trate redação de prompt como um pequeno ajuste em cima desses movimentos estruturais, nunca como toda a defesa. Um modelo que soa certo não lhe disse nada sobre se está correto, porque fluência e correção vêm do mesmo processo e rotineiramente divergem.

JunoPor que modelos inventam coisas Alucinação é o modelo emitindo texto fluente, provável com nenhum controle interno para verdade, e fica pior nas bordas do seu conhecimento e em dados que nunca viu. Classificar suas correções por impacto: fundamenta em texto que você fornece (a maior alavanca), dê a ele espaço para dizer "I don't know", diga a ele para responder apenas a partir do contexto fornecido e citar, e mantenha temperatura modesto para trabalho factual. Constrain para contexto e verifique as saídas que importam; não confie em truques de redação sozinho.

Alucinação é o modelo retornando texto confiante, bem-formado que por acaso é falso, e é uma propriedade da arquitetura, não um bug que você conserta. O modelo classifica continuações por probabilidade sem sinal de verdade anexado, então nas bordas do seu treinamento, tópicos raros, eventos novos, qualquer coisa privada, ele ainda emite seu palpite mais provável. Você não eliminará isso. O trabalho é desenhar o sistema para que uma resposta errada seja capturada ou contida antes de alcançar qualquer coisa que importa.

Isso significa três movimentos estruturais, nenhum deles redação de prompt. Valida a forma de cada resposta: faça o modelo retornar dados contra um schema para que saída malformada ou fora de intervalo falhe ruidosamente em vez de fluir para baixo, que é o que saída estruturada lhe compra. Meça sua taxa de alucinação real com evals, um conjunto separado de entradas com respostas conhecidas boas marcadas automaticamente, em vez de spot-checar alguns prompts e chamá-lo de bom. E mantenha um humano no loop onde quer que o custo de estar errado é alto, porque nenhuma proteção automatizada pega tudo.

A armadilha por baixo de tudo disso é calibração. Confiança do modelo é pobremente calibrada: certeza afirmada não é prova de correção, e o tom de uma resposta não carrega nenhuma informação sobre seu valor de verdade. Então nunca gat uma decisão no modelo parecendo certo.

Construa e prefira um caminho de abstém, um "Eu não consigo responder isso a partir do que me foi dado" sancionado, e faça abster barato para que o sistema alcance por ele em vez de inventar. Essa mentalidade estrutural, assuma qualquer resposta única pode estar errada e contenha o dano, é o que o capítulo inteiro segurança e limites é construído em cima.

JunoPor que modelos inventam coisas Você não consegue deletar alucinação, então engenharia para contenção: valida estrutura com schemas, meça a taxa com evals em vez de olhar alguns itens, e mantenha um humano onde estar errado é caro. Confiança do modelo é mal calibrada, então um tom certo não é prova e você nunca gat nela. Dê ao sistema um caminho barato, sancionado para abster, e prefira-o a um palpite confiante toda vez.

Colocando junto

Tudo neste capítulo é uma ideia vista de diferentes ângulos. Um modelo é um montão fixo de números que prediz o próximo token, e quase todo comportamento com o qual você lidará cai disso:

• Ele prediz um token por vez a partir de uma classificação de probabilidades, então ele improvisa em vez de recordar, e um toque de aleatoriedade (temperatura) significa respostas variam.
• Tokens são os pedaços com os quais trabalha: a unidade da sua conta, a unidade do seu limite de tamanho, e a razão pela qual não consegue confiavelement contar letras.
• A janela de contexto é a mesa de uma única solicitação, compartilhada por tudo, e o modelo não se lembra de nada entre solicitações, então continuidade é seu trabalho.
• Seu conhecimento é congelado em um ponto de corte de treinamento e nunca incluiu seus dados privados, que é por que você busca fatos e os coloca no prompt.
• Alucinação é o preço de um sistema que prediz texto provável sem senso de verdade, reduzido por fundamentação e verificação, nunca apenas por redação inteligente.

Mantenha isso junto e uma quantidade surpreendente de engenharia de IA acaba sendo uma tarefa em diferentes fantasias: colocar o texto correto na mesa, na forma certa, no momento certo, e nunca confiar cegamente na saída. O próximo capítulo, Modelos abertos e fechados, olha que tipos de modelos existem e como você consegue um, e então prompting é onde você começa a dirigir toda essa previsão para o que você realmente quer.

JunoColocando junto Quase tudo sobre um modelo segue de um fato: é um conjunto congelado de números predizendo o próximo token. Disso vêm respostas variadas, custo baseado em token e limites, nenhuma memória entre solicitações, um ponto de corte de treinamento, e alucinação. Muito de construir com esses modelos é colocar o texto correto na mesa e nunca confiar cegamente na saída.

Um fato gera o capítulo inteiro: um modelo é uma função congelada que prediz o próximo token a partir de uma distribuição de probabilidade. Rastreie as consequências e você tem seu modelo de trabalho:

• Previsão mais amostragem significa que a saída varia; temperatura define quanto.
• Tokens são a unidade de custo, a unidade do limite, e por que tarefas de nível de caractere pertencem ao código.
• A janela de contexto é finita e sem estado, então você reenvia e curatea tudo que o modelo precisa.
• Conhecimento é congelado em um ponto de corte e sem origem, então fatos atuais e privados vêm de recuperação, não recall.
• Alucinação é estrutural, reduzida por fundamentação e verificação, não por redação.

O padrão por baixo disso tudo é o mesmo: coloque o texto correto no contexto, na forma certa, no momento certo, e verifique o que volta. É o que o resto do manual constrói, começando com a paisagem de modelos abertos e fechados e depois prompting.

JunoColocando junto O capítulo inteiro é um fato e suas consequências: um previsor de próximo-token congelado lhe dá saída variada, custo baseado em token e limites, estatelessness, um ponto de corte de conhecimento, e alucinação. O trabalho que segue é constante: coloque o texto correto no contexto na forma certa, depois verifique o que volta. Prompting é onde você começa a fazer isso.

Tudo aqui se reduz a uma sentença: uma função congelada prediz o próximo token sobre o texto que você fornece, sem estado, sem sinal de verdade, e sem plano. Toda propriedade de produção que você gerencia é um corolário:

• Saída é estocástica, então você testa distribuições, não execuções únicas.
• Custo e latência rastreiam tokens, especialmente saída, então você orça e transmite.
• Contexto é finito e sem estado, então memória é uma escolha de engenharia com modos de falha.
• Conhecimento paramétrico é congelado, com perdas, e sem origem, então qualquer coisa de carga fica fundamentada e citada.
• Confiança é mal calibrada, então você verifica em vez de confiar.

O benefício é que nada disso se move quando o modelo faz. Fixe uma versão, construa o aparelho ao redor dos modos de falha, e a próxima versão é uma atualização que você avalia, não uma surpresa que você absorve. O resto do manual é aquele aparelho, e começa com a paisagem, modelos abertos e fechados, depois prompting.

JunoColocando junto Uma sentença executa o capítulo: um previsor de próximo-token congelado e sem estado com sem sinal de verdade. Saída estocástica, custo direcionado por token, contexto finito, conhecimento congelado, e confiança mal calibrada são todos corolários, e seu aparelho existe para conter cada um. O lado positivo é que ele não se move quando o modelo faz, então fixe uma versão e construa ao redor dos modos de falha.