把模糊函数编译成权重：Program-as-Weights 想改变软件运行时

最反直觉的数字是这样的：一个 0.6B 的 Qwen3 小模型，在执行编译好的 PAW 程序后，FuzzyBench verified test 的 exact match 达到 73.78%；同一批任务上，直接提示 Qwen3-32B 是 68.70%。前者推理内存约 1.2GB，后者约 60GB。量化以后，它还能用 430MB 左右的共享 base 加每个函数 23MB 左右的 LoRA adapter，在 MacBook M3 上跑到约 30 tokens/s。

如果只看这个数字，很容易误解成“小模型终于打败大模型”。但这不是论文真正想说的事。PAW 没有证明 0.6B 模型突然具备了 32B 模型的通用智能。它证明的是另一件更像软件工程的事：当一个模糊函数会被反复调用时，我们不一定要每次都让大模型重新理解同一份说明书。可以先把说明书编译成一个小小的神经程序，再让本地小解释器反复执行。

所谓模糊函数，就是那类人类一眼能判断、代码却很难写稳的函数。比如日志里哪一行值得报警，损坏的 JSON 应该怎么修，搜索结果是否符合用户真实意图。这些任务不是没有规则，而是规则边界太软：错别字、格式漂移、语气、上下文都会改变答案。工程师今天最常见的做法，是在业务代码里直接调用 LLM API。这个方案方便，但代价也很硬：贵、慢、依赖网络、版本不可控。

PAW 的核心转向，是把大模型从“每次请求的解题者”改成“每个函数的工具建造者”。开发者先用自然语言写出函数规格，编译器读一次规格，生成一个可复用的权重程序；之后每个输入进来，都由冻结的小解释器加载这个程序，在本地给出输出。类比传统编程，这不是每次运行都请编译器解释源码，而是编译一次，运行很多次。差别只在于，这里的可执行文件不是机器码，而是一段 pseudo-program 加一组 LoRA 权重。

不是提示词缓存，也不是普通微调

先排除三个容易混在一起的答案。

PAW 不是提示词缓存。提示词缓存保存的是文本上下文，后续请求仍然靠模型读 prompt 来理解任务。PAW 保存的是混合程序：一半是可读的 pseudo-program，一半是会临时改写解释器内部线性层的 PEFT 权重。

PAW 也不是给每个任务单独微调一个模型。普通微调要为目标任务做梯度下降；PAW 的训练发生在编译器上。新函数出现时，不再训练解释器，只跑一次编译器前向传播。

它还不是让大模型写 Python。符号代码适合边界清楚的逻辑，但很多 fuzzy function 的难点恰好是边界写不清。用 if-else 解释“这条日志是否重要”“这个候选网页是否匹配意图”，很快会落入无穷边界条件。PAW 的目标语言不是 Python，而是权重：把那些难以符号化的行为偏置放进连续参数里。

这三层排除之后，论文的位置就清楚了：PAW 不是又一个 prompt 技巧，而是在问，模糊逻辑能不能像普通软件函数一样被编译、缓存、分发和离线运行。

编译器和解释器各做什么

PAW 的系统有三块。

第一块是 pseudo compiler。它是一个未训练的 Qwen3-4B-Instruct，只做一件事：把用户随手写的规格重写成干净的 pseudo-program，通常包含任务重述、输出约束和若干输入输出示例。真实开发者写规格不会像 benchmark 一样整洁；pseudo-program 相当于把噪声先整理成小模型更容易执行的说明。

第二块是 LoRA compiler。它同样从 Qwen3-4B 初始化，但经过训练。它读取原始 spec 和 pseudo-program，从若干层 hidden states 中抽取信息。LoRA mapper 再把这些信息投影成共享 LoRA basis 的混合系数。这里不是为每个函数自由生成巨大的矩阵，而是在 64 组共享低秩基上调配比例。日常类比像调音台：底层旋钮固定，编译器为每首歌调出不同混音。技术上，每个 fuzzy function 注入约 38.5M 个 LoRA 参数，量化后形成约 23MB 的程序文件。

第三块是 frozen interpreter。主实验用 Qwen3-0.6B。执行时，它加载对应 LoRA，把 pseudo-program 拼到输入前面，然后生成答案。解释器本身不更新，所以同一个本地 runtime 可以热切换许多 PAW 程序：日志分类、JSON 修复、搜索重排，都是不同程序。

这就是论文最重要的架构切分：编译器负责昂贵的一次性理解，解释器负责便宜的重复执行。

FuzzyBench：这篇论文真正昂贵的地基

如果没有训练数据，PAW 只是一个漂亮抽象。研究者为此构建了 FuzzyBench：1000 万条 fuzzy function 样本。每条样本是一个三元组：函数规格、输入、目标输出。数据由 gpt-5.2 生成：先生成自然语言规格，再为每个规格生成 8 组输入输出对。

这个数据集的关键不是数量，而是切分方式。训练、验证、测试按 spec 切分，测试集里的函数说明在训练时完全没见过。为了降低标签歧义，研究者还构建了 verified test set：只有 gpt-5.2 和 gpt-5-mini 输出一致的样本才保留。PAW 测的不是“记住类似输入”，而是“面对没见过的新函数说明，能不能编译出可执行行为”。

FuzzyBench 分 29 个版本逐步扩展，覆盖 800 多个子类，归为七大任务家族。数据生成模型自身在该测试上达到 96.09%，gpt-5-mini 为 91.87%，这给 PAW 的上限划出了一条现实边界：它还远没有达到 frontier 模型的绝对精度，真正赢的是成本、部署和复用形态。

关键结果：赢在哪里，不赢在哪里

主结果最有冲击力：PAW 的 0.6B 解释器达到 73.78%，超过直接提示 Qwen3-32B 的 68.70%。但更能说明问题的是同基座对照。Qwen3-0.6B 直接 prompt 只有 9.84%；固定 LoRA rank 64 是 52.10%；全量微调是 58.40%。这排除了一个简单解释：收益不是“用了 LoRA”本身，而是“为每个函数动态生成 LoRA”。

论文还比较了早期 prefix-tuning 方案和当前 Text-to-LoRA。在相同训练计算下，prompting 是 9.8%，prefix-tuning 到 50.4%，Text-to-LoRA rank 18 到 56.5%，rank 64 到 65.7%。这说明“权重程序”不是只靠某个偶然实现成立，但 LoRA 是当前文本任务上更强的程序形态。

噪声实验解释了 pseudo-program 为什么必要。clean 情况下，让解释器看 pseudo-program 相比直接看 raw spec 只高约 1.6 个点；但在 heavy typo 下差距扩大到 4.5 个点。它不是装饰性的润色器，而是一个降噪前端。

多模态实验更像一个概念验证。研究者把文本编译器换成 Qwen3-VL-4B，解释器仍然是文本 Qwen3-0.6B。图像信息在编译时被视觉语言编译器编码进 LoRA，运行时小解释器不直接看像素。PAW LoRA 在电路图、化学结构、乐谱等任务上超过多种 0.6B 到 4B VLM baseline；但在 Im2LaTeX 长结构输出上弱于 prefix-tuning 前身。这个反例说明，PEFT 形态仍然依赖任务类型。

真正的应用场景：反复调用的小判断

论文给了五个案例，最值得看的是它们共同的形状：都不是一次性复杂推理，而是会在软件里反复出现的小判断。日志监控里，PAW 在本地判断哪些输出值得提醒；意图导航里，它匹配页面内容和用户意图；搜索重排里，它给关键词召回的候选重新分档；ToolCall-15 案例里，10 个 PAW 函数组成流水线，报告达到 93%；猜词游戏里，每种语言一个 PAW 程序，同一个 0.6B 解释器热加载服务玩家回合。

这些案例说明 PAW 的甜点区：高频、低延迟、隐私敏感、规则难写、但单次判断不需要 frontier 模型的任务。它不适合替代所有大模型调用，却很适合把小模糊逻辑从 request path 上拿下来。

论文证明了什么，也没证明什么

论文证明了五件事。第一，大量单步 fuzzy functions 可以从自然语言规格编译成小模型可执行的权重程序。第二，动态生成的 per-function LoRA 明显强于直接 prompt、固定 LoRA 和全量微调。第三，pseudo-program 在噪声规格下有实际保护作用。第四，本地部署不是口号：量化 base、23MB adapter、MacBook M3 速度和 Python/JavaScript API 都已经跑通。第五，编译器-解释器抽象可以扩到部分图像条件任务。

它没有证明的东西也同样明确。所有评估都是 single-step；长程、多步、带状态的程序还没有验证。生成的 LoRA 不可解释，人能检查的只有 pseudo-program。compiler 和 interpreter 是耦合的，换解释器通常需要重新训练编译器。FuzzyBench 仍然是合成数据，外部真实任务验证才刚开始。最后，PAW 不追求最高精度；它赢的是可交付性和运行时经济性。

Big Picture：把模糊性从 API 调用变成软件工件

这篇论文最重要的反转，不在模型参数量，而在软件边界。

过去几年，很多产品默认把大模型放在 request path 上：用户点一次按钮，后端问一次 LLM；日志来一行，问一次 LLM；搜索重排一次，问一次 LLM。这个模式简单，但会把成本、延迟、隐私和版本漂移全部带进运行时。

PAW 提出另一种秩序：大模型像编译器一样，在开发或部署阶段工作；真正响应用户输入的是本地小 runtime 和已编译程序。未来的软件包里可能不只有 .py、.wasm、.so，还会有 .lora 这样的神经二进制。确定性逻辑仍然应该交给传统代码；但在日志重要性、意图匹配、格式修复、语义重排这些灰色地带，PAW 给出了一层介于 prompt 和代码之间的新对象。

它现在还很早。调试器缺失，安全模型粗糙，跨解释器 ABI 不存在，程序行为的可解释性也很弱。但它提出的问题足够清楚：当越来越多软件逻辑不是硬规则，而是软判断时，我们究竟要把这些判断放在哪里？放在每次远程 API 调用里，还是编译成本地程序？

PAW 选择了后者。Program-as-Weights 这个名字像一个模型技巧，但它真正指向的是一种软件工程观：让大模型编译模糊性，让小模型执行模糊性，把不可写成规则的判断从在线服务变成可交付工件。