布景

基于DB-GPT与Google Bard构建知识库问答系统

在人类开展历史上,有两样东西是持续伴随整个人类开展的, 1. 常识 2. 东西。大模型呈现之后,尤其是ChatGPT发布之后,因其具有的推理、逻辑才能,尤其是说不明,道不清的涌现才能,把AI的才能推向了一个新的层次。不仅仅引爆了整个科技圈,也跟着媒体铺天盖地的宣扬与烘托,被越来越多的用户所了解。 跟着环绕大模型的产品与运用的不断推出,十分多用户感受到了AI的魅力。在自然言语范畴,各种常识库、写作、文档东西正在改变大家的学习常识、文档检索与撰写的办法。 在多模态范畴,Midjourney,stable diffustion的体现也十分炽热,许多图形、规划类的作业也在发生者巨大的改变。

更令人惊喜的是最近秒鸭相机的出圈,让环绕大模型的运用与落地充满了等待。 一个崭新的年代,正在加速拉开帷幕,为咱们奉献精彩绝伦的表演。 处在年代中的咱们,是多么的走运,尤其是处在这个年代的开发者们,咱们正在见证也在深度参加一个伟大的年代,也亲眼目睹它的到来。

AIGC的大航海年代现已开启,热血的开发者们,想要大模型带来的财宝吗? 想要的话就去追逐吧,所有的财宝现已被放在大模型里边了,去解开它的秘密吧。扬起你的帆船,带上你的伙伴,去找吧~

One piece, we are coming~

基于DB-GPT与Google Bard构建知识库问答系统

扯远了,咱们言归正传 ,在本文中,咱们首要介绍DB-GPT的一些才能以及扼要的运用手册,同时怎么依据DB-GPT与Google Bard在本地跑一个常识库问答体系。

功用概览

现在DB-GPT现已发布了多种要害的特性:

  • SQL 言语才能, SQL生成、确诊
  • 私域问答与数据处理
    • 常识库办理(现在支撑 txt, pdf, md, html, doc, ppt, and url)
    • 数据库常识问答
    • 数据处理
  • 数据库对话
  • Chat2Dashboard
  • 插件模型
    • 支撑自定义插件履行使命,原生支撑Auto-GPT插件。如:
    • SQL主动履行,获取查询成果
    • 主动爬取学习常识
  • 常识库一致向量存储/索引
    • 非结构化数据支撑包含PDF、MarkDown、CSV、Word、Txt、PPT、WebURL等等
  • 多模型支撑, 支撑多种大言语模型, 当时已支撑如下模型:
    • Vicuna(7b,13b)
    • ChatGLM-6b(int4,int8)
    • guanaco(7b,13b,33b)
    • Gorilla(7b,13b)
    • llama-2(7b,13b,70b)
    • baichuan(7b,13b)

开源地址: github.com/eosphoros-a…

原生对话

原生对话是指大模型供给的原生才能,经过DB-GPT供给的一致对话界面能够完结与大模型的流式对话体验,感受大模型的才能。原生对话无需挑选任何场景,直接在下方的输入框傍边进行发问,即可感受原生对话的才能。 经过DB-GPT供给的一致ChatUI,能够丝滑体验大模型的才能。

基于DB-GPT与Google Bard构建知识库问答系统

常识库(Chat Knowledge)

DB-GPT中常识库,是指依据私域文档、数据进行问答与数据处理的才能,现在已支撑 txt、pdf、markdown、html、doc、ppt、csv多种文档类型。 同时在常识库办理上,DB-GPT供给了常识空间(Knowledge Space)。 在运用时首要经过常识空间,将文档、数据上传到常识空间做向量化

基于DB-GPT与Google Bard构建知识库问答系统

然后经过DB-GPT供给的常识库对话的才能,进行常识库对话。

基于DB-GPT与Google Bard构建知识库问答系统

编辑切换为居中

增加图片注释,不超过 140 字(可选)

在进行详细的常识库对话时,进入到对话场景之后,需求挑选对应的常识库空间。选中常识库空间之后,即可依据详细的常识库进行对话。

基于DB-GPT与Google Bard构建知识库问答系统

数据库对话(ChatDB)

数据库对话是指依据数据库傍边的元数据信息,例如表信息、索引信息、列信息等进行对话的才能。在实际运用进程中,能够依据这些元数据信息进行对话,能够出产可履行SQL、对指定SQL进行确诊、给出优化主张,SQL改写等。

基于DB-GPT与Google Bard构建知识库问答系统

假如需求切换数据库,在左下角进行切换即可。 依据数据库对话的才能,能够极大进步DBA、研制的提效。

数据对话(ChatData)

ChatData供给的数据对话的才能,是对ChatDB的才能做进一步主动化,即经过插件才能主动履行成果。 经过ChatData的才能,咱们能够更好的完结与数据库的交互,提高日常运用数据库时的功率,降低数据库运用门槛。

基于DB-GPT与Google Bard构建知识库问答系统

数据剖析(ChatDashboard)

ChatDashboard的才能也便是数据剖析才能。咱们能够经过自然言语交互的办法,完结报表制造,报表剖析等才能。当时ChatDashboard的才能受限与模型才能,在开源模型上的体现还十分差,需求切换到ChatGPT、Bard等署理模型才会有较好的体现作用。

基于DB-GPT与Google Bard构建知识库问答系统

插件(Plugin)

插件才能现在已支撑Auto-GPT插件模型,但考虑到开源模型在插件才能上较差的体现,相关才能暂未开放。

常识库才能介绍

当时才能

前面现已简略介绍了常识库相关才能的演示。 接下来咱们详细介绍一下常识库才能,并在没有GPU的情况下,怎么依据Google Bard 来构建自己的本地的常识库体系?

在DB-GPT项目中现已供给了AutoDL的镜像,假如想本地化布置开源大模型的同学,能够依照镜像在对应的平台上完结布置。 AutoDL镜像教程, 在DB-GPT中,关于常识库供给了完好的办理才能,包含:

  • 常识空间办理、文档上传、删除
  • 多文档类型支撑,包含PDF、MarkDown、CSV、Word、Txt、PPT、WebURL等
  • 常识向量操作与使命办理
  • 文档Embedding以及Chunk概况检查

常识库架构

在DB-GPT傍边,关于常识库相关的才能,咱们是经过ICL的办法进行规划与开发,为了能够让常识库的才能更强壮,同时充沛具有可拓展的才能,咱们在DB-GPT傍边规划了一套Embedding的引擎。 如同所示,各类常识经过DB-GPT-Embedding Engine之后,经过Embedding Engine供给的Loader-> Reader-> Process -> Embedding 整个数据管道的才能,能够轻松的完结各类数据的Embedding, 同时整个引擎也供给了可拓展的才能,能够按需进行自定义与拓展。

基于DB-GPT与Google Bard构建知识库问答系统

关于ICL,下面也有一张更详细的介绍图,大家能够据此来了解整个ICL的进程。这种形式在常识问答里边归于端对端形式,对传统的两阶段办法常识问答做了晋级。传统的两阶段办法首要分为召回阶段和阅览了解阶段。召回阶段中,运用传统的TF-IDF的办法回来评分最高的Top-K个文章片段。阅览了解阶段中,选用神经网络模型RNN将问题转化为序列标注问题,即关于给定文档中呈现的每个词,判别是否呈现在答案中。

大模型年代外挂本地常识库形式下在召回阶段用向量检索办法替代传统的TF-IDF的办法进行召回,用向量去召回是指将所有常识问答经过Embedding映射到一个固定维度的向量空间。当用户进行发问时,能够将这个问题经过相同的Embedding模型映射到相同维度的向量空间。在相同维度的向量空间中找到与问题语义类似的Top-K文档进行召回作为答案的候选项。在阅览了解阶段,经过大言语模型对收集到的问题+外挂常识一致吐给模型让其进行了解并回来终究的答案。

基于DB-GPT与Google Bard构建知识库问答系统

环绕着上面的外挂本地常识库办法论,DB-GPT在常识库也构建了常识库运用的api,运用文档。

基于DB-GPT与Google Bard构建知识库问答系统

如图所示, 整个常识库的架构首要分为3层:

embedding engine层

常识embedding客户端,包含怎么将文档常识knowledge_embedding办法导入向量数据库以及经过similar_search办法依据用户发问向量检索出类似度高的常识片段。

document_path = "your_path/test.md"
embedding_engine = EmbeddingEngine(
    knowledge_source=document_path,
    knowledge_type=KnowledgeType.DOCUMENT.value,
    model_name=embedding_model,
    vector_store_config=vector_store_config)
embedding_engine.knowledge_embedding()

knowledge source层

供给依据不同常识类型进行读取->切片->数据处理->转向量的pipeline, 每一步能够依照默认的完结办法,也能够可自定义的进行个性化处理。 此层具有必定的拓展性,能够不断地扩展常识类型,包含但不限于文档、视频、音频、数据库、数仓、目标存储等等。扩展办法都是经过继承SourceEmbedding然后按需完结

read()->data_process()->index_to_store()  整个PipeLine
  • read():常识的加载解析,这儿能够运用langchain的各种Loader,也能够自定义Loader进行完结。
  • data_proccess():数据预处理,能够依照自定义逻辑进行数据处理。
  • index_to_store():存入向量数据库,经过vector_store_config装备向量数据库连接参数
class SourceEmbedding(ABC):
    """base class for read data source embedding pipeline.
    include data read, data process, data split, data to vector, data index vector store
    Implementations should implement the  method
    """
    def __init__(
        self,
        file_path,
        vector_store_config: {},
        source_reader: Optional = None,
        text_splitter: Optional[TextSplitter] = None,
        embedding_args: Optional[Dict] = None,
    ):
        """Initialize with Loader url, model_name, vector_store_config"""
        self.file_path = file_path
        self.vector_store_config = vector_store_config
        self.source_reader = source_reader or None
        self.text_splitter = text_splitter or None
        self.embedding_args = embedding_args
        self.embeddings = vector_store_config["embeddings"]
    @abstractmethod
    @register
    def read(self) -> List[ABC]:
        """read datasource into document objects."""
    @register
    def data_process(self, text):
        """pre process data."""
    @register
    def text_splitter(self, text_splitter: TextSplitter):
        """add text split chunk"""
        pass
    @register
    def text_to_vector(self, docs):
        """transform vector"""
        pass
    @register
    def index_to_store(self, docs):
        """index to vector store"""
        self.vector_client = VectorStoreConnector(
            self.vector_store_config["vector_store_type"], self.vector_store_config
        )
        return self.vector_client.load_document(docs)

vector connector层

首要供给常识向量和向量数据库交互的才能,每一种详细的向量数据库注册到vector connector,让用户并不感知详细向量数据库的完结底层细节。相同地vector connector底层现在也只完结了Chroma, Milvus, Weaviate向量数据库,更多的向量数据库也能够经过横向扩展注册到vector connector中。

  • load_document():加载文档导入到向量数据库
  • similar_search():文档类似性查找
  • vector_name_exists:判别向量数据库名是否已存在
class VectorStoreConnector:
    """VectorStoreConnector, can connect different vector db provided load document api_v1 and similar search api_v1.
    1.load_document:knowledge document source into vector store.(Chroma, Milvus, Weaviate)
    2.similar_search: similarity search from vector_store
    how to use reference:https://db-gpt.readthedocs.io/en/latest/modules/vector.html
    how to integrate:https://db-gpt.readthedocs.io/en/latest/modules/vector/milvus/milvus.html
    """
    def __init__(self, vector_store_type, ctx: {}) -> None:
        """initialize vector store connector."""
        self.ctx = ctx
        self.connector_class = connector[vector_store_type]
        self.client = self.connector_class(ctx)
    def load_document(self, docs):
        """load document in vector database."""
        return self.client.load_document(docs)
    def similar_search(self, docs, topk):
        """similar search in vector database."""
        return self.client.similar_search(docs, topk)
    def vector_name_exists(self):
        """is vector store name exist."""
        return self.client.vector_name_exists()

本地实践

本文中,为了让开发者能够在本地丝滑的构建常识库的才能,咱们供给了依据Bard-Proxy的构建计划。接下来,咱们来详细看看怎么经过Bard-Proxy与DB-GPT快速建立超赞的本地的常识库体系。

Bard Proxy布置

在开始布置Bard Proxy之前,咱们简略讲一下为什么要用Bard,Google Bard最近支撑了中文,同时Google Bard不像ChatGPT需求注册才能运用,Google Bard经过VPN署理即可直接运用, 在运用进程中也不需求付费,没有严格的运用次数上限。因此在本地运用中,Google Bard是一个不错的挑选。

Bard-Proxy布置十分简略,仅有需求重视的点是,需求找一台能够访问Google的外网服务器,在腾讯云或许阿里云购买一台国外的服务器,然后布置Bard-Proxy即可完结署理布置。 Bard-Proxy的源码地址: github.com/eosphoros-a…

1. 下载源码

git clone github.com/eosphoros-a…

2. 登陆署理,检查自己的Bard Key,打开浏览器开发者形式(F12),在Application -> Cookies 下面找到对应的Key

打开bard.google.com/ 网站,或许对应的Cookie信息。

基于DB-GPT与Google Bard构建知识库问答系统

3. 经过Docker在阿里云或许腾讯云的外网服务器上布置Bard-Proxy

docker run -d --name bard_proxy -p 8671:8671 -e BARD_PROXY_API_KEY=YOUR-BARD-KEY shinexy/bard_proxy

经过上述进程,咱们即完结整个Bard-Proxy的布置,接下来,咱们看看怎么在DB-GPT中布置运用。

DB-GPT + Bard + 本地常识库

1. DB-GPT 署理形式布置

在开始之前,首要咱们装置一下DB-GPT依靠的MySQL,相同是经过Docker进行装置。

1.1. 装置MySQL

$ docker run --name=mysql -p 3306:3306 -e MYSQL_ROOT_PASSWORD=aa12345678 -dit mysql

# 初始化数据库信息
$ mysql -h127.0.0.1 -uroot -paa12345678 < ./assets/schema/knowledge_management.sql

1.2. 装置Python依靠

python>=3.10
conda create -n dbgpt_env python=3.10
conda activate dbgpt_env
pip install -r requirements.txt

1.3. 常识库前置依靠装置

python -m spacy download zh_core_web_sm

1.4. 下载Embedding向量模型

git clone https://huggingface.co/GanymedeNil/text2vec-base-chinese

在署理形式下,Embedding进程,即常识向量化的进程仍是本地进行的,所以需求一个embedding模型,text2vec-base-chinese 模型是中文场景下体现较好的模型。假如本地电脑装备较高,能够运用text2vec-large-chinese模型。

1.5. 环境变量装备

cp .env.template .env
# 修正变量值
LLM_MODEL=bard_proxyllm
EMBEDDING_MODEL=text2vec-base
PROXY_SERVER_URL=http://{bard_proxy服务器公网ip}:8671/api/bard/v1/chat/completions

1.6. 发动dbgpt-server

python pilot/server/dbgpt_server.py

基于DB-GPT与Google Bard构建知识库问答系统

如图所示,5000端口发动成功之后,即可访问DB-GPT了, http://127.0.0.1:5000

基于DB-GPT与Google Bard构建知识库问答系统

以上即依据Bard-Proxy布置DB-GPT的教程。 接下来,咱们简略介绍一下详细的运用。

运用指南

创建常识库

经过Knowledge Space,能够创建常识库。

基于DB-GPT与Google Bard构建知识库问答系统

导入常识文档

这儿常识文档现在分为3类,Text纯文本,WebUrl链接和文档类型,文档类型包含PDF, Markdown, Word, PPT, HTML和CSV,上传文档成功后后台会主动将文档内容进行读取,切片,然后导入到向量数据库中。

基于DB-GPT与Google Bard构建知识库问答系统

基于DB-GPT与Google Bard构建知识库问答系统

导入常识成功后,回来首页挑选Chat Knowledge,然后与常识库进行对话问答。

基于DB-GPT与Google Bard构建知识库问答系统

不足与改进

当时DB-GPT在常识问答作用上具有了常识库问答的才能,并供给了通用的底层模块,关于相对简略的问答场景,有较好的体现。但是在略微杂乱的问答场景上面,作用还比较差,首要体现在:

  • 直接将问题 + 类似性查找出文档当作上下文,常常因为提出问题的含糊性查找出匹配不相关的文档。这些不相关的文档会让模型推理出的答案有误。比方

Q:问题MySQL支撑哪些时刻函数? A: 除了时刻函数还有其他函数。

这儿有个思路便是预备一个问题集与答案集,将问题集向量化到向量数据库,依据用户供给的问题从问题集检索到最贴近的几个问题,然后获取每个问题集对应的答案,再将问题和答案交给大模型进行推理总结,这种计划的长处:能够必定程度进步模型答案的准确性,能够解决问题含糊性带来不相干文档的干扰。缺陷:需求预先预备大量的问题集和答案集。

  • 关于一些杂乱问题比方多常识点的比较问答,比方:

Q: 比照MySQL、OceanBase分别在布置架构、业务以及高可用上面的优缺陷?

假如直接依据初始问题进行Embedding然后进行向量检索出常识片段然后再丢给模型推理,作用十分不理想,尤其是在开源大模型上的体现。其中一种可选的思路是将问题进行拆解,也能够说要害词提取,经过拆解的要害词分别进行向量检索,比方能够拆解成MySQL布置架构的优缺陷,MySQL业务优缺陷,MySQL高可用优缺陷,OceanBase布置架构的优缺陷,OceanBase业务优缺陷,OceanBase高可用优缺陷。

基于DB-GPT与Google Bard构建知识库问答系统

将拆解后的问题进行embedding后经过大模型推理出每个问题的答案,然后再将初始问题和拆解后的问题+答案一起再丢给大模型进行推理出终究答案。这儿的涉及到的难点便是问题拆解以及多轮模型对话的交互,环绕以上问题咱们也正在依据CoT、ToT这样的技术手段来构建工程化的才能。

基于DB-GPT与Google Bard构建知识库问答系统

  • 现在开源模型答复还不够稳定。

这个问题是开源大模型的通病,首要不同的模型关于prompt上下文的灵敏程度是不一样的,或许prompt一点点变化都会导致模型答复的作用产生变化。下面是DB-GPT常识库在开源的一些大言语模型下简略的评测(针对部分LLM模型测验成果如下的评测(更多模型在集成中,测验作用很差的模型没有列举出来)

模型 ChatGLM-6B ChatGLM2-6B Vicuna-13B baichuan-7b
占用空间(G) 24 24 50 27
支撑中文
支撑上下文token 2k 8k 2k 4k
推理速度(字符/s) 31.49 44.62
问答作用 长处:1.推理速度快2.用户能够在消费级的显卡上进行本地布置缺陷:1.会胡说八道2.常识总结啰嗦 长处:1.推理速度快2.能接纳更大的上下文3.常识总结不啰嗦4.用户能够在消费级的显卡上进行本地布置缺陷:杂乱问答作用欠好 长处:1.杂乱使命比方text2sql, text2json体现还不错缺陷:1、推理速度慢2.总结性答复比较啰嗦3.上下文token支撑太小,简单呈现乱码 长处:1.推理速度比chatglm略微慢一点2.能接纳更大的上下文3.常识总结不啰嗦缺陷:1.杂乱问答作用欠好2.受prompt影响较大

小结

本文中首要介绍了,依据DB-GPT跟Google Bard构建本地常识库体系的教程,关于GPU缺少的同学,快速了解并上手大模型的才能。 假如在布置进程中有任何问题,或许有相关方向的评论,都能够来咱们社区参加评论,社区沟通地址:

总的来说在中文常识库问答场景下,ChatGLM2-6B模型在推理速度,推理稳定性,总结文档作用现在是开源模型里边体现较好的,Vicuna-13b尽管逻辑正确性与准确率较高,但推理速度,token长度等都体现较差。 baichuan-13b在中文场景下,也具有必定的优势,但还有待进步, 开源模型现在跟ChatGPT、Google Bard、Claude等比照,差距还很明显。 后面咱们也会经过工程 + 算法的才能将杂乱场景的常识答复的作用做更多的提高。

参阅

  • zhuanlan.zhihu.com/p/647033456
  • github.com/eosphoros-a…
  • github.com/eosphoros-a…
  • zhuanlan.zhihu.com/p/628750042
  • stablediffusionweb.com/
  • civitai.com/
  • zhuanlan.zhihu.com/p/628750042
  • zhuanlan.zhihu.com/p/629998078
  • zhuanlan.zhihu.com/p/639359512
  • zhuanlan.zhihu.com/p/642443023
  • bard.google.com/