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

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

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

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

一、总体架构

text 复制代码

浏览器 / 企业门户
        ↓ HTTPS
Nginx / API Gateway
        ↓
FastAPI 应用服务
  ├── 用户、团队、权限
  ├── 知识库与文档 API
  ├── RAG 问答与 SSE
  └── 任务状态
        ├── PostgreSQL：业务事实
        ├── Redis：缓存、会话、限流
        ├── MinIO/S3：原始文件
        ├── Milvus/pgvector：向量检索
        └── RabbitMQ/Kafka：异步任务
                ↓
        解析、OCR、Embedding、索引 Worker

二、核心数据流

入库

text 复制代码

上传 → 对象存储 → 文档版本 → 消息队列
→ 解析/OCR → Chunk → Embedding → 向量索引 → 发布

问答

text 复制代码

问题 → 鉴权 → 查询改写 → 检索 → 过滤/重排

问答链路还应把 `trace_id`、`run_id`、知识库 `serving_version`、模型版本和权限版本贯穿到底。答案中的每条引用都由服务端根据 `chunk_id` 回查生成，不能由模型自己拼出文档链接。
→ Prompt → LLM → 引用回查 → SSE 返回

三、组件如何选择？

能力	轻量方案	生产扩展方案
业务数据库	PostgreSQL	托管 PostgreSQL / 集群
向量检索	pgvector	Milvus
原始文件	MinIO	S3 / OSS / 高可用 MinIO
缓存	Redis	Redis 高可用或托管版
异步任务	Redis Stream	RabbitMQ / Kafka
API	FastAPI	FastAPI + Gateway + 多副本
部署	Docker Compose	Kubernetes / 托管容器
观测	日志和指标	OpenTelemetry + Langfuse + Prometheus

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

四、租户和权限设计

每条文档至少关联：

text 复制代码

tenant_id
team_id
knowledge_base_id
document_id
version
visibility

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

五、异步任务设计

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

text 复制代码

queued → parsing → chunking → embedding → indexing → ready

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

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

六、问答体验设计

前端应展示：

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

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

七、质量和安全门槛

上线前至少建立：

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

八、分阶段落地

阶段一：验证闭环

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

阶段二：工程化

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

阶段三：规模化

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

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

结语

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

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

参考资料

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