Un agent local pour un travail de la connaissance privé et économique

Perplexity Portable Computer est un agent axé sur le local.

L'ensemble de la pile s'exécute localement par défaut. Le modèle, le harnais, la conversation et la trajectoire résident tous sur la machine de l'utilisateur. Le travail qui nécessite le monde extérieur, tel que la recherche web, les connecteurs ou l'escalade vers un modèle conseiller plus puissant sur le cloud, n'est invoqué qu'en cas de besoin et est toujours contrôlé par l'utilisateur. Les données sensibles ne quittent donc jamais l'appareil sans autorisation, et les modèles locaux n'entraînent aucun frais d'inférence : le système est privé et économique par conception.

Un agent local efficace exige que le modèle et le harnais soient conçus ensemble. Les harnais polyvalents supposent un modèle de pointe capable d'absorber de longs contextes, de naviguer dans une surface d'outils étendue et de planifier sur de longs horizons. Les modèles locaux sont moins fiables face à ces exigences. Plutôt que de demander à un petit modèle de gérer un harnais conçu pour un grand, nous avons façonné les deux l'un autour de l'autre : un harnais adapté au profil de capacité du modèle, et un modèle post-entraîné pour utiliser ce harnais efficacement.

Introduction

Ces derniers mois, les capacités des agents ont progressé rapidement dans un large éventail de tâches de travail de la connaissance. Bien que ces avancées apportent de gains importants en productivité et en efficacité, elles posent également deux défis.

La consommation de jetons augmente rapidement, et avec elle les dépenses globales. Lorsque l'intelligence est accessible via les API de modèles à code source fermé exécutés sur des clusters distants, les informations privées et la propriété intellectuelle quittent l'appareil de l'utilisateur à chaque requête. À mesure que les agents se développent à travers les flux de travail individuels et les organisations entières, la consommation de jetons et le mouvement des données deviennent de plus en plus difficiles à régir.

Dans le même temps, les modèles open-source se sont améliorés à un rythme encore plus rapide. Les progrès sont particulièrement visibles dans les modèles très petits et efficaces tels que NVIDIA Nemotron 3.5 Lightning (30 milliards de paramètres au total), Qwen 3.6 (35 milliards) et Qwen 3.8 (27 milliards). Ces petits modèles surpassent leur catégorie et sont désormais capables de flux de travail complexes. Le matériel d'inférence local progresse en parallèle : des systèmes tels que le NVIDIA DGX Spark peuvent désormais exécuter ces modèles localement. Ensemble, ces tendances rendent le fonctionnement entièrement sur appareil pratique tout en permettant aux utilisateurs d'opter pour des capacités externes si nécessaire, telles que la recherche web, les connecteurs ou l'escalade vers un modèle cloud.

Cette approche axée sur le local permet des économies de coûts importantes, car l'inférence locale évite les frais d'API par jeton. Elle résout également naturellement les problèmes de confidentialité et de propriété intellectuelle : les jetons privés n'ont jamais besoin d'être transmis à des clusters distants et restent en toute sécurité dans les limites de l'appareil local.

En juin, nous avons présenté le premier orchestrateur d'inférence hybride local-serveur qui décide quel travail doit s'exécuter sur l'appareil et quel travail doit être confié à des agents dans le cloud. Nous expliquons ici comment nous avons conçu un tel agent local, y compris le harnais et les modèles co-optimisés les uns pour les autres.

Nous présentons un aperçu des principaux choix de conception et évaluons Computer par rapport aux harnais polyvalents open-source populaires (Hermes et Pi) à travers trois benchmarks publics et notre benchmark interne Local Knowledge Work Bench. Sur notre benchmark, avec le modèle Qwen 3.8 27B exécuté sur un NVIDIA DGX Spark, Computer obtient le score le plus élevé, soit 82,6 % contre 77,6 % pour Pi et 74,0 % pour Hermes. PPLX 27B, notre modèle post-entraîné sur Qwen 3.8 27B, élève encore le score à 85,4 %.

Concevoir le harnais autour du modèle local

Bien que les modèles compacts sur appareil soient déjà très performants, ils restent en deçà des grands modèles de pointe en matière de performances. Un harnais soigneusement conçu est nécessaire pour guider efficacement ces modèles et répondre à leurs limitations.

Les harnais open-source populaires tels que Pi et Hermes se sont révélés polyvalents : ils fonctionnent bien avec une grande variété de modèles de toutes tailles et catégories. Mais ils ne sont pas optimisés pour les capacités des modèles sur appareil. Nous avons conçu le harnais local spécifiquement pour ce contexte, autour de quelques principes clés.

Efficacité contextuelle

L'objectif principal lors de la conception de notre harnais était d'utiliser au mieux le contexte du modèle.

Bien que les modèles sur appareil tels que Qwen 3.8 27B offrent des fenêtres de contexte de 260 000 jetons, nous avons constaté de manière empirique qu'ils commencent à rencontrer des difficultés au-delà de 100 000 jetons. Nous veillons donc à ce que le harnais principal reste concis : une invite système minimale et un petit ensemble d'outils essentiels.

Toutes les autres capacités sont modulées en compétences à la demande qui se chargent et se déchargent tout au long de la trajectoire. Nous avons conçu ces compétences pour les tâches courantes de travail de la connaissance : recherche, science des données, visualisation de données, création de documents, génie logiciel, etc.

Le harnais prend également en charge la compaction du contexte, résumant le contexte obsolète lorsqu'une trajectoire s'allonge afin que le modèle reste dans sa fenêtre efficace.

Connecteurs en tant d'outils en ligne de commande

Le travail de la connaissance quotidien nécessite souvent des connecteurs tels que Gmail, GitHub, Outlook et Google Calendar. Ceux-ci sont généralement exposés à un harnais sous forme de serveurs MCP, dont les grandes définitions d'outils consomment une part substantielle du contexte. Au lieu de cela, nous avons converti les MCP les plus utilisés en outils en ligne de commande compacts et faciles à utiliser, complétés par des compétences personnalisées qui font un bien meilleur usage du contexte effectif limité.

Auto-vérification

Les performances s'améliorent également lorsque l'agent vérifie son propre travail. La vérification ajoute des étapes supplémentaires, mais elle améliore considérablement les résultats finaux et réduit substantiellement l'écart avec les modèles de pointe. Elle peut être déclenchée par le modèle lui-même ou par un ensemble de crochets qui surveillent la santé de la trajectoire et demandent une auto-vérification en cas de problème.

Exécution dans un bac à sable

Le harnais exécute les outils dans un bac à sable au niveau du système d'exploitation sur l'appareil de l'utilisateur. La limite restreint les processus, les chemins du système de fichiers et l'accès au réseau conformément aux règles. Cela limite le rayon d'impact d'une commande erronée. Si le bac à sable n'est pas disponible, le harnais se désactive avant tout appel d'outil plutôt que de dégrader l'exécution sans bac à sable.

Cela diffère des harnais open-source tels que Pi et Hermes, qui exécutent les commandes directement avec les autorisations de l'utilisateur par défaut. Dans Computer, l'isolation est toujours activée, ne nécessite aucune configuration et les outils ne peuvent pas s'exécuter sans elle.

Le diagramme ci-dessous montre comment ces principes s'articulent dans la boucle d'exécution. L'orchestrateur est un code de harnais déterministe, et non un LLM : il maintient la boucle, assemble le contexte et applique les politiques. Le modèle local propose la prochaine action ; l'orchestrateur exécute les appels d'outils approuvés dans le bac à sable et renvoie leurs résultats au modèle. La recherche web, les connecteurs et les appels au conseiller ne traversent la frontière de l'appareil que lorsqu'ils sont activés et approuvés.

Un harnais local tire le meilleur parti du même modèle

En utilisant le même modèle de base sur appareil, nous comparons notre harnais local avec des alternatives polyvalentes sur la recherche web et la compréhension de documents multimodaux. Tous les harnais utilisent le modèle Qwen 3.8 27B avec un raisonnement moyen, s'exécutant sur un NVIDIA DGX Spark. Cette comparaison isole les capacités apportées par le harnais lui-même, avant tout post-entraînement du modèle.

Nous nous concentrons sur ces deux capacités car le travail de la connaissance combine souvent des documents privés sur l'appareil de l'utilisateur avec des informations publiques du web pour produire un artéfact fondé. La recherche web nécessite une connectivité, mais l'inférence du modèle et le traitement des documents privés restent locaux. Les fichiers locaux servent de source faisant autorité, les sources publiques ajoutent du contexte et les utilisateurs peuvent désactiver entièrement la recherche web pour un travail totalement hors ligne.

Recherche web

Nous construisons notre harnais local parallèlement au moteur de recherche de Perplexity, qui a obtenu les meilleurs classements lors d'évaluations indépendantes. Le harnais y accède via l'interface Search as Code.

Nous évaluons la qualité de la recherche sur 1 266 tâches BrowseComp. Computer utilise l'infrastructure de recherche de Perplexity ainsi que notre harnais local, tandis que Pi et Hermes s'appuient sur Brave, leur fournisseur de recherche recommandé. Computer atteint une précision de 66,7 %, contre 50,2 % pour Pi et 43,9 % pour Hermes.

Computer présente également le temps réel moyen enregistré et l'utilisation de jetons les plus faibles : 402,1 secondes et 852 000 jetons par tâche, contre 1 020,9 secondes et 1,01 million de jetons pour Hermes, et 826,0 secondes et 2,82 millions de jetons pour Pi. Computer utilise donc 61 % de temps réel en moins et 16 % de jetons en moins qu'Hermes, et 51 % de temps réel en moins et 70 % de jetons en moins que Pi.

Compréhension de documents multimodaux sur appareil

De nombreux documents contiennent des informations visuelles et sont difficiles à analyser sous forme de texte brut : PDF, pages numérisées, captures d'écran, graphiques et présentations. Ces flux de travail dépendent de l'OCR et de la compréhension d'images, et bénéficient le plus d'un modèle nativement multimodal.

Le harnais transmet les pages de documents et les images directement au modèle, qui les comprend et associe les preuves visuelles au texte extrait. Le traitement de ces fichiers sur l'appareil garantit la confidentialité des documents sensibles et de leur contenu extrait.

Nous évaluons la compréhension de documents multimodaux sur ParseBench-100, un sous-ensemble de 100 tâches du benchmark ParseBench, avec 20 tâches chacune pour les graphiques, la mise en page, les tableaux, le contenu textuel et la mise en forme.

Computer atteint un score moyen de 65,1 %, contre 34,6 % pour Hermes et 13,9 % pour Pi. Il accomplit également les tâches avec le moins de temps et le moins de jetons : en moyenne 60,6 secondes et 20 100 jetons par tâche, contre 108,3 secondes et 32 100 jetons pour Hermes, et 410,5 secondes et 829 100 jetons pour Pi. Computer est en tête dans les cinq catégories de documents, son avantage le plus important étant sur les graphiques. La mise en page reste difficile pour les trois harnais.

Tableau 1. Score moyen ParseBench-100 par catégorie de document pour les harnais Computer, Hermes et Pi avec le modèle Qwen 3.8 27B sur appareil. Computer est en tête dans les cinq catégories.

Réduction de l'écart avec les modèles de pointe grâce à l'escalade vers un conseiller

Même avec un harnais soigneusement conçu, les tâches les plus difficiles dépassent toujours les capacités d'un modèle compact sur appareil. Pour ces tâches, le harnais expose un outil de conseil : le modèle local peut consulter un modèle de pointe plus puissant lorsqu'il a besoin d'aide pour planifier, résoudre une ambiguïté, se remettre d'échecs répétés ou vérifier le résultat final.

Le modèle local décide du moment où il convient de demander conseil, tandis que l'orchestrateur du harnais conserve l'autorité sur les outils et contrôle le contexte envoyé. L'escalade est facultative. L'utilisateur décide s'il souhaite l'activer et s'il convient d'approuver chaque appel au conseiller manuellement ou automatiquement.

Avant un appel au conseiller, le harnais sélectionne le contexte pertinent, applique un classificateur PII pour signaler les informations sensibles et montre à l'utilisateur ce qui quitterait l'appareil. Le conseiller ne reçoit que le contexte approuvé et renvoie des conseils textuels ; il n'a aucun accès direct aux fichiers, aux outils ou aux conversations de l'appareil. Cela améliore à la fois les coûts et la confidentialité, et nous prévoyons d'explorer davantage cette direction dans nos futurs travaux.

Nous testons cette approche sur des tâches complexes de génie logiciel, qui exigent un raisonnement solide et constituent le domaine où un modèle local est le plus souvent insuffisant. Pour ce faire, nous utilisons Terminal Bench 2.1, un benchmark populaire de 89 tâches pour les agents de codage.

Nous voulons répondre à deux questions : quelle part de l'écart avec un modèle de pointe l'escalade vers un conseiller peut-elle combler, et à quel coût. Les modèles entièrement locaux ne coûtent pratiquement rien à exécuter, puisque l'inférence se produit sur le matériel de l'utilisateur. Cependant, dès que le modèle commence à faire appel au conseiller, il commence à encourir des coûts d'API.

Comme référence pour les performances des modèles de pointe, nous utilisons Claude Opus 5 fonctionnant dans le harnais local ; le modèle local est Qwen 3.8 27B. Enfin, nous associons les deux : Qwen 3.8 27B exécute la tâche et fait appel à un conseiller Claude Opus 5 lorsqu'il a besoin d'aide. Nous n'évaluons pas l'escalade vers un conseiller avec Pi ou Hermes car aucun d'eux ne fournit d'outil de conseil équivalent ; en ajouter un nécessiterait de modifier sa surface d'outils et sa logique d'orchestration, de sorte que le résultat ne représenterait plus le harnais standard.

L'escalade vers un conseiller fait passer le score de Computer de 59,6 % à 73,0 %, soit un gain de 13,5 points de pourcentage, pour un coût d'API estimé à 0,415 $ par exécution. L'exécution de Claude Opus 5 seul atteint 82,4 % à 0,65 $ par exécution. L'escalade récupère ainsi environ les trois cinquièmes de l'écart avec les modèles de pointe pour environ les deux tiers de leur coût, et l'utilisateur décide si ce compromis en vaut la peine.

Post-entraînement pour le harnais et le travail de la connaissance

Jusqu'à présent, nous avons laissé le modèle local inchangé pour isoler la contribution du harnais. La conception du harnais étant en place, les gains les plus importants proviennent de l'adaptation du modèle lui-même. Les données d'utilisation de Perplexity Computer nous montrent ce que les gens font réellement pour le travail de la connaissance, ce que nous utilisons pour synthétiser des données d'entraînement. Nous post-entraînons le modèle local au sein du harnais Computer, guidé par la distribution réelle des tâches effectuées par les utilisateurs.

Concrètement, nous identifions un ensemble diversifié de cas d'utilisation qui mobilisent différentes capacités de modèle, outils et connecteurs. À partir de ces cas d'utilisation, nous synthétisons des environnements d'apprentissage par renforcement réalistes et définissons des tâches difficiles mais vérifiables : chaque tâche se compose d'une instruction, d'un environnement et d'un vérificateur qui note le résultat final, l'environnement étant un conteneur Docker dans lequel le harnais fonctionne. Il est important de noter que, les tâches étant synthétiques, elles ne contiennent aucun document réel ni information utilisateur.

Nous utilisons ces environnements pour un entraînement en deux étapes : un réglage fin par rejet suivi d'un apprentissage par renforcement. Dans la première étape, nous déployons le modèle sur chaque tâche à plusieurs reprises, sélectionnons les meilleures trajectoires en fonction du score du vérificateur et les entraînons par apprentissage supervisé. Cette étape initialise le modèle pour le harnais spécifique et la distribution des tâches. Dans la seconde étape, l'apprentissage par renforcement affine davantage le modèle, le rendant plus robuste.

Un sous-ensemble de tâches est exclu de l'entraînement et utilisé pour l'évaluation finale ; nous appelons cet ensemble exclu le Local Knowledge Work Bench : 53 tâches couvrant sept catégories de travail de la connaissance quotidien, de la recherche approfondie à la création de documents. Nous publierons bientôt un rapport technique décrivant en détail l'entraînement du modèle, et nous prévoyons de publier ce benchmark d'évaluation en open source.

Nous avons post-entraîné Qwen 3.8 27B avec cette approche, produisant un modèle que nous appelons PPLX 27B, et l'avons évalué sur le Local Knowledge Work Bench. Avec le modèle de base Qwen 3.8 27B, Computer atteint le score le plus élevé (82,6 %, contre 77,6 % pour Pi et 74,0 % pour Hermes) et utilise le moins de jetons (520 000, contre 681 000 pour Pi et 634 000 pour Hermes). Pi accomplit les tâches le plus rapidement, en 176 secondes par tâche, contre 218 secondes pour Computer et 292 secondes pour Hermes. PPLX 27B porte le score de Computer à 85,4 %, au prix d'un nombre de jetons plus élevé (678 000 contre 520 000). Son temps réel estimé est de 250 secondes.

Tableau 2. Catégories de tâches du Local Knowledge Work Bench.

Conclusion

Nos recherches montrent qu'un modèle open-source puissant, doté d'un matériel local performant et d'un harnais conçu pour eux, peut gérer un véritable travail de la connaissance à un coût d'inférence proche de zéro, sans nécessiter que des données sensibles quittent l'appareil.

À travers les différents benchmarks, Computer a égalé ou dépassé Hermes et Pi en termes de précision tout en exécutant Qwen 3.8 27B sur un NVIDIA DGX Spark. Parmi les trois benchmarks qui rapportent la latence et l'utilisation de jetons, Computer a été le plus rapide sur BrowseComp et ParseBench-100 et a utilisé le moins de jetons sur les trois ; Pi a été le plus rapide sur le Local Knowledge Work Bench.

Les gains proviennent des choix que nous avons faits. Nous avons construit un harnais local concis doté de compétences qui se chargent à la demande. Nous avons converti les connecteurs en outils CLI compacts au lieu de serveurs MCP. L'exécution a été placée dans un bac à sable pour des raisons de sécurité.

Les résultats montrent également où les modèles compacts peuvent encore s'améliorer. Par exemple, sur les tâches de codage complexes de Terminal Bench 2.1, le modèle local est à la traîne par rapport au modèle de pointe sur l'ensemble des trois harnais. L'escalade vers un conseiller réduit mais ne comble pas entièrement l'écart ; des améliorations continues des capacités des modèles et du matériel local sont encore nécessaires pour pousser les performances plus loin.

Le but de la construction du harnais et du modèle pour des contraintes locales est de donner aux utilisateurs un contrôle explicite sur les informations qui quittent leurs machines. Il y a également des avantages en termes de coûts pour l'utilisateur. Nous y voyons une composante d'une évolution plus large dans laquelle des agents de plus en plus capables passent d'une infrastructure distante à des appareils individuels et locaux. Nous prévoyons que les progrès des puces, des modèles et des appareils élargiront continuellement la gamme de travaux de la connaissance que Portable Computer peut gérer localement.