大模型的不足与解决方案

文章目录

在前面三个章节呢，为大家从技术的角度介绍了大模型的历程与发展，也为大家介绍了目前主流的大模型的一些特点。在平时的使用中呢，我们也能够感受得到
大模型 非常的强大，但不可否认的是 大模型也存在着一些不足的部分，具体表现在以下几方面。

⭐ 不具备记忆能力 上下文窗口受限

首先我们需要知道的一件事情，大模型虽然非常的强大，但是它是不具备记忆能力的，也就是说实际上大模型是一个 0状态 的东西。在使用大模型的时候，尤其是在使用大模型的API进行多轮对话的场景下，在经过一些轮次之后，原本与大模型对话所赋予的记忆就会消失，因为大模型也记不住这么多东西。

在一个就是上下文窗口的限制，什么意思呢？就是说大模型对于 input 和 output 、输入与输出有一定数量限制的，之所以这样是为了保护自身的计算能力，相当于是一个带宽的概念。比如说 OpenAI 之前的上下文限制是32K，最新的上下文窗口已经扩张到了 128K ，大概相当于是一本书的容量了，从这个角度来说 上下文限制 的问题已经被解决了，但是其他类型的大模型就没这么幸运了，它们的上下文依然会受到限制。

在上下文窗口比较下的情况下，就会存在很多的限制，比如说不可以发那种一长段 Prompt（提示词） 过去，也不可以一直不停的不受限制的与大模型进行对话，因为这需要对对话窗口的 Token 进行计算消耗，避免没有办法进行 input 和 output ，也就是输入和输出，这是大模型的第一个缺陷。

⭐ 实时信息更新慢 新旧知识难区分

在前面的大模型发展历程中我们都知道，大模型其实是基于 预训练 所实现的，所谓的 预训练 就是利用大量的数据在神经网络上进行训练，最终形成 现在这样真实可用的大模型。大模型的知识库就是依赖于这些被用来训练的数据，OpenAI 之前的知识库是截止到2021年，最新的 GPT-4 的知识库是更新到2023年，即使如此依然会存在实时的信息无法感知的情况。

比如说 GPT-4 的知识库更新到了 2023年的10月份，那么类似 2023年11月份、12月份之后时间点的信息，它就是不知道的。所以很多人在去 “调戏” GPT 的时候就会发现这些知识库之外的信息，它是不知道的。还有一个问题就是，在大模型的底模数据比较小的时候，就会出现一些大模型胡说八道的现象。

⭐ 内部操作很灵活 外部系统难操作

现在很多大模型只是支持去进行对话、做聊天，但是没有办法去针对外部系统进行操作的。虽然说现在 ChatGPT 提供了插件机制，并且提供了插件的开发工具，但是在实际使用之后就会知道这个东西其实就是提供了一个相当于是 标准化 的工具而已，无法满足一些定制化的开发，想要更深度的融合个性化业务的场景还是比较难的。ChatGPT尚且如此，就更别提其他的大模型了。

所以说，在操作外部系统这一层面做的其实算是比较差的，或者说是 缺少有效的工具 去支持大模型操作外部的系统。比如说想要让大模型去操作智能家居系统，去操作现在的植入智能操控的汽车，这些场景都是缺少有效的外部连接器或者是框架去帮助大模型实现的。

⭐ 无法为专业问题 提供靠谱的答案

关于专业问题上的答案，相信很多小伙伴的感受是最深的。就是我们向 ChatGPT 提问一些比较宽泛的问题时，它都能够回答的很好，但是一旦问一些专业的问题，它可能就回答不上来了。因为这块儿专业性的问题可能预训练的时候并不涉及，虽然它的答案看起来像是一个人在回答，但是能够看出来那个答案是不对的。针对这样的问题，业界内的专家们提出了两种解决方案，但是这两种方案都不能够 完全的解决这种问题 ，只能说是对部分问题进行了覆盖。

第一种就是基于 “微调” 实现的解决方案，主要解决的事专业知识库的问题，同时还包括了专业知识库的更新问题。 “微调” 的底层其实还是大模型，专业数据通过 “微调” 的方式 “喂” 给大模型再做一次训练，这种训练是一次性的，也无法解决实时感知的问题，智能更新底层的数据库。而且这种方式的成本也非常的高，以 GPT 为例，相当于是将数据 “喂” 给 OpenAI 重新做了一次全量的训练。所以这种方式呢，比较适合自有大量数据的行业模型，也就是专业领域的公司积累了大量的数据，利用自有的这些数据希望以AI的方式指导后续的业务工作，这个时候就可以通过 “微调” 的方式 “喂” 给大模型在做一次调教。

目前业界比较火的一个概念就是 Maas ，也就是 Model as a Service （模型即服务）。它就是通过 微调 的技术在大模型基础之上灌入行业数据，从而实现行业模型。非常适合于拥有大量行业数据的企业去这样做，但是这样做的话也只能是解决 领域数据专业性 的问题、或者说是 知识库更新 的问题，而不是 外部操作系统、记忆能力、窗口扩张 等问题。

第二种解决方案是通过 类似于 “提示词工程” 这样的方式来解决，也就是 “Prompt Engineering” ，通过上下文提示词的设计，引导大模型输出精确的答案。这种方案的原理就是在大模型的基础之上，将专业的数据通过 Embedding （词嵌入） 和 Prompt（提示词） 的方式来实现精准的、专业的回答。同时，这种解决方案可以实现 实时信息的感知，操作外部系统，包括记忆增强、上下文窗口的扩张，最大的好处就是无需训练，也就是说不需要在大模型上进行再次训练的，成本是非常低的。

这种解决方案呢，比较适合数据样本比较少的场景。比如说我们想要从某一本书上得到一些有用的信息，但是呢又不想整本书通读一遍，这个时候就可以通过AI的机器人的方式直接从书里找到答案。这里就可以将这本书的数据作为 专业数据 ，通过 词嵌入 的方式嵌入到大模型，再通过 Prompt 的方式去引导，从而得到一个精确的答案。在这个过程中间，甚至可以将这些答案与打印机连接起来，这些都是可以通过 “Prompt Engineering” （提示词工程） 来实现的。

⭐ 解决方案的结果 各有不同的侧重

所以我们可以看到，上述的两种方式都可以解决大模型出现的一些问题，但是适应的场景不同，各自擅长的点也不一样。很多时候呢，都是将两者结合起来使用，可能效果会比较好一些。

针对第一种的 微调 的解决方案，ChatGPT 其实也提供了一系列的可以直接微调的方式， 目前已经将门槛降的很低了，可以直接将想要微调的数据直接上传上去就可以了。但是 ChatGPT 又是闭源的，所以如果是企业用户的话，有可能就会担心数据安全、数据所有权问题等等。

另一个问题就是 “Prompt Engineering （提示词工程）” 这种方案适合于 开源的大模型 ，比如说我们在本地使用 ChatGLM ，在做 “词嵌入” 这种提示词引导的时候，就可以在本地实现。但是因为底层的底模没有 ChatGPT 这么强大，可能会在语言的组织和智能度稍微低一些，这一方案的代表大模型就是 LangChain 。

总结概括的话，大模型的这些问题，有两套的解决方案，每个方案呢都有自己的优劣点和适应场景。具体使用那种方案，还是得看我们整个项目的情况。需要提一下的是，在后续的内容中，我们所使用的解决方案是以 “Prompt Engineering （提示词工程）” 为主的，也就是 LangChain 框架。