社内文書AIの検索設定を自動比較、Red Hat AutoRAGの仕組み｜2026年9月12日版
社内文書を読ませたAIが、必要な条項を見落とす。その改善を、文書の分割方法や検索設定の比較から支援するのが、Red HatのAutoRAGです。2026年9月10日に公開された公式デモでは、正解付きの質問で複数の構成を評価し、選んだ構成をアプリから呼び出す流れが示されました。
核心は、検索の設定を実際の質問で採点して選ぶことです。ただし、何を正解とするかは利用する組織が用意する必要があります。日本時間2026年9月12日時点の公開情報から、仕組みと導入時の確認点を整理します。
- 文書の分け方や検索方法を変え、回答の品質を比較する。
- OpenShift AI 3.5では、多言語処理や会話形式のテストなどを追加。
- AutoRAGは技術プレビュー。評価問題の質と、日本語文書での検証が重要になる。
AutoRAGは「検索して答える」までの設定を選ぶ
RAGは、質問に関連する文書を検索し、その内容を生成AIに渡して回答を作る方式です。検索段階で必要な情報を拾えなければ、回答の根拠も不足します。
Red HatのAutoRAGの技術説明では、次のような処理を比較対象にしています。
- 文書分割：検索に使う断片を、どのように切り出すか。
- 検索方法：キーワード検索、意味の近さを使うベクトル検索、両者の組み合わせをどう使うか。
- 並べ替え：検索後の候補を再評価し、どの文章を優先してAIに渡すか。
短いFAQと長い規程集では、必要な情報のまとまり方が異なります。したがって、共通の設定をそのまま当てはめるより、対象文書に質問を投げて比較する意味があります。
AutoRAGはこの比較を自動化します。調整の対象は検索・生成の処理構成であり、導入するだけで文書の誤りまで直るわけではありません。
9月の更新で多言語処理と会話テストを追加
AutoRAG自体は、2026年5月のOpenShift AI 3.4で技術プレビューとして紹介されていました。
9月9日のRed Hat AI 3.5の発表では、AutoRAGに多言語処理、文脈を考慮した検索、会話形式のテスト、視覚的なデバッグ、pgvector対応が加わったと説明されています。pgvectorは、PostgreSQLでベクトルを扱うための拡張です。
日本の開発者にとって、多言語処理は確認したい変更です。ただし、発表には日本語の規程集を使った精度の数値は示されていません。日本語対応という言葉だけで判断せず、自社の略語や表、例外規定を含む文書で測る必要があります。
なお、同発表ではResponses APIと組み込みRAGは一般提供とされていますが、AutoRAGは引き続き技術プレビューです。APIの提供段階と、自動最適化機能の提供段階は区別して確認すべきです。
正解付きの質問で採点し、選んだ構成をAPIにつなぐ
9月10日の公式デモ解説では、質問と期待する回答の組を渡し、設定ごとの結果をLLMで採点します。
評価指標の例が「faithfulness」です。これは、生成された回答が検索した文書の内容に沿っているかを見る指標です。候補は順位付きで表示され、文書分割や検索方法などの設定も確認できます。
ここで注意したいのは、文書への忠実さと、その文書自体の正しさは別だということです。古い規程を正確に引用しても、現在の業務に適した回答になるとは限りません。
デモの規模とアプリ構成
公開されたデモリポジトリには、架空の銀行の内部方針6件、約1万語の文書、25問の評価データが含まれます。実在する銀行での導入実績や、法令判断の正確さを示す実証ではありません。
アプリの流れは次のとおりです。
- PythonのFlaskアプリから、プラットフォームのResponses APIへ質問を送る。
file_searchが、索引化した文書から関連部分を取得する。- LLMが回答を生成し、画面に回答と参照元を表示する。
検索処理をアプリ側で一から組み直さず、選定した構成を呼び出せる点が開発上の利点です。検証には、AutoRAGを配置したOpenShift環境や、索引化済みの文書などが必要です。
日本語の社内文書で試すなら、評価問題から作る
実務で最初に考えたいのは、どの質問に答えられれば使えると判断するかです。
Red Hatも、評価セットの設計が悪ければ誤った目的に向けて最適化され、文書の品質不足はAutoRAGでは補えないと説明しています。この性質を踏まえると、日本語の社内問い合わせでは、例えば次のケースを評価に含めると役立ちます。
- 例外条件がある質問：原則だけでなく、適用除外まで示せるか。
- 複数文書にまたがる質問：関連する規程と手順書を取りこぼさないか。
- 文書に答えがない質問：根拠のない結論を作らないか。
- 追質問：「その場合の申請先は？」のような会話でも、参照先がずれないか。
これらは導入時の評価案であり、公開デモで日本語の性能が実証された項目ではありません。採点結果に加え、担当者が回答と引用箇所を照合する工程を残すことが重要です。
継続ウォッチ：高得点の構成を、そのまま完成扱いにしない
AutoRAGによって、設定候補を比較する作業は自動化しやすくなります。一方で、現場の質問を集め、正解を定義し、文書を更新する仕事は残ります。
次に確認したいのは、次の3点です。
- 日本語の文書と質問で、現在の検索構成より改善するか。
- 品質だけでなく、応答時間と評価に必要な計算量が運用に見合うか。
- 規程改定後に再評価し、回答と参照先の変化を確認できるか。
試す際には、最適化に使う質問とは別に、最終確認用の質問も残しておきたいところです。既知の問題で順位が上がっただけなのか、日々の問い合わせにも通用するのかを見分ける材料になります。