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