你好，我是金伟。

对于咱们开发者来说，在本地体验大模型，相当于写一个 hello world 程序，没什么难度。那这节课，我们就讨论讨论大模型AI智能体开发过程里更多的一些挑战。

接触过一些大模型知识的朋友都听过一个词，大模型幻觉，指的是大模型有一定概率会胡编乱造。比如你问它桃园三兄弟“刘备、关羽、赵云”是怎么先后战死的啊？很明显，这问题就是错误的。但是大模型还会沿着错误一本正经地发挥。

我们介绍过，Transformer架构是基于概率输出内容，这是大模型产生幻觉的原因。然而幻觉并不一定就意味着是坏事，没有幻觉的大模型不可能具有创造性，对吧？做大模型AI智能体开发，本质上就是如何尽量提高大模型的创造性，同时避免大模型出现偏差错误的过程。

我把大模型AI智能体开发由浅入深分为三个层次，应用开发、微调开发和专有模型开发。这节课，我们就把这三个层次分别都是什么，需要做什么给讲清楚。

应用开发

想要了解清楚大模型在应用开发中的角色，我们需要先从传统的互联网开发架构谈起。如下图所示，传统的互联网开发架构分为数据库层、应用层和用户终端层。

加入大模型之后的应用架构应该是什么样的呢？我们需要进一步分析。上图中的LLM表示大模型，在真实应用开发中，指的就是一个公开提供服务的大模型平台。

温度（Temperature）

我在[第二节课]提到，训练完的大模型可以看做一个全功能的“人”。那怎么才能让这个“人”干活呢？其实很简单，通过一个接口就可以调用大模型，以讯飞星火大模型3.5的Python接口为例，先看它的具体实现代码。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
from sparkai.llm.llm import ChatSparkLLM, ChunkPrintHandler
from sparkai.core.messages import ChatMessage


#星火认知大模型Spark Max的URL值，其他版本大模型URL值请前往文档（https://www.xfyun.cn/doc/spark/Web.html）查看
SPARKAI_URL = 'wss://spark-api.xf-yun.com/v3.5/chat'#星火认知大模型调用秘钥信息，请前往讯飞开放平台控制台（https://console.xfyun.cn/services/bm35）查看
SPARKAI_APP_ID = ''
SPARKAI_API_SECRET = ''
SPARKAI_API_KEY = ''#星火认知大模型Spark Max的domain值，其他版本大模型domain值请前往文档（https://www.xfyun.cn/doc/spark/Web.html）查看
SPARKAI_DOMAIN = 'generalv3.5'if __name__ == '__main__':
    spark = ChatSparkLLM(
        spark_api_url=SPARKAI_URL,
        spark_app_id=SPARKAI_APP_ID,
        spark_api_key=SPARKAI_API_KEY,
        spark_api_secret=SPARKAI_API_SECRET,
        spark_llm_domain=SPARKAI_DOMAIN,
        streaming=False,)
    messages = [ChatMessage(
        role="user",
        content='你好呀')]
    handler = ChunkPrintHandler()
    a = spark.generate([messages], callbacks=[handler])
    print(a)

我说过，大模型是一个全功能的“人”，而代码第5行的 /v3.5/chat 这个接口，就可以看作跟这个“人”说话。让它干活，这一个接口就够了。

我们进一步分析一下这个接口的内部请求参数。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
# 参数构造示例如下
{
        "header": {
            "app_id": "12345",
            "uid": "12345"
        },
        "parameter": {
            "chat": {
                "domain": "generalv3.5",
                "temperature": 0.5,
                "max_tokens": 1024, 
            }
        },
        "payload": {
            "message": {
                # 如果想获取结合上下文的回答，需要开发者每次将历史问答信息一起传给服务端，如下示例
                # 注意：text里面的所有content内容加一起的tokens需要控制在8192以内，开发者如有较长对话需求，需要适当裁剪历史信息
                "text": [
                    {"role":"system","content":"你现在扮演李白，你豪情万丈，狂放不羁；接下来请用李白的口吻和用户对话。"} #设置对话背景或者模型角色
                    {"role": "user", "content": "你是谁"} # 用户的历史问题
                    {"role": "assistant", "content": "....."}  # AI的历史回答结果
                    # ....... 省略的历史对话
                    {"role": "user", "content": "你会做什么"}  # 最新的一条问题，如无需上下文，可只传最新一条问题
                ]
        }
    }
}

我们关注最主要的几个参数即可。其中最重要的就是第10行温度Temperature参数。这个参数和大模型的幻觉是相关的，取值范围0-1。温度越大，大模型创造性越强。有趣的是，现实中即使将温度调到0，它还是有创造性的，千万不要以为温度设置为0大模型就乖乖听话了。

我们画张图表示下大模型的接口。

比照互联网架构图中的传统互联网架构，传统架构下的接口是一个分而治之的逻辑，一个接口完成一个专有逻辑。大模型的接口是一个全能逻辑，但却可以实现所有细分的专用能力，具体实现要靠提示词工程。

提示词工程

我们常说，大模型输出结果的质量好坏取决于输入的质量好坏，这里的输入就是提示词。我们还是以讯飞大模型为例，看下讯飞大模型的输入数据。

1
2
3
{"role":"system","content":"你现在扮演李白，你豪情万丈，狂放不羁；接下来请用李白的口吻和用户对话。"} #设置对话背景或者模型角色
{"role": "user", "content": "你是谁"} # 用户的历史问题
{"role": "assistant", "content": "....."}  # AI的历史回答结果

这里的system，user，assistant等角色代表什么呢？system代表就是系统提示词，参数里的你现在扮演李白，你豪情万丈，狂放不羁；接下来请用李白的口吻和用户对话。就是提示词的具体内容，它决定了接下来AI在会话中的具体功能。

大模型接口默认场景是一个AI会话，而这个数据里的user和assistant分别代表了会话里的用户和AI机器人这两个角色，有了它们，把会话历史写到参数数据里就很方便了。

在这个接口里，我们可以调整的是什么呢？其实就是输入的system提示词。

我们用一个大模型执行SQL的示例进一步说明提示词的作用。

1
2
3
4
5
6
7
8
9
10
11
12
我给你一个数据表的数据，再给你一个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升级。

架构图 V1

好了，现在我们整理一下这些大模型应用的开发模式和传统互联网系统的关系。

模型微调

如果把LLM看做一个全功能、带算法的数据库，那么遇到数据库里没有的数据怎么办呢？这就需要用到大模型微调技术。

这里说的模型微调和[第二节课]里大模型训练阶段的微调没有本质的不同，都是用新的训练数据调整大模型的参数，经过微调形成独有的一套参数。还是把LLM当做一个全能数据库来说，模型微调，就是复制一份全能数据库，再加入自己的私有表数据。

什么是微调（Fine-tuning）？

微调大模型的核心工作其实整理数据集，而且是按大模型平台的格式整理。用户要微调大模型得到自己的微调模型，也需要大模型提供微调能力支持，

举个例子，现在，我要用讯飞星火大模型微调一个春联模型，看一下整体的数据格式。

我只要把全部的春联数据整理成这3段的格式就可以了，我们看看微调前后的效果对比。

很明显，经过模型微调，春联数据被“注入”到这个大模型里了。你看，将一部分专业私有数据加入大模型，整个大模型就具备了某项专业能力。

不过别忘了一个词，幻觉。即使我们把私有数据微调注入大模型，大模型还是会在涉及这类数据的时候产生幻觉。如果你想完全避免私有数据的幻觉问题，可以用向量数据库结合大模型开发。

向量数据库 VS 微调

在工程实践经验看来，向量数据库往往比微调效果还好。

以一个天气查询的AI应用来说明向量数据的应用。比如，现在用户的提问了，问：明天下午纽约的天气如何？

因为大模型没有实时数据，所以只能是我们查询出实时的天气数据提供给LLM，让大模型组织语言输出给用户。

假设我们的天气数据存储在MySQL里。

好，我们需要先查询出明天、纽约、天气相关的数据。但有一个问题，MySQL没法通过语义查询出数据，而基于向量的向量数据库则可以基于语义查询。这时就需要先将明天下午纽约的天气如何？转化为向量表示，再去向量数据库里查询，就可以按语义相似度查询所有数据。

注意，这里只是为了更清楚地说明向量数据库的作用，在原MySQL表基础上加入这条数据的向量表示，不是实际的向量数据库结构。

好了，最后把所有可能相关数据交给LLM，让LLM这个“全能人”来根据用户需求回答就可以了。

架构图 V2

加入私有数据的大模型相当于开发出一个私有的数据库，下面的架构图能够辅助你理解。

专有模型开发

你如果对全能数据库本身不满意，还可以基于开源大模型二次开发，也就是我们说的专有模型开发，例如专门实现代码开发能力的大模型。

这个基于开源大模型的二次开发，又分为两种情况，偏向行业数据的行业大模型开发，以及偏向大模型能力扩展的大模型插件开发。

行业大模型

我们知道，ChatGPT已经具备了很强的编程能力，但是要在代码能力上进一步提升，可以训练一个专门用于开发代码的大模型。

比如，大型语言模型 Code Llama 可以根据文本提示生成代码。它就是一个专业的代码大模型。Code Llama支持许多流行语言，包括Python、C++、Java、PHP、Typescript(Javascript)、C# 和 Bash。

具体的训练方法和[第二节课]大模型训练部分以及本节课提到的大模型微调方法是类似的。要训练一个专有大模型重点解决两个问题，一是选用一个开源的基模型，二是制作专用领域的高质量数据集。

因为ChatGPT这类的闭源大模型不能深度定制，所以专有大模型的定制训练和开发一般会选择类似Llama这种开源大模型。至于训练的数据，就学ChatGPT的方法，用对应领域的高质量数据集就好了。

还是以我刚才提到的Code Llama为例。Code Llama就是在Llama开源大模型的基础上开发的，用了 500B 代码 token 和代码相关数据进行训练。后续的课程案例也会有更多专有大模型的训练细节，我这里就简单介绍一下。接下来跟你说说插件开发。

插件开发

如果要给自己的专用大模型增加一个算法能力，比如互联网搜索、代码执行等，需要修改大模型推理部分的代码，也就是我们平常说的大模型插件开发，一个插件对应一个专有的功能。

比如用户输入：帮我搜索XX信息，并根据这个信息来回答问题。

显然大模型应该有能力识别用户的意图，并且在它自己的输出中标识出用户的意图，不然就没有机会调用搜索程序了。

你看，图中的 search_page 就是大模型意图识别后给我们返回的标识，这表明大模型需要我们的专有程序去处理 search_page 任务，获取数据后再次提交给大模型处理用户请求。

现在的问题就变成了如何让大模型具备识别这些意图的能力。答案还是大模型数据微调。我们需要用类似下面的意图判断实例数据对大模型进行训练，大模型就会具备这类意图识别能力了。

1
2
3
4
5
"查找关于GPT-4的最新研究论文" -> "search_paper"
"天气怎么样" -> "weather_query"
"给我讲个笑话" -> "tell_joke"
"搜索一个网页" -> "search_page"
... ...

架构图V3

专有模型相当于全能数据库的二次开发，以及全能数据库自定义函数的开发。下面整理一个完整的大模型应用开发工程架构图。

小结

回顾一下最终整理的大模型AI智能体应用开发架构图，我们会发现传统互联网架构、传统应用、大模型、提示词、微调、AI first应用之间的关系其实是比较清晰的。从分层的角度对比来看，AI大模型和数据库是一层的，提示词和传统接口是一层的，AI应用属于应用层。

类比传统应用架构来理解AI应用会更清晰。

现在让我们回顾第一、第二节课的内容，梳理一下Transformer、大模型、微调以及应用开发的关系。

未来的大部分应用都将是AI first的，但是传统应用框架下现有的能力和开发方法同样重要。如果对照传统开发框架来说，提示词就是新时代的接口程序，LLM就是集合了现有世界知识的全能数据库，而专有LLM则是一个行业专有数据库。

当然，最终的应用往往需要在专有LLM或公有LLM基础上结合私有数据微调，同时结合已有的应用接口整合出一个可靠的AI应用，避免大模型那些出错的“幻觉”，留下我们需要的创造性。

具体怎么做呢？我想接下来的项目实战课程会给出更细的答案。

思考题

在大模型AI智能体开发中，哪些功能用LLM实现，哪些功能用传统程序接口实现呢？如何选择？有什么评判标准吗？

欢迎你在留言区和我交流。如果觉得有所收获，也可以把课程分享给更多的朋友一起学习。我们下节课见！

>>戳此加入课程交流群