BGE（FlagEmbedding）を採用する前に確認すること: 埋め込みとリランカーを1つのリポジトリで扱う構成
Retrieval and Retrieval-augmented LLMs
ひと目でわかる
- これは何？
- BAAI の FlagEmbedding は、BGE 系の埋め込みモデルとリランカー、そして BGE-M3 や Visualized-BGE といった派生研究を1つのリポジトリにまとめたツールキットである。検索と RAG のどこをこのリポジトリに任せ、どこを自前で持つべきかを、README とリポジトリ構成から読み取れる範囲で整理する。
- 誰に向いている？
- BGE 系の埋め込みモデルを自前の検索基盤に組み込み、リランカーまで同じ配布元で揃えたいチームには向いている。逆に、ホスティング型の検索 API で十分な用途や、埋め込みモデルの学習自体を主目的とする場合には、このリポジトリの中心部分は不要である。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 23 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
BGE が埋めているのは「検索パイプラインの部品が別々に配布される」問題
検索や RAG を組むとき、埋め込みモデル、リランカー、評価ベンチマークはたいてい別々のリポジトリや別々の配布元から来る。FlagEmbedding はそこを1つに寄せたツールキットで、README の冒頭で「One-Stop Retrieval Toolkit For Search and RAG」と名乗っている。対象読者は、RAG の検索精度を上げたいが、埋め込みとリランキングを別々のライブラリで繋ぐ糊コードを書きたくないエンジニアである。
リポジトリの構成もその方針に沿っている。ルート直下に research ディレクトリがあり、その中に baai_general_embedding、BGE_M3、llm_reranker、visual_bge、Long_LLM といったサブプロジェクトが並ぶ。製品としての BGE 本体と、そこから派生した研究コードが同じツリーに入っている点が、単一モデルの配布リポジトリとの違いである。Tutorials ディレクトリも 2024 年 9 月から維持すると README に書かれている。
BGE-M3 の3方式同時保持という設計をどう読むか
BGE 系の中核は BGE-M3 である。README は M3 を Multi-linguality（100 以上の言語）、Multi-granularities（入力長は最大 8192）、Multi-Functionality（dense、lexical、multi-vec/colbert の統合）の3点で説明している。つまり1つのモデルから密ベクトル、語彙ベースのスコア、ColBERT 型のマルチベクトルの3種類の検索信号が得られる。
これは実務的には、ハイブリッド検索を別々のモデルで組む必要がなくなるという意味を持つ。スパース検索用に BM25 を別途立て、密ベクトル用に別の埋め込みモデルを動かす、という構成を1つの推論経路に畳める可能性がある。ただし README はこの3方式をどう重み付けして統合するかまでは述べていない。スコアの融合方法は利用側の設計判断であり、そこは自分で決める必要がある。技術レポートとコードは research/BGE_M3 に置かれていると README が示しているので、融合の実装例はそちらを読むことになる。
リランカーは LLM バックボーン側に寄っている
リランキングは BGE の初期からの構成要素だが、2024 年以降のリリースは方向性が変わっている。3 月 18 日付の項目では、M3 と LLM（GEMMA と MiniCPM）をバックボーンにしたリランカーが research/llm_reranker に置かれ、多言語処理とより長い入力に対応すると説明されている。7 月 26 日には bge-reranker-v2.5-gemma2-lightweight が公開され、トークン圧縮とレイヤ単位の軽量化でリソースを削減しつつ性能を保つと README は述べている。
ここから読み取れるのは、リランカーの精度向上がモデルサイズの拡大とセットで進んできたという履歴である。軽量版が用意されたのは、その拡大が実運用では重すぎたからだと推測できる。ただし README には具体的なレイテンシやメモリ量の数値は載っていない。Gemma-2-9b ベースのリランカーをどの程度の GPU で回せるかは、この資料からは判断できない。導入検討時には、まず軽量版の側から試して、必要なら大きい方に上げる順序が現実的だろう。
導入は pip 1 行、ただしモデル選定は別作業
インストールは README の Installation セクションに従う形で、pip install -U FlagEmbedding が基本になる。ソースから入れる場合はリポジトリを clone して pip install -e . を実行する手順が示されている。Python パッケージとして入るので、既存の検索サービスに組み込むハードルは低い。
注意すべきは、パッケージのインストールとモデルの選択が別の作業だという点である。README には Model List セクションと Hugging Face のコレクション（BAAI/bge-66797a74476eb1f085c7446d）へのリンクがあり、bge-m3、bge-en-icl、bge-multilingual-gemma2、bge-reranker-v2.5-gemma2-lightweight などが個別のモデルとして配布されている。どのモデルをどのタスクに使うかは、この一覧と各モデルカードを突き合わせて決める。パッケージのバージョンとモデルの対応は README からは自明ではないので、リリースノート（v1.4.0、v1.4.1、v1.4.2）と実際に使うモデルの組み合わせは導入前に確認したほうがよい。
研究ディレクトリの同居がもたらす保守コスト
FlagEmbedding の特徴は、製品として使う部分と研究コードが同じリポジトリに同居していることだ。research 配下には visual_bge、Long_LLM の longllm_qlora や activation_beacon、llm_reranker、BGE_M3 などが並ぶ。News を見ると、Llama-3-8B-Instruct-80K-QLoRA や Visualized-BGE、MemoRAG、OmniGen といった、埋め込みとは直接関係しない項目も同じ流れで告知されている。
これは情報の集約という点では便利だが、依存関係の管理という点では負担になる。研究ディレクトリのコードはそれぞれ独自の依存を持ちうるし、本体のバージョンアップが研究側のコードに影響しないという保証は README からは読み取れない。本体だけを使いたいチームにとっては、ツリーの大半が関心外のコードになる。clone して使う場合は、どのディレクトリを追跡するかを決めてから始めたほうがよい。
Visualized-BGE と BGE-VL は別物として扱う
画像を含む検索を考えている場合、README には2つの異なる取り組みが現れる。1つは 2024 年 3 月 18 日の Visualized-BGE で、BGE に視覚能力を付与し、画像とテキストが混在したデータの埋め込みを生成できると説明されている。もう1つは 2025 年 3 月 6 日の BGE-VL で、text-to-image、image-to-text、image&prompt-to-image といった検索に対応するマルチモーダル埋め込みモデルとして紹介され、MIT ライセンスで学術・商用ともに無料と明記されている。
両者は名前が似ているが、リポジトリ上の位置づけが違う。Visualized-BGE は research/visual_bge に置かれた研究コードであり、BGE-VL は Hugging Face のコレクション（BAAI/megapairs-67c6bbe49c15a9e7a7c69d92）で配布されるモデルである。マルチモーダル検索を検討するなら、古い方の研究コードではなく BGE-VL のモデルカードを起点にするのが素直な読み方だ。
埋め込みを自前で学習したい人には向かない
FlagEmbedding が向かないケースはいくつかある。第一に、埋め込みモデルを自前のドメインデータで一から学習したい場合。リポジトリには baai_general_embedding の研究コードがあり、学習に関わる実装は存在するが、README は学習パイプラインを主要な機能として前面には出していない。学習済みモデルを使って検索を組むことが主眼のツールキットだと読むのが自然である。
第二に、検索基盤そのものをマネージドサービスで済ませたい場合。BGE はモデルの重みを自分でホストする前提であり、推論サーバの運用、GPU の確保、インデックスの管理は利用側の責任になる。第三に、多言語検索が不要で、英語のみの軽量な検索で足りる場合。BGE-M3 の3方式同時保持や 8192 トークンの入力長は、その必要がないなら過剰な複雑さになる。
代替としては、同じくオープンな埋め込みモデルを配布する Sentence Transformers 系のモデル群が挙げられる。違いは明確で、Sentence Transformers は埋め込み生成に機能を絞り、リランカーやマルチベクトル検索は別ライブラリの組み合わせで組む。FlagEmbedding は逆に、密・疎・マルチベクトルとリランカーを1つの配布元にまとめる方向に振っている。検索スタックの部品を減らしたいなら後者、1つの責務だけを小さく持ちたいなら前者である。
MIT 表示と個別モデルの条件を分けて確認する
ライセンスはリポジトリ全体として MIT が表示されている。README のバッジにも LICENSE-MIT があり、BGE-VL については MIT ライセンスで学術・商用ともに無料と本文で明記されている。ここまでは導入の障壁にならない。
ただし注意点がある。リポジトリには研究ディレクトリのコードと、Hugging Face 側で配布される多数のモデルが含まれる。リポジトリの MIT 表示が、それら個々のモデルの重みの利用条件まで一律に定めているとは README からは読み取れない。特に gemma-2-9b をベースにした bge-multilingual-gemma2 や bge-reranker-v2.5-gemma2-lightweight は、ベースモデル側の条件を別途確認する必要がある。ここは法的助言ではなく、確認箇所の指摘である。
保守コストの面では、リリースが v1.4.0（2026 年 4 月 22 日）、v1.4.1（8 月 23 日）、v1.4.2（8 月 24 日）と続いており、更新は活発である。活発な更新は利点である一方、マイナーリリース間の追従コストを負うことでもある。パッケージのバージョンを固定して、モデルの重みは別途バージョン管理する、という分離を最初から決めておくと、後々の更新が楽になる。
編集部の結論
BGE 系の埋め込みモデルを自前の検索基盤に組み込み、リランカーまで同じ配布元で揃えたいチームには向いている。逆に、ホスティング型の検索 API で十分な用途や、埋め込みモデルの学習自体を主目的とする場合には、このリポジトリの中心部分は不要である。導入前に確認すべきは、README の News にある通り BGE-VL が MIT ライセンスで提供される一方、リポジトリ全体の MIT 表示と個々のモデル・研究ディレクトリの条件が一致するかどうか、そして pip install -U FlagEmbedding で入るバージョンと利用したいモデル（bge-m3、bge-reranker-v2.5-gemma2-lightweight など）の対応関係である。
コミュニティノート