プライベートかつ費用対効果の高いナレッジワークのためのローカルファーストエージェント

Perplexity Portable Computerは、ローカルファーストのエージェントです。

スタック全体がデフォルトでローカル実行されます。モデル、ハーネス、会話、およびトラジェクトリのすべてがユーザーのマシン上に存在します。ウェブ検索、コネクタ、またはクラウド上のより強力なアドバイザーモデルへのエスカレーションなど、外部の世界を必要とする作業は、必要な場合にのみ呼び出され、常にユーザーによって制御されます。そのため、機密データが許可なくデバイス外に出ることはなく、ローカルモデルには推論料金がかかりません。システムは設計上、プライベートかつ費用対効果に優れています。

効果的なローカルファーストのエージェントを実現するには、モデルとハーネスを一体として設計する必要があります。汎用ハーネスは、長いコンテキストを処理し、幅広いツールサーフェスを操作し、長期的な視野で計画を立てることができるフロンティアモデルを前提としています。ローカルモデルは、そのような要求に対して信頼性が低くなります。小型モデルに大型モデル用のハーネスの管理を求めるのではなく、私たちは両者を相互に最適化しました。モデルの機能プロファイルに合わせたハーネスと、そのハーネスを効果的に使用するように事後学習されたモデルです。

はじめに

近年のエージェント機能は、幅広いナレッジワークのタスクにおいて急速に進歩しています。これらの進歩は生産性と効率の大幅な向上をもたらす一方で、2つの課題も提起しています。

トークンの消費量は急速に増加しており、それに伴い全体的なコストも増加しています。リモートクラスター上で実行されるクローズドソースモデルのAPIを通じてインテリジェンスにアクセスする場合、リクエストのたびにプライベートな情報や知的財産がユーザーのデバイスから外部に送信されます。エージェントが個々のワークフローや組織全体へとスケールするにつれて、トークンの支出やデータの移動を管理することがますます困難になっています。

同時に、オープンソースモデルはさらに速いペースで改良されています。その進歩は、NVIDIA Nemotron 3.5 Lightning（総パラメータ数30B）、Qwen 3.6（35B）、Qwen 3.8（27B）などの非常に小さく効率的なモデルにおいて最も顕著です。これらの小型モデルは実力を大きく上回るパフォーマンスを発揮し、現在では複雑なエージェントのワークフローを実行できるようになっています。ローカル推論ハードウェアも並行して進化しており、NVIDIA DGX Sparkなどのシステムにより、これらのモデルをローカルで実行できるようになりました。これらのトレンドが一体となることで、完全なオンデバイス操作が実用的になると同時に、ウェブ検索、コネクタ、クラウドモデルのエスカレーションなどが必要な場合に外部機能を選択的に利用できるようになります。

このローカルファーストのアプローチにより、ローカル推論によってトークンごとのAPI料金が不要になるため、大幅なコスト削減が可能になります。また、プライバシーや知的財産の懸念も自然に解消されます。プライベートなトークンをリモートクラスターに送信する必要が一切なく、ローカルデバイスの境界内に安全にとどまるためです。

6月、私たちはどの作業をオンデバイスで実行し、どの作業をクラウド内のエージェントに送信するかを決定する、初のハイブリッドローカル・サーバー推論オーケストレーターを発表しました。ここでは、ハーネスや相互に最適化されたモデルを含め、このようなローカルファーストのエージェントをどのように構築したかについて説明します。

主要な設計上の選択の概要を示し、3つのパブリックベンチマークおよび社内のLocal Knowledge Work Benchにおいて、一般的なオープンソースの汎用ハーネス（HermesおよびPi）とComputerを比較評価します。当社のベンチマークでは、NVIDIA DGX Spark上で実行されるQwen 3.8 27Bモデルを使用したComputerが最高スコアである82.6%を記録し、Piの77.6%およびHermesの74.0%を上回りました。Qwen 3.8 27Bの上に事後学習を施した当社のモデルであるPPLX 27Bは、スコアをさらに85.4%に引き上げます。

ローカルモデルを中心にハーネスを設計する

コンパクトなオンデバイスモデルはすでに十分な能力を備えていますが、パフォーマンスの面では依然として大型のフロンティアモデルに劣ります。これらのモデルを効果的に誘導し、その制限に対処するためには、慎重に設計されたハーネスが必要です。

PiやHermesなどの人気のオープンソースハーネスは汎用的であることが証明されており、さまざまなサイズやクラスのモデルと良好に連携します。しかし、それらはオンデバイスモデルの機能に最適化されていません。私たちは、いくつかの主要な原則に基づき、この環境向けに特化してローカルハーネスを設計しました。

コンテキストの効率性

ハーネスの設計における主な焦点は、モデルのコンテキストを最大限に活用することでした。

Qwen 3.8 27Bなどのオンデバイスモデルは260Kトークンのコンテキストウィンドウを提供しますが、経験的に100Kトークンを超えると処理に苦労し始めることがわかりました。そのため、コアとなるハーネスは簡潔に保ち、最小限のシステムプロンプトと少数のコアツールのみを使用しています。

その他のすべての機能は、トラジェクトリ全体を通じてロードおよびアンロードされるオンデマンドのスキルへとモジュール化されています。これらのスキルは、リサーチ、データサイエンス、データ可視化、文書作成、ソフトウェアエンジニアリングなどの一般的なナレッジワークのタスク向けに設計されています。

また、ハーネスはコンテキストのコンパクションをサポートしており、トラジェクトリが長くなった際に古いコンテキストを要約することで、モデルが有効なウィンドウ内に収まるようにします。

コマンドラインツールとしてのコネクタ

日々のナレッジワークでは、Gmail、GitHub、Outlook、Googleカレンダーなどのコネクタが必要になることがよくあります。これらは通常、MCPサーバーとしてハーネスに公開されますが、その大規模なツール定義はコンテキストのかなりの部分を消費します。代わりに、私たちは最も使用されているMCPをコンパクトで使いやすいコマンドラインツールに変換し、限られた有効なコンテキストをはるかに効率的に活用できるようにするカスタムスキルで補完しました。

自己検証

エージェントが自身の作業を検証すると、パフォーマンスも向上します。検証には追加のステップが必要になりますが、最終的な結果が大幅に改善され、フロンティアモデルとのギャップが大幅に縮まります。これはモデル自身によってトリガーされるか、トラジェクトリの状態を監視し、問題が発生した際に自己検証を要求する一連のフックによってトリガーされます。

サンドボックス化された実行

ハーネスは、ユーザーのデバイス上のOSレベルのサンドボックス内でツールを実行します。この境界により、ポリシーに従ってプロセス、ファイルシステムのパス、およびネットワークアクセスが制限されます。これにより、誤ったコマンドによる影響範囲（ブラスト半径）が制限されます。サンドボックスが利用できない場合、ハーネスはサンドボックス化されていない実行にフォールバックするのではなく、ツール呼び出しの前に自らを無効化します。

これは、デフォルトでユーザーの権限で直接コマンドを実行するPiやHermesなどのオープンソースハーネスとは異なります。Computerでは、分離機能が常に有効であり、設定は不要であり、分離なしでツールを実行することはできません。

以下の図は、実行ループにおいてこれらの原則がどのように組み合わされているかを示しています。オーケストレーターはLLMではなく、決定論的なハーネスコードです。ループの維持、コンテキストの組み立て、およびポリシーの適用を行います。ローカルモデルが次のアクションを提案し、オーケストレーターが承認されたツール呼び出しをサンドボックス内で実行して、その結果をモデルに返します。ウェブ検索、コネクタ、およびアドバイザーの呼び出しは、有効化され承認された場合にのみデバイスの境界を越えます。

ローカルハーネスにより、同じモデルの性能をより多く引き出す

同じオンデバイスのベースモデルを使用し、ウェブ検索とマルチモーダル文書理解において、私たちのローカルハーネスと汎用代替品を比較します。すべてのハーネスは、NVIDIA DGX Spark上で実行される中程度の推論を備えたQwen 3.8 27Bモデルを使用しています。この比較により、モデルの事後学習を行う前に、ハーネス自体がもたらす機能を切り分けることができます。

私たちがこれら2つの機能に焦点を当てる理由は、ナレッジワークではユーザーのデバイス上のプライベートな文書とウェブからの公開情報が組み合わされて、根拠のあるアーティファクトが生成されることが多いためです。ウェブ検索には接続性が必要ですが、モデルの推論とプライベート文書の処理はローカルにとどまります。ローカルファイルが信頼できるソースとして機能し、パブリックソースがコンテキストを追加し、ユーザーは完全にオフラインでの作業を行うためにウェブ検索を完全に無効にすることができます。

ウェブ検索

私たちは、独立した評価でトップランキングを獲得しているPerplexityの検索エンジンと一緒にローカルハーネスを構築しています。ハーネスはSearch as Codeインターフェースを介してそれにアクセスします。

1,266件のBrowseCompタスクでリサーチの品質を評価します。ComputerはPerplexityの検索インフラストラクチャをローカルハーネスとともに使用し、PiとHermesは推奨検索プロバイダーであるBraveに依存しています。Computerは66.7%の精度に達し、Piの50.2%およびHermesの43.9%を上回ります。

また、Computerは記録された平均壁時計時間およびトークン使用量も最も低くなっています。タスクあたり402.1秒および852kトークンであり、Hermesの1,020.9秒および101万トークン、Piの826.0秒および282万トークンと比較して優れています。したがって、ComputerはHermesよりも壁時計時間を61%短縮し、トークンを16%削減し、Piよりも壁時計時間を51%短縮し、トークンを70%削減しています。

オンデバイスのマルチモーダル文書理解

多くの文書には視覚的な情報が含まれており、PDF、スキャンされたページ、スクリーンショット、グラフ、プレゼンテーションなどのプレーンテキストとしての解析が困難です。これらのワークフローはOCRと画像理解に依存しており、ネイティブなマルチモーダルモデルの恩恵を最も受けます。

ハーネスは文書のページや画像をモデルに直接渡し、モデルがそれらを理解して視覚的な証拠と抽出されたテキストを組み合わせます。デバイス上でこれらのファイルを処理することで、機密文書とその抽出されたコンテンツをプライベートに保ちます。

ParseBenchベンチマークの100タスクのサブセットであるParseBench-100でマルチモーダル文書理解を評価します。グラフ、レイアウト、テーブル、テキストコンテンツ、フォーマットの各カテゴリにそれぞれ20タスクが含まれています。

Computerの平均スコアは65.1%に達し、Hermesの34.6%およびPiの13.9%を上回ります。また、最小限の時間と最小限のトークンでタスクを完了します。タスクあたり平均60.6秒および20.1kトークンであり、Hermesの108.3秒および32.1kトークン、Piの410.5秒および829.1kトークンと比較して優れています。Computerは5つの文書カテゴリすべてでリードしており、グラフにおいて最大の優位性を示しています。レイアウトについては、3つのハーネスすべてにとって依然として困難な課題です。

表1：オンデバイスのQwen 3.8 27Bモデルを使用したComputer、Hermes、およびPiハーネスによる、文書カテゴリ別のParseBench-100平均スコア。Computerが5つのカテゴリすべてでリードしています。

アドバイザーのエスカレーションによるフロンティアギャップの縮小

慎重に設計されたハーネスを使用しても、最も困難なタスクは依然としてコンパクトなオンデバイスモデルの能力を超えています。このようなタスクのために、ハーネスはアドバイザーツールを公開しています。ローカルモデルは、計画の策定、曖昧さの解決、繰り返される失敗からの回復、または最終結果の検証で支援が必要なときに、より強力なフロンティアモデルに相談することができます。

ローカルモデルがアドバイスを要求するタイミングを決定し、ハーネスオーケストレーターがツールの権限を保持して送信されるコンテキストを制御します。エスカレーションはオプションです。ユーザーは、それを有効にするかどうか、および各アドバイザーの呼び出しを手動または自動で承認するかどうかを決定します。

アドバイザーを呼び出す前に、ハーネスは関連するコンテキストを選択し、PII分類器を適用して機密情報をフラグ付けし、デバイスから外部に送信される内容をユーザーに表示します。アドバイザーは承認されたコンテキストのみを受信し、テキストによるガイダンスを返します。デバイスのファイル、ツール、または会話に直接アクセスすることはできません。これによりコストとプライバシーの両方が向上し、今後の研究でこの方向性をさらに探求する予定です。

このアプローチを困難なソフトウェアエンジニアリングのタスクでテストします。これらは強力な推論を必要とし、ローカルモデルが最も頻繁に限界を迎える領域です。このために、コーディングエージェント向けの人気の89タスクベンチマークであるTerminal Bench 2.1を使用します。

私たちが答えたい疑問は2つあります。アドバイザーのエスカレーションによってフロンティアモデルとのギャップをどれだけ埋めることができるか、そしてそれはどのようなコストで行われるかということです。完全にローカルなモデルは、推論がユーザーのハードウェア上で実行されるため、実行コストが実質的にかかりません。しかし、モデルがアドバイザーの呼び出しを開始すると、APIコストが発生し始めます。

フロンティアパフォーマンスのベースラインとして、ローカルハーネス内で動作するClaude Opus 5を使用します。ローカルモデルはQwen 3.8 27Bです。最後に、この2つを組み合わせます。Qwen 3.8 27Bがタスクを実行し、支援が必要なときにClaude Opus 5アドバイザーにエスカレーションします。PiやHermesでは同等のアドバイザーツールが提供されていないため、アドバイザーのエスカレーション評価は行いません。ツールを追加するにはツールサーフェスとオーケストレーションロジックを変更する必要があり、その結果はもはや標準の（オフザシェルフの）ハーネスを表さなくなるためです。

アドバイザーのエスカレーションにより、Computerのスコアは59.6%から73.0%へと13.5パーセンテージポイント上昇し、ロールアウトあたりの推定APIコストは$0.415となります。Claude Opus 5単体での実行では、ロールアウトあたり$0.65で82.4%に達します。したがって、エスカレーションはフロンティアのコストの約3分の2でフロンティアとのギャップの約5分の一を回収し、ユーザーはそのトレードオフに見合う価値があるかどうかを決定します。

ハーネスおよびナレッジワークのための事後学習

これまでのところ、ハーネスの貢献度を切り分けるために、ローカルモデルを変更せずに維持してきました。ハーネスの設計が完了した今、残された最大の向上効果はモデル自体の適応から得られます。Perplexity Computerの使用データから、人々がナレッジワークのために実際に何を行っているかがわかり、これをトレーニングデータの合成に使用しています。ユーザーが実行するタスクの実際の分布に導かれながら、Computerハーネス内でローカルモデルの事後学習を行います。

具体的には、さまざまなモデルの機能、ツール、コネクタを試す多様なユースケースを特定します。これらのユースケースから現実的な強化学習環境を合成し、挑戦的でありながら検証可能なタスクを定義します。各タスクは、指示、環境、および最終結果をスコア化するベリファイアで構成されており、環境はハーネスが動作するDockerコンテナです。重要な点として、タスクは合成されたものであるため、実際の文書やユーザー情報は含まれていません。

これらの環境を2段階のトレーニング（拒否ファインチューニングとそれに続く強化学習）に使用します。最初の段階では、各タスクに対してモデルを複数回ロールアウトし、ベリファイアのスコアによって最適なトラジェクトリを選択し、教師あり学習でトレーニングを行います。この段階により、特定のハーネスとタスクの分布に向けてモデルが初期化されます。第2段階では、強化学習によってモデルがさらに微調整され、より堅牢になります。

タスクのサブセットはトレーニングから除外され、最終評価に使用されます。私たちはこの除外されたセットをLocal Knowledge Work Benchと呼んでいます。ディープリサーチから文書作成まで、日々のナレッジワークの7つのカテゴリにわたる53のタスクで構成されています。モデルのトレーニングについて詳細に記述したテクニカルレポートを間もなく公開する予定であり、この評価ベンチマークをオープンソース化する計画です。

このアプローチでQwen 3.8 27Bの事後学習を行い、PPLX 27Bと呼ばれるモデルを生成して、Local Knowledge Work Benchで評価しました。ベースのQwen 3.8 27Bモデルを使用した場合、Computerは最高スコア（Piの77.6%およびHermesの74.0%に対し、82.6%）を達成し、最小限のトークン（Piの681kおよびHermesの634kに対し、520k）を使用しました。Piはタスクあたり176秒で最も速くタスクを完了し、Computerの218秒、Hermesの292秒を上回りました。PPLX 27BはComputerのスコアを85.4%に引き上げますが、より多くのトークン（520kに対し678k）を使用するコストがかかります。推定壁時計時間は250秒です。

表2：Local Knowledge Work Benchのタスクカテゴリ。

まとめ

私たちの研究は、強力なオープンソースモデルが、有能なローカルハードウェアとそれらのために構築されたハーネスを備えていれば、機密データをデバイス外に送信することなく、ほぼゼロの推論コストで実際のナレッジワークを処理できることを示しています。

さまざまなベンチマークにおいて、NVIDIA DGX Spark上でQwen 3.8 27Bを実行するComputerは、精度においてHermesおよびPiと同等またはそれを上回りました。レイテンシーとトークン使用量を報告する3つのベンチマークのうち、ComputerはBrowseCompとParseBench-100で最も高速であり、3つすべてにおいて最小限のトークンを使用しました。PiはLocal Knowledge Work Benchで最も高速でした。

これらの向上は、私たちが行った選択から得られたものです。私たちは、オンデマンドでロードされるスキルを備えた簡潔なローカルハーネスを構築しました。コネクタをMCPサーバーではなくコンパクトなCLIツールに変換しました。セキュリティのために実行環境はサンドボックス化されました。

また、これらの結果は、コンパクトなモデルに改善の余地があることも示しています。たとえば、Terminal Bench 2.1の困難なコーディングタスクにおいては、すべてのハーネスにおいてローカルモデルがフロンティアモデルに後れを取っています。アドバイザーのエスカレーションによってギャップは縮まりますが、完全に埋めることはできません。パフォーマンスをさらに向上させるためには、モデル機能とローカルハードウェアの継続的な改良が依然として必要です。

ハーネスとモデルをローカルの制約に合わせて構築する目的は、ユーザーのデバイスからどのような情報が外に出るかに対して、ユーザーに明示的な制御権を与えることにあります。また、ユーザーにとってのコスト削減のメリットもあります。私たちはこれらを、ますます能力を高めるエージェントがリモートインフラストラクチャから個別のローカルデバイスへと移行していく、より広範なシフトの一環と捉えています。チップ、モデル、およびデバイスの進化により、Portable Computerがローカルで処理できるナレッジワークの範囲は継続的に拡大していくものと期待しています。