LangChainによるRAG実装 LLMアプリ開発が変わる

大規模言語モデル（LLM）の登場は、アプリケーション開発の世界に革命をもたらしました。OpenAIのGPTシリーズやGoogleのGeminiのような強力なモデルは、これまで不可能だったレベルの自然言語処理能力を開発者に提供しています。しかし、これらの汎用モデルをそのまま利用するだけでは、すぐに限界に突き当たります。具体的には、「最新の情報に追随できない」「社内文書のようなプライベートなデータは扱えない」「平気で嘘をつく（ハルシネーション）」といった課題です。これらの課題は、LLMをビジネスの現場で本格的に活用する上での大きな障壁となっています。

この記事では、そうしたLLMの限界を突破する強力な技術であり、現代のLLMアプリケーション開発における新たな常識となりつつあるRAG（Retrieval-Augmented Generation / 検索拡張生成）について、フルスタック開発者の視点から徹底的に解説します。さらに、RAGの実装を劇的に簡素化し、開発を加速させるフレームワークLangChainを用いて、実際に手を動かしながらRAGアプリケーションを構築する全プロセスを、ステップバイステップでご紹介します。単なるチュートリアルに留まらず、なぜこの技術が必要なのか、各コンポーネントがどのように連携するのか、そして実運用を見据えた高度なテクニックまで、深く掘り下げていきます。この記事を読み終える頃には、あなたも自信を持って独自のデータに基づいた高精度な生成AIアプリケーションを開発できるようになっているでしょう。

RAG（検索拡張生成）とは何か？LLMの限界を超える技術

RAG（Retrieval-Augmented Generation）を理解するために、まずはLLMがどのように回答を生成するかを考えてみましょう。標準的なLLMは、まるで「頭の中にある知識だけでテストを受ける学生」のようなものです。事前学習で得た膨大な知識をもとに質問に答えますが、学習データに含まれていない最新の出来事や、特定の企業が持つ内部情報については全く知りません。そのため、知らないことを聞かれると、それらしい嘘（ハルシネーション）を生成してしまうことがあります。

一方、RAGはLLMを「参考資料の持ち込みが許可されたテストを受ける学生」に変身させる技術です。質問が与えられた際、まずその質問に関連する情報を外部の知識ソース（例えば、PDFドキュメント、データベース、ウェブサイトなど）から検索（Retrieval）します。そして、検索してきた関連情報を「参考資料」として元の質問文と一緒にLLMに渡します。LLMは、その場で与えられた参考資料を基に回答を生成（Generation）するため、より正確で、事実に即した、そして具体的な根拠のある回答を返すことができるようになるのです。

このアーキテクチャは、大きく分けて2つの主要コンポーネントで構成されます。

  1. Retriever（検索器）: ユーザーの質問（クエリ）を受け取り、それと関連性の高い情報を外部の知識ソースから見つけ出す役割を担います。この「検索」の精度が、RAGシステム全体の性能を大きく左右します。一般的には、テキストをベクトル化して類似度を計算する「ベクトル検索」という技術が用いられます。
  2. Generator（生成器）: Retrieverが見つけてきた情報（コンテキスト）と元の質問を組み合わせて、最終的な回答を生成するLLM本体です。GPT-4やGemini Proなどがこれにあたります。
RAGがもたらす主要なメリット
  • ハルシネーションの抑制: 外部の事実に基づいた情報を参照するため、LLMが不正確な情報を生成する可能性を大幅に低減できます。
  • 知識の拡張と更新: LLM自体を再学習させることなく、外部の知識ソースを更新するだけで、最新の情報や独自のデータに対応できます。これはコストと時間の面で非常に大きな利点です。
    • - 透明性と信頼性の向上: 回答の根拠となった情報ソースをユーザーに提示できるため、「なぜこの回答になったのか」を検証可能です。これにより、アプリケーションへの信頼性が格段に向上します。

このように、RAGは既存の生成AIモデルの能力を飛躍的に向上させ、より実用的で信頼性の高いアプリケーション開発を可能にする、まさにゲームチェンジャーと言える技術なのです。

なぜLangChainなのか？RAG実装を加速させるフレームワーク

RAGの概念はシンプルですが、いざ自力で実装しようとすると、多くの複雑な処理が必要になることに気づきます。データの読み込み、適切なサイズへの分割、ベクトル変換（Embedding）、ベクトルデータベースへの保存、検索ロジックの実装、LLMへの入力（プロンプト）の整形、APIの呼び出し...。これらの処理を一つ一つコーディングするのは非常に手間がかかり、エラーの温床にもなりかねません。

ここで登場するのがLangChainです。LangChainは、LLMを中心としたアプリケーション開発を円滑に進めるための、いわば「接着剤」や「オーケストレーションツール」の役割を果たすオープンソースフレームワークです。RAGを構成する一連の処理を、再利用可能な「コンポーネント」として抽象化し、それらを鎖（Chain）のようにつなぎ合わせることで、複雑なパイプラインを驚くほどシンプルに構築できます。

LangChainが提供する主要なコンポーネントは、RAGのアーキテクチャに完璧に対応しています。

  • Document Loaders: PDF、CSV、Textファイル、Webページ、Notionなど、様々な形式のデータソースからドキュメントを読み込むためのモジュールです。
  • Text Splitters: 読み込んだドキュメントを、LLMが処理しやすいように、またベクトル検索に適したサイズに分割（チャンク化）します。
  • Embeddings: 分割したテキストチャンクを、意味的な類似度を計算できる数値ベクトルに変換します。OpenAIやHugging Faceなど、様々なEmbeddingモデルとの連携が可能です。
  • Vector Stores: 生成されたベクトルを効率的に保存し、高速な類似度検索を可能にするデータベースです。FAISS, Chroma, Pineconeなど多くの選択肢をサポートしています。
  • Retrievers: Vector Storeに対して、与えられたクエリと類似度の高いドキュメントを検索するインターフェースを提供します。
  • Chains: これら全てのコンポーネントとLLMを連結し、一連の処理フロー（例えば、質問を受け取ってからRAGによる回答を返すまで）を定義します。RetrievalQA Chainは、まさにRAGのための代表的なChainです。

LangChainを使うことのメリットを、ゼロから実装する場合と比較してみましょう。

評価項目 ゼロから実装 (From Scratch) LangChainを利用
開発速度 遅い。各コンポーネントの仕様調査と実装に時間がかかる。 非常に速い。数行のコードでパイプラインを構築可能。
コードの複雑さ 高い。データ処理、API連携、エラーハンドリングなどを全て自前で管理。 低い。抽象化されたインターフェースにより、本質的なロジックに集中できる。
拡張性・保守性 低い。LLMやベクトルDBを変更する際に大幅なコード修正が必要。 高い。コンポーネントを差し替えるだけで、LLMやDBを容易に変更可能。
機能性 基本的な機能は実装できるが、高度な機能（Agent, Tool連携など）は困難。 豊富。RAGだけでなく、Agent機能やカスタムツール連携など、幅広い機能が提供されている。
コミュニティ 限定的。問題解決は自己責任。 活発。ドキュメントが豊富で、多くの事例やサポートが得られる。

結論として、プロトタイピングから本番運用まで、LLMアプリケーション開発、特にRAGの実装においてLangChainを利用しない手はありません。開発者は煩雑な実装詳細から解放され、より価値の高い、アプリケーションのコアロジックやユーザー体験の向上に集中することができるのです。

実践！LangChainでRAGアプリケーションを構築する

それでは、いよいよLangChainを使って、実際にRAGアプリケーションを構築していきます。ここでは、ローカルにあるテキストファイルを知識ソースとして、それに関する質問に答えるシンプルなQ&Aシステムを作成します。このプロセスを通じて、前述した各コンポーネントが実際にどのように機能するのかを具体的に理解できるはずです。

Step 1: 環境構築

まず、プロジェクトに必要なライブラリをインストールします。Python 3.9以上がインストールされている環境を想定しています。


# LangChainのコアライブラリ
pip install langchain

# OpenAIのLLMとEmbeddingモデルを使用するためのライブラリ
pip install langchain-openai

# テキスト分割のためのトークン計算ライブラリ
pip install tiktoken

# ドキュメントローダーが依存するライブラリ
pip install unstructured

# ベクトルストアとして使用するFAISSのCPU版
pip install faiss-cpu

次に、OpenAIのAPIキーを設定します。OpenAIのウェブサイトでアカウントを作成し、APIキーを取得してください。取得したキーは環境変数として設定するのが安全で推奨される方法です。


export OPENAI_API_KEY="sk-..."

もし環境変数の設定が難しい場合は、Pythonコード内で直接指定することも可能ですが、キーがコードにハードコーディングされるため、Gitなどで公開しないように細心の注意が必要です。

Step 2: データの準備と読み込み (Document Loading)

RAGの知識ソースとなるデータを用意します。今回は、日本の有名な文学作品である『吾輩は猫である』の冒頭部分をテキストファイル（neko.txt）として保存し、これを使用します。

neko.txt:

吾輩わがはいは猫である。名前はまだ無い。
どこで生れたかとんと見当けんとうがつかぬ。何でも薄暗いじめじめした所でニャーニャー泣いていた事だけは記憶している。吾輩はここで始めて人間というものを見た。しかもあとで聞くとそれは書生という人間中で一番獰悪どうあくな種族であったそうだ。この書生というのは時々我々を捕つかまえて煮にて食うという話である。しかしその当時は何という考もなかったから別段恐しいとも思わなかった。ただ彼の掌てのひらに載せられてスーと持ち上げられた時何だかフワフワした感じがあったばかりである。
掌の上で少し落ちついて書生の顔を見たのがいわゆる人間というものの見始みはじめであろう。この時妙なものだと思った感じが今でも残っている。第一毛をもって装飾されべきはずの顔がつるつるしてまるで薬缶やかんだ。その後ご猫にもだいぶ逢あったがこんな片輪かたわには一度も出会でくわした事がない。のみならず顔の真中が余りに突起している。そうしてその穴の中から時々ぷうぷうと煙けむりを吹く。どうも咽むせぽくて実に弱った。これが人間の飲む煙草たばこというものである事はようやくこの頃知った。

このテキストファイルをLangChainのTextLoaderを使って読み込みます。


from langchain_community.document_loaders import TextLoader

# ドキュメントローダーの初期化
loader = TextLoader("neko.txt", encoding="utf-8")

# ドキュメントの読み込み
documents = loader.load()

# 読み込んだ内容の確認
print(f"ドキュメント数: {len(documents)}")
print("--- ドキュメントのメタデータ ---")
print(documents[0].metadata)
print("--- ドキュメントの内容（先頭100文字） ---")
print(documents[0].page_content[:100])

実行すると、1つのドキュメントが読み込まれ、メタデータ（ソースファイル名）と内容が確認できます。Documentオブジェクトは、page_content（テキスト本体）とmetadata（ソースなどの付随情報）の2つの属性を持つLangChainの標準的なデータ構造です。

Step 3: テキストの分割 (Text Splitting)

読み込んだドキュメントは、多くの場合、LLMのコンテキストウィンドウ（一度に処理できるトークン数）には長すぎます。また、ベクトル検索の観点からも、意味のある単位で小さなチャンクに分割する方が、検索精度が向上します。ここではRecursiveCharacterTextSplitterを使用します。これは、まず改行（\n\n）で分割を試み、それでもチャンクが大きすぎる場合は次に改行（\n）、次にスペース（ ）、というように再帰的に分割を試みる賢いスプリッターです。


from langchain.text_splitter import RecursiveCharacterTextSplitter

# テキストスプリッターの初期化
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=200,  # 各チャンクの最大サイズ
    chunk_overlap=20,  # チャンク間のオーバーラップ
    length_function=len,
    is_separator_regex=False,
)

# ドキュメントをチャンクに分割
split_documents = text_splitter.split_documents(documents)

print(f"分割後のチャンク数: {len(split_documents)}")
print("--- 1つ目のチャンク ---")
print(split_documents[0].page_content)
print("--- 2つ目のチャンク ---")
print(split_documents[1].page_content)

chunk_sizeでチャンクのおおよそのサイズを指定し、chunk_overlapでチャンク間に重なりを持たせます。オーバーラップを設定することで、文の途中で分割されても意味が途切れにくくなる効果があります。実行結果から、元の1つのドキュ"キュメントが複数のチャンクに分割されたことがわかります。

Step 4: EmbeddingとVector Storeへの格納

次に、分割したテキストチャンクをベクトルに変換し、Vector Storeに格納します。このプロセスが、テキストデータを「検索可能」にするための核心部分です。

  1. Embedding: 各テキストチャンクを、OpenAIEmbeddingsモデルを使って高次元の数値ベクトルに変換します。このベクトルは、テキストの意味的な内容を捉えています。
  2. Vector Store: 変換されたベクトルを、FAISS（Facebook AI Similarity Search）というライブラリが提供するVector Storeに格納します。FAISSは、大量のベクトルデータに対して非常に高速な類似度検索を実行できる優れたライブラリです。

from langchain_openai import OpenAIEmbeddings
from langchain_community.vectorstores import FAISS

# OpenAIのEmbeddingモデルを初期化
embeddings = OpenAIEmbeddings()

# 分割したドキュメントとEmbeddingモデルを使って、FAISSベクトルストアを作成
# この処理の内部で、各チャンクがベクトル化され、FAISSインデックスに格納される
vectorstore = FAISS.from_documents(split_documents, embeddings)

print("ベクトルストアの準備が完了しました。")

これで、私たちの知識ソース（neko.txt）は、意味に基づいた検索が可能な状態になりました。試しに、あるクエリに類似したチャンクを検索してみましょう。


query = "主人公が見た人間について"
# 類似度検索の実行
retrieved_docs = vectorstore.similarity_search(query)

print(f"--- 「{query}」の検索結果 ---")
for doc in retrieved_docs:
    print(doc.page_content)
    print("-" * 20)

クエリに関連するテキストチャンクが正しく検索されていることが確認できるはずです。これでRetrieverの準備が整いました。

Step 5: Retrieverの作成

LangChainでは、Vector StoreをRetrieverとして簡単にラップすることができます。Retrieverは、クエリ文字列を受け取り、関連ドキュメントのリストを返す標準化されたインターフェースを提供します。


# Vector StoreからRetrieverを作成
retriever = vectorstore.as_retriever()
print("Retrieverの準備が完了しました。")

これだけでRetrieverが完成しました。内部的には、前ステップで行ったsimilarity_searchを呼び出すオブジェクトです。

Step 6: Chainの構築と実行 (RetrievalQA)

最後に、これまで作成したコンポーネントをすべて統合し、RAGパイプラインを完成させます。LangChainのRetrievalQA Chainは、この目的のために作られた便利なChainです。

RetrievalQAは以下の要素を受け取ります:

  • llm: 回答生成に使用するLLM（今回はOpenAIのGPTモデル）。
  • chain_type: 検索してきたドキュメントをどのようにLLMに渡すかを指定します。"stuff"は最もシンプルで、すべてのドキュメントを一つのプロンプトにまとめて渡します。
  • retriever: Step 5で作成したRetriever。

from langchain.chains import RetrievalQA
from langchain_openai import ChatOpenAI

# LLM（GPT-3.5 Turbo）を初期化
llm = ChatOpenAI(model_name="gpt-3.5-turbo", temperature=0)

# RetrievalQA Chainを作成
# retrieverが質問に関連するドキュメントを検索し、
# llmがそのドキュメントを基に回答を生成する
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff",
    retriever=retriever,
)

# 質問を定義
question = "主人公の猫が初めて見た人間はどんな特徴でしたか？箇条書きで教えてください。"

# Chainを実行して回答を取得
response = qa_chain.invoke(question)

# 結果を表示
print("--- 質問 ---")
print(question)
print("--- 回答 ---")
print(response["result"])

これを実行すると、LLMはneko.txtの内容だけを参考にして、質問に対する的確な回答を生成します。例えば、以下のような回答が得られるでしょう。

主人公の猫が初めて見た人間（書生）の特徴は以下の通りです。 - 顔が毛で装飾されておらず、つるつるして薬缶のようだった。 - 顔の真ん中が非常に突出していた。 - 顔の穴（口）から時々ぷうぷうと煙を吹いていた（煙草を吸っていた）。

素晴らしいですね！わずかなコードで、独自のデータに基づいた質問応答システムが完成しました。これがLangChainとRAGの力です。

RAGパイプラインの高度化とチューニング

基本的なRAGパイプラインは構築できましたが、実用的なアプリケーションにするためには、さらなる改善とチューニングが必要です。ここでは、より高品質な応答を得るためのいくつかの高度なテクニックを紹介します。

プロンプトエンジニアリング for RAG

RetrievalQA Chainは内部的にデフォルトのプロンプトテンプレートを使用していますが、これをカスタマイズすることで、LLMの振る舞いを細かく制御できます。例えば、「参考資料に答えがない場合は、無理に答えようとせず『分かりません』と答える」ように指示することができます。これはハルシネーションをさらに抑制する上で非常に重要です。


from langchain.prompts import PromptTemplate

# カスタムプロンプトテンプレートを定義
template = """以下のコンテキスト情報だけを使って、最後の質問に答えてください。
コンテキストに答えが見つからない場合は、「提供された情報からは分かりません。」と回答してください。

コンテキスト:
{context}

質問: {question}
回答:"""

# PromptTemplateオブジェクトを作成
CUSTOM_PROMPT = PromptTemplate(
    template=template, input_variables=["context", "question"]
)

# chain_type_kwargsにpromptを指定して、カスタムプロンプトを使用するChainを再構築
qa_chain_with_prompt = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff",
    retriever=retriever,
    return_source_documents=True, # ソースドキュメントも返すように設定
    chain_type_kwargs={"prompt": CUSTOM_PROMPT}
)

# 文書にない情報について質問してみる
question_out_of_context = "この猫の好きな食べ物は何ですか？"
response = qa_chain_with_prompt.invoke(question_out_of_context)

print(f"質問: {question_out_of_context}")
print(f"回答: {response['result']}") # -> 提供された情報からは分かりません。

このようにプロンプトエンジニアリングを適用することで、RAGシステムの堅牢性を高めることができます。

ソースの引用（Citing Sources）

RAGの大きな利点の一つは、回答の根拠を示せることです。RetrievalQA Chainを作成する際に `return_source_documents=True` を設定すると、応答とともに、回答の生成に使用されたソースドキュメント（チャンク）も返してくれます。これにより、ユーザーは回答の信頼性を自分で確認できます。


question = "書生とはどのような種族だと説明されていますか？"
response = qa_chain_with_prompt.invoke(question)

print(f"質問: {question}")
print(f"回答: {response['result']}")
print("\n--- 参照したソースドキュメント ---")
for source in response['source_documents']:
    print(f"- {source.page_content.replace('\n', ' ')}")
    print(f"  (出典: {source.metadata['source']})")

この機能をUIに組み込むことで、ユーザー体験とアプリケーションの信頼性を劇的に向上させることができます。

Retrieverの最適化

RAGの性能はRetrieverの性能に大きく依存します。デフォルトの類似度検索（Similarity Search）だけでなく、LangChainはより高度な検索手法も提供しています。

  • MMR (Maximal Marginal Relevance): 検索結果の多様性を高めたい場合に有効です。単にクエリに似ているだけでなく、検索結果同士が似すぎていないドキュメントを優先的に取得します。これにより、多角的な情報をLLMに提供できます。
    retriever = vectorstore.as_retriever(search_type="mmr")
  • Contextual Compression: Retrieverが取得したドキュメント全体をLLMに渡すのではなく、その中から本当にクエリに関連する部分だけを抽出してから渡す手法です。LLMのコンテキストウィンドウを効率的に使い、ノイズを減らす効果があります。
    from langchain.retrievers import ContextualCompressionRetriever
    from langchain.retrievers.document_compressors import LLMChainExtractor
    compressor = LLMChainExtractor.from_llm(llm)
    compression_retriever = ContextualCompressionRetriever(base_compressor=compressor, base_retriever=retriever)

これらのテクニックを駆使することで、検索の精度と効率をさらに高め、最終的な回答の質を向上させることが可能です。

LangChain RAGのユースケースと未来

今回構築したQ&Aシステムは基本的なものですが、RAGの技術は非常に幅広い分野に応用可能です。以下に具体的なユースケースをいくつか紹介します。

RAGの代表的な応用例
  • 高機能な社内ナレッジベース検索: Confluence、Notion、Google Drive、Slackなどに散在する社内ドキュメントを知識ソースとし、社員からの質問（「経費精算のルールは？」「〇〇プロジェクトの技術仕様書はどこ？」など）に、根拠となるドキュメントを提示しながら回答するチャットボットを構築できます。
  • カスタマーサポートの自動化と高度化: 製品マニュアル、FAQ、過去の問い合わせ履歴などをRAGの知識ソースとすることで、顧客からの問い合わせに24時間365日、即座に自動応答するシステムを構築できます。人間のオペレーターは、より複雑で創造的な対応に集中できます。
  • リサーチ・学習支援ツール: 大量の学術論文や技術文書、ニュース記事を読み込ませ、特定のテーマに関する要約の生成、複数の文献を横断した情報の抽出、専門用語の解説などを行うリサーチアシスタントを作成できます。
  • パーソナライズされたコンテンツ推薦: ユーザーの過去の行動履歴やプロファイル情報を知識ソースとして、そのユーザーに特化した製品や記事を、推薦理由とともに自然な文章で提案するシステムを構築できます。

RAGとLangChainの技術は現在も急速に進化しています。より高度な検索手法の研究、複数の知識ソースを動的に使い分けるエージェント（Agent）技術との融合、そしてRAGパイプラインの性能を自動で評価・改善する仕組みなど、LLMアプリケーション開発の可能性は広がり続けています。

まとめ

本記事では、現代のLLMアプリケーション開発における必須技術であるRAG（検索拡張生成）の概念から、その実装を劇的に効率化するフレームワークLangChainを用いた具体的な構築方法、さらには高度なチューニングテクニックまでを網羅的に解説しました。

重要なポイントを再確認しましょう:

  1. LLMの限界: 標準的なLLMは、知識の鮮度や専門性、そしてハルシネーションという課題を抱えています。
    2. - RAGによる解決: RAGは、外部の知識ソースを検索し、その情報を基に回答を生成することで、これらの課題を克服します。 - LangChainの威力: LangChainは、RAGパイプラインの複雑なコンポーネントを抽象化し、開発者が迅速かつ柔軟にアプリケーションを構築することを可能にします。

今回学んだ知識は、単なる技術的なノウハウに留まりません。それは、あなた自身のデータ、あなたの組織独自の知識を活用して、これまでにない価値を生み出すための強力な武器です。ぜひ、この記事のコードをベースに、ご自身の興味のあるドキュメントを読み込ませ、独自のQ&Aシステムを構築してみてください。その一歩が、LLMアプリケーション開発の新たな世界への扉を開くことになるでしょう。

更なる学習のために、以下の公式リソースを参照することをお勧めします。

生成AIとLangChainが切り拓く未来は、あなたの手の中にあります。Happy Hacking!

```

Related Posts

Loading…

Post a Comment