前言
我们前面讲了很多大模型应用的功能模块，也讲了很多范式。但是在生产环境中，我们到底要如何来做一个完整的，通用的，能够不断优化迭代的，全局视角的架构设计。
架构图
其实之前的文章有涉及到，整个大模型应用系统分为三层（应用层，服务层，模型层），并且从不同场景，不同范式做了一些分析。详见：# 大模型应用（三）agent/copilot最佳实践，模型到应用之间的距离
所以本文不bb原因，直接上架构：
- 应用层：需要接入大模型能力的应用都属于应用层。
- 服务层：提供能力的这一层。
- core：核心应用：像 agent，workflow，cot这些原子功能都属于核心应用。
- scene：场景：可以理解基于核心的这些原子能力搭建出来的，更定制化，更靠近应用的功能服务。
- baas：将能力以api的形式开放出去，并且提供工程化的能力。
- webui：将这些能力以界面的形式提供给用户使用，并且也要提供相关功能，比如debug调试，流程搭建，评测等。这里把应用市场也放在这里了，这个功能是可以单独拆出来的。
- 基座模型：提供数据清洗，模型训练，微调等功能。
最佳实践
1. 为什么原子功能看起来并不原子？他们之间的关系是对等的吗？
在功能图上，我把核心功能都作为原子功能划分在一起，这代表它们一定是对等的，但不一定是原子的。
举个例子：一个agent是可以挂载workflow的，而workflow也是可以包含agent的，所以地位对等。而一个agent或者workflow或者cot这种功能，会包含多个其他功能，所以并不一定原子。
之所以说是原子功能，主要是从应用角度讲，功能不可再分。
2. 为什么对外提供的服务是baas？
这主要是从当前市场来看，最终有能力提供大模型能力的公司注定只有少数的几家，更多的企业会聚焦于应用层。所以对于一个大模型应用平台来讲，以baas的方式 提供lm能力，应用能力是比较合理的。
当然，实际还是要根据你的场景来。比如现在比较流行的端云协同方案，更多的是 Agent SDK + SLM + CloudService的模式。
3. scene为什么放在服务这一层，不放在应用层。
其实放在应用里也是可以，只是这会增加应用的复杂度。
我们在第一版平台实现的时候，给应用提供的就是 原子功能+流程编排，看起来解决了全部的问题，又保持了开放。但是这会导致应用接入难度非常高，类似的业务会重复搭建类似的流程。
所以在开放性和易用性中间保持平衡十分重要。提供相对开放的场景功能是十分有必要的。
4. lmOps下沉的重要性。
不建议将lmOps的功能集成到服务层里，防止有些人手贱，天天微调，成本hold不住。
服务层的定位是为应用服务的，而不是为模型层服务的。自研模型太垃圾，直接换友商聪明的模型，而不是在垃圾模型上死磕微调。和垃圾做隔离是多么的重要（手动狗头）；
5. 做场景还是做范式？
都要做，但场景更重要。
如果你在纠结，给应用提供通用的范式比较好，还是为他做特殊场景好，那你就直接做场景吧，场景做多了自然就会做范式了。
6. 产品不提需求，我要如何推动架构的落地？
现在大模型应用算是比较新的方向，几乎所有的产品都在围绕着应用在做事情，他是不会提出分层架构的概念的。
对此我只能说，如果你在司内地位比较高，那就强推落地。如果你只是个大头兵，就尽量分模块，从应用往下做，慢慢沉淀。然后默念S-B-P-D。
你还会发现，在这个方向，大部分的时候，产品的想象力是不够的，能力也不够。甚至八成的产品不知道怎么做评测，不知道看哪些指标，不知道哪些AI的亮点。这时候，就需要你反推产品，拉着他们往前走。
我们之前有很多图像处理的需要（生图，消除这种），但是产品不会用stable diffusion，思想还停留在老掉牙的技术上，然后被我们强推SD，最后首屏转化率增加了十几个点。
7. 服务层功能太多了，不知道如何落地实现？如何做技术架构？
我这里简单做了一个通用的技术架构，仅供参考。
- 这是一个相对比功能较完整的设计，现实中你可能并不需要全部功能，还是要因地制宜，不要生搬硬套。
- 这个设计几乎能够百分百cover关于智能体和大模型应用的需求。是俺一步一坑实践出来的。
8. 太多了，以后再写。
尾语
正所谓志同道合，和小伙伴们统一理论才能更好前进。
如果你对这个架构有不同的看法，欢迎留言讨论。
