大语言模型应用的业务架构点
背景
在国内某小龙干了一段时间了，困于时间、资本、人力等等原因，其实应用在工程侧的业务架构建模并没有做好。但是，随着业务迭代和读论文，对于大语言模型的应用（自认为）有一定的认知了，那么业务建模或者架构的重点是可以梳理一下的了。主要关注业务逻辑和前端的架构（我负责的部分）。
整体认知
- 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的选取和推荐。根据用户反馈、任务相似度、用户相似度做例子的选取（面向模型的推荐系统），以期大幅提高模型回答满意度。
- 部分模型层的插拔。以按照用户喜好切换输出模式（面向用户的推荐系统）。