AI 辅助测试（MEAP）（一）（2）

AI 辅助测试（MEAP）（一）（1）https://developer.aliyun.com/article/1516287

2.4 探究提示工程的原则

随着 LLM 的发展，提示工程的模式和技术也在不断发展。许多课程和博客文章围绕提示工程编写，但是一个值得注意的原则集合是由 Isa Fulford 和 Andrew Ng 及其各自的团队创建的，我们稍后将进行探讨。OpenAI 的 LLM 知识与 Deeplearning.ai 的教学平台的合作创建了一个名为 ChatGPT Prompt Engineering for Developers 的课程，其中包含一系列可以用于提示中以充分利用 LLM 的原则和策略。如果你有时间，我建议你参加www.deeplearning.ai/short-courses/chatgpt-prompt-engineering-for-developers的短期课程。（www.promptingguide.ai/也是一个有用的参考。）尽管该课程特指 ChatGPT，但其中教授的原则可以应用于许多 LLM。所以让我们探究这些原则和策略，以便熟悉提示 LLM。

2.4.1 原则 1：编写清晰明确的指示

乍一看，这个第一个原则似乎很明显——为他人提供清晰明确的指示总是明智的。但这个原则实际上建议我们要编写针对 LLM 清晰明确的提示。这将意味着与对人类清晰明确的提示有所不同。为了实现这个概念，Fulford 和 Ng 教授了四种策略来实现清晰明确的提示：使用分隔符，要求结构化输出，检查假设以及少次提示。在接下来的几节中，让我们更详细地研究每一种策略。

2.4.2 策略 1：使用分隔符

在撰写提示时，我们可能需要提供不同的内容和数据来满足不同的目的。例如，我们的提示开头可能包括关于我们希望 LLM 产生什么的说明，而提示的最后可能包括我们希望处理的原始数据。LLMs 能够猜测我们对提示不同部分的意图，但由于我们的目标是尽可能清晰明了，我们可以通过使用分隔符来帮助这个过程，分隔符是用于分隔字符串的字符，以在提示的不同部分表明我们的意图。以这个提示为例：

#A
You are a SQL data generator. Generate five rows of SQL for a MySQL database. 
#B
* The table name is identified with a # sign. 
* Each table column is identified with a % sign
* Each column is described in order of name, data type and data options using the | sign
* If a column data option says random. Randomize data based on the suggested format and column name
#C
Here are the instructions:
# rooms
% room_name | string | random
% type | string |  'single' or 'double'
% beds | integer | 1 to 6
% accessible | boolean | true or false
% image | string | random url
% description | string | random max 20 characters
% features | array[string] | 'Wifi', 'TV' or 'Safe'
% roomPrice |  integer | 100 to 200

运行此提示在 ChatGPT 中，我收到以下输出：

INSERT INTO rooms (room_name, type, beds, accessible, image, description, features, roomPrice) VALUES
    ('Room 1', 'single', 3, true, 'https://example.com/image1.jpg', 'Lorem ipsum dolor', '["Wifi", "TV"]', 150),
    ('Room 2', 'double', 2, false, 'https://example.com/image2.jpg', 'Lorem ipsum dolor', '["TV", "Safe"]', 180),
    ('Room 3', 'double', 4, true, 'https://example.com/image3.jpg', 'Lorem ipsum dolor', '["Wifi", "Safe"]', 160),
    ('Room 4', 'single', 1, true, 'https://example.com/image4.jpg', 'Lorem ipsum dolor', '["Wifi", "TV"]', 120),
    ('Room 5', 'double', 3, false, 'https://example.com/image5.jpg', 'Lorem ipsum dolor', '["TV"]', 170);

如我们所见，通过使用分隔符，正确的表名rooms已经被添加，并且列名、格式和范围已经被正确地随机化。这是通过在提示中通过各种分隔符来明确设定我们所设定的期望和规则而实现的。

分隔符有助于使提示更清晰，但也使其易于修改。例如，如果我们想重新配置生成的数据，我们可以输入另一行，如：

% room_size | string | 20m2 to 50m2

因此，在撰写包含大量随上下文变化的数据的提示时，我们可以使用分隔符清楚地表示在特定点的提示中提供了什么。

活动

使用分隔符提示示例，创建新的指令-这次是针对包括预订人、联系方式、入住和退房日期信息的预订。

2.4.3 策略 2：要求结构化输出

LLM 的一个有用的方面是它们具有以结构化格式提供输出的能力。在阅读本书时，我们将探索这种能力的有用性，但是作为一条规则，我们必须始终记住，我们需要在提示中清楚地说明我们想要看到使用的结构化格式。以这个提示为例：

Create a JSON object with random data that contains the following fields: firstname, lastname, totalprice, deposit paid. Also, include an object called booking dates that contains checkin and checkout dates.

我们首先明确说明我们想要以 JSON 格式查看我们的对象，然后开始概述对象的结构。当我将此提示发送给 ChatGPT 时，返回了以下结果：

{
  "firstname": "John",
  "lastname": "Doe",
  "totalprice": 150.50,
  "deposit_paid": true,
  "booking_dates": {
    "checkin": "2023-08-01",
    "checkout": "2023-08-10"
  }
}

如提示中明确说明的，预期格式和结构是两个不同的指令，这意味着我们可以通过发送附加的提示来修改指令，从而快速更改格式结构，例如：

Create this in a YAML format

将此提示发送给 ChatGPT 返回以下输出：

firstname: John
lastname: Doe
totalprice: 150.50
deposit_paid: true
booking_dates:
  checkin: 2023-08-01
  checkout: 2023-08-10

注意结构是相同的（以及随机化的数据）。通过明确说明我们想要的格式，我们可以指示 LLM 在特定时间以及轻松地交替格式。

活动

尝试创建一个包含不同数据类型和不同格式的多个参数的对象。尝试提示一个 LLM 将你的对象从一种格式转换为另一种格式，例如从 JSON 转换为 XML。

2.4.4 策略 3：检查假设

正如我们之前学到的那样，LLM 可能会产生幻觉，生成包含不正确或脱离现实的信息的输出。不用说，我们希望减少产生幻觉的风险，这就是我们的第三种策略，检查假设，可以帮助的地方。如果向 LLM 提供了围绕我们想要解决的问题的边缘情况的提示，那么 LLM 更有可能产生幻觉。如果 LLM 没有得到适当的指示，它更有可能对答案进行猜测，而不是直接告诉我们它无法提供有用的答案。因此，如果我们想避免猜测，我们需要在提示中提供指示，让 LLM 在无法执行我们的请求时退出。考虑这个例子：

#A
You will be provided with a JSON object delimited by three hashes. Extract all emails that end with .com and write them out as a list.
#B
If no email addresses with a .com email address exist, simply write "No .com emails found"
#C
###
[{
  "firstname": "Bret",
  "lastname": "Averay",
  "email": "baveray0@apple.com"
}, {
  "firstname": "Annabel",
  "lastname": "Biswell",
  "email": "abiswell2@nsw.gov.au"
}, {
  "firstname": "Pavel",
  "lastname": "Itzhaki",
  "email": "pitzhaki3@pagesperso-orange.fr"
}, {
  "firstname": "Pail",
  "lastname": "Yandell",
  "email": "pyandell4@ning.com"
}, {
  "firstname": "Glennis",
  "lastname": "Pentecost",
  "email": "gpentecost6@yelp.com"
}]
###

使用可以提取的电子邮件地址集运行此提示返回以下输出：

Here are the email addresses that end with ".com":
* baveray0@apple.com
* pyandell4@ning.com
* gpentecost6@yelp.com

但是当我再次运行提示而不包含电子邮件地址时会发生什么：

You will be provided with a JSON object delimited by three hashes. Extract all emails that end with .com and write them out as a list.
If no email addresses with a .com email address exist, simply write "No .com emails found"
###
[{
  "firstname": "Bret",
  "lastname": "Averay"
}, {
  "firstname": "Annabel",
  "lastname": "Biswell"
}, {
  "firstname": "Pavel",
  "lastname": "Itzhaki"
}, {
  "firstname": "Pail",
  "lastname": "Yandell"
}, {
  "firstname": "Glennis",
  "lastname": "Pentecost"
}]
###

然后我收到了以下内容：

Here is the list of email addresses that end with .com extracted from the provided JSON object:
No .com emails found

LLM 的这个响应直接参考了提示的这一部分：

If no email addresses with a .com email address exist, simply write "No .com emails found

这阻止了 LLM 提供不正确输出。例如，当我没有进行假设检查运行提示时，返回以下内容：

Sure! I can help you with that. Here are the email addresses that end with ".com" from the provided JSON object:
`
["bret@example.com", "annabel@example.com", "pavel@example.com", "pail@example.com", "glennis@example.com"]
`
Please note that I have used example.com as a placeholder domain for all the email addresses. Replace it with the appropriate domain if you have the actual email addresses.

这是 LLM 幻觉的一个很好的例子。我们提供的对象不包含电子邮件地址，因此 LLM 使用猜测，并基于现有数据错误地开始生成新的电子邮件地址。然而，有了假设检查，我们防止了幻觉的发生。

活动

创建一个过滤掉原始数据列表中特定数据并输出结果的提示（例如，在不同食物列表中过滤水果）。然后修改数据以包含一个边缘情况（例如，不正确或缺失的数据）。观察 LLM 输出的内容，然后尝试通过向提示添加跟随检查假设提示的指令来更正输出。

2.4.5 策略 4：Few-shot prompting

随着我们在本章中的进展和对 LLM 和提示的新概念的学习，通过示例澄清了关键点。它们是不仅仅是教学，而且是相互交流的重要工具。对于 LLM 来说也是如此。 Few-shot prompting 基本上意味着提供明确的示例来澄清说明（在这种情况下，few 这个词指示你分享了多少示例。一个没有示例的提示将是 zero-shot prompt）。看一个使用示例的提示的例子：

#A
You are an expert exploratory tester. Create three test charters for a booking system that focus on the risks around booking dates. The format should follow: Explore <Target> using <Resource> to discover <Information>
#B
For example:
* Explore user permissions using different users to discover permission issues
* Explore browser animations using different devices to discover how animations render

将此提示发送给 ChatGPT 返回以下输出：

Explore date validation using various date formats to discover potential input errors.
Explore time zone handling using different geographical locations to discover discrepancies in booking times.
Explore booking conflicts using overlapping reservation requests to discover potential double-booking issues.

考虑格式使用探索以发现。它是基于规则的，但它在使用自然语言来传达规则时有很大倾向（不像依赖显式分隔符规则的 JSON 或 XML 结构）。通过在我们的提示中提供示例，我们可以帮助界定我们所指的、和，并减少 LLM 猜测它们含义的风险。

活动

创建一个使用 few-shot 策略的提示。在您的提示中，提供您期望 LLM 遵循的说明，然后至少添加两个示例以帮助指导它提供所需的结果。

2.4.6 原则 2：给模型一些“思考”的时间

考虑到我们一直将 LLMs 视为概率机器而不是可以思考的实体，看到一个鼓励我们给模型一些“思考”时间的原则似乎有点不寻常。毕竟，使用 LLMs 的价值在于它们能够比我们人类更快地回答复杂问题吗？

然而，原则 2 的重点不在于 LLM 如何思考，而在于我们如何向概率引擎呈现复杂任务。在稍早提到的针对开发者的 ChatGPT 提示工程课程中，富尔福德在介绍这个原则时给出了一个有用的类比：

“如果你给一个模型一个在短时间内无法完成的任务……它可能会做出一个可能是错误的猜测。”

她解释说，如果人类被要求在有限的时间内完成复杂任务，同样的情况也会发生。我们将依赖于有根据的猜测，并且可能得出一个不太满意的答案。因此，原则 2 提供了策略来帮助我们编写提示，将任务拆分，并鼓励 LLMs 评估输出，以再次最大化产生所需响应的可能性。

2.4.7 策略 1：指定完成任务的步骤

第一种策略相对直接，一旦我们对原则 1（编写清晰明确的说明）的策略有信心，就可以轻松掌握。通过使用分隔符，我们可以将复杂的任务分解为单个步骤，供 LLM 执行以解决更大的任务。看看这个提示：

#A
You are going to be given a list of instructions to follow.
#B
1 - Identify functional risks that might impact the text delimited by three hashes
2 - Convert the risks into test charters
3 - Format each charter into a Discover <feature> using <resource> to discover <information> format
#C
###
As a user
I want to be able to calculate my tax
So I know what tax I have to pay
###

当发送给 ChatGPT 时，它返回了这个结果：

Functional risks:
    Calculation accuracy: There is a risk that the tax calculation may be inaccurate, leading to incorrect tax amounts being calculated.
Test charters based on the identified risks:
    Test Charter 1: Validate the accuracy of tax calculations by inputting different test scenarios with known tax amounts and verifying that the calculated tax matches the expected values.
Formatting the charters into a "Discover <feature> using <resource> to discover <information>" format:
    Discover tax calculation accuracy using test scenarios with known tax amounts to validate the accuracy of the calculated tax.

这是我收到的输出片段。它创建了许多风险和章程，但每个部分的第一个示例都演示了 LLM 逐个回应每个子任务以创建输出。

活动

创建一个需要执行复杂任务的提示。尝试将复杂任务拆分为 LLM 可以执行的多个子任务。

2.4.8 策略 2：指导模型先解决自己的方案

我们最后的策略不是关注创建输出的过程，而是关注评估输出本身。类似于检查假设，要求 LLM 评估输出以确认其与其被指示产生的内容是否一致。让我们看一个示例，以更好地理解这将如何运作。首先，让我们看一个不要求 LLM 首先解决其解决方案的提示：

#A
You are a software developer in test that is experienced in writing Java. Create a unit test for the following method:
#B
public class AuthService {
   public HttpStatus deleteToken(Token token) throws SQLException {
        Boolean successfulDeletion = authDB.deleteToken(token);
        if(successfulDeletion){
            return HttpStatus.OK;
        } else {
            return HttpStatus.NOT_FOUND;
        }
    }
}

将此发送到 ChatGPT，返回以下结果：

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;
class TokenManagerTest {
    @Test
    void deleteToken_SuccessfulDeletion_ReturnsOK() throws SQLException {
        // Arrange
        TokenManager tokenManager = new TokenManager();
        Token token = new Token();
        // Act
        HttpStatus result = tokenManager.deleteToken(token);
        // Assert
        assertEquals(HttpStatus.OK, result);
    }
}

这看起来像一个合理的 Java 代码用于单元测试，但如果这被添加到一组单元检查中，它会失败。这会失败，因为在提供的生产代码中，方法authDB.deleteToken没有被正确处理。具体来说，如果我们希望此单元检查工作，我们需要模拟authDB.deleteToken。

现在，如果我们再次运行提示，但这次在输出最终答案之前让它评估其解决方案，我们会得到不同的结果。所以首先我们将提示更改为以下内容：

#A
You are software developer in test that is experienced in writing Java. Create a unit test for the following method that will be shared. Before outputting the unit tests, check to see that the assertion of each unit check will return a deterministic result.
#B
public class AuthService {
   public HttpStatus deleteToken(Token token) throws SQLException {
        Boolean successfulDeletion = authDB.deleteToken(token);
        if(successfulDeletion){
            return HttpStatus.OK;
        } else {
            return HttpStatus.NOT_FOUND;
        }
    }
}

将此发送到 ChatGPT 返回以下结果：

import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;
import org.mockito.Mockito;
import java.sql.SQLException;
public class TokenDeletionTest {
    @Mock
    private AuthDB authDB;
    @Test
    public void testDeleteToken_SuccessfulDeletion() throws SQLException {
        // Mocking the behavior of authDB.deleteToken() to return true
        Token token = new Token();
        Mockito.when(authDB.deleteToken(token)).thenReturn(true);
        AuthService authService = new AuthService(authDB);
        HttpStatus result = authService.deleteToken(token);
        // Assertion: The method should return HttpStatus.OK
        Assertions.assertEquals(HttpStatus.OK, result);
    }
}

这一次，我们可以看到因为我们要求 LLM 在返回结果之前评估其解决方案，输出的单元检查使用了Mockito来模拟authDB.deleteToken。因此，如果我们观察到 LLMs 输出错误的解决方案或它们开始产生幻觉，我们可以添加一条指令首先评估解决方案，以最小化幻觉的发生。

活动

创建一个提示，需要 LLM 解决问题的解决方案。观察其输出，并查看所产生的解决方案是否正确。然后添加指令，让 LLM 评估解决方案。会发生什么？解决方案会改变吗？是不是有所改善？

2.5 使用不同的 LLM

到目前为止，我们在广义上讨论了 LLMs，同时在之前的示例中使用 OpenAI 的 ChatGPT 来演示它们的工作原理。然而，ChatGPT 只是我们可以使用的众多不同 LLMs 中的一个。因此，在我们结束本章之前，让我们熟悉 LLMs 之间的差异，并了解一些当前流行的模型和社区，以增加我们找到适合工作的正确 LLM 的机会。

2.5.1 比较大型语言模型

什么使得一个 LLM 优秀？我们如何确定一个模型是否值得使用？这些都不是容易回答的问题。LLM 的复杂性质以及它们的训练方式和使用的数据使得这些系统难以进行深入分析，并构成了一些研究人员试图改进或阐明的领域。然而，这并不意味着我们不应该了解 LLM 的一些关键方面以及它们如何影响它们。我们可能并不都是尝试探索 LLM 深层内部运作的人工智能研究人员，但我们是或将成为它们的用户，我们会想知道我们投入资源的东西是否给了我们价值。因此，为了帮助我们分解一些术语并为我们提供一些关于 LLM 如何相互区别的基础知识，让我们来看看 LLM 领域讨论的一些关键属性：

参数数量

看看不同的 LLM，你可能会看到关于 LLM 拥有“1750 亿”或“1 万亿”参数数量的说法。有时候这可能听起来像是营销说辞，但参数数量确实会影响 LLM 的表现。参数数量本质上与模型内部存在的统计权重量有关。每个单独的权重都提供了组成 LLM 的统计谜题的一部分。因此，粗略地说，LLM 拥有的参数越多，其性能就越好。参数数量也可以让我们了解成本。参数数量越高，运行成本就越高，这种成本可能在一定程度上转嫁给用户。

训练数据

LLM 需要大量的数据进行训练，因此数据的规模和质量对 LLM 的质量会产生影响。如果我们希望 LLM 在回应请求时准确无误，仅仅提供尽可能多的数据是不够的。需要的是能够以合理方式影响模型概率的数据。例如，我们在本章前面探讨过的 Reddit 示例，其中使用 subreddit r/counting 来训练 ChatGPT 导致它产生奇怪的幻觉，表明更多不一定就是更好。然而，与参数数量类似，LLM 训练过的高质量数据越多，其性能可能就越好。挑战在于了解 LLM 训练过的数据是什么——这是 AI 企业创造者们极力保守秘密的一件事情。

可扩展性和整合性

与任何其他工具一样，如果 LLM 能够提供除核心功能之外的其他功能，如整合到现有系统中或进一步为我们的特定需求训练模型，那么它的价值可以进一步提高。LLM 可以整合和扩展的功能主要取决于谁负责对它们进行训练。

例如，OpenAI 提供付费 API 访问其模型。但除了一项指令功能可以通过简单提示来调整输出外，没有能力进一步调整并部署其中一个他们的 GPT 模型供私人使用。相比之下，Meta 的 LlaMa 模型是开源的，允许 AI 社区下载并根据自己的要求进一步训练，尽管他们必须构建自己的基础设施来部署该模型。

随着 LLM 平台的发展，我们将看到它们不仅在回应提示方面取得进步，而且在周围的功能和访问方面也会有所提升。因此，在评估要使用的内容时，记住这些功能是必要的。

回应质量

有人认为，考虑 LLM 是否提供易读、有用和尽可能免费（或接近免费）幻觉的回复是最重要的因素之一。尽管参数数量和训练数据等标准是 LLM 性能的有用指标，但我们需要明确我们想要使用 LLM 做什么，然后确定每个 LLM 对我们的提示作出怎样的响应，并在解决我们具体问题时提供怎样的帮助。我们面临的挑战并不都需要市场上最大、最昂贵的 LLM。因此，我们要花时间尝试不同的模型，比较它们的输出，然后自行判断。例如，OpenAI 的 GPT 模型在处理代码示例方面表现更好，而 Google Bard 则不然。这些细节是通过实验和观察发现的。

我们探讨的这些标准绝不是一个穷尽列表，但再次表明，一旦我们克服了它们如何回应的初始魅力，就会发现关于 LLMs 还有更多要考虑的东西。不同的 LLM 以不同的方式执行，帮助我们解决不同的挑战。因此，让我们来看看当前可用的一些更受欢迎的模型和平台。

2.5.2 检查流行的大型语言模型

自从 OpenAI 推出 ChatGPT 以来，各种组织发布的大型语言模型（LLMs）数量激增。这并不是说在 ChatGPT 推出之前没有这些模型和相关工作，但公众关注度确实加强了，越来越多的营销和发布公告聚焦在公司发布的 LLM 产品上。以下是自 2022 年底以来发布的一些更常见/流行的 LLMs。

跟上 LLMs

值得注意的是，LLMs 的推出及其相关功能的情况非常复杂，发展速度相当快。因此，我们所探讨的一些内容可能与撰写时（2023 年中期）到你阅读本书时有所不同。然而，这个列表展示了 LLM 领域中一些值得探索的大型名字。

OpenAI

在撰写本文时，OpenAI 是提供 LLM 供使用的组织中最普遍的。虽然 OpenAI 已经在 LLM 模型上工作了相当长的时间，他们在 2020 年发布了他们的 GPT-3 模型，但是他们在 2022 年 11 月发布的 ChatGPT 才引发了广泛的兴趣和 LLM 的使用浪潮。

OpenAI 提供了一系列不同的 LLM 模型，但最突出的两个是 GPT-3.5-Turbo 和 GPT-4，您可以在他们的文档中了解更多信息：platform.openai.com/docs/models/overview。这两个模型被用作基础模型，或者说可以进一步针对特定目的进行训练的模型，用于一系列产品，如 ChatGPT、GitHub Copilot 和 Microsoft Bing AI。

除了他们的模型外，OpenAI 还提供了一系列功能，如直接访问他们的 GPT-3.5-Turbo 和 GPT-4 模型的 API，以及一系列与 ChatGPT 集成的应用程序（如果您订阅了他们的 plus 会员）。这是迄今为止最受欢迎的 LLM（目前为止）并已启动了一个与组织竞争发布他们自己的 LLM 的竞赛。

虽然我们已经尝试过一些与 ChatGPT 相关的提示，但您随时可以访问并尝试 ChatGPT，网址是chat.openai.com/。

坚持使用 OpenAI

尽管有许多不同的大型语言模型，我鼓励您使用，但为了保持一致，我们将坚持使用 ChatGPT-3.5-Turbo。这不一定是目前最强大的 LLM，但它是最普遍的，而且是免费的。也就是说，如果您想尝试其他 LLM 模型的这些提示，可以随意尝试。但请注意，它们的响应可能与本书中分享的内容不同。

PaLM

一旦 OpenAI 发布了 ChatGPT，Google 很快就会发布他们自己的 LLM 与聊天服务，他们于 2023 年 3 月发布了。基于他们的 PaLM 2 LLM，一个拥有 5400 亿参数的模型，Google 试图与 ChatGPT 竞争，并提供了类似的基于聊天的体验，称为 Bard。

与 OpenAI 类似，Google 通过他们的 Google Cloud 平台提供了对 PaLM 2 的访问（网址为developers.generativeai.google/），并最近开始提供与 OpenAI 的 ChatGPT 应用类似的应用程序，同时还可以集成到其他 Google Suite 工具中，如 Google Drive 和 Gmail。

您可以访问并尝试 Bard，网址是bard.google.com/chat。

LLaMa

LLaMa 是 Meta 在 2023 年 7 月首次发布的一个模型集合的名称。LLaMa 与 OpenAI 的 GPT 模型和谷歌的 PaLM 有所不同之处在于，LLaMa 是开源的。除了开源许可证外，LLaMa 还有多种规模：分别是 70 亿、13 亿和 7 亿个参数。这些规模和它们的可访问性的结合使得 LLaMa 已成为 AI 社区中一个受欢迎的基础模型。然而，这种可访问性的另一面是，Meta 并不提供公共平台来训练和运行 LLaMa 的版本。因此，必须个人获取数据集和基础设施才能使用它。

更多关于 LLaMa 的详细信息可以在以下链接中找到：

• www.llama2.ai/
  
• llama-2.ai/download/
  

Huggingface

与列表中的其他条目不同，Huggingface 并没有提供专有模型，而是促进了一个包含各种不同模型的 AI 社区，其中大多数模型都是开源的。查看他们的模型索引页面，位于 huggingface.co/models，我们可以看到来自不同公司和研究实验室的数十万个经过不同训练的模型。Huggingface 还提供了用于训练、应用程序和文档的数据集，使读者能够深入了解模型的构建方式。所有这些资源都可用于 AI 社区访问预训练模型，对其进行微调，并针对特定用途进行进一步训练，这是我们将在本书第三部分进一步探讨的内容。

在短时间内，LLMs 的市场规模在商业和开源方面都有了显著增长，与软件开发的其他领域类似，积极主动地了解新的 LLMs 出现可能是有益的。然而，尝试一直跟上一切可能是令人不知所措的，也不一定可行。因此，与其试图紧跟 AI 社区的一切动态，我们可以选择在想要使用 LLMs 解决特定问题时探索它们。拥有问题可以帮助我们构建关于哪些工具最适合我们以及哪些不适合的标准。

活动

从本章选择一个早期提示，或者创建一个你自己的提示，并将其提交给不同的 LLMs。注意每个 LLM 的响应和比较。有些是否感觉更像是对话？它们如何处理接收或发送代码示例？在你的观点中，哪个提供了最佳响应？

AI 辅助测试（MEAP）（一）（3）https://developer.aliyun.com/article/1516294