向量数据库落地实践-京东云开发者社区

一、前言

本文基于京东内部向量数据库vearch进行实践。Vearch 是对大规模深度学习向量进行高性能相似搜索的弹性分布式系统。详见： https://github.com/vearch/zh_docs/blob/v3.3.X/docs/source/overview.rst

二、探索

初次认识向量数据库，一脸懵逼？

向量是什么？如何将文本转换为向量？如何确定维度？如何定义表结构？如何选择索引方式，建表参数如何配置？检索参数如何配置？分片数副本数如何选择等等

随着对文档的逐渐熟悉以及和vearch相关同事的沟通，以上问题迎刃而解，具体的不再赘述。主要记住以下几点：

1、文本转向量：采用大模型网关接口 domain/embeddings 传入对应的模型如：text-embedding-ada-002-2和待转换的文本即可；

2、向量维度：这个和向量转换所采用的模型有关，细节不用关注；

3、建表参数的选择以及表结构：主要在于retrieval_type 检索模型的选择，具体的可以参考文档。经过综合考虑，决定采用 HNSW：

字段标识	字段含义	类型	是否必填	备注
metric_type	计算方式	string	是	L2或者InnerProduct
nlinks	节点邻居数量	int	是	默认32
efConstruction	构图时寻找节点邻居过程中在图中遍历的深度	int	是	默认40

"retrieval_type": "HNSW",
"retrieval_param": {
    "metric_type": "InnerProduct",
    "nlinks": 32,
    "efConstruction": 40
}

注意: 1、向量存储只支持MemoryOnly
      2、创建索引不需要训练，index_size 值大于0均可

具体的建表示例见后文。

4、分片数和副本数结合实际数据量评估，如果无法评估，按照最少资源申请即可，后续可扩展。

三、实践

1、建表（space）

为了简化操作，实行db（库）-space（表）一对一的方案，弱化库的概念。经过一系列探索之后定义出了通用的space结构：

{
    "name": "demphah",
    "partition_num": 3,
    "replica_num": 3,
    "engine": {
        "name": "gamma",
        "index_size": 1,
        "id_type": "String",
        "retrieval_type": "HNSW",
        "retrieval_param": {
            "metric_type": "InnerProduct",
            "nlinks": 32,
            "efConstruction": 100,
            "efSearch": 64
        }
    },
    "properties": {
        "vectorVal": {
            "type": "vector",
            "dimension": 1536
        },
        "contentVal": {
            "type": "string"
        },
        "chunkFlagId": {
            "type": "string",
            "index": true
        },
        "chunkIndexId": {
            "type": "integer",
            "index": true
        }
    }
}

字段说明：

engine、partition_num等都是固定的参数，properties中所列字段皆为通用字段，如果有扩展字段如：skuId，storeId追加即可

字段名	含义	类型	说明
vectorVal	文本向量	vector	维度与选用模型有关
contentVal	源文本	string
chunkFlagId	文件唯一id	string	文件的标识id，用于串联分块后的片段
chunkIndexId	文件分段位置	integer	从0开始，递增
skuId ...			扩展字段见上

这里file的概念可以理解为一个单元，可能是一个文件，也可能是一个url，总之就是一个数据整体。

2、分段写入

这里针对通用文件描述，比如提供一个pdf文件如何导入向量库：

a. 首先上传文件到oss，然后根据对应的fileKey获取到文件数据流

b. 再根据各种拆分场景（按行、字节数、正则拆分等）分成片段

c. 分段写入向量库：

    /**
     * 将字符串转换为向量并插入数据库
     * <p>
     * 目前所有的知识库管理端写入全走这个方法
     *
     * @param dbName       数据库名称
     * @param spaceName    空间名称
     * @param str          字符串
     * @param flagId       标志ID
     * @param chunkIndexId 块索引ID
     * @param properties   属性
     */
    private void embeddingsAndInsert(String dbName, String spaceName, String str, String flagId, Integer chunkIndexId, Map<String, Object> properties) {
        // 先向数据库写入一条记录，记录当前文档的写入操作
        int success = knbaseDocRecordService.writeDocRecord(spaceName, flagId, chunkIndexId.longValue(), 0, str);
        if (success <= 0) {
            log.error("writeDocRecord失败 {},{},{}", spaceName, flagId, chunkIndexId);
        }

        // 分块转向量并写入
        List<Float> embeddings = GatewayUtil.baseEmbeddings(str);
        if (CollectionUtils.isEmpty(embeddings)) {
            return;
        }

        KnBaseVecDto knBaseVecDto = buildKnBaseVecDto(new FeaVector(embeddings),flagId,chunkIndexId,str);

        Map<String, Object> newPros = JsonUtil.obj2Map(knBaseVecDto);
        if (MapUtils.isNotEmpty(properties)) {
            newPros.putAll(properties);
        }
        // {"_index":"kn_base_file_db","_type":"kn_base_file_space","_id":"-8182839813441244911","status":200}
        String insert = VearchUtil.insert(dbName, spaceName, null, newPros);
        if (StringUtils.isBlank(insert) || !insert.contains("_index")) {
            log.error("写入失败的块：{},{}", chunkIndexId, insert);
        }
    }

3、数据记录

上文写知识库的过程有个 knbaseDocRecordService.writeDocRecord 的逻辑，用于记录写入的片段。下文详细介绍其中用到的mysql表：

1、表1 space记录表

注：主要用于记录创建的space，以及查询管控，如禁用某个space等

CREATE TABLE `xxx_vearch_spaces` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增主键',
  `type` tinyint(3) NOT NULL COMMENT '类型',
  `status` tinyint(3) NOT NULL COMMENT '状态',
  `space` varchar(127) NOT NULL COMMENT '空间标识',
  `db` varchar(127) NOT NULL COMMENT '库标识',
  `desc` varchar(127) NOT NULL COMMENT '空间描述',
  `ext` varchar(4095) NOT NULL DEFAULT '' COMMENT '扩展字段',
  `creator` varchar(127) NOT NULL DEFAULT '' COMMENT '创建人',
  `created` timestamp NOT NULL COMMENT '创建时间',
  `modifier` varchar(127) NOT NULL DEFAULT '' COMMENT '修改人',
  `modified` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间',
  `deleted` tinyint(3) NOT NULL DEFAULT '0' COMMENT '已删除(0:否;1:是)',
  PRIMARY KEY (`id`) USING BTREE,
  UNIQUE KEY `uniq_space_db` (`space`,`db`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=0 DEFAULT CHARSET=utf8mb4 COMMENT='xxx向量空间'

2、表2 file记录表

注：主要用于记录space下的file，以及查询管控，如禁用某个file，以及关联查询对应的全部片段。

CREATE TABLE `xxx_spaces_knbase` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增主键',
  `status` tinyint(3) NOT NULL COMMENT '状态',
  `space` varchar(127) NOT NULL COMMENT '空间标识',
  `file_name` varchar(255) NOT NULL COMMENT '文件名',
  `file_desc` varchar(511) NOT NULL COMMENT '文件描述',
  `byte_num` bigint(20) unsigned NOT NULL COMMENT '字符数',
  `hit_count` int(10) unsigned NOT NULL COMMENT '命中次数',
  `ext` varchar(4095) NOT NULL DEFAULT '' COMMENT '扩展字段',
  `creator` varchar(127) NOT NULL DEFAULT '' COMMENT '创建人',
  `created` timestamp NOT NULL COMMENT '创建时间',
  `modifier` varchar(127) NOT NULL DEFAULT '' COMMENT '修改人',
  `modified` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间',
  `deleted` tinyint(3) NOT NULL DEFAULT '0' COMMENT '已删除(0:否;1:是)',
  `file_flag_id` varchar(255) DEFAULT NULL COMMENT '文件唯一标识',
  PRIMARY KEY (`id`) USING BTREE,
  KEY `idx_space` (`space`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=0 DEFAULT CHARSET=utf8mb4 COMMENT='xxx空间知识库'

3、表3 paragraph记录表

注：主要用于记录file拆分的片段，包括当前位置，查询命中数等。

CREATE TABLE `xxx_knbase_doc_record` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增主键',
  `space` varchar(127) NOT NULL COMMENT '空间标识',
  `file_flag_id` varchar(255) NOT NULL COMMENT '文件标识',
  `d_index` bigint(20) unsigned NOT NULL COMMENT '文档位置',
  `hit_count` int(10) unsigned NOT NULL COMMENT '命中次数',
  `ext` varchar(4095) NOT NULL DEFAULT '' COMMENT '扩展字段',
  `creator` varchar(127) NOT NULL DEFAULT '' COMMENT '创建人',
  `created` timestamp NOT NULL COMMENT '创建时间',
  `modifier` varchar(127) NOT NULL DEFAULT '' COMMENT '修改人',
  `modified` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间',
  `deleted` tinyint(3) NOT NULL DEFAULT '0' COMMENT '已删除(0:否;1:是)',
  PRIMARY KEY (`id`) USING BTREE,
  UNIQUE KEY `uniq_space_file_idx` (`space`,`file_flag_id`,`d_index`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=0 DEFAULT CHARSET=utf8mb4 COMMENT='xxx知识文档记录'

四、总结

向量数据库对于大模型应用落地来说至关重要，有些不可外露的内部数据可以存储在向量库中，用于内部检索。随着向量库中数据的丰富，大模型推理回答的能力也将更加精准。

上文的设计比如space中的chunkFlagId可以关联出原始的整个文件；chunkIndexId可以控制数据的查询范围，另一方面可以通过此字段实现分页（vearch目前不支持分页查询）以及全文导出。xxx_knbase_doc_record表中记录了片段的记录，可用于计算片段的chunkIndexId，一方面避免重复，另一方面保证属性的递增，可用于扩展很多能力。

目前向量数据库的检索只支持基本的向量检索和关键字检索，后续会逐步优化混合检索等方案以提高检索准确率等。