判断场景是否适合大模型

鉴于最近看到以及收集到的问题多半是“大模型能否做XXX问题”、“XXX问题为什么大模型做的会这么差”之类的，为了让大家对大模型的边界有更加清楚的认识，本文对自己的理解进行梳理，也为大家对大模型树立一个预期，避免非理性的方案选型。

没有万能药

开始聊之前，还是想跟大家强调，没有什么方法是万能的，我们需要因地制宜地，针对性的为问题提供合适的解决方案。

一方面，大模型给我们带来了很多惊喜，也在很多问题上得到了“看起来不错”的效果，另一方面，因为他拥有接近“地球百科”级别的知识，所以在解决很多问题时体现出很强的“无监督”性，从而给大家带来了很高的预期，但凡出现问题都想尝试用大模型来试试看，然而实际上仍旧因为很多原因，大模型在这些问题的表现却又并不如我们预想的那么优秀。

我们应该把大模型当做一个有些强的工具，而并非万能的神器，在方案筛选的时候可以放入当做备选项，而不能够当做唯一解。

请严肃反思，你现在掌握的，应该不会只有这一个方法吧，不会吧不会吧。

大模型的优劣势

大家对大模型的目前的优势看的还是比较多的，我总结下来，主要是这几点：

海量开放域知识支撑，不需要再进行针对性学习。
部分具体简单问题的无监督性，简单的分类、提取等，只要足够明确，模型能做到比较高的下限。
通用良好的生成能力，语言回复基本能通顺。
指令执行能力，即在输入中提供指令，常用指令在模型层面能够识别和体现。
技术影响力。

除此之外，还会有些缺点，想必只要多次尝试，并进行过详细分析的大家应该能感受到：

不可识别判断以及修正的幻觉问题。
专业性知识的缺失导致特定领域内的回复不稳定。
多轮对话策略的定制困难。
性能、耗时、成本问题。

大模型选型的判断

因此，要判断用不用大模型，可以从下面几个角度来考虑：

首先，是否具备使用大模型的条件，这是一票否决的，如果不具备，根本不要谈使用大模型了。

需求对任务的时延要求很低，例如十来毫秒。
私有化部署的缺设备，缺显卡，想买服务但是预算给不到。

其次，任务的复杂性，一般而言，越复杂的任务，越充裕的资源，应该是各自用更加专业的方案来做各自的上限才会比较高，大模型能提供的，是一个基础的、快速的、zero shot或者few shot的baseline方案，他的通用性和海量知识的支撑让他对简单的东西能快速反应并且做对，但是复杂的，到达边缘瓶颈的问题，他解决的肯定是不好的，再者微调和微调后的部署，都存在很大的风险和成本困难。

第三，基础工作的支撑。当我们都把目光聚焦在大模型本身，甚至是训练的时候，我们通常忽略了围绕大模型所需要的大量基础工作，这些工作是支撑大模型运行的关键，例如外挂知识库所需要的检索模块，大模型性能提升的加速引擎、多级多卡能力，模型的推理部署，有利于任务执行的prompt等等（这里需要强调，基础工作也非常关键，围绕大模型有很多基础工作需要做，甚至是某些定制的内容，这个我应该会专门写文章来讲）。

案例思考

给个例子大家看看，为了更加清晰地让大家明白，选型时需要考虑的问题以及角度，不见得是不能用，也不见得是万能，这些思路我自己感觉才是相比于技术本身来的更加重要。

搜索意图识别

搜索意图识别应该是我最擅长的任务了，最近听不少人来问我有没有必要尝试下大模型来做。考虑还是因地制宜吧，意图识别表面上就是个因地制宜问题，但领域和意图的划分规则非常多样，而且划分很多时候不是主观的，有很多客观因素存在，我列举一下我可能会考虑到的地方：

是否有用模型的必要，有些规则或者词典就能轻松做到的，别说大模型，模型都没必要，而且甚至还没规则词典做的好。
泛化能力的需求是用模型的门槛，有泛化需求才有用模型的必要。
边界是否能比较简单地陈述。毕竟大模型的分类依赖指令和few-shot样本，如果不好描述，其实很难做好这种分类，例如“百科”、“客服”、“投诉”这些，语言其实很难描述他们的边界，此时大模型做起来其实也会比较吃力。
是否有足够的训练数据。训练数据越充裕，小模型的优势越会体现。
数据不足的时候，few-shot（自己编几个），in-context learning可能也可以取得不错的效果，就看别的因素了，随着数据量增加，结合向量召回找到合适的样本再用in-context learning，也会有不错的效果。
性能，性能，还是性能。尤其是意图识别本身只是搜索中的小部分，耗时还是要给召回、排序让更多的。

若非找资源充足且性能要求不高，或者有技术影响力之类的压力，一般不会直接用大模型直接做意图识别，更多可能的思路：