Salesforce 開発者がローカルマシン上で動作する LLM アシスタントを作成

私は Salesforce 内のローカル LLM を試してきましたが、その結果として開発したコンポーネントについてお話ししたいと思います。このコンポーネントには、Salesforce レコードをコンテキストとして使用する、すでにおなじみのチャット インターフェイスがあります。このコンポーネントはコンピューター上でローカルに動作するため、処理されたデータはサードパーティのサービスに送信されません。

Agentforce の導入が、私がこのコンポーネントを開発するきっかけとなりました。Agentforce は、エージェント (意思決定を行い、さまざまなアクションを実行できるシステム) を使用します。一方、アシスタントは情報をリアクティブに処理するだけです。Pico LLM を使用してローカル エージェントを構築することは可能だと思いますが、膨大な労力がかかります。そのため、代わりにアシスタントを開発することにしました。

特徴

LLM が機能すると予想されるとおり、膨大なデータセットで事前トレーニングされているため、あらゆるトピックに対する応答を生成します。さらに、Salesforce レコードを使用して追加のコンテキストを取得できます。このコンポーネントの機能は次のとおりです。

• 複数のモデルをサポートします。Gemma 、Llama、Phi など、Pico Web サイトのオープンソース モデルはすべて使用できます。ここでの唯一の制限は、コンピューターの RAM の量です。モデルの重量が重いほど、消費する RAM の量も多くなります。
• 単一のレコードで動作します。コンポーネントをレコード ページに配置すると、コンテキストのレコードにアクセスできるようになります。たとえば、取引先レコードの詳細ページにある場合、フィールド値に基づいて応答を生成できます。
• 関連レコードをサポートします。レコードに関連レコードがある場合、コンポーネントはそれらをクエリして応答に組み込むことができます。
• 設定可能。設定ポップアップを使用して、コンポーネントをオンザフライで設定できます。完了トークン制限、温度、トップ P などの生成オプションを変更できます。

仕組み

エンドユーザーの観点から見ると、プロセスは簡単です。モデルをアップロードし、システムプロンプトを選択し、レコードを選択し、ユーザープロンプトを記述して、生成される結果を確認します。

Pico LLMとは何ですか?

ブラウザで LLM を実行するのは、モデルのサイズ、帯域幅要件、RAM の必要性により、リソースを消費するタスクです。そのため、Pico チームは、コンピュータで LLM をローカルで使用する際の効率を大幅に高める picoLLM 圧縮技術を開発しました。彼らは、フロントエンド開発者がブラウザ間で LLM をローカルに実行できるように、picoLLM 推論エンジンを JavaScript SDK として提供しました。これは、Chrome、Safari、Edge、Firefox、Opera を含むすべての最新ブラウザをサポートしています。picoLLM 推論エンジンの仕組みについて詳しくは、記事をお読みください。

LWCの部分

このコンポーネントは、ユーザーと PicoLLM インターフェース間のブリッジとして機能します。コンポーネントの中心には、iframe として埋め込まれた Visualforce ページがあります。このページは PicoLLM SDK を読み込み、LWC と通信して、ポスト メッセージを介して SDK を使用できるようにします。要素の組み合わせ全体は、次のことを処理します。

• モデルの読み込み。LWCには、選択したモデルを読み込むためのボタンがあります。このボタンは、iframe 内に隠されたファイル入力要素をトリガーします。モデルが読み込まれると、Pico SDK は Web ワーカーを作成し、コンポーネントはユーザー入力を処理できるようになります。
• システム プロンプトの設定。毎回システム プロンプトを記述する必要はありません。System_Prompt__c System_Prompt__cの保存されたレコードを簡単に選択できます。ボタンを押すと、選択可能な既存のシステム プロンプトを含むポップアップが表示されます。
• ユーザー入力を受け入れます。ユーザー入力を収集するためのサイズ変更可能なテキスト領域があります。収集されると、ペイロードとして iframe に送信され、会話履歴に追加されます。
• Salesforce レコードにアクセスします。 [フィールドの選択] と [関連レコードの選択] の 2 つのボタンがあります。最初のボタンは、LWC が存在するレコード ページのレコードのフィールド値を収集します。2 番目のボタンを使用すると、関連オブジェクトを選択し、選択したフィールド値とともにそのレコードをクエリできます。この情報は、ペイロードとしても iframe に送信されます。
• 生成オプションの変更。必要に応じて、コンポーネント内の専用ボタンを使用して、完了トークン制限、温度、およびトップ P オプションを変更できます。この情報は、iframe へのペイロードとしても送信されます。
• 結果の生成。iframeがペイロードを受信すると、Pico SDK を使用してロードされたモデルを活用し、結果を生成します。生成オプションが指定されている場合は、それらが考慮されます。また、ダイアログは毎回更新されるため、LLM はその履歴を記憶します。
• チャット メッセージのレンダリング。LWCは、ユーザーが提供した送信メッセージをレンダリングできます。生成された応答を含む受信メッセージは、コンポーネントがユーザーに伝える内容があると、動的にレンダリングされます。生成された結果や情報、エラー メッセージなどです。

ちょっとしたApexコード

バックエンド側では、特別なことは何もありません。Apex コードは、レコード ページのレコード ID を使用してオブジェクト間の関係を検出することに関連するすべての面倒な作業を実行します。また、いくつかの SOQL クエリを実行し、その役割はここで果たされます。

開発の課題

ウェブワーカー

以前は、LWC コンポーネントのノード モジュールからコードを実行するために unpkg ツールを使用していました。このアプローチでは追加の構成手順が必要になり、安全性の低い方法で動作していました。今回は、Salesforce から直接 PicoLLM モジュールを実行し、以前実行した Experience Cloud サイトだけでなく、Lightning Experience インターフェースからも実行したいと考えました。

内部的には、PicoLLM は並列処理に Web ワーカーを使用しますが、LWC から実行できないことが主な問題でした。幸いなことに、Visualforce ページから Web ワーカーを実行することを拒否する人はいませんでした。それが私が使用したアプローチでした。

私は生の PicoLLM コードをダウンロードし、それを静的リソースとして Visualforce ページに追加しました。LWC では、Visualforce ページを含む iframe を使用しました。LWC と iframe 内のページ間の通信により、Web ワーカーを使用できるようになりました。このページは、Lightning Web コンポーネントから PicoLLM 関連コードをトリガーします。

Salesforce レコードをコンテキストとして使用する

Salesforce レコードを JSON または CSV 形式でコピーして貼り付け、任意のオンライン LLM に投入して確認します。レコードが消費され、追加のコンテキストに使用され、応答が生成されます。圧縮モデルをローカル処理に使用すると、それほど簡単ではないことがわかりました。

最初は、レコードを JSON 形式でユーザー プロンプトに直接入力していました。その後、プロンプト自体と私が提供した追加のコンテキストを区別できるほどスマートになるだろうと期待しました。さまざまなサイズのさまざまなモデルを使用しましたが、応答の生成に JSON が使用されない理由がわかりませんでした。ほとんどの場合、プロンプトへの応答が拒否されたり、要求したこととは関係のない架空のデータが生成されたりしました。コンテキスト データのさまざまな形式を試し始めました。CSV の使用、JSON の使用、プロンプト区切りを使用してプロンプトとコンテキストを厳密に区別するなど、何も役に立ちませんでした。

主要機能が動作しなかったため、このアイデアをあきらめそうになりました。数か月後、突然、ばかばかしいほど単純なひらめきが浮かびました。プロンプト部分の順序を逆にしたらどうなるでしょうか。ユーザー プロンプトが最初に来てコンテキストが 2 番目になるという状態から、コンテキストが最初に来てプロンプトが 2 番目になるという状態にしました。驚いたことに、これはうまくいき、使用したどのモデルでもすぐに Salesforce レコードをコンテキストとして理解し始めました。

パフォーマンス

コンポーネントの機能は次のマシンでテストされました:

• AMD Ryzen 9 9900X プロセッサと 32GB の RAM (5600 MT/s) を搭載した PC。
• Microsoft Surface Laptop 7 は、16 GB の RAM (8448 MT/s) を搭載した Snapdragon X-Elite ARM プロセッサを搭載しています。

モデルの読み込み速度はメモリがすべて

コンポーネントの使用で最も時間がかかるのは、最初のモデルの読み込みです。9900X は Snapdragon X-Elite よりも簡単にパフォーマンスが優れていると思われるかもしれませんが、それは間違いです。驚いたことに、後者の方が高速です。メモリが高速なので、RAM が高速であればあるほど、モデルの読み込みが高速になると思います。参考までに、モデルの読み込み速度の比較表を以下に示します。

応答生成速度

応答生成速度についても同じことが言えます。私が理解しているように、可能な限り最速の生成を得るには、CPU と RAM の高速な組み合わせが必要です。応答生成は同じプロンプトでも異なるため、正確な速度テストは実施していません。それでも、生成速度は非常に速く、オンラインの代替手段とほぼ同じくらい速いです。

GPU を使用する場合はどうでしょうか?

実際、GPU を使用して応答を生成する方がはるかに効率的です。PicoLLM で GPU を使用することは可能ですが、私はその構成を自分でテストしていません。これにはいくつかの理由があります。まず、ほとんどのブラウザー (Edge を除く) ではデフォルトで有効になっていない WebGPU 機能を使用していると思われます。次に、モデルをロードするにはおそらく数ギガバイトの VRAM が必要ですが、私にはそれがありません。

結論

このアシスタントの開発は、魅力的な探求の旅でした。Web ワーカーの制限への取り組みから、コンテキストを提供する際の迅速な順序付けの重要な役割の発見まで、課題は刺激的でやりがいのあるものでした。その結果、Salesforce エコシステム内で大規模言語モデルのパワーを活用するための独自のアプローチを提供する Lightning Web コンポーネントが誕生しました。

特に大規模なモデルの場合、初期のモデル読み込み時間は考慮すべき事項ですが、データをローカルで処理する機能は、データのセキュリティ、応答性、コスト効率の点で大きな利点があります。コンテンツ生成の自動化からインテリジェントな支援の提供まで、潜在的なユースケースは膨大であり、検討されるのを待っています。

GitHub リポジトリを確認してください。