当前位置：首页 > news >正文

企业级 RAG 系统落地：C# + Semantic Kernel + 向量数据库完整方案

news 2026/7/5 12:51:27

做过三家制造企业的内部知识库RAG项目，最深的感受是：绝大多数企业级RAG的难点，从来不是算法本身，而是「能不能安全落地、能不能和现有系统打通、能不能真的用起来」。

很多方案一上来就是Python全家桶，对接云端大模型，演示效果很惊艳，一到落地全是问题：核心文档不能出内网、和现有.NET业务系统集成要重做一层、运维团队根本不会维护Python环境，最后活生生做成了演示玩具。

今天这套方案完全基于.NET原生技术栈：用Semantic Kernel做智能编排，向量数据库做语义检索，支持云端大模型和本地离线大模型无缝切换，从文档解析、向量化、检索到生成全链路用C#实现，是我们在多个内网项目里踩坑磨出来的成熟方案。

一、别上来就堆框架：企业级RAG的核心诉求

个人玩RAG和企业落地RAG，完全是两回事。个人追求的是效果新奇，企业追求的是稳定、安全、可控。

绝大多数企业做RAG，核心诉求就四个：

数据安全：内部文档、工艺标准、客户资料绝对不能流出企业内网，不能调用公网大模型传原文
无缝集成：能直接嵌进现有的OA、MES、知识库系统，不用额外搭一套独立服务
效果可控：不能胡说八道，答案必须有原文依据，可追溯、可校验
运维简单：符合现有技术栈，.NET团队就能维护，不需要专门养Python开发

这也是为什么我们最终选了Semantic Kernel这套路线——微软原生.NET生态，和ASP.NET Core、依赖注入、日志监控体系天然契合，企业落地的摩擦成本最低。

二、整体架构：四层结构，全链路可控

一套标准的企业级RAG系统，分为清晰的四层架构，每一层职责单一，可独立替换、独立扩容。

这套架构最大的优势是灵活：

大模型可插拔：初期可以用云端API，合规要求高了随时切本地大模型
向量库可升级：数据量小用SQLite就能跑，量大了无缝切Milvus/Qdrant
业务侧无感知：所有能力都以标准接口对外提供，现有系统直接对接

三、核心组件选型：不求最潮，求最稳

企业级选型，稳定优先于花哨，生态优先于性能。每个组件我们都对比过至少三个方案，最终选的都是.NET生态下最成熟、坑最少的。

3.1 编排框架：Semantic Kernel

微软官方推出的智能应用编排框架，原生.NET实现，和ASP.NET Core的依赖注入、配置、日志体系完全打通。

优势：原生支持插件化开发，内置内存、向量检索、函数调用能力，团队学习成本低
不选LangSharp的原因：社区驱动、版本迭代快，生产环境踩坑多，企业级支持不足

3.2 向量数据库：分场景选择

没有最好的向量库，只有最适合的：

数据量<10万条：直接用SQLite + 向量扩展，零额外部署，运维成本为零，适合中小规模内网知识库
数据量10万~千万级：用Qdrant，轻量高效，有官方.NET SDK，单机性能足够绝大多数企业使用
超大规模集群：上Milvus分布式集群，适合集团级多业务线共用场景

3.3 Embedding 与大模型

同样分云端和离线两种方案，可平滑切换：

云端方案：Embedding用通义千问、文心一言的文本向量接口，大模型用对应业务模型，接入简单、效果好
离线方案：Embedding用中文开源向量模型转GGUF格式，通过LlamaSharp本地加载；大模型用Qwen2、Llama 3等开源模型本地推理，数据全程不出内网

四、分步落地：从0到1跑通完整流程

4.1 环境准备

新建一个ASP.NET Core Web API项目，直接通过NuGet安装核心依赖：

Microsoft.SemanticKernel：核心编排框架
Microsoft.SemanticKernel.Connectors.Sqlite：SQLite向量存储连接器
PdfPig+NPOI：PDF、Office文档原生解析，无Python依赖
大模型连接器：根据选型安装对应包，比如Azure OpenAI、通义千问SDK

4.2 文档处理流水线

文档处理是RAG的地基，这一步做不好，后面检索再怎么优化都没用。

核心分块策略：不要用固定长度硬切，优先按文档标题、段落结构切分，每块控制在500-800中文字符，块之间保留10%-15%的重叠内容，避免信息断裂。

4.3 接入 Semantic Kernel 内核

核心配置代码非常简洁，几行就能完成内核初始化：

varbuilder=WebApplication.CreateBuilder(args);// 注册 Semantic Kernel 内核builder.Services.AddKernel();builder.Services.AddScoped<IKernel>(sp=>{varkernel=Kernel.CreateBuilder()// 接入大模型，可切换云端/本地.AddQwenChatCompletion(modelName:"qwen2-7b-instruct",apiKey:builder.Configuration["Qwen:ApiKey"])// 接入向量存储.AddSqliteVectorStore("Data Source=rag.db").Build();returnkernel;});

如果是纯离线场景，把大模型部分替换成本地LlamaSharp服务即可，上层业务代码完全不用改。

4.4 检索增强生成核心流程

用户提问后的完整处理链路，是RAG的核心：

核心实现代码：

publicasyncTask<RagAnswer>AskAsync(stringquestion){// 1. 从向量库检索相关片段varcollection=_vectorStore.GetCollection<string,TextChunk>("knowledge_base");varsearchResults=awaitcollection.VectorizedSearchAsync(question,newVectorSearchOptions{Top=5,ScoreThreshold=0.7f});varrelevantChunks=newList<string>();awaitforeach(varresultinsearchResults.Results){relevantChunks.Add(result.VectorRecord.Text);}// 2. 拼装提示词，强制基于原文回答varprompt=@$"请仅基于以下参考资料回答用户问题，如果资料中没有答案，请回答"资料不足，无法回答"。 参考资料：{string.Join("\n---\n",relevantChunks)}用户问题：{question}";// 3. 调用大模型生成答案varanswer=await_kernel.InvokePromptAsync<string>(prompt);// 4. 返回答案和引用来源，方便溯源returnnewRagAnswer{Answer=answer,References=relevantChunks};}