当 RAG 系统从原型走向生产环境，将所有功能塞进一个单体应用会迅速暴露问题：不同模块的计算资源需求差异巨大，更新频率各不相同，故障隔离也难以保证。将系统按职责拆分为独立的微服务，是保证可维护性、可扩展性和可靠性的重要一步。
一个典型的 RAG 系统可以拆分为四个核心服务：文档处理服务、检索服务、问答服务和管理服务。它们各自聚焦单一职责，通过 API 或消息队列协作。
1. 文档处理服务
职责：负责知识资产的持续摄入与预处理，是知识库的“入口”。
- 接收原始文档（PDF、Word、网页、Markdown 等），进行格式解析和文本提取。
- 按预设策略将文本切分为合适大小的 chunk，并生成每条 chunk 的向量嵌入。
- 将 chunk 文本、向量以及元数据（来源文件名、章节、更新时间等）写入向量数据库。
- 处理文档的更新与删除：当业务方上传新版本政策、产品手册时，该服务负责识别变更、重新切片向量化，并替换旧记录。
设计要点：
- 异步处理：文档上传、解析、向量化都是计算密集型任务，不应阻塞其他流程。通常采用消息队列（如 RabbitMQ、Kafka）将上传事件与处理逻辑解耦，前端上传后立即返回“处理中”状态，处理完成后再通知。
- 容错与重试：对于解析失败的文档，服务应记录异常并提供重试机制，避免因个别文档损坏导致整个流程中断。
- 可横向扩展：当企业一次性上传海量历史文档时，可通过增加 Worker 实例加速处理。嵌入模型调用若使用本地部署的服务，也需要考虑 GPU 资源的独立调配。
常用技术选型：文本提取可使用 Apache Tika、Unstructured 等工具；嵌入模型调用封装为独立模块；向量数据库写入 SDK（如 Milvus、Pinecone、Weaviate 客户端）。
2. 检索服务
职责：根据用户问题快速召回最相关的文档片段，是系统响应速度的核心瓶颈。
- 接收标准化后的查询文本（通常已由上游做过去除无关词等轻量清洗），调用嵌入模型将其转为向量。
- 向向量数据库发起相似度搜索，并应用业务过滤条件（如只检索特定产品线的文档、排除过期文档）。
- 可选地执行混合检索：结合关键词匹配（BM25）与向量相似度，平衡召回的字面准确性和语义覆盖度。
- 对召回结果进行简单的后处理，如按相关性分数截断、去重、重组上下文顺序。
- 返回 Top-K 个文本片段及其元数据给问答服务。
设计要点：
- 低延迟：检索是用户提问响应的主要耗时环节，服务应保持轻量，尽量做到 P99 延迟在百毫秒级别。这要求向量数据库选择合理、索引优化良好。
- 无状态：检索服务本身不存储任何业务数据，便于水平扩展。当并发量增加时，直接增加实例数量，负载均衡器自动分发。
- 缓存策略：对于高频重复问题（例如“如何重置密码？”），可在检索服务前增加一层精确匹配缓存，直接将问题哈希映射到缓存的检索结果，进一步降低延迟和资源消耗。
常用技术选型：嵌入模型调用、向量数据库查询客户端；混合检索可使用 Elasticsearch + 向量插件，或原生支持混合搜索的数据库如 Weaviate、Qdrant。
3. 问答服务
职责：将检索到的上下文与用户问题组装成提示词，调用 LLM 生成最终回答，是系统的“出口”。
- 接收用户原始问题和检索服务返回的文档片段列表。
- 根据场景拼装提示词模板，明确指令（如“你是内部知识库助手”“用中文回答”“引用出处”等），插入上下文内容。
- 调用大语言模型生成答案，并处理流式输出、超时、异常情况。
- 对生成的答案做后处理，例如提取引用标记、格式化为 Markdown 或富文本、滤除不安全内容。
- 记录完整交互日志（问题、检索结果、最终回答、用户反馈）用于后续分析和优化。
设计要点：
- 解耦 LLM 提供方：将模型调用封装为统一接口（如适配层），支持轻松切换 OpenAI、本地部署模型或不同供应商，避免与单一服务商深度绑定。
- 流式响应：为提升用户体验，问答服务应将 LLM 的流式输出逐字或逐句推送给前端，而不是等待完整生成。这要求服务本身支持异步流式传输（如 WebSocket 或 SSE）。
- 安全与护栏：对输出内容进行敏感词过滤、越狱攻击检测等，防止生成不合规内容。同时，对 LLM 请求做速率限制和计费追踪。
- 降级策略：当 LLM 不可用或超时时，可回退为直接返回检索片段列表，供用户自行查阅，保证基本可用性。
常用技术选型：LangChain、LlamaIndex 等编排框架（或在生产环境中自行实现的轻量版）；LangFuse、MLflow 等用于追踪与监控。
4. 管理服务
职责：提供面向运维人员、业务管理员的操作界面与管控能力，是系统的“控制台”。
- 知识库管理：查看已索引文档列表、状态、最后更新时间；手动触发索引重建或删除；管理文档的元数据标签（如分类、有效期限）。
- 配置管理：调整分块参数、检索 Top-K 值、提示词模板等系统参数，并支持多环境配置。
- 监控与告警：展示各服务健康状态、检索延迟、LLM 调用量、错误率等关键指标，设置阈值报警。
- 用户反馈审核：收集用户对回答的“有用/无用”评价及修正建议，标记低质量回答供改进。
- 权限与审计：管理后台用户角色（管理员、普通运营），记录所有配置变更和敏感操作日志。
- 简单分析看板：高频问题统计、检索词云、知识库覆盖率等基础分析，帮助业务方了解系统使用情况。
设计要点：
- 独立部署：管理服务是纯后台能力，前端可单独部署为内部管理台。它不应影响用户侧的核心问答链路，即使管理服务宕机，检索和问答仍应正常工作。
- 安全性：管理服务暴露的 API 必须鉴权，通常接入企业统一登录体系（SSO），并采用 RBAC 控制操作权限。
- 异步任务管理：对于重建索引等耗时操作，管理服务应通过消息队列下发任务给文档处理服务，自身只负责展示任务状态。
常用技术选型：前端使用 Vue/React + 组件库快速搭建；后端轻量级框架（如 FastAPI、Spring Boot）；任务调度可集成 Celery 或直接使用队列。
拆分带来的工程价值
- 独立扩缩容：检索服务承载高并发的用户请求，问答服务需要等待 LLM 的长耗时，两者资源需求不同，拆分后可以各自按需扩展。
- 故障隔离：文档处理服务宕机不影响用户提问；检索服务若挂掉，问答服务无法工作，但管理平台仍可访问，便于排查问题。
- 团队分工清晰：不同服务可由不同开发小组独立维护、部署，迭代速度更快。
- 技术选型自由：各服务可以根据需要选择最合适的语言、框架，而不必统一为一种技术栈。
微服务化的本质不是追求架构的时髦，而是为不同工作负载找到最合理的边界。文档处理、检索、生成、管理四个领域的计算特性、可用性需求、变更频率差异显著，自然形成服务边界。这一拆分让 RAG 系统从“跑得通”走向“能大规模、稳定可靠地承载业务”。