心法利器[56] | 算法技术设计思路小结

心法利器

本栏目主要和大家一起讨论近期自己学习的心得和体会，与大家一起成长。具体介绍：仓颉专项：飞机大炮我都会，利器心法我还有。

近期，我再次总结了我的历史文章，累积起来有50w字，百余篇文章了，有兴趣可以拿来看看，获取方式：七夕清流，百余篇累计50w字文章合集发布。

往期回顾

• 心法利器[51] | 长短句语义相似问题探索

• 心法利器[52] | 口语化句子解析问题

• 心法利器[53] | 数据增强的现实应用思考

• 心法利器[54] | NLP任务上线前评测

• 心法利器[55] | 算法工程师读论文思路

随着工作逐渐深度，无论是对算法技术，还是对业务场景，都已经有了很高的熟练度，所以自己逐渐开始进行各种算法的技术设计。今天我就来聊一下我在算法技术设计的思路经验吧。

之前好像也有简单聊过，我是写完后才想起来的，不过对比起来好像更成熟一些，大家也能传送过去看看（心法利器[25] | 如何做技术设计）。

下面其实就是我思考的思路，大家也可以跟着我的思路走走看。

为什么要做技术设计

凡事预则立，不预则废，在真正做一件事之前，我们需要有良好的规划，才能把事情真的做好，技术设计的流程本质是希望能把一些问题考虑到位，你能很清楚自己要做什么，要关注什么，最终能更容易达成。更极致的技术设计是做完之后，你能直接上手干活，按部就班就能完成这个任务。

明确问题和目标

对每一个版本和需求，我们首先需要做的都是确定问题和目标，即我们需要解决的问题是什么，这个的重要性我应该在很多文章都有所提到，问题和目标不明确，后续的所有工作都是徒劳。那我们来盘点下，目标可能会有哪些方面：

• 上一版本遗留的问题，那这个版本就需要解决。

• 产品或者其他提出的功能需求。

• 算法效果的需求，例如准确率召回率双90%。

• 其他的优化要求，例如要求原来好的结果不能变差。

• 工程上的性能需求，这个很隐性，但是有经验的算法工程师都需要关注。

• 代码和架构上的需求，例如一些可拓展性、可维护性的需求。

诚然算法更多就需要关注算法问题，但是算法问题并不会独立存在，因此我们不能够独立地处理算法问题，我们需要考虑的应该更多一些。

现状和资源的确定

抛开资源谈解决问题无疑是不现实的，我们需要针对问题，看现在有什么资源，再来设计方案。

对于算法而言，需要关注的比较敏感的资源是这些：

• 数据。算法，尤其是用到深度学习的算法，对数据是多少一些需要的，至少要有评测集吧。

• 机器。算法的执行依赖及其环境，如果机器环境不好，例如内存不行，没有GPU，那我们是需要考虑更加轻便的算法方案了。

方案调研

解决问题的方案总是不会那么唯一，局限的从来不是方法本身，局限的是人，所以我们在进行方案设计的过程，建议还是先进行相对比较完整的技术调研。大家可以根据这几个角度去看。

• 这个方案的baseline是什么，最简单和快捷的方式是哪些，都有什么优缺点。

• 大厂常用的方案是什么，有没有什么特别地操作，为什么要做这个操作。

• 论文，科研界的主要方式是什么，需要关注哪些方面。

要找的话，看论文、搜百度谷歌、搜知乎，首先学会自己尝试找到解决方案。

在技术调研的过程中，我们应该可以知道很多思路，同时也有一定的成长吧。有这些内容的支持，我们可供筛选的方案会很多。

技术方案的筛选

有了上面的一系列操作，其实有关怎么做这个事情上已经有了一些答案了，这一步是为了整理思路，并且细化自己的技术方案。

• 各种方法会有什么优缺点，与现有资源是否匹配。

• 时间上的效率分析。

• 开发难度和风险，考虑下是否会出现类似在线问题、项目延期等风险。

• 和上下游对好接口，确认接口协议，有些数是否好给，例如用的规则，类似打分的方法就要仔细考虑下了。

这些是我们要考虑的。为了简单，我仍旧以文本分类任务作为例子介绍下，例如搜索场景的意图识别，我们要做的是开放域下某一个类的识别（这个问题其实之前我有详细讨论过：心法利器[48] | 开放域文本分类技术思考），方法手里有很多，有规则词典这种简单但高准的方式，有以搜代分检具灵活性和强零散分布处理效果较好的优点，还有一系列我们熟悉的文本分类模型，从简单到复杂的fastext、textcnn、bert分类等等，那我们的选择一般是这样：

• 数据越少，越不建议用模型，尤其是是复杂模型，一定要给评测集留数据，训练集可以少，但是测试集一定要有而且质量高。

• 计算机资源越少，也不建议方案内有模型甚至是大模型。

• 泛化需求越大，越建议用模型，这个主要看场景下的query都是什么样的。

• 越是频繁更新，也不建议首先考虑模型，规则词典、以搜代分都可以考虑。

• 越是对字面意思要求高，模型复杂程度拉开的距离越小。

方案的详细设计

有了基本的思路，我们就可以开始考虑详细设计了。我这里分算法和工程设计来讨论下。

算法设计

首先是数据，模型训练的数据，最终结果评测的测试集，必要时候的词典，怎么来，怎么保证可靠性，预估数量。这里还需要考虑是否要在线更新，如果有的话，还需要设计在线实时更新的pipeline。

然后是算法，离线的计算流程是什么样的，模型的训练策略，结果评估方式，然后是在线模型怎么上线，以搜代分的话搜索模块用什么方案，灌库的方式是什么，根据更新频次设计更新方案，多个算法方案如何协同，这些都要考虑了。

工程设计

工程设计则是需要考虑大量的工程信息。列举一下，感觉不是很全，但是得考虑：

• 算法模块在整个流程中的角色是什么，上下游接口怎么样。

• 数据流是怎么走的，需要确认，包括离在线，搜索系统的话不仅考虑用户query等信息，还有物料的信息怎么存储，另外如果个性化，还有用户画像的数据问题。

• 中间件的使用和维护，如常用的数据库mysql、ES、redis之类的，还有些类似kafka、hadoop全家桶之类的。

所谓详细，就是要把怎么做都写出来，考虑清楚，这样子详细设计才足够详细。

小结

这是我可能不太成熟的技术设计思路吧。这个东西指导了我做了不少东西，后续可能还会逐步优化这个流程，往里面加更多东西，让事情的处理能更加完善完整。