生产环境部署
AI应用程序生产环境部署检查清单
本指南将帮助您为生产环境准备应用程序。我们将提供可操作的步骤,帮助您扩展应用程序、确保其可靠性、能够处理负载,并为您的使用场景提供最佳准确性。
有关大规模工程设计的更多信息,请参阅我们的规模化工程设计指南。
是否需要索引?
顺序扫描会导致明显更高的延迟和更低的吞吐量,但能保证100%的准确性且不受内存限制。
在以下情况下您可能不需要索引:
- 数据集较小且无需扩展
- 不预期会有大量向量搜索查询每秒
- 需要保证100%的准确性
在这些情况下您无需创建索引,可以使用顺序扫描。这类工作负载不受内存限制,不需要额外资源,但会导致更高的延迟和更低的吞吐量。额外的CPU核心可能有助于提高每秒查询数,但不会改善延迟。
另一方面,如果需要扩展应用程序,您将需要创建索引。这将降低延迟并提高吞吐量,但需要额外的内存来利用Postgres缓存功能。此外,使用索引会降低准确性,因为您正在用近似最近邻(ANN)搜索替代精确的K最近邻(KNN)搜索。
HNSW 与 IVFFlat 索引对比
pgvector
支持两种类型的索引:HNSW 和 IVFFlat。我们推荐使用 HNSW,因为它具有出色的性能表现和对数据变化的强健适应性。
HNSW 索引:理解 ef_construction
、ef_search
和 m
参数
索引构建参数:
-
m
表示在构建过程中为每个新元素创建的双向链接数量。较高的m
值适合高维数据集和/或高精度要求的场景。合理的m
值范围在 2 到 100 之间,对于大多数用例来说 12-48 是一个不错的起始范围(默认值为 16)。 -
ef_construction
是最近邻动态列表的大小(用于构建算法)。较高的ef_construction
会提高索引质量和精度,但也会增加构建索引所需的时间。ef_construction
必须至少为 2 *m
(默认值为 64)。当ef_construction
增加到一定程度后,继续增加将不再提升索引质量。您可以通过设置ef_search
=ef_construction
来测量精度:如果精度低于 0.9,则还有改进空间。
搜索参数:
ef_search
是最近邻动态列表的大小(用于搜索过程)。增加ef_search
会提高搜索精度,但也会增加查询执行时间(默认值为 40)。
IVFFlat 索引:理解 probes
和 lists
参数
pgvector 中用于近似向量相似性搜索的索引会将数据集划分为多个分区。这些分区的数量由 lists
常量定义。而 probes
参数则控制查询时需要搜索的列表数量。
lists
和 probes
的值会直接影响搜索精度和每秒查询量(QPS):
- 更高的
lists
值意味着索引构建速度会变慢,但可以获得更好的 QPS 和搜索精度 - 更高的
probes
值意味着查询速度会变慢,但能获得更好的搜索精度 lists
和probes
并非独立参数。当lists
值较高时,您需要使用更高的probes
值才能达到相同的精度水平
您可以在pgvector 0.4.0 性能分析博客文章中查看更多关于 lists
和 probes
如何影响精度和 QPS 的示例。
使用索引时的性能优化建议
首先是一些通用建议,您可以根据需要选择采用:
- Supabase托管平台会根据您的计算附加组件自动优化Postgres配置。但如果是自托管,建议根据RAM和CPU核心数调整Postgres配置。详见优化示例获取详细信息。
- 如果向量已归一化(如
text-embedding-ada-002
),优先使用inner-product
而非L2
或Cosine
距离。若嵌入向量未归一化,使用Cosine
距离配合索引可获得最佳效果。 - 预热数据库。在转入生产环境或运行基准测试前实施预热技术:
- 使用pg_prewarm将索引加载到RAM中:
select pg_prewarm('vecs.docs_vec_idx');
,这有助于避免缓存冷启动问题。 - 每次基准测试/生产前执行10,000到50,000次"预热"查询,可更高效地利用缓存和缓冲区。
- 使用pg_prewarm将索引加载到RAM中:
- 确定您的工作负载。通过调整pgvector索引的
m
和ef_construction
或lists
参数来加速查询(代价是构建时间变长)。例如,在包含1,000,000个OpenAI嵌入向量的基准测试中,我们将m
和ef_construction
分别设为32和80,相比24和56的配置获得了35%的QPS提升。 - 针对特定工作负载进行基准测试。在缓存预热期间进行测试,有助于找到索引构建参数的最佳值,在准确性与每秒查询数(QPS)之间取得平衡。
投入生产环境
- 决定是否使用索引。如果不使用索引,可以跳过本指南的其余部分。
- 在准备阶段超额配置RAM。虽然可以在步骤
5
中缩减规模,但最好从较大的配置开始以获得最佳的RAM需求结果。(如果使用Supabase,我们建议至少选择8XL规格。) - 将数据上传到数据库。如果使用
vecs
库,它会自动使用默认参数生成索引。 - 使用随机生成的查询运行基准测试并观察结果。同样可以使用
vecs
库配合ann-benchmarks
工具。先用索引构建参数的默认值进行测试,后续可以调整这些参数以获得最佳结果。 - 监控RAM使用情况,并做好记录。未来您可能会需要使用与当前RAM使用量(包括实际RAM使用量和缓存/缓冲区占用的RAM)相匹配的计算插件。
- 将计算插件缩减至与当前RAM使用量相匹配的规格。
- 重复步骤3将数据加载到RAM中。您应该会看到后续运行的QPS(每秒查询数)有所提升,当不再提升时即可停止。
- 使用真实查询运行基准测试并观察结果。同样可以使用
vecs
库配合ann-benchmarks
工具。调整HNSW的ef_search
参数或IVFFlat的probes
参数,直到准确率和QPS都满足您的要求。 - 如果需要更高的QPS,可以增加HNSW的
m
和ef_construction
参数或IVFFlat的lists
参数(考虑从IVF切换到HNSW)。必须用更高的m
和ef_construction
值重建索引,并重复步骤6-7以找到m
、ef_construction
和ef_search
的最佳组合,从而实现最优的QPS和准确率。更高的m
和ef_construction
意味着索引构建速度会变慢,但可以获得更好的QPS和准确率。更高的ef_search
意味着查询速度会变慢,但可以获得更好的准确率。
实用链接
别忘了查看通用的生产环境检查清单,确保您的项目安全、高性能且能为用户持续提供服务。
您可以参考我们的选择计算附加组件指南,初步了解您的工作负载可能需要多少计算资源。
或者查看我们关于pgvector 0.5.0性能和pgvector 0.4.0性能的博客文章,了解pgvector的能力以及如何使用上述技术获得最佳效果。