# RAGベースクラウド運用支援 Navigation: [[AIOps]] | [[OpsQA]] | [[RAGノイズ除去]] ## 定義 RAGベースクラウド運用支援は、検索拡張生成(RAG: Retrieval-Augmented Generation)を用いてクラウド運用エンジニアの知識取得を自動化・高速化するアプローチである。製品マニュアル・FAQ・インシデントチケット・障害ライブラリ等の内部ドキュメントをベクトルデータベースに格納し、ユーザーの自然言語クエリに対して関連ドキュメントを検索・統合して LLM が回答を生成する。クラウドサービスの広大なドキュメント(Azure・AWS では 200 以上の製品に及ぶ)を横断する情報取得の非効率性を解消することが主目的である。(Source: [[@2025__ASE__iKnow - an Intent-Guided Chatbot for Cloud Operations with Retrieval-Augmented Generation]]) ## 標準的な RAG パイプライン構成 **オフライン段階**: 1. ドキュメントをチャンク(例: 100 トークン)に分割 2. ドキュメント名・セクションタイトルを先頭付加(コンテキスト強化) 3. 埋め込みモデルでベクトル化しベクトルデータベースに格納 **オンライン段階**: 1. クエリをベクトル化して類似度検索(コサイン類似度) 2. リランキング(クロスエンコーダ)で関連性の高い上位チャンクを選択 3. クエリ・取得チャンクを LLM プロンプトに統合して回答生成 iKnow の実装例: LangChain + FAISS、BGE-M3 埋め込み、bce-reranker-base_v1、Qwen-2.5-32B。(Source: [[@2025__ASE__iKnow - an Intent-Guided Chatbot for Cloud Operations with Retrieval-Augmented Generation]]) ## クラウド運用での特有の課題 一般的な RAG と比較して、クラウド運用 RAG は以下の固有の課題を持つ。 1. **独自性・機密性**: 運用ドキュメント(障害ログ・インシデントチケット等)は組織内に閉じており、汎用 LLM の訓練データに含まれない 2. **急速なソフトウェア進化**: 製品の複数バージョンが並行して参照されるため、バージョン認識型のドキュメント管理が必要 3. **クエリの曖昧性**: 運用者は障害の前で余裕がなく、短い・不完全なクエリを入力しがちである(iKnow では失敗の 32% が不完全クエリ起因) 4. **高ステークス性**: 誤った回答が実運用システムの意思決定に影響し、障害拡大のリスクを持つ 5. **知識の動的性**: 新機能・新エラーはドキュメント化が遅れるため、知識欠如が頻発する(iKnow では 27% が知識欠如起因) (Source: [[@2025__ASE__iKnow - an Intent-Guided Chatbot for Cloud Operations with Retrieval-Augmented Generation]]) ## 代表的な失敗パターン RAG ベースのクラウド運用チャットボットに共通する 6 種の根本原因(iKnow の経験的研究より): - **クエリ側**: 不完全クエリ(32%) / 対象外クエリ(10%) / 無効クエリ(9%) - **知識側**: 知識欠如(27%) - **検索側**: 不正確な検索(11%) - **生成側**: 不正確な生成(11%) ## 主要な改善アプローチ | アプローチ | 効果 | iKnow での実装 | |---|---|---| | 意図誘導型クエリ書き換え | 不完全クエリの解決 | 原型ネットワーク + LLM 書き換え | | 2 段階検索(検索→リランキング) | 検索精度の向上 | ベクトル検索 + クロスエンコーダ | | 欠落知識検知 | 幻覚の抑制・透明性向上 | LLM ベース充足性評価 | | バージョン認識型ベクトルデータベース | 版数ずれの回避 | メタデータ抽出 + 複数 VecDB | | 回答への参照ドキュメントリンク | 透明性・信頼性の向上 | メタデータ付き引用生成 | ## 横断的知見 - **クエリ品質が RAG 全体の最大ボトルネック**: iKnow の経験的研究で失敗の 51% がクエリ側起因と判明した。モデル性能(検索・生成)の改善より入力整形が先決であることを示唆する。(Source: [[@2025__ASE__iKnow - an Intent-Guided Chatbot for Cloud Operations with Retrieval-Augmented Generation]]) - **意図別の失敗パターンが異なる**: 用語説明は不完全クエリが 58.8% で圧倒的、事実確認・症状分析は知識欠如が主因と、意図ごとの失敗構造が異なる。これは意図非依存の一律改善より意図特化の対処が有効であることを示す。(Source: [[@2025__ASE__iKnow - an Intent-Guided Chatbot for Cloud Operations with Retrieval-Augmented Generation]]) ## 未解決の問い - 静的ドキュメントコーパスへの RAG は症状分析(リアルタイムな異常診断)に本質的に不向きか。ログ・トレース・メトリクスのリアルタイムデータを RAG コーパスに統合する実現可能な設計は? - 知識欠如の縮退応答ではなく、不足知識を能動的に更新するフィードバックループ(エンジニアの回答を新規知識として追記する仕組み)はどう設計するか。 - GraphRAG のような知識グラフベースアプローチは多面的要約クエリ(複数ドキュメントを横断する証拠の集約)でどれだけ有効か。 - RAG ベースチャットボットの「信頼スコア」をユーザーに提示することで、過信による誤操作をどれだけ減らせるか。 - 複数チーム(外部・内部・オンコール)でドキュメントコーパスを共有するか分離するかのトレードオフは? ## 関連 - 子概念: [[OpsQA]] - 隣接概念: [[AIOps]] / [[RAGノイズ除去]] / [[根本原因分析]] / [[クラウドインシデント]] - 実装システム: [[iKnow]] - 関連 MOC: [[structures/AIOps - Fault Localization - MOC]] ## 出典 - [[@2025__ASE__iKnow - an Intent-Guided Chatbot for Cloud Operations with Retrieval-Augmented Generation]]