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

大模型向量数据库机器学习

心法利器

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

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

往期回顾

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

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

最近一年做了什么

去年有提到,自己在新的环境下,有很多挑战,也收获很多,最近的一年里,在和团队伙伴们的共同努力下,项目逐渐进入深水期,遇到了很多新的挑战。我简单总结一些我这段时间的感受。

  • 项目进入深水期后,很多任务并非简单方案便可快速完成,需要很多基础工作,这些基础工作对产品、业务视角并不可见,如果埋头做,很可能会导致业务方视角没有产出。此时,我这里有两个方案,一个是把这个不可见的任务一定程度转化为可见的,另一个思路就是把这个基础工作打散到日常的迭代里,一点一点带上,就不至于长期没有可见产出。前者比较好理解,而后者则需要比较长远的眼光,提前想到后面可能要做什么,需要什么,提前规划安排。
  • 需要合理权衡好,研究和业务的时间,两者缺一不可。很多时候,我们可能遇到的是,急迫的业务需求,需要赶时间完成任务发版上线,并没有时间去做一些尝试,毕竟最近又是技术井喷的时候,我们不得不去持续做很多学习和实验,或者拥有大量时间去做研究和实验,远离了业务,并不知道什么东西是真正有用的,什么并非实验中的那么有效,走偏了。我们还是需要两者兼顾,不能顾此失彼。
  • 项目发展后,原本的小项目里有的东西越来越多,需要合理规划,例如服务/代码/数据甚至是人员分工的合理规划,大模型资源的权衡,多个服务的并发性能,新老方案迭代的提升等。最近还有些趋势,对于一些为了快速上线的大模型+prompt方案,会被微调的小模型或者其他更轻量的方案给迭代掉。

越发感觉,在项目逐渐迭代的过程,要想把事持续做好,除了要比较扎实的技术积累,还需要更加强的整体规划能力,这个我并不擅长,还需要持续学习吧。

比较重要的经验和感想

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

0
0
0
0
关于作者
关于作者

文章

0

获赞

0

收藏

0

相关资源
IDC 大模型应用落地白皮书
大模型技术已深度融入业务实践,各企业期望其释放更大商业价值。 但大模型落地之路面临许多挑战和顾虑。 如何精准对接业务需求与发展蓝图,制定切实可行的大模型落地策略? IDC发布首个大模型应用策略与行动指南 一为您揭晓一
相关产品
评论
未登录
看完啦,登录分享一下感受吧~
暂无评论