上周有个做安卓开发的朋友跟我聊起一个需求给相册 App 加一个“物品识别”入口。产品经理丢给他一句话“这个简单找个模型推理一下就行。”结果他打开资料一看迎面而来的是数据集、特征、标签、损失函数、过拟合、微调、量化、端侧推理、TensorFlow Lite……每一个词都认识放在一起就不知道从哪下手了。这其实是很多安卓开发者学机器学习的真实卡点不是某一个术语太难而是不知道怎么把这些术语放进一条完整的链路里去理解。单独背一个“过拟合”的定义没什么用因为它只有在“训练 → 检验 → 调参”这个循环里才有意义。单独知道“量化”两个字也没用只有当你发现模型放在手机里太大、跑起来太慢时量化才变成一个必须解决的问题。所以这篇文章不打算按字母表列词条而是按一条真实的工作流来讲数据 → 训练 → 模型文件 → 端侧推理 → 评价与维护。这套流程和安卓开发是高度对应的——数据就像是源码训练过程就是编译打包模型文件就是最后的 APK推理就是在手机上运行评价监控就是看崩溃率和性能报表。一旦你看清了这层对应关系绝大部分术语就不用背了因为它们只是在某个环节回答了一个具体问题。1. 先看懂全局AI、机器学习、深度学习到底是什么关系1.1 为什么这三个词总是被混在一起在技术文章、产品文档包括招聘 JD 里AI、机器学习、深度学习经常被交替使用。这会让刚入门的人非常迷惑到底哪个是哪个严格来说这三个概念是包含关系不是并列关系。**AI人工智能**是最大的范畴指让机器表现出类似人类智能的能力比如识别图像、理解语言、做决策。机器学习是实现 AI 的一种方法核心思想是“不靠人把规则写死而是让算法从数据中自动总结规律”。深度学习是机器学习的一个分支它用多层神经网络来处理更复杂的规律是近十年图像识别、语音识别、自然语言处理取得突破的主要技术路线。对安卓开发者来说这个区别不是纯理论问题。日常项目里你接触到的 TensorFlow Lite、ML Kit、PyTorch Mobile绝大多数跑的都是机器学习模型而且往往集中在深度学习方法上。所谓“AI 功能”落到代码层面其实就是加载一个模型文件、处理输入、执行推理、解析输出。理解这层关系你就知道为什么很多“AI 教程”一上来就在讲神经网络——因为那是当前最主流的实现手段。1.2 用安卓开发类比这套全局图可以这样看我比较喜欢用“源码 → 构建 → 产物 → 运行”这个框架来类比机器学习工作流安卓开发机器学习对应关系源码和资源文件数据集和特征都是“输入原料”Gradle 构建/编译训练Training都是“从原料生成产物”的过程APK/AAB 安装包模型文件Model都是可以被加载和分发的“产物”Activity 运行、网络请求推理Inference都是“把产物用起来”的阶段崩溃日志、性能监控准确率、损失、线上指标都是“产物质量如何”的反馈这个类比虽然不完全精确但对入门阶段的认知构建非常有用。比如你会更容易理解为什么模型需要训练完才能用因为 APK 也需要构建完才能安装。为什么模型文件那么重要因为它就是整个机器学习项目交付出来的“安装包”。为什么部署时要在乎模型体积因为你不会把一个 500MB 的 APK 直接丢给用户。记住这一张地图后面出现的所有术语都能找到自己的“工位”。2. 数据侧术语模型还没开始训练时你就要先听懂这些词2.1 样本、特征、标签机器学习的最小单元机器学习里最基础的三件套是样本、特征、标签。样本Sample一条用于学习的数据记录。在图像任务里一张图片就是一个样本在文本任务里一句用户评论就是一个样本。特征Feature描述样本的输入信息。对图片来说特征最初是像素值对文本来说特征可能是分词后的词向量。标签Label这条样本对应的正确答案。比如图片里是“猫”还是“狗”评论情绪是“正面”还是“负面”。为什么这三个词必须先搞清楚因为几乎所有监督学习算法做的事情就是输入特征预测标签然后根据预测结果和真实标签的差距来调整模型。用安卓开发来类比一条样本相当于一条带答案的测试用例特征是传入的输入参数标签是期望的输出结果。你在写单元测试时也要先定义“给定什么输入期望什么输出”机器学习的训练数据本质上就是大量这样的“测试用例”。2.2 训练集、验证集、测试集为什么不能只用两份数据初中级开发者在接触机器学习时容易犯一个错误把数据随机分成两份一份训练、一份测试以为这样就够了。实际工程里标准做法是分成三份训练集Training Set用来让模型学习规律。验证集Validation Set用来在训练过程中调整超参数判断模型是否学得“差不多得了”。测试集Test Set训练完全结束后用来模拟“未来真正会遇到的数据”评估模型真实水平。为什么需要三份而不是两份关键原因是如果你用测试集反复决定什么时候停、调什么参数你实际上是在“针对测试集做优化”测试集就不再客观了。这就像你反复用同一套单元测试去修代码代码肯定会越来越贴合这套测试但换一组新数据就不知道会怎样。验证集是你的“内部评审”测试集才是“最终验收”。对安卓开发者来说还有一个更贴近的场景你接入第三方预训练模型不再自己训练但依然要自己划分数据去验证效果。这时候至少要把一份数据留出来做最终验收不要一边调参一边拿它打分。2.3 特征工程与数据增强数据质量比模型大小更影响结果很多刚入门的人以为模型越复杂效果越好真实工程经验往往相反数据质量和特征设计经常比模型结构更决定结果。特征工程Feature Engineering从原始数据中加工出更有用的输入。比如把日期拆成“星期几”“是否节假日”把文本做分词和去停用词。这些加工在传统机器学习里至关重要深度学习方法虽然能自动学特征但输入数据的格式、归一化方式仍然会影响训练稳定性。数据增强Data Augmentation在不改变标签含义的前提下对样本做变换来增加数据量。图片任务常见做法是旋转、翻转、裁剪、调亮度文本任务可能是同义词替换或回译。数据增强的价值是让模型见过更多样的情况减少过拟合。这里要提醒一句数据增强不是无限做的。过度翻转对某些方向敏感的任务比如文字识别反而会降低效果。落地时一定要结合具体任务判断而不是照着教程逐个套。注意如果原始数据只有几千条先不要急着换更大的模型。先检查数据标注是否一致、类别是否均衡、是否存在大量重复样本。数据侧的这些问题往往比模型结构更影响最终效果。3. 训练过程术语模型是怎么从数据里“长”出来的3.1 模型、参数、损失函数训练到底在调什么训练过程的底层逻辑可以压缩成一句话给定输入模型输出一个预测算一下预测和真实答案差多少然后调整模型让这个差距变小。围绕这个逻辑有一组高频术语模型Model一个可计算的函数结构里面有大量参数等待确定。参数Parameters模型内部的权重和偏置。训练的过程就是不断调这些参数。损失函数Loss Function衡量“预测结果和真实标签差多少”的函数。值越小代表模型当前的效果越好。优化器Optimizer负责根据损失值更新参数的具体算法。常见的有 SGD、Adam、RMSProp。梯度下降Gradient Descent优化器做参数更新的基本方法。可以理解成“沿着下山最快的方向迈步”梯度就是哪个方向下降最快的信号。对安卓开发者来说这些词之所以容易绕晕是因为它们在训练阶段和推理阶段完全不会出现。推理时你只需要模型文件不需要损失函数和优化器。如果你只是在 App 里调用模型这些训练术语多数时候只是背景知识。只有当你打算自己做微调时才真正需要关注它们。3.2 epoch、batch、学习率那几个经常在日志里看到的词当你真正开始跑训练时会发现几乎每一条训练日志都在显示这几个词Epoch把整个训练集完整过一遍。就像你把整本习题册从头到尾做了一遍。Batch一次参数更新用到的样本数。受限于显存、内存和时间通常不是把全部数据一次算完。Batch Size 越大一次更新看到的样本越多但占用的内存也越大。Iteration / step更新一次参数等于处理一个 batch。学习率Learning Rate控制每次参数更新“步子”能迈多大。学习率太高loss 会震荡甚至不收敛学习率太低训练很久也不见效果。常见的训练过程可以写成这个循环把数据切成多个 batch每个 batch 做一次前向计算和参数更新所有 batch 都跑完一个 epoch 结束然后循环多个 epoch直到在验证集上的效果不再明显提升。这里我想给出一个实战建议刚开始做训练任务时不要一上来就追求“最佳超参数”。先拿小数据、少量 epoch 把流程跑通确认数据加载、模型结构、损失计算都没有问题再逐步扩大数据量和训练时长。否则你根本分不清是代码写错了还是模型没训练够。3.3 过拟合、欠拟合、泛化判断模型好坏的真正标准训练模型最核心的矛盾不是“让训练集准确率更高”而是“让模型在新的数据上也能表现得不错”。这组术语就是用来描述这个矛盾的欠拟合Underfitting模型还没学会基本的规律训练集和测试集表现都差。相当于复习太少题目都不会做。过拟合Overfitting模型把训练集里的细节和噪声都记住了训练集表现很好但一到新数据就掉链子。相当于把试题答案背下来了遇到新题就懵。泛化Generalization模型在没见过的新数据上表现良好的能力。这是机器学习项目最终追求的东西。判断一个模型好不好永远要看它在验证集或测试集上的表现而不是只看训练集。训练集 loss 一直下降验证集 loss 却开始回升这是典型的过拟合信号。缓解过拟合的常见手段包括增加数据量、做数据增强、降低模型复杂度、加正则化项等。3.4 预训练模型与微调为什么安卓开发现在不用从零训练如果你现在才开始接触机器学习技术会发现大量落地项目都不再是从零训练模型而是“读入一个预训练模型再基于自己的业务数据做微调”。预训练模型Pre-trained Model已经在大型通用数据集上训练好的模型例如在 ImageNet 上训练过的图像分类模型或在大规模文本上训练过的语言模型。微调Fine-tuning在预训练模型的基础上用你自己的少量数据继续训练让模型适配你的具体任务。迁移学习Transfer Learning把预训练模型学到的通用能力迁移到相关的新任务中。这条路线对安卓开发者特别有意义。因为你不需要掌握整个训练链路的所有细节也能使用一个很好的模型。实际上很多成熟的 App 方案是直接下载一个高效模型甚至用 ML Kit 这类封装好的 SDK连模型文件都不用亲自管理。但要注意预训练模型不是万能的。如果你的业务场景和预训练数据差异很大比如预训练模型是通用物体识别你要识别工业设备的特殊零件那就需要准备一批带标签的业务数据做微调。否则直接拿通用模型硬跑效果往往不理想。4. 推理与部署术语模型进入 App 之后的关键词4.1 推理、延迟、吞吐端侧任务主要看什么模型训练完成后进入使用阶段核心动作叫推理。跟安卓开发密切相关的往往是这几个维度推理Inference用训练好的模型对新的输入进行计算得到预测结果。这个动作在移动端通常由 TensorFlow Lite、ML Kit、PyTorch Mobile 等框架执行。延迟Latency从输入数据到拿到推理结果所花的时间。在相机识别、实时语音等场景里延迟直接决定产品可用性。吞吐Throughput单位时间内能处理的推理请求数量。对服务端比对移动端单机通常只需要关心单次延迟和功耗。移动端推理和服务器推理的关注点很不一样服务端更看重吞吐和并发移动端更看重单次延迟、模型体积和功耗。模型再准如果跑一次要两秒、手机发烫、内存飙高用户也无法接受。4.2 预处理、后处理、标签映射最容易出错的三个环节第一次接入模型的人往往把注意力放在“加载模型、调用推理 API”上但真正容易翻车的是推理之前和之后的数据处理。预处理Preprocessing把原始输入转换成模型要求的格式。常见操作包括调整图片尺寸、归一化像素值、把文本转成 token 序列。不同模型要求不同有的要 [0, 1]有的要 [-1, 1]有的要 BGR 而不是 RGB。后处理Postprocessing把模型输出的原始结果转成业务可用的结果。分类模型输出的是概率分布不是“猫”这个字符串。标签映射Label Map把模型的类别索引映射成人类可读的名称。比如索引 0 对应“猫”索引 1 对应“狗”。这个映射文件要随模型一起维护。如果你在 App 里跑了一个模型发现结果全不对先别怀疑模型坏了。先检查输入图像有没有压缩变形、通道顺序对不对、像素归一化是否一致、输出结果有没有按索引取错标签。我见过很多“模型效果很离谱”的案例最后都是后处理环节的问题。这里给一个最小可运行的 TFLite 推理流程示意只表示常见的调用形态具体 API 要以你项目里依赖的版本为准// 常见写法示例使用 TensorFlow Lite 执行一次图片分类推理 // 实际 API 和模型输入要求以你使用的依赖版本和模型文档为准 val options Interpreter.Options().apply { setNumThreads(4) // 如需使用 GPU可结合 Delegate 方案配置 } val interpreter Interpreter.loadModelFile(context, model.tflite) // 假设模型的输入是 [1, 224, 224, 3] 的浮点张量 val inputArray Array(1) { Array(224) { Array(224) { FloatArray(3) } } } // 这里需要把 Bitmap 缩放、归一化后填入 inputArray val outputArray Array(1) { FloatArray(labels.size) } interpreter.run(inputArray, outputArray) // 取出概率最大的索引映射到标签 val resultIndex outputArray[0].indices.maxByOrNull { outputArray[0][it] } val label labels[resultIndex ?: 0] interpreter.close()这串代码的真实价值不在 API 细节而在让你看到推理管线的完整结构加载模型 → 准备固定形状的输入 → 执行 run → 从输出张量中解析结果 → 关闭资源。很多问题都出在“输入张量的形状、类型、归一化方式”上。4.3 模型格式与压缩TFLite、ONNX、量化、剪枝分别解决什么移动端不能直接跑训练框架里的原版模型因为体积大、依赖多、计算慢。于是出现了一批面向部署的技术TensorFlow LiteTFLiteTensorFlow 的移动端/嵌入式推理框架模型文件后缀通常是 .tflite。ONNX一个开放的模型交换格式用来让不同训练框架产出的模型可以互转、互用。PyTorch MobilePyTorch 生态的移动端推理方案。量化Quantization把模型里的浮点参数从 32 位降到 8 位甚至更低以减小体积、提升推理速度。代价是精度可能轻微下降。剪枝Pruning去掉模型中对结果影响不大的参数或连接。知识蒸馏Knowledge Distillation用一个大模型“教”一个小模型把小模型训练得更紧凑。先理解一个原则这些技术都是为了解决“移动端资源有限”这个问题。模型在服务器上可以很大放到手机上就要考虑安装包体积、内存占用、推理延迟、耗电。量化是移动端最常见的优化手段很多 TFLite 模型默认就是量化后的版本。注意量化模型虽然快但并不是所有算子都支持量化。当你下载一个量化的模型却发现某些层报错时不一定是你的代码有问题可能是模型里的算子超出了当前推理框架的支持范围。4.4 端侧推理与云端 API怎么选才不踩坑安卓开发经常要面对一个决策模型放在设备上跑还是把输入发到服务器让云端模型推理后返回结果两种方案各有术语和代价维度端侧推理云端 API隐私数据不出设备隐私更可控数据要传到服务器延迟无网络往返单机延迟低取决于网络状况离线能力支持离线使用无网络无法使用模型大小受设备存储和内存限制服务器可以承载大模型更新成本模型更新要发版或动态下发服务器端更新即可这不是“二选一”的技术题而是产品权衡题。像相机实时检测这类对延迟和隐私敏感的场景端侧更合适像复杂语言理解、超大模型对话这类任务移动端暂时跑不动的云端更现实。如果你刚开始做 AI 功能我的建议是优先用现成的端侧 SDK 或云端 API 跑通产品流程确认业务价值再决定是否要自训练、自部署模型。不要一上来就搭训练环境、搞模型优化那是把架构复杂度提前引入到了需求验证阶段。5. 评价与维护术语上线之后才是真正考验5.1 accuracy、precision、recall、F1不能只看一个数很多文章在介绍模型效果时只给一个准确率但这在真实业务里是远远不够的。准确率Accuracy预测正确的样本占总样本的比例。类别均衡时够用但如果 99% 是“正常”1% 是“异常”一个什么都不做、永远输出“正常”的模型也能有 99% 准确率——这个模型显然没有业务价值。精确率Precision预测为“正类”的样本里有多少是真的正类。用来回答“我的结果可靠吗”。召回率Recall真正的正类样本里有多少被模型找出来了。用来回答“我漏掉了多少”。F1 分数精确率和召回率的调和平均用来在两者之间做平衡。在安卓业务里这个选择会直接影响产品规则。比如做一个垃圾评论过滤精确率太低会误杀正常用户做一个医疗影像提醒召回率太低会漏掉风险。评估模型时最好把这几项都看一遍不仅看整体指标还要看分类别指标。5.2 数据漂移与模型退化模型会“变老”模型上线后不是一劳永逸的。真实世界的数据会随着时间发生变化这带来一组维护相关术语数据漂移Data Drift模型的输入数据分布和训练时不一致了比如用户手机拍照的场景变了、新硬件的图像风格变了。概念漂移Concept Drift业务规律本身变了比如“客户流失”的定义变了。模型退化Model Degradation由于上述变化模型在真实场景中的表现逐渐下降。对安卓应用来说这意味着如果模型长时间不更新即使代码没改功能效果也可能越来越差。成熟的团队会给模型加“版本管理”像管理接口版本一样定期用新数据做验证再通过客户端下发或动态加载方式更新模型文件。5.3 从单次推理到 AI Agent大模型时代的术语延伸近两年技术圈大量出现“AI Agent”“AI 编程”“大模型”这些词。它们在概念上都不是孤立的而是对“模型使用方式”的扩展。大语言模型LLM在海量文本上训练的大规模语言模型能生成自然语言文本。AI Agent智能体一个能自主拆解任务、调用工具或模型、根据结果继续执行的系统而不是简单的一次推理请求。AI 编程借助大模型辅助写代码、解释代码、生成测试。它本质上也是“模型推理 上下文管理 结果校验”的组合。对安卓开发者来说真正需要理解的变化是以前接入 AI 是“一个模型 → 一个结果”现在可能是“一个 Agent → 多次调用模型和工具 → 完成一项复杂任务”。底层仍然是推理、输入输出、上下文这些概念但系统层级更高了。学习早期不必被这些新词吓到先掌握单次推理的完整链路再看 Agent 是“如何把多次推理编排起来”思路会更清晰。6. 给安卓开发者的一条可复用学习路线6.1 阶段一用现成能力先跑通一个案例不要一上来就搭 TensorFlow、准备训练数据。先找一个你业务场景接近的现成能力比如 ML Kit 的文字识别、图像分类或者一个现成的 TFLite 示例项目。目标只有一个在 App 里成功跑起来一个 AI 功能。这个阶段你需要掌握的核心术语是输入、输出、预处理、后处理、标签映射。不要纠结模型是怎么训练出来的先把“模型是一个文件App 加载它传入数据得到结果”这条链路跑通。此时最容易踩的坑是照搬教程后发现模型跑不了。排查顺序应该是先看模型文件是否完整、格式是否匹配再看输入张量形状和类型是否正确再看依赖版本是否兼容最后看输出解析是否合理。不要把问题归到“AI 很玄”上绝大多数问题都是工程问题。6.2 阶段二接入一个预训练模型理解完整推理管线跑通案例后你可以尝试下载一个通用预训练模型比如图像分类或文本分类模型自己完成加载、输入处理、推理、结果解析的全流程。这个阶段需要掌握的术语包括模型格式、量化、推理延迟、内存占用、线程数、GPU 加速。你可以试试量化和非量化版本之间的体积和耗时差异感受“模型压缩”到底在平衡什么。一旦你亲手处理过输入尺寸、归一化、标签映射这些问题再看网上文章就有了实际经验支撑。强烈建议这个阶段给自己做一个小实验选一个任务分别用端侧模型和云端 API 实现一遍记录延迟、失败率、开发成本、维护成本。有了这组对比数据以后再遇到“该端侧还是上云”的讨论你就不会只靠感觉判断。6.3 阶段三微调、评估、监控具备生产能力如果业务确实需要自定义模型那就进入真正的机器学习阶段。这时候再开始看训练相关术语数据集、特征、标签、训练集/验证集/测试集、损失函数、优化器、过拟合、微调、评估指标。学习路径可以考虑先看经典的机器学习入门课程建立全局认知然后选择一个和安卓关系更近的实操方向图像分类、文本分类或语音指令识别做一个小规模微调实验。重点是理解“数据怎么影响模型”而不是追求一次训练出完美模型。生产落地时还需要补三块模型版本管理、线上效果监控、失败回退机制。模型不像普通代码改动一次脏数据的引入可能让整个功能回归。最好先把模型当成一个可独立发布的组件有版本、有记录、有可回退路径。6.4 通用问题排查链路按这个顺序查能省很多时间如果你把 AI 功能接入了安卓项目遇到问题不知道从哪查起可以按下面这个顺序排查先看现象是崩溃报错没输出还是输出结果完全不对不同现象对应的问题层完全不同。再看输入图片大小、格式、方向、像素范围、文本编码、文件路径是否正确。再看环境依赖版本、权限、设备架构、模型下载是否完成、文件是否损坏。再看参数线程数、输入 batch、模型路径、输出张量尺寸、标签映射。最后看工具边界模型是否支持当前设备算子是否兼容量化模型是否需要特定 delegate是否超出了当前推理框架的能力范围大部分初学时遇到的“模型跑不通”都能在这个链路里找到答案。真正属于模型本身不收敛、不准的情况远比你想象中少。回到底层安卓开发者其实不需要成为算法专家。你需要的是建立一张完整的认知地图知道数据、训练、模型、推理、评价分别是什么知道每一步有哪些关键词知道模型一旦进入 App后续还需要维护和更新。看懂这些你就能在和技术专家、产品经理、算法工程师沟通时准确判断问题出在哪一层也能判断一个“AI 需求”到底是简单的模型接入还是需要完整的数据工程和训练调优。先跑通一个最小的案例再逐步往底层延伸。这条路比一次性背完所有术语可靠得多。