はじめに

こんにちは。DeNA IT戦略部のtolinerです。

このブログは以下のブログの続きです。前回の記事で解説した背景知識や一部の用語を前提として進めていくため、ぜひ先にこちらを一読してください。

「業務量を半分に、生産性を倍に」という高い目標を実現するためにIT戦略部では社内AIヘルプデスク「Findout」を開発し、IT領域の操作質問に関する問合せの回答精度は80%超えと高い精度を誇ります。 しかし導入当初は回答精度は50％台とそれほど高いものではなく、DeNAのIT戦略部の課題となっていました。 それではいかにして「Findout」の回答精度を上げたのか。

Findoutにおける「Amazon Bedrock Knowledge Bases」を活用したマネージドRAGの事例をもとに、回答精度を向上させるための具体的なアプローチをご紹介します。特に、パラメーターチューニングの試行錯誤や、直面した課題とその解決策について、実体験ベースで詳しくまとめてみました。

本記事は、RAG の構築経験がある方や、導入・精度改善を検討されている方を対象としています。 今回ご紹介するプロセスを通じて、RAG の精度改善を「自分たちでも実現できる」と実感していただき、スクラッチ開発とマネージドサービスのトレードオフを理解した上で、皆様が最適な選択をするための一助となれば幸いです。

RAG精度改善に向けた評価システムの構築

RAGの精度改善は、試行錯誤と継続的な検証の繰り返しが不可欠です。このプロセスを効率的に進めるためには、高速な「施策実行・評価・分析」サイクルを回せる評価システムが不可欠でした。

自動評価システムの全体像と仕組み

FindoutのAI開発では、「raglab」と呼ぶRAG検証用フレームワークを構築し、その中で RAG の精度改善を加速させるための自動評価システムを運用しています。このシステムの主な目的は、RAGの「検索→生成」の改善が本当に有効かを継続的かつ客観的に測ることです。

このraglabは、「使い捨て可能なコード」 であることを前提としています。本番環境に求められる堅牢性や安定性よりも、高速な試行錯誤と柔軟性を最優先し、アイデアを即座に実装・検証できる実験場として設計しました。

私たちは、実際に社内でやり取りされた質問と、それに対する人手による「模範解答」をテストケースとして利用しています。このテストケースを用いてRAGの最終回答をLLMによって自動的に採点し、その結果を集約・可視化することで、「どの変更で品質がどう上がったか」を追跡可能にしています。

自動評価システムの高レベルなデータフローは以下の通りです。

1. テストケースの取得: 既存のQ&Aから、質問、模範解答、およびカテゴリなどのメタ情報を読み込みます。
2. RAGの実行: 取得した質問文を入力として、RAGが関連ナレッジを検索し、回答文 (最終回答) を生成します。
3. LLMによる自動採点: 採点用のLLMに、質問、RAGの回答、模範解答の3点を提示します。LLMは定義された採点基準に従い、0〜4点のスコアと、スコアの理由を短い日本語で説明するreasonを返します。
4. 結果の保存と集計: 各テストケースの詳細 (質問、回答、模範解答、検索結果リンク、スコア、理由など) を保存します。この際、RAGの構成を示すバージョンや実行時のメタデータと紐付けられます。その後、合計点や合格率 (3点以上を合格) が算出されます。
5. 可視化と共有: テストケースの詳細一覧と集計値がダッシュボードなどで可視化され、関係者が迅速に結果を把握できるようになります。また、Slackなどの通知チャネルにサマリを投稿し、結果への導線を共有します。

継続的なRAG改善を支えるバージョン管理戦略

RAGの精度改善を進めるプロセスでは、膨大な数の試行錯誤が発生します。その際、私たちは主に2つの課題に直面しました。

• 施策と結果の紐付け: どの設定変更がどんな結果を生んだのか追跡しにくい
• 環境の混在: 安定稼働させたい「本運用」と、アグレッシブに試したい「実験」が混ざってしまう

これらを解決し、組織として継続的に改善を続けるために、私たちは独自の「バージョン管理戦略」を導入しました。

FindoutのAI開発では、raglabの中でバージョン管理のルールを定めています。
まず、RAGの各種設定 (インデックス構築 (Indexing)、検索 (Retrieval)、生成 (Generation)) の組み合わせをパターンとして管理します。各設定変更はバージョンとして識別され、例えばIndexingのチャンク分割方法を変更すれば、新しいIndexingバージョンが作成されるといった具合です。
このバージョニングは、自動評価システムにおける「インデックス構築」「検索」「生成」の各要素にも適用され、評価結果とともに保存されます。これにより、どの組み合わせの変更が品質の改善や悪化に繋がったかをA/Bテスト的に追跡できるよう設計されています。

特に重要なのは、baseバージョンとtargetsという概念です。
baseバージョンは、最終的に成果物として出すような、本運用に足る安定したRAGの設定を指します。一方、targetsは、チームとして継続的に評価・分析したい、あるいはビジネス側が検証に利用する複数のパターンを指定するものです。これにより、一時的な検証のための試行錯誤と、長期的な運用を見据えた評価を明確に区別し、混在を防ぐことができます。

また、自動評価システムが生成した評価結果の管理においても、resultスキーマとresult_experimentalスキーマを使い分けています。
resultスキーマには、mainブランチかつtargetsに指定された、本運用に準ずるパターンの評価結果のみを保存し、Looker Studioでの可視化や部定例での報告に利用します。一方、result_experimentalスキーマは、開発ブランチでの試行錯誤の結果を格納し、迅速なフィードバックサイクルを回すための情報源として活用します。

このようなバージョン管理戦略と評価結果の分離により、私たちはRAGの継続的な改善を組織的に、かつ効率的に推進できる環境を構築しました。

マネージドRAGサービス活用の戦略的選択

RAGは基本的な実装は比較的簡単ですが、その精度向上には多くの試行錯誤と深い洞察が求められます。私たちもこの課題に直面し、少ない工数で効率的に高精度なRAGを実現するための戦略的な選択を迫られました。その結果、私たちは Amazon Bedrock Knowledge Bases の採用を決定しました。

実は、Findoutの開発初期において、私たちもフルスクラッチでの実装を行っていました。しかし、運用を続ける中でその「重さ」を痛感することになります。
スクラッチでのRAG開発は、柔軟性が高く、独自の要件に合わせたカスタマイズが可能な反面、ベクトルデータベースの選定・構築・運用、チャンク戦略、エンベディングモデルの選定、リランキングモデルの導入、プロンプトエンジニアリングなど、多大な工数と専門知識を必要とします。
特に精度改善においては、数多くあるRAGの精度改善手法から適しているものを取捨選択し、自力で実装しきる必要があり、高い負荷がかかります。

一方、 Amazon Bedrock Knowledge Bases のようなマネージドRAGサービスは、これらの複雑な要素をサービスとして提供します。これにより、インフラの構築・運用負荷を大幅に削減し、RAGの核となる精度改善の取り組みに集中できるという大きなメリットがあります。Amazon Bedrock Knowledge Bases は、リランキング、チャンク処理、クエリ変換といったRAGの精度を左右する主要機能を内包しており、これらの機能を少ない工数で素早く試すことが可能です。

私たちは、DeNAの「AIオールイン」戦略において、スピード感を持って全社的なAI活用を推進するためには、RAGの構築・運用に関するオーバーヘッドを最小限に抑え、価値創出に直結する精度改善にリソースを集中すべきだと判断しました。

結果として、 Amazon Bedrock Knowledge Bases の採用により回答精度が大幅に向上し、マネージドRAGへの転換はFindoutのRAG精度改善を加速させる鍵となりました。

私たちは、Amazon Bedrock Knowledge Baseで提供される機能を最大限に活用し、Findoutの回答精度を向上させるための徹底的なパラメーターチューニングを行いました。RAGの精度は、個々のコンポーネントの性能だけでなく、それらが連携し合う全体のバランスによって決まります。ここでは、私たちが試行錯誤した主要なパラメーターと、そこから得られた知見を共有します。

本ブログ公開時点での最高評価を獲得した設定は以下の通りです。

• ベクトルデータベース: OpenSearch Service Managed Cluster
• 生成モデル: Claude 4 Sonnet
• Embedding モデル: Cohere Embed 3 Multilingual
• ReRankingモデル: Cohere Rerank 3.5
• 検索設定: 検索結果数=100、リランキング後の検索結果数=20
• オーケストレーション設定: クエリ変換有効
• チャンク設定: 種類=階層型チャンク、文字数= (小: 300, 大: 1200) 、パーサー=デフォルトパーサー

検索設定の最適化

RAGの初期段階では、関連性の高い情報をいかに効率的に取得するかが重要です。正しいコンテキストがなくては正しい回答はできません。

検索結果数の調整

私たちはまず、リランキングなしの状態で検索結果数と精度の関係を評価しました。Embedding モデルに Amazon Titan Text Embedding V2 を使用し、検索結果数5件で54%、10件で61%、20件で69%と、検索結果数を増やすことで精度が向上する傾向が見られました。これは、検索精度が十分でないことと、LLMへの情報投入がチャンク単位であるため、より多くの情報を渡すことでソースナレッジの不足を補っていたことの2つが理由であると考えられます。

ここで検索結果数を増やすことにはトレードオフがあります。利点としては、検索精度が十分に高くない場合でも、より多くの候補の中から適切な文書がLLMに投入される可能性が高まります。一方、欠点としては、コンテキスト長が増加することによるコストやレイテンシーの増加、そして関連性の低い不要な文書が含まれることでLLMが誤った情報を参照し、かえって精度が低下するリスクがある点が挙げられます。

これらのトレードオフと実際の精度から、20件が検索結果数の限界であると結論付けました。

リランキングの導入

次に、リランキング機能を導入しました。リランキングは、初期検索で取得した多数の文書の中から、質問との関連性が高いものを再評価し、最終的に生成モデルに渡す文書の数を絞り込むプロセスです。
リランキング導入時には、リランキング前の検索数とリランキング後の検索数を設定する必要があります。今回は、リランキング前の検索数をBedrockの最大数である100件に設定し、リランキング後の検索数を10件と20件にして比較しました。
リランキング前の検索数を最大数まで増やした理由は、検索結果数を増やした時に精度が向上したことから、検索精度が十分ではないと判断し、より多くの検索結果を取った方が効果的だと思ったためです。また、リランキングのコストは安価であり、デメリットがほぼ無いため、可能な限り多くの候補をリランキングに投入することが有利だと考えました。

その上で、Amazon Rerank 1.0とCohere Rerank 3.5を比較しました。結果として、Cohere Rerank 3.5を導入することで、精度が約5%向上しました (リランキングなし20件で69%に対し、Cohere Rerank 3.5導入で74%) 。これは、Cohere Rerankがベクトル検索より適切にナレッジを絞り込めたことを示唆しています。

チャンク設定の最適化

RAGでは、元のドキュメントをどのように分割 (チャンク化) するかが、検索精度と生成される回答の質に大きく影響します。Amazon Bedrock Knowledge Bases には、デフォルトの固定文字数チャンク、階層型チャンク、そしてセマンティックチャンクの3つのチャンク方式があります。

私たちはこれら3つの方式を比較検証しました。結果は以下の通りです。

• デフォルト (固定)：74%
• 階層型チャンク：76%
• セマンティックチャンク：40%〜73% (設定による)

階層型チャンクは、小さなチャンクでベクトル検索の精度を高めつつ、大きなチャンクで生成時の文脈を維持するという利点があります。これは、RAGにおいてよく採用される「ページの全文取得」に近いアプローチであり、我々のケースでも特に具体的なコマンドや手順がチャンク区切りで分断されてしまう問題を解決し、精度向上に貢献したと考えられます。セマンティックチャンクは理論的には優れているはずですが、閾値等の設定が難しく、我々の環境では安定した高精度を出すに至りませんでした。

クエリ変換機能の活用

Amazon Bedrock Knowledge Baseのクエリ変換機能は、複雑なユーザーの質問を複数のサブクエリに分解し、それぞれで検索を実行することで、より網羅的かつ正確な情報を取得する仕組みです。例えば、「〇〇と△△のゴール数はどちらが多いか」といった質問に対して、「〇〇のゴール数」と「△△のゴール数」の2つのサブクエリを生成し、それぞれで検索を行います。

この機能を導入した結果、RAGの回答精度は76%から79%へと向上しました。このクエリ変換は、私たちがスクラッチで実装を試みた際には期待した効果が得られず、回答精度向上に繋がりませんでした。しかし、Amazon Bedrock Knowledge Baseのマネージド機能として利用することで、想定通りに検索精度が改善し、AIが回答生成に必要な情報を幅広く、かつ精度高く集められるようになりました。これは、複雑な機能を自力で一から構築するよりも、実績のあるマネージドサービスの「巨人の肩に乗る」ことが有効な戦略であることを示す良い例となりました。

エンベディングモデルの比較

エンベディングモデルは、ドキュメントとクエリをベクトル空間に変換し、類似度を計算するRAGの根幹を担うコンポーネントです。私たちは Amazon Titan Text Embedding V2 と Cohere Embed 3 Multilingual の2つのモデルを比較しました。

初期のテストケースでは両モデルで79%と差が見られませんでしたが、新たなテストケースでは、Titan V2が59%だったのに対し、Cohere Embed 3 Multilingualは64%と、Cohereモデルが明らかに高い性能を示しました。これは、初期のテストケースでは既に検索精度が飽和状態にあり、モデルの差が出にくかったのに対し、新たなテストケースではまだ改善の余地があり、モデル性能の差が顕在化したためと考えられます。日本語に特化した性能を考えると、Cohereの優位性は顕著でした。

ベクトルデータベースの選定

RAGの基盤となるベクトルデータベースの選定も重要な検討事項でした。私たちは Amazon OpenSearch Service Managed Cluster(Managed Cluster) と Amazon OpenSearch Serverless(Serverless) を比較検討しました。

驚くべきことに、私たちのテストではManaged Clusterの方がServerlessよりも精度が高い結果となりました。Serverlessのハイブリッド検索が悪く働いた可能性や、日本語の形態素解析プラグインの有無、あるいは質問内容がセマンティック検索向きではない可能性が考えられました。

最終的には、低負荷時のコスト効率と運用負荷が許容範囲内であることから、Amazon OpenSearch Service Managed Clusterを採用しました。Serverlessは最小課金単位が高く、我々の現在の要求性能ではManaged Clusterが圧倒的に安価でした。

成果と今後の展望

このRAG精度改善の道のりを通じて、私たちは以下の重要な学びを得ました。

1. 自動評価システムによる高速な改善サイクル: RAGの精度改善は、多くの試行錯誤を伴います。AIを活用した自動評価システムを構築することで、「施策実行→評価・分析」のサイクルを高速で回し、人間だけでは不可能な検証スピードと規模を実現できました。これは、継続的な精度向上を実現するための基盤となります。
2. マネージドサービスの戦略的活用: Amazon Bedrock Knowledge Bases のようなマネージドサービスを積極的に活用することで、インフラ構築・運用にかかる工数を大幅に削減し、RAGの主要パラメーターのチューニングという、本質的な精度改善活動にリソースを集中できました。スクラッチ実装で課題があったクエリ変換機能がマネージドサービスで効果を発揮した例は、この戦略の有効性を示すものです。
3. 主要パラメーターの組み合わせとデータの質: RAGの精度は、エンベディングモデル、リランキング、チャンク方式、クエリ変換といった個々のパラメーターの性能だけでなく、それらの最適な組み合わせによって大きく左右されます。また、ナレッジの「量」だけでなく「質」と「選定」が極めて重要であり、これらを体系的に最適化するプロセスが不可欠であることを改めて認識しました。

私たちの挑戦はまだ道半ばです。「IT領域の質問に対する回答精度100％」という究極の目標に到達するためには、RAGシステムのチューニングだけでは限界があることも痛感しました。

そのため現在は、RAGシステムそのものの改善から一歩進んで、回答の根拠となる「ナレッジの品質」をいかに担保するかという、運用・管理の仕組み作りに主軸を移して挑戦を続けています。

おわりに

RAGの精度改善は、確かに地道で時間のかかる作業であり、時に奥深く、多くの試行錯誤を要する課題です。しかし、適切な評価システム、体系的なバージョン管理、そしてマネージドサービスを戦略的に活用した継続的なパラメーターチューニングを行うことで、着実に成果を上げることが可能です。

本記事が、RAGの精度改善に悩むエンジニアの皆様にとって、具体的なヒントや実践的な学びとなれば幸いです。DeNAはこれからも、技術の力を信じ、新たな挑戦を通じてエンジニアリングの価値を追求し続けます。最後までお読みいただき、本当にありがとうございました！