💬 NLP

Program-as-Weights: A Programming Paradigm for Fuzzy Functions

Dieses Paper stellt Program-as-Weights (PAW) vor, ein Paradigma, das natürliche Sprachspezifikationen in kompakte, lokal ausführbare neuronale Adapter kompiliert, wodurch ein kleiner, eingefrorener Interpreter in der Lage ist, die Leistung wesentlich größerer Foundation-Modelle zu erreichen und gleichzeitig die Inferenzkosten drastisch zu senken sowie die Offline-Ausführung zu ermöglichen.

Ursprüngliche Autoren: Wentao Zhang, Liliana Hotsko, Woojeong Kim, Pengyu Nie, Stuart Shieber, Yuntian Deng

Veröffentlicht 2026-07-03

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Wentao Zhang, Liliana Hotsko, Woojeong Kim, Pengyu Nie, Stuart Shieber, Yuntian Deng

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie haben einen sehr klugen, aber sehr teuren und langsamen Sternekoch (ein großes KI-Modell). Derzeit müssen Sie diesen Koch jedes Mal aufs Neue anrufen, wenn Sie hungrig sind. Sie müssen ihm das Rezept von Grund auf neu erklären, warten, bis er nachdenkt, und für jede Mahlzeit eine Gebühr bezahlen. Es funktioniert, aber es ist langsam, kostspielig und Sie können nicht kochen, wenn das Internet ausgefallen ist.

Das Papier „Program-as-Weights“ (PAW) schlägt eine völlig andere Art des Kochens vor. Anstatt den Sternekoch jedes Mal anzurufen, bitten Sie ihn einmalig, ein winziges, maßgeschneidertes Kochbuch speziell für dieses eine Gericht zu schreiben. Sobald das Buch geschrieben ist, können Sie es einem kleinen, günstigen, lokalen Küchenassistenten (einem winzigen KI-Modell) übergeben, der genau dieses Gericht sofort und kostenlos zubereiten kann – sogar ohne Strom (offline).

Hier ist die Aufschlüsselung des Papiers unter Verwendung einfacher Analogien:

1. Das Problem: „Vage“ Aufgaben

Einige Jobs sind für Menschen einfach, aber unmöglich mit strengen Regeln zu beschreiben.

Die Analogie: Stellen Sie sich vor, Sie versuchen, ein Regelwerk für die Frage „Wie erkennt man eine dringende E-Mail?“ zu schreiben. Man kann nicht einfach sagen: „Wenn sie ‚DRINGEND‘ sagt, markiere sie.“ Was ist, wenn dort steht: „Bis Ende des Tages benötigt!“? Oder „Mein Chef ruft an“? Menschen verstehen das sofort, aber Computer benötigen sehr spezifische, starre Anweisungen.
Die aktuelle Lösung: Entwickler lassen derzeit einfach den großen, teuren KI-Koch jede E-Mail lesen und entscheiden. Das ist langsam und teuer.
Die PAW-Lösung: Erstellen Sie eine „vage Funktion“ (fuzzy function) – ein maßgeschneidertes Werkzeug, das diese vagen, menschenähnlichen Anweisungen versteht.

2. Der Zaubertrick: „Einmal kompilieren, lokal ausführen“

Das Papier führt einen zweistufigen Prozess ein, der Program-as-Weights genannt wird.

Schritt 1: Der Compiler (Der Sternekoch, der das Kochbuch schreibt)
Sie beschreiben, was Sie wollen, in natürlicher Sprache (z. B. „Markiere E-Mails, die heute eine Unterschrift benötigen“). Ein großes KI-Modell (der Compiler) liest Ihre Beschreibung und gibt Ihnen nicht nur eine Antwort, sondern schreibt eine winzige, maßgeschneiderte Anleitung (ein „neuronales Programm“) speziell für diese Aufgabe.
- Was das Papier sagt: Dieser Compiler wandelt Ihre Beschreibung in natürlicher Sprache in eine kleine Datei (ca. 23 MB) um, die „Gewichte“ (mathematische Anpassungen) und ein kurzes „Pseudo-Programm“ (eine bereinigte, umformulierte Version Ihrer Anweisungen mit Beispielen) enthält.
Schritt 2: Der Interpreter (Der lokale Küchenassistent)
Sie nehmen diese winzige Datei und laden sie in ein kleines, eingefrorenes KI-Modell (den Interpreter), das auf Ihrem Laptop oder Smartphone lebt. Dieses kleine Modell ist wie ein allgemeiner Küchenassistent. Es weiß von sich aus nichts über das Kochen. Aber wenn Sie ihm das „maßgeschneiderte Kochbuch“ (die Gewichte) geben, weiß es sofort genau, wie es diese spezifische Aufgabe ausführt.
- Was das Papier sagt: Das kleine Modell (0,6 Milliarden Parameter) führt die Aufgabe lokal aus. Es muss nicht das Internet oder die große KI aufrufen.

3. Warum ist das besser?

Das Papier vergleicht dies mit der alten Methode:

Geschwindigkeit & Kosten: Die alte Methode (den großen KI aufzurufen) ist wie das Bestellen von Essen zum Mitnehmen bei jedem Hunger. Der neue Weg ist wie das Besitzen eines persönlichen Sous-Chefs, der Ihr Lieblingsrezept kennt. Das Papier behauptet, dass das kleine Modell 30-mal schneller läuft (30 Token pro Sekunde) auf einem Standard-MacBook und 50-mal weniger Speicher benötigt als das große Modell.
Zuverlässigkeit: Wenn das Internet ausfällt, hört die große KI auf zu arbeiten. Das PAW-System funktioniert offline, da das „Kochbuch“ direkt auf Ihrem Gerät gespeichert ist.
Reproduzierbarkeit: Bei der großen KI könnte das Unternehmen morgen heimlich das Rezept des Kochs ändern, und Ihre App funktioniert nicht mehr. Mit PAW haben Sie eine gespeicherte Datei. Sie wird genau das Gleiche tun, für immer, weil das „Rezept“ in dieser Datei festgeschrieben ist.

4. Was haben sie tatsächlich getestet?

Die Autoren haben nicht nur darüber gesprochen; sie haben einen massiven Trainingsplatz namens FuzzyBench (10 Millionen Beispiele dieser „vagen“ Aufgaben) gebaut und ihr System getestet.

Das Ergebnis: Ihr winziges lokales Modell (0,6B), wenn es das maßgeschneiderte „Kochbuch“ verwendet, schnitt besser ab (73,8 % Genauigkeit) als die direkte Abfrage des riesigen 32-Milliarden-Parameter-Modells (68,7 % Genauigkeit).
Das Konzept „Ein Laufzeit-Modell, viele Programme“: Stellen Sie sich einen kleinen Küchenassistenten vor. Sie können sein „Kochbuch“ in Sekunden austauschen. In einer Minute sortiert er E-Mails, in der nächsten repariert er fehlerhaften JSON-Code und in der nächsten spielt er ein Wortspiel. Er muss nicht neu trainiert werden; er lädt einfach ein neues Set an Gewichten.

5. Reale Beispiele aus dem Papier

Das Papier zeigt, wie dies in fünf spezifischen Szenarien funktioniert:

Log-Überwachung: Scannen von Computerprotokollen, um nur dann zu alarmieren, wenn etwas tatsächlich wichtig ist, und dabei das Rauschen zu ignorieren.
Website-Navigation: Verstehen, was ein Nutzer auf einer Website möchte, basierend auf seiner vagen Suche, ohne einen großen Server zu benötigen.
Such-Reranking: Eine Liste von Suchergebnissen nehmen und sie basierend auf der Absicht der Suche neu ordnen, nicht nur nach Schlüsselwörtern.
Tool Calling (Werkzeugaufruf): Einer KI helfen zu entscheiden, welches Werkzeug sie nutzen soll (wie einen Taschenrechner oder eine Karte) basierend auf der Anfrage eines Nutzers.
Wortspiele: Ausführen eines mehrsprachigen Worträtselspiels, bei dem die KI Wörter basierend auf Beschreibungen errät, alles auf einem kleinen Server.

Das Fazit

Das Papier argumentiert, dass wir uns von einer Welt weg bewegen, in der wir eine riesige, teure KI bitten, jedes einzelne Problem zu lösen, hin zu einer Welt, in der wir eine riesige KI bitten, einmalig ein kleines, maßgeschneidertes Werkzeug für uns zu bauen. Dann erledigt dieses kleine Werkzeug die Arbeit für immer, direkt auf Ihrem Gerät, günstig und schnell.

Wichtiger Hinweis: Das Papier beschränkt seine Ansprüche strikt auf diese textbasierten (und einige bildbasierten) Programmieraufgaben. Es behauptet nicht, dass dies für medizinische Diagnosen, Rechtsberatung oder andere hochsensiblen Anwendungen in der realen Welt funktioniert, noch behauptet es, dass das System in der Lage ist, komplexe, mehrstufige Probleme eigenständig durch logisches Denken zu lösen, ohne dass diese in diese einzelnen „Funktionen“ zerlegt werden.

Technisches Resümee: Program-as-Weights (PAW)

1. Problemstellung

Viele reale Programmieraufgaben lassen sich nicht durch präzise, regelbasierte Implementierungen lösen. Diese „unscharfen Funktionen“ (fuzzy functions) – wie etwa das Filtern von Log-Zeilen nach Dringlichkeit, das Reparieren von fehlerhaftem JSON oder das Ranking von Suchergebnissen nach Intention – sind für Menschen intuitiv, aber bei der Implementierung mit scharfen symbolischen Regeln (z. B. regulären Ausdrücken) aufgrund von Rauschen, Tippfehlern und Randfällen jedoch fragil.

Derzeit lagern Entwickler diese Aufgaben an Large Language Model (LLM) APIs aus. Während dies bequem ist, verursacht dieser Ansatz hohe Kosten, führt zu Latenz, untergräbt die Reproduzierbarkeit (aufgrund stiller Modell-Updates durch Anbieter) und verhindert, dass Software autark agieren kann. Das Paper postuliert die Notwendigkeit eines Paradigmas, das die Flexibilität von LLMs für unscharfe Aufgaben beibehält, während es gleichzeitig eine lokale, reproduzierbare und kosteneffiziente Ausführung ermöglicht.

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

Die Autoren schlagen Program-as-Weights (PAW) vor, ein Paradigma, bei dem eine unscharfe Funktion aus einer natürlichen Sprachspezifikation in ein kompaktes, lokal ausführbares neuronales Artefakt kompiliert wird. Das System entkoppelt die „schwere Arbeit“ des Verstehens der Spezifikation von der „täglichen Arbeit“ der Ausführung der Funktion.

Kernarchitektur

Die PAW-Pipeline besteht aus drei Hauptkomponenten:

Der Compiler: Ein neuronales Modell, das eine Benutzerspezifikation ( $s$ ) auf ein Programm ( $p$ ) abbildet.
Das Programm ( $p$ ): Ein hybrides Artefakt, bestehend aus:
- Diskreter Komponente ( $p_{discrete}$ ): Ein „Pseudo-Programm“ in natürlicher Sprache (eine Umformulierung der Aufgabe plus repräsentative Input-Output-Beispiele). Dies schützt den Interpreter vor Mehrdeutigkeiten und Tippfehlern in der ursprünglichen Spezifikation.
- Kontinuierlicher Komponente ( $p_{continuous}$ ): Ein Modul für effizientes Parameter-Fine-Tuning (PEFT) (speziell LoRA oder Prefix-Tuning KV-Cache), das einen eingefrorenen Interpreter speziell auf die Aufgabe feinjustiert.
Der Interpreter: Ein kleines, eingefrorenes Sprachmodell (z. B. Qwen3-0.6B), das das Programm ausführt. Er lädt das PEFT-Modul und das Pseudo-Programm, verarbeitet den Benutzereingang und generiert die Ausgabe autoregressiv.

Die Kompilations-Pipeline

Der Kompilationsprozess umfasst zwei Stufen, die beide ein 4B Qwen3 Modell nutzen:

Pseudo-Compiler ( $C_p$ ): Ein fertiges, untrained Modell, das mit einem Task-Rewriting-Template gepromptet wird. Es wandelt die rohe Benutzerspezifikation in ein sauberes Pseudo-Programm um, das eine klare Aufgabenbeschreibung und Few-Shot-Beispiele enthält.
PEFT-Compiler ( $C_{PEFT}$ ): Ein trainiertes Modell (speziell ein LoRA-Compiler in der aktuellen besten Instanziierung), das die Spezifikation und das Pseudo-Programm als Input erhält. Es emittiert die kontinuierlichen PEFT-Gewichte (LoRA-Matrizen), indem es seine Hidden States durch einen LoRA-Mapper abbildet.
- Der Mapper aggregiert die Hidden States aus spezifischen Layern des Compilers, poolt sie und projiziert sie in Mischkoeffizienten. Diese Koeffizienten setzen LoRA-Matrizen ( $A, B$ ) über einen Satz gemeinsam genutzter lernbarer Basen zusammen und injizieren pro Funktion etwa 38,5 Mio. Parameter in den Interpreter.

Training

Nur der PEFT-Compiler und der LoRA-Mapper werden trainiert. Der Pseudo-Compiler und der Interpreter bleiben eingefroren. Das Trainingsziel ist die Maximierung der Likelihood des Ziel-Outputs gegeben den eingefrorenen Interpreter, das generierte Pseudo-Programm und die generierten LoRA-Gewichte. Dies ist ein einzelnes überwachtes Ziel unter Verwendung des FuzzyBench Datensatzes.

3. Wesentliche Beiträge

FuzzyBench Datensatz

Die Autoren veröffentlichen FuzzyBench, einen mit 10 Millionen Beispielen konzipierten Datensatz, der zur Ausbildung von PAW-artigen Methoden dient.

Konstruktion: Generiert mittels gpt-5.2 in einer zweistufigen Pipeline (Generierung der Spezifikation gefolgt von der Generierung von Input/Output-Paaren).
Abdeckung: Inkrementell aufgebaut über 29 thematische Versionen, deckt er über 800 Kategorien unscharfer Aufgaben ab (z. B. Textverarbeitung, Formatreparatur, agentische Werkzeugnutzung, Sicherheitsverifizierung).
Verifizierung: Enthält einen verifizierten Testsatz, bei dem zwei starke Modelle dem Output zustimmen müssen, um mehrdeutige Ziele zu filtern. Er enthält zudem rauschbehaftete Versionen (Tippfehler, Grammatikfehler, Mehrdeutigkeit) zur Bewertung der Robustheit.

Das PAW-System

Text-to-LoRA Instanziierung: Die Autoren zeigen, dass das Generieren von LoRA-Adaptern aus Textspezifikationen das Prefix-Tuning und direktes Prompting übertrifft.
Modalitäts-Generalität: Die Abstraktion lässt sich auf bildgesteuerte Aufgaben erweitieren, indem lediglich der Compiler durch ein Vision-Language-Modell (Qwen3-VL) ersetzt wird, während derselbe textbasierte Interpreter verwendet wird.
Entwickler-Schnittstelle: Eine praktische API (paw.compile, paw.function), die es Entwicklern ermöglicht, Spezifikationen in serialisierbare Gewichtdateien (GGUF-Format) zu kompilieren, die vollständig offline laufen.

4. Experimentelle Ergebnisse

Performance auf FuzzyBench

Genauigkeit: Ein 0,6B-Parameter Interpreter, der PAW-Programme ausführt, erreicht 73,78 % Exact Match auf FuzzyBench.
Vergleich: Dies übertrifft das direkte Prompting von Qwen3-32B (68,70 %) und übersteigt signifikant die Leistung des 0,6B Basismodells mit direktem Prompting (9,84 %).
Effizienz: Das PAW-System nutzt etwa 1/50stel des Inferenz-Speichers des 32B Modells (~1,2 GB vs. ~60 GB).
Latenz: Auf einem MacBook M3 läuft das quantisierte System mit 30 Tokens/Sekunde.

Robustheit

PAW zeigt eine hohe Robustheit gegenüber verrauschten Spezifikationen (Tippfehler, Grammatikfehler). Das diskrete Pseudo-Programm fungiert als Denoiser; wenn die rohe, verrauschte Spezifikation direkt an den Interpreter gefüttert wird (unter Umgehung des Pseudo-Programms), sinkt die Performance erheblich (um 4,5 Punkte bei schweren Tippfehlern), während die vollständige PAW-Pipeline nur geringfügig degradiert.

Ablationsstudien

Notwendigkeit des Compilers: PAW übertrifft das Full Fine-Tuning des 0,6B Basismodells um 15,4 Prozentpunkte und Fixed LoRAs um 21,7 Punkte, was bestätigt, dass der Gewinn aus dem Compiler-generierten, spezifikationsbewussten LoRA resultiert.
Architektur: Das einfachste LoRA-Mapper-Design (Mean-Pooling der Hidden States in einen einzelnen Vektor, flaches MLP, gemeinsame Basen) erwies sich als überlegen gegenüber komplexeren, „ausdrucksstärkeren“ Varianten.
Quantisierung: Die Quantisierung des Basismodells auf Q6_K und des LoRA-Adapters auf Q4_0 führt zu einem vernachlässigbaren Genauigkeitsverlust im Vergleich zu bf16, bei einem gesamten Speicherbedarf von ~507 MB.

Fallstudien

Das Paper validiert das Paradigma anhand von fünf Anwendungsfällen:

Ereignisgesteuertes Log-Monitoring: Lokale Klassifizierung der Log-Dringlichkeit.
Intent-basierte Seitennavigation: Klassifizierung der Nutzerintention ohne API-Aufrufe.
Semantisches Search-Reranking: Re-Ranking von Keyword-Suchergebnissen nach Intention.
Agent-Preprocessing: Eine Tool-Calling-Pipeline, die 93 % auf TOOLCALL-15 erzielt.
Kreative Generierung: Ein multilinguales Wortraten-Spiel (Alien-Taboo), bedient durch einen 0,6B Interpreter.

5. Bedeutung und Ansprüche

Das Paper rahmt PAW als konkreten Schritt in Richtung einer „Small-Model-Zukunft“ ein, in der Foundation Models als Werkzeugbauer fungieren, statt als Problemlöser für jeden einzelnen Input.

Paradigmenwechsel: Anstatt für jede Anfrage ein massives Modell aufzurufen, findet die schwere Arbeit (das Verständnis der unscharfen Spezifikation) einmalig zur Kompilationszeit statt. Das resultierende Artefakt ist eine kleine, wiederverwendbare, versionierte und distribuierbare „neuronale Binärdatei“.
Lokale Ausführung: PAW ermöglicht es, komplexe unscharfe Logik vollständig offline auf Consumer-Hardware (z. B. MacBooks, Browser via WebAssembly) auszuführen, was die Probleme von Kosten, Datenschutz und Reproduzierbarkeit adressiert, die mit Cloud-LLM-APIs verbunden sind.
Modularität: Die „One Runtime, Many Programs“-Architektur erlaubt es einem einzigen kleinen Interpreter, unendlich viele unscharfe Funktionen zu bedienen, indem die PEFT-Adapter ausgetauscht werden.

Die Autoren bleiben bescheiden hinsichtlich der Limitationen und merken an, dass das System derzeit primär einstufige (single-step) unscharfe Funktionen handhabt (mehrstufige Argumentation ist zukünftige Arbeit) und auf synthetischen Trainingsdaten basiert sowie den Compiler neu trainieren muss, falls sich die Interpreter-Architektur ändert. Sie argumentieren jedoch, dass PAW für die Klasse von Aufgaben, die einer symbolischen Implementierung widerstehen, aber kein massives Kontext- oder Reasoning-Niveau erfordern, eine praktikable, effiziente und lokale Alternative zu API-basierten LLMs bietet.