大语言模型应用的业务架构点
背景
在国内某小龙干了一段时间了,困于时间、资本、人力等等原因,其实应用在工程侧的业务架构建模并没有做好。但是,随着业务迭代和读论文,对于大语言模型的应用(自认为)有一定的认知了,那么业务建模或者架构的重点是可以梳理一下的了。主要关注业务逻辑和前端的架构(我负责的部分)。
整体认知
- AGI不一定是单一模型搞定一切。短期更可能是在多个垂类模型前加一个路由。这个路由可能是意图模型,也可能是MOE的gate。但是,这些都应该反馈到工程侧,形成一定的路径差异。在模型规模/能力远超现在的大小之前,组合小模型会比单一模型的效果好很多;只有要求极强的迁移能力时,单一巨型模型才是合理的。
- 接1,有一些意图是应该让用户主动选择的(豆包等的智能体中心很大一部分是在明确意图而不是选模型能力)。
- 不同形态的问题,执行的逻辑是不一样的,pe的逻辑也是不一样的。
- 输出部分不一定是和模型本体耦合的,而是可以以风格、功能来做特殊训练和插拔的(ChatGPT的json api)。
- 特殊token一定是后面做工程化中极为重要的手段,而且是要求从业务需求角度出发,反向向模型训练数据中插入大量的业务化token。
- 模型的应用开发流程大概是:模式定义->生成对应的数据->ft->测评,跟传统应用开发能对应上:产品定义->技术设计->coding->测试。
PE认知
PE是为了治疗模型的智障。智障来源于问题不清晰、思考不正确、信息不全、迁移和杂糅等。解决问题主要几个路径:
- x-shot这种想办法给例子的。
- COT这种引导模型多思考的,这里会有COT这种单路径的,也有TOT这种多分支的,还有ReAct这种。
- tooling。
- 反思,包括多条的选择(self-consistency)和单条内的修改(reflection)。
- 分而治之,planner类或我的POT bot。
- 整合,包括多种角色的(ChatDev)、多种知识背景的或者只有超参差异的(ER)。
可能出现的非传统流式形态
最传统形态就是模型一个文本流直接展示到端上,只做一些展示上的优化。
- 隐藏模型输出。对于COT、ReAct这些方式,模型输出的很大一部分是思路,这些思路又一定要输出(模型不会思考,只是next token)。所以标记(特殊token)和隐藏这些内容是非常重要的工程能力。
- 结构化思考过程。planner、POT这种,甚至人肉的chain规则,这些都是有可能被以结构化的方式来展示的。这些展示的合理、巧妙能极大的提升产品体验。包括了特殊token、特殊格式的规定和展示;chain的建模(openai assistant api的run-step)。
- 方法调用。这个包括了后端、前端的方法调用。之前文章的微服务部分简单提到过。细化下来,需要有一个双工长信道来做IPC,传统的trunk或者sse其实都不如websocket靠谱(经典面试题,如何设计跨语言的callback)。同样可以适配到run-step的体系下。
- 多流。所有整合类的模式,都需要多流的展示,因为所有这种模式如果只输出整合步骤的内容,首token时间会让产品直接不可用。
- 修改。流的每个部分都是可能被重新生成的(reflection)。需要有一个地方持有当前流内容、每段内容用特殊token标记出来,模型的反思以“将token1之后的内容替换为xxx”的形式输出。这里的替换直接反馈到流本体上。注意这里和隐藏输出会有交错,潜在bug会很多。
关键点
- 意图分流,以及对于意图->推理过程的管理。以及遍布产品形态内部的意图明确方式:比如重新生成时询问意图、生成样式等。意图作为核心context存在于整个产品生命周期中。
- 插件化,两级插件化:特殊token作为纯文本标记,调起特殊逻辑;run-step中的step,直接在流式中打断纯文本行为。
- 流累积和管理,不只是端需要做累积+展示,而是后端需要完整管理模型输出,且可能出现全量replace的情况。
- 双向流。websocket,这里有个不太懂的,是不是一分钟左右的websocket是不是工程上合理的。
- 流式信息样式的极大复杂化。特别是可能会出现各种浮层/子页面+浮层内流式输出的case,毕竟多流直接在正常流式中输出肯定是各种问题的。还要做飞书聊天卡片量级的卡片内样式的横向扩展的设计。
与前端无关的
- x-shot的选取和推荐。根据用户反馈、任务相似度、用户相似度做例子的选取(面向模型的推荐系统),以期大幅提高模型回答满意度。
- 部分模型层的插拔。以按照用户喜好切换输出模式(面向用户的推荐系统)。