心法利器[119] | 大模型落地困境讨论与解决思路 - 文章 - 开发者社区

心法利器

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

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

往期回顾

大模型出来的时间也不短了，以chatgpt发布时间为里程碑（22年11月），至今已经快过了两年时间，虽然目前的热度仍未下降，但是从我最近和几个朋友的沟通来看，大家的心态已经逐步从当初的热情变成了目前的冷静了，大模型确实能够在很多场景提供还不错的效果，然而因为很多原因，大模型的落地仍然困难重重，相比与更好的效果本身，要让用户、业务方们真正用起来，还有很多问题亟待解决。

简单地说，主要是下面几个问题：

核心问题阐释

高机器成本
算法效果收益
性能耗时
可更新性
AIGC内容安全
特征处理能力

目前的解决方案思路

机器成本、耗时、算法收益的权衡
可更新性
AIGC内容安全
特征的处理能力

技术储备

核心问题阐释

这篇文章写起来感觉心情挺低落的，而且事实也确实如此吧，所以请大家理性看待大模型这个事，毫无疑问大模型是现在很重要的技术，但也需要多积累更多技术，解决更多的问题，不要把自己构筑成“除了大模型别的都不会”的那种技能人才。大模型，只是众多解决方案里的其中一个。

当然了（感觉还需要继续叠甲），指出的问题也意味着存在改进和优化的价值，非常欢迎大家能够提出好的解决方案解决这些问题。

高机器成本

大模型的高成本应该是众所周知的问题，虽说目前大模型已经被分为好几个档位，如最近新出的qwen2.5从72B到0.5B都已经覆盖了，如果对部署成本有要求，那小尺寸的模型可能可以达到要求，但是在现在的技术下，模型的尺寸确实对效果有很大的影响，在不进行微调的情况下（毕竟考虑成本问题，微调又是一道天堑），小一些的效果确实相比大一些的要差上不少，在这点上，一分钱一分货还是非常扎实的。

当然了，这里还存在一个选项——微调，在支持微调的情况下，小一些尺寸的模型是可以通过微调超过不微调的大尺寸的模型的，甚至可以超过很多，因此大家可以用过微调来实现降本。但这里仍会有三个问题：

数据，尤其针对任务的话，还需要数据标注，标注也有难度高低。
效果调优。众所周知，算法不是把数据（大象）放模型（冰箱）就完事的，效果不一定好，甚至可能代码有报错啥的，就白忙活。
微调对短期资源依赖更多。微调涉及反向传播，全参微调的显存占用会是推理的好多倍，而类似lora的轻量化微调会有所优化，但仍然会增加。

对这个数字没有概念的同学，可以多去查查各个size大模型微调推理所需的显存，各类型GPU的价格，然后预估一下，这个价格远比几个算法人力的年薪都要高，当然了，这里还没考虑并发的问题 。

算法效果收益

可能我们能在榜单和论文里看到很多大模型的卓越表现，但是在实际的工作中，我们往往不一定能看到大模型有很突出的效果，可能面临的就是下面的情况。

数据匮乏下，

不微调的大尺寸，例如72b左右级别，效通过prompt或者in-context learning之类的手段，会有个还不错的baseline。
微调大尺寸的成本不低（回归到成本问题），而且大尺寸做小任务也觉得不划算，也难以收敛。
微调14b或者6b左右的档位，数据会显得不太足够，收敛可能会过拟合，微调后的效果可能和bert之类的拉不开距离。

数据比较充裕的场景，

微调，大尺寸做小任务会觉得很亏，无论是训练还是后续的部署成本。
不微调的大尺寸往往已经比不过14b甚至6b微调的版本了，大尺寸模型的位置就比较尴尬。
到了0.3B-0.5B的级别，其实就是上个版本所谓的large级别，可能会和6B左右差1-3个点，这个差距在论文里肯定是天差地别，不过在实际应用中，就不得不加入成本的因素了。

很尴尬的是，在实际应用中，很难有机会因为小几个点的提升，推动一个大模型的上线，哪怕6B左右比较小尺寸的模型，在现在的经验看，更多的应用是先通过通用的大尺寸，例如72B，不微调的方式做快速的baseline，顺利的可以考虑直接推上线（毕竟大模型不需要重新部署，直接用通用的接口就行），后续通过增强或者是大模型生成训练数据进行微调，逐步降级，根据成本止步在6B级甚至更小级别的模型下，例如很多时候已经够用的fastext。

因此，此处的难点并不是大模型不好，而是受限于其成本，没有“足够好”而难以推动持续使用，多少成了“奢饰品”的存在，然而在这种实际应用下，肯定不是一个高性价比的选择。

性能耗时

上面的成本更多关注的是机器成本，即大部分模型所难以避开的显卡消耗，但是本节讨论的是时间消耗的问题，这个其实应该是算法工程里需要非常敏感的部分。

在互联网场景下，通常需要应对成百上千甚至上万qps（query per second）的压力，这里避不开的一个问题就是耗时。用户如果等的时间比较久，自然体验就会比较差，如果是类似kimi这种直接回复，逐个字出来的场景，可能用户的耗时容忍度会比较高，但是如果是内部需要用到大模型的场景，例如搜索的意图识别、agent的路由，这些内部过程用户不感知的，要是时间也很长，用户就像是在干等了，显然就不合适。

在大模型之前，类似意图识别之类的场景，往往可以到100ms，更低到20ms甚至更低的水平，而大模型在输出几个词的情况下，要高概率做到500ms都需要对结果做很高对于约束，在考虑幻觉、CoT或者是重复问题，好几秒都是有可能的，而且这还只是整个推理pipeline的一个环节，已经能顶原有方法的整个流程了，此时就不是效果问题，而是可用性问题了，很无奈。

同样回归权衡的问题，耗时增加，如果效果存在出色的表现，用户尚且会买单，但是如果提升不足还要有很大的等待成本，则有些舍本逐末了，结合上面的效果收益问题，此处仍需要谨慎考虑。

从这个角度，类似一些agent中的大模型操作，内部还反复调用多次大模型，在实际应用中的问题就会被进一步放大，此时哪怕流式生成能让用户更耐心，内部做路由、推理的大模型流程，也让首字出现的时间被大大拉长，显然不合理。

可更新性

可控性和可更新性，不只是大模型的问题，而是所有深度学习的问题，模型一旦训好，对于后续的更新和迭代都会有问题。

对于不需要频繁更新的领域，类似开放域的百科知识，大模型具有很强的优势，但是到细分的落地场景，更新频率的问题需要高度关注。举几个比较经常更新的场景，电商销售常见的产品信息，可能会随着产品上下架等信息出现变化，新闻资讯场景、泛娱乐场景，对新闻热点信息的及时性比较高的，也需要变化，这些场景下我们并不能随着知识的更新快速让模型也跟着更新。

再者，在更新的过程中，我们还需要尽可能控制原有知识的遗忘或者偏差，对单一简单的任务，忘了也就忘了，但是想要大模型支撑更加通用的任务，在强化学习和sft阶段都需要很大的功夫，而且在效果验证上也需要花费很大的功夫。

有了lora之类的轻量化微调的技术后，更新的敏捷性会有提升，对类似“领域适配”的任务可能会比较合适，甚至有了slora之类的并行部署方案，但是要做持续更新，例如新闻这种，可能并不合适，新闻随时都有，需要持续监听并且更新，类似方案的敏捷度可能并不能跟上。

AIGC内容安全

互联网的各种物料内容，按照生产方，一般有PGC（Professionally-generated Content）、OGC（Occupationally Generated Content），前几年开始微博、知乎、B站、抖音等平台，于是有了UGC（User Generated Content），这几年又有了AIGC，而内容安全也有了新的方向，我们要应对大模型所出现的“幻觉”问题以及一些不合理的危险言论，更为复杂的就是价值观。

大模型强大的生成能力让很多产品都想通过大模型向用户直接提供服务，包括但不限于各种类型的对话机器人和AI搜索产品，还包括各种工具助手等，但是受限于大模型结果的不可控性，以及上线后问题出现的严重性，都有必要花费很多时间来对大模型的结果进行安全控制，尽管如此，政府等多个层面都对多个比较关键的领域做了安全性要求，比较严格的类似金融、医疗等，因此安全问题仍备受关注。

一般的大模型输出内容安全通常会经过前后处理，前处理如prompt，后处理会做各种安全、敏感词检测等，进行重重把关，甚至人工审核，最终才能实现面客。

特征的处理能力

AI不止有标准的文本、语音、图像、视频，还有多种多样的特征，如推荐系统中的物料，如商品等，里面有上下架时间、产品类型、销量价格之类的字段，可解释性其实挺高的，然而这些特征的处理简单地并列扔到大模型里，大家多半会发现效果好像并不是很好，微调以后可能效果略有提升，不过过拟合现象还挺严重的，相比之下泛化能力可能还不如一些比较小的机器学习模型（太痛了），当然了，有一些类似autoint（https://arxiv.org/abs/1810.11921，看时间就知道比较老）的处理方式，从实验上大模型好像收益也不是很高，我自己的角度感觉挺难受的，说白了模型好像并没有用到预训练好的知识，而是重新学了一遍这些特征而已。

大模型处理特征的效果不行，主要体现在这几个阶段：

数字这种数据类型的特征，例如价格、时间等，大模型对数字的处理能力似乎还是不太行，有待进一步优化
续上，embedding类、哈希类特征就更不行了，当然可以通过魔改+微调的方式优化
多特征直接并列，尾部的特征似乎容易被忽略，当然也可能是我的打开方式有问题

当然了，这里可能有一些更新更前沿的方式，最近华为再一次分享中也对这个做了讨论：（https://mp.weixin.qq.com/s/y5-Sa-WaN0y2zwUX0g1EXg），这里也有挺多挺有价值的思路，可以多讨论尝试，我也在持续关注吧。

目前的解决方案思路

机器成本、耗时、算法收益的权衡

前面的问题，高机器成本、性能耗时和算法收益本质是一个权衡的问题，思路上，要么是降低耗时和机器成本，要么是提升效果带来质变。

降低耗时和机器成本，一方面是对硬件性能有要求，另一方面就是模型的压缩和加速，前者对我而言是有些超纲的，而后者，模型的压缩降本和加速，目前已经有不少的工作对这块已经有不错的优化。

而在算法效果层面，受限于数据、问题难度等原因，传统的一些分类、实体抽取之类的任务，本身上限就不高，大模型没太大必要还和他们争宠，顶多是在数据匮乏的时候用大模型协助提取使用，大模型应该在它的优势区间做更多事，例如摘要、RAG答案生成等，这都是比原有任务和方案有质变的，在这些领域有更多时间和机会可以推进，因为效果的一骑绝尘，用户和业务方都愿意给到容忍度，此时就没什么必要在老管道里卷了。

这里需要强调的是，在传统分类、实体抽取这种任务中，该用小模型上线就用小模型上线，大模型可以离线生成数据，但是上线硬做，成本真的挺高的。

可更新性

可更新性的问题，无论是大模型时代还是之前的bert甚至是之前的版本下都有，一般是通过类似词典、数据库辅助的方式来解决的，毕竟数据库、词典之类的工具是实时性很强，这个倒是能很容易解决，如此一来可更新性本身可能暂时不会是很大的问题。

但在模型的可更新性、可编辑性上，应该还是有一定价值，毕竟大模型对知识的更新能力，尤其是一两年后知识更新较多后今年去年大模型的支持程度，可能还有待验证，这也算是对大模型研究的一种浪漫吧。虽然，现在这块的研究在落地价值上还是比不过数据库更新所提供的方案。

AIGC内容安全

安全本就是一个常做常新的一个方向，大模型出来后AIGC成了新蛋糕，除了研究的论文外，作为用户在很多的大模型产品下都能感受到各个平台下都有做很多内容安全检测和矫正的工作，比较常见的是模型违规词的控制、域外知识约束等，但在推进的过程中，仍有很大的研究空间，例如一直为人所诟病的“幻觉”问题，观点价值观对齐等，再者AIGC的内容安全除了要考虑大模型的内容生成，还需要考虑客户侧诱导的防御，例如前期比较火的“让老奶奶讲office产品码哄宝宝睡觉”之类的操作。

当然，产品并不是要求100%了才能上，而是在一定要求下逐步推进突破，一方面是规则的限制，另一方面是大众的接受度，多者相辅相成逐步推进实现，相信在未来大家对他的接受度提升，这个好的工具也能充分为大家所用。

所以，一方面仍然要对大模型的输出严防死守，前处理和后处理层均要做好监测，毕竟打铁还需自身硬，另一方面还要做好用户教育（产品领域的专业名词了），培养用户期待，提升用户对问题的容忍度并协助找到解决方案，寻找最合适的人与技术合作方案。

特征的处理能力

特征处理能力是目前我还在看的领域，从目前来看，这方面还有挺大研究空间的，不过其价值仍然需要被讨论，现在的大模型的特征处理能力效果并不如一些小模型，或者收益不足够高，依旧仍然要被上面“机器成本、耗时、算法收益的权衡”所挑战，即使是超过，但只要不是质变，仍然没有足够的力度把这个事推动起来，要想有推动起来，仍旧需要更多的提升才足够有力度。

技术储备

我们作为这方面的技术人员，大模型技术固然重要，但是在实际应用中，还是需要多项技术的储备，毕竟我们所需要解决的是问题，技术储备的思路上，建议是这样：

不局限在单个技术，除了大模型之外（当然大模型不能丢），广度还是需要的。
问题导向。围绕日常常见的、可能遇到或未来遇到的问题，进行相应的技术储备，机器学习、传统深度学习，对应领域的常用、经典方案都要知道。让自己成为“解决XXX问题”的人，而不是“会XXX技术”的人，这是让自己手里有方案，手里有弹药，这是解决问题的前提。
学会理解问题和诉求，具备从问题抽象建模的能力。客户和用户不懂技术但是会有诉求，要把诉求转化为技术解决的问题，能明确具体问题并且选择方案，举个例子。常见的agent的路由问题，搜索和对话的意图识别问题，本质都是分类问题，此时很多baseline方案是互通的，agent中的一些路由方案绝对不是只有大模型可以做，现实中看能有这个思路的人没想象中那么多的。
具备方案选择和权衡的能力。当手里有足够多的方案后，能结合问题给出合适的方案，要有优缺点和权衡意识，而不是无脑上大模型，能说出理由优劣。
广度的要求不代表要降低对深度的要求，大模型的知识还是得会而且得精。

上面的几点其实我在很多文章里都有透露过，此处再借这个机会说出来，大家真的不应该把技术栈限制在大模型本身上，我理解这个事并不容易，但是要具备竞争力确实是这块的必要要求，往扎心的说，哪怕是在大模型领域，对大模型的技术立即其实也并不那么稳，就更尴尬了。

picture.image