设计一个企业内部的知识库问答系统

深入系统设计场景题约 5 分钟读完

一句话回答

先澄清需求(数据规模、文档类型、更新频率、权限要求、准确率和延迟要求),再按数据接入 → 索引 → 检索 → 生成 → 评测与运营分层设计。重点讲清楚几个落地难点:检索准确率、文档权限、知识更新、可追溯的引用和成本控制。

详细解析

第一步:澄清需求

  • 数据:来源有哪些(Wiki、网盘文件、工单、聊天记录)?规模是几万篇还是几百万篇?
  • 更新:需要实时同步,还是每天同步一次就够?
  • 权限:不同部门、不同职级能看的文档是否不同?
  • 指标:可接受的回答延迟、对准确率的要求、预算

第二步:整体架构

文本
【离线】数据源(Wiki / 网盘 / 工单)→ 增量同步 → 解析清洗 → 切块 → Embedding
       → 写入向量库和全文索引(元数据:来源、权限、更新时间)

【在线】用户提问 → 鉴权 → 问题改写 → 混合检索(按权限过滤)→ 重排
       → 模型生成(附引用)→ 返回答案 → 记录日志和用户反馈

各环节的细节见 RAG 的完整链路,检索部分见混合检索和重排序。

第三步:核心数据模型

文档和分块分两张表,向量库里的每个向量带上同样的元数据:

SQL
CREATE TABLE documents (
  id           BIGINT PRIMARY KEY,
  source       VARCHAR(32) NOT NULL,   -- wiki / drive / ticket
  source_id    VARCHAR(128) NOT NULL,  -- 源系统里的 ID,增量同步靠它对应
  title        VARCHAR(500),
  content_hash CHAR(64) NOT NULL,      -- 内容没变就不重新切块、不重新向量化
  acl_groups   JSON NOT NULL,          -- 允许访问的用户组,从源系统同步
  updated_at   DATETIME NOT NULL,
  deleted_at   DATETIME,               -- 源文档删除后标记,并删除对应的向量
  UNIQUE KEY uk_source (source, source_id)
);

CREATE TABLE chunks (
  id           BIGINT PRIMARY KEY,
  document_id  BIGINT NOT NULL,
  seq          INT NOT NULL,
  heading_path VARCHAR(500),           -- 所属章节,引用时展示
  content      TEXT NOT NULL,
  INDEX idx_doc (document_id, seq)
);
  • 向量的元数据里带上 document_id、acl_groups 和更新时间,检索时以"acl_groups 和当前用户所在的组有交集"作为过滤条件
  • 权限记在用户组上,而不是记用户 ID:员工调岗只需要改他属于哪些组,索引不用动

第四步:关键设计点

问题 方案
权限 同步文档时带上访问权限,检索时按用户身份过滤;权限变更要及时同步
知识更新 增量同步,用文档 ID 和内容哈希判断是否需要重新索引;源文档删除后同步删除对应的向量
准确率 混合检索 + 重排;回答必须附引用;检索不到就说不知道,不要编造
延迟 流式输出;高频问题做缓存;检索、重排链路做并行和超时控制
成本 简单问题用小模型、复杂问题用大模型(模型路由);利用提示词缓存
评测 建评测集做离线回归;线上收集点赞、点踩,定期分析答错的案例

第五步:扩展与优化(可以主动提的加分项)

  • 多轮对话:结合历史改写问题,比如把"那它多少钱?"改写成"X 产品多少钱?"
  • 结构化数据:报表、数据库里的数据走 Text-to-SQL,而不是硬塞进向量库
  • 安全:对回答做敏感信息检测;防范文档里夹带的间接提示注入

面试官可能追问

用户反馈"答案不对",你怎么排查?

先看日志里这次的检索结果:

  • 正确的文档没被检索到 → 检查解析、切块和检索策略
  • 检索到了但排名靠后,没进上下文 → 优化重排
  • 检索到了、也进了上下文,但模型答错 → 优化提示词或换模型

完整的排查方法见 RAG 效果不好怎么排查。

文档从 1 万篇涨到 1000 万篇,哪里会成为瓶颈?
  • 索引构建:Embedding 的吞吐和成本,需要批量处理、限流和失败重试
  • 向量检索:内存占用和查询延迟,需要分片、使用 HNSW 等近似最近邻索引、做向量量化
  • 增量同步:变更检测和任务调度的压力
怎么防止员工通过问答拿到无权查看的信息?

根本措施是在检索层按权限过滤,让无权查看的内容根本进不了上下文。另外要防范文档中夹带的提示注入,对输出做敏感信息检测,并保留审计日志。

文档的权限变了,怎么让检索结果及时生效?

权限变化只改元数据,不需要重新向量化:监听源系统的权限变更事件(或者定时比对),更新文档和对应向量的 acl_groups。用户属于哪些组,在查询时从统一身份系统实时获取,调岗、离职马上生效。再定期做一次全量核对,修正漏掉的变更。特别敏感的文档,可以在检索之后再调用源系统的权限接口复核一次。

易错点

  • 系统设计题不要一上来就画架构图,先澄清需求和约束
  • 不要只说"向量库 + 大模型",面试官更想听权限、更新、评测这些落地细节

AI 模拟面试官

用自己的话回答,AI 对照参考答案打分、指出遗漏,再追问,最多 3 轮

登录后就可以和 AI 面试官对练,面试记录也会保存下来。登录

这道题你掌握了吗?

选一个最接近的状态,没掌握的题会出现在"我的进度 · 待复习"里。

学习记录暂存在本机浏览器。登录后自动同步到账号,换设备也能看到。