KDDIアジャイル開発センター 2つのRAG活用事例 - Azure & AWS の特徴と選定のポイント

Microsoft Azureを活用したRAG開発事例

執筆：出光 広和 / 開発2部 エンジニア
　　　岡本 浩尚 / 開発2部 エンジニア

法人顧客向けサポート支援の一環でRAGを活用

弊社KAGでは、KDDI社のシステム開発を支援をしています。今回はこのKDDI社に対するRAGを活用した支援事例をご紹介します。

KDDI社では通信ビジネスの一つとして、法人のお客様向けにスマートフォンなどのモバイル機器を提供しています。モバイル機器をご利用のお客様向けにサポート用のMyページをWebで提供している他、お客様からの機器に関する問い合わせをKDDI社のサポート部門が日々受け付けています。

この質問やサポート要望への対応は、もともとは人手によって行なっていました。しかしながら、質問内容がサイト関連、端末関連、通信関連と多岐にわたることや、人手による対応で回答待ち時間が長引くといった課題があったため、お客様の質問へ一元的に回答できる生成AIチャットボットの開発を開始しました。

お問い合わせ対応チャットボットを実現するアーキテクチャと技術選定

サポートで回答する内容には、提供サービスの情報や個別の端末特有の内容等、通常の生成AIの回答やWeb検索等では得られない情報が多いことからRAGを利用しています。以下、各技術選定の意図を細かく解説していきます。

• クラウドサービス
  

  • Microsoft Azure
    PoC開始時にLLMを扱えるクラウドサービスがAzureのみであったため、その後の本格展開も含めてAzureを選択・踏襲しました。
    

• テキスト生成モデル
  

  • Azure Open AI GPT-4o
    高度な文脈理解が必要であったため、判断能力の高いGPT-4oを選択しています。
    

• 埋め込みモデル
  

  • Azure Open AI text-embedding-3-large
    他のモデルと比較して、コストが大幅に安くなっており、効率も向上しているため選択しています。
    

• ドキュメントパーサー
  

  • Azure AI Document Intelligence
    PDF、XLSX、PPTに関しても取り込む必要があるため、テキスト抽出にDocument Intelligenceのレイアウトモデルを選択しました。
    

• ベクトルDB
  

  • Azure AI Search
    ファイルの各チャンクごとのベクトルデータを保存しています。AI Search Indexerを利用し、CosmosDBのチャンクデータの更新をトリガーにAI SearchのIndexを更新しています。検索にはハイブリッド検索を利用し、Semanticランカーを利用することでチャンクデータの検索精度向上を図っています。
    

• その他データストア
  

  • Cosmos DB
    ファイルのメタデータのほか、ファイルを分割したチャンクデータを保存しています。FAQデータは頻繁にファイルの一部二のみ更新が入ることが多いため、CosmosDBにチャンクデータを保存することで差分更新により効率的なRAGデータの更新を可能にしています。AI Searchのバックアップとしても機能しているほか、CosmosDBがベクトル検索に対応したため、AI Searchの代わりとして利用することも検討中です。
    

• LLMOps
  

  • Langfuse
    LangSmithと違い、自Azure環境内にデプロイができるためLangfuseを選択しました。エンジニア以外も生成AIの処理や履歴を視覚的に確認することができるように導入しています。チャットボットでのユーザーフィードバックの確認や集計に利用しています
    

  • RAGAS
    回答精度の可視化や精度向上施策の効果確認に利用しています。RAGASのスコアをもとに回答精度の指標を定めています。
    

また、この案件は2023年8月にPoCに着手してから、約1年で社内向け環境をリリースするに至りました。

• PoC、実装、運用の体制や期間
  
  • 2023年 8 ~ 12月 PoC（RAGの技術検証をメインに実施）
    
  • 2024年 4月 開発開始
    
  • 2024年 8月 社内向け環境リリース
    
  • 2024年 9月 社外向け開発開始
    
  • 2024年 12月 社外向け環境リリース（予定）
    

開発はスクラムで実施しており、メンバー構成はプロダクトオーナー1名、プロダクトオーナー支援メンバー5名、スクラムマスター1名、エンジニア3名です。
開発内容を決めていくうえでは、PoCを実施したのち、アジャイル開発の考え方に乗っ取ったMVP（Minimum Viable Product）を事前に作成し、機能のすり合わせを進めました。
社内向けリリースの前、PoCの段階でRAGデータの検索が上手くいかない等の課題が発見できたため、チャット処理のなかで「検索クエリを作成するLLM」を挟むなどのチューニングを行いました。

RAG活用で困難だったこと

RAG活用の難しかった事の一つに、回答精度の問題がありました。導入するサイトの性質上、サービス固有の名称が多いため、質問をする際にRAGの情報がヒットしにくいという問題が発生しました。これを解消するため、一度ユーザが入力した質問をLLMにて変換することで対象のRAGがヒットしやすくなるようにしています。
また、テキスト抽出の精度も課題となりました。開発初期はドキュメントパーサーのDocument IntelligenceはReadモデルを利用していましたが、pdfやExcelなどのフォーマットに対応はしているものの、文字情報を全て抽出する仕様になっており、画像の中の文言など必要のない文字についても抽出していました。RAGに含めてしまうと回答精度を下げる要因になるため、別モデルであるLayoutモデルを利用し、必要な情報のみ抽出するように工夫をしています。

RAG活用の成果と今後の展望

今回のRAGを活用した事例では、通常の生成AIでは対応できない、個別の端末やサービスに関する質問に対して7割程度は回答できるまでに精度を向上させることができました。また、生成AIを利用することで質問に回答できなかった場合であっても、関連する情報やサポート窓口の案内を提供できています。
このKDDI社員を先行ユーザーとして行ってきた開発では、チャットボットの回答精度をブラッシュアップしたり、試用フィードバックを得ながら改善を繰り返し、一定の品質の担保をしてリリースすることができました。現在はエンドユーザーである法人のお客さまに直接RAGチャットボットを使っていただくために、生成AIを利用したFAQの自動生成等に挑戦するなど、さらなる品質向上に取り組んでいます。

Amazon Bedrockを活用したRAG開発事例

執筆：御田 稔 / 開発5部 テックエバンジェリスト　X: @minorun365 / GitHub: @minorun365
　　　大坪 悠 / 開発5部 エンジニア　X: @meitante1conan / GitHub: @tubone24

最近は多くの企業で「生成AIの活用」をテーマとしたプロジェクトが立ち上がっているのではないでしょうか。KAGおよびKDDIでも社内で多数の取り組みがなされており、その一つとして「ソリューション営業の業務効率化」をテーマとした生成AI活用の検討が進められました。

KDDIでは、お客様に自社のITソリューションを提案する営業が多数いるのですが、営業担当が様々な業務を抱えており業務効率化が悩みでした。

• 毎週お客様と多数の会議を行うため、議事録の作成だけで結構な工数がかかっている
  
• 日々の活動を日報や週報といった形で社内のレポートラインに上げる必要がある
  
• お客様向けの提案資料を作成する際、自社の商材が多すぎて選定や情報収集に時間がかかる
  

これらの足かせを少しでも軽減し、お客様への価値提供に直結する活動や提案内容のブラッシュアップにより工数を割きたいというのが営業担当の課題でした。
生成AIを活用してこの課題を解消すべく、KDDIアジャイル開発センターが開発したプロダクトが「議事録パックン」です。

議事録パックンのRAG活用におけるアーキテクチャと技術選定

議事録パックンはAWSを用いて開発しました。生成AIサービスであるAmazon Bedrockを中心に、RAGパイプラインの構築にはBedrockのナレッジベース機能を利用しています。StreamlitアプリケーションをECSのコンテナで稼働させ、LLMアプリの監視にはLangfuseを利用しました。
下記に、各技術選定の意図を解説していきます

• クラウドサービス
  エンジニアが普段使い慣れており、ユーザーの情報も多いAWSを選定しました。
  

• 生成AIサービス
  

  • Amazon Bedrock
    すでにGAから半年以上経っており、他のクラウドサービスと遜色ないレベルまで機能も充実していました。
    

• テキスト生成モデル
  

  • Anthropic Claude 3 Opus
    本アプリのメイン機能である議事録生成では、まるで普通の日本人が書いたような自然でレベルの高い文章を作ることができ、Claudeの日本語性能の高さを享受できました。
    

• 埋め込みモデル
  

  • CohereのEmbed Multilingual
    埋め込みの検索精度の評判が良いためです。日本語資料の埋め込みでは、トークン計算がうまくいかずコンテキストウィンドウを溢れてしまい、同期エラーとなってしまうドキュメントが複数ありました。
    

• ベクトルDB
  

  • Amazon OpenSearch Serverless
    Bedrockのナレッジベースに標準対応しており、検索精度を上げるためのハイブリッド検索などのオプションも利用可能だったため、こちらを利用しました。（ちなみに、初期のテスト段階ではより安価なPineconeを利用していました）
    

• アプリケーション稼働環境
  

  • Amazon ECSのコンテナをAWS Fargateでサーバーレス稼働
    アプリケーションを迅速に構築するため、StreamlitというPythonフレームワークを用いたのですが、よりサーバーレスなLambdaやApp RunnerがStreamlitに対応していなかったため、王道のコンテナサービスを選択しました。
    

• LLMOps
  

  • LLMアプリのトレーシングやプロンプト管理には、OSSのLangfuseを利用
    有名な競合製品にSaaSのLangSmithもありますが、Langfuseであれば自分たちのAWS環境内にデプロイして使えるため、セキュリティやコストの観点からこちらを選択しました。AWS App RunnerとAmazon RDSを使ってマネージドに稼働させています。
    

開発体制とスピード

議事録パックンの開発体制は、プロダクトオーナー1名、デザイナー2名、エンジニア3名のスクラムチームです。企画〜開発〜評価を3ヶ月という短期間で完遂しました。
エンジニアのうち2名は他案件との兼務のため、工数にして2人月を下回る少人数での開発でしたが、なんと2週間で実装作業を完了していました。

RAG活用における課題とその対応

議事録パックンでは、提案書作成機能においてRAGを活用したのですが、検索対象となる社内の商材マニュアルなどの資料はテキストだけでなく図表やグラフも多数含まれており、そのまま埋め込みへ変換しても思ったように検索精度が上がりませんでした。そこで、マルチモーダル入力に対応しているClaude 3モデルを利用して、図表入りのドキュメントは各ページを画像として読み込み、その内容を分かりやすく説明させたテキストに変換してからベクトルDBに取り込みました。（なお今ではこれをLambda等で作らずとも、Bedrockのナレッジベースの機能として搭載されています）

また、素早く開発できるようにStreamlitを使ってアプリケーションを開発したのですが、UX上の機能追加が増えるごとに実装難易度が上がってしまったため、もう少し早いタイミングでReactやFastAPIを用いた一般的なWebアーキテクチャに作り替えておくべきでした。まずはプロトタイプを作ってプロジェクト関係者のフィードバックを得て、そのまま開発継続しそうであれば早めにリアーキテクチャしてしまうのがお勧めです。

議事録パックンの導入の成果

この議事録パックンの導入により、KDDIの営業担当が議事録や提案書の作成時間を最大1時間短縮することができ、大きな業務効率化に繋がりました。業務品質向上という観点でも、AIエージェントが顧客の課題をWeb情報から調査したうえで、RAGを用いて社内の商材ドキュメントから適切なものをピックアップしてくれるため、よりお客さまに適したソリューションを提案しやすくなっています。

Azure OpenAI ServiceとAmazon Bedrock、両者の特徴と選定のポイント

Azure OpenAI Serviceは、大手クラウドの中でも最初期から生成AIサービスとして展開されており、機能的にも成熟しています。Microsoft製品との相性もいいことから、エンタープライズ環境でEUCと組み合わせるにはもってこいです。
一方でAmazon Bedrockは、AWSという開発者に人気の高いプラットフォームでいちビルディングブロックとして使えることが魅力で、ローンチは出遅れましたが機能も他社に追随してきました。色々な機能をマネージドサービス化してくれている点が強みです。

RAGアーキテクチャを活用するうえでは、複雑なパイプラインをより簡単に実装できることや、Advanced RAGに代表される検索精度向上のためのチューニングのしやすさなどを考慮するとよいでしょう。
まずはクラウドサービスをどれにするか、を起点に選定すると考えやすいです。自社での導入実績や、所属エンジニアの得意分野をベースに検討し、LLMやRAG領域における各製品の機能差異をチェックしてみましょう。

RAGの現在の課題と今後の展望

RAGアーキテクチャを実装した方は分かると思うのですが、運用を始めるとベクトルDBのランニングコストが課題となりやすいです。これについてはサードパーティのSaaS（Pineconeなど）を活用することも可能ですが、クラウドベンダー各社にもアップデートを期待したいところです。

また、RAGを「PoCから商用リリースへ」移行するうえで重要になるのが検索精度です。検索精度の向上のためには、よくAdvanced RAGと呼ばれるアプローチが活用されます。いくつもの手法が含まれていますが、検索対象のドキュメントのチャンク分割方法を工夫したり、検索クエリーをLLMに変換させたり、ハイブリッド検索を活用したりといった具合です。これらはすでにクラウドサービスの機能として取り込まれているものもありますが、そうでないものはアプリケーション側で実装する必要があります。こちらも各クラウドの機能追加を日々楽しみにしたい点です。

ガートナー社が発表した2024年のテクノロジーハイプサイクルにもあったように、RAGは「過度な期待」のピーク期にある技術と言われます。今後は評価・運用や、エージェントとRAGの組み合わせなど、より実際の商用プロダクトに求められる高度な領域で事例が増えていくことを期待したいところです。弊社KAGも注力していきます。

今後取り入れていきたい注目の生成AI関連技術

ここ2年ほどでRAGは多くの人がすでに試していますが、この次に重要なトレンドは「AIエージェント」だと考えています。実際、弊社KAGでも現在はAIエージェントを活用したプロダクトの開発にも力を入れています。
AIエージェントは、生成AIがまるで人間のように行動計画を立てながら、複雑な仕事を代わりに遂行してくれます。Web検索やファイル操作、外部APIなどのツールを実行させることもできます。RAGもツールの一つとしてエージェントに使用させることができます。

また、RAG領域に限っていえば、GraphRAGという新たなアプローチが今年登場しています。検索対象のデータを、埋め込みの代わりに「グラフ」の形式で保存し、関係性を整理して検索に用いる手法です。例えば人事データの検索など、ユースケースによっては従来のRAGよりも検索精度が向上するため、オプションとしていつでも使えるようにしておきたいと思っています。