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

做过三家制造企业的内部知识库RAG项目最深的感受是绝大多数企业级RAG的难点从来不是算法本身而是「能不能安全落地、能不能和现有系统打通、能不能真的用起来」。很多方案一上来就是Python全家桶对接云端大模型演示效果很惊艳一到落地全是问题核心文档不能出内网、和现有.NET业务系统集成要重做一层、运维团队根本不会维护Python环境最后活生生做成了演示玩具。今天这套方案完全基于.NET原生技术栈用Semantic Kernel做智能编排向量数据库做语义检索支持云端大模型和本地离线大模型无缝切换从文档解析、向量化、检索到生成全链路用C#实现是我们在多个内网项目里踩坑磨出来的成熟方案。一、别上来就堆框架企业级RAG的核心诉求个人玩RAG和企业落地RAG完全是两回事。个人追求的是效果新奇企业追求的是稳定、安全、可控。绝大多数企业做RAG核心诉求就四个数据安全内部文档、工艺标准、客户资料绝对不能流出企业内网不能调用公网大模型传原文无缝集成能直接嵌进现有的OA、MES、知识库系统不用额外搭一套独立服务效果可控不能胡说八道答案必须有原文依据可追溯、可校验运维简单符合现有技术栈.NET团队就能维护不需要专门养Python开发这也是为什么我们最终选了Semantic Kernel这套路线——微软原生.NET生态和ASP.NET Core、依赖注入、日志监控体系天然契合企业落地的摩擦成本最低。二、整体架构四层结构全链路可控一套标准的企业级RAG系统分为清晰的四层架构每一层职责单一可独立替换、独立扩容。基础能力层向量存储与检索层智能编排层 Semantic Kernel业务应用层企业知识库前端OA/ERP系统集成移动端问答入口提问意图识别检索策略编排提示词管理大模型调用管理文档分块处理向量化引擎向量数据库混合检索引擎大模型服务云端/本地可选文档解析组件权限与审计智能编排层这套架构最大的优势是灵活大模型可插拔初期可以用云端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.SqliteSQLite向量存储连接器PdfPigNPOIPDF、Office文档原生解析无Python依赖大模型连接器根据选型安装对应包比如Azure OpenAI、通义千问SDK4.2 文档处理流水线文档处理是RAG的地基这一步做不好后面检索再怎么优化都没用。原始文档PDF/Word/Excel文本解析提取文本清洗去页眉页脚/去乱码语义分块带重叠窗口生成Embedding向量写入向量数据库核心分块策略不要用固定长度硬切优先按文档标题、段落结构切分每块控制在500-800中文字符块之间保留10%-15%的重叠内容避免信息断裂。4.3 接入 Semantic Kernel 内核核心配置代码非常简洁几行就能完成内核初始化varbuilderWebApplication.CreateBuilder(args);// 注册 Semantic Kernel 内核builder.Services.AddKernel();builder.Services.AddScopedIKernel(sp{varkernelKernel.CreateBuilder()// 接入大模型可切换云端/本地.AddQwenChatCompletion(modelName:qwen2-7b-instruct,apiKey:builder.Configuration[Qwen:ApiKey])// 接入向量存储.AddSqliteVectorStore(Data Sourcerag.db).Build();returnkernel;});如果是纯离线场景把大模型部分替换成本地LlamaSharp服务即可上层业务代码完全不用改。4.4 检索增强生成核心流程用户提问后的完整处理链路是RAG的核心用户提问问题向量化向量库TopN检索相关性重排序拼装提示词模板大模型生成答案返回答案引用来源核心实现代码publicasyncTaskRagAnswerAskAsync(stringquestion){// 1. 从向量库检索相关片段varcollection_vectorStore.GetCollectionstring,TextChunk(knowledge_base);varsearchResultsawaitcollection.VectorizedSearchAsync(question,newVectorSearchOptions{Top5,ScoreThreshold0.7f});varrelevantChunksnewListstring();awaitforeach(varresultinsearchResults.Results){relevantChunks.Add(result.VectorRecord.Text);}// 2. 拼装提示词强制基于原文回答varprompt$请仅基于以下参考资料回答用户问题如果资料中没有答案请回答资料不足无法回答。 参考资料{string.Join(\n---\n,relevantChunks)}用户问题{question};// 3. 调用大模型生成答案varanswerawait_kernel.InvokePromptAsyncstring(prompt);// 4. 返回答案和引用来源方便溯源returnnewRagAnswer{Answeranswer,ReferencesrelevantChunks};}这一步最关键的是提示词约束必须强制模型「基于给定资料回答不知道就说不知道」从根源减少胡说八道的概率。五、企业级优化从「能用」到「好用」基础版跑通很容易但要达到企业可用的标准还有大量细节要优化。5.1 检索效果优化这是决定RAG好不好用的核心80%的答非所问都是检索没找对资料。混合检索不要只用向量相似度检索加上BM25关键词检索两者结果融合召回。专业术语、编号类内容关键词检索效果远好于向量检索重排序召回Top20后用轻量Rerank模型做二次排序选出最相关的Top5准确率能提升30%以上分块分层大文档做「摘要块详情块」两级结构先检索摘要再定位到具体详情块大幅提升长文档召回准确率5.2 工程化能力补齐企业级系统稳定大于一切。结果缓存相同问题直接走缓存减少大模型调用提升响应速度批量入库幂等同一文档重复上传不会重复向量化按文件哈希去重异常重试大模型调用、向量库操作都要加重试和熔断机制避免偶发故障影响业务审计日志每一次提问、检索到的片段、生成的答案都要留痕方便后续排查和优化5.3 权限与安全企业内部文档不是所有人都能看全部内容。文档级权限向量化时带上部门、权限标签检索时自动过滤当前用户无权查看的文档数据脱敏入库前自动识别并脱敏身份证、手机号、合同金额等敏感信息离线部署全组件本地化部署不用公网接口数据全程不出内网满足等保合规要求六、踩坑实录那些让项目延期的坑1. 分块大小拍脑袋很多人上来就按1024字符切块中文场景完全不适用。中文信息密度高500-800字符的分块检索和生成效果最优块太大冗余信息多块太小上下文断裂都不行。2. Embedding和大模型不匹配用通用领域的Embedding模型去检索工业、法律这类垂直领域文档召回率会非常低。垂直场景一定要用对应领域微调过的Embedding模型或者用和大模型同系列的向量模型。3. 纯向量检索的幻觉只靠向量相似度检索经常会召回语义相近但完全不相关的内容。一定要加关键词检索做兜底混合检索是企业级RAG的标配没有例外。4. 本地大模型上下文溢出用7B本地小模型的时候不要一下塞太多检索片段。4k上下文窗口扣除提示词和回答空间实际能塞的资料很有限。要么做上下文压缩要么控制检索片段数量。5. 忽略了运营环节RAG不是上线就完事了文档更新、分块优化、 bad case 迭代都需要专人运营。很多项目上线就没人管文档过期、答案不准最后慢慢就没人用了。七、最后说几句现在很多人一谈RAG就说Python、LangChain、各种前沿技术好像.NET生态做不了一样。其实落地到企业场景Semantic Kernel .NET 原生组件的组合已经足够支撑绝大多数企业级知识库场景。它的优势从来不是技术最前沿而是最贴合企业现有技术栈、最低的落地和维护成本、最高的可控性。对于已经有.NET技术积累的企业不用为了做RAG专门招Python团队不用冒数据出内网的风险就能把智能问答能力落地到业务系统里。技术选型从来不是选最火的而是选最适合的。能稳定解决业务问题、能安全落地、能长期维护的方案就是最好的方案。