心法利器[145] | 论文VS应用：算法工作的理想与现实，差距究竟有多大 - 文章 - 开发者社区

心法利器

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

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

往期回顾

日常的很多沟通中都有留意到，很多人对算法的论文研究、应用算法工作都存在很多理解的误区，包括但不限于这些。

论文研究这么多算法，为什么不能都用到实际。
明明论文里已经有这么多算法了，甚至还开源了，为什么做个需求还需要那么长时间。
论文算法已经被验证这么强了，为什么到了实际效果却不尽人意。

可以看到，论文算法和应用算法之间存在很大的分歧，而无论是论文还是实际的业务应用，我都有不少经验了，所以应该有一定的发言权，今天给大家对比一下，让大家更好地理解这些差别。

叠甲，我目前已经在应用算法这个方向时间比较长了，虽然很久以前论文写的也不少，但现在确实已经是应用算法的形状了，很多讨论都比较像是应用算法的视角，聊的也会比较多，并非贬低论文算法哈，只是两者的目标和倾向性不同，没优劣之分，我们需要的是互相理解，合作共赢。

论文算法和应用算法的概念

要分析两者的差异，首先需要知道这俩分别是什么，我在这里明确一下。

所谓论文算法，简单的说就是论文里的算法。论文的核心目的是为了分享研究发现，在学术界，将自己的可靠想法分享出来的一个重要媒介（当然，也是研究组织，尤其是学校科研组织的KPI），这里强调的可靠，是指经过可靠的理论推理，或在特定环境中，有严谨、准确的实验下得到一个结论，同时还强调创新，要和以前的工作存在差异性甚至“亮点”，这才有发论文的意义。举个例子，最近的kimi k2的论文（https://arxiv.org/abs/2507.20534），内部有完整的思路以及严谨的实验，同时内部还强调了他们所做的突破性或者创造性的工作，对于已有的，相对趋同的部分，顶多是通过引用文献的方式提及就好了。

应用算法，是指在实际应用中，设计合适的算法方案解决一个实际业务场景的问题，他的核心目标是解决实际问题，这里强调解决，特定问题有一个解决的标准，当达到某个程度，问题被解决了，那这事就算完整了。

论文算法的特点

现在AI领域，或者说是大模型领域的论文，也已经基本比较成熟，有一套完整的分析方法论。

现在这个领域一般的论文思路大概就是这样的。

Introduction。论文的研究背景，目前大家的研究重点，以及目前对有关问题的研究现状，是否存在什么漏洞、或者盲点，最后引出本文的研究思路概括。
Methodology。论文所提新的算法，论文的核心创新点和具体工作，部分论文会提供对应的理论推导证据。
Experiment。结合数据的实验，这里会讲明白数据来源，实验方案和论文中提及的方案的细节，关键参数等，然后给出实验结果，并对实验数据进行分析，得到最终论文的结论。在咱这个领域，这里更多是验证本文提出的方案的可靠性，以及探索本方案中起到重要作用的部分（消融）。
Conclusion。结论，总结本文提出的算法，补充实验中的发现，归纳成成本文的主要贡献，有些论文还会在这里提及一些展望。

从整个行文中，我们会发现，论文算法通常有如下特点（相比应用算法）。

强调创新。诚然，如果内容不是新的，那论文将毫无意义，但在实际操作过程中，过分强调创新往往会把其他因素给忽略，例如实用性等，此时的“研究意义”就很有难度，很多顶会或者期刊被吐槽为“故事会”，有一部分这个原因。此处并非说创新不对，因为实用性这个概念是有时间属性的，过去没用不代表未来没用，新的想法往往会激发新的思路，形成新的研究方向，甚至是很多新的领域的基础。
论文的切入点大部分都比较小。由于篇幅、实验等的原因，很大部分的论文，尤其是会议或者是期刊的论文，由于篇幅限制，他的核心创新点都只是一个很小的部分，只为了解决一个小问题，实验过程也重点在这部分对比，实验在这个位置的差异下，会有多大的影响，从控制变量法的角度，除了这个位置之外的其他位置，就都得一样。当然，也有一些论文可能是从系统层面的大更新，例如前段时间我分享的这篇论文（MemoryOS：前沿重器[67] | 北邮腾讯MemoryOS：分层记忆模式解决大模型长记忆问题（上）、前沿重器[68] | 北邮腾讯MemoryOS：分层记忆模式解决大模型长记忆问题（下）），毕竟他是对整个记忆系统改造，还有类似大模型论文最喜欢的技术报告，那都是系统性、大规模的创新，所以并非绝对，但大部分论文基本上就是一个小点的讨论。
实验环境的理想性。通常，论文的实验环境会比较稳定和理想，为了排除其他因素，也为了方便横向对比，实验通常会固定在特定的、可靠的、开放的数据集上，使用比较统一常用的参数。当然，部分论文为了强调自身方案的优势，可能也会特别设计一些数据集，而且出于组织的信息安全原因，有些论文只能提供一些内部实验场景下的结论，这个在推荐系统之类的领域并不罕见，尤其是一些互联网大厂的论文，只能给一些内部AB实验的数据了。
论文内大都强调成功。一个思路，通常有好有坏，我们日常看到的论文，通常强调该方案的正确性，我们很少看到用一篇论文来论证某个思路的不正确性，尤其是并没有怎么提及的新思路（对老思路的问题，还是有论文可能会聊的，但也是严重问题才会），我们往往只能看到什么方法靠谱，但无法看到什么方法不靠谱，此时很可能，我们对某个方案的优劣评判，可能会出现偏差。我们在论文中看到的算法，基本都出自于论文，而论文的作者就是方案提出人，此时从作者的视角，也很容易忽略算法本身的劣势，人之常情，因此要想更客观，可能还要通过自己的经验，以及可能出现在其他人论文里的评价了。

应用算法的特点

应用算法是指在企业等的组织下，做出一些真正让用户用到的产品，虽说是算法，但最终提供的其实远比论文中的算法要多很多，是一套更为完整的解决方案。所以算法工程师一般要多做这些事。

自己去挖掘或者采集数据。科研通常使用的都是开源、可靠的数据集，但实际场景很可能连数据都没有，需要自己采集、合并、对齐等。
在很多情况下，创新的优先级不那么高，更多是对应应用场景的效果要达标。
在准确情况这点，应用算法和论文算法的目标是基本一致的，但是应用算法除了准确，还有性能、成本，这也是为什么很多地方大模型反而是首先被毙掉，另外实际的业务价值，例如用户的点击率预测的很准了，并不代表其他的目标就很好，例如留存、例如后续的转化率等，因为到了极端情况，很多都是标题党，很多时候，这方面就变成了权衡。
有些情况下，可能并非一个算法就解决全部问题，那就是个系统工程了。以RAG为例，他有除了有向量模型作为检索向量表征，还有大模型，这本质就不是一个模型了，更复杂地，还得考虑多轮问答，还得考虑文档加载提炼切片，甚至在一些场景还得个性化，这不是一个简单的场景能够理解的。

所以其实可以发现，除了在追求单个模型的效果提升这点，论文算法和应用算法存在相似性之外，其他方面两者有巨大的差别。

给个应用算法的案例

产品需求，需要做一个比较完整的客服对话系统，电商场景的，现在已经有一些基础的问答能力了，现在需要新增一个功能，需要根据用户的描述给用户推荐合适的商品。例如“预算200，帮我选一个这个价位比较合适的键盘”，那就要推荐出合适的商品。（这是典型的对话式推荐系统的任务，之前聊过：前沿重器[39] | 对话式推荐系统——概念和技术点）

我来讲一下应用算法需要考虑的问题，注意此处先不考虑后续的技术方案，仅分析方案设计需要考虑的点。主要是下面这些内容。

数据
算法方案的设计
效果评估
算法工程开发

数据

首先需要考虑的便是数据，数据应该是整个系统里设计方向最多最杂的部分，大概需要考虑这些部分。

从实际应用出发，我们要考虑实际场景会遇到以及应用到的数据。

用户的提问。用户会怎么问，会提及哪些内容。简单的，可能是比较会提到比较明确的约束，我们就直接按着标准结构化查询都能搞定的，例如前面提到的“预算200，帮我选一个这个价位比较合适的键盘”，复杂的反而是有些模糊的要求的，例如“想要轻一点的键盘”，毕竟产品参数内更多是数值，没有轻重概念，再进一步，甚至里面没什么要求的，“最近新品”，甚至甚至“你们有啥推荐的吗”。我们需要分析我们可能面临的情况才能决定后续的方案，分析到现在其实可以发现，这里的问题没那么简单了。
产品信息，现有系统下，是否已经能够支持用户完成这样的提问推荐，还是键盘，外观信息、具体参数、欢迎度（日阅读量、销量等信息）、价格优惠活动信息等，这些信息是否已经完善，尤其是是否已经覆盖用户提问所涉及的信息。
个性化信息加入。是否具备收集用户偏好信息的条件，例如用户其他的购买信息等，这个信息直接决定了我们是否能做更为泛化的推荐，例如价格偏好这种不一定会出现在用户提问中但也还挺重要的场景下。

训练数据。我们难免要进行模型的训练，可能会面对意图识别的迭代，后续产品检索的相似度模型，推荐模型的精排，甚至是大模型回复这个任务可能需要的微调。以意图识别为例吧，这玩意放现在还是会比较简单，好理解。

我们是否能找到足量可靠的标注数据。
如果没有，我们能从什么地方找到无标注但是比较可靠的数据（例如直接从客服系统的数据中用大模型预标注或者规则匹配来挖掘），找出来后如何去做预标注（例如之前提到的自动化标注训练方案：心法利器[142] | 大模型自动化标注：实战代码分享）。
还是找不到，那是否支持使用大模型等模式进行合成，或者用简单的方式做few-shot覆盖问题。
找到的数据，是否足够覆盖前面提到的用户提问的几种模式。

测试数据。上线之前，我们要确定上线标准，在确定一定程度的可靠度后才能上线，这个数据也需要设计。

数据这块，大家应该可以感受到，这里的工作量是巨大的，再回头看论文，可以发现大部分论文其实并没有提到很多关于数据的工作，更多是用一些开源数据集，除非是专门聊数据构造、数据合成的专项论文，否则真的不会谈很多有关数据的事，可实际应用中，数据的工作很可能占到四五成甚至六成以上的工作量。

算法方案的设计

终于到算法方案了，相信也是大家最喜欢的部分，具体要考虑的东西很多，这里我列举一些可能会比较影响大体设计方案的细节。

耗时和并发需求。这点我应该反复强调很多次，估计有读者都觉得烦了，但这点真的很关键，举个例子，在一些实时性要求很高的情况下，例如就要100ms以内，那基本断绝了大模型的可能，此时，还去弄大模型，可能就会很大程度影响开发周期了。
成本需求。说白了就是多少钱办多少事，虽说大模型的成本已经很低，但现在相比其他部分，如前后端之类的在线成本，大模型仍旧非常大，我们仍需要把大模型的开发（训练）、部署成本都给考虑进去，如果条件不允许，那肯定是不好搞的。
未来需求的变化程度。这点挺容易被忽略的，我们知道一个项目的发展肯定不是一蹴而就，而是逐步迭代的，现在做的很可能只是未来的一个过渡或者初始版本，所以我们要给未来提供修改的接口，一上来就端到端模型，未来的优化的包袱会越来越重（毕竟未来时间点下的修改，需要尽量对已有功能的影响尽可能小），所以这也是个非常需要考虑的问题。
问题整体的逻辑规则难度。一般对越定制的要求，技术上的设计也越定制，复杂的规则在人与人之间的交流中传递就很困难，模型更是如此，对于复杂的任务，一个模型甚至少数模型可能并不好做，可能要横向或者纵向拆解（Agent某种程度也是这类型需求的产物），此时算法的整体设计就会变得非常困难。

效果评估

一个方案好不好，是需要评价的，这里的评价并非简单的准确率，很多问题并非一个简单的准确就能覆盖的。

类似一些大模型的任务，大模型的回复，可能并不止准不准，回复的友好度、完整性、简洁性，在不同场景下的要求就不同。这个回答产品推荐问题的场景，除了要考虑用户的偏好，可能可以通过增加一些推荐理由和产品的文字信息介绍。
业务目标可能并不绝对和准确率有关。能增加用户对推荐产品的理解，推荐产品的质量上，除了考虑是否符合用户的字面，还需要考虑用户的隐含需求，因此与其看准确，可能还得看用户最终的点击和购买率，这些就是业务指标，而且无法简单的在离线就得到验证，是需要AB实验等模式在线对比的。

因此，效果评估方案的设计，并没有论文那么直接，实际场景的变化会更多，更考验算法工程师即时的设计能力。

算法工程开发

一般的论文，可能更多是聚焦在模型内容更新和批跑训练测试的开发上，然而在应用算法的视角下，全流程要关注的会不一样，同样地，我举几个例子。

上游，我们要关注数据的来源以及计算口径。例如，同样是用户偏好（例如点击），有3日点击、7日点击、15日点击、30日点击等，口径不同，所代表的含义肯定也截然不同，我们要进行严格把控，而且这些数据可能会分散在不同的表里，此时我们要进行整合，这个是整合除了数据库本身，还有在线数据流，都需要花精力盯。
中间的核心算法部分，数据刚进来的前处理，模型的部署，后面模型结果的后处理，都需要关注，除此之外，如果是结构复杂，那还有各种数据库数据的存取维护（如RAG），各个子模块之间的整合。继续以对话式推荐为例，query理解、商品召回、精排、推荐理由和回复生成等，他们本身孤立，要把它们整合起来的工作量不少。
下游，你负责输出的部分，下游怎么用的，双方的理解是否达成一致，需要确认（例如你给的是0-100的分，对方理解是0-1的小数）。
日志、监控、运维。服务是否正常运行，是否有异常，在线运行是否有出奇怪的错误，这些都需要监控，如果一个系统有严重问题却不自知，肯定是危险的。
后续的评估，是需要具体的方案的，例如要出每日报表，就要每天拿取数，定时计算，这些脚本肯定都要准备好。

补充说一下分工的事

可能有人会说，上面的很多工作，其实都不需要自己来做，自己是有机会或正在聚焦于某个小的技术点在突破。

我想说的是，大部分一个困难的事，都并非一个人就能完成，你之所以能聚焦，相对舒适地去完成你的任务，是因为有人替你负重而行。在学校，你能安心地做各种大模型实验，是因为有人帮你购买并维护了机器，你能聚焦于模型的调优，是因为有人帮你收集、整合、标注了可靠的数据集，你能关注你的模块，是因为整个技术体系有其他人在构造好合适的骨架让你使用。才能让你，能心无旁骛地聚焦自己所需要关注的事。

但这种环境，并非什么时候都能有。

后记

敬畏，保持敬畏。

但凡是技术，都需要扎实的知识，努力的学习，辛勤的劳动。论文算法也好，应用算法也罢，两者都有很扎实的知识根基，也在自己的方向上有重要的作用，产生了重要的价值，两者不应该相轻，反而应该互相理解学习碰撞，发扬各自优点，论文算法能发现当下应用缺陷持续改进，避免闭门造车，应用算法能获取前沿技术信息，通过落地实现产生新的价值，避免浮于表面。

picture.image