 |
| Bellacosa Mainframe o macaco infinito encontra o llm |
☕ Um Café no Bellacosa Mainframe
O Macaco Infinito encontra o LLM: por que o ChatGPT não está simplesmente sorteando palavras até aparecer Shakespeare
🐒 Tokens, probabilidade, temperatura, entropia, Markov, brute force, atenção e o dia em que descobrimos que “prever a próxima palavra” esconde um monstro matemático
Existe uma frase sobre inteligência artificial que parece muito inteligente durante aproximadamente trinta segundos:
“Esses modelos só ficam escolhendo a próxima palavra provável.”
Tecnicamente, existe alguma verdade nela.
O problema começa quando o “só” entra na sala.
É como dizer:
“Um mainframe só move elétrons.”
Correto.
Absolutamente inútil.
Ou:
“Um Boeing só empurra ar para baixo.”
Também correto.
Tente explicar assim ao passageiro sentado na poltrona 17A durante uma turbulência.
Depois da nossa aventura com Émile Borel, os macacos infinitos e Shakespeare, surge uma pergunta irresistível:
Se o macaco ficava apertando teclas aleatoriamente até eventualmente produzir Hamlet…
…um modelo de linguagem não estaria fazendo aproximadamente a mesma coisa, só muito mais rápido?
Resposta curta:
não.
Resposta longa:
Pegue café.
Muito café.
Porque vamos precisar atravessar tokens, distribuições de probabilidade, temperatura, entropia, cadeias de Markov, contexto, atenção, brute force e aquele estranho fenômeno no qual um sistema treinado para prever sequências começa a produzir código COBOL, explicar filosofia e discutir por que alguém esqueceu de fechar um IF.
Capítulo I — O macaco não sabe o que acabou de escrever
Voltemos ao nosso funcionário mais improvável do Bellacosa Mainframe.
Na sala 327-B encontramos:
FUNCIONÁRIO: MACACO-01
FUNÇÃO: DIGITAÇÃO ALEATÓRIA
SALÁRIO: BANANAS
SLA: INFINITO
O macaco recebe um teclado contendo:
ABCDEFGHIJKLMNOPQRSTUVWXYZ
Cada vez que pressiona uma tecla, suponhamos que escolha uma delas aleatoriamente.
Ele produz:
XQJHABZP...
Depois:
BANANA
Depois:
TOBEORNOTTOBE
Fantástico.
Mas aconteceu algo importante?
Para nós, sim.
Reconhecemos Shakespeare.
Para o macaco?
Nada.
A tecla anterior não influencia necessariamente a próxima.
Ele não sabe que escreveu:
TO BE OR NOT TO
Portanto a próxima letra continua sendo apenas mais uma escolha no conjunto disponível.
Ele pode produzir:
TO BE OR NOT TO X
com a mesma tranquilidade com que poderia produzir:
TO BE OR NOT TO B
O gerador aleatório clássico não possui uma ideia operacional de contexto.
Um modelo de linguagem possui.
E essa diferença muda praticamente tudo.
Capítulo II — O LLM não pergunta “qual palavra existe?”
Ele pergunta algo muito mais interessante:
dado tudo o que apareceu antes, o que provavelmente vem agora?
Simplificando brutalmente, podemos imaginar:
P(próximo token | contexto anterior)
Esse pequeno símbolo:
|
é quase o personagem principal da história.
Significa:
condicionado a.
Não estamos perguntando:
Qual é a probabilidade da palavra PERFORM?
Estamos perguntando:
Qual é a probabilidade de PERFORM
dado tudo que apareceu antes?
Veja:
IDENTIFICATION DIVISION.
PROGRAM-ID. TESTE.
PROCEDURE DIVISION.
Agora imagine as possibilidades seguintes:
PERFORM
BANANA
TARDIS
DIVORCE
WORKING-STORAGE
DISPLAY
Todas essas sequências de caracteres são fisicamente possíveis.
Mas não são igualmente plausíveis naquele contexto.
Um modelo treinado em COBOL aprendeu relações estatísticas que tornam algumas alternativas muito mais prováveis.
O macaco pensa:
QUALQUER COISA SERVE.
O modelo pensa aproximadamente:
ALGUMAS COISAS FAZEM MUITO MAIS SENTIDO AQUI.
E isso já é uma revolução.
Capítulo III — Primeiro problema: modelos não enxergam exatamente palavras
Aqui entra uma pequena criatura chamada:
TOKEN.
Quando falamos informalmente:
“o modelo prevê a próxima palavra”
estamos simplificando.
Modelos de linguagem modernos geralmente trabalham com tokens, que podem representar:
uma palavra inteira;
parte de uma palavra;
pontuação;
espaços ou combinações;
sequências frequentes de caracteres.
Por exemplo, dependendo do tokenizer, algo semelhante a:
programador
pode ser uma unidade ou ser dividido em pedaços.
E:
WORKING-STORAGE
pode virar vários tokens.
Pense nos tokens como peças de LEGO linguísticas.
O modelo não recebe necessariamente:
PALAVRA 1
PALAVRA 2
PALAVRA 3
Ele recebe algo mais parecido com:
PEÇA 593
PEÇA 18271
PEÇA 44
PEÇA 905
Durante treinamento, aprende como essas peças aparecem juntas.
O macaco aperta teclas.
O LLM navega num espaço de peças linguísticas.
Capítulo IV — Uma distribuição, não uma resposta pronta
Imagine esta frase:
O programador entrou no CPD e pediu um...
O modelo não necessariamente possui apenas uma resposta.
Ele poderia atribuir algo conceitualmente parecido com:
café 0,36
acesso 0,18
terminal 0,12
relatório 0,08
dump 0,06
abacaxi 0,00001
dinossauro 0,000001
Os números aqui são apenas ilustrativos.
O ponto é a estrutura:
há uma distribuição de probabilidades.
Isso é fundamental.
O modelo não pensa simplesmente:
RESPOSTA = CAFÉ
Ele produz algo mais próximo de:
POSSIBILIDADES ORDENADAS POR PLAUSIBILIDADE.
Depois algum mecanismo de seleção determina qual token será efetivamente escolhido.
E aí entra uma palavra que parece saída de previsão meteorológica:
temperatura.
Capítulo V — Temperatura: aumentando a dose de caos
Temperatura controla, de forma simplificada, quão concentrada ou espalhada fica a distribuição usada durante a geração.
Temperatura baixa:
ESCOLHA O MAIS PROVÁVEL.
Temperatura mais alta:
DÊ MAIS CHANCE PARA ALTERNATIVAS MENOS ÓBVIAS.
Imagine:
O gato subiu no...
Distribuição hipotética:
telhado 45%
muro 20%
sofá 10%
armário 8%
mainframe 0,01%
Saturno 0,0001%
Com temperatura baixa, provavelmente teremos:
telhado
Com temperatura mais alta:
armário
pode aparecer com maior frequência.
Subindo absurdamente:
mainframe
entra na reunião.
Aumentando ainda mais:
O gato subiu no checksum metafísico das quintas-feiras.
Nesse ponto talvez seja prudente desligar alguma coisa.
Capítulo VI — Então existe aleatoriedade?
Sim.
Mas isso não transforma o modelo no macaco de Borel.
Existe uma enorme diferença entre:
ESCOLHER ALEATORIAMENTE ENTRE TODOS OS SÍMBOLOS
e:
ESCOLHER A PARTIR DE UMA DISTRIBUIÇÃO
APRENDIDA SOBRE O QUE FAZ SENTIDO
DADO O CONTEXTO.
O segundo processo carrega informação.
Esse detalhe é gigantesco.
Nosso macaco poderia escrever:
IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.
PROCEDURE DIVISION.
DISPLAY "HELLO WORLD".
STOP RUN.
Mas teria chegado lá por acidente.
Um LLM treinado em código percebe padrões como:
IDENTIFICATION DIVISION
→ PROGRAM-ID
ou:
DISPLAY
→ literal ou variável
Ele não precisa experimentar todas as combinações até encontrar uma compilável.
Aprendeu um relevo estatístico do território.
Capítulo VII — Imagine uma montanha de probabilidades
Pense em todas as sequências possíveis como uma paisagem gigantesca.
O macaco possui um mapa completamente plano.
Para ele:
AAABBB
e:
TO BE
são apenas coordenadas diferentes.
Já o modelo aprendeu montanhas e vales.
Algumas sequências possuem caminhos naturalmente elevados:
Era uma vez...
tende a levar para narrativa.
SELECT *
FROM
tende a levar para SQL.
IDENTIFICATION DIVISION.
tende a levar para COBOL.
Você forneceu contexto.
O espaço de possibilidades foi drasticamente reorganizado.
Essa talvez seja uma das melhores maneiras de imaginar aprendizado:
o modelo transforma um universo plano de combinações numa geografia de plausibilidades.
Capítulo VIII — E aqui encontramos Claude Shannon
Agora precisamos falar de entropia.
Calma.
Ninguém precisará usar capacete de física.
Em teoria da informação, entropia mede aproximadamente o grau de incerteza existente numa distribuição.
Se você tem:
A = 25%
B = 25%
C = 25%
D = 25%
há bastante incerteza.
Mas:
A = 99,9%
B = 0,05%
C = 0,03%
D = 0,02%
há muito menos.
O contexto reduz entropia.
Considere:
O Sol nasce no...
Existe forte expectativa de:
leste
Agora:
Ele abriu a porta e viu...
Existem muito mais continuações possíveis.
Um cachorro.
Uma pessoa.
A chuva.
Um quarto vazio.
Um macaco digitando Hamlet.
Um fiscal do Ministério de Caminhadas Bobas.
A distribuição fica mais espalhada.
Mais incerteza.
Mais entropia.
Capítulo IX — Conhecimento é redução de entropia
Esse conceito conecta maravilhosamente com programação.
Você recebe:
O SISTEMA ESTÁ COM PROBLEMA.
Entropia enorme.
Pode ser:
CPU;
memória;
rede;
banco;
aplicação;
segurança;
storage;
configuração;
JCL;
CICS;
Db2;
VSAM;
operador;
mudança;
dados.
Agora alguém informa:
ABEND S0C7
BUM.
O espaço reduz.
Depois:
OCORRE NA ROTINA CALC-TOTAL
reduz mais.
Depois:
CAMPO WS-VALOR RECEBEU '12A45'
Praticamente acabou o mistério.
Diagnóstico é essencialmente um processo de:
redução progressiva de incerteza.
Você não precisa investigar o Universo.
Precisa descobrir qual informação diminui mais rapidamente o espaço de possibilidades.
Capítulo X — O velho programador é uma máquina anti-entropia
Um iniciante vê:
S0C7
e pensa:
— MEU DEUS O MAINFRAME QUEBROU.
O veterano responde:
— Mostra o campo.
Por quê?
Porque sua experiência acumulou relações.
Ele sabe quais evidências são informativas.
De certa forma, cada mensagem recebida modifica sua distribuição mental:
P(causa | evidências)
Parece familiar?
Sim.
Porque agora estamos novamente perto do nosso LLM.
Capítulo XI — Antes dos Transformers havia Markov
Outra palavra importante:
Markov.
Uma cadeia de Markov trabalha, de forma simplificada, com probabilidades de transição entre estados.
Por exemplo, examinando textos poderíamos aprender:
depois de "bom" →
dia 60%
trabalho 10%
café 8%
Um modelo simples poderia olhar apenas uma ou algumas palavras anteriores.
Isso permite gerar textos surpreendentemente convincentes por pequenos trechos.
Imagine treinarmos uma cadeia de Markov com documentação COBOL.
Ela poderia aprender:
IDENTIFICATION
→ DIVISION
PROGRAM-ID
→ nome
PROCEDURE
→ DIVISION
Já seria muito superior ao macaco.
Por quê?
Porque existe memória estatística local.
Mas existe um problema.
Contexto distante importa.
Muito.
Capítulo XII — Hamlet não cabe numa janela de duas palavras
Veja:
Maria colocou o livro sobre a mesa porque precisava
consultá-lo depois da reunião.
Para saber a que:
lo
se refere, talvez precisemos relacioná-lo com algo ocorrido várias palavras antes.
Agora imagine:
um romance;
um programa;
documentação;
uma conversa;
código contendo funções espalhadas;
uma história com personagens.
Dependências podem existir a centenas ou milhares de tokens de distância.
Modelos baseados apenas em relações locais possuem dificuldade crescente nisso.
E então chegaram os Transformers.
Com eles aparece um conceito que mudou profundamente o jogo:
atenção.
Capítulo XIII — Attention, please
A ideia central de atenção é quase deliciosamente intuitiva:
para entender o elemento atual, quais partes do contexto anterior são especialmente relevantes?
Imagine:
O arquivo CUSTOMER foi aberto no início do programa.
Depois de diversas operações, o programa tentou lê-lo,
mas recebeu FILE STATUS 47.
Para entender o problema, talvez algumas palavras sejam muito mais relevantes:
arquivo
CUSTOMER
aberto
ler
FILE STATUS 47
Outras são menos importantes.
O mecanismo de atenção calcula relações entre representações dos tokens para determinar quais partes devem exercer mais influência umas sobre as outras.
Não é uma busca literal por palavra-chave.
É uma relação aprendida em espaços matemáticos de representação.
Capítulo XIV — Query, Key e Value entram num bar
No mecanismo clássico de attention aparecem três conceitos:
QUERY
KEY
VALUE
Isso parece suspeitosamente familiar para alguém que vive de sistemas.
Podemos criar uma analogia grosseira.
Cada token produz algo como:
QUERY = o que estou procurando?
KEY = que tipo de informação eu represento?
VALUE = qual informação posso fornecer?
A Query de um token é comparada às Keys dos outros tokens.
Correspondências fortes recebem maior peso.
Depois os Values relacionados são combinados.
É muito mais complexo matematicamente, mas a intuição funciona.
Imagine uma reunião.
Você pergunta:
— Quem sabe sobre RACF?
Cinquenta pessoas estão na sala.
Um DBA levanta levemente a sobrancelha.
O sysprog RACF começa imediatamente a falar.
O estagiário continua olhando para o celular.
Sua Query:
RACF
encontrou uma Key altamente compatível.
Atenção alocada.
Capítulo XV — O macaco procura tudo; a atenção decide onde olhar
Agora nossa comparação fica bonita.
Macaco:
TODAS AS TECLAS
TODAS AS VEZES
SEM CONTEXTO
Brute force:
TODAS AS POSSIBILIDADES
ATÉ ACHAR.
Heurística:
TENTE AS MAIS PROMISSORAS.
LLM:
USE O CONTEXTO
PARA PRODUZIR UMA DISTRIBUIÇÃO
SOBRE CONTINUAÇÕES PLAUSÍVEIS.
Atenção:
DESCUBRA QUAIS PARTES DO CONTEXTO
SÃO MAIS RELEVANTES AGORA.
Estamos muito longe do macaco original.
Capítulo XVI — “Mas ele continua apenas prevendo o próximo token!”
Sim.
E seu programa COBOL continua apenas executando instruções.
O ponto não é qual operação elementar acontece.
O ponto é qual estrutura emerge da combinação de bilhões dessas operações.
Um processador faz basicamente operações muito simples.
Ainda assim executa:
CICS;
Db2;
compiladores;
criptografia;
sistemas bancários;
inteligência artificial.
Dizer:
“LLM só prevê token”
é semelhante a explicar um banco dizendo:
“O computador só altera bits.”
Não está errado.
Só deixou de explicar praticamente tudo que é interessante.
Capítulo XVII — O poder está na distribuição condicionada
Observe a diferença.
Macaco:
P(X) = aproximadamente constante
simplificando nosso modelo ideal.
Modelo:
P(X | CONTEXTO)
O contexto pode incluir:
palavras;
frases;
código;
instruções;
relações;
exemplos;
estilo;
estrutura.
Logo:
PERFORM UNTIL
faz determinadas continuações subirem de probabilidade.
E:
Era uma noite escura e tempestuosa...
faz outras subirem.
O mesmo mecanismo básico consegue trabalhar em domínios completamente diferentes porque aprendeu regularidades estatísticas extremamente amplas.
Capítulo XVIII — O treinamento é onde o mapa nasce
Durante treinamento, o modelo vê enormes quantidades de sequências.
Ele tenta prever partes seguintes.
Erra.
Os parâmetros internos são ajustados.
Tenta novamente.
Erra menos.
Repete isso incontáveis vezes.
De forma caricata:
INPUT:
IDENTIFICATION
MODELO:
BANANA
SISTEMA:
ERRADO.
AJUSTA PESOS.
INPUT:
IDENTIFICATION
MODELO:
DIVISION
SISTEMA:
MELHOR.
Claro que treinamento real é incomparavelmente mais complexo.
Mas a ideia fundamental permanece:
o modelo internaliza regularidades por otimização.
Ao final, ele não guarda simplesmente uma gigantesca tabela:
SE INPUT = X
THEN OUTPUT = Y
Existe um conjunto enorme de parâmetros representando padrões distribuídos.
Capítulo XIX — Pesos: memória sem ficha catalográfica
Isso costuma causar confusão.
As pessoas imaginam que um modelo possui algo parecido com:
DATABASE
--------
PERGUNTA 1 → RESPOSTA 1
PERGUNTA 2 → RESPOSTA 2
PERGUNTA 3 → RESPOSTA 3
Não funciona assim.
Grande parte do conhecimento aprendido está distribuída nos pesos da rede.
Podemos usar uma analogia humana.
Você sabe falar português.
Onde está armazenada a regra completa para usar:
por que
porque
por quê
porquê
no seu cérebro?
Provavelmente não existe uma gaveta física etiquetada:
PORTUGUÊS/PORQUES.DAT
Seu conhecimento está distribuído.
No modelo acontece algo matematicamente diferente, porém conceitualmente podemos dizer:
o conhecimento não está organizado como páginas numa enciclopédia interna.
Capítulo XX — E o brute force?
Aqui chegamos novamente ao macaco.
Se quiséssemos gerar uma resposta testando todas as sequências possíveis de tokens, teríamos algo monstruoso.
Suponha um vocabulário de:
50.000 tokens
Para uma sequência de apenas 10 tokens:
50.000^10
possibilidades.
Isso é:
aproximadamente 10^47
combinações.
Dez tokens!
Uma resposta real pode conter centenas ou milhares.
Brute force é simplesmente inviável.
O modelo precisa navegar inteligentemente pelas regiões de maior probabilidade.
De novo:
conhecimento reduz espaço de busca.
Capítulo XXI — Beam Search entra carregando uma lanterna
Existem estratégias de geração que ilustram esse princípio.
Uma delas, tradicional em vários sistemas de geração, é beam search.
Em vez de seguir apenas uma alternativa, mantemos algumas das melhores candidatas.
Imagine:
O café está...
Possibilidades:
quente 40%
pronto 30%
frio 20%
cantando 0,001%
Podemos manter:
quente
pronto
frio
e expandir cada caminho.
Depois descartamos alternativas cada vez menos promissoras.
Não exploramos o universo inteiro.
Mantemos uma pequena fronteira de possibilidades.
Novamente:
não seja o macaco.
Capítulo XXII — Top-k e top-p: expulsando possibilidades absurdas da reunião
Outra família de técnicas limita candidatos.
Top-k:
considere apenas os K tokens mais prováveis.
Se K = 5:
ignore todo o resto.
Top-p, ou nucleus sampling:
considere o menor conjunto de tokens
cuja probabilidade acumulada atinja determinado limite.
Essas estratégias evitam gastar probabilidade com opções extremamente improváveis.
Nosso macaco aceita tudo.
O modelo diz:
— Desculpe, ornitorrinco possui probabilidade baixa demais nesta frase.
O ornitorrinco protesta.
A reunião continua.
Capítulo XXIII — Temperatura baixa demais também causa problemas
Agora vem uma sutileza.
Se sempre escolhermos o token mais provável, podemos obter textos:
previsíveis;
repetitivos;
conservadores;
pouco variados.
Imagine um escritor que sempre escolhe a continuação estatisticamente mais comum.
Teríamos o romance:
Era uma vez um homem.
O homem foi para casa.
Na casa havia uma casa.
A casa era uma casa.
Fim.
Parabéns.
Produzimos documentação de fornecedor.
Um pouco de aleatoriedade permite diversidade.
A criatividade computacional prática vive parcialmente no equilíbrio entre:
PREVISIBILIDADE
e:
EXPLORAÇÃO.
Capítulo XXIV — Isso lembra exploração versus exploitation
Machine learning possui um dilema clássico:
EXPLOITATION
usar aquilo que já sabemos funcionar.
versus:
EXPLORATION
tentar possibilidades novas.
Temperatura baixa favorece exploitation.
Temperatura mais alta aumenta exploration.
A vida profissional possui exatamente isso.
O programador experiente pode resolver tudo sempre do mesmo jeito.
Seguro.
Previsível.
Até chegar um problema novo.
O jovem tenta vinte coisas absurdas.
Dezenove falham.
Uma revela algo que ninguém percebeu.
Uma boa equipe mistura ambos.
Capítulo XXV — LLM não possui uma “frase escondida” esperando ser revelada
Outra ideia errada:
“A resposta já está dentro do modelo.”
Não exatamente.
A geração é sequencial.
Cada token produzido passa a fazer parte do contexto para os tokens seguintes.
Assim:
TOKEN 1
↓
modifica contexto
TOKEN 2
↓
modifica contexto
TOKEN 3
↓
...
A resposta vai sendo construída.
Isso significa que uma escolha inicial pode alterar profundamente o caminho posterior.
Quase como uma execução de programa.
Só que probabilística.
Capítulo XXVI — Um pequeno desvio pode criar outro universo
Imagine que o modelo começa:
Existem três causas principais...
Agora provavelmente continuará estruturando três causas.
Mas se começar:
A causa principal é...
criou outra trajetória textual.
Cada token não é apenas output.
Ele também vira input subsequente.
Temos feedback.
Não exatamente no sentido de treinamento, mas no sentido de condicionamento da próxima geração.
Uma espécie de:
MOVE OUTPUT-TOKEN TO NEXT-INPUT-CONTEXT
Isso explica por que pequenas diferenças iniciais podem produzir respostas bastante diferentes.
Capítulo XXVII — E aqui mora a alucinação
Um modelo produz aquilo que parece provável linguisticamente.
Isso não garante que seja verdadeiro.
Essa distinção é fundamental.
Imagine:
FORMA PLAUSÍVEL
≠
FATO VERIFICADO
O modelo pode gerar uma referência com aparência perfeita:
Autor,
ano,
título,
revista,
volume,
página.
Tudo linguisticamente impecável.
E inexistente.
Por quê?
Porque o objetivo básico da geração não é:
EXECUTE FACT-CHECK
antes de cada token.
É produzir uma continuação plausível segundo o contexto e os mecanismos adicionais do sistema.
É por isso que ferramentas externas, recuperação de documentos, pesquisa e verificação são tão importantes em tarefas factuais.
Capítulo XXVIII — O macaco erra de forma idiota; o LLM pode errar de forma elegante
O macaco produz:
XJSQWERTYZZZZ
Você olha e diz:
— Errado.
Fim.
O modelo pode produzir:
“Segundo o estudo realizado pela Universidade Real de Copenhagen em 1987…”
Você pensa:
— Parece plausível.
Esse erro é muito mais perigoso.
Fluência gera confiança.
Portanto existe uma regra prática maravilhosa:
quanto mais importante o fato, menos você deve confundir boa escrita com prova.
No mainframe isso já era conhecido há décadas.
Um job pode terminar com:
RC=0000
e ainda produzir resultado logicamente errado.
Compilar não significa estar correto.
Soar convincente também não.
Capítulo XXIX — O LLM encontrou Shakespeare sem digitar infinitamente
Aqui finalmente fechamos o círculo.
O macaco precisa de:
TENTATIVAS ABSURDAMENTE NUMEROSAS
porque não possui conhecimento.
O LLM aprendeu estrutura.
Por isso consegue navegar diretamente para regiões onde texto coerente vive.
Em vez de procurar Hamlet em:
TODAS AS SEQUÊNCIAS POSSÍVEIS
ele aprendeu:
sintaxe;
relações semânticas;
estilos;
formas narrativas;
convenções;
padrões estatísticos.
Shakespeare deixa de ser uma agulha completamente escondida num universo plano.
O modelo possui um mapa imperfeito de onde “coisas parecidas com linguagem humana” costumam existir.
Capítulo XXX — Mas isso é inteligência?
Excelente pergunta.
O Ministério das Perguntas Filosóficas informa que sua senha é:
8.391.274
Atendimento atual:
12
Existe debate enorme sobre o que constitui inteligência, compreensão, raciocínio e significado.
Mas uma coisa podemos afirmar operacionalmente:
o comportamento de um LLM não é equivalente ao de um gerador uniforme de caracteres aleatórios.
Existe estrutura aprendida.
Existe condicionamento pelo contexto.
Existem representações internas complexas.
Existe atenção.
Existe uma distribuição de probabilidades profundamente moldada pelo treinamento.
Compará-lo ao macaco infinito é uma metáfora divertida.
Como explicação técnica, porém, ela desaba rapidamente.
Capítulo XXXI — O programador COBOL iniciante pode aprender muito com isso
Primeira lição:
contexto vale ouro.
Se você pedir:
me explique esse erro
existe enorme incerteza.
Mas:
Tenho um programa COBOL rodando em z/OS,
recebendo S0C7 após um COMPUTE.
O campo WS-AMOUNT é PIC 9(7)V99
e recebeu dados vindos deste arquivo.
Você reduziu brutalmente o espaço de possibilidades.
Para humanos e para modelos.
Segunda:
forneça evidências, não apenas conclusões.
Em vez de:
DB2 está lento.
forneça:
query
access path
elapsed
CPU
getpages
locks
Informação reduz entropia.
Terceira:
não aceite fluência como confirmação.
Sempre valide:
comandos;
versões;
parâmetros;
comportamento;
fatos importantes.
Quarta:
aprenda padrões.
Quanto mais padrões você conhece, menor fica seu espaço de busca.
Quinta:
quando tudo parece possível, procure a informação que mais elimina hipóteses.
Essa talvez seja uma das melhores técnicas de troubleshooting que existem.
Capítulo XXXII — A atenção no dia a dia do mainframe
Imagine um dump com milhares de linhas.
O iniciante lê:
LINHA 1
LINHA 2
LINHA 3
...
LINHA 9000
O experiente procura:
ABEND CODE
PSW
OFFSET
MODULE
REGISTER
FILE STATUS
SQLCODE
MESSAGE ID
Isso é uma espécie de attention humana.
Não no sentido matemático do Transformer, claro.
Mas no sentido cognitivo:
algumas partes do contexto merecem muito mais peso.
A habilidade de investigar sistemas complexos depende enormemente disso.
Você nunca consegue observar tudo.
Precisa saber onde olhar.
Capítulo XXXIII — O macaco recebeu atenção e pediu aumento
Nosso macaco original finalmente descobre o conceito.
Ele chama o gerente.
— Durante cem anos eu digitei aleatoriamente.
— Sim.
— Agora descobri que existe um sistema que usa contexto.
— Sim.
— E vocês sabiam disso?
— É complicado.
— Quantas bananas eu desperdicei?
Silêncio.
O macaco abre sindicato.
O projeto entra em negociação coletiva.
Capítulo XXXIV — Easter egg: Monty Python entra no laboratório
Um funcionário do Ministério da Inteligência Artificial entra carregando uma pasta.
— Precisamos determinar se esta máquina pensa.
O cientista pergunta:
— Como?
— Se ela responder corretamente, pensa.
— E qual a pergunta?
— Ainda estamos decidindo.
— Quem decide?
— O Comitê para Definir Perguntas que Determinam Pensamento.
— Onde fica?
— Dentro do Departamento de Definições Indefinidas.
— E eles pensam?
— Isso ainda está sendo avaliado.
Enquanto isso, o macaco já foi embora com a máquina de escrever.
Provavelmente tomou a decisão mais inteligente da sala.
Capítulo XXXV — Existe ainda um fantasma chamado determinismo
Se definirmos determinados parâmetros e mecanismos de seleção, podemos tornar a geração mais determinística.
Em outros cenários, sampling introduz variação.
Isso explica por que o mesmo prompt pode produzir respostas diferentes.
Não significa que o modelo:
MUDOU DE OPINIÃO
como um humano necessariamente faria.
O processo de geração percorreu outra trajetória probabilística.
Pense numa bifurcação:
CONTEXTO
|
-----------------
| | |
TOKEN A TOKEN B TOKEN C
| | |
... ... ...
Cada escolha abre um caminho diferente.
A linguagem é uma árvore gigantesca de possibilidades.
Capítulo XXXVI — Do macaco para a árvore
Essa talvez seja a imagem definitiva.
O macaco olha para uma árvore contendo bilhões de bilhões de galhos e escolhe aleatoriamente qualquer um.
O LLM possui um mapa dizendo:
ESSE GALHO PARECE PROMISSOR.
ESSE TAMBÉM.
AQUELE É ESTRANHO.
AQUELE OUTRO PROVAVELMENTE TERMINA NUM ORNITORRINCO.
Não possui certeza absoluta.
Mas possui orientação.
E orientação muda completamente a complexidade prática do problema.
Capítulo XXXVII — O segredo não é prever; é prever muito bem
Agora podemos reinterpretar aquela frase:
“O modelo apenas prevê o próximo token.”
Sim.
Mas para prever bem o próximo token em linguagem humana, precisa capturar enormes quantidades de estrutura.
Considere:
Se João colocou o copo sobre a mesa
e Maria esbarrou na mesa...
Qual consequência é provável?
Talvez o copo caia.
Para prever continuações plausíveis, o modelo precisa representar relações sobre:
objetos;
ações;
linguagem;
física cotidiana;
causalidade;
convenções narrativas.
Não significa necessariamente possuir compreensão humana.
Mas mostra por que o problema de previsão pode forçar a aprendizagem de estruturas surpreendentemente profundas.
Capítulo XXXVIII — Previsão como compressão
Existe outra forma fascinante de olhar para isso.
Um sistema que prevê bem encontrou regularidades.
Se você sabe que:
IDENTIFICATION
quase sempre é seguido por:
DIVISION
não precisa tratar cada ocorrência como informação completamente nova.
Você capturou uma regularidade.
Nesse sentido, modelar é parcialmente comprimir padrões.
Quanto melhor entendemos a estrutura, menos surpresa existe.
Isso conecta:
probabilidade;
entropia;
compressão;
aprendizado.
Claude Shannon provavelmente pediria café neste ponto.
Capítulo XXXIX — Quando a surpresa é útil
Um texto em que cada próxima palavra é totalmente previsível é entediante.
Um texto em que cada palavra é completamente imprevisível é ruído.
Boa linguagem vive entre ambos.
Compare:
O gato é um gato que é gato e gato.
Entropia baixa demais.
Agora:
XQZ RTM PFJK WLLZ.
Entropia inútil.
Agora:
O gato dormia sobre o terminal 3270 enquanto o operador tentava explicar ao auditor por que aquilo constava no inventário como dispositivo biométrico.
Surpresa.
Mas coerência.
Esse equilíbrio é uma parte importante da produção de linguagem interessante.
Capítulo XL — E criatividade talvez more nessa fronteira
Talvez criatividade não seja:
ALEATORIEDADE PURA
nem:
PREVISIBILIDADE ABSOLUTA.
Talvez esteja em algo como:
ESTRUTURA
+
VARIAÇÃO
+
CONTEXTO
+
SELEÇÃO
Humanos fazem isso.
Modelos fazem algo matematicamente diferente, mas também exploram uma região entre ordem e surpresa.
O macaco infinito possui surpresa demais.
Um autocomplete rígido possui surpresa de menos.
O desafio interessante mora no meio.
Epílogo — O macaco pede acesso ao Transformer
Depois de cem anos no Bellacosa Mainframe, MONKEY01 finalmente encontra o novo sistema.
Na tela:
PROMPT:
Escreva uma frase no estilo de Shakespeare.
Resposta:
A noite pesa sobre a torre,
e cada sino parece contar
os segundos que restam ao rei.
O macaco olha.
Olha para sua máquina de escrever.
Olha novamente para a tela.
Depois chama o sysprog.
— Quanto tempo isso levou?
— Alguns segundos.
— Quantos macacos?
— Nenhum.
— Quantas tentativas?
— Não funciona exatamente assim.
O macaco permanece em silêncio.
Depois pergunta:
— Então durante todos esses anos vocês estavam esperando que eu encontrasse Shakespeare no espaço completo de possibilidades...
— Sim.
— ...quando poderiam aprender quais sequências parecem linguagem?
— Tecnicamente...
O macaco vira a mesa.
E está certo.
Porque essa é a grande mudança entre o Macaco Infinito e o Modelo de Linguagem.
O primeiro depende de:
TEMPO
+
ALEATORIEDADE
+
SORTE.
O segundo depende de:
TREINAMENTO
+
ESTRUTURA
+
CONTEXTO
+
PROBABILIDADE
+
ATENÇÃO.
O macaco explora um universo indiferenciado.
O modelo aprendeu que algumas regiões desse universo são muito mais interessantes que outras.
Brute force diz:
Tente tudo.
Probabilidade diz:
Algumas coisas são mais prováveis.
Entropia pergunta:
Quanto ainda não sabemos?
Contexto responde:
Agora sabemos um pouco mais.
Markov diz:
O passado recente ajuda.
Attention acrescenta:
Nem todo passado é igualmente importante.
O Transformer junta tudo numa arquitetura capaz de manipular relações em escala gigantesca.
E o velho programador COBOL, que assistiu a toda a discussão enquanto tomava café, finalmente fecha o dump e comenta:
— Interessante.
— O quê?
— Passamos cem anos tentando criar máquinas que procurassem respostas.
Ele aponta para o terminal.
— Agora estamos criando máquinas que aprendem onde vale a pena procurar.
Silêncio.
O macaco olha para o programador.
O programador olha para o macaco.
Ambos olham para o gerente.
O gerente pergunta:
— Isso reduz headcount?
O macaco imediatamente volta para a máquina de escrever.
Era melhor lidar com o infinito.
☕🐒🤖
No console aparece:
MONKEY01 ENDED
LLM0001 STARTED
O operador verifica.
MAXCC=0000
Cinco segundos depois:
WARNING:
OUTPUT PLAUSIBLE.
FACT CHECK REQUIRED.
O velho COBOLzeiro sorri.
Finalmente uma máquina que aprendeu uma das regras fundamentais de produção:
parecer correto nunca foi a mesma coisa que estar correto.
Sem comentários:
Enviar um comentário