原文towardsdatascience.com/structured-generative-ai-e772123428e4?sourcecollection_archive---------3-----------------------#2024-04-18如何限制你的模型输出定义的格式https://medium.com/orenmatar?sourcepost_page---byline--e772123428e4--------------------------------https://towardsdatascience.com/?sourcepost_page---byline--e772123428e4-------------------------------- Oren Matar·发表于 Towards Data Science ·阅读时间 7 分钟·2024 年 4 月 18 日–在这篇文章中我将解释并演示“结构化生成式 AI”的概念即将生成式 AI 限制在定义的格式内。文章结束时你将理解它的应用场景以及如何实现它无论是从零开始构建一个变换器模型还是使用 Hugging Face 的模型。此外我们还将介绍一个与分词相关的重要技巧特别适用于结构化语言。生成式 AI 的许多用途之一是作为翻译工具。这通常涉及在人类语言之间的翻译但也可以包括计算机语言或格式。例如你的应用程序可能需要将自然语言人类语言翻译成 SQL**Natural language**:“Get customer namesandemails of customersfromthe US”**SQL**:SELECT name, email FROM customers WHERE country USA或者将文本数据转换为 JSON 格式**Natural language**:“I am John Doe,phone numberis555–123–4567,my friends are AnnaandSara”**JSON**:{name:John Doe,phone_number:555–123–5678,friends:{name:[[Anna,Sara]]}}自然地其他结构化语言也可以有更多的应用。此类任务的训练过程包括将自然语言与结构化格式的示例输入到编码器-解码器模型中。或者利用预训练的语言模型LLM也可以满足需求。虽然实现 100% 准确率是不可能的但有一类错误我们是可以消除的语法错误。这些错误是对语言格式的违反比如用点替代逗号使用 SQL 模式中没有的表名或者遗漏括号闭合这些都会导致 SQL 或 JSON 无法执行。我们正在翻译成结构化语言这意味着在每一步生成过程中合法令牌的列表是有限的并且是预定的。如果我们能够将这一知识注入到生成式 AI 过程中就能避免许多不正确的结果。这就是结构化生成式 AI 的理念将其限制为一组合法的令牌。关于令牌生成的快速提醒无论是使用编码器-解码器架构还是 GPT 架构令牌生成都是按顺序进行的。每个令牌的选择依赖于输入和之前生成的令牌直到生成令牌标志着序列的完成。在每一步分类器会为词汇表中的所有令牌分配 logit 值表示每个令牌作为下一个选择的概率。接下来的令牌是基于这些 logits 进行采样的。https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/cad3a2ae8eae2f7150a70bacdecbaa82.png解码器分类器为词汇表中的每个令牌分配一个 logit图片由作者提供限制令牌生成为了约束令牌生成我们结合了对输出语言结构的理解。不合法的令牌将其 logits 设置为-inf确保它们不会被选中。例如如果在“Select name”后只有逗号或“FROM”是合法的那么所有其他令牌的 logits 都会被设置为-inf。如果你使用 Hugging Face可以通过“logits 处理器”实现这一点。要使用它你需要实现一个包含call方法的类该方法在计算 logits 后被调用但在采样之前。此方法接收所有令牌 logits 和生成的输入 ID并返回所有令牌的修改后的 logits。https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/e92f5fbfb0e5b222e3b5b4571ae33971.png从 logits 处理器返回的 logits所有不合法的令牌都会得到-inf 的值图片由作者提供我将通过一个简化的示例演示代码。首先我们初始化模型这里我们使用 Bart 模型但任何模型都可以使用。fromtransformersimportBartForConditionalGeneration,BartTokenizerFast,PreTrainedTokenizerfromtransformers.generation.logits_processimportLogitsProcessorList,LogitsProcessorimporttorch namefacebook/bart-largetokenizerBartTokenizerFast.from_pretrained(name,add_prefix_spaceTrue)pretrained_modelBartForConditionalGeneration.from_pretrained(name)如果我们想要生成从自然语言到 SQL 的翻译可以运行to_translatecustomers emails from the uswordsto_translate.split()tokenized_texttokenizer([words],is_split_into_wordsTrue)outpretrained_model.generate(torch.tensor(tokenized_text[input_ids]),max_new_tokens20,)print(tokenizer.convert_tokens_to_string(tokenizer.convert_ids_to_tokens(out[0],skip_special_tokensTrue)))返回More emails from the us由于我们没有针对文本到 SQL 任务对模型进行微调因此输出不类似于 SQL。在本教程中我们不会训练模型但我们会引导它生成 SQL 查询。我们将通过使用一个函数来实现这一点该函数将每个生成的令牌映射到允许的下一个令牌列表。为了简化我们仅关注紧接着的前一个令牌但更复杂的机制也容易实现。我们将使用一个字典来定义每个令牌允许的后续令牌。例如查询必须以“SELECT”或“DELETE”开始在“SELECT”之后仅允许“name”、“email”或“id”因为这些是我们架构中的列。rules{s:[SELECT,DELETE],# beginning of the generationSELECT:[name,email,id],# names of columns in our schemaDELETE:[name,email,id],name:[,,FROM],email:[,,FROM],id:[,,FROM],,:[name,email,id],FROM:[customers,vendors],# names of tables in our schemacustomers:[/s],vendors:[/s],# end of the generation}现在我们需要将这些令牌转换为模型使用的 ID。这将在一个继承自 LogitsProcessor 的类中完成。defconvert_token_to_id(token):returntokenizer(token,add_special_tokensFalse)[input_ids][0]classSQLLogitsProcessor(LogitsProcessor):def__init__(self,tokenizer:PreTrainedTokenizer):self.tokenizertokenizer self.rules{convert_token_to_id(k):[convert_token_to_id(v0)forv0inv]fork,vinrules.items()}最后我们将实现call函数该函数在计算 logits 后被调用。此函数创建一个包含-infs 的新张量检查哪些 ID 符合规则字典中的规则并将其分数放入新张量中。结果是一个仅包含有效令牌的有效值的张量。classSQLLogitsProcessor(LogitsProcessor):def__init__(self,tokenizer:PreTrainedTokenizer):self.tokenizertokenizer self.rules{convert_token_to_id(k):[convert_token_to_id(v0)forv0inv]fork,vinrules.items()}def__call__(self,input_ids:torch.LongTensor,scores:torch.LongTensor):ifnot(input_idsself.tokenizer.bos_token_id).any():# we must allow the start token to appear before we start processingreturnscores# create a new tensor of -infnew_scorestorch.full((1,self.tokenizer.vocab_size),float(-inf))# ids of legitimate tokenslegit_idsself.rules[int(input_ids[0,-1])]# place their values in the new tensornew_scores[:,legit_ids]scores[0,legit_ids]returnnew_scores就这样我们现在可以使用 logits 处理器进行生成to_translatecustomers emails from the uswordsto_translate.split()tokenized_texttokenizer([words],is_split_into_wordsTrue,return_offsets_mappingTrue)logits_processorLogitsProcessorList([SQLLogitsProcessor(tokenizer)])outpretrained_model.generate(torch.tensor(tokenized_text[input_ids]),max_new_tokens20,logits_processorlogits_processor)print(tokenizer.convert_tokens_to_string(tokenizer.convert_ids_to_tokens(out[0],skip_special_tokensTrue)))返回SELECT email,email,id,email FROM customers结果有点奇怪但请记住我们甚至没有训练模型我们只是根据特定规则强制生成标记。值得注意的是约束生成不会干扰训练约束只在训练后生成过程中起作用。因此当这些约束得当实施时它们只会提高生成准确性。我们的简化实现未能涵盖所有 SQL 语法。一个真正的实现必须支持更多的语法可能不仅考虑最后一个标记还要考虑多个标记并且支持批量生成。一旦这些改进到位我们训练好的模型可以可靠地生成可执行的 SQL 查询且仅限于模式中有效的表名和列名。类似的方法也可以在生成 JSON 时强制执行约束确保键存在和括号闭合。注意分词问题分词通常被忽视但在使用生成性 AI 进行结构化输出时正确的分词至关重要。然而在后台分词可能对模型的训练产生影响。例如您可能会微调一个模型将文本翻译为 JSON。在微调过程中您向模型提供文本-JSON 对模型会对其进行分词。那么这种分词会是什么样子呢https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/dc9052660570390852112c1180650f1e.png(图像来源作者)当您阅读“[”时它是两个方括号但分词器将其转换为单一的 ID这将被分词分类器视为与单一括号完全不同的类别。这使得模型必须学习的整个逻辑更加复杂例如记住需要关闭多少个括号。类似地在单词前添加空格可能会改变它们的分词和类别 ID。例如https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/ce09edd397c68277a6d2ddf93b2cb378.png分开写的单词有助于更一致的分词图像来源作者在微调过程中输入带空格的示例可以简化模型需要学习的模式从而提高模型的准确性。在预测时模型将输出带空格的 JSON您可以在解析之前去除这些空格。总结生成性 AI 提供了一种有价值的方法用于翻译成格式化语言。通过利用输出结构的知识我们可以约束生成过程消除一类错误并确保查询的可执行性和数据结构的可解析性。此外这些格式可能会使用标点符号和关键词来表示某些意义。确保这些关键词的标记化一致性可以显著降低模型需要学习的模式复杂度从而减少模型的所需规模和训练时间同时提高其准确性。结构化生成式人工智能可以有效地将自然语言转换为任何结构化格式。这些翻译能够从文本中提取信息或生成查询这是许多应用的强大工具。