RAG開発実践例：“動く”から“使える”に変えるためにやったこと

2024年以降、RAG の注目度が急上昇しています。生成AIと社内ナレッジを連携させる RAG は、容易に構築できるソリューションが続々と登場していますが、現場で実際に活用されるレベルにまで持っていくにはいくつもの落とし穴があります。
以下の記事では、RAG の精度改善の考え方について、RAGの仕組みから振り返ることで解説しました。

RAG(検索拡張生成)とは？ 仕組みからわかる、“動く”から“使える”へのステップアップ！

当社でも、上記の記事の考え方にもとづいて RAG の精度改善に取り組んだ実績があります。
RAG の精度改善においては、出力結果をよく観察したうえで対応策を検討する仮説思考の考え方が重要であり、本取り組みはその実践例となっています。 そこで今回は、RAG の精度改善で悩んでいる方に向けて、実際のプロジェクトがどのように進んでいくのかを、事例を通じてお伝えします。

当社ツールにおける RAG 事例

データ分析プラットフォーム「Alkano」

当社では、汎用のデータ分析プラットフォームである「Alkano」を開発・販売しています。
Alkano は、プログラミングの知識がなくても、直感的な操作で高度なデータ分析を実現できるよう設計されています。総計100種類近くの機能を搭載しており、統計解析、機械学習、テキストマイニングなど、多種多様な分析ニーズに対応しています。

AIエージェントを「Alkano先生」にする

Alkano では、前処理機能や分析機能を組み合わせることで、様々な分析を自在に実現することが可能です。
しかしその反面、「どのように機能を組み合わせればやりたい分析が実現できるかわからない」のようなお問い合わせを頂くことがあります。

これまで当社では、ユーザーからのご不明点のお問い合わせに対し、メールサポートや有償コンサルティングを通してご対応してきました。
しかしどうしても即時の対応が難しいことから、ユーザーが直ちに不明点を質問できるAIエージェントを Alkano に搭載するという企画が発案されました。

このAIエージェントは、現在「教えて！Alkano先生」という名称で搭載されています。
実装においては RAG のアーキテクチャが採用されており、ユーザーの質問に対して Alkano のドキュメントを参照しつつ回答を生成するようになっています。

本記事では「教えて！Alkano先生」開発の裏側を通して、RAG の精度改善の一事例をご紹介します。

「動く」RAGの構築

RAGの構築は、次の2ステップに分けられます。

• フェーズ1：「動く」RAG を実装する
• フェーズ2：「使える」RAG を目指して精度を改善する

このうち、フェーズ1は実はさほど難しくはありません。昨今は LangChain のように、LLM を使ったアプリケーションを実装する上で便利なライブラリが豊富であるため、RAG のコア部分のロジックは比較的容易に実装が可能となっています。

分析者による評価

フェーズ1で実装した暫定版の「教えて！Alkano先生」は、どの程度実用に耐えるものだったのでしょうか。
フェーズ1時点での使い勝手を評価するため、まず「ユーザーの質問内容をちゃんと理解できているか」「Alkano の機能の活用方法は妥当か」のような評価観点をいくつか用意します。
その後、普段から Alkano を利用している当社のコンサルタント数名が「教えて！Alkano先生」を利用し、人間で言えばどの程度のレベルに達しているか（「新人社員レベル」「シニアコンサルタントレベル」など）を主観的に評価しました。

その結果、フェーズ1時点の「教えて！Alkano先生」は、以下のように「新人社員レベル」未満であるとの評価がなされました。およそ「Alkano先生」とは呼べないような結果となってしまったのです。

特に問題となったのがハルシネーションです。ユーザーからの質問に対し、実際には Alkano に存在していない機能を使った分析アプローチを提案してしまうといった挙動が目立ちました。
このようなことが頻繁に起これば、「教えて！Alkano先生」はユーザーの助けになるどころか、むしろユーザーを混乱させてしまう結果となってしまうでしょう。

「使える」RAGを目指して

仮説思考の３ステップ

前回の記事 では、RAG の精度改善のポイントをいくつかご紹介するとともに、より本質的な考え方である仮説思考についても述べました。
仮説思考にもとづいた精度改善のアプローチは、以下の３ステップに沿って進められます。

1. さまざまな入出力パターンを試して、どんな場合に期待する精度が出ないのかを知る。
2. 精度が出ない理由について仮説を立てる。
3. 仮説にもとづいて精度改善の施策を立てる。

今回の事例において、これらの各ステップがどのように進んでいったのかをご紹介します。

ステップ１：出力の観察――どこで躓いているかを見極める

コンサルタントによって「新人社員レベル」未満と評価されてしまった「教えて！Alkano先生」ですが、どのような質問を与えた際に特に回答精度が低かったのかを観察しました。
次は観察結果です。

• 回答精度が落ちているのは分析の方法や進め方について質問した場合。Alkano に存在しない機能を用いた回答内容となっていることが多い。
• Alkano の機能について質問した場合はおおむね良い回答が得られている。回答内容はマニュアルの情報を踏まえており、マニュアルの該当箇所へのリンクも適切である。

RAGの出力を観察する際のポイントのひとつとして、どのような質問をした際に回答の精度が落ちるのかを見極めるというアプローチは各所で使えるノウハウであると言えるでしょう。

ステップ２：仮説の立案――なぜ失敗するのかを想像する

ステップ１の観察にもとづいて、「精度が出ていないのは RAG のこの部分が原因ではないか」という仮説を立てます。

今回の場合、なぜ分析の方法や進め方について質問した場合には精度が落ちるのでしょうか。
「教えて！Alkano先生」では、データベースに Alkano のマニュアルの記述を格納しています。
「分析の方法や進め方に関する質問が苦手」というステップ１の観察結果は、Alkano のマニュアルの記述自体にこの種の質問の回答が含まれていないことを示唆しているのかもしれません。

改めて Alkano のマニュアルの記述を振り返ってみると、以下の図のように説明がもっぱら機能ベースで書かれており、ユースケースベースでは書かれていません。
「ECサイトの口コミデータを分析するにはどうすればよいですか？」のような質問が与えられた際、マニュアルには「ECサイト」「口コミデータ」といった用語は登場しないため、関連の深い記述を検索できなかったという可能性が考えられました。

マニュアルに明示的に書かれていないことを尋ねているから精度が低いのではないか。この仮説にもとづいて、次のステップでは精度改善の策を考えていきます。

ステップ３：改善策の立案――人間の思考プロセスを模倣する

マニュアルに明示されていない内容について質問されたRAGは、どのようにすれば精度良く回答を生成できるでしょうか。
ここでヒントとなるのは、人間の思考プロセスです。

ユーザーから質問を受け取って回答する生成AIは、人間で言えば分析コンサルタントに相当します。生成AI自体は Alkano の機能について知りませんから、人間で言えば「Alkano については初心者だが分析の一般論については詳しい人」といったイメージでしょう。
一方、RAG はデータベースからマニュアルの記述を検索し、それに基づいて生成AIが回答します。これを人間で言うと、マニュアルを参照しつつ質問に回答する分析コンサルタントとなります。

そこで、「Alkano 初心者の分析コンサルタント」が Alkano を用いた分析の進め方について質問された場合を想像してみると、いきなりマニュアルを最初から最後まで読み通すようなことはおそらくしなさそうです。
まずは機能名や概要説明にざっと目を通して、使えそうな機能があるのか、あるとしたらどれなのかといったところから考えていくものと思われます。

この思考プロセスを整理すると、以下のような流れになるでしょう。

1. Alkano の機能名と概要説明を一通り見て、分析に使えそうな機能を絞り込む
2. 手順1.で絞り込んだ各機能の詳細説明を読んで仕様を確認する
3. 分析フローを組み立てる

先ほどの「ECサイトの口コミデータを分析」という課題を例にとると、この課題を解決するためにデータ分析の熟練者がまず最初にやるべきことは、「ECサイト」や「口コミ」等のキーワードで Alkano マニュアルを検索することではありません（そういったキーワードで、機能別に書かれたマニュアル検索をしても、有用な情報は得られません）。まずすべきことは、以下のように「手法」のあたりをつけることなのです：

こうして絞り込んだ各機能の詳細説明を読んで、仕様を理解したうえで、分析フローを組み立てることができるわけです。

もしこの思考プロセスを「教えて！Alkano先生」上で再現できれば、回答の生成プロセスがより人間に近くなり、回答の精度改善が見込めると考えられます。
再現手順は以下のようになります。

1. 生成AIのプロンプトに「ユーザーからの質問」と「Alkano の機能一覧」を渡し、分析に使えそうな機能の一覧を出力させる
2. 手順1.で抽出した各機能に対し、それらの詳細なマニュアルをデータベースから検索する
3. 分析フローを組み立てて回答を生成する

手順1.においては、Alkanoの機能一覧という多少ボリュームのあるテキストをプロンプトに含めています。
昨今の生成AIでは、かなり長いテキストをプロンプトに含めることが可能になってきています（ロングコンテキスト）。このため、RAG構築にあたっては、データベースを構築する代わりにテキストデータを直接プロンプトに渡してしまうというアプローチも可能になってきています（Cache-Augmented Generation: CAG）。
今回の事例では、Alkano のマニュアル全文をプロンプトに入れることはできなかったものの、機能一覧であれば入れることが可能であったため、このような方法をとっています。

また、手順2.で検索対象となるデータベースは、ベクトルデータベースではなくドキュメントデータベースを採用しています。
これは、機能名と詳細説明が key と value の形で対応していれば十分であるためです。テキストデータのベクトル化も必要ありません。

回答を生成する前に機能を絞り込んでいるため、当初問題となっていたハルシネーションなどのリスクが軽減されることが期待できそうです。

さらに、回答生成時のプロンプトも調整を重ねました。
Alkano で分析フローを構築する際の典型的なパターンや、間違えやすいポイントについて細かくプロンプトに記載することで、生成AIの回答精度を高めました。
最終的なプロンプトは数千行に及ぶものとなっています。プロンプトの調整については、業務知見を活かす余地が十分にあると言えるでしょう。

分析者による評価ふたたび

以上のような改良を施した「教えて！Alkano先生」を、改めて当社のコンサルタントが利用し、人間で言えばどの程度のレベルに達しているかを観点ごとに評価しました。
その結果、改善前では「新入社員レベル」未満と評価されていた観点も、以下の図のように「ジュニアコンサルタントレベル」へと評価が向上しました。
特に問題とされていたハルシネーションは許容範囲内と言えるまでに減少し、「教えて！Alkano先生」はユーザーの助けとなる機能となりました。

汎用解だけでは届かない

ここまで、成功した「仮説」のみを紹介してきましたが、もちろん当たらなかった仮説も多くあります。

特に、今回は、一般的に効果があるとされている「汎用的なアプローチ」だけでは十分な成果につながりませんでした。たとえば次のような取り組みを試しましたが、今回は大きな効果を生み出すに至りませんでした。

• チャンキングサイズ調整などの、汎用的な「RAG 精度改善」アプローチ：読み取り単位の粒度やオーバーラップの設定、セグメントの切り方といった、RAG 改善の基本どころを丁寧に試行しました。しかし今回の課題に対しては、いずれも目に見える改善には結びつきませんでした。
• 「グラフRAG」などの、汎用的で高度な RAG アルゴリズム：当時注目されていた論文および OSS 実装に沿って、Alkano マニュアルに登場する概念の関係性をグラフ構造※として扱うアプローチも検証しましたが、それだけでは期待した水準には届きませんでした。

もちろん、これらのアプローチは、多くのケースに適用できる優れた方法であり、ときに強力に精度改善をもたらすことがわかっています。「まず汎用的なアプローチを試してみる」というのは良い手なのですが、いつもそれで問題が解決するとは限りません。

こうした汎用的なアプローチでダメなら、今回のような「特化したアプローチ」、すなわち、特定の思考のプロセスや、業務のプロセスに踏み込んだ改善策をデザインする必要があります。人が現場でどの順序で情報を参照し、どこで判断し、どこにつまずきやすいのかといった業務フローや思考フローを丁寧に写し取り、それをヒントにアルゴリズムや設計そのものを見直していく発想です。

今回のアプローチのように、特定の思考手順を細かく指定して作るAIエージェントは、「ワークフロー型エージェント」とよばれることがあります。ワークフロー型エージェントは、業務課題を目的特化に解決する有力な選択肢ですが、作り込めば作りこむほど、特定用途に特化してしまい、柔軟性が下がってしまうといったトレードオフも伴います。

次の表は、汎用アプローチと、特定の思考プロセスや業務プロセスに特化したアプローチのメリット・デメリットをまとめたものです。

観点	汎用的な「定石」アプローチ	特定の思考プロセスや業務プロセスに特化したアプローチ
メリット	当たれば素早く「底上げ」を達成しやすい。導入が速く再利用もしやすい（独自実装しなくても、有名ソフトウェア機能やOSS等が利用できる場合もある）。	業務の流れに適合しやすく外れが減り、説明可能性も上がりやすい。
デメリット	課題の本質でない場合も多く、効果が頭打ちで、「使える」段階にまで至らない場合もある。	用途特化で柔軟性が下がってしまう。また、設計・調整に時間と手間がかかり、保守も発生しやすい。

大切なのは、汎用アプローチと現場理解を往復しながら、目的に合ったバランス点を見つけていくことだと考えています。

• ここでいう「グラフ」は、用語や出来事などの概念を点として置き、その関連（因果・参照・包含など）を線で結んだ抽象的な「関係図」のことを指します。グラフRAGのような手法では、この関係図をたどることで、単なるキーワード一致に頼らず、そのキーワードと文脈でつながる情報まで広く拾い上げることを目指します。

社内関係者のコメント

最後に、当社の AI開発担当者・システム開発リーダー・取締役から、今回の取り組みに関するコメントを掲載いたします。
RAGの開発や精度改善に関する現場の空気感をお伝えするものとして、参考になれば幸いです。

AI開発担当者

システム開発リーダー

取締役

おわりに

RAGの構築においては、「動いた」段階で満足を宣言しないことが重要です。

本稿の事例における課題は、「どのような質問で精度が低下するか」の観察不足や、ユースケースとマニュアル構造の齟齬に起因するものでした。 そこで、データ分析熟練者の思考プロセス（候補機能の当たり付け → 該当箇所の深掘り → フロー設計）を明確化し、機能一覧はロングコンテキストとして提示、詳細はドキュメント DB から要点抽出する構成としました。 結果として、ハルシネーションの抑制を確認しています。

最終的な成果は「設計 → 検証 → 改良」という反復の質と量に強く依存します。 これさえ使えば万事解決、といった「銀の弾丸」に期待するのではなく、失敗例を収集し、仮説を立て、測定で確かめる——この当たり前を着実に回すことが、「動く」を「使える」へ転換する最短経路だと考えます。

あわせて、評価設計は想像以上に重要で重い仕事であることも忘れてはなりません。評価軸の定義、代表性のある質問セットの構築、わかりやすくぶれにくい採点基準の整備——いずれもプロジェクトの成否を左右します。測れないものは改善できません。私たちも段階的な人材メタファ（新人／ジュニア／シニア…）を用い、データ分析コンサルタントの現場感覚を引き出しながら、回答の質を定量化することを試みました。

RAG の評価設計や改善サイクルの実装、プロンプト／検索戦略の最適化については、当社にて伴走支援が可能です。 具体的な適用や運用のご計画がございましたら、ぜひ当社までご相談ください。