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 数据平台。
