datawhale开源项目：动手学大模型应用开发第二三次打卡调用大模型API大模型开发流程及架构

一、基本概念

1. Prompt

Prompt 最初是 NLP（自然语言处理）研究者为下游任务设计出来的一种任务专属的输入模板，类似于一种任务（例如：分类，聚类等）会对应一种 Prompt。在 ChatGPT 推出并获得大量应用之后，Prompt 开始被推广为给大模型的所有输入。即，我们每一次访问大模型的输入为一个 Prompt，而大模型给我们的返回结果则被称为 Completion。

例如，在下面示例中，我们给 ChatGPT 的提问 “NLP 中的 Prompt 指什么”是我们的提问，其实也就是我们此次的 Prompt；而 ChatGPT 的返回结果就是此次的 Completion。也就是对于 ChatGPT 模型，该 Prompt 对应的 Completion 是下图的展示。

后续我们都将会使用 Prompt 替代给 LLM 的输入，使用 Completion 替代 LLM 的输出。同时，我们会结合具体案例，介绍如何设计 Prompt 能够充分发挥 LLM 的能力。

2. Temprature

LLM 生成是具有随机性的，在模型的顶层通过选取不同预测概率的预测结果来生成最后的结果。我们一般可以通过控制 Temprature 参数来控制 LLM 生成结果的随机性与创造性。

Temprature 一般取值在 0~1 之间，当取值较低接近0时，预测的随机性会较低，产生更保守、可预测的文本，不太可能生成意想不到或不寻常的词。当取值较高接近1时，预测的随机性会较高，所有词被选择的可能性更大，会产生更有创意、多样化的文本，更有可能生成不寻常或意想不到的词。

3. System Prompt

System Prompt 是随着 ChatGPT API 开放并逐步得到大量使用的一个新兴概念，事实上，它并不在大模型本身训练中得到体现，而是大模型服务方为提升用户体验所设置的一种策略。

具体来说，在使用 ChatGPT API 时，你可以设置两种 Prompt：一种是 System Prompt，该种 Prompt 内容会在整个会话过程中持久地影响模型的回复，且相比于普通 Prompt 具有更高的重要性；另一种是 User Prompt，这更偏向于咱们平时的 Prompt，即需要模型做出回复的输入。

我们一般设置 System Prompt 来对模型进行一些初始化设定，例如，我们可以在 System Prompt 中给模型设定我们希望它具备的人设如一个个人知识库助手等。System Prompt 一般在一个会话中仅有一个。在通过 System Prompt 设定好模型的人设或是初始设置后，我们可以通过 User Prompt 给出模型需要遵循的指令。

二、调用 ChatGPT

1. API是什么

API 即应用程序接口（API：Application Program Interface），应用程序接口是一组定义、程序及协议的集合，通过 API 接口实现计算机软件之间的相互通信。

根据不同软件应用程序间的数据共享性能，可以将 API 分为四种类型：

远程过程调用（RPC）：通过作用在共享数据缓存器上的过程（或任务）实现程序间的通信。
标准查询语言（SQL）：是标准的访问数据的查询语言，通过数据库实现应用程序间的数据共享。
文件传输：文件传输通过发送格式化文件实现应用程序间数据共享。
信息交付：指松耦合或紧耦合应用程序间的小型格式化信息，通过程序间的直接通信实现数据共享。

2. 大模型API是什么

大模型API是一种应用程序编程接口，它提供了一种方式，使得开发者可以更方便地使用大模型。大模型API是一种合约，它定义了开发者和服务提供商之间的交互方式。

例如，智谱AI提供了一个大模型API，叫做MaaS服务，也就是Model as Service。这个API可以让开发者在自己的应用中使用智谱AI的大模型。

3. 大模型API和githubAPI的区别

大模型API和githubAPI的主要区别在于它们的功能和使用场景。大模型API，如智谱AI的MaaS服务，允许开发者在自己的应用中使用大模型，这在实现一些复杂功能，如智能推荐、自动翻译等方面具有优势。另一方面，githubAPI则是一种用于与GitHub仓库进行交互的API，主要用于管理代码库、处理问题和拉取请求等，主要被软件开发者使用。

GitHub上也有一些开源项目，如one-api，它支持包括OpenAI ChatGPT系列模型在内的多种大模型。可以访问该项目页面查看详细信息并获取使用方法。在选择和使用这些服务时，请确保理解其定价模式和服务条款。

4.获取文心一言调用秘钥

4.1方法一：python代码

要调用文心一言 API，需要先获取文心一言调用秘钥，在代码中需要配置自己的秘钥才能实现对模型的调用。

百度文心有两层秘钥认证，第一层是拥有调用权限的账户可以从账户中获取的 API_Key 和 Secret_Key，每一个账户可以创建若干个应用，每个应用会对应一个 API_Key 和 Secret_Key。

在获取完成 API_Key 和 Secret_Key 后，还需要基于这两个 Key 去获取 access_token 值。access_token 是第二层认证，基于 access_token 即可调用百度文心大模型，而 access_token 是可以控制基于时间或流量过期的。通过上述两层秘钥认证，可以进一步提高企业服务的安全性。

首先我们需要进入文心千帆服务平台，点击上述应用接入按钮，创建一个调用文心大模型的应用。

注意，你需要首先有一个经过实名认证的百度账号。
接着点击“去创建”按钮，进入应用创建界面：

简单输入基本信息，选择默认配置，创建应用即可。

创建完成后，我们可以在控制台看到创建的应用的 AppID、API Key、Secret Key。使用这里的 API Key 和 Secret Key 即可进行 access_token 的获取。

access_token 需要通过代码 post 访问指定网址得到：

import requests
import json

def get_access_token():
    """
    使用 API Key，Secret Key 获取access_token，替换下列示例中的应用API Key、应用Secret Key
    """
    # 指定网址
    url = "https://aip.baidubce.com/oauth/2.0/token?grant_type=client_credentials&client_id={api_key}&client_secret={secret_key}"
    # 设置 POST 访问
    payload = json.dumps("")
    headers = {
        'Content-Type': 'application/json',
        'Accept': 'application/json'
    }
    # 通过 POST 访问获取账户对应的 access_token
    response = requests.request("POST", url, headers=headers, data=payload)
    return response.json().get("access_token")

不要忘记加函数调用并输出

# 调用函数获取 access_token
access_token = get_access_token()
print("Access Token:", access_token)

通过上述代码，即可获取到账户对应的 access_token，后续使用 access_token 即可调用百度文心大模型。

4.2方法二：浏览器直输

前面步骤和方法一一样，在浏览器中输入下面的代码。

https://aip.baidubce.com/oauth/2.0/token?grant_type=client_credentials&client_id=[API Key]&client_secret=[Secret Key]

将[API Key]和[Secret Key]替换成自己之前获取的，注意：替换后访问链接中不包含[]。

结果：我们需要关心的是这两个键值对， expires_in 与 access_token

expires_in：Access Token的有效期(秒为单位，默认有效期30天)

access_token：要获取的Access Token。

上述方法参考链接: https://blog.csdn.net/qq_30299877/article/details/131917097

三、大模型开发整体流程

1. 何为大模型开发

我们将开发以大语言模型为功能核心、通过大语言模型的强大理解能力和生成能力、结合特殊的数据或业务逻辑来提供独特功能的应用称为大模型开发。开发大模型相关应用，其技术核心点虽然在大语言模型上，但一般通过调用 API 或开源模型来实现核心的理解与生成，通过 Prompt Enginnering 来实现大语言模型的控制，因此，虽然大模型是深度学习领域的集大成之作，大模型开发却更多是一个工程问题。

在大模型开发中，我们一般不会去大幅度改动模型，而是将大模型作为一个调用工具，通过 Prompt Engineering、数据工程、业务逻辑分解等手段来充分发挥大模型能力，适配应用任务，而不会将精力聚焦在优化模型本身上。因此，作为大模型开发的初学者，我们并不需要深研大模型内部原理，而更需要掌握使用大模型的实践技巧。

同时，以调用、发挥大模型为核心的大模型开发与传统的 AI 开发在整体思路上有着较大的不同。大语言模型的两个核心能力：指令理解 与 文本生成 提供了复杂业务逻辑的简单平替方案。在传统的 AI 开发中，我们首先需要将非常复杂的业务逻辑依次拆解，对于每一个子业务构造训练数据与验证数据，对于每一个子业务训练优化模型，最后形成完整的模型链路来解决整个业务逻辑。然而，在大模型开发中，我们将尝试用 Prompt Engineering 来替代子模型的训练调优，通过 Prompt 链路组合来实现业务逻辑，用一个通用大模型 + 若干业务 Prompt 来解决任务，从而将传统的模型训练调优转变成了更简单、轻松、低成本的 Prompt 设计调优。

同时，在评估思路上，大模型开发与传统 AI 开发也有了质的差异。传统 AI 开发需要首先构造训练集、测试集、验证集，通过在训练集上训练模型、在测试集上调优模型、在验证集上最终验证模型效果来实现性能的评估。然而，大模型开发更敏捷、灵活，我们一般不会在初期显式地确定训练集、验证集，由于不再需要训练子模型，我们不再构造训练集，而是直接从实际业务需求出发构造小批量验证集，设计合理 Prompt 来满足验证集效果。然后，我们将不断从业务逻辑中收集当下 Prompt 的 Bad Case，并将 Bad Case 加入到验证集中，针对性优化 Prompt，最后实现较好的泛化效果。

2. 大模型开发的整体流程

结合上述分析，我们一般可以将大模型开发分解为以下几个流程：

确定目标。在进行开发前，我们首先需要确定开发的目标，即要开发的应用的应用场景、目标人群、核心价值。对于个体开发者或小型开发团队而言，一般应先设定最小化目标，从构建一个 mvp（最小可行性产品）开始，逐步进行完善和优化。

设计功能。在确定开发目标后，需要设计本应用所要提供的功能，以及每一个功能的大体实现逻辑。虽然我们通过使用大模型来简化了业务逻辑的拆解，但是越清晰、深入的业务逻辑理解往往也能带来更好的 Prompt 效果。同样，对于个体开发者或小型开发团队来说，首先要确定应用的核心功能，然后延展设计核心功能的上下游功能；例如，我们想打造一款个人知识库助手，那么核心功能就是结合个人知识库内容进行问题的回答，那么其上游功能的用户上传知识库、下游功能的用户手动纠正模型回答就是我们也必须要设计实现的子功能。

搭建整体架构。目前，绝大部分大模型应用都是采用的特定数据库+ Prompt + 通用大模型的架构。我们需要针对我们所设计的功能，搭建项目的整体架构，实现从用户输入到应用输出的全流程贯通。一般来说，我们推荐基于 LangChain 框架进行开发。LangChain 提供了 Chain、Tool 等架构的实现，我们可以基于 LangChain 进行个性化定制，实现从用户输入到数据库再到大模型最后输出的整体架构连接。

搭建数据库。个性化大模型应用需要有个性化数据库进行支撑。由于大模型应用需要进行向量语义检索，一般使用诸如 chroma 的向量数据库。在该步骤中，我们需要收集数据并进行预处理，再向量化存储到数据库中。数据预处理一般包括从多种格式向纯文本的转化，例如 pdf、markdown、html、音视频等，以及对错误数据、异常数据、脏数据进行清洗。完成预处理后，需要进行切片、向量化构建出个性化数据库。

Prompt Engineering。优质的 Prompt 对大模型能力具有极大影响，我们需要逐步迭代构建优质的 Prompt Engineering 来提升应用性能。在该步中，我们首先应该明确 Prompt 设计的一般原则及技巧，构建出一个来源于实际业务的小型验证集，基于小型验证集设计满足基本要求、具备基本能力的 Prompt。

验证迭代*。验证迭代在大模型开发中是极其重要的一步，一般指通过不断发现 Bad Case 并针对性改进 Prompt Engineering 来提升系统效果、应对边界情况。在完成上一步的初始化 Prompt 设计后，我们应该进行实际业务测试，探讨边界情况，找到 Bad Case，并针对性分析 Prompt 存在的问题，从而不断迭代优化，直到达到一个较为稳定、可以基本实现目标的 Prompt 版本。

前后端搭建。完成 Prompt Engineering 及其迭代优化之后，我们就完成了应用的核心功能，可以充分发挥大语言模型的强大能力。接下来我们需要搭建前后端，设计产品页面，让我们的应用能够上线成为产品。前后端开发是非常经典且成熟的领域，此处就不再赘述，我们将主要介绍两种快速开发 Demo 的框架：Gradio 和 Streamlit，可以帮助个体开发者迅速搭建可视化页面实现 Demo 上线。

体验优化。在完成前后端搭建之后，应用就可以上线体验了。接下来就需要进行长期的用户体验跟踪，记录 Bad Case 与用户负反馈，再针对性进行优化即可。

四、项目流程简析

步骤一：项目规划与需求分析

1.项目目标：基于个人知识库的问答助手

2.核心功能：

上传文档、创建知识库；
选择知识库，检索用户提问的知识片段；
提供知识片段与提问，获取大模型回答；
流式回复；
历史对话记录

3.确定技术架构和工具

LangChain框架
Chroma知识库
大模型使用 GPT、科大讯飞的星火大模型、文心一言、GLM 等
前后端使用 Gradio 和 Streamlit。

步骤二：数据准备与向量知识库构建

过程包括加载本地文档 -> 读取文本 -> 文本分割 -> 文本向量化 -> question向量化 -> 在文本向量中匹配出与问句向量最相似的 top k个 -> 匹配出的文本作为上下文和问题一起添加到 prompt中 -> 提交给 LLM生成回答。

1. 收集和整理用户提供的文档。

用户常用文档格式有 pdf、txt、doc 等，首先使用工具读取文本，通常使用 langchain 的文档加载器模块可以方便的将用户提供的文档加载进来，也可以使用一些 python 比较成熟的包进行读取。

由于目前大模型使用 token 的限制，我们需要对读取的文本进行切分，将较长的文本切分为较小的文本，这时一段文本就是一个单位的知识。

2. 将文档词向量化

使用文本嵌入(Embeddings)对分割后的文档进行向量化，使语义相似的文本片段具有接近的向量表示。然后，存入向量数据库，这个流程正是创建 索引(index) 的过程。

向量数据库对各文档片段进行索引，支持快速检索。这样，当用户提出问题时，可以先将问题转换为向量，在数据库中快速找到语义最相关的文档片段。然后将这些文档片段与问题一起传递给语言模型，生成回答。

3. 将向量化后的文档导入Chroma知识库，建立知识库索引。

Langchain 集成了超过 30 个不同的向量存储库。我们选择 Chroma 向量库是因为它轻量级且数据存储在内存中，这使得它非常容易启动和开始使用。

将用户知识库内容经过 embedding 存入向量知识库，然后用户每一次提问也会经过 embedding，利用向量相关性算法（例如余弦算法）找到最匹配的几个知识库片段，将这些知识库片段作为上下文，与用户问题一起作为 prompt 提交给 LLM 回答。

步骤三：大模型集成与API连接

集成GPT、星火、文心、GLM 等大模型，配置 API 连接。
编写代码，实现与大模型 API 的交互，以便获取问题答案。

步骤四：核心功能实现

构建 Prompt Engineering，实现大模型回答功能，根据用户提问和知识库内容生成回答。
实现流式回复，允许用户进行多轮对话。
添加历史对话记录功能，保存用户与助手的交互历史。

步骤五：核心功能迭代优化

进行验证评估，收集 Bad Case。
根据 Bad Case 迭代优化核心功能实现。

步骤六：前端与用户交互界面开发

使用 Gradio 和 Streamlit 搭建前端界面。
实现用户上传文档、创建知识库的功能。
设计用户界面，包括问题输入、知识库选择、历史记录展示等。

步骤七：部署测试与上线

部署问答助手到服务器或云平台，确保可在互联网上访问。
进行生产环境测试，确保系统稳定。
上线并向用户发布。

步骤八：维护与持续改进

监测系统性能和用户反馈，及时处理问题。
定期更新知识库，添加新的文档和信息。
收集用户需求，进行系统改进和功能扩展。

整个流程将确保项目从规划、开发、测试到上线和维护都能够顺利进行，为用户提供高质量的基于个人知识库的问答助手。

五、项目架构简析

1. 整体架构

经过上文分析，本项目为搭建一个基于大模型的个人知识库助手，基于 LangChain 框架搭建，核心技术包括 LLM API 调用、向量数据库、检索问答链等。项目整体架构如下：

如上，本项目从底向上依次分为 LLM 层、数据层、数据库层、应用层与服务层：
① LLM 层主要基于四种流行 LLM API 进行了 LLM 调用封装，支持用户以统一的入口、方式来访问不同的模型，支持随时进行模型的切换；
② 数据层 主要包括个人知识库的源数据以及 Embedding API，源数据经过 Embedding 处理可以被向量数据库使用；
③ 数据库层 主要为基于个人知识库源数据搭建的向量数据库，在本项目中我们选择了 Chroma；
④ 应用层 为核心功能的最顶层封装，我们基于 LangChain 提供的检索问答链基类进行了进一步封装，从而支持不同模型切换以及便捷实现基于数据库的检索问答；
⑤ 最顶层为服务层，我们分别实现了 Gradio 搭建 Demo 与 FastAPI 组建 API 两种方式来支持本项目的服务访问。

2. 代码结构

-project
    -readme.md 项目说明
    -requirements.txt 使用依赖包的版本 
    -llm LLM调用封装
        -self_llm.py 自定义 LLM 基类
        -wenxin_llm.py 自定义百度文心 LLM
        -spark_llm.py 自定义讯飞星火 LLM
        -zhipuai_llm.py 自定义智谱AI LLM
        -call_llm.py 将各个 LLM 的原生接口封装在一起
        -test.ipynb 使用示例
    -embedding embedding调用封装
        -zhipuai_embedding.py 自定义智谱AI embedding
        -call_embedding.py 调用 embedding 模型 
    -data 源数据路径
    -database 数据库层封装
        -create_db.py 处理源数据及初始化数据库封装
    -qa_chain 应用层封装
        -qa_chain.py 封装检索问答链，返回一个检索问答链对象
        -chat_qa_chian.py：封装对话检索链，返回一个带有历史记录的对话检索链对象
        -get_vectordb.py 返回向量数据库对象
        -model_to_llm.py 调用模型
        -test.ipynb 使用示例
    -serve 服务层封装
        -run_gradio.py 启动 Gradio 界面
        -api.py 封装 FastAPI
        -run_api.sh 启动 API
        -test.ipynb 使用示例

3. 项目逻辑

用户：可以通过 run_gradio 或者 run_api 启动整个服务；
服务层调用 qa_chain.py 或 chat_qa_chain 实例化对话检索链对象，实现全部核心功能；
服务层和应用层都可以调用、切换 prompt_template.py 中的 prompt 模板来实现 prompt 的迭代；
也可以直接调用 call_llm 中的 get_completion 函数来实现不使用数据库的 LLM；
应用层调用已存在的数据库和 llm 中的自定义 LLM 来构建检索链；
如果数据库不存在，应用层调用 create_db.py 创建数据库，该脚本可以使用 openai embedding 也可以使用 embedding.py 中的自定义 embedding。

4. 各层简析

4.1 LLM 层

LLM 层主要功能为将国内外四种知名 LLM API（OpenAI-ChatGPT、百度文心、讯飞星火、智谱GLM）进行封装，隐藏不同 API 的调用差异，实现在同一个对象或函数中通过不同的 model 参数来使用不同来源的 LLM。

在 LLM 层，我们首先构建了一个 Self_LLM 基类，基类定义了所有 API 的一些共同参数（如 API_Key，temperature 等）；然后我们在该基类基础上继承实现了上述四种 LLM API 的自定义 LLM。同时，我们也将四种 LLM 的原生 API 封装在了统一的 get_completion 函数中。

4.2 数据层

数据层主要包括个人知识库的源数据（包括 pdf、txt、md 等）和 Embedding 对象。源数据需要经过 Embedding 处理才能进入向量数据库，我们在数据层自定义了智谱提供的 Embedding API 的封装，支持上层以统一方式调用智谱 Embedding 或 OpenAI Embedding。

4.3 数据库层

数据库层主要存放了向量数据库文件。同时，我们在该层实现了源数据处理、创建向量数据库的方法。

4.4 应用层

应用层封装了整个项目的全部核心功能。我们基于 LangChain 提供的检索问答链，在 LLM 层、数据库层的基础上，实现了本项目检索问答链的封装。自定义的检索问答链除具备基本的检索问答功能外，也支持通过 model 参数来灵活切换使用的 LLM。我们实现了两个检索问答链，分别是有历史记录的 Chat_QA_Chain 和没有历史记录的 QA_Chain。

4.5 服务层

服务层主要是基于应用层的核心功能封装，实现了 Demo 的搭建或 API 的封装。在本项目中，我们分别实现了通过 Gradio 搭建前端界面与 FastAPI 进行封装，支持多样化的项目调用。

链接: 以上内容皆来自datawhale