大型语言模型(LLM)非常强大,但它们有限制。 你需要了解 LLM 默认可以执行的作以及如何调整它们,以获得生成式 AI 应用的最佳结果。 本文介绍 LLM 的主要挑战,并演示了解决它们的方法,并改进生成内容的方式,无论你构建哪种类型的生成 AI 功能。
使用 LLM 时的工程挑战
以下是使用 LLM 时要记住的最重大挑战和限制:
知识截止:LLM 只知道他们在特定日期接受过哪些训练。 如果没有外部数据连接,则无法访问实时或专用信息。
幻觉:LLM 可能会生成不准确或误导性的信息。 Azure AI Foundry 中的地面检测功能可帮助你确定 LLM 的响应是否基于你提供的源材料。 非前台响应包括数据不支持的信息。 在本 快速入门中了解如何使用停工情况检测。
透明度:不能始终跟踪生成的内容的源或准确性,并且没有内置的验证步骤。
没有特定于域的知识:除非集成内部或专有数据,否则 LLM 不知道自己的内部数据。
无法从交互中学习:LLM 没有过去交互的内存或意识,因此他们不能根据用户反馈适应或改进随时间推移。 若要克服这些挑战并获得最佳结果,请使用自己的数据补充 LLM 的知识并使用验证工具。
LLM 从哪里获取信息
LLM 基于书籍、文章、网站和其他来源的大型数据集进行训练。 他们的响应反映了此数据中的模式,但不包括训练截止后发生的任何内容。 如果没有外部连接,LLM 无法访问实时数据或浏览 Internet,这可能会导致过时或不完整的答案。
影响推理工作原理的因素
使用 LLM 时,模型可能记住整个对话。 实际上,你发送的每个新提示都包含你之前的所有提示和模型的答复。 LLM 使用此完整历史记录作为上下文来创建下一个答案。 此正在运行的历史记录是 上下文窗口。
每个 LLM 都有一个最大上下文窗口大小,按模型和版本更改。 如果对话超过此限制,模型会删除最旧的部分,并在答案中忽略它们。
较长的上下文窗口意味着模型必须处理更多数据,这可能会降低作速度并增加成本。
上下文窗口大小使用标记,而不是单词。 令牌是模型可以处理的文本中最小的部分-这些部分可能是整个单词、部分字词或单个字符,具体取决于语言和标记器。
对于开发人员,令牌使用直接影响:
- 模型可以考虑的最大会话历史记录量(上下文窗口)
- 每个提示和完成的成本,因为计费基于处理的令牌数
什么是令牌化?
标记化 是将文本分解为令牌的过程- 模型可以处理的最小单位。 令牌化对于使用 LLM 进行训练和推理都至关重要。 根据语言和标记器,令牌可能是整个单词、子词,甚至是单个字符。 标记化可以像按空格和标点符号拆分一样简单,也可以像使用解释语言结构和形态的算法一样复杂。
OpenAI tokenizer 页详细介绍了标记化,并包括一个计算器,用于说明句子如何拆分为标记。
在典型的英语文本中,一个标记大约是四个字符。 平均而言,100 个令牌大约是 75 个单词。
对于开发人员,以下库有助于估算提示和完成的令牌计数,这对于管理上下文窗口限制和成本很有用:
- tiktoken 库 (Python 和 JavaScript)
- Microsoft.ML.Tokenizers 库 (.NET)
- 拥抱人脸标记器库(JavaScript、Python 和 Java)
令牌使用情况会影响计费
每个 Azure OpenAI API 都有不同的计费方法。 使用聊天完成 API 处理和生成文本时,会根据你提交的提示令牌数量以及生成的结果令牌数量(完成情况)进行计费。
每个 LLM 模型(例如 GPT-4.1、GPT-4o 或 GPT-4o mini)通常有不同的价格,这反映了处理和生成令牌所需的计算量。 很多时候,价格显示为“每1000个令牌的价格”或“每100万个令牌的价格”。
此定价模型对如何设计用户交互以及添加的预处理和后期处理量具有显著影响。
系统提示与用户提示
到目前为止,本文讨论了 用户提示。 用户提示是发送到模型的内容,以及模型答复的内容。
OpenAI 还添加了 系统提示 (或 自定义说明)。 系统提示是添加到每个聊天的一组规则。 例如,你可以告诉 LLM“始终以 haiku 形式回答”。之后,每一个答案都是一个海库。
此 haiku 示例演示如何通过更改提示来更改 LLM 的答案。
为什么更改用户的提示? 如果为工作、客户或合作伙伴构建生成生成 AI 应用,可能需要添加规则来限制模型可以回答的内容。
但是,更改用户提示只是使文本生成更好的方法之一。
提高用户文本生成体验的方法
为了改进文本生成结果,开发人员仅限于改进提示,并且有许多提示工程技术可以帮助。 但是,如果要构建自己的生成 AI 应用程序,可通过多种方式改进用户的文本生成体验,并且可能需要尝试实现所有这些应用:
- 以编程方式修改用户提示。
- 实现推理管道。
- Retrieval-Augmented世代(在其他文章中讨论)。
- 优化(其他文章中已讨论)。
以编程方式修改用户提示
若要向用户对话添加系统提示,请不要使用特殊 API。 只需根据需要在提示中附加指令。
但是,可以使用一些方法来改进用户提示:
- 上下文启动:创建系统提示,明确在特定域中设定会话的上下文。 此方法涉及在每个交互开始时提供简短说明或一组说明。 这些说明指导 AI 保留在问题域中。
- 基于示例的指导:在初始提示中,包括与域相关的问题和答案类型的示例。 此方法可帮助 AI 了解预期响应类型。
可以使用任何提示工程技术。 如果可以通过编程方式完成此操作,可以代表用户改进用户提示。
需要注意的是,此方法的提示内容越长,每次调用 LLM 的成本就越高。 即便如此,此方法可能是本文介绍的开销最低的方法。
实现推理管道
改进用户的提示后,下一步是生成推理管道。
推理管道是一个过程:
- 清理原始输入(如文本或图像)
- 将其发送到模型(预处理)
- 检查模型的答案,确保它满足用户的需求,然后再显示它(后处理)。
预处理可以包括检查关键字、评分相关性或更改查询以更好地适应域。 例如,查看用户的第一个提示。 询问 LLM 提示是否有意义、遵循规则、基于正确的想法,或者需要重写以避免偏见。 如果 LLM 发现问题,可以要求它重写提示以获取更好的答案。
后处理可能意味着检查答案是否符合你的域并满足你的标准。 可以删除或标记与规则不匹配的答案。 例如,检查 LLM 的答案以查看它是否符合质量和安全需求。 可以要求 LLM 查看其答案,并根据需要进行更改。 重复此过程,直到获得良好的结果。
请记住:每次在推理管道中调用 LLM 时,响应花费的时间更长,成本更高。 你需要将这些权衡与你的预算、速度和系统工作程度进行平衡。
有关构建推理管道的具体步骤的信息,请参阅 构建高级检索增强生成系统。
影响完成的其他因素
除了以编程方式修改提示、创建推理管道和其他技术外,更多的详细信息在通过检索增强生成和微调来扩充大型语言模型中讨论。 此外,还可以在调用 Azure OpenAI API 时修改参数。
若要查看可能影响完成各个方面的必需参数和可选参数,请参阅聊天终结点文档。 如果使用 SDK,请参阅所用语言的 SDK 文档。 可以在 Playground 中试验参数。
Temperature:控制模型生成的输出的随机性。 从零开始,模型会变得确定性,始终从其训练数据中选择最有可能的下一个标记。 当温度为 1 时,模型在选择高概率标记和引入输出随机性之间达到平衡。Max Tokens:控制响应的最大长度。 设置较高或较低的限制可能会影响所生成内容的详细信息和范围。Top P(核采样):与Temperature一起使用来控制响应的随机性。Top P将 AI 限制为在生成每个标记时仅考虑概率质量的最高百分比(P)。 较低的值会导致文本更加集中且可预测。 较高的值允许更多的多样性。Frequency Penalty:降低模型重复相同行或短语的可能性。 增加此值有助于避免生成的文本中的冗余。Presence Penalty:鼓励模型在完成时引入新的概念和术语。Presence Penalty可用于生成更加多样化和创造性的输出。Stop Sequences:可以指定一个或多个序列来指示 API 停止生成更多令牌。Store Sequences有助于控制输出的结构,例如在句子或段落末尾结束完成。Logit Bias:允许修改指定令牌在完成中出现的可能性。Logit Bias可用于指导特定方向完成或禁止显示特定内容。
Microsoft Azure OpenAI 防护措施
除了让 LLM 的回应与特定主题或领域保持一致之外,你可能也关心用户向 LLM 提出的各类问题。 请务必考虑它生成的答案类型。
首先,API 调用Microsoft Azure OpenAI 服务会自动筛选 API 发现可能令人反感的内容,并在许多筛选类别中将此报告回给你。
可以直接使用 内容审查 API 来检查任何内容是否存在潜在的有害内容。
然后,可以使用 Azure AI 内容安全 来帮助进行文本审查、图像审查、越狱风险检测和受保护的材料检测。 此服务将门户设置、配置和报告体验与可添加到应用程序的代码相结合,以识别有害内容。
人工智能代理
AI 代理是构建可自行工作的生成 AI 应用的一种新方法。 它们使用 LLM 读取和写入文本,还可以连接到外部系统、API 和数据源。 AI 代理可以管理复杂的任务,使用实时数据做出选择,并了解人们如何使用它们。 有关 AI 代理的详细信息,请参阅 快速入门:创建新代理。
工具调用
AI 代理可以使用外部工具和 API 来获取信息、采取措施或与其他服务连接。 此功能允许他们执行不仅仅是生成文本并处理更复杂的任务。
例如,AI 代理可以从天气 API 获取实时天气更新,也可以根据用户询问的内容从数据库拉取详细信息。 有关工具调用的详细信息,请参阅 Azure AI Foundry 中的工具调用。
模型上下文协议 (MCP)
模型上下文协议(MCP)允许应用为大型语言模型提供功能和上下文。 MCP 的主要功能是定义 AI 代理用于完成任务的工具。 MCP 服务器可以在本地运行,但远程 MCP 服务器对于在云规模上共享工具至关重要。 有关详细信息,请参阅 在 Azure 上使用模型上下文协议生成代理。
应用程序设计的最终注意事项
了解令牌化、定价、上下文窗口和实现编程改进,以增强用户的文本生成体验会影响你设计生成 AI 系统的方式。
下面是本文要考虑的事项和其他要点的简短列表,这些内容可能会影响应用程序设计决策:
- 根据成本注意事项评估使用最新 AI 模型的必要性。 成本较低的模型可能足以满足应用程序的需求。 平衡性能与预算限制。
- 请考虑优化上下文窗口长度来管理成本,而不会影响用户体验。 剪裁聊天中不必要的部分可能会降低处理费用,同时保持质量交互。
- 评估输入和输出的标记化和粒度如何影响性能。 了解所选 LLM 如何处理令牌化,有助于优化 API 调用的效率,降低成本并提高响应时间。
如果想要立即开始尝试构建生成式 AI 解决方案,建议查看使用你自己的 Python 数据示例开始聊天。 本教程还可用于 .NET、Java和 JavaScript。