RAG知识库怎么从零搭建？从数据整理到入库的全流程步骤详解

手里有一堆公司文档、产品手册或技术资料，想让模型基于它们回答而不是自己瞎编，但一上来就卡在「先干什么、后干什么」上——直接丢文件进去答不准，又不知道是哪一步出了问题。这篇按数据整理到入库的真实顺序走一遍，每一步告诉你做什么、做到什么程度算过关，以及哪一步出问题会表现成什么症状。

手里有一堆公司文档、产品手册或技术资料，想让模型基于它们回答而不是自己瞎编，但一上来就卡在「先干什么、后干什么」上——直接丢文件进去答不准，又不知道是哪一步出了问题。这篇按数据整理到入库的真实顺序走一遍，每一步告诉你做什么、做到什么程度算过关，以及哪一步出问题会表现成什么症状。

整条流程可以拆成六步：定边界、盘资料、清洗切分、选模型和库、入库建索引、接检索跑评测。顺序别跳，因为后面每一步的验收标准都依赖前一步的产出。跳过边界定义直接建库，最后会得到一堆能搜但答不到点子上的片段；跳过评测直接上线，改了哪里变好变坏全靠感觉，根本说不清。

先定边界：这套知识库要答什么、不答什么

这一步不写代码，但花的时间最值。你要在动手前拿出一份真实问题清单，用它当整条流程的验收标准。清单来源就是日常被问得最多的问题，比如产品怎么开通、某个报错怎么处理、某条政策怎么解释。别等做完再回头想「效果好不好」，那时候你已经没有参照物了。

• 写一份 10 条左右的真实问题清单，覆盖你希望它答对的主要场景，整条流程都用它验收
• 明确知识范围：只答某几类文档，还是全公司资料；范围越糊，后面越难判断对错
• 区分问答型和检索型需求：前者要一个答案，后者要一堆出处，切分和排序策略不一样
• 把「不该答的问题」也列出来，比如需要实时行情、需要权限判断的，提前想好兜底话术
• 什么情况下不适合做 RAG：答案依赖实时数据、或资料本身互相矛盾时，先去解决数据源

第一步：资料盘点和格式分堆

把所有待入库文件列成一张表，按格式分堆，因为不同格式的处理成本差好几倍。纯文本和网页最省事，结构化表格要单独设计切法，PDF 要看是文字版还是扫描件，扫描件还得先过 OCR。分完堆你就知道哪一堆会吃掉大半工期，先排它。

• 每堆标注预计处理难度和是否会更新，更新频率决定后面是重建还是增量
• 先剔掉明显不该入库的：过期的、重复的、只有内部少数人看得懂的
• 给每份资料打上来源和负责人，出问题时知道找谁确认

这一步有个容易被忽略的动作：标记更新频率。政策类文档可能每月变，技术手册可能一年不动。更新频繁的那堆，后面入库脚本必须支持增量，否则每次全量重建既慢又容易出批号混乱。站内参考：到 /pdf-ocr-doc-cleaning 看 PDF 和扫描件进料前的清洗清单，那篇讲的是这一步往下细做的部分。

第二步：清洗与切分，最容易埋雷的地方

清洗不是简单删空格和换行。真正要清的是页眉页脚、页码、目录、广告位、重复段落，以及同一份文档里反复出现的免责声明。这些东西进了库，会让检索命中的片段看起来相关、读起来没用。清完之后再抽查几份，看正文是不是完整、标题层级还在不在。

1. 清噪声写规则或脚本去掉页眉页脚、页码、目录页；跑完抽查三份文档，确认正文没有被误删
2. 定切分单位按语义边界切，标题切换、段落结束、表格换行都是边界；避免只按固定字数硬切
3. 补元数据每个片段带上来源文件名、标题路径、更新时间；拿一条片段反查，看能不能顺着元数据回到原文位置
4. 抽检验收从问题清单里挑两条，人工找对应的片段，看关键信息是否落在同一个 chunk 里

语义边界

标题、段落、列表项、表格行这类天然的语义终止位置

元数据

附在片段上、用来引用和过滤的结构化信息，比如来源和更新时间

硬切

按固定字数机械分割，会把一句话或一个操作步骤拦腰截断

第三步：选 embedding 与向量库

embedding 选型看三件事：中英文混排效果、维度与成本、要不要配重排模型。你的资料如果是中文为主夹杂英文术语，选型时就得拿这种混合内容去试，纯英文效果好的不一定适合你。向量库按规模选：几千条用轻量本地方案就够，上百万条再考虑分布式和索引类型。

• 入库前先把「同一份文档重复入库」的幂等逻辑想好，否则重建一次数据就翻倍
• 决定要不要重排模型：召回不准时先调召回数量，最后才考虑加重排
• 相似度阈值先留空，等有基线检索结果后再定，拍脑袋定阈值会误杀正确片段
• 到 /embeddings 对照嵌入模型，到 /stacks/vector-dbs 对照向量数据库

什么情况下不适用这套选型流程：资料总量很小，比如就十几份文档，直接塞进上下文可能比搭 RAG 更省事，检索层反而增加维护负担。判断标准很简单——如果全量资料塞得进上下文还答得准，就先别建库。

第四步：入库、建索引与可回滚

入库脚本要能重复执行，并且同时支持全量重建和按单个文档增量更新。只支持全量的脚本，改一份文档就得重跑几小时，时间一长没人愿意更新，知识库就慢慢烂掉。每条记录带上文档标识和内容哈希，靠哈希判断这份文档是否真的变了。

# 伪代码示意，不是可运行命令\n\n# 全量重建\ningest --mode full --batch-id 2025xx\n\n# 单文档增量\ningest --mode delta --doc-id handbook-03\n\n# 入库后立即验证\nquery --test-set acceptance-10 --output baseline.json

• 每次入库记录批次号、条数、耗时，出问题能定位到是哪一批
• 生成一批固定测试问题的检索结果存成基线，之后每次改切分或换模型都对比这份基线
• 入库失败要能单条重试，不要一失败就整批回滚，那会浪费大量时间
• 保留上一版索引快照，切换新索引出问题时能快速切回去

可回滚这件事在生产环境里比性能重要。改切分策略或换 embedding 之后，如果检索质量下降，你要能在几分钟内切回旧索引，而不是花半天重新跑一遍。建议每次改动前先导出一份当前索引的元信息清单，出问题时照着清单逐项核对。

第五步：把检索接进模型，先跑检索再管生成

很多人一上来就调提示词，结果答不准到底是检索没召回还是模型没理解，根本分不清。正确顺序是先单独看检索结果：拿问题清单里的问题去搜，人工检查返回的片段里有没有正确答案。这一步过了再谈生成，两件事混在一起排查不了。

提示词里明确要求「只依据给定片段回答，找不到就说找不到」，并要求附上出处。塞进上下文的片段数量和长度要控制，塞太多反而稀释重点，参考 /context-budget-engineering 里的思路去分配预算。

第六步：上线后的评测与更新闭环

上线不是终点。建一组固定问题加期望要点的小评测集，每次改动前后各跑一次，只认结果不认感觉。评测集不用大，十个到二十个问题覆盖主要场景就够，关键是每次都跑同一份，这样才有可比性。如果评测集本身在变，那对比的就是噪音。

• 监控三类信号：答不出来、答错、引用了过期文档，分别对应不同的修法
• 文档更新流程固定下来：谁负责提交、多久入库一次、旧版本怎么标记失效
• 把用户实际问过但答不准的问题收集起来，它们是最值钱的下一轮改进输入
• 定期抽查检索结果，确认召回的片段来源覆盖了你预期的文档范围

常见翻车点速查：症状对原因

下面这几条是搭 RAG 知识库时最常遇到的翻车点。遇到问题的正确做法是先定位在哪一步，再动手改，别一上来就换模型或重写提示词。绝大多数「模型答不准」其实发生在入库之前的某一步。

• 答案总是差点意思、关键信息没出现：多半是切分把相关内容切散了，回去看 chunk 边界
• 答案里引用的出处对不上：元数据没写好，或者入库时串了批次
• 同一问题有时对有时错：召回片段不稳定，检查是不是没做去重或相似度阈值太低
• 更新了文档但答案还是旧的：增量入库没生效，或者检索层有缓存没清
• 换了模型反而更差：先看评测集对比结果，别凭几条感觉就下结论

想对照业界主流模型和中转站的实际价格再决定用哪家，到 /price-watch 核对当时的数字；挑工具和依赖时，到 /tools/speed-test 看速度测试的口径。别用记忆里的价格和跑分做决策，这类数字变化很快。