从零搭建一个企业文档问答系统总体架构与技术选型码海寻道 · 大模型、智能体与 RAG 工程组件系列第 55 篇企业文档问答系统不是“上传文件加一个聊天框”。它需要处理文档版本、权限、异步解析、向量检索、引用、监控、成本和安全。本篇先给出一套完整架构再说明如何按阶段落地。一、总体架构浏览器 / 企业门户 ↓ HTTPS Nginx / API Gateway ↓ FastAPI 应用服务 ├── 用户、团队、权限 ├── 知识库与文档 API ├── RAG 问答与 SSE └── 任务状态 ├── PostgreSQL业务事实 ├── Redis缓存、会话、限流 ├── MinIO/S3原始文件 ├── Milvus/pgvector向量检索 └── RabbitMQ/Kafka异步任务 ↓ 解析、OCR、Embedding、索引 Worker二、核心数据流入库上传 → 对象存储 → 文档版本 → 消息队列 → 解析/OCR → Chunk → Embedding → 向量索引 → 发布问答问题 → 鉴权 → 查询改写 → 检索 → 过滤/重排 问答链路还应把 trace_id、run_id、知识库 serving_version、模型版本和权限版本贯穿到底。答案中的每条引用都由服务端根据 chunk_id 回查生成不能由模型自己拼出文档链接。 → Prompt → LLM → 引用回查 → SSE 返回三、组件如何选择能力轻量方案生产扩展方案业务数据库PostgreSQL托管 PostgreSQL / 集群向量检索pgvectorMilvus原始文件MinIOS3 / OSS / 高可用 MinIO缓存RedisRedis 高可用或托管版异步任务Redis StreamRabbitMQ / KafkaAPIFastAPIFastAPI Gateway 多副本部署Docker ComposeKubernetes / 托管容器观测日志和指标OpenTelemetry Langfuse Prometheus先使用最小可行组件跑通业务闭环再根据规模和瓶颈拆分。四、租户和权限设计每条文档至少关联tenant_id team_id knowledge_base_id document_id version visibility检索时由服务端计算可访问范围向 PostgreSQL 和向量库传入可信过滤条件。引用和文件下载还要再次进行权限检查。五、异步任务设计上传接口返回document_id和job_id任务状态分为queued → parsing → chunking → embedding → indexing → ready每个阶段记录进度、错误和重试次数。ready只能在向量可搜索、元数据完整和发布状态切换后设置。任务执行应支持至少一次投递下的幂等、租约超时和人工重试。上传成功、解析成功、索引成功和发布成功是不同事实任何一步失败都要能从对应阶段恢复而不是重新上传或静默覆盖旧版本。六、问答体验设计前端应展示正在检索正在生成引用来源取消按钮失败和重试对话历史。SSE 只负责传输过程最终答案和引用仍然要持久化便于断线恢复、审计和反馈。七、质量和安全门槛上线前至少建立代表性问题集RecallK、忠实度和引用命中率P95 延迟和 Token 成本越权、提示词注入和敏感信息测试文档删除和版本切换测试模型和索引升级回滚方案。质量评测集和发布门禁备份恢复、租户删除和敏感数据清理演练断线重连、取消、重复提交和下游超时测试。八、分阶段落地阶段一验证闭环PostgreSQL pgvector FastAPI 本地对象存储验证解析、切分、检索和回答。阶段二工程化加入 Redis、异步队列、SSE、任务状态、权限和引用。阶段三规模化按真实指标拆分 API、Worker、检索和模型调用增加高可用、灰度发布、成本预算、观测平台和灾备演练。不要在没有容量数据前盲目引入 Kubernetes 或多个专用中间件。根据压测决定 Milvus、独立 Worker、Gateway、Kubernetes 和完整观测。结语企业文档问答系统的核心不是某个单独组件而是把文件、业务数据、向量检索、异步任务、权限、回答和观测连成一条可恢复链路。先建立清晰边界再根据真实指标扩展。下一篇将开始轻量 RAG 实战PostgreSQL、pgvector 和 FastAPI 如何组合。参考资料FastAPI 官方文档pgvector 官方项目Milvus 官方文档本文为“码海寻道”原创技术文章。架构选型需要结合文档规模、租户数量、并发、合规和团队运维能力验证。