使用基于Caffe的MobileNet分类踩坑备忘录

首先帮Caffe甩个锅:Caffe对图像处理进行了很高明的封装,以protobuffer形式组织的搭积木式的网络构建也很灵活方便,这里的坑都是自己走路不稳崴进去的。

1. Caffe的一个iter是一个batch,不是一个epoch。

2. 使用现有模型存档对网络进行fine_tune的时候,由于改变了输出的number,最后一层必须重新命名,目的是不复用最后一层的存档参数。和tensorflow不太一样的时候,如果最后一层的参数数量不一致,训练时不会抛出异常,居然可以正常运行,然后。。。收敛只是梦一场。

3. 对于caffe的分类标签文件,需要严格遵循从0开始的规则,如果像我一样拍脑袋从1开始,您能收敛,我直播吃手机。 (据同事经验:类别需要连续,0,1,2,3,4....是ok的;0,1,2,4,6.....是会被ko的)。

4. 学习率选择需要炼丹的耐性,建议从0.001开始试错,每次降一个数量级。从过大和过小的学习率去初始训练,都会极大提升时间成本(和你的怨念感)。

5. 因为我做分类用的label文件在前期做了比较多的数值处理,类型转换等工作,每一个流程/环节有疏忽都会造成最终的label文件有问题,并且这些问题因为数据量过大,很难通过肉眼排查, 非常容易出错,对于label文件的生成,小心为妙!

(估计未完,只能待续)

原文地址:https://www.cnblogs.com/punkcure/p/9233857.html

时间: 2024-10-25 17:43:19

使用基于Caffe的MobileNet分类踩坑备忘录的相关文章

基于Python技术栈的算法落地踩坑

背景介绍 在一些业务场景,我们需要把离线训练好的模型以微服务部署线上,如果是简单的使用sklearn pipeline,可以保存为XML格式的pmml供Java调用,在配置为4 core,8G内存的docker环境可以提供8K左右的高并发,并且这种docker可以快速大规模部署到PaaS云平台,优势相当明显,实际情况是算法人员会基于Python自定义lambda处理数据,而自定义的lambda是很难保存到pmml中的,并且很多公司的算法团队也是要求基于Python技术栈是 落地的. 踩坑过程 算

AI相关 TensorFlow -卷积神经网络 踩坑日记之一

上次写完粗浅的BP算法 介绍 本来应该继续把 卷积神经网络算法写一下的 但是最近一直在踩 TensorFlow的坑.所以就先跳过算法介绍直接来应用场景,原谅我吧. TensorFlow 介绍 TF是google开源出来的人工智能库,由python语言写的 官网地址:http://www.tensorflow.org/   请用科学上网访问 中文地址:http://www.tensorfly.cn/ 当然还有其他AI库,不过大多数都是由python 写的 .net 的AI库叫 Accord.net

基于caffe与MATLAB接口的回归分析与可视化

如果遇到一些问题,可以在这里找下是否有解决方案.本文内容主要分为两部分,第一部分介绍基于caffe的回归分析,包括了数据准备.配置文件等:第二部分介绍了在MATLAB上进行的可视化.(话说本人最近有个课题需要做场景分类,有兴趣可以共同探讨一下). Preparation 预装好caffe on windows,并编译成功MATLAB接口. 通过caffe进行回归分析 通过caffe进行回归分析,在实验上主要分成HDF5数据准备.网络设计.训练.测试.该实验已经有网友做过,可以参考:http://

之后要接触更多代码管理的知识——2015踩坑有感

前言 学习是没有止境的,管理代码的能力也永远需要提高. 前几个月还觉得R语言,业务上要用的都学得七七八八了呢,这几个月在自家部门吭哧吭哧搞报表自动化时,各个坑一踩一个准,才明白写代码,懂得一点语言特性固然重要,弄一套科学地管理代码的方法,却是势在必行. 因此在这里总结一下这几个月来我踩过的种种坑,以及之后在查阅种种大神的经验,以及学软件工程这门课时看到的一些比较妥当的方法,算是这几个月的一个总结.2016年的时候,真的要多学学如何科学地管理代码,科学开发 请注意,因为我属于跨专业半路出家写代码,

人工智能(AI)库TensorFlow 踩坑日记之二

上次 踩坑日志之一 遗留的问题终于解决了,所以作者(也就是我)终于有脸出来写第二篇了. 首先还是贴上 卷积算法的示例代码地址 :https://github.com/tensorflow/models   这个库里面主要是一些常用的模型用tensorflow实现之后的代码.其中我用的是 models/tree/master/tutorials/image/cifar10 这个示例,上一篇也大致讲过了. 关于上次遇到问题是: 虽然训练了很多次,但是每次实际去用时都是相同的结果.这个问题主要原因是

基于Caffe的Large Margin Softmax Loss的实现(上)

小喵的唠叨话:在写完上一次的博客之后,已经过去了2个月的时间,小喵在此期间,做了大量的实验工作,最终在使用的DeepID2的方法之后,取得了很不错的结果.这次呢,主要讲述一个比较新的论文中的方法,L-Softmax,据说单model在LFW上能达到98.71%的等错误率.更重要的是,小喵觉得这个方法和DeepID2并不冲突,如果二者可以互补,或许单model达到99%+将不是梦想. 再次推销一下~ 小喵的博客网址是: http://www.miaoerduo.com 博客原文:  http://

【转】Android开发在路上:少去踩坑,多走捷径

本文是我订阅"腾讯大讲堂"公众帐号时,他们推送的一篇文章,但在腾讯大讲堂官网上我并没有找到这篇文章,不过其它专门"爬"公众号文章的网站倒是有.我觉得写的很不错.就转载出来,如有版权问题请email告知.   你可以通过扫描下面的二维码来关注"腾讯大讲堂"     ----------------------------------------- 我是可恶的分隔线 -----------------------------------------

Windows利用Swarm原生Docker集群踩坑总结

环境: 角色 机器名称 操作系统 IP 备注 Mater Web30 Windows Server 2016 GUI 192.168.2.30 安装最新推荐补丁 Node Web31 Windows Server 2016 Core 192.168.2.31 安装最新推荐补丁 Node Web32 Windows Server 2016 Core 192.168.2.32 安装最新推荐补丁 第一坑:Windows Server 2016 Core 1.操作系统分区坑 由于我们使用的Windows

Spark踩坑记——数据库(Hbase+Mysql)转

转自:http://www.cnblogs.com/xlturing/p/spark.html 前言 在使用Spark Streaming的过程中对于计算产生结果的进行持久化时,我们往往需要操作数据库,去统计或者改变一些值.最近一个实时消费者处理任务,在使用spark streaming进行实时的数据流处理时,我需要将计算好的数据更新到hbase和mysql中,所以本文对spark操作hbase和mysql的内容进行总结,并且对自己踩到的一些坑进行记录. Spark Streaming持久化设计