很多企业想做 AI 知识库，第一反应是把 PDF、Word、网页资料上传给大模型。但稳定可用的 RAG 系统，需要解决文档质量、切分策略、向量检索、权限隔离、答案可追溯和人工纠错等问题。否则 AI 看似能答，实际很容易答偏、答混或无法解释来源。
典型架构链路
- 业务文档 / FAQ / 产品资料
- 解析与清洗
- Chunk 切分与元数据标记
- Embedding 向量化
- 向量库 + 关键词索引
- 检索 + 重排
- 提示词组装
- 大模型生成答案 + 来源引用
文档解析：先把资料变成可处理的文本
PDF、Word、网页、表格、图片 OCR 的结构都不同。第一步要把标题、段落、表格、编号和来源保留下来，避免后面检索时丢失上下文。
切分策略：Chunk 太大太小都不行
切分太小会丢上下文，切分太大会降低检索精度。常见做法是按标题层级、段落语义和 token 长度混合切分，并保留文档名、章节、页码、更新时间等元数据。
向量化与索引：不只靠向量检索
向量检索适合语义相近的问题，但对产品型号、订单号、政策条款这类精确词，关键词检索也很重要。实际项目里经常采用向量检索 + BM25 + 规则过滤的混合检索。
重排与上下文组装：决定答案质量
检索到的片段不一定都适合喂给模型，需要做相关性重排、去重、按来源排序，并控制上下文长度。提示词里要明确回答边界：资料没有就说不知道。
权限隔离：企业知识库必须考虑谁能看什么
不同部门、客户、项目资料不能混在一起。RAG 系统要在检索前过滤租户、角色、项目和文档权限，而不是生成答案后再隐藏。
可追溯与纠错：让 AI 答案能被业务信任
答案最好带来源引用、文档片段和更新时间。用户反馈“答错了”时，要能追踪是文档问题、检索问题、提示词问题还是模型问题。
脱敏项目复盘：服务手册知识库如何做到有据可查
知识库项目失败，通常不是模型能力不够，而是资料版本、权限、表格图片和评测体系没有做好。一类设备售后项目拥有说明书、故障码表、维修通告和历史工单，客服希望直接提问，但同一型号跨年份存在多版资料，错误引用比回答慢更危险。
业务与产品形态
首期限定为故障定位和操作说明，不回答合同责任、费用承诺与安全决策。客服端提供搜索、问答、引用证据和反馈；资料管理员维护产品型号、版本、生效时间和可见范围；质检端查看低置信问题、未命中问题和人工修正，形成持续改进队列。
技术解决方案
文档入库先做格式解析、版面识别、表格与图片关联，再按标题层级和语义切分；每个片段保存文档、版本、页码、产品和权限元数据。检索先做权限和型号过滤，再组合关键词、向量召回与重排；生成提示只允许使用候选证据，并输出引用。高频稳定问题缓存结果，但资料版本变化时主动失效。
难点设计
故障码表不能被随意切成孤立段落，图片步骤也不能只保留 OCR 文本；需要针对文档类型定义解析策略。用户问题中的俗称要映射标准型号，版本冲突时优先显示冲突而不是自行选择。权限必须在检索前过滤，不能生成后再遮盖，否则模型已经接触到越权内容。
用户体验
回答旁显示资料名称、版本、页码和原文片段，用户可快速展开上下文。信息不足时系统列出需要补充的型号、故障码或现象；没有可靠证据时明确“不确定”并转给专家。反馈不是简单点赞，而是区分证据错误、答案遗漏、版本不符和问题已解决。
产品效果与验收
上线前建立来自真实工单的评测集，覆盖常见、长尾、歧义、无答案和越权问题。指标包括检索命中率、引用正确率、无答案识别率、回答延迟、人工采用率和升级专家比例，并按型号分层观察。RAG 的价值不是让每个问题都有回答，而是让可靠答案更快到达、错误答案更容易被发现和追责。
RAG 的难点不在接模型，而在持续控制知识质量
一个演示版知识库，上传几份 PDF 后就能回答问题；生产系统要面对文档重复、版本冲突、扫描件解析失败、人员权限变化和模型升级。我们把知识入库设计成可重放的数据流水线：原始文件保留校验值，解析结果有版本，Chunk 能追溯到页码和标题，索引记录使用的解析器与 Embedding 模型。哪一环变化，都能有选择地重新处理，而不是全库手工重建。
检索链路要为不同问题选择不同策略
产品型号、法规条款、故障代码依赖精确关键词；操作咨询和自然语言问题更适合语义检索。我们通常并行执行 BM25 与向量召回，先按租户、部门、文档状态做元数据过滤，再用重排模型对候选片段评分。对表格和长文档还会保留父子块关系，检索到局部后补充所在章节，避免片段有答案却缺少条件。
权限必须在召回之前生效
生成后再遮盖敏感内容已经太晚，因为模型上下文里可能包含无权查看的信息。索引记录要携带租户、项目、部门和密级，查询时由服务端根据用户身份生成过滤条件。权限变更后还要处理缓存和已生成会话，下载原文也必须再次鉴权，不能因为拿到了引用链接就绕过文档权限。
评测集比反复调整提示词更可靠
上线前我们会和业务一起整理一组问题，包含可回答、不可回答、歧义问题和越权问题，并标记期望来源而不只标记答案文本。每次调整切分、检索或模型后，自动比较召回率、引用正确率、拒答率和响应时间。生产环境再记录匿名化查询、命中文档和用户反馈，以区分是知识缺失、检索失败还是生成偏差。
系统要允许明确地说“不知道”
企业知识库最危险的不是偶尔找不到，而是把相似内容拼成一个听起来合理的答案。提示词需要限制只依据证据回答，低于相关性阈值时直接拒答，并把可疑答案送入人工纠错队列。纠错结果应回到文档或问答数据源，而不是只在某段提示词里打补丁。长期可用的 RAG，本质上是一套知识治理系统。
一条可验收的 RAG 查询链路，应该记录什么
入库时保存版本、权限和可追溯位置
文档解析后，每个 chunk 不只存正文和向量，还要保存 document_id、版本、页码或段落、chunk_hash、解析器版本、所属部门和访问标签。文件更新时生成新版本并使旧索引失效，不能静默覆盖。回答引用到具体片段后，用户才能回到原文核对，权限变更也能准确清理相关索引。
检索通常需要关键词与向量共同参与
产品编码、合同编号和专业缩写适合 BM25 等关键词检索，语义相近的问题适合向量召回。实际链路会先按租户、权限、文档类型和有效期过滤，再合并两路候选并去重，最后用 reranker 排序。top_k 不是越大越好，候选过多会稀释上下文，还会增加延迟和模型成本。
回答器必须知道什么时候不回答
上下文组装要控制 token 预算，保留标题、层级和引用编号，并明确要求仅依据提供资料回答。没有足够证据、资料冲突或用户越权时，返回“当前资料无法确认”并指出缺少什么，而不是补一个听起来合理的答案。最终响应保存引用 chunk、检索得分、模型和模板版本，便于复盘。
用固定问题集衡量召回与答案质量
评测集应包含可回答、不可回答、跨文档、数字日期、同义问法和越权问题，并由业务人员标注期望证据。检索层看 recall@k 与权限泄漏，回答层看引用一致性、事实正确率和拒答是否合理，同时记录 P95 延迟与单次成本。模型、切分或索引策略变更后重复运行，才能知道优化是否真实而不是只挑几个演示问题。
落地前建议确认
- 资料是否有明确来源和更新时间
- 是否需要按部门或客户隔离权限
- 是否需要答案引用来源
- 是否有人工纠错和知识更新流程