从零搭建一个企业文档问答系统：总体架构与技术选型

码海寻道 · 大模型、智能体与 RAG 工程组件系列第 55 篇

企业文档问答系统不是“上传文件加一个聊天框”。它需要处理文档版本、权限、异步解析、向量检索、引用、监控、成本和安全。本篇先给出一套完整架构，再说明如何按阶段落地。

一、总体架构

浏览器 / 企业门户        ↓ HTTPSNginx / 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 返回

三、组件如何选择？

先使用最小可行组件跑通业务闭环，再根据规模和瓶颈拆分。

四、租户和权限设计

每条文档至少关联：

tenant_idteam_idknowledge_base_iddocument_idversionvisibility

检索时由服务端计算可访问范围，向 PostgreSQL 和向量库传入可信过滤条件。引用和文件下载还要再次进行权限检查。

五、异步任务设计

上传接口返回 document_id 和 job_id，任务状态分为：

queued → parsing → chunking → embedding → indexing → ready

每个阶段记录进度、错误和重试次数。ready 只能在向量可搜索、元数据完整和发布状态切换后设置。

任务执行应支持至少一次投递下的幂等、租约超时和人工重试。上传成功、解析成功、索引成功和发布成功是不同事实；任何一步失败都要能从对应阶段恢复，而不是重新上传或静默覆盖旧版本。

六、问答体验设计

前端应展示：

• • 正在检索；
• • 正在生成；
• • 引用来源；
• • 取消按钮；
• • 失败和重试；
• • 对话历史。

SSE 只负责传输过程，最终答案和引用仍然要持久化，便于断线恢复、审计和反馈。

七、质量和安全门槛

上线前至少建立：

• • 代表性问题集；
• • Recall@K、忠实度和引用命中率；
• • P95 延迟和 Token 成本；
• • 越权、提示词注入和敏感信息测试；
• • 文档删除和版本切换测试；
• • 模型和索引升级回滚方案。
• • 质量评测集和发布门禁；
• • 备份恢复、租户删除和敏感数据清理演练；
• • 断线重连、取消、重复提交和下游超时测试。

八、分阶段落地

阶段一：验证闭环

PostgreSQL + pgvector + FastAPI + 本地对象存储，验证解析、切分、检索和回答。

阶段二：工程化

加入 Redis、异步队列、SSE、任务状态、权限和引用。

阶段三：规模化

按真实指标拆分 API、Worker、检索和模型调用，增加高可用、灰度发布、成本预算、观测平台和灾备演练。不要在没有容量数据前盲目引入 Kubernetes 或多个专用中间件。

根据压测决定 Milvus、独立 Worker、Gateway、Kubernetes 和完整观测。

下面是ai交流群，可以分享或者交流一些ai相关技术，感兴趣的可以加入：

结语

企业文档问答系统的核心不是某个单独组件，而是把文件、业务数据、向量检索、异步任务、权限、回答和观测连成一条可恢复链路。先建立清晰边界，再根据真实指标扩展。

下一篇将开始轻量 RAG 实战：PostgreSQL、pgvector 和 FastAPI 如何组合。

参考资料

1. 1. FastAPI 官方文档
2. 2. pgvector 官方项目
3. 3. Milvus 官方文档

本文为“码海寻道”原创技术文章。架构选型需要结合文档规模、租户数量、并发、合规和团队运维能力验证。