向量数据库品类的兴衰：Jo Kristian Bergum（前 Vespa 首席科学家）
摘要
- 嘉宾的核心判断是，向量数据库公司可能存活，但独立的向量数据库品类不会。 如今 PostgreSQL 已通过 pgvector 提供向量搜索，Elasticsearch、Solr、Vespa 等系统也都支持；能够长期存在的抽象是搜索，向量则会退居实现细节：“我不是说这些公司会消亡，但我是说这个品类会消亡。”
- 这个品类吸引的风险资本，超过了其可能承载的市场结构。 宿主估算，约有2.3亿美元流入向量数据库，比 MongoDB 整个生命周期募集的资金还多；未经验证的消息称，Pinecone 曾快速冲到“接近1亿美元 ARR”，随后失去动能：“它们不可能全都赢。”
- 实用的 RAG 技术栈，始于干净的数据和沿用了30年的关键词基线，而不是某个专业数据库。 嘉宾建议先用 BM25，再用现成的嵌入模型做混合搜索，只有在延迟和成本可承受时才加入重排序；合理规模下 PostgreSQL 可能已经够用，但搜索质量决定业务成败的公司应考虑专用检索引擎。
- 长上下文会消除部分旧式 RAG 工作负载，但不会消除检索本身。 单份 PDF 或约300篇文章可能直接放进 Gemini 的上下文窗口，尤其在不要求高 QPS 的情况下，2023年初那套向量管线就没有必要了。但170,000份文档已经对应3600万 tokens：“你不可能为了单次查询把这些全部加载进去……”
- 嵌入仍是基础设施，但单靠余弦相似度无法实现高质量搜索。 新鲜度、权威性、元数据和重排序仍然重要；大型推荐系统会先用嵌入召回候选池，再层层筛选到可能约100个结果：“嵌入会长期存在（‘Embeddings are here to stay.’）。”
- 嘉宾认为 PostgreSQL 在中等规模下合理，但反对把模型推理塞进数据库。 他并不看好用巨型 SQL 管道完成数据转换、嵌入和重写，因为推理和存储遵循不同的扩展规律，而且他希望明确掌控成本与性能。
- 下一轮嵌入机会可能在领域专用的多模态文档检索，但经济模型仍不确定。 讨论认为 Voyage 是领域专用模型的领先者，并提到其已被 Nvidia 收购；Jina AI 也在做出色的工作，尤其是在欧洲语言方面。嘉宾希望法律、金融和医疗文档模型能够直接嵌入页面截图而无需 OCR，但 API 算力和批处理让这成为“困难的商业模式”。
精读
1. 向量数据库还没成为持久品类，就先变成了一个功能
嘉宾将这个品类追溯到2022年11月，当时 OpenAI Cookbook 的一个示例通过嵌入把 ChatGPT 接入用户数据。他参与编写了其中的 Chroma 示例，也是天使投资人，但他说，开发者由此形成了一种“不自然的关联”：RAG 中的检索必须意味着向量。
Pinecone 随后将嵌入包装成一个新的基础设施品类：如果每个 AI 应用都需要嵌入，那么每个应用就都需要向量数据库。宿主援引未经核实的传闻称，Pinecone 曾快速冲到“接近1亿美元 ARR”（“like $100 million ARR”）；嘉宾则认为其后来面向开发者的定位，是在回归初心。
Turbopuffer 带来的竞争确实重要，但更重要的是市场趋同：pgvector、Elasticsearch、Solr、Vespa 以及大量数据库都提供向量搜索。嘉宾的区分是品类层面的：“我不是说这些公司会消亡。”
宿主对风投市场的盘点显示，约2.3亿美元进入了向量数据库初创公司，超过 MongoDB 整个生命周期募集的资金。MongoDB 建立了更宽泛的 NoSQL 品类；向量数据库则“太窄”，难以以同样的方式站稳。
2. 搜索质量决定复杂度逐层增加
对于已经运行在 PostgreSQL、规模合理的工作负载，嘉宾认为 pgvector 足够可靠：它增加了 IVFFlat、HNSW、半精度和二进制向量支持。但如果搜索质量决定业务成败，就应考虑专用检索引擎。
RAG 的流程应从检查和清理数据开始，尤其是 PDF。BM25——存在了30年的“关键词匹配”——提供了强劲基线；随后加入混合嵌入搜索，最后才是在应用能够承担延迟和成本时进行重排序。
宿主提到重排序可能只增加“3%到4%”，并询问这些阶段应如何排序。嘉宾不接受一套放之四海而皆准的配方；在大规模场景中，推荐系统会从嵌入召回开始，经过多层重排序级联，直到可能只剩约100个候选。
3. 模型推理和数据库遵循不同的扩展规律
在每秒数千次查询的场景下，嘉宾会避免依赖一个远程嵌入 API，尤其是不希望它以 JSON 浮点数返回结果；他更倾向于本地、速度更快的方案。他回忆说，过去认为针对大型浮点向量、约300毫秒的接口调用尚可接受，但现在越来越倾向于认为，小规模工作负载更适合使用 API 服务。
他仍然“不看好”类似 PostgresML 的设计，即把嵌入和 LLM 推理塞进巨型 SQL 语句。存储和推理的扩展规律不同，而不透明的执行过程会削弱对成本和性能的控制；宿主也承认，数据库与外部系统之间的边界始终存在张力。
4. 长上下文淘汰过时的 RAG 演示，但不会淘汰检索
嘉宾说，读者错误地把“向量数据库品类已死”转换成了“RAG 已死”。通过检索或搜索增强 AI，在“很长时间内”仍然 relevant，即使实现方式不再依赖专用向量存储。
关键在于工作负载：1份视觉型 PDF 或300篇文章，可能直接放进 Gemini，尤其是在没有高 QPS 要求时。上下文窗口已经从4K或8K扩展到1000万，但人们仍在反复复现2023年1月初、围绕旧限制设计的演示。
嘉宾一条含义隐晦的推文称，Llama 4 将重新点燃“长上下文对决 RAG”的争论，并以“不是你想要的方式”解决它。宿主认为，“长上下文会杀死 RAG”这种一概而论的说法，本质上是在骗互动。
具体边界是170,000份文档、合计3600万 tokens——这已经多到不可能为每次查询全部加载。
5. 更好的数据构建释放图谱与文档原生嵌入
嘉宾反对 GraphRAG 的理由并不是图遍历：图数据库很擅长边遍历、随机访问以及沿边跳转。真正的瓶颈在于构建实体和关系；他“讨厌这种关联”——仿佛采用一个概念，就必须绑定某一种特定数据库技术。
GraphRAG 在某些场景下可能胜过 Vector RAG，也可能作为混合方案使用。讨论认为，LLM 或许能降低生成三元组这一过去很难的任务的门槛；至于知识图谱是否会不再是一个“脏词”，则仍然只是：“也许，也许，也许（‘Maybe, maybe, maybe.’）。”
嘉宾期待的前沿方向，是面向法律、金融和医疗文档的领域专用嵌入模型，理想情况下使用视觉语言模型骨干，在无需 OCR 的情况下嵌入截图。讨论认为 Voyage 正在引领这一方向，并提到其已被 Nvidia 收购；Jina AI 也在做“很多出色的事情”，尤其是在欧洲语言方面。但供应商必须通过 API 为推理和批处理买单，这会推动公司转向企业搜索等更高价值的上层应用。