星环科技向量数据库从 0 到 1 技术实践：提升数据处理的精确度是重中之重

大模型擅长理解和生成类人文本，它们将文本转换为高维向量（也称为嵌入）来捕获文本的语义。这种转换使得对文本执行复杂的操作成为可能，例如查找相似的单词、句子或文档，这些是聊天机器人、推荐引擎等许多应用程序不可或缺的一部分。这些向量表示的性质需要一个有效的存储解决方案来处理索引和查询嵌入，这就是向量数据库的用武之地。

尽管传统的 NLP 模型依赖于 Word2Vec、Global Vectors for Word Representation ( GloVe ) 等技术，但像 GPT-3 这样的 Transformer 模型会创建上下文化的词嵌入。这意味着单词的词嵌入可以根据使用它的上下文而改变。

每个大语言模型都使用不同的机制来生成词嵌入 / 向量。例如，OpenAI 的 text-embedding-ada-002 模型旨在生成与 text-davinci-003 和 gpt-turbo-35 模型变体一起使用的词嵌入。类似地，Google 的 PaLM 2 使用 embedding-gecko-001 模型来生成嵌入向量。

语言模型，特别是 GPT-4 和 LLaMa 等大型语言模型 (LLM)，在塑造数据管理的未来方面发挥着关键作用，特别是推动了一种称为向量数据库的新型数据库的采用。

那么，大模型时代，向量数据库为何如此重要，目前国内向量数据库产业的现状以及所面临的技术挑战都是什么？本期《极客有约》，我们邀请到了星环科技基础架构部副总经理刘熙，请他与我们共同探讨目前业内较为关心对关于向量数据库的一些话题。

以下为访谈实录，经编辑。

刘熙： 大家好，我是刘熙，来自星环科技基础架构产品部。我已在星环科技工作达 10 年，一直从事数据库方面的研究。在这段时间里，我积累了丰富的工作经验，涵盖了非关系型数据库、新型关系型数据库、数据仓库、搜索引擎、时序数据库等产品领域。目前，我主要领导着向量数据库团队。非常感激 InfoQ 能够为我提供这个宝贵的机会，与各位进行深入交流，再次表示诚挚的谢意。

刘熙： 我们星环向量数据库团队在星环内部显得颇具特色，因为我们涵盖了人工智能领域的数据库与数据应用。我们一直与星环的人工智能团队密切合作，汇聚了不少人工智能专家以及安全领域的专业人才。总体而言，我们团队被内部称作虚拟团队，因为我们涵盖了多个不同领域的专业知识，横跨多个领域的协作。

刘熙： 确切地说，我们的主要目标是将向量数据库打造得更为优越。在这一过程中，我们汇聚了 AI 领域的专业人才以及数据库和安全领域的专家。鉴于如今大模型备受瞩目，星环科技一直致力于为用户提供一站式解决方案，因此我们还与从事大型模型领域的同事协作。一般而言，研发团队都具备自身的专业背景，难以找到单一的研发团队或部门，能够涵盖 AI、安全、数据库以及大型模型等多个领域。因此，我们的内部组织形式是一个团队，专注于向量数据库，但团队成员来自不同的技术部门。换言之，团队中的许多成员并没有直接的人事汇报关系，但我们一同致力于向量数据库的发展。

刘熙： 当谈到我们团队的要求时，有几个关键点需要强调。首先，向量数据库是一个相对新兴的领域，因此我们希望团队成员对技术充满热情。当面临技术难题时，能够保持对解决方案的浓厚兴趣，并主动深入探究。

其次，我们公司一直强调客户至上的价值观。在团队中，我们鼓励每位成员始终将客户需求放在首位。

第三，良好的编码能力和团队沟通能力也是我们考察的要点。除了技术技能，我们同样注重通用软技能的发展。

刘熙： 我认为"AI 向量数据库"这个概念非常切合实际，它类似于关系数据库在交易领域的作用。个人观点是，向量数据库实际上是为了人工智能而生的。一方面，向量数据库的数据完全源自于人工智能技术。另一方面，对于 AI 应用而言，向量数据库也是至关重要的基础设施。

至于和我们日常理解的数据库有何不同，我简单解释一下。传统数据库主要处理数值和字符类型的数据，通常是高质量的关系型表。当然，现在也有许多处理半结构化数据（如 JSON 数据）的数据库，例如 MongoDB、Elasticsearch 等。然而，这些数据的语义通常只表现在表面，没有深层次的含义。

向量数据库则与众不同，它处理的是非结构化数据，如图片、视频、长文本和音频等。这些数据的意义不在于其物理表示，并不仅仅是一堆字节，真正有意义的地方在于隐藏的语义。

与传统数据库不同，我们无法通过数据库直接处理语义问题。那么，数据库如何解决这个问题呢？我们采用了 AI 技术，例如典型的神经网络，来识别、提取和编码非结构化数据背后的语义特征。最终，我们将这种数据的语义映射或嵌入到高维的向量空间中。这样做有什么好处呢？这实际上将数据库无法直接处理的语义问题，转化为向量空间中的一个搜索问题。简而言之，我们利用 AI 技术将数据库无法直接处理的数据背后的语义转化为一个结构化的过程。

在处理非结构化数据时，我们通常不仅提取特征向量这一个维度，还会提取一些结构化的属性标签。举个例子，我们正在开发的金融大模型，从财经新闻中通过实体识别算法提取企业法人等信息。这些信息并不仅仅是向量，它们更像是一些属性标签。类似地，在以前的电商中，对于商品图片，除了特征向量外，还可能提取价格、颜色等结构化标签。

因此，可以说没有 AI 技术，就不会有向量数据库这样细分的数据库品类。另一方面，为什么向量数据库如此重要呢？您之前也提到了近期向量数据库的火爆。实际上，向量数据库能够很好地解决 AI 技术落地的问题。

大模型近来非常受关注，但 OpenAI 自己也明确指出，大模型的能力是有限的。它无法回答它从未见过的问题，即无法回答训练语料库中没有的知识。例如，一些私密数据或专业领域的数据，通常不会存在于通用语料库中。因此，当面对需要回答专业问题的情况时，大模型可能会提供错误答案。

在以前的小模型时代，我们通常会进行精细调整，但如今的模型参数可能达到数千亿、万亿级别。在这种情况下，精细调整的成本非常高，并且无法解决大模型无法获取最新数据的问题。因此，OpenAI 提出了一个解决方案：将知识从大模型中分离出来，引入向量数据库，实际上为大模型添加了一个记忆单元，这就是所谓的大模型 + 向量数据库 +Prompt（MVP）架构。在这种架构下，整个大模型的技术实现更加容易。

通过使用向量数据库，我们可以处理私密数据或更新数据，并且可以更好地控制数据的安全性。因此，向量数据库作为一种基础的 AI 设施，可以有效地解决 AI 技术在实际应用中的问题。综上，可以看出向量数据库与 AI 的关系非常密切。它源自 AI，同时又为解决 AI 技术应用问题提供了有效的解决方案。以上就是我们对向量数据库的理解。

刘熙： 关于向量数据库，我坚信它确实是迫切需求。刚开始时你也提到了，向量数据库在大模型兴起之前可能并没有受到特别大的关注。然而，现在来看，向量数据库在技术方面的重要性是不容忽视的。它并不仅仅是一个产品形态，如今许多厂商也纷纷进入市场，提供向量数据库产品。实际上，在国内，向量数据库的技术已经得到了广泛的应用。我们自己就一直在使用向量数据库，此外还有一些大型企业也在使用，以及像生成式 AI 的顶尖企业，此外，向量数据库在 AIGC 之外也有许多其他应用场景。

举例来说，电商领域主要专注于搜索、广告推荐等应用，这对于电商而言至关重要。自动驾驶领域也大量应用了向量数据库，例如用于自动化标注、场景识别等。在社交媒体中，向量数据库可以用于内容风控，帮助平台过滤掉敏感言论，以提高内容的质量和安全性。金融领域也能充分发挥向量数据库的应用，例如服务推荐等。此外，生物医药、知识产权等领域也都有广泛的应用。

刘熙： 谈及成本问题，我认为向量数据库的成本主要包括两个方面。首先，是将数据进行向量化所需的成本，涉及神经网络模型的训练和向量化等方面。其次，是向量数据库本身的成本。

今年向量数据库和 AIGC 之所以能够如此受欢迎，主要是因为 OpenAI 降低了大模型和向量化的门槛。这让企业能够更加容易地应用 AI 技术，不再需要构建一个庞大的 AI 技术团队，只需调用 OpenAI 的接口或采购行业大模型，就能在短时间内将 AI 技术引入企业。这也是为什么向量数据库和 AIGC 能够迅速火起来的原因之一。

向量数据库能够为业务产品带来怎样的最终收益呢？这个问题实际上有一个更深层次的考虑，就是从我看来，任何东西所能产生的最终收益，实际上都不是数据库本身所创造的，而是由数据库所赋能的业务产品所带来的。举个例子来说，以往在大模型兴起之前，电商领域广泛使用向量数据库技术，这里我将向量搜索和向量数据库混合使用，不加以明确区分。

那么，为什么电商领域最为频繁地使用这项技术呢？主要原因在于，电商通过这项技术赋能于搜索和推荐系统。对于头部电商来说，只要能够提升 1% 的推荐精度，这就会对整个公司的营收产生巨大影响。

因此，我们可以认为，向量数据库的真正价值在于用 AI 等基础技术赋能于各种应用，而应用本身则需要评估其能力提升后能够为企业带来的实际效益。这形成了一个相互关联的链路，而数据库作为赋能的一环在其中扮演着重要的角色。这就是我们的观点。

刘熙： 我认为，对于绝大多数企业而言，自行研发向量数据库并不具备明显优势。首先，成本是一个很关键的问题，自研一个复杂的向量数据库需要投入大量时间和人力资源。向量数据库涉及多个领域的知识，包括交叉的 AI 知识和数据库知识。从头开始构建一个向量数据库的时间和实践成本都很高。

关于我们公司的情况，外界可能认为我们很快就推出了向量数据库，但实际上并非如此。我们早在几年前就将自己定位为一个融合了大数据和 AI 的公司。我们的 AI 团队从 2016 年开始成立，专注于发展 AI 基础设施，并积累了丰富的 AI 人才。同时，我们也有专门负责数据库的团队，因此，在支持和经验方面，我们能够很好地覆盖数据库领域。

另外，对于 ToB 的厂商来说，最终产品会应用到很多家企业中。但对于单个企业来说，我个人认为自行研发向量数据库并没有必要。

我们认为，现在更重要的是将企业尽快实现 AI 转型，利用 AI 技术提升生产力，而不是花费精力去自研数据库。此外，现在的市场上已经出现了许多成熟的向量数据库选项，相比几年前更加容易找到适合的解决方案。因此，对于大多数企业而言，将精力投入到 AI 转型，而不是自研数据库，会更有价值。

刘熙： 在开始谈论这段时间的背景时，我可以分享一些当时发生的事情。最初阶段，大约在 2018 年左右，那时我们还专注于开发多模数据库。我们逐步将一些数据库的通用功能，如分布式存储、分布式计算、安全性和资源管理等功能，从紧密耦合的架构逐步转化为松耦合的架构。我们当时的目标是更好地支持各种专用数据库，例如图数据库和时序数据库，这些都是从那个时候开始的。

在这段时间里，我们公司内部的 AI 团队找到我，告诉我有一类数据叫做向量数据，对于我们的 AI 业务非常重要。然而，他们手头只有一个叫做 Faiss 的库来处理这类数据。当时 Faiss 的版本可能是 1.1 或者 1.2，还处于比较早期的阶段。他们面临的问题是，这些数据需要他们自己编写代码来进行管理，基本上每个项目都需要重复进行这样的工作，非常费时费力，而且可能无法保证高可用性和安全性。因此，他们希望我们能够开发一个专门处理向量数据的数据库，供他们的 AI 团队使用。

我们当时进行了一些调研，最终的结论是，尽管当时市场还不大，但这项技术有很大的潜力。即使可能不能立即商业化，但我们仍然认为有必要为将来做这样的技术储备。于是，我们决定着手进行这项工作。从 0 到 1 的第一个版本，我们进展迅速，因为需求相对明确，而且内部团队也不需要太多考虑面向客户的问题。我们的第一个版本基本上只是将 Faiss 库改造成了一个分布式库，通过基于数据 ID 的分片方式，每个分片下有一些副本，并通过 Raft 算法确保数据一致性。这个时期我们已经完成了之前提到的解耦工作，手上有很多可直接复用的技术组件，所以我们第一个版本很快就交付给了 AI 团队，整个过程不到两个月的时间。

AI 团队使用后感觉还不错，有了一个数据库来管理向量数据，而且非常可靠。随后，他们也提出了许多需求。接下来，我们为这个数据库添加了独立的存储和查询向量索引，这个索引仅仅是一个索引。然后，我们逐步开始添加数据的增删改查功能，以及标量和向量的混合搜索，标量索引等等。简而言之就是快速开发第一个版本并持续添加功能。

刘熙： 实际上我们最初交付的只是第一个版本。后续的几年时间里，我们不断进行迭代，逐步增加了各种功能和能力，这是一个持续演进的过程。我们注意到整个大模型概念将向量领域推向了前台，并且我们公司也开始推出行业大模型，我们意识到向量数据库这项能力应该作为一个独立的数据库产品来支持，而不仅仅是作为一个内部组件存在。

因此，我们开始了产品化的工作，并投入了大量时间。这个过程中涉及了许多工作，比如我们首先要解决安全性的问题。当产品面向外部用户时，安全性一直是我们高度重视的问题。我们还需要确保用户能够拥有开箱即用的体验，运维能力要足够优秀，以便用户可以轻松使用和管理。另外，监控能力也是一个需要考虑的重要方面。作为一个完整的产品，我们必须综合考虑各种方面的问题。

在这个过程中，正如之前提到的，我们团队也吸纳了来自 AI 领域和安全领域的专业人士，大家共同合作完成了这项工作。

刘熙： 我认为技术上的挑战主要集中在几个方面，其中一些已经得到了解决，但还有一些可能需要更深入的研究。

首先，我认为第一个要解决的挑战是扩展性。随着 AIGC 等应用的发展，特别是大模型的兴起，对嵌入（embedding）和向量化这块能力的需求急剧增加。大模型的普及也让向量数据的规模不断增大，从百万级别的数据体量已经变为千万级别，甚至更大。这就需要数据库能够有效地支持大规模向量数据的存储和检索，这对硬件资源提出了更高的要求，特别是在云上部署时成本可能成为一个重要问题。

第二个挑战是成本问题。在向量搜索中，索引的大小和存储是关键因素，而向量索引的成本通常较高。以前在数据量较小的情况下，可能只需要几台机器就足够了，成本并不是关键问题。但随着数据规模的增大，需要更多的资源来支持，这就涉及到成本的考虑。

第三个挑战是易用性问题。与传统的关系型数据库不同，向量搜索涉及到更多维度的考量，包括性能和召回率等。为了平衡性能和召回率，需要调整各种参数，但这可能对用户来说不太友好。因此，简化参数选择，提高用户体验是一个重要的挑战。

最后一个挑战是混合搜索中的路径优化问题。与传统的优化器相比，向量搜索的优化器更加复杂，因为它需要考虑多维度的因素。如何设计一个能够描述向量搜索代价的模型，以实现性能和召回率的平衡，是一个需要解决的难题。

当然，向量数据库还面临着其他有趣的挑战，比如在向量搜索中实现向量相似度过滤，以及如何在不同数据集间进行相似性 join 等问题。这些问题都需要深入的研究和解决，使得向量数据库能够更好地应对现实世界的各种应用场景。

刘熙： 因为我们在数据库技术方面这么年的积累，所以在数据维护和备份方面，我们拥有完善的备份机制。具体来说，我们支持全量冷备、增量冷备以及双集群、跨集群的热备，以确保数据的安全性和稳定性。这些备份机制是数据库自身的核心能力。

在维护方面，我们的向量数据库产品都配备了一个统一的管理组件，称为“manager”。该组件提供了产品的升级和安装功能。此外，我们公司拥有一系列可复用的技术组件，其中之一是“Aquila ”，它专门负责监控指标和告警等功能。至于日志管理，我们通常会采用单独的日志系统进行处理。

总体而言，数据维护、备份、升级和部署等工作都建立在我们自身的技术栈之上。我们的向量数据库产品通过统一管理组件和可复用技术组件，确保了这些关键操作的高效执行。这些举措有助于保障向量数据库的稳定运行和数据安全。

刘熙：当谈到升级方面，我们向量据库产品具有高可用性（HA），因此可以实现无停机滚动升级。这意味着我们可以在不中断业务的情况下进行升级操作。我们的数据库本身拥有这种能力，可以滚动重启每个组件，以实现升级过程。我们公司自主研发的基于容器技术的资源管理系统 TCOS，让升级过程变得简单。

具体而言，升级过程就是上传一个新的镜像或者补丁，然后触发滚动重启逻辑。底层的调度平台会根据数据库特性，对每个组件进行滚动重启，从而完成升级。对于使用者来说，只需在我们的界面上上传一个补丁，然后发起滚动升级任务，系统会自动处理。

我们提供了单机的社区版，如果要从这个单机版升级到分布式版本，可以通过许可证的变更来实现。如果涉及上下游数据迁移，例如从其他数据库迁移到我们的数据库，或者从我们的数据库迁移到另一个数据库，我们的数据库提供了批量导入和导出功能，数据的流动是比较顺畅的。

刘熙： 目前，国内的向量数据库以及 AIGC 在行业内的火热程度不言而喻，特别是在我们星环这半年的时间里，与 1000 多家合作伙伴及客户的交流中，也注意到这一问题。

国外似乎更早一步开展了这个领域的研究，落地的时间点似乎会比国内提前半年左右。从与客户的交流中我们发现，客户对这些深度学习应用非常感兴趣。然而，客户们目前仍处于学习和选型的阶段。例如，我们与多个客户合作，进行了深入的原型验证工作。

在客户将新技术引入实际业务之前，他们需要时间来适应和了解这些新概念。我们认为在下半年，国内的大模型应用可能会迎来一个高潮。需要注意的是，国外的情况也不尽相同，他们也经历了几个月的时间来逐步适应和应用这些新技术。

在未来的几个月内，我们将会看到更多客户开始在实际业务中应用这些新技术，因为每次与客户交流时，他们对于如何应用这些技术以及如何在他们的企业中发挥作用都会有更清晰的认识，这是一个逐步推进的过程。

刘熙： 关于技术趋势，我认为有几个关键点需要强调。首先，对于向量数据库领域，要实现深度学习技术的最优应用，需要具备 AI、数据库和安全等多方面的能力。数据库内通常会储存一些敏感数据，因此如何保证这些数据的安全性将成为一个极其重要的议题。尤其是随着向量数据库等领域逐渐引入深度学习技术，对 AI 能力和数据安全的需求将变得愈发迫切。

其次，我认为在短期内，随着大模型技术的迅速崛起，将会进一步加剧市场竞争的激烈程度。大模型的兴起为向量数据库等领域带来了巨大的关注度，同时也催生了更多的产品和解决方案，促使市场快速成熟。这对于技术从业者和用户都是利好，因为竞争带来了更多选择，也能获得更高性价比的解决方案。

我相信，在这个大数据时代，向量数据库领域具备巨大的潜力。同时，我想借此机会为对这一领域感兴趣的同学们打个小广告，欢迎与我们进行线上交流或投递简历。我们的团队将继续努力，不断积累和分享行业大模型的经验，与大家共同进步。

刘熙： 大模型知识的获取是一个深层次的过程，它可以类比为大模型的两个核心组成部分。一个是所谓的静态知识，另一个是通用的计算能力。举个例子来说明，假设我是一个有经验的程序员，对于某门编程语言，我已经具备了一定的了解和技能。然后，如果我学习了一门新的编程语言，但没有经过系统的学习，我可能无法完全掌握它的语法和特性。这时，我们可以将这门新编程语言的知识类比为向量数据库，它可以帮助我们存储和检索与这门语言相关的知识。如果我接入了这个数据库，就好像我获得了关于这门编程语言的指南，使我能够使用新语言编写出精美的程序。如果没有这个数据库，我可能不了解新语言的语法规则，从而无法充分应用它。

虽然我本身可能并不具备新语言的知识，但我拥有通用的计算能力。这就好比，数据库为不同的语言提供了相应的知识，例如，数据库为语言 A 提供了 A 的知识，为语言 B 提供了 B 的知识。当我接入语言 A 的数据库时，我能够回答与语言 A 相关的问题；当我接入语言 B 的数据库时，我能够回答与语言 B 相关的问题。因此，这个过程可以看作是知识和通用能力的一种分离。

刘熙： 我们来了解一下大模型的概念。大模型实际上包含了大量的静态参数，这需要进一步解释。在大模型中，存在一个名为 Transformer 的机制，这实际上是一个生成式模型。该模型最早应用于翻译任务。我们提供一个中文句子，模型会生成对应的英文句子。这是一个概率模型，它会根据之前的输入令牌和已生成的英文令牌来预测下一个令牌，从而完成翻译。这构成了整个大模型的底层原理。

您刚刚提到了大模型是如何回答问题的。这实际上是一个概率模型，其中包含许多参数。提供的提示词，也称为"prompt"，在模型的预训练过程中起到了重要作用。通过这些 prompt，模型在生成过程中会考虑特定的上下文和方向。例如，如果要回答关于北京的问题，通过合理的 prompt，模型会根据知识背景回答首都问题，而不会涉及其他不相关的信息。这些 prompt 实际上是在控制模型生成概率的空间，使其产生有关问题的合理回答，而不是随意的内容。

现在，让我们探讨一下数据库在这个过程中的作用。有了之前的背景，我们可以更好地理解。当我们构建提示词时，比如律师需要写法律文件，而他对该领域并不熟悉时，数据库的作用就显现出来了。如果大模型具备与法律领域相关的知识，它会首先从数据库中搜索与问题相关的案例。然后，大模型会利用这些案例的相关信息，生成更加真实和准确的回答，避免产生不切实际的内容。向量数据库的引入实际上是为了增强大模型的知识和回答能力，从而更好地应对不同领域的问题。

刘熙： 结合我个人观点和项目中的实践经验来谈一些看法。个人认为，如果数据量较小，且对访问并发和延迟要求不高，从现有数据库中封装和计算向量应该是可行的。然而，一旦数据规模增加，特别是在访问并发方面，考虑到性能、扩展性、弹性和成本等多方面的因素，我们仍然需要专业的向量数据库。

我可以分享一些实际经验。在我们着手进行项目时，我们也是经过了一段前期的思考和研究。我们最初放弃了基于已有数据库扩展的路线，主要是因为基于 Java 等语言的执行效率、内存管理等方面的限制，特别是在高性能需求方面存在挑战。我们随后探索了基于现有数据库的工程化方法，这与许多人的做法是类似的。我们将向量视为一列数据，通过构建向量索引和扩展 SQL 语法或使用 UDF 来实现向量搜索能力。虽然这种方法在理论上看起来很简单，但深入研究后会发现其中涉及一些架构性问题，影响性能和效率。

其中几个关键问题值得注意。首先，在向现有数据库中扩展新索引时，必须遵循数据库的索引规范，如 PG 中的索引页面结构。否则，新索引可能无法与数据库的内存管理和存储机制协同工作，从而导致性能损失。向量索引是向量数据库的核心，但这种扩展可能会导致性能下降，尤其是相对于专用的向量数据库而言。这一点在许多公开的测试和性能评估中也得到了验证。

另一个问题是，现有数据库在资源使用模式上与像向量搜索这样的特殊需求不匹配。在传统数据库中，存储和计算分离，计算节点主要处理复杂算子，而存储节点处理数据 IO。然而，在向量搜索中，大部分资源开销都发生在存储节点上，导致存储和计算分离策略的效果有限。这可能会影响性能和扩展性。

此外，从用户成本的角度考虑，数据库是复杂的系统，我们在向量数据库中可能并不需要传统数据库中的所有功能。在面向 AI 的场景中，传统数据库的许多功能可能并不适用，这会导致用户为不需要的功能买单。特别是对于一些公司来说，他们可能只需要一个功能完善、专业的向量数据库，而不是一个功能繁杂的通用数据库。

在这里，我想强调的是，我们追求的是提供一种专业、高效的向量数据库，以满足向量搜索等特定需求，而不是将通用数据库的功能扩展到不同场景。从星环的角度来看，我们不太倾向于采用功能复杂的通用数据库方式。

刘熙： 这个问题确实很有深度。实话实说，这个问题并不仅仅是向量数据库要解决的，更多地涉及到大模型在关键领域，特别是在容错率低的场景下，如何确保结果的正确性。这两个方面都是重要的：首先是如何保证结果的正确性，其次是由谁来担保这一点。

实际上，这个问题可能超出了计算机领域的范畴，可能涉及到人类价值观等更广泛的问题。这是一个开放性的问题，我们需要不断地进行研究和探讨，以找到合适的方法来解决这个复杂的挑战。

刘熙： 实际上，问题的核心在于如何提升数据处理的精确度。在这方面，可以分为两个主要方面进行考虑。

首先，与大模型相关的问题。关键在于对大模型的训练和设计进行优化，确保其结果的正确性。

其次，针对向量数据库的问题，需要提高其准确性。举例来说，当处理长文本时，采取分段的方式进行处理，每个段都进行嵌入，然后再进行召回。然而，分段的质量对结果影响重大。如果分段不当，可能会导致语义失真，从而影响准确性。技术上可以考虑两个方向：一是研究语义分词，将长文本分割成更合理的语义单元；二是设计更适合于数据库召回的分词算法，考虑上下文关系。

对于向量数据库搜索，目前尚未充分表征同一长文本内部的上下文关系。这可能导致召回结果的准确性下降。解决方案之一是在语义搜索过程中不仅考虑单一向量的匹配度，还要感知上下文关系，以综合进行召回。另一方面，分词算法的设计也应该考虑数据库的能力，以获得更好的分段效果。

需要承认，这些问题的解决不是一蹴而就的，特别是在容错率低的领域。然而，通过逐步积累和迭代，从各个技术维度攻克各种困难，最终可以实现技术的落地。重要的是要保持持续的进步和创新，使得我们的 AI 助手能够应用于更关键的领域，为未来的落地铺平道路。

刘熙： 我们星环也有图数据库团队和知识图谱团队。在处理大模型的过程中，我们进行了讨论和研究，并做了相关的解决方案，将向量数据库的召回结果与图谱的召回结果进行结合，从而实现联合召回。这样的方案旨在提高整个推进过程的准确性，这是完全可行的。

刘熙： 以刚刚提到的例子为例，我们需要识别出其中的语义组群，并将这些组群进行嵌入。对于这个简单的例子来说，只需要将语义组群进行识别，然后对这些语义组群进行嵌入就可以了。如果是刚刚的那个例子，非常简单，只需要将文本进行适当的分段和识别，然后可以将其嵌入为若干个向量。比如说，对于句子"今天天气很好，但是我很难受"，可以分为三个语义组群：“今天天气很好”、“但是我很难受”、以及整个句子的上下文，然后将它们进行嵌入即可。

刘熙： 目前，我们确实在进行相关工作，特别是在我们行业大模型应用方面，我们的 AI 团队正在研究，相信不久应该能够与大家分享这些进展。

刘熙：“Zero prompt”实际上展现了当前大模型的强大能力，这一点毋庸置疑。各类大型模型都正处于研究和发展的规划阶段，正在不断进行改进和完善。

即使采用 Zero prompt 的方式，最终产生的结果也不会过于偏离预期。向量数据库在这一过程中的主要作用是防止内容出现不准确的情况，确保信息的准确性，防止生成虚假信息。此外，在我们进行工程提示时，通常推荐从 Zero prompt 开始着手，因为很可能 Zero prompt 已经能够取得有效的结果，然后再逐步构建更复杂的 prompt，以实现更好的效果。因此，即使 Zero prompt 产生的结果也并非毫无参考价值，这一点需要明确。

刘熙：在进行数据迁移时，可以采用了一个中间媒介的方法。具体来说，需要将原始数据库的数据导出成向量数据库能够识别的格式，比如 CSV，然后通过 CSV 格式将数据导入向量数据库中，进行分布式的加载。目前我们也在逐步完善不同数据库之间的连接和互通。比如，以前在处理类似金融领域的产品（如金融数据仓库），我们会构建一整套生态工具来与常用数据库进行连接。因此，向量数据库这个领域，我们也可以有类似的工具。

刘熙： 简单来说，多模态是将各种非结构化数据的特征表示统一起来的一种方法。不论是什么类型的数据，它都能够在这个统一的特征表示下进行分析。对于向量数据库来说，多模态是非常重要的。

举例来说，比如有一些语料是中文，而另一些是英文，尽管它们语言不同，但在语义上可能有相似之处。多模态可以屏蔽掉原始数据的差异，统一地处理语义搜索。

我们认为多模态和智能体有着紧密的联系，它们有可能成为引领向量数据库领域发展的关键点。智能体在 AI 和机器学习领域已经受到广泛关注，而多模态应用则是一个相对较新但同样有着巨大潜力的方向，我们将其视为下一个可能引爆市场的重要点。

刘熙，星环科技基础架构部副总经理

以「启航·AIGC 软件工程变革」为主题的 QCon 全球软件开发大会·北京站 将于 9 月 3-5 日在北京•富力万丽酒店举办，此次大会策划了向量数据库、大前端新场景探索、大前端融合提效、大模型应用落地、面向 AI 的存储、AIGC 浪潮下的研发效能提升、LLMOps、异构计算、微服务架构治理、业务安全技术、构建未来软件的编程语言、FinOps 等近 30 个精彩专题。

现已确认 130+ 名嘉宾，咨询购票优惠信息可联系票务经理 18514549229（微信同手机号）。

点击底部阅读原文访问 InfoQ 官网，获取更多精彩内容！