简介teachable_machine 对应 CS580HO 可教学机器项目以谷歌 Teachable Machine 为原型面向学生、教育者以及想快速上手机器学习的前端开发者可在浏览器中直观体验图像、手势与声音识别任务。资源一共 7 个文件压缩包仅 162KB包含 HTML 页面结构、CSS 界面样式、JavaScript 交互逻辑与模型调用、说明文档及示例图片结构精简便于阅读和二次修改。学习者可以自己采集面部表情、手势或语音片段实时观察不同训练数据对识别效果的影响借此理解监督学习、数据收集与标注、分类器训练与迭代优化等核心概念也能借助 TensorFlow.js 在浏览器中运行模型理解从训练到推理的完整链路并了解模型性能的限制与改进方向。已有 431 人学习/下载。对初学 AI 的读者而言它既能作为可运行的交互示例又能练习 HTML、CSS、JavaScript 的实际应用适合课程设计或自学入门。 刚开始接触 Teachable Machine 的时候我其实有点不屑一顾——毕竟做了这么多年开发训练模型这种事不写代码总觉得不踏实。但后来一个给非技术同事做内部工具的需求彻底改变了我的看法。当时需要快速验证用摄像头识别不同零部件摆放位置这个想法能不能落地传统流程走一遍要两三天用 Teachable Machine 从录数据到导出模型前后不到两个小时。那一刻我才意识到这类无代码机器学习工具真正的价值不在于替代专业训练流程而在于把想法验证和原型落地的门槛降到了近乎为零。这篇文章就是冲着实际应用去的。我会从 Teachable Machine 能解决什么问题讲起然后拆解数据采集和训练参数那些容易被忽略的细节再重点说导出到不同平台的流程和部署时的坑最后聊聊它的能力边界和进阶玩法。不管你是想给学生做个趣味 AI 教具、给团队搭个快速原型验证工具还是单纯想搞明白这种浏览器里训练模型到底是怎么实现的这篇都能帮你少走不少弯路。1. 为什么一个网页工具能训练模型TM 背后的迁移学习逻辑Teachable Machine后面简称 TM是 Google 推出的一个基于浏览器的无代码机器学习平台主打图像分类、音频分类和姿态分类三类任务。听起来很神奇但它能在浏览器里跑起来并快速完成训练靠的并不是什么黑科技而是两件事迁移学习和 Web 端的推理优化。先搞明白 TM 的训练原理。它默认的图像模型基于 MobileNet 架构这是一个为移动端和嵌入式设备设计的轻量级卷积神经网络。TM 在加载时会先把 MobileNet 在大规模图像数据集上预训练好的权重加载进来这部分权重已经学会了识别边缘、纹理、形状等通用视觉特征。当你上传自己的分类图片后TM 做的其实是冻结MobileNet 主干网络只训练最后几层全连接层——也就是让模型把已经学到的通用特征映射到你的具体类别上。这就解释了为什么 TM 只需要每类几十张图片就能训练出可用的模型而传统从零训练一个卷积神经网络动辄需要上万张图片。你可以把 MobileNet 的预训练权重理解成一个见过无数物体的实习生你对它做的训练只是告诉它以后见到圆形的、带纹路的就归为 A 类见到方形的、光滑的就归为 B 类它不需要从头学什么叫纹理、什么叫形状只需要学怎么组合已有知识来回答你的问题。音频分类和姿态分类的原理也类似。音频模型会用预训练的音频特征提取器处理频谱图姿态模型则直接通过 PoseNet 或 MoveNet 提取人体关键点坐标再把关键点坐标作为特征输入分类器。所以拍一段动作就能训练举手挥手的分类核心是 TM 已经把人体关键点检测这个脏活累活干完了你只需要提供动作样本。我之所以先讲透这层原理是因为后面所有关于怎么采数据怎么调参数的决策根源都在这里。理解了 TM 是在微调预训练模型你就明白为什么数据质量远比数据数量重要为什么类别太相似会导致训练效果差也就能理解为什么有时换一组背景模型准确率就突然暴跌——因为这些都跟特征提取层对你数据的适配程度有关。2. 数据采集和训练参数决定模型成败的隐藏细节TM 的界面设计得极其简洁上传数据、点训练、看结果三步走完。但也正是因为太简单很多人会忽略数据采集这个真正决定模型质量的环节。我见过太多人随手拍几张图就点训练结果模型在测试时表现得惨不忍睹回头还怪工具不好用。实际上TM 的模型能力上限就是由你提供的数据决定的。2.1 每类样本的数量、多样性和背景控制先给一个可落地的起步值图像分类每个类别准备 50 到 100 张图片音频每个类别 20 到 30 段样本姿态每个类别 30 到 50 段动作视频。这个数量级足够 TM 训练出一个在受控场景下表现不错的模型。但数量只是底线真正拉大差距的是样本的多样性。多样性这个词听起来抽象落到图像分类上就是三个维度拍摄角度、光照条件和背景环境。如果你训练的样本全是从正上方拍的、在固定灯光下拍的、背景是纯色桌面的那模型学到的其实是你拍摄环境的特征而不是物体本身。等模型部署到真实场景光线一变、角度一转、背景一换准确率断崖式下跌。我自己的经验做法是每个类别采集时刻意让物体在画面里偏左、偏右、偏上、偏下距离远近各来几张再换几个不同的光照时段。如果部署场景的背景是固定的那就让训练数据的背景尽量贴近真实使用环境这样模型能更快收敛。背景这块有个常见误区为了干净大家倾向于找纯色背景拍。这在实际部署时反而容易翻车。如果训练时全是纯白背景使用时背景出现一个纸箱模型可能直接懵掉。更稳妥的做法是训练数据里混入几种与真实使用场景接近的背景让模型学到物体本身长什么样而不是白色背景加物体长什么样。2.2 类别设计哪些能分哪些分不了类别的区分度直接决定了模型上线的效果。TM 不是万能的它能够学会的区分边界受限于 MobileNet 特征提取层的能力。一个典型的失败案例是试图区分不同品种的狗——如果这些狗长得太像比如柯基和柴犬幼犬MobileNet 提取的特征可能不足以支撑这么细粒度的分类。这时候不是你数据采得不够多而是 TM 的架构上限摆在那里。我常用的判断标准是如果一个人在不看标签的情况下光凭肉眼能快速分辨出两个类别那 TM 有大概率也能学会如果人眼都得分半天那 TM 基本也白搭。所以做类别设计时尽量让类别之间的差异落在形状、颜色、纹理等宏观特征层面。比如区分可乐瓶和矿泉水瓶靠瓶身颜色和标签图案就够但区分百事可乐瓶和可口可乐瓶如果两者都是红色系那就要靠商标图案这类细节特征模型的稳定性就很难保证。一个更稳的做法是先做两类粗分类有标签的瓶子和没标签的瓶子需要更细的区分时再接一个专门的分类模型或者人工介入流程。2.3 训练轮数、学习率和置信度阈值的调参经验TM 的高级设置里提供了三个参数训练轮数Epochs、学习率Learning Rate和批量大小Batch Size。默认值是轮数 50、学习率 0.001、批量 16。大多数人保持默认就能跑出不错的效果但具体到场景还是可以微调。训练轮数决定模型在训练数据上过多少遍。轮数太少模型还没充分学习到特征欠拟合轮数太多模型可能把训练数据里的噪声也背下来过拟合。我的经验是先从默认 50 轮开始观察训练完成后的准确率。如果训练集准确率很高但测试集表现差说明有过拟合倾向可以考虑把轮数降到 20 到 30如果训练集准确率一直上不去说明模型还没学够把轮数提到 80 到 100。批量大小影响训练速度和稳定性默认 16 在大多数场景下够用如果你的类别差异很小可以试着调小批量让每次更新参数时看得更仔细。置信度阈值不在 TM 的界面里而是在导出模型的代码中调节但它反而是上线时必须关注的参数。TM 输出的分类结果是各类别的概率分布模型告诉你A 类 0.8、B 类 0.15、C 类 0.05你得决定多高的概率才算是 A 类。如果阈值设得太低比如 0.5那模型给出 0.51 的结果也会被当成有效判断容易误判设得太高比如 0.95模型会频繁告诉你我不确定导致大量输入无法被分类。我在实际项目中一般先设为 0.7 到 0.8然后跑一批真实数据统计置信度的分布再根据宁可拒绝也不能误判还是宁可误判也不能漏判的取舍来微调阈值。3. 导出与部署从浏览器到真实应用的完整链路模型训练完成只是第一步TM 真正的价值在于它提供了多样化的导出格式让一个浏览器里训练出来的模型能跑进网页、iOS App、Android App甚至树莓派这类边缘设备。这个部分我踩过不少坑值得单开一章讲。3.1 四种导出方式怎么选TM 的导出模型面板里有四种选项TensorFlow.js、TensorFlow Lite、TensorFlow SavedModel、TensorFlow.js带 Keras 层。它们的适用场景完全不同选错了后面会非常痛苦。TensorFlow.js 是部署到网页端的首选它能直接跑在浏览器里不需要服务器参与推理。TensorFlow Lite 面向移动端和嵌入式设备适合打包进 Android App 或跑在树莓派上。TensorFlow SavedModel 是完整模型格式适合在 Python 环境中配合 TensorFlow Serving 做服务端部署或者作为基础做二次迁移学习。带 Keras 层的 TensorFlow.js 导出则保留了模型结构方便你进一步修改网络结构。这四种格式的差异我整理成了表格方便快速对照导出格式适用场景能否自定义修改模型结构部署难度TensorFlow.js网页端推理纯浏览器运行不能直接加载使用低TensorFlow Lite移动端 App、嵌入式设备一般不能但可做量化优化中TensorFlow SavedModelPython 服务端、二次训练可以完全开放中高TensorFlow.js带 Keras 层需要改网络结构的网页端可以模型结构完整保留中我给个更直接的建议如果你想快速做网页 Demo直接用普通的 TensorFlow.js如果要做移动端应用原型导 TensorFlow Lite 然后配合 Flutter 或原生 Android 调用如果想深入改造模型或者和现有 Python 训练流程结合导 SavedModel。3.2 网页部署的完整流程和常见报错网页部署是最多人用、也最容易出问题的路。导出 TensorFlow.js 格式后你会得到一个 model.json 文件加一组权重 bin 文件。最常见的错误是只上传了 model.json 而忘了权重文件导致浏览器加载时报错 Could not load model。这两个文件必须放在同一目录并且路径要和 model.json 里的引用保持一致。加载模型的上游代码很简单但有一次我在一个项目里加载模型后怎么都拿不到预测结果排查了很久发现是模型路径写错了。这里有个容易忽略的点如果你用了前端构建工具比如 Vite 或 Webpack把模型文件放在 public 目录下加载路径写的是绝对路径如果放在 src 目录下被打包处理路径就要跟着资源处理规则走。建议直接把模型文件放 public 目录用相对路径加载省掉一堆构建工具的幺蛾子。另外TM 导出的模型在浏览器里跑推理时第一次加载后需要做一次预热否则第一次预测速度会明显偏慢。做法是加载完成后立即用一张全黑或全白的图片调用一次 predict 函数把 WebGL 的纹理缓存和模型权重加载流程先走一遍。这个小技巧在线上 Demo 演示的时候特别有用不至于现场第一次点击按钮卡顿三秒钟。3.3 模型量化和性能优化本地跑不卡才叫真的部署完成导出 TensorFlow Lite 后模型文件通常有几十兆这对移动端来说偏大。好在 TFLite 支持量化——把模型的权重从 32 位浮点数压到 8 位整数。量化后的模型体积能缩小约四倍推理速度也能提升不少代价是准确率会有一点点下降。TM 官方导出流程里没有直接提供量化选项但你可以把导出的 TFLite 文件丢到 Python 环境里用 TensorFlow 的转换器做量化或者用一些第三方在线工具处理。网页端也有类似的性能优化思路。TM 的模型在浏览器里默认用的可能是 CPU 计算如果你的页面可以明确要求使用 WebGL 后端推理速度会有质的提升。设置方式很简单在加载模型后加一句await model.setBackend(webgl);这句话会让 TensorFlow.js 把矩阵运算交给 GPU 完成。我在一个识别分类的项目里实测过同一套模型在 CPU 后端下单次推理要 80 到 120 毫秒切到 WebGL 后降到 15 到 25 毫秒体感上是完全不同的流畅度。4. 边界、局限与进阶玩法别指望 TM 解决所有问题TM 虽然好用但它有明确的能力边界。把这些边界搞清楚比学会操作本身更重要。我见过有人试图用 TM 做工厂质检里的细粒度缺陷分类也有人想靠它做复杂场景下的多目标检测——这些都属于用错工具最后大概率会得出AI 不可用的错误结论。4.1 哪些场景千万别用 TM第一类是细粒度分类。就像前面说的需要区分相似度极高的子类比如电池表面不同位置的划痕、不同颜色的同款螺丝MobileNet 的特征提取能力就是不够用。这种情况应该考虑用更大的模型或者自己训练一个专门的特征提取器。第二类是目标检测和位置定位。TM 的核心能力是图像分类也就是判断这张图里最主要的东西是什么。你要是想框出图里每个物体的位置和类别TM 做不到。那是 YOLO、SSD 这类目标检测模型的领地。不过有个变通方案如果你能把物体在哪个位置这个问题转换成不同位置专属的分类问题——比如监控摄像机固定机位下判断商品摆放在 A 区还是 B 区可以通过裁剪画面成两个区域、分别训练两个分类器来解决但这就涉及到更多的工程设计了。第三类是样本量极少且类别又多的场景。每类图片就三五张还想分十个类别这种极端数据依赖下 TM 的训练效果会很不稳定。迁移学习能降低数据需求但降低程度是有下限的。4.2 从 TM 到专业训练的衔接思路TM 导出模型后并不代表这条技术路线走到了尽头。一个更容易被忽视的用法是把 TM 当做一个快速的数据标注和可行性验证工具。你可以在 TM 里快速验证这个分类问题到底可不可行,如果可行再用导出的 TensorFlow SavedModel 格式在 Python 环境里做进一步优化——加载 TM 的权重作为初始权重用更专业的训练流程比如更精细的数据增强、更合理的类别权重在本地继续训练。这样既享受了 TM 的低门槛起步又突破了它在模型结构上的限制。此外TM 导出的模型可以配合很多应用场景做扩展。比如把训练好的图像分类模型接到机器人小车套件上小车摄像头看到的东西会被分类然后根据分类结果执行不同动作——这种项目在学校创客教育和产品原型验证中非常常见。姿态分类模型则可以和游戏引擎联动用身体动作控制游戏角色做体感交互原型。这类玩法在 TM 和编程工具集成的生态里已经很成熟。4.3 给非技术背景使用者的几条建议如果你不是程序员只用 TM 做原型验证我的建议是先把数据采集当成最核心的工作来做不要急于点训练按钮。每次采集数据时保持同一个姿势和环境基准分批采完后随机抽一些样本做测试看模型是不是真的学到了类别的本质特征。TM 的预览窗口里可以实时看到模型对摄像头画面的分类结果这是非常直观的验证手段。多做几次调数据—重训—测试的循环你会发现准确率的提升路径和写代码调参数完全不同——它的瓶颈几乎永远在数据端。另外TM 的项目文件是可以导出的格式是一个 .tm 文件。这个文件包含了模型权重和样本数据。我强烈建议每次调好一版就导出保存一次因为它本质上就是个工程文件。我之前有一次在浏览器里清缓存项目直接没了模型没导出数据也没备份只能重新采集白白浪费了一个多小时。这种教训一次就够了。5. 从一个小学科学课项目到工业场景验证TM 的真实使用案例说了这么多理论分享一个我实际经手的项目或许能帮你更直观地理解 TM 的定位。当时朋友所在的小学要做一堂科学课内容是让学生理解人工智能如何识别物体。校方的硬件条件只有一台普通电脑和一个 USB 摄像头预算几乎为零网上现成的 AI 教学案例要么需要 GPU 服务器要么需要买昂贵的人工智能套件。我帮他们设计了一个方案用 TM 让学生每人拍 10 到 15 张手掌图片分石头、剪刀、布三个类别。课堂上的流程是每个学生轮流对着摄像头出拳电脑实时显示分类结果和置信度。整个过程中学生能直观看到模型是怎么从猜不准慢慢变准的——这其实就是数据迭代训练的过程。他们甚至不需要知道神经网络这个名词就已经在用工程师的方式思考问题了为了让剪刀的识别更准我需要补充更多角度的手势图片。做完这个案例我最大的感触是TM 这种工具真正的价值不在于模型性能有多强而在于它把一个复杂系统的因果关系变得可视化、可触摸。同样的逻辑放到工业场景里其实也成立。有个做仓储管理的朋友告诉我说他们想验证用摄像头判断货架上的货物是否摆放整齐但公司没有专职算法工程师。IT 部门用了三天时间学了 TM用现场摄像头拍了几十张整齐和凌乱的图片训练了一个模型部署在办公室电脑上每天截图自动跑一次分类准确率意外地不错。这个方案虽然原始但它解决了从 0 到 1 的问题——用最小成本验证了 AI 在那个场景下是否值得投入。如果验证结果是可行的再考虑引入专业团队做正式部署。这两个案例想说明的其实是同一件事TM 最适合的场景是快速搞清楚一个 AI 想法到底靠不靠谱。它不是一个生产级训练平台而是一个想法验证器和需求翻译器。把这件事想清楚你对它的期望就不会错位使用它的姿势也会自然正确。6. 我踩过的那些坑从网络加载失败到模型过拟合的解决记录最后一部分把我在 TM 实际使用中踩过的一些坑集中写出来。这些坑不一定每个人都会遇到但遇到了真的能卡很久写出来给大家省点时间。6.1 网络和浏览器相关模型加载失败的根源排查TM 整个流程都依赖浏览器联网但很多人没意识到的是模型训练和模型加载对网络的要求还不一样。训练过程是在浏览器本地完成的把数据丢给浏览器里的 TensorFlow.js 算数据不会上传到服务器。但导出模型的加载就涉及资源获取了。如果你是把 TM 导出的文件部署在自己的服务器上一定要确认服务器支持静态文件的正确 MIME 类型——特别是 .bin 权重文件有些服务器默认不认识这个扩展名会返回错误类型导致加载失败。我的排查方法很简单打开浏览器的开发者工具切到 Network 面板刷新页面看 model.json 和 .bin 文件有没有加载成功状态码是不是 200响应类型对不对。如果 404那就是路径问题如果是 200 但还报错那大概率是跨域问题。我遇到过最离谱的一次是文件托管在一个图片存储服务上服务商默认给 .bin 文件加了防盗链浏览器端拿不到内容折腾了好久才发现问题出在云服务配置而不是代码上。这类问题没有通用解法唯一能做的就是排查时先确认资源是真的能被完整访问。6.2 过拟合和欠拟合训练集测试集表现差距过大的处理TM 界面里只显示模型在训练集上的表现你看到的准确率 98%只是在它背过的题上考了 98 分换个新场景可能直接跌到 60%。所以在 TM 里训练完一定要做留出验证——把数据分成两部分比如每类留出 10 张图不参与训练等训练完成后用这 10 张图测试模型。TM 界面上没有直接提供这种划分方式但你可以利用添加样本功能把测试图片单独放到一个类别里跑一遍看分类结果。或者更简单的方法训练完点预览窗口打开摄像头把真实物体放到镜头前看实时分类结果和置信度。这个过程才是真正检验模型泛化能力的时刻。如果发现真实场景里频繁误判先别急着加数据重训。回到 2.2 节说的类别区分度检查一遍再看采集数据的背景和光照是否跟真实使用环境差距太大。绝大多数泛化问题出在这两个环节而不是 TM 的性能。6.3 音频和姿态分类的特有坑音频分类和姿态分类各自有一些隐藏问题。音频分类对背景噪声非常敏感。我训练时用麦克风采集的样本可能是在安静的办公室录的但部署到嘈杂的环境里模型会倾向于把所有声音都归为背景噪声那个类别。解决办法是采集时故意加入目标场景的底噪或者尽量在接近真实使用环境的地方采集数据。另外TM 的音频分类本质上是识别音频片段的频谱特征如果你的音频样本长度太短短于 1 秒特征提取会非常不充分分类效果会明显变差。音频样本建议每段 2 到 3 秒太短的信息不足太长的延时又太大需要在这两者之间做取舍。姿态分类的坑主要在动作对齐上。TM 的姿态分类提取的是人体关键点位置它对关键点出现在画面里的位置非常敏感。同样是举手动作站在画面左边举手和站在画面右边举手关键点在画面中的绝对坐标完全不同模型表现会有很大波动。解决思路是在训练数据里尽量覆盖不同的站位或者在做推理前对关键点坐标做归一化处理——比如把所有关键点坐标除以肩膀宽度得到一个相对位置这样能在一定程度上消除人物大小和站位的影响。但这个处理已经超出 TM 的操作界面范围了需要你在导出模型后的代码里自己实现。6.4 多浏览器兼容性为什么 Edge 能跑 Chrome 却不行最后分享一个偏门但容易遇到的情况TM 训练完模型导出 TensorFlow.js 部署到网页后有时候在 Chrome 上跑得好好的换到 Edge 或 Safari 就出问题。这通常是 WebGL 后端兼容性导致的问题。旧版本的 Safari 对 WebGL 2.0 支持不完整TensorFlow.js 某些算子会自动回退到 CPU 执行而某些算子在这种回退链上会报错。解决办法是在模型加载时加一个能力检测走一个兼容性兜底await tf.setBackend(webgl); try { await tf.ready(); } catch (e) { tf.setBackend(cpu); }实测下来这个处理能解决大部分浏览器兼容问题。另一个常见原因是浏览器版本太老TensorFlow.js 要求的最低版本已经不支持了。这类问题没有特别优雅的解决方案只能在写代码前先明确目标用户的浏览器水平再决定要不要扛这一层兼容性成本。7. 从原型到产品的最后一步TM 之外的取舍与思考文章写到这里我已经把 TM 从原理到实操到踩坑都过了一遍。但我还想再强调一件事TM 应该被理解为一个验证工具和入门阶梯而不是长期依赖的生产平台。我见过有些团队用 TM 训练出的模型跑了很长一段时间模型效果其实一直在一个可接受的范围内因为他们的场景足够简单、数据分布足够稳定。但如果你的需求是持续演进的比如数据分布会随时间变化、需要接入复杂的数据预处理流水线、或者对推理延迟有严格的服务端要求那 TM 的定位就只适合做原型不适合做生产。这时正确的路径是借助 TM 的快速验证能力和导出的模型文件迁到更完整的机器学习工程框架里去。这个迁移路径我在 4.2 节提过导出的 SavedModel 格式可以作为预训练模型在你的自有数据上继续训练。迁移到 Python 环境后你就解锁了更完整的数据增强策略、更灵活的训练循环、更精细的超参数调优手段。而且因为有 TM 那一步做了可行性验证这个迁移过程的风险大幅降低。这就像写代码先做 mock 验证接口约定确认无误后再实现完整逻辑——TM 就是那个 mock帮你用最低成本确认方案方向对不对。最后再分享一个我个人的操作习惯无论是做课程项目还是产品原型我都会把 TM 项目里采集的原始图片、音频导出到本地保存一份。因为 TM 的在线编辑能力虽然直观但它不是一个长期的资源管理系统项目多了之后查找和管理都会变慢。把原始素材归到你自己的目录结构里后面无论要切换到哪个平台数据都是完整可用的。毕竟一个机器学习项目的成败说到底数据才是真正的基本盘。工具会更新、架构会换、模型结构会变得更好但你手里那批经过验证的高质量数据才是任何时候都不会过时的资产。本文还有配套的精品资源点击获取 无代码机器学习实战：Teachable Machine 从模型训练到部署全指南
简介teachable_machine 对应 CS580HO 可教学机器项目以谷歌 Teachable Machine 为原型面向学生、教育者以及想快速上手机器学习的前端开发者可在浏览器中直观体验图像、手势与声音识别任务。资源一共 7 个文件压缩包仅 162KB包含 HTML 页面结构、CSS 界面样式、JavaScript 交互逻辑与模型调用、说明文档及示例图片结构精简便于阅读和二次修改。学习者可以自己采集面部表情、手势或语音片段实时观察不同训练数据对识别效果的影响借此理解监督学习、数据收集与标注、分类器训练与迭代优化等核心概念也能借助 TensorFlow.js 在浏览器中运行模型理解从训练到推理的完整链路并了解模型性能的限制与改进方向。已有 431 人学习/下载。对初学 AI 的读者而言它既能作为可运行的交互示例又能练习 HTML、CSS、JavaScript 的实际应用适合课程设计或自学入门。 刚开始接触 Teachable Machine 的时候我其实有点不屑一顾——毕竟做了这么多年开发训练模型这种事不写代码总觉得不踏实。但后来一个给非技术同事做内部工具的需求彻底改变了我的看法。当时需要快速验证用摄像头识别不同零部件摆放位置这个想法能不能落地传统流程走一遍要两三天用 Teachable Machine 从录数据到导出模型前后不到两个小时。那一刻我才意识到这类无代码机器学习工具真正的价值不在于替代专业训练流程而在于把想法验证和原型落地的门槛降到了近乎为零。这篇文章就是冲着实际应用去的。我会从 Teachable Machine 能解决什么问题讲起然后拆解数据采集和训练参数那些容易被忽略的细节再重点说导出到不同平台的流程和部署时的坑最后聊聊它的能力边界和进阶玩法。不管你是想给学生做个趣味 AI 教具、给团队搭个快速原型验证工具还是单纯想搞明白这种浏览器里训练模型到底是怎么实现的这篇都能帮你少走不少弯路。1. 为什么一个网页工具能训练模型TM 背后的迁移学习逻辑Teachable Machine后面简称 TM是 Google 推出的一个基于浏览器的无代码机器学习平台主打图像分类、音频分类和姿态分类三类任务。听起来很神奇但它能在浏览器里跑起来并快速完成训练靠的并不是什么黑科技而是两件事迁移学习和 Web 端的推理优化。先搞明白 TM 的训练原理。它默认的图像模型基于 MobileNet 架构这是一个为移动端和嵌入式设备设计的轻量级卷积神经网络。TM 在加载时会先把 MobileNet 在大规模图像数据集上预训练好的权重加载进来这部分权重已经学会了识别边缘、纹理、形状等通用视觉特征。当你上传自己的分类图片后TM 做的其实是冻结MobileNet 主干网络只训练最后几层全连接层——也就是让模型把已经学到的通用特征映射到你的具体类别上。这就解释了为什么 TM 只需要每类几十张图片就能训练出可用的模型而传统从零训练一个卷积神经网络动辄需要上万张图片。你可以把 MobileNet 的预训练权重理解成一个见过无数物体的实习生你对它做的训练只是告诉它以后见到圆形的、带纹路的就归为 A 类见到方形的、光滑的就归为 B 类它不需要从头学什么叫纹理、什么叫形状只需要学怎么组合已有知识来回答你的问题。音频分类和姿态分类的原理也类似。音频模型会用预训练的音频特征提取器处理频谱图姿态模型则直接通过 PoseNet 或 MoveNet 提取人体关键点坐标再把关键点坐标作为特征输入分类器。所以拍一段动作就能训练举手挥手的分类核心是 TM 已经把人体关键点检测这个脏活累活干完了你只需要提供动作样本。我之所以先讲透这层原理是因为后面所有关于怎么采数据怎么调参数的决策根源都在这里。理解了 TM 是在微调预训练模型你就明白为什么数据质量远比数据数量重要为什么类别太相似会导致训练效果差也就能理解为什么有时换一组背景模型准确率就突然暴跌——因为这些都跟特征提取层对你数据的适配程度有关。2. 数据采集和训练参数决定模型成败的隐藏细节TM 的界面设计得极其简洁上传数据、点训练、看结果三步走完。但也正是因为太简单很多人会忽略数据采集这个真正决定模型质量的环节。我见过太多人随手拍几张图就点训练结果模型在测试时表现得惨不忍睹回头还怪工具不好用。实际上TM 的模型能力上限就是由你提供的数据决定的。2.1 每类样本的数量、多样性和背景控制先给一个可落地的起步值图像分类每个类别准备 50 到 100 张图片音频每个类别 20 到 30 段样本姿态每个类别 30 到 50 段动作视频。这个数量级足够 TM 训练出一个在受控场景下表现不错的模型。但数量只是底线真正拉大差距的是样本的多样性。多样性这个词听起来抽象落到图像分类上就是三个维度拍摄角度、光照条件和背景环境。如果你训练的样本全是从正上方拍的、在固定灯光下拍的、背景是纯色桌面的那模型学到的其实是你拍摄环境的特征而不是物体本身。等模型部署到真实场景光线一变、角度一转、背景一换准确率断崖式下跌。我自己的经验做法是每个类别采集时刻意让物体在画面里偏左、偏右、偏上、偏下距离远近各来几张再换几个不同的光照时段。如果部署场景的背景是固定的那就让训练数据的背景尽量贴近真实使用环境这样模型能更快收敛。背景这块有个常见误区为了干净大家倾向于找纯色背景拍。这在实际部署时反而容易翻车。如果训练时全是纯白背景使用时背景出现一个纸箱模型可能直接懵掉。更稳妥的做法是训练数据里混入几种与真实使用场景接近的背景让模型学到物体本身长什么样而不是白色背景加物体长什么样。2.2 类别设计哪些能分哪些分不了类别的区分度直接决定了模型上线的效果。TM 不是万能的它能够学会的区分边界受限于 MobileNet 特征提取层的能力。一个典型的失败案例是试图区分不同品种的狗——如果这些狗长得太像比如柯基和柴犬幼犬MobileNet 提取的特征可能不足以支撑这么细粒度的分类。这时候不是你数据采得不够多而是 TM 的架构上限摆在那里。我常用的判断标准是如果一个人在不看标签的情况下光凭肉眼能快速分辨出两个类别那 TM 有大概率也能学会如果人眼都得分半天那 TM 基本也白搭。所以做类别设计时尽量让类别之间的差异落在形状、颜色、纹理等宏观特征层面。比如区分可乐瓶和矿泉水瓶靠瓶身颜色和标签图案就够但区分百事可乐瓶和可口可乐瓶如果两者都是红色系那就要靠商标图案这类细节特征模型的稳定性就很难保证。一个更稳的做法是先做两类粗分类有标签的瓶子和没标签的瓶子需要更细的区分时再接一个专门的分类模型或者人工介入流程。2.3 训练轮数、学习率和置信度阈值的调参经验TM 的高级设置里提供了三个参数训练轮数Epochs、学习率Learning Rate和批量大小Batch Size。默认值是轮数 50、学习率 0.001、批量 16。大多数人保持默认就能跑出不错的效果但具体到场景还是可以微调。训练轮数决定模型在训练数据上过多少遍。轮数太少模型还没充分学习到特征欠拟合轮数太多模型可能把训练数据里的噪声也背下来过拟合。我的经验是先从默认 50 轮开始观察训练完成后的准确率。如果训练集准确率很高但测试集表现差说明有过拟合倾向可以考虑把轮数降到 20 到 30如果训练集准确率一直上不去说明模型还没学够把轮数提到 80 到 100。批量大小影响训练速度和稳定性默认 16 在大多数场景下够用如果你的类别差异很小可以试着调小批量让每次更新参数时看得更仔细。置信度阈值不在 TM 的界面里而是在导出模型的代码中调节但它反而是上线时必须关注的参数。TM 输出的分类结果是各类别的概率分布模型告诉你A 类 0.8、B 类 0.15、C 类 0.05你得决定多高的概率才算是 A 类。如果阈值设得太低比如 0.5那模型给出 0.51 的结果也会被当成有效判断容易误判设得太高比如 0.95模型会频繁告诉你我不确定导致大量输入无法被分类。我在实际项目中一般先设为 0.7 到 0.8然后跑一批真实数据统计置信度的分布再根据宁可拒绝也不能误判还是宁可误判也不能漏判的取舍来微调阈值。3. 导出与部署从浏览器到真实应用的完整链路模型训练完成只是第一步TM 真正的价值在于它提供了多样化的导出格式让一个浏览器里训练出来的模型能跑进网页、iOS App、Android App甚至树莓派这类边缘设备。这个部分我踩过不少坑值得单开一章讲。3.1 四种导出方式怎么选TM 的导出模型面板里有四种选项TensorFlow.js、TensorFlow Lite、TensorFlow SavedModel、TensorFlow.js带 Keras 层。它们的适用场景完全不同选错了后面会非常痛苦。TensorFlow.js 是部署到网页端的首选它能直接跑在浏览器里不需要服务器参与推理。TensorFlow Lite 面向移动端和嵌入式设备适合打包进 Android App 或跑在树莓派上。TensorFlow SavedModel 是完整模型格式适合在 Python 环境中配合 TensorFlow Serving 做服务端部署或者作为基础做二次迁移学习。带 Keras 层的 TensorFlow.js 导出则保留了模型结构方便你进一步修改网络结构。这四种格式的差异我整理成了表格方便快速对照导出格式适用场景能否自定义修改模型结构部署难度TensorFlow.js网页端推理纯浏览器运行不能直接加载使用低TensorFlow Lite移动端 App、嵌入式设备一般不能但可做量化优化中TensorFlow SavedModelPython 服务端、二次训练可以完全开放中高TensorFlow.js带 Keras 层需要改网络结构的网页端可以模型结构完整保留中我给个更直接的建议如果你想快速做网页 Demo直接用普通的 TensorFlow.js如果要做移动端应用原型导 TensorFlow Lite 然后配合 Flutter 或原生 Android 调用如果想深入改造模型或者和现有 Python 训练流程结合导 SavedModel。3.2 网页部署的完整流程和常见报错网页部署是最多人用、也最容易出问题的路。导出 TensorFlow.js 格式后你会得到一个 model.json 文件加一组权重 bin 文件。最常见的错误是只上传了 model.json 而忘了权重文件导致浏览器加载时报错 Could not load model。这两个文件必须放在同一目录并且路径要和 model.json 里的引用保持一致。加载模型的上游代码很简单但有一次我在一个项目里加载模型后怎么都拿不到预测结果排查了很久发现是模型路径写错了。这里有个容易忽略的点如果你用了前端构建工具比如 Vite 或 Webpack把模型文件放在 public 目录下加载路径写的是绝对路径如果放在 src 目录下被打包处理路径就要跟着资源处理规则走。建议直接把模型文件放 public 目录用相对路径加载省掉一堆构建工具的幺蛾子。另外TM 导出的模型在浏览器里跑推理时第一次加载后需要做一次预热否则第一次预测速度会明显偏慢。做法是加载完成后立即用一张全黑或全白的图片调用一次 predict 函数把 WebGL 的纹理缓存和模型权重加载流程先走一遍。这个小技巧在线上 Demo 演示的时候特别有用不至于现场第一次点击按钮卡顿三秒钟。3.3 模型量化和性能优化本地跑不卡才叫真的部署完成导出 TensorFlow Lite 后模型文件通常有几十兆这对移动端来说偏大。好在 TFLite 支持量化——把模型的权重从 32 位浮点数压到 8 位整数。量化后的模型体积能缩小约四倍推理速度也能提升不少代价是准确率会有一点点下降。TM 官方导出流程里没有直接提供量化选项但你可以把导出的 TFLite 文件丢到 Python 环境里用 TensorFlow 的转换器做量化或者用一些第三方在线工具处理。网页端也有类似的性能优化思路。TM 的模型在浏览器里默认用的可能是 CPU 计算如果你的页面可以明确要求使用 WebGL 后端推理速度会有质的提升。设置方式很简单在加载模型后加一句await model.setBackend(webgl);这句话会让 TensorFlow.js 把矩阵运算交给 GPU 完成。我在一个识别分类的项目里实测过同一套模型在 CPU 后端下单次推理要 80 到 120 毫秒切到 WebGL 后降到 15 到 25 毫秒体感上是完全不同的流畅度。4. 边界、局限与进阶玩法别指望 TM 解决所有问题TM 虽然好用但它有明确的能力边界。把这些边界搞清楚比学会操作本身更重要。我见过有人试图用 TM 做工厂质检里的细粒度缺陷分类也有人想靠它做复杂场景下的多目标检测——这些都属于用错工具最后大概率会得出AI 不可用的错误结论。4.1 哪些场景千万别用 TM第一类是细粒度分类。就像前面说的需要区分相似度极高的子类比如电池表面不同位置的划痕、不同颜色的同款螺丝MobileNet 的特征提取能力就是不够用。这种情况应该考虑用更大的模型或者自己训练一个专门的特征提取器。第二类是目标检测和位置定位。TM 的核心能力是图像分类也就是判断这张图里最主要的东西是什么。你要是想框出图里每个物体的位置和类别TM 做不到。那是 YOLO、SSD 这类目标检测模型的领地。不过有个变通方案如果你能把物体在哪个位置这个问题转换成不同位置专属的分类问题——比如监控摄像机固定机位下判断商品摆放在 A 区还是 B 区可以通过裁剪画面成两个区域、分别训练两个分类器来解决但这就涉及到更多的工程设计了。第三类是样本量极少且类别又多的场景。每类图片就三五张还想分十个类别这种极端数据依赖下 TM 的训练效果会很不稳定。迁移学习能降低数据需求但降低程度是有下限的。4.2 从 TM 到专业训练的衔接思路TM 导出模型后并不代表这条技术路线走到了尽头。一个更容易被忽视的用法是把 TM 当做一个快速的数据标注和可行性验证工具。你可以在 TM 里快速验证这个分类问题到底可不可行,如果可行再用导出的 TensorFlow SavedModel 格式在 Python 环境里做进一步优化——加载 TM 的权重作为初始权重用更专业的训练流程比如更精细的数据增强、更合理的类别权重在本地继续训练。这样既享受了 TM 的低门槛起步又突破了它在模型结构上的限制。此外TM 导出的模型可以配合很多应用场景做扩展。比如把训练好的图像分类模型接到机器人小车套件上小车摄像头看到的东西会被分类然后根据分类结果执行不同动作——这种项目在学校创客教育和产品原型验证中非常常见。姿态分类模型则可以和游戏引擎联动用身体动作控制游戏角色做体感交互原型。这类玩法在 TM 和编程工具集成的生态里已经很成熟。4.3 给非技术背景使用者的几条建议如果你不是程序员只用 TM 做原型验证我的建议是先把数据采集当成最核心的工作来做不要急于点训练按钮。每次采集数据时保持同一个姿势和环境基准分批采完后随机抽一些样本做测试看模型是不是真的学到了类别的本质特征。TM 的预览窗口里可以实时看到模型对摄像头画面的分类结果这是非常直观的验证手段。多做几次调数据—重训—测试的循环你会发现准确率的提升路径和写代码调参数完全不同——它的瓶颈几乎永远在数据端。另外TM 的项目文件是可以导出的格式是一个 .tm 文件。这个文件包含了模型权重和样本数据。我强烈建议每次调好一版就导出保存一次因为它本质上就是个工程文件。我之前有一次在浏览器里清缓存项目直接没了模型没导出数据也没备份只能重新采集白白浪费了一个多小时。这种教训一次就够了。5. 从一个小学科学课项目到工业场景验证TM 的真实使用案例说了这么多理论分享一个我实际经手的项目或许能帮你更直观地理解 TM 的定位。当时朋友所在的小学要做一堂科学课内容是让学生理解人工智能如何识别物体。校方的硬件条件只有一台普通电脑和一个 USB 摄像头预算几乎为零网上现成的 AI 教学案例要么需要 GPU 服务器要么需要买昂贵的人工智能套件。我帮他们设计了一个方案用 TM 让学生每人拍 10 到 15 张手掌图片分石头、剪刀、布三个类别。课堂上的流程是每个学生轮流对着摄像头出拳电脑实时显示分类结果和置信度。整个过程中学生能直观看到模型是怎么从猜不准慢慢变准的——这其实就是数据迭代训练的过程。他们甚至不需要知道神经网络这个名词就已经在用工程师的方式思考问题了为了让剪刀的识别更准我需要补充更多角度的手势图片。做完这个案例我最大的感触是TM 这种工具真正的价值不在于模型性能有多强而在于它把一个复杂系统的因果关系变得可视化、可触摸。同样的逻辑放到工业场景里其实也成立。有个做仓储管理的朋友告诉我说他们想验证用摄像头判断货架上的货物是否摆放整齐但公司没有专职算法工程师。IT 部门用了三天时间学了 TM用现场摄像头拍了几十张整齐和凌乱的图片训练了一个模型部署在办公室电脑上每天截图自动跑一次分类准确率意外地不错。这个方案虽然原始但它解决了从 0 到 1 的问题——用最小成本验证了 AI 在那个场景下是否值得投入。如果验证结果是可行的再考虑引入专业团队做正式部署。这两个案例想说明的其实是同一件事TM 最适合的场景是快速搞清楚一个 AI 想法到底靠不靠谱。它不是一个生产级训练平台而是一个想法验证器和需求翻译器。把这件事想清楚你对它的期望就不会错位使用它的姿势也会自然正确。6. 我踩过的那些坑从网络加载失败到模型过拟合的解决记录最后一部分把我在 TM 实际使用中踩过的一些坑集中写出来。这些坑不一定每个人都会遇到但遇到了真的能卡很久写出来给大家省点时间。6.1 网络和浏览器相关模型加载失败的根源排查TM 整个流程都依赖浏览器联网但很多人没意识到的是模型训练和模型加载对网络的要求还不一样。训练过程是在浏览器本地完成的把数据丢给浏览器里的 TensorFlow.js 算数据不会上传到服务器。但导出模型的加载就涉及资源获取了。如果你是把 TM 导出的文件部署在自己的服务器上一定要确认服务器支持静态文件的正确 MIME 类型——特别是 .bin 权重文件有些服务器默认不认识这个扩展名会返回错误类型导致加载失败。我的排查方法很简单打开浏览器的开发者工具切到 Network 面板刷新页面看 model.json 和 .bin 文件有没有加载成功状态码是不是 200响应类型对不对。如果 404那就是路径问题如果是 200 但还报错那大概率是跨域问题。我遇到过最离谱的一次是文件托管在一个图片存储服务上服务商默认给 .bin 文件加了防盗链浏览器端拿不到内容折腾了好久才发现问题出在云服务配置而不是代码上。这类问题没有通用解法唯一能做的就是排查时先确认资源是真的能被完整访问。6.2 过拟合和欠拟合训练集测试集表现差距过大的处理TM 界面里只显示模型在训练集上的表现你看到的准确率 98%只是在它背过的题上考了 98 分换个新场景可能直接跌到 60%。所以在 TM 里训练完一定要做留出验证——把数据分成两部分比如每类留出 10 张图不参与训练等训练完成后用这 10 张图测试模型。TM 界面上没有直接提供这种划分方式但你可以利用添加样本功能把测试图片单独放到一个类别里跑一遍看分类结果。或者更简单的方法训练完点预览窗口打开摄像头把真实物体放到镜头前看实时分类结果和置信度。这个过程才是真正检验模型泛化能力的时刻。如果发现真实场景里频繁误判先别急着加数据重训。回到 2.2 节说的类别区分度检查一遍再看采集数据的背景和光照是否跟真实使用环境差距太大。绝大多数泛化问题出在这两个环节而不是 TM 的性能。6.3 音频和姿态分类的特有坑音频分类和姿态分类各自有一些隐藏问题。音频分类对背景噪声非常敏感。我训练时用麦克风采集的样本可能是在安静的办公室录的但部署到嘈杂的环境里模型会倾向于把所有声音都归为背景噪声那个类别。解决办法是采集时故意加入目标场景的底噪或者尽量在接近真实使用环境的地方采集数据。另外TM 的音频分类本质上是识别音频片段的频谱特征如果你的音频样本长度太短短于 1 秒特征提取会非常不充分分类效果会明显变差。音频样本建议每段 2 到 3 秒太短的信息不足太长的延时又太大需要在这两者之间做取舍。姿态分类的坑主要在动作对齐上。TM 的姿态分类提取的是人体关键点位置它对关键点出现在画面里的位置非常敏感。同样是举手动作站在画面左边举手和站在画面右边举手关键点在画面中的绝对坐标完全不同模型表现会有很大波动。解决思路是在训练数据里尽量覆盖不同的站位或者在做推理前对关键点坐标做归一化处理——比如把所有关键点坐标除以肩膀宽度得到一个相对位置这样能在一定程度上消除人物大小和站位的影响。但这个处理已经超出 TM 的操作界面范围了需要你在导出模型后的代码里自己实现。6.4 多浏览器兼容性为什么 Edge 能跑 Chrome 却不行最后分享一个偏门但容易遇到的情况TM 训练完模型导出 TensorFlow.js 部署到网页后有时候在 Chrome 上跑得好好的换到 Edge 或 Safari 就出问题。这通常是 WebGL 后端兼容性导致的问题。旧版本的 Safari 对 WebGL 2.0 支持不完整TensorFlow.js 某些算子会自动回退到 CPU 执行而某些算子在这种回退链上会报错。解决办法是在模型加载时加一个能力检测走一个兼容性兜底await tf.setBackend(webgl); try { await tf.ready(); } catch (e) { tf.setBackend(cpu); }实测下来这个处理能解决大部分浏览器兼容问题。另一个常见原因是浏览器版本太老TensorFlow.js 要求的最低版本已经不支持了。这类问题没有特别优雅的解决方案只能在写代码前先明确目标用户的浏览器水平再决定要不要扛这一层兼容性成本。7. 从原型到产品的最后一步TM 之外的取舍与思考文章写到这里我已经把 TM 从原理到实操到踩坑都过了一遍。但我还想再强调一件事TM 应该被理解为一个验证工具和入门阶梯而不是长期依赖的生产平台。我见过有些团队用 TM 训练出的模型跑了很长一段时间模型效果其实一直在一个可接受的范围内因为他们的场景足够简单、数据分布足够稳定。但如果你的需求是持续演进的比如数据分布会随时间变化、需要接入复杂的数据预处理流水线、或者对推理延迟有严格的服务端要求那 TM 的定位就只适合做原型不适合做生产。这时正确的路径是借助 TM 的快速验证能力和导出的模型文件迁到更完整的机器学习工程框架里去。这个迁移路径我在 4.2 节提过导出的 SavedModel 格式可以作为预训练模型在你的自有数据上继续训练。迁移到 Python 环境后你就解锁了更完整的数据增强策略、更灵活的训练循环、更精细的超参数调优手段。而且因为有 TM 那一步做了可行性验证这个迁移过程的风险大幅降低。这就像写代码先做 mock 验证接口约定确认无误后再实现完整逻辑——TM 就是那个 mock帮你用最低成本确认方案方向对不对。最后再分享一个我个人的操作习惯无论是做课程项目还是产品原型我都会把 TM 项目里采集的原始图片、音频导出到本地保存一份。因为 TM 的在线编辑能力虽然直观但它不是一个长期的资源管理系统项目多了之后查找和管理都会变慢。把原始素材归到你自己的目录结构里后面无论要切换到哪个平台数据都是完整可用的。毕竟一个机器学习项目的成败说到底数据才是真正的基本盘。工具会更新、架构会换、模型结构会变得更好但你手里那批经过验证的高质量数据才是任何时候都不会过时的资产。本文还有配套的精品资源点击获取