🧠
RAG検索時に過去履歴を読み込ませるべきか？開発中のAIチャットから得た最適解
はじめに
現在、私はRAG（Retrieval-Augmented Generation）を活用したAIチャットシステムを開発しています。
目的は、ユーザの質問に対して高精度な回答を返しつつ、コストを最小限に抑えること。
その中で直面した課題が──
🔍 「RAG検索時に過去の会話履歴をどこまで読み込ませるべきか？」
でした。
本記事では、私が実際に試行錯誤した結果たどり着いた実践的な最適解を、
コスト面・精度面・実装面の観点からまとめます。
RAG検索における「過去履歴」の役割
RAGは「検索＋生成」を組み合わせたアプローチで、
クエリ（質問）をもとに知識ベースから関連情報を検索し、回答を生成します。
このとき、チャット形式のシステムでは以下のようなケースが頻発します：
ユーザ：「それってどうやるの？」
AI：「どれのことを指していますか？」
こうした曖昧な質問を適切に解釈するには、過去の会話履歴を参照して質問意図を補完する必要があります。
つまり、履歴を読み込ませるかどうかは、文脈理解の精度に直結します。
履歴を全て読み込ませるとどうなるか？
一見、「すべての履歴を読み込ませれば、文脈が完全にわかるから良いのでは？」と思いがちです。
しかし、実際には以下の問題が発生します。
🧱 トークンコストが増加
- 履歴が長くなるほど、入力トークン数が膨らむ
- Azure OpenAI（GPT-4o）の場合、入力1,000トークンあたり約$0.005のコスト
- 会話が長引くほどコストが雪だるま式に増える
🎯 文脈のノイズ化
- 古い履歴は、現在の質問に無関係なノイズになることが多い
- モデルが「どの情報を優先すべきか」迷い、リライト精度が低下
🐢 レイテンシ増加
- 入力サイズが大きいと、応答までの処理時間も増加
実際に試した構成
私は以下の2パターンで検証しました。
❌ パターンA：全履歴を読み込ませる
- メリット：一貫した文脈把握
- デメリット：コスト増・応答遅延・リライトの精度低下
✅ パターンB：直近3ラリー分のみ読み込ませる
- メリット：必要十分な文脈 + トークン削減
- デメリット：まれに古い履歴を参照したいケースが発生
- 結果：最も精度とコストのバランスが取れた
採用したアプローチ
結論として、現在のシステムでは以下の構成を採用しました。
🧩 構成概要
-
フェーズ① クエリリライト（gpt-4o-mini）
- 直近3ラリー分の履歴＋最新質問を入力
- 質問を明確化・具体化する
-
フェーズ② ベクトル検索
- リライト後のクエリでベクトル検索を実行
-
フェーズ③ 応答生成（gpt-4o）
- 検索結果と質問をもとに回答生成
💰 コスト最適化
- リライトには軽量モデル gpt-4o-mini を使用
- 出力は短文なので高精度モデルは不要
- コスト増加は全体の 約10〜15%以内
⚡ レイテンシ
- 追加リクエスト1回分（約0.5秒前後）の増加
- UXに影響しない範囲
実装イメージ（LangChain）
rewrite_llm = ChatOpenAI(model="gpt-4o-mini", temperature=0.2)
answer_llm = ChatOpenAI(model="gpt-4o", temperature=0.3)
# クエリリライト
rewrite_prompt = f"""
以下は会話履歴とユーザの質問です。
履歴を踏まえ、検索に適した質問文に書き換えてください。
【履歴】:
{recent_history}
【質問】:
{user_question}
"""
rewritten_query = rewrite_llm.invoke(rewrite_prompt)
# ベクトル検索 + 応答生成
docs = retriever.get_relevant_documents(rewritten_query)
final_answer = answer_llm.invoke(f"以下の文書を参考に質問に回答してください。\n\n{docs}\n\n質問: {rewritten_query}")
まとめ
| 項目 | 方針 | 理由 |
|---|---|---|
| 履歴参照 | 直近3ラリー分 | 必要十分な文脈 + ノイズ削減 |
| クエリリライト | 実施（別フェーズ） | 検索精度を最大化 |
| モデル | リライト: gpt-4o-mini / 回答: gpt-4o | コスト最適化 |
| 構成 | 2フェーズ構成 | 精度・速度・コストのバランスが良い |
🎯 結論：直近3ラリーを gpt-4o-mini でリライト → gpt-4o で RAG 応答
コストと精度を両立する最適構成。
RAGシステムでは「検索精度の向上」＝「コスト増」になりがちですが、
リライト + 直近履歴限定 というアプローチを取ることで、
精度・速度・コスト のバランスを比較的高いレベルで実現できました。
RAG制度に関しては今後も考察を続けていきたいです。
Discussion