AgentforceとRAG： AIエージェントを向上させるベストプラクティス

Reinier van Leuken、Agentforce部門製品管理シニアディレクター

このガイドでは、非構造化データと長い自由テキストフィールドを活用して、Agentforce 360 Platform上で検索拡張生成（RAG）によってAgentforceを強化するためのベストプラクティスを提供します。 RAGは、ファイル、メール、記事、ドキュメント、通話メモ、目的の説明、構造化されたテーブルのフィールドなどを含む企業のエンタープライズナレッジを活用して、AIエージェントの応答をより正確で最新のものにし、関連性を高めることで、その質を高めます。 RAGツールの中には、シンプルでそのまま使用できるものもあれば、詳細な設定オプションを提供しているものもあります。 本ガイドは、Salesforceシステム管理者および開発者が、情報にもとづいて設計に関する選択を行いソリューションを最適化する上で役立ちます。

このコンテンツは実際の導入シナリオにもとづいており、一般公開中、またはオープンベータ版のテクノロジーを対象としています。 ロードマップの項目について審議される場合があり、これらは#ロードマップと記されており、可能な場合にはリリースのタイムラインが提供されています。これは、付録内の将来予想に関する記述の対象となります。

このドキュメントは、help.salesforce.comおよびTrailheadドキュメントを補完し、高性能AIエージェントを実現するための実践的なガイダンスを提供します。

本ガイドの「はじめに」では、Agentforce 360 Platform上のRAGの概要をご紹介します。 ただし、本ガイドは完全な初心者向けではありません。 この章の最後には、本ガイドの残りの部分を理解するための前提条件が記載されています。

Data 360のRAGは、大規模言語モデル（LLM）のプロンプトをグラウンディングするためのフレームワークです。 正確かつ最新で関連性の高い情報を追加することで、RAGはユーザーへのLLMの応答の関連性と価値を高めます。 プロンプトにデータを取り込むには、差し込み項目やデータグラフなど、さまざまな方法があります。 本ガイドでRAGについて言及する場合、クエリとの意味的な類似性にもとづいて取得された長文テキストコンテンツでプロンプトを拡張することを指します。

LLMプロンプトを送信すると、Data 360のRAGは以下のように動作します。

• ナレッジストアである検索インデックスから、構造化および非構造化コンテンツなどの関連情報を取得
• 元のプロンプトとこの情報を組み合わせてプロンプトを拡張
• プロンプトの応答を生成

多くのLLMは、インターネット上で一般公開されている静的なコンテンツをもとに学習しています。 RAGは、企業の非公開データなど、LLMの学習データに含まれていない、正確な最新情報をプロンプトに追加し、ナレッジストアからの関連情報によってLLMの機能を補完します。 RAGを使用すると、ユーザーはモデルの再学習や微調整を行うことなく、独自のデータをLLMに提供できます。 その結果、ユーザーのコンテキストやユースケースにより適したLLMの応答を得ることができます。

RAGのユースケースの例は以下のとおりです。

• ナレッジ記事、ドキュメント、研究論文を使用して質問に回答する
• メモ、メール、通話の文字起こしを使用して営業会議の概要を生成する
• 過去の類似ケースの解決結果を使用してサービス返信を生成する

オフライン準備とオンライン利用の2つの主要な部分で分けて考えると、RAGを理解しやすくなります。

リトリーバーを含むプロンプトテンプレートが実行されるたびに、上記の図に示されているようなシーケンスが発生します。

1. リトリーバーは、プロンプトテンプレートの動的クエリで呼び出されます。
2. クエリはベクトル化され、数値表現に変換されます。 ベクトル化によって、すでにベクトル化されている検索インデックス内で、この検索が意味的な一致を見つけることができるようになります。
3. クエリは、検索インデックス内のインデックス化されたデータから関連するコンテンツを取得します。
4. 元のプロンプトには、検索インデックスから取得した情報が入力されます。
5. プロンプトがLLMに送信され、応答が生成されて返信されます。

クエリはプロンプトにおける重要な要素です。 これには、ユーザーのインテントを反映した検索文字列が含まれています。 RAGプロセスは、この検索文字列を使用して、意味的な類似性にもとづいて関連するデータを検索します。このプロセスでは、正確な単語ではなく、意味に重点が置かれます。 ハイブリッド検索は、セマンティック検索にキーワードの類似性を追加することで、LLMの応答品質を向上させることができます。 RAGは、識別子や単一のキーワードを使った単なるデータ検索とは異なります。 RAGには必ず、複数のキーワードを含む検索文字列との意味的な類似性にもとづいて、より長い自由記述形式のテキストデータを特定することが伴います。

Agentforce Builderまたは設定でAgentforceデータライブラリ（ADL）を追加する ことが、RAGソリューションを設定する最短の方法です。 ADLを作成すると、RAGを活用したソリューションの動作に必要なすべてのコンポーネントが自動的に設定されます。 これらのコンポーネントには、データストリーム、オブジェクトとマッピング、ベクトルデータストア、検索インデックス、リトリーバー、プロンプトテンプレート、およびエージェントアクションが含まれます。 Salesforceは、これらのコンポーネントにデフォルト設定を使用します。 作成したコンポーネントをベースとして、さらに設定や改良を行うこともできます。 たとえば、カスタムテンプレートでデフォルトのリトリーバーを使用したり、検索インデックス用にカスタムリトリーバーを作成したりできます。

Data 360でRAGを手動で実装するには、まず、LLMプロンプトのグラウンディングのために、RAGが関連情報を取得する構造化データおよび非構造化データを接続します。Data 360は、検索インデックスを使用して、構造化および非構造化コンテンツを検索に最適化された方法で管理します。 サポートされているファイルタイプのコンテンツは、さまざまなソースから取り込むことができます。 RAGで使用される非構造化コンテンツには、サービス返信、ケース、RFPの回答、ナレッジ記事、よくある質問、メール、会議メモなどがあります。

Data 360でのオフライン準備の手順は以下のとおりです。

1. 非構造化データ（DSO → DLO/UDLO → DMO/UDMO）を接続します。
2. コンテンツをチャンク化してベクトル化するための検索インデックスの設定を作成します。 チャンク化によって、テキストを文や段落のような小さな単位に分割します。 ベクトル化によって、これらの分割された要素を、意味的な類似性を捉える数値表現に変換します。
3. Data 360で検索インデックスを保存および管理します。

詳細については、AI、自動化、分析の検索 をご確認ください。

リトリーバーは、検索インデックスとプロンプトテンプレートの間の橋渡し役として機能します。 検索インデックスを作成すると、Data 360は自動的にデフォルトのリトリーバーを作成します。これは、エージェントスタジオで表示されます。 さまざまなユースケースに対応するために、エージェントスタジオ でカスタムリトリーバーを作成できます。 プロンプトを拡張するために、カスタムリトリーバーは検索条件を改善し、フィルターを追加したり、追加の返信フィールドを含めたりするなどして、コンテキストとの関連性がもっとも高い情報を取得します。 詳細については、リトリーバーの管理 をご確認ください。

RAG実装の最後の要素となるのが、プロンプトテンプレートにリトリーバーへの呼び出しを追加することです。 特定のプロンプトテンプレートに対して、プロンプトデザイナーは、リトリーバークエリおよび結果設定をカスタマイズすることができます。これにより、プロンプトとの関連性がもっとも高い情報が入力されます。 詳細については、Data 360における検索拡張生成（RAG）によるグラウンディング をご確認ください。

これまで、検索インデックスのオフライン準備と、プロンプトテンプレート内でのオンライン使用について説明してきました。 RAGをAgentforceで実装するには、このプロンプトテンプレートを呼び出すエージェントアクションが必要です。 以下の図は、RAGを活用したAIエージェントのランタイムフロー全体を示しています。

RAGを活用したAIエージェントのフロー

上のフローは、Agentforceが適切なモデルとリトリーバーを選択し、構造化データと半構造化データを組み合わせた非構造化データにもとづいて適切なアクションを実行する方法を示しています。

本ガイドの内容への理解を深めるために、以下のコンテンツをご確認ください。

• Trailheadモジュールを完了する： 検索拡張生成： 概要
• Trailheadモジュールを完了する： Data 360における非構造化データ
• デモ動画を見る： 非構造化データからAgentforceへ
• ドキュメントを読む： データライブラリを追加
• ドキュメントを読む： AI、自動化、分析の検索
• ドキュメントを読む： リトリーバーを管理
• ドキュメントを読む： Data 360における検索拡張生成（RAG）によるグラウンディング

構造化コンテンツには、数値や関係性を備えた意味のある構造に従ったオブジェクトやデータテーブルが含まれます。 これらには、カテゴリ型（ピックリスト、識別子）、数値型、参照型などのフィールドがあります 一部の構造化コンテンツには、説明、会話、記事などの長文テキストフィールドがあります。 これらのフィールドのうち、意味的に有益なファクトイドを表す完全な文がテキストに最低1つ含まれているもののみ、RAGに使用できます。 機密レベル、閲覧数、商品の種類など、インデックス化可能なテキストに関連するカテゴリ型および数値型のフィールドは、セクション5.1で説明されているように、インデックスを充実させる目的で使用できます。

構造化コンテンツの例には、ナレッジ記事用のSalesforceオブジェクト（記事本文、説明などを含む）、ケース（ケース詳細、解決結果、まとめなどを含む）、アクティビティ（アクティビティメモを含む）があります。

ドキュメント、記事、メール、メモなどの長文テキストのファイルは、非構造化コンテンツと呼ばれます。 これには、RAGプロセス向けにテキスト化された音声ファイルや動画ファイルが含まれる場合もあります。 音声ファイルと動画ファイルは、元の場所（ゼロコピー・ファイルストア）に保持されます。 これらは、音声をテキストに変換する文字起こしサービスに送信されます。 次に、文字起こしされたデータはチャンク化およびベクトル化され、分割要素とベクトルのみがData 360に保存されます。

当然ながら、すべてのファイルが非構造化に該当するわけではありません。 ファイルにJSON、CSV、XML形式などのフィールドと値を持つ固有の構造が含まれている場合、まず構造化データとして読み込む必要があります。 長文テキストのみがチャンク化およびベクトル化に使用できます。 その他のフィールドは、セクション5.1で説明されているように、インデックスおよび検索の強化に使用できます。

LLMのプロンプトや応答を向上させるために、ソースコンテンツを調整して、情報検索を最適化します。 特定の製品の機能は、インデックス化の強化（セクション5.4）やフィールドのプリペンド（セクション5.1）など、不適切に作成されたコンテンツの問題に対応しています。 しかし、ソースコンテンツにコンテンツキュレーションの手法を適用すれば、検索を強化し、結果を向上させることができます。

• Salesforceナレッジ記事
• 以下の形式でアップロードされたファイル
  • PDF（最大100MB）
  • HTML（最大4MB）
  • txt（最大4MB）

Data 360で手動作成された検索インデックスでは、以下のような追加のコンテンツソースに対応しています。

• 任意のDMO上の自由テキストを含むテキストフィールド。 例： CRMコネクターを使用してSalesforceオブジェクトから発生した場合、または他のシステムからData 360に取り込まれた場合。
• Salesforceレコードからの関連ファイル
• Salesforceナレッジ記事（Data 360でDMOとして取り込むパターンを使用）
• サポートされているファイル形式：
  • PDF（最大100MB）
  • HTML（最大4MB）
  • txt（最大4MB）
  • 音声（mp3、wav、flac、mpga、m4a、ogg）
  • 動画（mp4、mpeg、webm）
• サポートされているファイルストレージプラットフォーム*：
  • AWS S3
  • Google Cloud Storage
  • Azure Blob Store
  • #ロードマップ MuleSoft Directコネクター経由：
  • SharePoint
  • Googleドライブ（Googleドキュメントを含む）
  • Confluence
  • Sitemap

*注： ファイルはData 360にコピーされません。 その代わりに、必要なメタデータとインデックス化されたコンテンツのみを処理して保存するゼロコピーアプローチを使用します。

以下の推奨事項は、ナレッジ記事やその他の長文テキストを含むオブジェクトなど、長文テキストフィールドに保存されたドキュメントや長文テキストに適用されます。 AIによって生成された記事の場合、これらの推奨事項をプロンプト内の指示として提供できます。

1. 高度な詳細と徹底的な説明を提供する
   生成AIは、きめ細やかで完全な情報が提供される場合にもっとも効果的に機能します。 プロンプトで指定された特定のオーディエンスに合わせて、詳細の程度を変えながらデータをまとめ、ユーザーへと提供することができます。 たとえば、AIエージェントとのチャットにおいて、顧客は短くて直接的な回答を求めがちです。 しかし、サービス担当者が複雑な問題を診断する場合、通常は包括的な技術情報が必要となります。 一般的に、ナレッジコンテンツでは、簡潔すぎるよりも、きめ細やかで詳細であることが最善です。 詳細なコンテキスト情報を提供することで、適切なコンテンツを取得できます。 たとえば、記事内で一般的な類義語や略語を説明することで、LLMはナレッジコンテンツ内のさまざまな概念の関連性をさらに深く理解できるようになります。
2. 実際の事例を提供する
   ナレッジ記事では、指定されたトピックについて一般的なユーザーが直面し得る事例を含め、それらを詳細に説明しましょう。 これらのシナリオを会話形式で提供することで、検索プロセスがユーザーの問い合わせに対して適切なコンテンツを特定しやすくなります。
3. 記事を適切に構成する
   各文が互いに論理的に関連付けられているようにします。 意味的かつ論理的にまとまりのある段落にコンテンツを整理します。 HTML形式のコンテンツでは、見出しタグ（H1からH6）を使用して、コンテンツの階層的な関係を示します。 チャンク化プロセスは、チャンクの区切りとして見出しタグを使用します。
4. Salesforceナレッジ記事のフィールドにコンテンツを分散する
   Salesforceナレッジ記事をチャンク化およびベクトル化する際、検索インデックスは構造化されたDMOに対して構築されます。 長文コンテンツを質問、説明、解決結果、例外など複数のフィールドに分散させることで、この構造を活用できます。 ナレッジ記事に、セクション5.1で説明されているフィルタリングとプリペンド用のメタデータを付与します。
5. メディアに代替テキストを付与する
   チャンク化およびベクトル化プロセスは、ドキュメントに含まれる動画ファイルと画像を無視します。 ただし、それらに関連付けられた説明はチャンク化され、ベクトル化されます。 メディアのコンテンツを詳細な代替テキストで説明し、その意味と値が検索インデックスに含まれるようにします。
6. 一般的なユーザーの質問に合わせてコンテンツの焦点を絞って構造化する
   RAGは、多くの場合、よくある質問エージェントなどがユーザーの質問に回答するために使用されます。 システムはそこから、コンテンツとユーザーのクエリの意味的な関係を確立する必要があります。 質問と回答が一緒にベクトル化されるため、ドキュメント内で質問と回答を明示的にリンクすることで意味的なつながりが強化されます。 一般的なユーザーマニュアルといった、その他のドキュメント手法の場合、質問とコンテンツの意味的な一致はそれほど明確ではありません。 記事が単一のトピックに重点を置けるように、コンテンツをセグメント化します。 無関係またはほぼ関係のない複数のトピックを1つの記事にまとめないようにします。
7. タイトル、見出し、小見出しを使用する
   タイトル、見出し、小見出しによって、コンテンツに有用なコンテキストを提供できます。 さらに、この情報を追加のフィールドに保存し、プリペンドに使用すると効果的です（セクション5.1を参照）。 このコンテキストは、強化されたチャンク化機能（セクション5.4を参照）によって生成することもできますが、LLMにこのコンテキストを追加させるのではなく、ドキュメント内で明示的に含めるのが最善です。
8. ナレッジ監査を実施し、ガバナンスを適用する
   不正確で古い情報にグラウンディングすると、同様の応答がAIによって生成されてしまいます。 ナレッジベースの定期的な監査を実施し、問題があれば迅速に修正します。 ナレッジコンテンツにはバージョン管理を使用し、バージョンを管理して検索インデックスのコンテンツを統制します。

従来のRAGのベストプラクティスでは、長いテーブルを分割したり、PDFをJSONに変換してから取り込んだりなど、複雑なドキュメントをフォーマットする多大な手作業が必要でした。 Data 360のインテリジェントコンテキストや高度な解析オプションの導入により、この手作業によるキュレーションを行う必要がなくなりました。 AIを活用して、コンテンツを自動的にキュレーション、解析、構造化し、最適な検索を実現できるようになっています。

インテリジェントコンテキストは、Data 360内のAIを活用したワークスペースです。完全な検索インデックスを構築する前に、非構造化データの処理方法を対話的にテストおよび調整できます。 「ブラックボックス」的な取り込みプロセスの代わりに、チャンク化および抽出論理を最適化できる実践的な環境を実現できます。

主な機能

• プロンプトベースのカスタマイズ： 自然言語の指示を使用して、「ドライブトレインテーブルをマークダウンとして抽出する」や「法的免責事項のフッターを無視する」など、抽出に関する特定の問題を修正できます。
• カスタマイズ可能なビュー（レンズ）： 同じドキュメントに対して複数の「レンズ」を作成できます。 たとえば、営業レンズは価格設定や価値提案を抽出し、サービスレンズは同じ製品仕様PDFからトラブルシューティング手順やメンテナンススケジュールを抽出することができます。
• テストから本番環境への展開： 少数のサンプルドキュメント（5つのPDFなど）をワークスペースにアップロードし、生成されたチャンクとベクトルを確認した後、その設定を非構造化データモデルオブジェクト（UDMO）に公開して、膨大な数のレコードに拡張します。

インテリジェントコンテキストのワークフロー

1. アップロード： インテリジェントコンテキスト・ワークスペースで、サンプルファイル（PDF、音声など）をアップロードします。
2. 設定： AIスマートデフォルトを使用して初期設定を生成するか、解析戦略を手動で選択します。
3. テストと反復： 検索インデックスが正しい情報を取得しているかを確認するために、AIエージェントチャットウィンドウで質問します。 チャンクをクリックしてソーステキストを確認します。
4. 公開： すべて確認できたら、設定を検索インデックスに公開し、ライブデータストリームにリンクします。

インデックス戦略を設定する際は、インテリジェントコンテキスト内または標準の高度な検索インデックス設定のいずれかで、解析方法を選択する必要があります。 この選択によって、特にテーブルやレイアウトのような複雑な要素に対して、ドキュメント構造をシステムが読み取る方法を決定します。

LLMベースの解析

LLMベースの解析は、マルチモーダル大規模言語モデル（例：GPT-4o）を使用して、ドキュメントを視覚的に「読み取り」ます。 ここでは意味的な理解もとづいてコンテンツの解釈が行われます。

• 最適なドキュメント： 意味を理解することが構造を抽出する上で重要な、「扱いにくく」ノイズが多い、非常に不規則なドキュメントに最適です。
• 強み： 未知のフォーマットへの高い適応力を持ち、複雑で非標準的なテーブルの解釈にも優れています。
• トレードオフ： ローカルモデルと比較して処理速度が遅く、通常APIのコストや遅延が大きくなります。

Docling解析の違い

Docling（IBM製）は、ドキュメントのレイアウト分析向けに最適化されたコンピュータビジョンとOCRモデルを使用しています。 これは、ドキュメントの構造的完全性の復元に重点を置いています。

• 最適なドキュメント： デジタルで作成されたPDF、レポート、再現可能な安定した構造を持つマニュアルに最適です。
• 強み： 論理的な読み取りの順序の維持や、表構造をクリーンなマークダウンまたはJSONに再構築することに優れています。 一般的に、LLM解析よりも高速かつ効率的です。
• トレードオフ： 最先端のマルチモーダルLLMと比べて、著しく崩れたコンテンツや手書きのコンテンツへの対応が難しい場合があります。

これらの自動キュレーション機能は、実装パスに応じてプラットフォームの複数の領域で利用できます。

1. インテリジェントコンテキスト・ワークスペース： Data Cloud > プロセスコンテンツ > インテリジェントコンテキストからアクセスできます。 設定をUDMOに公開する前に構築およびテストできる推奨プレイグラウンドです。
2. 高度な検索インデックス設定： 標準フローで検索インデックスを手動で作成する場合、「解析オプションの設定」メニューでDoclingまたはLLM解析を選択できます。
3. Agentforceデータライブラリ（ADL）： 現在ADLは、手動による設定なしで、10MB未満のすべてのアップロードされたドキュメントに対して自動的にインテリジェントコンテキスト論理を呼び出し、品質基準を確保しています。

セクション5.5に詳細が記載されている多言語埋め込みモデルによって、検索インデックスは多くの言語のコンテンツに対応しています。 数十種類の異なる言語に対応し、言語間で意味的な類似性を保持します。 これは、ある言語のクエリに対して、別の言語で書かれたコンテンツから意味的に関連する結果を取得できるということを意味します。 埋め込みモデルの学習データセットにその言語が含まれているかどうかによって、結果は異なる場合があります。 詳細については、セクション5.5をご確認ください。

言語は事前フィルターとしても使用できます（セクション5.1を参照）。 コンテンツを複数の言語で使用すべきでない場合や、クエリと同じ言語のコンテンツを使用して応答を生成する必要がある場合に役立ちます。

Agentforceでの言語サポートは、広範なトピックであることにご注意ください。 以下は、機能ごとの言語サポートの内訳です。

• 非構造化データとRAG（埋め込みおよびインデックス化）： チャンク化およびベクトル化には数十の言語が対応しており、意味的類似度と語彙の類似度による検索の両方を可能にします。
  • 詳細をセクション5.5で確認する。
• プロンプトテンプレート入力（グラウンディング言語）： プロンプトテンプレートを介してRAG応答を生成するLLMが、グラウンディングの対応言語を決定します。 プロンプトビルダーで利用可能なデフォルトのモデルは、多言語埋め込みモデルと同じ言語に対応しています。
• プロンプトテンプレートの出力： プロンプトランタイムが、応答生成でサポートされる出力言語を決定します。
  • プロンプトテンプレートの応答の対応言語を確認する。
• Trust Layer: Language support varies for trust components, such as toxicity detection and data masking.
  • See Trust Layer Region and Language Support .
• Agentforce: The Agentforce platform has its own set of supported languages, including for its conversational experience and reasoning engine.
  • Agentforce （デフォルト）検討事項 を確認する。

Intelligent Document Processing（IDP）とデータ前処理は、Agentforceで効果的にRAGが機能するための基礎となります。 IDPは、PDFや画像などの非構造化ドキュメントから構造化データを自動的に抽出し、このデータをデータレイクオブジェクト（DLO）でアクセスできるようにします。 RAGシステムは、適切に準備された関連性の高いデータによって最大限に機能するため、これは重要なプロセスとなります。 データ前処理は、広い意味で、Agentforceエージェントによって使用される前にコンテンツを調整し、クリーンアップするために必要なすべての作業を含みます。これにより、最適なパフォーマンスを確保できます。

IDPの主なユースケースには、自動請求書処理、カスタマーサービス文書の処理、契約書分析、自動オンボーディングがあります。 抽出された値をData 360に入力し、Agentforceがそれらを活用して実践的なインサイトを提供します。

RAGのシナリオでは、IDPは大量のドキュメント処理において特に有用です。 これにより、大量の非構造化ファイルからのデータのストリーミングおよび抽出が可能になります。 これらのインサイトはAgentforceに保存されます。 このプロセスにより、RAG、セグメンテーション、分析などのダウンストリームアプリケーションを有効化できます。

効果的な前処理には、特定の見出しをインデックス化から除外したり、Agentforceへの引き渡し前にコンテンツをクリーンアップしたりすることも含まれます。これにより、高品質な情報のみが使用されることを保証できます。

Agentforceデータライブラリ（ADL）を設定することで、RAGを活用したAIエージェントを最短でセットアップすることができます。 ユーザーは、ADLにファイルをアップロードするか、設定またはAgentforce Builderインターフェースを通じてナレッジ記事を選択できます。 ただし、ADLに他の形式のコンテンツを追加することはできません。 たとえば、ナレッジ記事以外のSalesforceオブジェクトからコンテンツを取得する必要がある場合は、RAGパイプラインを手動で設定する必要があります。 ADLのオープンWeb検索は2025年5月時点で利用可能ですが、この機能はデータの取り込みや検索インデックスの構築を行わないため、本ガイドでは取り扱っていません。

ファイルは手動でADLにアップロードされ、Salesforceが管理するファイルストレージに保存されます。 ファイルのコンテンツはRAGに使用されます。 そのストレージからファイルをダウンロードすることはできません。また、ユーザーがそのファイルに戻るためのクリック可能なリンクもありません。 ユーザーによって削除されるまで、ファイルは保存されたままになります。

ADLを設定した後、RAGパイプラインの構成要素はすべて、以下に記載されているデフォルト設定を使用して自動的に作成されます。

• Data Cloudオブジェクト
  • ファイル用の非構造化データモデルオブジェクトの名前はFileUDMO__dlm です。このオブジェクトには実際のファイルは含まれておらず、メタデータ（ファイルタイプやファイルの場所など）のみが含まれています。
• 検索インデックス 組織内には、すべてのADL用にFileUDMO_SIという名前の検索インデックスが1つ存在します。 異なるADLのファイルは同じ検索インデックス内に整理されます。 対応するインデックスDMOオブジェクト（ベクトルを含む）であるFileUDMO_SI_index__dlmは、GroundingSourceId__cというフィールドを介してADLへの参照が含まれています。 このグラウンディングソースIDは、ベクトルが属するADLを表しています。 AiGroundingFileRefCustom__dlmという名前の特別なDMOには、アップロードされたファイルとそのADLとのマッピングが含まれています。 FileUDMO__dlmの検索インデックスを手動で作成し、異なる設定を使用することが可能です。 以下の設定は、ADLのデフォルト検索インデックスに使用されます。
  • • ハイブリッド検索
    • チャンク化の強化なし（#ロードマップ チャンク化の強化へのオプトインは、今後ADLで利用できるようになります。）
    • チャンクごとに512トークン
    • E5 Large Multilingual埋め込みモデル
• リトリーバー デフォルトFileUDMO_SI： あらゆる検索インデックスと同様に、すべてのインデックス化されたコンテンツから取得する単一のデフォルトリトリーバーが存在します。 これは、以下のデフォルト設定で作成されます。
  • • 10件の結果を表示
    • 各結果について、次のフィールドを返却： 主要な修飾子レコードID、データソース、チャンク、レコードID、データソースオブジェクト、チャンクシーケンス番号、内部組織、およびソースレコードID。 （これらのフィールドの詳細内容については、help.salesforce.com ページをご覧ください。）
    • 高度な取得モード（セクション6.3参照）はオフになっています。
  • 各ADLごとに、個別のリトリーバーが存在します。 このリトリーバーは、グラウンディングソースIDフィールドを使用して事前にフィルタリングされ、対応するADLからのみコンテンツを取得します。 次のフィールドを返します： チャンク、ソースレコードID、データソース、データソースオブジェクト。 その他のすべての設定は、デフォルトリトリーバーの設定と一致します。
  • 手動で作成されたリトリーバー： FileUDMO_SI検索インデックス用にリトリーバーを手動で作成することが可能です。 これらは、カスタムプロンプトテンプレートのグラウンディングに使用できます。

• DLO/DMO
  • 検索インデックスは、KnowledgeArticleVersion__dlm という名前のDMOにもとづいています。 このDMOがまだ存在しない場合は、そのデータストリームおよびマッピングとともに自動的に作成されます。
• 検索インデックス
  • ナレッジ記事用の検索インデックスの名前には、KA_がプレフィックスとして付き、その後にユーザーが指定した名前が続きます。 KA_Agentforce_Default_Libraryや KA_Published_Articlesがこの一例です。 1つの検索インデックスには、同じ識別フィールドを使用して作成された場合に限り、異なるADLのベクトルを含めることができます。 識別フィールドはユーザーによって選択され、その後すべてのチャンクにプリペンドされます。つまり、実際にチャンクテキストに追加されます。 フィールドのプリペンドに関する詳細は、セクション5.3をご確認ください。 コンテンツフィールドは、（識別フィールドがプリペンドされた後で）実際にチャンク化およびベクトル化されるフィールドです。 次の例では、ADL 1とADL 2は同じ識別フィールドを持っているため、両方とも同じ検索インデックスに追加されます。 ADL 3には、異なる検索インデックスが作成されます。
  • ADL 1
    • 識別フィールド： タイトル、要約
    • コンテンツフィールド： 詳細、回答
  • ADL 2
    • 識別フィールド： タイトル、要約
    • コンテンツフィールド： 詳細、コンテンツ、質問
  • ADL 3
    • 識別フィールド： タイトル、カテゴリ
    • コンテンツフィールド： 詳細、回答
• リトリーバー
  • ADLナレッジ設定は、リトリーバー用のクエリテンプレートに変換されます。 ナレッジを備えたADLのリトリーバーには事前フィルターがありません。取得の設定はクエリテンプレートで管理されます。 これにより、ADLで定義されたフィルターに従って選択されたフィールドが確実に返され、コンテンツが正しいナレッジ記事フィールドから取得されるようになります。 リトリーバーのクエリテンプレートはエージェントスタジオで確認できます。 次の例は、「FAQ_Internal_Comments_c__c」 および 「AssignmentNote__c」フィールドから発生したチャンクがどのように取得されるかを示しています。

リトリーバーには、Data 360オブジェクトへの2つのパス（ファイルとナレッジ記事）が存在します。 RAGソリューションスタックの残りのプロセスでは、これらのパスがプロンプトテンプレートとエージェントアクションで収束します。

• アンサンブルリトリーバー（#ロードマップ 現時点では、ADLは単一ソースのみ対応） ADLにナレッジ記事とファイルの両方がある場合、ADLにはそれぞれのパスに対応する2つのリトリーバーが存在します。 コンテキストでプロンプトを拡張する場合、これらを組み合わせる必要があります。 1つ目の選択肢は、2つのリトリーバーでプロンプトをグラウンディングすることですが、出力には常にナレッジ記事とファイルの結果の両方が追加されるため、最適な選択肢とは言えません。 ただし、一部のクエリはナレッジ記事のコンテキスト、あるいはファイルのコンテキストだけで最適に回答できるため、もう一方は不要になる場合もあります。 不要なデータでプロンプトを紛らわせると、応答の品質が低下し、不必要なEinsteinリクエストが消費され、遅延が増加します。 無駄な入力を過剰にプロンプトに追加してしまうと、LLMのコンテキストウィンドウを超えるリスクがあり、リトリーバーが返す結果セットのサイズを減らす必要が生じます。 これらの問題に対処するため、ADLが作成されると、デフォルトでアンサンブルリトリーバーが作成されます。 アンサンブルリトリーバーは、2つのリトリーバーを単一のリトリーバーにまとめ、2つの結果セットを1つの結果セットにまとめてから、クエリとの類似性にもとづいて、これらの結果を動的に再ランク付けします。 これには、以下のようなメリットがあります。
  • • プロンプトテンプレートのグラウンディングに、1つのリトリーバーのみが使用される。
    • もっとも関連性の高いクエリ結果は、データソースに関係なく、このランクの上位に示される。
    • 無関係な結果がプロンプトに追加されることがない。
    • 消費するEinsteinリクエストが少ないため、遅延とコストが削減される。
• プロンプトテンプレート
  • ADLの作成時に、ナレッジで質問に回答するという名前のプロンプトテンプレートが自動的にインスタンス化されます。 このプロンプトテンプレートには、あらかじめ作成されたRAGの指示が含まれており、Agentforce推論エンジンから取得した自由テキストの質問を入力として受け取ります。 {!$EinsteinSearch:sfdc_ai__DynamicRetriever.results}という動的リトリーバーが、実行時にコンテキストでプロンプトを拡張します。 Agentforce推論エンジンは、そのAIエージェントに対して選択されたADLにもとづいて、実行時に正しいリトリーバーを選択します。 異なるAIエージェントはこのプロンプトテンプレートを使用でき、各AIエージェントは独自の個別ADLを備えています（1つのAIエージェントにつき1つのADLのみ）。 動的リトリーバーは、RAGソリューションに実行時の柔軟性と多様性を追加します。 Salesforceでは、手動で作成したリトリーバーで上書きするのではなく、このプロンプトテンプレートで提供されているデフォルトのリトリーバーを使用することを推奨します。
• エージェントアクション
  • ADLの作成時に、ナレッジで質問に回答するという名前のプロンプトテンプレートのエージェントアクションが自動的にインスタンス化されます。 これは、同じ名前のプロンプトテンプレートに関連付けられています。

AIエージェントがSalesforce管理ファイルストア内のファイルやSalesforceナレッジ記事のコンテンツにグラウンディングして質問に回答する必要がある場合、ADLが推奨されます。 その他のデータソースについては、手動での設定が必要です。

• 効率的なクイックスタートアプローチ。 すべての必要なコンポーネントをデフォルト設定で自動的にインスタンス化します。
• 集約ストレージ。 ファイルのための個別のストレージはありません。
• #ロードマップ 動的な再ランク付け。 アンサンブルリトリーバーは、さまざまなデータソース（ナレッジ記事やファイル）から得た結果を動的に再ランク付けして、RAGの品質を向上させ、コストと遅延を削減します。

• ファイルおよびナレッジ記事のみをサポートします。 その他のソースコンテンツには手動設定を使用してください。
• カスタマイズのオプションが限定的です。 RAGソリューションコンポーネント全体でデフォルト設定を維持することを推奨します。 たとえば、カスタムリトリーバーを作成したり、標準のプロンプトテンプレート内の動的アンサンブルレトリーバーを手動で作成したリトリーバーで上書きしたりして、チェーンを分断することは推奨しません。

次のシナリオにおいては、RAGの構成要素を手動で設定する必要があります。

• すでに外部のBLOBストアや他のドキュメント共有に保存されているファイルや、ナレッジ記事以外のオブジェクトの長文テキストフィールドなど、さまざまなデータソースが必要となります。
• 検索インデックス、リトリーバー、プロンプトテンプレート、エージェントアクションの設定可能性に対して、以下のような追加の制御が必要となります。
  • コンテンツを取り込むデータストリームを制御することで、検索インデックスを構築する前に、どのナレッジ記事を含めるかをより細かく制御
  • 異なるチャンク化戦略
  • 異なる検索タイプ（ハイブリッド検索ではなくベクトル検索）
  • 異なる埋め込みモデル
  • 異なるリトリーバーの事前フィルター

1つの検索インデックスは、1つのデータソースにのみマッピングできます。 検索インデックスは単一のDMO/UDMOに対してのみ構築できるため、複数のデータソースがある場合、異なるデータソースは単一のDMO/UDMOにマッピングする必要があります。 「ファイル」は、ファイルの数やファイル拡張子の種類に関係なく、1つのデータソースとしてカウントされることにご注意ください。

以下は、RAGグラウンディング用のデータソースのコレクションの例です。

• ファイル
• ナレッジ記事
• ケース（標準Salesforceオブジェクト）
• 欠陥（カスタムSalesforceオブジェクト、不良品に関する顧客対応の追加情報を保持）

この例では、4つの個別の検索インデックスが必要であり、それぞれに少なくとも1つのリトリーバーが必要です。

特定のソリューション内でRAG関連コンポーネントを整理および分配する最適な方法は何でしょうか？4つのリトリーバーすべてを含む1つのプロンプトテンプレート（および対応するエージェントアクション）を作成すべきでしょうか？リトリーバーごとに個別のプロンプトテンプレートを作成すべきでしょうか？あるいは、2つのプロンプトテンプレートを構築し、それぞれに2つのリトリーバーを備えるべきでしょうか？それとも、リトリーバーを3つ備えたプロンプトテンプレートと、リトリーバーを1つ備えたプロンプトテンプレートの2つを作成すべきでしょうか？このような設計上の選択を行う理由とトレードオフについて説明していきます。

アプローチ 1： アンサンブルリトリーバーを使用して、すべてのリトリーバーで1つのプロンプトテンプレートと対応するエージェントアクションを作成

このアプローチでは、以下のコンポーネントを使用します。

• 1つのプロンプトテンプレートと1つのエージェントアクション
• それぞれ異なる検索インデックスと独自の設定（結果の件数や返却フィールドなど）がある複数のリトリーバー

以前は、Agentforce推論エンジンのエージェントアクションが呼び出されると、プロンプト解決時にすべてのリトリーバーが必ず実行され、それぞれの結果ですべてのプロンプトが拡張されていました。 これによってプロンプトの肥大化が生じ、LLMのコンテキストウィンドウを超えて失敗の原因になるリスクがありました。

現在、アンサンブルリトリーバーの利用が可能になったことで、このアプローチは複数のデータソースを扱うために大幅に最適化されています。 アンサンブルリトリーバーは、さまざまなデータソースからの結果を統合し、再ランク付けして、もっとも関連性の高い情報が上位に表示されるようにします。 これは、複数の個別リトリーバーを呼び出す代わりに、1つのアンサンブルリトリーバーを使用してプロンプトをグラウンディングできることを意味します。

このアプローチは、以下の場合に最適です。

• あらゆるデータソースが、すべてまたはほとんどの質問に関連している可能性が高いと考えられる場合。
• （Agentforceの指示および分類の説明を用いても、）どの種類の質問に対して、どのリトリーバーを使用すべきかを十分に明確に定義することができない場合。

このアプローチにおけるアンサンブルリトリーバーの使用には、以下のようなメリットがあります。

• プロンプトテンプレートのグラウンディングに、1つのリトリーバーのみが使用される。
• もっとも関連性の高いクエリ結果は、元のデータソースに関係なく上位に表示される。
• 無関係な結果はプロンプトに追加されないため、LLMのコンテキストウィンドウを超えてしまうのを防止できる。
• 消費するEinsteinリクエストが減少し、遅延とコストが削減される。

以前の「アプローチ1」を使用していた既存のソリューションでは、プロンプトテンプレート内で複数のリトリーバーを呼び出していた部分を、ただアンサンブルリトリーバーの呼び出しに置き換えるだけで済みます。 残りのエージェントソリューション設計は、これ以上変更することなく維持できます。 現在、アンサンブルリトリーバーはADLおよびその他の標準機能で利用可能であり、今後、任意のリトリーバーを手動でバンドルできるツールの公開も計画されています。

このアプローチでは、以下のコンポーネントを使用します。

• データソースごとに、1つのプロンプトテンプレートと1つのエージェントアクション
• データソースごとに異なる検索インデックスおよび設定（結果の件数や返却フィールド）を関連付けたプロンプトテンプレートごとに、1つのリトリーバー

このアプローチでは、Agentforce推論エンジンが複数の対応するエージェントアクションを呼び出す必要があります。

このアプローチは、以下の場合に最適です。

• 十分明確に（Agentforceの指示および分類の説明を含めて）、どのデータソース（したがって、リトリーバー、プロンプトテンプレート、アクション）がどの種類の質問に使用されるべきかを指定することが可能な場合。
• このような単一アクションで、ユーザーの質問に対する完全な応答を生成することが可能な場合。 対応する単一データソースから取得された結果は、LLMがこの回答を作成するのに十分であると見込んでいる場合。

たとえば、「欠陥」という名前のデータソースに、商品の欠陥に関するナレッジが含まれているとします。 このリソースに対応する指示または分類の説明は、次のようなものになる可能性があります。 「お客様が不良品について質問した場合は、必ず『既知の欠陥で回答』アクションを使用してください。」 これは、Agentforce推論エンジンが実行時にこのアクションを呼び出すタイミングを判断するためのガイドとなります。 他のすべてのアクションについても、同様に明確かつ正確な説明と手順を必ず提供してください。

注意： 前述の最初のアプローチの代替として、個別のアクションを個別のプロンプトテンプレートと一緒に使用しないでください。 Agentforce推論エンジンに、次のような複数のアクションを連続して実行するような指示は使用しないでください。 「常に4つのアクションを使用してユーザーの質問に回答してください。 まず、ファイル用にアクション1を呼び出します。 次に、ナレッジ記事用にアクション2を呼び出します」など。 このアプローチを避けるべき理由は以下のとおりです。

1. 明確にすべてのアクションを呼び出すよう指示された場合でも、Agentforce推論エンジンは、すべてのアクションが呼び出される前にユーザーのインテントが満たされた（および回答が提供された）と判断することがあります。 その結果、実行時にRAGソリューションは、グラウンディングに有用な情報を本来提供するはずのアクションを、想定外かつ予測不能な形でスキップする可能性があります。
2. コンテンツの解釈方法と応答の生成方法を具体的に定義するLLMの指示は、プロンプトテンプレートのレベルで提供するのが最適です。 つまり、AIエージェントレベルでの指示や分類の説明は、主にAgentforce推論エンジンに正しいアクションを実行させ、その出力をどのように活用するかを示すために使用すべきです。 これらのアクションがどのように実行されるべきかについて、過度に説明すべきではありません。 RAGでは、エージェント型 レベル（こちらはより非決定的）よりも、プロンプトレベルでの検索および応答生成の挙動をより詳細に制御できます。

ユースケースに該当する場合、同じソリューション内で両方のアプローチを使用することは可能です。 たとえば、あるソリューションでは「欠陥」専用の個別アクション（アプローチ2）を用意し、その他の3つのグラウンディングソース（「ファイル」、「ナレッジ記事」、「ケース」）を1つのプロンプトテンプレート（アプローチ1）で組み合わせることができます。

RAGを活用したAIエージェント内のトピックおよびアクションには、説明、手順、範囲の明確化が必要です。 すべての一般的なベストプラクティスは、トピックはこちらのヘルプページ 、アクションはこちらのヘルプページ に記載されているとおりに適用されます。 RAGのトピックおよびアクションの指示と範囲の説明は、検索インデックスが回答できる範囲内の質問に対してのみ選択され、呼び出されるように作成します。

RAGアクションが呼び出されると、プロンプトテンプレートのリトリーバーは必ず検索インデックスから結果を取得し、LLMが応答を生成します。 検索インデックスに関連するコンテンツが見つからない場合、プロンプトテンプレート内の適切な指示によって、LLMがハルシネーションを避けるよう促すことができます（セクション7を参照）。 ただし、最初から範囲外の質問に対してRAGアクションが呼び出されれないようにすることが望ましいです。 これにより、ハルシネーションのリスクがさらに低減され、AIエージェントのコストと遅延も削減されます。

RAGソリューションでは、検索インデックスビルダーを使用して検索インデックスを設定すると、ハイブリッド検索に対応できます。 ハイブリッド検索は、ベクトル検索とキーワード検索の強みを1つの検索呼び出しに統合します。 単一のデータソースから2つの異なる検索操作を行い、その結果を統合して再ランク付けするものと考えてください。 これはアンサンブルリトリーバー（セクション3）に類似していますが、ハイブリッド検索は単一のデータソースから結果を導き出すのに対し、アンサンブルリトリーバーは複数のデータソースから結果を導き出す点において異なります。

ハイブリッド検索は、ベクトル検索とキーワード検索の結果を組み合わせてランク付けし、もっともランクが高いチャンクが、意味的および語彙的に類似しているものとなります。

ベクトル検索は、それ自体で意味的な類似性に優れていますが、キーワードが重要な場合にそれを認識できないことがあります。 たとえば、ベクトル検索は「自分のアカウントにログインする方法は？」と「どのようにサインオンすればいいですか？」が類似したクエリであることを理解します。 しかし、「レーザープリンターTX 400」と「レーザープリンターTX 440」を探している場合、類似していることを理解できない場合があります。 キーワード検索とは異なり、ベクトル検索は数値をうまく一致させることができず、また特定のドメイン用語（レーザープリンターなど）を適切に一致することも困難です。

しかし、ベクトル検索とキーワード検索を組み合わせることで、互いに補完し合い、「レーザープリンターTX 400で紙詰まりが発生した場合はどうすればよいですか？」のような質問に対して最適な回答を返すことができます。

出典： help.salesforce.comのハイブリッド検索のページ

ハイブリッド検索を使用することで、意味的な類似性とキーワードの類似性の両方を利用してコンテキストを取得できます。 たとえば、商品名、ブランド、特定の用語、専門用語などのキーワードが検索品質の鍵となる場合、ハイブリッド検索が推奨されます。 ユーザーの質問および取得可能なすべてのコンテンツが、特定の用語やセマンティック、キーワードを含まない自然言語である場合、ハイブリッド検索の付加価値は小さく、ベクトル検索のみで対応することが可能です。

ただし、カテゴリのキーワード検索エンジンとしてハイブリッド検索を使用しないでください。

RAGソリューションの場合、ベクトル検索は単独で使用できますが、キーワード検索はできません。 キーワード検索はベクトル検索結果を強化できますが、辞書式順序検索の単独利用には使用できません。 検索インデックスの場合、カテゴリのみを含むフィールド（Salesforceのピックリストなど）をインデックスフィールドとして選択することは推奨されません。

カテゴリは、非常に短いチャンク（1つの単語または数単語）になってしまいます。 これらのマイクロチャンクもユーザーのクエリに対して意味的な類似性で一致されますが、単語単位のチャンクによるセマンティック検索は、これらのチャンクが意味的なコンテキストを欠いているため、適切には機能しません。 その結果、ハイブリッド検索のベクトル検索部分が不安定になり、最終的なランキングが不正確になってしまいます。 代わりに、カテゴリはセクション5.1で説明しているように、プリペンドするフィールドとして使用する方が適しています。

ハイブリッド検索は、実行時の遅延やData 360クレジット消費の増加というトレードオフと引き換えに、検索結果の精度を向上させます。

ハイブリッド検索機能は、ベクトルとキーワードインデックスの両方でクエリを処理し、結果を再ランク付けするため、Data 360サービスクレジットを約2倍消費します。

再ランク付け中に、ハイブリッド検索はベクトルスコアとキーワードスコアを組み合わせてハイブリッドスコアを生成します。そのハイブリッドスコアにもとづいて最終的なランキングが決定されます。

検索インデックスビルダーには、人気度と最新度という2つの追加のランク付け要素が存在し、最終的なランキングに影響を与える可能性があります。 検索インデックスビルダーでは、ユーザーはこれらのドキュメント特性を定義する（関連する）DMO上の2つのフィールドを選択できます。 最終ランキングでは、これらの特性を取り入れて、人気が高く、最新のコンテンツが上位にランク付けされます。

詳細および例については、help.salesforce.com の記事をご確認ください。

検索インデックスを設定する際、Data 360はデータをベクトル化する前にチャンク化を実行します。 チャンク化は情報をより小さな要素に細分化します。 すべてのチャンク（およびベクトル）は、有意義なファクトイドまたはファクトイドの集合を表します。 1つのベクトルがドキュメント内のすべてのコンテンツの意味的な表現にはなり得ないため、1つのベクトルで冗長なドキュメント全体を表現することは現実的ではありません。

RAGソリューションにおいてフィールドが担う、以下の4つのロールを検討しましょう。

• インデックスフィールド（DMOインデックスのみ）
  インデックスフィールドのテキストコンテンツはチャンク化およびベクトル化され、セマンティック検索の際に使用されます。 注： UDMOインデックスでは、インデックスフィールドの選択はありません。 選択したファイルタイプのすべての未加工のコンテンツがインデックス化されます。
• フィールドのプリペンド（DMOインデックスのみ）
  これらのフィールドの値は、すべてのチャンクにプリペンドされます（「タイトル」や「商品名」など）。 プリペンドによって、これらのフィールド値がチャンクの一部となり、プロンプト拡張やData 360クエリエディタで表示されるようになります。 プリペンドは、主要な識別フィールドがすべてのチャンクに含まれるようにすることで、チャンクを強化し、検索精度を向上させる強力な仕組みです。
• フィルターフィールド（UDMO/DMOインデックス）
  フィルターフィールドは、ベクトルを含むインデックスDMOのスキーマの一部としてインデックスに追加されますが、ベクトル化はされません。 これらは検索中の意味的な類似性の評価には使用されません。 代わりに、セマンティック検索を絞り込むために使用されます。 フィルターはリトリーバーで定義され、動的に設定することも可能です（セクション6.2を参照）。
• 返却フィールド（UDMO/DMOインデックス）
  返却フィールドは、インデックスフィールドまたは非インデックスフィールドのいずれかとなります。 これらのフィールドは、検索インデックスを作成する際に選択する必要はありません。 返却フィールドは、リトリーバーを構築する際に指定されます。 ベクトルを保存するDMO、または関連するDMOから取得できます。

以下の例は、これら4つのフィールドがどのような役割を担っているのかを示しています。 このユースケースでは、ケースオブジェクトがユーザーの質問に回答するために使用されます。 プロンプトは、説明がユーザーの質問と一致する、完了したケースの解決結果の内容で拡張されます。 これを達成するには以下を必要とします。

• ケースの説明は、プリペンドされたタイトルおよび要約フィールドとともにインデックス化されていること。
• ケースステータスは、リトリーバー上の固定された事前フィルターとして機能すること。
• ケース製品ファミリーは、リトリーバー上で動的な事前フィルターとして機能すること。
• ケースの解決結果およびまとめは、リトリーバーの出力フィールドとして利用可能なこと。 この例では、解決結果はプロンプトを拡張するフィールドです。

ユースケースの図： 過去のケースの解決結果を使用した顧客への返信。

検索インデックスを構築する際は、ステップ2のチャンク化でインデックスフィールドを選択します。 「フィールドを管理」ボタンをクリックします。 検索インデックスの作成時に、インデックスフィールドはチャンク化およびベクトル化されてから、検索プロセス中にクエリとの意味的な類似性を評価するために使用されます。

インデックスフィールドとして選択できるのはテキストフィールドのみです。 カテゴリやカテゴリデータではなく、長い自由テキストコンテンツのあるテキストフィールドのみを選択してください。 カテゴリフィールドは選択しないでください。 複数のフィールドをインデックス化のために選択できます。 たとえば、「説明」、「要約」、「コンテンツ」、「解決結果」が選択されている場合、すべての対応するベクトルは同じ検索インデックスにまとめて保存されます。 ベクトルのDMO上のDataSource__c というフィールドにもとづいて、ベクトルを分離することが可能です。 DataSource__c には元のフィールド名が含まれています。 このフィールドはインデックスDMOにあるため、リトリーバーの事前フィルターで使用することが可能です。 たとえば、リトリーバーは特定のフィールド（「解決結果」ではなく「説明」など）に対してのみクエリの意味的な類似性を評価できます。

注意： カテゴリ列をインデックスフィールドとして選択しないでください。 カテゴリデータは、Salesforceのピックリストにマッピングされる1語または2語の記述子です。 優れた結果を得るためには、セマンティック検索には長いテキスト範囲と多くのコンテキストが必要です。 ハイブリッド検索は、キーワード検索によってセマンティック検索を補完することを思い出してください。 検索インデックスはキーワード検索エンジンではありません。 カテゴリフィールドのみをインデックス化するのではなく、それらを、長い自由テキストコンテンツを含むテキスト列にプリペンドする必要があります。

注意： 類似したフィールドを選択しすぎないようにしてください。 選択項目は少ない方が効果的です。 すべてのテキストフィールドを選択しないように注意し、「要約」、「タイトル」、「説明」などの重複する可能性のあるフィールドを選択しないようにします。 こうすることで、DataSource__cに事前フィルタリングを使用せずに検索インデックスを利用した場合、再呼び出し率が低下する可能性があります。 これらのフィールドは、すべて同じ、または非常に類似した情報を含んでいる可能性が高いため、特定のクエリに対して、同じドキュメントから少なくとも3つのチャンクがランクの上位に表示されることがあります（フィールドごとに1つずつ）。 これらは同じ情報をLLMにもたらします。たとえば、リトリーバーが9件の結果を取得するように設定されている場合でも、結果リストには3つのドキュメントのみが表示されます。 これによりばらつきが減少する一方、ドキュメントが見逃される場合があります。

2つ以上のフィールドが同じ内容を異なる形式で表している場合、前述の例の「説明」のように、もっとも圧縮されていない形式のフィールドを選択することが推奨されます。 このフィールド（セクション5.3を参照）には、前の例の「タイトル」のような、短くて簡潔なバージョンをプリペンドすることを検討してください。

検索エンジンビルダーでは、インデックス化するフィールドを選択する際（DMOケース）や、インデックスに含めるファイルタイプを選択する際（UDMOケース）に、ユーザーはチャンク化戦略を構成できます。詳細はhelp.salesforce.comのこのトピックをご参照ください。

フィールドのプリペンドを使用して、チャンクにコンテキストを追加し、識別しやすくします。 たとえば、トラブルシューティング手順のシーケンスを含むチャンクがあるとします。 そのチャンクの前に「デバイス123が動作xyzを示す場合の対処方法」というテキストを付け加えることで、そのコンテンツがユーザーの質問に関連していることを識別しやすくなります。

注： フィールドのプリペンドは、DMOベースのインデックスでは利用可能ですが、UDMOベースのインデックスでは利用できません。

RAG実装をデザインする際には、フィールドのプリペンドが環境内のメタデータからどのようなメリットを得られるかを慎重に検討してください。

検索インデックスビルダーのチャンク化戦略で、フィールドのプリペンドを設定します。 インデックス化するフィールドを選択した後、チャンク化設定のダイアログを開き、「フィールドをプリペンドする」のトグルをオンにします。

チャンク化を最適化するもう一つの方法として、検索インデックス設定でソリューションに合わせてチャンクサイズを調整することがあります。

検索インデックスの作成中、プラットフォームは、ヘルプで説明されている意味ベースの文章抽出マーカーを使用して、可能な限りコンテンツを分割し始めます。 その後、プラットフォームは指定されたチャンクサイズに達するまで、細かく分割されたチャンクを再びまとめます。 現在設定可能な最大のチャンクサイズは512トークンであり、これはラテン系言語で約400～500語に相当します。

最適なチャンクサイズはソリューションごとに異なります。 これは、特定のソリューションの目標にもっとも適した最適化戦略に一部依存します。

検索向けにチャンクサイズを最適化する際は、コンテンツの情報密度と組織構造を考慮します。 1つのチャンクが1つのベクトルになることを忘れないようにしてください。 このチャンク全体のコンテンツは、この1つのベクトルで表されます。 チャンクの意味を十分に理解するには、いくつの単語が必要でしょうか？400～500語でしょうか？少ない語数でもフィールドのプリペンドやチャンク強化によって補強された場合に、自己完結型で識別可能なファクトイド情報を十分に表現できるでしょうか？

拡張の観点からチャンク化を検討します。 LLMが十分に実践的な応答を生成するためには何が必要でしょうか？小さな個々のファクトイドだけで十分でしょうか、それとも、さらなるコンテキストが必要でしょうか？

• UDMOベースの検索インデックスの場合、コンテンツの拡張は通常、チャンクサイズに依存します。このケースでは、追加のコンテキストを含めるためにチャンクを大きくする必要があります。
• DMOベースのインデックスの場合、追加フィールドを拡張に利用できるため、オプションが増えます。 プロンプトを拡張する際、単なるチャンクだけでなく、元のドキュメント（ナレッジ記事など）全体を使用することも可能です。 これによりプロンプトの解像度が向上するため、選択した結果の件数とLLMのコンテキストウィンドウとの関係性を考慮しましょう。 また、このようなプロンプトは応答生成のコストを増加させます（プロンプトサイズと応答サイズの増加により、より多くのEinsteinリクエストが消費されます）。

インデックス化の強化（近日公開）は、検索のリコールと精度を向上させるために、インデックス化の際に追加の（または強化された）チャンクが生成されるプロセスを指します。

インデックス化の強化が有効になっている場合、元のチャンクに対して、「PLAIN」「QUESTION」「METADATA」の3種類のチャンクが生成されます。

インデックス化の強化 は、特にフィールドのプリペンドができないケース（UDMOパス）や、Q&Aエージェントアクションにおいて、検索の精度を大幅に向上させます。 チャンクの強化は、LLM生成コンテンツが適切なチャンクの特定を向上させるため、集中的なコンテンツキュレーションの代替手段を提供します。 トレードオフとして、チャンクの強化により、取得処理に含まれるチャンク数が増えるため、コストと遅延が増加します。

プラットフォームは3つの埋め込みモデルをサポートしています。

コンテンツが英語以外の言語である場合は、この埋め込みモデルを使用してください。 このモデルは、言語間での意味的な類似性をも保持します。 たとえば、フランス語でのクエリがドイツ語で書かれた関連記事を取得できます。 この埋め込みモデルは100の言語に対応しています。 次の表は、対応しているすべての言語と、モデルが各言語で学習したトークン数を示しています。 5億トークン未満で学習された言語については、結果の品質を十分に評価する必要があるため、慎重に扱うことを推奨します。

出典： Unsupervised Cross-Lingual Representation Learning at Scale（英語）

コンテンツが英語以外の言語である場合は、この埋め込みモデルを使用してください。 このモデルは、言語間での意味的な類似性をも保持します。 たとえば、フランス語でのクエリがドイツ語で書かれた関連記事を取得できます。 この埋め込みモデルは100の言語に対応しています。 次の表は、対応しているすべての言語と、モデルが各言語で学習したトークン数を示しています。 5億トークン未満で学習された言語については、結果の品質を十分に評価する必要があるため、慎重に扱うことを推奨します。

出典： Unsupervised Cross-Lingual Representation Learning at Scale（英語）

この埋め込みモデルは、チャンクの強化が有効になっている場合にデフォルトで使用されます。 E5モデルと組み合わせてチャンクの強化を実行することはできません。 チャンクの強化が有効になっていない場合、このモデルを使用できます。 Ada 002も多言語に対応していますが、本ガイド執筆時点では、OpenAIは対応言語の確定リストを公開していません。 一般的でない言語については、追加のテストおよびモニタリングが推奨されます。

多くの場合、RAGは特定のレコードのコンテキスト内で実行される必要があります。 例として、特定のケースのタスク内を検索することや、特定のアカウントの契約内を検索することが挙げられます。 これは、ドキュメントをSalesforceレコードに関連ファイルとしてアップロードすることで可能です。 このアカウントの例を用いて、このような（ノーコード）ソリューションを設定するには、以下の手順が必要です。

1. まだ設定していない場合は、ContentDocument、ContentDocumentLink、ContentDocumentVersionのデータストリームを設定します。 対応するDLOを必ずSSOT DMOにマッピングします。 ContentDocumentLinkに、元のDMO（このケースでは SSOTアカウント）への関連付けを必ず作成します。
2. アカウントDMOのために検索インデックスを作成し、説明または他の関連する長文テキストフィールドをインデックス化します。
3. 検索インデックス設定（詳細設定モード）のステップ2で、「添付ファイルを含める」を選択します。ここでチャンク設定が定義されます。 その後、アカウントオブジェクトからの関連ファイルがすべてインデックス化されます。 これらはアカウントフィールドのチャンクとともに1つのインデックスにまとめられます。 これらをフィルタリングするには、アカウントIDなどの検索インデックスに事前フィルターを追加します。
4. Account_ID = $placeholder（セクション6.2参照）などの動的な事前フィルターを使用して、カスタムリトリーバーを作成します。
5. アカウントを入力として使用し、プロンプトビルダーで$placeholderをプロンプト入力のアカウントIDにマッピングするフレックスRAGプロンプトテンプレートを作成します（セクション6.2およびセクション7を参照）。
6. その内容を中心に、アカウントとユーザーの質問をフレックスプロンプトテンプレートに引き渡すエージェントアクションを作成します。

リトリーバーは、検索インデックスと、それにコンテキストを追加するプロンプトの橋渡し役として機能します。 ADLを設定する際、リトリーバーは自動的に作成されます。 取得および拡張プロセスをより詳細に制御するために、エージェントスタジオでは、リトリーバーを手動で作成およびカスタマイズできます。これには、ADLを使用して作成された検索インデックス用のリトリーバーも含まれます。

リトリーバーは、取得したチャンクに追加のフィールドを返すことができます。 これらは、チャンクDMOまたは元のDMOから来る場合があります。 検索インデックスがUDMO（ファイルなどの非構造化データ）に対して作成されている場合、通常は関連するメタデータをほとんど利用できません。 これは、非構造化ファイルを関連ファイルとしてSalesforceのレコードにアップロードすることで解決できます。 ContentDocumentコネクターを使用することで、これらを添付ファイルとして検索インデックスに取り込むことができます。 検索インデックスには、これらの添付ファイルおよび選択されたインデックスフィールドから生成されたチャンクが含まれるようになります。 この検索インデックスに対して、ソースDMOから任意のフィールドを返すようにリトリーバーを設定できます。

カスタムリトリーバーの場合、すべての取得結果に特定の条件（特定の言語で書かれていることや、特定のカテゴリに属していることなど）を適用するために、事前検索フィルター（または単に事前フィルター）を設定できます。 事前フィルタリングにより、要求した件数の結果が返され、すべての結果がフィルターの条件を満たすことが保証されます。 フィルターは、検索インデックス作成時に検索インデックスビルダーで定義されたフィールドにもとづき、リトリーバーの設定エクスペリエンスで定義されます。 これらのフィールドは、インデックスDMO（ベクトルを含む）のスキーマの一部となります。

注： 現在、既存の検索インデックスに事前フィルタリング項目を追加することはできません。

事前フィルターによって、結果セットのサイズを制限し、クエリに関連しない余分なコンテンツを除外することで、関連性に結果の重点を置くことができます。 リトリーバーが10件の結果を返すように設定されている場合、検索インデックスで見つかった最大10件の結果を返します。 結果には、フィルター条件が「True」と評価されたコンテンツのみが含まれます。

対照的に、事後検索フィルタリングは最初に10件の結果を取得して、それからフィルターを適用します。 これにより、結果セットのサイズが縮小される可能性が高く、フィルター条件を満たす結果がない場合は、結果セットが0になることもあります。 現在、事後フィルターはリトリーバーに対応していません。 ただし、Apexを使用したプロコードソリューションで定式化することができます（セクション9を参照）。 事後検索フィルターを使用するメリットは、あらゆるアクセス可能な関連フィールドを使用できる点です。一方、事前フィルターはフィルタリングのために検索インデックスに追加されたフィールドを必要とします。

動的事前フィルターでは、フィルター条件の値が実行時に提供されます。 フィルター条件は、プロンプト解決時に設定される値のプレースホルダー構文を使用して、設計時にリトリーバーに指定されます。 たとえば、Account = $placeholderのようにフィルターを設定できます。 次に、プロンプトビルダーのプロンプトエンジニアによって、プロンプトテンプレートの入力から$placeholderが適切な値にマッピングされます。 たとえば、アカウントフィールドのフィールド補完テンプレートや、アカウントを入力フィールドとするフレックステンプレートでは、プロンプトエンジニアはそのプレースホルダーをアカウント名やID、または検索インデックスの識別用事前フィルターとして追加された任意のフィールドにマッピングできます。 この方法により、リトリーバーはその特定のアカウントでタグ付けされた結果のみを返却します。

（デモリンク 、現在はSalesforce内部のみ）

#ロードマップ

詳細検索モードは、クエリの書き換えと反復的な検索を組み合わせたリトリーバー機能です。 詳細検索モードを使用すると、特にユーザーのクエリが適切に構成されていない場合や、ユーザーが質問を把握していない場合、または、検索インデックスが何に応答できるかを把握していない場合に、検索の品質を最適化できます。 具体的なステップは以下のとおりです。

1. 元のユーザークエリを使用して最初の検索を実行します。
2. ステップ1の結果を要約します。
3. 元のユーザークエリとステップ2の要約結果を入力として受け取るプロンプトを使用する、LLMベースのクエリ書き換えが行われます。
4. （ステップ3で）書き換えられたクエリを使用して、2回目の検索を実行します。

RAGは通常通り実行されます。 ステップ4の結果でプロンプトを拡張し、解決したプロンプトを選択したLLMに送信して、最終的な応答を生成します。

プロンプトテンプレートの指示は、LLM生成結果の成功に不可欠です。

基本的なプロンプトテンプレートの例

上記の例には、2つの差し込み項目があります。

• {!$Input:question} は、プロンプトテンプレートの自由テキスト入力から取得されます（すべてのプロンプトテンプレートタイプで利用可能）。
• {!$EinsteinSearch:ArticleRetriever_1Cx_Q8Qa1857028.results} は、取得したコンテキストを使用するようにLLMに指示するリトリーバーの挿入です。 LLMがコンテキストをどのように使用すべきかを指定していないため、指示は最小限かつ限定的です。

過度に単純化された指示は、さまざまな理由によりLLMのハルシネーションを引き起こすリスクがあります。

• LLMは、提供されたコンテキストよりも関連性が高いと判断した場合、内部のナレッジの一部を使用することを選択できます。 このような内部ナレッジは、古くなっている場合や、関連性が低い場合があります。
• 場合によっては、LLMは内部のナレッジをまったく使用することなく、回答を作り上げてしまうこともあります。 その理由として、「この情報を使用する」よりも「この質問に答える」という指示を重要視してしまうことが挙げられます。 LLMは提供されたコンテキストにもとづいてどのように回答すべきか確信が持てない場合でも、ユーザーのインテントに最適な回答を考え出そうと最善を尽くします。
• さらに、プロンプトには、期待される出力や、与えられたコンテキストに対してLLMが行うべき推論のレベルに関する指示が一切含まれていません。

これは、12歳の子供に地理の本を渡して、「試験のために勉強しましょう」と言うようなものです。 一部の生徒は試験準備を進められますが、生徒の多くはどのように勉強すればよいか、また、本をどのように活用すればよいかについてのさらなる指導を必要とします。

「ナレッジで質問に答える」という標準の、すぐに使えるプロンプトテンプレートは、一般的なプロンプト設計の原則に従って、より詳細な指示を提供します。 前述の基本プロンプトテンプレートで指定されている内容に加えて、このテンプレートは以下を提供します。

1. ユーザーの質問を理解することを奨励。
2. そのコンテンツ内で関連性のある情報を探すことを推奨し、提供されたコンテンツにもとづいてLLMの応答を作成するよう明確に指示。
3. 指定されたソースコンテンツに情報が存在しない場合の対応方法。
4. 応答を作成する方法に関する手順。

以下は、既製のプロンプトテンプレート内の指示です。これは標準アクションに属します。 動的リトリーバーを使用します。