算法技术设计思考：迭代的思维方式

这次也算是试试水，做一次尝试，写一下日常方案设计过程中的一些方法论，看大家是否感兴趣，如果喜欢我会多写点。

在这里，我先把这个“迭代的思维方式”展开解释一下，我这里是指，对于一个任务，在并不容易一次性解决的时候要把他拆解成逐步推进各个击破的长期任务，至于这里怎么拆，如何设计和推进，看我后面慢慢解释。

思路的来源

最近是在做一些大方案的技术设计，在设计过程汇总，会发现很多很好的方案，在现阶段可能并没有很好的落地条件，总结下来，包括但不限于下面原因：

• 数据层面的基础工作不够。现实上，缺少标注数据，某些数据尚未积累，数据表还没建立，某些数据甚至还没打通，理想上的数据理解尚未到位。
• 工程技术尚未成熟，某些算法工程做需要依赖工程支持，除了上面可能有涉及的埋点，还有类似AB实验工程、某些用户行为方案没上线、机器资源等。
• 大而复杂的模型，影响因素过多，可能会出现众多的问题，模型结构、数据集、训练、测试等，出现问题后难以定位，直接上线的成本高。
• 当下问题的现状，复杂模型或者方案下，能解决的问题很多，他是解决综合问题的一个组合解，并没有那么对症，然而在现实中，我们需要了解到当下环境的核心痛点，因地制宜（这个词我好像也在公众号里反复提到过），才能更高效，也更有利于推进解决问题。
• 人的问题，合作起来存在一定困难，分工难以平衡，设置可能会影响一些人的利益（如工作被合并），从而出现困难或者未知风险。

在这里列举下来，也是希望大家能够理解这个迭代思路的核心来源，让大家在设计方案时能够更留意到这些问题，以便进一步推进。

因此在项目实施过程，直接把一些现行看到的很好的方案直接落地，而需要有计划地拆解，找到合适的切入点，逐步迭代完成最终的落地实施。

概述这个思路的核心点

这只是一个比较宏观的方法论，在运用过程，要注意的部分我先列举出来，然后后面逐步展开解释。

• 明确最终愿景和形态。明确适合这个场景的最终方案。
• 了解现状。现状是一个广义概念，里面包含的东西很多，项目现状、资源现状、研究现状等。
• 以痛点为出发点，配合现有资源的情况，开始初始方案。
• 方案的设计，除了要求解决当下痛点，还要考虑逐步满足达成最终方案的条件。
• 维持稳定增长的技术储备。

我理解的核心点就是上面这些，后面我会逐步展开解释。

明确最终愿景和形态

这里强调“最终”，就是因为我们需要一个最终的目标。目标的重要性已经在管理学、哲学等多门学科里被强调多次重要性，在这里，也仍旧需要强调。

这里的最终愿景要明确清楚，可以通过回答以下问题来实现：

• 你做的是一个什么项目，最根本的是要解决什么问题，有什么评价标准
• 要完成这个项目，目前比较前沿或者理想的方案是什么
• 由哪些部分组成，每个部分的职责是什么
• 这几个部分下的常用方案是什么
• 每个部分是怎么协同的
• 逐步拆解这个方案内部的内容
• 为什么要选这个方案，优缺点是什么
• 要达成这个愿景，需要什么条件。

最后这点，“要达成这个愿景，需要什么条件”非常重要，这是我们后续要逐步迭代的一个重要线索，我们设计的每一次迭代，除了要满足每一步所遇到或者遗留的短期问题，还需要把愿景中未满足的条件给满足了，才能最终达成我们的愿景，所以，最好盘点出来。

了解现状

了解现状是现实工作中非常重要的步骤，在新接触一个项目时、要做方案升级时、逐步迭代过程中都非常需要，而且“现状”一次的概念也非常广，重点在于，要了解哪些现状，对一个算法技术设计而言，主要有如下方面：

• 目前是否有使用什么算法方案，这个方案的效果如何（指标），使用的什么测试集
• 从bad case分析反馈而言，目前有什么问题，重要程度如何（问题占比）
• 用户角度的问题有哪些诉求。（此处注意多沟通挖掘）
• 该方案目前的SOTA和口碑比较好的方案有哪些
• 制约方案的因素要了解清楚。
• 上线需要多少耗时、并发，有多少机器资源（CPU核、内存、显卡型号显存等，涉及数据库中间件还有硬盘大小等）
• 能支持提供多少的训练数据（无论是挖掘、自动标注还是人工标注，盘点清楚）
• 排期时间。简单的，2天能做的事和10天能做的事肯定不一样。

能尽可能理清这些问题，大概率就能对现状有个比较清楚的把控了。

初始方案的设计

算法设计

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

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

工程设计

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

• 算法模块在整个流程中的角色是什么，上下游接口怎么样。
• 数据流是怎么走的，需要确认，包括离在线，搜索系统的话不仅考虑用户query等信息，还有物料的信息怎么存储，另外如果个性化，还有用户画像的数据问题。
• 中间件的使用和维护，如常用的数据库mysql、ES、redis之类的，还有些类似kafka、hadoop全家桶之类的。

另外，补充一块比较重要的内容，那就是要逐步满足最终愿景所需要的条件。在最终方案中，往往需要更多的资源和基础，例如需要埋点数据、需要基础的工程支持、需要特定数据的积累，甚至有些坑是需要提前踩的这些事，我们是可以通过前期的方案设计，把这些内容带上车一起推进。

举个例子，我们要构造完整的搜索系统，我们要有NLU、召回、排序，早期一蹴而就并不可能，但是类似召回需要的中间件、或者是用户点击之类的反馈信息，那我们完全可以在早期就提前安排，尤其像埋点这种，很早就可以安排，并行推进的，就可以在尽快安排上线。

维持稳定增长的技术储备

持续学习肯定是非常有必要的，我们往往会纠结于学习方向是什么，而在结合项目的进展持续深入学习则是一个很好的方向。

要设计方案的前提，是手里有足够多的牌，如果手里就没什么牌，轻则找不到很优秀的方案，重则无从下手，时常和朋友聊起的很扎心的话：

• 你不会除了微调没有别的方法了吧。
• 现在让你微调了，你不会还微调不好吧。

所以维持稳定增长的技术储备是非常有必要的，大到整个框架愿景，小到每个部分，都值得持续调研学习，看论文、看分享、分析具体场景的case，都是常用的学习提升更新方案，慢慢你就会发现自己在这个领域逐步得心应手了。

案例

在这里，我提供一个案例来体现这种迭代思维。

现在手里拿到一个产品需求，是要为一个场景做一个知识类的搜索系统，面向的用户主要是专业人士，做专业知识的查询。目前已经有一些业务方提供的知识库，非结构化的书籍材料，由于是新产品，所以暂时完全没有用户日志数据。

要做成完整的搜索系统，肯定不是一蹴而就的，确定好目标和规划，按照计划进行即可。

首先对于最终形态，还是比较明确的，就是构造架构比较完善的NLU、召回、排序模块，内部结合用户搜索习惯和知识库情况划分好模块分情况处理，配合大模型的RAG能力为用户提供最精准的知识查询服务。

显然这里并不能全部立刻完成，这里有几个核心的痛点需要优先考虑开展工作：