ChatGLM-直播笔记-全-

ChatGLM 直播笔记（全）

课程01：基于ChatGLM的金融问答系统构建方案详解 💼

在本节课中，我们将详细拆解“馒头科技”团队在ChatGLM金融大模型挑战赛中的获胜方案。该方案的核心是利用ChatGLM2-6B模型，构建一个能够精准回答各类金融问题的智能系统。我们将从任务定义、整体架构到各个关键技术模块，进行系统性的学习。

概述

我们的目标是构建一个金融领域的问答系统。该系统需要处理上市公司年报数据，并回答用户提出的三类问题：基础信息查询、统计计算分析以及开放性文本问题。评价标准侧重于答案的准确性、关键词匹配以及文本相似度。

一、整体方案架构 🏗️

上一节我们明确了任务目标，本节中我们来看看实现这一目标的整体技术流程。我们的方案是一个典型的“检索-增强生成”流水线。

整个处理流程分为以下几个核心步骤：

数据解析与抽取：从原始PDF年报中提取结构化和非结构化信息。
问题分类：将用户问题划分到预定义的类别，以决定后续处理路径。
SQL生成与意图识别：对于涉及统计计算的问题，生成查询数据库的SQL语句；对于其他问题，则识别其具体意图。
信息召回：根据分类和意图，从数据库或文本中召回相关信息。
答案生成：将召回的信息组合成提示词（Prompt），交由大模型生成最终答案。

以下是整体架构的示意图：

二、数据解析与抽取 📄

在流程开始前，我们必须将非结构化的PDF年报转换为机器可处理的数据。这是后续所有步骤的基础。

我们采用的方法如下：

表格提取：使用官方提供的脚本，通过识别年报中的横线与竖线来定位和提取表格内容。为提高效率，我们先根据关键词定位到具体页面，再对该页进行解析。
数据过滤：年报内容复杂，包含合并报表、母公司报表等。我们需要过滤掉非目标数据，确保后续处理基于正确的“合并报表”。
数据存储：将提取后的结构化表格数据存储为JSON文件，便于后续导入数据库进行查询。

以下是数据过滤的一个代码示例，用于确保使用正确的报表数据：

# 示例：过滤非合并报表数据
if “合并报表” not in table_title and “母公司” in table_title:
    skip_this_table()

三、问题分类 🏷️

面对多样化的用户问题，第一步是确定其类型，以便分派给不同的处理模块。我们尝试并迭代了多种分类方法。

我们的分类方法演进如下：

规则匹配（初期）：根据问题中是否包含公司名、年份、特定财务字段（如“研发费用”）等关键词进行简单分类。
大模型提示（尝试）：直接要求大模型进行选择题式的分类，例如：“请问以下问题属于哪一类？A. 基础查询 B. 统计分析 ...”。
模型微调（最终方案）：为提高分类准确性和稳定性，我们采用微调（Fine-tuning）方式训练了一个专用的分类模型。

我们将问题分为六类：

A类：公司基本信息查询（如注册地址、邮箱）。
B类：员工信息查询。
C类：三大财务报表数据查询。
D类：需要计算的问题（如增长率、比率）。
E类：统计类问题（如“负债率最高的公司”）。
F类：开放性问题，需从文本段落中寻找答案。

微调使用的提示词模板示例：

你是一个金融问答系统分类器。请将用户问题分类为A、B、C、D、E、F中的一种。
用户问题：{question}
分类结果：

四、 SQL语句生成 🗃️

对于D类和E类问题，通常需要从数据库中进行统计查询。让大模型直接生成准确的SQL语句是关键。

我们探索的方案如下：

直接提示的局限性：初期尝试用Prompt让6B模型写SQL，但输出不稳定，格式和准确性不佳。
大模型能力验证：使用ChatGLM2-130B模型进行测试，发现其生成SQL的能力非常强且准确。
微调增强：因此，我们决定对6B模型进行微调，专门增强其SQL生成能力。

训练数据构造是关键。我们采用的方法结合了模板填充和大模型改写：

设计覆盖排序、统计、条件求和、多字段查询等场景的SQL模板。
使用比赛相关的财务字段随机填充模板，生成基础数据。
调用大模型对生成的问题进行多样化改写，增强模型的泛化能力。

一个成功的SQL生成示例：

用户问题：“2022年，万科A的研发费用是多少？”
生成SQL：SELECT 研发费用 FROM 利润表 WHERE 公司名称 = ‘万科A’ AND 年份 = 2022;

五、意图识别与信息召回 🎯

对于非SQL类问题（A、B、C、F类），我们需要更精细地理解用户意图，并从数据库或文本中召回准确信息。

我们的方法分两步走：

意图识别：设计结构化Prompt，让模型提取问题中的核心要素，如公司名称、年份、查询的字段。后期我们也对此任务进行了微调，以提升复杂问题（如多字段查询）的识别精度。
- Prompt示例：“请从以下问题中提取信息：1. 目标公司；2. 年份；3. 想查询的财务指标或内容。问题：{question}”
信息召回与Prompt构建：
- 表格数据（A、B、C类）：根据识别出的公司、年份、字段，从数据库中找到对应数值。构建Prompt时，我们对不同数据类型进行格式化，以提升模型理解度。例如，金额后加“元”，人数后加“人”，文本加双引号。
- 文本数据（F类）：使用关键词从全文文本中召回最相关的Top-3个段落。由于上下文长度限制，我们额外训练了一个排序模型，从中选出最匹配的一段放入Prompt。

一个表格数据问答的Prompt构建示例：

用户问题：“2021年，中兴通讯的研发人员数量是多少？”
召回信息：{“研发人员数量(人)”: “31748”, “研发人员占比(%)”: “16.01%”}
构建Prompt：“已知中兴通讯2021年年报信息：研发人员数量为“31748”人，研发人员占总人数比例为“16.01%”。请回答：2021年，中兴通讯的研发人员数量是多少？\n回答：”

六、复杂问题处理与答案生成 ⚙️

某些问题需要多步推理或计算，直接询问大模型可能得到错误结果。我们采用“问题分解”和“程序辅助”的策略。

以下是针对不同类型问题的处理技巧：

计算类问题（D类）：模型不擅长精确计算。我们将其分解为“问题链”。例如，对于“营业利润率”，分解为“营业利润”和“营业收入”两个子问题。模型分别回答后，用Python执行计算：利润率 = 营业利润 / 营业收入。
开放性问题（F类）：在提供召回的文本片段时，我们会在Prompt中加入对年报文本的说明（Context），帮助模型理解文本中的特殊符号或表述。同时，严格要求模型按照“关键词：答案”的格式输出。

七、方案优化与总结 🚀

在实现核心流程后，我们对方案进行了反思和优化展望。

效果优化总结

Prompt设计：角色定义清晰，任务描述简洁，多使用枚举示例，明确输出格式。
微调策略：针对分类、意图识别、SQL生成等特定任务进行轻量微调，能显著提升小模型（6B）在专项任务上的能力。未来可考虑多任务联合微调。
流程设计：采用“检索-生成”框架，将大模型的生成能力建立在准确的信息检索之上，保证了答案的准确性。

未来改进方向

精度：探索更优的文本Embedding模型以提高召回准确率；结合知识图谱增强模型知识。
速度：优化检索精度以减少输入模型的Token数；采用模型量化、Token裁剪等技术；设计大小模型协同的推理流程。
通用性：探索不依赖中间检索、端到端的全量微调方案，以简化流程并提高通用性。

总结

本节课中，我们一起学习了构建专业领域大模型应用的全过程。从数据预处理、问题分类，到意图识别、SQL生成，再到最终的答案合成，每一步都融合了传统NLP技术与大模型的新能力。该方案的核心启示在于：通过任务分解和针对性微调，可以充分发挥中小规模模型在垂直领域的潜力；而精心设计的Prompt和“模型+程序”的协作，则是解决复杂、精确问题的有效手段。这套“检索-增强生成”的框架，对于开发其他行业的专业问答系统具有很高的参考价值。

注：本教程根据“馒头科技”团队竞赛答辩内容整理，侧重于技术方案与实现思路的解析。

课程一：ChatGLM与LangChain简介及本地知识库问答原理 🧠

在本节课中，我们将学习ChatGLM与LangChain的基本概念，并深入探讨基于本地知识库进行智能问答的核心原理与实践流程。

概述

本次分享将结合ChatGLM和LangChain，介绍如何构建一个基于本地知识库的智能问答应用。内容主要分为三个部分：ChatGLM与LangChain的简介、项目原理与实践、以及问答环节。

第一部分：ChatGLM与LangChain简介

首先，我们来了解一下ChatGLM-6B模型。它是一个开源的支持中英双语的对话语言模型，基于GLM架构，具备62亿参数。近期该模型更新至1.1版本，解决了英文回答中夹杂中文词语的现象。

ChatGLM-6B模型具备多种能力，例如：

自我认知：回答“你是谁”等问题。
提纲写作：根据主题列出写作提纲。
文案写作：进行各类文案创作。
信息抽取：从给定文本中提取关键数据。

然而，在实际应用中，除了通识知识，我们常需要模型处理垂直领域或私有知识。这时通常有两种方法：

模型微调：在原有模型基础上，使用特定领域的数据进行进一步训练。适用于任务明确、有足够标记数据的场景。
提示词工程：设计自然语言指令来指导模型执行特定任务。适用于需要高精度和明确输出的任务，例如信息抽取。

我们今天介绍的基于本地知识库的应用，就属于提示词工程的范畴。

第二部分：LangChain框架与项目原理

上一节我们介绍了提示词工程，本节中我们来看看实现它的一个流行框架——LangChain。

LangChain是一个用于开发由语言模型驱动的应用程序的框架。它的主要功能包括调用语言模型、将不同数据源接入交互，并允许模型与运行环境互动。

LangChain框架包含以下核心组件：

模型：支持各类语言模型和向量化模型。
提示词：管理、优化和序列化提示模板。
索引：连接外部数据与语言模型。
链：将多个组件组合成序列化的工作流。
代理：赋予模型使用工具和链的能力，以执行复杂任务。

LangChain适用于多种场景，例如：

文档问答：基于特定文档回答问题。
个人助理：基于日历等信息提供行动建议。
查询表格数据：查询CSV、SQL等结构化数据。
API交互：让模型获取最新信息。
信息提取：从文本中提取结构化信息。
文档总结：对长文档进行内容压缩和总结。

本节课我们将聚焦于文档问答场景。

基于本地知识库的问答原理

在文档问答中，我们希望实现的效果是：当用户提出一个问题时，系统能从本地文档中检索出相关信息，并将这些信息与问题一起，按照预设的模板组合成最终的提示词，再交给语言模型生成答案。

这个过程可以类比为考试：

直接提问模型：相当于闭卷考试，依赖模型自身的知识。
基于知识库提问：相当于开卷考试，模型可以“翻阅”提供的资料（本地文档）来回答问题。

基于单一文档的问答实践通常包含五个步骤：

1. 加载文档
将本地文件（如TXT、PDF）读取为文本格式。

2. 文本拆分
由于语言模型有输入长度限制，需要将长文本拆分为较短的段落。拆分方式包括：

按字符拆分：例如按句号、问号划分。
按长度拆分：例如每500字为一段。
按语义拆分：使用NLP模型理解语义后进行划分。

3. 匹配相关文本
获取用户提问后，在拆分后的文本段落中寻找相关内容。匹配方式有：

字符匹配：进行精确或模糊的字符串搜索。
语义检索：将文本转化为向量，在向量空间中进行相似度检索。这种方式能更好地理解语义，支持跨语言检索。

4. 构建提示词
将匹配到的相关文本和用户问题，填入预设的提示词模板中。

5. 生成答案
将构建好的提示词发送给语言模型，获得基于文档内容的回答。

以上是基于单一文件的流程。对于本地知识库，我们需要处理多个文档。其核心原理是构建一个向量数据库。

以下是构建和使用向量数据库的完整流程：

1. 加载本地多个文件 -> 2. 文本拆分 -> 3. 段落向量化 -> 4. 存储到向量数据库
5. 用户提问 -> 6. 将问题向量化 -> 7. 在向量库中检索相似段落 -> 8. 构建提示词 -> 9. 模型生成答案

简单来说，就是将文档内容转化为向量并存储。当用户提问时，将问题也转化为向量，然后在向量数据库中查找最相似的文档片段，最后将这些片段作为“已知信息”提供给模型来生成答案。

第三部分：代码实践与项目演示

上一节我们介绍了原理，本节中我们通过代码和项目演示来看看具体如何实现。

代码流程解析

以下是使用LangChain和ChatGLM实现基础文档问答的关键代码步骤：

1. 初始化大模型
首先加载ChatGLM-6B模型。

# 示例：初始化ChatGLM模型
from transformers import AutoTokenizer, AutoModel
tokenizer = AutoTokenizer.from_pretrained("THUDM/chatglm-6b", trust_remote_code=True)
model = AutoModel.from_pretrained("THUDM/chatglm-6b", trust_remote_code=True).half().cuda()

2. 加载与拆分文档
使用DocumentLoader加载文件，并用TextSplitter进行拆分。

from langchain.document_loaders import UnstructuredFileLoader
from langchain.text_splitter import CharacterTextSplitter

![](https://github.com/OpenDocCN/dsai-notes-zh/raw/master/docs/chatglm/img/9e6ab9221bbd27ed8b9032e28e354e9b_40.png)

# 加载文档
loader = UnstructuredFileLoader("test.txt")
documents = loader.load()

![](https://github.com/OpenDocCN/dsai-notes-zh/raw/master/docs/chatglm/img/9e6ab9221bbd27ed8b9032e28e354e9b_42.png)

![](https://github.com/OpenDocCN/dsai-notes-zh/raw/master/docs/chatglm/img/9e6ab9221bbd27ed8b9032e28e354e9b_44.png)

![](https://github.com/OpenDocCN/dsai-notes-zh/raw/master/docs/chatglm/img/9e6ab9221bbd27ed8b9032e28e354e9b_46.png)

![](https://github.com/OpenDocCN/dsai-notes-zh/raw/master/docs/chatglm/img/9e6ab9221bbd27ed8b9032e28e354e9b_48.png)

![](https://github.com/OpenDocCN/dsai-notes-zh/raw/master/docs/chatglm/img/9e6ab9221bbd27ed8b9032e28e354e9b_50.png)

![](https://github.com/OpenDocCN/dsai-notes-zh/raw/master/docs/chatglm/img/9e6ab9221bbd27ed8b9032e28e354e9b_52.png)

# 拆分文本
text_splitter = CharacterTextSplitter(chunk_size=500, chunk_overlap=200)
split_docs = text_splitter.split_documents(documents)

chunk_overlap参数用于设置段落间的重叠字符数，以防止完整的句子被切散。

3. 构建向量数据库
使用Embedding模型将文本段落向量化，并存储到向量库中。

from langchain.embeddings import OpenAIEmbeddings
from langchain.vectorstores import FAISS

# 加载Embedding模型（此处为OpenAI，实践中可替换为本地模型）
embeddings = OpenAIEmbeddings()
# 从文档创建向量存储
vector_store = FAISS.from_documents(split_docs, embeddings)

4. 检索与构建提示词
用户提问后，在向量库中检索相关段落，并构建最终提示词。

# 检索相关文档
query = "LangChain能够接入哪些数据类型？"
matched_docs = vector_store.similarity_search(query, k=3) # k为返回的相似段落数量

# 构建上下文
context = "\n".join([doc.page_content for doc in matched_docs])

# 构建提示词模板
prompt_template = f"""已知信息：
{context}

根据上述已知信息，回答以下问题：
{query}
"""

5. 调用模型生成答案
将构建好的提示词发送给ChatGLM模型。

response, history = model.chat(tokenizer, prompt_template, history=[])
print(response)

LangChain-ChatGLM 项目介绍

基于上述原理，我们开发了 LangChain-ChatGLM 项目。它是一个基于开源大模型的本地知识库问答应用，特点包括：

离线部署：依托ChatGLM等开源模型，可完全离线运行。
快速接入：基于LangChain，能快速接入多种数据源。
中文优化：针对中文场景优化了文档加载、文本拆分和提示词模板。

项目已支持的文件格式包括：PDF、TXT、Markdown、Docx以及包含文字的JPG/PNG图片（通过OCR识别）。

项目核心优化点：

文本拆分：针对中文标点（句号、问号、叹号）进行分句，并控制每段长度（默认100字符左右），以适应本地Embedding模型。
上下文扩充：检索到核心句段后，会向上向下扩充相邻句子，以形成语义更完整的段落。
去重与排序：当检索到多个相关段落时，会对扩充后的内容进行重排和去重，避免信息重复。

总结

本节课我们一起学习了以下内容：

ChatGLM-6B模型的基本特点及其在提示词工程中的应用。
LangChain框架的核心组件及其在文档问答等场景下的作用。
基于向量数据库的本地知识库问答系统的完整工作原理，从文档加载、文本拆分、向量化到检索和生成答案。
通过代码示例了解了如何使用LangChain和ChatGLM搭建一个简单的问答流程。
介绍了 LangChain-ChatGLM 项目如何对中文场景进行优化，并演示了其Web界面的基本操作。

通过本课程，你应该对如何利用ChatGLM和LangChain构建私有知识库问答系统有了一个基本的认识。核心思想是将非结构化的文档知识通过向量化进行管理，从而让大模型能够“有据可依”地回答问题。

课程一：ChatGLM-6B 微调教程：P-Tuning, LoRA, Full Parameter 🚀

在本节课中，我们将学习如何对 ChatGLM-6B 模型进行微调。主要内容包括：回顾 GLM 模型结构与预训练过程，介绍微调所需的基础知识（混合精度与 Zero 优化器），并详细讲解两种高效微调方法（P-Tuning v2 与 LoRA）以及全量微调。最后，我们将学习如何使用 Gradio 部署一个交互式前端。

GLM 模型回顾 🤖

首先，我们来回顾一下 GLM 模型。GLM 模型与 GPT 一样，是一个语言模型，但其预训练过程与 GPT 有所不同。

从右侧的注意力掩码（attention mask）来看，其前缀部分（即输入序列）可以进行双向注意力计算。假设输出语段是 X1 到 X6，在预训练过程中，我们会随机遮盖（mask）掉一些部分。与 BERT 不同的是，我们会遮盖一个较长的连续片段（span）。

另一个不同之处在于，我们采用双向编码（bidirectional encoding）。从右侧的注意力掩码可以看到，这些前缀 token 可以互相进行注意力计算。

我们将整个被遮盖的片段替换成一个 [MASK] token，无论其原始长度如何。同时，我们使用二维位置编码（two-dimensional positional encoding）。第一个位置表示该 token 在原始训练序列中的位置，第二个位置表示该 token 在被遮盖序列中的相对位置。

在训练过程中，我们要求模型预测每一个被遮盖的语段是什么。我们会将这些被遮盖的语段顺序进行随机打乱。例如，正常顺序是 X1, X2, X3, X4, X5, X6。我们可能遮盖 X3 以及 X5, X6。遮盖后，将它们替换成 [MASK] token。

在生成时，我们使用第二个位置（position two）的编码来提示模型生成原始序列中对应位置（如 position five）的 token。这样，模型就能学习如何生成被遮盖的内容。在生成了第一个序列片段后，第二个序列片段就可以关注（attend to）之前自己生成的内容。这就是 GLM 的预训练过程。

在实际的推理（inference）过程中，我们会先给出一个提示（prompt），然后在后面加上一个 [MASK] token 和一个 [sop] token（代码中可见）。这相当于我们认为模型在遮盖最后一个位置，并在其后有一个句子开始标记。

GLM 系列有很多模型。首先是最基础的 GLM 模型。其次是今年 ICLR 2023 上发布的 GLM-130B 大模型。当然，这个大模型无论是进行高效微调还是全量微调，都需要非常大的算力，并非每个人的电脑都能运行。

因此，我们也推出了 GLM-6B 模型，让每位拥有消费级显卡的同学都可以进行高效微调。如果你有几张较好的显卡，就可以进行全量微调。以上就是关于 GLM 模型的简单回顾。

环境配置与模型下载 ⚙️

接下来，我们介绍如何真正运行它。第一步是下载模型检查点（checkpoint），并验证是否下载正确。然后，我们将进入微调过程。

首先说明今天演示所使用的环境。我们的演示主要使用 RTX 3090 GPU，这是一款消费级 GPU，拥有 24GB 显存。实际上不一定需要这么多显存。如果使用我们将介绍的 P-Tuning 方法，在 4-bit 量化的情况下，7GB 显存就足够了。如果不做量化，则需要十几个 GB。如果进行全量微调，经过尝试，在八张 3090 上似乎无法运行，但四张 A100（每张约需 50GB 显存）可以运行。我们也会演示全量微调，但这并非重点。

我们演示所使用的容器镜像是 nvcr.io/nvidia/pytorch。如果你有一台 Linux 机器，可以启动一个 Docker container，这将非常方便地帮助你配置环境，省去许多配置步骤。

还有一个提示：刚才提到的 A100 80GB 版本，如果用四张卡，需要 80GB 版本；如果用八张卡，40GB 版本应该也可以。另外，如果你使用这个镜像，一定要注意更换软件源（换源），否则它会从 NGC 下载，速度非常慢，而且其 pip.conf 的位置与普通环境不太一样。建议直接使用以下三条命令来快速换源。

接下来是下载模型检查点。我们可以访问 Hugging Face 页面。如果你在 GitHub 上点开链接，会发现可以跳转到 Hugging Face。这里有一个模型介绍页面，你可以看到很多 space 都在使用 ChatGLM-6B。这里有很多文件，它使用 Git LFS 进行管理。

最简单的方法是首先安装 Git LFS。因为我们使用 Git LFS 来管理大文件。安装后，你可以从 Hugging Face 克隆仓库。

但你会发现从 Hugging Face 下载特别慢。执行 git clone 后，它会卡在最后一行，这是预期行为，因为它在运行 LFS 过程中不会显示内容。如果你打算从 Hugging Face 下载，可以使用 bwm-ng 来监控网络流量，以了解下载状态。

另一种方法是手动下载。官方仓库提供了一个清华云盘的链接。你可以手动一个个下载文件，然后再传到服务器上，但这非常慢且麻烦。因此，我们推荐大家直接使用一个现成的工具：Tsinghua Cloud Disk Downloader（清华飘down）。这个工具可以帮助你快速从清华云盘下载文件。

具体操作是，克隆仓库后，运行该下载工具，它会自动帮你下载链接中的所有文件。下载过程可能需要十几分钟。

下载完成后，你需要克隆官方的源代码仓库。克隆后，你需要手动安装 PyTorch，不要自动安装，因为自动安装很可能与你的 CUDA 版本和系统不匹配。你可以访问 PyTorch 官网的 “Previous Versions” 页面，在里面找到适合你环境的版本进行安装。

然后，安装 requirements.txt 中的依赖。

运行演示：CLI 与 Web Demo 🖥️

下载完成后，你就可以直接运行演示了。我们将演示命令行界面（CLI）和网页界面（Web Demo）。

首先，对于 CLI Demo，你只需要修改两行代码：tokenizer 和 model 的路径。如果不修改，它会默认从 Hugging Face 重新下载一遍，比较麻烦。因此，你可以将其改为你自己模型的相对路径，然后直接运行。

运行前，可以查看一下显卡状态。如果显卡识别通过，就不需要指定 device。运行后，模型会加载并进行推理。例如，输入“你好”，它会开始生成回复，呈现打字机效果。我们可以查看全量推理（未量化）的显存占用情况。在 3090 上完全可以运行。如果显存不够，可以尝试量化。

CLI 效果不错，但不够酷炫，所以我们可以试一下 Web Demo。同样，你需要先指定模型路径。Web Demo 使用了 Gradio，这是一个非常适合为深度学习模型搭建前端的框架。

如果你用 VS Code 来编写代码，它会自动检测并开启端口转发。这样，本地的请求就会被自动转发到服务器上的 7861 端口。后端实际上运行在服务器上，你就可以直接进行推理。如果你打算为它搭建一个前端，一种比较简单的策略就是直接在 Web Demo 代码上修改，然后加一个反向代理即可。

微调前置知识：混合精度与 Zero 优化器 📚

现在，大家应该已经知道如何运行模型了。接下来，我们将进入微调环节。首先，我们会介绍两个前置知识：混合精度训练和 Zero 冗余优化器。

混合精度是什么意思呢？这涉及计算机基础知识——浮点数。大家应该都了解 IEEE 754 浮点数标准。FP32 是 32 位浮点数，即单精度浮点数。它有 8 位指数位和 23 位尾数位，可以用来表示很大范围的数字。

但是，浮点数乘法计算步骤多，在现代处理器中也需要多个周期才能算完，速度较慢，而且它占用空间大（4字节）。在机器学习中，我们发现很多计算并不需要那么高的精度。

因此，我们有了另外两种半精度浮点数：FP16 和 BFloat16。FP16 是 IEEE 的 16 位浮点数标准，有 5 位指数和 10 位尾数。它的表示范围非常小，最大只能到约 6万，最小约 5e-8。

在机器学习中，很多时候并不需要这么高的精度，相比而言更需要一个较大的表示范围。因此，我们有了 BFloat16。它可以表示非常大的数（约 3.8e38），也可以表示非常小的数。这样，在训练过程中既不容易发生下溢（underflow），也不容易发生上溢（overflow）。

使用半精度浮点数有什么好处呢？首先，直观来说，显存节省了一半（从 32 位变为 16 位）。其次，根据 NVIDIA 的说明，使用半精度时，计算速度会成倍提升，训练起来会更加方便，尤其在大参数量模型中。

但这样做有问题：会丢失精度。我们如何解决这个问题呢？或者说，所有精度都有必要保留吗？我们发现，在模型梯度更新过程中，有些梯度非常小（例如小于 1e-27），这对训练几乎没有影响。但有些梯度的大小介于某个范围（例如 1e-17 到 1e2 之间），这类梯度虽然低于 FP16 的表示范围，但对模型训练仍有影响。

因此，我们不能把所有参数都变成 FP16，但我们又想要 FP16 省显存、算得快的特点。怎么办呢？我们就采用混合精度训练。

具体做法是：假设我们使用 Adam 优化器，它会有动量（momentum）和方差（variance）这两个状态。我们将参数（parameter）、动量（momentum）和方差（variance）这三个部分都用 FP32 来表示。这样做的好处是，如果在训练中出现了一个非常小的梯度，它仍然可以在 FP32 的精度上被体现出来，对模型的更新会在 FP32 精度上进行。

然后，我们拿到梯度后，将其转换为 FP16 进行更新。你可能会问：那很小的梯度在转换成 FP16 时不是已经丢了吗？这时就有一项技术叫动态损失缩放（Dynamic Loss Scaling）。它的意思是，在保证损失不发生上溢的情况下，尽可能将损失放大一些。这样，一个很小的数（例如 1e-18）在加上一个缩放因子（如 4096）后，可能会变成 1e-15，就更不容易发生下溢。下溢是指数值太小，以至于直接表示成零了。

在前向传播（forward pass）过程中，我们首先将参数转换为半精度（half()）。然后，前向传播和计算损失也使用半精度。在前向传播过程中，我们得到半精度的激活值（activation）。在反向传播（backward）过程中，我们使用动态损失缩放，将损失放大一个范围。这样，一些原本会发生下溢的梯度由于被放大就不会下溢。

得到这个放大后的梯度后，我们再将其转换回正常的 FP32 梯度，然后在 FP32 上进行更新累加。这样，一些原本会下溢的梯度就不会变成零，从而对模型产生实际的影响。以上就是混合精度训练的基本思想。

接下来，另一个非常重要且常见的技术是 Zero 冗余优化器（ZeRO）。这个工作的目的是帮助你节省显存。

为什么需要 ZeRO 呢？我们已经有了数据并行（Data Parallel, DP）和模型并行（Model Parallel, MP）技术。数据并行大家应该很熟悉，就是多卡训练。例如，如果你有八张卡，原来在一张卡上 batch size 只能设为 4，因为显存不够。那么，你可以用八张卡，每张卡跑 batch size 为 4。前向传播后，每张卡单独进行反向传播，得到梯度。然后进行一次 all-reduce 通信操作，将所有梯度取均值。这样每个节点都拿到了梯度均值，然后每个节点用自己的优化器更新自己的参数。这就是数据并行的基本思想。

模型并行的意思是将模型的不同部分放到不同的显卡上计算。例如，将权重矩阵分块到不同的显卡进行运算。在前向传播中，有些地方需要进行 all-reduce，有些地方则进行复制（identity）。在反向传播过程中，原来做复制的部分进行 all-reduce，原来做 all-reduce 的部分进行复制。具体细节可以参考相关论文。

但模型并行的问题在于通信太慢。而数据并行虽然通信量小（只需要通信梯度），但它有非常大的冗余。冗余是什么呢？就是模型状态（model state）。我们知道，除了参数本身，优化器还需要存储动量、方差等状态。因此，模型状态实际上比参数占用更多的显存。

如果你使用数据并行，优化器状态在每张卡上都会存储一份，这显然非常低效。而模型并行虽然彻底分割了模型，但其通信非常密集，没那么方便。

ZeRO 这篇论文提出，我们可以将这些重复的部分拆分开。下图直观地展示了这一点。

假设基础数据并行（DP）中，每个 GPU 都拥有一套完整的参数、完整的梯度和完整的优化器状态。这图中显示，优化器状态占了主导地位。

如果你使用 ZeRO stage 1，就是将优化器状态（optimizer states）拆分开，将其分散到 N 个 GPU 上。
如果你使用 ZeRO stage 2，就是将梯度和优化器状态都拆分开。
如果你使用 ZeRO stage 3，就是将参数也拆分开。
可以看到，右侧的显存占用下降得非常厉害。

有了这些技术，我们就可以进行实际的微调了。

高效微调方法：P-Tuning v2 🎯

接下来，我们介绍一种高效微调方法：P-Tuning v2。

大家可以先回忆一下 Prompt Tuning 的做法。它的输入是提示（prompt）。你可以在输入的前面或后面添加一些连续的嵌入向量（continuous embeddings）。正常情况下，我们会将一个 token 通过嵌入层（embedding layer）变成一个向量。我们添加一些连续的可学习嵌入向量，然后在每次训练时，只训练这些添加的连续向量。

这种方法在许多大模型上效果还可以，但它有很大的局限性：其性能与直接微调相比可能还差得比较多。

因此，就有了 P-Tuning v2 这种方法。它的做法是：除了在前面添加可学习的嵌入向量外，我们在模型的每一层都加入这样的可学习参数。这些参数不参与原来的注意力计算，而是直接放置在那里。而其他部分（图中蓝色表示）则保持原样，我们不会计算它们的梯度。

这样做的好处是大大节省内存和训练时间，并且能获得较好的性能。

我们来看一下 P-Tuning v2 论文中的一个性能对比。可以看到，P-Tuning v2 与直接微调相比，取得了非常好的效果，虽然可能还差几个百分点，但非常接近。在某些情况下，它甚至能超过直接微调。

今天我们要做的示例，就是 ChatGLM-6B 官方仓库中的一个例子：一个广告生成数据集。我们要微调模型，输入是衣服的描述（例如“上衣版型”等属性），要求语言模型的输出是将其变成一段人类可读的广告词。

在克隆了 ChatGLM-6B 的官方仓库后，你需要下载一些依赖，然后下载这个数据集。接下来，我们就可以直接运行微调脚本。

这段代码基本上可以让你快速上手。第一个需要注意的是，如果有多张卡，记得配置在哪张卡上运行。quantization_bit 参数可以配置你的量化程度。如果开启量化，性能会稍微慢一点。

你还需要配置数据集的位置。然后，它就会下载模型并进行微调。如果开启了 4-bit 量化，大概需要三个小时。

关于过拟合和灾难性遗忘：因为我们的数据集很小，而模型参数量很大，所以非常容易过拟合。我们要求模型完全适应（condition on）这个广告数据集，所以它原来的知识肯定会发生灾难性遗忘。

至于如何避免过拟合，你可以尝试一些方法，例如数据增强、减少训练轮次（epoch）、或增加额外的数据集等。

如果你想训练更快一点，可以把 gradient_accumulation_steps 参数去掉。如果去掉这个参数，训练会快一些，但显存占用会相对高一些（约 13GB），不过在 RTX 3090 上也无所谓。

全量微调与 LoRA 微调 ⚡

接下来是 P-Tuning v2 的参数解释。do_train 和 do_predict 告诉模型现在是训练还是推理。train_file 和 validation_file 很明确。prompt_column 和 response_column 是指你的训练文件中，提示和回复分别由哪些键决定。

overwrite_cache 参数：你可以看到它在对数据集进行分词（tokenize），这大约需要一分钟。但在调试过程中，你会反复杀掉并重启模型，每次都进行分词非常耗时。所以如果你设置 overwrite_cache，它就会忽略缓存的存在。如果你要针对同一个数据集反复微调或调试，但数据没有变，你可以删掉缓存文件，这样它就会先检查缓存是否存在。如果有缓存，它就不会重新分词，从而很大程度上节约调试时间。如果训练数据变了，一定要加回这个参数或删除缓存，否则你会一直在用旧数据。

output_dir 是输出目录。max_source_length 和 max_target_length 的意思是，假设我们将提示分词后，其长度不能超过多少个 token。如果超过 max_source_length，它就会直接截断。max_target_length 也是一样。这样做的好处是，假设你使用一个未经处理的数据集，里面的 token 长度可能会非常长，甚至有些异常长。这时你可能会一下子刷爆显存，或者无法进行批处理（batch）。所以你必须将其限制成一个固定长度，这样我们在准备数据时，就可以将它们全部填充（pad）或截断（truncate）成一样的长度。

per_device_train_batch_size 很明确，就是每个设备上放多少个样本。gradient_accumulation_steps 在做高效微调或单卡微调时比较重要。你可以看到，P-Tuning 的噪声非常大，如果直接训练，可能无法收敛或效果很差。因此，我们模拟一个大 batch size 的效果。例如，我们让它进行 16 次前向传播，然后把这 16 次的梯度累积起来，就好像用一个大 batch 做了一次前向传播一样。

max_steps 是训练多少步。logging_steps 是每隔多少步打一次日志。save_steps 是每隔多少步保存一次。pre_seq_len 参数就是 P-Tuning v2 中添加的前缀 token 数量。

评估（evaluate）时，它会读取测试文件，让模型推理，然后将输出写入一个 txt 文件。原来的代码只会输出标签（ground truth）和预测结果。我加了一个打印，让大家可以更清楚地看到提示是什么、标签是什么、以及模型的预测是什么。这就是评估功能的简单实现。

接下来是全量微调。全量微调一定要使用 DeepSpeed，它实现了刚才提到的 ZeRO。我们来看一下全量微调的脚本。

这也是 ChatGLM-6B 仓库中的代码。首先，你需要指定模型名称或路径。事实上，用四张卡就可以跑

课程一：大模型与Prompt工程基础 🧠

在本节课中，我们将要学习大模型的基本概念、核心能力与局限性，并初步了解什么是Prompt工程。这是理解后续所有应用案例的基础。

什么是大模型？

上一节我们介绍了课程概述，本节中我们来看看大模型究竟是什么。

大模型本质上是一个概率生成模型。它通过神经网络的机制，统计语言上下文之间的相关性。在没有经过特定指令训练时，大模型的行为是基于上文来补全下文。例如，输入“天空是蓝色的，大海”，模型可能会补全为“也是蓝色的”。

既然它是概率模型，就意味着它既可能答对，也可能答错。如果问题恰好是它“读过”并牢记的，它就能答对。如果问题超出了它的“知识”范围，它就会根据概率生成一个最可能的答案，这可能导致“杜撰”或“幻觉”。例如，让它“写一个林黛玉倒拔垂杨柳的故事”，它可能会生成一个看似合理但完全虚构的故事。

从另一个角度看，今天所谓的“大模型”，其与以往NLP技术的最大区别在于参数规模非常庞大。例如，ChatGLM的当家产品有130B（1300亿）参数，而大家熟知的ChatGPT-3.5有175B参数。

参数规模“大”为何重要？研究表明，当模型参数规模逼近千亿时，人类已经很难区分其生成的内容是由机器还是由人创作的。因此，千亿参数模型被认为是进入AI时代的一张“船票”。

此外，我们今天所谈论的大模型主要分为两部分：

基座模型：就像一个读了大量书籍的高中生，拥有广泛的知识，但缺乏针对性训练。
指令模型：在基座模型基础上，通过“指令微调”进行对齐训练，就像高中生通过不断刷题来掌握答题技巧。我们日常使用大模型进行总结、写作、问答等，都是在与指令模型交互。

大模型为何强大？

了解了什么是大模型后，本节我们来看看它为何能引起如此大的变革。

首先，大模型具有能力涌现的特性。随着参数量的增长，模型在某些任务上的能力（如算术、翻译、指令遵循）会突然出现显著提升，而非平滑增长，这种现象称为“涌现”。

其次，大模型具备强大的小样本学习能力。传统NLP任务需要大量标注数据，而大模型只需极少的示例（即提示）就能学会并泛化到新任务。例如，只需给出一个“电影评论”及其情感分类的例子，模型就能对新的“手机评论”进行情感分类。

第三，大模型拥有思维链推理能力。通过在其提示中展示一步步的推理过程，可以引导模型进行复杂的逻辑推理和计算。例如，在解决“尾号限行”问题时，将分析步骤（识别尾号、对比限行规则、得出结论）作为提示的一部分，模型就能模仿这个推理链给出正确答案。

最后，大模型实现了任务、算法和数据的统一。过去，不同的NLP任务需要不同的算法和数据。如今，一个大模型通过不同的指令（Prompt），就能统一解决多种任务，极大地降低了AI应用的门槛。

大模型能做什么与不能做什么？

上一节我们探讨了大模型的强大能力，本节中我们来看看它的能力边界，明确其擅长与不擅长的领域。

借用吴军老师的抽象，大模型的能力可分为三类：

信息从少变多（生成）：根据简单信息生成周报、简历、文案、对话等。
信息从多变少（提炼）：对长文本进行总结、分类、关键信息提取等。
信息形式转化（转换）：例如翻译、将自然语言描述转化为代码（CodeGeeX）、不同文体间的转换等。

然而，大模型也有其局限性：

大模型不是搜索引擎：它无法实时获取最新知识，其知识存在滞后性，且可能杜撰信息。但它可以作为搜索引擎的辅助（如New Bing）。
大模型不是数据库：它无法像数据库一样精确存储和召回所有细节数据。它学习的是知识的模式和规律，而非原文本身。不过，它可以与外部知识库结合，通过检索增强来回答特定领域问题。

什么是Prompt工程？

讲了大模型的能力边界，我们终于可以进入核心主题：Prompt工程。

Prompt（提示词） 就是我们给大模型的指令，用于引导其生成符合我们期望的输出。最简单的Prompt就是一个问题。但为了获得更精确、更符合业务需求的答案，我们需要设计更复杂的指令。

然而，编写有效的Prompt目前存在一些挑战：

依赖个人经验：只有方法，没有固定语法，更像一门“自然语言编程”艺术。
灵活性差：一个写好的Prompt难以被他人直接复用或修改。
存在偏好分布：Prompt的效果严重依赖于其训练数据分布和具体业务场景的匹配度，需要在真实语料上进行评测和调优。
模型间差异大：为一个模型（如ChatGPT）优化的Prompt，在另一个模型（如ChatGLM）上可能效果不佳。

因此，Prompt工程是一个需要迭代的工程化过程：产生想法 -> 实现为Prompt -> 在真实场景测试 -> 分析结果 -> 优化Prompt，如此循环，才能得到稳定可用的生产级Prompt。

如何编写有效的Prompt？

了解了Prompt工程的挑战后，本节我们来看看编写Prompt的核心原则与通用结构。

编写Prompt有两个核心原则：

原则一：指令必须清晰、明确
避免使用模糊、宽泛的指令（如“讲个笑话”或“谈谈科技”）。应使用具体、明确的指令（如“用一句话解释人工智能”）。
为了确保清晰，可以使用以下工具：

分隔符：使用"""、---、<>等符号将指令、输入数据、示例等不同部分清晰分隔开。
结构化输出：使用序号、换行、键值对等形式，让指令条理清晰。

以下是使用分隔符和示例的示范：

请总结以下用三个反引号括起来的文章。
并以“要点：1. 2. 3.”的格式输出。

文章内容放在这里


法国的首都是哪座城市？

城市：巴黎


![](https://github.com/OpenDocCN/dsai-notes-zh/raw/master/docs/chatglm/img/a322993b7338d68dd3ac6e4b125d0172_15.png)

![](https://github.com/OpenDocCN/dsai-notes-zh/raw/master/docs/chatglm/img/a322993b7338d68dd3ac6e4b125d0172_16.png)

![](https://github.com/OpenDocCN/dsai-notes-zh/raw/master/docs/chatglm/img/a322993b7338d68dd3ac6e4b125d0172_18.png)

请回答：意大利的首都是哪座城市？

原则二：给模型“思考”的时间
将复杂任务分解为明确的步骤，引导模型一步步推理。这包括：

分步指令：明确列出需要模型执行的步骤。
提供思维链：在示例中展示推理过程。

一个结构良好的Prompt通常包含以下四个部分：

上下文：设定模型的角色、任务目标、必要的背景知识。
指令：清晰、具体的任务要求，可包含步骤、示例、格式等。
输入数据：需要模型处理的具体内容（如用户问题、待总结的文章）。
输出指引：对输出格式或开头的引导（如“输出类别：”）。

动手实践：第一个Prompt示例

理论需要结合实践，本节我们将通过一个简单的例子，体验Prompt的编写与迭代过程。

场景：智能音箱的备忘录功能。用户说“我儿子的生日是3月初七”，我们需要让模型理解这句话，并结构化地提取出关键信息，以便后续查询。
目标输出：意图、时间、人物、关系。

以下是优化过程：

初始尝试：

你是一个智能助手，帮我记录或查询生日信息。从以下句子中抽取出意图、时间、人物、关系。
句子：我儿子的生日是3月初七。

结果可能不准确，例如意图是“记录生日信息”（多了“生日”二字），关系是“和儿子”（不符合枚举要求）。

第一次优化（增加枚举值解释）：

你是一个智能助手...（同上）
意图只能是“记录信息”、“查询信息”、“修改信息”、“删除信息”中的一个。
关系只能是“本人”、“父亲”、“母亲”、“儿子”、“女儿”、“配偶”中的一个。

结果可能将意图误判为“查询信息”，说明解释仍不够清晰。

第二次优化（进一步明确意图判断规则）：
在指令中增加：“当用户陈述生日时，意图是‘记录信息’。”
此时内容基本正确，但输出顺序可能不符合要求。
第三次优化（提供输出示例以规范格式）：
在指令中增加一个示例：
```
示例：
输入：我爸爸的生日是五月初十。
输出：
意图：记录信息
时间：五月初十
人物：爸爸
关系：父亲
```
最终，模型能够输出格式正确、内容准确的结果。

本节课中我们一起学习了大型语言模型的基本原理、核心能力与局限，并深入探讨了Prompt工程的概念、挑战、核心原则和基本结构。通过一个智能音箱的动手示例，我们体验了Prompt从雏形到可用的迭代优化过程。理解这些基础是后续学习复杂应用案例的关键。

🚀 官方教程：GLM-4-9B 实战部署和微调 - P1

在本节课中，我们将学习如何部署和微调 GLM-4-9B 开源模型。课程内容涵盖模型下载、部署配置、常见问题解决以及微调数据集的构建与训练。

📥 模型下载与简介

首先，我们需要获取 GLM-4-9B 模型。模型可以从 ModelScope 或 Hugging Face 平台下载，两个平台的模型权重是同步的。

以下是不同模型文件的区别：

glm-4-9b：这是一个基座模型，不支持对话，上下文长度为 8K。
glm-4-9b-chat 与 glm-4-9b-chat-1m：这两个都是对话模型，具备工具调用能力。前者支持 128K 上下文，后者支持 1M 上下文。
glm-4v-9b：这是一个视觉问答模型，支持 8K 上下文，在一个对话中仅支持处理一张图像。

在下载时，请确保使用最新的代码仓库（例如支持 Flash Attention 2 的版本），模型权重本身无需更新。

⚙️ 模型部署实践

上一节我们介绍了如何下载模型，本节中我们来看看如何进行部署。我们重点推荐使用类 OpenAI API 的服务器进行部署，这能极大地方便与 LangChain 等开源框架的集成。

该部署方案基于 vLLM 后端，支持流式与非流式输出。以下是部署时需要注意的几个核心点：

工具调用限制：在当前的演示中，单次请求仅支持调用一个工具。
上下文长度设置：默认设置为 8K 以适配 24G 显存的显卡。如果你的显存更大（如 80G），可以适当调高此值，反之则需调低以防显存溢出。
微调模型加载：此演示未直接适配微调后的模型（如 LoRA 权重）。如需加载，请参考 vLLM 官方教程合并权重，并仅修改模型加载部分的代码。
停止符设置：为确保模型正常停止生成，必须正确设置停止符。GLM-4-9B 包含三个特殊的停止符 ID：1511329 (end of text), 1511336 (user), 1511338 (observation)。在官方演示代码中已正确配置。
推理精度：强烈推荐使用 BF16 精度进行推理。FP16 有极低概率出现问题，而训练/微调时则必须使用 BF16，使用 FP16 会导致损失值变为 NaN（精度溢出）。

部署的核心代码示例如下，展示了如何设置 GPU 内存限制、上下文长度和停止符：

# 设置 vLLM 引擎参数
from vllm import LLM, SamplingParams

llm = LLM(
    model="THUDM/glm-4-9b-chat",
    tensor_parallel_size=1,  # 使用单张 GPU
    gpu_memory_utilization=0.9,  # GPU 显存利用率，可根据需要调整
    max_model_len=8192,  # 最大模型长度，防止显存溢出
    stop_token_ids=[1511329, 1511336, 1511338]  # 设置停止符 ID
)

![](https://github.com/OpenDocCN/dsai-notes-zh/raw/master/docs/chatglm/img/4d13edbd47db261637678d5c7b6a739c_17.png)

![](https://github.com/OpenDocCN/dsai-notes-zh/raw/master/docs/chatglm/img/4d13edbd47db261637678d5c7b6a739c_19.png)

# 启用 Flash Attention 2 (需在 BF16/FP16 下)
# llm = LLM(..., enforce_eager=True, ...) # 通常无需手动设置

🛠️ 模型微调指南

了解了部署后，我们进入模型微调环节。微调的关键在于准备格式正确的数据集。

数据集格式

数据集的构建有两种类型：

1. 非工具微调数据集
格式与 OpenAI 的 messages 格式完全一致，角色包括 system, user, assistant。多条这样的对话组成一个 JSONL 文件。

2. 工具微调数据集
格式相对复杂，核心结构如下：

system 的 content 必须为空字符串。模型会使用内置的系统提示词来处理工具调用。
tools 字段描述工具的定义，格式与 OpenAI API 相同。
工具执行结果的返回角色是 observation，而非 OpenAI 格式中的 tool。

一个最小的工具调用数据单元示例：

{
  "messages": [
    {"role": "system", "content": ""},
    {"role": "user", "content": "查询北京今天的天气。"},
    {"role": "assistant", "content": null, "tool_calls": [{"function": {"name": "get_weather", "arguments": {"city": "北京"}}}]},
    {"role": "observation", "content": "{\"weather\": \"晴朗\", \"temperature\": 22}"},
    {"role": "assistant", "content": "北京今天天气晴朗，气温22摄氏度。"}
  ],
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_weather",
        "description": "获取指定城市的天气信息",
        "parameters": {...}
      }
    }
  ]
}

数据处理与训练

我们的代码库提供了完整的数据处理和训练脚本。数据处理的核心是 apply_chat_template 方法，它会为每条消息添加特殊的起始符（如 1511331, 1511333），并正确设置损失掩码（不计算损失的部分标签设为 -100）。

训练启动非常简单。以下是单卡启动 LoRA 微调的示例命令：

CUDA_VISIBLE_DEVICES=0 python src/train_bash.py \
    --dataset_dir /path/to/your/data \  # 数据集路径
    --model_name_or_path THUDM/glm-4-9b-chat \  # 基础模型路径
    --stage sft \  # 训练阶段
    --do_train \
    --finetuning_type lora \  # 微调类型
    --output_dir /path/to/save/output \  # 输出目录
    --overwrite_cache \
    --per_device_train_batch_size 4 \
    --gradient_accumulation_steps 4 \
    --lr_scheduler_type cosine \
    --logging_steps 10 \
    --save_steps 1000 \
    --learning_rate 5e-5 \
    --num_train_epochs 3.0 \
    --plot_loss \
    --fp16  # 注意：此处应为 bf16，示例命令可能需调整

训练完成后，可以使用提供的推理脚本加载微调后的模型进行检查。

📝 总结与答疑

本节课中我们一起学习了 GLM-4-9B 模型的下载、部署和微调全流程。

核心要点总结：

部署：推荐使用类 OpenAI API 的服务器，便于集成，需注意停止符、上下文长度和推理精度的设置。
微调：严格按照指定格式准备数据集，工具微调时 system 内容需留空。代码库提供了开箱即用的训练脚本。
硬件：请根据模型类型和上下文长度需求评估显存。例如，GLM-4V-9B 需按 13B-14B 量级的模型来估算显存。

常见问题与未来计划：

已知问题：正在适配 Ollama、llama.cpp、TensorRT-LLM 等推理框架。
未来计划：将推出支持 Windows 的 OpenAI 格式演示，并持续优化多模态模型微调等。

如果在实践过程中遇到问题，欢迎在项目的 GitHub Issue 中提出，我们会尽快响应和处理。

本节课到此结束。希望这份教程能帮助你顺利开始使用 GLM-4-9B 模型。

课程 P1：智谱AI新一代视频生成模型 CogVideoX 🎬

在本节课中，我们将学习智谱AI发布的新一代生成式视频模型 CogVideoX 及其核心应用 “清影”。我们将探讨其技术特点、背后的多模态理念，并了解如何实际使用它来生成视频。

概述：为什么需要多模态大模型？🧠

上一节我们介绍了课程主题，本节中我们来看看多模态大模型的重要性。人类大脑是一个复杂系统，其认知功能通过各脑区相互配合完成，不仅包括文字语言，还包括视觉理解、听觉等。因此，多模态的感知和理解与认知能力的发展有非常密切的关系。

作为一家以AGI为目标的人工智能公司，智谱AI一直非常重视多模态技术。物理学大师费曼曾说过：“不创造一个东西就不会理解一个东西。”这句话非常适合用来形容智谱在多模态领域的观点。从文字、图像到视频内容，这既是一个模态逐渐丰富的过程，也是一个大模型对世界的理解逐渐复杂化、多维化的过程。

智谱的团队从2021年开始布局文生图和文生视频模型，先后研发了 CogView、CogVideo、Relay Diffusion 等多个模型。

技术演进：从 CogView 到 CogVideoX 🚀

上一节我们探讨了多模态的重要性，本节中我们来看看智谱AI在多模态领域的技术发展路径。

第一代的 CogView 使用了单向的Transformer结构，对成对的文本和图像进行了深层次的预训练。它在2021年发布时，在所有指标上都超过了OpenAI同期推出的DALL·E模型。而最新的 CogView3 的性能也与 DALL·E 3 旗鼓相当。

今天，我们很高兴向大家汇报在多模态领域的又一阶段性成果：全新升级的生成式视频模型 CogVideoX。

CogVideoX 的核心技术特点 ⚙️

上一节我们回顾了技术演进，本节中我们将深入剖析CogVideoX的几个关键技术突破。

以下是CogVideoX的主要技术特点：

高效三维视频压缩与长程依赖建模
为了解决内容连贯性的问题，智谱自研了一个高效的三维变分自编码器结构，称为 3D-VAE。该结构能将原始视频空间压缩至原大小的2%，大大减少了视频扩散生成模型的训练成本和难度。配合上 3D RoPE 位置编码模块，更有利于在时间维度上捕捉帧间关系，建立起视频中的长程依赖。

强大的指令遵循与可控性
智谱自研了一个端到端的视频理解模型，用于为海量的视频数据生成详细且贴合内容的描述文本。这样可以增强模型的文本理解和指令遵循能力，使得生成的视频更符合用户的输入，能够理解超长、超复杂的Prompt指令。

创新的多模态融合架构
模型采用了将文本、时间、空间三个维度全部融合起来的Transformer架构。它摒弃了传统的Cross-Attention模块，并设计了 Expert Block 来将文本和视频两个不同模态的空间进行对齐，以及进行更好的模态交互。

当然，这个技术的研发过程本身充满各种挑战和难度。但今天，智谱又一次验证了 Scaling Law 在视频生成方面的有效性。未来，智谱会在继续扩大数据规模和模型规模的同时，探究更具突破性创新的新型模型架构，更高效地压缩视频信息，更充分地融合文本和视频内容。

产品发布：AI视频生成功能“清影”正式上线 🎉

上一节我们了解了核心技术，本节中我们来看看这些技术如何转化为用户可用的产品。

俗话说，百闻不如一见。从此刻开始，“清影” 视频生成功能在智谱清言的PC、APP端以及小程序端全面正式上线。所有用户都能通过清言APP，免费体验AI文生视频、图生视频的能力。

这就是智谱AI的风格：全量上线，不限量使用。

无论是没有视频制作基础的普通用户，还是专业的视频内容创作者，大家现在就可以在PC端和移动端进行体验。

“清影”功能特点与演示 🎬

上一节我们宣布了产品上线，本节中我们通过具体演示来看看“清影”的几个突出特点。

以下是“清影”的几个核心特点：

生成速度快
理论上，清影每生成6秒的视频，只需要花费约30秒的时间。现场演示了输入Prompt“写实地描绘近距离猎豹卧在地上睡觉，身体微微的起伏”，模型在短时间内就生成了符合描述的视频。

支持多种输入方式
除了用文字作为Prompt输入生成视频，还可以利用图片作为输入来生成动态视频。现场演示了输入一张花的图片，模型生成了花朵在几秒钟内盛开的逼真场景。

优秀的指令遵循能力
基于强大的技术，清影能够很好地理解并执行复杂的Prompt指令。例如，对于描述“赛博朋克城市夜景中，机械小猴子用高科技设备维修……”的长Prompt，生成的视频对所有描述元素都进行了很好的呈现。
良好的内容连贯性
基于自研技术，生成的视频可以较好地还原物理世界中的运动过程。例如，让古画中的杜甫自然地端起一杯咖啡。

支持大幅度的画面调度
生成的视频可以实现流畅的镜头移动，例如镜头跟随三只狗移动，效果如同真人跟拍。

当然，今天的生成式视频模型才刚刚起步，整体还有很大的进步空间。但我们已经收到了来自电商广告、影视特效等众多产业场景的实际需求。

开放生态：面向开发者与企业 🏢

上一节我们展示了C端产品的特点，本节中我们来看看面向开发者和企业的开放能力。

除了面向普通用户的“清影”，智谱AI同样在大模型开放平台 bigmodel.cn 上上线了生成式视频模型的API。企业和开发者可以通过调用API的方式，体验并使用 CogVideoX 的文生视频以及图生视频能力。这在国内尚属首次。

近期，我们也邀请了部分第三方创作者提前内测模型能力，并看到了许多优秀的创作作品。

未来展望与总结 🌟

在本节课中，我们一起学习了智谱AI新一代视频生成模型 CogVideoX 及其产品“清影”。

我们首先探讨了多模态大模型对于实现通用人工智能（AGI）的重要性。接着，回顾了智谱从 CogView 到 CogVideoX 的技术演进路径。然后，深入剖析了 CogVideoX 在视频压缩（3D-VAE）、指令遵循和模态融合架构（Expert Block）等方面的核心技术突破。

我们看到，这些技术最终落地为面向广大用户的“清影”产品，它具备生成速度快、指令理解强、画面连贯性好等特点，并支持文生视频和图生视频。同时，智谱也通过开放平台将能力提供给开发者和企业，构建更丰富的应用生态。

随着“清影”功能的加入，智谱清言已成为市场上少有的集对话、代码、智能体、生成式图片和视频于一体的全功能AI智能助手。未来，我们将继续迭代，推出更高分辨率、更长时长的生成式视频功能。

人工智能行业对多模态模型的探索还处于初级阶段，CogVideoX 还将不断迭代。智谱AI会继续努力，为大家提供更好的模型和产品。

课程一：认识「清影」AI视频生成工具 🎬

在本节课中，我们将要学习一个名为「清影」的AI视频生成工具。它旨在让每个人都能轻松地使用人工智能技术来创作视频内容。我们将了解它的基本概念、核心功能以及它能为我们带来什么。

什么是「清影」？✨

上一节我们介绍了本课程的主题。本节中，我们来看看「清影」究竟是什么。

「清影」是一个利用人工智能技术生成视频的工具。它的目标是降低视频制作的技术门槛，让没有专业背景的用户也能创作出有趣的视频内容。其核心在于通过简单的输入（如文本或图片），由AI模型自动生成对应的动态视频。

其背后的核心概念可以简化为一个公式：
用户输入（文本/图像） + AI模型 = 生成视频

「清影」能做什么？🚀

了解了基本定义后，本节我们来看看「清影」具体具备哪些能力。

以下是「清影」工具的一些主要功能和应用场景：

文生视频：用户输入一段描述性文字，AI根据文字内容生成相应的视频片段。
图生视频：用户上传一张静态图片，AI能够让图片中的元素动起来，生成短视频。
创意辅助：为视频创作者提供灵感，快速生成视频素材或预览效果。
简化流程：将复杂的视频剪辑、特效制作过程，简化为几步简单的操作。

如何使用「清影」？🛠️

知道了它能做什么，接下来我们了解一下大致的操作流程。虽然具体步骤会因平台而异，但通常遵循以下模式：

以下是使用「清影」生成视频的一个基本流程示例：

打开工具：访问「清影」的官方网站或应用。
选择模式：在“文生视频”或“图生视频”模式中选择其一。
输入内容：
- 如果选择“文生视频”，在输入框内填写你的创意描述。
- 如果选择“图生视频”，上传你的图片文件。
调整参数：设置视频风格、时长、分辨率等可选参数。
生成视频：点击生成按钮，等待AI处理并输出视频结果。
下载分享：对生成的视频满意后，可以下载到本地或直接分享。

这个过程可以用一段伪代码来描述：

打开工具(“清影”)
选择模式(模式=”文生视频”)
输入内容(文本=”一只猫在弹钢琴”)
调整参数(风格=”卡通”， 时长=”10秒”)
视频结果 = 生成视频()
下载(视频结果)

总结 📝

本节课中，我们一起学习了「清影」AI视频生成工具。我们首先了解了它是一个旨在普及化AI视频创作的工具，然后探讨了其核心的“文生视频”和“图生视频”功能，最后梳理了使用它的基本步骤。记住其核心公式 输入 + AI = 视频，你就能理解它的工作原理。希望这节课能帮助你迈出使用AI进行创意表达的第一步。

第一课：从GPT快速迁移到ChatGLM 🚀

在本节课中，我们将学习如何将现有的、基于OpenAI GPT模型的代码，快速迁移到使用智谱AI的ChatGLM模型。整个过程只需修改少量配置，无需重写核心业务逻辑。

快速迁移指南 ✨

上一节我们介绍了课程目标，本节中我们来看看具体的迁移步骤。只需修改三处变量，即可在30秒内完成迁移。

以下是实现快速迁移的三个关键步骤：

修改API密钥：将OpenAI的API密钥替换为智谱AI平台的API Key。你需要提前将智谱API Key设置到环境变量中。
修改API基础地址：将OpenAI的调用端点（api.openai.com）替换为智谱AI开放平台的地址（open.bigmodel.cn）。
修改模型名称：将请求中指定的GPT模型名称（如gpt-3.5-turbo）替换为智谱GLM模型名称（如glm-4-0520）。

迁移后的核心代码示例如下：

# 导入OpenAI SDK（无需更改）
from openai import OpenAI

# 1. 修改API密钥（假设已设置环境变量ZHIPU_API_KEY）
client = OpenAI(
    api_key="你的智谱API Key",  # 或使用 os.environ.get("ZHIPU_API_KEY")
    base_url="https://open.bigmodel.cn/api/paas/v4/"  # 2. 修改基础地址
)

# 发起调用
response = client.chat.completions.create(
    model="glm-4-0520",  # 3. 修改模型名称
    messages=[
        {"role": "user", "content": "你好"}
    ]
)
print(response.choices[0].message.content)

可以看到，除了上述三处修改，其他业务代码完全保持不变。

ChatGLM与GPT的差异与优势 ⚖️

在成功迁移后，了解两个平台之间的主要差异和GLM的特色优势，有助于你更好地规划业务。

以下是ChatGLM与GPT的一些关键差异点，请注意提前规划：

输入输出长度：GLM-4模型支持128K上下文输入，但最大输出默认为4K token。若有8K或更长输出的需求，可联系商务咨询。这与GPT支持128K输出的能力目前存在差异。
Embedding模型：智谱的Embedding-3模型支持最大文本长度为2048 token，向量维度为1024。OpenAI的text-embedding-ada-002模型则支持8192 token和1536维度。
特定参数支持：部分GPT已支持的参数，GLM暂未完全支持。例如：
- 通过response_format指定JSON格式返回。
- 使用presence_penalty和frequency_penalty精确控制文本重复性。
- 设置top_p=0（会报错）。但可通过设置do_sample=False实现类似“确定性输出”的效果。

以下是ChatGLM提供的额外优势和服务：

更长的上下文：GLM模型最长可支持1M（约100万）token的上下文，具体可咨询商务开通。
丰富的模型矩阵：提供从十亿、百亿到千亿参数的不同规模模型（如GLM-4-Flash, GLM-4-Air, GLM-4），满足从高速响应到复杂推理的不同业务场景。
本地化服务：服务国内客户，提供人工客服、工单系统、专属服务群和专业的技术支持。
全面的能力支持：除通用对话外，还支持图像理解（CogView）、拟人化对话、工具调用（Function Call）、代码解释、联网搜索、知识库检索以及文生图等多种能力。

开发者资源与模型介绍 📚

上一节我们对比了差异，本节我们来了解可用的开发资源和最新的GLM-4模型系列。

开发者资源中心：
你可以访问智谱AI开放平台获取所有开发资源。此外：

GitHub上提供了Python、Java、C#、Node.js等多种语言的官方SDK。
提供官方的使用指南和代码示例（Cookbook）。
由于协议兼容，你完全可以继续使用OpenAI官方SDK来调用GLM模型，正如我们在迁移指南中所做的那样。

GLM-4新模型系列：
GLM-4系列模型在性能上已接近GPT-4，并在长上下文、工具调用等方面表现优异。该系列主要分为三个型号：

GLM-4-Flash：速度最快，性价比高（0.1元/百万tokens），适用于长文本分析、总结、信息抽取等场景。
GLM-4-Air：平衡速度与效果的高性价比选择。
GLM-4 (如glm-4-0520)：能力最强（1元/百万tokens），适用于复杂的逻辑分析、智能体（Agent）应用、严格的指令遵循等场景。

对于企业客户，智谱AI还提供线上最低六折的折扣。如果需要通过批处理（Batch）进行离线大批量调用，也可联系获取相应支持。

总结 🎯

本节课中我们一起学习了如何从GPT快速迁移到ChatGLM。核心在于修改API密钥、基础地址和模型名称这三处配置。我们还探讨了GLM与GPT的主要差异，并介绍了GLM在模型多样性、本地化服务以及GLM-4新模型系列上的优势。利用这些知识和资源，你可以轻松地将现有应用切换到更符合国内需求的ChatGLM平台。

课程名称：智能体Builder时代入门 - P1

概述

在本节课中，我们将一起探讨大模型与智能体的基本概念，理解它们为何代表了一次重大的技术变革。我们将从宏观视角出发，分析大模型的核心特点，并厘清“智能体”这一关键概念的定义与分类。最后，我们将通过几个简单的实战案例，展示如何无需编程，仅用自然语言就能创建属于自己的智能体应用。

第一部分：理解大模型——一次技术大变革

上一节我们概述了课程内容，本节中我们来看看为什么大模型如此重要。

我认为，大模型可能是我们这一代人遇到的最大的一次技术变革，其影响可能远超互联网、移动互联网等技术浪潮。

大模型的核心特点

以下是理解大模型重要性的三个关键视角：

1. 通用性与潜力巨大
大模型最直观的理解方式，是将其类比为人脑。它是由海量人工神经元（参数）组成的网络。其底层逻辑是仿造人类智能。更关键的是，研究发现的“规模定律”表明，只要持续扩大模型规模、算力和数据，其智能水平就会近乎线性地提升，目前还看不到上限。这意味着大模型具有达到乃至超越人类通用智能水平的巨大潜力。

2. 普惠性与易用性
大模型的使用门槛极低。像ChatGPT或质朴清言这样的产品，用户只需用自然语言提问和交流即可，无需编写代码或进行复杂配置。这种普惠性意味着，未来每个人都可以低成本地配备多个由大模型驱动的“数字实习生”。个人与企业的竞争力，可能将取决于你能否有效管理和运用这些“数字助手”。

3. 革命性的交互方式
大模型是历史上第一个能真正“听懂”并“讲出”人话的计算机系统。这预示着交互方式的根本性变革。未来的AI原生产品将主要依靠自然语言交互，就像人与人对话一样。这可能进一步推动硬件形态的变化，例如更轻便的AR眼镜、耳机等设备将成为主流交互入口，传统的图形界面操作比重将下降。

第二部分：厘清概念——什么是智能体？

上一节我们探讨了大模型的变革性，本节中我们聚焦于另一个热词——“智能体”。

目前，“智能体”的概念相当混乱。我们需要回到其学术本源来理解。

在人工智能经典教材《人工智能：现代方法》中，智能体是贯穿全书的主题。其定义是：从环境中接收感知并执行动作的实体。因此，人工智能在某种程度上就是研究智能体的学科。

智能体的关键在于“能动”，并能根据环境感知做出判断和行动。相比之下，传统软件是“死”的，功能固定，难以随用户需求即时调整。而智能体应能像人一样，根据用户指令灵活适应和改变。

为什么智能体现在火了？

智能体的概念早已有之，近期火热主要源于OpenAI等机构的推动。其内部人士曾表示，他们格外关注智能体相关的研究。一种主流的智能体定义是：以大模型为核心控制器，通过附加组件（如记忆、规划、工具使用等能力）来扩展大模型潜力的系统。

当前许多工作都围绕弥补大模型的短板展开（如记忆短、规划弱）。但随着大模型自身能力不断增强，这些外部组件可能会逐渐变薄甚至内化。长期来看，智能体与大模型的发展密不可分。

智能体的分类展望

我们可以将智能体放入一个更广阔的框架中分类理解：

软件智能体：这是当前发展的重点。
- 单智能体：如ChatGPT本身，或在其中创建的定制化助手。这是我们本节课实战的核心。
- 多智能体：由多个智能体协作的系统（如AutoGPT）。目前尚不成熟，更像前瞻性探索。
硬件智能体：即机器人，包括人形机器人、自动驾驶汽车等具身智能。
生物智能体：人类自身，以及经过训练的动物等。

未来的社会，将是人、软件智能体、机器人协同合作的“人机混合多智能体社会”。

第三部分：实战入门——人人都是Builder

上一节我们梳理了智能体的理论框架，本节中我们进入最激动人心的部分：动手创建你的第一个智能体。

一个核心观点是：最热门的新“编程语言”是英语（自然语言）。大模型正在重塑技术栈。传统的复杂技术层（芯片、操作系统、编程）可能被大模型和自然语言交互所简化。未来的软件形态可能就是“智能体”，而创建它可能不再需要传统编程，只需“会说话”、“会教学”。

这开启了“人人都是Builder（建造者）”的时代。你的竞争力将体现在两方面：在特定领域的深厚经验与知识（成为专家），以及将这些知识有效“教”给大模型的能力（提示工程）。在垂直领域成为专家，并打造一个出色的智能体，可能成为一种新的职业路径。

实战案例演示

以下，我将通过质朴清言平台演示三个智能体的创建过程。请注意，创建功能目前主要在网页端进行。

案例一：翻译神器

目标：创建一个智能体，用户只需粘贴原文、上传文件或链接，它就能自动翻译，无需额外指令。
创建过程：
1. 在创建界面输入简单描述：“作为一个翻译助手，用户只需提供原文、文件或链接，即可自动获得翻译，无需更多指令。”
2. 系统自动生成智能体配置（名称、描述、内部指令）。
3. 检查并微调配置，确保符合预期。
4. 保存后即可使用。测试时，直接粘贴英文链接，智能体会自动抓取内容并翻译。

案例二：绘图神器

目标：用户直接描述图片需求，智能体自动调用文生图功能，无需说“请画一张图”。
创建过程：
1. 输入描述：“作为一个绘图助手，用户直接描述图片需求，即可自动生成图片。”
2. 系统生成配置。调试时，直接输入“盲人摸象”，智能体便生成相应图片。

案例三：哄哄神器

目标：创建一个模拟哄伴侣的游戏智能体，根据用户回答进行评分互动。
创建过程：
1. 输入一段较长、结构化的自然语言描述，定义角色、规则、评分机制和对话示例。
2. 这段描述本身就是复杂的“提示词”，但完全由人话构成，无需代码。
3. 保存后，用户即可与智能体进行互动游戏。例如，输入“生日忘记买礼物了怎么办”，智能体会根据设定规则进行评判和反馈。

通过以上案例可以看到，创建功能各异的智能体，核心在于用清晰、结构化的自然语言向大模型描述你的需求。这正是“用英语编程”的体现。

总结

本节课中，我们一起学习了以下内容：

大模型的变革性：从通用潜力、普惠易用、自然交互三个角度，理解大模型为何是颠覆性技术。
智能体的本质：智能体是能感知环境并执行动作的实体。当前主流是以大模型为核心、增强其能力的系统。它可分为软件、硬件、生物等类别。
成为Builder：大模型降低了创造数字产品的门槛。未来，在垂直领域积累专业知识，并善于通过自然语言（提示工程）将知识“传授”给大模型以构建智能体，可能成为重要的个人技能。

技术发展日新月异，今天的观点未来可能被修正。但毫无疑问，积极了解、使用并尝试创造大模型与智能体，是面向未来的一项重要准备。希望你能从今天开始，动手尝试创建你的第一个智能体。

课程名称：CogVideoX视频生成模型详解与部署指南 - P1

概述 📖

在本节课中，我们将全面学习由智谱AI开源的CogVideoX视频生成模型。课程将分为三个主要部分：首先，深入解析模型的核心算法与架构设计；其次，提供清晰、直白的模型部署与推理教程；最后，介绍未来的开源计划与社区贡献方向。无论你是初学者还是有一定经验的开发者，本教程都将帮助你理解并上手这一先进的视频生成技术。

第一部分：算法核心解析 🧠

上一节我们概述了课程内容，本节中我们来看看CogVideoX模型背后的核心技术。

1.1 Cog系列模型发展历程

CogVideoX并非凭空诞生，它建立在智谱AI在生成模型领域多年的技术积累之上。

以下是Cog系列模型的关键发展节点：

2021年：团队开始使用大规模Transformer预训练文生图模型，采用自回归（Auto Regressive） 技术，将图像分块并按序生成。该技术已能生成“现实中不存在的物体”，例如“老虎踢足球”。
同年改进：针对自回归速度慢的问题，改进为半自回归模型CogView2，在生成效果上取得了显著提升。
同年开源：发布了当时开源领域最大、效果最好的文生视频模型 CogVideo。CogVideoX正是这一系列的传承与发展。
技术栈迁移：将技术栈迁移到Diffusion（扩散模型） 上，推出了CogVideo3模型，在当时超越了其他开源模型。
当前模型：今天的主角CogVideoX，其架构结合了Diffusion与Transformer，在生成效果和评测指标上均达到了开源模型的最佳水平。

1.2 核心模块一：3D Transformer with Full Attention

CogVideoX使用一个特殊的3D Transformer进行文生视频的生成。其核心创新在于文本与视频Token的融合处理方式。

以下是该结构的设计要点：

联合输入：将文本和视频压缩后的Token拼接（Concat）在一起，共同输入到Transformer中。
共享与分离：文本和视频Token会经过相同的Self-Attention和Feed-Forward网络层。但在进行Layer Norm操作时，会使用两组不同的参数，分别称为 text expert adaptive layer norm 和 vision expert adaptive layer norm。
设计考量：这种结构旨在增强模型的语义理解能力。传统模型通常只让图像特征通过Transformer主体，文本仅通过Cross-Attention交互，导致文本理解不够深入。借鉴Swin Transformer的设计，CogVideoX让文本也充分参与前向计算。
Full Attention的优势：模型采用了Full Attention（全注意力） 机制，而非时空分离的Attention。这是因为当物体在视频中大幅运动时（例如，人物从第一帧的左侧移动到第二帧的右侧），时空分离的Attention需要隐式地、多步传递信息才能建立关联，而Full Attention可以直接建模任意两个时空位置的关系，效率更高。

1.3 核心模块二：3D VAE（视频变分自编码器）

视频的连续性与流畅度至关重要，CogVideoX通过3D VAE解决了这一问题。

以下是3D VAE的关键特性：

解决闪烁问题：之前的模型使用2D VAE对视频逐帧压缩，会导致帧间不连续，画面闪烁。3D VAE能保证视频的时空连续性，并获得更高的压缩率。
结构核心：主要区别在于将2D卷积（Conv2D）替换为3D卷积（Conv3D）。
因果卷积：在时间维度上采用了因果卷积（Causal Convolution），即每一帧在卷积时只参考其之前的时间帧，不参考未来帧。这符合视频的时序因果关系，并且使得该VAE也能对单张图像进行压缩。
训练挑战与优化：训练3D VAE显存消耗巨大。团队采用了时间上下文并行（Temporal Context Parallel） 策略进行优化。简单来说，将长视频序列分到多张GPU上，每张卡处理一个片段，并通过通信传递相邻片段边界的几帧信息，从而在训练时实现时间维度的并行，显著降低了单卡显存占用。

第二部分：数据处理、训练与快速上手 🚀

上一节我们介绍了模型的核心算法模块，本节中我们来看看其背后的数据工作流、训练策略，以及如何快速部署运行模型。

2.1 高质量视频描述数据生成

对于生成模型，高质量的训练数据是成功的关键。视频数据的文本描述（Caption）尤其重要。

以下是CogVideoX的数据处理流程：

问题：互联网上的视频-文本对通常质量不高，匹配性差。
目标：需要生成能详细描述视频内容（包括动态信息）的文本，使模型具备强大的语义理解能力。
Pipeline V1：初期方案较为复杂。首先对视频抽帧，用智谱自研的图片理解模型CogVLM生成图像描述；同时，使用开源视频理解模型Video-LLaMA生成包含动态信息的短视频描述；最后，用一个大语言模型（LLM）对上述描述进行总结，得到最终的长视频描述。
Pipeline V2（端到端）：为了简化流程，团队使用V1产出的数据对开源的CogVLM2-Video模型进行微调，得到了一个端到端的视频描述生成模型，该模型已开源。
推理提示：由于训练时使用了详细描述，因此在推理时，也建议用户输入尽可能详细的提示词（Prompt），以最大程度激发模型能力。

2.2 渐进式与混合训练策略

训练视频模型需要海量数据，如何高效组织训练是一个挑战。

以下是CogVideoX采用的训练策略：

图像-视频联合训练：为了充分利用图像数据并让模型学习静态先验，采用了图像与视频联合训练。
Pastion Pack方法：传统方法将单张图片与固定帧数的视频一起训练，存在序列长度上的差异（Gap）。CogVideoX将不同时长（2帧、3帧、4帧...）的视频与图片一起训练。为了高效批次训练，采用了Pastion Pack方法，将不同长度的序列打包到同一个长序列中，减少了因填充（Padding）造成的计算浪费。
渐进式训练（Progressive Training）：借鉴图像生成经验，采用渐进式训练策略。先在低分辨率数据上训练，让模型快速学会语义理解和粗粒度动态建模；然后在高分辨率数据上训练，学习细节生成；最后在高质量数据上进行微调，进一步提升效果。

2.3 模型部署与推理指南（Diffusers版）

了解了算法和训练后，本节我们来看看如何快速上手运行模型。推荐使用Diffusers库，它提供了标准化的接口。

以下是使用Diffusers库推理的关键步骤和注意事项：

环境准备：安装Diffusers 0.30或更高版本 (pip install diffusers)。模型已上传至Hugging Face、ModelScope等平台。
提示词优化：模型针对长而详细的提示词进行了优化。团队提供了提示词润色代码，可以使用GPT-4等大模型将简短提示词扩展为详细描述。

核心代码示例：

# 1. 导入管道
from diffusers import CogVideoXPipeline
# 2. 启用CPU卸载，这是单卡（如3090）运行的关键，可将峰值显存从36G降至约24G
pipe = CogVideoXPipeline.from_pretrained("THUDM/CogVideoX-2B", torch_dtype=torch.float16).to("cuda")
pipe.enable_model_cpu_offload()
# 3. 准备提示词（建议使用润色后的长提示词）
prompt = "A detailed description of your scene..."
# 4. 生成视频
video_frames = pipe(prompt, num_inference_steps=50, guidance_scale=6.0).frames[0]

重要参数：
- num_inference_steps=50：推理步数，不建议减少，否则影响质量。
- guidance_scale=6.0：指导系数，不建议修改。
- negative_prompt：负向提示词效果有限，目前主要使用正向提示词。
硬件要求：单张RTX 3090（24G）或4090显卡即可流畅推理。需确保显存几乎无其他占用。
多卡推理：注释掉 enable_model_cpu_offload() 一行即可，但峰值显存需求仍在，需根据显存规划。

2.4 模型部署与推理指南（SAT版）

除了Diffusers，还可以使用智谱自研的Swift-Armory Transformer (SAT) 框架进行推理和微调。

以下是SAT版本的特点与注意事项：

优势：显存占用更低（约18G），代码结构更简洁，更适合学术研究和底层修改。微调支持完善。
模型下载：权重存放在清华云盘，需单独下载Transformer和VAE两部分，并组合。
T5文本编码器：需要从Hugging Face获取T5-v1_1-xxl模型，并推荐转换为safetensors格式以提升兼容性。
运行限制：SAT依赖Triton等库，目前仅支持Linux系统。Windows用户请使用Diffusers方案。
提示词：SAT的示例脚本未内置提示词润色功能，需直接输入详细提示词。

第三部分：开源计划与社区共建 🌱

上一节我们完成了模型的部署教学，本节中我们将一起了解CogVideoX的未来发展路线和社区参与方式。

3.1 近期开源计划

团队致力于持续推动开源生态的发展。

以下是已公开的计划：

更大规模模型：将开源参数量更大、能力更强的CogVideoX模型，并与当前2B版本架构兼容，便于现有代码迁移。
框架与工具完善：
- 持续优化Diffusers库集成，包括显存优化和新模型适配。
- 适配XInference等部署框架。
- 在项目首页展示并推荐优秀的社区二次开发项目（如CFUI等）。

3.2 社区贡献指引

CogVideoX的成功离不开社区的共同努力。

以下是鼓励社区参与的方向：

算法与性能：
- 在非CUDA架构（如AMD GPU、NPU）上的测试与适配。
- 低精度量化（如Int4）的探索。
应用与工具链：
- 开发视频超分辨率、插帧等后处理工具，提升生成视频的帧率与分辨率。
- 基于CogVideoX开发有趣的Demo和完整的上层应用。
模型微调与下游任务：
- 使用提供的代码对模型进行LoRA微调，定制个性化风格。测试表明，在百段视频数据内微调几十个Epoch即可获得不错效果。
- 开发ControlNet等可控生成功能。
- 探索图生视频等扩展任务。

团队欢迎所有形式的贡献，并将优秀贡献展示在项目首页。遇到问题或有好建议，推荐在GitHub仓库提交Issue或Pull Request。

总结 🎯

本节课中我们一起学习了CogVideoX视频生成模型的完整知识体系。我们从其3D Transformer with Full Attention和3D VAE的核心算法开始，理解了模型如何实现高质量的文生视频。接着，我们探讨了其背后的高质量数据生成Pipeline和渐进式混合训练策略。然后，我们提供了两种清晰的部署方案：标准化的Diffusers库方案和更灵活、显存友好的SAT框架方案，并明确了单卡3090/4090即可运行的条件。最后，我们展望了未来的开源计划，并鼓励社区在算法优化、工具链开发和模型微调等方面共同参与建设。希望本教程能帮助你顺利踏入视频生成的大门。

Agent工作流课程 - P1：如何实现完全可控的Agent应用 🚀

在本节课中，我们将学习如何构建一个“完全可控”的AI智能体（Agent）。我们将从一个具体的例子——日程助手出发，剖析如何将一个复杂的任务拆解为稳定、可预测的工作流。课程内容将涵盖核心概念、设计思路以及实践中的关键考量。

概述：为什么“可控”至关重要

在将AI应用于商业场景，尤其是像销售这样的关键领域时，模型的“靠谱性”往往比其“强大能力”更为重要。AI可以“不作为”，但绝不能“做错事”。例如，一个汽车品牌的客服AI错误推荐了竞品车型，这就是不可接受的。因此，实现Agent的“完全可控”是其在To B场景中落地的核心前提。

第一部分：理解大模型的能力与局限

上一节我们概述了可控性的重要性，本节中我们来看看为什么大模型本身难以做到完全可控。

大模型存在固有的能力不足，主要体现在以下几个方面：

缺乏深度推理：对于需要多步骤逻辑判断的任务，表现不稳定。
知识更新滞后：无法获取训练数据截止日期之后的新知识。
“幻觉”问题：可能生成看似合理但实际错误的内容。

正因为这些不足，行业提出了多种技术来增强大模型，例如提示词工程（Prompt Engineering）、检索增强生成（RAG） 和微调（Fine-Tuning）。然而，这些方法通常是在概率上提升效果（例如从60%正确率提升到80%），难以达到业务要求的100%确定性。

第二部分：定义我们的解决范畴

在探讨具体方案前，需要明确我们试图用Agent替代人类工作中的哪一部分。我们可以将人的智力任务分为三层：

L1 提出问题：定义目标和方向（如老板）。
L2 拆解问题：规划解决方案和步骤（如中层管理者）。
L3 执行任务：根据明确指令进行具体操作（如一线员工）。

本课程讨论的“可控Agent”，旨在替代的是L3层——即“执行任务”层面。 我们可以将大模型视为一个专业基础好但缺乏公司具体经验的新员工，我们的目标是让它在我们设定的“受限场景”内，可靠地完成被拆解好的具体任务。

第三部分：Agent与工作流的两种模式

上一节我们明确了Agent的定位，本节中我们来看看实现Agent的两种主要工作流模式。

我对Agent工作流的理解是：协调组织各种AI基础能力与外部工具，分工协作，最终实现对指定任务稳定、有效的解答。 工作流大致可分为两种类型：

以下是两种主要的工作流模式：

全自动规划型：人类不知道具体解题步骤，但为AI设定角色和规则，让多个AI通过博弈、沟通自行寻找解决方案（如AutoGPT）。这对应人类“不知道步骤”的场景。
人类编排型：人类自己完全清楚解决问题的标准和步骤，并将这些步骤明确编排成工作流，指导AI逐步执行。这对应人类“知道步骤”的场景。

本课程聚焦于第二种——“人类编排型”工作流。 它的本质是将一个复杂问题简化、拆解，让大模型在每个简单的子步骤中稳定发挥，从而在整体上实现确定性的输出。

第四部分：实战拆解——以“日程助手”为例

理论需要结合实际，本节我们将以构建一个“日程助手”Agent为例，展示如何将一个真实需求拆解为可控的工作流。

首先，我们需要对“日程管理”这个任务进行完整的业务逻辑拆解。核心操作无非“增删改查”，但每个操作都可能涉及复杂的子判断。

以下是“日程助手”的核心功能与逻辑拆解：

查询日程
- 按日期范围查询（如“查询下周的日程”）。
- 按关键词查询（如“查询所有与‘会议’相关的日程”）。
- 组合条件查询（如“查询明天所有与‘项目’相关的会议”）。
新建日程
- 需要从自然语言中提取关键要素：事件内容、开始时间、结束时间、参与人等。
- 处理信息不完整的情况（如用户只说“明天开会”，需要询问具体时间）。
编辑/删除日程
- 前提：必须先唯一确定要操作的目标日程（复用“查询”逻辑）。
- 编辑：可能修改时间、内容、参与人等。
- 删除：通常需要增加确认环节，防止误操作。

通过以上拆解，我们可以设计出对应的工作流架构。其核心思想是：让大模型专注于它擅长的意图理解和信息提取，而将逻辑判断和确定性操作交给编排好的流程和外部工具（如数据库）。

工作流的核心节点设计如下：

意图判断节点：使用大模型分析用户输入，判断属于“新建”、“查询”、“编辑”还是“删除”，并输出标准化指令。

信息提取与生成节点（用于新建/编辑）：使用大模型从自然语言中提取结构化数据，或根据指令生成数据库操作语句（如SQL）。

# 示例：大模型需要将用户输入“明天下午三点和团队开会”转化为结构化数据
{
  “event”: “团队会议”，
  “start_time”: “2023-10-27 15:00:00”，
  “end_time”: “2023-10-27 16:00:00”
}

查询代理节点：这是一个抽象化的公共模块，专门处理所有“查找日程”的需求。无论是为了查看、编辑还是删除，都先通过此节点精准定位目标数据。
工具调用节点：执行具体的数据库操作（增删改查），或调用其他外部API。
确认与补充节点：当关键信息缺失时，引导用户补充。

第五部分：总结与展望

本节课中，我们一起学习了如何通过“人类编排型”工作流来实现一个完全可控的Agent应用。我们从“可控性”的需求出发，明确了Agent的适用范畴（L3执行层），并以“日程助手”为例，详细演示了如何将一个业务场景拆解为标准化、可编排的工作流节点。

关键总结如下：

核心理念：将复杂任务拆解为一系列简单的、大模型能稳定处理的子任务，通过流程控制实现整体确定性。
技术本质：大模型在工作流中扮演“聪明但需指导的执行者”角色，负责理解、提取和生成，而流程本身确保了业务的逻辑正确性。
适用场景：适用于业务逻辑清晰、步骤可定义的“受限场景”，如垂直领域的SOP（标准作业程序）自动化。
创业启示：对于创业者而言，从简单、能快速验证和变现的垂直场景入手，利用工作流技术小成本试错，是当前阶段一个行之有效的策略。

Agent的落地，尤其是将行业隐性知识（如金牌销售的话术）通过工作流显性化、产品化，蕴含着巨大的机会。未来，随着大模型能力的进化，我们期待它能更多地自动完成工作流的规划和编排，但在此之前，人工设计的高确定性工作流仍是实现商业价值可靠、稳健的路径。

课程名称：Agent工作流 - P1：如何实现完全可控的Agent应用
核心工具：工作流编排、大模型API（如智谱AI）、数据库
关键输出：一个逻辑清晰、节点分明、可稳定执行的Agent业务流程设计图。

课程 P1：ChatGLM 开源进展与最新发布介绍 🚀

在本节课中，我们将学习智谱AI与清华大学联合开发的ChatGLM系列大模型的最新开源进展。我们将介绍多个新发布的模型及其核心特性，包括长文本理解、代码生成、数学计算、图像生成以及角色扮演等方向的发展。

开源模型的影响力与持续发展

上一节我们介绍了课程背景，本节中我们来看看ChatGLM开源模型的整体影响力与发展历程。

智谱AI与清华大学一直致力于大模型基础模型的开发。今年3月14日，团队上线并开源了ChatGLM-6B模型。后续还开源了GLM-130B等一系列模型。

根据科技部在5月份发布的关于中国开源大模型影响力的报告，智谱AI的开源模型（报告中红色部分）表现突出。其中，ChatGLM-6B模型在全球的下载量居于首位。

团队在持续进行研究和开发，并于6月25日推出了ChatGLM2-6B开源模型。与第一代相比，第二代模型在多项指标上取得了巨大进步。

以下是ChatGLM2-6B的主要提升：

性能提升：在多项测试中成绩显著提高。
推理加速：模型推理速度大幅提升。
上下文长度：上下文长度从原来的2K扩展到了8K。
商用许可：对商用使用免费开放。

长文本理解能力的突破

在增强了基础模型能力之后，团队在长文档理解方面也做了大量工作。

除了8K版本，团队即将推出支持32K上下文长度的版本。从token数量上讲，这可以支持接近5.7万汉字。上下文长度的显著增强，为处理长文档任务提供了可能。

在更强的上下文能力基础上，团队在LongBench基准上进行了测试。该测试包含13个英文任务、5个中文任务和2个代码任务。ChatGLM2-6B取得了非常好的成绩。

以下是与其他模型的对比情况：

英文任务：成绩与ChatGPT-3.5-Turbo-16K类似。
中文任务：在“多文档问答”等任务上展现出更好的能力。
对比模型：包括ChatGPT、LLaMA、LongChat等。

代码生成模型的进化

除了通用语言模型，代码生成是开源模型的一个重要方向。

团队近期将CodeGeeX代码生成模型升级到了第二代。新模型参数量从原来的130亿下降到了60亿，但性能反而得到提升。

以下是CodeGeeX2的核心特点：

参数量下降：从13B降至6B。
性能提升：在HumanEval测试集上的得分从22.9提升至35.9。
推理加速：参数减少带来了更快的推理速度。
IDE集成：持续增加与更多集成开发环境的集成，使编程更加方便。

大模型数学计算能力的提升

大模型的计算能力一直备受关注。团队近期发表了一篇论文，探讨大模型在不使用计算器的情况下解决数学问题的能力。

为此，团队开发了MathGLM模型。该模型在数学计算任务上的成绩远超GPT-4，在许多任务上正确率甚至达到99%以上。

MathGLM模型的特点如下：

高正确率：在小学数学计算上表现优异。
复杂运算：能够正确处理八位数以上的乘法等运算。
应用题解析：在数学应用题解析上也取得了超过90%的优异成绩。
模型轻量：论文中使用的模型规模非常小，最大不过百亿或十亿参数级别。

图像生成算法的创新

团队在图像生成领域也进行了探索，并提出了一种算法上的改进。

该改进称为RDM算法，即“级联式扩散模型”。其基本原理是：首先使用扩散模型从白噪声生成一个低分辨率图像；然后以此小图像为基础，再次使用白噪声进行填充和分块生成；最终合成一个高精度、高清晰度的大幅图像。

这个算法涉及许多需要处理的细节，有兴趣的读者可以查阅相关论文。该模型已集成到“智谱清言”产品中，可供用户体验。

以下是该技术的优势：

运行成本低：相比其他方法有更低的运行成本。
性能更好：能生成质量更高的图像。
易于体验：已在“智谱清言”应用中上线。

迈向情感化与角色扮演

团队还在探索大模型在情感陪护和角色扮演方面的应用。

受Character.AI等公司的启发，团队正在开发一个名为CharacterGLM的模型。其目标是让大模型能够扮演更人性化的角色，进行情感交互。

目前的一个有趣尝试是探索大模型在模拟对话和剧情创作中的应用。例如，未来在赋予大模型特定角色背景后，或许可以演绎如《甄嬛传》之类的复杂剧情。

这项工作的愿景是让大模型更多地渗透到创意创作领域。该模型尚未正式发布，此次仅为预告，发布后欢迎大家使用。

总结与展望

本节课中我们一起学习了ChatGLM系列大模型的最新开源进展。

总而言之，团队始终坚持开源道路，推动大模型向多样化发展，使其在各个领域发挥作用。我们真诚希望更多的研究者、工程师、公司和行业领域能够参与进来，共同将大模型技术深耕到实际应用中。

有人说，大模型的上半场是基础模型的比拼，而下半场的竞赛——即技术下沉到各行各业——已经开始。期待与大家一同参与下半场的开拓。

课程 P1：认识智谱清言与ChatGLM2 🚀

在本节课中，我们将一起了解智谱清言及其背后的ChatGLM2模型。我们将介绍它的基本概念、特点以及如何开始使用它。

概述

智谱清言是一个基于ChatGLM2模型构建的智能对话服务。ChatGLM2模型现已全面开放，正式对外提供服务。本教程旨在帮助初学者理解其核心概念并掌握基本使用方法。

什么是智谱清言？🤖

智谱清言是一个人工智能对话助手。它的名字来源于“清言的「清」”和“清言的「言」”，寓意清晰、智慧的言语交流。

上一节我们介绍了课程目标，本节中我们来看看智谱清言的具体定义。

智谱清言的核心是一个大型语言模型，它能够理解人类的自然语言输入，并生成流畅、相关的文本回复。其目标是提供高效、准确的信息服务和对话体验。

认识ChatGLM2模型 🧠

ChatGLM2是支撑智谱清言服务的底层人工智能模型。它是一个经过大规模数据训练的语言生成模型。

上一节我们了解了智谱清言，本节中我们将深入其技术核心——ChatGLM2模型。

ChatGLM2模型基于Transformer架构，这是一种在自然语言处理领域取得巨大成功的深度学习模型。其核心工作原理可以简化为根据输入的文本序列，预测下一个最可能的词或字，公式可以表示为：

P(下一个词 | 已输入的文本序列)

模型通过不断重复这个过程，从而生成完整的句子或段落。

主要特点与能力 ✨

ChatGLM2模型和智谱清言服务具备多项特点，使其成为一个强大的工具。

以下是其主要能力列表：

强大的语言理解与生成：能够处理复杂的对话上下文，生成连贯、合乎逻辑的回复。
多领域知识：在训练中学习了广泛的互联网文本，涵盖科技、文化、生活等多个领域。

代码理解与生成：支持多种编程语言的代码解释、补全和错误排查。

# 例如，它可以帮你解释一段Python代码
def greet(name):
    return f"Hello, {name}!"

逻辑推理与问题解决：能够进行简单的数学计算、逻辑推理和分步骤的问题解答。

如何开始使用 🛠️

使用智谱清言服务通常非常简单，无需复杂的配置。

上一节我们介绍了它的能力，本节中我们来看看如何实际使用它。

一般来说，你可以通过以下方式访问：

访问官方网站或指定的平台入口。
在提供的对话框或输入框中，直接输入你的问题或指令。
模型会处理你的输入并返回相应的文本回复。

整个过程类似于与一个知识渊博的朋友进行即时文字聊天。

总结

本节课中，我们一起学习了智谱清言及其背后的ChatGLM2模型。我们了解了智谱清言是一个智能对话服务，其核心ChatGLM2模型是一个基于Transformer架构的强大语言模型。我们还列举了它的主要特点，包括语言生成、多领域知识和代码处理能力，并简述了开始使用它的基本步骤。希望本教程能帮助你顺利开始与智谱清言的交互。

课程 P1：ChatGLM3 一键安装与基础使用指南 🚀

在本课程中，我们将学习如何通过一键安装包快速部署 ChatGLM3 大语言模型，并了解其基本的聊天、工具调用和代码生成功能。

概述

本节教程将引导你完成 ChatGLM3 的本地部署与初步体验。我们将从启动 Web 聊天界面开始，逐步探索其核心功能，最后简要介绍其 API 服务能力。

启动 Web 聊天界面 💬

上一节我们概述了课程内容，本节中我们来看看如何启动 ChatGLM3 的 Web 聊天界面。

打开名为“零一”的启动程序，系统将自动打开默认浏览器并加载 ChatGLM3 的 Web 界面。

如果系统未设置默认浏览器，你需要手动复制终端中显示的网址，在浏览器中打开。随后，请等待后台程序加载模型。

探索聊天功能与角色扮演 🎭

模型加载完成后，页面将默认进入 Chat（聊天） 模式。你可以开始与 ChatGLM3 对话，测试其各项能力。

以下是基础操作指南：

刷新网页：此操作可以清空当前的聊天记录。
使用左侧设定栏：你可以在此调整对话参数，例如让模型扮演特定角色（如“猫娘”）。
调整参数：将“温度”等参数调整至 0.8，可以测试模型在创造性任务（如算术）上的表现。

测试结果表明，其回答基本正确。

使用工具调用与代码生成模式 ⚙️

了解了基础聊天功能后，我们进一步探索 ChatGLM3 更强大的工具调用与代码生成能力。

以下是其他模式的使用方法：

切换到 Tool（工具）模式：在此模式下，你可以让模型调用内置工具，例如查询“北京天气”。用户也可以自行添加自定义工具。
切换到 Code（代码）模式：此模式专为代码生成与执行设计。例如，你可以输入指令“用Python画一个爱心”，模型会生成相应代码并展示运行效果。

至此，ChatGLM3 的基本功能已介绍完毕。

启用 API 服务端 🌐

除了交互式网页，ChatGLM3 还提供了 API 服务，可供其他应用程序调用。

首先，关闭之前打开的网页和后台进程。然后，打开名为“零二”的启动程序。启动成功后，该 API 服务即可作为后端，供诸如 ChatGPT-Next-Web 等基于 ChatGPT 的应用连接使用。

为了演示 API 的连通性，此时可以打开“零三”测试程序进行验证。

关于安装包与进阶学习 📚

本一键安装包基本基于官方 Git 仓库的原版文件构建，主要针对 NVIDIA 显卡用户添加了自动量化代码以优化运行效率。

安装包内还包含更多资源供你探索：

基础演示脚本：帮助你快速上手。
Lag Train 及训练代码：为有兴趣进行模型微调或进阶学习的用户提供起点。

请大家利用这些资源自行深入学习与实践。

总结

在本节课中，我们一起学习了 ChatGLM3 大语言模型的一键安装与启动流程。我们体验了其 Chat（聊天）、Tool（工具调用） 和 Code（代码生成） 三种核心模式，并了解了如何启用其 API 服务 以供其他应用集成。最后，我们也介绍了安装包内包含的进阶学习资料。现在，你可以开始尽情探索 ChatGLM3 的各项能力了。

课程一：金融领域大模型应用的核心认知与场景概览 🧠

在本节课中，我们将学习大模型在金融行业应用的核心逻辑、关键挑战以及典型应用场景。我们将从基础认知出发，理解大模型如何“思考”，并探讨其在银行、保险等具体业务中的落地路径。

概述：大模型是什么？它能做什么？

大模型的核心功能是实现“认知对齐”，即让机器像人一样思考。从技术形态上看，它需要知识库作为基础，并具备听说读写等交互能力。然而，最关键的部分在于中间的“思考过程”。简单的问答（一问一答）本质上是搜索能力的体现，而复杂的、需要多轮交互和逻辑推理的任务，则依赖于对“思考过程”的精心设计和编程。

因此，大模型的应用开发，其关键与难点在于对特定业务场景下“思考逻辑”的复现与优化，而不仅仅是提供知识库。

大模型的应用形态与价值

上一节我们介绍了大模型的核心是“思考”，本节中我们来看看它的具体应用形态和带来的价值。

从产品形态上看，大模型的应用非常广泛：

智能对话问答：对应人的“听”和“说”的能力。
智能文档与代码处理：对应人的“读”和“写”的能力。
智能工具与多模态应用：例如图像生成、内容创作，对应“看”、“画”和“做事”的能力。
自然语言调用工具：通过自然语言交互调用现有的专业工具（如CAD、CAE软件）。

从应用价值上看，大模型可以实现双向赋能：

对人（员工或客户）：增强人的智能，充当智能助理。
对物（产品、工具）：赋予物拟人化的交互能力，实现“假如产品会说话”的体验。

最终，大模型的目标是实现认知的普惠或泛在智能，让智能能力无处不在。目前，逻辑和技术路径是通的，主要难点在于每个专业领域“思考过程”的设计。

大模型应用的开发路径与难点

理解了应用价值后，我们来看看将一个通用大模型变成专业领域工具需要经历什么。

以下是典型的大模型应用开发路径：

通用预训练模型：拥有广泛但浅层的知识。
领域专业知识注入：通过微调等方式，让模型掌握特定领域知识。
提示工程与任务适配：设计提示词，引导模型完成特定任务。
产品化与工程化：将能力封装成稳定、可用的产品。

我们近期的体会是，真正的难点和重点工作在于产品化和工程化。微调可以改变模型回答的风格和准确性，但无法直接赋予其复杂的业务思维逻辑。这好比医学教科书无法代替医生问诊。必须深入理解业务场景（如信贷审批、保险核保）的思维链条，并将其“编程”到大模型的应用流程中，才能打造出客户期待的产品。

行业报告洞察：哪些领域价值最大？

根据麦肯锡的报告分析，大模型对需要“动脑”的工作影响最大。报告通过对大量工种的分析，指出了四个价值最显著的方向：

以下是麦肯锡报告指出的四大高价值方向：

客户运营：包括客户交互、档案查询、生成工作建议等。
营销与销售：提升营销内容生成、销售对话的质量与效率。
软件工程：辅助代码生成、测试、文档编写等。
产品研发：加速产品设计、市场调研等创新过程。

这些方向的共同点是都需要高度的“思考”和“实时交流”。在银行业的具体应用中，则体现在员工辅助（信息查询、知识问答）、自动化流程、客户服务以及风险管理等方面，核心目标是提升效率、满意度和降低风险。

金融行业典型应用场景解析

基于与客户的共创实践，我们总结出一些金融领域的具体应用场景。其核心思路是为每个岗位打造“智能助手”。

场景一：保险销售与客服助手 🛡️

在保险行业，大模型可以赋能多个环节。

以下是保险领域的几个关键助手应用：

销售助手：辅助保险销售人员理解产品、应对客户咨询。
核保助手：帮助核保人员快速审核保单，提示风险点。
理赔助手：引导用户完成理赔流程，自动审核材料。
产品知识助手：将复杂的保险条款转化为通俗易懂的解答，方便内外勤人员及客户查询。

其技术逻辑可以概括为一个公式：智能应用 = 自然语言交互界面 + 场景思维逻辑 + 知识库系统。难点在于构建符合业务逻辑的“思维链条”和高效的信息调取机制。

场景二：全生命周期保险管家 🔄

围绕一个保险产品，从客户了解、购买、保全到理赔的全生命周期，都可以嵌入智能助手。这可以形成覆盖App、小程序、客服系统等全入口的智能矩阵。背后需要整合产品说明、投保规则、理赔条件、配套服务等海量信息，并提供连贯的、个性化的问答交互，价值巨大。

场景三：智能销售教练 💬

销售的本质是建立信任，而非简单推销。优秀的销售过程是一个精细化的对话和需求引导过程。

一个智能销售教练系统应能模拟以下思维链：

客户画像预测 -> 沟通中挖掘痛点 -> 确认并引导需求 -> 生成定制化方案 -> 方案讲解与促成

它需要集成客户画像库、痛点需求库、产品知识库以及销售技巧库。通过大模型复现“听说读写”的销售过程，从而提升销售人员的专业度、用心度和成交率。这是价值高、难度也高的应用方向。

场景四：金融文档自动生成与报告助手 📊

在金融业，如客户经理拜访前需要准备客户分析报告。大模型可以整合企业年报、新闻、内部数据等多源信息，进行总结、提炼，并按照特定格式自动生成报告，甚至提供初步的合作建议。这极大地提升了前台人员的工作效率。

从企业管理角度看，文档即流程。几乎企业中的所有文档（如尽调报告、合规报告、审计底稿）都可以规划其自动生成路径。这反过来会推动与数据库、BI系统等工具的深度集成。大模型正成为人与系统交互的“第一入口”，负责调度各类工具完成复杂任务。

总结：核心理念与开发建议

本节课中，我们一起学习了金融大模型应用的核心逻辑与落地场景。

我们可以将大模型的应用归结为一个核心：做人的智能助手。人的工作无非“沟通、分析、决策”。

对于沟通岗（业务岗），助手以问答为核心，关键是从“等待提问”变为主动引导和帮助用户思考，这需要对业务思维过程进行“编程”。
对于分析决策岗（管理岗），助手以生成为核心，集成各类工具进行信息分析，支撑决策。

目前，大模型技术与应用之间存在鸿沟。成功的开发需要业务方与技术方深度协同，甚至业务方要承担70%的工作（定义场景、梳理逻辑、准备知识、持续测试），技术方则提供方法论和工程实现。

对于企业而言，引入大模型应用是一个创新过程。建议以“创新副驾驶”的心态，从小场景切入，快速迭代，让大模型真正赋能业务，走向认知普惠。

（注：文末的二维码及联系人信息在此教程中略去）

CogVLM2 课程：第二代视觉大模型详解与应用 🚀

概述

在本节课中，我们将学习智谱AI与清华大学联合研发的第二代开源视觉大模型 CogVLM2。该模型仅用190亿参数，即可在多项任务上达到媲美GPT-4V的性能。课程将分为两部分：首先深入解析模型原理与架构，然后介绍其实际应用与快速上手方法。

第一部分：模型原理与技术细节

上一节我们概述了课程内容，本节中我们来看看CogVLM2的核心技术原理。

多模态大模型的发展背景

自GPT-4发布以来，大语言模型在众多任务上展现出强大性能。它能够通过少量样本学习和思维链解决复杂问题。但由于大语言模型训练使用的是纯文本语料，缺乏对视觉概念和真实物理世界的理解，它们常常会在一些简单问题上犯错。

今年以来，头部科技公司无一例外地将多模态能力作为主要卖点。例如，谷歌在去年3月提出了PaLM-E模型，将多模态大模型与机器人相结合，从而响应人类指令并执行动作。其今年发布的Gemini 1.5支持原生动态输入，并能处理长达十小时的视频。今年5月，OpenAI发布的GPT-4o可以实现实时输入、解析以及输出包括音频、图片、视频、文字在内的所有模态内容。

我们相信，训练一个强大的语言模型，然后在它的基础上添加各种模态，是实现AGI比较可行的技术路线。

现有多模态模型的痛点与CogVLM的演进

虽然最新的多模态大模型在过去一年发展迅速，但仍然存在一些关键痛点。例如，模型往往会输出图片中的“幻觉”，分不清图片中物体的形状和位置，或者只能处理224分辨率的模糊图片，以及完全无法识别中文场景和文字等。

我们团队针对这些痛点持续进行改进，并且很早就意识到多模态模型的OCR能力是模型能否落地的关键因素。

以下是CogVLM系列的演进过程：

2023年5月 (VisualGLM)：模型只能回答一些简单问题，例如“图片中有几个人”或“图片里的人在干什么”。
2023年9月 (CogVLM初代)：模型已具备较强的指代能力和初步的文字识别能力。
2023年11月 (CogAgent)：模型在GUI交互和通用领域取得较好结果，具备T2I能力，可以进行关于图片的对话和OCR对话。例如，将表格转化为Markdown格式或分析折线图中的具体数字。

具体来说，我们在去年10月发布的CogAgent模型已经可以高效完成十个多模态任务，包括传统的视觉问答、世界知识，以及一些高级任务，如涉及数据和代码的逻辑问答、图表问答等。其另一大特点是能够直接与生活场景交互，即让模型模仿人类与手机、电脑等设备的GUI界面进行交互。

CogVLM2的核心架构创新

上一节我们回顾了模型的发展，本节中我们聚焦于CogVLM2解决核心问题的关键技术。

1. 高分辨率视觉输入处理

对于CogAgent，相对于初代CogVLM的一个重要改进是使其适应高分辨率输入图片。我们知道，网页截图或文档至少需要720P分辨率，可能需要上千像素的输入才能支持模型很好地识别信息。但如果直接使用原始的CogVLM结构，会导致视觉序列非常长。

假设CogVLM的输入是一个224分辨率的图片，它大概有256个token。但如果扩展到1000以上分辨率，可能会达到6400个token的图片序列，接近纯文本输入十页PDF的计算量。这个巨大的计算开销可能难以接受，虽然现在的一些长文本语言模型可以训练，但速度会非常缓慢，不利于快速推理和迭代。这也是现在大多数多模态模型面临的问题。

我们的解决方案是引入了一个高分辨率的Cross Attention分支。思路很简单：完全保留CogVLM的原始结构，只是加上了一个以Cross Attention形式桥接的高分辨率图像输入。它对应一个很小的图像编码器，并与原有的CogVLM结合。原始参数是170亿，加上这个模块后只增加了约1亿参数，并且通过减少输入到语言模型中的序列长度，最终实现了十倍左右的加速。

2. Visual Expert（视觉专家）模块

在CogVLM2中，我们延续了一代模型和CogAgent使用的Visual Expert模块。其实我们刚提出Visual Expert时，像BLIP-2和Flamingo这类只微调视觉编码器和语言模型之间少量参数（即“浅层融合”）的模型还比较流行。它们所有的语言模型参数在训练过程中完全不变，可能在VQA这样的简单数据上能取得较好效果。

但我们实测发现，这种浅层融合的模型在一些困难任务（如MathVista和视觉推理任务）上的效果并不理想，比相似参数量的LLaVA要低几十个点，并且模型输出“幻觉”的概率也远高于训练了语言模型参数的模型。我们分析，这种现象是因为在浅层融合过程中，大语言模型并不能理解多出来的图像序列是什么，导致视觉特征和文本特征难以对齐。

一个直观的方法是在预训练时连同语言模型的参数一起训练，例如谷歌的PaLI就做了这样的事。但这可能带来另一个问题：模型会完全忘记之前学过的纯文本语料知识。我们希望训练后的模型既能保持原有的大语言模型知识和推理能力，而不是一个只能输入图片的模型。因此，如何在深度融合视觉和语言特征的同时，又保留原本的语言理解能力，是我们需要解决的问题。

CogVLM给出了一个比较优雅的解决方案。因为很多视觉概念是语言空间里所不具备的，因此我们想让视觉和语言空间还是各自占据一个空间。我们在冻结的预训练语言模型中，引入了一个可以训练的视觉专家模块。

具体来说，这个视觉专家是在语言模型的每一层（注意力和前馈神经网络里）添加了为视觉特征单独学习的参数。在调节参数时，我们只调节这部分参数。所以当输入不含图像时，模型就会自动退化为原来的语言模型。这样就既实现了视觉语言特征在所有层的深度融合，又可以完全保留语言模型的知识。

它的总体机制类似于一种硬路由的MoE机制，也就是说每个token只激活模型参数中的一部分，因此没有增加任何计算开销。当然，最近的一些开源模型，如LLaVA-NeXT和MiniGPT，没有使用Expert也取得了比较好的效果。所以我们同时基于LLaMA 3训练了一个有Expert和一个没有Expert版本的模型，发现训练原始的语言模型也可以取得比较好的效果，这也算一种深度融合的手段，只是模型的纯文本能力会损失大一些。我们的实验结果显示，加上Expert之后，模型在MMBench等数据集上的分数会平均高出2%左右，所以我们最后决定开源这个带Expert的版本。

3. 视觉-语言特征对齐与位置编码

在设计CogVLM2的结构时，一个比较重要的问题是如何来桥接视觉和语言的特征。像BLIP-2和Flamingo采用了Q-Former，它的好处是可以很好地压缩信息来减少token，因此训练和推理的速度都很快。但是一个比较明显的坏处是，它的Query无法保证哪些图像的特征被保留。特别是像InstructBLIP，它的Query会和每轮的Prompt强相关，这样每一轮输入的图像特征都不同，甚至无法使用像KV Cache这样的推理加速方法。

另一个缺点是它也很难保留原始图片在语言空间中的位置信息，因为它将图片序列完全转成新的查询序列。我们测试时也发现，如果使用Q-Former，会导致模型输出“幻觉”的概率明显变大。第三个缺点是，如果我们要测试的图像内容与训练Q-Former的图像有差距，它就不一定能很好地泛化。这其实很好理解：假如我们用一个自然图像来训练Q-Former，那么可能就会丢弃掉那些适用于文本的特征，最终导致其在OCR和文档理解等任务上的能力变弱。而在另一方面，在低分辨率上训练的Q-Former，也很难迁移到高分辨率场景。

我们采用的方法是直接用一个MLP和一个Linear层，从而起到一个模态翻译的功能，尽可能减少在桥接过程中信息的压缩或损失。我们最终的结论是，把一个两层的MLP和一个2×2的卷积层相结合，就可以在尽可能保证图像特征的前提下，降低四倍左右的计算量，同时实现一种无损压缩。

我们针对高分辨率图像的另一个重要改进是修正了图片序列的位置编码。原始的位置编码对于文本中的某个token，只需要一个标量（例如N）来记录它是第N个token。但是对于一个图片序列来说，即使我们进行了patchify操作，它也可能保留宽度和高度两个方向的维度，那么我们就需要一对坐标来准确编码这个patch在语言序列中的位置。

总的来说，文本的位置是一个标量，而图像的位置是一个向量(X, Y)，它们两者并不一致。因此我们在处理图文混合输入时，就需要一些技巧来调和这两个模态之间的不一致性。

一个直接的方案是把图片展成一个一维的序列，然后把它当成普通的文本来处理，文本怎么加位置编码，它就怎么加位置编码。但是这样的话，如果图片序列很长，又会带来新的问题。例如，在一个序列长度2000的图片后面拼接一个Prompt，如果这个Prompt是关于图片下半部分的信息可能还好，但如果是关于图片上半部分的信息，就会受到比较大的注意力衰减的影响。

我们采用了一个比较直接的方法：同一张图片内的所有token共享一个位置ID。这样既减少了位置ID的消耗，方便位置外推，又可以避免注意力衰减影响。而图片中序列的相对位置关系就完全通过视觉编码器来获取。这样做的好处是，可能在低分辨率的图片上效果不太明显，但是对于1000分辨率以上的文档和图片，可能会看到比较大的提升。

最近RoPE的原作者苏剑林也发现了多模态模型位置编码的问题。他认为位置编码的概念不应该和Attention的用法相绑定，它应该适用于Decoder、Encoder和一种任意的Attention Mask。所以说只有保持图片的二维性，才能最大程度保证模型关于相对位置的先验。如果我们将序列直接展平，就没有办法保证所有邻近位置的相近性，因为少了一个维度，所以可表达的相似性也就少了很多。他提出的另一种方法是把图片序列中的位置编码用2D的RoPE表示，从而无损地保留图片patch的位置信息。而对于纯文本输入，它又会退化为原始的1D RoPE，从而兼容已有的大语言模型。感兴趣的同学可以在会后查看他的相关分享。

4. 视觉编码器选择与中文能力优化

在视觉编码器方面，可能有同学会好奇，为什么我们在去年的CogAgent中使用了EVA-CLIP-large和EVA两个ViT，但在二代CogVLM中只回归到了一个EVA。其实这也是基于我们充分的实验观察到的现象：虽然CogAgent可以在结合高分辨率和低分辨率的同时进行比较高效的推理，但是很多情况下，两个ViT的特征是冲突的。例如，可能一个ViT认为图片中有三个人，但另一个ViT认为有两个人，或者两个ViT的特征会显示图片中写着不同的字，导致语言模型并不知道该输出什么信息，从而影响OCR任务的结果。

所以为了保证模型效果，我们在CogVLM2中只用了一个40亿参数的ViT。这样做的问题可能是很多同学会反馈它占用的显存比较大。未来我们也会基于一些新的视觉编码器，例如效果持平但参数少得多的SigLIP，来方便大家的部署。最近也有一些其他研究工作会把两个、四个甚至八个ViT的编码器特征拼到一起。个人观点是这样做的效果可能还需要进一步验证，很可能不如使用一个更大的视觉编码器效果好。

我们发布之后，大家常问的另一个问题是：Meta官方发布的LLaMA 3可以理解中文，但很难用中文来回答。那么CogVLM2怎么可以用这个语言模型为基础，做到理解并支持中文？其实主要是在训练数据方面的一些优化。

首先是在预训练阶段，我们收集了比较大量的中文图文数据，这些数据会涵盖中文场景中的各种情况。但我们在实际训练时也发现，中文图文对的质量远远低于已有的开源英文数据。在训练一个CLIP模型时，可能用英文数据能达到70左右的效果，但是中文只有50甚至40。因此我们的训练策略是以英文图文对为主，结合少量高质量的中文图文数据。

另一个比较关键的步骤是我们针对中文场景进行了OCR和文档等特定数据类型的数据收集。例如，我们将一些纯文本语料库的数据渲染成了图片，得到了大概8000万张图片。我们还借助了一些已有的OCR工具，如PaddleOCR，来标注约1800万张自然图片。我们还从arXiv上爬了大概900万篇中文的学术论文，以获取比较高质量的LaTeX和PDF配对。在这个过程中，模型可以学到比较好的中文能力。

在接下来的指令微调阶段，我们又确保了中英数据的比例在一个合理的范围内，从而使得模型在处理一些中文问题时可以更加得心应手。通过这些措施，我们的CogVLM模型在支持中文方面相比前一代取得了比较显著的提升，无论是在理解中文问题方面，还是用中文回答论述这方面，都能展现出比较良好的性能。这也是我们构建CogVLM模型的一个比较大的亮点和优势。

5. 实验结果与消融实验

最后我们进行了一系列比较彻底的消融实验，研究多模态训练过程中的不同设定，也有了一些比较有意思的发现。

例如，我们尝试引入了图像自监督的损失，让模型预测patch的特征或原始像素，但是发现这样并没有提升模型的效果。我们猜测，这样虽然可能学到一些更好的视觉表征，但是对于模型的自然语言生成能力的帮助可能不大。这一点在谷歌的PaLI工作中也得到了一些印证。

另一个发现是，在图像序列中使用下三角注意力编码，会比使用全注意力编码效果更好。这个也比较反直觉，因为一般情况下，如果一个图像token能看到序列的所有内容，按理说是能取得更好的效果。我们猜测这是因为下三角注意力的掩码更加契合语言模型原有的结构，而全注意力会破坏这种机制。

我们也尝试使用了一个30亿参数的EVA-CLIP模型来替换现在的40亿参数的EVA模型作为视觉编码器，发现在绝大多数任务上可能影响很小，但是对OCR任务的影响比较大。在训练中文OCR图片的时候，也发现了这个现象：30亿参数的ViT学会中文字符的速度要远远慢于40亿的ViT。这也会为大家未来的工作提供一些新的启发。

在实验结果方面，我们与一系列优秀的开源和闭源模型进行了对比，例如同参数量最优的LLaVA-1.5和LLaVA-NeXT模型。我们在所有数据集上的表现都要领先10%到20%左右。相比于Claude-3和GPT-4这些闭源模型，在OCR-Bench等能体现模型识别文字、文档、表格方面能力的数据集上，也可以说是有比较大幅度的领先。仅仅在MMMU这样需要模型有特别强的纯文本语言能力的情况下，大概落后了5%到10%左右。

第二部分：模型应用与快速上手

上一节我们详细介绍了CogVLM2的技术原理，本节中我们来看看它的实际应用效果以及如何快速部署使用。

典型应用场景演示

我们已经看到CogVLM2在很多榜单上取得了成就，在一些领域有比较大的提升。大家可能会有疑问：经历了这么多代视觉模型的进步，我们是否能在更多的应用层面进行新的探索？本次直播的后半部分将为大家提供这方面的简单介绍。

大家对多模态模型有很多憧憬，包括最常见的图表分析和OCR任务。特别是对于一些不规则的文档，无法使用传统的OCR工具进行扫描时，大家就会把这个场景寄托于多模态模型。同时，对于一些不太好用Python或其他编程语言直接读取的图表和文件，我们也希望能通过视觉的方式，用多模态模型进行理解并给出简单分析。此外，还有大家经常提到的拍照解数学题，或者拍照看漫画去体会漫画寓意等带有图像和文本双重模态的任务，我们都对多模态模型有一定的期待。

以下是几个具体的应用场景及其经典案例：

图片细节识别与文件提取：这是CogVLM2在应用层面能够以肉眼感受到的强大提升。
OCR能力：包括表单拾取与识别，相对于一代模型甚至比一些专业OCR工具还有更出色的表现。
复杂理解与推理：例如，给到一个前端页面草图，然后生成代码；或者给一个数学题，要求给出带有解答过程的答案。

在线演示与快速上手

在线体验

我们提供了一个在线的Demo页面供大家体验，地址是：https://chat.cogvlm.ai/。该页面部署了BF16精度的模型，性能较好，可以免费公开使用。

在Demo中，我们提供了英文和中文两个版本的模型。英文版本基于原始的LLaMA-3-Instruct训练，只能理解中文但难以用中文回答。中文版本（模型名称中带有“chinese”）则具有完整的中文对话能力，也是我们今天演示使用的版本。

演示案例包括：

“选西瓜”挑战：上传一张有多个西瓜的图片，让模型选择其中最熟的一个。
手写体OCR识别：上传手写文字图片，让模型识别并输出内容。
流程图理解：上传化学流程图，让模型用简单语言描述其过程。

模型能够准确完成这些任务，展示了其在视觉理解和语言生成方面的强大能力。它不仅能完成常规的视觉问答，也能在没有图片输入时作为传统的对话模型使用。

本地部署与硬件要求

如果希望进行更深入的体验，包括各种方式调用或微调模型，则需要本地部署。

模型下载地址：

Hugging Face：搜索 CogVLM2 专栏，可以看到四个模型：
- cogvlm2-llama3-chat-19B (英文版)
- cogvlm2-llama3-chat-19B-int4 (英文版，INT4量化)
- cogvlm2-llama3-chinese-chat-19B (中文版)
- cogvlm2-llama3-chinese-chat-19B-int4 (中文版，INT4量化)
ModelScope：同样有上述四个模型，若无法访问Hugging Face可在此下载。

代码仓库：模型的调用和实现代码位于GitHub: https://github.com/THUDM/CogVLM2。其中包含了基础的调用方式，方便大家入门。

硬件与软件要求：
目前所有模型都需要在 Linux 环境下搭配 英伟达显卡 运行，因为依赖了 triton 库。

以下是硬件配置建议：

最低配置 (运行INT4量化版)：
- 显卡：至少16GB显存的英伟达显卡。
- 内存：建议32GB系统内存用于加载模型。
推荐配置 (运行BF16原版)：
- 显卡：单卡显存42GB以上（如A100 40GB可能勉强，建议A100 80GB或类似卡）。
- 原因：加载模型瞬间需要约38-39GB显存，对话过程中随着上下文增长，显存占用会增加。
多卡方案：
- 可以使用多张显卡进行推理，例如三张16GB的英伟达显卡（需型号相同）。
- 测试过两卡或三卡均可，但单卡必须16GB以上以避免前向

课程一：拥抱GLM-4：API调用与案例实践 🚀

在本节课中，我们将学习如何调用智谱AI开放平台的最新GLM系列模型API。课程将涵盖平台简介、不同模型的API调用方法、核心功能演示以及两个简单的应用案例。目标是帮助初学者快速上手，利用大模型能力进行智能化开发。

平台简介 🌐

智谱AI开放平台通过开放API，旨在提供强大且易用的大模型能力。“强大”指提供全球顶尖的各类大模型，包括语言、多模态等模型。“易用”指为开发者提供高效的开发支持，例如与应用开发套件（如LangChain）的打通、官方SDK、最佳实践案例以及工业级解决方案分享。

平台的愿景是为开发者提供便宜、可靠、安全、高效的大模型能力，帮助大家轻松实现智能化创新。其使命是为每一位开发者赋能，共同开启智能未来时代。

开放平台的API是继开源模型和私有化部署之外的第三种选择。它的核心能力包括：

模型推理：提供各类大模型的推理API，这是本节课的重点。
检索增强生成（RAG）：用于构建知识库。
模型微调：平台已开放模型微调的API能力。

相比私有化部署，API调用的成本更低，希望让开发者能以最低成本使用最先进的大模型。

平台自2023年初以来，模型经历了多次升级，从GLM-6B到现在的GLM-4，协议越来越稳定。建议开发者使用最新的V4版本API。

API实践：模型调用与演示 💻

上一节我们介绍了开放平台的概况，本节中我们来看看如何具体调用不同的模型API。我们将介绍语言模型、多模态模型等，并进行代码演示。

语言大模型：GLM-3 Turbo 与 GLM-4

首先是语言类大模型。GLM-3 Turbo是GLM-Turbo的全新升级版，综合性能提升20%以上，推理速度更快，上下文长度从32K提升至128K，价格保持为 0.005元/千Tokens。

GLM-4在整体性能上相比GLM-3全面提升60%以上，逼近GPT-4的水平。它也支持128K上下文，并新增了智能体（Agent）相关能力，如系统提示词（System Prompt）支持、工具调用（Function Call）、联网搜索（Web Search）和知识库检索（Retrieval）。其计费为 0.1元/千Tokens。

在能力对比上，GLM-4的英文基础能力达到GPT-4的95.8%，指令跟随能力达到90%。在中文能力上，如写作、问答、角色扮演等方面均超越GPT-4。在长文本测试（如“大海捞针”）中，128K上下文内可实现全对。

核心代码演示：调用GLM-4

以下是调用GLM-4模型的基础方法。平台提供了Python和Java的SDK，支持同步、异步和流式（SSE）三种调用方式。本节以Python为例。

1. 安装与初始化
首先通过pip安装SDK，并使用您的API Key初始化客户端。

pip install zhipuai
from zhipuai import ZhipuAI
client = ZhipuAI(api_key="your_api_key") # 请替换为您的API Key

2. 同步调用
调用后等待并一次性返回完整结果。

response = client.chat.completions.create(
    model="glm-4",  # 指定使用GLM-4模型
    messages=[
        {"role": "system", "content": "你是一个乐于助人的助手。"},
        {"role": "user", "content": "2022年世界杯冠军是谁？"}
    ],
    temperature=0.95,
    top_p=0.7,
)
print(response.choices[0].message.content)

参数说明：

model: 指定模型，如 glm-4。
messages: 对话消息列表。role 可以是 system（设置背景）、user（用户输入）、assistant（模型回复）。
temperature 和 top_p: 控制生成随机性的参数，可使用默认值。

3. 异步调用
适用于输入较长或无需实时响应的场景，先返回任务ID，再轮询结果。

# 发起异步请求
async_response = client.chat.asyncCompletions.create(
    model="glm-4",
    messages=[{"role": "user", "content": "你好"}]
)
task_id = async_response.id
# 轮询结果
result = client.chat.asyncCompletions.retrieve_completion_result(id=task_id)
print(result.choices[0].message.content)

4. 流式调用
以数据流形式逐步返回结果，提升交互体验。

response = client.chat.completions.create(
    model="glm-4",
    messages=[{"role": "user", "content": "你好"}],
    stream=True,
)
for chunk in response:
    print(chunk.choices[0].delta.content)

GLM-4 的智能体（Agent）能力演示

GLM-4的一个重要特性是支持智能体能力，即通过“工具”（Tools）连接真实世界。模型本身不执行工具，而是生成调用工具所需的参数，由开发者编排后续流程。

1. 函数调用（Function Call）
让模型根据用户问题，生成调用某个函数所需的参数。

response = client.chat.completions.create(
    model="glm-4",
    messages=[{"role": "user", "content": "帮我查询北京南站到上海2024年1月1日的火车票"}],
    tools=[
        {
            "type": "function",
            "function": {
                "name": "query_train_ticket",
                "description": "查询火车票信息",
                "parameters": {
                    "type": "object",
                    "properties": {
                        "departure": {"type": "string", "description": "出发站"},
                        "destination": {"type": "string", "description": "到达站"},
                        "date": {"type": "string", "description": "出发日期"}
                    },
                    "required": ["departure", "destination", "date"]
                }
            }
        }
    ],
    tool_choice="auto",  # 由模型决定是否调用工具
)
# 从 response.choices[0].message.tool_calls 中解析出函数调用参数

2. 知识库检索（Retrieval）
让模型从指定的知识库中查找信息来回答问题。

response = client.chat.completions.create(
    model="glm-4",
    messages=[{"role": "user", "content": "CogView有几种POC方法？"}],
    tools=[
        {
            "type": "retrieval",
            "retrieval": {
                "knowledge_id": "your_knowledge_id", # 替换为您的知识库ID
                "prompt_template": "从文档中查找问题答案。如果有答案，请用文档语句回答；如果没有，请告诉我无法从文档中找到答案。"
            }
        }
    ]
)

3. 联网搜索（Web Search）
让模型从互联网搜索信息来增强回答。

response = client.chat.completions.create(
    model="glm-4",
    messages=[{"role": "user", "content": "智谱AI这家公司怎么样？"}],
    tools=[
        {
            "type": "web_search",
            "web_search": {
                "enable": True,  # 启用搜索
                "search_query": "智谱AI"  # 可指定搜索词，默认为用户问题
            }
        }
    ]
)

多模态与图像模型

1. 视觉模型 GLM-4V
GLM-4V是强大的图文理解模型，定价为 0.1元/千Tokens（图片有固定Token消耗）。调用方式与语言模型类似，只需在消息中传入图片。

response = client.chat.completions.create(
    model="glm-4v",
    messages=[
        {
            "role": "user",
            "content": [
                {"type": "text", "text": "描述这张图片"},
                {"type": "image_url", "image_url": {"url": "https://example.com/image.jpg"}}
            ]
        }
    ]
)

应用场景示例：OCR识别、信息提取（如从发票中提取金额、日期等字段）。

2. 文生图模型 CogView-3
CogView-3是图像生成模型，定价为 0.25元/张。可通过文字描述生成图像。

response = client.images.generations.create(
    model="cogview-3",
    prompt="一只摇滚风格的小猫，抱着电吉他在舞台上表演",
)
image_url = response.data[0].url

提示词（Prompt）需要尽可能具体，以生成更符合预期的图像。

3. 角色扮演模型 Character GLM
Character GLM是超拟人模型，适用于情感陪伴、游戏NPC等场景，定价为 0.015元/千Tokens。通过设置角色元数据（metadata）来控制对话风格。
开发者可在平台“体验中心”直接测试不同角色。

应用案例实践 🛠️

了解了核心API调用后，我们来看两个利用这些API构建的简单应用案例。

案例一：智能客服问答机器人

这个案例展示了如何利用知识库检索（RAG）能力构建一个客服机器人。

创建知识库：在开放平台的知识库平台中，上传客服相关的文档（如PDF、Word或在线文档）。
创建问答应用：基于创建的知识库，配置一个问答机器人应用。可以自定义提示词模板，例如要求模型优先从知识库中寻找答案。
调用应用：用户提问时，机器人会自动从知识库中检索相关信息并生成回答，极大提高问题排查效率。

案例二：简历信息提取与分析

这个案例展示了如何利用大模型的信息抽取和总结能力处理非结构化文本。

加载文档：使用LangChain的Document Loader读取简历文件。
构建提示词：设计提示词，要求模型从简历中提取结构化信息（如JSON格式），或进行特定分析（如评价候选人是否匹配职位要求）。
调用模型分析：将简历文本和提示词发送给GLM-4模型，获取分析结果。

# 简化的提示词示例
prompt_template = """
请从以下简历内容中提取信息，并以JSON格式输出，包含字段：姓名、年龄、学历、工作年限、技能列表。
简历内容：{resume_text}
"""

这可以用于简历初筛、人才库建设等场景，减少重复性人力工作。

开发者资源与总结 📚

本节课中我们一起学习了智谱AI开放平台GLM-4系列模型的API调用方法。最后，为您汇总一些关键的开发者资源，助力您的AI开发之旅：

模型获取：开放平台API、私有化部署、开源模型。
开发工具：LangChain、官方SDK、平台内置应用构建能力。
数据连接：知识库平台、向量数据库、Embedding模型。
提示词优化：平台Prompt模板、开源B-PRO模型（即将开放API）。
模型评估：平台评测中心（即将开放）。

常用资源链接：

Demo GitHub：包含各种场景的使用示例。
SDK GitHub：官方Python/Java SDK仓库，欢迎贡献。
API文档：详细的接口说明。
官方教程与Cookbook：最佳实践和教程集合。

希望本教程能帮助您快速入门GLM-4的API调用，开启您的智能化应用开发。

EmojiAgen🤖️技术分享 - P1 - ChatGLM - BV1qm411y7EP

在本节课中，我们将学习如何制作一个“表情包智能体”。这个智能体能够理解用户的输入，并回复一个语义匹配的表情包。我们将从创意构思开始，逐步讲解数据准备、模型标注、智能体配置到最终发布的完整流程。课程最后，我们还将探讨智能体与API结合的应用潜力，并简要介绍大模型应用安全的相关知识。

🎯 创意来源：为什么是表情包？

上一节我们介绍了课程概述，本节中我们来看看制作表情包智能体的创意来源。

表情包是一种“模因”，指可以被人模仿并传递的信息，例如一段音乐、一个观念或一个流行语。但并非所有模因都能像表情包这样简洁地表达心境。表情包本身具有高度的传染性和多样性。每次发送或接收表情包时，我们的大脑会产生多巴胺，不断触发我们使用表情包的欲望。

大模型的回复有时不够生动。即使通过微调或提供聊天记录来复刻聊天风格，仍感觉缺少趣味性。制作一款表情包智能体的想法由此产生：为对话增添表情包，使其更有趣。

📦 第一步：数据收集与处理

创意确定后，我们需要准备数据。以下是数据准备的关键步骤：

图像收集：需要足够多样化的图像来满足需求，避免内容过于同质化。如果用户输入与表情包内容的语义距离太远，则无法有效匹配。我们从公开渠道的多个分类中爬取了5329张静态和动态的热门表情包图像用于初步测试，后续已扩展到数万张。
格式转换：当前多模态大模型通常不支持直接识别动态图像（如GIF）。我们需要将动态图像批量转换为静态图格式。但为了将用于标注的图像和展示在平台上的图像归为一类，我们选择将其转换为APNG格式。APNG是一种支持PNG动画帧序列存储的格式，目前大部分基于Web渲染的页面都能播放PNG动画。我们使用开源工具ffmpeg来完成转换。

🏷️ 第二步：数据标注

数据准备好后，下一步是进行数据标注。这是最耗时的环节。

我们首先使用阶跃星辰的“跃问”网页版接口完成第一轮数据标注。后续，GM社区赞助了2000万token的GLM-4V API额度，并提供了五路并发支持，我们仅用一小时就完成了第二轮数据标注。

通过数据标注我们发现，当前多模态大模型具备从表情包中提取语义的能力，能够从比较跳跃的语义中理解表情包想表达的核心信息。虽然模型对“梗图”的理解还有提升空间，但整体能力令人期待。图中展示了两条通过计算思维标注出来的数据样例。

☁️ 第三步：素材上传与存储

标注完成后，需要将素材上传到云端存储，并提供可供外部访问的URL。

鉴于我们在智谱清言平台上发布智能体，我们借助其网页文件上传接口来上传图像。这个过程通过编写的脚本模拟网页接口进行批量上传，因为手动上传5000多张图像太慢。脚本批量上传后，会将生成的URL与对应的标注数据进行映射。

🤖 第四步：创建与配置智能体

素材准备就绪后，就可以创建智能体了。以下是配置智能体的核心步骤：

填写基本信息：填写智能体的简介和配置信息。
设定提示词（Prompt）：这是关键步骤，主要设定智能体的任务。目标是提高它对用户内容语义的关注度，让它能分析用户聊天内容，理解聊天意图，提取关键信息。同时，提示词还需指导它如何处理从知识库中检索到的内容，并提供响应案例，告诉它如何以Markdown形式输出URL，以便页面的Markdown渲染器能够处理并展示图片。

📚 第五步：导入知识库

智能体配置好后，需要将数据导入其知识库。

智谱清言的智能体支持使用知识库进行检索。我们将数据导出为Excel文件进行处理。平台接收到文件后，会自动进行数据拆分和向量化处理。

🚀 第六步：发布与使用

完成以上所有步骤后，就可以发布并分享智能体了。

用户只需要输入一句话，智能体就会自动从知识库中检索语义最接近的N条数据，提供给ChatGLM-4作为参考上下文。根据先前的设定，模型需要从用户输入中匹配一条最接近的表情包数据，并输出其URL，最终实现右图所示的效果。大家也可以扫描提供的智能体二维码在微信中体验。

不过，由于URL较长，在多轮对话时可能会发生“幻觉”（即模型错误地编造URL）。建议每次新建对话使用以改善体验。后续计划通过短链来改善幻觉问题。

🔧 技术原理解析

上一节我们完成了智能体的发布，本节我们来解析其背后的工作原理。下图展示了其简化流程，不代表商业化检索增强系统的内部复杂设计，仅供学习参考。

以下是核心步骤的分解：

知识库构建：上传表情包数据（知识库）时，平台内部会解析文件，拆分数据，然后通过Embedding模型将文本转换为向量空间中的矩阵表示。这个过程捕捉文本语义，并将向量矩阵与文本的映射存储到向量数据库或其他存储引擎中。
- 公式表示：文本 -> Embedding模型 -> 向量矩阵
用户查询处理：用户输入一句话（如“拖出去打一顿”），这句话同样通过Embedding转换为向量矩阵。
向量检索：系统通过调用向量数据库或自研的向量检索引擎，寻找与用户输入向量最接近的知识库向量，即进行语义相似度匹配。
上下文构建与推理：检索到的数据经过预处理后，作为上下文输入给大模型（如ChatGLM-4）。模型参考该上下文，推理出最匹配的表情包URL。
结果输出：模型以Markdown格式输出URL，平台渲染后即可展示表情包。

🌐 扩展应用：API与工作流

智能体本身功能强大，但与API结合能碰撞出更多火花。

我们发现通过API调用可以复用智能体的能力，无需自行构建知识库和配置，只需调用API即可实现效果。下图展示了将表情包智能体接入微信后的效果，通过文本和表情包结合提升了对话趣味性。

目前智谱官方的智能体调用API尚未开放，图中效果是通过网页版接口实现的调用。但智能体API是未来趋势。

除了单独调用，智能体在工作流中可以发挥更强大的能力。我们可以将多个智能体组合到一个工作流中，让它们协作完成任务。图中是一个简单的工作流示例：将用户输入发送给ChatGLM-4进行对话，将其回复消息作为表情包智能体的输入，获取匹配的表情包，最后将消息和表情包合并输出，即可得到类似微信中的效果。

智能体加工作流是一种学习成本很低的AI应用搭建工具。

⚠️ 大模型应用安全探讨（红队视角）

在智能体与API功能不断发展的同时，应用安全至关重要。我们是大模型红队，致力于挖掘和分析国产大模型应用的安全风险，以促进厂商完善风控策略。

我们总结了大模型平台可能存在的一些风险，希望厂商在确保平台安全稳定的前提下，尽量提升用户体验。以下是部分风险列表：

认证与授权风险：
- 无条件登录态续期，增加盗号风险。
- 支持非实名手机号或虚拟号码注册，易引发恶意注册。
- Token明文静态存储，未进行动态JS计算，易被窃取。
- 资源所有权不明确，可能导致越权操作（如修改他人信息）。
客户端与接口风险：
- 未有效跟踪和风控浏览器指纹/LBS指纹，导致模拟请求易通过。
- 接口地址未混淆，易于被猜测和攻击。
- 未禁用或监测开发者工具，降低了反逆向能力。
数据与内容风险：
- SSE流数据明文传输或仅简单编码，易被解析。
- 上下文数据未脱敏，可能导致敏感信息（如API Key）泄露。
- 仅对模型输入进行整体审查，对模型自行输出的内容审查不足。
功能滥用风险：
- 无限制的文件上传，可能使平台沦为网盘或图床。
- 无限制地调用外部API，缺乏黑白名单和审核，可能导致上下文污染。
- 资源额度错配，可能被利用以小资源消耗大资源额度。

我们正在与多家厂商开展合作，通过发现和报告风险，共同促进大模型安全生态建设。

📝 课程总结

本节课中，我们一起学习了“表情包智能体”从创意到实现的全过程。我们了解了其创意来源、数据准备、标注、上传、智能体配置、知识库导入和发布的完整步骤，并解析了其背后的检索增强生成（RAG）技术原理。此外，我们还探讨了智能体与API、工作流结合的扩展应用潜力，并简要了解了大模型应用安全中需要注意的各类风险。希望本教程能帮助你理解如何构建一个有趣且实用的AI智能体应用。

课程一：GLM-4的两个核心：规模化与对齐 🚀

在本节课中，我们将学习ChatGLM团队分享的大语言模型（LLM）发展的两个核心驱动力：规模化与对齐。我们将了解为何模型参数会不断增长，以及如何让强大的基座模型更好地理解并执行人类的指令。

规模化：为何越大越好？📈

上一节我们介绍了课程的核心主题。本节中，我们来看看第一个核心概念：规模化。

随着ChatGPT和GPT-4的发布，大模型引发了新一轮热潮。与此同时，大模型所需的计算力也在迅速增长。GPT-2（2019年发布）只有15亿参数，而GPT-3达到了1750亿参数。据传，GPT-4的参数规模高达1.8万亿。这表明，单个模型的参数量或计算量正以每年约十倍的趋势增长。

我们为何要追求参数量的增加？可以从一项谷歌的研究中找到答案。该研究在“新算符定义算术”和“国际音标翻译”两个具有挑战性的任务上进行了实验。

以下是其实验发现：

从1000万到10亿参数规模的模型，性能几乎没有提升。
当模型规模扩展到100亿到1000亿参数时，模型性能出现了快速涌现的现象。

我们把这种效应称为模型性能的涌现效应。正是这种从量变到质变的能力，驱动着我们不断扩展计算规模，即进行 scaling。

如果我们把现有经典模型列成表格，会发现scaling仍然是提升模型性能的有效途径。例如，对比GPT-3和另一个130B参数的模型，两者总计算量大致相同，在MMLU数据集上的表现也相近。

然而，并非所有的scaling都是最高效的。例如，PaLM 540B模型的算力几乎是LLaMA 70B模型的三倍，但它们在MMLU数据集上的准确率却差不多。我们认为，在模型容量足够的情况下，有效学习更多高质量数据，模型的性能才会更强大。

智谱团队近两年也在scaling方面不断探索：

2020年：开始研发GLM系列模型。
2021年：开源了GLM-10B模型。
2022年：开源了GLM-130B系列模型。
随后的ChatGLM-2、ChatGLM-3，都是团队在scaling上进一步探索，以提升模型基座能力的结果。

对齐：让模型理解人类意图 🤝

光有强大的基座模型可能还不够。大模型的最终目标是满足人类意图，完成人类任务。从GPT-3到ChatGPT，关键步骤不在于基座能力的提升，而在于对模型进行了更好的对齐，使其能更好地理解人类意图。

随着ChatGLM基座模型能力的提升，其对齐能力也在不断增强。从ChatGLM-130B（MMLU准确率约44%）到ChatGLM-4（MMLU准确率81.7%），模型的对齐能力获得了显著进步。

以下是ChatGLM在对齐能力上的演进：

第一代模型：在基座模型基础上进行了初步的人类意图对齐。模型从一个只会复读问题的“傻”模型，变成了能进行流畅对话的人工智能助手。
第二代ChatGLM-2模型：解锁了32K长文本理解能力，使模型能够支持PDF阅读、长文档解读等一系列下游应用。
第三代ChatGLM-3模型：进一步引入了函数调用能力，使模型首次能够与外部的API进行初步交互。

ChatGLM-4 All Tools：强大基座与工具的融合 ⚙️

基于GLM-4强大的基座能力，团队进一步解锁了其在128K长上下文下的复杂任务处理能力，该系统被称为ChatGLM-4 All Tools（或称All Tools系统）。

All Tools系统的总体架构如下：基于GLM-4强大的基座能力、出色的工具调用能力以及128K长上下文，模型能够处理非常复杂的用户任务需求。

当用户提出任务需求后，模型会智能分析并进行工具调用。如果不需要工具，模型也会正常回复。与普通函数调用不同的是，All Tools模型可以智能规划并迭代交互，进行多轮、多工具调用，最终目的是完成用户需求。

网页浏览：超越传统检索生成

以上描述可能有些抽象。让我们用GLM-4 All Tools的“网页浏览器”功能为例，详细讲解其复杂的交互能力。

传统的基于检索生成（RAG）方法通常将用户输入的提示词（prompt）经过一个检索器模块，检索到相关内容后交给模型，模型综合参考信息和用户输入来生成回复。

对于大部分常规情况，传统RAG方法表现良好。但对于一些复杂场景，例如多跳问答，单次检索可能无法获取到有意义的信息。此时，模型无法从参考信息中得到有效回复，而传统的RAG方法无法让模型与检索模块进行再次交互，存在较大局限性。

我们的All Tools高级联网功能则不同。模型可以直接接受用户任务，自行规划检索子任务、选择信息源、与信息源交互，并根据任务进度迭代获取信息，从而极大地增强了模型的信息收集能力。

在基准测试（benchmark）上可以看到，GLM-4结合高级联网功能，相比GLM-3的传统RAG方案有巨大提升，同时相比GPT-4的Web Browsing功能也有明显优势。

以下是一个展示All Tools多跳能力的案例：

问题：我要去参加2023年CCF中国开源大会，当天的天气如何？

要解答这个问题，传统RAG模块拿到这个查询（query）后，很难一次性找到答案。我们的GLM-4 All Tools模型可以将其分解为两个查询：

检索“CCF开源大会的日期和地点”，得到“10月21日，长沙”。
结合第一个信息，检索“10月21日长沙的天气”。

模型综合这两个信息后，就能回答用户的问题。这就是GLM-4 All Tools利用网页浏览功能进行复杂网络交互的例子。

代码解释器：扬长避短解决复杂计算

GLM-4同样引入了代码解释器功能。现有大量研究表明，即使是GPT-4，也不擅长进行多位数的加减乃至更复杂的计算。

我们的GLM-4 All Tools模型可以通过调用Python解释器，以一种扬长避短的方式来解决模型不擅长的复杂计算，从而提高模型的数学能力。

从基准测试可以看到，GLM-4结合代码解释器的All Tools能力，在各个数学基准测试上都处于第一梯队。相比未使用代码解释器的GPT-4，有着非常明显的提升。这表明，利用代码解释器解决数学计算问题的思路，能带来巨大的性能收益。我们不必让本就不擅长直接计算的语言模型，去硬扛计算任务。

多工具联合调用：处理复杂综合任务

同时，我们的All Tools模型可以联合调用多个工具。这是一个更复杂的案例：

问题：根据小鹏汽车去年的公告，披露了多少融资？并计算在最新汇率下约合多少美元。

这个查询非常复杂。模型需要：

搜索“小鹏汽车去年公告披露的融资额（人民币）”。
搜索“查询当天的最新汇率（美元兑人民币）”。
进行正确的货币换算计算。

我们可以看到，All Tools模型完美地执行了两个搜索指令，找到了融资额和汇率，并调用了代码解释器进行计算，结果准确无误。这展现了All Tools模型的两个优势：一是将计算转为Python解释器调用以避免误差；二是能通过网页搜索解决复杂的用户需求。

与文生图模型联动：实现上下文连贯创作

最后，GLM-4 All Tools模型还与最新一代的文生图模型（CogView）进行了联动。相比于传统的单轮绘图，我们的模型可以实现结合上下文的互动创作。

其原理是：当模型进行一轮CogView生成时，会将相关的prompt保留在对话历史中。当用户进行下一轮提问时，模型会自主判断这是否是一个画图请求。如果不是，则走正常生成流程；如果是，则会根据上一轮的画图prompt，智能地按照用户新需求进行修改，从而实现结合上下文的AI绘图创作。

例如：

第一轮：要求画一个“开发者大会的场景”。
第二轮：要求改成“CEO在台上演讲”。
第三轮：要求“最后大家画一张合影”。

All Tools模型能很好地理解多轮对话需求，最终呈现出一个具有故事感的连续创作。

另一个案例是：先让模型画一只“柯基犬”，然后不断要求它“跑得越来越快”。模型能很好地遵循指令，从一只可爱的柯基，逐渐变成背景虚化、充满动感的奔跑状态，甚至最后带有一些虚幻的感觉。这表明GLM-4能够基于上下文修改画图prompt，实现复杂的创作需求。

我们的文生图模型也可以联合网络浏览功能。例如，提问：“2024年巴黎奥运会的宣传语是什么？并画一幅图来突出宣传语中的场景。”模型能够自动联网搜索宣传语内容，并根据内容生成一幅符合主题的图片。这体现了All Tools模型多工具联合，并能根据上一轮搜索内容智能生成下一轮画图prompt的能力。

总结 📚

本节课中，我们一起学习了GLM-4发展的两个核心：

规模化：通过增加模型参数和计算量，利用“涌现效应”实现模型能力的质变。
对齐：通过技术手段让强大的基座模型更好地理解并执行人类指令，例如工具调用、长上下文理解等。

基于这两个核心，ChatGLM-4 All Tools系统将强大的基座能力与多种工具（网页浏览、代码解释器、文生图）深度融合，实现了智能规划、迭代交互、多工具联合调用的复杂任务处理能力，为更广泛、更复杂的实际应用场景提供了可能。

ChatGLM 课程 01：GLM-4 模型与 All Tools 功能详解 🚀

在本节课中，我们将学习智谱 AI 最新发布的 GLM-4 大语言模型及其核心功能。我们将了解其作为新一代基座模型的特点，并重点解析其强大的“All Tools”集成能力。

GLM-4：新一代基座大模型 🧠

今天，我们正式介绍 GLM-4。它是智谱 AI 推出的新一代基座大语言模型。

上一节我们介绍了 GLM-4 的发布，本节中我们来看看它的核心功能架构。

All Tools：一体化智能工具箱 🛠️

GLM-4 的一个关键特性是集成了“All Tools”功能。这意味着模型能够在一个对话中，根据用户的需求，自主调用不同的工具来完成任务，例如联网搜索、代码解释、文件处理等。

以下是“All Tools”功能可能包含的核心工具类型：

联网搜索：获取实时信息。
代码解释器：执行和解释代码片段。
多模态理解：处理和分析图像、文档等文件。
长文本处理：高效总结和分析超长文档。

这种设计让 GLM-4 不再仅仅是一个对话模型，而是一个能够主动使用工具解决问题的智能体。其工作流程可以抽象为以下模式：

用户请求 -> GLM-4 理解与规划 -> 调用相应工具 -> 整合工具结果 -> 生成最终回复

GLMs：定制化模型生态 🌐

除了强大的基座模型，GLM 生态还包含一系列针对特定场景优化的模型，统称为 GLMs。

这些定制化模型在特定领域，如代码生成、数学推理或创意写作上，可能表现得更专业、更高效。用户可以根据自己的具体需求，选择合适的 GLM 模型。

本节课中我们一起学习了 GLM-4 新一代基座大模型的核心特点。我们重点探讨了其“All Tools”功能如何通过集成多种工具来增强模型的问题解决能力，并简要介绍了 GLMs 定制化模型生态。理解这些概念，是有效利用 ChatGLM 系列模型的第一步。

GLM 使用指南：入门 GLM API（全）🚀

在本节课中，我们将要学习如何开始使用智谱 AI 的 GLM 系列大模型 API。我们将介绍官方教程 GLM CookBook 的设计理念、内容结构以及为你规划一条清晰的学习路径，帮助你从零开始快速上手大模型 API 的调用。

课程概述与背景

我是来自智谱 AI 技术团队的成员，也是 GLM CookBook 的作者。本次直播作为系列的第一期，旨在为刚刚接触大模型的开发者或学生提供一个清晰的学习起点。我们将聚焦于如何快速上手大模型 API 调用这一核心问题。

后续的第二场和第三场直播将深入讲解具体的 demo 和实战案例。

为什么需要 `GLM CookBook`？

许多开发者最初接触大模型开发是通过 OpenAI 的 API。然而，国内大模型的 API 接口各异，导致学习成本高、适配工作繁琐。开发者们面临几个核心痛点：

API 不统一：学习过 OpenAI API 的开发者，在切换至国内不同厂商的模型时，常遇到接口不兼容的问题。
缺乏从零开始的教程：部分开发者完全没有大模型 API 使用经验，需要一个系统的入门指南。
不清楚 API 能做什么：即使掌握了基础调用，许多开发者也不清楚如何利用 API 构建一个最小可行产品（MVP）。

GLM CookBook 正是为了解决这些问题而设计的。

`GLM CookBook` 的设计理念与特点

与一些专注于前沿论文复现的教程不同，GLM CookBook 的核心目标是降低使用门槛，提升开发效率。

降低门槛，注重实用：我们优先提供入门级内容和常见的、可执行的最小方案。教程中的代码可以直接复用或进行二次开发。
整合两大平台：智谱 AI 目前有两套 API 系统：
- 开放平台 API：提供 GLM-4、GLM-4V、ChatGLM 等模型的接口，功能对标 OpenAI。
- 智谱清言 API：主要面向智能体（Agent）的构建和调用。
  GLM CookBook 将这两部分内容整合在一本教程中，方便开发者按需选择。
开源与社区驱动：教程完全开源并托管在 GitHub 上，方便开发者获取代码、提出建议（Issue）甚至贡献代码（Pull Request）。

教程框架结构

GLM CookBook 的整体结构分为五个主要部分，如下图所示：

以下是各部分的简要说明：

GLMs（智谱清言）：
- 提示词构建：介绍如何配置智能体，并提供了一些现成的智能体配置示例。
- 智能体 API：讲解如何接入智谱清言的智能体 API，以及如何让智能体去调用第三方 API。
Basic（基础）：API 使用的起点。涵盖计费方式、基础调用方法以及如何与主流开源框架（如 LangChain）进行对接。
Vision（多模态）：专门讲解图像理解模型 GLM-4V 和文生图模型 CogView3 的使用。
Demos（应用示例）：在掌握基础后，可以学习如何利用 API 实现具体功能。例如：
- 推理任务
- 发挥 GLM-4 的 Agent、Function Call、代码分析、数学计算等特长能力。
- 如何编写和调试提示词。
Fine-tune（微调）：介绍如何使用智谱 AI 的微调平台对模型进行定制化训练，训练后的模型可直接通过 API 调用。

注意：GLM CookBook 主要关注 API 和智谱清言的应用层教程。关于开源模型（如 ChatGLM3-6B）及其本地部署的教程，请访问智谱 AI 在 GitHub 上的 THUDM 组织下的相关仓库。

提供的代码示例

教程中包含了大量即拿即用的代码示例。

API 部分：每个功能都以独立的 Jupyter Notebook 形式提供。
- OCR 识别：结合 Python OCR 库与 GLM，实现文档扫描与问答。
- 数据分析：读取 CSV 文件，让模型完成数据抽取与分析。
- Agent 应用：包括最简单的工具调用（Function Call）、任务规划（Planning）以及多角色互动的简易仿真。
智谱清言部分：提供智能体热榜、API 接入方案，并计划分享部分公开的智能体提示词配置。

教程更新迅速，后续会有更多新功能和应用案例加入。

学习路线图

对于初学者，我们推荐以下学习路径：

准备资源：
- API 部分：需要在智谱 AI 开放平台注册并完成实名认证，以获取 API Key 和初始赠送的 tokens（约 10万-20万 tokens 即可完成基础部分学习）。
- 智谱清言部分：只需注册智谱清言账号并完成实名认证即可获得 API 调用额度。
选择学习路径：建议开发者优先学习 API 调用 部分，因其功能更全面，上限更高，更适合应用开发。
循序渐进：
- 从 Basic 开始，学习 GLM-4 的基础调用。
- 然后学习 Vision，掌握多模态模型的使用。
- 接着研究 Demos 中的各种应用案例。
- 此时，你已具备将 GLM API 接入各类开源框架（如 LangChain）的能力，可以开始系统性学习这些框架，并构建自己的应用。

这条路径帮助你从最底层的模型调用，平滑过渡到基于框架的完整应用开发。

如何获取帮助与反馈

学习过程中遇到问题或有新的想法，可以通过以下渠道反馈：

GitHub Issues：这是最主要的反馈渠道。如果你发现教程代码有误、有优化建议，或是有新的功能需求，都可以在项目的 GitHub 仓库中按模板提交 Issue 或 Pull Request。
官方微信群：用于开发者之间的交流讨论，链接可在教程相关页面找到。

我们鼓励大家积极提出问题，共同完善教程。

常见问题解答（Q&A）

上一节我们介绍了反馈渠道，本节中我们整理了一些直播中的常见问题供你参考。

教程在哪里？
教程位于 GitHub：https://github.com/THUDM/GLM-CookBook。你可以克隆整个仓库到本地，所有教程都是可交互的 Jupyter Notebook 文件。
如何开始调用？需要多少费用？
1. 在开放平台注册并获取 API Key。
2. 对于学习基础调用，使用价格更低的 GLM-3 模型完全足够。GLM-4 更适合体验 Function Call 等高级功能。具体价格请参考平台公告。
API 调用慢怎么办？
对于未充值的用户，并发数可能较低。充值达到一定额度后，并发数会动态提升。首 token 时间问题团队正在优化中。
智谱清言 API 和开放平台 API 有什么区别？
- 智谱清言 API：更侧重于智能体的无代码构建和调用，功能相对简单，适合快速搭建对话应用，但灵活性和性能低于开放平台。
- 开放平台 API：功能全面，对标 OpenAI，提供丰富的参数控制和高级功能（如 Function Call, Planning），适合复杂、高性能的应用开发。
多模态、RAG（检索增强生成）、Agents 有教程吗？
- 多模态：在 Vision 部分有 GLM-4V（图理解）和 CogView3（文生图）的详细教程。
- RAG：这属于应用框架层的能力，建议在学习 LangChain 等框架时，将 GLM 作为模型基座接入。教程 Demos 中也会涉及相关思路。
- Agents：将在后续直播（第二/三期）中详细讲解 Planning 和 Function Call 等 Agent 相关能力。
提示词能和 ChatGPT 通用吗？
大部分基础提示词技巧（如 CoT）是通用的。但由于模型结构差异，对于需要精确控制输出的场景，提示词可能需要针对 GLM 进行微调。许多开源框架（如 LangChain）的 Agent 提示词可以直接复用。
数据安全如何保障？
开放平台承诺不会使用用户的 API 调用数据做二次训练。如果对数据出境有极端严格的要求，建议使用本地部署的开源模型。
如何实现“找不到答案时用模型自身知识回答”？
这是可以实现的。通过提示词工程进行控制即可：在 RAG 流程中，如果检索结果为空，则指示模型忽略检索内容，直接运用自身知识库回答；如果检索到内容，则基于检索内容回答。这也可以通过 LangChain 等框架的流程编排来实现。

下期预告与总结

本节课中我们一起学习了 GLM CookBook 的定位、结构和学习路线，为你使用智谱 AI 大模型 API 奠定了坚实的基础。

从下一期开始，我们将进入实战环节。第二期直播将聚焦于具体的 Demo，我会选择一两个应用案例，从第一行代码开始，详细讲解设计思路、实现步骤以及模型在其中扮演的角色，帮助你更深入地理解如何将 API 用于实际工程。

期待在接下来的课程中与你继续探索！

GLM法律行业大模型挑战赛 · 答疑与Baseline分享教程 📚

课程概述

在本节课中，我们将学习GLM法律行业大模型挑战赛的赛题背景、赛制规则、数据集描述以及三位优秀选手分享的Baseline方案核心思路。课程旨在帮助初学者理解比赛要求，并掌握构建法律问答智能体的基本方法。

第一部分：赛题与赛制介绍 🏁

本次比赛由智谱AI牵头，联合深圳数据交易所、安硕信息、魔搭社区共同承办，天池平台为指定竞赛平台。比赛旨在利用大语言模型的语义理解与函数调用能力，精准分析法律问题，通过规划任务、调用法律数据库或API，提供相关法律服务。

比赛流程与时间线

以下是本次比赛的主要阶段和时间安排：

报名与组队阶段（第一阶段）：选手需在天池平台和琶洲算法大赛官网完成双平台注册与实名认证，截止时间为6月30日上午10点。队伍人数限制为1-3人。
初赛阶段：
- A榜：6月11日至6月30日。
- B榜：7月1日至7月14日。B榜将公布更多API，赛题难度升级。
- 初赛总成绩由A榜（30%）和B榜（70%）加权得出。
复赛阶段：7月21日至8月4日。此阶段需在Docker环境下运行，且B榜为“盲打”模式（即看不到具体题目对错）。复赛前八名队伍进入决赛答辩。
决赛与总决赛：暂定9月举行。决赛成绩由复赛成绩（60%）和答辩成绩（40%）综合评定。本赛道冠军将有机会参加总决赛，与其他赛道冠军角逐更高奖项。

数据集与赛题示例

数据集来源于随机抽取的上市公司，包含以下信息：

公司基本信息与工商信息。
关联子公司信息。
裁判文书信息。
法律场景文书模板（如起诉书、反诉状）。
法律条文。
法律报告模板。

赛题示例如下：

简单查询：我想联系瑞丰光电的法人代表，他的名字是什么？
- 思路：根据公司名称调用公司基本信息API，提取“法定代表人”字段。
- 答案示例：蔡瑞雄。

链式查询：根据股票代码“601865”查询公司全称，并进一步查询其英文名称。
- 思路：先调用根据股票代码查询公司全称API，再用得到的公司全称调用公司基本信息API查询英文名。

复杂查询与统计：
- 化学原料和化学制品制造业这个行业的公司有哪些？请列出注册资本最大的三家头部公司，并给出他们的具体注册资本数额。
  - 思路：先查询该行业所有公司，再按注册资本排序，取前三名。
- 上海家化联合股份有限公司为原告时，主要和哪家律所合作？合作次数为几次？
  - 思路：查询该公司作为原告的所有裁判文书，统计合作律所的出现频率。

API调用与测评指标

API调用示例（已封禁，仅作格式参考）：

# 假设的API调用代码结构
import requests
import json

![](https://github.com/OpenDocCN/dsai-notes-zh/raw/master/docs/chatglm/img/29ac4df9eec97854db7ec5d276e81b63_22.png)

![](https://github.com/OpenDocCN/dsai-notes-zh/raw/master/docs/chatglm/img/29ac4df9eec97854db7ec5d276e81b63_24.png)

![](https://github.com/OpenDocCN/dsai-notes-zh/raw/master/docs/chatglm/img/29ac4df9eec97854db7ec5d276e81b63_26.png)

![](https://github.com/OpenDocCN/dsai-notes-zh/raw/master/docs/chatglm/img/29ac4df9eec97854db7ec5d276e81b63_28.png)

![](https://github.com/OpenDocCN/dsai-notes-zh/raw/master/docs/chatglm/img/29ac4df9eec97854db7ec5d276e81b63_30.png)

![](https://github.com/OpenDocCN/dsai-notes-zh/raw/master/docs/chatglm/img/29ac4df9eec97854db7ec5d276e81b63_32.png)

url = "https://api.example.com/getLegalRep"
headers = {"Authorization": "Bearer YOUR_API_KEY"}
data = {"company_name": "瑞丰光电"}

![](https://github.com/OpenDocCN/dsai-notes-zh/raw/master/docs/chatglm/img/29ac4df9eec97854db7ec5d276e81b63_34.png)

![](https://github.com/OpenDocCN/dsai-notes-zh/raw/master/docs/chatglm/img/29ac4df9eec97854db7ec5d276e81b63_36.png)

response = requests.post(url, headers=headers, json=data)
result = response.json()
print(result) # 输出：{"legal_representative": "蔡瑞雄"}

测评指标：
最终得分由两部分构成：
最终得分 = 0.6 * 关键结果准确度得分 + 0.4 * 语义相似度得分
关键结果指标准答案中的核心实体或数值。

第二部分：Baseline方案分享 💡

上一部分我们梳理了赛题的基本情况，接下来我们深入看看三位选手是如何设计解决方案的。他们的方案各有侧重，但核心都围绕如何让大模型理解问题、规划步骤并调用工具。

方案一：法外张三团队 - 基于任务规划（Plan-Action）的Pipeline

该方案的核心思想是将复杂问题分解为可执行的原子操作序列。

整体流程如下：

问题分类：使用大模型的Few-Shot能力，先将问题分为“开放性问答”或“需查表问答”。若是开放性问题，则直接由大模型生成答案。
基表选择：对于需查表的问题，再次分类，确定问题主要基于哪张数据表（公司表、注册表、子公司表、案件表）。公司表和注册表操作相似，可合并处理。
方案生成（Plan）：根据问题和选定表的结构，让大模型生成一个解决该问题的逻辑计划（Plan）。一个Plan可能包含多个子步骤。
- 例如：对于问题“列出酒饮料制造业注册资本最大的三家公司”，Plan可能是：
  1. 查询行业为‘酒饮料制造业’的所有公司（查询操作）。
  2. 将上述公司列表按注册资本降序排序（排序操作）。
  3. 取前3家公司，并总结其名称和注册资本（总结操作）。
执行与整合（Action）：为每种操作类型（查询、筛选、排序、统计、总结）编写对应的执行函数（Action）。按顺序执行Plan中的每一步，并将每一步的结果（数据流）传递下去。最后，将所有中间结果和原始问题一起提交给大模型，让它生成忠于关键信息的最终答案。

该方案的优点是逻辑清晰，将问题拆解得非常细致，可控性强。挑战在于需要为不同的操作类型编写可靠的执行代码，且Plan的生成质量依赖于提示工程。

方案二：五七团队 - 基于智能体（Agent）与工具封装的架构

该方案采用更工程化的分层架构，灵感来源于传统的服务分层设计。

整体架构如下：

用户问题 -> Router（路由层） -> Agent（智能体层） -> Tools（工具层） -> Services（服务层） -> APIs（API层）

API层：封装比赛提供的8个原始API。注意处理输入格式（如全角括号转半角）、空值等边界情况以增强健壮性。
服务层：将原子API组合成有业务意义的服务。例如，根据行业统计公司数量服务，内部会先调用查询行业公司列表API，再对结果计数。
工具层：将服务封装成大模型可以理解和调用的“工具”。需要精心编写工具的名称、描述和参数说明，以引导大模型正确使用。
智能体层：创建不同的智能体（如“公司查询专家”、“法律咨询专家”），每个智能体配备不同的工具包。智能体根据提示词和可用工具，自主决定调用哪个工具、传入什么参数，并可以基于返回结果决定下一步行动（ReAct模式）。
路由层：首先用一个简单的分类器（Zero-Shot或Few-Shot）将问题路由到最合适的智能体。例如，将涉及公司信息的问题路由给“公司查询专家”智能体。

该方案的优点是架构清晰，易于扩展和维护。通过分层封装，降低了每一层的复杂度。挑战在于需要设计有效的提示词来引导智能体正确使用工具，并防止其陷入无效循环。

方案三：张江高科AI特战队 - 基于开源平台（Dify）的低代码实现

该方案利用开源LLM应用开发平台Dify，通过可视化配置的方式快速构建智能体应用。

实现步骤：

Workflow开发：在Dify中创建“工作流”。将官方的8个API封装为工作流节点，并在此基础上开发更复杂的工作流（如排序、过滤、统计）。例如，可以创建一个“查询某行业注册资本Top N公司”的工作流。
发布为工具：将开发好的工作流发布为“扩展工具”。需要定义工具的名称、描述和输入参数，以便智能体调用。
配置智能体：在Dify中创建一个“智能体”，为其赋予角色和技能提示词，并将上一步创建的所有工具关联给该智能体。
服务部署与调用：将Dify应用部署为后端服务，通过其提供的API接口，用Python脚本批量处理赛题并生成答案文件。

该方案的优点是开发效率高，无需编写大量底层代码，通过图形化界面即可完成复杂逻辑的编排，且便于调试。挑战在于对平台有一定依赖，且需要深入理解平台特性以优化智能体表现。

第三部分：进阶思路与常见问题答疑 ❓

在学习了三个Baseline方案后，我们可以思考一些更前沿的优化方向和比赛中遇到的实际问题。

进阶思路参考

任务自动规划：参考AutoGen、Camel等多智能体框架，或智谱Auto的设计，让智能体自主完成复杂任务的分解、工具调用和结果迭代优化。
提示词优化：将提示词模板化并存入向量数据库，根据问题检索最相关的提示词，以节省Token并提升准确性。
处理不确定性：设计健壮的异常处理机制，例如当查询结果为空时，让智能体尝试转换查询关键词（如中英文转换）后重试。

常见问题答疑（Q&A）

Q：控股子公司超过50%有几家，如何理解？
- A：此题意为查询控股比例大于50%（不包括等于100%的全资子公司）的子公司数量。需要先查询所有子公司列表，再筛选出“持股比例”字段大于50%的记录，最后进行计数。
Q：可以使用网上数据或微调模型吗？
- A：不建议使用网络数据，因为复赛B榜数据会随机打乱，网络答案可能不匹配。模型微调虽未被禁止，但比赛核心考察的是任务规划与工具调用能力，而非模型本身的领域知识。
Q：如何控制大模型输出稳定的JSON格式？
- A：在提示词中明确指定输出格式，并给出一个清晰的JSON示例，大模型通常能很好地遵循。
Q：初赛B榜会有何变化？
- A：B榜将提供更多API（计划约20个），题目更复杂，例如可能要求根据多个信息生成法律文书（如起诉书）。题目模板数量也会大幅增加。

课程总结

本节课我们一起学习了GLM法律行业大模型挑战赛的完整面貌。我们从赛题解读入手，明确了比赛的目标是利用大模型进行语义理解和函数调用，以解决法律垂直领域的问题。接着，我们详细分析了三位选手的Baseline方案：

法外张三团队的Plan-Action管道方案，展示了如何通过精细的任务分解来解决问题。
五七团队的分层Agent-Tool架构，体现了工程化思维在LLM应用中的重要性。
张江高科AI特战队的Dify平台实践，提供了快速构建和迭代智能体应用的新途径。

这些方案从不同角度启发了我们：复杂任务可以通过规划来拆解，工具可以通过分层来封装，开发可以通过平台来提效。最后，我们探讨了一些进阶思路并解答了常见问题，希望大家能在此基础上，发挥创意，构建出更加强大和智能的法律问答系统。

课程名称：GLM法律大模型挑战赛 · 初赛B榜数据与接口详解 🧠

概述

在本节课中，我们将详细解析GLM法律大模型挑战赛初赛B榜所使用的全部数据表、API接口设计以及评分标准。我们将逐一介绍13个核心数据表的结构、功能、关联关系，并通过具体示例说明如何调用接口来解答赛题。课程旨在帮助参赛者清晰理解数据全景，掌握解题的关键路径。

数据表总览与赛制说明

初赛B榜共涉及13个数据表。每个赛区的前十名将晋级复赛。最终的复赛名单将于7月22日公布。

评审方案会结合所有选手的表现进行灵活调整。选手无需对某一道特别困难的题目过于纠结。赛题设计留有一定空间，不会卡得特别死，目的是让努力参赛并对赛题感兴趣的人，能尽量获得更多机会。因此，遇到确实难以回答的题目，可以先解决大部分问题。

核心数据表详解

上一节我们介绍了赛制，本节中我们来看看构成赛题基础的13个数据表。

1. 上市公司基本信息表

此表数据来源于随机抽取的上市公司名单，并获取了其相关公开信息。

以下是该表包含的主要字段示例：

公司名称、公司简称
公司代码（即股票代码）
法人代表（亦称法定代表人、法人）
总经理、董事会秘书（董秘）
注册地址、办公地址
联系电话、传真、官网、电子邮箱
主营业务范围、机构简介等

接口特点：支持通过公司名称、公司简称或公司代码进行查询，三者均可查到同一条信息。例如，输入“妙可蓝多”、“上海妙可蓝多食品科技股份有限公司”或股票代码“600882”，返回结果相同。
关键关联：表中的地址字段（注册地址、办公地址）可能与后续的地址解析表产生关联。

2. 公司工商账面信息表

此表包含了上市公司及非上市公司的工商注册信息，字段与上市公司表有相似也有不同。

核心区别与答题策略：

数据范围：包含上市公司与非上市公司。
字段差异：相同含义的字段可能名称不同（如“法人”与“法定代表人”）；同一家公司的“企业地址”和“注册地址”也可能不同。
时效性：两表数据取自不同时间点，信息可能存在变动和不一致。

答题建议：若题目未明确指定查询哪个表，最稳妥的方式是同时调用两个相关接口，并分别说明结果。例如：“经查询，该公司在工商信息表中的法定代表人是A，在上市公司信息表中的法定代表人是B。”
接口设计：提供两个接口：
* get_company_info_by_name：根据公司名称查询全部信息。
* get_company_registered_name：仅能输入统一社会信用代码，输出对应的公司名称。此设计用于增加查询链的复杂性。

3. 上市公司投资子公司关联信息表

此表记录了上市公司（母公司）与其投资子公司之间的关系。

以下是字段说明：

上市公司：母公司名称。
关联公司：此字段实际指代“子公司”名称。
参股比例：母公司对子公司的投资比例。
投资金额：母公司的投资额。

接口功能：

根据子公司名称，查询其被哪些上市公司投资，以及投资比例和金额。
根据上市公司名称，查询其投资了哪些子公司（返回列表）。

4. 法律文书信息表

此表基于母公司及子公司清单，抽取了部分裁判文书信息。

以下是该表的核心字段：

关联公司：涉案公司。
案号：案件的唯一编号。
标题：案件标题。
文书类型：如民事判决书、刑事判决书等。
原告、被告：注意在实际场景中，称谓多样（如申请人、被执行人、被申请人等）。
原告律师事务所、被告律师事务所
案由：案件事由。
涉案金额
判决结果
日期：此为审理日期。案号中的括号年份（如(2020)）代表立案年份，两者可能不同。

关键概念：案号解析
案号格式例如：(2020)京0105民初49970号

京0105：法院代字，可唯一对应具体法院。
民：案件类型（民事）。
初：审级（初审）。
49970：案件序号。

接口功能：

通过唯一案号查询单条案件详情。
通过公司名称查询其关联的所有案件列表。

5. 法院基础信息表 & 6. 法院代字信息表

这两个表用于管理法院信息。

法院基础信息表：相当于法院名录，包含法院标准化名称、地址、联系电话等。但实际文书中法院名称可能有多种叫法。
法院代字信息表：核心表，建立了法院代字（如“京0108”）与法院全称（如“北京市海淀区人民法院”）的一一对应关系。这是连接案号与法院实体的关键。

接口功能：支持通过法院代字查名称，或通过法院名称查代字。

7. 律师事务所信息表 & 8. 律师事务所业务数据表

这两个表管理律师事务所信息及其业务数据。

律师事务所信息表：名录信息，包含名称、负责人、规模、地址、电话等。
律师事务所业务数据表：记录了某一年度，律师事务所服务上市公司的情况，如服务公司数量、涉及违规事件数等。

9. 通用地址省市区信息表 & 10. 通用地址编码表

这两个表用于地址的解析和标准化。

通用地址省市区信息表：输入一个完整地址，输出解析后的省、市、区信息。此为简化版，未包含街道等更细粒度信息。
通用地址编码表：根据省、市、区名称，查询其对应的行政区划编码。当前也仅支持省市区三级。

11. 天气数据表

根据日期、省份、城市，查询该日期的天气情况，如最高/最低温度、湿度等。

12. 文书摘要表

模拟了一个NLP摘要接口。输入案号，返回该对应裁判文书的摘要内容。为保证赛题可验证，实际数据是预设好的。

13. 限制高消费数据表

此表为格式化数据，与法律文书信息表类似，以案号为核心。

包含字段有：案号、被限制高消费企业名称、涉案金额、立案日期、发布限制消费令的日期、执行法院等。
接口功能：支持通过案号查询单条，或通过公司名称查询多条记录。

高级功能与接口（初赛未强制要求）

上一节我们介绍了基础数据表，本节中我们来看看一些为复赛或更复杂场景设计的高级功能接口。

求和与排序接口 (`get_sum`, `get_rank`)

设计初衷是为增加挑战性，但因数据单位（港币、美元、日元等）不统一等问题，在初赛阶段不强制调用。复赛可能会优化并引入。

结构化报告生成

这是比赛希望导向的应用场景之一：针对一家公司，自动生成一份整合其工商信息、投资子公司、涉案文书、限制消费令等信息的综合报告，并可加入图表和分析描述。

法律文书生成（如起诉状）

提供了生成起诉状等法律文书模板的接口。需要填入当事人（公司或个人）信息、诉讼请求等字段，系统会填充模板。此功能旨在展示更广阔的应用可能性。

评分标准与例题解析

评分机制

总得分由两部分加权构成：
最终得分 = 0.6 * 关键结果得分 + 0.4 * 语义相似度得分

关键结果得分：答案中是否包含了所有预设的关键词(Key)。目前规则是需全部命中才能获得这0.6分，否则为0分。
语义相似度得分：在关键结果正确的基础上，评估整体答案的语义质量。

例题解析

以下是按难度抽取的六道例题及解题思路：

简单题示例

题目：北京市金杜律师事务所服务上市公司的数量是多少家？
- 关键词：北京市金杜律师事务所, 68家
- 接口：调用律师事务所业务数据表接口。
题目：浙江省丽水市景宁畲族自治县对应的区划代码是什么？
- 关键词：浙江省, 丽水市, 景宁畲族自治县, 区划代码
- 接口：调用通用地址编码表接口。

中级题示例
3. 题目：统一社会信用代码是91331007200456372的这家公司的法人是谁？
* 解题步骤：
1. 调用 get_company_registered_name 接口，通过信用代码得到公司全称“浙江百达精工股份有限公司”。
2. 调用上市公司信息表接口，查询该公司法人。
3. 调用工商信息表接口，查询该公司法人。
* 串行调用：步骤2和3依赖于步骤1的结果，因此存在两次串行调用。
* 答案建议：分别给出两个表的查询结果。
4. 题目：某案号案件的被告律师事务所的地址是什么？
* 解题步骤：
1. 调用法律文书接口，通过案号查询到“被告律师事务所”为“安徽永盛律师事务所”。
2. 调用律师事务所信息接口，查询该律所的地址。
* 串行调用：1次。

高级题示例
5. 题目：原告是安利股份的案件，审理法院是哪家法院？
* 解题步骤：
1. 通过“安利股份”简称，查询公司全称“安徽安利材料科技股份有限公司”。
2. 通过公司全称，查询其作为原告的所有案件列表。
3. 从列表中确定正确案号。
4. 从案号中提取法院代字。
5. 通过法院代字查询法院全称。
6. 题目：某案号案件中，审理当天，审理法院所在城市与原告律师事务所所在城市的最低温度相差多少度？本题使用API个数为多少？最小调用次数为多少？
* 解题步骤：此题综合性强，需串联多个接口：
1. 通过案号查审理法院代字及审理日期。
2. 通过案号查原告律师事务所名称。
3. 通过法院代字查法院名称，再解析其所在城市。
4. 通过律所名称查律所信息，再解析其所在城市。
5. 根据审理日期和两个城市，分别查询天气数据，获取最低温度。
6. 计算温度差。
7. 统计所用API种类和最小调用次数。

常见问题答疑 (FAQ)

本节汇总并解答参赛者普遍关心的问题。

关于数据与查询

问：公司的地址应回答注册地址还是办公地址？
- 答：题目明确则按题目答。未明确时，可两者都回答以确保覆盖正确答案。
问：某些子公司为何在工商信息表中查不到？
- 答：数据可能存在噪声或缺失。若广泛存在此问题，可联系组委会核查。策略上，查不到可如实返回“未查询到相关信息”。
问：“关联公司”与“原告/被告”是什么关系？
- 答：“关联公司”指案件中涉及的公司，它可能是原告、被告，也可能是第三人、案外人等角色。题目若未特指，则包含所有角色。
问：案号中的括号格式不统一（中括号[]/小括号()）怎么办？
- 答：这是故意加入的噪声。建议在提示中让模型学会识别标准案号格式，或尝试两种格式进行查询。答题时可按标准格式书写。

关于接口调用与答案格式

问：什么是串行API调用？
- 答：指调用B接口时，必须依赖A接口的输出结果作为输入。这种有依赖关系的调用计为串行调用。
问：金额单位如何处理？
- 答：题目问“XX万”，则答案含“万”字；问“XX亿”，则含“亿”字。若题目只问“金额”，则答案仅输出数字，不含单位。货币单位默认人民币，通常不在答案中额外标明。
问：必须输出查询过程中的公司名等中间步骤吗？
- 答：不是必须。评分主要看最终答案的关键词。但清晰的中间步骤有助于模型推理和人工审阅。
问：可以合并多个API请求或使用本地模型吗？
- 答：可以，但需注意，复赛评审会考察方案设计，过度合并可能影响得分。使用本地开源模型（如GLM-4-9B）搭建服务是允许的。

关于评分

问：关键关键词（Key）没有全部命中能得分吗？
- 答：当前初赛规则是，需全部命中才能获得关键结果分（0.6分）。部分命中可能不得分。此规则后续可根据反馈调整。
问：“否定”答案如何评分？（如“查无信息”）
- 答：只要正确反映了“无法查到”的事实，即可命中关键词得分。

总结与建议

本节课中，我们一起学习了GLM法律大模型挑战赛初赛B榜的完整数据体系、接口设计逻辑和评分细则。

核心要点总结：

理解数据关联：重点是掌握“公司-子公司-案号-法院/律所-地址/天气”这条核心查询链路。
掌握串行调用：复杂问题需要分解为多步查询，理清接口间的依赖关系。
灵活应对噪声：数据中存在格式不统一、别称等问题，需在提示词或后处理中设计应对策略。
明确评分标准：以命中全部关键词为首要目标，确保答案的精确性。

给参赛者的建议：

先完成，再优化：优先保证大部分题目的正确率，不必在个别难题上耗时过多。
注重提示工程：设计清晰的提示词，引导模型理解任务、处理噪声、分步思考。
为复赛做准备：思考如何优化调用效率、设计更鲁棒的流程，并探索结构化报告等高级应用场景。

祝各位参赛者取得优异成绩！

📚 课程：LongCite - 让大模型精准找到 {引用} - P1

在本节课中，我们将学习一个名为 LongCite 的工作，它旨在让大模型在长文本问答中生成细粒度的引用，从而提升模型输出的可验证性和可信度。

🌍 背景介绍

上一节我们介绍了课程目标，本节中我们来看看长文本语言模型的应用背景。

现在，超长的上下文窗口已成为最新一代语言模型的标配。一些模型的上下文窗口甚至超过了1,000,000个token，例如谷歌的GEMINI 1.5和智谱的GLM-4-9B-Chat。大多数公开模型都标配了128K的上下文窗口，例如GPT-4o、Claude 3、GLM-4和Qwen-2等。

长文本语言模型最常用的场景之一是长文本问答。例如，用户上传一篇几百页的文档，希望从中抽取信息、提问或进行总结。虽然现有模型能够回答用户的各种提问，但它们存在一个严重缺陷。

⚠️ 现有模型的缺陷

上一节我们了解了长文本模型的能力，本节中我们来看看其核心缺陷。

模型在回答中没有标注每句话在原文中的依据。例如，模型回答“ChatGLM的训练数据主要包含多语言文档，主要为中文和英文”，但用户很难知道这句话对应原文的哪个部分。如果用户想要验证，会非常困难，因为文档可能有几百页。

同时，大模型常常会输出不忠于原文的信息，即产生“幻觉”。例如，一篇新闻的时间是2023年，但模型的输出却标注为2006年。在长文本中，用户即使看到一句话，也难以判断其真伪，这严重影响了模型的可信度。对于法律、金融等高度敏感的领域，这个问题尤为严重。

🔍 现有解决方案：Attributed LM

为了增强大模型的可信性和可验证性，在开放领域问答和智能搜索引擎中，出现了一种称为 Attributed LM 的系统。

以下是其两种主要实现方式：

检索生成（RAG）：系统先从文档库（如维基百科）中检索出相关片段，然后大模型根据这些片段生成带有引用的回答。每句话后面会有一个引用符号，指向其证据来源。
后处理（Post-hoc）：模型先不看外部信息，自行生成回答。生成后，再通过检索的方式为回答中的每一句话单独查找并添加引用。

这两种方法在开放域场景中效果良好，用户可以通过引用轻松验证信息。然而，将它们直接移植到长文本问答场景中却存在困难。

🧩 长文本场景的独特挑战

上一节我们介绍了现有的解决方案，本节中我们来看看这些方案在长文本场景下面临的挑战。

以下是两种方法在长文本问答中的缺陷：

检索生成（RAG）的缺陷：RAG通常只召回少量文本片段（例如4K个token），而原文可能有128K个token。这意味着大部分文本信息被丢弃，模型无法看到，从而导致回复的正确性下降，特别是在处理“总结”类问题时，性能会严重变差。
后处理（Post-hoc）的缺陷：这种方法会使整个问答流程变复杂，需要多次调用模型，从而显著增加用户的等待时间。在长文本问答中，等待时间本身就是一个重要指标，额外的延迟难以接受。

那么，有没有一种方法可以同时解决这两个问题呢？

💡 理想方案：直接生成引用

理想的解决方案是让长文本模型在根据全文生成回答的同时，直接生成细粒度的引用。

具体流程可以表示为：

模型阅读全文 -> 生成第一句话 -> 立即生成该句的引用[1,2] -> 生成第二句话 -> 立即生成该句的引用[3] -> ...

与后处理相比，它在一次前向传播中完成，不增加等待时间。与RAG相比，模型阅读了全文，不会丢失文本信息，理论上限更高，正确性更强。

既然如此，我们首先需要测试现有长文本模型是否具备这种直接生成引用的能力。

📊 评测基准：LongBench-Cite

为了衡量长文本模型生成引用的能力，我们提出了一个评测基准：LongBench-Cite。

该基准基于我们之前的两项工作（LongBench和LongEval）中的数据构建，总计包含1000条数据，涵盖了单文档QA、多文档QA、文档总结等常见任务场景，能较好地评测模型在真实场景下的引用生成能力。

与以往工作不同，在长文本场景下，我们更注重评测细粒度的句子级引用。

传统引用（块级/网页级）：一个引用对应一个文本块（如128个token）或整个网页。用户需要在这个大范围内再次寻找具体证据，体验不佳。粗暴的分块方式还可能导致句子被切断。
句子级引用：将原文按句子分割并编号（如C0, C1, C2...）。模型的引用对应原文的一个句子区间（如[22, 23]）。这样引用包含完整句子，定位精准，对用户更加友好。

LongBench-Cite的评测主要分为两个维度，由GPT-4o自动判断：

回答正确性
- Correctness：判断模型的回答是否正确，是否满足用户需求。
- Correctness Ratio：比较模型“带引用回答”与“不带引用回答”的正确性比例，用于判断加入引用是否损害了其长文本问答能力。
引用质量
- Citation Recall：回答中的每个事实性陈述（Statement）是否被对应的引用所支持。完全支持得1分，部分支持得0.5分，不支持得0分。
- Citation Precision：每个引用是否包含了对应陈述的信息，而非无关内容。相关得1分，无关得0分。
- Citation F1：综合Recall和Precision的F1分数。
- Citation Length：每个引用对应文本的平均长度（token数）。长度越短，说明引用粒度越细，定位越精准。这个指标可以防止模型通过“引用全文”这种取巧方式来获得高分。

经实验验证，GPT-4o的自动判断与人工评估有较高的一致性（准确率约80%以上），比较可靠。

📉 现有模型评测结果

有了评测基准后，我们首先测试了现有长文本模型的效果。

由于现有模型没有在此类数据上微调过，我们通过上下文学习（In-Context Learning） 的方式，即给出示例，让模型回答测试用例。

以下是主要发现：

开源模型（如GLM-4-9B, LLaMA, Mistral Large）：它们的Citation F1普遍偏低。主要原因是其指令遵循能力不足，经常生成错误格式的引用或不生成引用。
闭源模型（如GPT-4o, GLM-4）：能较好地遵循格式并输出引用，F1相对较高。但它们的引用粒度非常粗，平均每个引用长度超过128个token，比传统的块级引用还要粗，用户仍需费力定位。
对问答能力的影响：大多数模型通过上下文学习加入引用后，其长文本问答的正确性（Correctness Ratio）受到了损害。这是因为这种使用方式与模型原有的训练方式存在分布差异。

总结：当前长文本模型生成引用的能力普遍偏低，且会损害其长文本问答的表现。因此，需要通过构造相应的训练数据来增强这种能力。

🏗️ 数据构造框架：CoF（Coarse-to-Fine）

上一节我们指出了问题，本节中我们来看看解决方案——一个自动构造带有细粒度引用数据的数据构造框架。

我们提出CoF（由粗到细） 框架，旨在自动构造高质量的、带有句子级引用的长文本问答数据。它遵循两个原则：

充分利用现有模型的超长文本能力，保证生成的问答质量不下降。
生成的引用质量要高，粒度要细。

因此，我们放弃了会丢失信息的RAG方法，采用了后处理方式来保证答案质量，同时设计了由粗到细的流程来获得细粒度引用。

CoF框架包含四个步骤：

1. 问答生成

此步骤利用Self-Instruct方法，让大模型根据给定的长文档自问自答，生成高质量的问答对。我们预设多种任务类型（信息抽取、多跳推理、总结等）以保证问题多样性。模型阅读全文后生成的答案，质量有保障。

2. 块级引用生成

对上一步得到的答案，采用后处理方式为其添加块级（Chunk-level）引用。

使用答案中的每一句话去原文中检索相关文本块（实验中检索40个块，每块128个token）。
将问题、检索到的块和原始答案一起给大模型，并通过示例指导模型将块级引用（如[5]）插入到答案的对应位置。
此时，答案内容保持不变，只是加入了引用标记，因此答案质量得以保留。

3. 句子级引用抽取

这一步从块级引用中提炼出句子级引用。

对于答案中的每个陈述（Statement）及其对应的块级引用，将对应的文本块和陈述提供给大模型。
指导模型从该文本块中精确找出支持该陈述的句子区间（如块内的[8, 9]）。
将这个块内句子区间映射回原文的全局句子编号，得到最终的句子级引用（如原文的[22, 23]）。

4. 数据清理

删除那些引用过少（例如少于15%的陈述有引用）的数据。这类数据通常意味着答案包含大量幻觉，无法找到原文依据，删除它们可以提高整体数据集质量。

最终，我们将指令（Instruction）、分句编号的原文（Context）、问题（Question）和带有句子级引用的答案（Answer）组合成一个完整的训练样本。

✅ 框架有效性验证

在大量造数据之前，我们首先在LongBench-Cite上验证了CoF框架的有效性。

我们对比了多种方法：

One-pass方法：同时生成答案和引用（如L-C, L-S, RAG-C, RAG-S）。它们的F1尚可，但正确性比率（CR）普遍低于100%，说明损害了问答能力。
Post-hoc方法：先回答后加引用（如L, R）。它们的正确性比率为100%，不影响问答能力。

实验结果：我们的CoF方法在所有Post-hoc方法中取得了最高的Citation F1，并且与One-pass方法相比，它能保证回答正确性不下降。这证明了CoF框架的有效性。

🚀 训练模型与实验结果

验证框架有效后，我们使用CoF框架构造了大规模训练数据，并训练了新的模型。

数据集构建：我们从GLM-4的预训练语料中收集了5万篇长文档，通过CoF框架构造了包含44.6K条高质量问答对的数据集LongCite-45K，最长支持128K上下文。
模型训练：将LongCite-45K与通用SFT数据（如ShareGPT）混合，基于GLM-4-9B和LLaMA-3-8B训练，得到LongCite-9B和LongCite-8B模型。

在LongBench-Cite上的评测结果令人鼓舞：

引用质量：LongCite模型取得了最高的Citation F1，同时引用粒度很细（平均长度约90个token），比闭源模型（如GPT-4o）的引用粒度细了近一倍，实现了精准定位。

回答正确性：一个意外的发现是，使用带引用数据训练的LongCite模型，其回答正确性高于使用相同数据但去掉引用信息后训练的普通SFT模型。这表明加入引用训练不仅没损害能力，反而有所提升。

人工评估：人工评估结果与GPT-4o自动评估趋势一致，LongCite模型在引用质量上优于对比模型，且GPT-4o评分与人工评分有较高一致性。

🔬 深入分析：为什么效果更好？

我们通过案例分析探究了LongCite模型效果更好的原因：

减少幻觉：带有引用训练的模型更关注每句话的出处，因此幻觉更少。例如，普通SFT模型可能混淆两个公司的地址，而LongCite模型能正确找到并引用各自地址。
更均匀地利用上下文：普通SFT模型在总结时倾向于多用文档前部信息。LongCite模型由于有关注引用位置的意识，能更均匀地利用文档各部分的信-息，生成更全面的答案，且回答总长度并未增加。

此外，消融实验表明：

引用能力确实来源于LongCite-45K数据集，普通长文本SFT无法获得此能力。
数据清理步骤对提升模型效果有积极作用。
回答正确性与引用质量正相关，正确性越高，越容易找到准确的引用。

🎯 总结与展望

本节课中，我们一起学习了LongCite工作，它旨在提升长文本模型生成细粒度引用的能力。

核心总结如下：

在长文本问答中加入引用，可以显著提高模型输出的可验证性和可信度，改善用户体验。
通过我们提出的CoF框架可以自动构造高质量的、带有细粒度引用的训练数据。
使用此类数据训练的模型（如LongCite-9B/8B），不仅能生成精准的句子级引用，其长文本问答的正确性也优于普通SFT模型，因为它能减少幻觉并更均匀地利用上下文。

局限与展望：

局限：添加引用主要帮助用户验证信息，并不能从根本上解决模型的幻觉问题。
展望：未来可以探索将引用质量作为奖励信号，通过强化学习进一步提升模型能力；或利用引用文本对模型输出进行反思和后处理，以进一步降低幻觉。

本节课中，我们深入探讨了长文本模型生成引用的重要性、现有方案的不足、我们提出的CoF数据构造框架以及训练得到的优秀模型。希望这些内容能帮助你理解如何让大模型在长文本处理中更加可靠、透明。

posted @ 2026-02-03 19:58 绝不原创的飞龙阅读(7) 评论(0) 收藏举报

刷新页面返回顶部

龙哥盟

掠夺·扩张·投机·博弈

ChatGLM-直播笔记-全-

ChatGLM 直播笔记（全）

课程01：基于ChatGLM的金融问答系统构建方案详解 💼

概述

一、 整体方案架构 🏗️

二、 数据解析与抽取 📄

三、 问题分类 🏷️

四、 SQL语句生成 🗃️

五、 意图识别与信息召回 🎯

六、 复杂问题处理与答案生成 ⚙️

七、 方案优化与总结 🚀

效果优化总结

未来改进方向

总结

课程一：ChatGLM与LangChain简介及本地知识库问答原理 🧠

概述

第一部分：ChatGLM与LangChain简介

第二部分：LangChain框架与项目原理

基于本地知识库的问答原理

第三部分：代码实践与项目演示

代码流程解析

LangChain-ChatGLM 项目介绍

总结

课程一：ChatGLM-6B 微调教程：P-Tuning, LoRA, Full Parameter 🚀

GLM 模型回顾 🤖

环境配置与模型下载 ⚙️

运行演示：CLI 与 Web Demo 🖥️

微调前置知识：混合精度与 Zero 优化器 📚

高效微调方法：P-Tuning v2 🎯

全量微调与 LoRA 微调 ⚡

课程一：大模型与Prompt工程基础 🧠

什么是大模型？

大模型为何强大？

大模型能做什么与不能做什么？

什么是Prompt工程？

如何编写有效的Prompt？

动手实践：第一个Prompt示例

🚀 官方教程：GLM-4-9B 实战部署和微调 - P1

📥 模型下载与简介

⚙️ 模型部署实践

🛠️ 模型微调指南

数据集格式

数据处理与训练

📝 总结与答疑

课程 P1：智谱AI新一代视频生成模型 CogVideoX 🎬

概述：为什么需要多模态大模型？🧠

技术演进：从 CogView 到 CogVideoX 🚀

CogVideoX 的核心技术特点 ⚙️

产品发布：AI视频生成功能“清影”正式上线 🎉

“清影”功能特点与演示 🎬

开放生态：面向开发者与企业 🏢

未来展望与总结 🌟

课程一：认识「清影」AI视频生成工具 🎬

什么是「清影」？✨

「清影」能做什么？🚀

如何使用「清影」？🛠️

总结 📝

第一课：从GPT快速迁移到ChatGLM 🚀

快速迁移指南 ✨

ChatGLM与GPT的差异与优势 ⚖️

开发者资源与模型介绍 📚

总结 🎯

课程名称：智能体Builder时代入门 - P1

概述

第一部分：理解大模型——一次技术大变革

大模型的核心特点

第二部分：厘清概念——什么是智能体？

为什么智能体现在火了？

智能体的分类展望

第三部分：实战入门——人人都是Builder

实战案例演示

总结

课程名称：CogVideoX视频生成模型详解与部署指南 - P1

概述 📖

第一部分：算法核心解析 🧠

1.1 Cog系列模型发展历程

1.2 核心模块一：3D Transformer with Full Attention

1.3 核心模块二：3D VAE（视频变分自编码器）

一、整体方案架构 🏗️

二、数据解析与抽取 📄

三、问题分类 🏷️

五、意图识别与信息召回 🎯

六、复杂问题处理与答案生成 ⚙️

七、方案优化与总结 🚀