短期間でRAGシステムを実現 お客様と歩んだ生成AI内製化への道のり

1. 2025/10/30 クラスメソッド株式会社 酒井 貴央 短期間でRAGシステムを実現 お客様と歩んだ⽣成AI内製化への道のり
2. ⾃⼰紹介 2 • 2023年11⽉ ◦ クラスメソッド⼊社 • 2024年10⽉〜  ◦ ⽣成AIを中⼼に技術⽀援やプリセールスを担当 • 部署 ◦ クラウド事業本部コンサルティング部 • 名前 ◦ 酒井 貴央 • 出⾝‧住まい ◦ 神奈川 → 福岡 • ブログ ◦ DevelopersIO(酒井貴央) • 好きな技術 ◦ ⽣成AI全般
3. RAGとは？
4. RAGとは？LLMの課題を解決する技術 4 LLMの課題 • ハルシネーション（幻覚） • 古い情報 • ドメイン知識の⽋如 RAG（検索拡張⽣成）で解決 • 信頼できる知識ベースを参照 • コスト効率的（再トレーニング不要） • 最新情報を反映、ソース明⽰で信頼性向 上 https://aws.amazon.com/jp/blogs/news/a-practica l-guide-to-improve-rag-systems-with-advanced-rag -on-aws/
5. RAG運⽤の現実：精度が思うように出ない
6. あるある① 的外れな回答 6 質問： 「有給の取り⽅を教えて」 回答： 「弊社の経営理念は...」 → 全然関係ない情報を返す
7. あるある② 古い情報を参照 7 質問： 「最新の規定を教えて」 回答： 2年前の古い規定を参照 → 情報が更新されていない
8. あるある③ 幻覚（存在しない情報） 8 質問： 「ボーナスはいつ？」 回答： 「年3回⽀給します」 → 実際は年2回。存在しない情報を⽣成
9. RAG精度改善の3ステップ 9 アーキテクチャ選定 評価 改善 後から調整できる柔軟 な設計の選択。 チューニング可能な余 地を残し、運⽤しなが ら改善できる構成を実 現。 1 2 3 開発中と本番環境での 継続的な測定。 問題箇所を特定し、改 善効果を可視化するこ とで、次の改善アク ションの優先順位を明 確化。 評価結果に基づく段階 的な対応。 データ品質の向上を軸 に、⼩さく試して⼤き く育てるアプローチで 確実な精度向上を実 現。
10. A社様での実践：短期間でRAGシステムを実現
11. A社様での取り組み 11 当初の状況 • GenU + Kendra構成を採⽤するも精度に課題あり クラスメソッドでの取り組み • フェーズ1（2024/10-12） ◦ Knowledge Baseへ切り替え、PoC構築 • フェーズ2（2025/03-06） ◦ 全社展開に向けたベータ版 ▪ EntraIDをSAML連携、BOXの⾃動同期、継続的な評価‧改善サイクル
12. アーキテクチャ選定
13. AWSでのRAGアーキテクチャの選択肢 13 Amazon Kendra • マネージドなエンタープライズ検索サー ビス • 機械学習による⾼精度な⾃然⾔語検索 • 多様なデータソースコネクタを標準提供 • ⾃動最適化（チューニング不要） Amazon Bedrock KnowledgeBase • RAG専⽤に設計されたマネージドサービ ス • 柔軟なベクトルストア選択 ◦ OpenSearch, Aurora等 • 詳細なチューニングが可能 ◦ チャンク、パース、検索⽅式 • Bedrock基盤モデルとシームレスに統合
14. Amazon Bedrock KnowledgeBaseを選定 14 チューニングの柔軟性 • チャンク戦略、検索⽅式などを柔軟に調整可能 • 評価結果を⾒ながら段階的に精度改善 シンプルなコスト構造 • モデル利⽤料以外は基本的に無料 • 予算内で継続的に精度改善できる
15. 採⽤したアーキテクチャ 15 https://github.com/aws-samples/generative-ai-use-cases
16. 評価
17. 2つの評価アプローチ 17 オフライン評価 開発中の改善サイクル 事前データで検証 本番前の精度測定 定量的スコアリング オンライン評価 本番環境での検証 実ユーザーフィードバック 実⽤性を測定 定性的な使⽤感
18. オフライン評価 18 事前に⽤意したデータで検証し、本番前に精度を測定 代表的な評価ツール • RAGAS ◦ Python RAG評価フレームワーク • Bedrock RAG Evaluations ◦ AWSのマネージドな評価機能 ◦ コーディング不要で実⾏可能 → 定量的なスコアで課題を特定
19. オンライン評価 19 実際のユーザーによるフィードバックで実⽤性を測定 → オフライン評価と組み合わせて継続的に改善 段階的な展開 • 限定的なユーザーグループから開始 • フィードバックを収集し改善 • 徐々に展開範囲を拡⼤ ⼈間評価の重要性 • 定性的な使⽤感を把握 • 実際の業務での有⽤性を確認 • ユーザーの信頼を構築
20. A社様での実践：オフライン評価 20 • Bedrock RAG Evaluations で定量 評価 ◦ 評価⽤データセットを事前準備 ◦ 検索精度（Retrieval）を⾃動スコア リング ◦ 評価結果をもとに改善案を検討
21. A社様での実践：オンライン評価① 21 • 2024/10-12 & 2025/03-06 ◦ ⼈事担当者がトライアルを実施 • 2025/07~ ◦ ベータ版として全社員へ公開 ◦ 実運⽤での検証と継続的改善
22. A社様での実践：オンライン評価② 22 ユーザーからのFBを収集 • Good/BadボタンやコメントでFBを収集 • FBはDynamoDBから確認可能
23. 改善
24. 評価結果に基づく改善アプローチ 24 1. Amazon Bedrock KnowledgeBaseとベクトルデータベース機能の活⽤ ◦ Advanced Parsing Option ◦ メタデータフィルタリング ◦ ハイブリッド検索 など 2. ドキュメント修正 ◦ ドキュメントの構造化 ◦ 情報の整理‧統合 ◦ 古い情報の削除や更新 など
25. Advanced Parsing Option（⾼度な解析オプション） 25 https://aws.amazon.com/jp/blogs/news/a-practical-guide-to-improve-rag-systems-with- advanced-rag-on-aws/
26. メタデータフィルタリング 26 https://aws.amazon.com/jp/blogs/news/a-practical-guide-to-improve-rag-systems-with- advanced-rag-on-aws/
27. ハイブリッド検索 27 https://aws.amazon.com/jp/blogs/news/a-practical-guide-to-improve-rag-systems-with- advanced-rag-on-aws/
28. チャンキング 28 https://aws.amazon.com/jp/blogs/news/a-practical-guide-to-improve-rag-systems-with- advanced-rag-on-aws/
29. リランキング 29 https://aws.amazon.com/jp/blogs/news/a-practical-guide-to-improve-rag-systems-with- advanced-rag-on-aws/
30. クエリ書き換え 30 https://aws.amazon.com/jp/blogs/news/a-practical-guide-to-improve-rag-systems-with- advanced-rag-on-aws/
31. その他
32. 最新データの同期 32 ⽇次バッチでドキュメントを⾃動取得 • StepFunctions + Lambda によるバッチ 処理 • BOXのドキュメントをデータソース （S3）に⾃動同期
33. ユーザーガイドの作成 33 ⽬的 • ユーザーによってリテラシーや質問の投げ⽅が全く違う • ある程度の⽔準まで引き上げるための使い⽅ガイドを作成 内容 • Anthropicのプロンプトベストプラクティスを参考に効果的な質問⽅法やベストプラクティス を記載 ◦ Claude Docs - プロンプトのベストプラクティス • HP（社内ポータル）に掲載
34. まとめ
35. まとめ 35 RAG精度は測って、試して、磨くサイクルで確実に改善できる RAG精度改善の3ステップ 1. アーキテクチャ選定 ◦ 後から調整できる柔軟な設計を選ぶ 2. 評価 ◦ オフライン/オンライン評価で問題を可視化 3. 改善 ◦ データ品質の向上を軸に段階的に対応