2023年的世界人工智能大会(WAIC)是“百模大战”,今年WAIC的关键词是“应用至上”。纵观今年论坛热点话题,无论是具身智能还是AI Agent(智能体),都指向以大模型为代表的AI技术在不同场景下的垂直应用。
从模型输出看大模型应用的两种范式:
输出非结构化数据:问答机器人,智能客服,或者另一个大模型的上游输入,都属于这种范式。技术架构是(领域)大模型+RAG,对输出格式没有要求。
输出结构化数据:当需要把大模型嵌入到工作流中(尤其是原有的工作流),就需要大模型和原工作组件进行交互,在这种情况下,我们期望大模型的输出是结构化数据(Json)。
我们需要在prompt里面提示大模型,具体的提示词类似于:
Wrap the output in json tags. The output should be formatted as a JSON instance that conforms to the JSON schema below. As an example, for the schema {“properties”: {“foo”: {“title”: “Foo”, “description”: “a list of strings”, “type”: “array”, “items”: {“type”: “string”}}}, “required”: [“foo”]} the object {“foo”: [“bar”, “baz”]} is a well-formatted instance of the schema. The object {“properties”: {“foo”: [“bar”, “baz”]}} is not well-formatted. Here is the output schema:
去年的 DevDay 上,OpenAI 引入了JSON Schema,这是一项为开发者量身定做的工具,旨在帮助他们构建更为可靠的应用程序。尽管 JSON Schema 提高了模型生成有效 JSON 输出的准确性,但它并不保证响应能够完全符合特定的 schema 规范。为了克服这一限制,OpenAI 进一步推出了API的结构化输出特性,确保模型的输出能够精确匹配开发者所提供的 JSON Schema。
将非结构化输入转化为结构化数据是大模型(LLMs)的关键应用之一。开发者们利用 OpenAI API 构建出功能强大的智能助手,这些助手能够通过函数调用来获取数据、回答问题、提取结构化数据进行数据录入,以及构建多步骤的代理工作流程,从而让LLMs能够执行实际任务。
过去,开发者们通过使用开源工具、精心设计的提示以及不断尝试不同的请求,来解决LLMs在结构化数据生成方面的局限,确保模型的输出能够与他们的系统无缝对接。
现在,结构化输出功能通过强制模型遵循开发者指定的模式,并通过对模型进行更深入的复杂模式理解训练,有效地解决了这些问题。
边缘情况的考虑是确保系统鲁棒性的关键。在LeetCode等编程挑战中,全面性是区分优秀解决方案与普通方案的分水岭。同样,在将大型模型集成到工作流程中时,我们必须预见并处理所有可能的异常情况。
尽管大型模型可能拥有高达99.99%的准确率,但概率论告诉我们,随着运行次数的增加,即使是极小的失败几率也会导致失败的发生。在一万次的运行中,至少有一次失败是不可避免的。
在我们的应用场景中,我们依赖大型模型提供符合预定义JSON Schema的输出。任何与预期不符的返回结果都可能导致工作流程的中断,影响整体的稳定性和效率。
错误的类型可能多样,我们要主要关注以下几种情况:
JSON的合法性问题:非法的JSON结构可能导致解析错误,影响数据的进一步处理;
JSON层级问题:大型模型有时可能会在没有明确指示的情况下增加或减少嵌套层级,这会破坏预期的数据结构;
JSON key的问题:key的结果不符合约定,或者在value缺失的情况下,相应的key也可能意外地消失;
JSON key-value对应错误:当key相似时,可能会出现key-value错配的情况,即value被错误地关联到了错误的key上。
这些情况都有可能让工作流失败,所以一个好的方式是在给出结果前reflection下,保险的方式是做些校验
reflection:在模型输出前,我们可以通过reflection的方式,检查模型输出的结构,确保其符合预期的JSON Schema;这种方式适合对时延要求不高的场景;
Hard code校验:在模型输出后,我们可以通过校验的方式,检查模型输出的结构,确保其符合预期的JSON Schema;这种方式适合对时延要求较高的场景。
仓库上有原始的Markdown文件,完全开源,欢迎大家Star和Fork!