RAGの問題は後を絶たない - それを修正する5つの方法

検索拡張生成（RAG）の真実と向き合う時が来ました。これは、それ自体のソリューションを必要とするソリューションです。

RAGは、大規模言語モデル（LLM）が外部の知識ベースにアクセスしてトレーニングデータにとどまらないようにすることで、大規模言語モデルの性能を向上させ、ハルシネーションを軽減することを目的としていました。しかし、従来のRAGシステムの現実世界における限界は、痛々しいほど明らかになっています。

「RAGには大きな欠陥があります」とIBM Softwareのシニア・バイス・プレジデントであるDinesh Nirmal氏は言います。「純粋なRAGは、期待される最適な成果を実際にはもたらしません。」

ユーザーが日常的に直面するRAGの課題には、コンテキスト・ウィンドウや集計オペレーションの制限、複雑な関係の理解不能、最適でないチャンキングに関連する低品質なアウトプットなどがあります。つまり、RAGの実装は、データ漏洩などのセキュリティー上の懸念をもたらす可能性もあります。

幸いなことに、人工知能ツールとストラテジーの進歩により、従来のRAGの欠陥を補うのに役立ち、その結果、ユーザーのクエリに対してより正確に生成される応答が得られるようになりました。RAGの性能を向上させる方法について詳しく見てみましょう。

従来のRAGを利用したLLMアプリケーションに、膨大なデータセットの集計オペレーション（合計の検索など）を実行することは、多くの場合、困難ではありません。文字通り不可能です。システムの性能を妨げている要因の1つは、コンテキスト・ウィンドウのサイズです。一般的にLLMのコンテキスト・ウィンドウは、たとえば10万件の請求書の集合を処理するのに十分な拡張性がありません。さらに、従来のRAGパイプラインは、集計オペレーションではなく類似性検索用に設計されたベクトル・データベースに依存しています。

「本質的には、ベクトル・データベースだけでは、これらのケースに対処するには不十分だということです」と、IBMディスティングイッシュト・エンジニアのSudheesh Kairali氏は説明しています。「コンテキスト・ウィンドウに問題があります。もう1つは、数学的なオペレーションができないことです」。

SQL RAGを入力してください。

LLMユーザーが大規模なデータセットから答えを求める場合、検索拡張生成とSQLを組み合わせることで、正確な成果が得られるとKairali氏は説明します。

SQL には集計関数が組み込まれており、SQLデータベースは LLM コンテキストウィンドウよりも容量が大きくなります。企業が請求書データをSQLデータベースに取り込むと、LLMを使用して「昨年の請求書の合計はいくらですか」などのクエリーをSQLに変換し、RAG経由でSQLデータベースにクエリを実行し、答えにたどり着きます。

「構築できれば、たくさんの集約を行うことができます」とKairali氏は言います。SQLデータベースが集計を実行した後、「その時点ではLLMの自然言語処理 （ NLP ）の演習になるだけです。」

取得したさまざまな情報またはエンティティが互いにどのように関連しているかを識別することは、従来のRAGのもう1つの弱点です。たとえば、複雑な病歴を持つ患者のユースケースを考えてみましょう。従来のRAG取得プロセスを通じて、LLMが関連情報を提供する場合があります。このデータには、その患者が1年間に何人の医師を受診したかなどの詳細が含まれることがありますが、各医師がどの治療法を処方したかを特定するのは難しい場合があります。

2024年にMicrosoft Researchによって導入されたGraphRAGは、ナレッジ・グラフを通じて関係を処理および特定することによって、この課題に対処します。GraphRAGは、エンティティとそれらの相互関係を表すノードとエッジのネットワークとして情報を整理します。

「患者が病院に行ったことがあるなら、質問は『過去に訪れたすべての訪問履歴を見せてほしい』ということです。それを単なる言葉ではなく、グラフによる知識表現として示せます」とNirmal氏は説明します。「異なる複数のポイントに注目し、彼が面会したさまざまな医師、服用したさまざまな薬、受けた治療をすべて1つのグラフィック表示で見ることができます。」

Nirmal氏によれば、データ量が増えるにつれてグラフのレンダリングが困難になるため、GraphRAGには限界があるといいます。たとえば、数十万のノードをマッピングすることは、わずか数十のノードをマッピングするよりも困難です。「すべてのものには制限があります。しかし、GraphRAGが活普及した理由は、純粋なRAG自体に限界があるからです」とNirmal氏は言います。

GraphRag の詳細をご覧ください。

チャンク化は RAG アプリケーションにとってクリティカルです。埋め込みモデルによる従来のチャンク化では、関連する文書は固定点で小さな断片に分解され、それぞれがベクトル・データベースで表現されます。ただし、この方法では、LLMアプリケーションがドメイン固有の知識ベースでセマンティック検索機械学習アルゴリズムを使用している場合でも、不完全または不正確な回答を提供する可能性があります。

「このプロセスでは、データをチャンク化している場所が分からないため、多くの場合精度が低下します」とNirmal氏は説明します。「テーブルの真ん中でチャンク化したり、切り落としたりしたとします。テーブルを戻すときには、テーブルの半分を持ってくることになります。今はその正確性が失われているのです」

幸いなことに、エージェント・メソッドによるチャンク化のストラテジーの改善により、情報検索を改善できます。このエージェント的チャンクには、重なり合うチャンクの作成や、取得した文書内のコンテキストに基づいてチャンク・サイズの動的変更などの戦略が含まれます。LLMオーケストレーション・フレームワークは、この目的に役立ちます。例えば、LangChainのTextSplittersツールは、テキストを意味論的に意味のある小さなチャンクに分割することができます。このようなストラテジーは、文書が分解された際に関連情報が失われるのを回避するのに役立ちます。

エージェント・チャンク化の詳細はこちら

エージェント型AIはチャンク化に役立ち、他の方法で検索精度も向上します。エージェント RAG を検討してください：これは、 RAG パイプラインを統合して、SQL データベースの構造化データとドキュメント・リポジトリー内の非構造化データの両方をクエリし、類似性検索にベクトル・データベースを活用できる高度な AI フレームワークです。

またエージェントRAGは、メタデータで各チャンクを強化します。このプロセスは、構造化データ（トランザクション・データベースに格納されたメタデータ）と非構造化データを相関させ、検索精度を最適化します。

「ベクトル・データベースの力をトランザクションやSQLの側面と一緒に利用し、この2つを一緒にすることができれば、精度と性能を大幅に向上させることができます」とNirmal氏は言います。

非構造化データの3つの主要な課題を克服するために必要なことを学びます。

データ漏洩はAIシステム全般において既知の問題であり、RAGを使用するLLMも例外ではありません。適切な対策を講じなければ、LLMは、個人識別情報（PII）から機密性の高い財務データまで、アクセス権限のない低レベルのユーザーに情報を提供してしまうかもしれません。

「RAGではこれが現実になっています」とKairali氏は言います。「概念実証から始めると、誰もが満足します。しかし、それを本番環境にプッシュし、本番グレードのものであることを確認しようとすると、データ保護の問題があることを理解し始めるのです」。

この問題に対処するには、非構造化データが複数のデータベースに取り込まれる際のアクセス制御リスト（ACL）やその他のガバナンス・ポリシーを維持する必要があります。「クエリが来てデータが取得されるときは、ACLとガバナンス・ポリシーが遵守されていることを確認することが重要です」とKairali氏は述べています。「これは基本的にエンジニアリングの問題です。」

このエンジニアリング上の問題の解決は、管理されたオープンソース対応のデータレイクハウスなどの適切なデータ・プラットフォームを使用することで、より容易になります。たとえば、ハイブリッドなオープン・データレイクハウスであるIBMのwatsonx.dataは、データが取得されるときにドキュメント・ソース・システムからアクセス制御を確実に継承します。また、機密情報の共有を防ぐためのPIIの注釈も提供します。

LLMやその他の生成AIが日常のワークフローに深く根付く中、RAGの改善により、企業は企業データからより大きな価値を解き放つことができるようになっています。適切なエンタープライズレベルのツールとストラテジーにより、「性能と精度が向上し、データが管理しやすく価値のあるものになります」とNirmal氏は言います。「それこそが、すべてのお客様が求めていることです。」