接触过一些大模型知识的朋友都听过一个词，大模型幻觉，指的是大模型有一定概率会胡编乱造。比如你问它桃园三兄弟“刘备、关羽、赵云”是怎么先后战死的啊？很明显，这问题就是错误的。但是大模型还会沿着错误一本正经地发挥。
我们介绍过，Transformer 架构是基于概率输出内容，这是大模型产生幻觉的原因。然而幻觉并不一定就意味着是坏事，没有幻觉的大模型不可能具有创造性，对吧？做大模型 AI 智能体开发，本质上就是如何尽量提高大模型的创造性，同时避免大模型出现偏差错误的过程。
如下图所示，传统的互联网开发架构分为数据库层、应用层和用户终端层。
加入大模型之后的应用架构应该是什么样的呢？我们需要进一步分析。上图中的 LLM 表示大模型，在真实应用开发中，指的就是一个公开提供服务的大模型平台。
大模型的温度（Temperature）是一个非常重要的参数，它控制着模型生成文本的随机性和创造性。
我们常说，大模型输出结果的质量好坏取决于输入的质量好坏，这里的输入就是提示词。我们还是以讯飞大模型为例，看下讯飞大模型的输入数据。
{"role":"system","content":"你现在扮演李白，你豪情万丈，狂放不羁；接下来请用李白的口吻和用户对话。"} {"role": "user", "content": "你是谁"} {"role": "assistant", "content": "....."}
这里的 system，user，assistant 等角色代表什么呢？system 代表就是系统提示词，参数里的你现在扮演李白，你豪情万丈，狂放不羁；接下来请用李白的口吻和用户对话。就是提示词的具体内容，它决定了接下来 AI 在会话中的具体功能。
大模型接口默认场景是一个 AI 会话，而这个数据里的 user 和 assistant 分别代表了会话里的用户和 AI 机器人这两个角色，有了它们，把会话历史写到参数数据里就很方便了。
在这个接口里，我们可以调整的是什么呢？其实就是输入的 system 提示词。
我们用一个大模型执行 SQL 的示例进一步说明提示词的作用。
我给你一个数据表的数据，再给你一个sql，请你给我这个sql的执行结果，数据表 Movies：| Id | Title | Director | Year | Length_minutes ||| 1 | Toy Story | John Lasseter | 1995 | 81 || 2 | A Bug's Life | John Lasseter | 1998 | 95 || 3 | Toy Story 2 | John Lasseter | 1999 | 93 || 4 | Monsters, Inc. | Pete Docter | 2001 | 92 || 5 | Finding Nemo | Finding Nemo | 2003 | 107 || 6 | The Incredibles | Brad Bird | 2004 | 116 |SQL：select * from movies where year=1998
面的提示词给了大模型一个数据表对应的数据，又给了一个 SQL。很多人第一感觉可能会是：啊？大模型能完成这个任务吗？它还能执行 SQL？
事实上，这个提示词就能让大模型运算并正确输出结果。你可以在自己的大模型环境里尝试一下。我举这个例子只是想说明，大模型就像一个全能的“人”，只要提示词设置得当，它就能完成传统互联网里那些接口的功能。
当然，要把这些接口正确实现就需要提示词技巧，也就是我们说的提示词工程。从这个角度看，你可以认为大模型是一个全功能的数据库，事实上大模型也正是将整个世界知识压缩到一个很小的参数文件里。
更进一步来说，未来的所有应用都会基于提示开发，也就是我们日常说的 AI first 的应用。
说起来似乎完全用大模型就可以开发出所有应用了，其实则不然。做一个比喻，大模型更像一个文科比较强的人，而传统应用更像一个理科比较强的人。
就拿前面的 SQL 大模型例子来说，真的要调教出一个执行 SQL 完全不出错的大模型还是很难的，因此大模型和传统架构还是要结合使用。具体来说，有两种大模型应用模式。
一种是采用会话式交互，AI first 的应用模式。AI first 应用更适合从零开始的创业创新业务。比如一个聊天的 AI 应用，一个客服的 AI 应用，或其他一切基于大模型会话作为基础的应用。这类应用以大模型为中心，同时在必要时结合其他系统的接口（比如天气，计算等）在会话中完成用户的需求。
另一类则比较简单，这类应用以传统应用为中心，同时结合大模型的能力（比如：翻译，分类），让传统应用加入 AI 能力。这种传统应用开发模式更适合已有成熟业务模式的 AI 升级。
好了，现在我们整理一下这些大模型应用的开发模式和传统互联网系统的关系。
