面向 RAG 应用开发者的实用指南和建议

向量搜索听起来简单得很——把数据丢进Embedding模型，生成向量，存进向量数据库，然后就能检索了。不少厂商也是这么宣传的，什么“简单”、“用户友好”、“几行代码就能搞定”。

但实际情况呢？在小数据集上，用KNN算法加NumPy，十几行代码确实够用。可一旦数据集规模超过百万、千万级别，事情就没那么简单了。真正的生产环境里，搜索质量、可扩展性、可用性、多租户、成本、安全性……哪个环节都不能掉链子。

所以，今天咱们就来聊聊在生产环境中部署向量搜索应用时，那些绕不开的关键实践。核心可以总结为三点：设计一个有效的Schema,提前考虑可扩展性,以及选对索引并持续优化。下面逐一说透。

02. 设计一个有效的Schema

Schema定义了数据库的结构，包括表、字段、关系和数据类型。一个设计得当的Schema，能让数据存储一致、可预测，后续的查询和维护也会轻松很多。对于Milvus这类向量数据库来说，Schema不仅要管向量，还得协调好元数据、标量数据等结构化信息，这些字段能帮我们实现更精细的过滤，直接提升搜索结果的质量。

动态Schema灵活，适合数据结构经常变动的场景，插入和检索都不需要做大量的数据对齐或ETL。固定Schema则胜在存储紧凑、性能高效、内存友好。两者之间怎么选？其实不用二选一。一种更聪明的做法是混合使用——核心的关键数据链路用固定Schema保证稳定，其他灵活部分交给动态Schema去适配。比如在一个推荐系统里，产品名称和ID这类核心字段可以固定下来，而那些随业务变化的属性字段则用动态Schema来处理。

主键和Partition key是向量数据库里的两个基础概念。拿Milvus来说，它的数据架构可以分为几个部分：固定字段和动态字段（统称payload）、一个必需的向量字段，以及类似传统数据库里的时间戳、UUID等系统字段。

• 主键：通常作为唯一标识符，在RAG场景里常把chunk ID设为主键。它会被频繁访问，可以在Milvus里开启自动生成（Auto ID）。主键的作用就是快速定位和检索特定数据。

• Partition key：在创建Collection时指定，Milvus会根据这个键值把数据entity存储到不同的Partition中，从而将数据组织成更易管理的Segment。简单说，如果你有一些数据集需要过滤，比如在多租户场景下要隔离数据，用Partition key把不同租户的数据分到不同Partition里就非常方便。它还能通过哈希将数据分区成Shard，帮数据库高效管理大规模用户群。

这两个键在维护向量数据库的结构完整性和操作效率上至关重要，处理大规模数据时尤其如此。

选向量类型，本质上是选生成向量的机器学习模型。常见的类型有三种：

• 稠密向量（Dense Embedding）：最常用，语义相似性搜索的标配，稳健且适用性广。代表模型有OpenAI、BGE、Cohere。

• 稀疏向量（Sparse Embedding）：处理域外数据时效率很高，适合多样化、多功能的搜索场景。Splade和BGE M3是这方面的典型。

• 二进制向量（Binary Embedding）：以0和1存储，专为高效存储设计，适合蛋白质测序这类特殊用例。Meta ESM-2模型就常用于生成这类向量。

实际操作中，我们很少只用一种向量。你需要一个支持多种索引算法的解决方案，Milvus就支持管理稠密、稀疏、二进制甚至混合向量，确保不同数据类型都能高效搜索。

把上面的知识落地吧。一个有效的Schema，除了主键和向量字段，还需要考虑以下内容：

• 基础部分：主键（chunkID）和embedding向量（denseVector），每个entity必备。

• 多租支持：添加字段userID，按租户分区，实现用户级别的数据隔离和安全管控。

• 优化搜索结果：

  • docID：记录chunk的来源文档。利用Milvus的分组搜索功能，在search()操作中加入group_by_field参数，按文档ID对结果分组，直接找到相关文档而不是零散的段落。

  • dynamicParams：用于过滤，可以存储文档名称、来源URL等元数据。设置成json类型，一个字段能存多个键值对，非常灵活。

  • sparseVector：保存chunk的稀疏向量，让你能同时做ANN搜索并根据标量值检索。
    

这样设计的Schema，既发挥了向量搜索的优势，又兼顾了传统数据管理和检索的需求，为RAG应用打下了一个扎实的基础。

03. 考虑可扩展性

MVP跑通之后，就该为生产部署做打算了。这一步的核心是——预测数据会怎么增长，然后设计架构去承载这些增长。

一个常见的坑是：把所有数据放在一个大型Collection索引里。结果呢？索引速度越来越慢，频繁更新数据还会拉低索引质量，最终拖垮搜索结果。Milvus的解法是把整个数据集切分成可管理的Segment，当Segment不稳定时执行延迟更新或压缩，始终保持搜索质量。这种分段机制还能帮助负载均衡，让查询均匀分布到所有处理节点上。

用Partition做多租管理也是提升可扩展性和性能的利器。它能有效组织数据，并通过限制数据的可见性来增强安全性和隐私性。Milvus可以高效管理单个Collection里多达百亿条数据。

对于租户数少于1万的多租应用，用Collection管理数据更可控。如果租户数量是百万级别，Partition key可以通过动态分段数据来支持。Milvus本身是分布式系统，加节点就能提性能。对于起步时数据量不大的场景，增加内存（通常是当前分配的两到三倍）也能让每秒查询数（QPS）翻倍。

04. 选择、评估并优化索引

原型阶段，把数据全加载到内存里确实方便，但到了生产阶段，数据集一大，这条路就走不通了——内存有限、昂贵，而且大型数据集可能直接超过可用内存。正确的做法是选择合适的索引策略。

不同索引在三个关键指标上有明显差异：

• 每秒查询数（QPS）：衡量索引每秒能处理的搜索查询数量，反映吞吐量和效率。

• 存储：索引占用的磁盘空间大小，直接影响基础设施成本和可扩展性。

• 延时：处理单个查询并返回结果所需的时间，决定应用的响应速度。

Milvus提供了多种索引选择，适应不同需求：

• GPU索引：高性能环境首选，支持快速数据处理和检索。

• 内存索引：平衡型选手，QPS不错，能扩展到TB级存储，平均延时约10毫秒。

• 磁盘索引：能管理数十TB数据，延时约100毫秒，适合大数据且对时间不敏感的场景。Milvus也是唯一支持磁盘索引的开源向量数据库。

• Swap索引：在S3或对象存储与内存之间交换数据，成本降低约十倍，延时约100毫秒，冷数据可能到几秒，适合离线或预算有限的应用。

选好索引后，还要根据构建时间、准确性、性能和资源消耗来评估。比如一个未优化的索引可能只有20 QPS，优化后每次调优迭代可能提升十倍（同时也会增加延时）。具体步骤是：

1. 根据需求选索引类型。
2. 调整索引参数。
3. 做性能测试。
4. 再微调搜索参数。

如果对优化没把握，不妨试试VectorDBBench，这是Zilliz开发的开源性能测试工具，能评估所有主流向量数据库，帮你做全面实验，找到最佳配置。

05. 总结

向量搜索入门简单，但深挖起来并不轻松。从Schema设计的基础，到管理复杂大数据集的方式，开发者在实际部署时需要考虑的远不止代码本身。希望这份指南能帮你构建更强大、高效、可扩展的RAG应用。无论是老手还是初学者，踩过这些坑之后，再面对向量数据库时，会更有底气。