Gemma
読み: ジェマ
Gemmaとは社内で動く軽量AI
GemmaはGoogleが開発したオープンモデルのLLMである。最上位モデルであるGeminiの技術基盤を継承しつつ、企業が自社のオンプレミス環境やローカルPCで動かせるよう軽量化されている。商用利用も可能であり、外部にデータを出せない機密性の高い業務での活用が想定されている。
かんたんに言うと
プロの厨房にある業務用オーブンの家庭用モデルに近い。業務用ほどの火力はないが、自宅のキッチンに収まるサイズで、好みに合わせて温度も時間も自由に調整できる。Googleが培った技術を、手元で使える形にしたのがGemmaである。
外部にデータを出せない業務で活きるGemmaの立ち位置
Gemmaは単なるGeminiの縮小版ではない。Googleが自社の最先端モデルと同じアーキテクチャを用いて、外部の開発者が自由に扱えるように切り出したオープンモデル。
パラメータ数はGemma 2Bや7Bといったサイズが用意されている。
2Bなら最近のノートPCでも動く。
クラウドAPI経由でしか触れないGeminiと違い、自社のサーバーに直接デプロイできるのが最大の利点である。法務部門が扱う未公開のM&A;契約書や、人事部門が抱える従業員のメンタルヘルス記録など、絶対に外部APIへ投げられないデータがあるだろう。そうした閉鎖環境でのテキスト処理を自前で構築する際、Gemmaは有力な選択肢になる。ただ、軽量ゆえに複雑な推論を求めると途端に破綻する。どこまで任せるかは判断が分かれるところである。
Transformerの恩恵とローカル動作の現実
Gemmaの根底にあるのはTransformerアーキテクチャである。Google自身が提唱したこの技術を極限まで最適化し、少ないパラメータ数でも高い言語理解力を発揮するよう設計されている。
だが、現場の感覚から言わせてもらうと、7Bモデルを実業務で安定稼働させるのはそれなりに骨が折れる。
VRAMが24GB程度のGPUを積んだローカルサーバーを用意すれば動くには動く。しかし、複数ユーザーからの同時リクエストを捌くとなると話は別である。レスポンスタイムが急激に悪化する。経理部門の経費精算チェックシステムに組み込んだ際、月末のピーク時に処理が詰まって使い物にならなかったことがある。軽量モデルとはいえ、本番環境のインフラ設計を甘く見ると痛い目を見る。
Vertex AIやHugging Faceでの展開と実務への組み込み
Gemmaを試す環境は豊富に用意されている。Kaggleでノートブックを開けばすぐに触れるし、Hugging Faceからモデルの重みをダウンロードしてローカルで動かすのも容易である。
Google CloudのVertex AIを使えば、フルマネージドな環境でAPIとして呼び出すこともできる。
製造業の生産技術部門で、過去の不良品レポートから特定の不具合パターンを抽出するシステムを作った。この時、Hugging FaceのTransformersライブラリを使ってGemmaを自社データでファインチューニングした。特定の専門用語に対する理解度は劇的に向上したが、学習データのクレンジングに膨大な時間を溶かした。オープンモデルのカスタマイズは自由度が高い反面、泥臭いデータ整備の労力を自社で被ることになる。これを許容できるかは悩ましい。
自社運用におけるコストと精度のトレードオフ
オンプレミスでGemmaを運用すれば、APIの従量課金からは解放される。ランニングコストは電気代とハードウェアの減価償却費だけである。
しかし、精度面での限界は常に付きまとう。
物流部門の配車計画アシスタントとしてGemma 7Bをテストした際、複雑な制約条件をプロンプトで与えると、平気で物理法則を無視したルートを提案してきた。軽量モデルに高度な論理推論を期待してはいけない。Gemmaが得意なのは、与えられたテキストの要約や、決まったフォーマットへの情報抽出といった単一のタスクである。用途を絞り込めば強力な武器になるが、汎用的なチャットボットとして全社展開しようとすると、ユーザーからの不満が殺到して運用担当者が疲弊するだけである。
商用利用の壁とResponsible Generative AI Toolkit
Gemmaは商用ライセンスが明記されており、企業が自社サービスに組み込んで販売することも可能である。
ただ、オープンモデルをそのまま顧客向けサービスに露出させるのはリスクが高すぎる。
GoogleはGemmaと同時にResponsible Generative AI Toolkitを公開している。これを使えば、不適切な出力のフィルタリングや安全性の評価がある程度システム化できる。営業部門が顧客に送るメールの文面生成ツールにGemmaを組み込んだ際、このツールキットを使って攻撃的な表現を弾くよう設定した。それでも、予期せぬ単語の組み合わせで不適切なニュアンスが生まれるケースを完全にゼロにはできなかった。AIの出力をどこまでコントロールできるか。最終的な責任はモデルの提供者ではなく、システムを組んだ我々が負うことになる。
当社の見解
当社は機密情報のマスキング処理を全てローカルAIで行っている。これにより機密情報を外部に送信せずにAI処理できるようになった。だが、AIが嘘をつくハルシネーションの問題は依然としてある。確認していないのに「確認しました」と言う。当社はこの前提で運用を設計している。事実と推測の強制分離、ファクトチェック機能、3つのAIと人間の同士の三重検証を行っている。どこまでいっても、AIは完璧ではない。理論上100%安全設計をしていても、AIも人間も想定しないことは起こるものだ。その万が一に備えておくことが、AIを使う上では前提になっている。だろうではなく、かもしれない運用がAIを使う上での安全基盤となっている。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。