选择恰当的基础设施是部署生产级检索增强生成(RAG)系统的首要步骤。您的选择将直接影响性能、可伸缩性、运营成本和可维护性。RAG系统并非一个单一的整体应用;它是一个由相互关联的服务组成的流水线,每个服务都有独特的基础设施需求。这些通常包含数据摄取和预处理、向量生成、向量存储和搜索,以及语言模型推理的组件。
RAG系统的主要基础设施层面
从宏观层面看,您的RAG系统需要计算、存储和网络资源,并根据每个流水线阶段的特定需求进行调整。
计算资源
RAG流水线中的几项操作都需要计算资源:
- 向量生成:将您的知识库文档和传入查询转换为向量。这通常是计算密集型任务,特别是对于大型数据集或复杂的向量模型。虽然初始回填可以进行批处理,但增量更新可能需要响应更快的计算。GPU或其他机器学习加速器可以明显加快此过程。
- 检索:在向量数据库中执行相似性搜索。这方面的计算可能由向量数据库本身管理(如果使用托管服务),或者如果自行托管则需要专用资源。对于许多向量搜索工作负载,CPU优化的实例通常已足够,但某些高级索引或搜索算法可能受益于GPU。
- 重排序(可选但建议):如果您使用重排序模型在将搜索结果传递给生成器之前进行优化,此组件也需要自己的计算资源,通常根据模型的复杂性偏向CPU或较小的GPU。
- 语言模型(LLM)生成:运行生成器LLM,根据查询和检索到的上下文合成答案。这通常是RAG流水线中计算最密集的部分,特别是对于更大、能力更强的LLM。高性能GPU(例如NVIDIA A100、H100)通常是达到可接受延迟和吞吐量所必需的。选择自行托管LLM还是通过API使用模型将极大改变您在此处的基础设施需求。
存储
RAG系统中的存储要求多种多样:
- 源文档存储:构成您知识库的原始文档。这可以是云对象存储(如Amazon S3、Google Cloud Storage、Azure Blob Storage),也可以是数据库或文档管理系统。
- 处理后的数据存储:分块文档、元数据和任何中间表示。对象存储因其可伸缩性和成本效益而常被选用。
- 向量数据库:存储文档块的向量。这是一种专门的数据库,针对高维空间中的快速相似性搜索进行了优化。我们很快将详细讨论向量数据库的选择。
- 模型存储:用于存储您的向量模型、重排序模型以及可能自行托管的LLM。通常使用Hugging Face Hub或云平台中的私有模型注册表(例如AWS SageMaker模型注册表、Google Vertex AI模型注册表、Azure ML模型注册表)等服务。
- 缓存:用于频繁访问的向量、检索到的文档甚至LLM生成的缓存层可以显著提高性能并降低成本。这可能涉及Redis或Memcached等内存缓存。
网络
高效且安全的网络对于RAG系统组件间的通信非常重要:
- 内部通信:服务之间(例如,应用前端到检索器,检索器到生成器)的低延迟通信。在虚拟私有云(VPC)内,服务网格或内部负载均衡器很常见。
- 外部通信:处理用户请求,如果适用,还包括对外部LLM API的调用。API网关在此处对于管理流量、身份验证和速率限制非常重要。
- 数据传输:用于摄取源文档、传输向量和移动模型工件的带宽。
RAG组件的基础设施决策
我们来审视一些最有影响力的基础设施决策,这些是您需要做出的选择。
向量数据库:托管式 vs. 自行托管
向量数据库是检索阶段的中心。您在此处的选择对运营和成本有重要影响。
- 托管向量数据库服务:示例包括Pinecone、Weaviate Cloud Services、Zilliz Cloud、带有向量搜索的Redis Cloud、Google Vertex AI Vector Search和带有k-NN的Amazon OpenSearch Service。
- 优点:降低运营负担(供应商负责资源配置、伸缩、维护、备份),通常伴随性能优化和SLA。
- 缺点:大规模使用时可能更昂贵,存在供应商绑定风险,可能对细粒度配置或底层硬件的控制较少。
- 自行托管向量数据库:开源选项如Milvus、Weaviate(自行托管)、Qdrant,或者甚至在您自己的基础设施之上使用FAISS等库。
- 优点:对部署、硬件选择和配置有更大的控制权;如果您有能力高效管理,直接成本可能更低。
- 缺点:运营负担大(设置、伸缩、高可用性、补丁、监控、优化),需要对数据库技术和底层基础设施都有丰富的专业知识。
在选择时,请考虑数据集大小、查询吞吐量要求、期望延迟、更新频率、过滤需求、团队专业知识和预算等因素。对于需要高可用性和可伸缩性但运营资源有限的生产系统,托管服务通常是一个实际的起点。
LLM托管:API vs. 自行托管
对于生成组件,您基本有三种途径:
- 第三方LLM API(例如:OpenAI, Anthropic, Cohere):
- 基础设施影响:LLM本身直接的基础设施负担很小。您的主要考量是可靠地网络访问API端点以及管理API密钥和配额。
- 优点:无需复杂的托管即可访问先进模型,按使用付费。
- 缺点:数据隐私问题(数据发送到第三方),网络延迟,潜在的速率限制,对模型更新的控制较少,与使用量相关的持续运营成本。
- 自行托管开源LLM(例如:Llama 3, Mistral, Mixtral):
- 基础设施影响:显著。需要强大的GPU实例(大型模型通常需要多个),用于服务的设施(例如使用Triton Inference Server, vLLM或Text Generation Inference等推理服务器),以及用于模型部署、伸缩和监控的MLOps专业知识。
- 优点:对数据有完全控制,模型可定制(微调),如果优化得当,在极高规模下成本可能更低,核心LLM无外部API依赖。
- 缺点:前期和持续基础设施成本高,运营复杂性大,需要专业的机器学习工程和MLOps技能。
- 托管LLM服务(例如:Amazon Foundation, Google Vertex AI Model Garden, Azure AI Studio):
- 基础设施影响:一种折衷方案。云服务提供商管理选定模型的底层GPU基础设施和提供服务堆栈。您将模型部署到端点。
- 优点:比完全自行托管更容易访问各种模型,处理部分运营复杂性,数据通常保留在您的云环境中。
- 缺点:对于某些模型/使用模式来说,比纯API使用更昂贵,模型选择受供应商限制,控制权少于完全自行托管。
您的决定将取决于预算、数据敏感性、所需模型定制、团队能力和期望的控制水平等因素。许多团队从API开始,进行快速原型开发,然后随着规模扩大或需要更多控制时,评估自行托管或托管服务。
向量模型的计算
尽管不如大型生成LLM要求高,向量模型仍然需要仔细的计算规划:
- 批量向量化:对于初始知识库索引,您可以使用成本效益高的计算选项,如果您的工作负载具有容错性,可以考虑利用带有GPU的竞价实例。
- 增量/实时向量化:对于新文档或查询,需要低延迟的向量化。这可能涉及专用实例(CPU或GPU,取决于模型大小和吞吐量)或带有GPU支持的无服务器函数(如果可用且对您的流量模式具有成本效益)。
- 模型大小:较小的向量模型(例如E5-small、BGE-small)可以在CPU上高效运行,而较大、更准确的模型(例如Cohere-embed-v3、Voyage AI)则显著受益于GPU以提高吞吐量和降低延迟。
部署架构和模式
您如何打包和部署RAG组件也将影响您基础设施的形态。
生产RAG系统中基础设施组件的典型分解,说明了潜在的服务和数据流。
常见的部署模式包括:
- 无服务器架构:(例如,AWS Lambda, Google Cloud Functions, Azure Functions)
- 适用性:适用于RAG流水线中事件驱动的部分,例如检索器API端点、查询向量化器或较小的重排序器,如果它们的执行时间和资源限制相符。一些平台提供无服务器GPU选项,可能适合较小的LLM推理任务或向量生成。
- 优点:自动伸缩,按使用付费(对于可变工作负载具有成本效益),减少函数执行环境的运营管理。
- 缺点:对于面向用户的服务,冷启动延迟可能是一个问题,执行持续时间和包大小有限制,状态管理可能更复杂,无服务器环境中的GPU可用性和成本可能有所不同。
- 容器化部署(例如,Kubernetes, Docker Swarm, Amazon ECS, Google Kubernetes Engine, Azure Kubernetes Service):
- 适用性:对于大多数RAG组件来说,这是一种非常常见且灵活的方法,包括用于检索和生成的API服务、自行托管的向量数据库(带有有状态集),甚至LLM推理服务器。
- 优点:可移植性,环境一致,伸缩和编排能力,资源利用高效,监控和日志记录生态系统成熟。
- 缺点:Kubernetes学习曲线较陡峭,管理集群的运营负担(尽管托管Kubernetes服务能显著减轻这一点),对于非常简单的部署可能过于复杂。
- 托管式AI/ML平台:(例如,Amazon SageMaker, Google Vertex AI, Azure Machine Learning)
- 适用性:非常适合部署和管理机器学习模型,包括向量模型、重排序器和自行托管的LLM。它们通常提供用于创建端点、自动伸缩、监控以及与其他云服务集成的工具。
- 优点:简化MLOps任务,为机器学习工作负载提供内置的伸缩和监控功能,通常针对特定硬件(如GPU)进行优化。
- 缺点:可能导致供应商绑定,成本可能高于裸机计算,对于非机器学习组件而言,灵活性可能不如纯Kubernetes设置。
- 混合方法:许多生产系统采用组合方式。例如,API网关和轻量级处理使用无服务器函数,核心服务和自行托管模型使用Kubernetes,向量数据库或第三方LLM API使用托管服务。
Here's a comparative overview:
常见部署模式的比较,强调了它们在RAG系统组件方面的优劣权衡。
数据摄取流水线基础设施
不要忽视数据摄取和预处理流水线的基础设施。该系统负责:
- 获取或接收新的/更新的文档。
- 清洗、解析和分块文档。
- 为新数据块生成向量(可以是独立的批量或流处理过程)。
- 将向量索引到向量数据库中。
这方面 Infrastructure 可能包括:
- 编排工具:Apache Airflow、Kubeflow Pipelines、AWS Step Functions或Google Cloud Workflows,用于管理任务序列。
- 处理引擎:Apache Spark、Dask或运行在虚拟机/容器上的自定义脚本,用于大规模数据转换。
- 流处理平台:如果您需要近实时处理文档更新,可使用Apache Kafka或云原生流媒体服务(例如Kinesis、Pub/Sub)。
此处的基础设施选择取决于源数据的体量、速度和多样性。
基础设施与可伸缩性、可靠性和安全性的关系
您的基础设施决策与整个系统的非功能性要求密切关联:
- 可伸缩性:设计每个组件独立伸缩。计算资源使用自动伸缩组,选择可水平或垂直伸缩的向量数据库,并采用负载均衡器。
- 可靠性:为重要组件实现冗余(例如,跨可用区的多个服务实例),酌情使用带有SLA的托管服务,并设计容错能力。(更多内容见第7章)。
- 安全性:网络隔离(VPC、子网、安全组)、用于控制资源访问的身份和访问管理(IAM)、静态和传输中的加密,以及API密钥等敏感信息的安全管理都非常重要。(本章稍后将在“生产RAG中的安全考量”部分更详细地讨论)。
为您的RAG系统选择恰当的基础设施是一个权衡过程。它涉及衡量性能需求、成本限制、团队的运营能力以及期望的控制水平。通过仔细考虑每个组件的需求并了解不同部署模型的权衡,您可以为生产RAG系统构建一个强大且可持续的稳固架构。此处概述的原则将作为后续章节中讨论更高级优化方法的起点。