心法利器[136] | 算法开荒：大模型版本下高效应对碎片化需求的实战指南 - 文章 - 开发者社区

心法利器

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

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

往期回顾

这篇文章想写好久了，大模型版本下，突增大量新的需求，这些需求大都比较小，节奏要求比较快，加上开发从无到有可能一周到两周可能就要上一个新功能，为了保质保量地完成这些日常的业务需求，需要一些思路和技巧支撑，本文主要给大家总结一些有关的思路和技巧。

先谈开荒面临的问题
明确问题
调研分析意识
基线意识与方案选型
迭代思维
有关基建
评价意识
一些适合开荒的思路方案
小结

注意，今天主要讲的是意识和思路，先帮大家树立意识，有关怎么做，我会简单说，后续会专门写文章来讲。

先谈开荒面临的问题

所谓的开荒，是指从无到有，找出合适的方案，解决一个实际问题。

这里最大的难点，便是应对这个“无”。

数据是最基本的，在传统的NLP下，没什么标注数据的话，没有数据意味着没法训练。当然目前已经有一些常见支持不训练直接用的方法。但更难的是，在一些情况下，我们连数据探索的机会没有。
无思路无方向。开荒场景的问题普遍具有特异性，是一个很具体的问题，要设法和我们手里的模型联系在一起并不是那么简单。
无方案效果预期。即使是能有一些思路和方案，对有关方案的上限并不了解，有些场景甚至连“如何评估好坏”、“可量化指标”都不好做。
无基建。工程数据流、工程服务没打通，现有代码可能也没几行，都需要自己从头写。
没时间。有些新的场景，可能因为商业竞争等各种原因，整个开发周期就很短。

一整套完整的算法方案，“数据-方案-评估”三个因素紧密相连，而开荒环境下，这些东西都是比较稀缺的。而在实际应用，要开荒的话，基建和时间是紧密相连的，在时间紧迫的情况下，我们还需要兼顾基建，各种数据流的打通，服务搭建，接口对接等，都需要花费很多时间，这就会导致本就紧迫的算法3要素处理变得更为紧张，因此，算法开荒真的不是一件简单的事。

下面我会分点讲一些比较重要的意识和处理经验。

明确问题

抱着谦逊、严谨的态度，去了解问题，详细明确问题的含义，说得可能有些模糊，我自己总结是，下面几个问题了解的越清楚，我们对问题的理解程度就越高。

问题的预期输入和输出是什么。即，我们能获得解决问题的信息、依据有哪些，最终内容希望我们以什么格式和结构产出。
我们的输出最终是如何发挥作用的。用作下游计算的一个参数或特征，还是直接给用户展示，还是什么样的。
问题的场景和边界。明确我们要解决的具体场景是什么，以及可能涉及但不属于本项目解决范围的问题有哪些。
有哪些问题的典型样例。
我们面临的常见形式是哪些，例如对话、搜索场景，很需要这个，例如“用户通常的问法是什么”，甚至包括字数、高频提问方式等。

调研分析意识

要树立调研意识，很多人会因为很多原因而跳过这个流程，然而实际上这个流程对后续方案设计的可靠性有很大帮助，同时，这也是增强自己知识储备广度和厚度的重要方式，大家千万不要图方便就跳过了。

调研需要引子，需要一个检索词，此时大家可以考虑这些方向。

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

说完方向，就要说工具了。

论文，肯定是最直接快速的工具，可以了解一下近期比较前沿而有效的方案。
有关的分享方案，大小厂的，这个可以在知乎、微信公众号等知识比较密集的文字类平台中能快速看到。视频类网站肯定也有，但是收集起来的质量不如文字类平台，效率也比较低（标题党是真躲不开）。
可以试试具备联网搜索功能的大模型平台，甚至是一些agent平台，甚至可以尝试用对话的模式调整自己的思路，当你的提问逐渐收敛，方案选型基本就在你的心里形成了。不过要注意，时刻抱着怀疑的态度，一个是大模型搜到的东西可能和上面网上找到的类似，同时大模型也有幻觉，所以注意甄别。
人。身边比较靠谱，或者是有过类似经验的大佬，但要注意提前明确好问题，友好讨论。

经过一系列调研后，便可开始结合自己的实际问题，开始进行选型了。

基线意识与方案选型

在上面广泛调研的基础上，我们便可以开始进行方案设计了。

在这里，我要提出一个很关键的意识——基线意识。基线，即baseline，基线的一般概念是一个作为比较基准的方案，后续的算法迭代，都以基线方案为基准进行对比，提升变动了多少，从而体现后续方案的价值，但是在开荒场景，一开始根本没有什么基准，做出来的第一个版本，便是基准，我们必须快速找到一个可靠的方案并进行验证。在现在这个各种深度学习都有很长线发展的情况下，尽管方案已经很多，但是我还是建议在开荒场景下，不要刻意追求最前沿、看起来很炫酷的方案，而应该选更可靠、稳定能出及格线的方案。 有如下几个原因。

开荒场景，我们无法判定在现有的技术下，这个问题大概能解决到什么水平。在大部分的开荒场景下，我们无法一次上来就做的很好，甚至连评价方案好坏的评估指标、测试集都不一定靠谱，快速的方案能帮助我们快速验证这个问题的可行性和下限。
开荒环境，有大量基础工作需要做，快速、可靠的方案能为我们腾出时间花在基建工作上。再者，算法在设计上本就是不稳定的，在早期这么多非模型的工作需要做，还要花大量的时间来试验，项目时间压力会很大。
复杂的方案，在开荒场景下，因为数据问题突出，复杂前沿的新方案不见得能和经典可靠的方案拉开差距，大概率都很差，通俗地说，就是“这个烂摊子，谁来都没用”。
开荒期本就没啥数据，快速完成基线甚至上线积累数据，能加快迭代节奏，而且在积累数据后原本的基线方案其实都要改，既然如此，早期糙一些，然后后续针对性优化更加合适。

在这个基线意识下，我们能选择的方案范围就已经大大缩小了。

不用训练或少样本训练的方案。腾出更多数据给测试集，充分准确地验证方案效果。
被反复使用并验证的经典方案，避免因为模型本身就不可靠或者是自己写的难以定位的bug而导致效果出错。用上经典、现有、可靠的方案效果依旧不好，大概率就不是模型的问题，而是数据、评价指标、测试集之类的问题。
如果数据之类的资源支持训练的话，尽量选简单方案，过于复杂的模型很可能直接拟合到错误的数据，掩盖很多低级简单的问题。
尽量过程可解释、可调整的方案。早期要调整的业务规则会非常多，此时一个端到端的模型来弄，要摆正的难度还是很高的，相比之下，使用简单的模型+规则，能快速解决很多问题。
这里的复杂，并非指模型结构的复杂，而是实现、开发上的复杂，大模型结构上复杂，但是真正用的时候就是prompt，那实现成本就很低了，是个值得推荐的方案。

迭代思维

完成一个任务，是可以分步，分版本地去逐步做的。

开荒的时候，一方面是大量的基础工作需要我们去做，精力被分散，另一方面是刚开始的数据情况并不是很好，需要花费时间清洗整理，甚至需求都还比较模糊，需要花时间和产品沟通，更可怕的是，这些问题我们并不能跳过解决，因为这些事不处理好，后面我们做的模型效果就好不了，或者做出来的不是产品真正需要的。

尽管我们对这个问题有非常充足的理解，清楚未来可能什么方案是最合适的，但只要当前没这个条件，我们就需要徐徐图之了。

开荒的第一个版本，我们可以考虑用最简单、快速、稳妥的方案快速上线，为各种早期沟通、工程开发、数据处理腾出时间，即上面所说的快速把基线弄出来。
第二个版本开始，我们便可以开始铺垫我们后续的终极方案了，此时我们的需求成熟，数据也处理的比较好，甚至能拿到一些真实的数据，再者工程上要做的事也变少了，我们便可有时间去弄一些更高级、优秀的方案了。（PS：不得不说，通用的是最快的，但是定制的才可能是最好的。）

注意，不是说第二个版本就要上终极形态，而是根据终极方案所需的资源，逐步开始积累和准备，有没有什么所需的数据或者特征没到位的可以开始整，工程上的性能问题可以开始调研准备，一些关键的训练pipeline可以开始写，每一个工作准备好版本和里程碑，有计划逐步完成。

换个角度，把一些事放到迭代里，实际上是一种“技术债”，前期确实因为一些原因没法做的，后续要设法补上，

有关基建

基建在这里，是指服务于算法开发、上线的所有基础性工作，包括但不限于各种环境搭建、工程部署工作、离线训练数据、在线数据流、机器资源等。在大厂，可能很多基建工作都做的非常优秀，模型训练平台、大模型平台都有，模型部署也是一键完成，就很方便，但并非所有项目组都有这个条件，另一方面，数据流的问题，随着场景的变化，这个东西的变化也很大，很难做到通用，所以这个基建工作也要花大量时间。

如果缺少这些条件，我们就要动手去做，甚至是学。有关学，我这里列举一些作为建议，如果团队的基建比较不错，那可能这些都用不上，但如果基建不好的话，这些事都得自己来，我这里就是简单列举，详情我估计后面还会写别的文章。注意，下面的东西并非全都用得上，但至少得知道是什么，怎么整的，有需要的时候可以掏出来。

环境搭建相关。Docker，uv，pip。
服务部署。FastAPI、Flask、Tornado，外加gunicorn。模型部署考虑triton、onnx等，大模型部署有vllm、ollama等。
数据库。MySql、Redis、Postgre、Elasticsearch，还有些大数据工具，Hadoop、Spark（包括PySpark）、HDFS，MQ、kafka。

工程上数据流的事就是接口的事，离线训练的数据通常就是实际生产的采集，就真的都是体力活了。

基建关乎整个方案（不止算法本身）在线正常运行的全流程，没有这些，你的模型即使再好也上不了线用不了。

评价意识

一定要有严谨的评价意识，任何算法方案里都要有评价方案好坏的设计。最近有留意到很多新人容易踩这个坑，所以必须要说一下。

所谓评价，就是用户判断一个模型或者一套算法方案好坏的量化指标评价体系，哪怕简单，但一定要有，时刻要记住，不要图方便、图简单，对方案信任（尤其是现在的大模型），就忽略了严谨的评价，评价非常重要。

评价能让我们了解目前算法方案的现状，知晓其对当前任务的完成情况。
在了解现状的基础上，知道目前方案的上升空间，以及目前的难点（配合bad case分析：心法利器[37-40,115] | bad case治疗术：合集）。
避免出现严重问题。尤其是大模型，大模型的生成很容易阴沟里翻车，严格的效果监控和评估能避免这个问题。

而评估，并非走过场，前文就有提，是“严谨”的，并非测一两个case看起来不错就好了的那种。

一个具备足量样本、充分多样性、贴近生产环境、与业务需求高度匹配且高质量的测试集。在开荒环境下，可以适当放松，例如数量，多样性等，但还是得尽量保持，例如至少要有百来条，能让指标有统计意义，但是高质量、贴近生产，这些还是要尽量达到的，如果标注啥的都不准，那这个测试集出来的效果肯定也不对。
严谨的评价指标。例如分类要求准确率召回率，这一两年可能要面临的是大模型的生成结果，可以考虑规范化，如果不好规范化，例如一些推理任务或者是内容生成任务，那可以考虑错误率、幻觉率、异常率，人工判断打分，当然也可以考虑让大模型评判（别忘了，大模型评判本身的质量也需要评价一下）。

有关大模型评价这个事，我也写过文章（前沿重器[65] | 大模型评判能力综述），我自测的实验来看，首先他的可靠性高低取决于prompt写的是否全面、合理，让他能够理解你的评价标准，更多情况下，他在实际应用中直接评价“好坏”可能不一定准，毕竟标准再怎么理解都可能有偏差，也就是绝对分，但在判断‘哪一个方案更好’（相对比较）上还是相对可靠，即相对分。大家可以根据这个结论酌情选择和采纳。

这一步即使是有大模型的加入，还是建议大家认真看上几十上百条数据，仔细对比分析，尤其是开荒期，能更好地把握算法的真实情况，毕竟指标信息还是比较有限，另一方面也能监控到指标的欺骗性，例如测试集质量（标注错而模型对的情况）、数据分布（如难易分布和实际应用的差异）、异常严重的错误（可能就错1个，但这一个背后的问题严重，例如触发黄反），同时bad case分析对后续的迭代优化也很有好处（心法利器[37-40,115] | bad case治疗术：合集）。

一些适合开荒的思路方案

上面都是讲思路，在最后这一章，给大家推荐一些适合开荒的算法模型方案吧。

首先要讲的便是大模型+prompt的这一模式。虽说这个方案low，做起来也不够刺激，但他确实是一个很高的基线。常规的抽取、摘要任务可以说非常轻松，在7B这个档位就已经很优秀，而一些比较复杂的推理任务下，一些推理类的任务，要上到32B才会比较有起色，但终究是有的。

第二个要说的还是大模型，但不一样的是，大模型不仅可以直接完成任务，还可以间接的。早前我写过这篇文章（前沿重器[38] | 微软新文query2doc：用大模型做query检索拓展），利用大模型生成伪答案，能大幅提升搜索系统的下限。从这里可以看出，大模型可能不能100%完成所有事，但在一些事上，能提供足够多的建议支持。再例如，在早期的推荐系统里，从用户静态画像推断出一些显著偏好，还是可以考虑尝试地，这在暂时还没太多行为无法构造序列模型的情况下能比直接冷启动强。

以搜代分（心法利器[114] | 通用大模型文本分类实践（含代码））。我自己是已经经常用了，一些必要的分类问题，在少样本的情况下，向量召回能保证比较高的准确，同时还有比较高的准确性，如果类目还比较多而且比较杂，那更加合适，大模型一般很难吃下这么多的类目，而且性能也比较好，一些互联网环境，大模型可能适应不来，此时以搜代分的就比较可靠了，再者，最近的qwen3-embedding系列，对prompt的支持测下来还是不错的，非常建议尝试。

BM25和一些基于字面、关键词的规则。字面和规则的好处是，极具可解释性，对于一些业务层面的边界问题，能快速处理，有些时候大模型的生成内容不太合规，可以通过一些规则做小幅度调整，这可能是最low的，但绝对是最简单、可控的，非常适合开荒场景，有些甚至到了后期，都不愿意下掉。

小结

本文主要讲了算法开荒场景的一些必要的意识和思路，很多内容看起来项正确的废话，但在实践过程其实很容易忘记，还是需要形成条件反射或者标准流程，避免遗漏，希望大家能有所收获吧。

picture.image