联通软研院：基于OceanBase落地检索增强生成 (RAG) 的应用实践

联通软研院数据库平台服务数百到上千内部用户，涵盖了从应用开发到运维管理的各个环节。面对如此庞大和复杂的数据库应用场景，我们长期面临许多挑战：数据库种类繁多，版本差异大，生产系统的稳定性要求高，测试环境与生产环境之间的差异影响了效率，且日常数据库运维和管理的工作负荷巨大，响应速度难以提升。

具体来说，我们需要应对以下几个主要挑战：

1、多种数据库及版本管理：联通内部存在多款数据库产品，且版本更新和维护频繁。如何保持不同版本间的数据一致性并快速定位问题，成为了运维和管理中的一大难题。

2、生产环境的高效管理与测试环境差异：生产系统的稳定性至关重要，如何在保证生产环境稳定的同时，快速应对和解决生产系统中的问题。此外，测试环境与生产环境的差异可能导致性能偏差或潜在故障，如何高效地管理并在两者之间找到平衡，提升整体系统可靠性和响应速度，是提升数据库运维敏捷性的关键。

3、提高工作效率与敏捷性：随着业务需求的不断变化，如何在复杂多变的数据库环境中快速获取所需信息，并及时响应，成了提升数据库运维管理效率的核心问题。

为了提升运维效率和内部敏捷性，我们尝试用 RAG 架构解决这些实际问题，并开发了数据库智能专家“ChatDBA”。

通过结合数据库领域的专业知识和联通内部的运维数据，“ChatDBA”让开发人员和 DBA 可以直接用自然语言查询数据库状态、排查故障或者获取建议，减少了大量的重复工作。这样的方式，不仅提升了问题解决效率，也让团队能将精力更多地集中在关键任务上，以下是我们采用的整体方案流程示意图：

我们针对内外部的数据库通识类和特性类文档进行系统性梳理，形成文档知识库。通过文档切片和向量化模型嵌入，我们将这些文档内容转化为向量数据并存储在向量库中。这一做法使得大型语言模型（LLM）能够获得 DBA 领域的专业知识，大大提升了知识问答的召回率和准确性。

在此基础上，我们进一步引入了 RAG（检索增强生成）技术的知识问答系统。通过检索外部知识库，增强模型对特定问题的理解和回答能力，帮助生成更精准、更丰富的文本内容，从而提升了文本处理的效率和质量，最终打造了数据库智能专家“ChatDBA”， 它具备丰富的数据库知识和经验，能够为数据库使用者（应用人员）和数据库维护方（产品运维、支撑人员）提供全面的、高质量的技术咨询与解决方案服务，降低数据库使用门槛、提升数据库运维效率。

二、选型与现代化升级：从双库架构到一体化数据库

在项目初期，我们选择了 MySQL 进行关系型数据存储，并使用 Milvus 作为向量数据库。然而，随着数据量和需求的增长，我们很快发现了两个关键问题：首先，现有的数据库无法进行水平扩展，且无法应对更大规模的数据处理；其次，必须同时维护两种数据库系统，增加了管理和运维的复杂性。

为了解决这些问题，我们开始寻找一种能够统一支持关系型数据和向量数据的解决方案。在选型过程中，我们发现 OceanBase 4.x 实验室版本具备强大的向量检索与混合查询能力，这促使我们对独立向量数据库、单机数据库以及分布式数据库在向量场景下的能力进行详细评估，以下是评估结果的具体对比：

表：RAG 应用场景的向量数据库选型评估

深入对比了独立向量数据库、单机数据库和分布式数据库三种选型路线后，我们更倾向于 OceanBase 的一体化技术路线，不但可以使运维团队简化技术栈，更重要的是 OceanBase 在性能、扩展性和管理便利性方面展现出明显优势。

OceanBase 当前版本支持超过 16,000 维的稠密向量处理，并提供多种向量距离计算方式（如曼哈顿距离、欧式距离、内积和余弦距离）。此外，OceanBase 还支持创建 HNSW 向量索引、增量更新和删除操作，以及强大的 Filter 功能，能够基于向量、标量和半结构化数据进行混合过滤。结合 OceanBase 本身的分布式架构，这些特性使它成为一个高效且统一的平台，能够解决我们面临的数据库扩展性和管理复杂性问题。

通过对 OceanBase 的测试验证，我们发现其向量检索能力完全符合我们的需求，尤其是在支持应用 ChatDBA 方面表现出色。更重要的是，OceanBase 的向量检索功能具备完整的产品配套生态，进一步增强了其在实际生产环境中的可行性。

以下是我们在功能测试中对比 OceanBase 向量检索与 Milvus 开源版本的一些关键差异，OceanBase 展现出了明显的优势：

1、简易运维：OceanBase 向量检索功能可以直接复用OceanBase 的运维管理平台（OCP），大大简化了运维工作。OCP 提供了界面化的快速部署、硬件资源管理、监控告警、备份恢复等一整套完善的产品运维功能。而 Milvus 仅提供基础的数据库功能，不具备完善的运维支持，且存在安全隐患。

2、高可用与弹性扩缩：OceanBase 向量检索能力继承了 OceanBase 原生分布式数据库的高可用性，能够实现分布式部署、弹性扩缩容，并通过 Paxos 协议实现单点故障时的自动快速恢复。而 Milvus 只能进行单点部署，缺乏高可用性及横向扩展能力，这在生产环境中无法接受。

3、多租户资源隔离：OceanBase 向量检索支持多租户资源隔离，并配合 OceanBase 强大的可扩展性，能够提供安全、灵活的 DBaaS 服务。用户可以在现有 OceanBase 资源池内快速开通数据库实例，并根据业务需求灵活调整资源。相比之下，Milvus 缺乏资源隔离能力，尤其在物理机部署情况下，资源管理容易出现浪费或不足且无法扩展的问题。

4、支持 SQL：OceanBase 向量检索支持标准 SQL 操作，开发人员可以使用 DBeaver、Navicat 等熟悉的客户端工具与数据库交互，这降低了数据库使用门槛，提升了开发效率。Milvus 则不支持 SQL，只能通过 API 和代码操作数据，使用体验相对较差。

5、快速迁移：OceanBase 向量库能够利用 OMS 数据迁移工具进行同构与异构数据迁移。我们通过 OMS 的功能，成功将原本存储在 Milvus 中的测试数据迁移到 OceanBase 中。而 Milvus 本身不支持数据迁移，跨环境迁移需要重建数据，耗时且对业务影响较大。

在性能测试阶段，我们模拟了当前实际生产环境的使用场景。此前我们使用了两套独立的数据库系统，而现在关系型数据库与向量数据库共享同一个实例。与原本需要两套数据库的部署方式相比，当前实例的规格约小了 30%，在性能上完全满足了业务需求，并且资源使用率显著降低。这意味着在成本方面，我们实现了至少 30% 的硬件资源节省。

以下是官方发布的主流向量数据库性能对比。图中展示的 VSAG 曲线数据来源于 OceanBase 与蚂蚁集团联合研发的向量索引算法 VSAG，OceanBase 在性能表现上明显优于其他主流向量索引库，实现了“比快更快”的性能提升。

三、成效与价值：构建现代化 RAG 数据底座

在完成 OceanBase 数据库向量检索功能和性能验证后，我们决定将现有的 MySQL 和 Milvus 数据库进行现代化升级，并进行了相应的适配改造。

我们发现，OceanBase 的引入工作量较小。对于原 MySQL 数据库几乎没有额外工作量，SQL 语法完全兼容，甚至无需更换驱动包，只需要修改配置即可。对于Milvus向量数据库的升级，主要是更新数据库依赖包和调整数据库操作方式。由于 OceanBase 支持通过 SQL 操作向量数据，只要熟悉 SQL 语法，改造工作也非常简便。我们在大约一周的时间内完成了所有程序的适配改造，并在不到两周的时间内完成了所有验证工作。

2024 年 10 月，OceanBase 发布支持向量检索的稳定版本 4.3.3，我们随后启动了生产环境的数据库现代化升级。借助前期充分验证和 OceanBase 的 OMS 工具，升级过程高效顺畅，顺利完成从 Milvus 到 OceanBase 的数据迁移，加快了整体进程。

升级后，我们将多套数据库整合为一个统一的系统架构，硬件资源使用量减少约 30%，业务性能全面满足需求。OceanBase 原生的分布式架构不仅显著提升了系统稳定性，降低单点故障风险，还为未来业务增长提供可扩展能力。这次升级既简化了技术栈，减轻运维团队的压力，还为业务的长远发展打造灵活可靠、可扩展的技术基础。

四、展望未来：进一步简化技术栈

在联通软研院 RAG 实践中，我们通过引入 OceanBase，完成了数据库智能专家“ChatDBA”底层架构的现代化升级。OceanBase 在统一关系型和向量数据库的技术栈方面展现出卓越能力，一个数据库即可支持多种工作负载和数据处理需求。硬件资源使用率降低约 30%，配合 OCP、OMS 等工具，极大简化了运维流程，提升了团队效率。

结合项目实践，我们意识到 RAG 的向量检索能力对于实现高效的知识问答系统至关重要。而 OceanBase 作为一体化数据库，不仅能够支持多模态数据处理和多场景融合，还在性能和稳定性上表现出色。这样的设计帮助我们显著降低系统复杂性，同时为未来更复杂的业务需求提供了更坚实的技术支持，成为构建统一、高效智能数据库解决方案的关键一步。

展望未来，我们计划进一步扩大 OceanBase 应用范围，通过现代数据架构升级进一步简化技术栈，降低运维成本。