通过

构建生成 AI 解决方案的开发人员的重要概念和注意事项

  • 项目

大型语言模型（LLM）是惊人的，但他们甚至有他们的限制。 开发人员需要了解这些限制，哪些 LLM 能够“开箱即用”，以及如何调整它们，以获得他们正在构建的生成 AI 解决方案的最佳结果。 本文介绍了多种挑战和限制因素，并解释了克服这些挑战的常见方法，并控制内容生成过程，而不考虑要构建到应用程序中的生成 AI 功能类型。

使用 LLM 时的工程挑战

使用 LLM 时要注意的最重大挑战或限制：

  • 知识削减 - 由于训练 LLM 的成本很高，他们的知识主体仅限于他们在某个时间点接受训练的内容。 没有任何插件或其他住宿，他们无权访问实时信息，也无权访问私人数据。

  • 幻觉 - LLM 使用统计概率和一点随机性来生成信息。 有一些机制可以保持生成的响应与被询问的问题以及他们训练的信息中的意图保持一致，但他们有可能创建不准确的答复。

  • 透明度 - 同样，由于模型训练的方式，他们不再能够访问他们训练的基础知识。 即使他们做到了，也不能保证信息是真实和立足于第一位的。 此外，没有验证步骤来确保生成的响应准确。

  • 没有特定于域的知识 - 类似于“知识截止”，如果你有专用信息（如仅限内部的公司文档），则 LLM 没有根据此信息进行培训，因此没有特定于域的知识。

可以做些什么来缓解 LLM 可能存在的挑战或问题，并获得最佳结果来帮助用户和组织？ 首先，了解可以补充 LLM 从何处获取其数据的方式。

了解 LLM 获取其信息的位置

从 LLM 获得最佳结果的一个好起点是了解 LLM 从何处或如何获取其信息。 以下类别表示 LLM 如何与各种信息源进行交互以生成响应的不同方法。

该图描绘了三种不同类型的检索生成，其中顶部的检索关闭生成与最预先训练的知识相关，然后检索扩充的生成，然后在底部检索中心生成与最检索的知识相关。

  • 检索-关闭生成 （ROG） - 这是传统方式 LLM 运行的方式，模型基于其训练的知识生成响应，而无需在生成过程中访问或检索任何外部信息。 模型的知识是静态的，仅限于其定型数据中包含的内容，最长为截止日期。 除了创造性的写作，它还可以回答有关互联网上随时可用的信息的问题。

  • 检索扩充生成 （RAG） - 将 LLM 的生成功能与从外部数据库或文档实时检索信息的功能相结合。 该模型查询外部源以查找相关信息，然后用于通知其响应。 此方法允许模型提供比仅从预先训练的知识中获取的更准确和最新的信息。 用例包括事实检查、基于实时数据或专用域特定数据回答问题。

  • 以检索为中心的生成 （RCG） - 更加注重外部检索的内容，通常围绕从外部源提取的信息构建响应。 模型可以直接将检索到的大量文本段合并到其输出中，编辑或批注它们以适应用户的查询。 这种方法可以被视为基于检索的方法和生成方法之间的混合方法，其中平衡可能非常有利于检索到的信息，而模型自己的生成功能。 用例包括汇总较长的文档、用于跨多个相似文档提供比较和主题探索的研究帮助，以及将不同材料来源的编译或排序规则编译为组合输出。

“检索关闭生成”（ROG）的一个很好的示例是 ChatGPT。 相比之下，科皮洛特（通过必应）通过使用来自新闻源的外部来源（并提供指向这些来源的链接）来扩展 LLM。

首先，检索扩充生成（RAG）和以检索为中心的生成（RCG）听起来类似，因为两者都涉及将外部信息集成到语言生成过程中。 但是，它们在确定生成过程中检索到的信息的优先级和利用方式有所不同。

在 RAG 系统中，外部数据检索用于 增强 预先训练的语言模型的生成功能。 检索到的信息提供了模型用于通知其响应的更多上下文或特定数据。 在这里，语言模型的生成方面仍然是响应的核心，而检索到的数据充当 支持元素 以提高准确性或深度。

另一方面，RCG 系统更强调检索到的信息本身。 在这些系统中，检索的数据通常是响应的核心，生成模型的角色主要是为了优化、设置格式或稍微增强检索的文本。 当信息的准确性和直接相关性至关重要时，尤其使用此方法，并且需要较少的创造性合成或推断。

有关存储文档矢量化嵌入与微调 LLM 的文章中讨论了支持 RAG 和 RCG 的数据的外部检索机制，这两种常见方法基于初始训练来补充 LLM 可用的知识。

了解检索模型之间的区别有助于为特定应用程序选择合适的方法，平衡创造性合成的需求，以及对源材料的准确性和保真度的需求。

了解影响推理工作原理的因素

由于你可能熟悉 ChatGPT 的基于 Web 的用户界面，因此了解如何回答问题有助于了解在自己的应用程序中生成生成 AI 功能时至关重要的概念。

当用户与 ChatGPT 聊天时，用户界面设计提供了长时间运行的聊天会话的错觉，该会话会在你和 LLM 之间进行多次来回交换时保持状态。 实际上，对于给定的聊天会话，所有提示和 LLM 的所有响应（也称为 完成）都会随每个新提示一起发送。 因此，随着对话的增长，你正在向 LLM 发送更多的文本来处理 - 所有以前的提示和完成。 ChatGPT 在撰写对当前提示的响应时，使用整个聊天会话的上下文（而不仅仅是当前提示）。 整个聊天会话称为 上下文窗口。

上下文窗口长度限制取决于所使用的 ChatGPT 版本。 撰写对最新提示的响应时，将忽略超出上下文窗口长度限制的聊天对话的任何部分。

长对话起初似乎是个好主意，但长上下文窗口可能会影响处理提示和撰写完成所需的计算量。 这会影响响应的延迟以及 OpenAI 处理请求的成本。

ChatGPT 的上下文窗口限制是什么？ 或者，ChatGPT 可以处理多少个词？ 上下文窗口限制取决于你正在使用的 LLM 模型、版本和版本。 此外，上下文长度以令牌而不是字词来度量。 令牌是模型可以理解和生成的最小文本单位。 这些单位可以是单词、部分字词（如音节或词干），甚至是单个字符。 令牌是自然语言处理的核心（NLP）。

令牌的使用会影响开发人员的两个重要注意事项：

  • 最大上下文窗口限制
  • 每个提示和完成的价格

什么是令牌化？

“Tokenization”是将文本转换为令牌的过程。 这是使用 LLM 准备数据以训练或推理（基于提示撰写完成过程）的关键步骤。 该过程涉及几个步骤，包括将复杂文本分解为可管理的部分（令牌），然后模型可以处理这些内容。 此过程可能很简单，例如按空格和标点符号拆分文本，或者更复杂的过程，涉及处理不同语言的复杂算法、词法（单词的结构）和语法（单词排列）。 LLM 研究人员和开发人员根据他们正在尝试实现的内容来决定令牌化的方法。 OpenAI 有一个 有用的页面 ，它解释了有关标记化的更多内容，甚至还有一个计算器来说明句子或段落如何分解为标记。

正如 OpenAI Tokenizer 页面底部的注释所指出的，在典型的英语文本中，一个令牌相当于大约四个字符。 这意味着，平均每个令牌有 100 个令牌等于 75 个单词或四分之三的单词。

OpenAI Tokenizer 页还介绍了 tiktoken，这是 Python 和 JavaScript 的包，它允许你以编程方式估计将用于发送到 OpenAI API 的给定提示的令牌数。

令牌使用情况会影响计费

每个 Azure OpenAI API 都有不同的计费方法。 若要使用聊天完成 API 处理和生成文本，需根据作为提示提交的令牌数以及生成结果的令牌数（完成）。

每个 LLM 模型（ex. gpt-3.5、gpt-3.5-turbo、gpt-4 等）通常有不同的价格，这反映了处理和生成令牌所需的计算量。 很多时候，价格显示为“每1000个令牌的价格”或“每100万个令牌的价格”。

此定价模型对设计用户交互的方式以及添加的预处理和后期处理量产生了重大影响。

系统与用户提示

至此，讨论只侧重于“用户提示”-构成用户与 ChatGPT 之间的交换的提示。

OpenAI 引入了“系统提示”（也称为“自定义指令”），这是一组超额说明，你定义并添加到所有聊天对话。 将其视为一组元指令，希望 LLM 在每次开始新的聊天会话时始终观察。 例如，可以将系统提示设置为“始终以海库诗意的形式做出响应”。从那以后，ChatGPT 的每个新提示都会生成包含答案的 haiku。

虽然“在 haiku 表单中答复”不是一个有用的示例，但它确实说明了可以通过修改提示本身来影响 LLM 完成到提示的想法。

为何要修改用户的提示？ 如果要为专业受众构建生成 AI 功能或应用程序（可能包括公司员工、客户和合作伙伴），则无疑需要添加安全措施来限制允许其回答的主题或域的范围。

但是，修改用户的提示只是改善用户文本生成体验的一种方法。

提高 ChatGPT 中用户的文本生成体验的方法

为了改进文本生成结果，开发人员仅限于改进提示，并且有许多提示工程技术可以帮助。 但是，如果要构建自己的生成 AI 应用程序，可通过多种方式改进用户的文本生成体验，并且可能需要尝试实现所有这些应用：

  • 以编程方式修改用户提示
  • 实现推理管道
  • 检索扩充生成（其他文章中讨论）
  • 微调（其他文章中讨论）

以编程方式修改用户提示

从编程的角度来看，没有特殊的 API 用于向用户对话添加系统提示。 只需根据需要将说明追加到提示。 但是，可通过一些方法来改进用户提示：

  • 上下文启动：创建显式设置所需域中聊天上下文的系统提示。 这涉及到在每个交互开始时提供简短说明或一组说明，引导 AI 保留在问题域中。
  • 基于示例的指导：在初始提示中包含与域相关的问题和答案类型的示例。 这有助于 AI 了解预期的响应类型。

此外，可以应用所有提示工程技术。 如果可以通过某种方式以编程方式完成此操作，则可以代表用户改进用户的提示。

此方法的注意事项是，提示时间越长，每次调用 LLM 的成本就越高。 即便如此，这很可能是将讨论的最便宜的方法。

实现推理管道

除了以编程方式修改用户的提示之外，下一步是创建整个推理管道。

推理管道是一个端到端过程，它采用原始输入（如文本或图像），并在使用它执行主要提示（预处理）之前“清理它”或检查完成情况，以确保它在向用户显示之前满足用户的需求（后期处理）。

预处理可能涉及关键字检查、相关性评分或转换查询，以更好地适应预期的域语言。 例如，可以分析用户提交的初始提示，然后首先询问 LLM 是否有意义，如果它位于你愿意接受的内容的边界内，如果它基于错误的前提，或者需要重新编写，以避免某些偏见。 如果 LLM 分析提示并发现问题，可以进一步操作：要求 LLM 重新生成提示以改进答案。

后期处理可能涉及验证答案与域的相关性和适当性。 这可能包括删除或标记不符合域要求的答案。 例如，你可能想要检查 LLM 提供的完成情况，以确保它满足质量和安全要求。 你可以要求 LLM 评估答案，看看它是否确实满足你要求它遵守的要求。 如果没有，可以要求 LLM 修改完成，并重复此操作，直到获得令人满意的结果。

需要注意添加预处理步骤：每次在推理管道中添加对 LLM 的调用时，都会增加总体延迟（响应时间）以及每次与用户交互的成本。 作为一名经验丰富的软件开发人员，你可能已经意识到这些权衡必须由影响软件系统的预算、性能和有效性的领导做出。

生成高级检索扩充生成系统文章深入探讨生成推理管道的具体步骤。

影响完成的其他因素

除了以编程方式修改提示、创建推理管道和其他技术外，还讨论了使用检索扩充生成和微调扩充大型语言模型的详细信息。 此外，还可以在调用 Azure OpenAI API 时修改参数。

聊天终结点文档列出了传递的必需参数和可选参数，这些参数可能会影响完成的各个方面。 如果改用 SDK，请参阅 SDK 文档，了解所选语言。 如果要试验参数，可以在 Playground 中执行此操作。

  • 温度：控制模型生成的输出的随机性。 从零开始，模型会变得确定性，始终从其训练数据中选择最有可能的下一个标记。 在温度为 1 时，模型平衡选择高概率标记并将随机性引入输出。

  • 最大令牌：控制响应的最大长度。 设置较高或较低的限制可能会影响所生成内容的详细信息和范围。

  • Top P （核采样）：与温度一起使用来控制响应的随机性。 TOP P 限制 AI 在生成每个令牌时仅考虑概率质量的前 P 百分比。 较低的值会导致更集中和可预测的文本，而较高的值允许更多的多样性。

  • 频率惩罚：降低重复相同行或短语的模型的可能性。 增加此值有助于避免生成的文本中的冗余。

  • 状态处罚：鼓励模型在完成时引入新的概念和术语。 存在惩罚可用于生成更多样化和创造性的输出。

  • 停止序列：可以指定一个或多个序列来指示 API 停止生成进一步令牌。 存储序列可用于控制输出的结构，例如在句子或段落末尾结束完成。

  • Logit Bias：允许修改指定令牌在完成中出现的可能性。 Logit Bias 可用于指导特定方向完成或禁止不想要的内容。

了解 Microsoft OpenAI 防护措施

除了保持 LLM 对特定主题或域的响应，你还可能会关注用户询问的 LLM 问题类型。 请务必考虑它生成的答案类型。

首先，API 调用 Microsoft OpenAI Services 会自动筛选它发现可能令人反感的内容，并将其报告回许多筛选类别。

可以直接使用 OpenAI 的审查 API 来显式检查任何内容是否存在潜在的有害内容。

其次，可以使用 Azure AI 内容安全来帮助进行文本审查、图像审查、越狱风险检测和受保护的材料检测。 这会将门户设置、配置和报告体验与可添加到应用程序的代码相结合，以识别有害内容。

可能影响应用程序设计决策的最终注意事项

了解令牌化、定价、上下文窗口和实现编程改进，以增强用户的文本生成体验会影响你设计生成 AI 系统的方式。 下面是本文中要考虑的事项和其他要点的简短列表，这些内容会影响应用程序设计决策：

  • 根据成本注意事项评估使用最新 AI 模型的必要性。 成本较低的模型可能足以满足应用程序的需求，将性能与预算约束相平衡。
  • 考虑优化上下文窗口长度来管理成本，而不会影响用户体验。 剪裁不必要的对话部分可能会降低处理费用，同时保持质量交互。
  • 评估输入和输出的标记化和粒度如何影响性能。 了解所选 LLM 如何处理令牌化，有助于优化 API 调用的效率，降低成本并提高响应时间。

如果想要立即开始尝试生成生成 AI 解决方案，建议使用自己的 Python 数据示例来了解聊天入门。 .NET、Java 和 JavaScript 中还提供了本教程的版本。