解析篇 | 模型、提示词、上下文

欢迎来到《通俗易懂 AI 应用开发》系列视频，我是小麦。

本期是解析篇，如果还没有看过上一期的朋友，建议先看看上一期。

在上一期视频中，我们实现了这样一个支持连续对话的聊天机器人。

并提到三个概念：模型、提示词和上下文。

首先是模型，我们先定义了 API_KEY、BASE_URL 和 MODEL 这三个参数。

API_KEY 很好理解，远端模型服务通过它来验证身份。不过更重要的一点是，便于额度管控，避免单个 key 意外超支。

BASE_URL 为模型服务的根地址，后面连接不同的 pathname 来区分不同类型的服务接口，比如我们已经用到的对话补全接口。

除此之外，还有用于 RAG 的向量化接口、用于长文本或批量推理的文件上传接口等等。

最后是 MODEL，表示使用哪个模型，在项目中我们使用了 qwen-turbo 即通义千问的快速响应模型。

你也可以根据实际需要选择其他受接口支持的模型，比如：qwen-plus、qwen-max、qwq 系列等等。

如果要使用其他厂家的模型服务，那么必须同时调整这三个参数。

接着我们通过 fetch 发起一个 HTTP 请求，通过 Authorization 请求头传递 API_KEY、body 传递 MODEL 以及历史对话。

完整的响应数据（data）是这样的，值得注意的是，响应数据会包含本次调用的用量（usage）信息，包括输入和输出的总 tokens 消耗量，基于此我们可以得知当前上下文窗口的大小，以便在合适的时机优化上下文。

下面介绍提示词，提示词通常是指输入到模型中的指令，它可以是用户的请求或系统设定（即系统提示词）。

在聊天机器人项目中，我们在消息列表中预先植入了一个系统提示词，设定模型应该遵守的通用规则。

接着在循环中获取用户输入的提示词（user）。

在 AI 应用开发中，系统提示词扮演者至关重要的角色。系统提示词可以显著影响模型的输出效果，甚至业务流程。

提示词有多种书写技巧，可以搜索《Prompt Engineering Guide》这本书看看，里面有不少值得学习的方法。

在后续的实战项目中，我们还会多次接触到提示词，这里就不过多赘述了。

接下来是上下文，上下文可以说是整个 AI 应用开发中最重要且最难管理的部分。

在我们的项目中，messages 列表即上下文，每次循环都会往里面依次插入 user 和 assistant 消息，

这是一种非常简单直接的上下文管理方式。

在实际项目中，还会遇到上下文持久化，上下文窗口大小的限制，模型注意力，多窗口共享信息等问题，往往需要更复杂更精细的管理动作。

当前，上下文管理有一个更系统的称谓叫“上下文工程”。

即通过工程技术手段，让上下文管理这件事变得有方法可循。

在后续的实战项目中，我们还会深入探讨上下文管理，特别是包含工具调用的 Agent 上下文管理。

OK，本期视频就到这里，如果你想获取实战项目的完整代码，访问以上链接即可。

我是小麦，我们下期再见。