当企业搜索的数据量从十亿增长到百亿、千亿，系统需要同时解决容量、检索延迟和运行成本问题。接入大模型之后，搜索链路又增加了向量化、混合召回、重排序与上下文组织。本次分享围绕腾讯云 ES 的 AI Search 实践展开：先介绍产品与应用场景，再解释 DiskBBQ 内核优化如何减少无效读写和计算，最后讨论自动化索引、统一数据底座与知识驱动搜索的后续方向。这里的规模目标和延迟目标对应不同维度，不能据此推导出任意千亿级负载都能获得同样的毫秒级响应。

全文分为三个部分。产品综述说明腾讯云 ES 的社区积累、核心场景和 AI Search 流程；内核优化从 DiskBBQ 的索引结构出发，依次讨论 SOAR 冗余、多租户数据布局、标量与向量过滤的融合索引，以及Schema 在线演化；最后的 Coming Soon 介绍正在探索的能力。这三个部分分别回答系统能承担什么工作、性能瓶颈如何处理，以及后续如何减少数据和索引的人工维护成本。

03 产品综述：团队、架构与场景

企业级 AI Search 的基础仍然是可靠的数据管理和检索系统。模型负责生成或理解内容，搜索引擎负责把相关、可访问的数据及时交给模型，同时承担索引维护、权限控制和服务可用性要求。腾讯云 ES 的产品思路是在 Elasticsearch 的全文检索与数据管理能力上，补齐向量检索、模型接入和 RAG 所需的处理链路，让日志分析、业务搜索与企业知识检索能够共享技术基础。

腾讯云 ES 团队自 2019 年起持续参与 Elasticsearch 开源建设，累计提交 220 多个技术 PR，并有两位成员进入材料所述的全球贡献者 Top 100。页面也记录了 Elastic 创始人 Shay Banon 在 2019 年和 2024 年的两次公开认可，以及 2022 年杰出开源贡献奖、2024 年 Lucene 相关方案获得 Elastic 官方账号推广。这些数字和事件反映的是腾讯云 ES 团队的专业性和技术积累。

腾讯云 ES 的三个主要应用方向是实时日志分析、企业级 RAG 和实时搜索。日志场景侧重存储成本、写入吞吐和大规模分析，通过存算分离、压缩及内存管理等手段优化资源使用；RAG 场景侧重文档处理、Embedding、检索、Rerank 和权限约束，为模型提供可用上下文；实时搜索则将 BM25 关键词匹配、向量相似度和业务过滤结合起来。图中的成本降低 50%—80%、性能提升 2—10 倍等范围，应理解为产品材料列举的特定场景收益，而非面向所有数据集的统一承诺。

以企业文档问答为例，离线链路(数据摄入)先解析文档、切分内容并生成向量，再建立全文索引与向量索引；在线链路(检索)接收问题，通过混合检索获得候选内容，经过重排序后提供给大模型生成答案。模型接入、权限过滤以及可选的联网搜索也是这条链路的一部分。这里的“一体化”指数据处理与检索能力的衔接，不等同于物理部署必须采用存算一体。页面列出的单集群规模从 2024 年十亿级、2025 年百亿级增长至 2026 年千亿级，表达容量演进；具体响应时间还取决于维度、过滤条件、召回目标、并发和硬件配置。

07 内核优化：先看数据在哪里，再看如何访问

向量检索的开销不只来自距离计算。查询会访问哪些聚类、需要读取多少索引页、是否构建中间过滤结构，以及索引变更时是否重写不变的数据，都会影响整体性能。接下来先解释 DiskBBQ 的层次化 IVF 结构，再沿着减少冗余副本、限制多租户读取范围、改进过滤迭代和复用 Segment 四条路径展开, 不同优化针对不同瓶颈。

最底层 Vector Cluster Layer (IVF索引) 可以理解为先按向量相似性分组，再为每组保存一份向量列表。DiskBBQ 整体为两层 IVF 结构, 图中的父质心、子质心分别是一层 IVF。

查询多层路由：查询向量先寻找较近的父质心，再扫描改父质心对应的子质心， 然后扫描选中子质心的 Vector Posting List，对候选向量进行评分。

列表(Vector Posting List)把文档标识与对应的量化向量关联起来，连续的数据布局有利于批量读取；需要精排时还可能访问原始向量。

09 Slice DiskBBQ：让数据布局匹配租户边界

假设一次查询只访问租户 A，但全局聚类把 A、B、C 的向量混在同一批索引页中，读取 A 的候选数据时就可能把其他租户的数据一并带入缓存。Slice DiskBBQ 按 sliceField 划分物理数据边界，在各 Slice 内独立组织聚类与 Posting List；匹配该 Slice 的查询可以缩小读取范围，小 Slice 则可采用 FLAT 路径。原始 500 万向量测试中，10% filter、并发 20 时 QPS 为 3276 对 600，约 5.5 倍，Force Merge 耗时由 9811 秒降至 8611 秒，缩短约 12.2%。图中 Page Cache 下降约 87.7% 来自另一组冷启动测试：约 2.5 GB 对 308 MB，但两组 Recall 为 0.9962 与 0.8938，因此只能说明该次实验的访问与缓存差异，不能解释为相同召回率下的节省。

10 标量与向量融合：用有序交集减少中间处理

例如，文本过滤命中的文档为 [7, 15, 23, 31]，某个向量聚类的文档为 [3, 7, 12, 15]，真正需要评分的是交集 [7, 15]。旧路径先遍历文本过滤结果构建 BitSet，再扫描向量列表逐个判断是否命中，产生数据的两次扫描；优化路径， 把向量索引的 Posting List 改造为类似跳表的结构， 让向量列表与文本过滤结果通过有序迭代器求交集，借助 advance 和块级跳跃跳过不可能匹配的区间，减少中间结构和无效访问， 把两次数据遍历变成一次，查询性能得到 2 倍提升。

11 常驻内存去冗余与评分路径优化

DiskBBQ 原始的 SOAR 分配会让一个向量同时进入主质心和一个溢出副质心的 Posting List， 以达到较好的召回率，但常驻内存会翻倍；关闭这项冗余后，只保留主分配，从而减少列表及其页缓存占用。按本次演示材料的估算，相关常驻内存合计由约 2.94 GB 降至约 2.02 GB，节省约 0.92 GB，即约 31%；代价是 QPS 会下降 13% 左右，因为要扫描更多的质心数据。但我们通过另一项 native scoring 路径优化，来弥补了这个 QPS 下降的问题。

12 Schema 在线演化：Segment 复用减少索引的重复构建

向量场景下，有一个普遍的需求是 Schema 在线演化，比如过一段时间，更新 embedding 模型，那向量字段要重新生成。或者原来的文本字段要 embedding，数据规模增长后，要扩充 shard 数、修改索引类型（比如 HNSW → DiskBBQ）。这些 Schema 演化能力要借助 ES 的 reindex 能力。

原生 _reindex 从源文档读取 _source，经网络传输和 Bulk 写入，在目标端重新构建索引，并产生后续 Segment 合并。

优化后的的索引演化，Segment 复用可以保留不变的存储文件，通过硬链接等机制共享已有内容，只读取必要的原始向量并构建发生变化的索引部分。演示材料给出的 90 亿向量、约 35.9 亿父文档、15.7 TB 测试中，耗时由 6.55 小时降至 22.6 分钟，约快 17.4 倍；写 I/O 从 97.7 TB 降至 9.5 TB，下降约 90.3%，堆内存峰值由 74% 降至 23%。这些结果来自所述 30 节点、512 维、1024 分片场景；文件复用比例不等同于 I/O 降幅，格式转换、跨文件系统或需要重新计算字段时也不能假设全部复用。

前面的优化解决既有检索与索引处理路径上的成本问题，后续探索则面向更完整的数据生命周期：Distributed Auto Index 希望自动组织和演化索引，Vector Lakebase 希望打通离线数据处理与在线检索，Knowledge & Ontology 则面向知识组织和受控业务行动。

14 Distributed Auto Index：查询剪枝与在线演化

如果所有查询都访问全部索引，数据规模增大后，分发和扫描成本也会增长。Distributed Auto Index 的设想是在读写入口共享 Cluster Inference，接入 K-Means、分类模型或其他聚类模型：写入路由到最近的一个 Cluster Index，查询则访问最近的 N 个索引，编码 touch 全量数据， 达到查询剪枝的目的。图中以 Top-2 为例，缩减搜索范围换取延迟、成本与召回之间的平衡。另一部分是通过稳定 Alias、后台构建和增量追平演化索引，在满足切换条件后发布新版本，覆盖分片调整、HNSW 到 DiskBBQ 的转换及新增向量字段等需求。

15 Vector Lakebase：离线处理与在线检索形成 DataLoop

文档、表格、图片、音视频、事件和 Agent Memory 进入统一的逻辑数据底座后，Lakehouse 侧利用 Spark、Ray 等计算引擎进行清洗、批处理、聚类、评测和重嵌入；Vector Database 侧则利用向量、文本与过滤索引提供在线检索，服务 RAG、推荐和 Agent。两侧通过共享 Catalog 关联 Schema、版本、快照和血缘，配合发布协议把一致的数据与索引版本交给在线服务，再把查询反馈、执行轨迹与评测结果送回离线侧。这个 DataLoop 建立在存算分离基础上，目标是减少重复导入和多套数据真相源，而不是消除所有物理副本或缓存。

16 Knowledge & Ontology：证据、关系与受控行动

以“某个零件延迟交付会影响哪些订单”为例，RAG 可以找到供应商通知、订单资料和处理规范，并返回带引用的回答；GraphRAG / Context DB 所代表的知识与上下文组织能力，进一步关联零件、产品、工厂与订单，帮助分析影响路径；Ontology 则统一业务对象、指标含义、状态、规则与动作，在权限和审批约束下支持后续处理。这是能力协作，不是后三者依次替代前者：RAG 并非只能回答单跳问题，关系图也不会自动证明因果，Context DB 不必采用唯一的图实现。本页所说的 Operational Ontology 包括动作执行与治理机制。

AI Search 的工程工作贯穿数据接入、索引布局、查询执行和持续演化。DiskBBQ 相关优化说明，减少无效读取、冗余数据与重复构建，往往与改进算法本身同样重要；面向后续能力，自动化索引与统一数据底座可以降低系统维护成本，知识与业务语义建模则为 Agent 提供更可靠的上下文和行动边界。

筑基千亿 , 毫秒破局: 腾讯云 ES 重塑 Al Search 新范式-- 2026 ES Meetup

着重介绍腾讯云 ES 在千亿规模 AI Search 的优化实践, 根据陈曦的 Elasticsearch Meetup 2026 分享整理。图片按原 PDF 页码编号，正文逐图对应；测试结果仅适用于所述条件，Coming Soon 部分介绍探索方向。

数据库

云计算

人工智能

腾讯云ES AISearch实践：通过DiskBBQ内核优化、Slice多租户隔离、标量向量融合索引及Segment复用，解决千亿级数据检索的延迟与成本问题，性能提升可达5.5倍，索引构建耗时缩短17倍。

日志分析

数据管理

文件系统

内存管理

数据处理

文档处理

GraphRAG

路由

Spark 

Agent

2026上云采购 | AI焕新·智启新局

ES特惠专场，新客首购5.5折起！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

筑基千亿 , 毫秒破局: 腾讯云 ES 重塑 Al Search 新范式-- 2026 ES Meetup

筑基千亿 , 毫秒破局: 腾讯云 ES 重塑 Al Search 新范式-- 2026 ES Meetup

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐