[SRE NEXT 2023 CfP]SREとして向き合うGenerative AI

Transcript

1. SREとして向き合うLLM 株式会社スリーシェイク 橋本玄基
2. 自己紹介｜橋本玄基 2 所属: 株式会社スリーシェイク Sreake事業部 経歴: 18年新卒で金融系事業者でのオンプレ運用 -> プログラミング教育系スタートアップで Pythonバックエンド -> スリーシェイクjoin なぜこの発表？: ・別にAIOpsのスペシャリストでも機械学習詳しくもな い。 ・半年休職しているなか、明らかにはてなブックマーク のトップエントリがLLM,ChatGPT, Generative AIに染 まっていくタイミングがあり、なにか社会が変わったん だなと震える。 ・復職後SREとしてのLLM活用の検討・検証というふんわ りした名目で色々触ってみた。 →同じように何か流行ってるけどどうなんだろう？とい う人に知見を共有したい。
3. 本日の想定視聴者とお話しすること Copyright © 3-shake, Inc. All Rights Reserved. LLMの原理 LLMのできること SREとして考えるGenerative AIの使い所 話すこと 話さないこと LLMを利用した詳細な実装方法 ・何かChatGPTとか流行ってるのは知ってる ・自分の仕事とはいまいち紐づかない ・とはいえ忙しいので触ってる暇がない 想定視聴者
4. 01. LLMとは？ →LLMってなんでこんなに騒がれてるんだっけ？を思い出す 02. LLMのテクニック、弱点と解決手法 →実際に使うときに必要なキーワードを知る 03. SRE活動の中で活かすLLM →この辺に使えそうだということを把握する、社内で使えないか考える a. 情報摂取効率の向上 →SREを増やすのって難しいの助けになるかも？ b. toil自動化を代替する →LLMの得意な自動化を探る 目次 4
5. LLMとは？ 5 01
6. ChatGPT公開によって突如盛り上がったGenerative AI(LLM) 6 “Generative AI”のgoogleトレンド(https://trends.google.co.jp/trends/explore?geo=JP&q=Generative%20AI&hl=ja) “chatgpt”のgoogleトレンド(https://trends.google.co.jp/trends/explore?geo=JP&q=ChatGPT&hl=ja)
7. 一般的な機械学習: 固定のタスクに 対して望ましい出力を得るように 学習すること。 これまでの機械学習モデルとLLMモデルの違い(何で騒がれてる？) 7 LLM: 入出力がテキストということ 以外は汎用的なタスクが可能(翻 訳、計算、要約、etc…) 100*100pxの 白黒画像を犬 か猫かを高精 度で分類します n文字以内の文 字列にたいして いい感じに答え ます すなわち学習というフェーズをス キップして誰でもAIを使える時代 の到来 学習フェーズのコストを 下げるために様々なサー ビスが登場 →とはいえハードルの高 いタスク
8. LLMのテクニック、弱点と解決手法 8 02
9. LLMへは質問文(prompt)を適切に作成して渡す必要がある 9 LLMへの質問(input)をPromptと呼ぶ。 基本的にはPromptの作成ガイドを各社提供しているためそれにのっ とる。 OpenAI: GPT best practices(https://platform.openai.com/docs/guides/gpt-best-practices/gpt-best-practices) Google: Introduction to prompt design(https://cloud.google.com/vertex-ai/docs/generative-ai/learn/introduction-prompt-design)
10. 一般的なpromptテクニックをいくつか 10 - 質問と回答の例を提示する - 役割を与える - 情報はブロックごとに分割する
11. 一般的なpromptテクニックをいくつか 11 - 質問と回答の例を提示する - 役割を与える - 情報はブロックごとに分割する 例を提示することで回答フォーマットを ある程度コントロールできる
12. 一般的なpromptテクニックをいくつか 12 - 質問と回答の例を提示する - 役割を与える - 情報はブロックごとに分割する 背景情報を追記することで返答に変化がある
13. 一般的なpromptテクニックをいくつか 13 - 質問と回答の例を提示する - 役割を与える - 情報はブロックごとに分割する
14. LLMの弱点は大きく2つ 14 ①入力と出力の長さに制限がある。 -> 大規模なテキストデータは送れない。 ②何でもは知らない、知ってることだけ(Knowledge cutoff) -> 学習データ以降の事象やプライベートな情報はわからない、場合 によっては幻覚(hallucination)を見せる。 また、実際のユースケースでは社内の情報や最新の情報が必要にな ることが多い。
15. 解決策①制限が大きいモデルを利用する 最近は長文用のモデルが各社提供されはじめている。お値段も長い分高くなる傾 向。 入出力長さ制限への対応 15 基本モデル 長文用モデル gpt-3.5turbo 4k 入力 $0.0015 / 1k tokens 返答 $0.002 / 1k tokens 16k 入力 $0.003 / 1k tokens 返答 $0.004 / 1k tokens gpt-4 8k 入力 $0.03/1k tokens 返答 $0.06/1k tokens 32k 入力 $0.06/1k tokens 返答 $0.12/1k tokens chat-bison 4k $0.0005 / 1k characters 32k $0.0010 / 1k characters OpenAI/Googleの料金設定
16. 解決策②質問文を要約して渡す 再帰的要約: 情報の順序を保って要約できる。 ※順序性がない場合は分割してそれぞれをLLMにわたす形でもOK 入出力長さ制限への対応 16 渡せる文字数 で分割 LLMで要約 要約
17. 解決策① 質問に組み込む 背景情報(context)として情報を事前に与えることで知らないことも答え られるように。ただし、文字数制限もあるため、汎用性が低い。 モデルが知らないことを利用する 17
18. 解決策② ファインチューニング 学習済みモデルに対して別のデータで再学習を行うこと。 モデルが知らないことを利用する 18 引用: ファインチューニング – 【AI・機械学習用語集】 (https://zero2one.jp/ai-word/finetuning/) 現時点では、出力形式の統一(口調 など)は行える例が出ているが、特 定の知識を学習させることを成功さ せている例はほとんどないのが現 状。。。
19. 解決策③ RAG(Retrieval Augmented Generation) 質問に応じて、データソースから関連する情報を取得して事前情報とし て埋め込む。 モデルが知らないことを利用する 19 文書 データソース 文書ベクトル DB Chat App LLM 質問 質問に 近い内容の 文章を検索 質問+文章 回答 embedding
20. SRE活動の中で活かすLLM 20 03
21. LLMの得意から考える活かしどころ 21 得意なこと - 要約する - 一般的な質問に答える - 指定通りの文章を作成する - 質問に近しい文書を探す (RAG) 活用①: 情報摂取効率の向上 活用②: toil削減のための自動化実装を代替する
22. 活用①: 情報摂取効率の向上 22 RAGを活用して以下のような課題に対して情報を得やすくする形で提供する(例えばslackへの埋 め込みchat botなど)ことで、SREingをよりハードルの低い作業へ 例①: SRE必要な知識多すぎる問題: どんなにすごい人が入社してもキャッチアップが必要なドメ イン知識、独自の情報についての検索性能を上げることで立ち上がりの早める 例②: オンコールできる人教育しなきゃ問題: 通知文章から過去のポストモーテム資料や障害対 応手順書を検索してアラートと一緒に教えてくれることでオンコール担当者の最低レベルを下 げ、当番制を実行しやすくする
23. Vertex AI Searchを利用した実装例 23 PaLM2に聞いた回答
24. Vertex AI Searchを利用した実装例 24 ↓秘匿情報管理方法の比較をしているドキュメン トがあり、その中で記載があるSOPSを利用した暗 号化について言及されている 社内wikiを渡したVertex AI Searchの回答
25. 活用②: toil削減のための自動化実装を代替する 25 SRE本5章より toilの定義「サービスを稼働させることに直結している作業で、繰り返されたり、手作業 だったりするもの」 toilの特徴 - 手作業であること - 繰り返されること - 自動化できること →自動化のコストが高くてそのままにして - 戦術的であること いるようなタスクをLLMに任せたい - 長期的な価値を持たないこと - サービスの成長に対してO(n)であること
26. 活用②: toil削減のための自動化実装を代替する 26 定期的に行われるレポートの1stインサイトをLLMに任せる。 e.g. ・コスト ・パフォーマンス ・キャパシティ Google Cloudのコストインサイトを定期的にslackへ通知してくれる仕組みの検証例 PaLM API for textで作るGoogle Cloudコストチェッカー (https://sreake.com/blog/google-cloud-cost-check-with-palm-api-for-text/)
27. 活用②: toil削減のための自動化実装を代替する 27 最新化が定期的に必要なドキュメンテーションのメンテナンスをLLMに任せる e.g. ・構成図 ・権限管理 OpenAI API を利用して Terraform から構成図っ ぽい Mermaid を出力してくれるコマンドを作っ た話 (https://sreake.com/blog/mermaid-with-open ai-api/) 自作した構成図 OpenAIがterraformから出したmermaid (登場人物は合っているが依存関係はterraformに引っ張られている) 精度が上がってくるとX as Codeが重要視されるかもしれない もしくはInputが言語以外に多彩に対応してくる →ChatGPTで画像入力が順次公開中、クラス図や画面イメージから ChatGPTでコード化する記事が登場 画像対応ChatGPTで設計図からコードの世界が実現しててやばい (https://nowokay.hatenablog.com/entry/2023/09/28/095849)
28. 活用②: toil削減のための自動化実装を代替する 28 最新化が定期的に必要なドキュメンテーションのメンテナンスをLLMに任せる e.g. ・構成図 ・権限管理 OpenAI APIを利用してパブリッククラウド の権限要約をしてくれるCLIコマンドを作 成した (https://sreake.com/blog/summarize-p ermission-with-openai/) code管理されているものに ついて、エンジニア <> 非エンジニ アの通訳をLLMによって自動化す る。
29. まとめ 29 • SREとしてGenerative AI(≒LLM)を活用する2つの提案 ◦ 情報摂取効率を上げる ▪ ナレッジの検索性能を向上させる • ドメイン知識の差分をなくしていく • オンコール対応の難易度を下げる など ◦ toilの実装を代替する ▪ “自動化可能”というtoilの定義からもう1段階広い領域の自動化を考える • (コストやパフォーマンス)レポートのインサイトをまとめる • ドキュメンテーションの一部自動化　　　　　　　　　　　など • LLMに任せる作業が増えるとX as Codeが進んでいくかも？ • 使いたいときに役立ちそうなキーワードたち ◦ トークン制限、再帰的要約/RAG(Retrieval Augmented Generation) ◦ langchain(発表には登場していないが、細々とした実装に必要なパー ツがまとまったpython/js/tsライブラリ)