面向LLM的App架构——业务维度

2023-12-13 17:34:01

这是两篇面向LLM的大前端架构的第一篇,主要写我对LLM业务的认知以及由此推演出的大前端架构。由于我是客户端出身,所以主要以客户端角度来描述,并不影响对前端的适用性。

对LLM的认知

基于Google对AGI的论文,AGI或者LLM一定会朝着在决策过程中越来越重要的方向发展。任务过程可以简单抽象为目标设定、信息收集、任务拆分、retro、执行。目前成型的LLM应用,主要还是在任务过程的某几个点作为最叶子的工具存在的,后续一定会向着主导完整过程的方向走。
曾经有个大佬说过,LLM是对世界的压缩。还有另一个大佬说过,语言可以完整描述世界。那么逻辑上,LLM在足够强的提示词/过程工具的加持下,是足够仅靠语言来接受所有世界信息,并利用语言反作用于世界的。而仅仅把LLM当做AIGC的手段来用,多少有点暴殄天物了。
最近也开始有LVM(Large Vision Model)等直接多模态的模型,但是,个人感觉除了图片、音视频之外,可能并不会再有其他多模态的模型了,而且LVM也会想办法融合到LLM而不是独立提供服务。原因是文字是最大量存在的数据源,其他在信息量维度都是数量级的小于文字的,而且有效的表达力并不会超过文字太多。刚写完就被打脸,gemini就是硬靠有钱把图片、音视频和文本做了个真多模态,有钱真好。
LLM成本非常高,如果所有层级的信息都放给唯一大模型迟早破产,而且是不可能变好的那种,除非是顶级烧钱大厂(如头条)。
综上,LLM会大概率会成为一个计划、调度和整合的大脑,其他都是工具,人会作为纠错工具存在。

App的定位

由上面对LLM的认知,我猜App会有几个维度的变化:1. 继续以流量分发为基本逻辑,但这时分发的不仅是内容,更是逻辑;2. 充分利用设备能力,为LLM的信息收集服务;3. 极端低码,让UGL(用户生产逻辑)变成必有功能。
这里多说一嘴UGL,我自己瞎取的名字,但是是我认为的web3.0该有的含义。web1.0平台生产内容和逻辑;web2.0用户生产内容,平台只负责逻辑和内容生产工具;web3.0 应该是用户生产内容和逻辑,平台只负责平台运营和工具搭建。传统的逻辑生产工具其实就是低码和代码,前者很难做出复杂逻辑,后者很难推广。而LLM在两个维度能极大的简化生产过程:逻辑终结点可以以自然语言的形式描述,表达效率极大提升,可以看一下我的(github)[https://github.com/pouloghost/pseudo-gpt];梳理逻辑流程对于麻瓜来说很麻烦,对于LLM来说通过对话把整个流程排布出来就很简单了。而逻辑抽象看其实就是这两个维度,我相当相信UGL会站起来,web3会站起来。
生态角度:头部流量App会进一步占有用户时间。其他功能类App或者垂类分发类App会被弱化成LLM的agent。会有真正的低码平台出现,让用户生产并分享逻辑(GPTs的进阶状态)。

App架构的变化

App定位的变化带来了架构的少量变化和具体能力的大量变化。
整体架构方面仍然可以保持portal-biz-common(有公司语义通用)-foundation(无公司语义通用)四层,且仍然能把业务粗暴的分为分发型和承载/能力型两个类型。
区别是LLM作为最核心的业务是分发型,会强迫让整体围绕着分发来组织,而不是之前非平台类(i.e.支付宝)App的功能、流程来组织。由于大量的路由、微服务的构建,路由(不同公司会放在biz最下或者common最上)会极为庞大,之前解耦带来的Android打包优势会不复存在,可能会像支付宝一样把直接按业务拆出来api-biz两个模块,来提速打包。

App具体能力

LUI

很火的一个词,Language UI。这个其实很简单,与IM逻辑基本一致的长链接+消息列。和普通IM比有几个不同点:

  • 对于接收到的消息是要有完整修改能力的。修改后的内容是需要即时回传的。可能会以一个修改消息上传,也可能直接把assistant消息改了,这个得看模型响应
  • 如果是多媒体内容,是需要有原始数据的(类比PS的psd文件)
  • 由于中间有修改过程,整个聊天的存储是一个树形结构而非链式。进而,有概览整棵树的需求,快速的查找和跳转到节点
  • 提示词模板,大部分非自由聊天的提示词都是模板。把随意输入变成填空,这时候普通的输入框并不靠谱,应该是一个特殊适配的填空输入UI。延伸出来,这里需要一套基于模板的渲染和拼装系统,注意这里要有多模态。见特殊的编辑器。

端智能

又一个很火的词,恰好之前也做过。如果能在端上把LLM的前几层给做了,对于大规模服务来说一定是有明显降本增效效果的。同时,在各种角度看,从多模态向文本转换的过程也都更适合在端上进行,甚至可以在转换后进行人肉纠错的hook。
那么端智能就又有几个核心能力需要在端上建立:

  • 运行时,这个不熟,之前是魔改的TensorFlow-lite
  • 模型本身的同步和下载。稍后资源离线包单独说
  • 模型外围代码的动态化。稍后动态化单独说
  • 推理调度。这个是之前的一个经验,当时的场景是模型并不作为核心业务执行,而是个锦上添花(屎上雕花)的功能,所以一定不能影响UI流畅度。所以需要一个推理调度功能,主要就是一套带优先级的多线程调度系统(Android不难,iOS见鬼)
  • 训练调度。这个应该是普适的,设备上最终一定会开始跑离线数据的训练,哪怕只是利用模型对设备上的局部数据进行压缩。但是这种耗电、耗CPU的任务一定是要偷偷执行的,如果在用户使用时跑一定会被搞。所以会有一套设备使用状况监控(特别是电池)+后台调度的机制,跟推理调度不太一样。

动态化

别的App不做动态化其实无所谓,对接模型的App一定是主要能力动态化的。模型的能力迭代是有两部分组成的:基础模型/ft和prompt。我相信(无实证)大部分应用层都会加上基础prompt,而且会持续迭代场景化的prompt。参见我之前的prompt自动优化,prompt的迭代会是超乎想象的快。
那么对接提示词的客户端功能,不论是简单展示(见LUI),承接页还是感知能力,都是需要极为动态的,覆盖率方面能够跟得上prompt迭代(至少是不构成限制prompt迭代的阻碍,也不会因为版本兼容带来大量的accidental complexity)。
这里的动态化与旧有的RN、lynx不一样,需要更加关注的是动态提供平台能力和计算能力,相机、GPU、传感器等等,让逻辑动态化,而非让UI动态化,也不非常关心跨端一致。可能会比较接近hummer的实现原理。
当然动态化也会有离线包的一系列问题,统一到资源离线包说。

三方业务容器

本文的逻辑是利用LLM做AGI,信息收集和执行两步都是有强分发属性的,这时候不做三方业务就太浪费流量了。想象一下,如果LLM流量入口对话找吃的,只会找到饿了么的数据,美团是否会哭死(新时代的SEO),能不能在流量入口的信息源和落地页中可能是变现业务的关键点。
那么,像小程序、BFF一样的三方业务容器或者对接方案就一定是必不可少的。这里包括了前后端。
而大前端让三方业务顺利承接流量的就是小程序,当然也能是其他技术,但必须有以下几个特征:

  • 加载性能足够好,排除原始的webview
  • 动态化,如果能想办法和上面的内部业务动态化整合也是极好的
  • 稳定性隔离,不能三方业务导致本App crash
  • 资源隔离,完整的信息安全沙盒
  • 能力支持,提供足够多的设备能力访问。这个讲道理应该和下面的微服务化整合到一起,在foundation甚至common层的能力都自动port出来

微服务化

或者说超级路由、客户端中台化,即所有业务都是组件、所有业务都可以被直接拉起。这里非常契合原教旨中台的定义,只不过这些能力不是为了让人类业务方来编排出新业务,而是为了让LLM有足够的agent可以调用。但是,这些能力一定还是有非LUI的入口可以进入的。
所以最大的挑战是对齐和管理三种调用方式的接口:端内代码强类型直接调用、跨端序列化调用和LLM agent声明调用。前两者做过靠谱的路由框架应该都知道咋做,第三个是新东西,不太能想到除了人肉维护或者LLM label的其他手段。试过GPT-4做代码label,效果还行。
还有一个和动态化一样差异。这里的服务同时包含了页面跳转和方法调用,甚至在环境感知维度更强调方法调用。
另外还有一个与普通路由相去甚远的变化:需要能唤醒其他App。大概逻辑是本地获取所有已安装App,发给服务端,服务端会根据版本号和数据库识别出所有可以调用的三方App,也作为agent的一部分灌给LLM。

资源离线

本来这是一个并没有很重要的能力。但是在LLM下,资源离线的使用场景非常广,值得单独强调一下。
标准的文件同步系统,需要关注:文件对外接口定义(毕竟大部分资源都是可执行模块)、兼容性、文件本身版本管理、下载、缓存、差量更新等。这里的接口自动抓取和匹配会是重点,因为所有动态化会更倾向于对接能力(方法调用)而不是页面(路由定义),前者的变化频率和兼容性都会比后者差很多。

低码/流程编排

这个之前完全没做过,所以简单查了一下。基本上现在的低码平台都是后端+web的,我坚定认为后面一定也会有App上完整的低码构建平台。因为手机是覆盖率最高设备,随着交互的简化和过程的智能化,小窗口也能做出大逻辑。可以类比剪映之于final cut。
低码这里核心有几个部分:

  • 逻辑表示,如何把编辑好的保存下来,这个有不少服务端的开源/闭源库
  • 版本管理,类似于git,应该开源库能包含类似功能(没细查,反正能序列化,大不了对序列化后的内容做git管理)
  • 画板,用于展示和编辑整个流程,这里的展示方式应该和web不一样,应该更符合总分双屏这种适合小屏的结构
  • 对话和preview,一定会有一个copilot来协助创建低码逻辑,同时快速验证某个逻辑块的正确性
  • 能力节点,把微服务化部分的能力都开放供调用。而且,应该是会有一些UGL会被当做能力节点暴露出来,相对会复杂一些。包括出入参、接口说明、稳定性、兼容性等提供服务的常见问题。
  • 执行,这个一定不发生在客户端,略过

特殊的编辑器

这个专指prompt格式化编辑器,基本可以认为是一个可视化的python f str。单独提出来说是因为这个东西大概会形成一个类似于markdown/富文本编辑器的一个面向LLM的文档标准,再叠加上合适的前后端服务。

总结

我认为的业务两个突出变化:LLM作为中心大脑来完成一个任务,成为流量分发核心,所有其他作为agent;UGL的真实落地,下一代互联网的真正到来。
为此,App会形成几种突出的能力:

  • for LLM:LUI、端智能、动态化、特殊的编辑器
  • for 分发:三方业务容器、微服务化
  • for UGL:低码/流程编排
背景碎碎念

大概率这是两篇没实际意义的文章,一方面我并没有供职于一个能生长出这种业务形态的公司;另一方面大前端真的还有架构吗?还有,我已经快35了…不过出于一种强烈的FOMO感,我还是要记录一下,万一呢。

文章来源:https://blog.csdn.net/pouloghost/article/details/134785811
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。