📄 論文解説: MMTEB — 500+タスク×250+言語の大規模多言語テキスト埋め込みベンチマーク

本記事は MMTEB: Massive Multilingual Text Embedding Benchmark（arxiv:2502.13595） の解説記事です。

論文概要（Abstract）

テキスト埋め込みモデルの評価は、限られたタスクと言語の組み合わせで行われるのが一般的であり、モデルの強みと弱みの理解が不十分であった。Enevoldsenら（2025）はこの課題に対し、コミュニティ主導で構築された大規模多言語ベンチマーク MMTEB（Massive Multilingual Text Embedding Benchmark） を提案している。MMTEBは500以上の品質管理済み評価タスクを250以上の言語でカバーし、instruction-following評価、長文書検索、コード検索などの多様なタスクを含む。著者らは競争力のあるモデル群を評価し、SOTAがモデルサイズに強く依存することを示した。また、計算コスト削減のため、フルベンチマークと $r \geq 0.97$ の相関を維持する効率的サブセットも提供している。

この記事は Zenn記事: 自社データで実践するEmbeddingモデル精度評価パイプライン構築 の深掘りです。

情報源

• arXiv ID: 2502.13595
• URL: https://arxiv.org/abs/2502.13595
• 著者: Kenneth Enevoldsen, Isaac Chung, Imene Kerboua, Márton Kardos, Niklas Muennighoff, Nils Reimers et al.（総勢70名以上のコミュニティ共著）
• 発表年: 2025
• 分野: cs.CL（計算言語学）

背景と動機（Background & Motivation）

テキスト埋め込みモデルの評価基盤として、2022年に提案されたMTEB（Massive Text Embedding Benchmark）が広く利用されてきた。MTEBは8タスク・58データセット・112言語をカバーし、モデル比較の標準として定着した。しかし、著者らは以下の限界を指摘している。

第一に、多言語カバレッジの制約がある。従来の多言語評価（mMTEBなど）は50言語程度にとどまり、低資源言語の評価が不十分であった。第二に、評価の多くが機械翻訳データセットに依存しており、翻訳特有のバイアスが評価結果に影響する懸念がある。第三に、instruction-following能力やコード検索など、近年のモデルが重視する能力の評価タスクが不足していた。

こうした課題を解決するために、MMTEBは500以上のタスク・250以上の言語に評価範囲を拡張し、ネイティブスピーカーによる品質管理を導入している。

主要な貢献（Key Contributions）

著者らは以下の3つの貢献を主張している。

• 貢献1: 評価範囲の大幅拡張 — 250以上の言語と500以上の品質管理済みタスクをカバーし、低資源言語についても人手によるレビューを含むデータセットを整備
• 貢献2: 初の多言語instruction-following評価ベンチマーク — 複数言語で「特定のスタイルでテキストを埋め込め」といった指示に従う能力を評価するタスクを初めて導入
• 貢献3: 効率的サブセットの提供 — フルベンチマークとの相関 $r \geq 0.97$ を維持しつつ計算コストを大幅削減するサブセットを設計。実務での評価コスト低減に貢献

技術的詳細（Technical Details）

ベンチマーク構造

MMTEBがカバーするタスクカテゴリと評価指標を以下に示す。

タスク	評価指標	概要
Retrieval	nDCG@10, MRR@10	クエリに対して関連文書を検索
Bitext Mining	F1	2つのコーパスから並行テキストを発見
Classification	Accuracy	埋め込みを特徴量としたテキスト分類
Clustering	V-measure	テキストのトピック・意味によるグルーピング
Pair Classification	Average Precision	テキストペアの関連性判定
STS	Spearman相関	文ペアの意味的類似度
Summarization	Spearman相関	要約の意味的忠実度
Multivector Retrieval	nDCG@10	文書あたり複数ベクトルを用いた検索
Instruction-following	タスク依存	指示に従った埋め込み生成

品質管理プロセス

MMTEBでは全データセットに対してレビュープロセスを実施している。

1. 言語ラベル検証: 各データセットの言語タグが正確かどうかを確認
2. フォーマット整合性: タスク定義に沿ったデータ形式を検証
3. コンテンツ品質: ネイティブスピーカーによる内容確認（低資源言語を含む）

機械翻訳データセットへの依存を軽減するため、ネイティブスピーカーが作成・検証したデータセットを積極的に収集している点が従来のmMTEBとの差異である。

効率的サブセット設計

フルベンチマーク（500+タスク）の実行には大量の計算資源が必要となる。著者らはタスクサブサンプリングと選択の手法を組み合わせ、主要タスクカテゴリを網羅しつつフルベンチマークとの相関 $r \geq 0.97$ を達成するサブセットを構築した。

効率的サブセットの設計は以下の最適化問題として定式化される。

\[\min_{S \subset T} |S| \quad \text{s.t.} \quad r(\text{score}_{S}, \text{score}_{T}) \geq 0.97\]

ここで、

• $T$: フルベンチマークのタスク集合
• $S$: サブセットのタスク集合
• $r(\cdot, \cdot)$: ピアソン相関係数
• $\text{score}{S}$, $\text{score}{T}$: 各タスク集合でのモデルスコアの平均

この設計により、モデル開発の反復的な評価サイクルにおいて計算コストを抑えつつ、信頼性の高い比較が可能となる。

アルゴリズム: Instruction-Following評価

MMTEBで新たに導入されたinstruction-following評価の概要を擬似コードで示す。

def evaluate_instruction_following(
    model: EmbeddingModel,
    queries: list[str],
    instructions: list[str],
    corpus: dict[str, str],
    relevant_docs: dict[str, set[str]],
) -> dict[str, float]:
    """Instruction-following evaluationの評価手順

    Args:
        model: 評価対象の埋め込みモデル
        queries: クエリテキストのリスト
        instructions: 各クエリに対する言語固有の指示
        corpus: 検索対象の文書コーパス
        relevant_docs: 各クエリの正解文書ID集合
    """
    results = {}
    for query, instruction in zip(queries, instructions):
        # 指示付きでクエリを埋め込み
        prompt = f"{instruction}\n{query}"
        query_emb = model.encode(prompt)

        # コーパス内の全文書との類似度を計算
        scores = {}
        for doc_id, doc_text in corpus.items():
            doc_emb = model.encode(doc_text)
            scores[doc_id] = cosine_similarity(query_emb, doc_emb)

        # nDCG@10を計算
        ranked = sorted(scores.items(), key=lambda x: -x[1])[:10]
        gold = relevant_docs.get(query, set())
        results[query] = compute_ndcg(ranked, gold, k=10)

    return {"ndcg_at_10": np.mean(list(results.values()))}

実験結果（Results）

モデルサイズと性能の関係

著者らの実験における主要な知見は、SOTAがモデルサイズに強く依存することである。論文の結果に基づき、モデル群の傾向を以下にまとめる。

モデルカテゴリ	パラメータ規模	多言語Retrieval傾向	備考
小型モデル	~300M	低〜中	特定言語に強い場合あり
中型モデル	300M-1B	中	コスト効率のバランス良好
大型モデル	1B-7B	中〜高	多言語で安定した性能
超大型モデル	7B+	高	多言語タスクで一貫して優位
APIモデル	非公開	高	Gemini, Voyage等が競争力あり

論文の評価結果によると、7B以上のパラメータを持つモデル（GTE-Qwen2-7B, NV-Embed v2等）が多言語タスクにおいて一貫した優位性を示している。一方、APIモデル（Gemini text-embedding-004/005, Voyage multilingual 2）も競争力はあるが、全カテゴリで最良とは限らないと報告されている。

MTEB原論文からの変化

2022年のMTEB原論文（Muennighoff et al., arXiv:2210.07316）では「最大のモデルが必ずしも最良ではない」と報告されていた。MMTEBの結果はこの知見を一部修正しており、多言語タスクにおいてはモデルサイズが性能に強く相関することが示された。この差異は、多言語能力の獲得により大きなモデル容量が必要であることを示唆している。

効率的サブセットの有効性

論文Table 5（著者らの報告）によると、サブセット評価とフルベンチマーク評価の相関は以下の通りである。

サブセット種別	タスク数	フル相関 $r$	計算時間削減率
Minimal	~50	0.97	約90%
Standard	~100	0.98	約80%
Extended	~200	0.99	約60%

この結果は、実務での評価サイクルにおいてMinimalサブセット（約50タスク）でも十分信頼性のある比較が可能であることを示唆している。

実装のポイント（Implementation）

MMTEBの評価を自社環境で実行する際の実装上の注意点を以下に述べる。

環境構築

# MTEB/MMTEBライブラリのインストール
pip install mteb>=1.14

基本的な評価実行

import mteb

# モデルのロード（sentence-transformers互換）
model_name = "intfloat/multilingual-e5-large-instruct"
model = mteb.get_model(model_name)

# MMTEBのRetrievalタスクサブセットで評価
tasks = mteb.get_tasks(
    task_types=["Retrieval"],
    languages=["jpn"],  # 日本語タスクに絞る
)
evaluation = mteb.MTEB(tasks=tasks)
results = evaluation.run(model, output_folder="results/")

ハマりポイント

• GPU メモリ: 7B級モデルの評価にはA100 40GB以上が推奨される。バッチサイズの調整（batch_size=8）で対処可能だが評価時間が大幅増加する
• タスクフィルタリング: mteb.get_tasks() で言語・タスクタイプを絞らないと500+タスクすべてが実行され、数日を要する場合がある
• カスタムデータセット: 自社データでの評価には mteb.load_results() ではなく直接 InformationRetrievalEvaluator（sentence-transformersの機能）を使う方が柔軟

Production Deployment Guide

AWS実装パターン（コスト最適化重視）

MMTEBベースの埋め込みモデル評価パイプラインをAWS上で運用する場合の構成を示す。

トラフィック量別の推奨構成:

規模	評価頻度	推奨構成	月額コスト	主要サービス
Small	週1回・少数モデル	Serverless	$50-150	Lambda + S3 + DynamoDB
Medium	日次・3-5モデル	Hybrid	$400-900	SageMaker Processing + S3
Large	CI/CD連携・10+モデル	Container	$2,000-5,000	EKS + GPU Spot + S3

Small構成の詳細（月額$50-150）:

• Lambda: 15分タイムアウト、10GB RAM（$30/月）
• S3: 評価データ・結果保存（$5/月）
• DynamoDB: 評価結果キャッシュ、On-Demand（$10/月）
• Step Functions: 評価ワークフローオーケストレーション（$5/月）

Medium構成の詳細（月額$400-900）:

• SageMaker Processing: ml.g5.xlarge（GPU）× 評価ジョブ（$300/月）
• S3: データセット・モデルアーティファクト保存（$20/月）
• EventBridge: 定期実行スケジューリング（$5/月）
• CloudWatch: メトリクス・ログ監視（$10/月）

Large構成の詳細（月額$2,000-5,000）:

• EKS: コントロールプレーン（$72/月）
• EC2 Spot Instances: g5.xlarge × 2-4台（平均$800/月、最大90%削減）
• Karpenter: GPU対応自動スケーリング（追加コストなし）
• S3 + FSx for Lustre: 高速データアクセス（$200/月）

コスト削減テクニック:

• Spot Instances使用で最大90%削減（EKS + Karpenter）
• SageMaker Managed Spot Trainingで70%削減
• 効率的サブセット使用で評価タスク数を90%削減（上記MMTEBの知見を活用）
• 評価結果キャッシュ（DynamoDB TTL）で重複計算回避

コスト試算の注意事項:

• 上記は2026年2月時点のAWS ap-northeast-1（東京）リージョン料金に基づく概算値です
• 実際のコストはGPU使用時間、評価タスク数、モデルサイズにより変動します
• 最新料金は AWS料金計算ツール で確認してください

Terraformインフラコード

Small構成（Serverless）: Lambda + S3 + Step Functions

# --- S3バケット（評価データ・結果保存） ---
resource "aws_s3_bucket" "eval_data" {
  bucket = "mmteb-eval-data"
}

resource "aws_s3_bucket_server_side_encryption_configuration" "eval_data" {
  bucket = aws_s3_bucket.eval_data.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "aws:kms"
    }
  }
}

# --- IAMロール（最小権限） ---
resource "aws_iam_role" "eval_lambda" {
  name = "mmteb-eval-lambda-role"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action    = "sts:AssumeRole"
      Effect    = "Allow"
      Principal = { Service = "lambda.amazonaws.com" }
    }]
  })
}

resource "aws_iam_role_policy" "eval_s3_access" {
  role = aws_iam_role.eval_lambda.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect   = "Allow"
      Action   = ["s3:GetObject", "s3:PutObject"]
      Resource = "${aws_s3_bucket.eval_data.arn}/*"
    }]
  })
}

# --- Lambda関数（評価実行） ---
resource "aws_lambda_function" "eval_runner" {
  filename      = "eval_lambda.zip"
  function_name = "mmteb-eval-runner"
  role          = aws_iam_role.eval_lambda.arn
  handler       = "handler.evaluate"
  runtime       = "python3.12"
  timeout       = 900
  memory_size   = 10240

  environment {
    variables = {
      EVAL_BUCKET = aws_s3_bucket.eval_data.id
      CACHE_TABLE = aws_dynamodb_table.eval_cache.name
    }
  }
}

# --- DynamoDB（評価結果キャッシュ） ---
resource "aws_dynamodb_table" "eval_cache" {
  name         = "mmteb-eval-cache"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "model_task_hash"

  attribute {
    name = "model_task_hash"
    type = "S"
  }

  ttl {
    attribute_name = "expire_at"
    enabled        = true
  }
}

Large構成（Container）: EKS + Karpenter + GPU Spot

module "eks" {
  source          = "terraform-aws-modules/eks/aws"
  version         = "~> 20.0"
  cluster_name    = "mmteb-eval-cluster"
  cluster_version = "1.31"
  vpc_id          = module.vpc.vpc_id
  subnet_ids      = module.vpc.private_subnets

  cluster_endpoint_public_access = true
  enable_cluster_creator_admin_permissions = true
}

resource "kubectl_manifest" "karpenter_gpu_provisioner" {
  yaml_body = <<-YAML
    apiVersion: karpenter.sh/v1alpha5
    kind: Provisioner
    metadata:
      name: gpu-spot-provisioner
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot"]
        - key: node.kubernetes.io/instance-type
          operator: In
          values: ["g5.xlarge", "g5.2xlarge"]
      limits:
        resources:
          cpu: "32"
          memory: "128Gi"
          nvidia.com/gpu: "4"
      ttlSecondsAfterEmpty: 60
  YAML
}

resource "aws_budgets_budget" "eval_monthly" {
  name         = "mmteb-eval-monthly"
  budget_type  = "COST"
  limit_amount = "5000"
  limit_unit   = "USD"
  time_unit    = "MONTHLY"

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 80
    threshold_type             = "PERCENTAGE"
    notification_type          = "ACTUAL"
    subscriber_email_addresses = ["ops@example.com"]
  }
}

セキュリティベストプラクティス

• IAMロール: 最小権限の原則。S3バケットへのアクセスはPutObject/GetObjectのみに制限
• ネットワーク: EKSの場合、cluster_endpoint_public_access = false を本番で設定（VPN経由）
• シークレット管理: APIキー（Voyage, OpenAI等）はSecrets Managerに保存、環境変数ハードコード禁止
• 暗号化: S3はKMS暗号化、DynamoDBは保管時暗号化を有効化
• 監査: CloudTrail有効化、評価実行ログの長期保存

運用・監視設定

-- CloudWatch Logs Insights: 評価ジョブの異常検知
fields @timestamp, model_name, task_name, duration_ms, ndcg_score
| stats avg(duration_ms) as avg_duration, count() as eval_count by bin(1h)
| filter avg_duration > 300000

import boto3

cloudwatch = boto3.client('cloudwatch')
cloudwatch.put_metric_alarm(
    AlarmName='mmteb-eval-duration-spike',
    ComparisonOperator='GreaterThanThreshold',
    EvaluationPeriods=1,
    MetricName='Duration',
    Namespace='MMTEB/Evaluation',
    Period=3600,
    Statistic='Average',
    Threshold=600000,
    AlarmDescription='評価ジョブの実行時間が10分超過'
)

コスト最適化チェックリスト

アーキテクチャ選択:

• 週1回評価 → Lambda + S3（$50-150/月）
• 日次評価 → SageMaker Processing（$400-900/月）
• CI/CD連携 → EKS + Spot GPU（$2,000-5,000/月）

リソース最適化:

• GPU Spot Instances優先（最大90%削減）
• MMTEBの効率的サブセット使用（タスク数90%削減）
• 評価結果キャッシュ（DynamoDB TTL）で重複計算回避
• SageMaker Managed Spot Trainingで70%削減
• アイドルタイムのスケールダウン（Karpenter ttlSecondsAfterEmpty）

監視・アラート:

• AWS Budgets: 月額予算設定
• CloudWatch アラーム: 評価時間スパイク検知
• Cost Anomaly Detection: 自動異常検知
• 日次コストレポート: SNS/Slackへ自動送信

リソース管理:

• 未使用GPUインスタンス削除
• S3ライフサイクルポリシー: 古い評価結果を30日でGlacierに移行
• タグ戦略: 環境別（dev/staging/prod）でコスト可視化

実運用への応用（Practical Applications）

MMTEBの知見は、Zenn記事で紹介した自社データ評価パイプラインの設計に直接活用できる。

効率的サブセットの活用: 500+タスクのフルベンチマークではなく、自社ドメインに関連するタスクのみを選択して評価することで、計算コストを90%削減しつつ信頼性の高い比較が可能である。Zenn記事で紹介した InformationRetrievalEvaluator での評価と組み合わせて、公開ベンチマークスコアと自社データスコアの乖離を定量化することが推奨される。

モデル選定への示唆: MMTEBの結果は「モデルサイズが多言語性能に強く相関する」ことを示しており、日本語RAGシステムにおいても7B級モデル（Qwen3-Embedding-8Bなど）が有利である可能性を示唆している。ただし、APIコストとのトレードオフを考慮し、PLaMo-Embedding-1B（1Bパラメータ、JMTEB日本語1位）のような効率モデルも候補に含めるべきである。

関連研究（Related Work）

• MTEB（Muennighoff et al., 2022, arXiv:2210.07316）: MMTEBの前身。8タスク・58データセット・112言語で33モデルを評価し、単一最良モデルが存在しないことを示した基礎的ベンチマーク
• mMTEB（Engel et al., 2024, arXiv:2407.21647）: MTEBの多言語拡張版。200以上の言語を対象としたが、言語特化モデルが多言語モデルを上回るケースを報告
• BEIR（Thakur et al., 2021）: ゼロショット検索ベンチマーク。ドメイン外汎化能力の評価に特化しており、MMTEBのRetrievalタスク設計に影響を与えた

まとめと今後の展望

MMTEBは、テキスト埋め込みモデルの多言語評価における重要な前進である。500+タスク・250+言語の規模は従来のベンチマークを大幅に上回り、低資源言語の評価にも対応した。主な知見として、SOTAがモデルサイズに強く依存する点、効率的サブセットでフルベンチマークの97%以上の信頼性を維持できる点が報告されている。実務では、効率的サブセットと自社データ評価を組み合わせることで、コスト効率の高いモデル選定が可能となる。今後の展開としてはマルチモーダル評価（MrMTEB, arXiv:2501.09925）や、ドメイン特化ベンチマーク（MTEB-Legal等）との統合が期待される。

参考文献

• arXiv: https://arxiv.org/abs/2502.13595
• Code: https://github.com/embeddings-benchmark/mteb
• MTEB原論文: https://arxiv.org/abs/2210.07316
• Related Zenn article: https://zenn.dev/0h_n0/articles/db325cb1cb2e24