垂直行业的语言大模型思考 (上)

风投Greylock合伙人对OpenAI CEO Sam Altam专访中提问，“提供这种语言大模型API服务给用户使用，你觉得这些API和商业使用之间缺少什么关键的东西”， Sam Altam回答，“目前是商业用户直接使用大模型API服务，未来会有中间层将这种语言大模型进行调整，不是简单调参，做行业适配，以便支持行业的各种应用，中间层的模型是具有长久价值的，而那些初创公司做大模型并不会持久”。

垂直行业领域的语言大模型是指专注于特定领域的语言模型，例如医学、法律、金融、科技等领域，与通用领域的语言大模型相比，垂直行业领域的语言大模型更加专业化，可以更好地适应不同领域的需求，领域逐渐细分化将有助于提高模型的专业性和精准度，同时，预训练和微调是大语言模型发展中的关键技术，预训练可以通过提高模型的泛化能力来提高性能，这需要行业内大数据的支撑，而微调可以通过适应特定领域的数据来提高模型的专业性和准确度，领域的细化也有助于硬件算力的分散以及管理的分散，从而可以摆脱对于通用语言模型的算力依赖而造成瓶颈的麻烦。

0x00 架构思考

这是基于上述行业语言模型思考而设计的整体架构图，着眼四个部分，最上层是OpenAI的能力，这是借助OpenAI接口来提升自己行业领域语言模型能力的一个重要依赖。最下面一层就是来自我们的客户端应用，这里我们把应用的场景考虑的更广泛一些，应用可能来自多个客户的多个应用，包括PC端、原生APP、Web端等，可以通过HTTP协议、Messaging协议、MQTT协议等，我们思考的场景，就是怎么通过语言模型的能力来提升这些产品的用户粘性。
中间的两层是我们核心要建设的内容，我把这两层定义为「GPT服务」和「NLP服务」，从微服务角度，这两个微服务提供对外接口。「GPT服务」要做的事情，主要是转发来自终端应用的请求到OpenAI服务，以及一些相关的计费、统计等服务，大致包括

• proxy：代理转发服务到OpenAI「核心能力，涉及到分布式部署」
• auth：验证来自客户端访问的合法性「来自多个客户端多个应用，可能有收费服务，要进行鉴权」
• analysis：统计客户端请求，计费等

该服务需要保证可以正常访问OpenAI官方「OpenAI的GPT服务目前部署在微软的Azure云服务上」。
「NLP服务」要做的事情，是基于企业的实际需要，在本地部署的一套自己的语言模型，具体包括

• fine-tuned：本地语言模型，包含企业知识库，以及实时数据等「数据来自企业收集」，设计「accuracy」，判断回答问题的准确性，从而决定是否要转发到OpenAI
• training：预训练，生成fine-turned模型，数据来自企业的客户端，以及OpenAI对话

0x01 场景思考

我们假设这个垂直行业领域是旅游业，旅游线上服务的场景，然后我们定义产品，类似ChatGPT语言模型的价值，是通过人工智能技术，创造更好的交互体验，通过智能让平台更懂用户，了解用户需求、增强用户参与感、提升用户忠诚度，在用户与产品交互过程中打造更高的用户体验，这些是语言模型可以创造价值的地方，我们把客户端产品定义为一款「智能客服」，目的是借助语言模型，提升这个智能客服的服务能力。

描述整个过程：参照上面的架构设计，在最底层终端用户场景，通过在APP上提出问题，这个过程类似我们常用的聊天应用，然后请求转到「NLP服务」，在「NLP服务」中沉淀了大量的旅游相关的数据以及旅游行业的语言模型，比如，在什么样的季节去哪里玩最佳，基于LBS的选择是什么等等，通过大量数据训练，本地模型会给出答案，答案的精准度设定一个阀值，比如这个阀值是0.8，当本地模型的回答精准度可以做到大于0.8时，就由本地模型处理用户问题返回答案给到用户，当本地模型的精准度达不到0.8时，请求会转发给「GPT服务」，「GPT服务」把这个请求发给OpenAI处理，返回的结果再返回给用户，同时可以通过用户行为跟踪，判断用户对这个结果的满意程度，如果用户非常满意，那么这个「GPT服务」返回的结果会记录到本地作为训练数据，本地的「NLP服务」进行新一轮的训练，如此不断循环，从而提高模型的精准度。

0x02 客户端代码实践

对于智能客服这个应用客户端的开发，我们通过微信小程序实现「仅为技术可行性验证的方便，微信的生态比较封闭，并不建议企业对微信小程序有太大依赖」，UX的效果大致如下图所示。

技术方面，为了快速的完成验证，采用Taro以及Taro UI组件库，通信方式采用socket，大约300行代码就可以搞定，按照腾讯开放平台规范发布这个微信小程序，这里不过多赘述。

0x03 GPT服务代码实践

上面的架构设计中，「GPT服务」包含三部分，其中核心服务是来自客户端请求的转发，我们根据OpenAI文档，可以采用多种语言来实现，甚至可以使用shell脚本完成，既可以通过官方SDK，也可以自己封装HTTP请求，这里以Node JS为例实现转发，OPENAI_API_KEY就是OpenAI官方给定的访问Token，这里需要注意的，请求头部要把超时的限制尽量设置大一些。

对于鉴权的设计，可以简单使用JWT完成，每个客户端一个kid，客户端与「GPT服务」中间件都使用相同的secret key，来自客户端的请求在加密后放到Bearer请求中，在「GPT服务」的中间件中拦截并解密请求，验证请求的合法性，同时可以判断来自哪个客户端，相应的可以做统计等服务，这些服务并不是这里要讲的重点，略过。再接下来的事情，就是把这个服务打包成容器镜像，发布到服务器，如果有成熟的DevOps环境，这个服务从写代码到发布大约2个小时内就可以搞定上线，这里不再赘述。

上面大致介绍了「GPT服务」的内容，「GPT服务」与「NLP服务」如何协作，我们设计了在线配置，如下图所示。

到这里我们可以看出，其实要做的重点就是「NLP服务」，怎么建设好本地这个语言模型是终极任务，对OpenAI的依赖越大，则说明本地NLP服务价值越小，目标就是提升本地语言模型服务能力，直到最终甚至可以不再依靠OpenAI的能力，「GPT服务」不过是我们提高本地模型服务的一个辅助手段，关于「NLP服务」放到下一篇文章中做介绍，内容会包括典型语言模型的技术、开源的一些解决方案，以及开发本地语言模型的思考。