如何优化算法？

xiaozongpeng · 发表于 2021-11-16 16:57

作为搜索排序的算法工程师，面对的业务场景和NLP与CV有很大不同，即使抛出工程方面，在算法模型上也有非常大的不同。下面将搜索模型简称为SE。
首先从模型复杂度上，CV和NLP都相对来说更加复杂，为什么会有这种原因呢？主要在于数据的不同，更精确一些，SE的数据太多，且噪声很大，而CV/NLP模型的数据则相对干净，数据量也少很多。至于工程方面的原因，那不是本质的。
因此我们经常看到各种酷炫的CV/NLP模型，而SE则大多数场景下还停留在wide&deep的框架中。这不是问题，如果SE想要彻底脱离大规模稀疏模型的框架，那可能需要一些比较彻底的改动，而不是修修补补。
本文不会讲述如何设计SE模型，也不会讲述任何已有的，经典的模型，本文对于没有SE实际经验的同学来说没有实际帮助。
简单来说，本文尝试解决这样一个问题，那就是，作为SE工程师，在碰到没有已有方案能够直接cover的问题时，该如何解决。
那么什么是已有方案能cover住的呢？比如想要提升AUC，比如想要引入用户历史行为，比如想要强化难样本学习，比如想要搜索网络结构，这些都有大量的论文可参考，你可以选择从基础的做到STOA，从而凑一下业绩数量的同时，也感受下每种迭代路径的直观效果，也可以一步到位直接跟进STOA进而推进创新。
什么是论文cover不住的呢？很简单，就是那些你没有思路的问题。
本文的目的很宏大，就是希望帮助有一定SE经验的工程师，在工作中提出更多想法和思路，也就是，本文的想法是让你能更容易的产生想法。

这样宏大的目的容易落入哲学，我们不会这样去引导，因为笔者不懂哲学。
相反，我们会虚构一个场景，给出想出解决思路的思路。为了脱敏，这里的场景会彻底的脱离实际，甚至看起来有点假。但笔者认为这不耽误思考。

特征：今天天气，温度，湿度。标签：下雨。学习目的，预测下雨概率。
模型结构：各个特征离散化后映射到embedding，而后embedding拼起来过一个全连接给出概率值。

1. 模型对湿度特征的学习不理想，在其他特征不变的情况下，湿度+1度，概率+0.1，湿度+2度，概率-0.1，湿度+3度，概率+0.2。但我们知道这样一条公理：湿度越大，下雨概率越大。
这里的核心问题是什么？
数据有问题？不一定的，合理的数据也可以让模型学出这个结果（想一下，什么样的数据会导致这个问题的出现。假如我们想归因到数据上，那么需要怎么去验证？）。
  数据太少？相对这个例子增加数据确实可以解决，但假如没法加数据了呢（本质上来说，加一部分数据也只能缓解，只有加上所有可能的数据，才能解决）。
  其实是泛化不足的问题，假如我们懒得去动数据，那么模型上怎么强迫模型知道这个先验呢？我们的特征都不是原始特征了(如果你的模型支持输入原始值，也可以直接用原始值，但原始值有它的问题，比如无法很好的做特征交叉，所以你还是不得不增加离散embedding)，甚至可能会和其他特征做了各种match，这时候怎么在模型中控制呢？笔者有一些自己感觉还行的想法，但想卖个关子，同时也是避免我的想法先入为主成为了另一种&#34;已有方案&#34;，如果大家的感兴趣，会考虑在后续的文章中阐述。
   这里的思考是，其实当你发现这个问题的本质时，就已经开始想着如何去解决了，而这时你提出的方案，就是自己的创新方案了。这看似好像和没说一样，但是想想你平时碰到这个问题是怎么解决的？我观察的大多数同学，除了修复数据外，首先想到的是去除embedding match，使用连续值特征。前面提过，这种方法会损失模型效果。
   作为SE工程师，应该做的不是从故纸堆里找寻接近的方法去挨个试试（当前，前提是已经翻遍了故纸堆发现这些方法都无法解决，这听起来矛盾有点，其实意思就是需要确认这个问题没有已有方案可以解决），而是找到问题的原因，去大胆思考如何解决，我们的模型设计没必要一定和哪些经典模型一样，或者跟哪个方案类似，只要是合理的能解决问题的，大胆的设计即可，破除对模型结构自己想法上的禁锢，也许是作出创新结果的第一步。

更多内容，欢迎关注我，后续会继续更新一些日常思考。

Ylisar · 发表于 2021-11-16 16:59

作为搜索排序的算法工程师，面对的业务场景和NLP与CV有很大不同，即使抛出工程方面，在算法模型上也有非常大的不同。下面将搜索模型简称为SE。
首先从模型复杂度上，CV和NLP都相对来说更加复杂，为什么会有这种原因呢？主要在于数据的不同，更精确一些，SE的数据太多，且噪声很大，而CV/NLP模型的数据则相对干净，数据量也少很多。至于工程方面的原因，那不是本质的。
因此我们经常看到各种酷炫的CV/NLP模型，而SE则大多数场景下还停留在wide&deep的框架中。这不是问题，如果SE想要彻底脱离大规模稀疏模型的框架，那可能需要一些比较彻底的改动，而不是修修补补。
本文不会讲述如何设计SE模型，也不会讲述任何已有的，经典的模型，本文对于没有SE实际经验的同学来说没有实际帮助。
简单来说，本文尝试解决这样一个问题，那就是，作为SE工程师，在碰到没有已有方案能够直接cover的问题时，该如何解决。
那么什么是已有方案能cover住的呢？比如想要提升AUC，比如想要引入用户历史行为，比如想要强化难样本学习，比如想要搜索网络结构，这些都有大量的论文可参考，你可以选择从基础的做到STOA，从而凑一下业绩数量的同时，也感受下每种迭代路径的直观效果，也可以一步到位直接跟进STOA进而推进创新。
什么是论文cover不住的呢？很简单，就是那些你没有思路的问题。
本文的目的很宏大，就是希望帮助有一定SE经验的工程师，在工作中提出更多想法和思路，也就是，本文的想法是让你能更容易的产生想法。

这样宏大的目的容易落入哲学，我们不会这样去引导，因为笔者不懂哲学。
相反，我们会虚构一个场景，给出想出解决思路的思路。为了脱敏，这里的场景会彻底的脱离实际，甚至看起来有点假。但笔者认为这不耽误思考。

特征：今天天气，温度，湿度。标签：下雨。学习目的，预测下雨概率。
模型结构：各个特征离散化后映射到embedding，而后embedding拼起来过一个全连接给出概率值。

1. 模型对湿度特征的学习不理想，在其他特征不变的情况下，湿度+1度，概率+0.1，湿度+2度，概率-0.1，湿度+3度，概率+0.2。但我们知道这样一条公理：湿度越大，下雨概率越大。
这里的核心问题是什么？
数据有问题？不一定的，合理的数据也可以让模型学出这个结果（想一下，什么样的数据会导致这个问题的出现。假如我们想归因到数据上，那么需要怎么去验证？）。
  数据太少？相对这个例子增加数据确实可以解决，但假如没法加数据了呢（本质上来说，加一部分数据也只能缓解，只有加上所有可能的数据，才能解决）。
  其实是泛化不足的问题，假如我们懒得去动数据，那么模型上怎么强迫模型知道这个先验呢？我们的特征都不是原始特征了(如果你的模型支持输入原始值，也可以直接用原始值，但原始值有它的问题，比如无法很好的做特征交叉，所以你还是不得不增加离散embedding)，甚至可能会和其他特征做了各种match，这时候怎么在模型中控制呢？笔者有一些自己感觉还行的想法，但想卖个关子，同时也是避免我的想法先入为主成为了另一种&#34;已有方案&#34;，如果大家的感兴趣，会考虑在后续的文章中阐述。
   这里的思考是，其实当你发现这个问题的本质时，就已经开始想着如何去解决了，而这时你提出的方案，就是自己的创新方案了。这看似好像和没说一样，但是想想你平时碰到这个问题是怎么解决的？我观察的大多数同学，除了修复数据外，首先想到的是去除embedding match，使用连续值特征。前面提过，这种方法会损失模型效果。
   作为SE工程师，应该做的不是从故纸堆里找寻接近的方法去挨个试试（当前，前提是已经翻遍了故纸堆发现这些方法都无法解决，这听起来矛盾有点，其实意思就是需要确认这个问题没有已有方案可以解决），而是找到问题的原因，去大胆思考如何解决，我们的模型设计没必要一定和哪些经典模型一样，或者跟哪个方案类似，只要是合理的能解决问题的，大胆的设计即可，破除对模型结构自己想法上的禁锢，也许是作出创新结果的第一步。

更多内容，欢迎关注我，后续会继续更新一些日常思考。

		自动登录	找回密码
密码			立即注册