ProgramAsWeights：将英文函数描述编译为本地运行的神经程序

Given the recent interest in tools like Jev, I wanted to share ProgramAsWeights (PAW), an open-source research project I'm working on at the University of Waterloo.

You describe a text function in English, compile it into a reusable neural program, and run it locally, including on a CPU. For example:

This example uses our hosted compiler for compilation (you can host your own compiler if you have a GPU using our released model weights). Once the program and local runtime are downloaded, subsequent calls run on your machine without an external API.

The idea: separate compilation from inference

In many applications, the task stays fixed while the inputs keep changing. You define what makes an email urgent once, then apply that definition to thousands of emails.

There are two jobs here: understanding the function you want, and executing it repeatedly. Our idea is to train a larger model to generate the task-specific weights that let a smaller model do the second job.

The resulting function can be saved, distributed, and composed with ordinary code.

https://preview.redd.it/a5zxim8w8kqh1.png?width=2122&format=png&auto=webp&s=c009655b083bddd316687c2fdef0365c9334c82e

How it works

https://preview.redd.it/g47kgyqq8kqh1.png?width=2462&format=png&auto=webp&s=28d0ea86131954e870ed7da8abb006e267b6bce7

Our standard compiler uses a finetuned Qwen3-4B model to generate a LoRA adapter for a frozen Qwen3-0.6B model, which we call the interpreter. Different functions use different adapters with the same base interpreter.

A neural program contains two components:

• A LoRA adapter that specializes the interpreter for the task.
• A pseudo-program: a cleaned-up task description and a few input/output examples, generated at compile time and included in the interpreter’s prompt.

The adapter-generation mechanism is similar to text-to-LoRA (Charakorn et al., 2025).

To train the compiler, we use triples of (task description, input, output). The compiler generates an adapter from the task description and pseudo-program. We attach that adapter to the interpreter and maximize the likelihood of the correct output for the given input.

Gradients flow through the frozen interpreter into the compiler and its adapter-generating layers. The interpreter's base weights remain unchanged.

This is one of the parts I still find surprising: the same frozen 0.6B model can become much more useful just by changing the program we load onto it. We're training the compiler to discover how to specialize it.

After training, the standard compiler predicts adapter weights for a new specification directly. Compilation takes seconds, and the larger compiler is no longer needed when processing new inputs.

Results

We built FuzzyBench, a synthetic dataset of specification/input/output examples covering classification, extraction, parsing, format conversion, and other text functions. The train/validation/test split is by specification, so test specifications are unseen during compiler training.

On FuzzyBench, PAW with the 0.6B interpreter reaches 73.4% exact-match accuracy, compared with 68.7% for direct prompting of Qwen3-32B. Our first paper includes the other benchmarks, baselines, and ablations.

https://preview.redd.it/eylmemku8kqh1.png?width=1334&format=png&auto=webp&s=528adcbfab287f1f4028380399cfadf41040250f

A higher-accuracy compilation mode

Because the generated program contains a LoRA adapter, we can also use it as an initialization for further training.

Our follow-up, Compile by Training, does this automatically: teacher models synthesize task-specific examples, then we finetune the generated adapter for 100 steps. This takes roughly a minute in our deployment and produces the same reusable program format for the same local interpreter.

On FuzzyBench-Hard, a subset selected from specifications where the original PAW evaluation produced no exact matches, this reaches 83.6% semantic accuracy.

The two compilers offer different compile-time/accuracy tradeoffs. Both produce functions that run locally without teacher calls afterward.

Trying it and building on it

My recommended workflow is to handwrite a small validation set, compile a specification, and inspect the errors. Then revise the specification or try the Finetune compiler.

My longer-term hope is that large models can become tool builders: describe the function you need, get back a small neural program, and use it as part of your own software. This is what makes me excited about PAW beyond any individual benchmark.

I'd love to see people build on this, whether through better compilers, different interpreters, or applications we haven't considered. Happy to answer questions about the architecture, training details, and failure cases.

Papers

• Program-as-Weights: A Programming Paradigm for Fuzzy Functions
• Compile by Training: Turning Natural-Language Specifications into Local Neural Functions

Code and models

• Code
• compile-by-training
• Model weights

Demo: https://programasweights.com/playground