Résumé Technique : OPENJARVIS – Une Stack IA Personnelle Décomposée et Optimisable de Bout en Bout

1. Énoncé du Problème

Les stacks IA personnelles (par exemple, OpenClaw, Hermes Agent) sont devenues centrales dans les flux de travail quotidiens, mais reposent actuellement presque exclusivement sur des modèles de pointe hébergés dans le cloud. Cette architecture présente quatre problèmes critiques :

1. Confidentialité : Les requêtes contiennent souvent des données locales sensibles acheminées vers des serveurs tiers.
2. Coût : Les frais récurrents d'API et d'abonnement s'élèvent à plusieurs milliers de dollars par an pour les utilisateurs intensifs.
3. Dépendance : Les utilisateurs ne possèdent pas les modèles et nécessitent une connectivité réseau constante.
4. Énergie : L'inférence dans le cloud consomme un ordre de grandeur d'énergie par token de plus que l'exécution locale.

Bien que le matériel grand public prenne désormais en charge des modèles à poids ouverts (1 à 128 milliards de paramètres) qui ne sont en retard que de 6 à 12 mois sur les tâches d'IA personnelle par rapport aux modèles de pointe, le simple remplacement d'un modèle local dans une stack existante conçue pour le cloud échoue. Les expériences montrent que le remplacement d'un modèle cloud (par exemple, Claude Opus 4.6) par un modèle local (par exemple, Qwen3.5-9B) au sein de frameworks tels qu'OpenClaw ou Hermes Agent entraîne une chute de 25 à 39 points de pourcentage (pp) en précision.

La cause racine est que les stacks existantes sont monolithiques : les prompts d'agent, les descriptions d'outils, les configurations de mémoire et les paramètres d'exécution sont co-conçus et fusionnés pour des modèles cloud spécifiques. Les méthodes d'optimisation actuelles (par exemple, les optimiseurs de prompts comme GEPA ou DSPy) ne peuvent ajuster que le primitif de prompt, ne comblant que 5 pp de l'écart. L'optimisation d'un seul primitif de manière isolée ne peut pas résoudre le désalignement à travers l'ensemble de la stack.

2. Méthodologie : L'Architecture OPENJARVIS

Pour permettre aux modèles locaux de rivaliser avec les systèmes cloud, les auteurs proposent OPENJARVIS, une architecture qui décompose les systèmes d'IA personnels en cinq primitifs typés, indépendamment modifiables.

2.1 L'Abstraction Spécification

OPENJARVIS représente un système d'IA personnelle comme une spécification typée (spec) composée de cinq primitifs :

1. Intelligence : L'architecture du modèle de langage, les poids et les paramètres de génération.
2. Moteur : Le runtime d'inférence, le chemin d'exécution matérielle, le regroupement (batching) et les paramètres de quantification.
3. Agents : La boucle de raisonnement, les prompts et les politiques d'utilisation d'outils.
4. Outils & Mémoire : Interfaces externes, mécanismes de récupération et état utilisateur persistant.
5. Apprentissage : L'optimiseur qui met à jour le système à partir de traces (par exemple, LoRA, optimiseurs de prompts ou l'algorithme de recherche proposé).

Cette décomposition permet de traiter l'ensemble de la stack comme un objet unique optimisable, exposant chaque composant comme un degré de liberté.

2.2 Recherche de Spécification Guidée par LLM

L'algorithme d'optimisation central est la recherche de spécification guidée par LLM, une collaboration local–cloud qui optimise conjointement les quatre primitifs modifiables (Intelligence, Moteur, Agents, Outils & Mémoire) tout en utilisant le primitif Apprentissage pour piloter le processus.

• Temps de Recherche (Cloud) : Un modèle cloud de pointe (le « Professeur ») agit en tant que proposeur réflexif. Il analyse les traces d'exécution de la spécification locale actuelle, diagnostique les clusters d'échecs (par exemple, « l'élève échoue sur les recherches de calendrier multi-sauts ») et propose des modifications coordonnées sur plusieurs primitifs simultanément (par exemple, réécrire une description d'outil et ajuster un paramètre d'exécution).
• Temps d'Inférence (Local) : La spécification optimisée résultante s'exécute entièrement sur l'appareil. Le modèle cloud n'est pas impliqué dans l'inférence.
• Le Portail : Pour prévenir la dégradation, un mécanisme de « portail » n'accepte une modification que si elle améliore les performances sur un cluster d'échecs spécifique sans entraîner de régressions inacceptables (définies par une tolérance $\epsilon$) sur d'autres clusters.
• Optimisation Conjointe : Contrairement aux optimiseurs de primitif unique, cette méthode permet à une seule modification de s'étendre sur plusieurs primitifs, capturant les effets couplés (par exemple, mettre à jour les poids du modèle pour correspondre à une nouvelle structure de prompt).

3. Contributions Clés

1. Architecture OPENJARVIS : Un cadre novateur qui décompose l'IA personnelle en cinq primitifs typés, rendant la stack optimisable et mesurable de bout en bout en termes de précision, de coût et de latence.
2. Recherche de Spécification Guidée par LLM : Un algorithme de recherche qui exploite les modèles cloud de pointe pour proposer des modifications aux spécifications locales au moment de la recherche, comblant l'écart de précision local–cloud de 13 à 32 pp à un coût d'optimisation 7 à 11 fois inférieur aux bases de référence de primitif unique.
3. Configurations Locales Pareto-Optimales : Preuves empiriques montrant que les spécifications optimisées sur appareil peuvent égaler ou dépasser la précision du cloud sur 4 des 8 benchmarks, tout en réduisant les coûts marginaux d'API d'environ 800 fois et la latence de bout en bout de 4 fois.
4. Analyse Complète : Une étude d'ablation démontrant que les gains proviennent à la fois du proposeur (diagnostic par LLM par rapport à une recherche évolutionnaire/aléatoire) et de l'espace de mouvement (optimisation des quatre primitifs contre un seul).

4. Résultats Expérimentaux

Les auteurs ont évalué OPENJARVIS sur 8 benchmarks (incluant PinchBench, GAIA, LiveCodeBench et DeepResearchBench), 11 modèles locaux issus de 4 familles, et 7 plateformes matérielles.

• Récupération de Portabilité : Le simple remplacement d'un modèle local dans un framework cloud fait chuter la précision de 24 à 39 pp. L'utilisation de la spécification OPENJARVIS avec le même modèle local récupère 56 à 77 % de cette baisse, réduisant l'écart résiduel à 5,6 à 16,5 pp.
• Précision vs Cloud : La meilleure spécification unique sur appareil (Qwen3.5-122B) atteint une précision moyenne de 80,3 %, soit à 3,2 pp de la meilleure base de référence cloud (Claude Opus 4.6 à 83,5 %). Sur 4 des 8 benchmarks, le meilleur modèle local égale ou dépasse les performances du cloud.
• Gains d'Efficacité : Les configurations locales offrent une réduction d'environ 800 fois du coût marginal d'API et une réduction de 4 fois de la latence de bout en bout par rapport aux bases de référence cloud.
• Efficacité de la Recherche :
  • La recherche de spécification guidée par LLM a amélioré les modèles locaux de 13 à 32 pp sur l'ensemble des benchmarks.
  • L'élargissement de l'ensemble modifiable des prompts uniquement à l'ensemble des quatre primitifs a ajouté 5,5 à 16,5 pp.
  • L'utilisation d'un professeur LLM pour diagnostiquer les échecs a ajouté 10,0 pp par rapport à la recherche évolutionnaire pour le même espace de mouvement.
  • Les modifications acceptées étaient réparties sur tous les primitifs : Intelligence (16–44 %), Agents, Outils et Moteur, confirmant qu'aucun composant unique ne domine l'optimisation.

5. Importance et Revendications

L'article revendique que l'IA personnelle locale nécessite plus qu'un simple remplacement de modèle ; elle exige une stack portable, mesurable et optimisable. OPENJARVIS démontre que :

• La Parité Local-Cloud est Atteignable : Avec la bonne architecture, les systèmes sur appareil peuvent s'approcher des performances cloud de pointe sans renoncer aux propriétés locales (confidentialité, coût, propriété).
• La Décomposition est Clé : L'écart de performance est architectural, pas seulement limité par les capacités. En exposant les hypothèses des stacks conçues pour le cloud sous forme de primitifs modifiables, les modèles locaux peuvent être reconfigurés pour correspondre à leurs forces.
• La Recherche Hybride est Efficace : L'utilisation de modèles cloud uniquement pour la phase de recherche (diagnostic et proposition) et l'exécution de la spécification optimisée localement au moment de l'inférence transfèrent les capacités de pointe aux appareils locaux sans dépendance cloud persistante.

Les auteurs soulignent que les spécifications locales résultantes ne font aucun appel au cloud au moment de l'inférence. Bien que la phase de recherche engendre un coût unique (amorti à <0,001 $/requête après six mois d'utilisation), le modèle opérationnel passe d'un abonnement cloud récurrent à une optimisation unique suivie d'une exécution locale.

Limitations notées par les auteurs :

• La précision statistique est limitée par 5 exécutions indépendantes par configuration.
• Un biais potentiel du juge LLM (utilisation de GPT-5-mini) pourrait favoriser les sorties de la famille GPT.
• L'évaluation est actuellement limitée aux déploiements sur machine unique.
• Certaines bases de référence cloud ont affiché des scores inattendument bas en raison de problèmes d'intégration d'outils dans le dispositif d'évaluation.