**M5Stack LLM8850上でQwen2.5-0.5Bモデルを微調整し、2秒以内の応答速度で構造化コマンド出力を実現しました。**プロンプトエンジニアリングだけでは不可能だった小規模言語モデルによる正確なデバイス制御を、データセット改善と微調整により達成した技術検証レポートです。
背景:小規模モデルの構造化出力の課題
HomeAssistantなどのスマートホーム制御において、LLMを活用したい場合、理想的にはエッジデバイスで完結させたいものです。しかし、1.5B以下の小規模モデルで構造化されたJSON形式のコマンドを出力させることは容易ではありません。
プロンプトエンジニアリングの限界
最初はプロンプト設計で解決を試みました。システムプロンプトに利用可能なデバイスリストと出力フォーマットの例を提示しましたが、Qwen2.5-0.5Bモデルは自分で提示した例ですら正確に再現できませんでした。
システムプロンプト例:
- デバイスリスト(JSON形式)
- 出力フォーマット例
- 制御コマンド仕様
↓
ユーザー: "リビングのライトをつけて"
↓
モデル出力: (不正なJSON / デバイス名の誤認識)
小規模モデルでは、複雑な構造を理解し出力形式を保つことが困難であることがわかりました。
解決策:微調整による構造化出力の実現
参考にしたアプローチ
home-llmプロジェクトが3Bクラスのモデル微調整に成功していることを発見しました。このプロジェクトのコアアイデアは以下の通りです:
データセット構造:
システムプロンプト: ランダムな組み合わせのデバイス+サービスリスト
ユーザー入力: 事前定義されたコマンドリスト
アシスタント出力: 構造化されたJSON制御コマンド
データセットの改善ポイント
元のhome-llmデータセットには2つの問題がありました:
問題1: 存在しないデバイスへの対応
元データセットは「正常なデバイス制御」のみを学習させていました。結果として、システムプロンプトに存在しないデバイスを指定された場合、誤ったデバイスを制御してしまう危険性がありました。
改善策:
{
"instruction": "システムプロンプト(ベッドルームライトのみ)",
"input": "キッチンのライトをつけて",
"output": "申し訳ございません。キッチンのライトは制御可能なデバイスリストに存在しません。"
}
このような「デバイス未検出」パターンを追加することで、誤制御を大幅に削減し、ノイズ入力のフィルタリングも向上しました。
問題2: デバイスリスト認識能力の不足
「どんなデバイスを制御できますか?」という質問に答えられないだけでなく、デバイスリスト全体を理解する能力も不十分でした。
改善策:
{
"instruction": "システムプロンプト(複数デバイス)",
"input": "制御可能なデバイスを教えて",
"output": "現在制御可能なデバイスは以下の通りです:\n- リビングルームライト\n- ベッドルームエアコン\n- キッチンスマートプラグ"
}
このパターンを追加することで、デバイス名の出力精度が向上しました(完璧ではないものの、エリアとデバイスの組み合わせミスは減少)。
微調整プロセス(LLaMA Factoryを使用)
1. データセット形式変換
LLaMA Factoryの推奨形式に変換:
[
{
"instruction": "あなたはスマートホームアシスタントです。以下のデバイスを制御できます...",
"input": "リビングのライトを50%にして",
"output": "{\"device\": \"living_room_light\", \"action\": \"set_brightness\", \"value\": 50}"
}
]
2. dataset_info.json設定
{
"home_assistant": {
"file_name": "home_ass.json",
"columns": {
"prompt": "instruction",
"query": "input",
"response": "output"
}
}
}
3. 重要な前処理
LLaMA Factoryにプリセットされているアイデンティティデータセットの名前を、自分のアシスタント名に変更することを忘れずに。
4. 微調整実行
Google Colabでの実行例:
https://colab.research.google.com/drive/1i_RSU8Y0EpkvfhfzVPPmuEvwcT_zIdxL?usp=sharing
推奨環境: RTX 3090以上(無料のT4では時間がかかりすぎる)
結果: Qwen2.5-0.5Bモデルで、推論時間1.5秒以内を達成。ASR・音声検出・データ転送を含めても2秒以内で制御完了が可能になりました。
リソース公開
微調整済みモデルとデータセット:
https://huggingface.co/yunyu1258/qwen2.5-0.5b-ha
制御サービスのリファレンス実装:
https://github.com/yuyun2000/HomeAssistant-Edge
VAD、KWS、ASR、LLMモデルをロードし、HomeAssistantのAPIキーを入力するだけでローカルネットワーク制御が可能です。(M5Stack LLM8850推奨)
M5Stack LLM8850の利点
今回のエッジAI推論において、M5Stack LLM8850の以下の特性が効果的でした:
- オンデバイス推論: クラウド通信遅延がゼロ
- プライバシー保護: 音声データがローカル完結
- モジュラー設計: 将来的にマイク搭載の他のM5デバイスをクライアントとして追加可能
今後の改善課題
本プロジェクトは現在プロトタイプ段階です。実用化には以下の改善が必要です:
1. アーキテクチャの拡張
- LLM8850を推論専用サーバーとし、ASR/LLMをローカルネットワークサービス化
- マイク搭載のM5デバイスをクライアントとして接続可能にする
- クライアント側のコード実装
2. デバイス多様性への対応
実環境でのデバイスバリエーションテストが不足
3. 微調整サンプルの拡充
- ASR誤認識への頑健性向上: 同音異義語、誤変換への対応
- エッジ推論モード最適化: システムプロンプトをメモリ固定する現在の方式では動的情報(時刻、リアルタイム状態)の入力が困難。動的コンテキストに対応したサンプル設計が必要
- 新機能追加: タイマー設定など
まとめ
Qwen2.5-0.5Bという軽量モデルでも、適切なデータセット設計と微調整により、エッジデバイス上で実用的な構造化コマンド出力が可能になりました。 特に「デバイス未検出」パターンの追加が誤動作削減に大きく寄与しました。
M5Stack LLM8850のようなエッジAI推論環境と組み合わせることで、プライバシーを保ちながら低レイテンシなスマートホーム制御が実現できる可能性を示せたと考えています。