Azure OpenAI Embeddings QnA：企业级 RAG 文档问答系统的标杆实现

你是否曾被淹没在成百上千份内部文档中，找不到想要的那一条政策、那一行代码注释？当员工用自然语言提问"我们公司去年Q3的技术债务回购政策是什么"时，传统搜索只能返回一堆模糊匹配的文档片段——而真正的答案往往藏在某一段落的某一句话里。Azure OpenAI Embeddings QnA 正是为解决这一痛点而生的开源项目：它让企业文档开口说话，用对话的方式精准提取答案。

项目背景与起源

图1：Redis Stack 作为向量存储的完整架构图

该项目由 Azure 技术布道师 Fabrizio Ruocco 创建并维护，最初作为微软官方 RAG（检索增强生成）参考架构的补充实现。与微软官方的 azure-search-openai-demo 相比，该项目在向量存储选型上更加多元：支持 Redis Stack、Azure Cache for Redis Enterprise、Azure Cognitive Search（预览版向量搜索）和 Azure PostgreSQL（pgvector）四种方案，开发者可根据现有基础设施自由选择。

项目采用 MIT 许可证，目前在 GitHub 拥有 847 颗星、498 个 fork，32 个 open issue，社区活跃度较高。技术栈聚焦于 Python + Azure 云生态，面向有一定 Azure 使用经验的企业开发者。

核心技术：RAG 架构的端到端实现

RAG（Retrieval-Augmented Generation，检索增强生成）是当前企业级 AI 应用的主流范式。该项目将 RAG 的三个核心环节——文档解析、向量嵌入、答案生成——串联为一条完整的流水线：

第一阶段：文档解析与分块（Batch Processing）

文档上传后，系统通过 Azure Form Recognizer（文档智能服务）提取 PDF/Word/Excel 等文件的文本内容，再使用 LangChain 的 TokenTextSplitter 按语义块进行切分。每一块文本通过 text-embedding-ada-002 模型转化为 1536 维向量，存入向量数据库。整个过程支持批量处理，用户可通过 Web UI 一键触发。

第二阶段：语义检索

用户提问时，系统先将问题本身转化为向量（同一个 embedding 模型），然后在向量数据库中执行余弦相似度搜索（Redis RediSearch / Azure Cognitive Search / pgvector），召回 Top-K 最相关的文档块。不同向量存储引擎共用同一套 LangChain VectorStore 接口，切换成本极低。

第三阶段：答案生成

将召回的文档块作为上下文，连同用户问题一起注入 Prompt，发送给 Azure OpenAI 的 GPT-3 / GPT-3.5-turbo / GPT-4 模型。Prompt 模板支持自定义，系统默认使用经过优化的检索问答模板。项目还支持翻译功能——文档和问答均可跨语言处理。

图2：PostgreSQL + pgvector 方案的架构示意图

技术架构详解

前端界面：基于 Streamlit 构建，提供多页面 Web UI，包括 Chat（对话问答）、Add Document（文档上传）、Document Management（文档管理）、Index Management（索引管理）和多个工具页面。streamlit-chat 组件提供对话气泡式交互体验。

核心编排层：LangChain v0.0.136 是整个系统的核心枢纽。项目大量使用 LangChain 的 ConversationalRetrievalChain 实现多轮对话记忆，使用 AzureOpenAI 和 ChatOpenAI 封装 LLM 调用，使用 OpenAIEmbeddings 封装 embedding 服务。值得注意的是，LangChain 版本较旧（0.0.136，发布于 2023 年初），新版 LangChain 的 API 已大幅变化，升级有一定迁移成本。

向量存储抽象：项目为不同向量存储实现了统一抽象接口：

• utilities/redis.py — Redis Extended，支持纯向量检索和混合检索
• utilities/azuresearch.py — Azure Cognitive Search 向量搜索（预览功能）
• utilities/pgvector.py — PostgreSQL pgvector 扩展
• utilities/formrecognizer.py — Azure Form Recognizer 文档解析
• utilities/translator.py — Azure Translator 多语言翻译
• utilities/azureblobstorage.py — Azure Blob Storage 原始文件存储

批处理后端：Batch Processing 使用 Azure Functions（Python 3.9）实现，支持无服务器事件驱动。文档上传触发函数执行，完成后通过 Redis Queue 通知前端。

容器化与部署支持

项目在容器化方面做得非常完善：

• WebApp.Dockerfile：基于 python:3.9.10-slim-buster，安装 tkinter 依赖（用于 Form Recognizer 本地 PDF 渲染），运行 Streamlit 应用，暴露 80 端口
• BatchProcess.Dockerfile：基于 mcr.microsoft.com/azure-functions/python:4-python3.9，适配 Azure Functions 运行环境
• docker-compose.yml：定义 web（Streamlit，8080:80）、api（Redis Stack Server，6379:6379）、batch（Azure Functions，8081:80）三个服务，自动健康检查等待 Redis 就绪

本地开发只需 docker-compose up 即可启动完整环境，不需要 Azure 账户（可对接本地 Redis Stack）。生产部署则提供了 5 套 Azure ARM 模板：标准 Redis Stack、Redis Enterprise、Azure Cognitive Search、Azure PostgreSQL（含中国区版本），覆盖全球和国内两大 Azure 区域。

适用场景与局限性

适用场景：企业内部知识库问答（如 HR 政策、IT 文档、产品手册）、技术支持文档检索、医疗/法律等合规文档查询、多语言文档库的跨语言问答。

局限性需注意：

1. 强依赖 Azure 生态：核心服务（OpenAI、Form Recognizer、Translator、向量存储）均需 Azure 账户，切换到 OpenAI 原版或其他云厂商成本较高
2. LangChain 版本陈旧：v0.0.136 发布于 2023 年 3 月，与当前主流 LangChain API 不兼容，直接升级可能导致 break change
3. 向量搜索精度依赖 embedding 模型：text-embedding-ada-002 虽是行业标准，但长文档场景下分块策略（chunk size = 400 tokens，overlap = 50 tokens）并非对所有文档类型最优
4. 生产级安全性需额外加固：.env.template 中明文存储密钥，生产部署需接入 Azure Key Vault；上传功能缺少文件类型和大小校验

总结

Azure OpenAI Embeddings QnA 是一个生产级的企业 RAG 参考实现，而非实验性 demo。它在架构设计上展现了 Azure 技术专家的深厚积累：多向量存储抽象、统一接口、完善的容器化、丰富的部署模板。对于已深度使用 Azure 的企业团队，该项目是快速搭建智能文档问答系统的捷径；但对于追求完全开源自主可控（不想绑定 Azure 服务费）的团队，建议基于该项目思路，替换为 Ollama + Weaviate/Milvus 的纯开源方案。