导读
这两年做产品，绕不开一个问题：用户在搜索框里输入一句大白话，系统能不能理解意思，把语义相关的内容找回来。做 RAG、做知识库问答、做站内智能搜索，底层都是同一件事------检索。
选型的信息很杂。有人说直接上专用向量数据库，有人说 PostgreSQL 加个插件就够，还有人发现 MongoDB 从某个版本开始也能做全文检索和向量检索了。到底怎么判断？
这篇把三件事讲清楚：向量检索和传统关键词检索各自的能力边界；MongoDB 现在的检索能力具体是什么架构、从哪个版本能用、怎么写、有哪些坑；最后给一个可复用的选型框架，帮你判断什么场景一套数据库就够，什么场景该拆成专用组合。
一、关键词检索和向量检索，各自解决什么
先把两种检索的能力边界摆清楚，后面的选型才有依据。
关键词检索（也叫全文检索，打分算法通常是 BM25）做的是字面匹配。你搜「iPhone 充电慢」，它把查询切成词，去倒排索引里找同时包含这几个词的文档，按词频和稀有度打分。它的优点是精确、可解释、对专有名词和代码片段和订单号这类精确串特别强；缺点是不懂同义和转述，你搜「手机没电快」它就匹配不上「电池续航差」。
向量检索做的是语义匹配。先用一个 embedding 模型把文本转成几百到几千维的浮点数组，语义相近的文本在向量空间里距离也近。查询时把问题也转成向量，找空间里最近的若干个。它能跨措辞、跨语言、跨表达习惯；代价是会出现看起来相关、实际答非所问的情况，而且模型没见过的新词、专有缩写、精确 ID 往往处理不好。
一个严肃的搜索系统通常两种都要。 只靠关键词，语义泛化能力弱；只靠向量，精确匹配和可解释性差。现在主流做法是两路一起召回，再融合排序，这个结构后面第四节会展开。
二、MongoDB 是怎么做全文和向量检索的
很多人对 MongoDB 检索能力的印象还停留在 $text 索引。那套东西对中文很不友好------中文分词要靠企业版的商业插件，而这个插件已经停止支持。现在能打的是另一套：MongoDB Search 和 Vector Search。
它的核心是一个叫 mongot 的独立进程。 mongot 内部打包了 Apache Lucene，和数据库进程 mongod 一起部署。它通过 change stream 实时订阅数据变更，在自己这边维护一套 Lucene 倒排索引和向量索引。你在聚合管道里用 $search、$vectorSearch、$searchMeta 这几个阶段发查询，mongod 收到后转发给 mongot，拿回文档 ID 和打分再回表。
这个设计意味着几件事。索引是近实时最终一致的，写入到可被检索之间有毫秒到秒级延迟。mongot 是一个额外的 JVM 进程，要额外的内存、磁盘和运维，可以简单理解为在数据库旁边多养了半套搜索引擎。从架构上看，这更接近在数据库旁挂一个深度集成的搜索引擎边车，它独立于存储引擎运行，和普通索引内建在 mongod 里的方式不一样。
全文检索方面 ，mongot 直接复用 Lucene 的分析器。和中文相关的内置项有三个：lucene.cjk 走二元组切分，把「机器学习」切成「机器」「器学」「学习」，召回高但精度一般、索引偏大；lucene.smartcn 用词典加隐马尔可夫模型做真正的词切分，简体中文效果较好，但对繁体、专业术语、新词一般；lucene.chinese 是基于词典的旧版分析器。也支持自定义分析器，但内置分词器里没有 jieba、IK、HanLP 这种级别的中文分词器。想要那种效果，要么在写入前自己分好词按空格存，要么接受 smartcn 的水平。
向量检索方面 ，底层是 Lucene 的 HNSW 图索引，支持近似最近邻和精确两种检索，支持标量量化（int8）和二值量化把存储压缩四到三十二倍，向量维度上限目前是 8192。查询用 $vectorSearch 阶段，可以带元数据预过滤。
三、从哪个版本开始，怎么用
如果用 MongoDB Atlas 云服务。 全文检索大约在 2020 年正式可用，向量检索在 2024 年 6 月正式可用，都是托管的，不用自己管 mongot。这是门槛最低的方式。
如果自己部署。 MongoDB 8.2 在 2026 年 6 月 30 日正式把 Search 和 Vector Search 带到自托管场景，社区版免费提供，企业版作为付费插件。硬性要求是必须副本集或分片集群，不支持单机，而且要自己安装、配置、运维 mongot。
如果用阿里云 ApsaraDB for MongoDB。 它在 MongoDB 8.3 及以上版本支持 MongoDB Search，同样基于 mongot 搜索节点，通过 change stream 异步同步，内置 lucene.chinese 中文分析器。要求是副本集独享型或分片集群独享型实例，搜索节点按规格和存储独立计费，官方建议搜索节点规格不低于主实例，目前仅公共云地域支持，有一个月的免费试用额度。
下面是几段通用写法，用一个 articles 集合示意。
建一个向量索引，并让数据库自动生成向量（自动向量化在 8.2 社区版是预览特性，阿里云在 8.3 支持）：
js
db.articles.createSearchIndex(
"vec_idx",
"vectorSearch",
{
fields: [
{
type: "autoEmbed", // 写入和查询时自动调 embedding 模型
path: "content",
model: "text-embedding-v4", // 外部模型，需要配 API Key
numDimensions: 1024,
similarity: "cosine",
quantization: "scalar"
},
{ type: "filter", path: "lang" }
]
}
)这里要留意：自动向量化调的是外部 embedding 模型的 API（阿里云的 text-embedding 系列或 Voyage 系列），不是数据库里内置了一个模型。 它省掉的是你自己搭 embedding 管线的活，网络出口和模型调用费用还是要有。
向量检索查询：
js
db.articles.aggregate([
{
$vectorSearch: {
index: "vec_idx",
path: "content",
query: "怎么给老人挑一台好用的手机", // autoEmbed 下可直接传文本
numCandidates: 200, // 召回候选数，越大越准越慢
limit: 20,
filter: { lang: "zh" }
}
},
{ $project: { title: 1, score: { $meta: "vectorSearchScore" } } }
])全文检索按字段加权，标题权重高于正文：
js
db.articles.aggregate([
{
$search: {
index: "text_idx",
compound: {
should: [
{ text: { query: "手机 续航", path: "title",
score: { boost: { value: 3 } } } },
{ text: { query: "手机 续航", path: "content",
score: { boost: { value: 1 } } } }
],
filter: [ { equals: { path: "status", value: 1 } } ]
}
}
},
{ $limit: 20 }
])关键词和向量两路混合，用排名融合（$rankFusion 在 8.1 及以上可用）：
js
db.articles.aggregate([
{
$rankFusion: {
input: {
pipelines: {
lexical: [ { $search: { /* 上面的全文查询 */ } }, { $limit: 100 } ],
semantic: [ { $vectorSearch: { /* 上面的向量查询 */ } } ]
}
},
combination: { weights: { lexical: 1, semantic: 1 } }
}
},
{ $limit: 50 }
])再往后，可以把 $meta 里的搜索得分取出来，在聚合管道里叠加发布时间衰减、作者权威度、互动量这些业务信号做二次排序；8.3 还提供 $rerank 阶段直接挂重排模型（目前在 Atlas 上是预览）。
常见坑与排查。 建完索引查不到结果，先确认 mongot 同步完成，大批量写入后要等回填。中文召回不理想，多半是分析器选得不对，smartcn 和自定义分析器要按语料实测。查询慢，numCandidates 调太大或量化没开都会拖延迟。单机开发环境起不来，因为 mongot 必须连副本集，本地要先把单节点转成副本集。$search 和 $vectorSearch 不能在事务里用。
四、可复用框架：AI 搜索的三段漏斗，和一张选型分界线
三段漏斗
不管用什么数据库，一个像样的 AI 搜索链路都可以拆成三段，从宽到窄：
第一段，召回（粗排）。 关键词检索取 top-N，向量检索取 top-N，两个结果集用排名融合（RRF）合并成一两百个候选。这一段要让召回够广，宁可多召回一些噪声，也不要把正确答案漏在门外，评价指标看召回率。
第二段，精排。 用一个交叉编码器重排模型，对候选集里每一条查询和文档的配对重新精细打分，取更靠前的几十个。交叉编码器把查询和文档拼在一起过模型，比向量检索那种查询和文档分开编码再算距离要准得多，代价是慢，所以只能用在小候选集上。这一段追求的是排得准。
第三段，业务重排。 在精排结果上叠加产品维度的信号：内容时效性、作者权威度、个性化偏好、商业权重。这一段把技术上最相关的，调整成业务上最该展示的。
写成一个式子：
最终顺序 = 业务信号加权( 精排( RRF( 关键词排名, 向量排名 ) ) )
大多数团队一上来只做了中间的一小段------一次向量检索加一次排序，召回不够广，精排没有,业务信号靠前端硬排。按这三段补齐，效果提升通常比换数据库更明显。
一栈到底，还是专用组合
判断该用一套数据库搞定，还是拆成专用检索组件，看四个维度：
| 维度 | 倾向一栈到底（MongoDB / PostgreSQL 等） | 倾向专用组合（Elasticsearch + 向量库 + 重排模型） |
|---|---|---|
| 数据在哪 | 数据已经在这个库里，不想再搭同步管线 | 已经有独立数据平台，多搭一套检索系统成本可接受 |
| 语料规模 | 文档量在千万级以内 | 文档量上亿，或增长曲线很陡 |
| 检索定位 | 检索是产品的一个功能点 | 检索是核心竞争力，排序质量直接影响留存和收入 |
| 团队与排序要求 | 团队小，BM25 加向量加简单重排够用 | 需要极致中文分词、精细相关性调优、甚至排序学习 |
有个经验数字可以参考：大多数 RAG 应用的文档量在十万到一百万之间，这个量级 PostgreSQL 加 pgvector、或者 MongoDB Search，都能扛住，没必要一上来就上分布式向量集群。反过来，当检索是你的护城河、语料到了亿级、要把中文排序打磨到极致，那么各个环节用最强的专用组件更划算。
两种典型的踩坑方向：一是过度工程化，数据量不大却上了一套重系统，运维成本吃掉了收益；二是轻装冒进，用最省事的方案起步，等数据涨上来发现扩不动，被迫推倒重来。选型时真正要回答的，是这套方案能陪产品走多远。
关键结论
- 关键词检索强在精确和可解释，向量检索强在语义泛化，严肃的搜索系统两者都要，用排名融合合并。
- MongoDB 的全文和向量检索靠独立进程
mongot，是挂在数据库旁边的 Lucene 搜索引擎，近实时同步，要额外的资源和运维。 - 版本门槛：Atlas 一直可用；自托管从 8.2 起，社区版免费但要自管
mongot，且必须副本集；阿里云 ApsaraDB for MongoDB 从 8.3 起支持，搜索节点独立计费。 - 自动向量化省的是搭 embedding 管线的活，底层仍然是调外部模型 API，不是数据库内置模型。
- AI 搜索按「召回、精排、业务重排」三段漏斗补齐，收益通常比换数据库更大。
- 千万级以内、检索是功能点、团队小，一套数据库够用；亿级、检索是护城河、要极致排序，才值得上专用组合。