企业官网建设流程全解析

独立向量数据库最尴尬的结局：同行还没分出胜负，Postgres、Redis、MongoDB、SQL Server 这些老家伙已经上桌夹菜了。

几年前做 RAG，方案里写 Pinecone、Milvus、Qdrant，看着很正常；现在不少团队新起检索需求，第一反应反而是先上 pgvector，或者直接用现有 MongoDB、Redis、Elasticsearch 那套搜索能力，撑不住再说。

pgvector 没有一夜之间吊打所有专用库。变化发生在另一层：存向量、建索引、找 TopK，正在从独立卖点变成数据库标配。向量检索本身的天花板还挺高，独立“向量数据库”品类的默认购买理由却在变弱。

存向量和查 TopK，已经不神秘了

向量检索核心动作很单纯：一段文本变成 embedding，embedding 存起来；用户问题也变成 embedding，再找距离最近的 K 条。听着像 AI，底层其实是老问题，近似最近邻搜索，ANN，早就不新鲜。

生产里常见的两条路，一条是 HNSW 图索引，一条是 DiskANN 这类面向大规模磁盘场景的索引。

HNSW 的思路很像在城市里问路，不用从每条街挨个走过去，先在高速路网里跳到目标附近，再往小路里钻。速度快，代价是“近似”，也就是召回率和延迟之间做交易。

DiskANN 系解决另一类问题：向量太多，内存放不下，还想靠 SSD 查得动。Timescale 的pgvectorscale就是把那套思路搬进 Postgres 生态里。

单看“最近邻搜索”这层，天花板没有想象中玄。后面的进步更多是在召回率多抠几个点、尾延迟少抖一点、同样机器多塞一点向量、索引构建别慢到怀疑人生。重要是重要，但更像数据库工程，不像一座没人爬上去过的新山。

pgvector 最烦的坑在过滤

吹 pgvector 的文章，最爱说“Postgres 里直接存向量，还能和业务表一起查”。话没错，但真上线，第一个容易咬人的地方就是WHERE。

比如一个知识库表长这样：

selectid,title,contentfromchunkswheretenant_id=123anddoc_type='contract'orderbyembedding<=>$query_embeddinglimit10;

看着很自然。先限定租户和文档类型，再按向量相似度排序，取前 10。

麻烦在于，HNSW 这种 ANN 索引和普通 B-tree 两套脾气。pgvector 文档里hnsw.ef_search默认是 40，意思是查询时动态候选列表默认就那么大。过滤条件如果很稀疏，候选拿回来以后再被tenant_id、doc_type刷掉，最后可能凑不够limit 10。

一个很粗的心算：ef_search = 40，过滤条件命中 10%，平均剩 4 条；如果命中 1%，平均连 1 条都不到。线上看到的现象很讨厌，库里明明有相关内容，查询不报错，只是返回很少，甚至返回空。排查时第一反应会怀疑 embedding、分块、提示词，最后才发现是过滤条件把召回打没了。

pgvector 0.8.0 之后有iterative_scan，可以让它不够就继续往下扫：

sethnsw.iterative_scan=relaxed_order;sethnsw.ef_search=100;

hnsw.max_scan_tuples默认 20000，文档里也写得很明白，它控制 HNSW 最多访问多少 tuple 的近似上限。开了以后结果更稳，延迟也会跟着上来。

向量检索一旦和元数据过滤搅在一起，麻烦就不再是“索引快不快”这么简单了。先过滤还是先向量搜、候选拿多少、过滤选择率多低、错过结果能不能接受，全都会变成工程问题。

不少专用向量库的卖点恰好也在过滤上，Qdrant 专门写过 filterable HNSW，Redis 文档里也把带过滤的 KNN 查询单独展开讲。各家文档都在暗示同一个痛点。

建索引会在千万级露出脾气

小数据量最容易骗人。几十万条 chunk，随手CREATE INDEX，查询一跑挺快，感觉 pgvector 稳得很。到千万级以后，麻烦开始冒头。

pgvector README 里有一句很实在：HNSW 图如果放不进maintenance_work_mem，构建会明显变慢，还会打出 notice：

NOTICE: hnsw graph no longer fits into maintenance_work_mem DETAIL: Building will take significantly more time.

那行日志比很多选型 PPT 管用。它说明 HNSW 没法只靠“加个索引”糊弄过去。m默认 16，ef_construction默认 64；调高能改善召回，但构建更慢、写入也更重。maintenance_work_mem、并行 worker、索引重建窗口、线上回滚方案，都得开始进入方案。

不少团队从 pgvector 往专用库搬，触发点往往不在第一天查询慢，而是半年后数据涨上去，重建索引、调参数、隔离租户、控制尾延迟，这些活开始挤在一起。到那时再问“pgvector 能不能用”，问法就粗了。更该问：当前数据量、过滤条件、写入频率、可用维护窗口，Postgres 还能不能扛得舒服。

老数据库在把向量检索吃进去

独立向量数据库最难受的地方，在产品层。底层能力一旦成熟，通用数据库就会来收租。

SQL Server 2025 文档里已经有vector数据类型、VECTOR_DISTANCE、CREATE VECTOR INDEX、VECTOR_SEARCH。MongoDB Vector Search 可以把向量搜索和全文搜索、字段过滤放在一起。Redis 文档里直接写了 FLAT、HNSW、SVS-VAMANA 这些向量索引。Cassandra 5.0 也把 Vector Search 放进了官方文档。

几个名字摆在一起，信号很明显：向量检索正在变成数据库的一项能力，像全文索引、JSON 字段、地理空间查询一样。刚开始是单独产品最先把体验做出来，后来通用数据库把常用能力吸进去，最后大部分业务在原来的数据库里顺手解决。只有规模、过滤、延迟、运维形态真的卡住时，才会单独拉一套专业系统。

全文搜索以前也有专门系统，后来 MySQL、Postgres、SQLite 都有基础全文能力，但 Elasticsearch 仍然活得很好。原因很简单，通用数据库吃掉的是基础需求，复杂搜索体验还是需要专门系统。向量数据库已经有这个味道了。

厂商基准能看，但别当判决书

Timescale 的pgvectorscaleREADME 里有个很有冲击力的 benchmark：5000 万条 Cohere embedding、768 维、99% 召回，Postgres + pgvector + pgvectorscale 对比 Pinecone 的 storage optimized index，p95 延迟低很多，吞吐也高很多，还说自托管成本低。

这组数字很适合传播，也很适合谨慎看。厂商 benchmark 永远带立场。数据集、查询分布、过滤条件、部署方式、成本算法，换一个就可能变样。

不过它至少说明一件事：专用向量数据库已经没法只靠“我更快”三个字躺着收费了。Postgres 生态追上来的速度，比很多人预期快。

资本和产品动作也在往 Postgres 方向挤。Databricks 收 Neon，Snowflake 收 Crunchy Data，Supabase 这种 Postgres 平台估值一路抬高。它们不都是为了向量搜索，但 AI 应用把“应用数据 + 检索 + 事务 + 权限 + 开发体验”重新绑到一起，Postgres 这张老牌桌子又热了。

向量数据库的压力就在于：如果只是存向量和查近邻，老数据库会越来越够用。

天花板高的地方不叫“向量数据库”

向量检索还没定型的地方，在检索链路。生产级 RAG 很少只靠向量召回，产品型号、合同编号、错误码、API 名，光靠语义相似度会漏。BM25 关键词召回得进来，元数据过滤得进来，rerank 得进来，权限、租户、时间衰减、文档版本也都得进来。

一条看起来简单的问答链路，最后会变成这样：

query -> query rewrite -> BM25 召回 -> vector 召回 -> metadata filter -> merge / dedup -> rerank -> permission check -> context packing -> LLM

“向量数据库”四个字，盖不住这条链路。它更像检索基础设施，或者 AI 应用的 memory layer。向量库只是其中一块，位置还挺靠下。

选型别按品牌，按疼点

真做项目时，别一上来问 Milvus、Qdrant、Pinecone、pgvector 哪个最强。问法本身容易把事情带偏。

先看哪块疼。

土办法反而管用：先用已有数据库跑起来，然后拿真实数据压三件事。过滤选择率降到 10%、1%、0.1% 时，TopK 还能不能凑够；索引重建要多久，期间线上服务怎么处理；混合检索加 rerank 后，端到端延迟能不能接受。

压测结果说不清，品牌选得再漂亮也没用。

天花板被谁压低了

向量数据库不会消失。Milvus、Qdrant、Pinecone、Weaviate 仍然有位置。规模够大、过滤够复杂、延迟要求够狠、团队想把检索能力单独平台化，专用库还是有意义。

但“只要做 RAG 就该上向量数据库”这句话，已经过时了。向量检索的天花板没被压低，独立向量数据库的默认购买理由被压低了。

后面的默认路径会更像：先在原有数据库或搜索系统里把向量能力用起来，等过滤、规模、尾延迟、运维隔离真的卡住，再把向量检索拆出去。分界线怎么画，各家差异会很大。

如果有团队在 pgvector 上扛过复杂过滤，尤其是hnsw.iterative_scan、ef_search、租户过滤一起上的场景，我倒挺想看实际配置和翻车点。比继续争“向量数据库有没有未来”有用多了。