タグ
#LLM
LLMに関する記事を公開しています。
AWS の判定モデル Strands Decider 2B はコードレビューのバグ探しに使えない
AWS の Strands チームが公開した判定モデル Strands Decider 2B に PR の差分からバグを当てさせました。既定の設定では長い差分の後ろを黙って捨て、設定を上げた伸びは大きい PR 1 本を丸ごと高く付けた結果でした。
Clef はリンク正誤判定なら Sonnet 並み、バグ探しには使えない
Cloudflare の判定モデル Clef を、自サイトの内部リンク関連度チェックとコードのバグ探しに使い、同じ問いを Claude Sonnet 5.5 にも投げて比べました。内部リンクでは Sonnet 5.5 と同じくらい当たり、費用は約 16分の1 でした。バグ探しでは、Clef が怪しいとした所の当たり方は無作為に選んだ場合とほとんど変わりませんでした。
結果がほぼ同じ判定に Claude は Jev の 70倍以上の費用がかかった
日本語の技術ブログ 137本の内部リンク関連度チェックを、同じ記事・同じ情報・同じ正解で Jev と Claude Sonnet 5.5 に解かせました。精度の差は小さく、費用は 70倍以上違いました。このチェックなら Jev で足ります。
Jev 互換をうたう無料モデルを内部リンクの判定で試したら、使い物にならなかった
Jev 互換をうたう無料の判定モデル Laya と Jeff を手元の CPU で動かし、ブログの内部リンクの判定に使えるか試すと、2つともモデルを使わないタグの一致にも負け、使い物になりませんでした。Laya は読んでいる記事で、Jeff は選択肢の並び順で点が決まっていました。
LLM に台本を判定させたら 12本すべて通した
生成した台本を LLM に判定させると 12本すべて通し、私が採用したのは 2本。判定のモデルを替えても私の選択には近づかず、通る台本が出たのは、生成の手前で素材を絞り、判定に通す例と落とす例を書き込んでからだった。
Jev に偶数判定・正解の無い 3択・日本語の建前・危険なコマンドを判定させた実験集
文と問いを渡すと確率だけを返す Jev は応答が速くコストも極めて低いため、if 文の代わりに使えないか、偶数判定・正解の無い 3択・日本語の建前・危険なコマンド・プロンプトインジェクションで実測しました。条件に使えなかったのは、計算が要る判定と、選択肢に正解が無い場面だけでした。
判定専用モデル Jev が LLM の代わりに使える処理と使えない処理
TypeSafe AI の Jev は文章を生成せず、宣言した選択肢への確率だけを返す判定専用モデル。自分のブログ記事 1本と、問い合わせを模した文 8件で日本語の判定を実測すると、原因の分類や窓口の振り分けは英語とほぼ同じ確率で当たり、好みの判定は Jev も Claude Sonnet も当てられなかった。
自動投稿 bot の設計を「ネタ→投稿」から「背景→投稿」に変えた
LLM で X に自動投稿する bot にテキスト投稿を足そうとして、「ネタの粒度」で機能を分ける設計を始め、書く前に破綻しました。bot を通す理由を「そのままでは投稿にならない背景を変換すること」と定め、境界線を「変換が要るか」の 1 本にしました。毎朝 GitHub の活動と PR 本文の「ハマったこと」欄を集めて Slack に提示する push 型に変え、返信がどのネタに届くか分からなくなった混線を 1 ネタ 1 スレッドにして解消し、状態機械の使い回しで生まれた競合を条件付き更新で防いだ記録です。
実況 AI が一歩遅れるので語るのをやめて相槌にした
カメラの前でゲストが手元の対象を次々切り替える様子を実況する音声 AI は、対象ごとに語ると構造的に追いつけず常に一つ遅れました。実際の MC に倣って基本は相槌、語るのは掲げた・止めた・声を上げたときだけにすると、高速な切り替え中も体験として成立しました。一方で検出器が「動きの山」しか見ておらず、止めて掲げた 20 秒間(差分 4〜8)を見逃し、静止イベントを足したら既存トリガーと二重発火して自己キャンセルが連鎖した経緯と、直列キューでの対処を記録しています。
OpenAI Realtime API に映像を流せないので 1fps の静止画で代用した
OpenAI の Realtime API には映像ストリームの入力がなく、音声実況 AI が 21 秒前の絵に反応していました。画像を「返事を求めない文脈」として 1fps で積み、「今切り替えるべき出来事か」だけを軽量な視覚言語モデルに一問で聞く設計に変えると、判定の中央値 1.7〜1.9 秒で手の動きを正しく棄却し、手元の実物の名前も当てました。検出 0.25 + 判定 1.7 + 発話 0.8〜1.9 秒の合計が人の動作と同じオーダーという限界と、次の一手まで含めた記録です。
OpenAI Realtime API の unknown_parameter で設定が全部消える
OpenAI の Realtime API で日本語のキャラクターを動かしていたら、設定に一行足しただけで英語の素のアシスタント(Hey there! What would you like to talk about)が出てきました。ベータ時代の名前 max_response_output_tokens が unknown_parameter となり、session.update が丸ごと拒否されて指示・声・VAD・転写言語がすべて初期状態のままだったのが原因です。session.updated を待ってから開始する、エラーは永続ログへ書く、計測にビルド SHA を記録する、という再発防止の記録です。
無言なのに AI が誰かと会話している原因は自分の残響だった
スピーカー運用の無言テストで、音声 AI が「なよぎら。」「そばランチ。」といった転写に返事をし、自分が言った単語が入力転写に現れていました。マイクの RMS は 0.001〜0.005 で静寂なのに、Web Audio API の自前再生はブラウザのエコーキャンセルの基準信号になりにくく、残留がサーバーの VAD に拾われて転写の幻聴と連鎖していました。ノイズゲートも VAD も「AI の声も声」なので止められず、再生と収音を WebRTC に預けて解決した記録です。
OpenAI Realtime API の response.cancel が効かない原因
OpenAI の Realtime API で発話を打ち切ろうと response.cancel を送ると response_cancel_not_active が返り、スピーカーからは前の話題が流れ続けました。モデルは 12 秒分の発話を約 2 秒で生成し終えていて、止めたかったのは生成ではなく再生でした。新しい応答が再生待ち行列の後ろに積まれて実況が一つ遅れる現象と、音が出る前の応答を打ち切ると出力ゼロの応答が連鎖する現象を、生成・送出・再生の 3 状態に分けて直した記録です。
LLM は喋っているのに音声が出ない原因は進行装置のフラッシュ
ライブ音声 LLM の上に番組進行の装置(状態機械・フェーズ転換・キュー注入)を被せたら、出力トークンは計上されているのにスピーカーから何も出なくなりました。原因は検出器の誤発火で 60 秒に 7 回フェーズが空転し、転換のたびに再生キューをフラッシュしていたことです。同じ条件でフラッシュを外すと発話が成立しました。制御を足すのをやめて合図を減らし、状態機械の責務をセッション寿命だけに縮めた設計の記録です。
検出器の精度ではなく誤検知時の体験で仕様を書く
リアルタイム AI アプリの動き検出で、精度チューニングが終わらない問題を精度を上げずに解決しました。検出結果の使い方を信頼度で二層に分け、低信頼側には疑問形の先走り反応しか許さない設計にすると、雑な検出器のまま出荷できます。64x48 のフレーム差分・約 30 行の実装で、音声実況 AI のシーン遷移がハンズフリーで 6 サイクル回りました。誤検知は、キャラクターが早とちりして違っていたら引っ込む演出になります。
システムプロンプトの禁止事項が効きすぎて出力が痩せる
映像を見て実況する音声 AI のシステムプロンプトに「見えていても知らないふりを通す」と書いたら、対象物の存在への言及まで消えました。「数字を数えない」と書いたら、目の前の個数の実況まで消えました。表層の語で書いた禁止は、モデルが安全側に過剰般化します。観察(可)と同定・評価(不可)のレベルに分けて対例つきで書き直すと、抑制の副作用が消えました。
Gemini Live API で turnComplete 後に音声が届かない
Gemini Live API の応答計測で、8 キュー連続で「転写あり・音声 0ms」という結果が出ました。原因は、turnComplete 受信で収集を打ち切っていた自分の完了判定です。映像ストリーミング併用時は turnComplete が音声チャンクより 0.7〜1.3 秒先に届きます。turnComplete と音声途絶を合成した完了判定に直すと 8/8 で正常受信になりました。
SDK なしで Gemini Live API を WebSocket で直接叩く
SDK を使わず ws と https-proxy-agent だけで Gemini Live API(BidiGenerateContent)と話す計測プローブの材料一式です。setup からのメッセージシーケンス、24kHz PCM を WAV にして聴く方法、企業プロキシ+社内 CA 環境での接続、実測した接続時間とセッション原価まで載せています。
Gemini Live API の proactive audio は自発的に喋らない
proactive audio という名前から「AI が自発的に喋り出す機能」を期待して設計を組んだら、公式リファレンスの定義は「直前の入力への応答を拒否できる」、つまりモデルが応答しないことを選べるようにする機能でした。自発的に喋るエージェントを作るならテキストキュー駆動が正解で、実測の初動 0.6〜1.0 秒で実用になります。2.5 Flash Live 系限定という制約も含めて整理しました。
Gemini Live API のセッションが突然切れる 3 つの制限
Gemini Live API のセッションが切れる理由は、セッション時間の上限・WebSocket 接続の寿命・ephemeral token の期限の 3 層に分かれていて、対処がそれぞれ違います。公式ドキュメントの数値を出典付きで整理し、GoAway が来ない切断への備えと、会話の切れ目まで待ってから接続し直す実装パターンをまとめました。