Blog

Blog

PHODAL

大语言模型友好的 API:借助集体智慧构建更好的软件架构

在过去的几个月里,我们一直在探索:如何将大语言模型用于研发效能提升?而随着,我们研究的逐步推进,慢慢进入一些深水区,诸如于:如何将 AI 更好地用于辅助架构设计?基于我们多年的架构设计及治理经验,开放服务能力是评价架构的重要维度之一,而 API 正是提升架构开放性和改善对外服务能力的关键手段。

我们先前的观察和 Unit Mesh 的一系列编程相关的 LoRA 试验,我们的结论是:【开源 LLM + LoRA 微调】将会成为大多数企业更愿意接受的方式,所以我们也将在此介绍:企业如何构建私有化的 API 设计能力,从而构建更加开放、现代化和高效的架构体系。

传统的API设计弊端

传统的 API 设计往往面临三个挑战:

  1. 开放资源难以决策。其中包括应当开放哪些数据以及服务,才能将企业的数字化价值最大程度输出及“变现”;
  2. 点状需求驱动。缺乏整体的设计与规划,API成为了交付物而非数字化资产;
  3. RESTful 设计标准难以落地。尤其在规模较大的研发组织中,技术能力参差不齐更容易导致API设计产出的标准不一。

同时,还需要加强技术能力培训和知识共享,以提高组织内部的 API 设计水平和一致性。

大语言模型友好的 API

在开源大语言模型(LLM)的加持之下,我们可以做到:

  1. 集采众长以帮助场景创新。将相关领域中已开放的专业知识和经验融合到语言模型中,从而辅助探索合适的API服务场景 - Discover;
  2. 资产建模驱动。将研发组织已有的经典的软件工程的资产,文本化、结构化转变为 LLM 的语料,充分利用既有经验以定义能够满足服务场景的API - Define;
  3. 标准内建的设计与交付。将自然语言描述的场景及需求转化为具体的 Restful API 设计,并结合数据工程与平台工程,持续整合整个组织的软件智慧和经验,以帮助我们构建好的软件架构 - Deliver。

通过利用 LLM 的能力,我们可以更好地应对 API 设计中的挑战,实现数字化价值最大化和 API 成为数字化资产的目标。

于是,我们针对 LLM 与 API 的结合应用进行了深入研究,而在这个过程中,发现了一些很有意思的范式。我们将适合于此的 API 模式称为 LLM 模型友好的 API。其定义如下:

大语言模型(LLM)友好的 API 是指为了更好地适应和利用大型语言模型的能力,而设计的软件 API 规格,以方便于 LLM 的指令设计和工具化集成。这种 API 的格式和输入输出应当与大型语言模型的输入输出格式相匹配,以便大型语言模型可以更好地理解和处理输入,并输出符合预期的结果。

简单来说,就是设计 LLM 友好的 API 格式,以用于 LLM 生成与识别,以方便后续的代码生成等环节。

模式:集体智慧飞轮

结合我们对于 LLM 的理解与探索,结合 GitHub Copilot 的免费试验过程与逻辑实现。我们基于 ChatGLM 训练了我们的第一个架构辅助设计 LoRA。并根据我们的理解,绘制了一个可复用的过程路径:

在不同的阶段,我们有不同的关注点:

  • Discover 阶段,关注于数据与语言工程。即:训练语料的来源与数据处理,或是来源于对 OpenAI 的数据蒸馏,或是来源于公开的 API,又或是从代码中提炼 API。
  • Define 阶段,关注于 Prompt 工程。即:设计适用于私有化大模型的 instruction、input 和 output,以及设计演进式评估所需要的评估数据集。
  • Delivery 阶段,关注于平台工程。即:将 LLM 的应用工程化,“无缝” 接入内部的各种平台和工具,持续处理用户对于数据的反馈,以持续迭代软件数据集。

在此时,LLM 的工程化便是一个跨越不同领域的复杂数据工程活动。将这样的工程标准化、跨不同部门协作、持续迭代下去,则会是我们未来的新挑战。

以 API 为例,我们将上述的三个阶段分解为六步:

  • Discover 阶段
    • 识别软件工程资产
    • 针对于资产的“语言建模”(格式化输出)
  • Define 阶段
    • MVP 微调试验
    • 设计增量引导指标
  • Delivery 阶段
    • LLM 体验设计与工具集成
    • 基于反馈的平台工程

针对于不同的场景下,可能略有差异。

三阶六步构建模型友好的智慧飞轮

步骤 1:识别软件工程资产

在清晰地了解工程过程之后,我们便需要继续深入架构领域,分析我们能怎么去实现。我们定义的第一步是:识别软件工程资产。即在分析如何实现目标之前,需要梳理和了解已有的软件工程过程,以及过程中产生的资产,包括文档、代码、测试用例等等,以便更好地利用这些资产,并将其与 LLM 进行结合,进而来提升研发效率。

在这个阶段,我们采用了经典的用户旅程分析方法:

上图中,包含了五个要素:

  1. 工序化。即理想情况下,API 设计的全生命周期的过程应该是怎样的?
  2. 工艺现状。我们的现状现在是怎样的?
  3. 痛点问题。过程中,不同角色的主要痛点是什么?
  4. 工艺改进。如何针对于上述的痛点进行改进?
  5. 资产沉淀。过程中会产生哪些关键产出(软件工程资产)?

随后,围绕于我们产出的软件工程资产,便可以进行 LLM 微调试点与探索。

在我们的 LLM 赋能的 API 全生命周期里,我们定义的四个关键资产是:API 规范和结构、软件需求(用户故事)、领域模型、API specs。

步骤 2:针对资产的 “语言建模”(格式化输出)

由于大语言模型本身是文本,所以我们需要对现有的架构资产进行 “语言建模”,简单来说就是将文本结构化,转变为特定的、易于阅读和解析的格式,即领域特定语言(DSL),诸如于 markdown 表格、UML 等。

在同一个场景之下,我们预期 LLM 能返回固定格式的数据,方便我们结合到工具中。尽管没有可信的来源证明: OpenAI 在语料阶段使用 markdown 作为数据,但是从经常性输出 markdown 的结构和 ChatGPT 的渲染来看,markdown 是其中一种 LLM 友好的格式。如:

  • 文本生成模型场景下,PlantUML 是最友好的格式之一
  • 生成 API 场景下,markdown 是最友好的格式之一

随后,我们定义了 API 的 “语言模型”:

与普通的 markdown 表格差别并大。只是呢,我们在 request、response、error response 中使用了类 json 的格式表示。

这里还有一个关键点是,编写一个针对于该格式的校验器,一旦出错可以重来,以提升数据质量、降低出错率等。

步骤 3:MVP 微调试验

在训练之前,我们需要准备一些数据,对于现有的 LLM,我们通常采用如下的:instruction、input、output 的结构方式,并由人或者现有的 AI API 来辅导我们进行数据准备。

出自《A Survey of Large Language Models》

在进行 MVP 阶段数据处理时,可以考虑多种方式结合:

  • 常规双向匹配。
  • 数据蒸馏。即将大型真实数据集(训练集)作为输入,并输出一个小的合成蒸馏数据集。
  • 反向生成。即基于目标 output 文本生成潜在的 input,以作为数量级。

如下是我们根据 Swagger、Postman 创建数据集的过程:

微调通常不是一次就能完成的,我们需要结合 self-instruct 的模式构建一些通用的指令、prompt。不过,考虑到大部分公司都有 AI 专家能更好地帮助解决这个问题。

步骤 4:设计增量引导指标

为了评估微调、训练的结果,我们需要构建一个增量引导的指标。而在 AI 编程领域,OpenAI 开源的 HumanEval 数据集提供了一个非常好的示例。

HumanEval 通过单元测试自动评估代码示例的正确性。包含了 164 个带有单元测试的原始编程问题的数据集。以用于评估语言理解力、算法和简单的数学,其中一些可与简单的软件面试问题相媲美。

在某种程度上也作为了其它 AI 在语言模型的标准,CodeGen、CodeGeeX 也采用它来进行评估。如下是 CodeGeeX 的评估结果示例:

对于 API 来说,我们同样也正在设计相似类似的方式来构建。如下是我们微调完的 RESTful API 示例:

这里还有几个问题要考虑:

  1. 如何有效验证结果是否正确?如 RESTful API 是易于验证的,但是 CRUD 是否合理如何验证呢?
  2. 数量级的全面性如何保证?
  3. 是否只针对特定领域编写?

尽管指标可以作为一种评价工作或项目进展的方法,但过度依赖指标可能产生指标驱动的风险。但是,我们可以通过构建基于反馈的平台工程,来优化并解决这个问题。

步骤 5:LLM 体验设计与工具集成

在构建了第一个 MVP 之时,我们也在探索如何与工具结合在一起。如在我们的场景之下,采用的是 IDE 插件,便需要开发 IDE 插件来实现。

而针对于 IDE 来说,其过程比较简单,如下图所示:

虽然语法分析难度虽然高了一点点,但是并不是主要的挑战。主要的挑战是,如何去进行交互设计。

如在 GitHub Copilot 的插件便有非常好的体验,支持多种不同交互(快捷键、Inlay、工具栏等)、Code Completion 模式等。在编辑模式内,通过 Intellij IDEA 自带的 InlayModel,可以支持:Inline,AfterLine,Block 三种不同的模式。

考虑到,过往我们已经有了大量的体验设计经验,由于需要注意的点是:AI 时代是否有更好的交互方式

步骤 6:基于反馈的平台工程

与常规应用的度量不同,对于 AI 产品来说,我们需要非常、非常、非常关注于用户对结果的反馈,并持续收集这些数据:接受、不接受、改进后的版本(按需)。

与 ChatGPT 不实用的 Like、Dislike 相比,针对于软件资产来说,企业更容易获得改进后的版本,如对于需求的进一步完善。

以代码为例,在 AI 编程工具里,当用户 accept 或者 reject 代码之后,我们就可以记录下这些信息。同时,如果用户对代码进行改动,我们还能将其作为后续训练的数据集。

因此,在我们构建端到端的工具时,需要设计好内部的平台工程,强化反馈回路,以使我们的 AI 更加智能。

总结

利用大语言模型技术,能帮助我们汲取来自不同领域的优秀 API 设计经验和方法,同时融合研发组织自身的经验和实践,以及主流的 API 规范。这有助于提高架构中的 API 设计效率和质量,从而增强整体架构的服务能力和开放性。而具体的提升效果如何,以及引入LLM增强的架构治理方式及路径是否会有所变化,还需要更多的实际应用场景来进一步验证。我们也会在 ArchGuard 架构治理平台中,持续嵌入相应的指标和实践,欢迎大家关注:https://github.com/archguard/

参考资料:

  • CodeGen: An Open Large Language Model for Code with Multi-Turn Program Synthesis
  • Evaluating Large Language Models Trained on Code》
  • A Survey of Large Language Models》

关于我

Github: @phodal     微博:@phodal     知乎:@phodal    

微信公众号(Phodal)

围观我的Github Idea墙, 也许,你会遇到心仪的项目

QQ技术交流群: 321689806
comment

Feeds

RSS / Atom

最近文章

关于作者

Phodal Huang

Engineer, Consultant, Writer, Designer

ThoughtWorks 技术专家

工程师 / 咨询师 / 作家 / 设计学徒

开源深度爱好者

出版有《前端架构:从入门到微前端》、《自己动手设计物联网》、《全栈应用开发:精益实践》

联系我: h@phodal.com

微信公众号: 最新技术分享

标签