ML/DS Casual Tech Talk @September 27, 2024

@Masataka Kashiwagi

GenOps: the evolution of MLOps for gen AI

Learn how to build and scale Generative AI solutions with GenOps | Google Cloud Blog

GenOps（MLOps for Gen AI）：生成 AI のための MLOps
- ユニークな課題として以下がある
  - Scale, Compute, Safety, Rapid evolution, Unpredictability
  Hidden Technical Debt in Gen AI Systems
- プロンプト関連で従来と異なる要素がある
GenOps パイプライン

Sample architecture for GenOps
- GenOps の主要なコンポーネント（Vertex AI を使う前提の話が多い）
  - データ：Few shot 用のサンプルや評価データセットなど
  - プロンプト管理: Vertex AI Studio で共同管理できる
  - モデルのファインチューニング: ファインチューニングデータを使用して学習済みモデルを調整する
    - Google Mesop: python ベースの Web UI
      
      UI built using Google Mesop for RLHF
      - 人が LLM の結果を評価するために使える（RLHF）
  - モデル評価: モデルベースと計算ベースのメトリクス
    - Google 独自のモデル，ROUGE や BLEU などの評価を用いる
  - モデルのデプロイ
  - モニタリング

@FukasawaYusuke

Generative Verifiers: Reward Modeling as Next-Token Prediction

PFN 岡野原さんのメルマガで紹介されていた論文
- 一部引用しながら紹介します
LLM の推論能力をあげることに関しての研究
今流行りのアプローチ → GenRM
- モデルに指示や問題を与えて複数の答えを出した時に、その出した答えを別の検証機もしくは報酬モデル(LLMベースの)が、どの答えが良かったかを独立に判定することによって性能を上げる(分類問題としてアプローチする)
- このアプローチは、どの答えが良かったかっていうのを判定するために別に訓練されたモデルを用意している。本来のテキスト生成能力とは少し違う能力を作っている感じ
  - LLMが持っているような生成能力とか、LLMが使っている大量の学習データとかを必ずしも活用できていない。LLMは思考連鎖（CoT）などでものすごく能力を引き上げているので、そういった部分が活用できてないのがもったいない。
- そもそもシステムとして生成部分と判定部分の2つがあってちょっと複雑
新しいアプローチ
- 生成問題としてアプローチする → GenRM-CoT
- そのためのデータセット準備
  - LLMが問題に対して答えを出す。その後にLLM自身がその答えに対して検証を始めて、その検証の結果、この検証が合ってました(間違ってました)の結果が全部一つの並びになったようなデータを作る
    - 問題と回答結果、それに対する品質評価(の対応を分類問題としてfine-tuningする)、というのが従来の枠組み
    - ここでは問題とそれに対する思考過程と回答結果、それに対する合っているかどうかのYes,No の学習を生成的に行う(分類ではなく)

例えば具体的な問題でいうと、上記のような問題文があって、まずこのモデルが出した答えがあって、この後に普通はソリューションに対して独立にこの出した答えが合ってるかどうかっていうモデルがいるんですけれども、このモデル自体が何も言語の能力も使わずいきなりこれを与えられて分類するだけなので、結構難しい問題を解いています。

これに対して、GenRM-CoTは、この答えが合っているかどうかという検証をステップバイステップで検証しましょうというようなことをやっています。

ステップごとに分解して検証して、これが正しくなかったということで、最終的にverificationで”Is the answer correct?”で”No”を出すというようなことをしていて、これ全体をできるように次のトークン予測で学習をしています。