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

Slide 1

Slide 1 text

ペアーズにおけるAmazon Bedrockを⽤いた障害対応⽀援⽣成AIツールの導⼊事例 2024年11⽉15⽇ AWSウェビナー

Slide 2

Slide 2 text

About Me Nari | Takashi Narikawa（@fukubaka0825） ● 株式会社エウレカ ○ 2020年に⼊社 ■ SRE Team -> AI Team ○ MLOps Engineer ○ サウナ、筋トレ、⿇雀、ボルダリングが好き

Slide 3

Slide 3 text

Agenda 1. ペアーズにおける障害対応プロセス概要 2. ペアーズにおける障害対応プロセスの課題 3. 解決策1 - 障害対応報告書⾃動⽣成機能 4. 解決策2 - LLM Q&A ChatBot, Pairs Navi 5. まとめ/今後の展望

Slide 4

Slide 4 text

①ペアーズにおける障害対応プロセス概要

Slide 5

Slide 5 text

ペアーズにおける障害対応プロセス概要 ● ペアーズでは、障害対応を円滑に進めるためのサポートを⾏う障害対応管理システムを内製し、そちらをメインに活⽤して対応 ○ 社内チャット/チケット/ドキュメントツールと連携 ○ 障害第⼀報と対応チャンネル作成から、必要な操作がほぼチャット上のコマンドで可能になっている ○ 専⽤の障害対応チャンネルにやりとりを集約

Slide 6

Slide 6 text

ペアーズにおける障害対応プロセス概要 ● ⾃分が⼊社してから、ここまでSRE Teamと協⼒し、様々な改善を⾏って便利にしてきてある程度の仕組みにはなっていた ○ 旧システムが退職者に属⼈化してそのまま停⽌していたため、Amazon API Gateway + AWS Lambdaにリニューアルしてチームでメンテできる形へ ○ チャットツールで障害報告すると、専⽤チャンネルが⾃動で作られ、必要なステークホルダーを⾃動招集 ○ ポストモーテム推進及びテンプレートの整備 ○ 障害深刻度をSEV1~3まで定義し、関係者と合意。深刻度によって、対応フローを分岐させ、適切な対応をおこなえるように

Slide 7

Slide 7 text

② ペアーズにおける障害対応プロセスの課題

Slide 8

Slide 8 text

ペアーズにおける障害対応プロセスの課題 ● ある程度システムもプロセスも整ってはきましたが、依然課題は⼭積みの状況 ○ インシデントコマンダー(※1) に関する課題 ■ 慣れてる⼈しか引き受けられない ■ そもそもコマンダーがアサインされずに進むことがある ■ コマンダーの責務が多すぎる課題、そもそも責務が認識されない ○ 障害対応プロセスがかなり煩雑になってきて、認知負荷が⾼い課題 ■ 慣れてる⼈しか障害対応をスムーズに⾏えない。新しい⼈も経験が積みづらいので状況が改善しない。 (※1) 障害対応の司令塔。以降コマンダー参考: インシデントコマンダーとは？〜現代のIT運⽤には必須！その役割と理由〜

Slide 9

Slide 9 text

ペアーズにおける障害対応プロセスの課題 ● そこで新たに、コマンダーの負荷軽減、障害プロセス認知負荷軽減のために様々な機能提供をおこないました ○ コマンダーの責務を明確化し、チャンネル作成時に都度⾃動投稿 ■ インシデントの発⽣⾔/作業要員や関連部⾨の招集 ■ 作業要員のアサインと体制構築、作業担当への指⽰ ■ ステークホルダーとのコミュニケーション、状況の交通整理（初動状況報告/中間状況報告） ■ ポストモーテム⽂書作成、それをもとに障害内容と根本対応の共有と議論を主導 ○ チャンネル作成時のコマンダー任命機能 ○ コマンダーのTODOリマインダー機能 ○ 障害対応報告⽂書⾃動作成機能 ○ LLM Q&A ChatBot, Pairs Navi

Slide 10

Slide 10 text

Slide 11

Slide 11 text

③ 解決策1 - 障害対応報告書自動生成機能

Slide 12

Slide 12 text

障害対応報告書⾃動⽣成機能の提供 ● コマンダーがステークホルダーへ障害状況を報告する中間報告⽂書を、障害対応チャンネルのメッセージとチケットの障害情報から⾃動⽣成する機能を提供 ○ 従来、1から報告書を書かなければならなかった負担や⼯数の削減を⽬指した ● 同様に、振り返りの際に作成するポストモーテム⽂書についても⽣成をサポート ○ コマンダーが主導する振り返りの負担や⼯数削減を狙うこととした

Slide 13

Slide 13 text

作成された障害対応報告書サンプル ※実際の報告書ではありません

Slide 14

Slide 14 text

システムアーキテクチャ - 報告書⽣成機能 ※現在のメインの使⽤モデルはClaude 3.5 Sonnet

Slide 15

Slide 15 text

なぜ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 で必要な要素が網羅的に提供されていること

Slide 16

Slide 16 text

報告書作成シーケンス障害対応報告書⾃動⽣成機能チャットツールで依頼コマンド実⾏ LLM APIが、報告テンプレートと社内チャットツールのメッセージ、障害情報から要約を⽣成 Incident Bot が受け付け、 LLM API を呼び出し

Slide 17

Slide 17 text

LLM API実装の⼯夫 ① ● データ前処理 ○ 社内チャットツールのメッセージデータから Bot の発⾔などを取り除き、必要なメッセージに絞る処理。また、メッセージデータに含まれるタイムスタンプは、対応時系列の項⽬などで使⽤したい形式にあらかじめ変換 ○ LLM に任せる必要のない単純なデータ処理は、事前に実施しておくことで、LLM を本質的なタスクに集中させ、⽣成の精度を上げることにつながる ○ また、Claude のモデルは命令プロンプトを XML 形式で記述すると⽣成の精度が上がる傾向にある(※2)ため、メッセージデータを XML 形式に変換し渡している (※2) 参考: Use XML tags to structure your prompts

Slide 18

Slide 18 text

LLM API実装の⼯夫 ② ● バリデーション/リトライ機構 ○ 使⽤しているドキュメントツールの制約により、XHTML 形式のデータを⽣成する必要がある。 ○ プロンプトで XHTML 形式のデータ⽣成を指⽰し、バリデーションも実施 ○ コード側でもバリデーションし、 XHTML形式でなければリトライで再⽣成

Slide 19

Slide 19 text

LLM API実装の⼯夫 ③ ● LLMに全てを⽣成させない ○ 状態が遷移しがちでハルシネーションや処理ミスが起こりやすいテンプレート項⽬（障害深刻度など）は、別で保存されているデータを取得しテンプレートに埋め込む ○ また、静的なテンプレート部分（注意事項など）は、⽣成データに後処理で結合 ○ LLM が⽣成する必要がない/不得意な部分は、LLM に⽣成させない

Slide 20

Slide 20 text

この解決策による効果/課題解決 ● 対応時間及びコストの短縮 ○ 障害対応報告書とポストモーテム⽂書の⾃動⽣成により、報告や振り返りにかかる⼯数が約 60 % 削減され、対応時間及びコストが⼤幅に短縮 ● 障害対応の⼼理的負担軽減 ○ コマンダーの役割の⼀部を⾃動化することで、対応負荷と⼼理的負荷を下げ、新任のコマンダーをアサインしやすく

Slide 21

Slide 21 text

④ 解決策2 - LLM Q&A ChatBot, Pairs Navi

Slide 22

Slide 22 text

LLM Q&A ChatBot, Pairs Navi の提供 ● Pairsの開発、運⽤、機能、障害対応に関する質問を解決するQ&A LLM ChatBot, Pairs Naviを提供 ○ 障害対応チャンネルが作成されると、Pairs Naviも⾃動でInvite され、いつでも活⽤できる状態に ○ 障害対応に不慣れな⼈でも簡単に障害対応プロセスをキャッチアップ可能な状態にし、プロセス認知負荷を下げることを⽬指した ● 1500ページ以上のドキュメント情報を基に構築したRAGの仕組みを活⽤し、⼀般的なLLMの知識も踏まえ多⾔語で質問に答える。テキストだけでなく画像やpdfのインプットにもマルチモーダルに対応。 ● そのほかにも、翻訳機能や校正機能も⼀部提供

Slide 23

Slide 23 text

システムアーキテクチャ - Pairs Navi ※現在のメインの使⽤モデルはClaude 3.5 Sonnet/Claude 3 Haiku

Slide 24

Slide 24 text

活⽤シーケンス - Pairs Navi LLM Q&A ChatBot, Pairs Navi回答⽣成チャットツールの投稿最⼤⽂字列で分割し返答を投稿チャットツール上で @pairs_naviにメンション RAGを活⽤して関連ドキュメントチャンク + 過去の会話を取得取得したチャンクと過去の会話を⽤いてプロンプト組み⽴て、回答⽣成を実⾏

Slide 25

Slide 25 text

活⽤シーケンス - Pairs Navi 以下は⽣成回答サンプル

Slide 26

Slide 26 text

こちらを提供してみたものの...？ ● 障害対応⽂脈以外ではある程度使われたが、障害対応チャンネルではほとんど使われなかった ○ 通常利⽤であれば従業員の約30%、エンジニア組織の約60%くらいには使⽤してもらうことができ、特にオンボーディング⽂脈では多く使われた ● 原因の仮説は⼤きく分けて⼆つ ○ 回答の質が悪いので使われない ■ こちらにはドキュメントの質への投資、⽣成ロジックの改善、新しいデータソースの検討などで随時投資している ○ 障害対応時、わざわざメンションする余裕がないのでそもそも使えない ■ ここから、こちらのUI/UX改善策の話をしていく

Slide 27

Slide 27 text

⼈らしくふるまう⾃律的なAgent Botの探求 ● そもそも⼈間は、メンションされなくても困っている⼈間が呟いていたらサポートすることができる。そのプロセスを参考にChatBotのふるまいとして実装することでより実⽤的、かつ緊急時にも使ってもらえる⾃律的なAgent Botとして機能するのではと考えた ● メンション以外のメッセージに対しても、適切に分類し⽣成した回答が課題を解決できると判定したら、投稿する仕組みの構築を模索し始めた ○ その際、以下ブログを⾮常に参考にさせていただいた ■ 社内⽤AIアシスタント「おっさんずナビ」を作った話、そして⼈間らしく振る舞う重要性を認識した話 ■ LayerXにおけるLLM以降の業務⾃動化の世界とAi Workforce

Slide 28

Slide 28 text

メンション以外のメッセージへの活⽤シーケンス - Pairs Navi LLM Q&A ChatBot, Pairs Navi回答⽣成有益だと判定されれば、チャットツールの投稿最⼤⽂字列で分割し返答を投稿チャットツール上のメッセージを分類 (質問/依頼相談/etc) 分類結果が質問であれば、メンション同様メッセージを⽣成する⽣成が本当にユーザーに有益で課題解決できるかを判定実⾏処理を分類、回答⽣成、判定、投稿に分解し、判定OKまで辿り着いたら初めて投稿する仕組みを導⼊

Slide 29

Slide 29 text

メンション以外のメッセージへの活⽤シーケンス - Pairs Navi ● 以下は回答サンプル ○ 直接聞かれたわけではなく⾃律的に返信する内容なので、急な返信に対するエクスキュースを必ずつけるようにしている

Slide 30

Slide 30 text

分類タスクの⼯夫 ● 全ての投稿メッセージに実⾏するので、⽐較的コストの安いClaude 3 Haikuを活⽤ ○ それぞれの分類カテゴリに対する例⽰をいれると精度が上がる ● 質問と、依頼や相談は分けてカテゴライズする ○ 他⼈への依頼や相談に関して回答⽣成までいくとたまに不必要なメッセージまで判定OKで投稿するケースがあったので、現在は質問カテゴリのみ回答⽣成ステップへ ● 分類系のタスクは、temperatureは0を推奨

Slide 31

Slide 31 text

回答⽣成タスクの⼯夫 ① ● 回答には根拠となるドキュメントのタイトル/URLは必ず含むように設計 ○ Knowledge Bases for Amazon BedrockならベクトルDBに取り込むドキュメントにmetadataを付与できるので、DailyのSync Batchで必要なドキュメントのタイトル/URL の組み⽴てに必要な情報を付与することで、データ取得の際に取得してチャンクと⼀緒に渡すことが可能に

Slide 32

Slide 32 text

回答⽣成タスクの⼯夫 ② ● tagの中で、まず与えられた情報を⽣成前に整理しさせ、それを踏まえて回答⽣成させるCoT(※3)を実施するプロンプトで精度を改善 ○ Anthropic Prompt Generator(※4) を使⽤してプロンプトを⽣成する中で発⾒したテクニック (※3) Chain of Thoughtというプロンプティングテクニック参考: Let Claude think (chain of thought prompting) to increase performance (※4) 参考: Automatically generate ﬁrst draft prompt templates

Slide 33

Slide 33 text

回答⽣成タスクの⼯夫 ③ ● 回答⽣成後は、ユーザーに評価してアノテーションしてもらう設計 ○ 5段階評価 ○ 評価が1~3のものについては、よりいい回答⽣成ができるようにチューニングするケースとして活⽤ ○ 評価が4~5の物に関しては、 LLM-as-a-Judgeなどで活⽤する評価データセットとしての利⽤を想定

Slide 34

Slide 34 text

判定タスクの⼯夫 ● ペアーズ、エウレカや障害対応に関連する課題や困りごとを解決しない投稿は評価しない ● 直接Botに尋ねられたメッセージでないことをプロンプトで強調し、それでも回答に値するかを判断させている。誤送信はそれなりにノイズになるのでかなり厳し⽬に判定 ● 判定も分類。分類系のタスクは、 temperatureは0を推奨

Slide 35

Slide 35 text

この解決策による効果/課題解決 ● メンションメッセージへの回答⽣成 ○ 障害対応⽂脈だとほとんど使われなかった ■ リリースから半年間で、全体の利⽤回数は約1500回。そのうち、障害に関する回答は全体の5%、約70回 ■ 障害対応中以外にチケットの切り⽅や対応⽅法、報告⽅法を聞くケースなどはあったので、少しは認知負荷の改善には寄与しているが、⼗分とは⾔えない ● メンションメッセージ以外への回答⽣成 ○ 導⼊して効果計測できるほど時間が経過していないのもあるが、こちらもまだまだ障害プロセス認知負荷軽減という観点で不⼗分だと考えている ○ 引き続き、利⽤者が障害対応などの緊急状況でも使えるようにUI/UX的な改善もしつつ、ドキュメントだけでなくログやコードなどの情報からもサポートできるようにしていく

Slide 36

Slide 36 text

⑤ まとめ/今後の展望

Slide 37

Slide 37 text

まとめ ● コマンダー負荷軽減、障害プロセス認知負荷軽減を⽬的に提供した⼆つの機能の話をした ○ 障害対応報告書⾃動⽣成機能 ○ LLM Q&A ChatBot, Pairs Navi ● ⽣成AIのシステム活⽤の⼤きなポイントは以下の3つ ○ ⽣成AI以前のシステムアーキテクチャ、データ整備への投資を⼤事にする ■ 報告書⾃動⽣成機能とRAGを⽤いたPair Naviともに、社内ツールへの情報集約や障害対応システムへの事前投資が⽣きた形 ○ ⽣成AIに⼀度に多くのことをやらせない ■ データ前処理、ルール処理、マルチモデルにタスク分解して組み合わせる設計が重要 ○ 社内ツールへの活⽤でも、UI/UX設計を最重要視する ■ 社内ツールはプロダクトであり、従業員は顧である

Slide 38

Slide 38 text

● 障害対応報告書⾃動⽣成機能 ○ Anthropic Tool use(function calling)の導⼊検討 ■ プログラマブルに扱いやすいレスポンスを返却させ、データのバリデーションとリトライの処理を簡潔に ● LLM Q&A ChatBot, Pairs Navi ○ Agents for Amazon Bedrockの導⼊検討 ■ 分類、データ取得、回答⽣成、判定などを⾃律的に必要な回数繰り返し実⾏するAgent形式への移⾏ ● 継続評価の仕組み導⼊ ○ 評価データセット管理 ○ LLM-as-a-Judge 今後の展望 - 実装⾯

Slide 39

Slide 39 text

● 関連ログやコードベースを抽出しながら、障害調査や根本原因分析(RCA)をサポートする機能提供 ● チャット/チケット内容から残りTODOを推測し、実⾏サポートする機能提供今後の展望 - 機能⾯

Slide 40

Slide 40 text

● インシデントコマンダーとは？〜現代の IT運用には必須！その役割と理由〜 ● Amazon Bedrock を⽤いた障害対応報告書とポストモーテム⽂書⾃動作成 ~ ペアーズにおける⽣成 AI 実装解説 ● 社内⽤AIアシスタント「おっさんずナビ」を作った話、そして⼈間らしく振る舞う重要性を認識した話 ● プロンプトエンジニアリングの概要 ● LayerXにおけるLLM以降の業務⾃動化の世界とAi Workforce 参考資料

Slide 41

Slide 41 text

We’re hiring! ペアーズではエンジニアを積極採⽤中！カジュアル⾯談もお待ちしております！ (X: @fukubaka0825)

Slide 42

Slide 42 text

No content