心法利器[134] | 算法工作6年经验分享：把活干得漂亮 - 文章 - 开发者社区

心法利器

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

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

往期回顾

转眼又到了写这篇文章的时候，不得不感慨光阴似箭。这是一篇年更的文章，主要讲讲自己一年以来的感受，并分享一些自己新感悟的经验。

先把历史放出来，之前聊过的东西，如果没有更新，我就不重新讲了，否则根本写不过来了。我尽量讲最近新感悟的东西。

比较重要的经验和感想

low和不low

很多时候，我们都会关注某个技术low不low，做的技术是否足够潮，挺多人会因为自己做的事不够潮，不够贴合现在流行的技术而感到焦虑，觉得自己已经落后版本，无论是短期的绩效还是长期的发展，都有很大的压力。

在实践中，我自己其实一直做的大部分活，其实都可以说是low的，例如时至今日，一些搜索的任务，我仍然在用字面匹配以及BM25，文本分类我还会用fasttext、textcnn来试试看，有些任务我也在用prompt快速完成一些活，另外类似xgboost这些已经很老的东西，我现在还用的非常顺手，low的事一件接着一件，但实际上并没有想象中的焦虑，我自己是这么想的。

从low不low的问题，转为适合不适合的问题。时刻需要记住，手里的活核心目标是什么，如果什么“技术影响力”、“论文产出”之类的事，而是把一些功能需求完成，在效果提升为目标的任务里，什么方案适合这个任务，能尽快得到好的效果，就应该使用什么，要对前沿方案理性看待，可以日常学习和理解，要对他有理性客观的理解，但在方案选型上要慎重。我非常理解一些刚开始做算法的同学，可能会对领导给你分配的任务和方法比较抗拒，此时你其实可以和领导探讨，为什么要这么选，有什么考量，甚至可以拓展一下还有哪些方法，为什么不用别的方法，经过这些交流，你能更清楚一些问题背后的思路，对自己的提升也会很大。
自己可以把握这个主动权。领到的任务可能使用并不前沿的方案，如果自己有思路且有时间，完全可以一起尝试，看哪个效果好，自己主动安排更多时间来试验测试，如果效果更好，在条件允许的情况下肯定会采纳你的方案，与其内耗不如主动出击，当然如果效果就是不好了，也得承认自己的理解出现偏差，整理结论积累下来就好了。
low不low一定程度其实取决于自己的思维界限。同样一件事不同的人做就不一样，同样是写prompt为例，这个是写多了确实会烦，大部分人可能只会捏着鼻子继续做，甚至跑路，而有的同学会比较有想法，通过自己prompt积累的经验，沉淀出一些比较常见的模板甚至是构造流程脚本，加快写prompt以及迭代的速度，提升效率，甚至能自动化完成prompt，能迁移到更多问题上，这便也是技术含量，我们都能感知到一些困境，从技术人的角度，我们要尝试去找到脱离困境的模式，这便不low了。
当然，这不意味着我们就要接受他，虽然小的low我们可以解决，但是如果整个职业发展上，并没有给你更多的机会，那肯定还是要脱离，及时止损，例如有些公司就是请你去标数据，后续也只有标数据的活（饼都不画的那种）。

还是鼓励大家多积极行动吧，首先应该排除的是内耗，然后是理清思路明确当前的目标来选型，不拘泥于某些方法是否过时，毕竟是否过时很多时候和最终目标并不无关系，再者自己把握主动权主动去做，还有就是看清大势及时止损了。

不设边界

主动承担或者关注一些和自己相关但超出自己负责部分的事。很多时候，大家都更倾向于把自己的事做好，对我们算法而言，甚至是工程的活都不想干，把模型训好就完事了，但实际上这并不合适，如果想要做的更进一步，还是要把和自己相关的事都尽可能关注到。

作为算法，要把活完成好是需要做大量的实验的，模型训练、调优等，改动很大，找人来专门配合，沟通成本会极高，这些事肯定要亲力亲为，整个模型的开发就不用说了，上下游的一些数据的处理，指标的计算，肯定也是得做的，这个应该是一名算法最基本的技能了。
模型依赖数据，数据从哪来，上游是怎么计算的，模型算完后怎么用，都要有清楚的了解。上游计算的数据是否正确，口径是否对应，是否可能存在空之类的异常，这些都对我们的算法设计有重要影响，至于下游的应用，直接影响我们的设计，下游要什么我们就应该给什么，格式和口径都要对应，肯定不能做完扔那就跑了。
了解甚至多干一些事，能让自己对全局的把控力提高。当我们做一个工作到一定时间长度后，会逐渐成为一个事的负责人，非常自然，如果自己对全局都有很大的把控，那就能用很多操作空间，例如多构造一些特征，多设计一些复杂的算法，上文提到的主动权便来源于此，此时我们能有空间、资源多做些事，也有比较稳定的试验田能开展我们的实验。

全局思维和迭代思维

在文章前面有提到，要去了解自己的上下游，这便是全局思维。我们要从一个个简单的算法，逐渐把视野拓展，形成全局视野，了解系统内各个模块具体在做什么，这个意识和思维都很重要，很多时候能帮助你事半功倍，提升效率，也能帮助你少踩坑，降低试错成本。

所谓的全局思维，主要是这几个层次。

首先就是要有意识，要主动了解整个全局的信息。
详细地，从你自己的模块开始，了解上下游的工作，逐步过渡到整体，甚至是整个项目里你这个模块的位置和功能。
更进一步，从了解到利用，是否有存在一些功能交叉或者相似的模块，能尽可能精简或者互相借鉴，例如用户画像模块可以给其他的预测模块服务，画像模块的信息则来源于各种信息抽取模块。
甚至走在前面，提前设计，然后让自己未来可能需要的东西现在就开始准备，

让已有的东西尽可能能帮到你，提升效率，避免重复建设，同时，让自己做的事在更多地方被用到。

至于迭代思维，则是要把一个复杂的任务拆解，拆分成多个版本计划，一步一步完成。

首先，不能想着所有的方案都一步到位，早期版本尽量用最快、低成本就看得到效果的方案。早期基础工作要做的事非常多而时间紧，我们尽可能把精力聚焦在整体服务开发、特征、数据上。注意，特征数据不行，啥模型都搞不定，所以，别太早上太好的模型，之前曾经遇到过一个情况，太好的模型你和能力过高，数据里的错误也能被学到，此时的错误就会被掩埋，甚至到线上去，所以真的要不就花时间把数据弄好，要不就是离线就提前做好数据验证。
不要想着“憋大招”，第一次就上很可能比较厉害的模型，诚然弄出来了可能会有很高的收益，但是如果弄不出来，就意味着前段时间白干。
需要资源多且短期内不好做的方案，并未当下不做，而是在后续具备条件后，再来开展，如果真的有必要做，则最近先开始准备资源，例如日志数据的积累，特征工程等，类似推荐系统，早期什么用户画像都没有，真的不好做。
虽说要放后面做，但不能无限推，在往后推所争取到的时间内，我们必须有计划地安排准备，数据、特征、工程，尽快到位，然后就能上我们心心念念的模型了。

有一个比较特别的情况，就是大模型的模式，最近发现好多这个迭代思路的，大模型的下限是比较高的，所以早期用prompt+大模型的模式，甚至是32B、72B更大的模型，通常能很快得到baseline甚至上线，后续技术迭代，有数据微调后，就可以换成更小的模型，7B甚至到bert的级别，可以试着追追上限，大模型毕竟太贵了，哪怕一个任务一个模型，10个1B的模型也比32B的大模型划算，更别说更小的模型了。

新知识的淡薄

这是我自己在最近几个月感受很明显的事。Deepseek模型出来的时候，我自己感觉就是一次正常的迭代更新，有了一些新的技术工具，我会在后续的工作中平等地参考使用（心法利器[129] | deepseek-R1自测效果分析和选择建议），然而很多人会认为，这次技术是惊艳的，充满了热情，尽管我会学，但我好像对这些东西没那么激动了，当然了，也并不会焦虑。

继续Deepseek这个事，有了新模型，很规范的思路，跑case，分析对比，当然会有目前已有模型的结果，例如早一些发布的qwen2.5，对比下来就会发现这里有问题，哪里有问题，最终指标Deepseek的效果还是比不过（心法利器[129] | deepseek-R1自测效果分析和选择建议），结论是他可能有更适合他自己的场景，于是好好学习然后把他放到武器库，就完事了，惊艳，完全没有。

我自己思考的原因，是因为我先前看到的太多，从而感觉技术的变化非常正常，我大概是16年左右开始接触机器学习，NLP应该还要晚一两年，tf-idf+ml的模式开始经历至今，历经了ml、word2vector、elmo、bert、llm等多个版本技术更新，大模型从23年开始到现在其实也更新了好几代，模型能力确实在逐步完善，在技术革新了这么多版本后，我对新的技术出来，总觉得会是正常的迭代，我通过快速的学习和跟进能很快学到，然后就成为一个我的武器库内很普通的一个工具了。

如果只是学完就完事，那并不会有什么影响，但在信息和知识爆发的时代，这种淡泊可能会让我对发展方向的感知变得迟钝。举个例子，在我的视角下，因为我对我在搜索方面的能力还比较有信心，此时我看RAG下的很多技术，其实都会是重复的，类似意图识别、改写、向量召回啥的，因为都是老技术而可能会让我疏于学习，因为这些技术我都比较熟悉，现在很多看起来很新的论文往前翻很可能只是“换汤不换药”，此时，这种感官会让自己放弃在这里深入学习，便会从中错过很多迭代更新的细节方法，例如self-consistency等新技术，能让同一类任务变得更简单、更优秀的方案，早年以搜代分的方案（心法利器[60] | 以搜代分的生效机理）在一些场景下我一直用的很好，但大模型时代，给我提供了一个复验的机会（心法利器[114] | 通用大模型文本分类实践（含代码）），在使用大模型后，效果会有新的提升。

再举个栗子吧，Agent里的路由，在一些比较简单的任务里，就是识别query的含义然后去调用不同的工具进行分析或者执行，我会很快把他和搜索里的“意图识别”联系起来，甚至是“文本分类”，初看便会觉得很失望，就是换个名字重新营销一遍的套路罢了，但只有深入学习，才知道，他甚至可以有planning，可以是结合更多信息的决策（对了，这个其实就更像多轮对话的dialogue policy），可能会有不同的理解。

这个问题，最近挺让我感到苦恼，不知道有没有大佬也遇到类似的情况，可以一起讨论排解一下。我目前的思路是，逼着自己学进去，就当复习，也尝试从中吸收一些新的思路，说实话收获肯定是有的，但是反馈感不是很强（很多时候学完知道了，但是到了应用阶段该用啥用啥），边际收益也不高，想看看大家有什么更好的思路。

大模型工作

现在是大模型的版本，还是想简单提一提。很多人可能会觉得做大模型的工作很酷，更有甚者可能会对“训练大模型”这个事有很高的期待，但现实是，并非如此，我来说几个情况。

对于训练大模型基座的工作，首先，基座模型，现在基本已经被几个大厂给统治，大家应该都懂，自己训的可能会有一定收益，但并不一定那么高，想让别人用到你的模型，还不那么容易，很多人图方便就直接用那几个口碑好的通用模型，自己捯饬捯饬就能上了，那你就是白忙活了；如果是不太在乎别人的使用，更关注自己把效果做出来的成就感，那就要注意，数据的清洗，也是很枯燥的，训练要好长时间，等个一天两天甚至半个月完事后，一出来效果不行就等于白干，别以为每天都有时间还模型结构、训练策略，有些小厂还要考虑性能、负载之类的事。

如果你是做应用大模型的有关工作，那就不得不提很多人嗤之以鼻的写prompt了，大部分情况，你这里根本没有模型，而只有一个冰冷的API接口，你通过调用它来得到大模型结果，你只能调整你的prompt，训练模型根本不存在，扎心的，你的代码，不用装pytorch就能跑起来。好不容易能微调，试试身手了，资源要省着用，数据依旧不行，可能你写的一手好的训练脚本，但和弄基座模型的同学一样，效果不好，又要开始分析数据，清洗数据，模型是改不动的，策略是不会写的，就是调用llama factory，久而久之，仍旧是洗数据。

此处也并非是说这些活不好，而是，要让还未正式工作的大家认清现实，认清可能要面对的东西吧，这是常态。任何事都可以是枯燥的，要自己多尝试从中找到热情和反馈感，会支撑你持续走下去。同时，别“只会大模型”，别的都不学，拓展自己的知识库，不去纠结low不low，好的就去学，有利于你能应对各种问题。

把活干的漂亮

小时候看《铁甲小宝》，蜻蜓队长的登场台词：第一，绝对不意气用事，第二，绝对不漏判任何一件坏事，第三，绝对裁判的公正漂亮。这里的漂亮，便是想指的这个，相比原来要求的“完成任务”，我希望对自己有更高的要求，自己也在努力。

以更低的成本（时间、资源）等，完成具体需求。如果特殊要求，我对方案的选型是没有什么执念的，例如“大模型”，我只会考虑更加适合当前任务下最适合的方案，大模型在这里只是一个平等地备选方案。
可靠，尽量不出现特别不稳定的bug或者bad case，无近忧。服务稳定，类似超时之类的不稳定因素尽可能排除，模型层面对于高频严重问题也会用更加稳妥的方式来控制，这是对一名工程师的基本要求，这意味着我可能不会很冒险地采用不成熟的方案。
无远虑，尽量没有长期的坑，做好长远规划。脑海里有未来成功的样子和目标，虽然短期内不具备条件，但是会逐步积累到具备条件的时候，然后落地应用。
技术亮点和特色会尽量保持。前面我只说到，不会因为技术新而去用，同样地，我也不会因为技术新而不用，前沿技术的储备依旧会保持，在情况合适的时候我再掏出来使用，逐步形成技术亮点、技术壁垒。

这是我持续努力的方向吧，与大家共勉。

picture.image

心法利器[134] | 算法工作6年经验分享：把活干得漂亮

最近一年做了什么