AIを使って「ちょっぴりだけ」ツールを便利にしたい：Zabbixとの連携
2024年07月02日 火曜日
CONTENTS
執筆中にお休みしたため・・
本記事なのですが、執筆したのは2024年6月時点の情報となります。
実は執筆してる最中に持病の定期治療時期に差し掛かってしまい、気づけば入院中何もできなくなりまして・・少し情報が古くなってしまいました。AI界隈の達人の方は活用例にご注目いただくとして、例えばモデルを現在最速のモデルや精度の高いモデル等に変更いただきつつ読んでいただくなどするともう少し何かしらの貢献ができるのかもしれませんですね。
多少の追記は行っていますので、なにとぞご理解くださいましー。
超便利な中小型LLM
最近やっぱり推論品質として高いのはGPT-4oとかGemini 1.5 Proとかに代表されるAPI型大規模モデルですが、それでもオープンウェイト型中小モデルでもノーチューニングで楽しめるLLMが登場してきました。中でも私の一押しは以下の2モデルです。
これらのモデルは中小型モデルにも関わらず、推論内容がかなりしっかりしてるので、非常に重宝しています。MicrosoftがリリースしているPhi-3シリーズもすごく優秀なモデルではあるものの、なぜかCode系の推論をさせるとMicrosoft製品に偏ってるところがあったりして非常に特定分野に関しては扱いづらいところがあり・・・。今のところは上述の2つをがっつりと触りながら過ごしているところです。
他にもマルチモーダルモデルだったり、現在の生成AIにおける対応レンジはどんどん広がってますが、私の場合頭がどうにも固いのか、ずーっと一貫してテキストLLMに拘って触り続けてます。ぶっちゃけ動画系とか画像系が苦手なのです(^-^;得意分野を伸ばそうという考えのもとで扱ってるので、ネタがこれだけになりお恥ずかしい限りですが、どうぞご理解くださいませ（きっとAI基盤とかマルチモーダルとかそのあたりの部分は弊社の誰かがなんかしてくれるやろう・・）。
便利なサーバ機能を持つllama.cpp
もう一つ気に入ってよく使ってるのがllama.cppという推論エンジンです。
これは、本来Pytorchとかtransformersを使用して推論をさせるような部分をさらにC++ベースで最適化を推し進めた推論エンジンで、名前の通り当時MetaのLLaMaをより高速に実行するために生まれたソフトウェアです。
その原型はGGMLというソフトウェアで、当時まだ莫大なGPUリソースを要求するAIの推論環境をなんとかしたいという動機で、PytorchでかかれたものをC/C++で作り直すようなことを考えて作られたものになります。やがてLLaMa.cppはGGMLフォーマットされたモデルとともにCPUでも動かせる推論エンジンとして脚光を浴びたわけなのですが、その後拡張フォーマットであるGGUFが開発され、LLaMa.cppが他のモデル（GemmaやMistral、Mixtral等）も動かせるようになり、結構多くの人がこれを活用するようになりました。また、LoRAやQuantize（量子化）にも対応しています。
このllama.cppの中で特にありがたい機能がserver機能です。このserver機能はプロセスを常駐させることにより、RESTAPIインタフェースとして機能してくれるのですが、OpenAIによく似たインタフェースを持ち、openaiライブラリを使用したChatCompletionに応答させることが可能になっています。
また、llama.cppがC++ベースで最適化された推論エンジンということもあり、その推論スピードはPythonスクリプトで構築したものと比較して圧倒的に処理速度が速く、我が検証環境で使用しているちょい古め、TensorCoreなしのNVIDIA Tesla P100でもそこそこの応答速度で出力してくれます。
Mistral-7b-Instruct-v0.3にログを食わせてみた
で、今回そんなllama.cppを使って単純にMistral-7b-Instruct-v0.3にログを食わせてみたのですが、これがなかなかいい応答を返したのです。
投げたログはこちら。検証サーバ上の /var/log/syslog から適当なところを拾って投げたものです。一応文字列に特殊文字が出力されることを考慮し、プロンプトとしてはこのログ全体に対してMarkdownにおけるコードブロックで囲ってはいます。
Jun 2 12:56:33 bdae02 gc_linux_service[128769]: Worker process waiting to finish the consistency operation. Jun 2 12:57:58 bdae02 gc_linux_service[128769]: Worker process exiting with exit code : 0 Jun 2 12:57:59 bdae02 gc_linux_service[129651]: Worker process waiting to finish the consistency operation. Jun 2 12:57:59 bdae02 gc_linux_service[129651]: Worker process is running consistency for assignment AzureLinuxBaseline, solution type inguest Jun 2 12:57:59 bdae02 gc_linux_service[129651]: Worker process is using https://japaneast-gas.guestconfiguration.azure.com/virtualMachines/*********************** service url for GAS communication. Jun 2 12:58:01 bdae02 gc_linux_service[129651]: /opt/GC_Service/GC/../GC/gc_worker: symbol lookup error: /var/lib/GuestConfig/Configuration/AzureLinuxBaseline/Modules/DscNativeResources//ASM_LinuxAuditResource/libASM_LinuxAuditResource.so: undefined symbol: _ZNK5boost10filesystem4path11parent_pathEv Jun 2 12:58:57 bdae02 slurmd[3306]: slurmd: debug2: Start processing RPC: REQUEST_PING Jun 2 12:58:57 bdae02 slurmd[3306]: slurmd: debug2: Processing RPC: REQUEST_PING Jun 2 12:58:57 bdae02 slurmd[3306]: slurmd: debug2: Finish processing RPC: REQUEST_PING Jun 2 12:59:40 bdae02 kernel: [11126.111475] perf: interrupt took too long (3133 > 3131), lowering kernel.perf_event_max_sample_rate to 63750 Jun 2 13:00:00 bdae02 slurmdbd[1617]: WARNING: MYSQL_OPT_RECONNECT is deprecated and will be removed in a future version. Jun 2 13:00:21 bdae02 gc_linux_service[131168]: Worker process waiting to finish the consistency operation. Jun 2 13:00:21 bdae02 gc_linux_service[131168]: Worker process is running consistency for assignment LinuxLogAnalyticsAgentInstalled, solution type inguest Jun 2 13:00:21 bdae02 gc_linux_service[131168]: Worker process is using https://japaneast-gas.guestconfiguration.azure.com/virtualMachines/*********************** service url for GAS communication.
応答内容は以下の通りです。
このログは、Azure 上の Linux 仮想マシンにおける Guest Configuration Service (GC) と Slurm Workload Manager (Slurmd) の動作を示すものです。
Guest Configuration Service (GC) は、Azure Linux Baseline や Linux Log Analytics Agent Installed など、Azure VM に対して定義されたセキュリティ設定を適用するためのサービスです。
Worker process waiting to finish the consistency operation. : GC ワーカープロセスが、コンシステンシー操作（セキュリティ設定の適用）を完了するまで待っていることを示しています。
Worker process exiting with exit code : 0 : GC ワーカープロセスが正常に終了し、エクシットコード 0（成功）を返したことを示しています。
Worker process is running consistency for assignment AzureLinuxBaseline, solution type inguest : GC ワーカープロセスが AzureLinuxBaseline のセキュリティ設定適用（consistency）を行っていることを示しています。
Worker process is using https://japaneast-gas.guestconfiguration.azure.com/virtualMachines/*************************************** service url for GAS communication. : GC ワーカープロセスが、GAS（Guest Agent Service）との通信に使用する URL（https://japaneast-gas.guestconfiguration.azure.com/virtualMachines/***********************）を示しています。Slurm Workload Manager (Slurmd) は、高性能計算や大規模なジョブの管理に使用されるシステムです。
slurmd: debug2: Start processing RPC: REQUEST_PING : Slurm Workload Manager (Slurmd) が、リクエスト PING を処理する準備が整ったことを示しています。
slurmd: debug2: Processing RPC: REQUEST_PING : Slurm Workload Manager (Slurmd) が、リクエスト PING を処理中であることを示しています。
slurmd: debug2: Finish processing RPC: REQUEST_PING : Slurm Workload Manager (Slurmd) が、リクエスト PING の処理を完了したことを示しています。最後に、kernel ログには perf インターバルト（perf: interrupt took too long）に関する警告があります。これは、Kernel Perf Event (perf) のインターバルト時間が設定された値を超えたことを示しています。 perf は、CPU のパフォーマンスを評価するために使用されるツールで、インターバルト時間が長くなると、システムのパフォーマンスに影響を与える可能性があります。この警告は、kernel.perf_event_max_sample_rate を 63750（原則的にインターバルト時間が短くなる）に設定することで解決できます。
最後に、slurmdbd ログには MYSQL_OPT_RECONNECT がデプレケートされることを警告しています。MYSQL_OPT_RECONNECT は、MySQL の接続を再接続するためのオプションで、将来的に削除されることを意味します。
一つ一つ丁寧にログに関する解説を応答してくれました。デュプリケートが「デプレケート」と書かれていたりなところはありますが、それぞれのログが何を示しているかを理解することが出来る内容です。ところどころ手短に補足を書いてくれたりもしていますね。加えてMistral-7b-Instruct-v0.3の最大コンテキスト長はありがたいことに32kもあります。それなりに長いログを食わせることもどうやらできそうです。
GPT向けの仕組みを活用して、ツール連携を画策する
llama.cppのこの疑似OpenAI APIを使用することで、巷にたくさん転がってるGPTとの連携ネタがそのままローカルLLMに対して使用することが出来ると分かり、とりあえず挑んだのが「ZabbixのアラートをこのLLMに食わせて補足コメントを出力させる」というものでした。
私らエンジニアって呼ばれる人達の中には、どうしてもどう頑張っても「英語が苦手」な人が多々いらっしゃるかと思います。私もそんな中の一人です。翻訳エンジンにかけたり、経験則で何が出てきたらどんなことが起きてるって知識は積み重ねてきていても、どーしても「英語で書かれたログを見ると【ウッ】とくる人は少なくないんじゃないかなぁ」とか思ったりしています。そんな中に日本語で書かれた解説文があるとそれだけでも業務を進めやすくなる・・・ということはまぁまぁあるのかなぁという風に考えています。
今回、GPTベースに組み上げられているこちらのソリューションをベースに、これをllama.cppで連携できるように取り組んで実装してみました。
https://tech-mmmm.blogspot.com/2023/09/openai-apizabbixai.html
こちらの環境としては以下の通りです。
- OS：Ubuntu 22.04
- Zabbixのバージョン：6.4.15-1+ubuntu22.04
全体的な構成としては以下の通りです。
llama.cppをビルドする
まずは、推論エンジンがないことには始まらないので、これをビルドします。
私の場合、GitHubからcloneしたうえで、CUDAを有効化する形でビルドしています。これを行うためにaptを使ってCUDA ToolkitとcuDNN、CUBLASをインストールする必要がありました。makeコマンドにLLAMA_CUDAオプションを付けた形で構築しています。
make LLAMA_CUDA=1
Mistral-7b-Instruct-v0.3をGGUF化＆量子化する
llama.cppで駆動するモデルは形式変換する必要があります。llama.cppをビルドすると、これらの変換ツールが生まれてくるので、これらを使ってGGUF形式に変換したのち、4bit量子化モデルに仕上げます。
実はGGUF化されたモデルそのものがHuggingfaceのサイトで別途公開されることもあるんですが、今回は敢えて元々のモデルをダウンロードしてGGUF化→加えて4bit量子化まで一通りを行うことにしています。これは、GGUF化されたモデルの中には既に決められたTokenizerの仕様に従って設定された内容が組み込まれてしまっており、こちらの想定するTokenizerが合わない場合に正常な推論結果を返さない場合があるからです。
きちんとMistralAIがリリースしたモデル及び周辺ファイルのセットをベースにGGUF化することが必要だろうと考えましたので、まずはそれら一式をダウンロードし、16bitモデルからの作成を行っています。Quantizeコマンドで実行できる量子化設定も、4bit量子化モードの中で最も品質低下の比率が小さい Q4_K_M を指定して量子化処理を行っています。
この辺りの変換処理はGPUを使用せずCPUを使用するような形になりますので、GPUリソースを気にせずに済むのは良い点かなと思います。但し、その分メインメモリが大量に必要となりますので注意をしてください。
■APIキーを使用してログインを行う。事前に mistralai/Mistral-7B-Instruct-v0.3の利用規約にAcceptしておきましょう。 https://huggingface.co/mistralai/Mistral-7B-Instruct-v0.3 huggingface-cli login ■モデルのダウンロードを行う huggingface-cli download mistralai/Mistral-7B-Instruct-v0.3 ダウンロードが完了すると保存されているsnapshotへのパスを教えてもらえるよ。 失敗した場合もレジュームが可能なので、再実行すればダウンロード再開してくれるよ。 ■モデルをGGUFフォーマットに変換する llama.cppをビルドした結果、いくつかのバイナリとpythonファイルが出来上がってると思うので、このうちの convert-hf-to-gguf.py を使って変換する 以下は実行例。変換元ディレクトリはモデルダウンロード完了後に通知されたディレクトリを指定します。 ./convert-hf-to-gguf.py ~/.cache/huggingface/hub/models--mistralai--Mistral-7B-Instruct-v0.3/snapshots/<ユニークID>/ --outfile ./models/Mistral-7B-Instruct-v0.3.gguf --outtype f16 ■GGUFモデルを量子化する 私の場合、バイナリとして出力されたビルド済みのものを/opt/llama.cpp/bin 配下に設置しているんで、そこから実行しています。4bit量子化・中サイズとして処理。 /opt/llama.cpp/bin/quantize ./models/Mistral-7B-Instruct-v0.3.gguf ./models/Mistral-7B-Instruct-v0.3.Q4_K_M.gguf Q4_K_M
serverプロセスをsystemd管理下に置く
serverプロセスの起動を自動化するため、/etc/systemd/system 配下に ggml-mistral.service というファイルを作成し、そこに以下のような内容を記述しています。
[Unit] Description=ggml-mistral After=network.service [Service] User=aiuser Group=aiuser Type=simple PIDFile=/var/run/ggml-mistral.pid ExecStart=/opt/llama.cpp/bin/server -m "/opt/llama.cpp/models/Mistral-7B-Instruct-v0.3.Q4_K_M.gguf" --port 50999 --host 0.0.0.0 -ngl 32 -n 25600 -c 16384 -mg 2 -sm none WorkingDirectory=/opt/llama.cpp/work StandardOutput=append:/var/log/llama.cpp/ggml-codebot-stdout.log StandardError=append:/var/log/llama.cpp/ggml-codebot-stderr.log [Install] WantedBy=multi-user.target
上記の中で、–port, –host以外にもいくつかオプションスイッチがあるので、そのあたりの説明をしておきますと、以下のような内容となっています。
- -ngl 32
これは、モデルの中で最大32層のAttentionBlocksに対してGPUオフロード処理を行うことを意味しています。数値を-1に設定することで「モデル全体をGPUオフロードさせる」ことも可能ですが、今回は明示的に総数を指定しました。 - -n 25600
推論における最大トークン長 - -c 16384
最大コンテキスト長を指す。モデルの特性上、最大32768まで指定可能ではあるのですが、ある程度この値を絞ることにより、メモリ消費量を削減することが可能になります。 - -mg 2
優先利用するGPUのID。今回はNVIDIA Tesla P100を使用するため、ここでGPUIDを固定した。 - -sm none
モデル分散を行うかどうかの設定。今回はP100以外は使用してほしくなかったので、noneを指定した。
シェルスクリプトをこさえる
ここからはZabbix上での作業になります。こんなシェルスクリプトをこさえます。ファイル名は冒頭で参考とした内容そのまま send_chatgpt_api.sh という名前で保存し、実行属性を付与しています。
#!/bin/bash
export no_proxy=localhost,127.0.0.1
# アラート内容を引数に代入
eventid=$1
alert=$(echo $2 | sed -e 's/"/\\"/g')
header='Content-Type: application/json'
apiurl='http://<検証サーバのアドレス>:50999/v1/chat/completions'
prompt="以下のZabbixアラートの内容から、何が発生したのかを述べなさい。また、原因及び解消方法を簡潔に教えてください。文字数は256トークン以内とします。${alert} "
json='{"model": "gpt-3.5-turbo", "messages": [{"role": "user", "content": "'${prompt}'"}],"max_tokens": 256}'
# API実行
result=$(curl ${apiurl} -sS -H "${header}" -d "${json}")
# 出力
result_message=$(echo $result | jq -r '.choices[0].message.content')
echo $result_message
# Zabbix API設定
header='Content-Type:application/json-rpc'
apiurl='http://127.0.0.1:28080/api_jsonrpc.php'
# Zabbix APIでイベントにメッセージ追加
json='{"jsonrpc": "2.0","method": "event.acknowledge","params": {"eventids": "'${eventid}'","action": 4,"message": "'$(echo ${result_message} | sed -e 's/"/\\"/g')'"},"auth": "<WebUIから取得したAPIキー>","id": 1}'
curl -sS -X POST -H "${header}" -d "${json}" ${apiurl} | jq
exit 0
まず、OpenAIのChatCompletion処理ですが、modelに関してはダミー扱いとなっており、gpt-3.5-turboなどと書いてはいますが実際の動作には関係ありません。プロンプト内容は「以下のZabbixアラートの内容から、何が発生したのかを述べなさい。また、原因及び解消方法を簡潔に教えてください。文字数は256トークン以内とします。${alert} 」としており、次からくるメッセージは「Zabbixのアラートだよ」という条件付けをしています。これにより、「後続のメッセージはZabbixのアラートなんだなという全体で答えてくれる」ような動きをしてくれます。
Zabbix6.4から、Zabbix-APIに対してアクセスする際、わざわざlogin/logout処理を作らずともWebUI上でAPIキーを作成し、これを適用することで一気にAPIアクセスができるように改良されていましたので、これを採用しています。
実行してみる
このスクリプトに第一引数としてイベントID(発生したイベント履歴のID)とそのイベントID内でトリガーを発生させる要因になるITEM.NAME, ITEM.VALUEあたりを含めると以下のようになりました。
$ sudo /usr/local/bin/send_chatgpt_api.sh '87' 'Process down Server Process:proc.num[,,,/opt/llama.cpp/bin/server]:2'
このZabbixアラートは、/opt/llama.cpp/bin/server プロセスの数が 2 になっていることを示しています。これは、このプロセスが正常に動作していない可能性があることを意味しま す。 原因： - プロセスが停止した可能性がある。 - プロセスが起動できない可能性がある。 解決方法： - プロセスが停止している場合、手動でプロセスを再起動する。 - プロセスが起動できない場合、プロセスの起動スクリプトや依存関係を確認し、必要なものが正しくインストールされていることを確認してください。
{
"jsonrpc": "2.0",
"result": {
"eventids": [
87
]
},
"id": 1
}
Zabbix上のスクリプト設定に組み込み・メディア設定の実装
WebUI上で 通知 → スクリプト へ移動して「スクリプトの作成」をクリックし、新規にスクリプトを登録します。
上記は初期実装時に設定した内容ですが、第二引数にはITEM.NAMEやTRIGGER.NAMEとかを加えてもよいかと思います。情報が多いほどLLMはいい感じに解説してくれると思います。
続いてメディア設定を行い、以下の通り実装します。
アクションには、任意の障害レベルでこれを適用するかしないかを選んでおきまして、実行内容には先ほど設定したスクリプトを適用するよう記述します。今回「軽度の障害」以上を実行対象にしまして、試しに別のllama.cppのサーバプロセスを停止したところ、以下のような出力が得られました。
もうちょっと拡大するとこんな感じです。
Zabbixの追加コメント機能では改行とかが反映されないためこのような内容となりましたが、それでもどんなエラーかが分かる分だけ、使い勝手は多少向上するのではないかな？と思われます。
メールで送る場合
メールで送る場合は、そのテンプレートを若干修正することで盛り込むことが可能です。
Problem started at {EVENT.TIME} on {EVENT.DATE}
Problem name: {EVENT.NAME}
Host: {HOST.NAME}
Severity: {EVENT.SEVERITY}
Operational data: {EVENT.OPDATA}
Original problem ID: {EVENT.ID}
{EVENT.ACK.HISTORY}
{TRIGGER.URL}
今回盛り込まれてるメッセージは{EVENT.ACK.HISTORY}というメッセージの中に含まれるので、上記のようにこれを間に挟みます。
すると、以下のようなメッセージとしてメール本文に盛り込まれます。
Problem started at 14:20:22 on 2024.05.30Problem name: Process down Server ProcessHost: BDAE02.KYUSHU.IIJI.JPSeverity: AverageOperational data: 1, 1Original problem ID: 290{EVENT.UPDATE.MESSAGE}2024.05.30 14:20:39 "Zabbix Administrator (Admin)"このZabbixアラートは、/opt/llama.cpp/bin/server
プロセスが停止したことを示しています。 原因： - プロセスが正常に終了した可能性がある。 -
プロセスが停止した原因は、ログファイルやシステムログを確認することで確認できます。 解決方法： - プロセスを再起動する。 -
システムの問題が原因である場合、問題を解決するために必要な手順に従ってください。 例： -
システムの更新やパッチの適用によるプロセス停止の場合、更新やパッチの適用を完了させ、再起動してください。 -
システムのリソース不足によるプロセス停止の場合、必要なリソースを確保することで解決できます。
メール通知の際にこのようなLLM出力文を添えるだけでも、対処を考える際に少し内容を把握する際の助けになるかもしれません。
推論スピードについて
今回この仕組みにおいてどの程度の推論スピードが出せるのか調べてみました。結果は以下の通りです。
今回使用したNVIDIA Tesla P100(VRAM:16GB)ですと以下の通りでした。
そして、NVIDIA L4（VRAM:24GB)ですと以下の通りとなりました。
およそNVIDIA L4の推論速度はNVIDIA P100の2倍程度といったところかなと思われます。ちなみに44ms/tokenはちょっと遅めかも？ぐらいの速度、21.83ms/tokenはそこそこ早めなスピードって感じの体感速度だったかなと思います。この辺りを見誤ってしまうと、コメント生成処理が追い付かなくなってしまい、GPUに相当な負担をかけるだけでなく、その負担が続くことによる関連エラーの発報まで発生してしまって手に負えなくなりますので。
多発的に発生しないことを想定して、大体10秒以内で推論終了するような長さで出力させるぐらいがちょうどいいのかなと思います。
また、今回はモデルとして7Bモデルを使用しており、16bit動作させることで凡そ13GB程度のモデルファイルをベースにしています。これを4bit化させて動作させてまして、実測値ベースで7,748MiBを記録しました。容量が本来の4bit化に比べて大きくなったのは、コンテキストサイズを16kにしていることが要因で、その為のワークメモリ領域が確保されたからかと思われます。
ただ、この程度の容量であれば、エンタープライズで扱うにしても大体エントリークラスのNVIDIA A2/T4/L4当たりで十分かなと思われ、それらのグラフィックボードの2024年6月時点の標準売価は数十万円程度の額で済みます。これらのグラフィックボードは消費電力も低く、凡そ70W前後ぐらいで済むことから、比較的現実的なGPU構成でこのような機能を実装できると考えると、それなりに小規模なところでも活躍できる場所はあるのではないかなぁと感じています。
ファインチューニングとかになってくると、さすがにもう少し立派なGPUが必要になってくるような気はしますけど・・
「【正解を出すこと】に拘らなければ」使いようはいくらでも
LLMに対する幻滅ってのは、主に「正解が得られない」とか「決まったものが出てこない」というものに起因することが多いのですが、そもそもディープラーニングモデルの本来の動きが「予測をする」というものなので、その結果が100%ってのは基本あり得ません。
確率分布からLLMは「きっとこういうことを言ってほしいんだろう」ということを推測しているだけで、以前の記事でも述べたのかもしれませんが、「LLMってのはそもそも正しい答えを導くことを目的としたものではない」ということは何度でも繰り返し述べたいところです。
今回もこの中小規模なLLMがすべて最適解を出すことは想定してなくて、あくまで「Mistral-7b-Instruct-v0.3」内の知識で分かる限りの範囲で、出てきたこのアラートの解説を適当にやっておくれ・・・というまでのお話をしてるにすぎず、その正確性は保証できません。しかし、英語の文章にどうしてもアレルギーを起こす人のために、ざっくりした解説があるだけでもどういうエラーなのか？をとらえる際、より迅速にとらえるちょっとした補助的な用途を持たせるにはちょうどいいケースなのかなと思いました。
例えば「何でもかんでも答えてくれるAI」が欲しい場合はやっぱりAPI型のものが必要になるかなと思います。しかし、使い方として「日本語としてきちんと整理できるAI」として入力データを扱ってもらうのであれば、ローカルLLMの精度でもそれなりのものが得られるのではないかなと思うのです。
API型LLMにもリスクはある
API型LLMはローカルリソースに過大なものを要求しない代わりに、APIへアクセスするためのライブラリであったり問い合わせ作法であったりするところに「破壊的なアップデート」が掛かることがあります。「破壊的アップデート」とは、従来動作していたライブラリやAPI問い合わせ方法の下位互換性が喪失するレベルでのアップデートを指し、特にメジャーバージョンアップが発生した場合にこれが起きてることが多いです。
これを放置した場合、そのアップデート内容によってはある日を境に問い合わせをしてもエラー応答を返されることがあり、その際のメンテナンスに結構な手間と費用が掛かることが予想されます。
最新情報に対してセンサーを張る（RSSリーダーでキャッチアップするとか）ことで、ある程度の追従は可能ですが、昨今生成AI系のアップデートサイクルは非常に速く（速いってもんじゃないってぐらい速い）、それでも全部を押さえきれずにアップデート時にエラーが起きるなどの問題は結構私自身体験しているところでして、それなりに苦労するところも多いのです。
しかし、一度ローカル環境にデータをダウンロードして抱え込めるローカルLLMについては、ずっとそのままとはいきませんが、ある程度の環境凍結は可能になるため、比較的計画的なロードマップを引くことが可能になると言えます。もちろんその為の設定が必要になりますけれども、それも含めて事前に計画立てて遂行することにより、トラブル発生リスクを最小限に抑えることも可能です。
作って終わりではなく、こうしたメンテナンスを含めた考慮が実際の実装には必要になってくることを考えておいた方がよいというのが私としての考えになります。
向上してゆくローカルLLM
それにしてもMistral-7bモデルの実力には本当にたまげました。0.2まではとにかく日本語推論が苦手なモデルで、それに日本語解釈の機能を持たせた派生モデルを扱おうとして色々苦戦していましたが、まさか0.3でここまで劇的に進化しているとは・・昨今のローカルLLMの発展・進化スピードは侮っちゃだめだなと再認識した次第です。
ELYZAから新しいモデルも登場しましたね。
ついに登場しましたね。 Llama-3-ELYZA-JP-8B。
ELYZA社が提供するLLaMa-3ベースの日本語8Bモデルです。この推論品質及び推論速度がかなりすごいとのことで、社内の人に使用感を聞いてみたところ、大体GPT-3.5相当ぐらいの推論ができそうだとのこと。上位モデルである70BモデルではGPT-4を超えると言われてるようで、ローカルLLMも粒ぞろいなモデルがだいぶ増えてきたようですね。さて、引き続き活用ネタを探らねば。
