OpenAI の RAG 戦略を LangChain で実装する方法

コンテキスト

OpenAI はデモデイで、顧客との共同プロジェクトにおける一連の RAG（Retrieval-Augmented Generation）実験の結果を報告しました。評価指標はアプリケーションごとに異なりますが、彼らの成功事例と課題から何を学べるかは非常に興味深いです。以下では、言及された各手法の詳細を解説し、実際にどのように実装できるかを示します。多くのパートナーやユーザーとの対話を通じて得られた知見として重要なのは、「万能な解決策」は存在しないということです。異なる問題には、それぞれに適した検索技術が必要なのです。

RAG ストックにおける位置づけ

まず、これらの手法をいくつかの RAG カテゴリに分類することができます。以下の図は、各 RAG 実験がどのカテゴリに属し、RAG ストック（スタック）のどこに位置するかを示しています：

ベースライン

ベクトルデータベースの距離ベース検索では、クエリを高次元空間に埋め込み（embed）、その「距離」に基づいて類似した文書を検索します。OpenAI の研究で用いられた基本的な検索手法はコサイン類似度でした。LangChain には 60 以上 のベクトルストア統合があり、その多くで類似性検索に使用する距離関数を設定できます。各種の距離指標に関する有用なブログ記事は、Weaviate や Pinecone から読むことができます。

クエリ変換

しかし、クエリの wording の微妙な違いや、埋め込みがデータの意味を十分に捉えられていない場合などにより、検索結果は異なるものになることがあります。クエリ変換とは、検索精度を向上させるためにユーザー入力を修正する一連のアプローチです。このトピックに関する最近のブログ記事は こちら でご覧ください。

OpenAI が報告した 2 つの方法があり、ぜひ試してみてください：

クエリ拡張：LangChain の Multi-query retriever は、LLM を活用してユーザーの入力クエリに対して多角的な複数のクエリを生成することでクエリ拡張を実現します。各クエリごとに関連するドキュメントセットを取得し、すべてのクエリにわたるユニークな結果の和集合を返します。

HyDE：LangChain の HyDE（Hypothetical Document Embeddings） retriever は、入力されたクエリに対して疑似ドキュメントを生成し、これを埋め込んだ上で検索に利用します（詳細は 論文 を参照）。この手法の狙いは、質問そのものよりも、こうしたシミュレーションされたドキュメントの方が目的とする元資料との類似度が高くなる可能性がある点にあります。

検討すべき他のアイデア:

• Step back prompting: 推論タスクにおいては、この論文で示されているように、ステップバック質問（step-back question）を用いて、回答合成をより高次の概念や原理に根付かせる手法が有効です。例えば、物理学に関する問いは、ユーザーのクエリ背後にある物理法則についての抽象的な問いと答えへと昇華させることができます。最終的な回答は、入力された質問自体と、ステップバックによって得られた回答の両方から導き出されます。詳細については、このブログ記事や、LangChain の実装例をご覧ください。

• Rewrite-Retrieve-Read: この論文では、検索精度を向上させるためにユーザーの質問を書き換える手法が提案されています。詳細は LangChain の実装例 をご覧ください。

ルーティング

複数のデータストアを横断してクエリを実行する際、適切なソースへ質問をルーティングすることが極めて重要です。OpenAI の発表では、2 つのベクトルストアと 1 つの SQL データベースの間で質問を振り分ける必要性が指摘されました。LangChain では、LLM を活用してユーザー入力を定義されたサブチェーン（このケースでは異なるベクトルストアなど）にゲートする機能を提供しています。

インデックス構築

OpenAI は、ドキュメントの埋め込み時にチャンクサイズを実験しただけでパフォーマンスが顕著に向上したと報告しています。これはインデックス構築の中核となるステップであるため、チャンクサイズをテストできるオープンソースの Streamlit アプリを用意しました。

Streamlit app でお試しください。

埋め込みモデルの微調整では性能が大幅に向上したという報告はありませんでしたが、好ましい結果は得られています。OpenAI はこれを「低垂れ果実（容易な成果）」ではないとして推奨していないものの、LangChain では 微調整のガイド を提供しており、HuggingFace にはさらに詳しく解説した 非常に良いチュートリアル や 他の資料 も多数あります。

後処理

検索後のドキュメントを LLM が読み込む前に加工する「後処理」は、多くのアプリケーションで重要な戦略です。これにより、取得したドキュメント間の多様性や最新性を確保できます。特に複数のソースから情報を集める場合、この手法は極めて有効です。

OpenAI は以下の 2 つの方法を報告しています:

リランク（Re-rank）: LangChain は Cohere ReRank エンドポイントと連携しており、大量の文書を取得する際に冗長性を削減してドキュメントを圧縮するための手法として利用できます。同様に、RAG-fusion では再帰的ランク融合（reciprocal rank fusion）を採用し、検索エンジンから返された結果をリランクします。これは前述したマルチクエリ手法に似たアプローチです。

分類（Classification）: OpenAI は取得した各ドキュメントの内容に基づいて分類を行い、その分類結果に応じて異なるプロンプトを選択します。この手法は 2 つのアイデアを組み合わせたものです。1 つ目は LangChain がテキストのタグ付けをサポートしている点で、関数呼び出しを用いて出力スキーマを強制することで分類を実現できます。

上記のように、論理ルーティングはタグに基づいてリダイレクトする際にも活用できます。また、論理ルーティングチェーン自体に意味的なタグ付けのプロセスを組み込むことも可能です。

検討すべき他のアイデア:

• MMR: 関連性と多様性のバランスを取るため、多くのベクトルストアで最大マージナル・リレバンス 検索が提供されています（詳細はこちらのブログ記事をご覧ください）。
• クラスタリング: 一部の手法では、埋め込まれた文書のクラスタリングにサンプリングを組み合わせるアプローチが採用されており、多様なソースからの文書を統合する必要がある場合に有効です。

結論

OpenAI が RAG（Retrieval-Augmented Generation）の分野で試みてきた取り組みを知ることは示唆に富んでいます。上記のように、これらのアプローチは実際に再現可能です。異なる手法を試すことが極めて重要なのは、RAG の設定によってアプリケーションのパフォーマンスが大きく変動する可能性があるからです。

しかし、OpenAI の結果からも明らかなように、評価は非常に重要です。評価を行わないと、ほとんどあるいは全く効果のないアプローチに時間と労力を費やすことになりかねません。RAG（Retrieval-Augmented Generation）の評価においては、LangSmith が強力なサポートを提供しています。例えば、LangChain の公式 GitHub リポジトリにある cookbook では、LangSmith を活用して複数の高度な RAG チェーンを評価する方法が紹介されています。

関連コンテンツ

オープンソース

エージェントアーキテクチャ

ディープエージェント

ディープエージェント vs LangChain vs LangGraph

Sydney Runkle 著

2026 年 8 月 6 日

読了時間 8 分

エージェントアーキテクチャ

AI エージェントとは何か？

Jess Ou 著

2026 年 7 月 31 日

読了時間 9 分

ディープエージェント

オープンソース

エージェントアーキテクチャ

Deep Agents v0.7

シンディ・ランクル

2026 年 7 月 29 日

6 分

エージェントの実際の動作を確認する

エージェントエンジニアリングプラットフォーム「LangSmith」を使えば、開発者は各エージェントの意思決定をデバッグしたり、変更の評価を行ったり、ワンクリックでデプロイしたりできます。