大規模な言語モデル API、動的なグラウンディング、プロンプト テンプレート、AI を活用したオーケストレーションを使用して、信頼できる AI アプリケーションを構築する方法を学びます。
生成 AI はインターネット以来最も革新的なテクノロジーであり、私たちが情報を作成し、情報とやり取りする方法に革命をもたらします。これは開発者にとって、「大規模言語モデル(LLM)を使用して AI を活用したアプリを構築するにはどうすればよいですか?」という実践的な新たな疑問を引き起こします。さらに深いところまでは、「生成 AI はアプリケーションの性質をどのように変えるのでしょうか?」このブログ投稿では、これら 2 つの質問について検討します。
LLM を使用して AI を活用したアプリを構築するにはどうすればよいですか?
最初の質問「LLM を使用してアプリを構築するにはどうすればよいですか?」から始めましょう。一般的に考慮される 3 つのオプションを検討します。
- 独自のモデルをトレーニングする
- オープンソース モデルをカスタマイズする
- API を介して既存のモデルを使用する
独自のモデルをトレーニングする
独自のモデルをトレーニングすると、モデルが学習するデータを完全に制御できるようになります。たとえば、業界固有のデータに基づいてモデルをトレーニングできます。ドメイン固有のデータでトレーニングされたモデルは、一般に、そのドメインを中心としたユースケースの汎用モデルよりも正確です。独自のモデルをトレーニングすると、より制御性と精度が向上しますが、それが常に最良のアプローチであるとは限りません。考慮すべき点がいくつかあります。
-
時間とリソース:独自の LLM をゼロからトレーニングするには、数週間、場合によっては数か月かかる場合があります。参考までに、モデルははるかに小さいと思われますが、OpenAI の GPT-3 モデルのトレーニングには 150 万 GPU 時間かかりました。
-
専門知識:モデルをトレーニングするには、専門の機械学習 (ML) および自然言語処理 (NLP) エンジニアのチームも必要です。
-
データ セキュリティ: LLM の力により、すべてのデータから学習するモデルを作成したくなりますが、これはデータ セキュリティの観点から常に正しいとは限りません。LLM の学習方法と、企業でのデータ セキュリティ ポリシーの実装方法との間に緊張が生じる可能性があります。LLM は大量のデータから学習します。データは多ければ多いほど良いです! ただし、フィールド レベル セキュリティ (FLS) と厳格なアクセス許可を使用する場合、企業のデータ セキュリティ ポリシーは多くの場合、最小特権の原則に基づいています。つまり、ユーザーは特定の仕事を行うために必要なデータにのみアクセスできる必要があります。データは少なければ少ないほど良いのです。したがって、利用可能なすべての顧客データでトレーニングされ、社内の全員が利用できるモデルは良いアイデアではなく、会社のデータ セキュリティ ポリシーに違反する可能性があります。ただし、製品仕様と過去のサポート チケット解決に基づいてトレーニングされたモデルは、エージェントがデータ セキュリティを損なうことなく新しいチケットを解決するのに役立ちます。
オープンソース モデルをカスタマイズする
オープンソース モデルのカスタマイズは、通常、独自のモデルを最初からトレーニングするよりも時間がかからず、コストも低くなります。ただし、専門の機械学習 (ML) および自然言語処理 (NLP) エンジニアのチームが依然として必要です。ユースケースによっては、上記で説明したデータ セキュリティの緊張が依然として発生する可能性があります。
API を介して既存のモデルを使用する
API を介して既存のモデルを使用するのが、LLM を使用してアプリケーションを構築する最も簡単な方法です。これは、現時点で最も一般的に使用されているオプションでもあります。ただし、これらのモデルは、独自のコンテキスト データやプライベート企業データに基づいてトレーニングされていないため、生成される出力は一般的すぎて役に立たない可能性があります。
このブログ投稿では、プロンプトを通じてコンテキスト データまたはプライベート企業データを追加するさまざまな手法を検討します。プロンプトはユーザーに代わって動的に作成されるため、ユーザーがアクセスできるデータのみが含まれ、上記のデータ セキュリティの緊張に対処します。プライベート データをサードパーティ API に渡すことを心配されるかもしれませんが、その懸念に対処するための手法があり、このブログ投稿でも説明します。
API を通じて既存のモデルを使用して AI を活用したアプリを構築する
基本的な API 呼び出し
OpenAPI、Anthropic、Google、Hugging Face、Cohereなどの主要なモデル プロバイダーは、モデルを操作するための API を提供しています。最も基本的な実装では、アプリケーションはユーザーからのプロンプトを取得し、それを API 呼び出しの一部として渡し、生成された出力をユーザーに表示します。
たとえば、OpenAI API を使用した API 呼び出しは次のようになります。
curl https://api.openai.com/v1/chat/completions \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-d '{
"model": "gpt-3.5-turbo",
"messages": [{"role": "user", "content": "Write a haiku about winter"}],
"temperature": 0.7
}'
このオプションは、一般的な知識に基づく一般的な出力のみを必要とする単純なユースケースで機能する可能性があります。たとえば、「冬に関する俳句を書く」や「外部結合を使用したサンプル SQL ステートメントを書く」などです。しかし、独自のコンテキスト データや企業の非公開データに合わせた答えが必要な場合、生成された出力は一般的すぎて役に立たない可能性があります。
たとえば、ユーザーが次のプロンプトを入力したとします。
Acme CEO に紹介メールを書きます。
モデルはあなたと Acme との関係や、あなたが Acme と行ったビジネスについて何も知らないため、生成される電子メールはパーソナライズされておらず、関連性もありません。
LLM の接地
応答をより関連性があり状況に応じたものにするために、ユーザーは追加情報を使用して LLM を接地できます。たとえば、次のプロンプトを入力する場合があります。
あなたは、Northern Trail Outfitters のアカウント代表者の John Smith です。
ACME の CEO、Lisa Martinez に紹介メールを書いてください。
Acme がノーザン トレイル アウトフィッターズに発注した過去 3 件のリストは次のとおりです。
サマー コレクション 2023: 375,286 ドル
2023 スプリング コレクション: 402,255 ドル
2022 ウィンター コレクション: 357,542 ドル
これにより、LLM はより関連性の高い出力を生成できるようになります。ただし、このアプローチには 2 つの問題があります。
-
ユーザーは多くの接地情報を手動で入力する必要があります。したがって、出力の品質は、ユーザーが入力した質問の品質に大きく依存します。
-
機密情報をモデルプロバイダーに渡していると、その情報が永続化されたり、モデルをさらにトレーニングするために使用されたりする可能性があります。つまり、プライベートデータが他の人のモデル生成応答に現れる可能性があります。
迅速な施工と動的接地
上記の最初の制限に対処するには、プロンプトをプログラムで作成できます。ユーザーが最小限の情報を入力するか、アプリ内のボタンをクリックするだけで、関連データを追加してプログラムでプロンプトを作成します。たとえば、「紹介メールを書く」ボタンをクリックすると、次のことが可能になります。
- サービスを呼び出してユーザーに関する情報を取得します。
- サービスに電話して、連絡先に関する情報を取得します。
- サービスを呼び出して、最近の商談のリストを取得します。
- 上記のデータ サービスから取得した情報を使用してプロンプトを作成します。
Apex でのプロンプト構築手順は次のようになります。
User u = UserController.getUser();
Contact c = ContactController.getContact(contactId);
List oppties = OpportunityController.getOpportunities(c.Account.Id);
String prompt = 'Your are ' + u.Name + ', ' + u.Title + ' at ' + u.CompanyName + '\n';
prompt = prompt + 'Write an intro email to ' + c.Name + ', ' + c.Title + ' at ' + c.Account.Name + '\n';
prompt = prompt + 'Here are the ' + c.Account.Name + ' opportunities: \n';
for (Opportunity opportunity : oppties) {
prompt = prompt + opportunity.Name + ' ' + opportunity.Amount + '\n';
}
このアプローチの主な欠点は、動的データを静的テキストにマージするという単純なタスクを実行するために、プロンプトごとにカスタム コードが必要になることです。
プロンプトテンプレート
プロンプトの構築を容易にするために、テンプレートを使用できます。テンプレートは、動的データを静的ドキュメントにマージするためによく使用されるよく知られたソフトウェア開発パターンです。テンプレートを使用すると、実行時に動的データに動的に置き換えられるプレースホルダーを使用してプロンプト ファイルを作成します。
汎用テンプレート言語を使用した上記の Apex の例は次のようになります。
あなたは、{{ user.CompanyName }} の {{ user.Name }}、{{user.Title } }
です。{{ contact.Name }}、{{contact.Title}}（{{ contact. Account.Name }}
{{contact.Account.Name}} の案件は次のとおりです:
{{#opportunities}}
{{Name}} : {{Amount}}
{{/opportunities}}
プロンプト テンプレートは、プログラムでプロンプトを作成するのに役立つだけでなく、ドラッグ アンド ドロップ環境でのプロンプトの作成をサポートするグラフィカル ツールの基盤としても使用できます。
プロンプトビルダー
そのため、プロンプトの作成を容易にする新しい Salesforce ビルダーである Prompt Builder を作成しました。これにより、グラフィカル環境でプロンプト テンプレートを作成し、レコード ページ データ、フロー、データ クラウド、Apex 呼び出し、または API 呼び出しを通じて使用できる動的データにプレースホルダー フィールドをバインドすることができます。プロンプトテンプレートを作成すると、レコードページや Apex コードなどのモデルをクエリするためにさまざまな場所で使用できます。
Einstein トラストレイヤー
プロンプト ビルダーを使用すると、グラフィカル環境で動的に固定されたプロンプトを定義できます。しかし、そのプロンプトを LLM プロバイダーに安全に送信するにはどうすればよいでしょうか?
プロンプトを LLM プロバイダーの API に直接送信することもできますが、その方法では考慮すべき問題がいくつかあります。
- プロンプトで個人を特定できる情報 (PII) データを渡す場合、コンプライアンスとプライバシーの問題はどうなりますか? PII データはモデルプロバイダーによって永続化される可能性がありますか、あるいはモデルをさらにトレーニングするために使用される可能性もありますか?
- LLM によって生成される出力の幻覚、毒性、バイアスをどのように回避しますか?
- 監査の目的で、プロンプトの作成手順をどのように追跡して記録しますか?
LLM プロバイダーの API を直接使用する場合は、これらの質問を処理するカスタム コードを作成する必要があります。考慮すべき点は数多くあり、すべてのユースケースに適切に対応するのは難しい場合があります。
Einstein トラストレイヤーに入ります。Einstein Trust Layer を使用すると、信頼できる方法で LLM にリクエストを送信できるようになり、前述の懸念事項に対処できます。
その仕組みは次のとおりです。
- 直接 API 呼び出しを行う代わりに、LLM ゲートウェイを使用してモデルにアクセスします。LLM ゲートウェイはさまざまなモデル プロバイダーをサポートし、それらの違いを抽象化します。独自のモデルを接続することもできます。
- リクエストはモデルプロバイダーに送信される前に、データのプライバシーとコンプライアンスを確保するために PII データを偽のデータに置き換えるデータマスキングなどの多くの手順を経ます。
- データをさらに保護するために、Salesforce はモデルプロバイダーとの間で保持契約を結んでいません。つまり、モデルプロバイダーは、Salesforce から送信されたデータを使用してモデルを永続化したり、さらにトレーニングしたりすることはありません。
- 出力がモデルから受信されると、マスク解除、毒性検出、監査証跡ログなどの別の一連のステップが実行されます。デマスキングは、プライバシーのために偽のデータに置き換えられた実際のデータを復元します。毒性検出は、出力内の有害または不快なコンテンツをチェックします。監査証跡ログは、監査の目的でプロセス全体を記録します。
将来を見据えて: まったく新しい方法でアプリケーションを構築する
ここで、今後の展開を覗いて、この記事の冒頭で挙げた 2 番目の質問、つまり生成 AI はアプリケーションの性質をどのように変えるのでしょうか? に答えてみましょう。
プロンプトチェーン
プロンプトの作成に含まれるロジックは、複雑になる場合があります。上記の動的グラウンディングの例のように、複数の API またはデータ サービスの呼び出しが含まれる場合があります。単一のユーザーの質問に答えるには、LLM への複数の呼び出しが必要になる場合もあります。これはプロンプトチェーンと呼ばれます。次の例を考えてみましょう。
プロンプトを作成するには:
- 最初の API またはデータ サービス呼び出しを行って、コンテキストに沿った企業データを取得します
- 最初のデータ サービス呼び出しから返されたデータは、LLM のクエリに使用する最初のプロンプトを作成するために使用されます。
- LLM の出力は、2 番目のデータ サービス呼び出しの入力として使用されます。
- 2 番目のデータ サービス呼び出しから返されるデータは、応答がユーザーに返される 2 番目のプロンプトを作成するために使用されます。
データ サービス呼び出しと LLM 呼び出しを組み合わせて出力を生成する可能性は無限です。
AIオーケストレーション
これまで説明したアプローチはうまく機能しますが、これらのワークフローがより複雑になるにつれて、何らかの形式のオーケストレーションが必要になることがわかります。開発者は、顧客に関するデータの取得、レコードの更新、計算ロジックの実行など、きめ細かなタスクを実行する一連のビルディング ブロックを構築します。その後、これらのビルディング ブロックは、オーケストレーションツール。これは、どのビルディング ブロックを、どのような順序で、いつ (さまざまな "if" 分岐を使用して) 使用するかを定義できる従来のオーケストレーション ツールを使用して実行できます。しかし、オーケストレーション自体が、どの構成要素を使用するか、特定のタスクを実行するためにそれらを構成する方法を推論して選択できるオーケストレーターを備えた AI によって強化されているとしたらどうなるでしょうか? AI を活用したオーケストレーションは、AI システムと対話してアプリケーションを構築する方法に革命をもたらす可能性のある強力な新しいパラダイムです。
以下の図は、AI によって調整されたこの新しいビルディング ブロック パラダイムを高レベルで説明しています。
この図では、アクションは上で説明した構成要素です。これらは、Apex 呼び出し可能なアクション、MuleSoft API、またはプロンプトである可能性があります。いくつかの基本的なアクションはデフォルトで利用可能ですが、その他は開発者によって開発されます。これは、開発者やパートナーによって構築されたアクションのマーケットプレイスの機会も生み出します。
プランナーはAI を活用したオーケストレーターです。プロンプトがオーケストレーション ランタイムに渡されると、プランナーは、ユーザーの要求に最もよく応えるために、使用するアクションとその構成方法を選択 (計画の作成) します。
AI オーケストレーションは、Salesforce および業界全体で活発な研究分野です。
まとめ
API を介して既存のモデルを使用することは、LLM を使用して AI 搭載アプリを構築する一般的な方法です。このアプローチを使用すると、より関連性が高く有用な出力を得るために、企業のプライベート データまたはコンテキストに基づいたデータをモデルに基礎付ける必要があります。ユーザーに多くの基礎情報を手動で入力するよう求める代わりに、データ サービスを呼び出してプロンプトにコンテキスト データを追加することで、プログラムでプロンプトを構築できます。プロンプトビルダーは、グラフィカル環境でプロンプトテンプレートを作成し、プレースホルダーフィールドを動的データにバインドできるようにすることで、プロンプトの作成を容易にする新しい Salesforce ビルダーです。Einstein Trust Layer を使用すると、信頼できる方法で LLM プロバイダの API にプロンプトを送信でき、データのプライバシー、バイアス、毒性の問題に対処できます。AI を活用したオーケストレーションは、AI システムと対話してアプリケーションを構築する方法を変える可能性のある新たなパラダイムです。