Azure AI Search 高级 RAG 与 Terraform:混合搜索、语义排序和代理式检索 🧠
Source: Dev.to
(请提供您希望翻译的文章正文内容,我将为您翻译成简体中文,并保持原始的格式、Markdown 语法以及技术术语不变。)
Azure AI Search 中的混合搜索与代理检索
仅使用向量搜索会遗漏相关性。
通过语义排序、分块策略、元数据过滤、严格度调优以及全新的 agentic retrieval 流水线实现混合搜索,可将 Azure AI Search 打造成生产级 RAG 系统——全部通过 Terraform 进行配置。
回顾 (RAG 第 1 篇)
- 部署了带有基础索引的 Azure AI Search,并将其连接到 Azure OpenAI。
- 检索质量一般——用户提出细致的问题,却得到不完整或不相关的答案。
解决方案: 并非更好的生成模型,而是 更好的检索。
Azure AI Search 提供了三大云平台中最为先进的内置检索流水线:
- 混合搜索 – BM25 关键字匹配 + 通过 Reciprocal Rank Fusion (RRF) 的向量相似度。
- 基于 Transformer 的语义排序器 – 对顶部结果进行深度重新打分。
- 元数据过滤 与 严格度控制。
- 代理检索 – 自动将复杂查询分解。
⚠️ 重要提示: Azure OpenAI “On‑Your‑Data” 已被弃用。Microsoft 建议迁移至 Foundry Agent Service 并使用 Foundry IQ。下面的模式使用直接的 Azure AI Search 集成,兼容当前及未来的架构。
分块策略
Azure AI Search 通过其索引器管道支持两种分块方法:
| 方法 | 工作原理 | 优点 | 缺点 |
|---|---|---|---|
| 固定大小分块 (Text Split skill) | 按标记或字符计数进行分割,可配置重叠。 | 简单、可预测、成本效益高。 | 忽略文档结构。 |
| 结构感知分块 (Document Layout skill) | 使用 Azure Document Intelligence 识别标题、章节和布局元素。 | 保留文档层次结构。 | 增加每页处理成本。 |
推荐分块大小(Microsoft 基准)
| 分块大小 | 重叠 | 适用场景 | 权衡 |
|---|---|---|---|
| 256 tokens | 25 % | 短 FAQ、问答对 | 高精度,上下文较少 |
| 512 tokens | 25 % | 通用文档 (默认) | 精度与上下文的最佳平衡 |
| 1024 tokens | 10‑15 % | 长技术/法律文档 | 上下文更多,噪声风险增加 |
关键洞察: 分块时保留句子边界。句中拆分会降低嵌入质量和检索准确性。
分层检索架构
1️⃣ 混合搜索(BM25 + 向量)+ RRF 融合
from azure.search.documents import SearchClient
from azure.search.documents.models import VectorizableTextQuery
search_client = SearchClient(
endpoint=search_endpoint,
index_name="company-docs",
credential=credential,
)
vector_query = VectorizableTextQuery(
text="What are the penalties for late delivery?",
k_nearest_neighbors=50,
fields="contentVector",
)
results = search_client.search(
search_text="penalties late delivery", # BM25 关键字查询
vector_queries=[vector_query], # 向量查询
select=["title", "content", "source"],
top=50,
)
- 为什么要两者兼顾?
- 向量 处理同义词和改写。
- 关键字 捕获产品代码、政策编号、精确术语。
- RRF 将两个结果集合并,提供两者的最佳效果。
2️⃣ 语义排序器(Transformer 重评分)
results = search_client.search(
search_text="penalties late delivery",
vector_queries=[vector_query],
query_type="semantic",
semantic_configuration_name="default",
top=50,
)
for result in results:
print(f"Score: {result['@search.reranker_score']:.2f} - {result['title']}")
- 排序器通过查询和文档文本之间的交叉注意力,生成 0 → 4(无关 → 优秀)的校准分数。
3️⃣ 用于语义排序的 Terraform 配置
resource "azurerm_search_service" "this" {
name = "${var.environment}-${var.project}-search"
resource_group_name = azurerm_resource_group.this.name
location = var.location
sku = var.search_sku
semantic_search_sku = var.semantic_search_sku
identity {
type = "SystemAssigned"
}
}
环境变量
# environments/dev.tfvars
search_sku = "basic"
semantic_search_sku = "free" # 每月查询次数受限
# environments/prod.tfvars
search_sku = "standard"
semantic_search_sku = "standard" # 语义查询次数无限制
基准结论: 混合 + 语义排序始终在各种结果集规模下找到最佳内容。纯向量搜索会漏掉许多混合搜索能捕获的相关结果,而没有语义排序时,最相关的结果往往位于第 7‑8 位,而不是第 1 位。
Agentic Retrieval(2025‑11‑01‑preview API)
Agentic retrieval 自动 将复杂查询拆解 为子查询,分别通过混合 + 语义管道运行,并合并结果。
示例
User: "Compare our 2024 and 2025 refund policies and highlight what changed"
拆解步骤
- 子查询 1:“2024 refund policy terms and conditions”
- 子查询 2:“2025 refund policy terms and conditions”
- 子查询 3:“changes updates refund policy”
每个子查询的流程为:
Hybrid search → Semantic rerank top 50 → Merge
编排逻辑位于 Knowledge Base 对象中;底层服务、索引和语义配置保持不变。
何时使用 Agentic Retrieval
- 具有 多重意图 的复杂问题。
- 比较型 查询(例如,版本间的分析)。
- 跨 多个文档类别 的查询。
影响: 会增加延迟,但在复杂查询上可将答案质量提升 最高 40 %(Microsoft 基准测试)。
TL;DR 检查清单
- ✅ 使用 512‑token 块,25 % 重叠,并保留句子边界。
- ✅ 启用 Hybrid search(BM25 + 向量)并使用 RRF 融合。
- ✅ 开启 Semantic ranking(Standard tier,
semantic_search_sku = "standard")。 - ✅ 对于多意图或比较性问题,切换到通过 Knowledge Base API 的 Agentic retrieval。
- ✅ 使用 Terraform 管理所有内容,以实现 dev / prod 环境的可复现性。
使用这些模式,Azure AI Search 将成为生产级 RAG 引擎,能够在大规模下提供精准、上下文丰富的答案。 🚀
可过滤字段的范围检索
Filters run before vector search, narrowing the candidate set:
results = search_client.search(
search_text="refund policy changes",
vector_queries=[vector_query],
query_type="semantic",
semantic_configuration_name="default",
filter="department eq 'legal' and year ge 2024",
top=20
)
Terraform 注释:
可过滤字段必须在索引模式中使用 filterable: true 定义。模式通常通过门户、SDK 或 REST API(而非 Terraform)进行管理,而搜索服务及其 SKU/功能则由 Terraform 管理。
Azure OpenAI 数据源集成
有两个参数控制检索质量:
| 参数 | 范围 | 描述 |
|---|---|---|
| strictness | 1‑5 | 过滤不相关块的力度。数值越高,过滤越严格。 |
| top_n_documents | 1‑20 | 在过滤和重新排序后,包含在 LLM 提示中的块数量。块越多,上下文越丰富(代价更高的 token 消耗)。 |
严格程度级别
| 严格程度 | 行为 | 典型使用场景 |
|---|---|---|
| 1‑2 | 宽松 – 包含边缘结果 | 探索性问题,宽泛主题 |
| 3 | 平衡(默认) | 通用 |
| 4‑5 | 严格 – 仅高度相关的结果 | 精确事实查询,合规性 |
示例调用
completion = client.chat.completions.create(
model=deployment,
messages=[{"role": "user", "content": "What changed in the refund policy?"}],
extra_body={
"data_sources": [{
"type": "azure_search",
"parameters": {
"endpoint": search_endpoint,
"index_name": "company-docs",
"query_type": "vector_semantic_hybrid",
"semantic_configuration": "default",
"strictness": 4,
"top_n_documents": 5,
"authentication": {
"type": "system_assigned_managed_identity"
}
}
}]
}
)
调优指南
- 模型提示“信息不足” → 降低
strictness或 提高top_n_documents。 - 答案包含不相关的上下文 → 提高
strictness或 降低top_n_documents。
Terraform 示例 (rag/main.tf)
resource "azurerm_search_service" "this" {
name = "${var.environment}-${var.project}-search"
resource_group_name = azurerm_resource_group.this.name
location = var.location
sku = var.search_sku
semantic_search_sku = var.semantic_search_sku
replica_count = var.search_replicas
partition_count = var.search_partitions
identity {
type = "SystemAssigned"
}
tags = var.tags
}
# 嵌入模型部署
resource "azurerm_cognitive_deployment" "embedding" {
name = "text-embedding-3-small"
cognitive_account_id = azurerm_cognitive_account.openai.id
model {
format = "OpenAI"
name = "text-embedding-3-small"
version = "1"
}
sku {
name = "Standard"
capacity = var.embedding_capacity
}
}
变量文件
environments/dev.tfvars
search_sku = "basic"
semantic_search_sku = "free"
search_replicas = 1
search_partitions = 1
embedding_capacity = 30
strictness = 3
top_n_documents = 5
environments/prod.tfvars
search_sku = "standard"
semantic_search_sku = "standard"
search_replicas = 2
search_partitions = 1
embedding_capacity = 120
strictness = 4
top_n_documents = 5
功能比较
| Feature | Azure AI Search | AWS Bedrock KB | GCP RAG Engine |
|---|---|---|---|
| Chunking | Fixed‑size + Document Layout skill | Fixed, hierarchical, semantic, Lambda | Fixed‑size only |
| Hybrid search | BM25 + vector via RRF (built‑in) | Supported on OpenSearch | Alpha‑weighted dense/sparse |
| Semantic reranking | Built‑in transformer ranker (L2) | Cohere Rerank | Rank Service + LLM Ranker |
| Query decomposition | Agentic retrieval (native) | Native API parameter | Not built‑in |
| Metadata filtering | Filterable index fields + OData | JSON metadata files in S3 | Filter string at query time |
| Strictness control | 1‑5 scale on data source | Not built‑in | Vector distance threshold |
| Reranker score range | 0‑4 (calibrated, cross‑query consistent) | Model‑dependent | Model‑dependent |
Azure的优势在于最成熟的检索管道——包括混合、语义排序、代理检索三层组合。语义排序器的校准评分还能在不同索引和查询模式之间实现一致的质量阈值。
建议配置
| 情境 | 查询类型 | 语义排序器 | 严格程度 | top_n_documents |
|---|---|---|---|---|
| 入门 | vector_simple_hybrid | 免费层 | 3 | 5 |
| 生产(通用) | vector_semantic_hybrid | 标准 | 3 | 5 |
| 精确事实查找 | vector_semantic_hybrid | 标准 | 4‑5 | 3 |
| 广泛研究查询 | vector_semantic_hybrid | 标准 | 2 | 10 |
| 复杂多部分问题 | Agentic retrieval | 标准 | 3 | 5 |
建议: 首先使用标准层的 vector_semantic_hybrid——这是 Microsoft 基准的默认设置。对于特别复杂的查询模式,可添加 agentic retrieval。
系列背景
- 第 1 篇: Azure AI Search RAG – 基础设置 🔍
- 第 2 篇: Advanced RAG – Hybrid Search, Semantic Ranking, Agentic Retrieval(此处)🧠
您的 RAG 流水线现在利用了完整的 Azure AI Search 套件:用于召回的混合搜索、用于精确度的语义排序、用于复杂查询的代理检索、用于范围的元数据过滤,以及用于噪声控制的严格度调优——所有这些都由每个环境的 Terraform 变量驱动。
发现这有帮助吗? 关注完整的 使用 Terraform 的 RAG 流水线 系列! 💬