旅botが自分で旅に出た話
2025年2月2日 02:34
ちょっとナンなタイトルですがバグの話しです。気楽に聞いてください。
操作していないのに、いつのまにかToDoタスクが追加された
最初の兆候は去年の年末頃の話しです。
以前から話しているようにmi-serverはそもそもは個人的なToDoの管理サーバーです。これにいつのまにか「こんにちは」というToDoが追加されていたのです。
そのときのToDoの一つ
この文は感じから行ってAIが生成したものです。mi-serverは旅botも含めLLM APIやローカルLLMの管理もさせており、mi-serverが音声生成するときの会話文章によく似ています。
しかしToDoの追加機能はLLM側に任せていません。自分でwebFrontからテキストで入力するか、音声指示で「～をタスクとして追加してください」と意図的に指示しないとToDoは追加されません。
何か外部からクラックされた可能性もあるものの、好き好んでこんな脆弱なラズパイとか狙わんだろうなーと思いつつ、どこかにバグがあるんだろうなーとは思っていたのです。バグだとしてそんなに害がある訳でもないし、どっちかというと面白いので放ってました。この後2,3回くらい似たToDoがいつのまにか追加される現象は起きました。
15時頃にいつのまにか旅botの旅が停止する
今年に入ってから、15時～16時頃にいつのまにか旅botが停止する現象が起こり始めました。
旅botの停泊のスケジューリングは「複数のアバターを操作する+StreetViewの画像取得失敗時は時間を少し遅らせて再スケジュールする」という特性があるため結構複雑です(StreetViewの画像が取得出来る場所は意外と少なく画像取得は田舎だと結構失敗するのです)
複雑といっても継ぎ足し継ぎ足し修正しながら仕様が変わっていくという手探り開発の場合は仕方ないところなのですが、そのためこの付近はごちゃごちゃしており、まぁまたバグってるのかなと最初は思いました。
でもここ最近は旅botミニの作り込みでmi-server側はほとんど触っておらず「なんでいきなり顕在化したんだろう」と不思議でした。
そのうち連日起きたり起きなかったりとこれまた不思議な挙動。
X/Twitter側だとPOST数制限でわかりにくいですが、Bluesky側だとすっぽり夕方のポストがなく、再起動するとそこから再スタートして夜まで旅ということも数日ありました。
長崎を旅していたmiが突然アメリカを目指して出発する
そうした状況で1/27午後にそれは起きました。
Miの旅/ わくわく! 「あたし」は、また新しい旅に出発します! ということで、「第48回・412日目」のスタートです。 (reply Powered Llama3Elyza8b-q4,animagine-xl-3.1,etc.)
— mi trip bot (@marblewalker.bsky.social) 2025-01-27T05:41:18.172Z
この日は朝にmu,昼にmeiを起動した状態でmiは起動していません(ちなみに旅bot達の起動は現時点はコースを指定して手動起動です)
起動操作をしていないmiが動き出すはずはないのです。
こっちは仕事中ですし気づいたのは夕方。最近旅bot達の不定期停止が起きているのでこれもそれの一つかなと思って仕事中もあって放置していました。
miのほうはその後も進んでいきフェリーを乗り継ぎながら21時になっても終わりません。
Miの旅/ 夜遅くのガソリンスタンドの様子が見えますね。道は空いていて、ガソリンスタンドには大きな看板が輝いています。駐車場も確認できます。近くにコンビニのようなお店もあり、远くに建物がみえますね。ですね。 (Powered Google map apis,command-r(cloud),animagine-xl-3.1,claude3-haiku-V,etc.basePhoto:山中秀海)
— mi trip bot (@marblewalker.bsky.social) 2025-01-27T12:39:17.954Z
さすがに妙だと思ってdbを確認してみると
From=1352-1 Tatekushigō, Shinkamigoto, Minamimatsuura District, Nagasaki 857-4603, Japan
To=945 Main St, East Greenwich, RI 02818, USA
TilEnd=1738222949(unix epoch 1/30 16時頃)
3日間予定でアメリカに旅立っていたのです。。
ログを調査してみると
その後ログを少し調査しました。
旅botミニに集中してた頃なので、きちんと検証までは出来ていないのですが、ちょっと笑ってしまう結論が出ました。
遠因としてはLLM呼び出し部の潜在エラーリトライのバグとかあるのですが、ログを追ってみるとどうも作ったっきり忘れていた機能と小さなバグがからんでいたようなのです。
LLMが言った言葉が人用の音声コマンド入力に流れ込んでいた
mi-serverの音声入力コマンドは結構いろいろなものを試しており、スマートプラグのONやロボット掃除機起動から、旅botの状態報告、ToDoの追加、そして作って忘れていたのですが自動旅計画機能などもあります。
ただこれらは誤動作防止のためにホットワードを含めないと起動しない仕組みです(アレクサやok googleとかと同じです) 「旅」とか「お願い」とかいう言葉が含まれた場合に、音声コマンドの選択判定が可能になり、LLMにfunc callを選択可能になる仕組みです。その状態で音声コマンドにfunc callへのon/off指示があるかどうかを判定しLLMが判定すればfunc callから実際の機能が起動されます。
これとはまったく別の機能としてmi-serverにはニュースのDJ機能もあります。これもガッツリではないですが使っている機能です。
このときに他の方の記事で出てきた「難読語/専門英単語をローカルLLMで音読みにする」というのをいいアイデアと思ったので取り込んだのですが、ここで誤って音読み変換指示文を音声コマンドの入力として実行する対象の文章として流し込んでいたのです。。
keywordForInvokeFunc in: 次の文から英単語を抽出してください。その英単語を日本語の音読みに変換してカタカナで返してください。jsonで返してください。
「はい、分かりました!それでは皆さんこれにて本日のプログラムを終了いたします。今週もたくさんのリクエストや質問いただきありがとうございました。次回もぜひよろしくお >つまりAIがしゃべった文が単語音読み処理のときに再びAIの入力になることがあり、その語に「旅」とか「タスク」とかいう言葉が入っていたときにホットワードの誤動作防止をすり抜けてfunc callを実行することがある。
そのfunc callがToDoを追加したり、自動旅計画機能を実行したとしか思えない。
15時台というのは、DJ機能が実行される時刻なのです。。
完全にログ解析はしてないですし、実際に起動トリガーになった文を絞り込んだ訳ではないのです。すべてが合点している訳ではないのですが(例えば実際に旅botが起動した時刻は14:40頃)流れとしてはほぼこれで間違いないとみています。
なんか真冬の怪談として自分でウケてしまったので長々書きましたが、仕事ではないし笑い話でよいですね。
ちなみに起こりにくくはしていますが直してはいません。また起きないか、ちょっと期待していたりします。
追記
そういえば「人の旅」も
「自分の言った言葉」に
「自分が従って」一歩を踏み出すものですね。 ﾆﾔﾆﾔ
Noteの自分の記事より転記 https://note.com/marble_walkers/n/n4656eebf2ac5