随着GPT-3.5在2月底的发布，标志着智能化时代的来临。这个时代为企业带来了前所未有的机遇和挑战。信息系统团队开始研究如何充分利用这一大型AI模型，以解决内部问题并提高工作效率。与此同时，行政部门也高度关注了GPT的潜力。他们与我们一同探讨，是否可以建立一个系统级的客服平台，以应对日常工作中繁琐且重复的沟通问题。在过程中我们留意到，数据应用团队已经建立了私域知识库平台，该平台具备对接大型模型、文本向量转换以及召回等功能。因此，通过和数据应用团队的深入讨论，我们认为可以采用私域知识库的方式来实现基于之家采购业务的客服系统。后期可以快速升级为提供标准服务客服并允许用户根据业务需求定制自己的语料库的AI 应用平台。整个落地的过程分两条线并行，产品线主导私域知识库的建立和问答效果的调优，技术线则重点放在大模型中台的开发上，下面分别阐述两条线的推进情况：2.1.1 私域知识库--语料准备
我们日常用到的大模型，如GPT系列、文心一言、讯飞星火等等，设计出来是为了理解和生成自然语言。这种模型的非凡之处在于，它通过分析和学习海量的文本信息，生成新的、与输入相关的文字。这种自动文字生成的能力使得GPT模型在解析复杂问题、自动生成报告、优化客户服务等方面表现出色，但是针对企业内部应用场景，企业特有的流程、制度等知识无法灌输给大模型进行针对性训练，即便是自研或者私有化部署的大模型，我们企业知识库的文本量级和大模型本身训练的数据量级相比，占比微乎其微，无法直接通过训练来影响大模型的回答效果。而私域知识库则是为了解决上述问题，应运而生的。私域知识库的基本原理是，将企业内部问答语料、制度、专业文档等信息进行Embedding向量化，存储在本地的数据库中，当用户提问时，通过Embedding模型将用户的问题也进行向量转化，再通过计算知识库中的向量和问题转化的向量之间的夹角（通常使用cosin函数），来获得两者的余弦相似度，通过召回策略配置，将前N个相似度大于P的结果，作为本次问答的语料，再加上该场景下本身的角色设定（提示词），组合成一个完整的prompt内容，推送给大模型进行总结回答。结合大模型和私域知识库，企业可以创建一个专业领域的AI助手，该助手可以回答关于公司业务的各种问题，或者根据员工的需求生成报告。这样的一种方式不仅可以提高企业的工作效率，还可以帮助员工更好地理解和利用企业的资源。那么，准备知识库语料时我们应该注意哪些问题呢？根据笔者现有项目的经验看，Embedding模型本身有以下特点：1.可以理解语义，例如生孩子和育儿，在向量化之后的相似度可以在0.8以上；2.相似度和字数有关，例如制度的字数过多时，会导致和问题的相似度降低；3.有时会出现两个完全不相关的语句计算出的相似度确很高，从而影响我们正常的回答效果；这是由于相似度算法根本原理还是数学的向量之间的夹角，不同的语料转换向量可能存在偶发的相似，这也和训练大模型的语料中使用的语法和语义有很大的关系，是我们作为应用方无法直接解决的。当我问“年假”，会出现和年假无关的语料，且相似度都在0.7以上
针对上述问题和特点，我们准备语料库数据时，可以从以下几个方向去优化：
1、在有限的字数内，可以冗余的描述问题和答案，例如生孩子、育儿假、哺乳假 等等相关词汇尽可能多角度的去描述该问题，从而在计算相似度时能更优先召回该答案；但也要注意字数不要过多，否则也会降低相似度；2、针对大模型普遍存在的“一本正经胡说八道”的问题，如果我们有明确的不想回答的问题， 可以准备一下该问题的语料，答案里可以写“该问题不方便回答”“对不起，此类问题请咨询XXX”之类的答案，这样在用户问到此类问题时，会根据知识库中的语料进行一个比较理想的答复；3、有些制度等文字过多，我们有两种方式解决，一种是用递归字符文本分割的方式，例如将每500个字分割成一块，但是这种分割会把一句完整的语句分到两个语料块中，所以在分割时我们还会加入重复字数的设置，比如重复字数100字，那么分块的时候，第1-500字是第一块内容，第400-900字是第二块内容，这样可以避免一句话或者一段完整的介绍被分割到两个内容块中；第二种方式是人工分割，根据实际含义，将一块完整的内容分割到一起；4、尽量避免只使用专业性词语，或对专业词语要有相应的口语化解释，因为用户提问时，大多不是专业用户，问的问题相对偏口语化，如果语料库中没有相应的口语化描述，召回的结果可能不尽人意。文本分割示例图
2.1.2 训练？prompt调优
当我们准备好私域知识库后，就可以开始我们的训练调优步骤了，针对当前应用的业务场景，要给大模型一个基本的角色设定（有的地方也叫提示词）、参数设置、私域知识语料、历史聊天内容等等信息，这些组合到一起构成一个完整的prompt内容。角色设定是指在模型生成输出之前，向模型提供一段特定的文本提示或引导信息，以帮助模型更好地理解输入数据并生成期望的输出。角色设定可以根据具体的任务和数据集进行定制化，以提高模型的性能和准确性。1、设置基本角色信息，并提出要求，例如不能干什么，或者必须干什么；2、直接提供答案：在某些场景中，可以直接向模型提供期望的答案。例如，问到资料外的问题请回答“对不起，我不知道。”；3.、提供相关知识信息：在文本生成场景中，可以向模型提供一些上下文信息，例如文章的主题、重要的关键词或相关背景知识等，以帮助模型更好地理解输入数据并生成高质量的输出。在问答场景下，此部分就是对应我们的私域知识库召回的内容和插件中返回的内容（见下文插件部分详解）；4、历史聊天内容：通常是多轮对话场景下，方便大模型理解上下文聊天内容，从而补全当前用户的问题，进而更好的去回答；5、 基本参数设置，例如温度、最大tokens、惩罚系数等等常用的GPT参数；提示词设定示例
开展针对私域数据库的训练，应遵循以下几个步骤：
1）召回是否准确：理想的知识库语料是不是被准确召回了，这里需要注意的是我们设置的召回数量和最低召回分数，如果目标语料排名比较靠后导致没有召回，则应调整语料中用词，尽量提高其相似度，或者将排名靠前的语料进行调整降低其相似度；如果是相似度分数较低导致没有召回，则需要优化语料中用词，提高相似度分数；2）召回准确，但是大模型没有很好的理解并回答：在角色设定内更清晰的描述需求，或者给一些相关的知识点、示例数据等，大模型更善于模仿而不是创造；3）大模型自由发挥，说了不该说的话：在角色设定中强调要求，并给出应该怎么回答的示例；降低GPT温度参数，减少其自由发挥的程度；4、经过优化后，再重复提问之前的badcase，验证效果直到符合预期；召回策略设置示例
2.1.3 插件迭代，扩展
我们使用大模型的过程中，发现无论是提前训练的语料还是私域知识库，都是基于历史数据产生的静态信息，我们无法让大模型回答一些实时性比较强的问题，比如今天天气怎么样？我的报销单据审批到谁了？等等。有需求就会有解决方案，目前市面上的主流大模型均已支持插件模式。所谓插件模式，就是针对某个场景研发一个系统接口，当用户问到相关问题时，由大模型（为了更容易理解，咱们可以把他当做一个人）来判断是否调用某个接口，插件内也要做设定、描述等设置，来要求大模型将自然语音转化为接口可识别的json等格式，并将接口返回的各个参数拼接成自然语言，再通过prompt给到大模型（这里的大模型我们可以把他当做第二个人，和之前调用插件的是完全不同的设定）进行总结回答。插件角色设定示例
通过插件模式，我们可以解决更多场景的问题，其中最最有效的插件，就是对接搜索引擎，将实时搜索到的信息，经过大模型总结成更实用的知识点。之前百度文心一言的发布会上，就有很好的应用场景，例如让大模型帮你制定一份出行攻略，他会先去搜索网上的攻略，然后根据你的要求、交通工具、时间等进行总结归纳，形成你个人定制化的出行计划，非常实用。而在企业内部应用，我们更多是用到查询内部系统单据信息、系统流程打通（例如创建日程、报销单、请休假申请等等）。除了插件模式外，我们还可以反向应用大模型技术，把大模型的使用内嵌到我们业务系统中，例如招聘场景下，当招聘官打开简历的时候，系统调用大模型接口自动分析简历与JD的匹配程度，给出分析，并给出一些面试建议等。这类应用场景可以不改变原有业务流程习惯，增强补齐原业务中缺失的智能分析能力。当然，尽管我们想尽办法去优化我们的知识库和prompt，还是会出现很多意外情况，例如我们曾经不想让小助手讲笑话，设定里写了你是采购小助手，只能回答和采购相关的问题，当我们问他可不可以给我讲个笑话时，大模型回答的是：我是采购小助手，不能给你讲笑话，但是我可以给你讲个采购员的笑话。我们在和大模型“斗智斗勇”的过程中，相互成长。在项目建设过程中，我们认识到尽管私域知识库提供了出色的对接机制和文档，但在实际业务对接中，仍需要投入大量开发资源，并且在新业务线接入时，面临着高昂的开发成本和重复的沟通，学习成本。因此，我们的开发团队经过深入讨论，提出了一个构想，即建立一个全新的业务对接模式，将通用功能进行封装，形成平台化。这将使公司内部新业务的接入成本几乎可以降至零，甚至完全零开发成本。这一举措将有助于加速智能AI在业务层面的应用推广。在与数据应用团队和云平台团队的深入研讨后，我们提出了建立之家大模型中台的构想，其主要组成部分如下：
1.、云平台团队将负责提供原生API的对接和基础设施支持。这包括与不同厂商和业务的对接，如ChatGpt、文心一言、科大星火、通义千问等大模型。这种对接可以确保平台具有广泛的能力，满足多样化的业务需求。
2、 数据应用团队将负责构建私域知识库，这是整个系统的核心部分。他们还将负责插件注册、Prompt（提示语）设定、语言向量召回、参数调教等功能。这些功能可以帮助系统更好地理解用户需求，提供个性化的回应。
3、信息系统和前端团队将承担业务侧功能的封装工作。将负责创建统一的接入安全策略，处理前端会话服务和用户交互，以及提供后台管理功能。这有助于确保系统的稳定性、安全性和业务接入的易用性。
各团队之间的协作将有助于减少重复开发工作，降低对接和熟悉成本，提高业务对接的效率。整体而言，这个构想有望加速智能AI应用在业务层面的推广，并为未来的业务扩展提供了灵活性和可扩展性。
系统构想的整体架构如下：
本次主要介绍平台层的设计和成果，在平台层的设计中，主要关注以下四点：
2.2.1 降低业务接入开发成本，支持业务快速落地：
为了实现这一目标，我们提供了两种接入方案，以满足不同需求：
2.2.1.1 前端直接接入：
这是一种简化业务接入流程的解决方案。当业务系统没有特殊需求时，只需引入适当的脚本并进行配置即可。这种方法要适用于各种前端技术栈，因此我们要求在开发的过程中使用原生JavaScript以确保兼容性。在这个脚本中要提供一个可定制的悬浮聊天助手按钮，用户可以轻松点击按钮以展示聊天助手容器，并可以自由拖动按钮以改变其位置。聊天助手容器通过内嵌的iframe加载特定的URL，从而呈现聊天助手的内容。
创建内嵌聊天助手的iframe，并设置其样式和源URL。
将聊天助手容器和按钮添加到页面中。
为悬浮按钮添加点击事件，以在点击时显示聊天助手容器。
为悬浮按钮添加拖拽事件，以允许用户拖动按钮的位置。
业务系统接入代码
可以看到，各业务系统如果使用通用的前端接入，只需要引入脚本，给予业务线ID 即可轻松接入使用，几乎0几乎成本。
2.2.1.2 后端接入：
考虑到不同业务场景的特殊要求，对于前端需要定制化开发的特殊情况，我们直接提供了后端API接入方式，以满足特殊需求，为此，业务平台提供了3大类，11个小类的功能接口来满足业务需要，涵盖会话服务，聊天辅助，后台管理数据对接等功能。
一个前端通过webSocket对接后端会话服务的示例：
前端会话发起，直接使用用WebSocket 接入后端服务，其中businessLineId 代表业务线，encryptedData 代表加密过的票据信息（这个的用途会在后面讲到）
2.2.2 确保业务对接过程的安全性
2.2.2.1 Token校验机制：
确保只有经授权的用户能够访问系统资源。为此，我们考虑到未来对接平台的业务系统会有两种：第一，公司内网的办公系统接入，这些系统共性是统一接入了sso 登录平台，因此考虑到接入的便利性，我们不需要业务系统给我们传递加密凭证，而是直接对接sso 平台获取身份信息，再把票据写入到cookie 确保链接的合法性，关键实现如下：02、转成加密票据写入cookie，以确保每次请求的合法性验证为了简化前端系统的对接工作，所以采用了cookie票据认证的方案，即每次请求时在后端解析cookie 票据以验证合法性，但是这样做也带来一个问题，即要求接入业务系统的根域名和iframe 嵌入中台助手的根域名必须一致,否则会有跨域读写cookie 的问题 ，但这无形中又会增加前端业务系统的对接成本，所以我们直接提供了两个引入脚本路径，根域名分别为corpautohome.com 和 autohome.com.cn 路径，各业务系统直接根据自己域名引入不同路径脚本即可，全部的适配工作都由平台端完成，无需业务系统考虑。
第二，外网系统或并未对接sso平台的系统，则需外围系统按照约定的加密标准开发一个加密认证的接口，初始化时给予加密凭证，平台拿到加密凭证后再验证合法性，验证通过后创建加密票据到cookie中,确保该链接的合法性
业务系统后端：业务系统拿到约定的业务线id 和秘钥后，开发密文生成程序。平台端：根据注入密文去验证合法性，如果合法，则执行和第一种接入方式相同的方法生成加密票据写入cookie：
2.2.2.2 黑名单机制：
由于平台对外提供的是一个对话服务，为了防止客户端强刷或者其它的潜在风险，所以平台提供了一个设置ip黑名单的功能，可以通过访问日志查看相关的风险信息，当判断有风险时，可以即可把ip 地址加入黑名单，以阻止其访问。
平台提供查看系统日志及加入黑名单的界面：
在用户建立通信链接时验证其IP是否在黑名单内，如果是则拒绝建立链接：
2.2.3 可控性和稳定性：
为提高系统的可控性和稳定性我们本次采用websocket方式实现前后端通信，并且基于redis 来对实现在线用户的控制，包括建立链接，中断，强制下线控制等。 1、建立webSocket 通道，自定义配置类，复制所有request 请求属性，用于后续的用户身份验证4、限流控制：考虑到有未来有内外网多业务线共同接入，在部署的容器实例有限的情况下为了防止有业务线被强刷的从而影响整体性能风险，所以平台建设时加入了业务线限流措施，即建立消息通道时把把建立通道的实例计数，同时在下线或者心跳检测失败时做减法，每次新建立链接时判断当前实例存活数是否达到上限。5、实时下线功能：引入实时下线功能，以及时处理系统问题，降低因异常情况导致的服务中断风险。
后台直接从redis 中移除在线用户实例，前端webSocket 通信时，则前端再次发起会话中，到当前用于已经不在redis中，则中断会话，代码参考上面试的用户下线功能。
2.2.4 通用功能和个性化配置：
考虑到各个业务线的不同的需求，我们提供了丰富的配置功能和统一的数据监控，管理功能。
2.2.4.1 针对业务线配置：
包括图标配置，欢迎语配置，显示配置：提供图标、欢迎语和显示方式的个性化配置选项，以满足不同业务的需求和品牌标识。
2.2.4.3 数据实时统计：
引入实时统计功能，帮助业务方监控和优化系统性能，提供决策支持。这些综合性措施旨在为业务接入平台的建设提供全面的支持，从而使系统更具可用性、安全性和灵活性，助力业务快速推进。同时，这些功能的引入将使平台在满足通用需求的同时，能够满足个性化的业务配置。
应用对接：基于大模型中台，我们已经快速建立了APP 和PC 两端组件，业务上支持了 好采小助手，员工助手，仓颉大模型应用，供应商门户等业务的智能化应用。
在未来，随着人工智能技术的不断发展，私域知识库和大模型中台将成为企业智能化转型的重要支撑。我们可以在不同业务领域应用这些技术，提高业务效率、增强智能决策能力，为员工和客户提供更好的服务体验。同时，随着大模型技术的不断演进，我们也可以升级更多功能，满足不同业务线的特定需求。插件模式的推广将使大模型变得更加灵活，可以应对更多复杂的场景和问题。总之，私域知识库和大模型中台代表了企业智能化的未来趋势，它们将为之家带来更多机遇和竞争优势，助力业务不断创新和发展。
■ 简介
王冠男：高级系统开发工程师, 目前主要负责行政，财务线相关系统及大模型业务中台的研发工作
孙鹏飞：系统开发工程师，目前主要负责招采平台，汇川平台，税务系统等内部系统及大模型中台会话功能的研发工作
王廷军：系统开发工程师，目前主要负责HR业务线相关系统和大模型中台管理部分的研发工作
郭鹏松：前端开发工程师，目前主要负责公司协同办公，知识库文档，和大模型前端交互部分的研发工作
徐晨曦：高级产品经理，目前主要负责行政业务线，汽车人及大模型中台的产品规划工作