Datawhale-动手学大模型应用开发-第二章心得

本章详细介绍了使用LLM（大型语言模型）API进行应用开发的基本概念和实践指导：

1. 基本概念：

   • 介绍了大型语言模型（LLM）的基本理论和特性。
   • 解释了LLM在自然语言处理中的应用，如文本生成、信息提取、摘要和翻译。
   • 讨论了开发基于LLM的应用时应考虑的关键点，包括模型选择、调用方式和性能优化。

2. 使用 LLM API：

   • 提供了如何通过API调用LLM来处理语言任务的具体代码示例。
   • 包括设置API环境、发送请求和处理响应的详细步骤。
   • 展示了如何利用LLM进行文本分类、生成和语义搜索的示例。

3. Prompt Engineering：

   • 专注于"Prompt Engineering"即如何设计和优化输入提示以获得最佳的LLM性能。
   • 包括不同类型的提示设计策略，如零样本、少样本和微调。
   • 提供了评估提示效果的方法和工具，以及如何根据模型反馈迭代优化提示。

学习心得：

①关于调用API的三段代码：

代码片段1：环境变量加载

负责从 .env 文件中读取环境变量（如 API 密钥和代理设置），这是在进行任何 API 调用之前必须完成的设置步骤。它确保了敏感信息的安全和配置的灵活性。

代码片段2：API 调用示例

展示了如何使用 openai 库创建一个 API 客户端，并调用 ChatGPT 模型来生成响应。这是一个直接的 API 调用示例，演示了如何发送请求和接收响应。

代码片段3：API 调用封装

提供了一个函数封装，用于生成 GPT 模型的请求参数，并通过函数 get_completion 获取模型的响应。这样的封装使得代码更模块化，方便在不同的场景下重复使用和维护。

②代理服务器配置问题

在脚本中设置了使用代理服务器（http://127.0.0.1:7890）。如果代理服务没有正确运行在该地址和端口上，或者配置不正确，就会导致连接被拒绝。解决步骤如下：

• 确认代理服务器正在运行，并且是在正确的端口（7890）。
• 确认代理服务器配置允许从您的应用进行连接。
• 如果不需要通过代理连接到互联网，尝试移除或注释掉代理设置，看看是否能解决问题：

③API 密钥及响应问题

环境变量 OPENAI_API_KEY 没有正确设置或 .env 文件没有被正确读取，因此在尝试进行 API 调用时 API 密钥为 None。

解决步骤：

1.确认在项目的根目录或脚本同目录下有一个 .env 文件，并且文件中正确设置了如下内容：

2.确保脚本中有以下代码来加载环境变量：

3.在尝试读取环境变量后，打印出来确保其已正确加载：

④TypeError: 'ChatCompletionMessage' object is not subscriptable

问题在于如何正确地访问 response.choices[0].message 对象。错误消息 TypeError: 'ChatCompletionMessage' object is not subscriptable 明确指出 message 对象不是一个字典，不能使用 ['content'] 这样的字典键来访问。因此需要使用属性访问来获取信息。

在 OpenAI 的 Python 客户端库中，message 是一个对象，而不是字典。因此应该直接使用点语法来访问其属性。修改代码如下：

def get_completion(prompt, model="gpt-3.5-turbo", temperature=0):
    '''
    获取 GPT 模型调用结果

    请求参数：
        prompt: 对应的提示词
        model: 调用的模型，默认为 gpt-3.5-turbo，也可以按需选择 gpt-4 等其他模型
        temperature: 模型输出的温度系数，控制输出的随机程度，取值范围是 0~2。温度系数越低，输出内容越一致。
    '''
    response = client.chat.completions.create(
        model=model,
        messages=gen_gpt_messages(prompt),
        temperature=temperature,
    )
    if response.choices:
        # 使用正确的属性访问方式
        return response.choices[0].message.content
    return "generate answer error"
 

在这里已经修改了访问 message 对象的方法，将 response.choices[0].message['content'] 改为 response.choices[0].message.content。

⑤NameError: name 'response' is not defined

在代码中，错误发生在最后一行：尝试访问一个名为 response 的变量，但这个变量在该脚本的当前作用域中未定义。在 get_completion 函数中定义了一个名为 response 的局部变量，但这个变量只在该函数内部有效。

在最后一行使用 print(response.text) 尝试访问的 response 变量并不存在于那个作用域中。这行代码看起来是想打印 API 响应的文本，但实际上，已经在函数 get_completion 中处理了这个响应并返回了处理后的结果。

如果目的是打印从 API 获得的原始响应或某个特定部分，需要修改代码以正确反映这一点。如果只是想确认函数返回的结果，已经有了 print("Generated response:", result) 这行代码，这已经足够了。

示例代码：

import os
from dotenv import load_dotenv, find_dotenv
from openai import OpenAI

# 环境变量配置
load_dotenv(find_dotenv())
api_key = os.environ.get("OPENAI_API_KEY")
print("API key is:", api_key)

# 创建 OpenAI 客户端
client = OpenAI(api_key=api_key)

def gen_gpt_messages(prompt):
    """
    构造 GPT 模型请求参数 messages
    请求参数：
        prompt: 对应的用户提示词
    """
    messages = [{"role": "user", "content": prompt}]
    return messages

def get_completion(prompt, model="gpt-3.5-turbo", temperature=0):
    '''
    获取 GPT 模型调用结果

    请求参数：
        prompt: 对应的提示词
        model: 调用的模型，默认为 gpt-3.5-turbo，也可以按需选择 gpt-4 等其他模型
        temperature: 模型输出的温度系数，控制输出的随机程度，取值范围是 0~2。温度系数越低，输出内容越一致。
    '''
    response = client.chat.completions.create(
        model=model,
        messages=gen_gpt_messages(prompt),
        temperature=temperature,
    )
    if response.choices:
        return response.choices[0].message.content
    return "generate answer error"

# 使用封装的函数进行 API 调用测试
prompt = "Hello!"
result = get_completion(prompt)
print("Generated response:", result)
 

⑥一些个概念理解：

SSH，全称为“Secure Shell”，是一种网络协议，用于在不安全的网络中安全地进行远程登录和其他网络服务。可以把它想象成一种特殊的超级电话线，连接你的电脑和远程电脑，确保你的数据在两者之间传输时不会被窃听或篡改。想象一下，你的电脑是一座金库，而远程电脑是另一座金库。你需要传递一些秘密文件。使用SSH就好比是在两座金库之间建立了一条秘密地下隧道。只有通过特殊的认证才能进入这条隧道，确保只有你和接收方能看到传输的文件，防止了间谍或小偷的窥探。

Git 是一种非常聪明的“时间机器”——但它是用来管理代码的。想象一下，你在画一幅画或写一本书，每次你觉得达到了一个里程碑，你就用相机拍个照片或者做个标记。Git 就是程序员用来做这个的工具，它可以帮你记录每一次重大的更改，这样如果你做错了什么，就可以轻松地回到过去的某个“快照”去修正。使用 Git 就像是玩乐高积木。开始时，你可能只有几个基础模块。随着你不断地添加新的部分，你的构建变得越来越复杂。如果你突然意识到那个巨大的飞船的一半应该是红色而不是蓝色，Git 让你可以轻松地撤销之前的几个步骤，重新开始而不是拆掉整个飞船。

Docker 是一种非常流行的魔法工具箱，可以让程序员把他们的应用程序连同所有需要的环境一起打包，确保它在任何地方都能像在原始环境中一样运行。想象你有一套完美的厨房设备，可以随时打包起来，到任何地方都能展开来做出一样美味的菜肴，这就是 Docker 的魔力。Docker 使用称为“容器”的技术，这些容器包装了应用程序及其环境。与传统的虚拟机不同，容器不需要携带整个操作系统，所以它们更轻便、启动更快。

那么，Docker 和 Git 这些概念又是怎么关联的呢？Git 让你管理代码的不同版本，而 Docker 让你把这些代码连同所有依赖一起封装起来。你可以想象 Git 是在管理你的食谱集，而 Docker 是确保无论在哪个厨房，你都能用相同的设备和原料做出一致的菜品。Docker 保证了“在我的机器上可以运行”的程序，也能在其他任何机器上同样运行，无论是你的同事的电脑还是云端服务器。这就像是确保你的魔法表演在世界任何一个角落都能够同样精彩地上演。通过这种方式，Docker 和 Git 一起帮助程序员在创建、共享和运行软件方面变得更加高效和一致。