RAG + Semantic Kernel + Azure Cosmos DB MongoDB vCore：让大模型"读懂"你的数据库

背景：为什么需要一个专属知识库助手？

想象一个场景：你是某制造业企业的技术文档管理员，公司积累了近十年的产品规格书、技术手册和维修记录。当同事问"这个型号的主板保修期是多久"时，你需要翻阅几十份 PDF 才能找到答案。更让人头疼的是，如果问的是组合问题——"这个型号的主板在高温环境下稳定性如何"——普通搜索引擎往往无能为力。

大语言模型（LLM）擅长理解和生成自然语言，但它的知识有截止日期，且无法直接访问你公司的私有数据。检索增强生成（RAG） 正是解决这一问题的核心技术：让 LLM 在回答问题时，先从私有知识库中检索相关文档，再结合检索结果生成答案。

今天要介绍的项目——john0isaac/rag-semantic-kernel-mongodb-vcore，就是一个基于 RAG 架构的企业级知识库问答系统示例，它组合了微软 Semantic Kernel 框架、Azure OpenAI 强大语言模型和 Azure Cosmos DB MongoDB vCore 原生向量搜索能力。

技术选型：为什么是这三件套？

Semantic Kernel：微软的 AI 粘合剂

Semantic Kernel 是微软开源的 AI 应用开发框架，其核心作用是将传统业务代码与 AI 服务（LLM）连接起来。它提供了一种"插件化"的架构：你既可以让 LLM 直接回答问题，也可以给它挂载各种"技能"（Plugins/Skills）——比如连接向量数据库、执行外部 API、调用业务逻辑。Semantic Kernel 的设计理念是让 AI 能力可以像搭积木一样组合，而不是把所有逻辑都塞进 prompt 里。

相比 LangChain，Semantic Kernel 的优势在于与微软生态（Azure OpenAI、Azure Cognitive Services）深度集成，配置更简洁，代码更易维护。对于已经使用 Azure 服务的团队来说，Semantic Kernel 是更自然的选择。

Azure Cosmos DB MongoDB vCore：原生向量搜索的 NoSQL 数据库

Cosmos DB 是 Azure 的多模数据库服务，其 MongoDB vCore 版本在 2024 年引入了内置向量索引支持。这意味着你不需要额外的向量数据库（如 Pinecone/Milvus），直接在 MongoDB 中存储文档的向量 embedding，并执行相似度搜索。vCore 采用按容量计费模式，相比传统 RU（请求单元）计费更适合有稳定规模的企业场景。

Azure OpenAI：企业级 LLM 服务

Azure OpenAI 提供 GPT-4、GPT-4o 等业界领先大模型的托管服务，相比公共 ChatGPT API，它提供企业级 SLA、数据隐私保护（你的数据不会用于模型训练）和更灵活的部署选项（可以部署在特定区域）。

架构设计：数据流转的全链路

整个 RAG 系统的数据流转如下：

1. 文档上传：用户通过 add_data.py 脚本将文本数据上传到系统
2. 向量化：通过 Azure OpenAI 的 text-embedding-ada-002 模型，将文本转为 1536 维向量
3. 存储：向量 + 原始文本一同存入 Azure Cosmos DB MongoDB vCore
4. 索引：Cosmos DB vCore 基于 HNSW 算法建立向量索引（m=16, ef_construction=64, ef_search=40）
5. 查询：用户输入问题 → 问题同样被向量化 → 在 vCore 中执行向量相似度搜索
6. 增强生成：将 Top-K 相关文档作为上下文（context）注入 Semantic Kernel 的提示词模板
7. LLM 回答：Azure OpenAI GPT-4o-mini 结合上下文生成最终答案

核心代码：Quart + Semantic Kernel 的实现细节

Web 层：异步 ASGI 应用

项目使用 Quart（异步版 Flask）作为 Web 框架，部署在 Azure App Service 上。通过 Hypercorn ASGI 服务器运行。Web 层提供两个核心端点：/hello（健康检查）和 /chat（主对话接口）。系统支持两种查询模式——纯向量搜索（vector）和完整的 RAG 增强生成（rag）。

RAG 核心：Semantic Kernel 的内存插件

通过 Semantic Kernel 的 AzureCosmosDBMemoryStore 将 Cosmos DB vCore 作为持久化记忆存储，实现了向量检索和 LLM 生成的无缝衔接。系统使用 HNSW 算法构建向量索引，参数 m=16、ef_construction=64、ef_search=40，在检索精度和性能之间取得平衡。Embedding 维度固定为 1536（适配 text-embedding-ada-002 模型）。

部署体验：Azure Developer CLI 自动化

项目通过 Bicep IaC 模板完整定义了 Azure 资源拓扑，包括 Azure App Service、Azure Cosmos DB MongoDB vCore、Azure OpenAI、Azure Key Vault 和 App Service Plan。部署流程高度自动化：安装 azd CLI → 登录 → 初始化 → 配置环境变量 → azd up 一键部署所有资源。

关键依赖项：semantic-kernel、pymongo、quart、hypercorn、azure-identity、openai、azure-cosmos。

争议与局限

1. 无容器化支持：没有 Dockerfile 和 docker-compose，无法本地或 Kubernetes 环境一键部署，必须通过 azd CLI 部署到 Azure，限制了灵活性和成本优化空间
2. 深度绑定 Azure 生态：非 Azure 用户迁移成本高
3. 仅支持文本 RAG：不支持 PDF 解析、表格理解或多模态内容
4. Embedding 模型固定：向量维度硬编码为 1536，切换模型需修改代码
5. 缺乏离线部署选项：所有服务依赖 Azure 云端

行业意义

微软将 Semantic Kernel 定位为"企业 AI 应用开发的标准框架"，该项目是其 RAG 参考实现的优秀案例。随着 Azure Cosmos DB vCore 原生向量搜索的成熟，"数据库即向量库"正在成为云原生 AI 应用的新范式——开发者不再需要在 Postgres + pgvector、Pinecone、Milvus 等多个服务之间做权衡，而是可以在熟悉的 MongoDB 生态中统一处理事务存储和向量检索。GitHub Stars 的稳步增长和 Microsoft Tech Community 官方博客的背书，也印证了这类技术组合在企业 AI 落地方案中的广泛认可。