大规模 Azure AI Search：构建具备增强向量容量的 RAG 应用

Source: Dev.to

Source: …

使用 Azure AI Search 扩展高性能检索增强生成（RAG）

在快速演进的生成式 AI 领域，**检索增强生成（Retrieval‑Augmented Generation，RAG）**模式已成为将大型语言模型（LLMs）与私有、实时数据结合的黄金标准。然而，当组织从概念验证（PoC）迈向生产环境时，会遇到一个重要障碍：扩展性。

扩展向量存储不仅仅是增加存储容量；它还需要在管理数百万高维嵌入的同时，保持低延迟、高召回率和成本效益。Azure AI Search（前身为 Azure Cognitive Search）近期完成了大规模基础设施升级，专门针对提升向量容量和性能。

在本技术深度解析中，我们将探讨如何利用 Azure AI Search 的最新功能来构建大规模 RAG 应用。

---

RAG 架构概览

RAG 应用由两个独立的流水线组成：

1. 摄取流水线 – 数据 → 索引
2. 推理流水线 – 查询 → 响应

在扩展到数百万文档时，瓶颈通常会从 LLM 转移到检索引擎。Azure AI Search 通过分区和副本实现存储与计算的分离，并提供专用的硬件加速向量索引来应对这一挑战。

图示（生产级 RAG 架构）
Search 服务充当原始数据与生成模型之间的编排层。

---

向量存储与容量

Azure AI Search 现在提供 存储优化 和 计算优化 两种层级，显著提升每个分区可存储的向量数量。

向量存储消耗 取决于嵌入的维度以及数据类型（例如 float32）。

示例： 一个常见的 1536 维嵌入（OpenAI 模型使用）采用 float32 时需要

1536 维 × 4 字节 = 6 144 字节/向量

外加少量元数据开销。

借助最新的增强功能，某些层级能够在单个索引中支持数千万向量，并通过 标量量化（Scalar Quantization） 等技术在不显著影响检索准确度的前提下压缩内存占用。

---

Azure AI Search 中的搜索模式

---

配置 HNSW 向量索引

Azure AI Search 使用 HNSW（Hierarchical Navigable Small World） 算法构建向量索引。HNSW 是一种基于图的近似最近邻（ANN）搜索方法，具备次线性时间复杂度。

在定义索引时，vectorSearch 配置至关重要。必须指定 algorithmConfiguration 以在速度和准确度之间取得平衡。

from azure.search.documents.indexes.models import (
    SearchIndex,
    SearchField,
    SearchFieldDataType,
    VectorSearch,
    HnswAlgorithmConfiguration,
    VectorSearchProfile,
    SimpleField,
    SearchableField,
)

# Configure HNSW Parameters
#   m               – number of bi‑directional links per element
#   efConstruction  – trade‑off between index build time and search speed
vector_search = VectorSearch(
    algorithms=[
        HnswAlgorithmConfiguration(
            name="my-hnsw-config",
            parameters={
                "m": 4,
                "efConstruction": 400,
                "metric": "cosine",

from azure.search.documents import SearchClient
from azure.search.documents.models import VectorSearch, HnswAlgorithmConfiguration, VectorSearchProfile

# Define the HNSW algorithm configuration
hnsw_config = HnswAlgorithmConfiguration(
    name="my-hnsw-config",
    m=16,
    ef_construction=500,
    ef_search=500,
)

# Define the vector search configuration
vector_search = VectorSearch(
    algorithm_configurations=[hnsw_config],
    profiles=[
        VectorSearchProfile(
            name="my-vector-profile",
            algorithm_configuration_name="my-hnsw-config",
        )
    ],
)

# Define the index schema
index = SearchIndex(
    name="enterprise-rag-index",
    fields=[
        SimpleField(name="id", type=SearchFieldDataType.String, key=True),
        SearchableField(name="content", type=SearchFieldDataType.String),
        SearchField(
            name="content_vector",
            type=SearchFieldDataType.Collection(SearchFieldDataType.Single),
            searchable=True,
            vector_search_dimensions=1536,
            vector_search_profile_name="my-vector-profile",
        ),
    ],
    vector_search=vector_search,
)

m 和 efConstruction – 含义

---

通过集成向量化降低“编排成本”

在大规模场景中，一个常见的挑战是管理独立的嵌入服务和索引器所带来的开销。Azure AI Search 现在提供 集成向量化：

• 当文档被添加到数据源（例如 Azure Blob Storage）时，内置索引器会自动：
  1. 检测到更改，
  2. 将文本切块，
  3. 调用嵌入模型，
  4. 更新向量字段。

这消除了用于切块和嵌入的自定义代码，简化了摄取管道。

---

混合搜索 + 语义排序

纯向量搜索在处理领域特定术语或产品代码（例如 “Part‑99‑X”）时可能表现不佳。一个稳健的 RAG 系统应当结合：

1. 混合搜索 – 使用 Reciprocal Rank Fusion (RRF) 将向量和关键字结果合并。
2. 语义排序器 – 使用计算密集型的 Transformer 模型对前 N（例如 50）条结果重新排序，以实现真正的语义相关性。

from azure.search.documents import SearchClient
from azure.search.documents.models import VectorQuery

client = SearchClient(
    endpoint=AZURE_SEARCH_ENDPOINT,
    index_name="enterprise-rag-index",
    credential=AZURE_SEARCH_KEY,
)

# 示例混合查询（向量 + 关键字）
vector_query = VectorQuery(
    vector=[0.12, -0.34, ...],   # 1536 维嵌入
    k=10,
    fields="content_vector",
)

results = client.search(
    search_text="Part-99-X",
    vector_queries=[vector_query],
    query_type="semantic",   # 在顶部结果上触发语义排序
    semantic_configuration_name="my-semantic-config",
)

---

关键要点

• 分区 & 副本 设计使 Azure AI Search 能够独立扩展存储和计算。
• 根据向量数量和查询延迟需求，选择合适的 层级（存储优化 vs. 计算优化）。
• 调整 HNSW 参数（m、efConstruction）以在内存、索引时间和召回率之间取得平衡。
• 利用 集成向量化 减少编排复杂度。
• 部署 混合搜索 + 语义排序，在企业 RAG 场景中实现最高相关性。

遵循这些指南，你可以构建一个生产级、高吞吐量的 RAG 解决方案，在优雅扩展的同时提供低延迟、准确的响应。

# 示例：使用 Azure AI Search 进行搜索

# 创建客户端（请替换为您自己的端点和凭证）
client = SearchClient(
    endpoint="https://my-search-service.search.windows.net",
    index_name="rag-index",
    credential=credential,
)

# 用户的自然语言查询
query_text = "How do I reset the firewall configuration for the Pro series?"

# This embedding should be generated via your choice of model (e.g., text-embedding-3-small)
qu

```python
ery_vector = get_embedding(query_text)

# Perform the search
results = client.search(
    search_text=query_text,                                 # Keyword search query
    vector_queries=[
        VectorQuery(
            vector=query_vector,
            k_nearest_neighbors=50,
            fields="content_vector",
        )
    ],
    select=["id", "content"],
    query_type="semantic",
    semantic_configuration_name="my-semantic-config",
)

# Print the results
for result in results:
    print(f"Score: {result['@search.score']} | Semantic Score: {result['@search.reranker_score']}")
    print(f"Content: {result['content'][:200]}...")

在此示例中，semantic_reranker_score 相较于标准余弦相似度分数，能够更准确地指示 LLM 上下文窗口的相关性。

Azure AI Search 可伸缩维度

经验法则

RAG 的块划分策略

• 固定大小块划分 – 快速，但常常打断上下文。
• 重叠块 – 对于在边界之间保持上下文至关重要（例如，512 个 token，重叠 10 %）。
• 语义块划分 – 使用 LLM 或专用模型寻找逻辑断点（段落、章节）。成本更高，但能获得更好的检索结果。

---

针对数百万向量的扩展技巧

1. 批量上传 – 使用 upload_documents 批量 API，每批处理 500–1 000 个文档。
2. 并行索引 – 如果数据集是静态且规模庞大，可运行多个指向同一索引的索引器，以并行生成嵌入。

需要监控的检索指标

• Recall@K – 正确文档出现在前 K 条结果中的频率。
• Mean Reciprocal Rank (MRR) – 相关文档在结果列表中的位置。
• Latency P95 – 混合搜索的第 95 百分位响应时间。

最佳实践清单

• 选择合适的层级 – 根据向量数量选择 S1、S2 或全新的 L 系列（存储优化）。
• 配置 HNSW – 根据召回需求调优 m 和 efConstruction。
• 启用语义排序器 – 在最终重新排序步骤中使用，以提升 LLM 输出质量。
• 实现集成向量化 – 简化流水线并降低维护开销。
• 使用 Azure Monitor 进行监控 – 随着数据集增长，跟踪向量索引大小和搜索延迟。

展望未来

未来的功能，例如 Vector Quantization 和 Disk‑backed HNSW，将能够以今天成本的一小部分支持数十亿向量，推动 RAG 可扩展性的边界。

针对企业架构师： 扩展 RAG 不仅仅关乎 LLM——更在于构建一个稳健的、高容量的检索基础设施。

---

获取更多技术指南请关注

• Twitter/X
• LinkedIn
• GitHub