专栏第12篇：前面三篇文章分别讲了RAG的离线阶段（文档处理）、在线阶段（混合检索与重排序）和评估优化。但在真实的企业环境中，RAG不是一段Jupyter Notebook脚本，而是一个需要处理并发请求、支持知识库热更新、保证低延迟、还要能流式输出的完整系统。这篇文章把我搞建企业级RAG系统的架构设计、核心模块和踩坑经验分享出来。
目录
- 一、从Demo到生产：RAG系统面临的真实挑战
- 二、系统架构全景
- 三、查询层：不只是"把问题丢给检索器"
- 四、检索层：双引擎混合召回的工程实现
- 五、生成层：检索与生成的职责分离
- 六、流式输出：SSE与用户体验
- 七、知识库热更新：不停机更新
- 八、踩过的5个坑
- 九、总结
一、从Demo到生产：RAG系统面临的真实挑战
很多教程里的RAG是这样的：加载几个PDF，建个向量库，用户提问时检索一下，把结果塞给LLM。这在笔记本上跑通没问题，但放到生产环境会暴露出各种问题。
| 维度 | Demo级RAG | 企业级RAG |
|---|---|---|
| 并发 | 单用户串行 | 多用户同时请求 |
| 知识更新 | 手动重新建索引 | 自动热更新、不停机 |
| 延迟 | 几秒钟可接受 | 首字延迟要控制在1秒内 |
| 输出 | 一次性返回 | 流式输出、实时渲染 |
| 容错 | 出错就报错 | 优雅降级、超时保护 |
| 来源追溯 | 可有可无 | 必须准确、可点击 |
