运维效率提升：基于大模型构建高效的运维知识及智能问答平台_智能运维大模型

此文背景说明：某客户基于大模型构建了知识及智能问答系统工具，需要在运维领域结合使用场景进行应用，为此，从头到尾声梳理了一遍大模型在运维领域构建知识及智能问答平台的应用场景、技术实现，总结出来供同业一同探索。 提升运维效率对于任何组织都至关重要。在追求高效运维的过程中，建立一个高效的知识共享平台是一个关键的步骤。平台为团队成员提供一个集中的地方，共享他们的经验、解决方案和最佳实践。通过知识共享，团队可以更快地解决问题，提高整体效率。 本文将探讨如何基于大模型构建这样一个高效的知识收集、知识在不同的运维场景中无缝集成和使用的平台。我们将深入了解大模型技术的应用，以及如何利用大模型相关技术来自动化知识的整理、归类和提取。 通过阅读本文，您将获得一份基于运维领域的轻量级的知识及问答系统的解决方案。让我们一起探索如何提升运维效率，构建一个优秀的知识及知识问答平台，为组织数字化转型的成功铺平道路。

以下是本文主要章节内容 ：

• 运维知识及问答平台对运维效率的重要性和挑战
• 基于大模型构建高效的知识及智能问答平台解决方案
• 20分钟构建知识库并在事件管理中应用的案例分享

运维知识及问答平台对运维效率的重要性和挑战

运维效率的提升很大一部分，在于不同角色的运维人员在不同的场景（故障处置、IT服务工作台、应急分析及处置等）中对知识的快速应用，其对提升运维效率非常重要，同时也面临很多挑战。

运维知识及问答平台对运维效率提升的重要性

1. 知识复用：同样的数据库故障，在不同的应用系统下事件管理员需要同样的分析过程和咨询原厂商的过程，难以在事件再次发生的情况下有效识别，并进行知识复用。
2. 专家经验工具化：专家在处理问题时，通常都具有很强的专业背景和经验，这些知识如何有效的工具化，使一线的值班人员在处理简单、重复的问题时，可以在不同的场景直接获得专家的经验知识，快速解决问题，降低成本，让专家专注在更高效地提升客户体验上。
3. 快速问题解决 ：运维知识及智能问答平台可以促进团队随时随地的知识使用和学习需求，使团队可以不断学习和改进运维流程和工具，最终快速问题解决，提高运维效率。

运维知识及智能问答平台面临的挑战

1. 知识有效利用：由于缺乏智能化手段（或成本高昂），老旧的知识库和自动问答系统只能作为存储和搜索数据库，难以有效利用存储在知识库中的知识。这也导致了对知识库的维护意愿不高。
2. 知识运用场景化：使用知识需要登录到知识库系统查询相关知识，而不是在不同的应用场景中。这导致了使用成本较高，例如在事件或应急场景下，是否能够在推送告警事件或应急场景时，同时推荐相关事件的知识或解决方案。
3. 知识反馈流程化：一旦知识进入系统，就很难发现其中的问题，因为无法有效利用。即使发现了问题，也需要经过冗长的流程和填写大量表单，这让大多数人望而却步。在场景化应用中，应该能够在使用流程的各个环节中遇到问题时进行实时且高效的反馈，润物细无声，而非刻意要去做某件事情。

基于大模型构建高效的知识及智能问答平台解决方案

由于最近一年来大模型的智能化能力在知识及智能问答领域的突飞猛进，使得之前力不从心的知识及自动问答系统有了更好的技术手段可以满足人们对其的应用需求。

使用场景说明

知识库系统和智能问答平台系统在运维领域，一定要同运维场景深度结合，才能发挥其最大价值，目前运维领域常见的场景包括：

• 故障排除与问题解决：
  • 告警处置方案知识化：当事件管理员在告警管理工作台处置告警时，其对告警的最终分析处置解决方案可以同步知识库做为故障处置的知识存储。
  • 告警产生知识推荐：当事件管理员在告警管理工作台看到新产生的告警时，大模型可以直接推送针对该告警可能的解决方案知识信息，加速分析及处置效率。
• 应急场景：
  • 应急手册：大型企业都会对一些重要的业务系统进行应急演练，并配置相应的应急手册，当出现故障时可以按应急预案进行操作，因此应急手册成为应急场景下的重要知识来源。
  • 应急知识推荐：在故障应急状态下，系统本身已经收集了应急的相关数据，这时可以根据应急状态下产生的告警信息由大模型分析之后，推荐应急操作预案、推荐针对单个告警的处置方案、甚至故障的成因也一并推送出来，这时可以辅助应急决策人员进行快速的应急处置和业务恢复。
• 已知故障：
  • 厂商手册：应用研发厂商、技术组件厂商（开源或商业）一般会准备一些快速的故障排查及处置手册，这些会成为运维领域知识的重要组成部分，大模型通过对故障关键字的匹配可以精确找到故障的解决方案。
  • 运维专家或SRE工程师对故障的总结：这两个重要的角色在日常运维的过程中针对发现和处置的故障进行总结之后，会形成已知故障场景库，当再次发到类似的故障之后，可以直接推送针对当前故障的分析方法、处置恢复方案，减少专家介入和排查的时间成本。
• 运维管理规范：也是重要的知识内容，当出现应急或重大事件的场景下，一般运维人员会采用各种方法找捷径去恢复业务，但是捷径代表不可预知的风险，因此在故障场景下，不仅要让当前的处置事件的工程师获取处置事件的知识、建议，同样也要告诉到他针对这类事件的处置要遵守某种操作规范。
• 工单处置结果：
  • 工单处置结果知识化：来自工单系统的对某个工单的处置结果同样也可以做为知识的一部分，当处置完成之后这些信息会同步知识库。
  • 工单知识推荐：当某个工程师被分配工单之后，针对工单上所描述之故障的推荐知识也会随之提供出来。
• IT服务台：
  • 服务台客户服务知识化：日常服务台响应和回答用户或客户的问题，是最好的一问一答格式，可以经过审核和优化之后的标准答案做为知识库存储起来。
  • 服务台客户服务知识推荐：不论是来自电话语音还是文字的客户沟通问题，都实时转译为文字通过大模型从知识库中匹配最佳的答案提供客服人员或智能问答机器人进行快速的回复。

运维知识体系构建

针对运维知识体系的构建，我们分成三个重要的组成部分：

• 运维知识供献场景层：蓝色的部分，为运维领域的一些主要场景，其在进行业务开展的过程中会产生大量的知识，这些知识需要通过某种标准化的手段（自动的、模板化的）进入到传统知识管理层，对这些知识进行分门别类的管理。
• 传统知识管理层：橙色的部分，知识构建和管理的过程同老旧的知识管理没有什么分别，可以用一些老版的管理工具，如wiki、conflunce甚至wordpress这种工具都可以很好地管理起来，在这里不再详述。
• 基于大模型的知识库层：灰色的部分，这是同传统的知识体系应用不太一样的地方，传统上的应用会定时将这些知识存储到ES类的系统中以方便进行全文检索，然后提供算法对检索的内容进行排序，而基于大模型的知识检索和知识问答则需要将知识库中的信息转换为纯文本信息，然后再对文本进行分割（分割知识块），然后通过特定的算法将文本向量化之后存储在向量数据库中。（这个过程在互联网上大家可以找到非常多的内容来详细了解，在此不再详细描述）

针对知识的创建主要分为两类：

• 手工知识创建：该过程可以让运维人员自行登录知识库系统并建立知识。
• 基于场景化的知识创建：在运维的不同场景中结合场景来自动化创建相应的知识，如事件处理完成之后，对事件的总结性回顾的内容可以日终批量同步到知识库系统中，包括问题、问题描述及日志、问题产生的原因、解决方案这四个关键字段内容。

运维知识体系应用

在收集了知识信息之后，剩下的部分就是知识的应用了，在“使用场景说明”章节中，已经详细介绍了在运维领域可能的使用场景，集成工作无非就是api嵌入到使用场景中，结合业务流程来进行使用，通过大模型的核心能力基于对应场景上下文信息，提供知识，满足场景使用需求。

以告警工作台为例，说明一下大模型场景下整个系统交互的处理流程：

1. 首先，事件管理员在告警工作台看到了一条告警，对于这条告警自己也没有遇到过，这时当他打开这条告警进行分析时，系统会自动根据告警内容抛出一个“查询/提问”，如：针对下方这条告警系统要能够自动归纳出这是“CPU使用率异常”问题。

【次要告警（xx数据中心）】应用监控平台[APM]，by10xxxxx，Linux服务器1分钟CPU负载高(实例:CPU）,当前值:1.25,阈值:1 - 9999999，发生时间:09/17/2020 18:38:25 【详细信息:Cpu Number:8; 1 Min Load Average:9.99; D Process Number:0】【生产地址:*.168.1.*；所属资源池:暂无,序列号:210xxxxxxxxx0218】

2. 针对查询/提问的内容“cpu使用率异常”进行有效性检验，一般验证查询或提问的内容是否为空。

3. 针对查询/提问的内容进行向量化转换（大模型通用的一种实现方案将文本或知识进行向量化存储，同时查询也会先向量化，具体可以通过google了解一下技术细节）。

4. 通过向量化之后，需要到向量数据库进行查询跟该向量结果相似的内容，注意这一步一般是本地的算法工程来完成，找到跟该内容相似的所有内容，而不是将整个库提供给大模型，大模型是在此基础上进行推理。

5. 在基于向量的知识库中查询之后，会将满足条件的相似内容提交给大模型处理。

6. 在正式发送给大模型之前，需要Prompt处理，其实是让大模型进行角色扮演的指令，如针对上面一条告警生成的prompt建议如下:

你现在是一名运维领域的专家，主要处理一些重要的告警。 请根据告警的问题“CPU使用率异常”，帮助推荐给出问题出现的大致原因和解决方案。

7. 这时调用大模型的接口对该prompt进行处理，注意在这里大模型可以是openAI提供的也可以是国内不同的企业所开发的大模型，由大模型针对查询的问题和相似的内容做出推理判断。

8. 针对大模型判断的结果输出给告警工作台，如下图所示：

系统集成边界

针对已有自动问答系统和知识库的企业用户，可以参照上图为系统集成边界，参照如上方式可以最大限度的保障企业已有的资产：

• 核心的推理引擎：采用openAI或其它的大模型来增强智能问答或知识检索系统的效果。
• 向量化知识库：传统的知识信息存储在关系数据库或ES这类系统中，而基于大模型的应用，则需要将其存放到向量数据库中，因此需要从传统知识库中同步相关的知识进向量化知识库，而对知道的管理过程，则保持不同。
• 知识管理：知识管理过程，知道的采集、审核、保存，如果企业已有现成的系统，则可以不必替换。只是需要将信息同步到向量化知识库中。
• 智能问答系统：老旧的智能问答系统一般已经完成了同部分使用场景的结合，这时不必对该系统进行全部替换，只是替换其核心的大模型推理引擎即可，如上图中利用openAI的部分，增强其知识的推理能力。
• 用户提问：即使用场景的部分，需要将其提供的方式参照大模型的Promp标准进行提问即可。

注意：为了未来对大模型进行效果微调，在系统设计时，要记录相应的调用日志，或在业务流程中对大模型回馈的结果进行评价，这样可以做为人工标注的数据，可以优化模型。

20分钟构建知识库及智能问答系统并在事件管理中应用的案例分享

所需要的软件列表

本次案例的实现，全部采用开源或SAAS的产品来提供，并不涉及到私有化部署的软件产品。软件列表如下所示，如何申请apikey请自行研究，在这里不再详细说明：

以上软件只是实现该系统的作者推荐列表，在实际的应用中有很多开源、saas、商业版本的软件产品供使用，在这里不再详说明，各位可以根据自己企业的性质自行选择合作的解决方案产品。

私有化知识样例说明

由于采用大模型对私有化的知识库数据进行智能问答和知识库系统的实现，因此需要说明私有化知识提供给大模型时一般采取什么格式，会取得比较好的效率。

通常情况下，可以支持各种文档数据，包括work、pdf、markdown、json等，在flowise中都有相应的解析组件可以完成解析，本例中我采用jsons格式，最佳格式是包括两个字段内容prompt和completion，这样大模型可以比较容易识别为“问题”和“答案”。如下示例所示：

{
"prompt": "Redis内存使用率高",
"completion": "Redis内存使用率高可能是由于数据存储的增长或未使用的数据未过期引起的。需要定期清理不必要的数据、优化内存配置以减少内存使用率。"
}

注意：在实际应用中，一定要考虑如果一份文档中包括多个知识点，如何做知识点切分的情况，因此建议采用json格式的数据，比较容易切分，一个“{}”即为一个知识点，pdf、word格式的知识块切分，可自行探索。

在告警的场景中，可以将告警的内容抽象成一段简单明了的问题存放到prompt字段中，将针对该事件的分析及处置过程整理到completion字段中，completion中可以详细记录产生问题的场景报错信息、问题产生的原因、解决的办法等信息，这样可以提供给大模型更好的推理能力。下面有一份Atlassian的产品报障信息及处置结果的总结，供参考：

• 圈1:标题，即为prompt字段的问题
• 剩下的问题、原因、解决方案，都可以放到completion字段中

准备知识数据

在开始之前需要先要有知识数据，本例我们为事件管理的智能问答系统，即在统一事件管理的工作台，事件分析及处置人员在对事件进行处置时，可以直接使用大模型推送的知识，并可以通过反覆盖的交互来完成问题的排查过程。

由于缺少这类的数据，以下知识为通过互联网搜索所得到的知识，比较简漏，但是通过构建这样私有化的知识内容，可以帮助我们走通整个构建的流程。

{"prompt": "Unix服务器保留CPU利用率异常", "completion": "Unix服务器的CPU利用率异常可能是由于不正确的进程管理或资源争用导致的。通过查看系统进程、性能监控工具和日志，可以帮助确定问题的来源，并采取适当的措施来解决它。"}
{"prompt": "GC次数", "completion": "GC次数表示垃圾回收的频率，它受到多种因素的影响，包括应用程序的负载和内存管理设置。要减少GC次数，可以优化代码，减少对象创建，增加堆内存，或者调整垃圾回收策略，以提高系统性能和稳定性。"}
{"prompt": "业务成功率低", "completion": "业务成功率低可能是由于网络问题、系统故障或应用程序错误引起的。需要进行详细的故障排除，包括检查日志、监视系统性能、验证网络连接，以找到并解决问题的根本原因。"}
{"prompt": "Unix服务器保留CPU利用率异常", "completion": "Unix服务器的CPU利用率异常可能是由于不正确的进程管理或资源争用导致的。通过查看系统进程、性能监控工具和日志，可以帮助确定问题的来源，并采取适当的措施来解决它。"}
{"prompt": "Weblogic中间件JVM使用的堆栈空间百分比", "completion": "Weblogic中间件的JVM堆栈空间百分比表示堆栈空间的使用情况。可以通过调整JVM参数、垃圾回收策略和应用程序代码来优化堆栈空间的使用，以提高性能和稳定性。"}
{"prompt": "Linux可用内存少", "completion": "Linux可用内存不足可能是由于运行的进程占用了太多内存，或者内存泄漏导致的。需要检查系统资源使用情况，释放不必要的进程或服务，以增加可用内存。"}
{"prompt": "ESX服务器内存使用率", "completion": "ESX服务器的内存使用率表示服务器内存的利用情况。通过监视内存使用情况、调整虚拟机配置和分配更多内存资源，可以改善性能和避免内存不足问题。"}
{"prompt": "Weblogic中间件JVM使用的Heap空间异常", "completion": "Weblogic中间件的JVM Heap空间异常可能是由内存泄漏或不正确的堆设置引起的。需要分析堆转储文件、调整JVM参数以及检查应用程序代码，以解决问题。"}
{"prompt": "Unix服务器磁盘忙", "completion": "Unix服务器磁盘忙可能是由于磁盘读写操作过多或者磁盘故障引起的。需要查看磁盘活动、日志和性能监控数据，以找到问题并采取适当的措施。"}
{"prompt": "Ping成功率低", "completion": "Ping成功率低通常是由于网络故障或丢包问题引起的。需要检查网络连接、路由、防火墙设置以及网络设备的状态，以提高Ping成功率。"}
{"prompt": "数据存储占用率高", "completion": "高数据存储占用率可能是由于数据积累或未清理的旧数据引起的。需要定期清理、归档或扩展存储资源，以处理数据存储占用率高的问题。"}
{"prompt": "NGINX连接数达上限", "completion": "当NGINX连接数达到上限时，可能是由于并发请求过多或配置限制不当引起的。需要增加连接数限制、优化配置和增加服务器资源以解决问题。"}
{"prompt": "系统成功率低", "completion": "系统成功率低可能是由于软件错误、硬件故障或网络问题引起的。需要进行详细的故障排除，包括检查日志、监视系统性能和验证网络连接，以找到并解决问题的根本原因。"}
{"prompt": "Redis内存使用率高", "completion": "Redis内存使用率高可能是由于数据存储的增长或未使用的数据未过期引起的。需要定期清理不必要的数据、优化内存配置以减少内存使用率。"}

构建向量数据库

我们需要登录pinecone，点击indexes，可以看到创建的index列表，本例中我们已经创建即了work index，基本上每个index对应一个领域的知识库，针对其它业务领域的可以再创建一个新的index。

对知识进行向量化之后，会有什么不同，我们可以看一下pingcone数据库存储的信息即可：我们无需创建任何表结果，embeddings方法会将原始数据即圈1位置的原始内容向量化转换为圈2的内容，并将这些信息都存储到一条记录中，一个分割的知识点一条记录。

流程配置步骤说明

flowiseai是一个可视化的大模型构建工具，提供了非常丰富的算子，可以满足不同情况下用户的建模需求，如上图所示，本例中主要使用了7个关键算法，构建步骤说明如下：

第 1 步：构建一个基于大模型的对话式应用

Flowise 是一个大模型构建工具，可以通过流程化的方式构建不同的应用，在本例中我们构建的是一个对话式机器人，因此，我们从chain中选择conversational retrieval QA Chain，它可以满足我们的需求，将其托动到红圈1所示的位置。

• Language Model：用于选择大语言模型，可以选择flowise 已经支持的大语言模型，这里不仅仅支持openai，也支持亚马逊的、google的、Facebook等主流场景，因为flowise是一个开源的产品，您也可以将自己私有的大模型填加进来。
• Vector Store Retriever：大模型进行知识存放的向量化数据库，下面的章节中会介绍向量数据库中存储的到底是什么。
• Memory：大模型的上下文记忆能力，如果没有配置这个，则每一次问答就结束，没有办法根据上下文会话的内容进行推理。

还有一个更重要的参数，点击Conversation Retrieval QA Chain界面的“Additional Parameters”按钮来配置Prompt，你也可以理解为规则，大致可以说明为你想要大模型角色扮演什么，他的知识从哪里来，回答知识时有些什么样的规则，本例中我配置如下：

You are currently an ITOM expert, responsible for providing solutions to all alarms that occur. You will provide me with answers from the given info. If the answer is not included, say exactly “Hmm, I’m not sure” and stop after that. Refuse to answer any question not about the info. Never break character. Follow these five instructions below in all your responses . Use Chinese lanquage only. 2. Use Chinese characters whenever possible, 3. Do not use English except in programming languages if any； 4. Avoid the Latin alphabet whenever possible. 5 Translate any other language to the Chinese language whenever possible

第 2 步：配置QA Chain的大语言模型

本例中我们使用OpenAI来完成，因此选择LLMs中的ChatOpenAI，在这里也可以选择一些其它厂商的模型（如aws、facebook、google等，甚至包括一些国内的大模型），如下图所示：

未开通4.0，在这里model Name配置为gpt3.5，connect Credential配置链接 openai 的apikey，其它参数选择默认即可。

第 3 步：配置向量数据库

在本例中我们选择pingcone这一SAAS软件。

1. 向量数据库创建index，获取api key ：需要登录pingcone获取一个api key，然后在pinecone中创建一个新的数据库索引，我这边命名为workindex。
2. 配置参数：
   • document：代表知识库中输入的知识源，可以是一个或一批文件（pdf、json、word、markdown）等，在flowise 中包括各种解析这种文件的算子。
   • Embeddings：是一个对文件转成文本之后对其进行向量化的算法，把document中的文本进行转向量化的处理，也是有许多开源的算法和厂商提供。
   • connect Credential：是配置连接pinecone数据库的api key参数。
   • Pinecone index：用于配置数据库的索引，在这里选择work index，如果企业内部有多个不同业务领域，则可以配置为不同的index，这样可以使回答更准确，而不易混淆，尤其是业务描述比较相近的情况下。

第 4 步：配置导入知识库

在本例中由于知识内容比较简单，没有大量的数据，我们直接以文本的方式导入，如下图所示：

我们直接将知识内容放入text文本框中即可。针对该文本的内容需要切分为不同的知识点，所在还有一个text splitter参数，进入第5步。

第 5 步：配置文本切分方法

文本切分主要是为了将一个大文件中会包括多个知识点，切分成一个个的独立知识点，存入向量数据库中，由于本例我们使用的json格式，切分比较简单，按“}”来进行切分即可，如下图所示：

第 6 步：针对切分好的知识点进行向量化转换

如下图所示，本例也使用open ai 的embeddings算法：

第 7 步：配置智能问答机器人的上下文记忆能力

选择buffer memory算法，参数如下图所配置即可：

第 8 步：验证创建的机器人是否能正常工作

我们输入“cpu利用率异常“，系统已经从我们构建的知识库中找到了答案，并且整个流程也能够跑通了：

第 9 步：智能问答机器人应用场景集成

集成操作也比较简单，提供了多种集成方法，建议选择javascript方法，只需要在场景中创建一个单独的页面，将javascript的代码嵌入，即可如第8步中看到的样子进行工作了，最后只要调整一下窗口的大小即可。