心法利器[139] | 算法方案设计：我的规范化框架与避坑要点 - 文章 - 开发者社区

心法利器

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

2024年新的文章合集已经发布，获取方式看这里：再添近20万字-CS的陋室2024年文章合集更新，更有历史文章合集，欢迎下载。

往期回顾

有关方案的设计，我在前面零散的聊过不少，要说比较系统地从头到尾的思考，那就要更早了，而随着时间变化，自己的技术和现在的技术环境已经有比较大的变化，最近花了点时间，重新梳理自己方案设计的思路，和大家分享。

之前聊过方案设计思路的文章，我放在这里。今天的文章，会和这些内容有关，但会更加系统和流程化吧。

为什么需要算法设计思路框架
算法设计的主要流程

明确需求和目标
现状和资源的盘点
方案调研与选型
风险评估与结果指标设计
长期迭代必要性

后记

叠个甲，方案设计的流程里很多事每个说起来都简单，实际上做起来也并不复杂，讲这个的过程更多是希望和大家交流细节吧，很多细节做没做到其实对最终的效果差异还是挺大的。

为什么需要算法设计思路框架

首先，项目需要。要把事做好，都需要有一个角色去做执行方面的统筹，要知道“怎么做”。简单的活固然可以拿到手里就干，例如处理个数，跑个模型啥的，很简单，但是问题变新、变大、变模糊，思考起来就不那么简单了，“产品搜索系统”，“客服机器人”等等，都不那么容易。

第二，实际的算法任务，但凡做过多一些项目的大家都知道，最终的运行效果是不稳定的。而在项目进行过程中，一旦有了效果不好的情况，那很可能项目的时间就会很紧，如果路线错误，例如大模型效果还行但是成本根本压不住，那压力更大了，在早期选择一个好的方案，我们能少走弯路，降低风险，提升效率，确保项目实施。

第三，能更快更早地发现很多项目流程可能有的问题。在思考技术方案的过程中，我们要考虑数据、机器成本、耗时、后续效果评估等多个影响方案设计的模块，在思考这些问题的过程，我们通常能考虑到很多需求、定义层面的问题，例如数据够不够，预期效果是什么，后面怎么衡量好坏，兜底等细节问题，问题可以搁置，但得先发现。

第四，思考解决方案对自己的技术能力提升也有巨大帮助。思考能让自己对具体业务和实施有很深的了解，技术调研能拓宽自己的知识面学到新的知识，结合后续的执行和实验，自己对方案的认知也会有明显的提升，最重要的一点，各种思考都能形成这一套方法论后，自己便能成为一个能独立作战、独当一面的兵，甚至是带领小队走向胜利的队长，至少技术层面的带路方向是足够的，因此对晋升也有很大帮助。

因此，我们需要学习如何设计算法方案，甚至需要一个比较完善的思路框架，引导我们去执行。

算法设计的主要流程

整个算法设计的流程，我主要分为以下几个部分。

明确需求和目标。明确当下需要做的事情是什么，具体要做成什么样，有什么要求和前提，最后希望达成的目标是什么。
现状和资源盘点。盘点现在的现状，有什么可以支撑当前任务的达成，还缺少什么，确定需要补充的内容有哪些。
方案调研与选型。调研有关任务目前有没有什么比较常见或者前沿的方案，结合自己对业务的理解，进行合理的选择。
风险评估与结果指标设计。深入评估方案可能存在的风险，并给出一定的规避或者解决方案，同时设计好最终衡量结果好坏的关键指标。
长期迭代必要性和思路。不满足于当下，结合现状分析查看当前方案能解决问题的程度以及潜在漏洞，给出后续需要长期迭代的必要性分析和具体的迭代思路。

明确需求和目标

明确需求和目标的这个事，更多是需要我们和需求方进行沟通，除了面对领导外的其他人，很多时候可能都需要非技术人员，他们多半对技术细节并没有很多了解，此时只能基于他们的想法来沟通，我们也要给予我们的技术理解给出特定的解释，两者的思路逐渐同步，便能把整个需求给说明白。

在这里，我给出在这个阶段最核心的考量点。

关心需求来源和背景，尽量弄清楚这个需求做完后的产出在后续是怎么用的。这个信息非常有利于我们理解这个需求，在很多时候人在面对问题的时候会下意识去考虑解决方案，然后再把自己想的解决方案当做是目前的问题来解决，有些看似不合理的需求是在这个原因下被提出，我们去了解背景，更多是直击需求本身了。
明确最终预期的输入和输出，在NLP场景挺常见的，输入的是什么，输出的又是什么。
明确边界，可能存在的一些交叉或者异常情况，该怎么处理，尽可能覆盖。例如问答机器人预期要回答哪些问题，领域外的或者领域内未无答案的该怎么处理要明确。
技术路径，有些业务可能会对技术路径有要求，尤其是最近大模型的环境下，很多业务有“使用大模型”的政治任务，这个会对技术选型有一些约束。
成本和性能要求，也要纳入需求的讨论中。有些业务可能预算不足无法上大模型，有些业务的在线性能要求高，这些要提前沟通好，之前见过最容易翻车的就是在线性能要求这里，要尽早给需求方一个预期，大模型的耗时大概是在什么范围，否则到时候真的很容易扯皮。
目标达成的判断标准。虽说后续可能还有结果指标设计，但这一步是和需求方的沟通，看业务关心的实际内容是什么，明确最终的验收方式，不至于让我们南辕北辙。

现状和资源的盘点

任何事要做，都要基于现在这个情况开始做的，哪怕是开荒，现状也是“啥都没有”，我们一定要对现状有一个比较初步的认识。而要理解现状和资源，可以尝试回答以下几个问题。

现在是否已经有比较完整的服务框架，是否需要从头搭建，基础服务、数据工程、结果评测体系。
这个需求的达成，是否会对其他已有的内容造成影响或者构成冲突，如果有需要怎么解决。
有什么前置的基础条件，例如服务需求、数据等，这些条件是否已经到位。

补充说，这个条件会比较笼统，包括数据的说法，以前我看的比较多的是推荐系统，但是早期的推荐系统，很多时候压根没有用户信息，都是0，这就不太适合构造推荐系统，毕竟“个性化”无从谈起，可能需要花点时间来进行挖掘和实验，甚至可能早期的版本更多不能考虑个性化而是考虑新热之类的内容了。

预判可能会用到啥技术，这些技术所需要的机器（唉，可能确实是我的穷日子过得太多了，风格偏抠）资源如何，是否有标注资源等。
我们手里目前是否有类似任务的积累可以直接使用（这个还挺重要的，团队积累可以提效，也可以减少走弯路）。

这些问题回答好，就说明目前已经对项目目前的现状有足够的了解，这些信息很可能是我们后续执行过程中的限制，在这些限制面前只有两个选择，突破和控制，即考虑突破这个限制，创造条件，以及就在这个约束下，把这个事办好。

方案调研与选型

尽管我们做的各种技术通常来源于日常的积累，但我还是建议大家在实践过程，还是抽点时间去做做调研，包括但不限于这些方向。

问题所属的场景下，都有哪些方案。拓展的，该场景下还有哪些常见的问题，他们都是怎么处理的。
问题抽象，形成具体的任务，调研对应任务尤其是NLP场景，其实来来去去都是那几个问题，归纳后进行深入调研学习。
了解目前的数据情况，尤其是他的特点、难点来进行调研，了解有关的数据类型有没有什么特别方法。（PS：在真的开始调研之前）
对于一些评价起来比较困难的任务，可以通过调研的方式了解有关任务的一些评价方法。

补充，这里不要局限在“新”，在实际项目过程中，可靠和稳定才是最重要的，因此相比于新，我更建议大家多看看被大家反复验证可靠的方案，最直接的便是经常被引，在论文里经常出现的方案，尤其是在实验里被当做baseline或者”被超越“的方案，一些能被反复当做对手的方案，很大程度上说明他是这个领域的”统治者“。

至于选型，有这些思路，在这些思路下，应该会有优势选项浮现。

结合目前现有的资源，比较容易形成卡点的是数据和机器，来进行选择。例如数据少的，得把不训练或者少样本训练的方案纳入考虑，严守测试集数据量的底线。
优先考虑自己比较熟练的方案，熟能生巧，一般自己熟练的方案出现风险的概率就会比较低。
自己都不熟练，那就找业界或者被身边的人被反复使用并验证的经典方案。因为他已经被广泛验证，后续实验除了问题，能少一个问题点研究，我们一般不用换怪罪于模型不行，更多是数据等外部因素出现问题。如果是要迭代升级，那再再模型层面去做优化即可，那就需要进一步进行调研了。
端到端可能最好，但是过程可解释、可调整的方案最稳，那种“每一步都做的不错后最终结果差不到哪去”的方案，在时间紧的项目下会更可靠，后续再寻找契机将其结合形成更泛化的端到端模型更好。

风险评估与结果指标设计

居安思危，即使是很简单的项目，我们还是得尽可能多的去考虑各种风险。

影响项目推进的风险，这个也是我们日常最需要关心的风险，例如数据不足，模型效果不好，机器配置不到位，工程问题，需求理解可能不透彻等问题尽可能去排除。
项目安全风险。比较常见的，用户信息泄露，用户敏感问题风险，大模型的输出内容风险等，这些可能导致项目甚至公司直接没了的风险，得严格控制。现在的大模型普遍都比较安全了，但还是建议大家多留个心眼，尤其是有用户输入自由文本的场景，多做一些控制可能会更加合适。

然后是结果指标设计，前文有提到，在需求沟通阶段我们需要考虑交付标准和结果指标的问题，此处我们要再进行重点设计。

在手里已经有明确方案的情况下，尤其是已经被拆解为多个小任务的情况下，还是建议大家稍微监控一下每个小任务的完成情况，一方面了解各个模块的完成情况，明确分析短板，另一方面也提供后续优化的方向，是不是有哪些任务始终做不好，可能要调整方向思路了。
业务层面很多指标可能无法离线评估，例如推荐系统的点击率、问答系统用户的点赞率等，但是离线我们就要设计出类点击率预估的ACC、AUC，问答系统至少得有问答内容准确率等，这些是和实际业务指标基本同向的算法或者说是技术指标了，这些指标不差，那在线大部分情况不会有很大的问题。
注意测试集，测试集我喜欢分为两类，一种是和在线分布基本一致的测试集，用来提前预演在线的实际表现，另一种是针对某个问题，专项构造的测试集，例如长难句的分类问题，例如新用户的点击率预估，再例如问答系统兜底回复的测试，一般情况我们可能更加关注前者，这是大盘的基本情况，早期的核心目标，在项目后期，这个集合更像是一条底线，后面的所有修改都不能让这条底线有变化，后者则是在解决专项问题时的一种检验，验证自己对该问题的解决情况。
另外，除了本次需求，还要对那些可能会因为做这个需求而影响到的模块进行测试，在专业测试的角度，这个可以叫做回归测试吧。说白了就是要对以前的功能进行回测，新需求的修改要最大限度地降低对以前任务的影响。

长期迭代必要性

随着经验的逐步积累，自己可能在方案的选型上对最前沿、最新的方案没那么狂热，但是终究是希望本着那个方向去的，毕竟这是一名算法极客的浪漫，但受限于现实情况，我们不得不选择一些最适合当下环境的方案，毕竟把事最好才是最重要的目标，这点和做美术设计的业务与做艺术品创作存在差距是类似的。然而，从终极目标角度，要本着最上限的效果去，我们肯定还是要和前沿方案接轨，去试错，尝试一些比较新的方案看有没有效果，后续的实验和迭代便有了意义。

具体怎么拆，怎么迭代，这个我可能还没法总结出比较完整的思考向和方法论吧，这个我还得持续思考和进步才能逐步领悟。

后记

重新梳理后，感觉整套流程更加饱满了，执行起来也更加扎实，当然也有很多残缺的部分，这些我还会继续补充。

另外，这套方法论下，后续我还会准备一些案例，后续通过这些案例的讲解，我相信大家会对我的这套思路有更加深刻的理解，敬请期待。

picture.image