实际工程问题中应用机器学习和深度学习的踩坑心得总结

数据样本

一开始会偏好去套用论文中的各种华丽算法，希冀提高百分之几的指标，最后“啪啪啪”打脸，发现还是那句老话说得好，“对于一个机器学习问题，数据和特征往往决定了结果的上限，而模型、算法的选择及优化则是在逐步接近这个上限”。所以追本溯源，提高结果的关键手段之一是提高数据和特征的质量和数量，这能达到快速提高指标结果的目的。

• 增加训练样本数量，收集更多的数据
• 优化数据清洗
• 改善样本分布

特征工程

特征工程主要是在应用机器学习算法时需要重点关注的地方，深度学习本身并不需要进行人工提取特征。

• 模型过拟合，可适当减少特征数量
• 尝试获得更多的特征
• 尝试增加多项式特征

模型选择

建模初期阶段，试图复现论文中各式各样的模型，但是实际工程应用中，这些往往不如基于一个模型逐步调参更有效。

• 初期可以先用一个baseline模型（通常是逻辑回归lr模型），看看指标的基线大致在多少，然后再尝试调参或者其他模型（CNN、RNN等）
• 尝试减少或增加正则化程度
• 深度学习神经网络中的隐藏层数选择，可以先从一层开始逐渐增加层数
• 深度学习中，embedding很重要
• 模型精度固然重要，但在部署上线时，计算效率也很重要

深度学习

样本规模大时如何读取和存储

​​​​​​小规模训练样本在输入时可以直接load（txt/csv）进内存处理，但深度学习往往样本百万级，直接load限制数据规模，大规模数据无法完成一次性加载，且散列存储占用磁盘空间，读取缓慢。数据预处理通常在python中直接调用，后续使用算法训练时使用gpu处理，这样gpu和cpu来回切换，gpu占用率抖动。所以并行计算是个好办法，用spark将样本数据构造成TFRecord的格式，TFRecord对大型训练数据很友好，简单快速，spark效率高，数据规模也有进一步的提升空间。

TFRecord的优点：

• 避免像图片/文本/语音数据集散列存储，不仅占用磁盘空间，而且一个个读取缓慢繁琐
• 避免占用大量内存空间（有些大型文件无法一次性加载），TFRecord内部使用了“Protocol Buffer”二进制数据编码方案，它只占用一个内存块，只需要一次性加载一个二进制文件的方式即可，简单，快速，尤其对大型训练数据很友好
• 当训练数据量比较大的时候，可以将数据分成多个TFRecord文件，来提高处理效率

生成TFRecord代码：

writer = tf.python_io.TFRecordWriter(record_path)
writer.write(tf_example.SerializeToString())
writer.close()

OOV（out of vocabulary）问题

oov问题就是文本中出现的字词不在我们所构建的词汇表中（经常是test阶段，如果是加载与训练的外部词向量，train和val阶段也会出现oov），也就没有办法在embedding层进行lookup的操作，从统计学的角度来说，这种字词大部分还是出现频率较低的字词（不然也就出现在词汇表中了），所以可以打那个做UNK（Unknown Words）问题处理。

1. 用char代替word，字符代替词语能够避免很多生词的出现，字典规模也比词典规模小很多，尤其是文本出现很多地名、人名、机构名、专有名词等，而常用字就那么多（3000左右规模），但是char based在处于中文文本时优势也并不十分明显
2. UNK初始化成一个embedding：①全初始化成0向量，但UNK则具有相同的语义 ②每次随机初始化成随机向量，避免了UNK存在语义一致性问题

How to add new embeddings for unknown words in Tensorflow (training & pre-set for testing)

Initializing Out of Vocabulary (OOV) tokens

模型过拟合

• batch normalization 
• layer normalization 
• dropout
• early stopping
• shuffle

模型部署

TensorFlow Serving

模型评估

模型调参或更换是否性能得到改进，需要应用一些评价指标来判断。

• 选择合适的评价指标，一般有准确率、召回率、F1值、AUC等

 

参考：

1. 吴恩达机器学习课程
2. 论算法工程师首先是个工程师之深度学习在排序应用踩坑总结