1 不具备记忆能力的
它是零状态的，一些大模型产品，尤其他们的API，发现你和它对话，尤其是多轮对话时，经过一些轮次后，这些记忆就消失了，因为它也记不住那么多。
2 上下文窗口的限制
大模型对其输入、输出有数量限制。为保护它自己，这计算能力或保护相当于带宽的概念，如openAI之前只有32k。最新上下文窗口扩张到128k，相当于一本《Clean Code》，这角度来看，这个问题其实已被解决。
但其他很多模型上下文窗口还是比较小，就有很多限制。如不可发一长段prompt或提示词，也不可不停在那对话.
你要注意计算整个窗口token消耗，避免被截断。
3 实时信息更新慢，新旧知识难区分
基于预训练的模型，拿大量数据在神经网络的训练，然后形成模型，其知识库就依赖于拿去训练的这些材料。
底模数据较小时，就会出现幻觉，胡乱回答。
4 无法灵活的操控外部系统
很多大模型只可对话，但无法作为一个外脑去操作外部的一些系统。虽然ChatGPT出现插件机制、开发工具。但实际用后，还是相当于提供一个非常标准的东西，定制开发或更深度融合较难。
若想用大模型作为一个外脑操控智能家居系统、操控汽车，需要有一些连接器和框架帮助。
5 无法为领域问题提供专业靠谱答案
你问泛泛而谈的东西，都能回答好，可一旦问他非常专业问题，就答不上来，因为这专业问题，他可能不涉及。虽然他回答的答案是看起来是像一个人在回答，但一眼就能看出来那个答案不对。
针对以上问题，业界提出两种解决方案，但也都不能彻底解决。
6 解决方案
6.1 微调（Fine-tunning）
主要解决专业问题，专业知识库问题，包括知识更新问题。
把这些数据喂给大模型，再做次训练。其实一次训练也无法解决知识感知信息问题，只能更新其数据库。成本较高，因为相当于把你的数据喂给LLM，然后再全量训练一次，成本很高。
适用场景
做一些自有的大量数据的行业模型。所谓行业模型，如某专业领域的公司，积累大量行业数据，如制药公司在制药过程积累大量制药数据，你希望这个数据以AI智能方式指导工作，就可用这种方式。把这些数据喂给大模型，对它再做一次调教。
这就涉及到
MaaS
Module as a Service，模型即服务。通过这个微调在大模型基础上灌入行业数据，实现这种行业模型，适合手里拥有大量行业数据的。
这也只能解决领域数据专业性和知识库更新问题，无法解决操作外部系统、记忆能力、窗口扩张。
6.2 提示词工程（prompt engineering）
通过上下文提示词设计引导。在LLM基础上把这种专业数据通过：
- Embedding嵌入
- prompt提示词
这两个工具实现精准的专业回答，同时可实现：
- 实时系统的感知
- 操作外部系统
- 记忆增强
- 窗口控制扩张
好处明显，无需训练，不用去在LLM上面做训练。
适用场景
适合数据样本较少的场景。
如你有一本书，希望从这本书得到一些信息，但又不想去一个个字读它，你希望有机器人，你问他问题，他直接从书里找答案。这种就能把书的数据作为专业数据，然后嵌入到LLM，再通过prompt方式去引导，得到精确答案。
这过程中间甚至还可把这些答案，和打印机系统连接，直接打印。
小结
两种都可解决大模型问题，但适用场景不同，各自擅长点不一，很多时候，两者结合效果更好。
微调，现在已经把门槛降到很低了，可直接将你想微调的数据upload上去，但闭源大模型还存有数据安全问题，数据所有性问题和成本问题。
而提示词工程适合开源大模型，如chatglm。若在本地部署大模型，再做这种词嵌入和提示词引导，即可实现企业内部的专业行业模型。但底层LLM可能不那么强大，只有个6b、13b，可能在语言组织或一些智能度上稍低。代表就是LangChain。
7 总结
大模型的这几个问题都有，有两套这样的解决方案：
- Model as aSerivce 模型即服务通过“微调”技术，在LLM基础上灌入行业数据，实现行业模型
- promptengineering提示词工程，通过上下文提示词设计31号LM输出精确答案
都有自己的优劣点，然后都有自己适用的场景。
所以用啥方案呢？看所需项目的情况，本专栏偏向提示词工程， 即基于LangChain框架的方式。
