はじめに：LLMの知識拡張における二つの選択肢

企業が生成AIを導入する際、直面する最大の壁は「モデルが自社の固有知識を持っていない」という点です。ChatGPTのような汎用LLMは高度な推論能力を持ちますが、機密性の高い社内文書や、直近の市場動向については学習していません。

この課題を解決するための主要なアプローチとして、外部知識を検索する「RAG（Retrieval-Augmented Generation）」と、モデルの挙動やトーンを微調整する「LoRA/QLoRA」が存在します。これらを単なる手段としてではなく、ビジネスの「知識管理戦略」という観点から比較・検討します。

RAG：外部データベースを「脳の外部メモリ」にする

RAGは、LLM本体を改変せず、社内文書などをベクトルデータベースに格納し、プロンプトのコンテキストとして渡す手法です。いわば「オープンブック試験」をモデルに行わせるような設計です。

なぜRAGを選ぶのか

情報の鮮度管理: データベースを更新するだけで知識を最新化できるため、頻繁に変わる社内ルールや市場データの扱いに適しています。
ハルシネーションの低減: 根拠となるドキュメントを提示できるため、モデルが事実に基づいた回答を行いやすくなります。
コスト効率: モデル本体を再学習するコストがかからないため、スタートアップや中規模プロジェクトでの導入に適しています。

LangChainを用いた実装の勘所

LangChainは、このRAGプロセスをパイプラインとして構造化するために最適です。例えば、以下の流れで実装します。

from langchain.vectorstores import Chroma
from langchain.chains import RetrievalQA

# ドキュメントをベクトル化してロード
vectorstore = Chroma(persist_directory="./db", embedding_function=embeddings)

# 検索と生成のパイプライン構築
qa_chain = RetrievalQA.from_chain_type(llm=llm, retriever=vectorstore.as_retriever())

# 実行
result = qa_chain.run("社内の有給休暇申請フローを教えて")

重要なのは「検索精度」です。ドキュメントの分割粒度や、検索エンジンに渡すクエリの最適化がシステムの質を決定します。

LoRA：モデルの「話し方」と「振る舞い」を個別最適化

一方で、「特定の出力形式を守らせたい」「専門的な文脈に沿った回答をさせたい」といったニーズには、モデル自体を微調整する「LoRA（Low-Rank Adaptation）」が有効です。

LoRAの技術的背景

LoRAは、全パラメータを更新する「Full Fine-tuning」とは異なり、モデルの重み行列に低ランク行列を挿入して加算する手法です。これにより、数％のパラメータを学習するだけで、元のモデルの知識を維持しつつ、特定のタスクに適応させることが可能です。特にメモリ消費を抑える「QLoRA」の登場により、民生用GPUでの学習も現実的な選択肢となりました。

使い分けの基準

タスクの複雑性: 言語生成のスタイルや専門用語の用法といった「振る舞い」を変えたい場合はLoRAが適しています。
知識の依存度: 新しい事実を覚えさせたい場合はRAGが勝ります。LoRAは知識の「暗記」には不向きであり、あくまで「推論能力のチューニング」と捉えるべきです。

どちらを選ぶべきか：設計の意思決定

実務において、これらは二者択一ではありません。多くのエンタープライズ環境では「RAGで専門知識を供給し、LoRAで回答のトーンと精度を担保する」というハイブリッドな構成が理想的です。

設計の際は、まずはRAGを実装し「知識の欠落」を埋めることから始めてください。その上で、回答の構造が安定しない、特定の社内フォーマットに従わないといった「出力の品質」に課題を感じた段階で、LoRAによる微調整を検討するロードマップが、最も失敗の少ないアプローチです。

AIを単なるツールとして利用するのではなく、組織内の知識エコシステムとしてどのように組み込むか。そのアーキテクチャの選択こそが、技術導入の成否を分ける鍵となります。