GPT-RAG
微软Azure官方企业级RAG解决方案加速器，支持混合检索、NL2SQL、Multi-Agent编排
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
微软Azure官方企业级RAG解决方案加速器，支持混合检索、NL2SQL、Multi-Agent编排
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
在企业部署大语言模型时，有一个核心矛盾始终无法回避：模型的通用知识再强大，也无法准确回答企业私有的、不断变化的业务问题。一个客户如果问"我们公司去年Q3的售后服务满意度是多少"，没有任何通用大模型能给出正确答案——因为它根本没见过这份数据。
传统的解决方案是把文档喂给大模型，但这种方法在面对海量文档、跨库关联查询、多格式混合内容（PDF、Excel、SharePoint）时，很快就会触及瓶颈：上下文窗口不够用、检索精度不足、无法执行动态计算。
Azure GPT-RAG 就是来解决这个问题的。它是微软 Azure 官方开源的企业级 RAG 解决方案加速器，为组织提供了从零构建"可信知识问答"系统的完整技术蓝图。GPT 即 Generation（生成），RAG 即 Retrieval-Augmented Generation（检索增强生成），合起来就是"基于检索增强的大模型问答"——只不过这里的 RAG 是经过微软大量企业客户验证过的工程化版本，而不是学术 demo。
图1：GPT-RAG 交互界面（Chainlit 构建的对话式问答 UI）
GPT-RAG 采用了多仓库（Multi-repo）分布式架构，这是它区别于大多数开源 RAG 项目的显著特点。整个系统由 5 个 GitHub 仓库协同工作：
| 仓库 | 角色 | 主要技术 |
|---|---|---|
Azure/gpt-rag（本仓库） | 平台核心 + 配置中心 | Python + Bicep |
Azure/gpt-rag-orchestrator | AI 编排引擎 | Semantic Kernel + Azure AI Foundry Agent |
Azure/gpt-rag-ingestion | 数据接入与处理 | Python（文档解析+分块+向量化） |
Azure/gpt-rag-ui | 用户交互界面 | Chainlit（对话式 UI） |
Azure/gpt-rag-mcp | 工具协议服务器 | Semantic Kernel + MCP |
这种拆分设计背后有明确的工程逻辑：数据接入、推理编排和界面展示是三个完全不同的关注点，分别由不同团队负责，单独迭代，互不影响。
当用户提出一个问题时，GPT-RAG 内部的处理链路是这样的：
GPT-RAG 的检索层没有采用单一向量检索，而是实现了向量 + 关键词混合搜索。这是企业场景下的最佳实践：向量搜索擅长语义匹配（"找和这段话意思相近的内容"），关键词搜索擅长精确匹配（"必须包含这个词"），两者结合才能覆盖大多数查询场景。
检索的数据源包括：
GPT-RAG 的编排层内置了三种Agent 策略，通过 Semantic Kernel 的 Strategy Pattern 在运行时动态选择：
single_agent_rag：使用 Azure AI Foundry Agent Service 的单 Agent RAG，具备 Function Calling 能力，可调用 AI Search 和 Bing 进行检索增强。nl2sql：自然语言转 SQL 查询，通过 Semantic Kernel AgentGroupChat 协调 Triage Agent、SQL Query Agent 和 Synthesizer Agent 三者协作，直接查询结构化数据库。mcp：连接外部 MCP（Model Context Protocol）服务器，动态发现并调用第三方工具。这种"策略模式"设计让系统天然具备可扩展性：开发者只需要实现 BaseAgentStrategy 抽象类，注册到工厂，即可引入新的 AI 框架或工作流，而无需修改现有代码。
这是 GPT-RAG 中技术含量最高的模块之一。大多数 RAG 系统只能回答"文档里写了什么"，但企业的大量核心数据存在数据库里，格式规范、实时更新。NL2SQL 模块让用户可以直接用自然语言查询结构化数据：
用户问："哪些产品在过去一个季度的销售额超过了 100 万？" GPT-RAG 解析意图 → 生成 SQL → 查询数据库 → 把结果整合到回答中
NL2SQL 包含专门的索引器（将数据库 Schema 预先写入 AI Search）和清理器（定期删除过期数据），保证每次查询都能基于最新的数据库结构。
GPT-RAG 名字里的"Zero Trust"不是营销词汇，而是实打实的架构设计。核心要点包括：
GPT-RAG 的数据接入层（gpt-rag-ingestion）使用工厂模式处理不同格式的文档，每种格式对应专门的 Chunker：
GPT-RAG 的部署模型与大多数开源 RAG 项目截然不同——它完全面向 Azure 云环境设计，没有提供本地一键部署方案。
部署工具链：
azd)：主协调工具，管理整个部署生命周期infra/ 目录包含了所有资源模板部署流程：
azd provision：创建 Azure 基础设施（AI Search、Cosmos DB、Container Apps 等）azd deploy：构建并推送容器镜像，初始化 AI Search 索引硬件需求全部在 Azure 端：数据处理由 Azure 的服务器端处理，不需要消费级 GPU。由于检索在 AI Search 上完成，大模型推理由 Azure OpenAI 的托管服务处理，因此本地无需 GPU。
| 维度 | 评估 |
|---|---|
| 架构设计 | 优秀——多仓库策略模式，可插拔 Agent 架构 |
| 技术栈纯度 | 高——纯 Python + Semantic Kernel + Azure SDK |
| 测试覆盖 | 良好——完整测试目录 |
| 文档质量 | 极高——Azure 官方文档站点，CHANGELOG、CONTRIBUTING 一应俱全 |
| 安全性 | 优秀——Zero Trust、Entra ID、RBAC、RAI 策略 |
代码结构亮点：gpt-rag-orchestrator 中的 Strategy Pattern 实现非常规范：
BaseAgentStrategy 抽象基类定义了 initiate_agent_flow() 接口AgentStrategyFactory 根据配置动态实例化策略非常适合的场景：
局限性：
GPT-RAG 最重要的意义不在于它用了什么模型，而在于它展示了一套可工程化落地的企业级 RAG 架构。在它出现之前，很多组织在尝试自建 RAG 时会遇到"文档能搜到但答案不准"、"安全合规过不了"、"多模态处理一团糟"等实际问题。
GPT-RAG 把这些问题逐一解决，形成了经过大规模生产验证的模板。它的 Multi-Agent 编排思想（不同任务交给不同 Agent）启发了后来的许多项目，而 NL2SQL 的实现则直接展示了如何将 RAG 从"文档问答"扩展到"数据库查询"。作为 Azure 官方出品，它也代表了微软将 Copilot 能力向下游企业输出的核心路径。