声明式编程与 LLM 的结合新范式
探讨如何用 LLM 理解开发者的高层意图,自动生成实现代码,融合声明式思想与 AI 能力。
探讨如何用 LLM 理解开发者的高层意图,自动生成实现代码,融合声明式思想与 AI 能力。
广义来说,要通过编程或指令让计算机执行一项任务,有两种方式:命令式编程与声明式编程。
命令式编程是我们最常采用的方式。我们编写计算机执行任务所需的全部代码,最终计算机只需要获取并执行 CPU 指令。如果你使用 Java、C#、JavaScript 等语言,那么你做的就是命令式编程。
声明式编程是一种更高阶的编程形式。我们指示计算机执行一项任务,但具体如何完成,则交由计算机自己“想办法”。声明式编程需要某种基于软件的执行引擎。命令式编程会将代码编译成机器码或字节码,再交给 CPU 运行;而声明式编程需要一个软件层来完成其中的“魔法”,让你不必亲自编写完成任务所需的精确逻辑。
我认为,结构化查询语言(SQL)以及负责处理它的关系数据库管理系统(RDBMS),应该是声明式编程范式中最具代表性的例子。
这两种编程方式构成了一组二分关系,可以概括为:指令与步骤。使用声明式编程时,你给出指令,其余部分由系统处理;使用命令式编程时,你要提供任务应该如何执行的详细步骤。
要让声明式系统真正有用,它必须提供足够强大的指令语言或格式,也就是领域特定语言(DSL),同时还要提供一套完备的工具,用来落实给定的指令。这也意味着,声明式系统很难在早期阶段快速成熟,因为开发者需要经过漫长的探索和实验,逐步积累必要的工具集,并提升 DSL 的表达能力,才能让它真正发挥优势。
你可以把声明式系统比作威士忌:它们往往会随着时间推移而变得更好——前提是能存活得足够久。
AI/LLM“或许”能够同时解决声明式系统面临的两个问题:指令语言或格式,以及工具集。
AI 不仅免去了开发定制 DSL 的需要——因为现在你的 DSL 就是自然语言——还可以利用 AI 的“智能”弥补工具能力上的缺口,例如 AI CodeGen。
市面上已经存在许多声明式系统,但其中大多数充其量只能算尚未成熟的尝试,因为无论表达能力还是工具集都相当有限。许多大型 CRM、ERP 和 BPM 平台都内置了一定程度的声明式能力,这些能力通常被称为规则引擎。
要让声明式解决方案真正有用,关键在于工具。然而,现有声明式系统提供的工具集,往往只是把命令式能力暴露给声明层。
例如,声明式系统中可能存在一个名为 list-interator 的工具:你向它传入一个列表,它便对列表进行迭代。这不过是以一种绕远路的方式进行命令式编程,而这种“工具”往往占据了现有声明式系统工具集中的很大一部分。
有了 AI,你的工具集便不再需要包含这类多余的声明式构造。工具将会是真正能够执行各种任务的工具。更进一步,其中许多工具甚至可以被实现为向 AI 提供简单反馈,也就是利用 AI 的输出生成更多 AI 输出。
让用户向计算机下达指令,而不是亲自指导计算机完成每一个步骤,这一目标几乎从计算机成为商业工具之初就已经成为人们追求的方向。COBOL 和 Visual Basic 等经典商业应用语言的语法,清楚地体现了这一点。
下面是一个通过 Solvent-Botworx 平台构建应用的指令(prompt)示例。它使用自然语言,不需要遵循严格的语法。这个 prompt 是用户给出的指令;实际发送给 AI 的 prompt 还包含一段更为详尽的前置信息,用来指导 AI 应该如何处理这项请求。
下面是由 AI CodeGen 将同一个 prompt 转换成的 COBOL 版本。
这两种指令形式在语法上的相似性显而易见。在我们的实现中,我们要求 AI 将 prompt 转换成 JSON 对象结构,然后由声明式执行引擎中的定制工具进一步处理。
采用 AI 的方式,意味着声明式系统在构建时可以摆脱特定平台的限制。此外,未来构建声明式系统的重点,将主要转向如何整合各种工具:这些工具会处理 AI 生成的配置,并进一步生成命令式逻辑或功能;这些逻辑或功能在部署之前可以接受审计、测试和评审。
关于 AI 的局限性,尤其是准确性方面的问题,人们已经讨论了很多。这些批评是合理的,但它们可能主要反映了 AI 淘金热初期的状况。
在所谓的 AGI 真正出现之前——如果它真的会出现的话——也就是在我们拥有一种能力足够强大且足够“理智”(即有现实依据)的 AI 之前:它能够像聪明且受过良好教育的人类一样,只需被告知需要完成什么,就能自行弄清楚应该如何完成。最可靠的 AI 解决方案,仍将是那些较少依赖 AI 仅凭自身“知识”直接生成原始输出,而更多利用完备工具来驱动自动化的方案。
这类解决方案主要依赖 AI 的抽象智能,也就是 AI 接收指令(包括数据),并生成结构化输出的能力;随后,这些结构化输出可以通过工具进行处理。换句话说,就是让 AI 成为声明式执行引擎的一部分。
事实上,未来胜出的 AI 企业中,很可能会出现一些出人意料的公司。当然,我预计 OpenAI、Anthropic、Google 以及其他基础设施服务提供商都会从中获利,但一些“老派”软件公司也有可能占据最有利的位置,凭借 AI 的声明式执行能力获得巨大利益。
以 SAP 这样的公司为例。SAP 以系统复杂、实施时需要聘请昂贵顾问而闻名。可以想象,SAP 最终可能会实现一套 AI 能力,将其复杂系统拆分成一个个工具,以渐进方式将其能力暴露出来,再通过声明式指令处理把这些工具组合在一起。
到那时,你很可能仍然需要那些昂贵的顾问,但数量应该会比原本少得多。这意味着 SAP 客户的成本将会降低,进而推动该平台获得更广泛的采用。
对 AI 生成的配置进行声明式处理,是让 AI 具备现实依据的一种方式。这需要投入大量工作,因为你不能只是把请求丢给 AI;相反,你的处理逻辑必须充当护栏,确保正在执行的操作合乎情理。如果要在强调可靠性的应用中使用 AI,这些工作就不可或缺。
Agent 应用同样如此。最有用的 Agent 应用,将是那些基于配置执行操作,并拥有明确逻辑的应用:这种逻辑能够判断配置步骤提出的方案是否真的合理。
归根结底,你不应该只是说:“AI,去完成 X 和 Y。”你应该这样说:“这是我的指令和必要的数据,请生成一份符合这个配置结构(或 schema)的配置。”然后,再让你的声明式处理实现对该配置采取行动,并应用所有必要的合理性检查与安全检查。
谈到提升 AI 能力,目前的发展势头主要集中在增加模型训练上。这当然是一个先决条件,但在可预见的未来,对于那些要求可靠性和一致性的用例,声明式处理方式很可能仍然不可或缺。
目前领先的模型确实非常聪明,但它们仍然有些“不受控制”。要实现一致性与可靠性,就必须让它们建立在明确的现实依据之上。
下面展示了一个会话,其中演示了 Solvent-Botworx 平台上由 AI 赋能的声明式处理: