海外の技術フォーラム Reddit の r/Rag に、こんな相談が投稿されていました。
大量の文書をRAGに載せようとしている人には、示唆に富む内容でした。
相談者の状況は、かなり具体的です。
- 科学論文のPDFが約1万7000件、容量は25GB
- 分野は脱塩、化学、膜、工学
- ベクトルDBはQdrant
- 検索はdenseとBM25のハイブリッド、その後にクロスエンコーダで再ランキング
- 回答生成はGemini 2.5 Flash
- チャンクは250語前後でオーバーラップあり
- 画像と表は別途抽出
埋め込みモデルには、OpenAI の text-embedding-3-large を使っています。
ただし、全件をインデックスする前に決めきりたい。
なぜなら、後から変えると全部やり直しになるからです。
なぜ「後で変えればいい」が通用しないのか
埋め込みモデルを差し替えると、ベクトルが置かれる意味空間そのものが変わります。
古いベクトルと新しいクエリのベクトルを突き合わせても、比較として成立しません。
つまり、全件を再計算するしかないのです。
1万7000件のPDFとなると、時間もコストも軽くはありません。
だから相談者は慎重になっています。
この判断は、理にかなっていると言えるでしょう。
最初の反応は「そもそも変える必要があるのか」
最も支持を集めたコメントは、モデル比較の話ではありませんでした。
いま検索が失敗しているという明確な証拠がない。
それなら、既存のパイプラインを維持するほうが安全だ、という指摘です。
再インデックスは重い作業になります。
そして、精度がボトルネックだと確認できていない段階で踏み切る理由はありません。
これに対して相談者は、まだ本格的なインデックスを始めていないと返しています。
一部はテスト用とのこと。
つまり、後戻りできない状態ではなかったわけです。
とはいえ、この視点は覚えておく価値があります。
モデルを変えたい欲求が先に立つと、測定を飛ばしてしまいがちですから。
「ランキングではなく自分のデータで測れ」
議論全体を貫いていたのは、この一点でした。
MTEBのような汎用ベンチマークは、学術論文コーパスでの挙動を保証しません。
実際、学術PDFに特化した公開ベンチマークは見当たらない。
複数のコメントが、そう述べていました。
代わりに提案されたのは、地味な手作業です。
まず、自分の論文から実際のクエリを50件ほど集める。
膜の名称、DOI、具体的な数値など、現場で本当に投げる質問を選びます。
それでrecall@10を測り、候補モデルを並べるわけです。
あるコメントは、この作業を退屈きわまりないと認めていました。
しかし、後から失う何十時間かを先に救ってくれるとも書いています。
私も同感です。
BM25のベースラインを先に取る
見落とされがちな指摘もありました。
化学物質名、数値、膜の型番、DOI。
この手の文字列は、語彙的な検索がめっぽう強い分野です。
あるコメントは、Elasticsearchの素のBM25を自前のクエリで走らせてみることを勧めていました。
埋め込みモデルを取り替えるより効くかもしれない。
BM25とdenseと再ランキングの組み合わせを詰めるほうが、結果的に近道だという経験談です。
別のコメントも、技術文書には字句検索を加えた三系統のハイブリッドが効くと述べています。
埋め込みモデルは、検索パイプラインの一要素にすぎません。
そこだけ磨いても、全体は動かないという話でしょう。
モデル選びの意見は、きれいに割れた
肝心の「どれを選ぶか」については、合意がありませんでした。
text-embedding-3-large を推す側の論拠は、実績とエコシステムの安定性です。
他の候補は興味深い。
しかし、学術コーパスでの検証結果が公開されていません。
乗り換えの痛みが大きい以上、最初に堅い選択をしておくべきだ、という主張でした。
一方で、オープンウェイトの bge-m3 を推すコメントもありました。
専門的な語彙に強く、ローカルでもクラウドでも動かせる。
だからベンダーロックインを避けられる、という理屈です。
ただし、これは自分のテスト環境での感触という但し書き付きでした。
公開ベンチマークの裏付けが示されたわけではありません。
このほか、Voyage、Cohere、Gemini の埋め込みモデルも名前が挙がっています。
図表が多いならマルチモーダル対応を検討すべき、という声も出ていました。
意見が割れたこと自体が、ひとつの答えでもあります。
誰かの結論を借りてくるのではなく、自分のコーパスで並べて測るしかありません。
なお、埋め込みの次元数やインデックス速度は、Transformer系エンコーダ間で大きく変わらないという指摘もありました。
そうであれば、比較の軸は検索品質とドメイン適合に絞られます。
移行を安くする設計
技術的に一番参考になったのは、この提案でした。
ベクトルの隣に、生成に使った埋め込みモデル名を保存しておく。
あわせて、チャンク分割時のパラメータも記録します。
そして、クエリ側では正しいモデルで作られたベクトルかどうかを照合するのです。
こうしておけば、モデルの入れ替えや実験が技術的には単純な作業になります。
計算コストが消えるわけではありません。ただ、「怖くて触れない」状態からは抜け出せます。
同じコメントは、こうも付け加えていました。パイプラインが手作業の調整なしで安定して回ること。そちらのほうが大事だ、と。
本当の難所は別にある
最後に、視点を引き戻すコメントを紹介します。
PDFから本文をきれいに取り出すこと。
そして、検索結果を評価できるQ&Aの仕組みを組み立てること。
この2つが最大のボトルネックであり、埋め込みモデルの優劣はパズルの小さな一片にすぎない、という指摘でした。
学術文書の処理については、Allen AIの既存成果を見てから動いたほうがいいとも書かれています。
品質を上げる具体策としては、チャンクに文脈を持たせる手法が挙がりました。
各チャンクの末尾に、その文書が何を扱っているかの要約を添えるやり方です。
参照先として、Anthropicが公開しているcontextual retrievalの記事も示されていました。
まとめ
大量の文書をRAGに載せる作業では、埋め込みモデルの選定が最初の関門に見えます。
しかし議論の中身は、モデル名の比較にほとんど費やされませんでした。
焦点は、いつも同じところに戻ってきます。
- 自分のデータで測ったか
- 字句検索のベースラインを取ったか
- 後から乗り換えられる設計になっているか
- PDFのパースは信用できるか
ベンチマークの順位表は出発点であって、答えではありません。
実クエリを50件書き出すところから始める。
遠回りに見えて、それが一番速い道かもしれません。
再インデックスを恐れる気持ちは、よく分かります。
ただ、恐れを消す方法は「完璧な最初の一手」ではないのでしょう。
「やり直せる構造」を先に作っておくこと。
そちらのほうが、たぶん効きます。
