RAG 系统的工程化实践：从原型到生产级架构的完整路线图

检索增强生成（RAG）已成为企业落地大模型应用的主流技术路径。但从 Demo 到生产环境之间存在巨大鸿沟。本文基于 Wise2C 为多个金融和制造业客户实施 RAG 系统的实战经验，详细拆解核心工程问题。

文档预处理流水线

企业知识库的文档格式五花八门——PDF、Word、Excel、扫描件图片、内部 Wiki 页面。一个健壮的 RAG 系统首先需要一条可靠的文档预处理流水线：

• PDF 解析——对于文本型 PDF 使用 pdfplumber/PyMuPDF 提取文本和表格；对于扫描型 PDF 先进行 OCR（PaddleOCR/Tesseract），再结合版面分析模型（LayoutLMv3）识别段落、表格、图片区域。
• 文本切片（Chunking）——切片策略直接影响检索质量。Wise2C 采用「语义感知切片」——基于句子 Embedding 的相似度计算自然语义边界，而非简单按固定长度切分。每个 Chunk 保留其来源文档的标题层级和上下文窗口（前后各 2 句），作为元数据一并存入向量库。
• 增量更新——生产环境中文档持续更新。通过计算文档 Hash 值检测变更，仅对变更文档重新处理和向量化，避免全量重建索引。

混合检索架构

单纯的向量检索（Dense Retrieval）在处理精确关键词匹配时表现不佳；而稀疏检索（BM25）无法理解语义相似性。Wise2C 的 RAG 方案采用三路混合检索：

• 稠密向量检索——使用 BGE-M3 或 GTE-Large 等 Embedding 模型将 Chunk 向量化，存入 Milvus 向量数据库，支持 HNSW 索引实现毫秒级 ANN 检索。
• 稀疏 BM25 检索——同步将文本存入 Elasticsearch，利用 BM25 算法处理精确关键词、专有名词、编号等查询。
• 知识图谱检索——对于结构化强的领域知识（如法规条款之间的引用关系、产品零件的上下游关系），构建 Neo4j 知识图谱，通过图查询补充向量检索难以捕获的关系型知识。

三路召回结果通过 Reciprocal Rank Fusion（RRF）算法融合排序后，送入 Reranker 精排模型（bge-reranker-v2-m3）进行二次排序，最终取 Top-K 作为 LLM 的上下文输入。

性能基准测试

在某金融客户的 500 万文档知识库上的测试结果：

• 端到端检索延迟（Query → Top-10 Chunks）：P95 = 180ms
• 混合检索相比纯向量检索，Recall@10 提升 23%
• 加入 Reranker 后，NDCG@5 提升 18%
• 最终 RAG 回答准确率（人工评估）：91.3%（纯 LLM 无 RAG 为 67.8%）

Kubernetes 弹性部署

整个 RAG 系统拆分为 Embedding Service、Vector DB、BM25 Engine、Reranker Service、LLM Gateway 五个独立组件，均部署在 Kubernetes 上，通过 HPA 独立弹性伸缩。文档摄入高峰期（如每周一批量更新），Embedding Service 自动扩容；业务查询高峰期（如工作日上午），Reranker 和 LLM Gateway 自动扩容。