Foundry IQ 解惑：它和 Azure AI Search、传统 RAG 到底什么关系？

文章主旨：

Foundry IQ 不是另一个搜索引擎，也不是传统 RAG 的简单包装，而是以 Azure AI Search 为基础、面向 Agent 的知识与上下文工程层。

关键要点：

1. Azure AI Search 负责"搜"，Foundry IQ 负责把搜索组织成可供 Agent 复用的知识服务，两者是同一能力链路上分工不同的两个层次。

2. Knowledge Base 中的 LLM 负责"把问题问对、把证据找对"——包括查询规划、知识源选择与可选的答案合成，而非直接回答用户问题。

3. Retrieval reasoning effort（Minimal/Low/Medium）控制 LLM 介入检索的程度，直接影响知识源数量、子查询数量、答案合成预算以及成本延迟。

4. Blob 页面配置模型用于文档摄取阶段（提取图片图表等视觉内容生成可检索文本），Knowledge Base 页面配置模型用于检索阶段（理解问题并编排检索），两者工作在不同 RAG 阶段。

5. Foundry IQ 的核心价值是关注点分离：将检索编排从各个 Agent 中抽离出来，让一个领域知识库可被多个 Agent 共享和独立更新。

内容结构：

一、命名澄清——两个入口指向同一套 Foundry IQ 知识库能力，但属于不同管理界面：Azure 门户偏底层资源管理，Microsoft Foundry 项目中的 Knowledge 偏 Agent 开发体验。两者操作的 Knowledge Base 托管在选定的 Azure AI Search Resource 中。

二、Knowledge Base 为什么也需要 LLM——知识库中的 Chat Completions Model 属于检索管线，承担三项工作：查询规划、查询与知识源规划、可选的答案合成。Retrieval reasoning effort 控制 LLM 介入程度，分三档：Minimal（无 LLM 查询规划，直接搜索）、Low（一轮规划，默认模式）、Medium（可修订查询并再检索一次）。需区分两个模型角色：Knowledge Base 的 LLM 优化"如何找到证据"，Agent 的 LLM 负责"如何完成任务"。

三、Blob Knowledge Source 也要配置模型的原因——Blob 页面配置模型是为了在摄取阶段把原始文档变成更容易检索的内容；Knowledge Base 页面配置模型是为了在检索阶段理解问题并编排检索。文档处理逻辑为：解析、分块、补充可检索文本、生成向量用于召回。

四、与传统 RAG 的差别——传统 RAG 让 Agent 直接连接 Search Index，链路短、控制直接；Foundry IQ 把检索编排从 Agent 中抽离，可组织多知识源、拆分问题、迭代检索、保留引用，实现领域知识库被多个 Agent 共享。官方基准显示 agentic retrieval 响应质量相比传统单次 RAG 提升约 36%，适合作为方向性参考。

五、如何选择——已有成熟索引、问题简单、强调精确控制与低延迟：继续直接使用 Azure AI Search；需要跨来源回答复合问题、理解对话上下文、多 Agent 共享领域知识：优先考虑 Foundry IQ。

文章总结：

本文以技术澄清方式梳理 Foundry IQ 与 Azure AI Search 的层次关系、LLM 在检索管线中的角色及其与传统 RAG 的能力边界差异，给出务实的技术选型建议：You can outsource your thinking, but you cannot outsource your understanding.

以上摘要由 AI 生成，仅供参详。

Bruce Talk

查看原文：Foundry IQ 解惑：它和 Azure AI Search、传统 RAG 到底什么关系？

文章来源：

Bruce Talk

扫码关注公众号