Google Gemma-7b（エッジAI向けモデル）に触れる
2024年02月28日 水曜日
CONTENTS
ぶわーっと色んなモデルが登場しましたね。
Googleが現地時間2024年2月21日、Geminiのテクノロジーを用いて開発したエッジAI向けモデル、Gemmaをリリースしましたね。
Gemma: Introducing new state-of-the-art open models がその発表の内容です。
他にも同社がGemini Pro 1.5を発表したり、StabilityAI社がStable-Diffusion3を発表したりと様々なところで色んな生成AIと呼ばれるモデルが登場し始めています。OpenAIが独走してるかと思いきや、他者も全然負けじといろんなモデルを発表しまくっていて、しばらくはこうした話題でにぎやかになるのかな？と思いつつ、その生成AIモデルに対する法体制も徐々に整備されつつあります。
また、NVIDIAにチップを供給してるTSMCは、熊本に新工場を建設し、2月24日、ついにその工場が開所しましてこれも話題になりました。わが日本も半導体製造という側面において国家プロジェクトと言えるほどの規模で半導体産業の振興にウェイトを置くようになり、はてさてその波に乗っかれるのやらどうなのやら・・実は昔、よくこの工場がある菊陽町を通りかかってた時期がありましたけれども、当時は見渡す限り田んぼの町ってイメージが強かったんですけどね・・・。でも、これを機におそらく今後がらりと変わっていくのでしょう。阿蘇に向かう国道57号線が混みまくりますな・・・こりゃ。
今回、ちょうど私らが使っている検証サーバでも動かせるGemmaを使ってその動きを眺めてみたりしましたのでそれを記事化しました。
Gemmaとは
Geminiで培われた技術をもってエッジAIでの駆動を想定して作られたLLMです。
私がよく活用しているHugging Faceのリポジトリでは、ラインナップとしては以下のものが公開されています。
- gemma-2b
- gemma-2b-it
- gemma-7b
- gemma-7b-it
itつきのモデルはいわゆる instruction アライメントを施したモデルです。つまりは指示に基づき回答する学習を受けたモデルです。
itなしのモデルはそのinstructionを行う前の事前学習のみ行ったモデルと言えます。GPUに対して処理を要求する場合は7bが適任であり、それより軽量なモデルが求められた場合に2bモデルが適任になると考えられます。
https://huggingface.co/google/gemma-7b-it
上記サイトのModelCardから以下引用、翻訳した文になります。
■概要
GemmaはGoogleが提供する軽量で最先端のオープンモデルのファミリーであり、Geminiモデルの作成に使用されたのと同じ研究と技術に基づいて構築されています。Gemmaはテキスト対テキスト、デコーダのみの大規模言語モデルであり、英語で利用可能で、オープンウェイト、事前学習済みバリアント、インストラクションチューニング済みバリアントがあります。Gemmaモデルは、質問応答、要約、推論を含む様々なテキスト生成タスクに適している。比較的小さなサイズであるため、ラップトップやデスクトップ、独自のクラウドインフラストラクチャなど、限られたリソースの環境でも導入が可能で、最先端のAIモデルへのアクセスを民主化し、すべての人のイノベーションを促進します。■モデルの微調整
google/gemma-7bリポジトリのexamples/ディレクトリに、微調整スクリプトとノートブックがあります。このモデルに適応させるには、model-idをgoogle/gemma-7b-itに変更するだけです。そのリポジトリには・QLoRAを使ってUltraChatデータセットに教師あり微調整（SFT）を実行するスクリプト。
・TPUデバイス上でFSDPを使ってSFTを実行するスクリプト
・フリーのGoogle Colabインスタンス上で実行できる、英語の引用句データセットに対するSFTを実行するためのノートブックが含まれています。
評価環境
別のローカルLLMであるelyza-llama2を実装してチャットをする仕組みを簡易的に設置してたのですが、この仕組みを半分流用する形でGemmaを実装しました。
この仕組み自体は過去に構築したチャットボット「天照」の仕組みを流用したものであり、会話履歴やBingSearchを活用したRAG機構を組み込んでいたのですが、後述する理由から、RAG機構は除外しています。対話記録はとってまして、回答例の内容等は記録した対話内容をDBから直接拾って転記する形をとりました。
簡易チャットツールを用いてGemma-7b-itを試している
GPUはNVIDIA L4(VRAM24GB)を使用しています。量子化なしだとこれがちょうどギリギリぐらいのVRAMサイズを消費します。当方のGPUは熱問題の関係もあり、クロック制限を800MHz上限に設定しているため、応答には少し時間がかかりました。大体200トークンぐらいで十秒前後・・・ぐらい？あまり厳密には計測してないので何とも言えませんが、トークン長が512ぐらいになると、使用しているChatUXが待ちきれずにタイムアウトしてました。単純な速度で言えばもしかしたらGeForceのミッドレンジクラスあたりのGPUの方が速いかもしれません。
アーキテクチャ
モデル説明やconfig.jsonファイルなどから読み取れる限りで調べてみた感じでは、以下のようになっていました。
- 最大コンテキスト長は8k
- トークナイザはGemma Tokenizerというものが使用されている
- 基本的に文字数ベースでのトークン構成がとられている（この辺りはGeminiと同じようなもの・・かな？）
- vocab_sizeは256,000なので、大体大抵の言葉は1文字1トークンで表現できそうな構成になっている（OpenAI Tiktoken cl100k_baseの凡そ2.5倍）
- そのことを考慮してか、マルチリンガルを前提にして日本語もモードを切り替えなくとも使えるように構成されている
- アテンションレイヤーの層数は28
- LLaMa2の7bモデルは32層なので、意外と層は少な目って感じ
- バイアス値は持ってないようです。
- アテンションヘッドの数は16
- ノーマライゼーション層は、LLaMaと同じくRMS-Normを使用。εの値は1.0e-06
- GemmaRMSNormと記述されています。
- 下の方にあるのは恐らくinput_layernorm
- Self-Attention層の上にあるのは恐らくpost_attention_layernorm
- RoPE(Rotally Positional Encodings）を使用している点もLLaMaと同じ。
- GemmaRotaryEmbeddingと記述されていました。
- Hidden層の次元数は3072次元
- Self-Attention層においては、4096次元に次元変換が行われます。
- KVキャッシュは使用している模様
- MLPにおけるアクティベーション関数はGeLUを使用
- Linear層で3072次元→24576次元→アクティベーション層→3072次元という形で次元変換しながら非線形化処理が行われると考えられます。
- モデルサイズ：モデルファイルのサイズ総量は凡そ17GB強ぐらい
- 基本的なテンソル形式は bfloat16
- BitsAndBytesを使うことで8bit量子化可能
- 8bit量子化をした時点でのメモリ使用量は凡そ16GB弱といったところ。
- 8bit量子化状態だと 13,670MB 程度消費→ワーキングメモリでその後2-3GB程度消費
- 16bit(bfloat16)だと、17,900MB 程度消費→ワーキングメモリでその後2-3GB程度消費
恐らくアーキテクチャを図にしてみると、モデルの config.json や model.safetensors.index.json を見た感じから以下の通り推察されます。(ちょっと自信ないけれど、おそらくLLaMa2に近い構造をしていると思われますので、LLaMa2をベースにニューラルネットワークの図は記述してみました。ちょうどこれが出ることを知る前までELYZA-LLaMa2-7bの仕様を深堀りしていたのでちょうどよかったです。）
補足：2024/03/01
その後、https://lightning.ai/lightning-ai/studios/understanding-using-and-finetuning-gemma にてモデルの全景について図示が為されており、Dropout層が実装されていることやアクティベーション関数の名称修正(GeGLU)を行いました。
RMS Normalization層は、Layer Normalization層と同じように値を正規化するために使用されるのですが、Layer Normalization層はモデルや入力が複雑になればなるほど計算コストが上昇するというリスクをはらんでいます。その為、計算量を節約できるようにするため、最近のTransformerでは1つの層のニューロンへの合計入力を二乗平均平方根統計量のみで正規化処理を行うRMS-Nomalizationをよく使うようになってるそうです。
これについて述べられた論文 「Root Mean Square Layer Normalization」に詳細記述がありますので、参考にしてみてください。
また、トークン位置を把握するための機構であるPositional Encodingsは絶対位置をSin/Cos関数を使用してその位置情報をベクトルに透かし彫りする代物でしたが、RoPEは相対位置を回転行列を使用して透かし彫りするというもののようで、確かにこれを使えば長文に対する位置定義がより容易にできるようになりますね。Attention層の構成のみならず、それ以外の周辺部分にもこうした計算回数を削減する工夫が盛り込まれているようです。これ自体はGemmaの特徴ではなく、ずっと前にリリースされていたLLaMaの特性ではありますが、こういう所が現在のローカルLLMにおけるトレンドとなっているようです。（すでに私行き遅れてるじゃん・・・）
プロンプトの構成
プロンプトの構成としては以下が基本となってるようです。
<bos><start_of_turn>user
Write a hello world program<end_of_turn>
<start_of_turn>model
この場合のtokenizerへの渡し方は以下のようになっている。(素のやり取り)
input_text = "<bos><start_of_turn>user\nWrite me a poem about Machine Learning.<end_of_turn>\n<start_of_turn>model\n"
input_ids = tokenizer(input_text, return_tensors="pt").to("cuda")
<start_of_turn>というタグから<end_of_turn>というタグの間に1ユーザ分の会話が入るようですね。そして「role [\n] message」という並びで記述が行われ、assistantの応答は「model」というロールで表現されるようです。
ローカルLLMだと、よく「プロンプトに対する回答を促すために、モデル側のプロンプトヘッダまで書き込んでおく」みたいなことが見受けられるんですが、このモデルでもどうやらそこは変わらないようですね。
OpenAIと似た構造に扱うことも可能で、transformersのchat_Templateというものを使用することで分かりやすく構成することができるようです。
この場合はRole/Contentを埋め込む形式のDictデータを配列要素にしたリスト構造になってます。
[
{"role": "user", "content": <メッセージ>},
{"role": "assistant", "content": <メッセージ>},
{"role": "user", "content": <メッセージ>},
{"role": "assistant", "content": <メッセージ>},
:
]
Roleはuserとassistantのみです。そして、初期プロンプトはsystemのRoleがないので、userで代用する形になります。
プロンプト冒頭のsystem role部分のみuserが重複してよく、その後は必ずuser / assistant / user / assistant …という形でつなげていかなければならない制約があります。重ねて何か同じRoleを投げようとすると以下のようなエラーが出て処理失敗します。
Jinja2 templates for conversation roles require that the roles alternate between `user`, `assistant`, and other roles in a specific order. The format is:user/assistant/user/assistant/... If the roles do not follow this format, it will result in a `TemplateError` with the message "Conversation roles must alternate user/assistant/user/assistant/...".
私の構築してる簡易チャットでは、こういう構成をとっており、prompt変数に格納するところに記述されているように、tokenizer.apply_chat_templateに乗せる形でこの配列を渡すと、トークナイズ後の状態として変換、変数へ格納してくれます。
[
{"role":"user", "content":"あなたは優秀なアシスタントです。\nあなたはユーザからの質問にやさしく丁寧に、フレンドリーに答えてください。\n但し、分からないことはわからないとだけ答えてください。"},
{"role":"user", "content":"<ユーザの入力テキスト>"},
]
#メッセージ配列をトークン化(messagesが先述したDICT型要素を持つリスト配列)
prompt = pipeline.tokenizer.apply_chat_template(messages, tokenize=False, add_generation_prompt=True)
そのあと、Hugging FaceのPipelineに乗せてローカルGemmaモデルに投げ込んでいます。レスポンス生成時の引数は以下の通り設定しています。
#レスポンスを生成
outputs = pipeline(
prompt,
max_new_tokens=max_tokens,
add_special_tokens=True,
do_sample=True,
temperature=1.0,
top_k=50,
top_p=0.6,
)
補足情報に引きずられがち
当初、対話履歴だけはRAG情報として参考にさせようとしたのですが、どうもこのGemma、補足情報に引きずられがちな印象を受けます。
65ced4cfa6a87 | 話題を変えたいです。 | こんにちは！今日はどのようなことでしょうか？ | 私はこれから何をする必要がありますか？ご案内しますか？ | 私はこれから何をする必要がありますか？ご案内しますか？ 65ced4cfa6a87 | 君が得意なことは？ | こんにちは！今日はどのようなことでしょうか？ | 私はこれから何をする必要がありますか？ご案内しますか？ | 私はこれから何をする必要がありますか？ご案内しますか？ | 私はどんな仕事やゲームや趣味をしたいですか？ | 私はどんなことをしたいですか？ | その他の話題も教えてください。
このように、対話履歴を参考にするというよりは、それまでの履歴に沿って答えてきたものをそのままassistant ロールに乗せてしまう傾向があります。
その為、現在チャットボット「天照」に実装してた対話履歴をRAGに使用するような仕組みは外した形でチャットボットを実装しています。
ただ、以前導入したELYZA-LLaMa2-7b-instructモデルを作成した、ELYZA,Inc.のブログを拝見してみると、もしかしたらGemmaにはinstruction学習をさせる過程で、「複数ターンの対話」を想定した学習を行なってない可能性があるかもしれません。
（以下、Elyzaの該当ブログ記事からの引用です。）
ユーザーからの指示に従い様々なタスクを解くことを目的として、ELYZA-japanese-Llama-2-7bに対して事後学習を行ったモデルです。事後学習には、ELYZA独自の高品質な指示データセットを用いており、複数ターンの対話にも対応することが可能です。なお、ELYZAでの事後学習においては、GPT-4やGPT-3.5-turboなどの出力は一切含まれていません。
あるいは、今時点では同じようにモデルを公開してるKaggleでは、そのモデル名の末尾に「-en」と記述されていることから、日本語の学習が不完全なのかもしれません。
いくつか質問してみた
ぱっと見それなりの回答が出来てるようには思えます。いくつか例を挙げます。
65ced4cfa6a87 | 日本の首相は誰でしょう？ | 私は現在、アクセスを得ていないため、日本の首相の最新情報に基づいて回答することは不可能です。 65ced4cfa6a87 | あなたの知る限り知ってる日本の首相を教えてください。 | 私の知る限り、日本の現在の首相は、**岸田文雄**です。 65ced4cfa6a87 | 人工知能について教えてください。 | 人工知能（AI）は、コンピュータシステムの一部であり、人間に匹敵するまたはそれを上回るとされる能力を備えたコンピュータシステムです。 | **人工知能の主な技術:**| * **機械学習:** データに基づいてモデルを構築し、新しいデータを予測するためのアルゴリズムです。 |* **画像認識:** 画像や動画の分析を行うことで、人間が見ていると同じように画像や動画を理解できます。 | * **自然言語処理 (NLP):** 人間言語の理解と処理を行うことで、人間が話すと同じようにテキストや音声を理解できます。 | * **ロボット制御:** robotを制御するためのアルゴリズムです。 | * **画像認識:** 顔認識、 object detection、vehicle detectionなど | * **自然言語処理:** Text summarization、Machine translation、Speech recognitionなど | * **機械学習:** Stock prediction、Fraud detection、Medical diagnosisなど | * **ロボット制御:** Autonomous vehicles、Manufacturing robotsなど | **人工知能のメリット:** | * **作業の効率化:** 人間によって不可能なタスクを自動化し、時間を節約します。 | * **新しい機会:** 新たな業務機会や解決方法を提供します。 | * **改善された決定:** データに基づいてより正確な決定を取る能力があります。 | **人工知能の課題:** | * **信頼性:** AIシステムの信頼性を確保するための研究が必要です。 | * **倫理:** AIシステムの倫理的な影響を考慮し、安全性の確保が必要です。 | * **コスト:** AIシステムの開発と運用には高いコストがかかります。 | **将来の展望:** | 将来の AIはさらに進化し、人間と密接したシステムとなり、様々な分野に適用されるでしょう。特に、医療、製造、エネルギーなど多くの分野において、AIは大きな変化をもたらす可能性があります
なお、GPTと同じようにいわゆる「おしゃべりモデル」な側面があり、多くのことが答えられる質問を投げると、max_tokensを振り切るほどに長文の回答をしようとする。別途プロンプト上でトークン制限等の実装をしたほうが良いように思われます。
その際、クロック制限状態のL4では少し応答に遅延があり、ChatUXが待ちきれずにタイムアウトしてました。
日本の文化に対する記憶はそれほど多くはとってないようで、だいぶ古い、あるいは頓珍漢な内容が返ってきましたので、あくまで特化型ボットを構築する際のベースモデルとしての利用がよさそうです。LoRAを使ったモデルファインチューニング手法などもちらほら見受けられますので、そのあたりを参照するのもよいかと思います（私はちょっと疲れてしまった・・・）
RAGの適用可否については何とも微妙で、その前に存在するプロンプトセットの内容にかなり引っ張られる特性が見受けられましたので、ちょっと気を付けたほうが良いかもしれません。とは言え、それまで登場してたローカルLLMの中でもワンランク上ぐらいの性能は持ってるんじゃないか？と思われます。このモデルは7bなので、LLaMa2の13b相当の性能を持ってるんじゃないかな？という気がしますね。対話能力については、プロンプト制御の方法やチュートリアルも充実してきましたので、もう少しノウハウを整理したうえで実装してみたいなーとは思っています。
参考までに
チャットプログラムを作る前に、サンプルとして提供されているプログラムからWarning要素が表示されなくなるよう諸々修正したスクリプトを使って基本動作は確認してましたので、それを参考情報として記載しておきます。
from transformers import AutoTokenizer, pipeline, BitsAndBytesConfig
import torch
import os
from dotenv import load_dotenv
load_dotenv()
#os.environ["CUDA_DEVICE_ORDER"] = "PCI_BUS_ID"
#os.environ["CUDA_VISIBLE_DEVICES"] = "2"
HF_TOKEN=os.getenv('HF_TOKEN')
model = "google/gemma-7b-it"
bnb_config = BitsAndBytesConfig(
load_in_8bit=True,
)
tokenizer = AutoTokenizer.from_pretrained(model,token=HF_TOKEN)
pipeline = pipeline(
"text-generation",
model=model,
model_kwargs={
"torch_dtype": torch.bfloat16,
"quantization_config":bnb_config,
"low_cpu_mem_usage":True,
"use_cache":True,
},
)
messages = [
# {"role": "user", "content": "Who are you? Please, answer in pirate-speak."},
{"role": "user", "content": "あなたは誰ですか？海賊語で答えてください。"},
]
prompt = pipeline.tokenizer.apply_chat_template(messages, tokenize=False, add_generation_prompt=True)
outputs = pipeline(
prompt,
max_new_tokens=256,
add_special_tokens=True,
do_sample=True,
temperature=0.7,
top_k=50,
top_p=0.95
)
print(outputs[0]["generated_text"][len(prompt):])
8bit量子化する際、モデル呼び出しの引数に「load_in_8bit」を仕込むケースが多いですが、どうもこれはBitsAndBytesで明示的にConfigを書いたほうが良いようです。また、トークンに関しても引数名が単純に「token」に変わったようですね。そのあたりは最新のTransformerに追従する形としました。Transformersライブラリは4.38.0からGemmaに対応してるようですので、それ以前のバージョンの場合はpipコマンドでバージョンアップしてください。
現在Finetuningに挑み中
現在、Hugging Faceブログの記述 https://huggingface.co/blog/gemma-peft を参考にしつつ、SFTTrainerを使ってファインチューニングに挑んでいます。
NVIDIA L4 GPUで動かせるギリギリ限界は以下の構成でした。
- ベースモデルはgemma-7b-itを4bit量子化
- 所謂QLoRA構成とし、保存対象はSelf-AttentionのQ_ProjとV_Proj（すべての層）とする
- データセットは kunishou/databricks-dolly-15k-ja を使用
上記の形で進めていて、現在時点のファインチューニングに必要なVRAMは最小限に抑えつつも、それでもかなりシビアな状況下で頑張らせてます。ただ、デフォルト状態で定格プラスアルファぐらいの800MHz駆動をさせてるにもかかわらず温度上昇がなかなかにすごいです。そのため、開始6分あたりでクロックダウンが発生し、どうにもこうにも時間がかかっちゃいますね。もう少し動きがはっきりわかってきたら必要な修正を施し、AzureVMのA100搭載インスタンスでもぶん回してみようかと思ってます。VRAM消費ですが、取り扱うトークンの最大量に左右されます。ざっくり以下のように傾向は見受けられましたので掲載します。
- 最大2048トークンに設定した場合：20791MiB上限でメモリ消費
- 最大1024トークンに設定した場合：15791MiB上限でメモリ消費
- メモリがたっぷり使える環境下だと、その後徐々にワークメモリ使用量が上昇するっぽい
1stepにかかる時間は凡そ6sec～10sec程度で、特に持続的にGPUを回すことによるクロックダウンの影響が強かったですが、エントリーGPUでやるこっちゃないのかもしれません・・・。(一応我らのワークステーション、冷却ファンをHP ProLiant ML350などで活躍してたのと同型のファンを突っ込んでるんですけどね・・・カードのサイズが小さすぎて冷却能力が追い付かないのです）
補足：2024/02/29：だいぶ想定と異なるところがぽろぽろ出ました。特にTokenizer。
その後、NVIDIA A100を使用して検証を行ってみているのですが、学習パターンについては少し見直しを掛けたほうが良いかもしれません。
特に気になったものとしては、トークンの締め方でした。1問1答形式で組んでると、Gemma-7b-itからの回答は以下のようになっていました。
<bos><start_of_turn>user あなたは優秀なアシスタントです。あなたの知る限りの情報に基づき、200文字以内で回答しなさい。完全な自動運転が実現するための最大の課題は何ですか？<end_of_turn> <start_of_turn>model 完全な自動運転が実現するための最大の課題は、環境の複雑性です。自動運転システムは、道路状況、気候条件、車両の状況など、多くの変動を含む複雑な環境をリアルタイムで認識し、 適切な反応をとる必要があります。そのため、完全な自動運転の実現には、多くの技術の開発とデータの収集が必要です。<eos>
<start_of_turn>modelから始まった内容の締めは<eos>で終わっています。ここはどうやら<end_of_turn>は加えないほうが良いようで、実際行ったファインチューニングで末尾を「<end_of_turn><eos>」で締めるようにデータセットを適用したところ、以下のような回答となりました。
いくつかの例を説明することができます。 <end_of_turn><end_of_turn> <end_of_turn> <end_of_turn>・・・・・（以降、トークン超過するまで無限ループ状態）
学習データ側の問題なのかどうかは完全にはわかりませんけれども、必ず最後は<end_of_turn>を挟むことなく<eos>で締めるという事が必要そうです。<end_of_turn>で締めさせようとすると、<end_of_turn>が延々と繰り返され、さらに余計な文とかが突っ込まれてしまい、レスポンスも大幅に遅れてしまうので、まずは末尾を<eos>で締めさせることを念頭にデータセットを適用させるようにしたほうが良いっぽいですね。
なお、NVIDIA A100で処理させたところ、1件当たりの学習に4秒程度時間がかかるようでした。バッチサイズを引き上げると8-9秒程度であり、およそ2,000Stepほど学習させるとそれなりの内容にはなりそうですが、あまり既存の言語ドメインとかかわりない新しい知識を覚えさせるようデータセットはそろえたほうが良いように感じました。
既存の言語ドメインと被ってしまうと、どうも知識が上書きされてしまっているようで、既存情報のメリットがうまく活用できてない印象を受けました。
Whisperの学習とも挙動が異なるところがあり、最終LayerのQ/Vだけチューンするようにしても逆に全体の文が崩れてしまう傾向が強いように思えました。学習率はあまり高いとgrad_normの値が大きくなり、逆に1,000Stepsを超えたあたりからlossが発散し始めてまして、grad_normもnanになってしまって学習不良な状態が発生していましたので、こうしたところは注意が必要そうです。
今回紹介した個所については、まだ出たてのモデルであるうえに、Tokenizerの構成も新顔な構成でしたので、今後改良されていくんじゃないかな？という気がしています。気のせいかもしれないけれど。私の検証は粒度が微妙なところもあり、確定的なことはあまり言えないにしても参考にしていただければ幸いです（というか、ベストなファインチューニングパラメータ、トークン構成が割り出されてくれるといいなぁという感じです・・ははは。）
個人的にやりたいこととしては・・
お仕事ではともかく、私がこの分野でやりたいことは、ローカルLLMを使ったチャットボットでコミュニケーションをより親密に行い、そこにDoTという手法（AIDBの記事 https://ai-data-base.com/archives/56696)を用いてメンタル改善を図るようなことが出来たらなぁ・・・（って、道のりは長いんだけどさ、完成したモデルはあるんだろうけどさ）って奴で、私が様々な持病のダブル・トリプルパンチにやられてる現状をより良い方向にもっていくツールがあったらなぁ・・って。
ただ、やっぱり歴の浅さがあってファインチューニング手法や、ニューラルネットワークに直接手を加えるようなことには全然力不足なので、私がそれが出来るようになるころにはきっとツールとして既に完成形のものがあるんだろうなーとか思ったりでなかなかやる気が出てませんけども。
また、Gemmaを使って雑談が出来たらなぁ・・・とか思ってたのですが、ちょっと今の時点ではそれは不向きなようで、むしろ複数ターン学習が行われた別のモデルを使ったほうがいいんだろうか・・とか思ったりも。しかしながら、このGemmaは恐らくQAボットとしてはかなり優秀に物事をこなせるんじゃないか？という気がしますね。他力本願で情けない限りではありますが、今後の発展形としてどんなものが登場してくるのか、ある意味楽しみではあります。
参考にした情報
この記事を作成するにあたり、公式ドキュメントやベースになってる論文、加えて、ずっと早くからGemmaの検証をなさっていた方々の記事も参考にさせてもらいました。その記事を参考情報としてリンクさせていただきます。
- https://note.com/npaka/n/n17170439fe62
- https://note.com/npaka/n/nc1436c57516f
- https://cloud.google.com/kubernetes-engine/docs/tutorials/serve-gemma-gpu-vllm
- https://huggingface.co/blog/gemma
- https://arxiv.org/pdf/1910.07467.pdf
