ペアーズにおけるAmazon Bedrockを⽤いた障害対応⽀援 ⽣成AIツールの導⼊事例 @ 20241115配信AWSウェビナー登壇

2024/11/15 AWS オンラインセミナー、「生成 AI が切り拓く、今後のエンジニアリング環境」での発表資料になります。
https://pages.awscloud.com/eib-aiml-241115-reg.html

Transcript

1. ペアーズにおけるAmazon Bedrockを⽤いた障害対応⽀援 ⽣成AIツールの導⼊事例 2024年11⽉15⽇ AWSウェビナー
2. About Me Nari | Takashi Narikawa（@fukubaka0825） • 株式会社エウレカ ◦ 2020年に⼊社 ▪ SRE Team -> AI Team ◦ MLOps Engineer ◦ サウナ、筋トレ、⿇雀、ボルダリングが好き
3. Agenda 1. ペアーズにおける障害対応プロセス概要 2. ペアーズにおける障害対応プロセスの課題 3. 解決策1 - 障害対応報告書⾃動⽣成機能 4. 解決策2 - LLM Q&A ChatBot, Pairs Navi 5. まとめ/今後の展望
4. ①ペアーズにおける障害対応プロセス概要
5. ペアーズにおける障害対応プロセス概要 • ペアーズでは、障害対応を円滑に進めるためのサポートを⾏う障害対応管理シス テムを内製し、そちらをメインに活⽤して対応 ◦ 社内チャット/チケット/ドキュメントツールと連携 ◦ 障害第⼀報と対応チャンネル作成から、必要な操作がほぼチャット上のコ マンドで可能になっている ◦ 専⽤の障害対応チャンネルにやりとりを集約
6. ペアーズにおける障害対応プロセス概要 • ⾃分が⼊社してから、ここまでSRE Teamと協⼒し、様々な改善を⾏って便利に してきてある程度の仕組みにはなっていた ◦ 旧システムが退職者に属⼈化してそのまま停⽌していたため、Amazon API Gateway + AWS Lambdaにリニューアルしてチームでメンテできる形へ ◦ チャットツールで障害報告すると、専⽤チャンネルが⾃動で作られ、必要 なステークホルダーを⾃動招集 ◦ ポストモーテム推進及びテンプレートの整備 ◦ 障害深刻度をSEV1~3まで定義し、関係者と合意。深刻度によって、対応フ ローを分岐させ、適切な対応をおこなえるように
7. ② ペアーズにおける障害対応プロセスの課題
8. ペアーズにおける障害対応プロセスの課題 • ある程度システムもプロセスも整ってはきましたが、依然課題は⼭積みの状況 ◦ インシデントコマンダー(※1) に関する課題 ▪ 慣れてる⼈しか引き受けられない ▪ そもそもコマンダーがアサインされずに進むことがある ▪ コマンダーの責務が多すぎる課題、そもそも責務が認識されない ◦ 障害対応プロセスがかなり煩雑になってきて、認知負荷が⾼い課題 ▪ 慣れてる⼈しか障害対応をスムーズに⾏えない。新しい⼈も経験が積 みづらいので状況が改善しない。 (※1) 障害対応の司令塔。以降コマンダー 参考: インシデントコマンダーとは？〜現代のIT運⽤には必須！その役割と理 由〜
9. ペアーズにおける障害対応プロセスの課題 • そこで新たに、コマンダーの負荷軽減、障害プロセス認知負荷軽減のために様々 な機能提供をおこないました ◦ コマンダーの責務を明確化し、チャンネル作成時に都度⾃動投稿 ▪ インシデントの発⽣ ⾔/作業要員や関連部⾨の招集 ▪ 作業要員のアサインと体制構築、作業担当への指⽰ ▪ ステークホルダーとのコミュニケーション、状況の交通整理（初動状 況報告/中間状況報告） ▪ ポストモーテム⽂書作成、それをもとに障害内容と根本対応の共有 と議論を主導 ◦ チャンネル作成時のコマンダー任命機能 ◦ コマンダーのTODOリマインダー機能 ◦ 障害対応報告⽂書⾃動作成機能 ◦ LLM Q&A ChatBot, Pairs Navi
10. ペアーズにおける障害対応プロセスの課題 • そこで新たに、コマンダーの負荷軽減、障害プロセス認知負荷軽減のために様々 な機能提供をおこないました ◦ コマンダーの責務を明確化し、チャンネル作成時に都度⾃動投稿 ▪ インシデントの発⽣ ⾔/作業要員や関連部⾨の招集 ▪ 作業要員のアサインと体制構築、作業担当への指⽰ ▪ ステークホルダーとのコミュニケーション、状況の交通整理（初動状 況報告/中間状況報告） ▪ ポストモーテム⽂書作成、それをもとに障害内容と根本対応の共有 と議論を主導 ◦ チャンネル作成時のコマンダー任命機能 ◦ コマンダーのTODOリマインダー機能 ◦ 障害対応報告⽂書⾃動作成機能 ◦ LLM Q&A ChatBot, Pairs Navi
11. ③ 解決策1 - 障害対応報告書自動生成機能
12. 障害対応報告書⾃動⽣成機能の提供 • コマンダーがステークホルダーへ障害状況を報告する中間報告⽂書を、障害対応 チャンネルのメッセージとチケットの障害情報から⾃動⽣成する機能を提供 ◦ 従来、1から報告書を書かなければならなかった負担や⼯数の削減を⽬指し た • 同様に、振り返りの際に作成するポストモーテム⽂書についても⽣成をサポート ◦ コマンダーが主導する振り返りの負担や⼯数削減を狙うこととした
13. 作成された障害対応報告書サンプル ※実際の報告書ではありません
14. システムアーキテクチャ - 報告書⽣成機能 ※現在のメインの使⽤モデルはClaude 3.5 Sonnet
15. なぜManaged LLM ServiceとしてAmazon Bedrockを採⽤したか • Amazon Elastic Kubernetes Service(EKS) との統合 ◦ 弊社のアプリケーションをホスティングしている環境が Amazon EKS で構 築されているため、IAM Roles for Service Accounts (IRSA) などを駆使して きめ細かい権限設計が可能であること • Managed RAG 機能 ◦ Knowledge bases for Amazon Bedrock などの Managed RAG 機能が利⽤ 可能であり、後述する弊社の LLM Q&A ChatBot での利⽤にも活⽤できるこ と • LLMOps のサポート ◦ モデル評価やプロンプトマネジメントなど、LLMOps で必要な要素が網羅 的に提供されていること
16. 報告書作成シーケンス 障害対応報告書⾃動⽣成機能 チャットツールで 依頼コマンド実⾏ LLM APIが、報告テンプレートと社 内チャットツールのメッセージ、障 害情報から要約を⽣成 Incident Bot が受け付け、 LLM API を呼び出し
17. LLM API実装の⼯夫 ① • データ前処理 ◦ 社内チャットツールのメッセージデータから Bot の発⾔などを取り除き、 必要なメッセージに絞る処理。また、メッセージデータに含まれるタイム スタンプは、対応時系列の項⽬などで使⽤したい形式にあらかじめ変換 ◦ LLM に任せる必要のない単純なデータ処理は、事前に実施しておくこと で、LLM を本質的なタスクに集中させ、⽣成の精度を上げることにつなが る ◦ また、Claude のモデルは命令プロンプトを XML 形式で記述すると⽣成の 精度が上がる傾向にある(※2)ため、メッセージデータを XML 形式に変換し 渡している (※2) 参考: Use XML tags to structure your prompts
18. LLM API実装の⼯夫 ② • バリデーション/リトライ機構 ◦ 使⽤しているドキュメントツールの制約 により、XHTML 形式のデータを⽣成す る必要がある。 ◦ プロンプトで XHTML 形式のデータ⽣成 を指⽰し、バリデーションも実施 ◦ コード側でもバリデーションし、 XHTML形式でなければリトライで再⽣ 成
19. LLM API実装の⼯夫 ③ • LLMに全てを⽣成させない ◦ 状態が遷移しがちでハルシネーショ ンや処理ミスが起こりやすいテンプ レート項⽬ （障害深刻度など）は、 別で保存されているデータを取得し テンプレートに埋め込む ◦ また、静的なテンプレート部分 （注 意事項など）は、⽣成データに後処 理で結合 ◦ LLM が⽣成する必要がない/不得意 な部分は、LLM に⽣成させない
20. この解決策による効果/課題解決 • 対応時間及びコストの短縮 ◦ 障害対応報告書とポストモーテム⽂書の⾃動⽣成により、報告や振り返り にかかる⼯数が約 60 % 削減され、対応時間及びコストが⼤幅に短縮 • 障害対応の⼼理的負担軽減 ◦ コマンダーの役割の⼀部を⾃動化することで、対応負荷と⼼理的負荷を下 げ、新任のコマンダーをアサインしやすく
21. ④ 解決策2 - LLM Q&A ChatBot, Pairs Navi
22. LLM Q&A ChatBot, Pairs Navi の提供 • Pairsの開発、運⽤、機能、障害対応に関する質問を解決するQ&A LLM ChatBot, Pairs Naviを提供 ◦ 障害対応チャンネルが作成されると、Pairs Naviも⾃動でInvite され、いつでも活⽤できる状態に ◦ 障害対応に不慣れな⼈でも簡単に障害対応プロセスをキャッチ アップ可能な状態にし、プロセス認知負荷を下げることを⽬指 した • 1500ページ以上のドキュメント情報を基に構築したRAGの仕組みを活 ⽤し、⼀般的なLLMの知識も踏まえ多⾔語で質問に答える。テキスト だけでなく画像やpdfのインプットにもマルチモーダルに対応。 • そのほかにも、翻訳機能や校正機能も⼀部提供
23. システムアーキテクチャ - Pairs Navi ※現在のメインの使⽤モデルはClaude 3.5 Sonnet/Claude 3 Haiku
24. 活⽤シーケンス - Pairs Navi LLM Q&A ChatBot, Pairs Navi回答⽣成 チャットツールの 投稿最⼤⽂字列で 分割し返答を投稿 チャットツール上で @pairs_naviにメン ション RAGを活⽤して関連 ドキュメントチャンク + 過去の会話を取得 取得したチャンクと過去 の会話を⽤いてプロンプ ト組み⽴て、回答⽣成を 実⾏
25. 活⽤シーケンス - Pairs Navi 以下は⽣成回答サンプル
26. こちらを提供してみたものの...？ • 障害対応⽂脈以外ではある程度使われたが、障害対応チャンネルではほとんど使 われなかった ◦ 通常利⽤であれば従業員の約30%、エンジニア組織の約60%くらいには使 ⽤してもらうことができ、特にオンボーディング⽂脈では多く使われた • 原因の仮説は⼤きく分けて⼆つ ◦ 回答の質が悪いので使われない ▪ こちらにはドキュメントの質への投資、⽣成ロジックの改善、新しい データソースの検討などで随時投資している ◦ 障害対応時、わざわざメンションする余裕がないのでそもそも使えない ▪ ここから、こちらのUI/UX改善策の話をしていく
27. ⼈らしくふるまう⾃律的なAgent Botの探求 • そもそも⼈間は、メンションされなくても困っている⼈間が呟いていたらサポー トすることができる。そのプロセスを参考にChatBotのふるまいとして実装する ことでより実⽤的、かつ緊急時にも使ってもらえる⾃律的なAgent Botとして機 能するのではと考えた • メンション以外のメッセージに対しても、適切に分類し⽣成した回答が課題を解 決できると判定したら、投稿する仕組みの構築を模索し始めた ◦ その際、以下ブログを⾮常に参考にさせていただいた ▪ 社内⽤AIアシスタント「おっさんずナビ」を作った話、そして⼈間ら しく振る舞う重要性を認識した話 ▪ LayerXにおけるLLM以降の業務⾃動化の世界とAi Workforce
28. メンション以外のメッセージへの活⽤シーケンス - Pairs Navi LLM Q&A ChatBot, Pairs Navi回答⽣成 有益だと判定されれ ば、チャットツール の投稿最⼤⽂字列で 分割し返答を投稿 チャットツール上の メッセージを分類 (質問/依頼相談/etc) 分類結果が質問であれ ば、メンション同様 メッセージを⽣成する ⽣成が本当にユーザー に有益で課題解決でき るかを判定 実⾏処理を分類、回答⽣成、判定、投稿に分解し、判定OKまで辿り着いたら初めて投稿する仕組みを導⼊
29. メンション以外のメッセージへの活⽤シーケンス - Pairs Navi • 以下は回答サンプル ◦ 直接聞かれたわけではなく⾃律的に返信する内容なので、急な返信に対す るエクスキュースを必ずつけるようにしている
30. 分類タスクの⼯夫 • 全ての投稿メッセージに実⾏するので、⽐較的 コストの安いClaude 3 Haikuを活⽤ ◦ それぞれの分類カテゴリに対する例⽰を いれると精度が上がる • 質問と、依頼や相談は分けてカテゴライズする ◦ 他⼈への依頼や相談に関して回答⽣成ま でいくとたまに不必要なメッセージまで 判定OKで投稿するケースがあったので、 現在は質問カテゴリのみ回答⽣成ステッ プへ • 分類系のタスクは、temperatureは0を推奨
31. 回答⽣成タスクの⼯夫 ① • 回答には根拠となるドキュメントのタイ トル/URLは必ず含むように設計 ◦ Knowledge Bases for Amazon BedrockならベクトルDBに取り込む ドキュメントにmetadataを付与で きるので、DailyのSync Batchで必 要なドキュメントのタイトル/URL の組み⽴てに必要な情報を付与する ことで、データ取得の際に取得して チャンクと⼀緒に渡すことが可能に
32. 回答⽣成タスクの⼯夫 ② • <scratchpad> tagの中で、まず与えられた情 報を⽣成前に整理しさせ、それを踏まえて回 答⽣成させるCoT(※3)を実施するプロンプト で精度を改善 ◦ Anthropic Prompt Generator(※4) を使 ⽤してプロンプトを⽣成する中で発⾒し たテクニック (※3) Chain of Thoughtというプロンプティングテクニック 参考: Let Claude think (chain of thought prompting) to increase performance (※4) 参考: Automatically generate first draft prompt templates
33. 回答⽣成タスクの⼯夫 ③ • 回答⽣成後は、ユーザーに評価してアノ テーションしてもらう設計 ◦ 5段階評価 ◦ 評価が1~3のものについては、よりい い回答⽣成ができるようにチューニン グするケースとして活⽤ ◦ 評価が4~5の物に関しては、 LLM-as-a-Judgeなどで活⽤する評価 データセットとしての利⽤を想定
34. 判定タスクの⼯夫 • ペアーズ、エウレカや障害対応に関連する課 題や困りごとを解決しない投稿は評価しない • 直接Botに尋ねられたメッセージでないこと をプロンプトで強調し、それでも回答に値す るかを判断させている。誤送信はそれなりに ノイズになるのでかなり厳し⽬に判定 • 判定も分類。分類系のタスクは、 temperatureは0を推奨
35. この解決策による効果/課題解決 • メンションメッセージへの回答⽣成 ◦ 障害対応⽂脈だとほとんど使われなかった ▪ リリースから半年間で、全体の利⽤回数は約1500回。そのうち、障害 に関する回答は全体の5%、約70回 ▪ 障害対応中以外にチケットの切り⽅や対応⽅法、報告⽅法を聞くケー スなどはあったので、少しは認知負荷の改善には寄与しているが、⼗ 分とは⾔えない • メンションメッセージ以外への回答⽣成 ◦ 導⼊して効果計測できるほど時間が経過していないのもあるが、こちらも まだまだ障害プロセス認知負荷軽減という観点で不⼗分だと考えている ◦ 引き続き、利⽤者が障害対応などの緊急状況でも使えるようにUI/UX的な改 善もしつつ、ドキュメントだけでなくログやコードなどの情報からもサ ポートできるようにしていく
36. ⑤ まとめ/今後の展望
37. まとめ • コマンダー負荷軽減、障害プロセス認知負荷軽減を⽬的に提供した⼆つの機能の 話をした ◦ 障害対応報告書⾃動⽣成機能 ◦ LLM Q&A ChatBot, Pairs Navi • ⽣成AIのシステム活⽤の⼤きなポイントは以下の3つ ◦ ⽣成AI以前のシステムアーキテクチャ、データ整備への投資を⼤事にする ▪ 報告書⾃動⽣成機能とRAGを⽤いたPair Naviともに、社内ツールへの 情報集約や障害対応システムへの事前投資が⽣きた形 ◦ ⽣成AIに⼀度に多くのことをやらせない ▪ データ前処理、ルール処理、マルチモデルにタスク分解して組み合わ せる設計が重要 ◦ 社内ツールへの活⽤でも、UI/UX設計を最重要視する ▪ 社内ツールはプロダクトであり、従業員は顧 である
38. • 障害対応報告書⾃動⽣成機能 ◦ Anthropic Tool use(function calling)の導⼊検討 ▪ プログラマブルに扱いやすいレスポンスを返却させ、データのバリ デーションとリトライの処理を簡潔に • LLM Q&A ChatBot, Pairs Navi ◦ Agents for Amazon Bedrockの導⼊検討 ▪ 分類、データ取得、回答⽣成、判定などを⾃律的に必要な回数繰り返 し実⾏するAgent形式への移⾏ • 継続評価の仕組み導⼊ ◦ 評価データセット管理 ◦ LLM-as-a-Judge 今後の展望 - 実装⾯
39. • 関連ログやコードベースを抽出しながら、障害調査や根本原因分析(RCA)をサ ポートする機能提供 • チャット/チケット内容から残りTODOを推測し、実⾏サポートする機能提供 今後の展望 - 機能⾯
40. • インシデントコマンダーとは？〜現代の IT運用には必須！その役割と理由〜 • Amazon Bedrock を⽤いた障害対応報告書とポストモーテム⽂書⾃動作成 ~ ペ アーズ における⽣成 AI 実装解説 • 社内⽤AIアシスタント「おっさんずナビ」を作った話、そして⼈間らしく振る舞 う重要性を認識した話 • プロンプトエンジニアリングの概要 • LayerXにおけるLLM以降の業務⾃動化の世界とAi Workforce 参考資料
41. We’re hiring! ペアーズではエンジニアを積極採⽤中！ カジュアル⾯談もお待ちしております！ (X: @fukubaka0825)