「RAGがうまくいかない」のはなぜ？ 精度を高める“チャンキング”のこつ：生成AIを支えるRAGの裏側【前編】

「RAGの構築が上手くいかない」と悩む企業は、データを見直すべき可能性がある。RAGの精度を高めるために欠かせないデータの前処理プロセスについて解説する。

[Gaetan Raoul，TechTarget]

　大規模言語モデル（LLM）を活用したシステムでは、「RAG」（検索拡張生成）が広く活用されている。RAGとは、LLMが外部のデータベースから情報を検索、取得できるようにすることで、事前学習していない知識や最新情報を含めたより実用的な応答を実現する仕組みだ。

　RAGは事前学習では補えない情報を補完する手段として有効だが、必ずしもその仕組みがうまく機能するとは限らない。「RAGが失敗する原因の大半は、入力データの品質に起因する」。コンサルティング企業Sopra Steria Nextでビジネス向けAI部門のディレクターを務めるブルーノ・マイヨ氏はこう指摘する。RAGの検索精度を高める上で重要なのは「データの前処理」、つまりどの情報をどのように分割し、検索しやすい形で構造化するかだ。

RAGがうまくいかない原因は“データ”にあり？

会員登録（無料）が必要です

続きを読む

併せて読みたいお薦め記事

RAGの実装を成功させるには

• 「RAGをそのまま導入」はダメ？　精度を上げる設計パターン3選
• 「RAGがうまくいかない」「精度が低い」　生成AI実装はどうすれば成功するのか

　RAGの基本的な仕組みは比較的シンプルだ。まず、ユーザーがプロンプト（AIモデルに対する指示や質問）を入力する。プロンプトを受け取ったRAGシステムは、検索用のクエリを生成し、それを使ってナレッジベース内の文書から関連情報を検索。最も関連性の高い順にランク付けする。LLMはその結果を基に、最終的な回答を生成してユーザーに返答する。それぞれの工程は密接に連携するため、統合的な設計と運用が求められる。

　RAGを構築する際、最初のステップは検索対象となる文書の収集だ。とはいえ、手元にある文書を全て一括で取り込むのは非効率的だ。バッチ更新とリアルタイム更新のどちらを採用するかという判断も伴うため、安易な一括取り込みは推奨されない。

　RAGの運用では、重複したドキュメントや古いドキュメントを排除し、最新かつ有効な情報を選別する必要がある。事前にデータを選別することで、無駄な情報をシステムに流し込むリスクを避け、処理性能の低下も防げる。

　検索対象となるドキュメントを絞り込んだら、未加工のデータ（HTML、PDF、画像など）をLLMで扱える形式に変換する必要がある。具体的には、テキストとメタデータのセット（JSON形式など）として整形し、文書の構造や著者、出典、作成日時などの属性情報を付与する。整形したデータを、トークン（テキストデータを処理する際の基本的な単位）やベクトル（数値のリストや配列）に変換する。

　マイヨ氏は次のように話す。「手元に200万件のドキュメントがあり、3週間でRAGを構築してほしいと相談してくる顧客もいるが、大体の場合上手くいかない」。機械学習の分野では、まずデータをきれいに整理してから使うのが常識だ。しかし生成AIでは、そうした準備の重要性が軽視されがちだ。

　コンテンツ量が膨大だったり、長文が多かったりする場合、文書全体を丸ごとベクトル化すると検索精度が下がってしまう。この課題を解消するために、RAGの実装時に重要になる手法が「チャンキング」だ。

RAGで欠かせない「チャンキング」とは？

　チャンキングとは、ドキュメントをチャンク（小さい区切り）に分割するプロセスだ。検索過程で最も関連性の高い情報を特定、取得しやすくする上で重要となる。

　一般的に、チャンキングには「SpaCy」「NTLK」などのPythonライブラリや、AI開発向けのオープンソースフレームワーク「LangChain」内のツール「text splitters」を用いる。

　チャンキングで考慮すべき要素として、まずチャンクのサイズ（長さ）がある。チャンクのサイズは、文字数、単語数、トークン数などで定義される。チャンクの数が多いほど検索のマッチング精度は高まる傾向にあるが、その分処理に必要なリソースや時間も増える。

　チャンクのサイズは、データをベクトルに変換するエンベディング（埋め込み）モデルのトークン制限に収まるように設計すべきだ。例えば、MicrosoftのAIサービス「Azure OpenAI Service」から利用できる「text-embedding-ada-002」モデルでは、入力テキストの最大長は8191トークンだ。OpenAIのモデルにおいては、1トークンは約4文字に相当するため、おおむね6000語程度のテキスト量に相当する。つまり、この上限を超えない範囲でチャンクサイズを調整する必要があるということだ。

　チャンクの分割方法も考慮すべきだ。代表的なパターンは以下の3つ。

• 固定長での分割
  • 一定の長さ（文字数、単語数、トークン数）ごとに文書を切り分ける最もシンプルな方法。処理が簡単なため、大量の文書を一通り確認したい初期フェーズに適している。
• 意味的な境界での分割（セマンティックチャンク）
  • 文章や段落、見出し、話題のまとまりといった自然な意味の区切りに基づく分割方法。最初からトークン数だけで機械的に切ると、意味の途中で切れてしまい検索精度が下がるため、より精度を高めたい場合に有効。
  • 空白、句読点、HTMLタグなどの論理的な区切り文字を使い、再帰的に分割する必要があり、実装はやや複雑になる。
• ハイブリッドチャンク
  • 上記2つのアプローチを組み合わせる方法。最初に固定長で分割した上で、必要に応じて意味的な境界を考慮して再構成することで、精度と効率のバランスを取ることができる。

　どの分割手法を採用するかは、求める精度や用途に応じて選ぶべきだ。例えば、「法律文書の中の特定の条文を探したい」といったケースでは、固定長での分割よりも、文章や段落など意味に沿った分割（セマンティックチャンク）がより適している。

　チャンクの分割においては、各チャンクを連結したり、一部を重複させたりする工夫も有効だ。一般的には、1チャンク当たり100～200語程度で、隣接するチャンク間で20～25％の内容を重複させる構成が広く採用されているという。

　AIベンダーCohereによると、「チャンク同士に多少の重なりを持たせることで、重要な情報がチャンクの境界で切り捨てられるリスクを減らすことができる」という。ただしこの方法には欠点もあり、「情報の重複（冗長性）が増える可能性がある」とも指摘している。

---

　次回は、RAGの検索精度を高める上で重要な構築・運用のポイントを解説する。