AI 时代为什么需要数据底座
在生成式 AI 深入业务的过程中，越来越多团队发现：AI 应用落地的难点，不只在模型本身，也在 AI 时代的数据链路建设。
业务数据在传统数据库里，向量在独立的向量库里，全文检索又是另一套引擎；数据在多个系统间来回搬运，还要接入各类工具和平台，同步成本、数据一致性风险和运维复杂度都在上升。
作为 MongoDB 社区迄今最新的版本，MongoDB 8.3 在读取、写入和复杂查询性能上都有明显提升，并把向量检索与 Auto Embedding 能力带进数据库引擎。
今天，火山引擎正式推出 MongoDB 8.3 版本。相比单纯升级社区能力，火山 MongoDB 8.3 更核心的变化，是把业务数据、向量生成、向量检索和混合检索尽量收进同一条产品链路里，并与火山方舟大模型平台深度融合，对接 Doubao-Embedding 等模型，帮助企业更快落地 RAG、语义搜索、智能推荐等 AI 场景。
结合火山方舟，把 Auto Embedding 收进火山 MongoDB
传统方案里，一条产品文档从写入到可被语义检索，通常要经过这些步骤：应用代码调用 Embedding API、处理返回的向量格式、把向量写入向量数据库、触发索引更新，再处理调用失败和重试。查询时，还要再调一次 Embedding，把用户问题转成向量，再拼装查询参数。这些代码和管道都需要业务团队自己建设和维护。
火山 MongoDB 8.3 结合火山方舟，支持 Auto Embedding 能力，可自动完成文档数据的向量生成、存储与检索。这一变化的核心，不只是少写几段代码，而是把原本分散在 Embedding 服务、向量库和应用侧的链路，尽量收回到数据库。
😃 火山方舟是火山引擎的一站式大模型服务平台，把字节跳动训练、打磨并支撑自身业务的大模型能力，以 API 形式开放给企业：豆包每天数百万亿 tokens 真实调用、50+ 场景验证，规模效应带来同配置更低价；上下文 256K 起步、数十家模型聚合、批量推理、兼容 OpenAI，从调模型到搭 Agent 一步到位。
AI 应用使用火山 MongoDB 8.3 后，数据链路会变成这样：
- 业务代码只需要写入或更新 MongoDB 8.3 中的文档，并指定需要向量化的文本字段；
- MongoDB 8.3 提取该字段内容，调用配置好的火山方舟 Embedding 模型生成向量；
- 向量写回后，MongoDB 8.3 会自动维护对应的向量索引；
- MongoDB 中的数据持续变化时，系统会通过变更监听机制做增量向量化，不需要业务侧轮询或手动触发；
- 业务直接用自然语言查询 MongoDB 指定字段时，模型会自动完成转向量，业务侧不需要单独调用 Embedding API、管理向量格式或拼装查询参数。
图1. Auto Embedding 数据生命周期
对开发者来说，最直接的变化，是开发 AI 应用时需要维护的代码明显变少了：写入逻辑里不再有 Embedding 调用和向量拼装，检索逻辑里不再有两路查询和手动融合。业务代码可以更聚焦业务本身——写入文档、构造查询条件、处理返回结果。
图2. Auto Embedding 控制台配置（产品示意图）
向量检索能力进一步增强
在把 Embedding 链路收进数据库之后，火山 MongoDB 8.3 继续补齐检索的关键能力：
- 支持原生向量检索： 对于已有自建模型或第三方模型生成向量的业务，无需改造现有向量化流程，即可将向量数据写入火山 MongoDB 并直接使用向量检索能力。无论选择 Auto Embedding 还是自带向量数据，都能在同一个库内承载向量的存储、索引与检索，避免在应用层维护多套数据系统。
- 混合检索正式发布： 全文检索与向量检索可在一次查询中完成，并支持多种归一化排序策略，直接输出统一的相关性排名结果。
- 检索架构独立演进： mongot 作为基于 Apache Lucene 构建的独立搜索进程，始终与 mongod 解耦部署，检索负载与数据库核心事务互不干扰。8.3 版本中，向量检索能力进一步模块化，mongot 可独立于数据库主版本迭代升级；同时，mongot 节点已纳入控制台完整生命周期管理，包括开启、关闭、变配和监控，无需再单独维护一套独立搜索集群。
- 向量维度支持更高： 最大支持 8192 维向量，可以满足主流 Embedding 模型的输出需求。
性能大幅提升，AI 检索和在线业务共用一套底座
要让 AI 检索真正跑进线上业务，底座性能必须跟上。MongoDB 8.3 在查询执行、存储引擎写入路径、事务协调和复杂查询处理上做了系统性优化。相比 8.0 版本，在不修改任何应用代码的情况下：
- 读取吞吐量提升约 45% ——更高效的查询执行引擎与缓存优化
- 写入吞吐量提升约 35% ——改进的 WiredTiger 存储引擎写入路径
- ACID 事务吞吐量提升约 15% ——优化的事务协调机制
- 复杂操作性能提升约 30% ——聚合管道与多阶段查询深度优化
这些数据来自指定测试环境和工作负载，实际收益还会受到业务数据模型、查询模式、实例规格和数据分布的影响。对 AI 应用来说，性能提升意味着向量检索与在线业务可以共享同一套高性能底座，更好满足 100ms 以内检索延迟和亚秒级上下文更新的要求。
图3：MongoDB 8.3 vs. 8.0 性能
All In One：把数据、检索和 RAG 链路尽量收在一个库里
火山 MongoDB 8.3 版本定位为 AI 应用 All In One 的数据存储底座。基于 MongoDB 的 JSON 文档模型，同一条记录里可以同时保存结构化字段、半结构化内容、业务元数据和向量等信息，不需要把它们拆到不同系统里。
- 数据存储 All In One： 结构化、半结构化、KV、向量、时序、地理信息等各种模态数据统一存储，免去多套系统的维护成本。
- 数据查询 All In One： 在线查询、向量检索、全文检索、混合检索基于单一数据库一站式完成。
- RAG AII In One： 知识数据文本存储与向量全文检索一体化，无需借助外部向量数据库即可实现完整 RAG 链路。
底层架构中，mongod 负责文档数据存储，mongot 作为检索引擎支持流式更新索引，Lucene 提供单机向量和全文检索核心能力。8.3 版本中，承载向量检索能力的 mongot 节点可纳入控制台完整生命周期管理，包括开启、关闭、变配和监控，运维团队不需要再单独管理一套独立向量数据库集群。
图4. MongoDB 8.3 架构图
图5. 火山 MongoDB 8.3 链路
这些能力已经在多个 AI 场景中得到验证
从产品能力回到落地场景，火山 MongoDB 已在多个 AI 场景中得到验证：
- 智能推荐： 通过用户行为向量与物品特征向量的相似度计算，实现“千人千面”推荐。MongoDB 的灵活 Schema 可同时存储用户画像、物品属性和向量嵌入，单库完成全链路数据支撑。
- RAG 检索增强生成： 企业知识库场景中，将文档内容向量化存储，结合全文检索实现高召回率的知识检索，配合火山方舟大模型生成精准回答。Auto Embedding 让知识库更新无需运维干预，文档变更即刻同步。
- 多模态内容检索： 跨文本、图像、音频的语义匹配，支持“以图搜图”“以文搜图”等场景。
- AI Ops 智能运维： 基于全文检索与时序能力，对运维日志、群聊消息进行智能分析，实现告警自动归因和应急处理辅助。
在业务规模上，火山 MongoDB 支持 MongoDB 4.0～8.3 全版本，线上单库集群最大数据量达 PB 级，最大百万级 QPS，广泛服务于汽车、互联网、AI、游戏等行业客户。
图6. 业务案例示意
下一步：继续补齐 AI 数据平台能力
火山 MongoDB 将持续在 AI 方向深耕，重点规划方向包括：
- 向量能力持续增强： 未来将支持客户使用自定义 Embedding 模型以覆盖更多垂直领域场景，同时扩展文本和图片的多模态 Auto Embedding 支持，并引入 Text Rerank 精排能力进一步提升检索精度。
- 性能与架构演进： 向量搜索引擎将进一步向数据库原生模块迁移以降低部署复杂度，同时优化大规模分片集群的向量检索横向扩展能力，并引入HA高可用组件支持从节点故障自动切换，提升整体数据面稳定性。
- 开发者体验提升： 将提供 Auto Embedding 索引的在线编辑和重建能力，支持 SDK 级别直接创建向量索引，并持续完善监控告警和诊断体系。
- 生态拓展： 将深化与火山方舟大模型平台的融合，拓展更多 AI 开发框架的原生对接，并持续完善 MongoDB MCP Server 能力。
图7. 火山 MongoDB 演进方向
结语：支持 AI，更把 AI 数据链路做成产品能力
MongoDB 8.3 把向量生成和检索收进数据库，缩短的是数据链路，减少了 AI 应用开发和维护的成本，让团队把精力从维护同步管道和排查数据不一致，转向切分策略、排序调优和问答体验这些更贴近业务的事。
对火山 MongoDB 来说，亮点不只在于支持向量检索和 Auto Embedding，更在于与火山方舟大模型生态深度打通，把模型接入、字段配置、用量监控和节点管理放进统一的产品流程。
如果你的团队正在为知识库、RAG 或语义检索维护多套系统和组件，不妨申请试用火山 MongoDB 8.3，体验 All In One 的 AI 数据平台。
