基于Azure Cosmos DB与OpenAI构建企业级RAG智能问答应用实战

1. 项目概述：构建一个基于向量数据库的智能对话应用

最近在折腾一个挺有意思的项目，想和大家分享一下如何用 Azure Cosmos DB 和 Azure OpenAI Service 来搭建一个真正能用的“副驾驶”应用。这个项目的核心思路，就是把你的数据变成 AI 能理解的语言，然后让 AI 基于这些数据和你进行有上下文、有记忆的智能对话。听起来有点复杂？别担心，我会把每一步都拆开揉碎了讲清楚。

简单来说，这个项目就是一个聊天应用，但它不是普通的聊天机器人。它背后连接着你自己的知识库（比如公司文档、产品手册、技术资料），当你问它问题时，它能从你的知识库里找到最相关的信息，然后组织成通顺的回答告诉你。这比让 AI 凭空想象要靠谱得多，回答的准确性和专业性也高得多。整个过程涉及到几个关键技术：用 Azure OpenAI 把文本转换成向量（一种数学表示），用 Cosmos DB 的向量搜索功能快速找到最匹配的文档，再用 Semantic Kernel 这个框架来优雅地管理整个对话流程和上下文。无论你是想做个内部知识问答助手，还是想给自家产品加个智能客服，这个架构都值得参考。

2. 核心架构与设计思路拆解

2.1 为什么选择“检索增强生成”架构

这个项目的技术选型背后，有一个非常明确的架构模式在支撑，叫做“检索增强生成”。这是目前构建可靠企业级 AI 应用最主流的方案之一。它的核心思想很简单：不让大语言模型去“记忆”或“编造”它不知道的事实，而是当用户提问时，先去外部的、可信的数据源里检索出相关的信息片段，然后把问题和这些信息片段一起交给大语言模型，让它基于这些材料来组织答案。

我选择这个架构，主要是为了解决大语言模型的两个固有短板：幻觉和信息过时。模型可能会自信地编造一个听起来合理但完全错误的答案，这就是幻觉。另外，模型的训练数据有截止日期，它无法知道那之后发生的事。通过 RAG，我们把答案的“事实依据”牢牢锚定在我们自己维护的、最新的知识库上，极大地提升了回答的可信度。在这个项目里，Azure Cosmos DB 就是那个强大、可扩展的“外部知识库”，而向量搜索则是从海量文档中瞬间找到最相关片段的“搜索引擎”。

2.2 核心组件选型与考量

整个应用由几个关键部件组成，每个部件的选型都经过了仔细的权衡。

首先是Azure Cosmos DB for NoSQL，我选择它而不是单纯的向量数据库，看中的是它的“多模”能力。我的业务数据（比如用户订单、产品目录）本来就可能存在 Cosmos DB 里，现在它原生支持向量搜索，意味着我可以在同一个数据库、甚至同一张表里，既存业务数据，又存文档的向量嵌入。数据一致性、运维复杂度都大大降低。而且 Cosmos DB 的全球分布和弹性扩展能力，为应用未来的增长铺平了道路。

其次是Azure OpenAI Service。直接用 OpenAI 的 API 行不行？技术上可以，但从企业级应用的角度看，Azure OpenAI 提供了更重要的东西：数据隐私与合规承诺、网络延迟优化（如果你的其他资源都在 Azure 上）、以及与 Azure Active Directory 集成的身份验证和精细的成本监控。特别是用于生成文本嵌入的text-embedding-ada-002模型和用于对话的 GPT 模型，通过 Azure 服务调用，在安全性和可控性上更让人放心。

最后是Semantic Kernel。这是一个由微软推出的开源 SDK，你可以把它理解为 AI 应用开发的“胶水”和“脚手架”。它抽象了与不同 AI 服务（OpenAI, Azure OpenAI, Hugging Face 等）的交互细节，提供了插件（Plugins）、规划器（Planner）、记忆（Memory）等高级概念。在这个项目里，我用它主要是为了优雅地管理“对话历史”（上下文窗口），以及标准化调用嵌入生成和聊天补全的流程。它让代码更清晰，也更容易未来扩展功能。

注意：在项目初期，务必在 Azure 门户中为你的 Cosmos DB for NoSQL 账户申请加入“向量搜索”的预览功能。这是一个必要的准入步骤，如果没有开启，后续的向量索引创建和查询都会失败。申请通常很快会通过。

2.3 数据流与交互逻辑全景

理解数据是如何流动的，是掌握这个项目的关键。整个交互过程可以分解为以下几个步骤，我画个简单的逻辑图在脑子里，大家跟着走一遍：

1. 知识库准备（预处理阶段）：首先，你需要有一批文档（比如 Markdown、PDF、Word）。通过一个后台处理程序，调用 Azure OpenAI 的嵌入模型，为每一段有意义的文本（例如一个段落）生成一个高维向量（比如1536维），同时将原文存储起来。这个“向量-原文”对，会被写入 Cosmos DB 的一个特定容器中。
2. 用户提问（查询阶段）：当用户在聊天界面输入一个问题，比如“我们产品的退货政策是什么？”，应用不会直接把问题扔给 GPT。而是先做同样的事情：把这个问题转换成向量。
3. 向量检索（核心阶段）：应用拿着问题的向量，去 Cosmos DB 中执行向量相似度搜索（通常使用余弦相似度）。Cosmos DB 会利用我们预先创建好的向量索引，快速从成千上万的文档片段中，找出与问题向量最相似的几个（比如 top 3）片段。
4. 提示词工程与上下文组装：检索到的几个原文片段，被组合成一个“上下文”。然后，我们精心设计一个“提示词”，其结构通常是：“你是一个客服助手。请根据以下上下文信息回答问题。如果上下文里没有答案，就说你不知道。上下文：{检索到的原文片段}。问题：{用户原始问题}。回答：”
5. 生成与返回：这个组装好的提示词被发送给 Azure OpenAI 的聊天补全模型（如 GPT-4）。模型基于我们提供的上下文生成回答，最后这个回答呈现给用户。同时，本次的“问题-回答”对，会被作为历史记录保存下来，并入下一次对话的上下文，从而实现多轮对话的记忆。

这个流程确保了答案的根源来自你的知识库，并且通过提示词约束了模型的发挥范围，既利用了模型的强大理解和生成能力，又规避了它的主要缺陷。

3. 环境准备与项目初始化实操

3.1 前置条件与资源创建

动手之前，我们需要把“舞台”搭好。所有的服务都基于 Azure，所以你需要一个有效的 Azure 订阅。如果还没有，可以去官网注册一个，通常有免费额度和试用金。

第一步，开通 Azure OpenAI 服务访问权限。这是一个需要申请的服务。在 Azure 门户中搜索“Azure OpenAI”，点击创建，你会发现需要提交申请。点击“申请访问”链接，填写一个简单的表格，说明你的使用场景（比如“开发智能问答原型用于内部知识管理”）。审批速度有时很快，有时需要一两天，所以这一步建议最先做。

第二步，创建 Azure OpenAI 资源。申请通过后，在 Azure 门户创建 OpenAI 资源。创建时注意选择离你用户近的区域，比如East US或Southeast Asia。创建完成后，进入该资源，在“密钥和终结点”页面，你会看到终结点 URL 和两个 API 密钥。妥善保存它们，我们后续配置会用到。接着，你需要部署模型。在资源的“模型部署”页面，点击“管理部署”，至少需要部署两种模型：

• 一个聊天模型：例如，选择gpt-35-turbo(或gpt-4)，给它起个部署名，比如chat-gpt35。
• 一个嵌入模型：选择text-embedding-ada-002，部署名起为text-embedding。

第三步，创建 Cosmos DB 账户并开启向量搜索预览。在 Azure 门户创建 Azure Cosmos DB 账户，API 类型选择“NoSQL”。创建时同样注意区域选择。创建完成后，进入资源，按照要求所述：左侧菜单“设置” -> “功能” -> 找到“Vector Search in Azure Cosmos DB for NoSQL” -> 点击“启用”进行注册。这个预览功能是免费的，但必须显式开启才能使用向量索引功能。

第四步，安装 Azure Developer CLI (azd)。这是一个非常棒的工具，它能把项目的代码、基础设施配置（IaC）和部署流水线统一管理。根据你的操作系统，从官网下载安装。安装后，在终端运行azd version确认安装成功。

3.2 使用 Azure Developer CLI 一键部署

项目原作者提供了azd模板，这极大地简化了部署。打开终端，进入一个你准备存放项目代码的目录。

1. 登录 Azure：执行azd auth login。这会打开浏览器让你完成 Azure 身份验证。这一步每个环境通常只需做一次。
2. 初始化项目：执行azd init --template cosmosdb-chatgpt。这个命令会从 GitHub 拉取这个示例项目的代码和基础设施即代码（Bicep）模板到当前目录。azd会交互式地询问你一些信息，比如环境名称（例如dev）、Azure 订阅和区域。它会根据你的选择，在本地生成配置文件。
3. 配置环境变量：在项目根目录，你会找到一个azure.yaml和infra文件夹。但关键的配置，比如 OpenAI 的密钥和终结点，通常需要通过.env文件或azd的环境来设置。你可能需要查看代码中的appsettings.json或类似文件，了解需要哪些参数。一个典型的做法是在执行azd up之前，通过azd config set命令来设置这些值，或者直接修改infra目录下的 Bicep 参数文件。
4. 执行部署：最关键的一步，运行azd up。这个命令会做三件大事：
   • 预配基础设施：它在你的 Azure 订阅里，按照 Bicep 模板的定义，自动创建所需的所有资源，包括 App Service 计划、Web 应用、Cosmos DB 账户和数据库容器。它甚至会帮你开启 Cosmos DB 的向量搜索预览功能（如果模板支持）。
   • 构建应用代码：它会在云端或本地（取决于配置）构建你的 .NET 应用，打包成 Docker 容器。
   • 部署应用到云：将构建好的容器镜像部署到 Azure App Service。

整个过程可能需要 10 到 20 分钟。部署成功后，终端会输出应用访问的 URL（通常是一个.azurewebsites.net的域名）。用浏览器打开它，你的聊天应用界面就应该出现了。

实操心得：第一次运行azd up时，可能会因为 Azure 资源提供商注册问题而失败。如果遇到关于Microsoft.DocumentDB或Microsoft.CognitiveServices的错误，可以到 Azure 门户的“订阅” -> “资源提供程序”里，手动搜索并注册一下这些提供程序，然后重试azd up。

3.3 手动部署与代码结构解析

如果你不想用azd，或者想更深入地理解每一部分，也可以手动部署。项目代码结构通常是这样的：

cosmosdb-chatgpt/ ├── src/ │ ├── ChatWebApp/ # 前端 Blazor 项目 │ └── ChatService/ # 后端 .NET Core Web API 项目 ├── scripts/ # 数据库初始化、数据导入脚本 ├── infra/ # Bicep/ARM 模板（azd 使用） └── README.md

手动部署步骤概要：

1. 创建资源：手动在 Azure 门户创建前述的所有资源：App Service Plan、Linux 上的 Web App（支持容器）、Cosmos DB NoSQL 账户（开启向量预览）、Azure OpenAI 资源并部署模型。
2. 配置连接字符串：在 Web App 的“配置” -> “应用程序设置”中，添加所有必要的连接字符串和密钥，例如：
   • CosmosDbConnectionString
   • OpenAiEndpoint
   • OpenAiKey
   • OpenAiChatDeploymentName(你部署的聊天模型名，如chat-gpt35)
   • OpenAiEmbeddingDeploymentName(你部署的嵌入模型名，如text-embedding)
3. 构建与发布：在本地用dotnet publish命令发布项目，或者配置 GitHub Actions/Azure DevOps 流水线进行持续集成部署。
4. 初始化数据库：运行项目中的数据库初始化脚本（如果有），或者通过应用首次启动时的逻辑，来创建 Cosmos DB 容器和向量索引。

手动部署的优点是控制力强，每一步都清晰可见；缺点是步骤繁琐，容易出错。azd的方案更适合快速原型验证和可重复部署。

4. 核心功能模块深度解析

4.1 向量嵌入生成与存储策略

向量是整个智能搜索的基石。这里用的模型是text-embedding-ada-002，它会把一段文本映射到一个 1536 维的浮点数向量空间中。语义相近的文本，其向量在空间中的距离（通常用余弦相似度衡量）也更近。

在代码中，你会看到一个专门处理嵌入的服务类，比如OpenAITextEmbeddingService。它的核心工作就是调用 Azure OpenAI 的嵌入 API。这里有个非常重要的实践细节：分块策略。你不能把一整本 100 页的 PDF 直接扔进去生成一个向量，那样粒度太粗，搜索精度会极差。常见的策略有：

• 固定大小分块：比如每 500 个字符或 token 为一块。简单，但可能割裂完整语义。
• 基于分隔符分块：按照段落（\n\n）、标题、句子等自然边界进行分割。
• 递归分块：先按大分隔符分，如果块太大，再按小分隔符继续分，直到块大小在预定范围内。
• 语义分块：使用更复杂的 NLP 模型来识别语义边界，成本较高。

在这个示例中，我建议采用一种重叠分块的策略。比如，每块 1000 个 token，块与块之间重叠 200 个 token。这样能确保即使答案的关键信息恰好落在两个块的边界，也能被至少一个完整的块所包含，提高检索召回率。

生成向量后，如何存入 Cosmos DB？你需要设计一个容器（Container），其文档结构可能如下：

{ "id": "doc_chunk_12345", "sourceDocumentId": "policy_manual_v2.pdf", "chunkIndex": 2, "text": "根据退货政策，商品在签收后30天内，保持完好且未经使用，可申请无理由退货...", "embedding": [0.012, -0.045, 0.987, ...], // 1536维向量 "metadata": { "title": "消费者权益条款", "page": 15, "category": "policy" } }

embedding字段就是存储向量的地方。为了能对这个字段进行高效相似度搜索，你必须在 Cosmos DB 中创建一个向量索引策略。

4.2 Cosmos DB 向量索引配置详解

这是 Cosmos DB NoSQL 向量搜索的核心配置。你可以在创建容器时指定，或者后期通过 SDK/Portal 添加。一个典型的向量索引策略如下：

{ "indexingMode": "consistent", "automatic": true, "includedPaths": [ { "path": "/*" } ], "excludedPaths": [ { "path": "/\"_etag\"/?" } ], "vectorIndexes": [ { "path": "/embedding", "type": "quantizedFlat" } ] }

关键部分是vectorIndexes。path指定了哪个字段是向量字段。type定义了索引算法，quantizedFlat是预览阶段支持的一种类型，它在精度和性能/成本之间取得了很好的平衡，通过对向量进行量化（一种有损压缩）来减少存储和计算开销，同时保持较高的搜索准确性。

创建这个索引后，你就可以使用 Cosmos DB SDK 中的新查询语法来执行向量搜索了。查询看起来会像这样（以 .NET SDK 为例）：

var embeddings = await _embeddingService.GenerateEmbeddingsAsync(queryText); var query = new QueryDefinition("SELECT TOP 3 c.text, c.metadata FROM c ORDER BY VectorDistance(c.embedding, @embedding) DESC") .WithParameter("@embedding", embeddings);

VectorDistance是 Cosmos DB 提供的用于计算向量相似度的内置函数。这里按距离降序排序，实际上就是取相似度最高的前 3 项。

注意事项：向量索引的创建和数据的插入是异步过程。在插入大量数据后立即进行搜索，可能无法立即查到全部数据，因为索引还在构建中。对于生产环境，需要监控索引转换进度，或设计数据预热流程。

4.3 语义内核对话管理与上下文窗口

Semantic Kernel 在这里扮演了“大脑皮层”的角色，管理着对话的短期记忆和复杂逻辑。我们主要用到它的两个核心概念：插件和记忆。

首先，我们会创建一个ChatCompletionService，连接到我们部署的 Azure OpenAI 聊天模型。然后，我们定义一个“聊天”插件。这个插件内部封装了之前描述的整个 RAG 流程：接收用户输入 -> 生成问题向量 -> Cosmos DB 向量搜索 -> 组装提示词 -> 调用 GPT 生成回答。

更关键的是上下文窗口管理。GPT 模型有一个 token 数限制（例如，gpt-3.5-turbo 是 4096 tokens）。这个限制包括你发送的提示词和模型返回的回答。如果无限制地将历史对话全部塞进去，很快就会超限。Semantic Kernel 的ChatHistory类帮我们管理这个列表。但我们需要一个策略来决定保留哪些历史：

• 滑动窗口：只保留最近 N 轮对话。简单有效，但可能丢失重要的早期信息。
• 摘要压缩：当对话轮数增多时，调用 GPT 对之前的对话历史生成一个简短的摘要，然后用这个摘要代替原始的长篇历史，放入上下文。这需要额外的 LLM 调用和提示词设计。
• 基于重要性的筛选：更复杂的策略，尝试评估历史中每句话的重要性，保留重要的，剔除冗余的。

在这个示例项目中，通常实现一个简单的滑动窗口。每次新的交互，我们都将“系统指令”、“检索到的上下文”、“最近几轮历史”和“新问题”组合成最终提示词。Semantic Kernel 让这种组合和调用变得非常声明式和简洁。

// 伪代码示例 var builder = Kernel.CreateBuilder(); builder.Services.AddAzureOpenAIChatCompletion(deploymentName, endpoint, apiKey); var kernel = builder.Build(); // 假设我们已经有一个检索插件 kernel.ImportPluginFromObject(new RetrieverPlugin(_cosmosDbService), "RetrieverPlugin"); // 创建聊天历史 ChatHistory history = new(); history.AddSystemMessage("你是一个乐于助人的助手，请根据提供的上下文回答问题。"); history.AddUserMessage("我们产品的退货政策是什么？"); // ... 在插件内部，会进行检索，并将上下文添加到历史或提示词中 ... // 获取聊天服务并生成回复 var chatCompletionService = kernel.GetRequiredService<IChatCompletionService>(); var result = await chatCompletionService.GetChatMessageContentAsync(history);

通过 Semantic Kernel，我们将检索、对话管理、工具调用等能力模块化，使得应用架构清晰，易于维护和扩展。

5. 性能优化与成本控制实战

5.1 构建语义缓存以降低开销

直接调用 OpenAI 生成嵌入和补全是应用的主要成本来源，尤其是嵌入接口，按 token 数计费。同时，向量搜索虽然快，但相比简单的键值查询仍有开销。一个非常有效的优化手段是引入语义缓存。

其原理是：很多用户问题在语义上是相似或相同的。比如“怎么退货？”和“退货流程是怎样的？”。与其每次都重新生成嵌入、搜索向量、调用 GPT，不如把第一次计算出的结果缓存起来。当新问题进来时，先计算其向量，然后在缓存里搜索是否有语义相似的历史问题（同样使用向量相似度，设定一个较高的相似度阈值，如 0.95）。如果找到，直接返回缓存中的答案，完全跳过对 OpenAI 和知识库的调用。

这个缓存层可以放在哪里？直接用 Cosmos DB 实现！我们可以单独创建一个容器SemanticCache，其文档结构包含：QuestionVector（问题向量）、OriginalQuestion（原始问题文本）、Answer（生成的答案）、Timestamp。每次用户提问前：

1. 生成问题向量。
2. 在SemanticCache容器中对QuestionVector字段执行向量搜索，寻找相似度 > 0.95 的条目。
3. 如果找到，直接返回缓存的Answer，并更新Timestamp。
4. 如果未找到，走完整的 RAG 流程，并将最终的结果（问题向量、问题文本、答案）写入SemanticCache容器，同时可以设置一个 TTL（生存时间）来自动清理旧缓存。

这样做的好处是：

• 大幅降低延迟：缓存命中时，响应速度极快。
• 显著节省成本：减少了 OpenAI API 的调用次数。
• 提升用户体验：对于常见问题，回答一致性更高。

5.2 令牌管理与上下文优化策略

Token 是 OpenAI 计费的单位，也是模型上下文长度的限制单位。管理好 Token 使用，是控制成本和保证功能正常的关键。

1. 输入 Token 优化：

• 精简系统指令：系统指令（System Prompt）每次都会发送，确保它简洁、必要。避免冗长的角色扮演描述。
• 优化检索结果数量：不要盲目返回 top 10 的文档片段。通过实验，找到在保证答案质量的前提下，所需的最少片段数量（通常是 2-3 个）。每个片段都是 Token。
• 压缩检索文本：对于检索到的长文本，可以尝试进行摘要压缩后再放入上下文。这需要额外调用一次 LLM，但在上下文非常紧张时可能是值得的。一个更简单的方法是在分块时，就控制好块的大小，避免过大的块。
• 历史对话摘要：如前所述，对于长对话，将旧历史总结成摘要，比直接拼接所有历史文本更节省 Token。

2. 输出 Token 控制：

• 设置max_tokens参数：在调用聊天补全 API 时，明确设置回答的最大 Token 数，防止模型生成过于冗长的回答（也浪费钱）。
• 使用流式响应：虽然不减少总 Token，但流式响应（Streaming）可以让用户更快地看到回答的开头部分，提升感知速度。

3. 监控与告警：在 Azure OpenAI 服务中，你可以方便地在“监控”部分查看各模型的 Token 消耗情况。建议为你的资源组或订阅设置预算告警，当日消耗或月消耗接近阈值时自动通知，避免意外的高额账单。

5.3 向量搜索的性能调优

当你的知识库文档达到百万甚至千万级别时，向量搜索的性能和成本就成为关键考量。

• 索引类型选择：Cosmos DB 预览提供的quantizedFlat索引是一种平衡之选。未来正式版可能会支持更丰富的索引类型，如 HNSW（Hierarchical Navigable Small World），这种图结构索引在超高维度和超大规模数据集上，能提供更快且近似度可接受的搜索速度，但构建成本和内存占用更高。需要根据数据规模和性能要求进行选择。
• 分区键设计：Cosmos DB 的性能核心在于分区键。对于向量搜索容器，分区键的设计需要深思熟虑。一个常见的模式是使用文档来源的类别或类型作为分区键（例如metadata.category）。这样，当大多数查询都集中在某个类别内时，查询可以限定在单个分区内，效率最高。避免使用像id或完全随机的值作为分区键，这会导致查询“扇出”到所有分区，增加 RU 消耗和延迟。
• 查询的 RU 消耗：向量搜索查询会比普通点读消耗更多的请求单位。你需要密切监控查询的 RU 费用，并在设计时考虑：
  • 减少每次查询返回的向量数量（TOP N中的 N）。
  • 尝试在WHERE子句中添加基于元数据（如category）的筛选，结合分区键，缩小搜索范围。
  • 根据查询模式，适当调整容器的吞吐量（RU/s）配置。

6. 常见问题排查与进阶技巧

6.1 部署与运行问题速查

在搭建和运行过程中，你可能会遇到一些典型问题。这里列出一个排查清单：

6.2 效果调优与评估心得

项目跑起来只是第一步，要让它的回答真正“好用”，还需要持续的调优。

1. 分块策略调优：这是影响检索质量最关键的环节。没有放之四海而皆准的方案。你需要用自己的数据做实验。

• 评估方法：准备一组标准问题（Q）和对应的标准答案片段（A，来自你的文档）。运行你的 RAG 流程，看检索到的文本块是否包含了 A。计算检索召回率。
• 调整参数：尝试不同的块大小（如 256, 512, 1024 tokens）和重叠度（如 0, 10%）。对于结构规整的文档（如 API 文档），按标题分块可能更好；对于长段落文本（如小说），固定大小+重叠可能更合适。

2. 提示词工程：系统指令和问题包装方式极大影响最终答案质量。

• 明确指令：在系统指令中清晰定义角色和限制，例如“你是一个严谨的技术支持专家，只根据提供的上下文信息回答问题。如果上下文没有明确信息，请直接说‘根据现有资料，我无法回答这个问题’，不要编造信息。”
• 提供格式示例：如果需要模型以特定格式（如列表、表格、JSON）回答，在指令中给出一个清晰的例子。
• 迭代测试：针对一些边界问题（如上下文不包含答案、问题模糊），反复测试并调整提示词，直到模型行为符合预期。

3. 相似度阈值调整：在检索和语义缓存中，都有一个相似度阈值。阈值太高（如 0.98），可能导致很多相关问题检索不到（漏召）；阈值太低（如 0.7），可能引入大量不相关的噪声（精度下降）。需要通过验证集，绘制“精度-召回率”曲线，找到一个业务上可接受的平衡点。

6.3 安全与生产化考量

当你想把这个原型推向真正的生产环境时，有几个关键点必须考虑：

• 身份认证与授权：示例应用可能没有复杂的身份验证。生产环境需要集成 Azure AD 或其他身份提供商，确保只有授权用户能访问聊天界面和底层数据。
• 输入输出过滤与审查：在将用户输入发送给 LLM 前，以及将模型输出返回给用户前，应进行内容安全过滤，防止提示词注入攻击或生成不当内容。Azure OpenAI 服务本身提供内容过滤功能，可以在调用时开启。
• 数据加密与合规：确保 Cosmos DB 和存储账户使用客户托管密钥（CMK）进行静态加密。审查数据流，确保符合 GDPR、HIPAA 等合规要求（如果适用）。敏感数据不应直接用于生成嵌入。
• 可观测性与监控：除了 Azure 自带的监控，应在应用中关键节点（检索、LLM 调用、缓存命中）添加详细的日志和指标（如延迟、token 用量、缓存命中率）。使用 Application Insights 进行全链路跟踪，便于故障排查和性能分析。
• 容错与重试：对 Azure OpenAI API 和 Cosmos DB 的调用必须添加重试逻辑（使用指数退避策略）和断路器模式，处理暂时的网络故障或服务限流。

这个项目提供了一个强大的、企业级的 RAG 应用蓝图。从快速原型到稳定生产，中间需要你在性能、成本、安全性和效果上不断打磨。希望我的这些经验分享，能帮你避开一些坑，更快地构建出属于自己的智能知识助手。