Un agente locale per il lavoro basato sulla conoscenza privato ed economico

Perplexity Portable Computer è un agente con approccio locale prioritario.

L'intero stack viene eseguito localmente per impostazione predefinita. Il modello, l'harness, la conversazione e la traiettoria risiedono tutti sulla macchina dell'utente. Il lavoro che richiede il mondo esterno, come la ricerca web, i connettori o l'escalation a un modello di consulenza più potente sul cloud, viene avviato solo quando necessario e sempre filtrato dall'utente. I dati sensibili, di conseguenza, non lasciano mai il dispositivo senza autorizzazione e i modelli locali non comportano costi di inferenza: il sistema è privato ed economico per costruzione.

Un agente con approccio locale prioritario efficace richiede che il modello e l'harness siano progettati insieme. Gli harness di uso generale presuppongono un modello di frontiera in grado di assorbire contesti lunghi, navigare in un'ampia superficie di strumenti e pianificare su orizzonti estesi. I modelli locali sono meno affidabili a fronte di tali richieste. Invece di chiedere a un modello piccolo di gestire un harness costruito per uno grande, abbiamo modellato i due elementi l'uno intorno all'altro: un harness su misura per il profilo di capacità del modello e un modello addestrato successivamente per utilizzare quell'harness in modo efficace.

Introduzione

Negli ultimi mesi le capacità degli agenti sono avanzate rapidamente in un'ampia gamma di attività di lavoro basato sulla conoscenza. Sebbene questi progressi portino grandi vantaggi in termini di produttività ed efficienza, pongono anche due sfide.

Il consumo di token sta aumentando rapidamente e, con esso, la spesa complessiva. Quando l'intelligenza viene consultata tramite le API di modelli a codice chiuso in esecuzione su cluster remoti, le informazioni private e la proprietà intellettuale lasciano il dispositivo dell'utente a ogni richiesta. Man mano che gli agenti vengono scalati su singoli flussi di lavoro e intere organizzazioni, il consumo di token e il movimento dei dati diventano sempre più difficili da gestire.

Allo stesso tempo, i modelli open source sono migliorati a un ritmo ancora più elevato. I progressi sono più evidenti nei modelli molto piccoli ed efficienti come NVIDIA Nemotron 3.5 Lightning (30B parametri totali), Qwen 3.6 (35B) e Qwen 3.8 (27B). Questi piccoli modelli offrono prestazioni superiori alle attese e sono ora in grado di gestire complessi flussi di lavoro basati su agenti. L'hardware di inferenza locale si sta evolvendo in parallelo: sistemi come NVIDIA DGX Spark possono ora eseguire questi modelli localmente. Insieme, queste tendenze rendono l'operatività completamente sul dispositivo pratica, consentendo al contempo agli utenti di optare per funzionalità esterne quando necessario, come la ricerca web, i connettori o l'escalation a modelli cloud.

Questo approccio con preferenza per l'architettura locale consente notevoli risparmi sui costi, poiché l'inferenza locale evita le commissioni API per token. Risolve inoltre in modo naturale i problemi di privacy e proprietà intellettuale: i token privati non devono mai essere trasmessi a cluster remoti e rimangono saldamente all'interno del perimetro del dispositivo locale.

A giugno abbiamo introdotto il primo orchestratore di inferenza ibrido locale-server che decide quale lavoro eseguire sul dispositivo e quale inviare agli agenti nel cloud. Qui spieghiamo come abbiamo costruito un tale agente con approccio locale prioritario, inclusi l'harness e i modelli co-ottimizzati l'uno per l'altro.

Forniamo una panoramica delle scelte di progettazione chiave, valutiamo Computer rispetto a famosi harness open source generici (Hermes e Pi) su tre benchmark pubblici e sul nostro Local Knowledge Work Bench interno. Sul nostro benchmark, con il modello Qwen 3.8 27B in esecuzione su una NVIDIA DGX Spark, Computer ottiene il punteggio più alto, 82,6% contro il 77,6% di Pi e il 74,0% di Hermes. PPLX 27B, il nostro modello sottoposto a post-addestramento basato su Qwen 3.8 27B, eleva ulteriormente il punteggio all'85,4%.

Progettare l'harness attorno al modello locale

Sebbene i modelli compatti sul dispositivo siano già piuttosto capaci, rimangono ancora indietro rispetto ai modelli di frontiera più grandi in termini di prestazioni. È necessario un harness accuratamente progettato per guidare questi modelli in modo efficace e affrontare i loro limiti.

Famosi harness open source come Pi e Hermes si sono dimostrati generali: funzionano bene con un'ampia varietà di modelli di diverse dimensioni e classi. Tuttavia, non sono ottimizzati per le capacità dei modelli su dispositivo. Abbiamo progettato l'harness locale specificamente per questo contesto, basandoci su alcuni principi chiave.

Efficienza del contesto

L'obiettivo principale nella progettazione del nostro harness è stato sfruttare al meglio il contesto del modello.

Sebbene i modelli sul dispositivo come Qwen 3.8 27B offrano finestre di contesto di 260K token, abbiamo riscontrato empiricamente che iniziano a incontrare difficoltà oltre i 100K token. Manteniamo pertanto l'harness principale sintetico: un prompt di sistema minimale e un piccolo set di strumenti di base.

Tutte le altre capacità sono suddivise in skill modulari che vengono caricate e scaricate durante tutta la traiettoria. Abbiamo progettato queste skill per le attività di lavoro basato sulla conoscenza più comuni: ricerca, scienza dei dati, visualizzazione dei dati, creazione di documenti, ingegneria del software e altro ancora.

L'harness supporta anche la compattazione del contesto, riassumendo il contesto obsoleto quando una traiettoria si allunga in modo che il modello rimanga all'interno della sua finestra efficace.

I connettori come strumenti da riga di comando

Il lavoro basato sulla conoscenza quotidiano richiede spesso connettori come Gmail, GitHub, Outlook e Google Calendar. Questi vengono solitamente esposti a un harness come server MCP, le cui grandi definizioni di strumenti consumano una quota consistente del contesto. Al contrario, abbiamo convertito gli MCP più utilizzati in strumenti da riga di comando compatti e facili da usare, integrati da skill personalizzate che sfruttano molto meglio il contesto efficace limitato.

Autoverifica

Le prestazioni migliorano anche quando l'agente verifica il proprio lavoro. La verifica aggiunge passaggi extra, ma migliora notevolmente i risultati finali e riduce in modo sostanziale il divario rispetto ai modelli di frontiera. Può essere attivata dal modello stesso o da un insieme di hook che monitorano la salute della traiettoria e richiedono l'autoverifica quando qualcosa va storto.

Esecuzione in sandbox

L'harness esegue gli strumenti in una sandbox a livello di sistema operativo sul dispositivo dell'utente. Il perimetro limita i processi, i percorsi del file system e l'accesso alla rete in base alle policy. Ciò limita il raggio d'azione di un comando errato. Se la sandbox non è disponibile, l'harness si disattiva prima di qualsiasi chiamata agli strumenti anziché degradare a un'esecuzione senza sandbox.

Questo differisce dagli harness open source come Pi e Hermes, che eseguono i comandi direttamente con le autorizzazioni dell'utente per impostazione predefinita. In Computer, l'isolamento è sempre attivo, non richiede configurazione e gli strumenti non possono essere eseguiti senza di esso.

Il diagramma sottostante mostra come questi principi si integrano nel ciclo di esecuzione. L'orchestratore è un codice harness deterministico, non un LLM: gestisce il ciclo, assembla il contesto e applica le policy. Il modello locale propone l'azione successiva; l'orchestratore esegue le chiamate di strumenti approvate nella sandbox e restituisce i relativi risultati al modello. La ricerca web, i connettori e le chiamate ai consulenti oltrepassano il confine del dispositivo solo quando abilitati e approvati.

Un harness locale ottiene di più dallo stesso modello

Utilizzando lo stesso modello base sul dispositivo, confrontiamo il nostro harness locale con alternative per usi generali sulla ricerca web e sulla comprensione multimodale dei documenti. Tutti gli harness utilizzano il modello Qwen 3.8 27B con ragionamento medio, in esecuzione su una NVIDIA DGX Spark. Questo confronto isola le capacità apportate dall'harness stesso, prima di qualsiasi post-addestramento del modello.

Ci concentriamo su queste due capacità perché il lavoro basato sulla conoscenza combina spesso documenti privati sul dispositivo dell'utente con informazioni pubbliche provenienti dal Web per produrre un artifact fondato. La ricerca web richiede connettività, ma l'inferenza del modello e l'elaborazione dei documenti privati rimangono locali. I file locali fungono da fonte autorevole, le fonti pubbliche aggiungono contesto e gli utenti possono disabilitare completamente la ricerca web per un lavoro completamente offline.

Ricerca web

Costruiamo il nostro harness locale insieme al motore di ricerca di Perplexity, che ha raggiunto i primi posti nelle valutazioni indipendenti. L'harness vi accede tramite l'interfaccia Search as Code.

Valutiamo la qualità della ricerca su 1.266 attività BrowseComp. Computer utilizza l'infrastruttura di ricerca di Perplexity insieme al nostro harness locale, mentre Pi e Hermes si affidano a Brave, il loro provider di ricerca consigliato. Computer raggiunge una precisione del 66,7%, rispetto al 50,2% di Pi e al 43,9% di Hermes.

Computer registra inoltre il tempo di elaborazione medio e l'utilizzo di token più bassi: 402,1 secondi e 852k token per attività, rispetto a 1.020,9 secondi e 1,01 milioni di token per Hermes e 826,0 secondi e 2,82 milioni di token per Pi. Di conseguenza, Computer utilizza il 61% in meno di tempo di elaborazione e il 16% in meno di token rispetto a Hermes, e il 51% in meno di tempo di elaborazione e il 70% in meno di token rispetto a Pi.

Comprensione multimodale dei documenti sul dispositivo

Molti documenti contengono informazioni in formato visivo e sono difficili da analizzare come testo normale: PDF, pagine scansionate, schermate, grafici e presentazioni. Questi flussi di lavoro dipendono dall'OCR e dalla comprensione delle immagini e traggono i maggiori benefici da un modello nativamente multimodale.

L'harness passa le pagine dei documenti e le immagini direttamente al modello, che le comprende e combina le prove visive con il testo estratto. L'elaborazione di questi file sul dispositivo mantiene privati i documenti sensibili e il loro contenuto estratto.

Valutiamo la comprensione multimodale dei documenti su ParseBench-100, un sottoinsieme di 100 attività del benchmark ParseBench, con 20 attività ciascuna per grafici, layout, tabelle, contenuto testuale e formattazione.

Computer raggiunge un punteggio medio del 65,1%, rispetto al 34,6% di Hermes e al 13,9% di Pi. Completa inoltre le attività con il minor tempo e il minor numero di token: in media 60,6 secondi e 20,1k token per attività, rispetto a 108,3 secondi e 32,1k token per Hermes e 410,5 secondi e 829,1k token per Pi. Computer è in testa in tutte e cinque le categorie di documenti, con il suo vantaggio maggiore sui grafici. Il layout rimane difficile per tutti e tre gli harness.

Tabella 1. Punteggio medio di ParseBench-100 per categoria di documento per gli harness Computer, Hermes e Pi con il modello Qwen 3.8 27B sul dispositivo. Computer è in testa in tutte e cinque le categorie.

Riduzione del divario con la frontiera tramite l'escalation al consulente

Anche con un harness accuratamente progettato, le attività più difficili superano comunque le capacità di un modello compatto sul dispositivo. Per tali attività, l'harness espone uno strumento di consulenza: il modello locale può consultare un modello di frontiera più potente quando ha bisogno di aiuto con la pianificazione, la risoluzione delle ambiguità, il recupero da errori ripetuti o la verifica del risultato finale.

Il modello locale decide quando richiedere una consulenza, mentre l'orchestratore dell'harness mantiene l'autorità sugli strumenti e controlla quale contesto viene inviato. L'escalation è opzionale. L'utente decide se abiliterla e se approvare ogni chiamata al consulente manualmente o automaticamente.

Prima di una chiamata al consulente, l'harness seleziona il contesto pertinente, applica un classificatore PII per contrassegnare le informazioni sensibili e mostra all'utente cosa lascerebbe il dispositivo. Il consulente riceve solo il contesto approvato e restituisce una guida testuale; non ha accesso diretto ai file, agli strumenti o alle conversazioni del dispositivo. Ciò migliora sia i costi che la privacy e prevediamo di esplorare ulteriormente questa direzione in lavori futuri.

Testiamo questo approccio su attività complesse di ingegneria del software, che richiedono un forte ragionamento e rappresentano l'ambito in cui un modello locale fallisce più spesso. A tal fine utilizziamo Terminal Bench 2.1, un popolare benchmark di 89 attività per agenti di codifica.

Vogliamo rispondere a due domande: quanta parte del divario rispetto a un modello di frontiera può colmare l'escalation al consulente e a quale costo. I modelli completamente locali non costano praticamente nulla da eseguire, poiché l'inferenza avviene sull'hardware dell'utente. Tuttavia, una volta che il modello inizia a chiamare il consulente, comincia a incorrere in costi API.

Come baseline per le prestazioni di frontiera, utilizziamo Claude Opus 5 in esecuzione nell'harness locale; il modello locale è Qwen 3.8 27B. Infine, abbiniamo i due: Qwen 3.8 27B esegue l'attività ed effettua l'escalation a un consulente Claude Opus 5 quando ha bisogno di aiuto. Non valutiamo l'escalation del consulente con Pi o Hermes perché nessuno dei due fornisce uno strumento di consulenza equivalente; aggiungerne uno richiederebbe la modifica della sua superficie di strumenti e della logica di orchestrazione, quindi il risultato non rappresenterebbe più l'harness predefinito.

L'escalation al consulente porta il punteggio di Computer dal 59,6% al 73,0%, con un incremento di 13,5 punti percentuali, a un costo API stimato di $0,415 per esecuzione. L'esecuzione del solo Claude Opus 5 raggiunge l'82,4% a $0,65 per esecuzione. L'escalation recupera quindi circa tre quinti del divario rispetto alla frontiera a circa due terzi del costo della frontiera, e l'utente decide quando vale la pena fare tale compromesso.

Post-addestramento per l'harness e il lavoro basato sulla conoscenza

Finora abbiamo mantenuto il modello locale invariato per isolare il contributo dell'harness. Con la progettazione dell'harness definita, i maggiori guadagni rimanenti derivano dall'adattamento del modello stesso. I dati di utilizzo di Perplexity Computer ci mostrano cosa fanno realmente le persone per il lavoro basato sulla conoscenza, che utilizziamo per sintetizzare i dati di addestramento. Sottoponiamo a post-addestramento il modello locale all'interno dell'harness di Computer, guidati dalla reale distribuzione delle attività eseguite dagli utenti.

In concreto, identifichiamo un insieme diversificato di casi d'uso che sfruttano diverse capacità del modello, strumenti e connettori. Da questi casi d'uso sintetizziamo ambienti di apprendimento per rinforzo realistici e definiamo attività impegnative ma verificabili: ciascuna attività è costituita da un'istruzione, un ambiente e un verificatore che assegna un punteggio al risultato finale, dove l'ambiente è un container Docker in cui opera l'harness. È importante notare che, poiché le attività sono sintetiche, non contengono documenti reali o informazioni sugli utenti.

Utilizziamo questi ambienti per l'addestramento in due fasi: fine-tuning tramite rifiuto seguito dall'apprendimento per rinforzo. Nella prima fase, eseguiamo il modello su ciascuna attività più volte, selezioniamo le traiettorie migliori in base al punteggio del verificatore e ci addestriamo su di esse con l'apprendimento supervisionato. Questa fase inizializza il modello per l'harness specifico e la distribuzione delle attività. Nella seconda fase, l'apprendimento per rinforzo perfeziona ulteriormente il modello, rendendolo più robusto.

Un sottoinsieme di attività viene escluso dall'addestramento e utilizzato per la valutazione finale; chiamiamo questo set escluso Local Knowledge Work Bench: 53 attività che coprono sette categorie di lavoro basato sulla conoscenza quotidiano, dalla ricerca approfondita alla creazione di documenti. Pubblicheremo presto un report tecnico che descrive in dettaglio l'addestramento del modello e prevediamo di rendere open source questo benchmark di valutazione.

Abbiamo sottoposto a post-addestramento Qwen 3.8 27B con questo approccio, producendo un modello che chiamiamo PPLX 27B, e lo abbiamo valutato sul Local Knowledge Work Bench. Con il modello base Qwen 3.8 27B, Computer ottiene il punteggio più alto (82,6%, rispetto al 77,6% di Pi e al 74,0% di Hermes) e utilizza il minor numero di token (520k, contro 681k di Pi e 634k di Hermes). Pi completa le attività più rapidamente con 176 secondi per attività, rispetto ai 218 secondi di Computer e ai 292 secondi di Hermes. PPLX 27B eleva il punteggio di Computer all'85,4%, al costo di un maggior numero di token (678k rispetto a 520k). Il suo tempo di elaborazione stimato è di 250 secondi.

Tabella 2. Categorie di attività del Local Knowledge Work Bench.

Conclusione

La nostra ricerca mostra che un forte modello open source, dotato di hardware locale capace e di un harness costruito appositamente per essi, è in grado di gestire il lavoro basato sulla conoscenza reale a un costo di inferenza prossimo allo zero, senza richiedere che i dati sensibili lascino il dispositivo.

Nei vari benchmark, Computer ha eguagliato o superato Hermes e Pi in termini di precisione eseguendo Qwen 3.8 27B su una NVIDIA DGX Spark. Tra i tre benchmark che riportano la latenza e l'utilizzo di token, Computer è stato il più veloce su BrowseComp e ParseBench-100 e ha utilizzato il minor numero di token in tutti e tre; Pi è stato il più veloce sul Local Knowledge Work Bench.

I guadagni derivano dalle scelte che abbiamo fatto. Abbiamo costruito un harness locale sintetico con skill che si caricano su richiesta. Abbiamo convertito i connettori in strumenti CLI compatti anziché in server MCP. L'esecuzione è stata messa in sandbox per motivi di sicurezza.

I risultati mostrano anche in quali ambiti i modelli compatti possono migliorare. Ad esempio, sulle difficili attività di codifica di Terminal Bench 2.1, il modello locale rimane indietro rispetto al modello di frontiera in tutti e tre gli harness. L'escalation al consulente riduce ma non chiude completamente il divario; sono ancora necessari continui miglioramenti nelle capacità dei modelli e nell'hardware locale per spingere ulteriormente le prestazioni.

Lo scopo della creazione dell'harness e del modello per i vincoli locali è dare agli utenti il controllo esplicito su quali informazioni lasciano le loro macchine. Vi sono anche vantaggi in termini di costi per l'utente. Consideriamo tutto ciò parte di un cambiamento più ampio in cui agenti sempre più capaci passano dall'infrastruttura remota a dispositivi individuali e locali. Prevediamo che i progressi nei chip, nei modelli e nei dispositivi espanderanno continuamente la gamma di attività di lavoro basato sulla conoscenza che Portable Computer può gestire localmente.