## Summary #SRE論文紹介 AWSのAI研究グループによるデータベースのデバッギングにLLMを応用するシステムの提案論文。DBのデバッギングはそのDBの文脈を踏まえる必要があるが、GPT-4の応答は一般的なベストプラクティスしか出力しない。RAGを用いるにも、非構造化テキストであるマルチモーダルデータに対してどのようにRAGを応用するかは自明ではない。提案するLLM駆動の自律型DBデバッグエージェントは、文脈を補完するためのGrounding、引用を生成するためのVerification、高リスクのアクションを強調するAffordance、改善のためのフィードバックを収集可能なFeedbackの4つの特性をもつ。合計6.25MトークンのAurora PostgreSQLとMySQLのwaitイベントドキュメントと、1分間の粒度で7日間かけて収集された合計250のDBメトリクスを用いて、GPT-3.5を基にした提案システムとGPT-4を比較した結果、人間による応答のスコア評価では、Pandaは信頼度、理解度、有用度においてGPT-4を凌駕した。 [CIDR'24] Panda: Performance Debugging for Databases using LLM Agents https://www.amazon.science/publications/panda-performance-debugging-for-databases-using-llm-agents ## Memo - AWS AI LabsによるCIDR'24の6pの会議論文。第１著者は、Amazon DevOps Guru for RDSに関わっていた https://svikramank.github.io/ 。Amazon CTO Werner VogelsがXで紹介している。 https://twitter.com/Werner/status/1752695865243001008。 - DBのデバッギングは、常に文脈を踏まえる必要があり、非構造化テキストであるマルチモーダルデータ（非構造化ログ、過去のチケット、トラブルシューティング文書、テレメトリ）の分析が必要である。 - しかし、GPTなどの[[LLM]]のデバッギングの質問に対する応答は、技術的に正しいが、ほとんどすべての状況において当てはまる事実かベストプラクティスに過ぎない。具体例としてFig.1の左側に[[GPT-4]]の応答が記載されている。文脈を補完するために、[[RAG]]が用いられるが、マルチモーダルデータに対してRAGを適用する確立された方法は知られていない。 - ![[Pasted image 20240215155403.png|600]] - 信頼できる応答のためには、Trust（知識の由来）、Impact（推薦された変更を行ったときの影響）、Feedback（推薦に対する良し悪し）、Risk（Drop tableなど危険性があるか？）の懸念がある。そこで、「正確で検証可能、かつ実行可能で有用な推奨を生成できる実運用中のデバッグ用LLMを安全に展開するために必要な構成要素は何か？」が問われる。 - 提案するLLM駆動の自律型DBデバッグエージェントは、文脈を補完するためのGrounding、引用を生成するためのVerification、高リスクのアクションを強調するAffordance、改善のためのフィードバックを収集可能なFeedbackの4つの特性をもつ。 - Pandaのアーキテクチャは、質問がDBデバッギングに関連するかどうかの検証機構と、これらの４特性をそれぞれ実現する機構とあわせて５つのコンポーネントから成る。 - Fig.2: Panda Architecture![[Pasted image 20240227212624.png|600]] - **QVA**: RAGを用いて、類似度指標の閾値スコアを0.85としてクエリを検証する。 - **Grouding**: ユーザーのクエリから適切なコンテキストを構築する。Globalとして「この問題は通常どのように解決されるのか」「どのような指標を見るべきか」「ベストプラクティス」などに関する情報を収集し、LocalとしてユーザーのDB、最近のクエリ、設定などを収集する。関連文書を抽出する文書レトリバー、テレメトリから特徴を抽出し、テキストに変換するテレメトリ-2-テキスト(T2T)、およびプロンプトを補強するためにこれらすべてを組み合わせるコンテキスト集約器から構成される - 文書検索 - 関連するトラブルシューティング文書や過去のチケットをRAGアプローチで取得する。 - 特徴抽出 - 検索された文書からメトリクス名リストのうち類似度の高いtop-k個(k=3)の関連メトリクスを特定する。メトリクス名から生の時系列データをストレージから取得する。 - [[2020__Signal-Processing__Selective review of offline change point detection methods]]のオフライン変化点検知アルゴリズムにより、デバッグに関連する特徴（変化点時刻？）を抽出する。各メトリクスについて、トレンド、季節性、平均、p95、相関スコアの特徴を抽出し、問題のあるメトリクスの特定に使う。少なくとも１つでもクエリ統計量が異常と判定された問題のあるSQLクエリも特定される。 - 問題と判断されたクエリの生のSQL文と、スキーマを収集し、インデックスの追加などを推薦をする。 - コンテキスト集約 - 抽出された特徴量はすべて、 構造化されたオブジェクト(例:JSON)の形でテキストとして保存される。大きなドキュメントをさらに小さなチャンクに分割し、関連する上位3つのチャンクのみを格納する。 - **Verification**: 生成された答えをLLMを用いて検証し、エンドユーザーも検証できるように引用も生成する。accept、reject、neutralのいずれかをLLMに回答させ、acceptが回答されるまでK回失敗したあとに失敗メッセージを出力する。 - **Affordance**: 推薦された修正に対して性能メトリクスの変化の推定値を提供する。 高リスクの操作（DROP系クエリなど）を強調してユーザーに注意を促す。 - **Feedback**: ユーザーからのフィードバックを受け入れられる。 - 各応答に対して、'Helpful'または'Not Helpful'のバイナリフィードバックをユーザーに要求する - 過去のユーザーのフィードバックをプロンプトに含める[[Few Shot Learning]]。 - 実験設定は、[[GPT-3.5]]とembeddingモデルとして text-embedding-ada-002を用いて、[[GPT-4]]と比較する。テキストデータとして、Aurora PostgreSQLとMySQLのwaitイベントドキュメントを使用し、合計 2.5K 文書、すなわち合計 6.25M トークンで構成される。テレメトリーデータは、1分間の粒度で7日間かけて収集された合計2 50のデータベースメトリクスと、合計2.5Mのデータポイントから構成され、最も顧客から尋ねられるwaitイベントに関してデバッグクエリを手動設計する。 - ![[Pasted image 20240227214643.png|600]] - 人間によるスコア Trust、Understand、Usefulの３項目の評価の結果、全ての項目でPangaがGPT-4を凌駕した。2標本の[[t検定]]で$p\_value>10^{-20}$が得られた。しかし、PandaはUnderstandがやや低く、時には十分な文脈を欠いた正しいが不完全な答えを出したため。また、いくつかのケース(30%)では、初心者にとって十分なコンテキストがない文書のトラブルシューティングから、Pandaの回答が具体的すぎる、逐語的にさえあると感じた(8%)。 - ![[Pasted image 20240227214735.png|400]] - 今後の発展性として、カスタムembeddingがある。より安価なヒューリスティックとしてOpenAIのcustom embedding（ https://github.com/openai/openai-cookbook/blob/main/examples/Customizing_embeddings.ipynb ）がある。次に、長いマルチモーダル文書の処理を解決するために、長いドキュメントをチャンクに分解し、関連するチャンクを取得する。テレメトリのテキスト化について、実世界でのテレメトリは長く、多次元的で、ノイズが多い。さらに、LLMが複雑な数学的操作を行うことができないため、Pandaは正確なアフォーダンスを計算することができないが、正しい外部ツールを照会できる推論器（ToolFormer）などを用いて解決できる可能性がある。 - 感想：DBのデバッギングに関して、人間のエンジニアが検索して取得するデータを集めてきて、GPTにそのデータ片をヒントに推論させれば望む回答が得られるのは直感的にもうまくいくように思う。文中では等に強調されていないが、膨大のメトリクスから絞り込むのではなく、関連文書内に含まれるメトリクス名からtop-kの類似度をもつメトリクスを取得する方法は即興的で簡便だが確かにうまく動作する可能性がある。メトリクスの時系列データをどのようにテキスト化しているかは文中の説明だけではわからなかった。おそらく、時系列データのベクトルそのものを直接テキストにするのではなく、変化点時刻やトレンド、p95などのスカラー値のみをテキストとして含めているのではないか。 - そのうち、Auroraの付属機能として提供される可能性がある。 ## Draft LLMのプロンプトに入力する特徴を抽出するフェーズで、オフライン変化点検知アルゴリズムを使っていて、[21]はMetricSifterでも使っているruptureだった。やっぱり特徴抽出には、よく使われている異常検知より変化点検知のほうが適しているよなと思えた。 > Panda uses a change point detection algorithm [21] to divide the time series into problematic and baseline regions and runs a set of classic time series detectors, on this data to extract features relevant for debugging performance issues. > We found JSON formatting of prompt to work really well as compared to unstructured large text paragraphs, but other structures like bulleted, numbered, etc too give similar results 抽出した特徴量をプロンプトに含めるフォーマットはJSONがいいらしい > Telemetry-2-Text (T2T) that extract features from telemetry and converts them to text テレメトリをテキストに変換するらしいが、この説明がなにもない… 本当にそのまま数値データをJSONにするのだろうか > …they found Panda’s answers to be too specific or even verbatim from troubleshooting documents that lacked enough context for a novice to utilize it as compared to GPT-4 answers However, on the other hand both intermediate and expert DBEs found that specific quality of Panda to be very useful. This contrast in usefulness of Panda wasn’t immediately obvious when we started the experiment. Pandaの出力は具体的すぎてnoviceには向かないが、expertには非常に有用という話があっておもしろい。ChatGPTの常識と逆になってる。 ## Abstract データベースのパフォーマンス問題をデバッグするのは難しい。もしすべてのデータベースシステムに、ユーザが自然言語(NL)で問い合わせることができるオラクルや副操縦士が存在したら便利だと思いませんか？[[ChatGPT]]のようなLarge Language Models ([[LLM]]s)は、例えばインターネットの大部分に対する膨大な知識を効率的に符号化することによって、幅広い質問に答える能力を考えると、このオラクルの自然な代用品であるように思えます。しかし、ChatGPTにデータベースパフォーマンスクエリを求めると、経験豊富なデータベースエンジニア(DBE)にとっては、「技術的には正しい」ものの、非常に「曖昧」あるいは「一般的」なレコメンデーションとなり、役に立たず、信頼できないことがよくあります。 この研究では、より「有用」で「文脈に沿った」トラブルシューティングの推奨を生成するために、事前に訓練されたLLMに文脈の根拠を提供するフレームワークであるPandaを提案します。Pandaは、経験豊富なDBEがデバッグを行う方法からヒントを得て、デバッグのために事前に訓練されたLLMを本番環境で堅牢に展開するために必要なコンポーネントを備えたシステムを構築します。パンダの4つの主要コンポーネントは以下の通り： (1)グラウンディング、(2)検証、(3)アフォーダンス、(4)フィードバック。各コンポーネントの必要性と有用性、そして、与えられたデータベースシステムをデバッグするために、事前に訓練されたLLMをインコンテキストで、実行可能で、有用かつ正確な推奨を生成するために、それらが内部でどのように通信するかを説明します。