python tensorflow

# 关于Python LightGBM一个常用但经常被误解的工具团队里有个新人问我LightGBM到底是个什么东西为什么大家都在用。正好借着这个问题把这些年用下来的感受整理一下。他是什么LightGBM其实是个梯度提升框架微软做的。你说它和XGBoost有什么本质区别核心差别就在树生长的策略上。传统的梯度提升树是按层生长的一层一层铺开像个贪吃蛇一样把整个空间填满。LightGBM不一样它按叶子生长每次只挑增益最大的那个叶子去分裂。打个比方吧就像两个人在做拼图。一个人把整张图先分成四块然后每块再分四块均匀地分。另一个人盯着最复杂的那块先把那个人脸拼出来剩下的简单区域随它去。后者就是LightGBM的路子。这种策略有个好处就是能在同样的深度下捕捉到更复杂的模式。缺点也不是没有深了容易过拟合这个后面再聊。他能做什么讲真结构化数据上的分类回归任务LightGBM基本上是默认选项之一。电商的点击率预测、金融的信用评分、工业场景的异常检测这些场景里LightGBM的表现通常不错。有个场景特别能体现它的特点。去年有个用户行为预测的项目数据量大概是三百万行两百多个特征。用XGBoost跑了快二十分钟换成LightGBM同样的参数设置五分钟不到就出结果了。速度优势在超大数据集上尤其明显。但得说清楚LightGBM不是万能的。图像、文本、序列数据这些它就不太擅长。有人非要拿它做NLP结果还不如一个简单的词袋模型加逻辑回归。怎么使用安装倒是简单pip install lightgbm就行。不过建议用conda装省得编译的时候出幺蛾子。基本用法和sklearn差不多importlightgbmaslgbimportpandasaspdfromsklearn.model_selectionimporttrain_test_split# 数据准备X_train,X_val,y_train,y_valtrain_test_split(X,y,test_size0.2)# 训练modellgb.LGBMClassifier(num_leaves31,learning_rate0.1,n_estimators100)model.fit(X_train,y_train)看着很简单对吧但真正用的时候参数调起来特别麻烦。我刚开始也踩过坑以为参数调得多就好结果模型跑得慢还过拟合。有个小技巧先固定learning_rate和n_estimators只调num_leaves。等叶子数合适了再去调整learning_rate。这样不会陷入参数地狱。最佳实践这些年调LightGBM踩过的坑说几个印象深刻的。第一个坑是num_leaves设得太大。有人觉得叶子数代表模型复杂度越大越好。但实际上一旦超过50在大部分数据集上就开始过拟合了。解决办法很简单把num_leaves和max_depth结合起来用。比如num_leaves设31同时限制max_depth6这样树不会长太高。第二个是类别特征的处理。LightGBM原生支持类别特征但有个前提特征值必须是整数并且要告诉模型这是类别特征。很多人直接传字符串进去模型就当是缺省值处理了。# 正确做法modellgb.LGBMClassifier(categorical_feature[feature_name])# 或者model.fit(X_train,y_train,categorical_feature[0,1,3])# 传入列索引第三个是关于early_stopping。这玩意儿非常有用但很多人用得不对。early_stopping依赖验证集所以验证集的划分很关键。要是验证集和训练集分布差异太大early_stopping反而会让模型更差。通常建议用分层抽样来划分数据。和同类技术对比单纯的梯度提升树有个问题对异常值敏感。所以出现了很多变体比如CatBoost和XGBoost。这三个放在一起比较有点像三种不同的做事方式。CatBoost处理类别特征最省心不需要做特征编码。但它的速度和内存消耗都比LightGBM大。XGBoost则胜在稳定性参数调起来不那么敏感但速度慢一些。LightGBM在处理数据倾斜时有个天然优势。因为它的直方图算法能自动忽略那些稀疏特征里的零值。想象一下一百个特征里有八十个全是零LightGBM就不会在这一大堆零上浪费计算资源。这在推荐系统的用户行为数据上特别有用。不过LightGBM对数值特征的容错性不如XGBoost。如果数据里有极端值LightGBM会直接切出一个只有几个样本的叶子节点。而XGBoost因为层生长策略不会出现这种极端情况。选哪个看场景。数据量大、特征多、对速度有要求LightGBM是首选。数据量大但# CatBoost这个名字第一次听到可能会觉得有点拗口但它背后其实藏着一个很直白的缩写Categorical Boosting专门处理分类特征的提升树算法。这块一开始是Yandex搞出来的那时候几家大厂都憋着劲在搞类似的东西Google有TensorFlow微软有LightGBM他们也需要一个自己的高性能框架来支撑搜索和推荐业务。它到底是什么本质上CatBoost是梯度提升决策树GBDT的一个实现变种。说白了就是让一连串决策树按顺序生长后一棵树尽量去修正前一棵树的错误。和所有同类工具最大的差异在于它对“类别特征”的处理方式——不是简单的转成数值而是用一种叫“目标编码”的动态策略。具体做法是在训练过程中用之前样本的标签均值来给当前样本的类别做编码同时加上贝叶斯先验来防止过拟合。这个听起来有点绕但实际效果蛮好的很多业务数据里性别、地域、用户标签这些非数值信息一多自己手动做编码经常做不干净CatBoost直接吃掉这些原始字段省去很多工作量。它擅长解决什么问题最常见的场景就是各种结构化数据的表格竞赛或真实业务比如电商的客户流失预测、信贷风控模型、医疗诊断中的特征分类应用。因为自带的处理类别特征能力特别适合那种字段里一堆“城市A/城市B”“高/中/低”这类字符串而你的时间又不允许一个个去试各种编码方案的场景。另一个会被提到的优势是它对缺失值的容忍度很高不少树模型遇到NaN会直接中断或需要额外补值CatBoost内部有一套默认的缺失值处理路径训练时候自动走不通就分到一个方向去初学者压力小很多。到底怎么上手用安装跟上其他的库差不多pip就搞定。但要特别注意一点它跟很多其他机器学习库一样依赖于比较好的C编译环境尤其在Windows上建议用Anaconda装会更稳不然编译半天失败怪郁闷的。典型的使用代码结构其实非常直观fromcatboostimportCatBoostClassifier,Pool# 构造数据train_data[[高,上海,30,1],[低,北京,25,0],[中,深圳,35,1]]train_labels[1,0,1]# 指明哪些列是类别特征cat_features[0,1]# 训练modelCatBoostClassifier(iterations500,learning_rate0.05,depth6)model.fit(train_data,train_labels,cat_featurescat_features)# 预测predsmodel.predict([[中,广州,28,0]])这里最特别的就是那个cat_features参数。如果不传这个库里会尝试自动检测哪些是类别列但有时候会被数值标志误判所以手动指定可能更稳。积累下来的一些经验如果说有什么值得分享的经验大概有三点。第一默认参数常常够用但不要迷信默认。很多新手上来就跑iterations1000结果训练久、还容易过拟。一个更像人工判断的态度是对着数据量去调小数据量几千条能把iterations降到200到300之间学习率提到0.1到0.2配合早停early stopping来结束训练。这个组合往往比默认值在有限数据上表现好不少而且时间快很多。第二对大规模类别特征可以适度降低one_hot_max_size。这个参数控制当某个类别变量取值超过多少个不同值以后就不再采用One-hot编码而是用CatBoost自己的多值编码算法。比如有个字段叫“用户ID”取值上百万那显然不适合做成几百列稀疏矩阵。这个阈值默认是255机器内存吃紧时可以调到50甚至更低。第三交叉验证策略要留意数据泄露问题。因为它的目标编码策略用到样本先后顺序如果对全量数据随机打乱再分fold可能在验证集上看到未来的信息。所以如果数据有时间概念比如按天划分官方建议用cv参数配合timeTrue使用按时间顺序的交叉验证。这点在线上服务里容易翻车。和LightGBM、XGBoost比起来怎么样这其实是不少人纠结的问题。从性能角度LightGBM在大型数据集百万级以上训练速度常是最快的XGBoost则因为历史更久、社区最成熟各种奇技淫巧都有解决方案。CatBoost的劣势在于训练速度尤其是用CPU跑的时候比LightGBM慢不少。但在类别特征多且分布较脏的场景里XGBoost往往需要手动做目标编码或者LabelEncoderLightGBM虽然支持类别特征但输入格式限制较严格需要转换成整型并指定categorical_feature参数。CatBoost是那种开箱直接用、不需要在数据预处理上花太多心思的类型尤其适合快速验证或者数据现状比较乱的时候。另外有一点很有意思在其他两个库中如果类别特征类别数特别多比如上千种LightGBM的分裂策略会陷入计算瓶颈而CatBoost由于内置了针对高层级类别特征的一组贪心策略在这个条件下反而训练更快。所以如果有几千个类别的字段不妨试试CatBoost。最后这三者在预测精度上差# ### 1. 他是什么TensorFlow 就像一个搭积木的数学游乐场。很多初学者以为它是某种“AI魔法盒”其实它的核心更像是一套让我们用代码描述数学运算的工具。比如你要计算 (35)×2普通Python直接写(35)*2就行但在TensorFlow里你得先搭个“计算图”创建两个占位符放3和5定义加法节点和乘法节点最后把数据喂进去跑。这种“先搭图后执行”的设计最初是为了方便在GPU上并行计算。不过现在的TensorFlow 2.x已经改了不少默认开启了Eager Execution动态执行模式更像我们平时写Python了。但底层那种“把运算看成数据流网络”的思维还在——每个节点是个运算比如矩阵乘法边是流动的数据张量其实就是多维数组。你可以想象成自来水管道水流数据经过不同的阀门运算最终变成你想要的输出预测结果。2. 他能做什么最广为人知的是深度学习但它的功能远不止此工业级生产部署很多银行的风控系统背后跑着TensorFlow SavedModel因为它能把模型序列化成标准格式用C或Java的推理引擎加载。比如某支付公司的实时交易反欺诈模型就是用TensorFlow训练后导出在Java服务里直接调用。迁移学习和微调假设你要识别不同品种的猫手头只有100张图片。用TensorFlow Hub模型仓库直接下载别人在ImageNet上预训练好的MobileNet冻结前面90%的层只重新训练最后几层识别猫品种。这就像学自行车的老手去骑电动车——核心平衡能力已经有了只需要适应新的操作细节。科学计算除了神经网络它的自动微分功能在物理仿真、期权定价里也有应用。国外有团队用TensorFlow计算蛋白质折叠的势能面论文里说比传统数值方法快20倍。边缘设备TensorFlow Lite可以把模型压缩到几百KB运行在树莓派甚至智能手环上。比如某款智能门锁能在本地用摄像头抓拍的0.3秒内完成人脸识别就是靠的TFLite。3. 怎么使用假设要从零训练一个模型识别手写数字MNIST数据集流程像做菜第一步准备食材数据importtensorflowastf(x_train,y_train),(x_test,y_test)tf.keras.datasets.mnist.load_data()x_trainx_train/255.0# 归一化就像洗菜切块第二步搭灶台定义模型modeltf.keras.models.Sequential([tf.keras.layers.Flatten(input_shape(28,28)),tf.keras.layers.Dense(128,activationrelu),tf.keras.layers.Dropout(0.2),# 防过拟合相当于烧菜时控制火候tf.keras.layers.Dense(10,activationsoftmax)])第三步点火编译模型model.compile(optimizeradam,losssparse_categorical_crossentropy,metrics[accuracy])第四步炒菜训练historymodel.fit(x_train,y_train,epochs5,validation_split0.2)第五步试菜评估test_loss,test_accmodel.evaluate(x_test,y_test)print(f测试准确率:{test_acc:.4f})这里有个容易踩的坑validation_split0.2表示从训练集自动切20%做验证但数据如果本身按标签排序比如前5000张全是数字0验证集就会失真。实际应该先用sklearn.model_selection.train_test_split手动切分。4. 最佳实践数据加载别用循环很多人习惯写for batch in dataset:但TensorFlow的tf.data有更高效的流水线。比如用.prefetch(tf.data.AUTOTUNE)能让CPU预处理下批数据的同时GPU在算当前批次就像泡面时同时烧水而不是等水烧开才找面饼。分布式调试的陷阱用多GPU训练时很多人直接在镜像策略里打印张量形状。但策略会复制张量到每个设备打印出来的是tf.Tensor的符号句柄不是真实值。需要改用tf.print()或者在函数内用tf.debugging.assert_equal。模型保存的版本管理别只保存.h5文件。用tf.saved_model.save生成的文件夹里包含签名定义和资产文件比如词汇表不同团队通过ProtoBuf的格式兼容性更好。有次我在生产环境加载同事的.h5模型因为对方用的是Keras 2.3而我本地是2.4加载直接崩掉。训练小模型的意外收获如果模型小于10MB用model.save_weights保存只有权重的二进制文件就行加载时再重建模型结构。这在移动端部署时能省掉序列化开销——好比搬家时不带衣柜模型结构只带走挂着的衣服权重到新家再买个结构一样的衣柜挂上。5. 和同类技术对比PyTorch最主流的对手。相似点都能做自动求导、GPU加速、支持分布式训练。差异点PyTorch的调试更直观——它的张量就像普通数组你可以随时print(tensor.shape)而TensorFlow早期版本要开启Eager Mode或者用tf.Session().run()才能看到真实值。但TensorFlow的模型部署生态更成熟它的TFLite能直接跑在MicroPython上而PyTorch在移动端的延展性相对弱一些。典型场景对比学术研究更多用PyTorch因为灵活工业部署更倾向TensorFlow因为工具链完善。JAXGoogle的另一个实验性框架适合写纯数学推导的论文。它用函数式编程的思维没有原生神经网络模块。比如你要做梯度下降得自己写循环更新参数而TensorFlow的model.fit一行搞定。JAX的加速比TensorFlow更极致通过jit编译但上手门槛高得多。ONNX Runtime一个跨框架的推理引擎。如果你用TensorFlow训练模型导出为ONNX格式就能用ONNX Runtime在Windows的.NET环境里跑。但ONNX对某些算子比如tf.random_uniform的支持不完整转换时容易报错。Keras是TensorFlow的高层API很多人分不清。其实Keras本身独立于TensorFlow背后可以调用任意框架。假设你写from tensorflow.keras是用的TensorFlow版本而from keras是独立的Keras项目。早期两个版本的行为有差异比如LSTM的return_sequences参数默认值不同现在基本统一了。选择建议如果项目需要快速验证算法原型且团队习惯动态图的调试方式PyTorch更合适如果有大量生产环境部署需求比如同时服务iOS/Android/Web或者需要用到TPU训练谷歌云专属硬件TensorFlow是更稳妥的选择。对于纯计算任务比如物理模拟中的微分方程JAX可能是更好的选择。别一般不会太大尤其是在调参合理的前提下。更多时候选择哪一个取决于你的数据特性、工程约束、以及个人习惯。如果硬要选一个推荐我会说做比赛或是研究的建议都试一下但在生产环境维护一个现成的项目建议先看看当前的数据管线里已有的依赖和读写习惯不要为了换而换。类别特征多CatBoost可能更好。数据量不是很大但对稳定性要求高XGBoost就够用了。说到底工具这东西没有绝对的好坏关键看怎么用。就像有人用notepad写代码有人非要装个IDE最后写出什么水平的代码跟工具有关但关系不大。