Da Criptoanálise à AI-Forensics: Desvendando os Segredos das Redes Neurais Quânticas
Este artigo explora uma nova abordagem para a análise de redes neurais quânticas, inspirada na criptoanálise. A pesquisa foca na criação de uma infraestrutura de 'AI-forensics' para inspecionar, modificar e validar modelos de linguagem, transformando a 'magia' da IA em engenharia precisa.
MundiX News·09 de maio de 2026·15 min de leitura·👁 17 views
Da Criptoanálise à AI-Forensics:
Introdução
Em um artigo anterior, demonstrei como a assinatura Schnorr / MuSig2 pode ser vista não como uma 'caixa preta', mas como um sistema de estruturas afins observáveis: através de uma rigorosa ponte de associação BIP340, famílias de nonces ocultos, métricas de compressão/conectividade e linearização de assinaturas parciais MuSig2. Isso muda a ótica: em vez de 'acreditarmos no protocolo', começamos a decompô-lo em blocos matemáticos verificáveis.
O próximo passo foi inesperado, mas lógico. Transportamos a mesma metodologia para a IA. Não no sentido de 'pegamos uma LLM e começamos a ajustá-la'. Mas no sentido de: pegamos um modelo MLX quantizado e começamos a investigar sua matemática interna da mesma forma que antes investigávamos as assinaturas.
O objeto do experimento foi uma distribuição local: gpt-oss-20b-TurboQuant-MLX-8bit. Não alteramos a arquitetura do modelo, não reescrevemos a atenção e não nos envolvemos no ajuste fino clássico. Fizemos outra coisa: aprendemos a ler .safetensors como uma estrutura precisa; construímos um cache de calibração determinístico; começamos a capturar ativações BF16 reais de camadas específicas; reduzimos a correção local de pesos a uma tarefa limitada de otimização de inteiros; fizemos uma gravação segura do patch de volta no modelo; e adicionamos uma verificação de fumaça que verifica se a matemática offline corresponde ao runtime MLX real.
O principal resultado deste artigo soa assim: não 'melhoramos o modelo com mágica', mas construímos um pipeline exato de AI-forensics, no qual a camada quantizada deixa de ser uma caixa preta e se torna um objeto observável, verificável e corrigível localmente.
Por que a transição de Schnorr para IA é natural
Em criptografia, tudo começou com uma ideia muito simples: se um objeto permite uma normalização rigorosa, então ele pode não apenas ser usado, mas também ser investigado como uma geometria de parâmetros ocultos. Para a assinatura Schnorr, a relação básica tem a forma: y = xG + rH, onde: x - chave privada, r - nonce, c - desafio, y - escalar da assinatura. Isso não é mais 'a magia da assinatura', mas uma estrutura linear.
Em IA, demos o mesmo passo. Paramos de olhar para o modelo como uma função 'prompt text' e descemos mais baixo - para o lugar onde sua álgebra linear interna vive: códigos quantizados, escala/viés, ativações de entrada, saídas de referência da camada linear. Ou seja, a questão mudou. Não: 'O modelo responde bem ou mal?' Mas: 'É possível representar uma camada quantizada específica como um objeto afim preciso, observar seu comportamento e corrigi-lo localmente sem destruir todo o modelo?' Isso é AI-forensics.
O que exatamente pegamos
A base foi a distribuição MLX: gpt-oss-20b-TurboQuant-MLX-8bit. Estávamos interessados em duas camadas específicas do primeiro bloco: model.layers.0.self_attn.q_proj.weight e model.layers.0.mlp.router.weight. Por que elas? Porque este é um bom teste para dois cenários diferentes: uma camada que pode ser muito 'rígida' para um patch significativo sem uma referência externa; uma camada que, por outro lado, permite a correção local. É nesse contraste que o valor do método se manifesta.
O que exatamente mudamos
É importante consertar imediatamente: não alteramos a arquitetura do modelo. Não alteramos o 'cérebro do modelo', mas a maneira como trabalhamos com ele. Era .safetensors como um contêiner opaco; pesos quantizados como 'algo dentro do runtime'; avaliação do modelo apenas pela saída de texto final. Tornou-se acesso preciso à representação de peso bruto; alocação de códigos de quantização, escala e viés; captura de runtime da entrada e saída de uma camada linear específica; otimização de inteiros local; gravação segura do patch de volta; uma verificação obrigatória de que a matemática offline não diverge da execução real.
Simplificando: transformamos a camada quantizada de um 'detalhe opaco do modelo' em um objeto de engenharia de diagnóstico.
Passo 1. Ponte exata para .safetensors
A primeira coisa que tivemos que fazer foi escrever uma ponte para a quantização MLX. Ele pode: encontrar o tensor certo no modelo; ler sua representação bruta; extrair códigos quantizados; ler as escalas e vieses BF16; se necessário, gravar códigos alterados de volta. Este é um ponto importante. Enquanto os pesos do modelo são percebidos como um 'blob pronto', nenhum trabalho preciso pode ser feito com eles. Primeiro, você precisa implantar este blob em uma estrutura matemática normal.
Passo 2. Cache de calibração determinístico
O próximo passo é o cache de calibração. Reunimos um conjunto estável de exemplos com antecedência: Parâmetro Valor Total de exemplos 768 Split general 512 Split logic 256 Tamanho do shard 128 Política de captura last-token Tipo de ativações BF16. Por que isso é necessário? Para que cada experimento subsequente seja reproduzível. Não 'parece melhor', mas: aqui está o mesmo conjunto, aqui está a mesma camada, aqui está a mesma entrada, aqui está a mesma saída de referência, aqui está a mesma métrica de erro. Sem isso, tudo se transforma rapidamente em narrativa.
Passo 3. Captura de ativações reais
Depois disso, adicionamos a captura de runtime para camadas lineares específicas. Para cada exemplo selecionado, foram salvos: pre_linear_input e linear_output_reference. E precisamente para o último token. Isso é muito importante. Não simulamos a camada separadamente do modelo, mas a removemos do MLX-runtime real. Ou seja, trabalhamos não com álgebra linear abstrata, mas com dados que o modelo realmente gera por si só.
Modelo matemático da camada quantizada
Agora você pode escrever a camada na forma de uma fórmula normal. Deixe a linha de pesos ser dividida em blocos de comprimento k. Para a linha W e o bloco w, denotamos: q - vetor de códigos quantizados de comprimento k; s - escala; b - viés. Então, o bloco de pesos dequantizado é definido como w = s(q - b) + b, onde 1 é um vetor de uns de comprimento k. Se o vetor de entrada para o exemplo x for dividido nos mesmos blocos: x = [x1, x2, ..., xn], então a saída na coordenada i é igual a yi = wiTxi, ou, após a substituição da dequantização, yi = si(qiTxi - biTxi) + biTxi. É aqui que a principal ponte aparece. A camada quantizada deixa de ser um 'conjunto de bytes incompreensíveis' e se torna um sistema afim sobre códigos discretos.
O que exatamente otimizamos
Para o bloco selecionado, estamos procurando um novo vetor de código q', que reproduza melhor a saída de referência, mas não se afaste muito do original. A tarefa de otimização tem a forma: minimize ||Wq' - y||^2 + λ||q' - q||^2, com restrições q' ∈ Z^k e |q'i - qi| <= δ. Onde: q - códigos originais do bloco; λ - coeficiente de regularização; δ - alteração máxima permitida de um código. Em nossos experimentos para a camada do roteador, foram usados: Parâmetro Valor Tamanho do bloco 64 Ridge lambda 16 Max code delta abs 8. Ou seja, o patch foi originalmente feito conservador: não reescrever a camada inteiramente; não alterar dezenas de milhares de parâmetros sem controle; não se afastar muito da estrutura original; consertar localmente e em uma janela limitada.
Teorema importante: por que não haverá um patch honesto sem uma referência externa
Esta é a fronteira chave do método. Teorema Se usarmos a camada quantizada atual como meta, então qualquer busca exata por um patch dá um ótimo trivial: não mude nada. Ideia Deixe o estado inicial da camada ser definido pelo trio: W, q, y, e deixe a função de erro ter a forma E(q') = ||Wq' - y||^2, onde: q' - qualquer configuração admissível; q' = q; o zero é alcançado apenas no ponto q' = q. Então, o mínimo já é alcançado no estado inicial, porque você não pode ir abaixo de zero. Conclusão Portanto, se tentarmos 'melhorar' a camada, usando esta camada como meta, então a melhor estratégia é não mudar nada. Conclusão Para que um patch não-identidade seja matematicamente significativo, é necessária uma referência externa: ativações de runtime reais; saída de referência; um holdout separado. É por isso que em nosso sistema o pipeline é construído em torno da captura e do holdout, e não em torno da auto-comparação do modelo consigo mesmo.
O que a auditoria q_proj mostrou
O primeiro candidato a teste foi a camada model.layers.0.self_attn.q_proj.weight. Executamos uma auditoria exata nela. Quadro estrutural Métrica Valor Total de linhas 4096 Largura decodificada 2880 Blocos por linha 45 Total de blocos 184320 Linhas únicas 4096 Linhas repetidas 0 Blocos únicos 184320 Blocos repetidos 0 Pares de blocos adjacentes exatamente iguais 0. Esta é uma tabela muito reveladora. A camada provou ser estruturalmente 'rígida': sem repetições triviais; sem clones de blocos; sem simetrias exatas baratas; sem compressão pronta que pudesse ser facilmente usada para patch. Como resultado, a conclusão final sobre q_proj foi dura, mas correta: Conclusão sobre q_proj Valor Identidade de auto-alvo ótimo Verdadeiro Referência externa necessária Verdadeiro Patch não-identidade justificado Falso Candidatos a patch exatos encontrados 0. E este é um bom resultado. Porque o sistema não 'inventou uma melhoria', mas provou o limite de aplicabilidade do método.
Onde o patch realmente funcionou: o roteador
Uma história completamente diferente aconteceu com a camada model.layers.0.mlp.router.weight. Para ele, um pipeline completo foi construído: cache de calibração, captura de ativação de runtime, otimização LWO por bloco, validação de holdout, patch seguro, verificação de fumaça. Parâmetros do experimento Parâmetro Valor Modelo gpt-oss-20b-TurboQuant-MLX-8bit Camada model.layers.0.mlp.router.weight Train shard general_0000_0128 Holdout shard logic_0000_0128 Contagem de amostras de treinamento 4 Contagem de amostras de holdout 4 Tamanho do bloco 64 Ridge lambda 16 Max code delta abs 8
Resultado no treinamento
No train-shard, a melhoria foi quase perfeita. Métrica Valor Baseline MSE 0.022966404894191328 Patched MSE 3.000931005970632e-11 Ganho MSE 0.022966404864182017 Blocos alterados 571 Códigos alterados no total 9067. Neste ponto, seria fácil dizer: 'pronto, curamos a camada'. Mas esta seria a conclusão errada. O treinamento pode quase sempre ser melhorado. A principal questão é se o efeito é transferido ainda mais.
Verificação no holdout
É aqui que começa o mais interessante. Métrica Valor Baseline MSE 0.022778386753429913 Patched MSE 4.3748027306868276e-05 Ganho MSE 0.022734638726123045 Taxa de transferência 0.9899084711155454 Holdout melhora Verdadeiro Suspeita de overfitting Falso. Ou seja, a melhoria foi quase totalmente transferida para um shard separado. Você pode escrever isso de forma muito breve: MSE_holdout_patched / MSE_holdout_baseline = 0.00192. Isso não se parece com um acerto aleatório ou ajuste para quatro pontos. Isso significa que o sistema realmente encontrou uma correção local que carrega um efeito estável.
Patch seguro: por que isso não é apenas um relatório bonito
Após calcular o patch, ele também precisava ser gravado de volta no modelo. Para isso, um fluxo de trabalho de patch seguro foi implementado: salvar backup; empacotar novos códigos em U32; gravá-los em .safetensors; reler e verificar a correspondência exata. Resultado da gravação Métrica Valor Blocos alterados 571 Códigos alterados no total 9067 Palavras brutas u32 alteradas 3335 Gravação aplicada Verdadeiro Correspondência exata de leitura Verdadeiro. Ou seja, o sistema é capaz não apenas de calcular o patch, mas também de implementá-lo corretamente no arquivo do modelo real. É aqui que começa a engenharia, e não apenas a pesquisa em papel.
A parte mais honesta de toda a história: verificação de fumaça
Após gravar o patch, uma verificação de fumaça de runtime foi executada. E é aqui que o sistema mostrou por que a verificação rigorosa é necessária. Verificação de fumaça: Geral Métrica Valor Linhas exatas de entrada 4 / 4 Linhas exatas de saída 0 / 4 MSE de runtime de entrada vs referência 0.0 MSE de runtime de saída vs referência 0.023193681612610817 Valores BF16 brutos alterados de saída 128 Verificação de fumaça: Lógica Métrica Valor Linhas exatas de entrada 4 / 4 Linhas exatas de saída 0 / 4 MSE de runtime de entrada vs referência 0.0 MSE de runtime de saída vs referência 0.021752476692199707 Valores BF16 brutos alterados de saída 128. O que isso significa? Muito simples: a entrada na camada é reproduzida perfeitamente; mas a saída real do runtime após a gravação não correspondeu à referência offline, apesar do forte resultado nos relatórios do solucionador. À primeira vista, isso parece uma má notícia. Na verdade, o contrário. Isso significa que o sistema é capaz de detectar a discrepância entre: o modelo de dequantização offline, e a semântica real da execução no MLX runtime. Ou seja, ele não apenas 'gera patches', mas é capaz de capturar o momento em que a bela matemática deixa de corresponder à realidade da execução. Esta é uma capacidade muito importante.
O que realmente mudamos no modelo
Para não exagerar com as formulações, vou consertar com cuidado. Nós não mudamos: a arquitetura do modelo; o número de camadas; o mecanismo de atenção; o tokenizador; o pipeline de inferência de alto nível. Nós mudamos a lógica de trabalhar com suas camadas quantizadas internas: adicionamos a leitura precisa de códigos; adicionamos análise por blocos; adicionamos captura de ativação BF16; adicionamos patching de inteiros restritos; adicionamos gravação segura de volta; adicionamos uma verificação de realidade pós-patch. Ou seja, na verdade, transformamos a distribuição MLX de uma 'caixa pronta' em um sistema que pode ser instrumentado, diagnosticado e corrigido cirurgicamente.
O que nosso sistema agora pode fazer
Se juntarmos tudo, obtemos um mapa de capacidade bastante forte. 1. Auditoria exata de camadas quantizadas O sistema é capaz de analisar a representação interna do peso no nível: códigos U32, decodificação uint8, escala/viés BF16, geometria de bloco. 2. Captura de runtime do modelo ao vivo Ele é capaz de remover as entradas e saídas reais da camada linear no MLX-runtime real, e não em um simulador. 3. Correção de inteiros local Ele é capaz de procurar um patch limitado para blocos específicos sem destruir toda a camada. 4. Patching seguro Ele é capaz de gravar a correção de volta em .safetensors com controle de leitura. 5. Validação de holdout Ele é capaz de distinguir a melhoria real do re-treinamento em um pequeno shard de calibração. 6. Detecção de incompatibilidade de runtime Ele é capaz de detectar que o patch offline é bonito, mas o ambiente de execução o interpreta de forma diferente. E esta, talvez, seja uma das capacidades mais fortes do sistema no estágio atual.
O que ainda não afirmamos
Para que o artigo permaneça de engenharia, e não publicitário, também fixarei as limitações. Nós ainda não afirmamos que: qualquer camada pode ser corrigida com o mesmo sucesso; q_proj já foi melhorado - não, lá o sistema honestamente encontrou o limite do método; a semântica de runtime MLX já foi totalmente decodificada; o ramo de IA já está fortalecendo a recuperação criptoanalítica de ponta a ponta; todo o ramo de lattice para IA já está pronto para produção. Mas podemos muito bem afirmar outra coisa: uma infraestrutura de AI-forensics exata funcional foi construída para um modelo MLX quantizado. E isso já é muito.
Por que isso é mais interessante do que o ajuste fino normal
O ajuste fino normal responde à pergunta: como tornar o modelo melhor em média na tarefa? Nossa abordagem responde a outra pergunta: o que uma camada quantizada específica faz, como ela é organizada na representação exata e é possível alterá-la localmente sem perder o controle de cada etapa? Este é um nível diferente de acesso. Não 'ajustar o comportamento do modelo', mas analisar sua mecânica linear interna até o nível dos códigos de quantização. É por isso que este ramo de IA não cresceu de MLOps, mas da criptoanálise. Porque lá e aqui a tarefa é a mesma: parar de acreditar na caixa preta e substituir a fé por uma estrutura observável.
Conclusão
Se formularmos de forma muito breve, o seguinte aconteceu. Pegamos gpt-oss-20b-TurboQuant-MLX-8bit e adicionamos a ele não 'outro script de IA', mas toda uma infraestrutura exata: ponte para .safetensors, cache de calibração, captura de ativação BF16, otimização por bloco restrita, patch seguro, validação de holdout, verificação de fumaça de runtime. O resultado confirmado no estágio atual é duplo: a camada do roteador realmente permite uma correção local significativa, e o efeito é transferido para o holdout; o modelo offline do patch e a semântica real do runtime MLX ainda não coincidem totalmente, e o sistema é capaz de detectá-lo honestamente. O que significa que hoje nosso sistema já é capaz de fazer não apenas o diagnóstico forense criptográfico, mas também o mesmo dentro de uma rede neural quantizada: selecionar uma camada, formalizá-la como um objeto afim, corrigi-la localmente e verificar se o próprio ambiente de execução não está nos enganando. É aqui que a IA deixa de ser 'a magia do modelo' e se torna um objeto de engenharia de diagnóstico preciso.
Pequeno pós-escrito
Este trabalho não é sobre 'melhoria mágica da LLM'. É sobre outra coisa: como transferir a disciplina da criptoanálise para a IA e aprender a trabalhar com um modelo quantizado com a mesma rigorosidade com que trabalhamos com protocolos de assinatura. Ou seja, não 'acreditar que algo está acontecendo por dentro', mas ver, medir, corrigir e verificar.
Da Criptoanálise à AI-Forensics:
Introdução
Em um artigo anterior, demonstrei como a assinatura Schnorr / MuSig2 pode ser vista não como uma 'caixa preta', mas como um sistema de estruturas afins observáveis: através de uma rigorosa ponte de associação BIP340, famílias de nonces ocultos, métricas de compressão/conectividade e linearização de assinaturas parciais MuSig2. Isso muda a ótica: em vez de 'acreditarmos no protocolo', começamos a decompô-lo em blocos matemáticos verificáveis.
O próximo passo foi inesperado, mas lógico. Transportamos a mesma metodologia para a IA. Não no sentido de 'pegamos uma LLM e começamos a ajustá-la'. Mas no sentido de: pegamos um modelo MLX quantizado e começamos a investigar sua matemática interna da mesma forma que antes investigávamos as assinaturas.
O objeto do experimento foi uma distribuição local: gpt-oss-20b-TurboQuant-MLX-8bit. Não alteramos a arquitetura do modelo, não reescrevemos a atenção e não nos envolvemos no ajuste fino clássico. Fizemos outra coisa: aprendemos a ler .safetensors como uma estrutura precisa; construímos um cache de calibração determinístico; começamos a capturar ativações BF16 reais de camadas específicas; reduzimos a correção local de pesos a uma tarefa limitada de otimização de inteiros; fizemos uma gravação segura do patch de volta no modelo; e adicionamos uma verificação de fumaça que verifica se a matemática offline corresponde ao runtime MLX real.
O principal resultado deste artigo soa assim: não 'melhoramos o modelo com mágica', mas construímos um pipeline exato de AI-forensics, no qual a camada quantizada deixa de ser uma caixa preta e se torna um objeto observável, verificável e corrigível localmente.
Por que a transição de Schnorr para IA é natural
Em criptografia, tudo começou com uma ideia muito simples: se um objeto permite uma normalização rigorosa, então ele pode não apenas ser usado, mas também ser investigado como uma geometria de parâmetros ocultos. Para a assinatura Schnorr, a relação básica tem a forma: y = xG + rH, onde: x - chave privada, r - nonce, c - desafio, y - escalar da assinatura. Isso não é mais 'a magia da assinatura', mas uma estrutura linear.
Em IA, demos o mesmo passo. Paramos de olhar para o modelo como uma função 'prompt text' e descemos mais baixo - para o lugar onde sua álgebra linear interna vive: códigos quantizados, escala/viés, ativações de entrada, saídas de referência da camada linear. Ou seja, a questão mudou. Não: 'O modelo responde bem ou mal?' Mas: 'É possível representar uma camada quantizada específica como um objeto afim preciso, observar seu comportamento e corrigi-lo localmente sem destruir todo o modelo?' Isso é AI-forensics.
O que exatamente pegamos
A base foi a distribuição MLX: gpt-oss-20b-TurboQuant-MLX-8bit. Estávamos interessados em duas camadas específicas do primeiro bloco: model.layers.0.self_attn.q_proj.weight e model.layers.0.mlp.router.weight. Por que elas? Porque este é um bom teste para dois cenários diferentes: uma camada que pode ser muito 'rígida' para um patch significativo sem uma referência externa; uma camada que, por outro lado, permite a correção local. É nesse contraste que o valor do método se manifesta.
O que exatamente mudamos
É importante consertar imediatamente: não alteramos a arquitetura do modelo. Não alteramos o 'cérebro do modelo', mas a maneira como trabalhamos com ele. Era .safetensors como um contêiner opaco; pesos quantizados como 'algo dentro do runtime'; avaliação do modelo apenas pela saída de texto final. Tornou-se acesso preciso à representação de peso bruto; alocação de códigos de quantização, escala e viés; captura de runtime da entrada e saída de uma camada linear específica; otimização de inteiros local; gravação segura do patch de volta; uma verificação obrigatória de que a matemática offline não diverge da execução real.
Simplificando: transformamos a camada quantizada de um 'detalhe opaco do modelo' em um objeto de engenharia de diagnóstico.
Passo 1. Ponte exata para .safetensors
A primeira coisa que tivemos que fazer foi escrever uma ponte para a quantização MLX. Ele pode: encontrar o tensor certo no modelo; ler sua representação bruta; extrair códigos quantizados; ler as escalas e vieses BF16; se necessário, gravar códigos alterados de volta. Este é um ponto importante. Enquanto os pesos do modelo são percebidos como um 'blob pronto', nenhum trabalho preciso pode ser feito com eles. Primeiro, você precisa implantar este blob em uma estrutura matemática normal.
Passo 2. Cache de calibração determinístico
O próximo passo é o cache de calibração. Reunimos um conjunto estável de exemplos com antecedência: Parâmetro Valor Total de exemplos 768 Split general 512 Split logic 256 Tamanho do shard 128 Política de captura last-token Tipo de ativações BF16. Por que isso é necessário? Para que cada experimento subsequente seja reproduzível. Não 'parece melhor', mas: aqui está o mesmo conjunto, aqui está a mesma camada, aqui está a mesma entrada, aqui está a mesma saída de referência, aqui está a mesma métrica de erro. Sem isso, tudo se transforma rapidamente em narrativa.
Passo 3. Captura de ativações reais
Depois disso, adicionamos a captura de runtime para camadas lineares específicas. Para cada exemplo selecionado, foram salvos: pre_linear_input e linear_output_reference. E precisamente para o último token. Isso é muito importante. Não simulamos a camada separadamente do modelo, mas a removemos do MLX-runtime real. Ou seja, trabalhamos não com álgebra linear abstrata, mas com dados que o modelo realmente gera por si só.
Modelo matemático da camada quantizada
Agora você pode escrever a camada na forma de uma fórmula normal. Deixe a linha de pesos ser dividida em blocos de comprimento k. Para a linha W e o bloco w, denotamos: q - vetor de códigos quantizados de comprimento k; s - escala; b - viés. Então, o bloco de pesos dequantizado é definido como w = s(q - b) + b, onde 1 é um vetor de uns de comprimento k. Se o vetor de entrada para o exemplo x for dividido nos mesmos blocos: x = [x1, x2, ..., xn], então a saída na coordenada i é igual a yi = wiTxi, ou, após a substituição da dequantização, yi = si(qiTxi - biTxi) + biTxi. É aqui que a principal ponte aparece. A camada quantizada deixa de ser um 'conjunto de bytes incompreensíveis' e se torna um sistema afim sobre códigos discretos.
O que exatamente otimizamos
Para o bloco selecionado, estamos procurando um novo vetor de código q', que reproduza melhor a saída de referência, mas não se afaste muito do original. A tarefa de otimização tem a forma: minimize ||Wq' - y||^2 + λ||q' - q||^2, com restrições q' ∈ Z^k e |q'i - qi| <= δ. Onde: q - códigos originais do bloco; λ - coeficiente de regularização; δ - alteração máxima permitida de um código. Em nossos experimentos para a camada do roteador, foram usados: Parâmetro Valor Tamanho do bloco 64 Ridge lambda 16 Max code delta abs 8. Ou seja, o patch foi originalmente feito conservador: não reescrever a camada inteiramente; não alterar dezenas de milhares de parâmetros sem controle; não se afastar muito da estrutura original; consertar localmente e em uma janela limitada.
Teorema importante: por que não haverá um patch honesto sem uma referência externa
Esta é a fronteira chave do método. Teorema Se usarmos a camada quantizada atual como meta, então qualquer busca exata por um patch dá um ótimo trivial: não mude nada. Ideia Deixe o estado inicial da camada ser definido pelo trio: W, q, y, e deixe a função de erro ter a forma E(q') = ||Wq' - y||^2, onde: q' - qualquer configuração admissível; q' = q; o zero é alcançado apenas no ponto q' = q. Então, o mínimo já é alcançado no estado inicial, porque você não pode ir abaixo de zero. Conclusão Portanto, se tentarmos 'melhorar' a camada, usando esta camada como meta, então a melhor estratégia é não mudar nada. Conclusão Para que um patch não-identidade seja matematicamente significativo, é necessária uma referência externa: ativações de runtime reais; saída de referência; um holdout separado. É por isso que em nosso sistema o pipeline é construído em torno da captura e do holdout, e não em torno da auto-comparação do modelo consigo mesmo.
O que a auditoria q_proj mostrou
O primeiro candidato a teste foi a camada model.layers.0.self_attn.q_proj.weight. Executamos uma auditoria exata nela. Quadro estrutural Métrica Valor Total de linhas 4096 Largura decodificada 2880 Blocos por linha 45 Total de blocos 184320 Linhas únicas 4096 Linhas repetidas 0 Blocos únicos 184320 Blocos repetidos 0 Pares de blocos adjacentes exatamente iguais 0. Esta é uma tabela muito reveladora. A camada provou ser estruturalmente 'rígida': sem repetições triviais; sem clones de blocos; sem simetrias exatas baratas; sem compressão pronta que pudesse ser facilmente usada para patch. Como resultado, a conclusão final sobre q_proj foi dura, mas correta: Conclusão sobre q_proj Valor Identidade de auto-alvo ótimo Verdadeiro Referência externa necessária Verdadeiro Patch não-identidade justificado Falso Candidatos a patch exatos encontrados 0. E este é um bom resultado. Porque o sistema não 'inventou uma melhoria', mas provou o limite de aplicabilidade do método.
Onde o patch realmente funcionou: o roteador
Uma história completamente diferente aconteceu com a camada model.layers.0.mlp.router.weight. Para ele, um pipeline completo foi construído: cache de calibração, captura de ativação de runtime, otimização LWO por bloco, validação de holdout, patch seguro, verificação de fumaça. Parâmetros do experimento Parâmetro Valor Modelo gpt-oss-20b-TurboQuant-MLX-8bit Camada model.layers.0.mlp.router.weight Train shard general_0000_0128 Holdout shard logic_0000_0128 Contagem de amostras de treinamento 4 Contagem de amostras de holdout 4 Tamanho do bloco 64 Ridge lambda 16 Max code delta abs 8
Resultado no treinamento
No train-shard, a melhoria foi quase perfeita. Métrica Valor Baseline MSE 0.022966404894191328 Patched MSE 3.000931005970632e-11 Ganho MSE 0.022966404864182017 Blocos alterados 571 Códigos alterados no total 9067. Neste ponto, seria fácil dizer: 'pronto, curamos a camada'. Mas esta seria a conclusão errada. O treinamento pode quase sempre ser melhorado. A principal questão é se o efeito é transferido ainda mais.
Verificação no holdout
É aqui que começa o mais interessante. Métrica Valor Baseline MSE 0.022778386753429913 Patched MSE 4.3748027306868276e-05 Ganho MSE 0.022734638726123045 Taxa de transferência 0.9899084711155454 Holdout melhora Verdadeiro Suspeita de overfitting Falso. Ou seja, a melhoria foi quase totalmente transferida para um shard separado. Você pode escrever isso de forma muito breve: MSE_holdout_patched / MSE_holdout_baseline = 0.00192. Isso não se parece com um acerto aleatório ou ajuste para quatro pontos. Isso significa que o sistema realmente encontrou uma correção local que carrega um efeito estável.
Patch seguro: por que isso não é apenas um relatório bonito
Após calcular o patch, ele também precisava ser gravado de volta no modelo. Para isso, um fluxo de trabalho de patch seguro foi implementado: salvar backup; empacotar novos códigos em U32; gravá-los em .safetensors; reler e verificar a correspondência exata. Resultado da gravação Métrica Valor Blocos alterados 571 Códigos alterados no total 9067 Palavras brutas u32 alteradas 3335 Gravação aplicada Verdadeiro Correspondência exata de leitura Verdadeiro. Ou seja, o sistema é capaz não apenas de calcular o patch, mas também de implementá-lo corretamente no arquivo do modelo real. É aqui que começa a engenharia, e não apenas a pesquisa em papel.
A parte mais honesta de toda a história: verificação de fumaça
Após gravar o patch, uma verificação de fumaça de runtime foi executada. E é aqui que o sistema mostrou por que a verificação rigorosa é necessária. Verificação de fumaça: Geral Métrica Valor Linhas exatas de entrada 4 / 4 Linhas exatas de saída 0 / 4 MSE de runtime de entrada vs referência 0.0 MSE de runtime de saída vs referência 0.023193681612610817 Valores BF16 brutos alterados de saída 128 Verificação de fumaça: Lógica Métrica Valor Linhas exatas de entrada 4 / 4 Linhas exatas de saída 0 / 4 MSE de runtime de entrada vs referência 0.0 MSE de runtime de saída vs referência 0.021752476692199707 Valores BF16 brutos alterados de saída 128. O que isso significa? Muito simples: a entrada na camada é reproduzida perfeitamente; mas a saída real do runtime após a gravação não correspondeu à referência offline, apesar do forte resultado nos relatórios do solucionador. À primeira vista, isso parece uma má notícia. Na verdade, o contrário. Isso significa que o sistema é capaz de detectar a discrepância entre: o modelo de dequantização offline, e a semântica real da execução no MLX runtime. Ou seja, ele não apenas 'gera patches', mas é capaz de capturar o momento em que a bela matemática deixa de corresponder à realidade da execução. Esta é uma capacidade muito importante.
O que realmente mudamos no modelo
Para não exagerar com as formulações, vou consertar com cuidado. Nós não mudamos: a arquitetura do modelo; o número de camadas; o mecanismo de atenção; o tokenizador; o pipeline de inferência de alto nível. Nós mudamos a lógica de trabalhar com suas camadas quantizadas internas: adicionamos a leitura precisa de códigos; adicionamos análise por blocos; adicionamos captura de ativação BF16; adicionamos patching de inteiros restritos; adicionamos gravação segura de volta; adicionamos uma verificação de realidade pós-patch. Ou seja, na verdade, transformamos a distribuição MLX de uma 'caixa pronta' em um sistema que pode ser instrumentado, diagnosticado e corrigido cirurgicamente.
O que nosso sistema agora pode fazer
Se juntarmos tudo, obtemos um mapa de capacidade bastante forte. 1. Auditoria exata de camadas quantizadas O sistema é capaz de analisar a representação interna do peso no nível: códigos U32, decodificação uint8, escala/viés BF16, geometria de bloco. 2. Captura de runtime do modelo ao vivo Ele é capaz de remover as entradas e saídas reais da camada linear no MLX-runtime real, e não em um simulador. 3. Correção de inteiros local Ele é capaz de procurar um patch limitado para blocos específicos sem destruir toda a camada. 4. Patching seguro Ele é capaz de gravar a correção de volta em .safetensors com controle de leitura. 5. Validação de holdout Ele é capaz de distinguir a melhoria real do re-treinamento em um pequeno shard de calibração. 6. Detecção de incompatibilidade de runtime Ele é capaz de detectar que o patch offline é bonito, mas o ambiente de execução o interpreta de forma diferente. E esta, talvez, seja uma das capacidades mais fortes do sistema no estágio atual.
O que ainda não afirmamos
Para que o artigo permaneça de engenharia, e não publicitário, também fixarei as limitações. Nós ainda não afirmamos que: qualquer camada pode ser corrigida com o mesmo sucesso; q_proj já foi melhorado - não, lá o sistema honestamente encontrou o limite do método; a semântica de runtime MLX já foi totalmente decodificada; o ramo de IA já está fortalecendo a recuperação criptoanalítica de ponta a ponta; todo o ramo de lattice para IA já está pronto para produção. Mas podemos muito bem afirmar outra coisa: uma infraestrutura de AI-forensics exata funcional foi construída para um modelo MLX quantizado. E isso já é muito.
Por que isso é mais interessante do que o ajuste fino normal
O ajuste fino normal responde à pergunta: como tornar o modelo melhor em média na tarefa? Nossa abordagem responde a outra pergunta: o que uma camada quantizada específica faz, como ela é organizada na representação exata e é possível alterá-la localmente sem perder o controle de cada etapa? Este é um nível diferente de acesso. Não 'ajustar o comportamento do modelo', mas analisar sua mecânica linear interna até o nível dos códigos de quantização. É por isso que este ramo de IA não cresceu de MLOps, mas da criptoanálise. Porque lá e aqui a tarefa é a mesma: parar de acreditar na caixa preta e substituir a fé por uma estrutura observável.
Conclusão
Se formularmos de forma muito breve, o seguinte aconteceu. Pegamos gpt-oss-20b-TurboQuant-MLX-8bit e adicionamos a ele não 'outro script de IA', mas toda uma infraestrutura exata: ponte para .safetensors, cache de calibração, captura de ativação BF16, otimização por bloco restrita, patch seguro, validação de holdout, verificação de fumaça de runtime. O resultado confirmado no estágio atual é duplo: a camada do roteador realmente permite uma correção local significativa, e o efeito é transferido para o holdout; o modelo offline do patch e a semântica real do runtime MLX ainda não coincidem totalmente, e o sistema é capaz de detectá-lo honestamente. O que significa que hoje nosso sistema já é capaz de fazer não apenas o diagnóstico forense criptográfico, mas também o mesmo dentro de uma rede neural quantizada: selecionar uma camada, formalizá-la como um objeto afim, corrigi-la localmente e verificar se o próprio ambiente de execução não está nos enganando. É aqui que a IA deixa de ser 'a magia do modelo' e se torna um objeto de engenharia de diagnóstico preciso.
Pequeno pós-escrito
Este trabalho não é sobre 'melhoria mágica da LLM'. É sobre outra coisa: como transferir a disciplina da criptoanálise para a IA e aprender a trabalhar com um modelo quantizado com a mesma rigorosidade com que trabalhamos com protocolos de assinatura. Ou seja, não 'acreditar que algo está acontecendo por dentro', mas ver, medir, corrigir e verificar.
