RAG 知识库搭建的难点通常不在于“把文件传上去”，而在于让资料能被稳定解析、准确召回，并在回答中保留可核查的依据。对企业团队来说，一套能演示的问答系统并不等于可上线的知识库；真正需要验证的是数据质量、检索效果、权限边界和持续更新能力。
先判断是否真的需要 RAG
RAG（检索增强生成）的基本流程是：用户提出问题后，系统先从外部知识库中查找相关片段，再把这些片段连同问题交给大模型生成回答。知识仍保存在可更新的数据源中，不必为了每次资料变更重新训练模型。
它适合以下场景：
- 产品手册、制度、技术文档经常更新；
- 回答需要附带出处，方便人工复核；
- 数据不适合直接进入公开模型训练流程；
- 问题答案依赖企业内部术语、型号、流程或权限。
如果需求只是固定的少量 FAQ，结构化问答表或规则系统可能更简单。若任务要求模型学习新的表达风格或稳定输出格式，微调可能更合适。RAG 主要解决的是“从现有资料中找到依据”，不能替代业务规则、权限控制和数据治理。
自建还是使用平台：先看控制权
自建方案可以自由选择文档解析器、Embedding 模型、向量数据库、重排模型和部署环境，适合已有工程团队、需要复杂权限过滤或必须私有化的项目。代价是团队要自行维护索引更新、监控、评测和故障恢复。
平台化方案更适合快速验证业务价值。它通常把文档导入、切分、向量化、检索测试和模型调用封装为配置项，但需要确认数据存放位置、支持的模型接口、导出能力、权限粒度与计费方式。
选择时不要只比较“是否零代码”，而应检查：
- 原始文档和向量数据能否迁移或导出；
- 是否支持按用户、部门或租户过滤检索结果；
- 模型、Embedding 与重排组件能否替换；
- 更新失败、解析失败时是否有日志和告警；
- 费用是按存储、调用量、Token 还是计算资源结算。
第一步：整理数据，而不是直接全量导入
知识库效果首先取决于资料本身。重复版本、失效制度、扫描质量差的 PDF 和缺少标题层级的长文，会在后续流程中放大噪声。导入前建议完成四项工作：
- 删除重复文件，标记生效日期和版本；
- 给文档补充标题、章节、产品型号、部门等元数据；
- 把扫描件先做 OCR，并抽查表格、页眉页脚和特殊符号；
- 明确哪些内容可公开回答，哪些只能在授权范围内检索。
不同数据形态应采用不同方式。说明书、制度和教程适合文档解析；标准客服话术适合问答对；商品参数、设备台账更适合结构化表格；持续变化的官网内容可以通过受控抓取或定时同步入库。不要为了统一入口，把所有内容都强行转成一段纯文本。
第二步：按语义结构切分文档
切分的目标，是让每个片段既能独立表达一个主题，又保留回答问题所需的上下文。片段过短，模型拿到的信息不完整；片段过长，检索结果会混入无关内容，并占用更多上下文窗口。
与其照搬一个固定字数，不如按文档类型建立策略：
- 教程按标题和步骤切分，保留前置条件；
- 制度按条款切分，同时携带制度名称与版本；
- FAQ 保持一问一答，不把多个问题合并；
- 表格保留字段名，避免只索引孤立的单元格值；
- 代码文档尽量保持函数说明与代码块完整。
相邻片段可以保留少量重叠，但重叠比例不是越高越好。过多重复会让多个相似片段同时占据召回名额。最终参数应通过真实问题集评测，而不是把某个经验值当成通用标准。
第三步：组合检索、过滤与重排
仅依赖向量相似度，容易漏掉型号、编号、缩写和精确数字；仅依赖关键词，又难以处理自然语言改写。生产环境常见的做法是混合检索：同时利用语义相似度和关键词匹配，再根据业务需要加入元数据过滤。
例如，用户查询某款设备的保修流程时，可以先限定产品型号和文档状态，再从候选片段中做语义检索。这样既减少无关召回，也能防止旧版本制度进入回答。
候选数量较多时，可使用 Rerank 模型重新排序。重排通常能改善靠前结果的相关性，但会增加一次模型计算和响应延迟。是否启用、召回多少条、最终传给大模型多少条，都应根据准确率、延迟和成本共同决定。
多轮对话还要处理指代不清的问题。例如用户先问某项服务，再问“支持哪些格式”，检索查询需要补全上下文。查询改写可以解决这一问题，但也会增加调用成本，因此更适合确有多轮依赖的场景。
第四步：建立可重复的检索评测
上线前至少要准备一组来自真实业务的测试问题，并为每个问题标注期望命中的文档或关键事实。问题集应覆盖：
- 高频标准问题；
- 包含型号、数字和缩写的精确查询；
- 口语化、错别字或表达模糊的问题；
- 文档中没有答案的问题；
- 用户无权访问相关资料的问题；
- 多轮对话中的省略和指代。
评测要把“检索”和“生成”分开。先检查目标片段是否出现在 Top-K 结果中，再检查模型是否忠实使用了片段、是否给出来源、无答案时是否拒绝猜测。否则，即使最终回答看起来流畅，也无法判断问题出在索引、召回、重排还是提示词。
参数调优建议一次只改一个变量，并保存版本：切分方式、Embedding 模型、混合检索权重、过滤条件、候选数量和重排开关都应分别对比。业务资料变化后还要定期回归测试，避免新文档使旧问题的命中率下降。
上线时容易忽略的四个问题
权限不能只写在提示词里
提示词无法替代访问控制。权限过滤应发生在检索阶段，并由后端根据已认证用户生成过滤条件，避免模型看到不应访问的片段。
文档更新需要完整链路
更新不只是重新上传文件。系统还要处理旧片段删除、索引重建、失败重试、版本回滚和缓存失效。网页同步尤其要防止正文结构变化导致解析结果异常。
回答必须允许“不知道”
当召回结果不足或互相冲突时，系统应明确提示无法确认，并引导用户查看来源或转人工处理。强制模型始终给答案，会把检索缺陷变成看似可信的错误结论。
成本要按整条链路计算
成本不仅包括生成模型 Token，还包括文档解析、Embedding、向量存储、重排、查询改写、日志和计算资源。小规模验证阶段就应记录单次查询各环节的耗时和用量，才能为扩容提供依据。
一条可落地的实施顺序
对个人开发者和小团队，可以按以下顺序推进：
- 选择一个边界清晰的场景，例如产品手册问答；
- 清洗一批高质量资料，建立版本和权限标签；
- 先实现基础检索，不急于加入复杂 Agent；
- 用真实问题集验证召回，再调整切分和检索；
- 加入来源展示、无答案处理和访问控制；
- 最后再评估查询改写、重排和自动同步的收益。
RAG 知识库搭建是一项持续的数据与检索工程。先用可重复的评测找到瓶颈，再决定增加模型能力还是改进资料质量，通常比不断叠加组件更有效。