目次
1. 課題設定
2. 全体パイプライン概要
3. 学習レシピ①：多様な文書収集
4. 学習レシピ②：合成クエリ生成
5. 学習レシピ③：Hard Negative Mining
6. 学習レシピ④：知識蒸留
7. 評価
8. GPUインフラ
9. モデルを使う
SionicAIは EUREKA(Extremely Universal Robust Embedding for Knowledge Access) プロジェクトを進めています。その名の通り、どんな言語・ドメイン・クエリ形式でも知識にたどり着けるようにする、普遍的(universal)で頑健(robust)な埋め込みを目指します。
1. 課題設定
検索埋め込みモデルは、クエリと関連文書を埋め込み空間上で近くなるように表現するモデルです。 ところが言語やドメインごとに要求される条件は異なります。
•
クエリスタイルが異なる: 短いキーワード検索もあれば、複数の段落を読み合わせる必要がある分析型の検索もあります。
•
文書の長さが異なる: 1文程度の短い文書から、数万字に及ぶ長文まで混在しています。
•
正解の位置が異なる: 正解が文書の冒頭にあることもあれば、本文の途中や末尾にあることもあります。
•
クエリと文書の対応が1:1ではない: 実際の検索では、一つのクエリに対応する文書が複数あり、一つの文書が複数のクエリに対応することもあります。
つまり、実際の検索で起こり得るさまざまな条件(正解位置の多様性、クエリ-文書の1:N・N:1関係)を学習データが捉えてこそ、特定の状況にだけ強いモデルではなく、どんな状況でも強い(robust)モデルが生まれます。
2. 全体パイプライン概要
学習パイプライン全体は次の6ステップから成ります。まず文書データを収集し（①）、学習用クエリを生成します（②）。次に、関連文書と混同しやすいnegativeを抽出し（③）、teacher modelのスコアを付与します（④）。そのスコアを使ってstudent modelを知識蒸留し（⑤）、最後に評価します（⑥）。
[多様なソースコーパス]
(FineWeb · HuggingFace · AIHub · 公開ドメインデータ …)
│ ① データ収集 · キュレーション
▼
[文書プール] ──② 合成クエリ生成──► [(クエリ, 文書) ペア]
│ ③ hard negative マイニング
▼
[(クエリ, 文書, negative×K)]
│ ④ teacher score 付与 (2つのteacher結合)
▼
[teacherスコアが付与された学習セット]
│ ⑤ KL-div distillation
▼
[student 検索モデル]
│ ⑥ 評価
▼
[ベンチマークスコア]
Markdown
복사
3. 学習レシピ①：多様な文書収集
合成クエリを作るには、まず文書(コーパス)が必要です。私たちは特定の一箇所に依存しないよう、多様な出所の文書を幅広く収集・キュレーションして学習用の文書プールを構成しました。
3.1 マルチソース文書収集
文書は単一のデータセットではなく、複数の公開ソースから幅広く収集しました。ウェブスケールコーパス（FineWeb系列）、Hugging Faceの公開データセット、そして法律・保健・医療・金融・科学・コードなどのドメインデータを収集しました。
3.2 学習・評価の分離による漏洩防止
学習ソースと評価ベンチマークが重ならないよう、収集段階でtest setに登場するデータを学習データから除外しました。この境界を明確に引いてこそ、その後の性能向上が実際の検索能力によるものか、ベンチマークの暗記によるものかを明確に区別できます。
4. 学習レシピ②：合成クエリ生成
良い合成クエリは、文脈上自然で、実際の検索意図や利用場面を反映した、自然なクエリである必要があります。合成クエリ生成ではデータの質を最優先とし、主に GPT-5.5 を使用しました。
4.1 クエリ多様性の確保
実際のユーザーのクエリは一つの形式ではありません。そこでクエリの多様性を生成段階の中心的な目標に据えました。
こうして、短い事実クエリ(factoid)、複数段落を統合する必要のある分析型クエリ、論評/レビュー型クエリ、自然言語でコードを探すコード検索クエリのようなドメイン特化クエリまで、異なる形式のクエリを幅広く生成しました。subsetの特性に合ったクエリ形式を用い、クエリの多様性のためにsubsetごとに一つの方式ではなく複数の方式を併用しました。したがって、学習データが特定のクエリ形式に偏らず、多様なクエリを学習できるよう促しました。
4.2 Answer Position Biasを考慮した学習データ構成
クエリ形式とともに統制したもう一つの変数は、正解となる文が文書のどこに位置しているかです。実際のユーザーの文書で、正解が常に特定の位置に来る保証はありません。本文の途中、結論部、付録、どこにでもあり得ます。
ところが検索モデルは、こうした正解位置に対する偏りを持ちやすいです。"Is Position Bias in Dense Retrievers Built In—or Learned from Data?"[4]によれば、一般的なdense retrieverは、クエリの正解に該当する文が文書の後方に位置するほど検索性能が低下する position bias の問題を抱えます。この偏りはアーキテクチャもある程度影響しますが、主要な偏りの要因は学習データに起因します。comsatはこの発見に基づき、学習データの正解位置分布を明示的に制御し、その結果、回答が文書のどの位置にあっても該当文書を安定的に検索するよう促しました。根拠箇所が文書の前半・中盤・後半に偏りなく分布するよう合成クエリを生成・選別しました。「正解は文書のどこにでもあり得る」という現実の検索状況を、学習データにそのまま織り込みました。
4.3 Multi-positiveデータ構成: 1:N・N:1対応関係の反映
現実の検索では、クエリと文書の対応は1:1ではないことがあります。
•
1:N (one query, many positives): 一つのクエリに複数の文書が対応する場合です。例えば「「年次有給休暇の規定はどうなっていますか」の答えは、就業規則・人事FAQ・社内規程など複数の文書に分かれて記載されている場合があります。
•
N:1 (many queries, one positive): 一つの文書が複数のクエリに対応する場合です。例えば一つの契約書条項が、期間・解約・更新に関する互いに異なるクエリすべての根拠になります。
ところが通常のRetrieval modelの学習データ構成では、クエリごとに正解文書を一つだけ使用します。多様な業界の検索ベンチマークであるRTEBリーダーボードで1位を達成したoctenの分析[5]も、このmulti-positiveラベルの保存を重要な要素として挙げています。そこで私たちは、一つのクエリに対して、複数の文書をpositiveとして付与し、一つの文書に多様なクエリ形式のデータを生成して、データのクエリ-文書構成を1:N・N:1で多様に保ちました。
5. 学習レシピ③：Hard Negative Mining
5.1 Hard Negativeの必要性
Contrastive learningにおいて、モデルは、正例のスコアが負例より高くなるように学習します。このときnegativeが簡単すぎると、十分な学習信号が得られません。positiveに似ているものの、実際には関連しない文書、すなわちhard negativeが検索品質を左右します。バッチ内の他サンプルをnegativeとして使うin-batch negativeだけでは、こうした混同しやすいnegativeを十分に確保できません。
5.2 Hard Negative Mining Method : Positive-aware Mining
Positive-aware miningはこれとは異なり、negativeを選ぶ際にそのクエリに対応する文書との類似度を基準にhard negativeを選択する方式です。
1.
埋め込み検索で各クエリに対して類似度上位の候補文書を取り出します。
2.
クエリとpositiveに対応する文書との類似度を基準線として閾値を定め、これを超える候補は除外します。
3.
残った候補の上位から、クエリごとに negative 15個 を確定します。
2番の閾値を数式で書くと、候補文書 は次を満たすときのみhard negativeとして採用されます。
すなわち、クエリと候補文書との類似度が、クエリとpositiveの類似度からmarginを引いた値を超える文書は除去します。つまり、クエリとpositiveとの類似度のmargin分だけ余裕を持たせ、それ以下でhard negative miningを行います。negativeを、それ自体のスコアの固定閾値ではなくそのクエリのpositiveスコアに相対的に選別する方法(positive-aware)を採ることで、より緻密にhard negative miningを進めることができました。
6. 学習レシピ④：知識蒸留
これで (query, positive, negative×15) が準備できました。残るは「positiveをnegativeよりどれだけ上に上げるべきか」をstudentに教えることです。私たちはその基準をより強いteacherモデルから得ます。
6.1 Scalar Teacher Score Precomputation
Teacherを学習ループ内で毎回実行すると、速度が遅くコストも大きくなります。代わりに学習前にteacherスコアをあらかじめ計算して保存(precompute)しました。保存するのは埋め込みベクトルではなく、各 (クエリ, 文書) ペアに対する scalarスコア です。
•
利点: 学習時にteacherをメモリに載せる必要がなく、studentだけをforwardすればよい。
•
保存スキーマ: クエリ単位で positiveスコア + negativeスコア15個
6.2 KL Divergence–Based Distillation Loss
studentは各クエリに対して positive + K(negative) 候補のスコア分布を作り、この分布を teacherのスコア分布に合わせるよう に学習します（KL divergenceベースのknowledge distillation[7])。このとき学習速度を上げるため、in-batch negativeは除外し、クエリごとの自身の候補群の中だけで分布を合わせます。この際、temperature(τ)で分布の尖り具合を調整します。
数式で書くと、クエリ q の候補集合 {positive p, negative n₁ … n_K} に対して、次のlossを最小化します。
studentスコア 、teacherスコア とすると、
Teacherのスコア分布をtargetとし、studentの候補スコア分布がそれに近づくほどlossが小さくなります。
6.3 Ablation Study on Loss Functions
代表的なretrieval model distillation lossの一覧
•
KL-div (listwise): 候補どうしの相対順位分布を合わせる。(τ=分布の尖り具合を決定)
◦
τによるdistributionの違いのグラフ例
•
•
実験はstudent・teacher・LRを固定し、lossだけを変えて行いました。評価指標は内部retrieval総合スコアです。
Lossごとに異なる4つの学習データで比較したスコアは次の通りです。
表1. Lossごとの最終性能 (内部retrieval総合スコア)
学習データ | KL-div (τ=0.05) | KL-div (τ=1.0) | Margin-MSE (hard-neg) | cosine-distillation |
データ A | 0.6216 | 0.5912 | 0.6035 | 0.5732 |
データ B | 0.6244 | 0.6050 | 0.6053 | - |
データ C | 0.6232 | 0.5935 | 0.6017 | - |
データ D | 0.6281 | 0.6148 | 0.6034 | - |
4つのデータすべてで KL-div(τ=0.05) が1位でした。
Cosine distillation はデータAで一度だけ実験しました。cosine distillation実験での低下の原因は、すでに十分整理されたstudentのembedding spaceを、teacher埋め込み空間に直接合わせるよう強制することで既存の表現が乱れるためであり、詳しいメカニズムは下の lossごとの動作原理 で扱います。
lossごとの動作原理
核心となる前提は、私たちのstudentがすでに十分にfinetuningされた強い検索モデルであり、自分なりのよく整理されたembedding spaceをすでに持っているという点です。
•
cosine distillation: student埋め込みを teacher埋め込み空間に直接整列 させます。jina-embeddings-v5[9]のようにゼロから(from scratch)学習する場合は強力ですが、すでに良いstudentには逆に作用します。teacherと次元を合わせるために付け足すlinear projectionは小さな値で初期化され、studentの既存空間が事実上そのまま維持されるのですが、その状態でteacher空間へ無理に引き寄せると、うまく整っていたstudentの表現が乱れます。
•
Margin-MSE: (positive − negative) の 絶対margin値 をteacherと同一に合わせます。これも絶対値の整列であるため、同じ理由でstudent空間を歪め、逆効果になります。
•
KL-div: teacherとstudentの絶対スコアが異なっても関係なく、候補どうしの相対的な順位分布だけを合わせます。studentのembedding space(絶対スケール)はそのままに 順位情報だけ を伝えるため、すでに優れたstudentを損なわずに性能を高めます。(ただし温度τが大きすぎると分布が平坦になり信号が弱まります。表のτ=1.0の事例がこれに当たります。)
すなわち 「すでに強いstudent + 相対順位が本質である検索」 の組み合わせでは、teacherの絶対表現に合わせるcosine・MSEではなく、相対順位分布を合わせる今回の実験では、KL-divが最も良い結果でした。
7. 評価
すべてのスコアは NDCG@10(上位10件の検索結果のランキング品質、1.0が最大)です。
7.1 
日本語: JMTEB v2 · 社内OODベンチマーク
公開ベンチマーク：JMTEB v2（11タスク）。日本語では、用途に応じて2つのモデルを開発しました。最高性能を目指したcomsat-embed-ja-8b（8B decoder系列）と、軽量なデプロイを目指したcomsat-embed-ja-0.3b（0.3B encoder）です。
comsat-embed-ja-8bとcomsat-embed-ja-0.3bはいずれも同一のパイプラインで学習しており、オープンモデルのリーダーボードでは、8Bモデルが総合1位（0.8133）、0.3Bモデルが総合5位（0.7785）を記録しました。商用APIモデルとの比較については、後ほど別に扱います。
表3. 日本語 公開ベンチマーク オープンウェイト上位10モデル (JMTEB v2 · 11タスク平均NDCG@10 · 同一採点パイプライン)
順位 | モデル | 開発組織 | 平均NDCG@10 |
1 | comsat-embed-ja-8b | Sionic AI | 0.8133 |
2 | F2LLM-v2-14B | CodeFuse | 0.7965 |
3 | Qwen3-Embedding-8B | Alibaba | 0.7924 |
4 | F2LLM-v2-8B | CodeFuse | 0.7855 |
5 | comsat-embed-ja-0.3b | Sionic AI | 0.7785 |
6 | Qwen3-Embedding-4B | Alibaba | 0.7779 |
7 | F2LLM-v2-4B | CodeFuse | 0.7705 |
8 | Qwen3-VL-Embedding-8B | Alibaba | 0.7702 |
9 | sarashina-embedding-v2-1b | SB Intuitions | 0.7659 |
10 | ruri-v3-130m | 名古屋大学 | 0.7641 |
comsat-embed-ja-8b: JMTEB総合1位。 JMTEB v2 11タスク平均NDCG@10 0.8133 で、2位(F2LLM-v2-14B)と0.015ポイント以上の差をつけています。
comsat-embed-ja-0.3b: 公開の小型(≤4B)1位。 0.3B(310M)という小さなサイズで、F2LLM-v2-14B・Qwen3-Embedding-8Bなど10倍以上のパラメータを持つモデルに次ぐ総合5位となり、公開されている小型(≤4B)モデルの中では 1位 です。
モデルサイズ軸の散布図で見ると、8Bは最上段に、0.3Bは 自分より10〜40倍大きいモデルたちと同じ性能帯 に位置します。どちらも、モデルサイズに対して高い性能を示しています。
グローバルな商用（クローズド）埋め込みAPIとの比較でも1位を記録しました。APIモデルが評価されていないMIRACLとMr.TyDiを除く共通9タスクの平均では、comsat-embed-ja-8bがNDCG@10で0.8399を達成し、Gemini Embedding 001（0.7991）、Gemini Embedding 2（0.7893）、Cohere Embed v4.0（0.7805）、OpenAI text-embedding-3-large（0.7459）をすべて上回りました。なお、ここでのスコアは共通9タスクの平均であり、前述した11タスク平均とはタスク構成が異なるため、絶対値を直接比較することはできません。
公開モデルと商用APIモデルを一堂に並べ、同じベンチマークで比較しても 1位 です(Qwen3-8B 0.7394, Gemini-Emb-001 0.7219(API), Cohere Embed-v4.0 0.7181(API), Arctic-l-v2.0 0.7136, EmbeddingGemma-300m 0.7090, bge-m3 0.6845)。
指標には、各ドメインごとに複数のチャンクサイズ（128 / 256 / 512 / 1024 / 2048）で計測したNDCG@10の平均を用いています。これは実務のRAG（検索拡張生成）で ドキュメントを分割する際に一般的に使われる粒度であり、短い分割から長い分割まで 、どのチャンク条件でも安定して機能するかを見極める狙いです。
比較対象は、オープンウェイト5モデルと商用API4モデルを合わせた計9モデル。Qwen3-8 Bや、Google Gemini・Cohere・OpenAIといった主要な商用API、bge-m3・Arctic・Embedd ingGemmaなどのオープンモデルが並びます。その中で自社モデル comsat-ja-8B（青）は 、比較した9モデルすべてを上回り、17ドメインのすべてで首位、平均スコアでも1位 となりました。
特定のドメインやチャンクサイズに偏ることなく、あらゆる条件で安定して最高水準を維持している点は、学習データへの過適合ではなく、ドメインもデータ形式も多様な実運用環境——すなわちAI活用の実際の現場——においても、確かに効果を発揮できることを示しています。
7.2 性能への寄与要因
1.
現実の分布を反映したデータ構成
•
多様なソースから文書データを収集しました。
•
文書に適した多様な合成クエリを生成しました。
•
正解位置を多様に考慮しました。
•
クエリと文書の対応を1:1ではなく1:N・N:1と多様に構成しました。
2.
Hard Negative Mining
•
Positive-awareな方式でhard negative miningを行い、望ましい難易度のnegativeを選別できました。
8. GPUインフラ: NVIDIA B300 64枚 (8ノード × 8)
1ノードのGPU構成
comsat-embedモデル群は NVIDIA B300 GPU 64枚(ノードあたり8枚 × 8ノード)で学習しました。8Bモデルの8192トークン長文学習や、大規模なteacherスコアのprecomputeまで無理なくこなしてくれたおかげで、データ構成 → ハードネガティブマイニング → distillation の実験サイクルを素早く繰り返すことができました。
9. モデルを使う
モデルはHuggingFaceで公開されています。本記事で紹介した2モデルは、現在previewバージョンとしてHugging Faceで公開されています。公開リポジトリは以下の通りです。
表4. 公開モデル仕様 (HuggingFace公開 · ライセンス CC-BY-NC-4.0)
モデル | 言語 | パラメータ | アーキテクチャ / pooling | 埋め込み次元 | 最大長 | クエリ/文書 prefix処理 |
sionic-ai/comsat-embed-ja-8b-preview | 日本語 | 8B | decoder / last-token | 4096 | 8192 | クエリにquery prefix、文書はprefixなし |
sionic-ai/comsat-embed-ja-0.3b-preview | 日本語 | 0.3B(310M) | encoder / mean | 768 | 8192 | 検索クエリ: / 検索文書: prefix |
すべての埋め込みはcosine類似度で比較します。
from sentence_transformers import SentenceTransformer
model = SentenceTransformer("sionic-ai/comsat-embed-ja-8b-preview")
queries = ["新入社員向けの情報セキュリティ研修はいつ実施されますか？"]
documents = [
"新入社員向け情報セキュリティ研修を、4月15日の午後2時から午後4時まで、第2会議室で実施します。研修では、パスワード管理、機密情報の取り扱い、フィッシングメールへの対応方法について説明します。対象者は開始10分前までに集合してください。",
"全社員向けコンプライアンス研修を、4月18日の午前10時から正午までオンラインで実施します。研修内容は、個人情報保護、職場におけるハラスメント防止、社内規定の改定事項です。",
]
query_emb = model.encode(queries, prompt_name="query") # クエリには必ずquery prefixを適用
doc_emb = model.encode(documents) # 文書はprefixなし
similarity = model.similarity(query_emb, doc_emb)
Python
복사
ライセンス : 公開するモデルの重みは CC BY-NC 4.0(非商用利用)で配布されます。ライセンス条件の範囲内で、研究・評価・個人利用などの非商用目的に利用できます。商用利用は下記までお気軽にお問い合わせください。 お問い合わせ : comsat-embedを実際にお試しになる中でご不明な点が生じたり、商用利用・カスタマイズ・協業が必要になったりした場合は、Sionic AI(サイオニックエーアイ)へお気軽にお声がけください。皆さまが取り組んでいる検索課題を一緒に考えたいと思っています。EUREKA
この記事は EUREKA(Extremely Universal Robust Embedding for Knowledge Access) — どんな言語・ドメイン・クエリ形式でも知識にたどり着ける、普遍的で頑健な埋め込み — という目標から出発しました。その目標に向けて、私たちは世界中の文書を幅広く集め(秘密のレシピ ①)、ユーザーが投げそうなクエリを生成し(秘密のレシピ ②)、紛らわしい誤答を掘り出し(秘密のレシピ ③)、より強いteacherの順位感覚をstudentへdistillationで移しました(秘密のレシピ ④)。そうして完成したcomsat-embedは、日本語の検索ベンチマークで1位となり、その目標へ一歩近づきました。
まだpreviewであり、道のりも残っていますが、方向は明確です。その方向とは、膨大な文書の中から、必要な情報を正確に見つけ出せる検索モデルを目指します。
参考文献
[2]: Lee et al., Gecko: Versatile Text Embeddings Distilled from Large Language Models, 2024. arXiv:2403.20327
[3]: Qwen Team, Qwen3 Embedding: Advancing Text Embedding and Reranking Through Foundation Models, 2025. arXiv:2506.05176
[4]: Yu et al., Is Position Bias in Dense Retrievers Built In—or Learned from Data?, 2026. arXiv:2605.26578
[5]: Octen Team, Octen Series: Optimizing Embedding Models to #1 on RTEB Leaderboard, 2026. Octen ブログ
[6]: Moreira et al., NV-Retriever: Improving text embedding models with effective hard-negative mining, 2024. arXiv:2407.15831
[8]: Hofstätter et al., Improving Efficient Neural Ranking Models with Cross-Architecture Knowledge Distillation, 2020. arXiv:2010.02666
[9]: Akram et al. (Jina AI), jina-embeddings-v5-text: Task-Targeted Embedding Distillation, 2026. arXiv:2602.15547