Um agente local para trabalho de conhecimento privado e económico

O Perplexity Portable Computer é um agente centrado no local.

Toda a pilha executa-se localmente por predefinição. O modelo, o chicote, a conversa e a trajetória residem todos na máquina do utilizador. O trabalho que necessita do mundo exterior, como a pesquisa na web, um conector ou a escalação para um modelo conselheiro mais forte na cloud, é invocado apenas quando necessário e sempre controlado pelo utilizador. Assim, os dados sensíveis nunca saem do dispositivo sem permissão, e os modelos locais não acarretam taxa de inferência: o sistema é privado e económico por conceção.

Um agente local eficaz exige que o modelo e o chicote sejam concebidos em conjunto. Os chicotes de uso geral assumem um modelo de fronteira capaz de absorver contextos longos, navegar por uma ampla superfície de ferramentas e planear ao longo de horizontes alargados. Os modelos locais são menos fiáveis perante essas exigências. Em vez de pedir a um modelo pequeno para gerir um chicote construído para um grande, moldámos ambos um em função do outro: um chicote adaptado ao perfil de capacidades do modelo e um modelo pós-treinado para utilizar esse chicote de forma eficaz.

Introdução

As capacidades agenticas avançaram rapidamente nos últimos meses numa ampla gama de tarefas de trabalho de conhecimento. Embora estes avanços tragam enormes ganhos de produtividade e eficiência, também colocam dois desafios.

O consumo de tokens está a crescer rapidamente, e com ele o gasto geral. Quando a inteligência é acedida através das APIs de modelos de código fechado executados em clusters remotos, as informações privadas e a propriedade intelectual saem do dispositivo do utilizador a cada pedido. À medida que os agentes se dimensionam por fluxos de trabalho individuais e organizações inteiras, o gasto de tokens e o movimento de dados tornam-se cada vez mais difíceis de governar.

Ao mesmo tempo, os modelos de código aberto têm melhorado a um ritmo ainda mais rápido. O progresso é mais visível em modelos muito pequenos e eficientes, como o NVIDIA Nemotron 3.5 Lightning (30 mil milhões de parâmetros no total), Qwen 3.6 (35 mil milhões) e Qwen 3.8 (27 mil milhões). Estes pequenos modelos superam as expectativas e são agora capazes de fluxos de trabalho agenticos complexos. O hardware de inferência local está a avançar em paralelo: sistemas como o NVIDIA DGX Spark conseguem agora executar estes modelos localmente. Juntas, estas tendências tornam a operação totalmente no dispositivo prática, permitindo que os utilizadores optem por capacidades externas quando necessário, tais como pesquisa na web, um conector ou escalação para um modelo na cloud.

Esta abordagem centrada no local permite poupanças de custos significativas, uma vez que a inferência local evita taxas de API por token. Também resolve naturalmente as questões de privacidade e de propriedade intelectual: os tokens privados nunca precisam de ser transmitidos para clusters remotos e permanecem em segurança dentro dos limites do dispositivo local.

Em junho, introduzimos o primeiro orquestrador de inferência híbrida local-servidor que decide que trabalho deve ser executado no dispositivo e que trabalho deve ir para os agentes na cloud. Aqui explicamos como construímos esse agente centrado no local, incluindo o chicote e os modelos otimizados em conjunto.

Apresentamos uma visão geral das principais escolhas de conceção, avaliamos o Computer face a chicotes de uso geral de código aberto populares (Hermes e Pi) em três benchmarks públicos e no nosso Local Knowledge Work Bench interno. No nosso benchmark, com o modelo Qwen 3.8 27B a ser executado num NVIDIA DGX Spark, o Computer obtém a pontuação mais alta, 82,6% versus 77,6% para o Pi e 74,0% para o Hermes. O PPLX 27B, o nosso modelo pós-treinado sobre o Qwen 3.8 27B, eleva ainda mais a pontuação para 85,4%.

Conceber o chicote em torno do modelo local

Embora os modelos compactos no dispositivo já sejam bastante capazes, continuam a ficar atrás dos modelos de fronteira maiores em termos de desempenho. É necessário um chicote cuidadosamente concebido para orientar estes modelos de forma eficaz e colmatar as suas limitações.

Os chicotes de código aberto populares, como o Pi e o Hermes, provaram ser gerais: funcionam bem com uma grande variedade de modelos de vários tamanhos e classes. No entanto, não estão otimizados para as capacidades dos modelos no dispositivo. Concebimos o chicote local especificamente para este cenário, em torno de alguns princípios fundamentais.

Eficiência de contexto

O principal foco na conceção do nosso chicote foi tirar o melhor partido do contexto do modelo.

Embora os modelos no dispositivo, como o Qwen 3.8 27B, ofereçam janelas de contexto de 260 mil tokens, constatámos empiricamente que começam a ter dificuldades acima de 100 mil tokens. Por conseguinte, mantemos o chicote principal sucinto: um prompt de sistema mínimo e um pequeno conjunto de ferramentas principais.

Todas as outras capacidades são modularizadas em Skills a pedido que são carregadas e descarregadas ao longo da trajetória. Concebemos estas Skills para tarefas comuns de trabalho de conhecimento: investigação, ciência de dados, visualização de dados, criação de documentos, engenharia de software e muito mais.

O chicote também suporta compactação de contexto, resumindo o contexto obsoleto quando uma trajetória se torna longa, para que o modelo permaneça dentro da sua janela eficaz.

Conectores como ferramentas de linha de comandos

O trabalho de conhecimento diário requer frequentemente conectores como o Gmail, o GitHub, o Outlook e o Google Calendar. Estes são habitualmente expostos a um chicote como servidores MCP, cujas grandes definições de ferramentas consomem uma parte substancial do contexto. Em vez disso, convertemos os MCPs mais utilizados em ferramentas de linha de comandos compactas e fáceis de utilizar, complementadas com Skills personalizadas que tiram um proveito muito melhor do contexto eficaz limitado.

Autoverificação

O desempenho também melhora quando o agente verifica o seu próprio trabalho. A verificação adiciona passos extra, mas melhora significativamente os resultados finais e reduz substancialmente a diferença para os modelos de fronteira. Pode ser acionada pelo próprio modelo ou por um conjunto de ganchos que monitorizam a integridade da trajetória e solicitam a autoverificação quando algo corre mal.

Execução em sandbox

O chicote executa ferramentas numa sandbox ao nível do SO no dispositivo do utilizador. Os limites restringem processos, caminhos do sistema de ficheiros e acesso à rede de acordo com a política. Isto limita o raio de impacto de um comando erróneo. Se a sandbox estiver indisponível, o chicote desativa-se a si próprio antes de qualquer chamada de ferramenta, em vez de se degradar para uma execução sem sandbox.

Isto difere de chicotes de código aberto como o Pi e o Hermes, que executam comandos diretamente com as permissões do utilizador por predefinição. No Computer, o isolamento está sempre ativado, não requer configuração e as ferramentas não podem ser executadas sem ele.

O diagrama abaixo mostra como estes princípios se articulam no ciclo de execução. O orquestrador é código de chicote determinístico, e não um LLM: mantém o ciclo, reúne o contexto e aplica a política. O modelo local propõe a ação seguinte; o orquestrador executa as chamadas de ferramentas aprovadas na sandbox e devolve os respetivos resultados ao modelo. A pesquisa na web, um conector e as chamadas ao conselheiro cruzam a fronteira do dispositivo apenas quando ativadas e aprovadas.

Um chicote local extrai mais do mesmo modelo

Utilizando o mesmo modelo base no dispositivo, comparamos o nosso chicote local com alternativas de uso geral em investigação na web e compreensão de documentos multimodal. Todos os chicotes utilizam o modelo Qwen 3.8 27B com raciocínio médio, executado num NVIDIA DGX Spark. Esta comparação isola as capacidades aportadas pelo próprio chicote, antes de qualquer pós-treino do modelo.

Centramo-nos nestas duas capacidades porque o trabalho de conhecimento combina frequentemente documentos privados no dispositivo do utilizador com informações públicas da web para produzir um artefacto fundamentado. A pesquisa na web requer conectividade, mas a inferência do modelo e o processamento de documentos privados permanecem locais. Os ficheiros locais servem de fonte autorizada, as fontes públicas adicionam contexto e os utilizadores podem desativar totalmente a pesquisa na web para trabalhos totalmente offline.

Investigação na web

Construímos o nosso chicote local em conjunto com o motor de busca da Perplexity, que alcançou os primeiros lugares em avaliações independentes. O chicote acede ao mesmo através da interface Search as Code.

Avaliamos a qualidade da investigação em 1266 tarefas do BrowseComp. O Computer utiliza a infraestrutura de pesquisa da Perplexity juntamente com o nosso chicote local, enquanto o Pi e o Hermes dependem do Brave, o seu fornecedor de pesquisa recomendado. O Computer atinge uma precisão de 66,7%, comparado com 50,2% para o Pi e 43,9% para o Hermes.

O Computer apresenta também o menor tempo de relógio médio registado e uso de tokens: 402,1 segundos e 852 mil tokens por tarefa, comparado com 1020,9 segundos e 1,01 milhões de tokens para o Hermes, e 826,0 segundos e 2,82 milhões de tokens para o Pi. Consequentemente, o Computer utiliza menos 61% de tempo de relógio e menos 16% de tokens do que o Hermes, e menos 51% de tempo de relógio e menos 70% de tokens do que o Pi.

Compreensão de documentos multimodal no dispositivo

Muitos documentos transmitem informações de forma visual e são difíceis de analisar como texto simples: PDFs, páginas digitalizadas, capturas de ecrã, gráficos e apresentações. Estes fluxos de trabalho dependem de OCR e de compreensão de imagens, beneficiando grandemente de um modelo nativamente multimodal.

O chicote transmite páginas de documentos e imagens diretamente para o modelo, que as compreende e combina a evidência visual com o texto extraído. O processamento destes ficheiros no dispositivo mantém os documentos sensíveis e o respetivo conteúdo extraído privados.

Avaliamos a compreensão de documentos multimodal no ParseBench-100, um subconjunto de 100 tarefas do benchmark ParseBench, com 20 tarefas para cada uma das seguintes categorias: gráficos, esquema, tabelas, conteúdo de texto e formatação.

O Computer atinge uma pontuação média de 65,1%, comparado com 34,6% para o Hermes e 13,9% para o Pi. Conclui também as tarefas com o menor tempo e o menor número de tokens: em média 60,6 segundos e 20,1 mil tokens por tarefa, comparado com 108,3 segundos e 32,1 mil tokens para o Hermes, e 410,5 segundos e 829,1 mil tokens para o Pi. O Computer lidera em todas as cinco categorias de documentos, com a sua maior vantagem nos gráficos. O esquema continua a ser difícil para os três chicotes.

Tabela 1. Pontuação média do ParseBench-100 por categoria de documento para os chicotes Computer, Hermes e Pi com o modelo Qwen 3.8 27B no dispositivo. O Computer lidera nas cinco categorias.

Reduzir a diferença para a fronteira com a escalação para o conselheiro

Mesmo com um chicote cuidadosamente concebido, as tarefas mais difíceis continuam a exceder as capacidades de um modelo compacto no dispositivo. Para essas tarefas, o chicote expõe uma ferramenta de conselheiro: o modelo local pode consultar um modelo de fronteira mais forte quando precisa de ajuda com o planeamento, a resolução de ambiguidades, a recuperação de falhas repetidas ou a verificação do resultado final.

O modelo local decide quando solicitar aconselhamento, enquanto o orquestrador do chicote retém a autoridade sobre as ferramentas e controla que contexto é enviado. A escalação é opcional. O utilizador decide se a ativa e se aprova cada chamada ao conselheiro manual ou automaticamente.

Antes de uma chamada ao conselheiro, o chicote seleciona o contexto relevante, aplica um classificador de PII para sinalizar informações sensíveis e mostra ao utilizador o que sairia do dispositivo. O conselheiro recebe apenas o contexto aprovado e devolve orientações em texto; não tem acesso direto aos ficheiros, ferramentas ou conversas do dispositivo. Isto melhora tanto os custos como a privacidade, e planeamos explorar mais esta direção num trabalho futuro.

Testamos esta abordagem em tarefas desafiantes de engenharia de software, que exigem um forte raciocínio e são aquelas em que um modelo local mais frequentemente falha. Para tal, utilizamos o Terminal Bench 2.1, um popular benchmark de 89 tarefas para agentes de programação.

Queremos responder a duas perguntas: quanta diferença para um modelo de fronteira pode a escalação para o conselheiro colmatar, e a que custo. Os modelos totalmente locais custam praticamente zero a executar, uma vez que a inferência ocorre no hardware do utilizador. No entanto, assim que o modelo começa a chamar o conselheiro, começa a incorrer em custos de API.

Como linha de base para o desempenho de fronteira, utilizamos o Claude Opus 5 a operar no chicote local; o modelo local é o Qwen 3.8 27B. Por fim, emparelhamos ambos: o Qwen 3.8 27B executa a tarefa e recorre a um conselheiro Claude Opus 5 quando precisa de ajuda. Não avaliamos a escalação para o conselheiro com o Pi ou o Hermes porque nenhum deles fornece uma ferramenta de conselheiro equivalente; adicionar uma exigiria modificar a respetiva superfície de ferramentas e lógica de orquestração, pelo que o resultado deixaria de representar o chicote pré-fabricado.

A escalação para o conselheiro eleva a pontuação do Computer de 59,6% para 73,0%, um ganho de 13,5 pontos percentuais, a um custo estimado de API de $0,415 por execução. Executar o Claude Opus 5 isoladamente atinge 82,4% a $0,65 por execução. A escalação recupera assim cerca de três quintos da diferença para a fronteira a cerca de dois terços do custo da fronteira, e o utilizador decide quando vale a pena fazer essa troca.

Pós-treino para o chicote e o trabalho de conhecimento

Até agora, mantivemos o modelo local inalterado para isolar o que o chicote aporta. Com a conceção do chicote implementada, os maiores ganhos restantes provêm da adaptação do próprio modelo. Os dados de utilização do Perplexity Computer mostram-nos o que as pessoas fazem efetivamente no trabalho de conhecimento, os quais utilizamos para sintetizar dados de treino. Pós-treinamos o modelo local dentro do chicote do Computer, guiados pela distribuição real de tarefas que os utilizadores executam.

Em termos concretos, identificamos um conjunto diversificado de casos de utilização que exercitam diferentes capacidades, ferramentas e conectores do modelo. A partir destes casos de utilização, sintetizamos ambientes de aprendizagem por reforço realistas e definimos tarefas desafiantes mas verificáveis: cada tarefa consiste numa instrução, num ambiente e num verificador que pontua o resultado final, sendo que o ambiente é um contentor Docker no qual o chicote opera. É importante salientar que, como as tarefas são sintéticas, não contêm documentos reais nem informações de utilizadores.

Utilizamos estes ambientes para treino em duas fases: afinação por rejeição seguida de aprendizagem por reforço. Na primeira fase, executamos o modelo em cada tarefa várias vezes, selecionamos as melhores trajetórias por pontuação do verificador e treinamos nelas com aprendizagem supervisionada. Esta fase inicializa o modelo para o chicote específico e para a distribuição de tarefas. Na segunda fase, a aprendizagem por reforço afina ainda mais o modelo, tornando-o mais robusto.

Um subconjunto de tarefas é retido do treino e utilizado para a avaliação final; chamamos a este conjunto retido o Local Knowledge Work Bench: 53 tarefas que abrangem sete categorias de trabalho de conhecimento diário, desde a pesquisa aprofundada até à criação de documentos. Publicaremos em breve um relatório técnico que descreve detalhadamente o treino do modelo, e planeamos disponibilizar este benchmark de avaliação em código aberto.

Pós-treinámos o Qwen 3.8 27B com esta abordagem, produzindo um modelo a que chamamos PPLX 27B, e avaliámo-lo no Local Knowledge Work Bench. Com o modelo base Qwen 3.8 27B, o Computer obtém a pontuação mais alta (82,6%, comparado com 77,6% para o Pi e 74,0% para o Hermes) e utiliza o menor número de tokens (520 mil, versus 681 mil para o Pi e 634 mil para o Hermes). O Pi conclui as tarefas mais rapidamente, a 176 segundos por tarefa, comparado com 218 segundos para o Computer e 292 segundos para o Hermes. O PPLX 27B eleva a pontuação do Computer para 85,4%, ao custo de mais tokens (678 mil versus 520 mil). O seu tempo de relógio estimado é de 250 segundos.

Tabela 2. Categorias de tarefas do Local Knowledge Work Bench.

Conclusão

A nossa investigação mostra que um modelo de código aberto forte, com hardware local capaz e um chicote construído para os mesmos, consegue lidar com trabalho de conhecimento real a um custo de inferência próximo de zero, sem exigir que dados sensíveis abandonem o dispositivo.

Ao longo dos vários benchmarks, o Computer igualou ou excedeu o Hermes e o Pi em termos de precisão ao executar o Qwen 3.8 27B num NVIDIA DGX Spark. Entre os três benchmarks que reportam a latência e o uso de tokens, o Computer foi o mais rápido no BrowseComp e no ParseBench-100 e utilizou o menor número de tokens em todos os três; o Pi foi o mais rápido no Local Knowledge Work Bench.

Os ganhos resultaram das escolhas que fizemos. Construímos um chicote local sucinto com Skills que se carregam a pedido. Convertemos os conectores em ferramentas CLI compactas em vez de servidores MCP. A execução foi colocada numa sandbox para garantir a segurança.

Os resultados também mostram onde os modelos compactos têm margem para melhorias. Por exemplo, nas tarefas de programação desafiantes do Terminal Bench 2.1, o modelo local fica atrás do modelo de fronteira em todos os três chicotes. A escalação para o conselheiro reduz mas não colmata totalmente a diferença; continuam a ser necessárias melhorias contínuas nas capacidades do modelo e no hardware local para impulsionar ainda mais o desempenho.

O objetivo de construir o chicote e o modelo para restrições locais é dar aos utilizadores um controlo explícito sobre que informações saem das respetivas máquinas. Existem também benefícios de custo para o utilizador. Vemos isto como parte de uma mudança mais ampla em que agentes cada vez mais capazes se deslocam da infraestrutura remota para dispositivos individuais e locais. Esperamos que os avanços em chips, modelos e dispositivos expandam continuamente a gama e a qualidade do trabalho de conhecimento que o Portable Computer processa localmente.