はじめに
Salesforce Data 360（旧 Data Cloud）のSearch Index Referenceを見ると、テキスト向けのEmbeddingモデルとして次のモデルが掲載されています。
- E5-large-v2
- Multilingual-E5-large
- SFR-v2-small（Salesforce Embedding V2 Small）
この中で個人的に気になったのが、SFR-v2-smallです。
名前を見ると、
Smallなら、E5 Largeより軽量・高速な代わりに精度を少し落としたモデルなのかな？
と想像してしまいます。
ところがSalesforce公式の仕様を確認すると、少し違った姿が見えてきました。
SFR-v2-smallは、公式Model Reference上では次の特徴を持つEmbeddingモデルとして説明されています。
- 最大8,000トークンの入力に対応
- 434Mパラメータ
- 1024次元のEmbedding
- Salesforceが掲載しているRetrievalベンチマークではE5-large-v2を上回る
- 一方、公式上の対応言語はEnglish
なお、Data 360のSearch Index設定画面（Advanced SetupのVectorization）では、このモデルは Salesforce Embedding V2 Small という表示名で出てきます。公式ドキュメント内でも「SFR-v2-small」というModel Reference名と、「Salesforce Embedding V2 Small」という設定画面上の名前が併用されているので、探すときは両方の名前で見た方が早いです。
本記事では、SFR-v2-smallとは何なのか、E5 Large V2と何が違うのか、AgentforceのRAGで使う場合に何を考えればよいのかを整理してみます。
この記事の目的
この記事の目的は、SFR-v2-smallを実Orgで詳細検証することではなく、まず次の点を把握することです。
- Data 360のSearch Indexで、SFR-v2-smallという選択肢があること
- 名前の「Small」だけで、E5 Large V2より小さい・低精度と決めつけない方がよいこと
- 最大入力長、対応言語、ベンチマーク値など、モデル選択時に見るべき軸があること
- 日本語ナレッジで使う場合は、Multilingual-E5-largeとの比較が必要になりそうなこと
そのため、この記事では概要理解と選定時の観点整理に寄せています。実際の検索品質や速度は、対象データ・チャンク設計・Retriever設定・質問パターンで変わるため、個別環境での検証が必要です。
※Salesforce公式ドキュメントをもとにした個人の整理メモです。Salesforce Helpは更新される可能性があるため、公開・利用前には最新の公式ページを確認してください。
確認日：2026年9月13日（初回整理：2026年8月30日）
先に結論
先にまとめると、SFR-v2-smallは「E5 Large V2の単純なSmall版」と見るより、Data 360のSearch Indexで選べる、長い入力に対応したSalesforce側のEmbeddingモデルとして理解した方がよさそうです。
| 見るポイント | E5-large-v2 | SFR-v2-small | 読み取り方 |
|---|---|---|---|
| 最大入力長 | 512 tokens | 8,000 tokens | SFR-v2-smallの方が長い入力を扱える |
| Parameters | 335M | 434M | 名前に反して、パラメータ数はSFR-v2-smallの方が多い |
| Embedding dimension | 1024 | 1024 | ベクトル次元は同じ |
| Supported language | English（英語専用モデル） | English | 日本語中心ならMultilingual-E5-largeも比較対象 |
| ベースモデル | E5系（自身がベース） | gte-large-en-v1.5 | そもそも別系統のモデル |
| Salesforce掲載のRetrieval値 | 50.6 | 58.1 | 掲載ベンチマーク上はSFR-v2-smallが高い |
この記事で言いたいことはシンプルです。
Data 360 / AgentforceのRAGを考えるとき、生成AIモデルだけでなく「どのEmbeddingモデルで検索インデックスを作るか」も見ておくとよさそうです。
そもそもEmbeddingモデルとは？
Embedding（埋め込み）モデルは、文章を数値のベクトルに変換するモデルです。
例えば、次の2つの文章があります。
顧客が契約更新を希望している
お客様から更新手続きについて問い合わせがあった
文字列としてはかなり違います。
しかし、人間が読むと「契約・更新に関する話」という意味的な近さがあります。
Embeddingモデルでは、おおまかに次のような処理を行います。
文章
↓
Embedding Model
↓
数値ベクトル
↓
ベクトル間の距離を比較
↓
意味の近い文章を検索
単なるキーワード一致ではなく、文章の意味的な近さを利用して検索できるのがベクトル検索の特徴です。
Data 360でも、非構造化データをロードし、チャンク化、ベクトル化して検索インデックスへ格納します。Retrieverは、その検索インデックスから関連するデータを取得し、RAGのGrounding情報として利用できます。
SFR-v2-smallとは？
SFR-v2-smallは、Data 360の検索インデックスで使用できるテキストEmbeddingモデルです。
Salesforce公式のSFR-v2-small Model Referenceでは、次のような仕様が公開されています。ここでは、まず「どのようなモデルとして説明されているか」を把握するための表として見ています。
| 項目 | SFR-v2-small |
|---|---|
| Model type | Text Embedding |
| Parameters | 434M |
| Embedding dimension | 1024 |
| Search Index上の最大入力長 | 8,000 tokens |
| Context window | 8192 |
| Supported language | English |
| Fine-tuned from | gte-large-en-v1.5 |
| License | Apache License 2.0 |
この表で個人的にありがたかったのが、Fine-tuned fromが明記されていることです。
派生元の Alibaba-NLP/gte-large-en-v1.5 は公開モデルなので、Hugging Faceのモデルカードで仕様を突き合わせられます。
| 項目 | gte-large-en-v1.5（派生元） | SFR-v2-small（Data 360） |
|---|---|---|
| Parameters | 434M | 434M |
| Embedding dimension | 1024 | 1024 |
| Context length | 8192 | 8192 |
| 対応言語 | English | English |
| License | Apache 2.0 | Apache License 2.0 |
パラメータ数・次元数・コンテキスト長・ライセンスが派生元とそのまま一致しているので、「Salesforce独自の閉じた数字」ではなく、公開モデルの仕様をそのまま引き継いだ値として読めます。この記事の数値の大半は、Salesforce Helpに加えてHugging Faceのモデルカード側でも裏が取れるということです。
ここで特に目を引くのが、最大8,000トークンという入力長です。
Search Index Referenceに掲載されているテキスト向けEmbeddingモデルの最大入力長を並べると、次のようになります。
| モデル | Modality | Parameters | 最大入力長 |
|---|---|---|---|
| E5-large-v2 | Text | 335M | 512 tokens |
| Multilingual-E5-large | Text | 560M | 512 tokens |
| SFR-v2-small | Text | 434M | 8,000 tokens |
512トークンから8,000トークンなので、扱える入力サイズには大きな差があります。
「Small」だけどE5 Large V2より小さいわけではない
ここが調べていて一番意外だったところです。
「SFR-v2-small」という名前だけを見ると、
Large
↓
高精度・大規模
Small
↓
軽量・高速
という関係を想像したくなります。
しかしSalesforceが公開している比較を見ると、そう単純ではありません。
| モデル | Parameters | Embedding Dimension | Context |
|---|---|---|---|
| E5-large-v2 | 335M | 1024 | 512 |
| SFR-v2-small | 434M | 1024 | 8192 |
実は、パラメータ数だけを比較するとSFR-v2-smallの方がE5-large-v2より多いです。
そして、もう一段大事だと思ったのがそもそも系統が違うという点です。
E5-large-v2
└─ intfloat の E5 ファミリー（BERT系）
SFR-v2-small
└─ Alibaba-NLP / gte-large-en-v1.5 の fine-tune
（transformer++ = BERT + RoPE + GLU 系）
つまり「Small」と「Large」は、同じシリーズの中でサイズを表しているラベルではありません。別々のモデルファミリーに付いた名前を、並べて見ているだけです。
- E5の「large」は、E5ファミリー内での相対サイズ（small / base / large）を表しています
- 一方、SFR-v2-smallの「small」が何との比較で付けられた名称なのかは、少なくとも公開されているModel Referenceからは読み取れません
したがって、E5ファミリーの「large」と、SFR-v2-smallの「small」を直接比較して、モデルサイズを判断することはできません。
そう考えると、
SFR-v2-small = E5 Large V2を小さくして高速化したモデル
と理解するのは適切ではなさそうです。E5を小さくしたものではなく、そもそもE5の派生ですらありません。
少なくとも「Small」という名前だけから、モデルサイズや精度を判断しない方がよさそうです。
Salesforce掲載ベンチマークではE5 Large V2を上回る
さらに興味深いのが、Salesforceが掲載しているベンチマークです。ここでは、モデルの優劣を断定するためではなく、Salesforceがどのような位置づけでSFR-v2-smallを説明しているかを見る材料として扱います。
| モデル | MTEB（56 tasks） | Retrieval（15 tasks） |
|---|---|---|
| E5-large-v2 | 62.2 | 50.6 |
| SFR-v2-small | 65.9 | 58.1 |
Salesforceでは、SFR-v2-smallについて、E5-large-v2に対してRetrieval性能が +7.5ポイント（15% relative）向上したと説明しています。
つまり、
E5 Large V2
↓
高精度
SFR-v2-small
↓
速度優先・精度は低め
という単純な使い分けではありません。
少なくともSalesforceが掲載している評価値だけを見ると、SFR-v2-smallは、
- 長いContext
- E5-large-v2を上回るRetrievalスコア
という特徴を持っているように見えます。
このスコアを読むときの注意点
ここで、日本語で使うことを考えている場合に必ず押さえておきたい前提があります。
この「MTEB 56 tasks」「Retrieval 15 tasks」という構成は、MTEB（Massive Text Embedding Benchmark）の英語ベンチマークの内訳です。56個のタスク、うち15個がRetrievalタスクという英語のデータセット群で測った値です。
つまり、
65.9 / 58.1 という数字は、英語データに対する評価値であって、日本語検索の品質を保証する数字ではありません。
これはSFR-v2-smallの対応言語がEnglishであることとも整合します。英語で強いモデルとして評価されているのであって、日本語で強いとは書かれていません。
もちろんベンチマークの数値だけで、実際の業務データに対する検索品質が決まるわけではありません。英語データであっても、業務ドメイン固有の言い回しが多ければ、汎用ベンチマークの順位はそのまま当てはまらないこともあります。
最終的には、自分たちのデータと質問パターンを使った評価が必要になります。
8,000トークン対応は何がうれしいのか？
RAGでは一般的に、ドキュメントをそのまま検索するのではなく、ある程度のサイズに分割して検索インデックスへ登録します。
長いドキュメント
↓
Chunking
↓
┌──────────┐
│ Chunk 1 │
├──────────┤
│ Chunk 2 │
├──────────┤
│ Chunk 3 │
└──────────┘
↓
Embedding
↓
Search Index
Data 360でも、検索用データを準備する際に、コンテンツをチャンク化してベクトル化し、検索可能な形で格納します。
E5-large-v2の最大入力長は512トークンですが、SFR-v2-smallでは8,000トークンです。
そのためSFR-v2-smallでは、より大きなチャンクをEmbeddingへ入力できる余地があります。
例えば、次のようなデータでは検討材料になりそうです。
- 長い業務マニュアル
- 議事録
- 要件定義書
- 提案書
- ナレッジ記事
- 長めの問い合わせ履歴
「8,000トークン対応」＝「8,000でチャンクを切る」ではない
ここで注意したいのは、
8,000トークン対応だから、8,000トークン単位でチャンクを作れば検索精度が高くなる
という意味ではないことです。
これは筆者の推測ではなく、Salesforce公式のチュートリアルが実際に選んでいる値を見ると分かりやすいです。
自社Webサイトでのgroundingを扱う公式ガイド（Ground Agentforce on Your Own Website）では、Salesforce Embedding V2 Small（＝SFR-v2-small）を使う構成として、次のように設定しています。
| 設定項目 | 値 |
|---|---|
| Chunking Strategy | Section Aware Chunking |
| Max Tokens | 1,200 |
| Embedding Model | Salesforce Embedding V2 Small |
Max Tokensは8,000ではなく1,200です。
そのうえで、公式ガイドは次の趣旨の説明をしています。
- 1,200トークンは、チャンクに十分な文脈を持たせつつ、必要以上に大きくしない値として選んでいる
- Salesforce Embedding V2 Smallはこのチャンクサイズをサポートしている
- 逆に512トークンのような小さいチャンクサイズを選ぶなら、サポートするシーケンス長がより小さいモデルを使うとよい
つまり公式の使い方としても、最大入力長は「上限」であって「推奨チャンクサイズ」ではありません。
チャンクが大きすぎると、一つのチャンクに複数の話題が混ざり、検索したい情報の意味が薄まる可能性もあります。検索は「そのチャンク全体」を1つのベクトルで表すので、話題が混ざるほど、どの質問にも中途半端に近いベクトルになりがちです。
整理すると、最大入力長は次の2つの意味で効いてきます。
| 効き方 | 内容 |
|---|---|
| 上限の引き上げ | 512では切れてしまう単位（長い節、長い議事録の1トピックなど）を、切らずに1チャンクへ入れられる |
| 設計自由度 | 512 / 1,200 / それ以上、とチャンクサイズを試せる幅が広がる |
RAGでは、
Embedding Model
+
Chunking
+
検索方式
+
Retriever
+
対象データ
をまとめて考える必要があります。
最大入力長が長いことは、チャンク設計の自由度を広げる要素の一つくらいに考えるのがよさそうです。
ただし、日本語で使うなら重要な注意点がある
ここは日本でAgentforceやData 360を利用する場合、かなり重要だと思います。
Salesforce公式のSFR-v2-small Model Referenceでは、Supported languageが English となっています。これは派生元のgte-large-en-v1.5が英語専用モデルであることとも一致しています。
一方、Data 360では別の選択肢として、Multilingual-E5-large も提供されています。
| 項目 | Multilingual-E5-large |
|---|---|
| ベースモデル | XLM-RoBERTa-large |
| Parameters | 560M |
| Embedding dimension | 1024 |
| 最大入力長 | 512 tokens |
| 対応言語 | 約100言語（日本語を含む） |
日本語を含む多言語データを扱うなら、まずここが比較対象になります。
そのため、日本語のナレッジを扱う場合に、
8,000 tokens対応
↓
SFR-v2-smallを選べばよい
と単純に考えるのは避けた方がよさそうです。
例えば、
英語中心のデータ
SFR-v2-smallを有力候補として比較する。
日本語を含むデータ
Multilingual-E5-largeとの比較・評価を行う。
という考え方になります。
Multilingual-E5-largeを選ぶ場合に効いてくる制約
ここで一つトレードオフがあります。Multilingual-E5-largeの最大入力長は 512トークンなので、SFR-v2-smallの8,000トークンという自由度は使えません。
さらに、E5系モデルのモデルカードでは、**512トークンを超える長い入力は最大512トークンまで切り詰められる（truncated）**と説明されています。
そのため、
- 長いチャンクを設定する場合、モデルへ実際に入力される範囲を意識する必要がある
- チャンク設計が512トークン以内に収まっているかを確認する
という点は、モデル選択とセットで見ておきたいところです。
日本語データでMultilingual-E5-largeを使うなら、チャンクのMax Tokenを512以内に収める設計になっているかを、Data Explorerなどで実際のチャンクを見ながら確認しておくと安心です。
特に日本企業のAgentforceでは、
- Salesforce Knowledge
- 社内FAQ
- マニュアル
- 問い合わせ履歴
- 業務手順書
などが日本語で作られているケースも多いと思います。
その場合はContext Lengthだけでなく言語対応もEmbeddingモデル選択の重要な評価軸になります。
ここでのポイントは、SFR-v2-smallを否定することではありません。
むしろ、
- 英語中心ならSFR-v2-smallを候補に入れる
- 日本語中心ならMultilingual-E5-largeも含めて比較する（チャンクは512トークン以内で設計する）
- 混在データなら、実際の質問セットでRetriever結果を見る
というように、モデル名ではなくデータと言語で選ぶのがよさそうです。
Data 360ではどこでEmbeddingモデルを使うのか？
Agentforceとの関係も整理してみます。
おおまかには、次のような流れとして捉えると理解しやすいです。
Data 360
↓
データ取り込み / 非構造化データ
↓
Chunking
↓
Embedding / Vectorization
↓
Search Index
↓
Vector Search / Hybrid Search
↓
Retriever
↓
Prompt Template / Agentforce
EmbeddingモデルがAgentforceの回答を直接生成しているわけではありません。
Embeddingモデルは主に、検索インデックスを作るためのベクトル表現を生成する部分を担当します。
検索インデックスからRetrieverが関連情報を取得し、その情報をAgentforceやPrompt TemplateのGroundingに利用する、という関係です。
つまりEmbeddingモデルの選択は、
Agentforceが回答するときに「どの情報を見つけてくるか」
というRAGの検索部分に影響します。
ここで押さえておきたいのは、Embeddingモデルは後から気軽に差し替えられるものではないという点です。モデルを変えるとベクトル空間そのものが変わるため、既存のインデックスを作り直すことになります。だからこそ、作る前に言語とチャンク設計を確認しておく価値があります。
Easy SetupではE5 Large V2が使われる
Data 360のSearch Indexには、Easy SetupとAdvanced Setupがあります。
Salesforce公式ドキュメントでは、Easy Setupで作成する検索インデックスについて、
- Embedding Model：E5-Large V2
- Search Type：Hybrid Search
とされています。Easy Setupでは、Embedding Modelや検索対象の項目が自動的に選択されるため、モデルを意識せずにインデックスが作られる点に注意が必要です。
一方、Advanced SetupではVectorizationの設定でEmbeddingモデルを選択できます。ここで Salesforce Embedding V2 Small（SFR-v2-small）や Multilingual E5 Large を選ぶことになります。
そのため、
SFR-v2-smallを使って比較してみたい
という場合は、そもそもEasy Setupではモデルを選べないので、Advanced Setupで作り直す必要があるという点まで含めて確認した方がよさそうです。
Agentforce Data Libraryを利用している場合も、裏側でData 360のSearch IndexやRetrieverが関係する構成として説明されています。細かな作成タイミングや設定項目は製品更新で変わる可能性があるため、実際の組織で確認するのが安全です。
では、どのモデルを選べばよいのか？
ここまでを見ると、
一番スコアが高いモデルを選べばよいのでは？
と思いたくなります。
しかし、実際にはデータによって変わりそうです。特にベンチマークが英語で測られている以上、日本語データでは順位がそのまま当てはまる保証がありません。
個人的には、少なくとも次の観点で比較したいと思いました。
| 観点 | 確認内容 |
|---|---|
| 言語 | 日本語か、英語か、多言語か（ここが最初のふるい） |
| 文書サイズ | 長い文書が多いか |
| Chunking | どの単位で分割するか、Max Tokenがモデルの上限に収まっているか |
| Retrieval精度 | 実際の質問で正しい文書を取得できるか |
| Search Type | Vector / Hybrid Search |
| 対象データ | FAQ、Knowledge、議事録など |
| Retriever | 取得件数やFilterなど |
順番としては、まず言語で候補を絞り、その中でチャンク設計とRetrieval精度を見るのが素直だと思いました。言語対応は後から工夫で埋められる部分が小さいためです。
例えば日本語データ中心なら、SFR-v2-smallの8,000トークンだけを見て決めるのではなく、Multilingual-E5-largeと実際の検索結果を比較した方がよさそうです。
逆に英語中心で長い文書を扱っているなら、SFR-v2-smallは比較候補に入れたくなる選択肢です。
モデル性能以外に見ておきたい注意事項
もう一つ、本番利用を考えるなら見ておきたい観点があります。
Salesforce公式のSFR-v2-smallのページには、規制変更の影響でこのモデルを削除する必要が生じた場合、代替モデルでSearch Indexを再構築するための事前通知を行う旨の注意書きがあります。
Search Indexの作り直しは、チャンク設計やRetrieverの再評価にもつながる作業です。
そのため本番利用では、ベンチマークや最大入力長といったモデル性能だけでなく、こうした提供上の注意事項も合わせて確認しておくとよさそうです。
「SFR-Embedding」と同じもの？
Salesforce AI Researchは2024年に「SFR-Embedding」というEmbeddingモデルを公開しています。
Text Embeddingが検索、分類、RAGなどの基盤技術として重要であることもSalesforceの公式ブログで解説されています。
ただし、注意したいのは、
Salesforce AI Research
SFR-Embedding / SFR-Embedding-2_R
と
Data 360
SFR-v2-small
を同じモデルとして扱わない方がよいという点です。
名前が似ているので混同しやすいのですが、公開されている仕様を並べると明確に別のモデルです。
| 項目 | SFR-Embedding-2_R（AI Research） | SFR-v2-small（Data 360） |
|---|---|---|
| ベースモデル | E5-mistral-7b-instruct / Mistral-7B-v0.1 | gte-large-en-v1.5 |
| Parameters | 約7B | 434M |
| 最大シーケンス長 | 4096 | 8192 |
| ライセンス | CC BY-NC 4.0（非商用。モデルカードではresearch purposes onlyと説明） | Apache License 2.0 |
| 提供形態 | Hugging Faceで公開 | Data 360のSearch Indexで選択 |
パラメータ数で約16倍、ベースモデルの系統もライセンスも違います。「SFR」という接頭辞（SalesForce Research）が共通しているだけで、中身は別物と考えた方が安全です。
特にライセンスは実務上の差が大きく、SFR-Embedding-2_Rは研究用途向けのライセンスで公開されている一方、Data 360のSFR-v2-smallはApache License 2.0の派生元をベースにしたモデルとしてSalesforceのサービス内で提供されています。「Hugging Faceで公開されているSFR-Embeddingを商用で使えるらしい」という読み方をしてしまうと、前提を取り違えます。
名前が似ているので少し混乱しやすいのですが、本記事ではData 360で選択できるSFR-v2-smallを対象としています。
調べる前と調べた後
今回調べる前は、名前だけから次のように想像していました。
E5 Large V2
↓
高精度・大規模
SFR-v2-small
↓
軽量・高速
しかし、公式情報を確認すると少し違いました。
SFR-v2-small
・434M parameters
・1024 dimensions
・最大8,000 tokens
・English
・Retrieval 58.1（英語ベンチマーク）
・ベースは gte-large-en-v1.5
↓
E5-large-v2
・335M parameters
・1024 dimensions
・最大512 tokens
・English
・Retrieval 50.6（英語ベンチマーク）
・ベースは E5 ファミリー
少なくとも、
「SmallだからE5 Large V2より小さくて、検索精度を落として高速化したモデル」
という理解ではなさそうです。そもそもE5の派生ではなく、別系統のモデルでした。
このあたりは、モデル名だけ見ているとなかなか分からない部分でした。
まとめ
Salesforce Data 360で利用できるSFR-v2-smallについて調べてみました。
主な特徴をまとめると、
- Data 360のSearch Indexで選択できるText Embeddingモデル（設定画面上の名前はSalesforce Embedding V2 Small）
- 最大入力長は8,000トークン
- 434Mパラメータ
- Embedding Dimensionは1024
- ベースモデルはgte-large-en-v1.5（E5系ではない）
- Salesforce公開のRetrievalベンチマークではE5-large-v2を上回る（ただし英語ベンチマーク）
- 公式上のSupported LanguageはEnglish
- 「Small＝単純な軽量版」とは言い切れない
- 日本語データではMultilingual-E5-largeとの比較が重要（こちらは512トークン上限）
- AgentforceではSearch Index → Retrieverを通してRAGに関係する
というモデルでした。
個人的には特に、
「Small」という名前なのに、E5 Large V2よりパラメータ数が多く、Salesforce公開のRetrievalスコアも高い
という点が印象的でした。そもそも同じシリーズの大小ではなく、別のモデルファミリー同士の名前を並べていた、というのが理解のポイントでした。
一方で、日本語環境ではSupported LanguageがEnglishであること、そして掲載スコアが英語ベンチマークの値であることを無視できません。
AgentforceのRAGを考えると、生成AIのモデルだけでなく、
データ
↓
Chunking
↓
Embedding
↓
Search Index
↓
Retriever
↓
Agentforce
という検索側の設計も回答品質を左右する重要な要素になりそうです。
モデル名やベンチマークだけで決めるのではなく、実際の業務データと質問を使ってRetrieverの検索結果を比較してみるのがよさそうです。
今回あえて書かないこと
この記事は概要理解を目的にしているため、次の内容は扱っていません。
- 実OrgでのSearch Index作成手順
- SFR-v2-small / E5-large-v2 / Multilingual-E5-largeの実測比較
- 日本語ナレッジに対する検索精度の検証
- チャンクサイズ別のRecall / Precision評価
このあたりは、別記事で「実際に比較してみた」として扱う方が読みやすそうです。
参考（公式情報）
Salesforce Help / Developers
- Salesforce Help: SFR-v2-small Embedding Model Reference
- Salesforce Help: Search Index Reference
- Salesforce Help: Retrieve Data
- Salesforce Help: Use Search for AI, Automation, and Analytics
- Salesforce Help: Create a Vector Search Index with Advanced Setup
- Salesforce Help: Create a Search Index Configuration with Easy Setup
- Salesforce Help: Agentforce Data Library
- Salesforce Developers: Step 3 - Create Search Index and Retriever（Ground Agentforce on Your Own Website）
- Salesforce Engineering: How Data 360 Vector Search Delivers Near Real-Time Intelligence
- Trailhead: Master Search Index Configurations for Effective Data Management
モデルカード（仕様の突き合わせに使用）
- Hugging Face: Alibaba-NLP/gte-large-en-v1.5（SFR-v2-smallの派生元）
- Hugging Face: intfloat/e5-large-v2
- Hugging Face: intfloat/multilingual-e5-large
Salesforce AI Research（別系統のSFR-Embedding）
- Salesforce Blog: SFR-Embedding-Mistral: Enhance Text Retrieval with Transfer Learning（旧URL:
blog.salesforceairesearch.com/sfr-embedded-mistral/） - Hugging Face: Salesforce/SFR-Embedding-2_R