心法利器[123] | 24年算法思考-大模型的应用与训练篇

因为很多原因，今年应该是我做的算法最杂的一年了，传统NLP、大模型、RAG、机器学习等多个领域*内容基本我都有涉及，同时，很多技术也在今年有了很多革新和进步，因此我想在这里总计一下我的视角下这些算法的情况以及我使用下来的经验感受。具体我就按照下面几个方面来划分，系统总结一下。

• 大模型的应用与训练
• RAG技术论文与实践小结
• 传统NLP的生存空间
• 机器学习与特征工程的必要性

今天是第一篇，主要讨论的是大模型在这一年里的训练和应用的经验。目录如下：

• 主要工作（顺带叠甲）
• prompt工程
• 基座模型能力变迁
• 训练方面的尝试
• 有关后续大模型的发展所想

主要工作（顺带叠甲）

这一年中，我在大模型方面的工作主要如下：

• prompt工程搭建与调优
• 小任务方面的简单微调
• 多轮对话方面的浅尝

可以看到，我在大模型方面的工作可能比较浅，更多是核心功能的实现，并非是偏通用的大模型构造，类似什么强化学习之类很复杂的操作，另外有关模型的部署，我并没有做，因此下面内容看起来会相对比较low，有问题欢迎大家指出。

prompt工程

从去年到现在，我已经做了挺多prompt工程的项目了，我按照下面几个角度来总结吧。

• 大模型和对应prompt的使用时机
• prompt工程构造baseline
• 调优手段和思路
• 上限的确定

大模型prompt的使用时机

我一直认为大模型是众多方案中的其中一个，在选型时，他只是一个选项，而非必选或唯一，此时更多应该打开思路多想一些办法，而在下面的情况下，我更推荐优先考虑大模型的方案。

• 训练数据，尤其是标注数据，很匮乏，甚至可以说是没有
• 对耗时要求不那么高（一般1s+），对成本也比较宽容。（说实话，相比去年，用户对这方面的要求已经降低了很多，接受了相对高成本高耗时但能解决问题的当前技术环境）
• 问题通过简单描述或少量例子就能说明白的问题
• 生成类的任务，摘要、话术生成之类的，大模型优先级提升
• 对baseline完成的时间压力较大时。大模型prompt的模式出效果相比传统的方案开发周期很快，能快速看到baseline效果

总体而言，大模型+prompt是一个在资源充足下非常值得尝试的方案，哪怕最终不上线，作为预标注给小模型准备训练数据也是个不错的，相比花费人力去标注还是要方便许多。

prompt工程构造baseline

在之前，我曾经对prompt工程做过一篇综述的解读，里面比较主流经常提到的方案，都在这篇文章里得到体现：前沿重器[55] | prompt综述的解释和个人思考，而在实践中，更多是结合任务和模板，先快速弄一个可以看效果的版本吧，然后尽快开始调优，这个模板大家可以参考。

<背景和任务初步概念描述>
<具体任务描述>
<任务要求>
<案例>
<需要做的任务/输入>
<输出前缀>

我一个一个讲一下：

• 背景和任务初步概念描述：描述清楚背景和初步概念，能预设人物的话尽量就预设，例如优秀的生物学专家。
• 描述清楚具体的任务，以分类任务为例，分几类，多分类还是多标签，类目说明等。
• 任务要求，这部分更多是给效果调优留空间，还有一些类似字数、语言风格啥的，可以在这里分点描述。
• 案例：说白了就是给模型举例子，高端的说就是in-context learning。
• 把要问的关键问题，或者是query放入。
• 这句话是让模型准备回复，有这句话似乎能很大程度避免模型可能有别的输出方向。

调优手段和思路

在有baseline的情况下，就可以开始调优了，按照之前我总结的心法利器[37-40,115] | bad case治疗术：合集，可以开展调优，这里有几个注意点：

• 尽量别幻想hard case，这样幻想出来的很可能压根不符合用户的问法，或者是非常低频，并非关键问题。
• 最好是有评测集，哪怕几十上百条也好，全都分析完再来优化，因为这里可能有权衡问题。

调优的手段和思路我这里也列举一些，方便大家参考：

• 去找信息对齐的问题，有些信息人脑有，但是模型并不理解，某些概念需要展开描述，这类型的错误非常高频。
• 要给问题安排一个“垃圾桶”，无类目、无信息、未知的，让模型往这里扔，如“如果未提取到上述信息，请回复【未提取到上述信息】”。
• 案例尽量找典型简单的，复杂的可能会有反作用。
• 配合前后处理（心法利器[103] | 大模型bad case修复方案思考），大模型把所有问题解决可能有难度。举例子，有些问题可能模型能擦边回答对，但是有些额外信息，此时适合后处理去掉，去掉的方法也应该有不少，例如可以再调一次大模型。
• 学会拆解问题，有些问题比较复杂，可以考虑多次请求分步或者分条件处理，例如提取和删除某些信息，或者是分情况做不同处理（当然这里做下来也有点agent那味了）。

上限的确定

尽管调整prompt会有很大的改观，但有些时候仅靠prompt调优并未达到我们的要求，就需要上微调了，这并不是一个简单的决定，而应该是经过严谨判断后的选择。

• 某些指令并不能和很好地执行，总有漏网之鱼或者占比不低。
• 指令过多，prompt太长导致遵循能力上不去。

此时，很可能就需要上微调，通过改变参数的方式，从根本上改变模型的效果。

基座模型能力变迁

其实从去年开始至今，大模型其实已经出了很多，也有很多新的版本，在自己的使用体验上会发现，发现有很多能力其实是逐步产生和优化的。

比较明显的是格式。去年时间线下，json的格式大模型的输出其实非常不稳定，还需要以来例子来引导，这种引导一方面浪费token（这是经济和效果的双重代价），另一方面是本身转化成功率也是个问题，除非是经过特别的微调，而现在的大模型，基本都已经具有比较稳定的json能力了，只要在指令里给出要求json基本就能实现，转化率也会很高。另外类似markdown啥的，也能很好地输出，说明这方面的指令遵循能力提升真的挺明显的。

当然了，还有一些软能力的提升，只管看可能不明显，但是摆出数据集来看，今年的模型普遍baseline都会比较高，仅prompt调整下就有比较好甚至直接是可用的效果了，因此可以大胆尝试。

现在，我自己的场景下，qwen2.5已经成为比较优先考虑的系列模型了，在条件允许的情况下，尽可能使用最大的即可开始倒腾了。

训练方面的尝试

训练方面的尝试我自己做的真不算多，可能可靠性不是很高，我就结合我的实验来聊一聊吧，内容可能比较散，但是没想到办法系统化，大家先凑合看，我看后面有没有什么办法把他系统化讲出来。

首先是大小，毋庸置疑，小一些的模型在经过简单微调后，效果就能轻松超过大体积未微调的模型，早期功能要求紧急，而后有时间进行逐步迭代的情况下，先用大体积如72b的大模型先上，后续通过积累数据微调，便能逐步优化、降级到更小体积的模型，这个模式既能方便功能快速上线，又能在后续通过迭代的方式降本优化，是一个不错的技术路线。

第二是微调能大幅降低prompt所需的信息量，通过训练，模型能把很多业务规则学进去，从而简化prompt的内容，更多只需要把在推理过程会变的部分学会即可。

第三是全量微调的优劣势，全量微调应该是目前比较容易想到而且比较方便的微调方案，不过会有下面明显的缺点：

• 原有通用能力的丢失。这个被挺多人诟病的，认为这个能力是巨大亏损，然后要开始用lora啥的，但在我的视角看来，其实只是一个“损失厌恶”的心态在作祟罢了，我们需要明确要一个问题——我们到底对所谓的“通用”能力有多高的要求，很多时候我们只是为了解决一两个问题，此时我们并不需要所谓的“通用能力”，我们只需要评估好这个问题即可。
• 可维护性能力太差。这里说的维护性是，在面对bad case或者是新需求下，要优化的代价太高，一般只能考虑增加样本微调，这个在小模型时代可能是一个很简单的事但是在大模型技术下就不那么简单了。
• 单一强大的能力在系统设计上，会导致后续我们可能需要很多个独立的大模型，这是个长期无法接受的问题，短期问题可以快速解决，但在后续的迭代中我们总要考虑如何把功能合并，从而减少大模型数量增加带来的成本问题。

第四是轻量化微调，这是个非常不错的全量微调替代品，能在较低成本下快速完成大模型的微调，加上量化方案，不分大模型的微调任务可以压缩到1卡即可完成，但与之对应的，效果上限也受到了极大的限制，另外所需的训练时间也会有所提高。

第五，微调并非立竿见影、药到病除，很多问题不是微调了就能解决的问题，可能是数据的准备，问题的难度等原因，归根结底还是多分析。

有关后续大模型的发展所想

从去年的迷茫到现在为止，大模型的调教其实成熟了非常多，有关大模型的部署、应用经验在业界也已经积累了很多，包括agent还是rag，目前都已经有大量的应用，说实话，对于很多已经有一定积累的团队而言，面对相关的问题，大模型作为重要工具能在较快时间被应用落地起来。

然而，在商业上，很多产品的方向仍然在探索，半年前有过传闻所谓AI六小虎都面临选择和各自的困难，后续还有阿里千问和豆包等有力竞争者，可见技术是一方面，产品力、影响力也是决胜的重要因素，如何在产品层面把这个东西用好，还有带给产品大佬们的探索。这方面也不是我所长，点到为止。

当然了，前段时间提到的很多落地的困境仍旧存在，我在这里有深入讨论过（心法利器[119] | 大模型落地困境讨论与解决思路），是一篇偏悲观的文章，不过也有很多有利因素在出现：

• 在技术产品的拷打下，用户开始愿意接受耗时、经济成本方面的代价换取更好的体验，某种程度上也算一种妥协，这种妥协让这方面的压力下降了不少。
• 很多公司内部的基础工作在完善，让应用大模型和训练大模型分离开，避免了两者耦合，加快产品化节奏。
• 算法工作者和大模型之间的磨合在收敛，有经验的大佬们似乎能理解大模型的能力边界，提升了落地效率。

另外，随着技术的更新迭代，很多问题也会慢慢解决，正如现在视角的bert模型，当初也有很多困难，也是突破了很多技术困难，现在也并不困难了，雄关漫道真如铁，而今迈步从头越，大概就是这个意思了。

期待更强的大模型，期待更优秀的创新产品。