Resumo Técnico: Program-as-Weights (PAW)

1. Definição do Problema

Muitas tarefas de programação do mundo real resistem à implementação precisa baseada em regras. Estas "funções difusas" — como filtrar linhas de log por urgência, reparar JSON malformado ou classificar resultados de busca por intenção — são intuitivas para humanos, mas frágeis quando implementadas com regras simbólicas nítidas (ex: expressões regulares) devido a ruídos, erros de digitação e casos extremos.

Atualmente, os desenvolvedores delegam essas tarefas para APIs de Grandes Modelos de Linguagem (LLMs). Embora convenientes, essa abordagem acarreta altos custos, introduz latência, compromete a reprodutibilidade (devido a atualizações silenciosas de modelos pelos provedores) e impede que o software seja autossuficiente. O artigo propõe a necessidade de um paradigma que retenha a flexibilidade dos LLMs para tarefas difusas, permitindo simultaneamente a execução local, reprodutível e de baixo custo.

2. Metodologia: Program-as-Weights (PAW)

Os autores propõem o Program-as-Weights (PAW), um paradigma onde uma função difusa é compilada de uma especificação em linguagem natural para um artefato neural compacto e executável localmente. O sistema desacopla o "trabalho pesado" de compreender a especificação do "trabalho cotidiano" de executar a função.

Arquitetura Central

O pipeline PAW consiste em três componentes principais:

1. O Compilador: Um modelo neural que mapeia uma especificação do usuário ($s$) para um programa ($p$).
2. O Programa ($p$): Um artefato híbrido que compreende:
   • Componente Discreto ($p_{discrete}$): Um "pseudo-programa" em linguagem natural (uma reiteração da tarefa mais exemplos de entrada-saída representativos). Isso protege o intérprete da ambiguidade e de erros de digitação na especificação original.
   • Componente Contínuo ($p_{continuous}$): Um módulo de Ajuste Fino de Parâmetros Eficientes (PEFT) (especificamente LoRA ou prefix-tuning KV cache) que re-ajusta um intérprete congelado para a tarefa específica.
3. O Intérprete: Um modelo de linguagem pequeno e congelado (ex: Qwen3-0.6B) que executa o programa. Ele carrega o módulo PEFT e o pseudo-programa, processa a entrada do usuário e gera a saída de forma autorregressiva.

O Pipeline de Compilação

O processo de compilação envolve duas etapas, ambas utilizando um modelo Qwen3 4B:

1. Pseudo-Compilador ($C_p$): Um modelo pronto para uso, não treinado, orientado por um template de reescrita de tarefa. Ele converte a especificação bruta do usuário em um pseudo-programa limpo contendo uma descrição clara da tarefa e exemplos de poucos disparos (few-shot).
2. Compilador PEFT ($C_{PEFT}$): Um modelo treinado (especificamente um compilador LoRA na atual melhor instância) que recebe a especificação e o pseudo-programa como entrada. Ele emite os pesos PEFT contínuos (matrizes LoRA) ao mapear seus estados ocultos através de um mapeador LoRA.
   • O mapeador agrega estados ocultos de camadas específicas do compilador, realiza o pooling e os projeta em coeficientes de mistura. Esses coeficientes compõem matrizes LoRA ($A, B$) sobre um conjunto de bases aprendíveis compartilhadas, injetando aproximadamente 38,5 milhões de parâmetros no intérprete por função.

Treinamento

Apenas o compilador PEFT e o mapeador LoRA são treinados. O pseudo-compilador e o intérprete permanecem congelados. O objetivo de treinamento é maximizar a verossimilhança da saída alvo dado o intérprete congelado, o pseudo-programa gerado e os pesos LoRA gerados. Este é um objetivo supervisionado único usando o dataset FuzzyBench.

3. Principais Contribuições

Dataset FuzzyBench

Os autores lançam o FuzzyBench, um dataset de 10 milhões de exemplos projetado para treinar métodos do tipo PAW.

• Construção: Gerado usando gpt-5.2 em um pipeline de duas etapas (geração de especificação seguida por geração de pares de entrada/saída).
• Cobertura: Construído incrementalmente ao longo de 29 versões temáticas, cobrindo mais de 800 categorias de tarefas difusas (ex: processamento de texto, reparo de formato, uso de ferramentas agênticas, verificação de segurança).
• Verificação: Inclui um conjunto de teste verificado onde dois modelos fortes devem concordar com a saída para filtrar alvos ambíguos. Também inclui versões perturbadas por ruído (erros de digitação, erros gramaticais, ambiguidade) para avaliação de robustez.

O Sistema PAW

• Text-to-LoRA Instantiation: Os autores demonstram que gerar adaptadores LoRA a partir de especificações de texto supera o prefix-tuning e o prompting direto.
• Generalidade de Modalidade: A abstração estende-se a tarefas condicionadas por imagem ao trocar apenas o compilador por um modelo de linguagem-visão (Qwen3-VL), mantendo o mesmo intérprete baseado em texto.
• Interface do Desenvolvedor: Uma API prática (paw.compile, paw.function) que permite aos desenvolvedores compilar especificações em arquivos de pesos serializáveis (formato GGUF) que rodam inteiramente offline.

4. Resultados Experimentais

Desempenho no FuzzyBench

• Acurácia: Um intérprete de 0,6 bilhão de parâmetros executando programas PAW alcança 73,78% de correspondência exata no FuzzyBench.
• Comparação: Isso supera o prompting direto do Qwen3-32B (68,70%) e excede significativamente o desempenho do modelo base de 0,6B com prompting direto (9,84%).
• Eficiência: O sistema PAW utiliza aproximadamente 1/50 da memória de inferência do modelo de 32B (~1,2 GB vs. ~60 GB).
• Latência: Em um MacBook M3, o sistema quantizado roda a 30 tokens/segundo.

Robustez

• O PAW mostra alta robustez a especificações ruidosas (erros de digitação, erros gramaticais). O pseudo-programa discreto atua como um denoiser; quando a especificação ruidosa bruta é alimentada diretamente ao intérprete (ignorando o pseudo-programa), o desempenho cai significativamente (4,5 pontos em erros de digitação pesados), enquanto o pipeline completo do PAW degrada apenas levemente.

Estudos de Ablação

• Necessidade do Compilador: O PAW supera o ajuste fino total do modelo base de 0,6B em 15,4 pontos percentuais e os LoRAs fixos em 21,7 pontos, confirmando que o ganho provém do LoRA consciente da especificação e gerado pelo compilador.
• Arquitetura: O design mais simples do mapeador LoRA (mean-pooling de estados ocultos em um único vetor, MLP raso, bases compartilhadas) provou ser superior às variantes mais complexas e "mais expressivas".
• Quantização: Quantizar a base para Q6_K e o adaptador LoRA para Q4_0 resulta em perda de acurácia insignificante em comparação ao bf16, com uma pegada total de disco de ~507 MB.

Casos de Uso

O artigo valida o paradigma em cinco casos de uso:

1. Monitoramento de logs orientado a eventos: Classificação local da urgência de logs.
2. Navegação de site baseada em intenção: Classificação da intenção do usuário sem chamadas de API.
3. Reclassificação de busca semântica: Reclassificação de resultados de busca por palavra-chave por intenção.
4. Pré-processamento de agentes: Um pipeline de chamada de ferramenta pontuando 93% no TOOLCALL-15.
5. Geração criativa: Um jogo multilíngue de adivinhação de palavras (Alien-Taboo) servido por um intérprete de 0,6B.

5. Significância e Alegações

O artigo enquadra o PAW como um passo concreto em direção a um "futuro de modelos pequenos", onde os modelos de fundação atuam como construtores de ferramentas em vez de resolvedores de problemas por entrada.

• Mudança de Paradigma: Em vez de invocar um modelo massivo para cada consulta, o trabalho pesado (compreender a especificação difusa) acontece uma única vez no tempo de compilação. O artefato resultante é um "binário neural" pequeno, reutilizável, versionado e distribuível.
• Execução Local: O PAW permite que a lógica difusa complexa rode inteiramente offline em hardware de consumo (ex: MacBooks, navegadores via WebAssembly), abordando questões de custo, privacidade e reprodutibilidade associadas às APIs de LLM na nuvem.
• Modularidade: A arquitetura "um runtime, muitos programas" permite que um único intérprete pequeno sirva inumeráveis funções difusas através da troca rápida (hot-swapping) de adaptadores PEFT.

Os autores mantêm a modéstia quanto às limitações, observando que o sistema atualmente lida com funções difusas de etapa única (raciocínio de múltiplas etapas é um trabalho futuro), depende de dados de treinamento sintéticos e requer o retreinamento do compilador se a arquitetura do intérprete mudar. No entanto, eles argumentam que, para a classe de tarefas que resistem à implementação simbólica mas não exigem contexto ou raciocínio massivos, o PAW oferece uma alternativa viável, eficiente e local às LLMs baseadas em API.