电商网站的模块,哪些网站可以接点私活做的,嘉兴南湖区建设局网站,黄页污水这是两篇面向LLM的大前端架构的第一篇#xff0c;主要写我对LLM业务的认知以及由此推演出的大前端架构。由于我是客户端出身#xff0c;所以主要以客户端角度来描述#xff0c;并不影响对前端的适用性。
对LLM的认知
基于Google对AGI的论文#xff0c;AGI或者LLM一定会朝…这是两篇面向LLM的大前端架构的第一篇主要写我对LLM业务的认知以及由此推演出的大前端架构。由于我是客户端出身所以主要以客户端角度来描述并不影响对前端的适用性。
对LLM的认知
基于Google对AGI的论文AGI或者LLM一定会朝着在决策过程中越来越重要的方向发展。任务过程可以简单抽象为目标设定、信息收集、任务拆分、retro、执行。目前成型的LLM应用主要还是在任务过程的某几个点作为最叶子的工具存在的后续一定会向着主导完整过程的方向走。 曾经有个大佬说过LLM是对世界的压缩。还有另一个大佬说过语言可以完整描述世界。那么逻辑上LLM在足够强的提示词/过程工具的加持下是足够仅靠语言来接受所有世界信息并利用语言反作用于世界的。而仅仅把LLM当做AIGC的手段来用多少有点暴殄天物了。 最近也开始有LVMLarge 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作为中心大脑来完成一个任务成为流量分发核心所有其他作为agentUGL的真实落地下一代互联网的真正到来。 为此App会形成几种突出的能力
for LLMLUI、端智能、动态化、特殊的编辑器for 分发三方业务容器、微服务化for UGL低码/流程编排
背景碎碎念
大概率这是两篇没实际意义的文章一方面我并没有供职于一个能生长出这种业务形态的公司另一方面大前端真的还有架构吗还有我已经快35了…不过出于一种强烈的FOMO感我还是要记录一下万一呢。
