← 返回教程库

用 AI 给传感器数据做判断:从采集到理解

最后更新 2026-06-20
L4 · AI 赋能 / AIoT ⏱ 约 17 分钟 🟢 软件/低风险
你将学到
  • 看懂"采集数据"和"理解数据"是两件完全不同的事
  • 说清写死阈值判断的三个死穴,以及为什么环境一变就误报
  • 理解三种让数据更聪明的层次:云端大模型解读、端侧小模型、多传感器融合
  • 知道异常检测和预测性维护到底在做什么,以及 AI 判断绝不能碰的红线

你的板子已经能读温度、读光照、读湿度了。串口里哗哗刷出一串数字:26.3、26.4、26.2、31.8……然后呢?数字本身什么也不说。真正的问题不是"读到了多少",而是"这意味着什么"——这串数正常吗?那个突然跳到 31.8 的,是该报警,还是只是有人开了门?

采集数据,你已经会了。但采集只是把世界翻译成数字,理解才是让这些数字产生价值的那一步。这一节讲的就是这个跨越:怎么让一块板子不只是"读数的嘴",而是"看懂数的眼"。

读这篇前,你最好已经跑通过让硬件调大模型——还没看的话先补让硬件会说话,那一节的 HTTPS 调用思路,这里要直接用。

📌 说明

这一节通篇讲思路与判断框架,不给你某个具体模型的下载链接或某家 API 的字段名——那些会过时,也不是重点。我要让你建立的是"看到一串传感器数据,知道该用哪种方法去理解它"的判断力。具体落地是后面综合项目的事。


写死的阈值:能用,但很快就不够用

最朴素的"判断",你现在就会写:读到温度,跟一个写死的数字比一下。

if (temperature > 30.0) {
  alarm();   // 超过 30 度就报警
}

这行代码没错,简单场景下也够用。问题是它有三个躲不开的死穴,一旦环境稍微复杂,它就开始坑你。

  • 阈值是死的,世界是活的。 30 度这个数,夏天的客厅嫌低(误报一整天),冬天的机房嫌高(真出事了反而不响)。一个写死的数字,没法适应不同季节、不同房间、不同时段。
  • 它只看"瞬间值",看不到"趋势"。 温度从 25 慢慢爬到 29,每一刻都没破 30,阈值判断全程沉默——可这条持续上升的曲线,往往才是真正值得警惕的信号。它能抓住"已经很高了",抓不住"正在变坏"。
  • 多个条件一交叉,if 就写到崩溃。 "温度高且湿度低且持续 10 分钟才算异常"——这种组合条件,用嵌套 if 写下去,很快变成谁也读不懂、谁也不敢改的一坨。

阈值判断的本质局限:它要求你提前想清楚所有情况、并把每种情况翻译成精确的数字边界。可现实里,"什么算异常"常常是你说不清、却一眼能认出来的——这恰恰是 AI 擅长、而 if 不擅长的地方。


三种让数据更聪明的层次

让数据从"被采集"走到"被理解",有三条路,由重到轻、由云到端。它们不是三选一,真实项目里常常叠着用。

层次一:把数据喂给云端大模型,让它解读

最省事、也最强的一条路:把一段传感器读数直接发给大模型,让它用语言能力替你解读

大模型的本事不在算得快,而在"懂上下文"。你不用预先定义"什么算异常",直接把一段数据和背景丢给它,它能给你一段有判断的话。这条路的链路,和让硬件会说话里讲的 HTTPS 调用一模一样——只不过这回 POST 上去的不是"今天会下雨吗",而是一段数据加一句提问。

  • 好处:几乎零门槛。不用训练模型、不用调参,会发 HTTP 请求就能用上最强的理解力。改判断逻辑,改的是那句给模型的提问,而不是改代码。
  • 代价:慢(一次往返一两秒)、要花钱(按 token 算)、要联网(断网就瞎)。每一条都在让硬件会说话那节算过账,这里同样成立。

层次二:在端侧跑个小模型,做异常检测或分类

不是每件事都值得上云。有些判断,塞个轻量小模型在板子本地跑就够了——比如"这段振动波形正不正常""这个手势是哪一种"。

端侧 AI 的逻辑和云端正相反:模型小、能力窄,但快、不依赖网、数据不出门。一个训练好的异常检测小模型,能在板子上毫秒级地吐出"正常/异常"的判断,不用等云端那一两秒。代价是它只会它被训练过的那一件事,换个任务就得换模型。

这条路本身是一整个话题——怎么把模型塞进算力和内存都紧张的单片机、怎么训练、怎么部署——专门放在端侧 AI那一节讲。这里你只需记住一个判断原则:要快、要省、数据敏感、任务固定,就往端侧挪;要灵活、要懂上下文、任务多变,才上云。

层次三:多传感器融合,让判断更可信

单个传感器容易被骗。光照传感器读到变暗,是天黑了,还是有人用手挡了一下?光看它一个,分不清。

多传感器融合就是把好几路数据放一起看,互相印证。"光照骤降"配上"声音正常、温度没变",更像是有东西短暂遮挡;配上"温度也在掉、时间是傍晚",才更像天黑了。多一路佐证,误判就少一分——这和大模型把多个传感器读数一起喂进去解读,是天然搭配的:数据越全,它的判断越有谱。


示意:把一段读数发给大模型让它判断趋势

把层次一具体化。思路很简单:你平时是把"一句人话"发给大模型,现在改成把"一段数据加一个问题"发上去。

// 思路示意:把最近几次读数拼成一句话,问大模型怎么看
// (HTTPS 调用的完整写法见 l4-llm 那节,这里只示意"问什么")
String judge(float temps[], int n) {
  String data = "";
  for (int i = 0; i < n; i++) {
    data += String(temps[i]) + " ";   // 把读数拼成 "26.3 26.4 ... 31.8"
  }
  // 关键是这句提问:给数据 + 给背景 + 问一个具体问题
  String prompt =
    "这是某机房过去十分钟每分钟的温度(摄氏度):" + data +
    "。请判断温度趋势是否异常,若异常用一句话说明可能原因。";
  return ask(prompt);   // ask() 就是 l4-llm 里那个 HTTPS 调用函数
}

注意这段代码的重点不在传感器、也不在网络,而在那句 prompt。同样一串数,你问"现在多少度",它只会复述;你问"趋势是否异常、可能什么原因",它才会去做判断。给数据、给背景、问一个具体问题——这三件事决定了大模型是帮你"理解",还是只帮你"读数"。

💡 提示

别把生数据一股脑全发上去。一秒十条、发几小时,既烧 token 又让模型抓不住重点。先在板子本地做点预处理——算个均值、挑出几个突变点、压成"过去十分钟每分钟一个值",再发上去。喂给模型的不是原始数据,是你替它整理过的摘要,判断又准又省钱。


入门两个概念:异常检测与预测性维护

上面这些手法,在工业里早有名字。提前认识它们,你看任何 AIoT 项目都不会蒙。

  • 异常检测(Anomaly Detection):回答"现在这个数,正不正常?"。它的聪明之处在于不需要你预先定义"什么算异常"——给它喂足够多的"正常"数据,它自己学出正常长什么样,之后任何明显偏离正常的,它都能挑出来。比起写死阈值,它能抓住"说不清但就是不对劲"的那种异常。
  • 预测性维护(Predictive Maintenance):回答"这东西,还能撑多久?"。不等机器坏了再修,而是从振动、温度、电流这些数据的缓慢漂移里,提前判断"这个轴承大概两周后要出问题"。它盯的不是"现在坏没坏",而是"正在往坏的方向走"——正好补上写死阈值最大的那个盲区。

这两件事都建立在同一个前提上:先有一段"正常"的历史数据当基准。没有基准,AI 不知道什么叫"偏离"。所以做任何聪明判断之前,先老老实实采一段正常状态的数据存下来——这步偷不得懒。


一个综合小例子的思路:判断环境状态

把前面的东西串成一个能想象的小项目:用温湿度传感器光照传感器,让板子说一句"现在环境怎么样、要不要提醒"。

思路链条是这样的:

  1. 采集:每隔几分钟读一次温度、湿度、光照,各自存最近十几个值。
  2. 本地粗筛:先用最简单的逻辑挡掉明显的废数据(比如读到 -100 度,是传感器抽风,直接丢掉)。这一步纯 if 就够,不用劳烦 AI。
  3. 整理摘要:把三路数据各压成一句话——"温度稳定在 26 度上下""湿度从 60% 缓慢降到 45%""光照在傍晚正常变暗"。
  4. 融合判断:把这三句摘要一起发给大模型,问它"综合看,现在环境舒适吗?有什么要提醒主人的?"。三路印证,它能给出比单看任何一路都靠谱的话:"温度舒适,但湿度偏低且仍在下降,建议开加湿器"。
  5. 输出:把这句话显示在屏幕上,或念出来。

看出门道没有:简单、确定、要快的活儿(粗筛废数据)留给 if;说不清、要懂上下文的活儿(综合判断舒不舒适)交给 AI。这条"本地粗筛 + 整理摘要 + AI 综合"的分工,几乎是所有 AI 传感项目的通用骨架。


避坑:AI 判断不能碰的红线

把判断交给 AI 很爽,但有几条线踩了会出大事,说在前面。

🚧 避坑

绝不要让云端 AI 做实时的、安全关键的判断。 火灾报警、燃气泄漏、设备急停、跌倒检测——这类"晚一秒就出人命"的事,只能用本地、确定、即时的逻辑去守(往往就是一个朴素的阈值加硬件联动)。云端 AI 那一两秒延迟、那个"断网就瞎"的依赖、那点"偶尔抽风给错答案"的不确定性,在安全场景里全是致命的。AI 可以在安全逻辑之上做"更聪明的提示",但它永远不能是那道保命的底线

除了这条红线,还有两笔实在账要记:

  • 延迟:每一次上云判断都是一两秒往返。盯着一个慢变量(室温)这没问题;但凡需要"立刻反应"的,云端这条路就不合适,得往端侧挪。
  • 成本:传感器是会不停产生数据的,而上云是按量花钱的。一个一秒发一次的设备,一天就是八万多次调用——账单会吓你一跳。所以前面反复强调"本地预处理 + 发摘要而非生数据",省的就是这笔钱。

动手挑战

别只看,动手把"理解数据"这件事跑起来:

  1. 先不接 AI:让板子连续读温度,自己在代码里算"最近十次的平均值"和"这一次比平均高了多少"。把"瞬间值"升级成"带趋势的判断",你会发现光这一步,误报就少了一大半。
  2. 再接上 AI:把上面那十个值拼成一句话,套用让硬件会说话里的 HTTPS 调用,发给大模型问它"这个趋势正常吗"。比较一下:你写的"超过均值就报警"和大模型的判断,谁更靠谱、各错在哪。

卡住了?把你的数据、你的 prompt、还有模型给的回答一起发给 AI,让它帮你改提问、对字段。


小结 · 你现在掌握了什么

  • 你分得清"采集数据"和"理解数据"是两件事:前者你早会了,后者才是让数字产生价值的那一步。
  • 你说得清写死阈值的三个死穴——阈值死、只看瞬间不看趋势、组合条件写到崩——以及为什么环境一变就误报。
  • 你知道了让数据更聪明的三个层次:云端大模型解读、端侧小模型、多传感器融合,以及该按"要快还是要灵活"来选。
  • 你记住了那条红线:安全关键的实时判断,只能靠本地确定逻辑,AI 永远不当保命的底线。

从"读数"到"懂数",你已经迈过去了。接下来这条路有两个去向:想看一个完整项目怎么把采集、判断、输出串成一体,去实战项目挑一个动手做;想让判断不依赖云、在板子本地毫秒级出结果,去端侧 AI那一节,把模型真正塞进单片机里。

📄 来源 / 自校链接

本文为公开资料整理,非亲测。关键参数与代码请结合实物与下列官方来源验证。

内容有错、看不懂、或想看下一期?告诉我们 →

本文为公开资料的学习整理,非亲测。涉接线/花钱/合规的步骤请结合实物与官方最新资料验证,风险自负。见免责声明