赞
踩
本文主要以LLM的应用为基础,说明LLM与数据开发、数据分析领域的相关工作以及未来可能存在的发展。
大模型能够回答较为普世的问题,但是若要服务于垂直领域,会存在知识深度和时效性不足的问题,那么企业如何抓住机会并构建垂直领域服务?
目前有两种模式,第一种是基于大模型之上做垂直领域模型的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 等信息。这样就可以在搜索的时候,根据元数据来过滤搜索结果,从而得到最终的结果。
为此,向量数据库通常维护两个索引:一个是向量索引,另一个是元数据索引。然后,在进行相似性搜索本身之前或之后执行元数据过滤,但无论哪种情况下,都存在导致查询过程变慢的困难。
过滤过程可以在向量搜索本身之前或之后执行,但每种方法都有自己的挑战,可能会影响查询性能:
为了优化过滤流程,向量数据库使用各种技术,例如利用先进的索引方法来处理元数据或使用并行处理来加速过滤任务。平衡搜索性能和筛选精度之间的权衡对于提供高效且相关的向量数据库查询结果至关重要。
向量数据库 | URL | GitHub Star | Language | Cloud |
---|---|---|---|---|
chroma | https://github.com/chroma-core/chroma | 7.4K | Python | ❌ |
milvus | https://github.com/milvus-io/milvus | 21.5K | Go/Python/C++ | ✅ |
pinecone | https://www.pinecone.io/ | ❌ | ❌ | ✅ |
qdrant | https://github.com/qdrant/qdrant | 11.8K | Rust | ✅ |
typesense | https://github.com/qdrant/qdrant | 12.9K | C++ | ❌ |
weaviate | https://github.com/weaviate/weaviate | 6.9K | Go | ✅ |
Milvus 是一款云原生向量数据库,它具备高可用、高性能、易拓展的特点,用于海量向量数据的实时召回。
Milvus 基于 FAISS、Annoy、HNSW 等向量搜索库构建,核心是解决稠密向量相似度检索的问题。在向量检索库的基础上,Milvus 支持数据分区分片、数据持久化、增量数据摄取、标量向量混合查询、time travel 等功能,同时大幅优化了向量检索的性能,可满足任何向量检索场景的应用需求。通常,建议用户使用 Kubernetes 部署 Milvus,以获得最佳可用性和弹性。
Milvus 采用共享存储架构,存储计算完全分离,计算节点支持横向扩展。从架构上来看,Milvus 遵循数据流和控制流分离,整体分为了四个层次,分别为接入层(access layer)、协调服务(coordinator service)、执行节点(worker node)和存储层(storage)。各个层次相互独立,独立扩展和容灾。
角色名称 | 作用 |
---|---|
root coord | 负责处理数据定义语言(DDL)和数据控制语言(DCL)请求。比如,创建或删除 collection、partition、index 等,同时负责维护中心授时服务 TSO 和时间窗口的推进 |
query coord | 负责管理 query node 的拓扑结构和负载均衡以及从增长的 segment 移交切换到密封的 segment |
data coord | 负责管理 data node 的拓扑结构,维护数据的元信息以及触发 flush、compact 等后台数据操作 |
index coord | 负责管理 index node 的拓扑结构,构建索引和维护索引元信息 |
角色名称 | 作用 |
---|---|
Query node | 通过订阅消息存储(log broker)获取增量日志数据并转化为 growing segment,基于对象存储加载历史数据,提供标量 + 向量的混合查询和搜索功能。 |
Data node | 通过订阅消息存储获取增量日志数据,处理更改请求,并将日志数据打包存储在对象存储上实现日志快照持久化 |
Index node | 负责执行索引构建任务。Index node 不需要常驻于内存,可以通过 serverless 的模式实现 |
角色名称 | 作用 |
---|---|
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模型的整体架构框架如下:
整个过程主要有两个流程:前端问答流程+后端数据处理和存储流程。底层主要依赖两个模块:基于大语言模型的推理模块+基于向量数据库的向量数据管理模块。
前端问答流程
id | Content | embedding | document |
---|---|---|---|
1 | Doris是… | [0.1, -0.1,0,1] | OLAP数据库Doris |
2 | NBA比分 湖人-篮网 | [0.2,0.1,0.2,-1] | NBA今日播报 |
3 | Doris可以帮助我们XXX | [0.2,0.1,0.2,-1] | OLAP数据库Doris |
4 | AIGC是xxx | [0.2,0.1,0.2,-1] | AIGC介绍 |
基于以下已知信息,简洁和专业的来回答用户的问题。
如果无法从中得到答案,请说"根据已知信息无法回答该问题"或"没有提供足够的相关信息",不允许在答案中添加
编造成分,答案请使用中文。
已知内容:
1.Apache Doris产生与PALO...
2.Doris可以帮助我们xxx
问题:
Doris有什么用
后端数据处理和存储流程
ADB-PG建表举例说明
假设有一个文本知识库,它是将一批文章分割成chunk再转换为embedding向量后入库的,其中chunks表包含以下字段:
字段 | 类型 | 说明 |
---|---|---|
id | serial | 编号 |
chunk | varchar(1024) | 文章切块后的文本chunk |
intime | timestamp | 文章的入库时间 |
url | varchar(1024) | 文本chunk所属文章的链接 |
feature | real[] | 文本chunk embedding向量 |
本节主要对微软在探索式数据分析(Exploratory Data Analysis,EDA)领域的研究工作进行汇总。该项研究相关成功以及发表在SIGMOD等全球顶会上,起对应的工作也已经应用于Microsoft Excel、Microsoft Power BI和Microsoft Forms等微软产品中。
探索性数据分析(EDA)与传统统计分析(Classical Analysis)的区别
论文链接:https://dl.acm.org/doi/10.1145/3299869.3314037
数据洞察(Data insight):“insight” 是指从多维数据中发现的 interesting data pattern(有趣的数据模式),它反映了数据在某种特定视角下的有趣特征。
数据模型:给定多维数据集
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的定义:
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。