RAGの精度、どう改善する？AIアシスタント「たまちゃん」の改善事例 vol.4

たまちゃんではRAGという仕組みを採用していますが、現在、社内ドキュメントは単純な文字列に変換してRAGに取り込んでいます。しかし、この取り込み方法では問題が発生します。

例えば、ドキュメント内に表が含まれている場合、表の中の文字列だけが抽出されることで、項目の対応関係や行・列といった表独自の構造が損なわれた状態でRAGに取り込まれてしまいます。その結果、生成AIがドキュメントを元に回答を生成する時、表の内容を正しく理解できず、誤った回答を生成する恐れがあります。

そこで今回の施策では、図2のように、ドキュメント内に含まれる表は、Markdown形式に変換してからRAGに取り込むことで、生成AIがドキュメント内の表を正しく認識して回答を生成できるか検証しました。

図3のように、表をMarkdown形式で生成AIに渡すと、生成AIは表やカラムの情報を正確に把握できるようになり、表の中のデータ同士の関係を正しく理解しやすくなり、正確な回答が得られると、一般的に考えられています。

一方で、最新の高性能な生成AIでは、表をMarkdown形式ではなく、単純な文字列として渡した場合でも、表やカラムの構造を上手く推測し、正しい回答を生成できる場合もあります。

今回の施策では、生成AIが「表」を正しく認識できるように、表をMarkdown形式に変換してRAGに取り込む方法を検証します。この変換には、OCR（光学文字認識）や表検出アルゴリズムを活用できます。

また、似たような変換処理として「図」をRAGに取り込む場合にも、図を文字列形式に変換してから取り込む方法があります。この場合、OCRを使って図の中の文字列を抽出したり、マルチモーダル生成AIを使って図からキャプション（説明文）を生成することで、文字列形式に変換します。

これらの変換の流れを図4に示します。

このように、ドキュメント内の様々なコンテンツを生成AIが理解しやすい形式に変換してからRAGに取り込むことで、検索精度や回答精度の向上が期待できます。

ドキュメント内の表をMarkdown形式に変換する時に、活用可能なサービスやOSS（オープンソースソフトウェア）を表1にまとめました。

今回は、Azure AI Document Intelligenceに加えて、変換の実行基盤であるAzure Functionsに導入が容易なMarkItDown、pdfplumberを使って検証しました。MarkItDownについては、表の認識にAzure AI Document Intelligenceを使うこともできますが、今回はMarkItDown独自のグリッド検出アルゴリズムを使って検証することにしました。

たまちゃんで取り扱っているドキュメントについて、表をMarkdown形式に変換してからRAGに取り込んだ時の精度は、表2のようになりました。

表をMarkdown形式にしてRAGに取り込むことで、生成AIが表の内容を正しく認識し、従来は回答できなかったいくつかの質問に対応できるようになりました。

一方で、Markdown形式にしたことでドキュメントの文字数が変わり、ドキュメントを一定のサイズで分割（チャンク化）した際の区切り位置が変化することで、一部のドキュメントが検索でヒットしなくなってしまい、うまく回答できなかったケースもありました。

結果的に、たまちゃんにおいて、「表を文字列としてRAGに取り込む方法」と「Markdown形式に変換してRAGに取り込む方法」とでは、最終的な精度の違いは無いことが分かりました。

現行と比べて最終的な精度の違いはありませんが、表をMarkdown形式にしたことで生成AIが上手く回答できたケースもあったため、pdfやdocx, xlsxの変換にMarkItDown、pdfの変換にはpdfplumberを使う「検証No3」を導入することに決めました。

たまちゃんではRAGの仕組みを採用していますが、ユーザーからの質問に対して「検索クエリ/タグ生成」と「回答生成」の2つのタスクで、GPT-4oという生成AIを利用しています。

「検索クエリ/タグ生成」では、ユーザーの質問から、ドキュメント検索用のクエリと検索時に重みづけとして使うタグを生成しています。また、「回答生成」では、検索で見つかったドキュメントから、ユーザーの質問に対する回答を生成しています。

2025年1月には、OpenAIから「OpenAI o3-mini」という新しい生成AIのモデルが発表されました。このモデルは、推論時間と価格を抑えながらも、複雑な課題に取り組む際に「より深く考える」ことができるのが特徴です。また、OpenAI o3-miniは、Azure OpenAI Serviceでも利用可能になりました。

このような背景を踏まえ、図5のように、たまちゃんの「検索クエリ/タグ生成」と「回答生成」において、GPT-4oの代わりにOpenAI o3-miniに切り替えることで、回答精度が向上するか検証しました。

OpenAIは、大きく分けて「GPTシリーズ（汎用モデル）」と「oシリーズ（推論モデル）」という2種類のモデルを提供しています。それぞれの特徴を表3にまとめました。今回施策で検証するOpenAI o3-miniは、このうちoシリーズに属するモデルになります。

補足情報ですが、oシリーズのモデルをOpenAIから直接利用する場合は「reasoning_effort」（推論の深さをlow、medium、highから指定）というパラメータが指定可能です。しかし、現時点では、Azure OpenAI Serviceで、このパラメータを指定できるのはOpenAI o1のみです。今後、OpenAI o3-miniでも指定可能になると予想されます。

Azure OpenAI ServiceでGPT-4oとOpenAI o3-miniを利用する際の料金を表5に示します。

OpenAI o3-miniは、GPT-4oと比べて入力の利用料金が約1/5、出力の利用料金が約1/3と、料金を大きく抑えることができます。ただし、OpenAI o3-miniは、出力にかかる料金として「内部での推論に消費したトークン分」も加算される点に注意が必要です。

たまちゃんの「検索クエリ/タグ生成」において、GPT-4oとOpenAI o3-miniをそれぞれ使った場合の検証結果を表6にまとめました。

それぞれのモデルで生成される検索クエリとタグの内容に大きな違いはありませんでした。一方で、生成に掛かる時間については、GPT-4oが約2秒であるのに対し、OpenAI o3-miniは約8秒と、GPT-4oよりも4倍ほど時間が掛かってしまいました。

以上のことから、「検索クエリ/タグ生成」では、OpenAI o3-miniに切り替えず、引き続きGPT-4oを使った方が良いと判断しました。

たまちゃんの「回答生成」において、GPT-4oとOpenAI o3-miniをそれぞれ使った場合の結果を表7にまとめました。

この結果から、「回答生成」においては、GPT-4oではなくOpenAI o3-miniを使うと、生成にかかる時間は長くなりますが、利用料金を大幅に削減しつつ、正解率を高められることが分かりました。

そして、たまちゃんでは「多少時間がかかっても、正確に質問に答えられることを重視する」というプロジェクトの方針から、「回答生成」に使用するモデルを、GPT-4oからOpenAI o3-miniに切り替えることに決めました。

今回の記事で紹介した2つの施策の結果を表8にまとめました。