企业知识库问答是 RAG 落地最多的场景也是最容易做出「演示惊艳、上线翻车」的场景。这篇把架构分层讲清楚再列三个最容易踩的坑——都是真实项目里花真金白银换来的。五层架构第一层是数据接入。文档来源越杂这一层越重要PDF、Word、在线文档、网页、数据库各有各的解析坑。经验是统一汇成中间格式再处理解析质量直接决定上限。第二层是切分与索引。按文档结构切块保留标题层级作为元数据块之间留重叠向量索引之外保留一份原文索引BM25混合检索是标配。第三层是检索服务。向量检索加关键词检索双路召回合并后过重排序模型取头部几条进上下文。这一层要做用户权限过滤——知识库问答翻车重灾区就是 A 部门的敏感表被 B 部门问出来了。第四层是生成服务。提示词里明确仅依据资料回答、注明出处、不知道就说不知道回答附带引用列表。第五层是评估与反馈。固定评测集问题、标准答案要点持续跑分线上加用户反馈按钮负反馈自动进入待优化清单。踩坑一PDF 解析的暗坑企业文档半数以上是 PDF而 PDF 解析是重灾区表格被打散成乱序文本、双栏排版读串行、扫描件是图片无法直接抽取。解法是用专业解析服务处理复杂版式表格单独走表格抽取逻辑扫描件上 OCR。宁可在这层花重成本也别让脏数据污染整个下游。踩坑二权限过滤做晚了很多团队先做效果后补权限结果发现权限过滤要在检索层实现——向量检索召回之后再过滤头部数量会不足必须在检索时带上权限条件。这个架构决定最好第一天就做对返工成本极高。踩坑三没有评估就上线调优感觉比上一版好是不可持续的工作方式。上线第一天就要有评测集几十到一百个真实业务问题加要点式标准答案每次改切块、换模型、调参数都跑分。评测集来源最好是实际用户问题而不是产品经理想象的问题——两者的分布差异大得惊人。预期管理知识库问答的合理预期是常见问题回答准确长尾问题给出资料引用让用户自行判断知识库里没有的坦承不知道。追求什么都能答的项目最后都死在幻觉投诉上。