Résumé Technique : Program-as-Weights (PAW)

1. Énoncé du Problème

De nombreuses tâches de programmation du monde réel résistent à une implémentation précise basée sur des règles. Ces « fonctions floues » (fuzzy functions) — telles que le filtrage de lignes de journaux par degré d'urgence, la réparation de fichiers JSON malformés ou le classement de résultats de recherche par intention — sont intuitives pour les humains mais fragiles lorsqu'elles sont implémentées avec des règles symboliques nettes (ex: expressions régulières) en raison du bruit, des fautes de frappe et des cas limites.

Actuellement, les développeurs externalisent ces tâches vers des API de Grands Modèles de Langage (LLM). Bien que pratique, cette approche induit des coûts élevés, introduit de la latence, compromet la reproductibilité (en raison des mises à jour silencieuses des modèles par les fournisseurs) et empêche les logiciels d'être autonomes. Le document pose la nécessité d'un paradigme qui conserve la flexibilité des LLM pour les tâches floues tout en permettant une exécution locale, reproductible et rentable.

2. Méthodologie : Program-as-Weights (PAW)

Les auteurs proposent le Program-as-Weights (PAW), un paradigme où une fonction floue est compilée à partir d'une spécification en langage naturel en un artefact neural compact et exécutable localement. Le système sépare le « travail lourd » de compréhension de la spécification du « travail quotidien » d'exécution de la fonction.

Architecture Centrale

Le pipeline PAW se compose de trois composants principaux :

1. Le Compilateur : Un modèle neural qui mappe une spécification utilisateur ($s$) vers un programme ($p$).
2. Le Programme ($p$) : Un artefact hybride comprenant :
   • Composante Discrète ($p_{discrete}$) : Un « pseudo-programme » en langage naturel (une reformulation de la tâche accompagnée d'exemples d'entrées-sorties représentatifs). Cela protège l'interprète de l'ambiguïté et des fautes de frappe de la spécification originale.
   • Composante Continue ($p_{continuous}$) : Un module de Fine-Tuning de Paramètres Efficients (PEFT) (spécifiquement LoRA ou le cache KV de prefix-tuning) qui ré-entraîne un interprète gelé pour la tâche spécifique.
3. L'Interpréte : Un petit modèle de langage gelé (ex: Qwen3-0.6B) qui exécute le programme. Il charge le module PEFT et le pseudo-programme, traite l'entrée de l'utilisateur et génère la sortie de manière autorégressive.

Le Pipeline de Compilation

Le processus de compilation comprend deux étapes, utilisant toutes deux un modèle Qwen3 4B :

1. Pseudo-Compilateur ($C_p$) : Un modèle prêt à l'emploi, non entraîné, sollicité par un template de réécriture de tâche. Il convertit la spécification brute de l'utilisateur en un pseudo-programme propre contenant une description de tâche claire et des exemples de quelques tirages (few-shot).
2. Compilateur PEFT ($C_{PEFT}$) : Un modèle entraîné (spécifiquement un compilateur LoRA dans la meilleure instanciation actuelle) qui prend la spécification et le pseudo-programme en entrée. Il émet les poids PEFT continus (matrices LoRA) en passant les états cachés de son modèle à travers un mappeur LoRA.
   • Le mappeur agrège les états cachés de couches spécifiques du compilateur, les regroupe (pooling) et les projette en coefficients de mélange. Ces coefficients composent les matrices LoRA ($A, B$) sur un ensemble de bases apprenables partagées, injectant environ 38,5 millions de paramètres dans l'interprète par fonction.

Entraînement

Seuls le compilateur PEFT et le mappeur LoRA sont entraînés. Le pseudo-compilateur et l'interprète restent gelés. L'objectif d'entraînement est de maximiser la vraisemblance de la sortie cible étant donné l'interprète gelé, le pseudo-programme généré et les poids LoRA générés. Il s'agit d'un objectif supervisé unique utilisant le jeu de données FuzzyBench.

3. Contributions Clés

Jeu de Données FuzzyBench

Les auteurs publient FuzzyBench, un jeu de données de 10 millions d'exemples conçu pour entraîner des méthodes de type PAW.

• Construction : Généré via gpt-5.2 selon un pipeline en deux étapes (génération de spécification suivie de la génération de paires entrées/sorties).
• Couverture : Construit de manière incrémentielle sur 29 versions thématiques, couvrant plus de 800 catégories de tâches floues (ex: traitement de texte, réparation de format, utilisation d'outils agentiques, vérification de sécurité).
• Vérification : Inclut un ensemble de test vérifié où deux modèles puissants doivent s'accorder sur la sortie pour filtrer les cibles ambiguës. Il inclut également des versions perturbées par du bruit (fautes de frappe, erreurs de grammaire, ambiguïté) pour l'évaluation de la robustesse.

Le Système PAW

• Instanciation Text-to-LoRA : Les auteurs démontrent que la génération d'adaptateurs LoRA à partir de spécifications textuelles surpasse le prefix-tuning et le prompting direct.
• Généralité de la Modalité : L'abstraction s'étend aux tâches conditionnées par l'image en remplaçant uniquement le compilateur par un modèle vision-langage (Qwen3-VL), tout en conservant le même interprète textuel.
• Interface Développeur : Une API pratique (paw.compile, paw.function) permettant aux développeurs de compiler des spécifications en fichiers de poids sérialisables (format GGUF) qui s'exécutent entièrement hors ligne.

4. Résultats Expérimentaux

Performance sur FuzzyBench

• Précision : Un interprète de 0,6 milliard de paramètres exécutant des programmes PAW atteint 73,78 % de correspondance exacte sur FuzzyBench.
• Comparaison : Cela surpasse le prompting direct de Qwen3-32B (68,70 %) et dépasse largement la performance du modèle de base 0,6B avec prompting direct (9,84 %).
• Efficacité : Le système PAW utilise environ 1/50ème de la mémoire d'inférence du modèle 32B (~1,2 Go contre ~60 Go).
• Latence : Sur un MacBook M3, le système quantifié tourne à 30 tokens/seconde.

Robustesse

• PAW montre une haute robustesse aux spécifications bruitées (fautes de frappe, erreurs de grammaire). Le pseudo-programme discret agit comme un débruiteur ; lorsque la spécification bruitée brute est injectée directement à l'interprète (en contournant le pseudo-programme), la performance chute significativement (perte de 4,5 points avec de lourdes fautes de frappe), tandis que le pipeline complet PAW ne se dégrade que légèrement.

Études d'Ablation

• Nécessité du Compilateur : PAW surpasse le fine-tuning complet du modèle de base 0,6B de 15,4 points de pourcentage et les LoRAs fixes de 21,7 points, confirmant que le gain provient du LoRA conscient de la spécification et généré par le compilateur.
• Architecture : La conception la plus simple du mappeur LoRA (mean-pooling des états cachés en un seul vecteur, MLP peu profond, bases partagées) s'est avérée supérieure aux variantes plus complexes et « plus expressives ».
• Quantification : La quantification de la base en Q6_K et de l'adaptateur LoRA en Q4_0 entraîne une perte de précision négligeable par rapport au bf16, avec une empreinte disque totale d'environ 507 Mo.

Études de Cas

Le papier valide le paradigme sur cinq cas d'usage :

1. Surveillance d'événements (logs) : Classification locale de l'urgence des journaux.
2. Navigation sur site basée sur l'intention : Classification de l'intention de l'utilisateur sans appels API.
3. Ré-classement de recherche sémantique : Ré-ordonner les résultats de recherche par intention.
4. Pré-traitement d'agent : Un pipeline d'appel d'outils score 93 % sur TOOLCALL-15.
5. Génération créative : Un jeu de devinettes multilingue (Alien-Taboo) servi par un interprète de 0,6B.

5. Signification et Revendications

Le papier présente PAW comme une étape concrète vers un « futur des petits modèles » où les modèles de fond servent de constructeurs d'outils plutôt que de solveurs de problèmes par requête.

• Changement de Paradigme : Au lieu d'invoquer un modèle massif pour chaque requête, le travail lourd (comprendre la spécification floue) se fait une seule fois lors de la compilation. L'artefact résultant est un « binaire neural » petit, réutilisable, versionné et distribuable.
• Exécution Locale : PAW permet à une logique floue complexe de s'exécuter entièrement hors ligne sur du matériel grand public (ex: MacBook, navigateurs via WebAssembly), répondant aux problèmes de coût, de confidentialité et de reproductibilité associés aux API de LLM cloud.
• Modularité : L'architecture « un runtime, de nombreux programmes » permet à un seul interprète de servir un nombre illimité de fonctions floues en échangeant dynamiquement les adaptateurs PEFT.

Les auteurs restent modestes quant aux limites, notant que le système gère actuellement des fonctions floues à étape unique (le raisonnement multi-étapes est un travail futur), repose sur des données d'entraînement synthétiques et nécessite de ré-entraîner le compilateur si l'architecture de l'interprète change. Cependant, ils soutiennent que pour la classe de tâches qui résistent à l'implémentation symbolique mais ne nécessitent pas un contexte ou un raisonnement massif, PAW offre une alternative viable, efficace et locale aux LLM basés sur des API.