RAGの検索精度を3軸で測ったら最適解が条件で全く変わった

RAGの検索精度を3軸で測ったら最適解が条件で全く変わった RAG（Retrieval-Augmented Generation）を組むとき、embeddingモデル・検索アルゴリズム・チャンクサイズの3つを「なんとなく」で選んでいないだろうか。 「BGE-M3が安定」「ベクトル検索で十分」「チャンクは500-1000文字」。よく見るアドバイスだ。しかし、この3軸を日本語テクニカルコーパスで実測したら、デフォルト設定の落とし穴が見えてきた。 E5-small（384次元）がBGE-M3（1024次元）より高品質で9倍速い。BM25は形態素解析を入れるだけでJ-Mean@3が5.50→8.97に跳ね上がり、300文字チャンクが600文字・1200文字に圧勝した。 最大のインパクトは「アルゴリズムの選択」ではなく、「日本語トークナイザが壊れていた」という基盤の問題だった。この記事では実測データを全て公開した上で、あなたの条件に合った構成の選び方を整理する。 実験の設計 コーパス 日本語テクニカル記事（Zenn/Qiita）217件から生成した約1,500チャンク。AI・半導体・ハードウェア領域の技術記事が中心。英語コンテンツは含まない。 評価方法: Judge-based 検索結果の品質をLLMジャッジ（mmarco multilingual cross-encoder）が10点スケールで評価する。従来のrecall/precisionではなく、「検索されたチャンクが質問に対してどれだけ有用か」を直接測る。 主要指標: J-MRR（Judge Mean Reciprocal Rank）: 最も関連性の高い結果が上位に来ているか J-Mean@k: 上位k件の平均品質スコア（10点満点） High-hit@k: 高品質チャンクがk件中に含まれる確率 3班分離 パイプライン（検索実行）・ジャッジ（品質評価）・分析（統計処理）を分離し、評価バイアスを抑制した。 軸1: Embeddingモデル — 小さい方が速くて品質も高かった 4つのembeddingモデルを同一コーパス・同一クエリで比較した。 モデル 次元 J-Mean@3 NDCG@3 速度 (texts/s) 埋め込み時間 E5-small 384 9.03 0.929 234 6.5秒 E5-large 1024