每次有朋友问我深度学习入门该用什么框架我的答案基本都是同一个先把TensorFlow用熟。这倒不是说它在每个维度都比其他框架强而是因为它的资料最全、踩坑答案最好找、从实验到部署的链路最短。前阵子我用TensorFlow 2.x做了一个花卉图像分类的完整项目从收集图片、搭建模型一路做到模型导出上线全流程走完之后才意识到网上很多教程要么停在1.x的旧API要么只讲Keras的舒适区真正到了实战环节坑全在拐角处等着。这篇文章不打算复述官方文档只想把这次实战里真正起作用的东西讲清楚数据管线怎么设计才快、模型结构怎么选择才稳、训练出问题怎么定位、模型怎么导出才能被业务方直接使用。不管你是刚接触TensorFlow的小白还是被某个诡异报错卡了两天的半经验开发者这份整理应该都能给你一些可复现的参考。项目本身不复杂就是一个标准的多分类视觉任务但它覆盖了TensorFlow从训练到部署的完整路径也正好是我认为最能体现这个框架性格的一条路径。1. 重新认识TensorFlow2.x和1.x不是简单的升级1.1 为什么很多教程越看越晕先解决一个普遍困惑为什么网上搜TensorFlow出来的代码五花八门有的甚至互相矛盾根源在于TensorFlow经历了一次极其剧烈的接口变迁。1.x时代的核心是静态图你得先定义placeholder、变量、操作然后用session.run去触发计算。写成代码大概是这样一套流程每个变量都要声明图构建和实际执行完全分离。这种设计早期追求的是性能优化空间但对初学者极不友好我见过太多人被图和会话两个概念劝退。到了2.x官方把Keras吸收为高层API默认开启eager execution即动态图模式写法上接近普通Python代码。你定义一个模型、调用一次fit计算就立即执行不用再管session。这个改变方向是对的但代价是旧教程大量过时。我现在搜索技术问题时会默认加2.x或tf.keras前缀否则搜到的结果可能是在教1.x的session写法代码复制下来直接报错。另一个让人晕的原因是API层级太多高层有tf.keras中层有tf.data和tf.image底层还有raw ops和Variable管理。很多教程只教高层fit读者遇到稍微定制一点的需求就不知道怎么下钻。我的建议是日常开发以tf.keras为骨架遇到性能问题往下钻到tf.data遇到定制训练逻辑往下钻到GradientTape。每一层都清楚它是干什么的就不会被API数量吓住。1.2 和PyTorch的生态对比我的选型逻辑在社区里聊框架选型难免要对比PyTorch。老实说研究圈里用PyTorch的人越来越多它的动态图体验和Python风格写起来确实舒服。但我在做这个项目时仍然选择TensorFlow核心原因有三条。第一是部署链路。TensorFlow从训练到推理的工具链是闭环的训练完的模型可以存成SavedModel格式直接走TensorFlow Serving做服务化推理也可以转成TFLite跑在移动端还能转成TensorFlow.js跑在浏览器。这个一份模型多端运行的能力在业务落地时价值非常大。PyTorch需要依靠ONNX转TorchScript等中间步骤链路相对曲折。第二是生态完整度。tf.data、TensorBoard、TFX这些配套工具虽然各有上手成本但当你真的要做一个持续迭代的机器学习系统时它们是成体系的。TensorBoard的可视化我至今觉得比大多数同类工具直观。第三是历史资源。TensorFlow的问世时间更长生产环境里的踩坑记录、案例、Stack Overflow回答覆盖了绝大多数场景。对做工程落地的人而言可搜到的答案数量本身就是一种效率。当然这不意味着TensorFlow全无缺点。它的文档更新频繁导致部分示例过时报错信息有时候又长又绕这我在后面会详细说到。选型不是选宗教而是看清自己的需求侧重点如果重点是快速发论文做实验PyTorch很合适如果重点是训练完还要部署到多端TensorFlow目前仍然更省心。1.3 安装环境第一个坑其实在这里很多人以为安装TensorFlow就是pip install tensorflow这么一句话实际执行的时候问题全在补充环节。我的建议是新建一个独立的虚拟环境不要装到系统Python里。不同项目的依赖经常互相冲突我见过太多人因为环境混乱把GPU版的库搞坏最后只能重装系统。安装命令本身并不复杂但有两个细节值得注意。第一CPU版和GPU版从2.1开始是同一个包pip会自动拉取对应平台的版本不需要像1.x时代那样分别装。第二GPU能不能被识别取决于CUDA和cuDNN的版本是否在官方支持列表内。官方文档里有一张兼容性表格明确写了TensorFlow 2.x对应哪个CUDA版本。我在这上面栽过跟头装完包后运行代码发现模型训练异常缓慢检查半天才意识到GPU根本没被调用。装好之后可以用这段代码快速验证环境是否正常import tensorflow as tf print(tf.__version__) print(tf.config.list_physical_devices(GPU))如果GPU列表为空先别急着重装检查一下显卡驱动。不要自己乱装CUDA直接装驱动附带的标准CUDA工具包往往更省事。这属于环境问题里最磨人但最不值得深入研究的部分把时间留给模型本身。2. 数据管线动手写模型前先把数据准备好2.1 为什么坚持用tf.data而不是自己写循环很多人在开始写模型之前根本不重视数据加载数据量小的时候感觉不出来一旦图片数量到几万张问题就暴露了。我自己最早也犯过这个错用Python原生代码读图片、做预处理、塞进列表再转成numpy数组喂给模型。数据集不大的时候一切正常但当我扩展到几万张图片时训练过程大部分时间都花在等待数据上GPU利用率掉到惨不忍睹。TensorFlow给出的解决方案是tf.data.Dataset API。它的核心思想是把数据读取和预处理也当成一套计算管线由框架自动调度并行、预取、缓存而不是你在Python层手动一步步去做。这里我常用的几个基础操作按顺序列出来tf.data.Dataset.from_tensor_slices把numpy数组或文件路径列表包装成数据集.map对每个样本做预处理可以用num_parallel_callstf.data.AUTOTUNE自动并行.shuffle打乱顺序缓冲区大小一般设为样本总数或至少一个epoch的量级.batch分批尺寸跟上GPU显存匹配.prefetch(tf.data.AUTOTUNE)让数据准备和模型计算重叠这个操作几乎是免费的提速手段。实际使用中最容易被忽略的是.cache()。如果你的预处理包含大量重复计算比如每轮都重新解码并缩放图片那么把处理后的数据集缓存到内存或磁盘能省掉大量重复开销。我的习惯是第一轮完整跑一遍预处理并缓存到内存后续每个epoch直接读缓存训练速度提升非常明显。需要注意缓存到内存时如果数据集太大可能让机器内存吃紧这时可以指定缓存到文件。2.2 图像预处理与数据增强的完整写法这次花卉分类项目的数据集是我自己整理的公开图片和手工拍摄混合而来总共约两万张分五个类别。图片来源杂乱尺寸不一、光照差异大、还有少量损坏文件这些现实情况都必须在数据管线里处理掉。我用的是tf.keras.utils.image_dataset_from_directory配合目录结构来加载数据。这个API允许你按文件夹名自动生成标签省去手动维护csv的麻烦。目录结构大概是train目录下每个类别一个子文件夹validation和test同理。加载部分代码如下train_ds tf.keras.utils.image_dataset_from_directory( data/train, validation_split0.2, subsettraining, seed42, image_size(224, 224), batch_size32 )注意validation_split会在载入时直接切分训练集和验证集seed参数保证每次切分结果一致这对实验复现很重要。图片会统一缩放到224×224格式转为float32。但仅做到这里是不够的原始像素值范围是0到255直接进网络会导致数值不稳定通常要归一化到0到1或-1到1。我更推荐的做法不是用Lambda层或者外部rescale而是把归一化和数据增强放在tf.keras.Sequential模型的第一层这样训练和推理时的预处理逻辑完全一致。我的增强层配置大致如下data_augmentation tf.keras.Sequential([ tf.keras.layers.Rescaling(1. / 255), tf.keras.layers.RandomFlip(horizontal), tf.keras.layers.RandomRotation(0.1), tf.keras.layers.RandomZoom(0.1), ])有人会问数据增强不是应该在训练时做、推理时不做吗放进模型层的确会在推理时也走一遍随机变换但RandomFlip这些层在推理阶段其实会退化为恒等操作。而Rescaling归一化是两种阶段都需要的放一起反而省心。要注意的是增强操作计算开销不小如果数据集很大建议在CPU上预处理并使用.prefetch让增强和GPU计算重叠而不要把增强加到GPU模型内部导致卡在瓶颈。2.3 数据管线的瓶颈排查数据管线的性能问题很难从肉眼发现因为报错不会出现只是训练变慢。我排查卡顿的思路是这样的先看GPU利用率训练过程中在命令行跑GPU监控工具。如果GPU利用率长期低于50%同时CPU占用很高大概率是数据加载跟不上。然后做一个简单的对照实验把fit里的数据换成.repeat().take(100)这样的无意义数据或者干脆用dataset.take(1)跑一遍预处理看耗时。如果单独跑数据管线很快但训练时整体慢那就是数据预取没有生效。检查一下有没有写.prefetch(tf.data.AUTOTUNE)它能让数据管线和模型前向反向传播并行执行。还有一种很隐蔽的情况.shuffle的缓冲区大小远超内存导致不断做磁盘换入换出。我一朋友的项目就是把缓冲区设成了整个数据集大小机器内存不够用训练速度反而比不打乱更慢。shuffle缓冲区设成几千就够了不需要覆盖全部样本。数据管线的优化思路其实和流水线工厂很相似每个环节的吞吐量要匹配瓶颈总在最慢的那一站。3. 模型搭建与训练循环Keras层和底层API怎么配合3.1 Sequential、Functional、Subclass到底怎么选TensorFlow 2.x里搭建模型有三套主流方式很多人分不清什么时候用哪个。Sequential是最简单的线性堆叠适合输入单输出、结构链式的网络。如果你要处理多输入多输出、共享层、分支结构Functional是更合适的选择它把层当作可复用的对象通过显式连接定义计算图。Subclass方式则是继承tf.keras.Model在call方法里用Python代码自由控制前向逻辑灵活性最高但不利于序列化我一般只在写特殊网络时才用。我的选择标准很直接默认从Functional开始因为它表达能力比Sequential强序列化支持比Subclass好而且代码结构一眼能看出张量怎么流动。如果你确定结构非常简单用Sequential当然也没问题。但要避免的是没想清楚就上Subclass一旦需要model.summary()或者导出模型时才发现自定义类没写对回溯成本很高。写Functional模型时核心是把层当作函数调用。下面这个示例可以看做一个简化版的分类网络骨架inputs tf.keras.Input(shape(224, 224, 3)) x data_augmentation(inputs) x tf.keras.layers.Conv2D(32, 3, activationrelu)(x) x tf.keras.layers.MaxPooling2D()(x) x tf.keras.layers.Conv2D(64, 3, activationrelu)(x) x tf.keras.layers.GlobalAveragePooling2D()(x) x tf.keras.layers.Dropout(0.2)(x) outputs tf.keras.layers.Dense(5, activationsoftmax)(x) model tf.keras.Model(inputs, outputs)这段代码的优点在于你可以在任意两个层之间插入旁路、拼接或新的输入可扩展性强。3.2 一个CNN花卉分类模型的搭建过程回到这个项目的具体模型。我最初尝试自己搭建一个三层卷积网络分类准确率在验证集上只能到80%左右。后来换成扒官方预训练模型做迁移学习效果立刻好了不少。这里我的建议是除非你在做网络结构研究否则图像任务优先考虑tf.keras.applications里的预训练模型作为骨干。我最后用的是EfficientNet系列的预训练网络作为特征提取器。选择它不是因为参数最多或精度最高而是因为它的精度和计算量的平衡性很好在有限显存条件下表现比同量级的其他网络更稳。用法上和常规模型差异不大base_model tf.keras.applications.EfficientNetB0( include_topFalse, weightsimagenet, input_shape(224, 224, 3) ) base_model.trainable False inputs tf.keras.Input(shape(224, 224, 3)) x data_augmentation(inputs) x base_model(x, trainingFalse) x tf.keras.layers.GlobalAveragePooling2D()(x) x tf.keras.layers.Dropout(0.3)(x) outputs tf.keras.layers.Dense(5, activationsoftmax)(x) model tf.keras.Model(inputs, outputs)这里有两个关键点。第一迁移学习初期必须把骨干网络设为trainableFalse先只训练后面的分类头。如果一上来就全量微调预训练权重很快被破坏尤其数据量不够大时模型容易直接崩掉。第二base_model(x, trainingFalse)要显式传trainingFalse避免BatchNormalization层在推理时使用移动均值还是批次统计的混乱。这个细节通常不会报错但会影响验证准确率的稳定性。迁移学习通常分两步先冻结骨干训练分类头几个epoch再把base_model.trainable True解冻整个网络用很小的学习率做微调。我在项目里的做法是第一阶段学习率1e-3训练5个epoch解冻后学习率降到1e-5再训练10个epoch。这里的学习率跨度比较大是有意的因为新加的分类头需要的更新步幅和预训练骨干需要的更新步幅完全不同一步到位容易互相干扰。3.3 什么时候需要自己写训练循环model.fit足够覆盖大多数场景但有些需求必须自己写训练循环。例如生成对抗网络里判别器和生成器需要交替更新再比如自定义复杂损失、需要在每个batch内做多次梯度更新。写自定义训练循环的核心是tf.GradientTape它会自动记录前向计算里的可训练变量操作然后通过tape.gradient计算梯度最后用优化器apply_gradients更新参数。optimizer tf.keras.optimizers.Adam(learning_rate1e-3) loss_fn tf.keras.losses.SparseCategoricalCrossentropy() tf.function def train_step(images, labels): with tf.GradientTape() as tape: predictions model(images, trainingTrue) loss loss_fn(labels, predictions) gradients tape.gradient(loss, model.trainable_variables) optimizer.apply_gradients(zip(gradients, model.trainable_variables)) return losstf.function装饰器把Python函数编译成计算图首次调用时会经历追踪和编译之后多次调用性能接近静态图。我实测同样的训练循环加了tf.function后速度能提升不少。这里要提醒一个新坑自定义循环里如果混用了Python原生的if分支来依赖张量值可能被编译逻辑搞出奇怪行为。解决办法是把条件判断也改成TensorFlow API比如只根据全局步数做判断时用tf.cond或直接让分支依赖Python整数而非张量。项目里我最终没有用自己的训练循环fit够用了。但我把自定义循环练熟是有必要的因为当你需要把某个研究想法快速验证时能自由在tape.gradient前后插入操作这种掌控感是高层API给不了的。建议所有想长期用TensorFlow的人抽半天时间写一个简单的自定义循环哪怕只是把MNIST从头练一遍。4. 训练过程中真实踩过的坑过拟合、学习率和断点续训4.1 数据增强不是加了就有效训练过程中我最先遇到的问题就是过拟合。模型在训练集上准确率摸到95%以上验证集却停留在82%左右而且每个epoch之后差距都在拉大。第一反应当然是加数据增强。但这里有个反直觉的经验数据增强不是越猛越好适合你当前数据分布的增强组合需要试出来。我一开始用RandomRotation的旋转角度设为0.3大概17度还叠加了亮度变化。结果验证集准确率不但没上升反而掉了一点。后来我逐个检查才发现我需要分类的花卉图片里有许多方向性很强的特征过度旋转让模型无法建立稳定的方向特征映射。最终把旋转角度降到0.1亮度扰动去掉只保留水平翻转和轻微缩放验证集准确率反而稳步爬升。增强的另一面是你需要同步增加训练轮数。数据增强等效于扩大了训练集但这是按概率生成的新样本不是真实的独立样本如果epoch数不增加模型其实没机会看到足够多的变体。我做了一个简单的对比不加增强、训练20轮和加了适度增强、训练40轮后者的泛化效果明显更好。如果过拟合仍然存在下一步是考虑Dropout位置和比例。很多人的误区是一味增大Dropout比例结果模型欠拟合。我建议从0.2起步每次实验递增0.1并在验证集上观察曲线。还有一个很有效的做法是Dropout放在全局池化之后而不是每个卷积层之后因为卷积层本身有参数共享的天然正则化效果过度加Dropout反而削弱特征提取能力。4.2 学习率与BatchSize的联动影响这个坑我总结成一句话学习率、BatchSize、训练步数三者是绑定的改了一个就得重新审视另外两个。我的默认配置是BatchSize32、Adam默认学习率1e-3。在后来的实验里我把BatchSize提高到128结果验证集波动明显变大。原因很好理解BatchSize变大后梯度估计更稳定但同样学习率下收敛状态不同需要把学习率也放大才对实际却没有同步调整。理论上BatchSize扩大k倍学习率可以尝试扩大sqrt(k)倍或k倍具体哪种有效取决于优化器和任务。我的实操建议是每次只改一个变量并且同时记录训练集和验证集曲线。不要只看最终准确率一定要看曲线形态。如果训练损失持续下降但验证损失走平说明学习率后期还是偏大这时候可以启用ReduceLROnPlateau回调让验证指标不再改善时自动降低学习率。那段时间我看了太多教程都只提学习率很重要但很少有人说该怎么调。我整理出了一个自己的基准流程先用默认1e-3跑10个epoch观察训练集和验证集损失。如果训练损失下降正常但验证波动大说明模型容量或者正则化有问题如果训练损失都降不动一般先考虑迁移学习里解冻的阶段对不对或者数据是不是有标签错误。学习率本身很少是第一个要调的参数它是其他参数大致调对之后才需要精调的变量。最后补充一个实用细节ReduceLROnPlateau的patience参数不要设太小我踩过patience2导致学习率在正常波动里被过早降低的坑。设成5到8比较合适给验证集指标一点喘息空间。4.3 断点续训与随机种子的细节训练一个模型动辄几十分钟甚至几小时最怕中途出意外。TensorFlow有ModelCheckpoint回调可以直接解决这个问题。我在项目里的习惯是每一个epoch结束都保存一次且只保留验证集精度最优的那一份权重设置save_best_onlyTrue。恢复训练也很方便加载上一次保存的权重再继续fit即可但要注意优化器状态。如果只保存权重而不保存优化器状态恢复训练后学习率和动量都是重新初始化的这在效果上可能产生微妙差异。所以我的建议是调试阶段用save_weights_onlyTrue保存权重文件方便快速加载正式训练阶段用save_weights_onlyFalse完整保存包含优化器状态的完整模型。这样一个意外中断之后可以直接从检查点恢复优化器的动量状态还在训练曲线不会出现平台期。随机种子的问题同样被严重低估。为了让实验结果可复现我习惯在代码最前面做这三件事import random import numpy as np import tensorflow as tf random.seed(42) np.random.seed(42) tf.random.set_seed(42)但必须诚实地说这只保证了代码层面的可复现性。GPU上的并行操作仍然可能引入微小不确定性因为某些算子比如原子加法的执行顺序并非严格一致。如果你需要完全可复现的实验需要连CUDA的环境变量都一起设置。对一般项目来说代码层种子已经足够偏离那一两个百分点的精度波动通常不会影响决策。5. 从SavedModel到TFLite模型部署与推理优化的完整链路5.1 几种导出格式怎么选训练完模型只是第一步如何交付给下游使用才是工程落地时真正见功夫的地方。TensorFlow的模型导出格式主要有三种完整模型文件格式、SavedModel和TFLite。完整模型文件格式用model.save(xxx.keras)保存包含结构和权重适合在TensorFlow环境内继续微调或推理但不适合跨平台。SavedModel用tf.saved_model.save(model, saved_model_dir)保存是官方推荐的跨系统格式包含签名函数、变量和资产可以被TensorFlow Serving以服务化方式加载也可以被Python、Java、Go等客户端调用。TFLite用转换器把SavedModel进一步转换为.tflite文件专门跑在移动端、嵌入式设备和浏览器边缘环境。我的选择逻辑是如果目标环境能装TensorFlow直接用SavedModel如果要上手机App或物联网设备转TFLite。如果你只是做实验写论文那model.save一种方式就够了。核心原则是别让模型格式成为业务上线的瓶颈提前想清楚运行环境。5.2 TFLite转换与量化压缩实测这个项目最后需要把一个分类模型集成到手机端演示所以我做了TFLite转换和量化实验。转换本身一行代码就能完成converter tf.lite.TFLiteConverter.from_saved_model(saved_model_dir) tflite_model converter.convert() open(model.tflite, wb).write(tflite_model)不做任何量化的情况下模型大小和精度都跟原版几乎一致但速度提升有限。进一步的量化有三种级别动态范围量化、float16量化和int8量化。动态范围量化最简单代码里加一句converter.optimizations [tf.lite.Optimize.DEFAULT]权重会被压缩推理时部分算子转为整型计算精度损失通常很小。float16量化类似权重用半精度存储。int8全整数量化压缩最狠但需要准备一个校准数据集让转换器统计激活值的动态范围。我实测这个花卉模型的对比数据大致如下方案模型大小精度变化适用场景原始SavedModel约18MB基准服务端推理动态范围量化约5MB几乎不变通用移动端float16量化约9MB几乎不变带GPU的移动端int8量化约4.5MB下降约1个百分点嵌入式设备int8量化后模型体积缩小到四分之一左右精度只掉了约1%这在分类任务里完全可接受。但如果你做的是回归或者检测类任务1%的精度损失可能就不可忽视了要针对具体任务去验证。量化后的模型必须用真实数据做一遍全面评测不能只看转换报告因为后端算子在不同设备上的精度表现并不完全一致。5.3 推理性能调优的几个方向部署调优这块我花了比训练更多的时间因为端侧算力远弱于训练环境。综合两种部署路径我总结出四个方向。第一是算子融合和精简。TFLite转换过程会自动做一部分算子融合但你的模型结构本身决定了融合上限。像GlobalAveragePooling加Dense这种收尾结构通常已经很省算力反而是大量堆叠的小卷积核会导致端侧推理变慢。第二是输入尺寸。如果业务允许把输入分辨率从224×224降到160×160推理时间通常能大幅缩短。这个调整只需要在数据预处理里改一个参数但效果显著。第三是多线程与加速器设置。TFLite的Python接口里可以设置num_threads参数我实测在不同设备上最佳线程数并不相同四线程在双核设备上有时反而更慢。要针对目标设备做粗略的线程数扫一遍。第四是模型本身的轻量化。如果你的网络太重换EfficientNet-Lite这类专门为端侧设计的变体会比任何调优手段都有效。整个部署环节我的体感是模型结构决定上限转换工具决定下限调优只能在两者之间腾挪。架构选错量化救不回来。6. 我把TensorFlow当日常工具后总结出的几个习惯6.1 调试工作流从报错到定位问题接触TensorFlow久了我逐渐养成了一套自己的调试流程效率比早期看到报错就全网搜索高了很多。第一步永远是看完整报错栈TensorFlow的报错经常非常长关键信息往往不在最后一行而在中间某个During handling of the above exception之前的部分。养成一个习惯把报错复制到编辑器逐层往上翻找到第一次出现你自己代码文件的栈帧那通常才是根源。第二步是缩小范围。如果模型训练loss突然变成NaN先别急着调学习率。我会打印每一层输入的均值和方差定位是哪一层输出爆炸。用tf.debugging里的检查算子可以在指定位置直接断言数值有限性快速定位。第三步是怀疑数据而不是模型。很多训练异常最终都查到了数据头上标签错位、图片损坏、类别不平衡。在训练之前单独输出一批数据和标签可视化看看这个简单的习惯能省掉大量无效排查。6.2 资源受限时的取舍不是所有人都有多卡服务器。我自己做这个项目时只有一块中等显存的GPU很多实验必须精打细算。第一个习惯是混合精度训练代码里设置精度策略为mixed_float16后训练速度和显存占用都有明显改善代价是少量精度损失但对我的分类任务无影响。第二个习惯是限制fit里每次只跑少数epoch用于快速验证验证通过后再跑完整训练。第三个习惯是及时保存checkpoint并勇敢地中断实验。早期我总舍不得停觉得跑都跑了就让它跑完结果浪费了更多时间。现在只要验证集指标连续几个epoch没有按预期变化我就果断停掉改参数后重新跑。算力不够就把实验设计得聪明些先做小规模验证确认方向对了再上全量数据。6.3 接下来我会往哪个方向扩展这个图像分类项目做完之后我拿到了一份完整的模板数据管线怎么组织、模型怎么迁移学习、怎么量化部署。模板的好处是以后遇到类似任务能快速复用。我正在尝试把这个流程扩展到两个方向。一是多标签分类任务这次是单标签五分类多标签在损失函数和评估指标上会有不少新问题需要处理。二是把模型放在一个真实的移动端应用里做端到端测试收集真实使用中的数据再反哺训练集形成闭环迭代。对刚刚开始接触TensorFlow的人我的最终建议是不要被框架的庞大API吓到你真正高频使用的只有几个部分。先把数据管线、fit训练、保存模型这三个主流程跑通再逐步扩展到自定义循环和量化部署。框架本质上是一个工具箱你对它越熟悉越知道哪些工具是为你现在的项目量身定做的哪些只是摆设。用项目驱动学习比从文档的第一页翻到最后一页有效率得多。
每次有朋友问我深度学习入门该用什么框架我的答案基本都是同一个先把TensorFlow用熟。这倒不是说它在每个维度都比其他框架强而是因为它的资料最全、踩坑答案最好找、从实验到部署的链路最短。前阵子我用TensorFlow 2.x做了一个花卉图像分类的完整项目从收集图片、搭建模型一路做到模型导出上线全流程走完之后才意识到网上很多教程要么停在1.x的旧API要么只讲Keras的舒适区真正到了实战环节坑全在拐角处等着。这篇文章不打算复述官方文档只想把这次实战里真正起作用的东西讲清楚数据管线怎么设计才快、模型结构怎么选择才稳、训练出问题怎么定位、模型怎么导出才能被业务方直接使用。不管你是刚接触TensorFlow的小白还是被某个诡异报错卡了两天的半经验开发者这份整理应该都能给你一些可复现的参考。项目本身不复杂就是一个标准的多分类视觉任务但它覆盖了TensorFlow从训练到部署的完整路径也正好是我认为最能体现这个框架性格的一条路径。1. 重新认识TensorFlow2.x和1.x不是简单的升级1.1 为什么很多教程越看越晕先解决一个普遍困惑为什么网上搜TensorFlow出来的代码五花八门有的甚至互相矛盾根源在于TensorFlow经历了一次极其剧烈的接口变迁。1.x时代的核心是静态图你得先定义placeholder、变量、操作然后用session.run去触发计算。写成代码大概是这样一套流程每个变量都要声明图构建和实际执行完全分离。这种设计早期追求的是性能优化空间但对初学者极不友好我见过太多人被图和会话两个概念劝退。到了2.x官方把Keras吸收为高层API默认开启eager execution即动态图模式写法上接近普通Python代码。你定义一个模型、调用一次fit计算就立即执行不用再管session。这个改变方向是对的但代价是旧教程大量过时。我现在搜索技术问题时会默认加2.x或tf.keras前缀否则搜到的结果可能是在教1.x的session写法代码复制下来直接报错。另一个让人晕的原因是API层级太多高层有tf.keras中层有tf.data和tf.image底层还有raw ops和Variable管理。很多教程只教高层fit读者遇到稍微定制一点的需求就不知道怎么下钻。我的建议是日常开发以tf.keras为骨架遇到性能问题往下钻到tf.data遇到定制训练逻辑往下钻到GradientTape。每一层都清楚它是干什么的就不会被API数量吓住。1.2 和PyTorch的生态对比我的选型逻辑在社区里聊框架选型难免要对比PyTorch。老实说研究圈里用PyTorch的人越来越多它的动态图体验和Python风格写起来确实舒服。但我在做这个项目时仍然选择TensorFlow核心原因有三条。第一是部署链路。TensorFlow从训练到推理的工具链是闭环的训练完的模型可以存成SavedModel格式直接走TensorFlow Serving做服务化推理也可以转成TFLite跑在移动端还能转成TensorFlow.js跑在浏览器。这个一份模型多端运行的能力在业务落地时价值非常大。PyTorch需要依靠ONNX转TorchScript等中间步骤链路相对曲折。第二是生态完整度。tf.data、TensorBoard、TFX这些配套工具虽然各有上手成本但当你真的要做一个持续迭代的机器学习系统时它们是成体系的。TensorBoard的可视化我至今觉得比大多数同类工具直观。第三是历史资源。TensorFlow的问世时间更长生产环境里的踩坑记录、案例、Stack Overflow回答覆盖了绝大多数场景。对做工程落地的人而言可搜到的答案数量本身就是一种效率。当然这不意味着TensorFlow全无缺点。它的文档更新频繁导致部分示例过时报错信息有时候又长又绕这我在后面会详细说到。选型不是选宗教而是看清自己的需求侧重点如果重点是快速发论文做实验PyTorch很合适如果重点是训练完还要部署到多端TensorFlow目前仍然更省心。1.3 安装环境第一个坑其实在这里很多人以为安装TensorFlow就是pip install tensorflow这么一句话实际执行的时候问题全在补充环节。我的建议是新建一个独立的虚拟环境不要装到系统Python里。不同项目的依赖经常互相冲突我见过太多人因为环境混乱把GPU版的库搞坏最后只能重装系统。安装命令本身并不复杂但有两个细节值得注意。第一CPU版和GPU版从2.1开始是同一个包pip会自动拉取对应平台的版本不需要像1.x时代那样分别装。第二GPU能不能被识别取决于CUDA和cuDNN的版本是否在官方支持列表内。官方文档里有一张兼容性表格明确写了TensorFlow 2.x对应哪个CUDA版本。我在这上面栽过跟头装完包后运行代码发现模型训练异常缓慢检查半天才意识到GPU根本没被调用。装好之后可以用这段代码快速验证环境是否正常import tensorflow as tf print(tf.__version__) print(tf.config.list_physical_devices(GPU))如果GPU列表为空先别急着重装检查一下显卡驱动。不要自己乱装CUDA直接装驱动附带的标准CUDA工具包往往更省事。这属于环境问题里最磨人但最不值得深入研究的部分把时间留给模型本身。2. 数据管线动手写模型前先把数据准备好2.1 为什么坚持用tf.data而不是自己写循环很多人在开始写模型之前根本不重视数据加载数据量小的时候感觉不出来一旦图片数量到几万张问题就暴露了。我自己最早也犯过这个错用Python原生代码读图片、做预处理、塞进列表再转成numpy数组喂给模型。数据集不大的时候一切正常但当我扩展到几万张图片时训练过程大部分时间都花在等待数据上GPU利用率掉到惨不忍睹。TensorFlow给出的解决方案是tf.data.Dataset API。它的核心思想是把数据读取和预处理也当成一套计算管线由框架自动调度并行、预取、缓存而不是你在Python层手动一步步去做。这里我常用的几个基础操作按顺序列出来tf.data.Dataset.from_tensor_slices把numpy数组或文件路径列表包装成数据集.map对每个样本做预处理可以用num_parallel_callstf.data.AUTOTUNE自动并行.shuffle打乱顺序缓冲区大小一般设为样本总数或至少一个epoch的量级.batch分批尺寸跟上GPU显存匹配.prefetch(tf.data.AUTOTUNE)让数据准备和模型计算重叠这个操作几乎是免费的提速手段。实际使用中最容易被忽略的是.cache()。如果你的预处理包含大量重复计算比如每轮都重新解码并缩放图片那么把处理后的数据集缓存到内存或磁盘能省掉大量重复开销。我的习惯是第一轮完整跑一遍预处理并缓存到内存后续每个epoch直接读缓存训练速度提升非常明显。需要注意缓存到内存时如果数据集太大可能让机器内存吃紧这时可以指定缓存到文件。2.2 图像预处理与数据增强的完整写法这次花卉分类项目的数据集是我自己整理的公开图片和手工拍摄混合而来总共约两万张分五个类别。图片来源杂乱尺寸不一、光照差异大、还有少量损坏文件这些现实情况都必须在数据管线里处理掉。我用的是tf.keras.utils.image_dataset_from_directory配合目录结构来加载数据。这个API允许你按文件夹名自动生成标签省去手动维护csv的麻烦。目录结构大概是train目录下每个类别一个子文件夹validation和test同理。加载部分代码如下train_ds tf.keras.utils.image_dataset_from_directory( data/train, validation_split0.2, subsettraining, seed42, image_size(224, 224), batch_size32 )注意validation_split会在载入时直接切分训练集和验证集seed参数保证每次切分结果一致这对实验复现很重要。图片会统一缩放到224×224格式转为float32。但仅做到这里是不够的原始像素值范围是0到255直接进网络会导致数值不稳定通常要归一化到0到1或-1到1。我更推荐的做法不是用Lambda层或者外部rescale而是把归一化和数据增强放在tf.keras.Sequential模型的第一层这样训练和推理时的预处理逻辑完全一致。我的增强层配置大致如下data_augmentation tf.keras.Sequential([ tf.keras.layers.Rescaling(1. / 255), tf.keras.layers.RandomFlip(horizontal), tf.keras.layers.RandomRotation(0.1), tf.keras.layers.RandomZoom(0.1), ])有人会问数据增强不是应该在训练时做、推理时不做吗放进模型层的确会在推理时也走一遍随机变换但RandomFlip这些层在推理阶段其实会退化为恒等操作。而Rescaling归一化是两种阶段都需要的放一起反而省心。要注意的是增强操作计算开销不小如果数据集很大建议在CPU上预处理并使用.prefetch让增强和GPU计算重叠而不要把增强加到GPU模型内部导致卡在瓶颈。2.3 数据管线的瓶颈排查数据管线的性能问题很难从肉眼发现因为报错不会出现只是训练变慢。我排查卡顿的思路是这样的先看GPU利用率训练过程中在命令行跑GPU监控工具。如果GPU利用率长期低于50%同时CPU占用很高大概率是数据加载跟不上。然后做一个简单的对照实验把fit里的数据换成.repeat().take(100)这样的无意义数据或者干脆用dataset.take(1)跑一遍预处理看耗时。如果单独跑数据管线很快但训练时整体慢那就是数据预取没有生效。检查一下有没有写.prefetch(tf.data.AUTOTUNE)它能让数据管线和模型前向反向传播并行执行。还有一种很隐蔽的情况.shuffle的缓冲区大小远超内存导致不断做磁盘换入换出。我一朋友的项目就是把缓冲区设成了整个数据集大小机器内存不够用训练速度反而比不打乱更慢。shuffle缓冲区设成几千就够了不需要覆盖全部样本。数据管线的优化思路其实和流水线工厂很相似每个环节的吞吐量要匹配瓶颈总在最慢的那一站。3. 模型搭建与训练循环Keras层和底层API怎么配合3.1 Sequential、Functional、Subclass到底怎么选TensorFlow 2.x里搭建模型有三套主流方式很多人分不清什么时候用哪个。Sequential是最简单的线性堆叠适合输入单输出、结构链式的网络。如果你要处理多输入多输出、共享层、分支结构Functional是更合适的选择它把层当作可复用的对象通过显式连接定义计算图。Subclass方式则是继承tf.keras.Model在call方法里用Python代码自由控制前向逻辑灵活性最高但不利于序列化我一般只在写特殊网络时才用。我的选择标准很直接默认从Functional开始因为它表达能力比Sequential强序列化支持比Subclass好而且代码结构一眼能看出张量怎么流动。如果你确定结构非常简单用Sequential当然也没问题。但要避免的是没想清楚就上Subclass一旦需要model.summary()或者导出模型时才发现自定义类没写对回溯成本很高。写Functional模型时核心是把层当作函数调用。下面这个示例可以看做一个简化版的分类网络骨架inputs tf.keras.Input(shape(224, 224, 3)) x data_augmentation(inputs) x tf.keras.layers.Conv2D(32, 3, activationrelu)(x) x tf.keras.layers.MaxPooling2D()(x) x tf.keras.layers.Conv2D(64, 3, activationrelu)(x) x tf.keras.layers.GlobalAveragePooling2D()(x) x tf.keras.layers.Dropout(0.2)(x) outputs tf.keras.layers.Dense(5, activationsoftmax)(x) model tf.keras.Model(inputs, outputs)这段代码的优点在于你可以在任意两个层之间插入旁路、拼接或新的输入可扩展性强。3.2 一个CNN花卉分类模型的搭建过程回到这个项目的具体模型。我最初尝试自己搭建一个三层卷积网络分类准确率在验证集上只能到80%左右。后来换成扒官方预训练模型做迁移学习效果立刻好了不少。这里我的建议是除非你在做网络结构研究否则图像任务优先考虑tf.keras.applications里的预训练模型作为骨干。我最后用的是EfficientNet系列的预训练网络作为特征提取器。选择它不是因为参数最多或精度最高而是因为它的精度和计算量的平衡性很好在有限显存条件下表现比同量级的其他网络更稳。用法上和常规模型差异不大base_model tf.keras.applications.EfficientNetB0( include_topFalse, weightsimagenet, input_shape(224, 224, 3) ) base_model.trainable False inputs tf.keras.Input(shape(224, 224, 3)) x data_augmentation(inputs) x base_model(x, trainingFalse) x tf.keras.layers.GlobalAveragePooling2D()(x) x tf.keras.layers.Dropout(0.3)(x) outputs tf.keras.layers.Dense(5, activationsoftmax)(x) model tf.keras.Model(inputs, outputs)这里有两个关键点。第一迁移学习初期必须把骨干网络设为trainableFalse先只训练后面的分类头。如果一上来就全量微调预训练权重很快被破坏尤其数据量不够大时模型容易直接崩掉。第二base_model(x, trainingFalse)要显式传trainingFalse避免BatchNormalization层在推理时使用移动均值还是批次统计的混乱。这个细节通常不会报错但会影响验证准确率的稳定性。迁移学习通常分两步先冻结骨干训练分类头几个epoch再把base_model.trainable True解冻整个网络用很小的学习率做微调。我在项目里的做法是第一阶段学习率1e-3训练5个epoch解冻后学习率降到1e-5再训练10个epoch。这里的学习率跨度比较大是有意的因为新加的分类头需要的更新步幅和预训练骨干需要的更新步幅完全不同一步到位容易互相干扰。3.3 什么时候需要自己写训练循环model.fit足够覆盖大多数场景但有些需求必须自己写训练循环。例如生成对抗网络里判别器和生成器需要交替更新再比如自定义复杂损失、需要在每个batch内做多次梯度更新。写自定义训练循环的核心是tf.GradientTape它会自动记录前向计算里的可训练变量操作然后通过tape.gradient计算梯度最后用优化器apply_gradients更新参数。optimizer tf.keras.optimizers.Adam(learning_rate1e-3) loss_fn tf.keras.losses.SparseCategoricalCrossentropy() tf.function def train_step(images, labels): with tf.GradientTape() as tape: predictions model(images, trainingTrue) loss loss_fn(labels, predictions) gradients tape.gradient(loss, model.trainable_variables) optimizer.apply_gradients(zip(gradients, model.trainable_variables)) return losstf.function装饰器把Python函数编译成计算图首次调用时会经历追踪和编译之后多次调用性能接近静态图。我实测同样的训练循环加了tf.function后速度能提升不少。这里要提醒一个新坑自定义循环里如果混用了Python原生的if分支来依赖张量值可能被编译逻辑搞出奇怪行为。解决办法是把条件判断也改成TensorFlow API比如只根据全局步数做判断时用tf.cond或直接让分支依赖Python整数而非张量。项目里我最终没有用自己的训练循环fit够用了。但我把自定义循环练熟是有必要的因为当你需要把某个研究想法快速验证时能自由在tape.gradient前后插入操作这种掌控感是高层API给不了的。建议所有想长期用TensorFlow的人抽半天时间写一个简单的自定义循环哪怕只是把MNIST从头练一遍。4. 训练过程中真实踩过的坑过拟合、学习率和断点续训4.1 数据增强不是加了就有效训练过程中我最先遇到的问题就是过拟合。模型在训练集上准确率摸到95%以上验证集却停留在82%左右而且每个epoch之后差距都在拉大。第一反应当然是加数据增强。但这里有个反直觉的经验数据增强不是越猛越好适合你当前数据分布的增强组合需要试出来。我一开始用RandomRotation的旋转角度设为0.3大概17度还叠加了亮度变化。结果验证集准确率不但没上升反而掉了一点。后来我逐个检查才发现我需要分类的花卉图片里有许多方向性很强的特征过度旋转让模型无法建立稳定的方向特征映射。最终把旋转角度降到0.1亮度扰动去掉只保留水平翻转和轻微缩放验证集准确率反而稳步爬升。增强的另一面是你需要同步增加训练轮数。数据增强等效于扩大了训练集但这是按概率生成的新样本不是真实的独立样本如果epoch数不增加模型其实没机会看到足够多的变体。我做了一个简单的对比不加增强、训练20轮和加了适度增强、训练40轮后者的泛化效果明显更好。如果过拟合仍然存在下一步是考虑Dropout位置和比例。很多人的误区是一味增大Dropout比例结果模型欠拟合。我建议从0.2起步每次实验递增0.1并在验证集上观察曲线。还有一个很有效的做法是Dropout放在全局池化之后而不是每个卷积层之后因为卷积层本身有参数共享的天然正则化效果过度加Dropout反而削弱特征提取能力。4.2 学习率与BatchSize的联动影响这个坑我总结成一句话学习率、BatchSize、训练步数三者是绑定的改了一个就得重新审视另外两个。我的默认配置是BatchSize32、Adam默认学习率1e-3。在后来的实验里我把BatchSize提高到128结果验证集波动明显变大。原因很好理解BatchSize变大后梯度估计更稳定但同样学习率下收敛状态不同需要把学习率也放大才对实际却没有同步调整。理论上BatchSize扩大k倍学习率可以尝试扩大sqrt(k)倍或k倍具体哪种有效取决于优化器和任务。我的实操建议是每次只改一个变量并且同时记录训练集和验证集曲线。不要只看最终准确率一定要看曲线形态。如果训练损失持续下降但验证损失走平说明学习率后期还是偏大这时候可以启用ReduceLROnPlateau回调让验证指标不再改善时自动降低学习率。那段时间我看了太多教程都只提学习率很重要但很少有人说该怎么调。我整理出了一个自己的基准流程先用默认1e-3跑10个epoch观察训练集和验证集损失。如果训练损失下降正常但验证波动大说明模型容量或者正则化有问题如果训练损失都降不动一般先考虑迁移学习里解冻的阶段对不对或者数据是不是有标签错误。学习率本身很少是第一个要调的参数它是其他参数大致调对之后才需要精调的变量。最后补充一个实用细节ReduceLROnPlateau的patience参数不要设太小我踩过patience2导致学习率在正常波动里被过早降低的坑。设成5到8比较合适给验证集指标一点喘息空间。4.3 断点续训与随机种子的细节训练一个模型动辄几十分钟甚至几小时最怕中途出意外。TensorFlow有ModelCheckpoint回调可以直接解决这个问题。我在项目里的习惯是每一个epoch结束都保存一次且只保留验证集精度最优的那一份权重设置save_best_onlyTrue。恢复训练也很方便加载上一次保存的权重再继续fit即可但要注意优化器状态。如果只保存权重而不保存优化器状态恢复训练后学习率和动量都是重新初始化的这在效果上可能产生微妙差异。所以我的建议是调试阶段用save_weights_onlyTrue保存权重文件方便快速加载正式训练阶段用save_weights_onlyFalse完整保存包含优化器状态的完整模型。这样一个意外中断之后可以直接从检查点恢复优化器的动量状态还在训练曲线不会出现平台期。随机种子的问题同样被严重低估。为了让实验结果可复现我习惯在代码最前面做这三件事import random import numpy as np import tensorflow as tf random.seed(42) np.random.seed(42) tf.random.set_seed(42)但必须诚实地说这只保证了代码层面的可复现性。GPU上的并行操作仍然可能引入微小不确定性因为某些算子比如原子加法的执行顺序并非严格一致。如果你需要完全可复现的实验需要连CUDA的环境变量都一起设置。对一般项目来说代码层种子已经足够偏离那一两个百分点的精度波动通常不会影响决策。5. 从SavedModel到TFLite模型部署与推理优化的完整链路5.1 几种导出格式怎么选训练完模型只是第一步如何交付给下游使用才是工程落地时真正见功夫的地方。TensorFlow的模型导出格式主要有三种完整模型文件格式、SavedModel和TFLite。完整模型文件格式用model.save(xxx.keras)保存包含结构和权重适合在TensorFlow环境内继续微调或推理但不适合跨平台。SavedModel用tf.saved_model.save(model, saved_model_dir)保存是官方推荐的跨系统格式包含签名函数、变量和资产可以被TensorFlow Serving以服务化方式加载也可以被Python、Java、Go等客户端调用。TFLite用转换器把SavedModel进一步转换为.tflite文件专门跑在移动端、嵌入式设备和浏览器边缘环境。我的选择逻辑是如果目标环境能装TensorFlow直接用SavedModel如果要上手机App或物联网设备转TFLite。如果你只是做实验写论文那model.save一种方式就够了。核心原则是别让模型格式成为业务上线的瓶颈提前想清楚运行环境。5.2 TFLite转换与量化压缩实测这个项目最后需要把一个分类模型集成到手机端演示所以我做了TFLite转换和量化实验。转换本身一行代码就能完成converter tf.lite.TFLiteConverter.from_saved_model(saved_model_dir) tflite_model converter.convert() open(model.tflite, wb).write(tflite_model)不做任何量化的情况下模型大小和精度都跟原版几乎一致但速度提升有限。进一步的量化有三种级别动态范围量化、float16量化和int8量化。动态范围量化最简单代码里加一句converter.optimizations [tf.lite.Optimize.DEFAULT]权重会被压缩推理时部分算子转为整型计算精度损失通常很小。float16量化类似权重用半精度存储。int8全整数量化压缩最狠但需要准备一个校准数据集让转换器统计激活值的动态范围。我实测这个花卉模型的对比数据大致如下方案模型大小精度变化适用场景原始SavedModel约18MB基准服务端推理动态范围量化约5MB几乎不变通用移动端float16量化约9MB几乎不变带GPU的移动端int8量化约4.5MB下降约1个百分点嵌入式设备int8量化后模型体积缩小到四分之一左右精度只掉了约1%这在分类任务里完全可接受。但如果你做的是回归或者检测类任务1%的精度损失可能就不可忽视了要针对具体任务去验证。量化后的模型必须用真实数据做一遍全面评测不能只看转换报告因为后端算子在不同设备上的精度表现并不完全一致。5.3 推理性能调优的几个方向部署调优这块我花了比训练更多的时间因为端侧算力远弱于训练环境。综合两种部署路径我总结出四个方向。第一是算子融合和精简。TFLite转换过程会自动做一部分算子融合但你的模型结构本身决定了融合上限。像GlobalAveragePooling加Dense这种收尾结构通常已经很省算力反而是大量堆叠的小卷积核会导致端侧推理变慢。第二是输入尺寸。如果业务允许把输入分辨率从224×224降到160×160推理时间通常能大幅缩短。这个调整只需要在数据预处理里改一个参数但效果显著。第三是多线程与加速器设置。TFLite的Python接口里可以设置num_threads参数我实测在不同设备上最佳线程数并不相同四线程在双核设备上有时反而更慢。要针对目标设备做粗略的线程数扫一遍。第四是模型本身的轻量化。如果你的网络太重换EfficientNet-Lite这类专门为端侧设计的变体会比任何调优手段都有效。整个部署环节我的体感是模型结构决定上限转换工具决定下限调优只能在两者之间腾挪。架构选错量化救不回来。6. 我把TensorFlow当日常工具后总结出的几个习惯6.1 调试工作流从报错到定位问题接触TensorFlow久了我逐渐养成了一套自己的调试流程效率比早期看到报错就全网搜索高了很多。第一步永远是看完整报错栈TensorFlow的报错经常非常长关键信息往往不在最后一行而在中间某个During handling of the above exception之前的部分。养成一个习惯把报错复制到编辑器逐层往上翻找到第一次出现你自己代码文件的栈帧那通常才是根源。第二步是缩小范围。如果模型训练loss突然变成NaN先别急着调学习率。我会打印每一层输入的均值和方差定位是哪一层输出爆炸。用tf.debugging里的检查算子可以在指定位置直接断言数值有限性快速定位。第三步是怀疑数据而不是模型。很多训练异常最终都查到了数据头上标签错位、图片损坏、类别不平衡。在训练之前单独输出一批数据和标签可视化看看这个简单的习惯能省掉大量无效排查。6.2 资源受限时的取舍不是所有人都有多卡服务器。我自己做这个项目时只有一块中等显存的GPU很多实验必须精打细算。第一个习惯是混合精度训练代码里设置精度策略为mixed_float16后训练速度和显存占用都有明显改善代价是少量精度损失但对我的分类任务无影响。第二个习惯是限制fit里每次只跑少数epoch用于快速验证验证通过后再跑完整训练。第三个习惯是及时保存checkpoint并勇敢地中断实验。早期我总舍不得停觉得跑都跑了就让它跑完结果浪费了更多时间。现在只要验证集指标连续几个epoch没有按预期变化我就果断停掉改参数后重新跑。算力不够就把实验设计得聪明些先做小规模验证确认方向对了再上全量数据。6.3 接下来我会往哪个方向扩展这个图像分类项目做完之后我拿到了一份完整的模板数据管线怎么组织、模型怎么迁移学习、怎么量化部署。模板的好处是以后遇到类似任务能快速复用。我正在尝试把这个流程扩展到两个方向。一是多标签分类任务这次是单标签五分类多标签在损失函数和评估指标上会有不少新问题需要处理。二是把模型放在一个真实的移动端应用里做端到端测试收集真实使用中的数据再反哺训练集形成闭环迭代。对刚刚开始接触TensorFlow的人我的最终建议是不要被框架的庞大API吓到你真正高频使用的只有几个部分。先把数据管线、fit训练、保存模型这三个主流程跑通再逐步扩展到自定义循环和量化部署。框架本质上是一个工具箱你对它越熟悉越知道哪些工具是为你现在的项目量身定做的哪些只是摆设。用项目驱动学习比从文档的第一页翻到最后一页有效率得多。
