信通院向量数据库全量测试：OceanBase 达标
在中国信息通信研究院组织的 2026 上半年批次“可信数据库”测试中，OceanBase 数据库软件顺利完成向量数据库基础能力的所有测试项目。
测试过程依据《向量数据库技术要求》（T/CCSA 573-2024），在基本功能、运维管理、安全性、兼容性、扩展性、高可用以及工具生态七大能力域，共 47 个测试项（27 个必选项 + 20 个可选项）中全量通过。
测试结果表明：OceanBase 数据库软件在向量数据库的功能完备性、易用性、通用性等方面完全符合标准要求。
《向量数据库技术要求》标准框架示意图
《向量数据库技术要求》（T/CCSA 573-2024）是中国信通院数据库团队依托中国通信标准化协会大数据与区块链工作组（CCSA TC1 WG6）以及大数据技术标准推进委员会（CCSA TC601），联合超 50 余家业内专家参与编制的技术标准。作为业内首个向量数据库技术标准，它已成为向量数据库技术研发和产品选型的风向标。
OceanBase 数据库通过一套数据库同时承载交易、分析与 AI 推理三大负载，帮助企业实现数据架构的现代化演进，将复杂的数据栈简化为统一的智能数据底座。
想了解 OceanBase 在产品技术核心竞争力及不同行业解决方案和最佳实践，可下载
把 AI 能力做进数据库内核
过去三十年，数据库为人设计——DBA 写 SQL，应用通过 ORM 读写。但当 AI Agent 成为数据库的主要调用者，一切都在变。
Agent 的工作方式跟传统应用完全不同。一个典型的 RAG（检索增强生成）任务，需要先把用户问题做 Embedding，再到向量库里找相似文档，回到业务库查关联数据，调 Rerank 模型重排序，最后送给大模型生成答案。六跳调用链，任何一跳超时，整条链路就崩。
更棘手的是数据类型的复杂化。Agent 要处理语义向量、全文内容、JSON 文档、空间坐标，再加上传统的结构化业务数据。如果每种数据类型都需要一个专门的系统——关系库存业务数据，向量库存 Embedding，搜索引擎做全文索引——企业的数据架构就变成了一堆“胶水”粘起来的脆弱拼图。
OceanBase 从内核层面支持向量数据类型和向量索引，不是外挂插件“嫁接”的。支持稠密向量和稀疏向量，内置多种距离算法。欧氏距离（L2）适合空间位置敏感的场景，余弦相似度（Cosine）适合关注方向而非幅值的语义匹配，内积（Inner Product）则常用于归一化后的 Embedding 检索。
索引层面提供内存和磁盘两类方案。对于延迟要求极高的在线检索场景，HNSW 图索引在百万级向量规模下可以获得亚毫秒级响应。对于数据量更大、成本更敏感的场景，IVF 索引通过聚类划分将检索范围收敛到少量簇内，大幅降低内存占用的同时保持较高的召回率。
量化压缩方面，标量量化（SQ）将浮点向量压缩为低精度整数表示，以较小的精度损失换取数倍的存储节省和检索加速。乘积量化（PQ）通过子空间分解与码本编码实现更高的压缩比，适用于超大规模向量集合。二进制量化（Binary）将向量映射为比特串，利用位运算实现极致的距离计算速度，适合对吞吐量要求极高的粗筛阶段。用户可以根据业务对召回率、查询性能与存储成本的不同侧重，灵活组合索引类型与量化策略。
这些向量索引能力和 LSM-Tree 存储引擎深度集成，确保在高并发写入场景下向量索引依然能够高效维护和实时可查。
混合搜索：一条 SQL 搞定三路检索
向量检索只是起点。AI 应用真正需要的，是多种检索能力的协同。
Agent 做一次决策，往往既要向量检索找语义相似的知识，又要全文检索匹配专业术语和关键词，还要关系型条件过滤限定时间范围、权限和业务类别。三类检索缺一不可，但如果分散在三个系统里，应用层就变成了结果拼接的“调度中心”。
OceanBase 在同一引擎内融合了向量检索、全文检索与关系型查询三大能力，支持在一条 SQL 中同时执行多路检索并统一排序返回。向量相似度召回、关键词全文匹配、业务表条件过滤，通过 RRF（Reciprocal Rank Fusion）等融合排序算法将多路结果归并为统一的排序列表，整个过程在数据库内完成。
这种内核级混合搜索带来三个直接好处：
第一，查询优化器统一感知。 向量索引、全文索引和 B+ 树索引的代价模型对查询优化器透明，数据库能智能选择最优执行路径，不需要在应用层手动编排“先查什么、再过滤什么”。
第二，事务一致性由内核保证。 所有检索操作共享同一事务上下文，不会出现向量库和业务库之间数据不同步的问题。Agent 查到的永远是最新、最一致的数据。
第三，调用链路收敛。 端到端延迟大幅降低，系统稳定性也随之提升。Agent 的一次复杂查询，从多跳网络请求收敛为一次数据库交互。
实测数据也验证了这种方案的优势——在稠密向量 + 全文索引 + 稀疏向量的三路召回评测中，混合搜索的检索精度显著优于单一检索方式。
SQL 内置 AI 函数：让数据库成为 Agent 的超级工具
混合搜索之外，OceanBase 还将 AI 能力封装成 SQL 函数。
Embedding 生成（AI_EMBED）、大模型推理（AI_COMPLETE）、结果重排（AI_RERANK）——这些原本需要在应用层逐个调用外部 API 的能力，现在可以直接在 SQL 语句中使用。
一个典型的 RAG 场景，用一条 SQL 就能跑通完整链路：
SELECT AI_COMPLETE('qwen-max',
CONCAT('基于以下资料回答问题：',
(SELECT GROUP_CONCAT(content)
FROM knowledge_base
ORDER BY VECTOR_COSINE_DISTANCE(embedding,
AI_EMBED('text-embedding-v3', '用户的问题'))
LIMIT 5),
'\n问题：用户的问题'))
AS answer;
对 Agent 框架来说，这意味着调用链从“Agent → Embedding API → 向量库 → 业务库 → Rerank API → LLM API”六跳，缩短成“Agent → 数据库”一跳。每减少一跳，就少一分网络开销、少一分故障概率、多一分可靠性。
本质上这是一种架构选择——让数据离计算更近，让智能离数据更近。当大模型变成数据库的一个新算子，数据库的角色也随之改变：从存储后端，变成 Agent 的全能工具箱。
TP/AP/AI 一体化：一套系统承接三种负载
向量检索和 AI 函数只是 OceanBase AI 能力的一个切面。更大的图景是 TP/AP/AI 三种负载在同一套系统内融合。
一套数据库，既能稳定承载核心交易系统的高并发强一致性需求（TP），又能高效支撑实时分析和智能决策（AP），还能原生运行 AI 推理负载。企业不再需要为不同负载维护交易库、分析库、向量库三套系统，在一个统一的数据底座上就能完成所有工作。
关系型数据、JSON、空间数据、ARRAY、向量、全文——多种数据类型原生支持，行存、列存及行列混存灵活选择，实现“写入即分析”。AI 推理可以直接访问最新鲜的交易和分析数据，不需要等数据同步。
对于正在拥抱 AI 转型的企业来说，这个架构选择的价值是直接的：技术栈简化，运维成本降低，数据一致性由内核保证，AI 应用的开发周期显著缩短。
生产级可靠性：Agent 的安全网
最后一个容易被忽视但极其关键的维度：可靠性。
Agent 的“自主性”意味着它可能在凌晨三点还在执行操作。一旦出错，影响可能是批量的、持续的。对于金融风控、医疗问诊、政务审批这些场景，任何一次数据不一致或系统故障，后果都是真金白银或人身安全的损失。
OceanBase 从 0 到 1 完全自主研发，代码级可控，在大规模金融核心场景中经过十余年验证。完整的 ACID 事务、基于 Paxos 协议的多副本强一致、三地五中心多活容灾、多租户隔离、细粒度权限控制、列级加密、在线弹性扩缩容——这些能力在 Agent 从实验室走向生产环境时，构成了最关键的安全网。
Agent 要变得更强大，前提是足够可靠。这种可靠性 Agent 自己给不了，要靠底层数据基础设施来兜底。
未来展望
OceanBase 对 AI 数据库的探索还没有停止。
AI 列是 OceanBase 即将推出的功能。它是一种声明式的智能衍生列，用户只需定义规则，数据流转、模型交互与结果维护全部交给数据库。AI 列和普通列一样，能参与 SELECT、WHERE、GROUP BY、JOIN 等各种操作。对 Agent 来说，这种能力完全透明，不需要应用层“逐行调用、手动解析、反复回写”，可以避免大量数据搬运。
行级权限控制也是多 Agent 协作场景的刚需。不同 Agent 操作同一张表时，应该只能看到各自权限范围内的数据行，这需要数据库层面的细粒度访问控制。
海量逻辑表支持则面向规模化场景。当 Agent 平台从服务几十个企业客户扩展到服务数百万个人用户时，“海量小租户”成为常态——每个租户数据量不大，但租户数量庞大，且彼此之间必须严格隔离。
逻辑表是实现 Agent 数据隔离的核心抽象，多个 Agent 看到的是“各自的表”，但物理上共享同一张表，通过数据库引擎保证隔离性。
立即试用 OceanBase 企业版，体验国产数据库能力
浙公网安备 33010602011771号