▼點擊下方名片，關注公眾號，獲取更多精彩內容▼
大家好，我是子衡，嵌入式 AI 工程師，《嵌入式AI：讓單片機學會思考》課程主理人，專注AI在MCU上的落地實踐。
零基礎速通嵌入式AI（加好友免費領取嵌入式AI資料）
上一篇文章中介紹了TInyML的一個典型應用：震動檢測。今天再介紹一個非常適合 TinyML 的應用方向：設備異常聲音檢測。
為什么說這個場景很適合 TinyML，因為它本質上不是一個“單閾值判斷”問題，而是一個“模式識別”問題。
1.為什么聲音異常檢測適合使用 TinyML？
傳統做法通常有兩類。
第一類是人工聽聲判斷：這種方式依賴經驗，主觀性很強，不可能長期在線，也不可能大規模復制。一個老師傅能聽出來，不代表系統能穩定做出來。
第二類是規則法：也就是采集聲音后做一些信號處理，例如算音量、RMS、峰值、FFT 某幾個頻段的能量，再設閾值判斷。
這種方法在簡單場景下有效，但一到真實現場就容易出問題。因為設備聲音不僅受故障影響，還受轉速、負載、安裝位置、環境噪聲、殼體共振、采集距離等等各種因素的影響。結果就是：
同一個閾值，今天能用，換個工況就不穩；為了減少誤報把閾值調高，又容易漏掉早期異常。
使用TinyML實現聲音異常檢測的最簡單的思路就是： 先讓系統盡量學會“什么叫正常聲音”。以后只要新來的聲音和正常模式差得比較遠，就判成異常。
這個案例適合 TinyML，還有兩個很現實的原因。
第一，麥克風前端成本低，很多設備改造難度比使用振動傳感器更小。
第二，聲音數據原始量很大，如果持續上傳云端，不僅費帶寬，也增加功耗和時延；而 TinyML 可以在本地做切窗、提特征、推理，只上傳結果或者少量異常片段，更適合長期在線運行。
所以，這個案例適合 TinyML，不是因為“聲音也能做 AI”，而是因為傳統規則法在這里很容易碰到上限，而 TinyML 又剛好能在低成本、低功耗、本地實時的條件下，把模式識別能力補上。
一個真實可落地的異常聲音檢測系統，通常不是“麥克風 + 模型”這么簡單，而是至少包含四部分：采集、前處理、推理、判決。
先看采集。
最前面是麥克風和安裝結構。這里最關鍵的不是“能不能錄到聲音”，而是“錄到的是不是穩定、可用的設備聲音”。麥克風離設備太遠，環境噪聲會蓋住設備特征；離得太近，又可能引入風噪、碰撞聲或者局部共振。所以安裝位置、朝向、固定方式、防護結構，都會直接影響效果。
然后是前處理。
原始音頻通常不會直接送進模型，而是先切成固定時間窗口，例如 250ms、500ms 或 1 秒，然后提取特征，例如頻譜圖、Mel 頻譜或者 MFCC。原因很簡單：原始波形太長，MCU 處理成本高；而頻譜類特征更容易把聲音模式壓縮成模型容易學習的形式。
再往后是推理。
模型本身通常不會很大，可能只是一個小型 CNN 或者全連接網絡，輸入是一幀聲音特征，輸出是“正常/異常”兩類，或者幾個常見狀態類別。第一版系統通常不建議一開始就做很多故障細分類，更合理的是先把“正常”和“偏離正常模式”區分開，把異常發現能力先做穩。
最后是判決。
真實系統不會因為單幀異常就立刻報警，因為聲音很容易被瞬時噪聲干擾。更常見的做法是連續多幀異常才觸發，或者異常分數持續超過閾值若干秒才上報。也就是說，模型輸出只是中間結果，最終能不能變成穩定產品，還要靠后面的系統判決邏輯。
所以這個系統真正的樣子應該理解成：麥克風穩定采集設備聲音，MCU 按固定窗口提取特征，輕量模型做本地推理，再由系統邏輯做平滑判決和異常上報。
這才是一個接近真實落地的 TinyML 聲音檢測系統。
設備異常聲音檢測，是一個非常典型、也非常適合 TinyML 的案例。它的核心價值在于：很多異常本質上是聲音模式變了，但這種變化很難用簡單閾值長期穩定地抓住，而 TinyML 恰好擅長在小設備上做這類模式識別。
這個案例真正值得嵌入式工程師重視的地方，不只是“聲音也能做 AI”，而是它非常符合真實產品開發邏輯：前端硬件成本不高，本地推理價值明確，系統閉環清晰，而且非常考驗工程能力。誰能把這種案例真正做成，不是學了一個概念，而是已經開始具備把 TinyML 落到設備里的能力了。
歡迎來我的課程學習嵌入式AI。
歡迎關注賀老師的公眾號，一起學習、一起成長。比如加入小編的微信及技術交流群，與高手一起學習。
掃描上方二維碼加群，回復【加群】或掃碼加我好友，限時免費進入技術交流群。
感謝大家閱讀，如果喜歡
請點贊和“在看”吧，或者分享到朋友圈。
點擊跳轉到原文，限時優惠加入我們的知識星球（加好友獲取免費券）
