前言

大模型带来的变革持续发酵，除了在大模型效果方向的如火如荼，其周边领域的发展，也成逐步爆发之势。 当前整个大模型的发展方向可以按"穷" "富"进行划分。 "富" 的方向呢，说的主要是搞大、搞好(模型搞大、效果搞好)。 那么"穷"的方向呢？ "穷"的方向主要是在 LLM 的基础上，构建工具、产品、应用。

关于搞大、搞好，前段时间微软出了一篇 State of GPT 的演讲。 详细的阐述了 Training 的 Pipeline，以及大概的成本。 可见从预训练基础模型，到微调、RM、RLHF 是一个漫长且需多金的过程。 而且这个过程中对算力、数据、人才、基础设施的要求都是很高的。

在模型效果这条路上，最近开源社区也非常热闹，尤其是羊驼系列以及 GLM 系列模型的开源，同时随着 LoRA、量化、QLoRA 等微调算法的加持，让更多的同学、组织也加入到了微调这条道路中。当然了，物极必反，最近也确实看到了很多不太有意义的现象，最近很多同学拿着不足上万条语料，一两台消费显卡。就开始加入到了 SFT 的大军。 学习的心态是好的，但学完之后记得关电，毕竟夏天来了，电力的压力也挺大的，让电力系统也歇歇。

另一条"穷"的路线，构建工具跟应用，就是更多同学可以参与进来的了。 而且这个方向现在是想法跟想象力为主导。 最近社区出现了非常多有意思的项目。 但就大模型应用工具来说，无疑最成功当属 HuggingFace 与 LangChain 了。 当然除此之外，像 AutoGPT、gpt-enginner 等等一众项目也火速赢得了社区的广泛认可跟关注。 此外，在产品跟应用层面，基于 ChatGPT 与 GPT-4 的应用也呈现出爆发的状态。 这其中最著名的，或者说场景落地效果最显著的，应该是知识库这个领域的应用。比如 Chat2PDF、Chat2Excel、Chat2Data、Chat2Everything。 除此之外，也有很多在 Private 这个方向的探索。 比如 DB-GPT、PrivateGPT、LocalGPT、H2oGPT 等等。

与"富"这条路，钱有多多，路有多远不同。 "穷"的这条路是想象力有多大，路就有多宽。 所以呢？ How do you thinking? What are you doing?

AGI 时代存在垂域 LLM 吗？

大模型出现之后，关于垂域 LLM 出现了很大的争议，一部分人认为随着大模型的能力越来越强，垂类的知识会加训融合到大模型。 尤其当下，在 GPT-4 效果一枝独秀的前提下，其他无论是通用模型，还是基于垂类模型都被 GPT-4 吊打，一个典型的对比就是 GPT-4 的代码能力比 CodeX 还要出色，让支持这种观点的声音也越来越多。另一种声音则认为垂类模型必然存在，也是具体落地到业务场景尤其是 ToB 业务场景时，必然的选择。 社区不断放出来的 DB-GPT、CodeGPT、LawGPT、FinGPT 等项目。当然，还有第三种声音，一定要非此即彼吗？ 两者融合会怎样？ 是的，第三种声音我个人倾向于用融合。 我们最近在 DB-GPT 项目的开发、测试、验证过程中，体会到了 BaseModel 的重要性。 在 DB-GPT 项目中，我们是在基于开源的大模型，培养一个数据库领域专家。 在这个过程中，我们也尝试了众多模型，深刻的领悟到了什么是"教不会的笨学生"。 同样的知识体系，同样的教学手段，这教出来的差距咋这么大呢？

在一番痛彻心扉之后，我们不得不选择 Vicuna-13b，当然基于 Vicuna-13b 我们确实也取得了不错的效果。 所以说，垂直领域 BaseModel 同样很重要，底座很重要。

为什么说底座很重要，其实我之前也有在知乎上做过回答，垂直领域或者说纵深领域，一般都是建立在通识知识之上的， 就拿数据库这个领域来讲。 你要具备很好的算法、编程、系统等等各方面的知识才能够学习这个专业纵深领域，否则基本的通识知识跟原理都不懂，普通的代码结构与逻辑都理不顺，又如何在这个领域有所深度呢？就好比说一个学生如果连本科阶段的知识都没有学，就直接跨入到研究生阶段，那必然学起来很吃力，是很难学会的。如果说有一种手段，可以跳过本科教育培养的理解力，直接学习研究生的课程，那也多半是靠死记硬背。 不幸的是，道理我们都懂。但大模型微调这条路上，还是有茫茫多的团队，在"死记硬背"这条路上，向前狂奔。

以上呢是技术层面的， 那么在大模型落地过程中，还有哪些其他层面的问题呢？ 我们不妨在回顾一下大模型发展的几个重要的因素。合规、数据、算力、工程、算法。 这里我把合规跟数据放在了最前面。 为什么呢？ 大家都知道 LLM 目前主要是 GPT，其生成内容与算法内核不具备明确的解释性，面对范互联网或者数据敏感性相对较低的 ToC 领域，可以具备一定的落地能力了，我们也看到 GPT-4 出现之后，大量的 ToC 的落地场景与应用，有些应用也确实很让人惊喜。 但数据敏感性较高的 ToB 呢？ 尤其数据作为新的生产资料，是一个企业、一个国家核心资产的今天。 ToB 的业务还能用通用大模型吗？

答案肯定是不能的， 无论你模型能力是否够强，都是不能的。因为数据就是一个企业的命脉，是一个行业的命脉，更是一个国家的命脉。试想一下，你会把自己的命脉拱手交给别人吗？ 总不能把？

所以说，垂域 LLM 必然是存在的，且会长在通用 LLM 之上，即将垂域知识融入到一个相对智能的通用 LLM 之上，打造行业/领域的专有模型，并进行私有化部署，是 ToB 业务未来非常重要的一条发展路径。

当前垂域模型之痛

将通用 LLM 与垂域知识融合，在通用 LLM 之上打造垂域大模型这条路无疑是正确的，尤其最近一众模型开源，LLaMA 系列开源模型效果显著变好之后，让越来越多的人开始朝这个方向追逐。 但截至目前来看，现实还是很残酷滴。 开源模型也开始越搞越大，从 ChatGLM-6B、Vicuna-7B，再到 Vicuna-13B，Falcon-40B，Guanaco-65B、ChatGLM-130B, 开源模型也是越搞越大。当然你这大不要紧，但是大了之后，落地的成本怎么解？ 另外，虽然模型是越搞越大了，但是越大的模型，除了算力之外，确实也需要更多的数据。 如果垂域也变成算力跟数据的竞争，那么落地这条路可能又遥遥无期了。 毕竟，技术跟业务之间的矛盾也在逐步爆发，你训不完的模型，我等不起的业务啊。"你们再这么一喂求大一直训下去，我业务可要死给你看了"。当然了，这都不是最重要的，最重要的是什么呢？ 最重要的可能我们确实没必要面对一个垂直领域，去教垂域模型学好自己专业之外的知识。 比如说，我们最近不断的去教 Vicuna-13b 怎么写好一个 Json，稳定输出一个完美的 Json 格式。 最近我们经过一个多月的自我折磨之后，终于痛彻心扉，扇了自己两耳光。 你一个写数据库领域的 LLM，为什么一定要求它写好 JSON 呢？ 写 JSON 这件事情交给更专业的 ChatGPT 不好吗？ 放下这个执念之后， 我们顿时感觉打开了一扇新的大门，原来事情还可以变得这么美好。 原来让 ChatGPT 写 JSON，我们就不用天天熬夜到 24 点后了，原来 23 点的天是那么的繁星闪耀。

我们经历了以上痛苦之后，终于结合成本、隐私、效果想出一个不那么完美，但是可以私有化落地方案。 下面我们结合在 DB-GPT 中的一个应用场景，来介绍一下垂域模型的应用实践。

DB-GPT 垂域模型应用实践

在这里，我们就以 Text2SQL 这个场景来介绍应用实践。 具体的任务如下：

有一个 BI 分析的任务，需要关联 6 张表来进行数据分析，当前的数据库中有 1000+表。

当前 LLM 处理这个任务时，有两个大的难点。 1. LLM 当前不具备 6 张表关联如此复杂的 SQL 编写能力。 2. 受限与 Token 长度，我们无法直接将所有的表信息提供给模型来生成正确的 SQL 语句。 基于大模型当前的能力，我们通过系统架构优化的方式，对此问题进行了解决， 首先我们看看整体的架构图。

这里我们用到了几个比较关键的技术思路。 1. Summary + Embedding 2. 大帮小 3. CoT+ToT(复杂任务拆步解)

Summary + EmbeddingSummary + Embedding 这一步相信大家已经比较熟悉了， 如果有不了解的可以看一下之前我发的一篇简单介绍实战的文章。https://zhuanlan.zhihu.com/p/628750042

Summary+Embedding

这一步实际就是对元数据进行向量化，以供后续大模型使用。那为什么要进行 Summary 呢？ 直接查询元数据丢给大模型行不行？ 实践证明是不行的， 在实际用户使用过程中，一张用户详情表，会命名为 udtail, 这你让大模型怎么认嘛？ 命名的人你自己认不认得到吗？ 在实际落地中有大量诸如的问题，所以我们要对元数据进行 Summary，其目的是让模型知道 udtail 这个命名是用户详情表。 除此之外，生产环境一般会有数百上千万的表，将这些表一股脑都丢给大模型，显然是不现实，也不可能。 所以我们要做 Embedding。在 DB-GPT 中，我们也设计了第一个简易版本的 Summary 脚手架。代码如下：

class DBSummary:    def __init__(self, name):        self.name = name        self.summery = None        self.tables = []        self.metadata = str
    def get_summery(self):        return self.summery

class TableSummary:    def __init__(self, name):        self.name = name        self.summery = None        self.fields = []        self.indexes = []

class FieldSummary:    def __init__(self, name):        self.name = name        self.summery = None        self.data_type = None

class IndexSummary:    def __init__(self, name):        self.name = name        self.summery = None        self.bind_fields = []

通过对库、表、字段、索引进行简要的 Summary，我们即可做到让大模型理解我们的元数据，理解我们的业务语义。

大帮小

再说到大帮小， 大帮小其实指的是大模型帮小模型，更具体一点。就是通过 ChatGPT/GPT-4、通义千文，文心一言这样更大的模型，来辅助私有化部署的百亿级模型来完成任务。 在我们写 SQL 这个案例当中，一个关联 6 张表的查询小模型是非常难理解的，因此我们会根据 Query + Summary 的内容让大模型先完成语义提取。 将复杂问题的理解，格式化输出一个固定的 ToT 的模版内容，将复杂的任务拆解为几个独立的简单步骤。

在此之后，我们将每个小步的任务丢给小模型去处理。 当然在这个环节，我们为了更稳定的效果，还需要跟大模型完成一些交互。 比如在 DB-GPT 当中，我们发现 Vicuna-13b 在格式化输出 Json 时，准确率跟稳定性都比较差，正确率不到 70%，这需要我们编写大量的代码来处理格式。 以如下格式为例，但当我们调用 GPT-4 来格式化时，准确率跟稳定性能达到 95%以上。

RESPONSE_FORMAT = {  "thoughts": {    "reasoning": "reasoning",    "speak": "thoughts summary to say to user",  },  "sql": "SQL Query to run",}JSON

因为是一个多步拆分任务，所以模型执行的中间结果，我们会暂存在一个中间态。 最后在通过链式计算来返回最终正确的结果。

CoT/ToT

思维链以及思维树，已经是业界非常流行的方案了。 尤其在插件使用上，思维链模型应用非常广泛，其中 Auto-GPT 整个推理过程就大量使用了思维链进行反复推理，来生成最终正确的结果。 同样在我们的方案中，也不例外。 但不同的是，在私有化模型下，反复推理的成本跟模型稳定性，目前表现还不那么令人满意，为了节约成本增加稳定性，我们在 ToT 环节里面，加入了 ChatGPT/GPT-4 来做正确性论证的能力。

以上即为我们综合考虑成本、隐私、效果制定的一个折中方案。 核心数据资产通过本地化 Embedding 模型，Summary 之后存储在私有向量数据中。 用户复杂的问题通过 DB-GPT Proxy 转接给中心化大模型做语义识别与任务拆解。 拆解完成的小任务，通过 DB-GPT 中的私有化大模型完成具体的任务执行。 最后结果通过思维链/思维树的路径进行多轮验证来确保得到准确的结果。 在这个过程中，用户数据与跟用户环境交互的模型都是本地化的。但是在任务拆解、格式化输出等方面，我们为了提供准确率同时降低推理成本，将这部分任务拆解给了 ChatGPT/GPT-4 这样的 API 来完成。 当然这并不是一个完美的方案，我们也在不断的探索大模型私有化落地的各种可能，感兴趣的话可以持续关注我们项目，也非常欢迎跟我们交流。

垂域模型发展之路

相较与通用模型，垂域模型在合规、数据、算力、工程、算法方面遇到的挑战更大。 为何如此说呢？通用模型发展到今天，基本可以定义为巨头们的生意。 而巨头们在数据、算力、工程、算法等方面都有很深的积累。 而通用大模型的训练数据，一般都是互联网公开的数据，所以在合规方面的挑战也不像垂域大模型。

在垂直领域，算力、工程包括算法，主要需要解决的是成本问题。 毕竟如若一个垂域模型需要大几百万的部署推理成本，那也很难有落地的可行性。

另一方面合规与数据是制约垂域模型发展最重要的因素。 垂域的数据是非常重要的资产，所以收集数据做 Training 的复杂度巨高。 单一企业或者组织的数据，受限与数据规模与质量，很难独立完成训练。 所以数据流通、数据价值交换与确权的诉求，会随着垂域模型的发展越来也大。 像隐私计算、区块链这样的技术，需要面对大模型时代的需求，继续做更多深入场景与领域的探索。 面向未来，区块链、隐私这些技术，更好的定位可能是服务与 AI。

面对垂域模型发展过程中的挑战，需要做更多的基础设施建设，打通垂域模型发展之路，才能更好助力业务落地。这方面腾讯已经发布了行业大模型的发展思路，算是开了个好头，后续期望更多的企业也能够参与共建基础设施。

小结

大模型的发展浪潮刚刚开始，面向垂域的大模型也才刚刚起步。 大模型作为新一轮的技术革命，一定会重构各行各业。 因此垂域大模型的发展也势必会随着业务与时代的诉求，逐步加速。未来已来，让我们试目以待吧。

参考

• StateOfGPT
  

• TreeOfThoughts
  

• ChainOfThouthts
  

• DB-GPT