「検索結果には正しいドキュメントが含まれているはずなのに、なぜかLLMが的外れな回答をする」
「プロンプトを修正して一つの質問が直ったと思ったら、別の質問で回答精度が落ちた」
RAG（Retrieval-Augmented Generation）システムのPoC（概念実証）を終え、本番導入や精度向上を目指すフェーズに入ったとき、多くのプロジェクトがこのような課題に直面します。
精度のボトルネックが見えないまま、手当たり次第にプロンプトを調整したり、チャンクサイズを変更したりしていませんか。それは目隠しをしてダーツを投げているような状態と言えます。
RAGシステムは、検索（Retrieval）と生成（Generation）という二つの不確実性が組み合わさった複雑なパイプラインです。どこで情報が歪んだのか、その「中間処理」を可視化せずに改善することは困難です。
本記事では、LLMアプリケーション開発プラットフォーム「LangSmith」を活用し、ブラックボックス化しがちなRAGの挙動を「トレース（追跡）」することで、精度低下の真因を特定するアプローチを解説します。単なるツールの使い方ではなく、実務の現場で有効とされる「分析の思考フレームワーク」を体系的にお伝えします。
感覚的なチューニングから卒業し、データに基づいたエンジニアリングの世界へ踏み出しましょう。
なぜRAGの精度改善は「モグラ叩き」になりがちなのか
実務の現場における一般的な傾向として、RAGの精度改善がうまくいかない最大の理由は、「評価」なき「修正」を繰り返していることにあります。
直感的なプロンプト修正の限界
「回答が少し不自然だから、プロンプトに『丁寧に答えて』と追加してみよう」
こうした修正は、一見手軽で効果的に見えます。しかし、RAGシステムにおいて、最終的な回答（Output）は、ユーザーの入力（Input）、検索されたコンテキスト（Context）、そしてLLMへの指示（Prompt）の掛け合わせで決まります。
回答が誤っている原因が、プロンプトの指示にあるのか、それとも検索されたコンテキストにノイズが混じっているからなのか、あるいはLLM自体の推論能力の限界なのか。これを切り分けずにプロンプトだけを調整し続けると、特定のケースには過剰適合（オーバーフィッティング）する一方で、システム全体の汎用性を損なう結果になります。
ブラックボックス化する中間処理の可視化
LangChainなどのフレームワークを使っていると、数行のコードで高度なチェーン（処理の連なり）を構築できる反面、内部でどのようなデータが受け渡されているかが見えにくくなります。
- 検索クエリはどのように変換されたのか？
- 実際に取得されたドキュメントの上位k件は何だったのか？
- リランク（再順位付け）処理で何が除外されたのか？
- LLMに最終的に渡されたプロンプトのトークン数は？
これらの「中間処理」がブラックボックスのままだと、問題の所在を特定できません。ここで必要になるのが、システム内部の挙動を詳細に記録・追跡する「トレーシング（Tracing）」の技術です。LangSmithは、このトレーシングを強力にサポートし、RAGパイプラインの透明性を確保するためのツールです。
「評価」なき「改善」のリスク
プロジェクトマネジメントの観点から重要なのは、「測定できないものは改善できない」という原則です。ログ（トレースデータ）を取ることは、健康診断で言えばレントゲンを撮るようなものです。どこに病巣があるのか分からないまま手術を始める医者はいません。
まずは現状を正確に把握し、データに基づいて仮説を立てる。LangSmithはそのための「診断ツール」として機能します。
専門家パネル：RAG分析のスペシャリストたち
今回は、RAGシステムの精度改善について多角的な視点を提供するため、3名の架空の専門家パネルを設定しました。彼らの異なる視点を通すことで、単一の解決策ではない、立体的な分析アプローチが見えてきます。
Expert A: 大規模LLM基盤エンジニア
専門領域: ベクトルデータベース、インフラ、検索アルゴリズム
視点: 「検索できていなければ、生成もできない」という考えのもと、Retrievalフェーズの最適化を重視する技術者。ログから「ノイズ」を見つけ出すアプローチを得意とする。
Expert B: 生成AIコンサルタント
専門領域: プロンプトエンジニアリング、UX設計、業務プロセス
視点: ユーザー体験とビジネス価値を重視。「検索結果が正しくても、回答がユーザーの意図に沿っていなければ無意味」と考え、LLMの挙動制御に詳しい。
Expert C: データサイエンティスト
専門領域: 評価指標設計、統計分析、MLOps
視点: 「再現性のない成功は失敗と同じ」と考える厳格な評価者。自動評価パイプラインの構築と、定量的な指標モニタリングを推奨する。
ここからは、彼ら3名の視点を借りながら、LangSmithのトレースデータをどう読み解くべきか、具体的な分析手法を解説します。
視点1：Retrieval（検索）フェーズにおける「ノイズ」の特定
まず、Expert A（基盤エンジニア）の視点から、検索フェーズの問題を分析します。RAGにおいて最も一般的な失敗は、「適切なドキュメントを取得できていない」あるいは「余計なドキュメントを取得してしまっている」ことです。
関連度スコアだけでは見えない「毒入りコンテキスト」
ベクトル検索を行う際、多くのエンジニアは「類似度スコア（Similarity Score）」が高いドキュメントが取れていれば成功だと判断しがちです。しかし、Expert Aはこう指摘します。
「スコアが高いことと、回答に役立つことは別問題だ。むしろ、意味的に似ているが事実関係が異なる『毒入りコンテキスト（Distracting Context）』が混入することで、LLMが混乱するケースが多い」
LangSmithのトレース画面では、各ステップの入出力を詳細に確認できます。ここで見るべきは、Retriever コンポーネントの出力です。上位にランクインしているドキュメントの中に、質問とは微妙に条件が異なる古いマニュアルや、類似製品の仕様書が混ざっていないかを確認します。
LLMはコンテキストとして与えられた情報を「正」として扱おうと努力します。そのため、ノイズ情報が混ざっていると、それを無理やり統合して誤った回答（ハルシネーションの一種）を生成してしまうのです。
トレースから読み解くチャンク分割の不整合
また、トレースデータからは「チャンク（文章の切り分け単位）」の問題も見えてきます。
例えば、検索されたテキストが文の途中で切れていたり、重要な前提条件が前のチャンクに残ってしまっていたりするケースです。LangSmithで Retriever の出力を確認し、「このテキストだけで本当に質問に答えられるか？」を人間が目で見て判断する必要があります。
Expert Aの分析手法：検索クエリと結果の乖離検知
Expert Aが推奨する分析フローは以下の通りです。
- LangSmithで
Retrieverのステップを開く - 入力されたクエリ（Query）を確認する：ユーザーの質問がそのまま使われているか、LLMによって検索用に書き換えられているか。
- 取得されたドキュメント（Documents）を精読する：上位3〜5件の中に「正解」が含まれているか。逆に「回答を阻害する情報」が含まれていないか。
- アクション：正解が含まれていないなら埋め込みモデルや検索手法（ハイブリッド検索など）の見直し。ノイズが多いならリランク（Re-ranking）処理の導入を検討。
検索フェーズの品質を担保せずに生成フェーズのチューニングを行うのは、土台の不安定な建物に装飾を施すようなものです。
視点2：Generation（生成）フェーズの「ハルシネーション」追跡
次に、Expert B（生成AIコンサルタント）の視点で、生成フェーズの問題を深掘りします。「検索結果には正解が含まれているのに、LLMが間違った答えを出す」という現象についてです。
コンテキスト無視の原因を探る
Expert Bは指摘します。「LLMは自身の事前学習知識と、与えられたコンテキストが衝突したとき、しばしば自身の知識を優先してしまう傾向がある」
これを防ぐためには、プロンプトで強力に「コンテキストのみに基づいて回答せよ」と制約をかける必要がありますが、それでも無視されることがあります。LangSmithを使えば、実際にLLMに送られた最終的なプロンプト（Final Prompt）を確認できます。
ここでチェックすべきは、コンテキストの挿入位置と量です。コンテキストが長すぎて、LLMのコンテキストウィンドウ（扱える情報量）の限界付近になっていないか。あるいは「Lost in the Middle（中間の情報を見落とす現象）」が起きていないかを確認します。
プロンプト注入データとモデル知識の競合
また、トレースを見ることで「プロンプトテンプレートの不備」も発見できます。
例えば、System Message で「あなたは親切なアシスタントです」と指示し、Human Message でコンテキストを渡している場合、LLMが「親切さ」を優先して、コンテキストにない情報を補完して回答してしまうことがあります。
LangSmithのログを見れば、変数が代入された後の「生のプロンプト」が見えます。「これではLLMが誤解しても仕方がない」という構成になっていないか、客観的に評価することができます。
Expert Bの分析手法：Groundness（根拠性）の評価
Expert Bが推奨する分析アプローチは、回答の「根拠性（Groundness）」を確認することです。
- LangSmithで
LLM（またはChatModel）のステップを開く - 入力（Prompt）と出力（Output）を並べて比較する
- 検証：出力された回答の各文節が、入力されたコンテキストのどこに基づいているかを確認する。
- アクション：コンテキストにない情報が含まれていれば、プロンプトの指示を強化（「コンテキストにない場合は『分からない』と答えよ」等）。コンテキストが無視されている場合は、プロンプト構成の簡素化やモデルの変更（より高性能なモデルへ）を検討。
視点3：E2E（エンドツーエンド）での「評価セット」構築と自動化
最後に、Expert C（データサイエンティスト）の視点です。個別の事例分析だけでなく、システム全体の品質をどう担保するかという、運用の要となるテーマです。
単発のデバッグから継続的な評価へ
「たまたま上手くいったログを見て安心していないか」とExpert Cは問いかけます。
RAGの精度改善において注意すべきは、修正によって以前は正解していた質問が不正解になる「デグレ（リグレッション）」です。これを防ぐには、人間が都度確認するのではなく、自動化されたテストスイートが必要です。
LangSmith Datasetを活用した回帰テスト
LangSmithには、過去のトレースデータから良質な入出力ペアを選び出し、テスト用の「Dataset」を作成する機能があります。これを活用することが推奨されます。
Expert Cの提案は、以下のサイクルを回すことです。
- ゴールデンデータセットの作成: 実際の運用ログや想定質問から、理想的な「質問」と「回答（Ground Truth）」のペアを50〜100件程度用意する。
- 自動評価の実行: システムを更新（プロンプト変更や検索ロジック変更）するたびに、このデータセットに対してテストを実行する。
- LLM-as-a-Judge: 回答の正誤判定を人間が行うのは負荷が高いため、GPT-4などの高性能モデルに評価させる（「回答Aは回答B（正解）と意味的に一致していますか？」と判定させる）。
Expert Cの分析手法：精度低下のトレンド分析
Expert Cは、個々のログよりも「トレンド」を重視します。
- 全体の正答率: 前回のバージョンと比較して上がったか下がったか。
- レイテンシ（応答速度）: 精度は上がったが、検索に時間がかかりすぎていないか。
- トークン消費量: コストが見合っているか。
LangSmithのダッシュボード機能を活用し、これらの指標を時系列で監視することで、システムが健全に進化しているかを客観的に判断します。
専門家たちの共通見解と相違点
ここまで3つの視点を整理しましたが、彼らの議論を総括してみましょう。
一致した結論：まずは「ベースライン」を知れ
3名全員が同意したのは、「現状の数値（ベースライン）を知らずして改善はない」という点です。検索精度（Recall/Precision）であれ、回答の正確性であれ、まずはLangSmithを導入して現状を可視化することがスタートラインです。
意見が割れた点：コスト対効果とトレースの詳細度
一方で、議論になったのは「どこまで詳細にログを取るか」という点です。
- Expert A & C: 「全件トレースすべき。稀に起きるエッジケースこそが重要だから」
- Expert B: 「コストとプライバシーの観点から、本番環境ではサンプリング（抽出）で十分ではないか。また、LLMによる自動評価もコストがかかるので、重要な更新時のみに絞るべき」
LangSmith導入のROIをどう考えるか
プロジェクトのROIを最大化する観点からは、開発フェーズ（Dev）と本番フェーズ（Prod）で戦略を変えることが推奨されます。
開発中は全件トレースし、徹底的にデバッグを行う。本番運用後は、コストを考慮してサンプリング率を調整しつつ、ユーザーからの低評価フィードバックがあった際のみ詳細ログを残すようなトリガーを設定するのが現実的な解です。
結論：データドリブンな改善サイクルへの転換
RAGの精度改善は、魔法のようなプロンプト一つで解決するものではありません。地道なログ分析と、仮説検証の繰り返しのみが、信頼性の高いシステムを作り上げます。
感覚的なチューニングからの脱却
「なんとなく良さそう」から「データが改善を示している」へ。この意識の転換こそが、AIエンジニアからAIアーキテクトへのステップアップに必要な要素です。LangSmithのようなツールは、そのための強力な武器となります。
明日から始めるトレース分析の第一歩
まずは、現在開発中のRAGシステムにLangSmithを接続してみてください（数行の環境変数設定で済みます）。そして、以下の3つを確認することから始めましょう。
- 検索結果の中身: 本当に欲しいドキュメントが取れているか？
- 最終プロンプト: LLMに渡される指示は意図通りか？
- 失敗ケースの収集: うまくいかなかったログを「Dataset」に追加する。
この小さなサイクルを回し始めることが、精度の高いRAGシステム構築への最短ルートです。
最後までお読みいただき、ありがとうございます。
RAGの精度改善やLLMOpsの実践的なノウハウを活用し、データに基づいた論理的なアプローチで、共にAI開発のレベルを上げていきましょう。
コメント