88次元音響特徴のクロスプラットフォーム整合における工学的実践
ラボのノートPC上では98%の精度だったモデルが、生産ラインのMCUに載せると70%まで落ちる。この落差は、産業音響AIの実装に関わったことがある方なら、さほど珍しい話ではないだろう。
さらに厄介なのは、それがモデル自体の問題ではないという点だ。モデルのパラメータは1バイトも変わっていない。変わったのは、特徴抽出のコードがPythonからCに置き換わったことだけである。
機械視覚の領域であれば、この落差はたいてい致命的にはならない。視覚の前処理（リサイズ、正規化）は比較的標準化されており、浮動小数点と固定小数点の差異は後段のネットワークが吸収してくれる。
しかし音響は違う。音響AIの特徴抽出チェーンは、視覚よりはるかに長く、そして脆い。
01 なぜ音響は特に脆いのか
視覚モデルが受け取るのは、生の、あるいは軽微な加工を施されたピクセルである。特徴の学習は大部分がネットワーク自身に委ねられている。
一方、音響モデルが受け取るのは人間が設計した特徴だ。FFTスペクトル、Melフィルタバンクのエネルギー、MFCCケプストラム係数。これらの特徴は分類器に入る前に、すでに4〜5段階の数学的変換を経ている。
生波形 → フレーム分割と窓関数 → FFT → Melフィルタバンク → Log圧縮 → DCT → MFCC
それぞれの変換は、プラットフォームごとに実装が微妙に異なる。単体で見れば誤差は1〜3%程度かもしれない。しかしこれらの誤差は段階を追うごとに累積し、さらに分類器の非線形マッピングを通ることで、最終的な判定結果を文字通り反転させてしまう。
本来Passと判定されるはずのサンプルが、特徴ベクトルの偏移によって決定境界を越え、Failになる。「デモでは驚くほど良かったのに、ラインに載せたら崩れた」という現象の技術的な根本原因は、ここにある。
一言でいえば、フロントエンドの特徴が一致しなければ、後段のアルゴリズムがどれほど優れていても、入れるゴミからはゴミしか出てこない。
02 重なり合う4つの偏差源
Librosa（Python）で訓練し、CMSIS-DSP（C）で推論するという典型的な組み合わせを例に取ると、偏差は主に4つの層から生じる。
偏差1：FFT実装の差異
Python側は通常、実数FFTにゼロ詰め戦略を組み合わせて用いる。C側はしばしば固定小数点QフォーマットのFFTを採用する。両者はスペクトル振幅において1〜3%の偏差を生む。
この偏差は小さく見えるが、後続のすべての計算にとっての入力である。偏差はそのまま末尾まで伝播していく。
偏差2：Melフィルタバンクの規格分歧
最も踏みやすく、そして最も見落とされやすい落とし穴だ。
Melフィルタバンクには、主流の規格が2系統存在する。
・HTK方式：Librosaがデフォルトで採用。等間隔のMelスケールによる三角フィルタを用いる。
・Slaney方式：CMSIS-DSPおよび一部の組み込みライブラリがデフォルトで採用。フィルタの正規化方法が異なる。
両方式で算出される周波数帯の重みには系統的な偏移がある。ここで注意すべきは、これがランダム誤差ではないという点だ。方向が一定の偏差であるため、統計的に相殺されることはなく、安定して特徴を一方向へ押しやり続ける。
偏差3：DCT係数の精度と累積順序
MFCCの最後の段階は、Melエネルギーの対数を取った上でDCT変換を行うことである。
Python側は倍精度浮動小数点、C側は単精度あるいは固定小数点であり、しかも効率のために積和演算の累積順序を変更することが多い。浮動小数点の加算は結合法則を満たさないため、累積順序が異なれば末尾の差異が生じる。これは高次のMFCC次元においてとりわけ顕著に現れる。
そして高次のMFCC次元こそが、電磁的な鳴き（コイル鳴き）や高周波の摩擦といった、多くの異音欠陥の判別根拠となっている部分なのだ。
偏差4：Log10の実装精度
Melエネルギーの対数を取る際、Pythonは数値演算ライブラリの高精度な実装を用いるのに対し、C側は速度のためにテーブル参照や多項式近似を採用することが多い。
低エネルギーの周波数帯では、この差が増幅される。低エネルギー領域の対数は関数の勾配が急な区間にあたるため、入力のわずかな差が出力の大きな差になるからだ。結果として低エネルギー帯のS/Nが歪むが、低エネルギー帯こそが微弱な欠陥特徴を担っていることが多い。
03 どう整合するか：4つの工学的制約
解決の考え方は「誤差をできるだけ小さくする」ことではない。誤差を生む自由度を、源流から排除することだ。
以下の4つの措置は、実装の現場で有効性が確認されている。
措置1：Melフィルタバンクのハードコード
両端がそれぞれ公式に従ってMel重みを計算する方法をやめる。代わりにこうする。
C側からMel重み行列をエクスポートし、Python側はその同一データを直接読み込む。
これにより、HTKとSlaneyの規格分歧は完全に消滅する。両端が同じテーブルを使う以上、「どちらがどの規格を使うか」という問題自体が存在しなくなる。
措置2：DCTのテーブル参照化
DCT係数テーブルを事前計算しておく。
・C側：テーブル参照で積和演算を行う
・Python側：np.dot で同じテーブルを読み込み、行列積を計算する
これにより、累積順序の違いによる精度差がなくなる。両端が実行するのは同一の行列演算であり、入力が同じなら出力は必然的に同じになる。
措置3：Log10精度の統一
C側にテーブル参照方式のLog10を実装し、Python側は np.interp で同じテーブルを模擬する。
重要なのは同じテーブルを使うことであって、「それぞれが高精度なバージョンを実装する」ことではない。補間方式が一致して初めて、低エネルギー帯の圧縮挙動が完全に一致する。
措置4：FFTインスタンスのグローバル化
呼び出すたびにFFTインスタンスを再初期化することを避ける。初期化の内容によって異なるパディング戦略が混入し、非決定性をもたらす可能性がある。グローバル化すれば、毎回のFFT設定は完全に同一になる。
04 どう検証するか：最終精度ではなく、次元ごとに比較する
ここが多くのチームが間違える部分だ。特徴の整合を、最終的な精度で検証してしまうのである。
問題は、精度という指標が鈍いことだ。特徴がすでにドリフトしていても、決定境界を大規模に越えるに至っていなければ、精度は1〜2ポイントしか落ちず、異常は見えない。生産ラインに出て、临界（クリティカル）なサンプルに遭遇したときになって初めて、問題が一気に噴出する。
正しい検証方法は、特徴ベクトルを次元ごとに比較することだ。
1. 同一のテスト音源を用意する（1kHz正弦波と広帯域ノイズの両方を使い、狭帯域応答と広帯域応答をそれぞれ検証することを推奨）
2. Python側とC側で、それぞれ完全な特徴抽出チェーンを実行する
3. 中間特徴ベクトルを出力し、次元ごとに数値の差を比較する
88次元の音響特徴を例に取ると、次元ごとに比較した上で各次元の平均誤差を統計する。工学的に許容できる目標値は全次元で誤差0.05%未満である。
この水準に達していれば、モデルがプラットフォーム上で訓練されたときの特徴分布と、ハードウェア推論時に目にする特徴分布とが数値として一致していることを意味する。この状態であれば、モデルをハードウェアに同期した後でパラメータを再調整する必要はなく、現場での慣らし期間も不要になる。
05 実行可能なチェックリスト
これから音響AIのエッジ実装を行う、あるいは準備している方は、この順序で確認することを勧める。
確認項目 | よくある問題 | 対処方法
Melフィルタの規格 | PythonはHTK、C側はSlaney | 重み行列を一方から出力し、両端で同じものを読み込む
DCTの実装方式 | 倍精度 vs 単精度、累積順序の違い | テーブルを事前計算し、両端で同じテーブルを使う
Logの実装 | 数値ライブラリ vs 固定小数点近似 | テーブル参照方式に統一し、補間方式も一致させる
FFTの初期化 | 呼び出しごとに再初期化 | インスタンスをグローバル化し、パディング戦略を固定
窓関数 | Hann窓の periodic / symmetric 定義の違い | 定義を明確にし、両端で固定する
正規化パラメータ | 平均・分散を両端で別々に計算 | 訓練側でパラメータを確定し、ファームウェアに書き込む
検証方法 | 最終精度だけを見る | 中間特徴ベクトルの次元ごと比較に変更する
このうち窓関数の定義と正規化パラメータの2項目は見落とされやすい。Hann窓には periodic と symmetric の2種類の定義があり、長さが1サンプル異なる。短時間フレームへの影響は決して小さくない。また、正規化パラメータを両端で別々に計算すると、データ分布がわずかに違うだけで不整合が生じる。
おわりに
クロスプラットフォームな特徴の整合は、アルゴリズムの問題ではない。エンジニアリングの規律の問題だ。
必要なのは、より賢いモデルではなく、「両端は一致しなければならない」を譲れない一線として扱い、特徴抽出の各層の実装にまで落とし込むことである。アルゴリズム能力の高いチームでさえ産業実装でここに躓くのは、学術的な訓練の中にこの科目がないからだ。
裏を返せば、これを確実にやり遂げれば、得られるものは長期的だ。モデルを更新する際に配備による精度低下を心配する必要がなくなり、現場調整で無駄な再訓練が不要になり、ライン立ち上げの期間も大きく短縮できる。
本稿で述べた整合手法は、ARM Cortex-M55 + CMSIS-DSP プラットフォームにおける複数の生産ライン案件で検証済みであり、88次元音響特徴の次元ごと誤差は0.05%未満である。