在 LLM 应用程序中构建稳健性和确定性
图片来自作者
欢迎来到雲闪世界。OpenAI最近宣布其最新的gpt-4o-2024–08–06模型支持结构化输出。与大型语言模型 (LLM) 相关的结构化输出并不是什么新鲜事——开发人员要么使用各种快速工程技术，要么使用第三方工具。
在本文中，我们将解释什么是结构化输出、它们如何工作以及如何将它们应用于您自己的基于 LLM 的应用程序中。尽管 OpenAI 的公告使得使用他们的 API 实现起来非常容易（正如我们将在此处演示的那样），但您可能希望选择开源Outlines包（由dottxt上的可爱人员维护），因为它可以应用于自托管开放权重模型（例如 Mistral 和 LLaMA）以及专有 API（免责声明：由于此问题， Outlines 在撰写本文时不支持通过 OpenAI API 生成结构化 JSON；但这很快就会改变！）。
什么是结构化输出？
如果RedPajama 数据集有任何指示，那么绝大多数预训练数据都是人类文本。因此，“自然语言”是 LLM 的原生领域——无论是在输入中，还是在输出中。然而，当我们构建应用程序时，我们希望使用机器可读的形式结构或模式来封装我们的数据输入/输出。这样我们就可以在应用程序中构建稳健性和确定性。
结构化输出是一种机制，通过该机制，我们可以在 LLM 输出上强制执行预定义模式。这通常意味着我们强制执行 JSON 模式，但它不仅限于 JSON — 原则上我们可以强制执行 XML、Markdown 或完全定制的模式。结构化输出的好处有两方面：
-
更简单的提示设计——在指定输出应该是什么样子时，我们不需要过于冗长
-
确定性名称和类型——我们可以保证在 LLM 响应中获得age具有Number JSON 类型的属性
实现 JSON 模式
在这个例子中，我们将使用Sam Altman 的维基百科条目的第一句话……
塞缪尔·哈里斯·奥特曼 (Samuel Harris Altman，1985 年 4 月 22 日出生) 是一位美国企业家和投资者，自 2019 年起担任 OpenAI 的首席执行官（他曾短暂被解雇并于 2023 年 11 月复职）。
…我们将使用最新的 GPT-4o 检查点作为命名实体识别 (NER) 系统。我们将强制执行以下 JSON 模式：
json_schema = {
"name": "NamedEntities","name" : "NamedEntities" ,
"schema" : {
"type" : "object" ,
"properties" : {
"entities" : {
"type" : "array" ,
"description" : "实体名称及其对应类型的列表" ,
"items" : {
"type" : "object" ,
"properties" : { "
name" : {
"type" : "string" ,
"description" : "文本中指定的实际名称，例如人名或国家名称"
},
"type" : {
"type" : "string" ,
"description" : "实体类型，例如'Person'或'Organization'" ,
"enum" : [ "Person" , "Organization" , "Location" , "DateTime" ]
}
},
"required" : [ "name" , "type" ],
“additionalProperties” : False
}
}
},
“required” : [ “entities” ],
“additionalProperties” : False
},
“strict” : True
}
本质上，我们的 LLM 响应应该包含一个NamedEntities对象，该对象由一个数组组成entities，每个数组包含一个name和type。这里有几点需要注意。例如，我们可以强制使用枚举类型，这在 NER 中非常有用，因为我们可以将输出限制为一组固定的实体类型。我们必须指定数组中的所有字段required：但是，我们也可以通过将类型设置为例如来模拟“可选”字段["string", null]。
现在，我们可以将模式连同数据和指令一起传递给 API。我们需要response_format用一个字典填充参数，然后提供相应的模式。type"json_schema”
完成 = 客户端。beta.chat.completions.parse(
model="gpt-4o-2024-08-06",“gpt-4o-2024-08-06”，
消息=[
{
“role”：“system”，
“content”：“”“您是命名实体识别 (NER) 助理。
您的工作是识别并返回
给定文本的所有实体名称及其类型。您只能严格遵守
以下实体类型：人员、位置、组织
和日期时间。如果不确定实体类型，请忽略它。
请小心某些首字母缩略词，例如角色头衔“CEO”、“CTO”、
“VP”等 - 这些应该被忽略。”“”，
}，
{
“role”：“user”，
“content”：s
}
]，
response_format={
“type”：“json_schema”，
“json_schema”：json_schema，
}
)
输出应如下所示：
{'entities': [{'name':'Samuel Harris Altman','type':'Person'},'实体'：[{ '名称'：'塞缪尔·哈里斯·奥特曼'，'类型'：'人' }，
{ '名称'：'1985 年 4 月 22 日'，'类型'：'日期时间' }，
{ '名称'：'美国人'，'类型'：'地点' }，
{ '名称'：'OpenAI'，'类型'：'组织' }，
{ '名称'：'2019'，'类型'：'日期时间' }，
{ '名称'：'2023 年 11 月'，'类型'：'日期时间' }]}
本文使用的完整源代码可在此处获得。
工作原理
魔法在于约束采样和上下文无关语法 (CFG)的结合。我们之前提到过，绝大多数预训练数据都是“自然语言”。从统计上讲，这意味着对于每个解码/采样步骤，从学习的词汇表中抽取一些任意标记的可能性都是不可忽略的（在现代 LLM 中，词汇表通常涵盖 40 000 多个标记）。但是，在处理形式模式时，我们确实希望快速消除所有不可能的标记。
在前面的例子中，如果我们已经生成了……
{'实体'：[{'名称'：'Samuel Harris Altman'，‘实体’：[{ ‘名称’：‘塞缪尔·哈里斯·奥特曼’，
...那么理想情况下，我们希望'typ在下一个解码步骤中对标记放置非常高的逻辑偏差，而对词汇表中所有其他标记放置非常低的概率。
本质上就是这种情况。当我们提供模式时，它会被转换成形式语法或 CFG，用于在解码步骤中指导逻辑偏差值。CFG 是那些正在卷土重来的老式计算机科学和自然语言处理 (NLP) 机制之一。这个 StackOverflow 答案实际上对 CFG 进行了非常好的介绍，但本质上它是一种描述符号集合的转换规则的方式。
结论
结构化输出并不是什么新鲜事物，但随着专有 API 和 LLM 服务的出现，它无疑正成为人们最关心的问题。它们在 LLM 不稳定且不可预测的“自然语言”领域与软件工程确定性和结构化领域之间架起了一座桥梁。结构化输出对于任何设计复杂 LLM 应用程序的人来说都是必不可少的，因为LLM 输出必须在各种组件中共享或“呈现”。虽然 API 原生支持终于到来了，但构建者也应该考虑使用 Outlines 等库，因为它们提供了一种与 LLM/API 无关的方法来处理结构化输出。
感谢关注雲闪世界。（Aws解决方案架构师vs开发人员&GCP解决方案架构师vs开发人员）
