大模型太给力了，数据库运维工作量直接减少 50%！

本文源自百度智能云数据库运维团队的实践，深入探究了基于大模型构建「知识库智能问答体系」的计划过程和应用。
全文包括了总体的技术方案选型、各个模块的计划实现、重点难点问题的突破、以及目前的落地场景应用等。
该体系自从内部上线以来，整体的回答准确率到达 80% 以上，数据库运维工作量直接减少 50%：包括 80% 咨询量，以及 20% 工单处理工作。

---

1 背景
随着大模型的飞速发展， AI 技术开始在更多场景中遍及。在数据库运维领域，我们的目标是将专家体系和 AI 原生技术相融合，帮助数据库运维工程师高效获取数据库知识，并做出快速准确的运维决议。
传统的运维知识库体系重要采用固化的规则和策略来记载管理操作和维护的知识，这些体系的知识检索方式重要基于关键字搜刮和预界说的标签或分类，用户需要具备肯定的专业知识才能有用地利用这些体系。
这已不足以满足现在复杂多变的运维情况。因此，借助大模型来提供运维知识并协助决议成为趋势。这将在运维本领、成本控制、效率提升和安全性等方面带来深刻的变革。
在数据库领域，AI 技术应用可以分别为不同场景，例如知识库学习（包括知识问答和知识管理）、诊断与推理（包括日记分析和故障诊断）、工作辅助（包括 SQL 天生和 SQL 优化）等。本文将重要侧重介绍「知识库智能问答体系」的计划与实现，旨在为读者提供深入了解该领域应用的思路。
2 架构计划和实现
2.1 技术方案选型
目前，大模型已经可以通过对天然语言的明白推测用户意图，并对原始知识举行汇总、整合，进而天生更具逻辑和完备性的答案。然而，仍存在以下几个问题，导致我们不能直接使用这些模型来对特定领域知识举行问答。

• 专业性不足：作为通用大模型，对专业领域知识的训练不足，可能会产生虚假陈述、准确性不足以及信息丰富度不足的问题。
  
• 时效性问题：模型的训练数据基于某个时间之前的数据，缺乏最新的信息，每次添加新数据都会导致高昂的训练成本。
  
• 安全性问题：模型无法访问企业内部私密文档，且这些文档不能直接用于 Fine-Tuning。
  

为了办理这些问题，业界采用了如下几种技术手段来为大型模型提供额外知识。

• Fine-Tuning（微调）：使用特定领域的知识对基础大模型举行微调，以改变神经网络参数的权重。固然实用于特定使命或风格，但需要大量资源和高质量的训练数据。
  
• Prompt 工程：将行业领域的知识作为输入消息提供给模型，让模型对消息中的知识举行分析和处理。这种方法在正确性和精度上体现精良，但有文本长度限定，对于大规模数据不敷高效。
  
• 与传统搜刮结合：使用传统搜刮技术构建基础知识库，然后使用大语言模型处理用户哀求，对召回结果举行二次加工。这种方法具有更高的可控性和效率，并实用于大规模数据。
  

为了确保准确性和效率，我们选择了第 2 种和第 3 种方式相结合的方案，通过向量数据库将知识外挂作为大模型记忆体，使用 LangChain 作为基础开发框架来构建知识库问答体系，最终依赖 Prompt 工程和大模型举行交互。
2.2 分模块计划实现
数据库运维知识库的整体计划流程如下图所示，包括文档加载、文档分割、文本/问题向量化、问答缓存、大模型天生答案等流程。

2.2.1 知识入库

• 数据源加载息争析：重要使用 LangChain 支持的文档加载方法，对 PDF、CSV、Markdown 等格式的文档范例举行加载和采集。此外，考虑到许多企业的文档泉源是内网网页，因此也支持 Selenium 和 BeautifulSoup 来爬取网页内容，最后再应用 LangChain 中的 Markdown 加载器举行格式解析。
  
• 文本分片：原始知识库应当被拆分成独立、较短的文本块，每个文本块将作为问答的最小记载，与问题举行匹配。文本的切分质量直接关系到 Embedding 和召回的质量。切分块不能太大或者太小，也不能超过 Embedding 和大模型的 token 限定。在许多内部网页文档中，由于多级标题和段落间是有上下文关联的，以是我们采用 Markdown 或者 HTML 方式举行切分，进而大大提高了对文档内容的感知本领。
  在文本切分器的选择上，我们重要采用 LangChain 中的 RecursiveCharacterTextSplitter 和 SpacyTextSplitter这两种分词器。它们能够在保持知识点完备性的基础上，对中文句子、段落、章节等举行精良的切分。需要注意的是，由于算法有 token 数目标限定，选择好的分词器能够为切片提供很好的切分单元和依据。目前我们选择的是 tiktoken 和 Spacy 中的 Tokenizer，但有时间并不抱负，需要根据大模型采用的 token 计算方法举行适配。
  
• 文本向量化：在项目初期 Embedding 模型选择了 Hugging Face 上开源的 Embedding模型，例如 GanymedeNil/text2vec-large-chinese和 moka-ai/m3e-large，但现实测试结果并不抱负。最终我们选择了文心的 Embeddings 模型，结果有质的飞跃，固然支持的 token 和向量维度低，但整体结果很好。LangChain 中对于千帆接口举行了封装，可以直接通过百度千帆调用文心 Embedding。关于文本向量化、存储和检索的详细信息，请参考下图：
  

• 存储：将天生的Embeddings（向量）与原始分片（知识点）举行存储，同时考虑存储一些关键的元信息，如链接地点和分片巨细，以用于检索时作为过滤条件。专业的办理方案是使用向量数据库，但也可以考虑传统数据库或存储中间件，如RedisSearch 或 pgvector，它们都支持向量字段和向量相似性查询，可提供及时向量索引和查询功能。
  在向量数据库选型上我们对 ElasticSearch、Baidu ElasticSearch（BES）、Milvus 和 PGVector分别做了测试，在查询性能方面，PostgreSQL 性能较差不可用，而 BES、ES、milvus 性能在一个层级，BES采用自研的插件实现了 HNSW 算法，召回结果体现更好。在资源消耗方面，它们都较为泯灭内存，此中 BES 和 ES 相对来说消耗较小。BES 是百度智能云自研的分布式、开源搜刮与分析引擎，在百度内部多模态和大模型基础平台有多年积累和应用，在性能、分布式和易用性方面体现精良，LangChain 也对其举行了集成，最终我们选择了 BES 作为向量数据库。
  

2.2.2 数据检索

• 用户问题向量化：对用户的问题举行向量化计算。假如结果在缓存中命中，将从缓存中获取已经缓存的答案，以减少文心大模型 API 费用和提高响应速度，可使用 GPTCache 等库来实现。
  
• 向量检索：使用 Embeddings 模型在向量数据库中举行相似性计算，召回相似度最高的 n 个分片。目前设置的召回策略是默认选择前 10 个评分最高的分片。
  

2.2.3 结果整合
将向量数据库检索召回的文本举行二次加工后，利用 LLM 总结概括和分析推理本领，完成最终答案的天生。

• Prompt 天生：将 n 个切片和用户原始 Question 组装成 Prompt。需要注意的是，Prompt 不能超出 Token 限定，超出限定则需要举行优化，例如淘汰或多次迭代调用等。我们在 Prompt 中除了原始问题和内容，还对大模型参加了回答内容的限定，如「不答应在答案中添加编造身分」、「请用中文回答」等。此外，我们还提供记忆功能，将历史会话信息传入 Prompt，一并发送给大模型。
  
• 大模型响应：将 Prompt 发送给大模型，获取最终的结果。同时，将对话信息和结果追加存储到 MySQL 中，以保存会话历史，这有助于会话重启和历史信息接入大模型。
  

3 技术难点和办理方案
**3.1 难点一：向量数据库召回率低
**
尽管通过将知识嵌入（Embedding）与大型语言模型相结合已经成为一种高效的实现路径，但向量数据库在向量化、存储和检索等多个阶段都可能存在问题，进而导致检索结果的召回率不尽如人意。在现实测试中，我们在未经优化的情况下，召回率仅到达了 70% 左右。而一个相对可靠的体系，召回率至少需要到达 85% 或甚至 90% 以上。以下是我们在应用中采取的优化措施。
3.1.1 精确切分文本

• 分割模型：由于训练的文档重要是中文文档，因此切片工具必须具备对中文的精良支持。为此，我们首选 Spacy 作为分割工具，并采用 zh_core_web_sm 模型作为标记器（tokenizer）。
  
• 分割条件：一般情况下，大部分体系会使用 LangChain 定长切分，但如许会丢失大部分上下文关联，知识点也是割裂的。在实践中，我们没有仅仅依赖 chunk size 作为唯一的切割条件，而是对那些具有显着段落或章节结构的文本格式（如 Markdown 或 HTML）举行了格式化分割，以确保文本的一连性、相关性和完备性。当段落超过 Embedding token 数限定时，我们会使用 RecursiveCharacterTextSplitter 对段落继承举行切分，切分条件除了设置换行符外，还参加了中文常见的断句符号，好比分号、叹号等。
  
• 标题补偿：当某段文字的巨细超过了 chunk size 时，我们会针对没有标题的 chunk 补充标题，以确保整体切分的完备性。
  

3.1.2 优化文本向量化

• 标题向量化：在举行精细化切分之后，标题的重要性显现出来。因此，我们在这一阶段对标题举行向量化处理。这一方法实用于帮助手册、 HTML 和 Markdown 等文本格式。
  
• 内容关键字向量化：假如仅对标题举行向量化，对于那些标题概括性较差或段落内容丰富的情况，精召率提升仍旧有限。因此，我们还实验了了另一种方法，即起首利用大型模型或关键字模型提取关键字，数目通常限定在 10 左右，然后对这些关键字举行向量化处理。由于多轮次调用的耗时和关键字提取的可靠性问题，最终该方案被放弃。
  
• 标题 + 内容同时向量化：在文本分割时，我们强行对每个分片参加了标题。在向量化时，会将标题 + 内容打包一并举行向量化。我们将用户提问向量化后，和向量化后的切片举行检索匹配，选择与问题最相关的 topN 切片，如许可以显著提高精召率，这也是我们最终的方案。
  

3.1.3 Embeddings 和向量检索调优
对于 Embeddings 的选择和调优，上文已经介绍过，我们最终选择了结果更好的文心 Embedding。对于向量数据库检索性能，这里优化空间并不大，调整 HNSW 算法的参数，对最后召回结果影响不大。
3.2 难点二：Token 数目限定
在应用大型语言模型时，我们面临的重要限定之一就是输入文本的上下文长度。开源模型和商业模型的上下文长度限定范围从 2K 到 100K 不等。上下文长度对于应用大型语言模型具有关键影响，包括知识增强、记忆等方面的工作，都是为了办理上下文长度限定而计划的。以下是我们采取的策略：

• 取舍：假如选择的 10 个文本组合成的 Prompt 超出了模型的 Token 限定，我们采取逐一舍弃相似度较低的片段的策略。假如减少到召回文档为 6 个时还是超限定，则会选择 token 数支持更多的模型。
  
• 模型选择：ERNIE-Bot-turbo 模型支持 10200 个Token，ERNIE-Bot 支持 2000 个 Token 的 ERNIE-Bot 模型，以扩大上下文长度。但是 ERNIE-Bot-turbo 在问答领域的结果并不如 ERNIE-Bot，此时，我们的策略是在不超过 2000 个 token 的情况下优先选择 ERNIE-Bot，极大地提升了体系对复杂问题的处理本领。
  
• 压缩 Prompt：我们实验对多个切片拼接后的文本举行压缩，以提取重要内容，去除无用且重复的词组。然而，这种方法的结果有限，甚至可能导致文本失真，且对中文支持较差，因此无法从根本上办理问题。压缩结果如下图：
  

• 多轮次迭代调用 LLM：面对超长文本超出大模型 token 限定的情况，我们采用了 MapReduce 的方式来突破 Token 限定。该方式将文本拆分成多个部分，并多次调用 LLM 以办理文本长度问题。详细流程包括将多个分段分别哀求 LLM，获取各自的局部答案。然后将这些局部答案拼接成新的 Prompt，再次哀求 LLM 以获取最终答案。这一流程有用地扩展了上下文长度，但是现实应用结果并不抱负，体现为最终结果失真，尤其是在回答流程类问题场景下。重要缘故起因是汇聚后丢失了许多原始文本细节。
  

3.3 难点三：知识陈旧和虚构答案
在商业大型模型的大多数应用场景下，模型能够为 MySQL、Oracle 等数据库的相关问题提供令人满意的答案。然而，不可避免地，这些大型模型有时会出现知识陈旧和答案虚构的问题。为了提供更加丰富和准确的答案，我们采用了一种搜刮和推荐体系的方法，并结合了大型模型的推理和总结本领。以下是我们的重要方案和流程：

• 提取问题关键字：起首从客户问题中提取关键字，以确保这些关键字能够准确地用于搜刮引擎检索。为此，我们探索了两种不同的方法：
  
• 
  
  
  
  • 大模型：大型模型本身具备肯定的关键字提取本领，但现实测试表明，这种方法的稳定性有待提高，可能会导致调用链出现异常。因此，我们需要对这种方式举行 Prompt 的调优，以提高其性能和可靠性。
    
  • NLP 算法：另一种思路是利用 NLP 模型来举行关键字提取。然而，我们曾实验使用 Hugging Face 的一些模型，但结果并不非常抱负。
    
  
  
• 搜刮引擎检索和文档解析：为了获得与数据库问题相关的准确答案，我们评估了以下两种不同的策略：
  
• 
  
  
  
  • 接入百度搜刮引擎：我们曾实验使用百度搜刮 API 来根据提取的关键字举行检索。然而，这一方法的答案质量较差，而且可能包含过期的信息，这可能会对最终答案造成负面影响。因此，我们最终放弃了这一方案。
    
  • 接入官方文档搜刮：对于 MySQL 等数据库，官方文档提供了用于客户搜刮的 API。我们只需传入关键字即可获取与之匹配的搜刮结果。然后，我们可以选择最相关的前 N 个结果，并对这些结果的链接内容举行爬取息争析。这一流程类似于之前描述的领域知识入库和知识检索流程，但详细细节不再赘述。
    
  
  

• 调用大模型：将多个 chunk 拼接和问题一起天生 prompt，调用大模型获取答案。
  

可以看到文档解析和大模型调用着实就是在重复我们前边介绍的领域知识入库和结果的二次整合过程，唯一不同的地方就是我们使用搜刮引擎去取代了向量检索。以 MySQL 为例子，详细流程如下：

4 应用场景接入
该体系自从内部上线以来，整体的回答准确率到达 80% 以上，数据库运维工作量直接减少 50%，包括 80% 咨询量，以及 20% 工单处理工作。
目前「知识库智能问答体系」重要通过两种方式接入和应用：Database Chat 和 IM 机器人。

• Database Chat：除了类似于 ChatGPT 问答界面外，还具备知识管理、用户管理等功能。（该功能已经集成数据库智能驾驶舱 DBSC 中，将于 3 月尾正式开放上线）
  
  
  
  
• IM 机器人：IM 工具做为工作协同中最重要的软件，使用频率非常高。我们提供了 IM 接入接口，客户可以开发 IM 软件（微信、飞书、如流等）机器人，在谈天群中实现快速高效获取信息和知识。
  

5 总结
从技术工程角度来看，利用向量数据库结合大型 AI 模型来构建领域知识库体系的实现并不复杂，然而，这一领域仍旧面临着不少挑战和潜在的改进空间。在本文中，我们已经讨论了一些办理方案和技术，但仍旧有许多可能的改进和将来发展方向值得深入研究。
起首我们认为关键点还是办理向量检索的召回准确性和超长文本处理本领是两个难点，这些方面可能还有更好的方式。此外，大模型本身的本领和文档质量是体系性能的关键因素，因此需要不断升级和维护模型，同时确保文档的及时性和准确性。
我们盼望更多的研究者和工程师积极贡献更多的创新思路和技术，推动大模型在数据库运维领域落地，等待将来能有更多的可能性。
零基础如何学习大模型 AI

领取方式在文末
为什么要学习大模型？

学习大模型课程的重要性在于它能够极大地促进个人在人工智能领域的专业发展。大模型技术，如天然语言处理和图像识别，正在推动着人工智能的新发展阶段。通过学习大模型课程，可以掌握计划和实现基于大模型的应用体系所需的基本原理和技术，从而提升本身在数据处理、分析和决议订定方面的本领。此外，大模型技术在多个行业中的应用日益增长，掌握这一技术将有助于提高就业竞争力，并为将来的创新创业提供坚固的基础。
大模型典型应用场景

①AI+教诲：智能讲授助手和自动评分体系使个性化教诲成为可能。通过AI分析学生的学习数据，提供量身定制的学习方案，提高学习结果。
②AI+医疗：智能诊断体系和个性化医疗方案让医疗服务更加精准高效。AI可以分析医学影像，辅助医生举行早期诊断，同时根据患者数据订定个性化治疗方案。
③AI+金融：智能投顾和风险管理体系帮助投资者做出更明智的决议，并及时监控金融市场，识别潜在风险。
④AI+制造：智能制造和自动化工厂提高了生产效率和质量。通过AI技术，工厂可以实现装备猜测性维护，减少停机时间。
⑤AI+零售：智能推荐体系和库存管理优化了用户体验和运营成本。AI可以分析用户行为，提供个性化商品推荐，同时优化库存，减少浪费。
⑥AI+交通：自动驾驶和智能交通管理提升了交通安全和效率。AI技术可以实现车辆自动驾驶，并优化交通信号控制，减少拥堵。
…
这些案例表明，学习大模型课程不仅能够提升个人技能，还能为企业带来现实效益，推动行业创新发展。
学习资料领取

假如你对大模型感兴趣，可以看看我整合并且整理成了一份AI大模型资料包，需要的小伙伴文末免费领取哦，无偿分享！！！
vx扫描下方二维码即可
加上后会一个个给各人发

部分资料展示

一、 AI大模型学习门路图

整个学习分为7个阶段

二、AI大模型实战案例

涵盖AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师，还是对AI大模型感兴趣的爱好者，皆可用。

三、视频和册本PDF合集

从入门到进阶这里都有，跟着老师学习事半功倍。

四、LLM口试题

假如二维码失效，可以点击下方链接，一样的哦
【CSDN大礼包】最新AI大模型资源包，这里全都有！无偿分享！！！