当前位置:   article > 正文

LLM与数据分析_数据分析 llm

数据分析 llm

写在前面

本文主要以LLM的应用为基础,说明LLM与数据开发、数据分析领域的相关工作以及未来可能存在的发展。

1.基于向量数据库的prompt工程

问题背景

大模型能够回答较为普世的问题,但是若要服务于垂直领域,会存在知识深度和时效性不足的问题,那么企业如何抓住机会并构建垂直领域服务?
ChatGPT对Doris的回答
目前有两种模式,第一种是基于大模型之上做垂直领域模型的Fine Tune,这个综合投入成本较大,更新的频率也较低,并不适用于所有的企业;第二种就是在向量数据库中构建企业自有的知识资产,通过大模型+向量数据库来搭建垂直领域的深度服务,本质是使用数据库进行提示工程(Prompt Engineering)。
在这里插入图片描述
上图显示了使用向量数据库搭建问答系统的基本框架。
1、用户的question通过embedding后通过词向量数据库查询与之相关的信息,产生konwledge。
2、用户的question和产生的konwledge一起喂给LLM,然后产生answer。
知识库的构成则由document转为向量,然后存储在向量数据库中。

向量数据库概述

  • 搜索

在传统数据库,搜索功能都是基于不同的索引方式(B Tree、倒排索引等)加上精确匹配和排序算法(BM25、TF-IDF)等实现的。本质还是基于文本的精确匹配,这种索引搜索算法对于关键字的搜索功能非常合适,但对于语义搜索功能就非常弱。

例如,如果你搜索“小狗”,那么你只能得到带有“小狗”关键字相关的结果,而无法得到“柯基”、“金毛”等结果,因为“小狗”和“金毛”是不同的词,传统数据库无法识别它们的语义关系,所以传统的应用需要人为的将“小狗”和“金毛”等词之间打上特征标签进行关联,这样才能实现语义搜索,因此,向量数据库的核心在于相似性搜索(Similarity Search)

高效的搜索算法有很多,其主要思想是通过两种方式提高搜索效率:
1、减少向量大小——通过降维或减少表示向量值的长度。
2、缩小搜索范围——可以通过聚类或将向量组织成基于树形、图形结构来实现,并限制搜索范围仅在最接近的簇中进行,或者通过最相似的分支进行过滤。
参考链接:向量数据库技术鉴赏

  • 索引

在实际的业务场景中,往往不需要在整个向量数据库中进行相似性搜索,而是通过部分的业务字段进行过滤再进行查询。所以存储在数据库的向量往往还需要包含元数据,例如用户 ID、文档 ID 等信息。这样就可以在搜索的时候,根据元数据来过滤搜索结果,从而得到最终的结果。

为此,向量数据库通常维护两个索引:一个是向量索引,另一个是元数据索引。然后,在进行相似性搜索本身之前或之后执行元数据过滤,但无论哪种情况下,都存在导致查询过程变慢的困难。

过滤过程可以在向量搜索本身之前或之后执行,但每种方法都有自己的挑战,可能会影响查询性能:

  • Pre-filtering:在向量搜索之前进行元数据过滤。虽然这可以帮助减少搜索空间,但也可能导致系统忽略与元数据筛选标准不匹配的相关结果。
  • Post-filtering:在向量搜索完成后进行元数据过滤。这可以确保考虑所有相关结果,在搜索完成后将不相关的结果进行筛选。

为了优化过滤流程,向量数据库使用各种技术,例如利用先进的索引方法来处理元数据或使用并行处理来加速过滤任务。平衡搜索性能和筛选精度之间的权衡对于提供高效且相关的向量数据库查询结果至关重要。

  • 现有向量数据库调研
向量数据库URLGitHub StarLanguageCloud
chromahttps://github.com/chroma-core/chroma7.4KPython
milvushttps://github.com/milvus-io/milvus21.5KGo/Python/C++
pineconehttps://www.pinecone.io/
qdranthttps://github.com/qdrant/qdrant11.8KRust
typesensehttps://github.com/qdrant/qdrant12.9KC++
weaviatehttps://github.com/weaviate/weaviate6.9KGo
  • 传统数据库的扩展
    除了选择专业的向量数据库,使用传统数据库进行扩展也是一种方法。类似 Redis 除了传统的 Key Value 数据库用途外,Redis 还提供了 Redis Modules,这是一种通过新功能、命令和数据类型扩展 Redis 的方式。例如使用 RediSearch 模块来扩展向量搜索的功能。

    同理的还有 PostgreSQL 的扩展,PostgreSQL 提供使用 extension 的方式来扩展数据库的功能,例如 pgvector 来开启向量搜索的功能。它不仅支持精确和相似性搜索,还支持余弦相似度等相似性测量算法。最重要的是,它是附加在 PostgreSQL 上的,因此可以利用 PostgreSQL 的所有功能,例如 ACID 事务、并发控制、备份和恢复等。还拥有所有的 PostgreSQL 客户端库,因此可以使用任何语言的 PostgreSQL 客户端来访问它。可以减少开发者的学习成本和服务的维护成本。

milvus介绍

Milvus 是一款云原生向量数据库,它具备高可用、高性能、易拓展的特点,用于海量向量数据的实时召回。

Milvus 基于 FAISS、Annoy、HNSW 等向量搜索库构建,核心是解决稠密向量相似度检索的问题。在向量检索库的基础上,Milvus 支持数据分区分片、数据持久化、增量数据摄取、标量向量混合查询、time travel 等功能,同时大幅优化了向量检索的性能,可满足任何向量检索场景的应用需求。通常,建议用户使用 Kubernetes 部署 Milvus,以获得最佳可用性和弹性。

Milvus 采用共享存储架构,​存储计算完全分离​,计算节点支持横向扩展。从架构上来看,Milvus 遵循数据流和控制流分离,整体分为了四个层次,分别为接入层(access layer)、协调服务(coordinator service)、执行节点(worker node)和存储层(storage)。各个层次相互独立,独立扩展和容灾。

  • 接入层(Access Layer):系统的门面,由一组无状态 proxy 组成。对外提供用户连接的 endpoint,负责验证客户端请求并合并返回结果
  • 协调服务(Coordinator Service):系统的大脑,负责分配任务给执行节点。协调服务共有四种角色,分别为 root coord、data coord、query coord 和 index coord。
角色名称作用
root coord负责处理数据定义语言(DDL)和数据控制语言(DCL)请求。比如,创建或删除 collection、partition、index 等,同时负责维护中心授时服务 TSO 和时间窗口的推进
query coord负责管理 query node 的拓扑结构和负载均衡以及从增长的 segment 移交切换到密封的 segment
data coord负责管理 data node 的拓扑结构,维护数据的元信息以及触发 flush、compact 等后台数据操作
index coord负责管理 index node 的拓扑结构,构建索引和维护索引元信息
  • 执行节点(Worker Node):系统的四肢,负责完成协调服务下发的指令和 proxy 发起的数据操作语言(DML)命令。执行节点分为三种角色,分别为 data node、query node 和 index node。
角色名称作用
Query node通过订阅消息存储(log broker)获取增量日志数据并转化为 growing segment,基于对象存储加载历史数据,提供标量 + 向量的混合查询和搜索功能。
Data node通过订阅消息存储获取增量日志数据,处理更改请求,并将日志数据打包存储在对象存储上实现日志快照持久化
Index node负责执行索引构建任务。Index node 不需要常驻于内存,可以通过 serverless 的模式实现
  • 存储服务 (Object Storage): 系统的骨骼,负责 Milvus 数据的持久化,分为元数据存储(meta store)、消息存储(log broker)和对象存储(object storage)三个部分。
角色名称作用
meta store负责存储元信息的快照,比如:集合 schema 信息、节点状态信息、消息消费的 checkpoint 等。元信息存储需要极高的可用性、强一致和事务支持,因此,etcd 是这个场景下的不二选择。除此之外,etcd 还承担了服务注册和健康检查的职责。
log broker负责存储日志的快照文件、标量 / 向量索引文件以及查询的中间处理结果。Milvus 采用 MinIO 作为对象存储,另外也支持部署于 AWS S3 和 Azure Blob 这两大最广泛使用的低成本存储。但是,由于对象存储访问延迟较高,且需要按照查询计费,因此 Milvus 未来计划支持基于内存或 SSD 的缓存池,通过冷热分离的方式提升性能以降低成本。
object storage负责存储日志的快照文件、标量 / 向量索引文件以及查询的中间处理结果。Milvus 采用 MinIO 作为对象存储,另外也支持部署于 AWS S3 和 Azure Blob 这两大最广泛使用的低成本存储。但是,由于对象存储访问延迟较高,且需要按照查询计费,因此 Milvus 未来计划支持基于内存或 SSD 的缓存池,通过冷热分离的方式提升性能以降低成本。

在这里插入图片描述

实践案例

现阶段存在诸多的向量数据库结合LLM进行使用,有点百家曾鸣的意思,本节以阿里云的AnalyticDB PostgreSQL作为实践案例进行说明。ChatBot模型的整体架构框架如下:
在这里插入图片描述
整个过程主要有两个流程:前端问答流程+后端数据处理和存储流程。底层主要依赖两个模块:基于大语言模型的推理模块+基于向量数据库的向量数据管理模块。

前端问答流程

  • Part1. 问题提炼:
    这个部分是可选的,之所以存在是因为有些问题是需要依赖于上下文的。因为用户问的新问题可能没办法让LLM理解这个用户的意图。比如用户的新问题是"它能做什么"。LLM并不知道它指的是谁,需要结合之前的聊天历史。LLM没法正确回答"它有什么用"这样的模糊问题,但是能正确回答"Doris有什么用"这样的独立问题。如果你的问题本身就是独立的,则不需要这个部分。得到独立问题后,我们可以基于这个独立问题,来求取这个独立问题的embedding。然后去向量数据库中搜索最相似的向量,找到最相关的内容。这个行为在Part2 Retrieval Plugin的功能中。
  • Part2. 向量检索:
    独立问题求取embedding这个功能会在text2vec模型中进行。在获得embedding之后就可以通过这个embedding来搜索已经事先存储在向量数据库中的数据了。比如我们已经在ADB-PG中存储了下面内容。我们就可以通过求取的向量来获得最相近的内容或者知识,比如第一条和第三条。
idContentembeddingdocument
1Doris是…[0.1, -0.1,0,1]OLAP数据库Doris
2NBA比分 湖人-篮网[0.2,0.1,0.2,-1]NBA今日播报
3Doris可以帮助我们XXX[0.2,0.1,0.2,-1]OLAP数据库Doris
4AIGC是xxx[0.2,0.1,0.2,-1]AIGC介绍
  • Part3. 推理求解
    在获得最相关的知识之后,我们就可以就可以让LLM基于最相关的知识和独立问题来进行求解推理,得到最终的答案了。这里就是结合“Doris是…”,“Doris可以帮助我们xxx”等等最有效的信息来回答“Doris有什么用”这个问题了。最终让GPT的推理求解大致是这样:
基于以下已知信息,简洁和专业的来回答用户的问题。
   如果无法从中得到答案,请说"根据已知信息无法回答该问题"或"没有提供足够的相关信息",不允许在答案中添加
编造成分,答案请使用中文。
已知内容:
   1.Apache Doris产生与PALO...
   2.Doris可以帮助我们xxx
问题:
   Doris有什么用
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8

后端数据处理和存储流程

  • Step1:先将原始文档中的文本内容全部提取出来。然后根据语义切块,切成多个chunk,可以理解为可以完整表达一段意思的文本段落。在这个过程中还可以额外做一些元数据抽取,敏感信息检测等行为。
  • Step2:将这些Chunk都丢给embedding模型,来求取这些chunk的embedding。
  • Step3:将embedding和原始chunk一起存入到向量数据库中。

ADB-PG建表举例说明
假设有一个文本知识库,它是将一批文章分割成chunk再转换为embedding向量后入库的,其中chunks表包含以下字段:

字段类型说明
idserial编号
chunkvarchar(1024)文章切块后的文本chunk
intimetimestamp文章的入库时间
urlvarchar(1024)文本chunk所属文章的链接
featurereal[]文本chunk embedding向量

2.LLM应用于探索性数据分析

本节主要对微软在探索式数据分析(Exploratory Data Analysis,EDA)领域的研究工作进行汇总。该项研究相关成功以及发表在SIGMOD等全球顶会上,起对应的工作也已经应用于Microsoft Excel、Microsoft Power BI和Microsoft Forms等微软产品中。

探索性数据分析(EDA)与传统统计分析(Classical Analysis)的区别

  • 传统的统计分析通常是先假设样本服从某种分布,然后把数据套入假设模型再做分析。
  • 探索性数据分析方法重视数据的真实分布,强调数据的可视化,使分析者能一目了然看出数据中隐含的规律,从而得到启发,以此帮助分析者找到适合数据的模型。

QuickInsights

论文链接:https://dl.acm.org/doi/10.1145/3299869.3314037

数据洞察(Data insight):“insight” 是指从多维数据中发现的 interesting data pattern(有趣的数据模式),它反映了数据在某种特定视角下的有趣特征。

insight建模

数据模型:给定多维数据集 R ( D , M ) \R(\mathcal{D},\mathcal{M}) R(D,M),其中 D = { D 1 , … , D d } \mathcal{D}=\{D_1,…,D_d\} D={D1,Dd} 表示维度的集合, M \mathcal{M} M 表示度量的集合。那么, d o m ( D i ) dom(D_i) dom(Di) 表示 D i D_i Di 的空间,例如如果 D i = D_i= Di= 性别,那么 d o m ( D i ) = { 男、女 } dom(D_i)=\{男、女\} dom(Di)={男、女}
在这里插入图片描述
insight的定义:声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/花生_TL007/article/detail/480379

推荐阅读