借助大模型实现从数字化到智能化

2024-06-01 08:07:53 浏览数 (1)

2024年5月初,国家发展改革委办公厅、国家数据局综合司印发《数字经济2024年工作要点》(以下简称《工作要点》),对2024年数字经济重点工作作出部署。国家发展改革委办公厅和国家数据局综合司印发的这份文件,提出了九方面的重点工作,包括适度超前布局数字基础设施、加快构建数据基础制度、深入推进产业数字化转型等,旨在全面推动数字经济的高质量发展。

在进行 IT 系统集成或设计某些自动化流程时,其实已经有 Agent 这一层了,尤其是在设备与外界交互的环节,而那时还没有将大模型技术整合进来以实现更广泛的泛化能力和生成式能力。大模型技术引入后,起初我们并没有考虑将其应用于设备控制或高度交互性的 IT 系统交互中,而主要看中其在创作和生成内容方面的潜力。我们在设备代理方面的工作与 AI Agent 的概念思路颇为相似,只是随着大模型的加入,AI Agent 的能力和应用场景都发生了变化。如果仅从 IT 系统的能力角度来看,AI Agent 这个概念并不神秘,不过是通过引入大模型为 AI Agent 带来了更多能力,从而丰富了其功能。

在数字世界中,我们需要利用规划、循环和反思的控制机制,实现任务从开始到结束的全流程控制,并调用数字世界里的外部工具进行执行,这正是我们的IT系统通过引入大模型实现数字化向智能化转变的关键技术:AI Agent。

大语言模型的主要功能是处理和生成文本,核心在于将文本信息进行向量化处理,并通过 Transformer 架构以及监督学习机制,实现技术上的范式转变。这些技术基础的迭代,再结合大量的数据和强大的算力,促成了 ChatGPT 等大语言模型的诞生,它们在文本生成和回复方面表现出色。尽管大语言模型在文本领域取得了显著的成就,但本质上只具备基于零样本提示词的文本回复的能力,而不具备执行实际任务的能力。这意味着,无论大模型在文本处理上多么先进,它们仍然需要 Agent 的介入来实现从文本到行动的转变和全流程的处理。 因此,大模型和 Agent 是两个不同的概念,前者专长于文本交互,而后者则涉及到任务的执行和落地能力。简而言之,大语言模型缺乏将文本回复转化为实际行动的能力,是典型的缸中之脑。

我分享一下第一次接触 Agent 的经历,在Chatgpt出来以后,微软发布了一个开源项目Semantic kernel,其中实现的思路就是Agent,只不过是单个Agent,在Semantic kerenl的示例项目Chat-copilot中做了展示。2023年夏天 OpenAI 在ChatComplete接口上开发了一项名为“Function Calling”的能力,虽然看起来仍然是文本的输入和输出,但当函数作为一个字符串被输出并被精确调用时,我确实看到了 Agent 的不同之处。以前我们认为创作和创意不确定性是大语言模型最人性化的特征,但同时它们也有机器的一面,能够在有限的范围内唤醒某些函数。这项能力让我意识到 Agent 应该被独立考虑,其围绕工具使用、规划和执行的能力,可以帮助大模型结合现实世界中的数字和物理能力,形成一个更完整、更通用的解决方案。OpenAI随后推出了GPTs,并将之前的Plugin作废了,GPTs 已经是一个Agent 的商店。

然而,随着时间的推移,我发现 Function Calling 可能并不像我最初想象的那么好。它演示的技能是查询天气,虽然可以很好地执行,但许多场景要复杂得多,可能不只有 1个或 2 个函数可供调用,会出现完全不确定的函数,下一步该执行哪个函数也会是未知的,测试过几十个模型号称具有Function Calling能力的模型,目前只有Azure OpenAI/OpenAI和Anthropic 这两个模型族具备稳定的函数调用能力,其他的很多模型都在稳定性和可用性方面存在能力短板。不过,Agent 的主流能力,如浏览器的唤起、搜索引擎的查询结果以及一些生成能力的唤起,确实有效地让它从概念走向实际。当然,在实际应用过程中,我们也发现了许多不确定因素,但 Agent 的能力已经让我感到惊讶,它不仅仅是一个玩具,而可以改变现实世界。

Agent 主要依赖于大模型的 Function Calling 能力,需要准确地识别出当前调用哪个模型来完成当前任务,并提供相应的结果,以便大模型进行下一步操作。而瓶颈可能在于读取上下文的长度,上下文长度决定了能够识别多少个函数。Agent 在执行过程中受限于场景,只能在有限的函数中进行选择,其执行也不完全精确;如果执行不精确,就需要获取更多的环境信息或反馈信息来执行函数,过程中可能会出错。Agent 是一个精妙但不够鲁棒的系统,如果它返回到上一级并根据错误信息重新执行,可能会带来更大的资源消耗和时间延迟。

在企业场景中实施 Agent 时,我们首先需要考虑的是技术的可实现性。在挑选场景的过程中,就要考察技术是否可行;一旦场景确定,接下来需要考虑的是如何提高 Function Calling 的准确度,如果准确度不够高,需探索其他工程手段来提升 API 的识别准确率,甚至在语义理解之后通过额外的工程能力进行调整、校验生成的 API 并通过查询方式进行补充。

0 人点赞