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

专业性不足：作为通用大模型，对专业领域知识的训练不足，可能会产生虚假陈述、准确性不足以及信息丰富度不足的问题。

时效性问题：模型的训练数据基于某个时间之前的数据，缺乏最新的信息，每次添加新数据都会导致高昂的训练成本。

安全性问题：模型无法访问企业内部私密文档，且这些文档不能直接用于 Fine-Tuning。

Fine-Tuning（微调）：使用特定领域的知识对基础大模型进行微调，以改变神经网络参数的权重。虽然适用于特定任务或风格，但需要大量资源和高质量的训练数据。

Prompt 工程：将行业领域的知识作为输入消息提供给模型，让模型对消息中的知识进行分析和处理。这种方法在正确性和精度上表现良好，但有文本长度限制，对于大规模数据不够高效。

与传统搜索结合：使用传统搜索技术构建基础知识库，然后使用大语言模型处理用户请求，对召回结果进行二次加工。这种方法具有更高的可控性和效率，并适用于大规模数据。

数据源加载和解析：主要使用 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 作为向量数据库。

用户问题向量化：对用户的问题进行向量化计算。如果结果在缓存中命中，将从缓存中获取已经缓存的答案，以减少文心大模型 API 费用和提高响应速度，可使用 GPTCache 等库来实现。

向量检索：使用 Embeddings 模型在向量数据库中进行相似性计算，召回相似度最高的 n 个分片。目前设置的召回策略是默认选择前 10 个评分最高的分片。

Prompt 生成：将 n 个切片和用户原始 Question 组装成 Prompt。需要注意的是，Prompt 不能超出 Token 限制，超出限制则需要进行优化，例如淘汰或多次迭代调用等。我们在 Prompt 中除了原始问题和内容，还对大模型加入了回答内容的限制，如「不允许在答案中添加编造成分」、「请用中文回答」等。此外，我们还提供记忆功能，将历史会话信息传入 Prompt，一并发送给大模型。

大模型响应：将 Prompt 发送给大模型，获取最终的结果。同时，将对话信息和结果追加存储到 MySQL 中，以保存会话历史，这有助于会话重启和历史信息接入大模型。

分割模型：由于训练的文档主要是中文文档，因此切片工具必须具备对中文的良好支持。为此，我们首选 Spacy 作为分割工具，并采用 zh_core_web_sm 模型作为标记器（tokenizer）。

分割条件：一般情况下，大部分系统会使用 LangChain 定长切分，但这样会丢失大部分上下文关联，知识点也是割裂的。在实践中，我们没有仅仅依赖 chunk size 作为唯一的切割条件，而是对那些具有明显段落或章节结构的文本格式（如 Markdown 或 HTML）进行了格式化分割，以确保文本的连续性、相关性和完整性。当段落超过 Embedding token 数限制时，我们会使用 RecursiveCharacterTextSplitter 对段落继续进行切分，切分条件除了设置换行符外，还加入了中文常见的断句符号，比如分号、叹号等。

标题补偿：当某段文字的大小超过了 chunk size 时，我们会针对没有标题的 chunk 补充标题，以确保整体切分的完整性。

标题向量化：在进行精细化切分之后，标题的重要性显现出来。因此，我们在这一阶段对标题进行向量化处理。这一方法适用于帮助手册、 HTML 和 Markdown 等文本格式。

内容关键字向量化：如果仅对标题进行向量化，对于那些标题概括性较差或段落内容丰富的情况，精召率提升仍然有限。因此，我们还尝试了了另一种方法，即首先利用大型模型或关键字模型提取关键字，数量通常限制在 10 左右，然后对这些关键字进行向量化处理。由于多轮次调用的耗时和关键字提取的可靠性问题，最终该方案被放弃。

标题 + 内容同时向量化：在文本分割时，我们强行对每个分片加入了标题。在向量化时，会将标题 + 内容打包一并进行向量化。我们将用户提问向量化后，和向量化后的切片进行检索匹配，选择与问题最相关的 topN 切片，这样可以显著提高精召率，这也是我们最终的方案。

取舍：如果选择的 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 以获取最终答案。这一流程有效地扩展了上下文长度，但是实际应用效果并不理想，表现为最终结果失真，尤其是在回答流程类问题场景下。主要原因是汇聚后丢失了很多原始文本细节。

提取问题关键字：首先从客户问题中提取关键字，以确保这些关键字能够准确地用于搜索引擎检索。为此，我们探索了两种不同的方法：

搜索引擎检索和文档解析：为了获得与数据库问题相关的准确答案，我们评估了以下两种不同的策略：

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

Database Chat：除了类似于 ChatGPT 问答界面外，还具备知识管理、用户管理等功能。（该功能已经集成数据库智能驾驶舱 DBSC 中，将于 3 月底正式开放上线）

IM 机器人：IM 工具做为工作协同中最重要的软件，使用频率非常高。我们提供了 IM 接入接口，客户可以开发 IM 软件（微信、飞书、如流等）机器人，在聊天群中实现快速高效获取信息和知识。