御存知の通り Mackerel では OpenTelemetry Metrics + PromQL への對應を進めてゐます (Mackerel の PromQL 處理の內部 (2023/12 時點) #mackerelio - c4se記：さっちゃんですよ☆)。その PromQL を OpenAI API 等で自動生成して樂できないかな〜、と試してみたので、その經驗を書きます。※試してみただけなので、Mackerel に PromQL 自動生成機能が搭載されると云ふ事を意味しません。
事前勉強
以下の二冊を土日に詰め込む。
- ChatGPT/LangChainによるチャットシステム構築［実践］入門
- LangChain での code が、OpenAI API でどんな prompt で實現されてゐるか透けて視える樣に解說されてゐる。(LLM (大規模言語 model) の內部の仕組みではないが) 仕組みを知れる
- LangChain完全入門 生成AIアプリケーション開発がはかどる大規模言語モデルの操り方
- 學習の流れはこっちの本が滑らか。大きな視野を得易い
數人で實驗したが、仲閒も同じ本を讀んでゐた。
昔ChatGPTの頭の中 (ハヤカワ新書 009)を讀んだ。御得。
他は、チラチラと流れてくる記事を眺めてゐたくらい。機械學習・人工知能・深層學習は一般敎養くらい。
ChatGPT で調査
OpenAI API playground でもよかったかもしれない。
適當な prompt で、割といい PromQL を生成できる事を確かめた。詰まり ChatGPT 3.5 や ChatGPT 4 の model は、既に PromQL を知ってゐる。
few-shot prompt で生成してみる
早速 Pipenv で LangChain を入る。寫經する樣に few-shot prompt の chain を組む。
「あなたはプロの SRE です。」みたいに役割を與へ、自分達で頑張って例を幾つか書いた。「greenサーバーのレイテンシー」みたいな文を入力すると、「greenサーバーのアベイラビリティを得るためのPromQLは以下の通りです。avg_over_time(http.server.duration.p99{service.name="green"}[2w])」みたいな出力が得られて盛り上がる。
盛り下がったのは、OPENAI_API_KEY を環境變數から拾ってくれなくて少し詰んだり、上記の本に書いてある code はもう deprecated でウゲゲとなったり。餘計な日本語がくっ附いて出力されるなぁと云ふのも思った。
オーガニゼーションに存在するメトリックを素に PromQL を書かせる
世の一般的な知識だけぢゃなくて、オーガニゼーションに投稿してゐるラベル對應メトリックを考慮し PromQL を書いてくれたら嬉しい。AI が Mackerel の API に問ひ合はせてくれたらよい (AI は「問ひ合はせよ」と云ふ指令を返すだけで、實際に問ひ合はせるのは自分達の仕事)。LangChain の agent で實現しよう。寫經。
Mackerel の API に問ひ合はせるのも面倒だし、實驗段階で AI への入力を制御したいと云ふ氣持ちもあり、API の返り値を僞造した JSON を作って使ふ。
get_metrics と云ふ tool を作って說明を書いて OPENAI_FUNCTIONS agent に與へるだけ。max_iterations は制限しておく。てきとーな文字列で get_metrics を呼び出してくるから、曖昧に檢索して返すやう工夫する、これは普通の programming。滅茶苦茶な長さの結果を prompt に入力しない樣に、get_metrics の返り値は適當に小さく保つ。
get_metrics が何も返さないと、agent は別の文字列を OpenAI に出力させる樣に retry するんだなぁ。かう云ふ訣で max_iterations は妥當に制限しないといけない。
出力を固定する
中々苦勞したが、prompt を工夫して、更に FewShotPromptTemplate | ChatOpenAI (with ReAct) | PydanticOutputParser | OutputFixingParser と chain を組んだら安定した。OutputFixingParser はほぼ每囘走ってゐる…。
精度を上げる
few-shot prompt の例を 20 個くらいに增やしたら結構よくなった。
日本語で書いてゐた prompt を英語に飜譯 (これも LLM で自動飜譯ね) したりもした。精度に效いたかはわからない (效くと云ふ噂が在る) が、token 數を節約できるらしい。
prompt injection 對策
色々遊んだら簡單に壞せたので、妥當に對策しておく。
prompt の長さ
既存の prompt を押し流せない樣に、そして token 數による課金 DoS を防ぐ爲に、適當な長さに制限する。PromQL を生成する指示が長編小說にはならないだらうからね。
deny list
「プロンプト」みたいな、prompt injection によく使ひ、PromQL 生成指示にはそんなに使はなささうな文句を拒否する。まぁ一長一短だが、やる。
話題の檢證
PromQL を生成する指示として相應しいか否かを OpenAI に聞く。temperature を 0.0 にする事で曖昧さは減らさねばならない。
user 入力の隔離
system role (SystemMessage) と user role (HumanMessage) を使ひ分ける。GPT 4 だと案外混同しないらしい。
加へて user 入力を、random に選んだ區切り文字列で圍んで隔離する。
出力の檢證
OpenAI Moderation API に、普通の business 慣行として相應しくない感じの出力になってゐないか確認する。
LangChain の moderation の chain は、叩く OpenAI API ver. が古くて動かなかったぜ。直ぐ直るんぢゃないかな。
今後の課題
今後やるべき事はいっぱい有る。この system の observability をどう確保するんだと云ふ點もまだ知らない。
一番の課題は、まだ精度だ。例を增やす、fine tuning する (100 個くらいの例が在ればよく、時閒は掛かるけど簡單だなぁ)、CoT (chain of thought) の指示をちゃんと與へる、短い指示でも生成できる樣に周圍の文脈も入力する、等を議論して話してゐる。また出力の質の評價も關聯した課題に擧がってゐる。機械學習や人工知能を使った開發 project には、system を構築する project の不確實性と、構築した system の精度を上げる project の不確實性と、2 つの不確實な phase が有ると云ふ話題が有るが、一つ目の不確實さは直ぐに潰せると云ふのが OpenAI の樣な構築濟みの LLM の利點なのか、とも話した。つまり 2 つめの不確實さは相變はらず有るんだなぁ。
法務的課題も確認し解決する必要があり、結局「責任を負へる人閒」って奴が要るんだな…。
