プロンプトエンジニアリング、RAGなどで性能向上する

[kechigon]

Why

alert-mentaはユーザーの問い合わせや、モニタリングツールからのアラートをIssueに集約し、要約、根本原因分析、改善案の提案を行う。

この用途に合ったプロンプトエンジニアリング、RAGを使った生成AIの性能向上についてサーベイする。

What

ソースを列挙し、まとめる。

• RCAgent: Cloud Root Cause Analysis by Autonomous Agents with Tool-Augmented Large Language Models

  • Alibabaにおけるクラウドインシデントの根本原因をLLMを用いて自動で推論するシステムの提案論文

    LLMによる障害診断の既存手法は、ファインチューニングやRAGベースのものがあるが、すべてGPTファミリーとMicrosoft内のシナリオに基づいていることから、データプライバシーの懸念がある。そこで、プライバシーの懸念と手動ワークフロー設計の問題に対処する、ツール拡張型の自律エージェントRCAgentを提案している。RCAgentは、プライバシー懸念を解消するローカルのオープンLLM（Vicuna）、ワークフローの手動設計を必要としない行動軌跡レベルのゼロショット、および、コンテキスト長を短縮するための、多様な非構造化データ型を集約するためのプロンプトフレームワーク、ノイズの多いデータの修正、自己一貫性をもつ行動軌跡の集約機構などを備える。実験では、ツール拡張型自律エージェントの代表であるReActに対して、全ての側面でRCAgentが凌駕しており、特に根本原因のエビデンスの予測において従来の手法を改善している。

  • https://arxiv.org/abs/2310.16340

• Automatic Root Cause Analysis via Large Language Models for Cloud Incidents

  • Microsoftにおけるクラウドのインシデントの根本原因カテゴリをLLMで自動で推論するシステムRCACopilotの提案論文

    インシデント対応時にエンジニアが複数のデータソースから手動でデータを精査することが難しいことに対して、1)アラート種別ごとに、ルールベースのプログラムを組み合わせた決定木ライクなハンドラを構築し、これにより診断情報を収集し、2)LLMを用いて一旦診断情報を要約した上で、さらに過去の類似インシデントのFew Shot学習により根本原因カテゴリとその説明を提供する。Microsoftのメールサービスシステムの653件のインシデントデータを用いた実験ではXGBoost、FastText、Fine-tuned LLM、素のGPT-4、GPT-4 embeddingに対して、予測精度が大幅に向上し、平均15秒以内に応答できている。

  • https://arxiv.org/abs/2305.15778

• A Survey of AIOps for Failure Management in the Era of Large Language Models
  • https://arxiv.org/abs/2406.11213
  • 障害対応をLLMを使って行う利点
    • human-generated, system-generatedでエージェントを持たす
• [RAGのSurvey論文からRAG関連技術を俯瞰する](https://sue124.hatenablog.com/entry/2024/07/02/233616)
• ITでの障害診断などを行うLLM Owl
  • ‣https://github.com/HC-Guo/Ow
• 異常検知とは？ 〜発生しうるリスクと検知を行う際のポイント〜
  • https://www.pagerduty.co.jp/blog/what-is-abnormal-detection
• つらいインシデント対応を楽に、学びに、そしてゼロに。
  • https://waroom.com/
• AIによる自動化
  • https://www.pagerduty.co.jp/platform/aiops/
• 自然言語での対話ですべてのオブザーバビリティ データを照会し、状態を迅速に把握して、問題を解決できます。
  • https://www.datadoghq.com/ja/product/platform/bits-ai/
• 吉田社長のアドバイス
  • RAGに食わせるもの
    • システム構成
    • 時系列データ
• https://qdrant.tech/ ベクトルDB
• 時系列データ　https://zenn.dev/tsurubee/articles/00446669b6c83a
• ダウンストリームログタスクを効率的に実行するhttps://github.com/chauhanjatin10/BERTops
• ITの運用に特化したモデルhttps://github.com/HC-Guo/Owl
• エージェントによる障害局所化　https://arxiv.org/abs/2403.16362
• RAG, プロンプトエンジニアリング　https://docs.google.com/document/d/1qP8jn-8Z45hGT1ISh22dYlSxnG18LH-CcMcSvy-uDFI/edit
• ウェビナー
  • Amazon Kendra
  • Amazon Bedrock
  • 技術的なつらみ
    • 検索速度が遅い
    • ハルシネーション
  • 評価が難しい
  • 運用のつらみ
    • ソースの管理が必要
  • そもそもRAGを使う必要があるのかを考える
  • Vertexはコスパ良い
  • LangServe
  • LangSmith
  • Google Colab
  • dify
    • LLMアプリをローコードで作成できる
  • 精度強化
    • 可視化
      • prompt Flow
        • RAGAS
          • pythonで作られた評価用フレームワーク
    • LLMが評価
      • LangSmith
  • フィードバックをもらうようにする
  • やりたいことは検索？
  • 最初から最新モデルを使えるリージョンを使う
  • チャンクサイズどうするか
    • コスト
    • 精度
• google cloud rapid evaluation api
  • プロンプトの評価
• pairsの社内ツール　https://speakerdeck.com/fukubaka0825/peazuniokeruamazon-bedrockwo-itazhang-hai-dui-ying-yuan-cheng-aiturunodao-shi-li-at-20241115pei-xin-awsuebinadeng-tan
• https://zenn.dev/r_kaga/articles/e0c096d03b5781

暫定的な流れ

1. プロンプトエンジニアリングからで満足いかなかったらRAG
2. stackoverflowの検索結果含める
   1. perplexity https://docs.perplexity.ai/