检索基础设施与向量存储

向量搜索的概念验证与能够承受真实查询流量的生产系统，是两个完全不同的工程问题。我们构建并运维位于您 RAG 流水线、智能体工作流或语义搜索产品底层的检索基础设施层——包括向量引擎、为其供给数据的嵌入流水线、保持其健康运行的索引生命周期管理，以及在用户察觉之前捕获质量退化的可观测性栈。

在引擎选择上我们保持厂商中立。我们的实践对以下引擎一视同仁： Qdrant、Milvus、Weaviate、pgvector 和 Elasticsearch kNN，至于我们推荐哪一款，取决于您的向量规模、查询模式、多租户需求和运维能力。

从 5 万向量的演示到 2 亿向量的生产系统

演示与生产系统之间的差距，几乎完全是一个基础设施问题。演示将 5 万个向量 载入 Pinecone，运行一次余弦相似度查询，并在 40 毫秒内返回结果。生产环境则完全不是这样。

• 2 亿个向量 、 每秒 500 次查询 的持续负载
• 15 个元数据过滤维度 ，且文档更新频率为 每小时
• 三个团队在严格的租户隔离下共享同一个集群

在这样的规模下，HNSW 压缩峰值会将您的 P99 拉升至 800 毫秒，召回率在经历一周的增量更新后会悄然退化，而嵌入流水线也跟不上您的文档变更速率。这正是我们发挥作用的地方。

引擎选择是一项基准测试工作，而非品牌决策

每家厂商都声称拥有业界领先的性能；而基准测试讲述的是一个更微妙的故事。我们不是从功能矩阵中挑选数据库——我们载入您真实的向量，用您真实的元数据过滤器运行您真实的查询，并在具有运维意义的 k 值上衡量召回率，同时测量并发负载下的 P50/P95/P99 延迟。

结果常常与厂商的营销宣传相矛盾。Pinecone 的无服务器层看似性价比很高，直到持续的高 QPS 工作负载将读取单元成本推过自托管的盈亏平衡点；pgvector 看似受限，直到迭代扫描弥合了过滤搜索的差距。

嵌入流水线才是生产检索真正崩溃之处

团队将 60% 的向量搜索工程投入花在流水线上，而非存储本身。流水线负责文档摄取、分块、嵌入模型推理、文档更新时的增量重建索引，以及元数据传播——而每个阶段都有会悄然使检索质量退化的失效模式。

• 陈旧知识 ——第二常见的生产 RAG 失效。文档已在 Confluence 中更新，但索引仍在提供旧的嵌入。修复方法是通过变更数据捕获触发器进行增量重嵌入，而非每晚批量重建索引。
• 幽灵文档 ——源文档已被删除，但其向量仍然存在，为已不复存在的内容返回结果。由于在拆分架构中跨真源系统与向量存储实现原子事务几乎不可能，我们构建对账层来检测并清除孤立向量。

嵌入模型的选择比大多数团队意识到的更为重要，而事后切换代价高昂：当您从 800 万篇文档 从 text-embedding-ada-002 升级到 text-embedding-3-large 时重嵌入这些文档，需要耗费数天的计算资源，并需要双写基础设施以避免停机。我们会在您做出决定之前，针对您特定领域的查询集来评估各个模型。

• Cohere embed-v4 ——在多语言检索方面领先，价格为 每百万 token 0.01 美元 ，覆盖 100 多种语言。
• Nomic Embed v2 —— 1.37 亿参数，可在 CPU 上运行，具备市场上最佳的质量与规模比。
• OpenAI text-embedding-3-large ——一款出色的全能选手。

正确的选择取决于您的语言组合、延迟要求，以及您能否接受 API 依赖或是否需要本地推理。

索引生命周期：无人警示过您的运维难题

HNSW 索引会退化——这不是缺陷，而是一种架构上的现实。在 1.6 亿向量规模下，一次完整的 HNSW 重建需要 3–6 小时。增量更新会使图结构变得次优，并随时间侵蚀召回率；压缩事件会使查询延迟出现峰值；每一次 upsert、删除和段合并都会触发子索引重建，把 CPU 耗费在维护上，而非服务查询。这种权衡无可回避：将召回率从 0.8 提升到 0.95 会使 HNSW 延迟大约提高 31%。

我们设计的生命周期管理能够在不损失质量的情况下吸收持续的摄取：

• 蓝绿索引轮换 ——在独立的基础设施上重建，并以零停机的方式原子式切换。
• 自动化召回验证门 ——在每次重大操作后，将黄金查询集与当前索引进行对比；如果召回率跌破阈值，切换便不会发生。
• GPU 加速的 HNSW 构建 在 Qdrant 和 Elasticsearch 中可将重建时间缩短一个数量级，尽管何时重建、如何验证以及如何切换的编排属于定制化工程。

量化进一步拓展了这一点。Qdrant 现已提供 1.5 位、2 位和非对称 量化，而 Elasticsearch BBQ 可将堆内存减少 相比 float32 超过 95%。这些方案节省内存并提升吞吐量，但每种方案针对不同的数据分布都有不同的召回率特性——因此在生产环境部署量化之前，我们会针对您特定的向量刻画其召回率影响。

真实规模下的多租户与隔离

服务于 200 多个内部 ML 团队的平台团队，或拥有数千个客户租户的 SaaS 产品，都需要保证隔离的基础设施：租户 A 的查询绝不能返回租户 B 的数据，审计日志必须将每一次查询追溯到某个租户身份，而冷租户不应消耗热租户所需的资源。

• Weaviate ——带有租户状态（ACTIVE、INACTIVE、OFFLOADED 到 S3）的一租户一分片模型，是面向高租户数部署的最成熟的实现。
• Milvus ——支持在数据库、集合、分区或分区键级别进行隔离，将粒度与您的合规要求相匹配。

两者在规模化时都需要定制编排——租户配置、状态转换、配额管理和跨租户泄漏检测都不由数据库本身处理。我们构建运维层，使多租户对于需要满足 SOC 2 或 ISO 27001 合规的受监管部署变得可管理。

智能体工作流正在重塑基础设施需求

智能体 AI 浪潮改变了向量存储必须做到的事情。静态 RAG 针对固定语料库检索文档。智能体工作流则需要 情景记忆 （对话历史与中间推理）、针对大型文档语料库的 语义搜索 ，以及 用户画像层 ——通常在单个智能体步骤中同时命中这三者。其 低于 400 毫秒 的延迟要求比批处理 RAG 更为严苛，而对于在不产生部分写入的情况下更新状态的多步骤智能体来说，ACID 事务支持正变得不可或缺。

没有单一向量数据库能同时很好地处理这三种记忆层，因此团队会组装多存储架构： Redis 用于会话状态， Qdrant 或 Milvus 用于语义搜索，以及一个 图数据库 用于关系追踪。 Oracle 的统一内存核心（Unified Memory Core，2026 年 3 月） 尝试在单一引擎中融合向量、JSON、图、关系和空间查询。我们为智能体系统设计检索层——哪些存储处理哪些记忆类型、查询如何在各存储之间路由，以及当智能体在单个推理步骤中跨多个后端更新状态时如何保持一致性。

我们交付的内容

每一次合作都从 基准测试阶段开始：我们载入您的向量、运行您的查询，并产出量化的引擎推荐。在此基础上，我们构建生产基础设施：

• 包含容量规划和扩展运维手册的 向量存储集群。
• 包含 CDC 触发的增量重建索引和模型版本管理的 嵌入流水线。
• 包含蓝绿轮换和召回验证门的 索引生命周期自动化。
• 在您需要租户隔离时的 多租户编排层。
• 包含漂移检测、召回率回归告警和 P95/P99 延迟监控的 可观测性栈。
• 迁移工具 ，面向在引擎之间迁移的团队，使用中间 Parquet 格式，在维度匹配时保留嵌入，而不是强制进行完整的重嵌入。

我们为每一次合作制定明确的 每月基础设施成本预测，让您在做出决定之前就知道生产环境将花费多少。