‍♂️ 个人主页小李同学_LSH的主页✍ 作者简介LLM学习者 希望大家多多支持我们一起进步如果文章对你有帮助的话欢迎评论 点赞 收藏 加关注目录一、RAG 不是一个点而是一条链二、文档清洗——别让垃圾进系统1. 什么叫文档清洗2. 文档清洗的本质3. 工程里要重点保留什么三、文本切分——为什么不能整篇直接入库1. 切分的目标2. 切分策略常见有三种按长度切按结构切按语义切3. 为什么要 overlap4. 切分不是越小越好四、入库——不只是存向量而是存“向量 元数据”1. 为什么只存向量不够2. 入库可以写成什么五、召回——先把“可能相关的”找出来1. 余弦相似度2. Top-K 召回3. 为什么召回不是最终答案第五步重排——从“可能相关”里再挑最好的1. 重排到底在做什么2. 为什么重排有效第六步生成——模型不是自己想而是“带资料作答”1. 生成阶段最核心的不是模型而是 prompt 组织2. 一个简化版生成目标这两年RAG 几乎已经成了大模型应用开发里最常见的一条技术路线。很多人第一次接触 RAG会把它理解成一句话“把文档喂给模型。”真正做过项目的人都知道RAG 的效果好不好通常不取决于“你有没有接一个向量库”而取决于整条链路有没有设计好。因为在真实项目里RAG 从来不是只有“检索”这一步它至少包含下面这几个关键环节文档清洗文本切分向量化与入库召回重排生成如果你把这条链路理解成一个流水线会更容易明白模型最后答得准不准往往不是生成阶段单独决定的而是前面每一步共同决定的。这篇文章我就按工程视角把一条完整的 RAG 流程彻底拆开。一、RAG 不是一个点而是一条链RAG 的本质不是“加一个知识库”而是在生成之前先从外部知识中检索出最相关的信息再把这些信息作为上下文交给模型生成答案。所以它天然分成两大阶段Retrieval先找到相关内容Generation再基于这些内容回答如果只写成最简公式可以这样表示答案不是只靠模型参数生成而是要条件化在外部文档上。阶段输入核心任务输出常见问题文档清洗原始文档去噪、去重、保留结构干净文本乱码、页眉页脚干扰、OCR 错误文本切分干净文本拆成适合检索的 chunkchunk 集合切太碎或切太大向量化与入库chunk生成 embedding并存储元数据向量索引只存向量不存来源信息召回用户问题从索引中粗筛相关片段Top-K 候选召回不准、噪声太多重排候选片段更精细地重新排序Top-N 高质量上下文相关但不关键的片段排在前面生成问题 上下文基于检索结果回答最终答案幻觉、引用错位、上下文污染二、文档清洗——别让垃圾进系统问题类型典型表现对 RAG 的影响常见处理方式页眉页脚重复每页都有相同标题、日期、公司名干扰 embedding召回噪声增加正则清理、模板去重OCR 错误字符识别错、断字、乱码语义失真检索失败OCR 后校正、人工抽样检查空白与换行混乱断句异常、段落碎裂切分后语义断裂标准化空格、合并异常换行表格被打散列对齐丢失模型难理解结构化信息表格单独解析、转 markdown重复内容同一段反复出现检索结果冗余去重、哈希检测标题层级丢失章节关系消失后续切分和来源展示变差保留标题、层级标签化很多人做 RAG 的第一反应是读文件切 chunk扔进向量库但如果原始文档本身很脏后面步骤做得再精细也会出问题。1. 什么叫文档清洗文档清洗的目标是把原始资料处理成适合后续切分和检索的文本形式。常见要处理的问题包括重复页眉页脚乱码空白行过多OCR 识别错误表格被打散标题层级丢失图片说明缺失HTML / PDF 解析噪声如果这些东西不清理后面向量化时模型会把很多没意义的信息也学进去结果就是召回不准chunk 语义断裂模型引用无关内容2. 文档清洗的本质文档清洗的本质可以理解成一个预处理函数这个阶段的目标不是让文本“更漂亮”而是让它更适合后续结构化处理。3. 工程里要重点保留什么清洗时最重要的不是删而是保住结构。尤其要尽量保住标题小节层级段落边界表格语义来源信息页码文档元数据因为这些结构后面都会影响切分、召回、重排甚至影响最终引用来源的可信度。三、文本切分——为什么不能整篇直接入库文档清洗后很多人会问既然已经是干净文本了为什么还要切分答案很简单因为检索和生成都不适合直接处理整篇长文。如果整篇都塞进去会有几个问题向量太粗语义平均化严重检索时很难命中真正相关的小段落上下文太长生成成本太高模型回答时容易引用无关内容所以必须切 chunk。切分方式做法优点缺点适用场景固定长度切分按字符数或 token 数切实现简单速度快容易切断语义快速原型、通用文本按段落切分以自然段为单位语义完整度较高长度不稳定文本结构较清晰的文档按标题/章节切分按文档结构切保留主题边界某些段可能过长手册、论文、技术文档语义切分根据语义边界切质量通常最好成本更高、实现复杂高质量知识库滑窗切分chunk 间保留 overlap缓解信息断裂冗余增加大多数生产 RAG1. 切分的目标文本切分本质上是在做把长文拆成“足够短但语义尽量完整”的小片段。设清洗后的文档为 x′切分后得到2. 切分策略常见有三种按长度切比如固定 500 字、1000 token 一段。优点是简单缺点是容易把语义切断。按结构切比如按标题、段落、章节、小节切。优点是语义完整性更强缺点是块大小可能不稳定。按语义切比如尽量让每个 chunk 保持一个完整主题。效果通常最好但实现更复杂。3. 为什么要 overlap参数偏小的影响偏大的影响一般建议chunk size语义不完整检索召回碎片化上下文太杂检索不精准先从 300–800 token 试chunk overlap信息断裂边界内容丢失冗余过高成本增加常见取 10%–20%Top-K 召回数容易漏掉关键信息噪声太多重排压力大先从 5–20 试Top-N 重排输出数上下文不足模型输入过长常见取 3–8很多系统在切分时会保留重叠区比如前后 chunk 重叠 50 到 100 个 token。原因很简单防止关键信息正好被切断。如果 chunk 写成那 overlap 相当于让相邻区间满足4. 切分不是越小越好这是很多人最容易踩的坑。chunk 太大召回不精准chunk 太小上下文不完整overlap 太少语义断裂overlap 太多冗余严重、成本升高所以切分本质上是在平衡两件事尽量完整”与“尽量可检索”之间的平衡点四、入库——不只是存向量而是存“向量 元数据”切完 chunk 以后下一步不是直接“存文本”而是先把它们变成向量。这些向量会被放进向量库里供后续召回使用。元数据字段作用为什么重要文档 ID标识来源文档便于追踪与去重文档名称展示来源回答引用更可信页码 / 段落号精确定位方便用户核对标题路径保留层级结构有助于后续重排和展示更新时间时间过滤避免引用过时内容权限标签访问控制企业场景常常必须有业务标签分类检索支持多知识库场景1. 为什么只存向量不够工程里绝对不能只存chunk 文本embedding 向量还必须存元数据比如文档名页码段落位置标题路径文件类型更新时间权限信息业务标签因为后面你做权限过滤来源展示时间筛选多文档聚合都离不开元数据。2. 入库可以写成什么你可以把一个入库单元理解成这个三元组才是一个完整的 RAG 索引单元。五、召回——先把“可能相关的”找出来当用户提出问题 q时系统首先要做的是把问题向量化去向量库里找最像的 chunk设问题向量为然后对每个候选 chunk 向量 vi 计算相似度1. 余弦相似度2. Top-K 召回最后取相似度最高的前 K个3. 为什么召回不是最终答案召回的目标只是把“可能相关”的先找出来。注意是“可能相关”不是“最适合直接喂给模型”。所以召回是一个高召回率优先的阶段它更像一个粗筛。这也是为什么很多系统到了这一步还不够需要下一层重排。第五步重排——从“可能相关”里再挑最好的很多 RAG 项目效果不佳不是因为没检索到而是因为召回回来的内容顺序不对或者前几条不够好。于是就需要重排器Reranker。1. 重排到底在做什么2. 为什么重排有效因为向量召回擅长的是“语义近似搜索”但它不一定最擅长细粒度判断这个 chunk 和问题到底是不是同一件事是不是只是词很像但意思不对多个 chunk 里哪个最适合直接回答而重排器更像是一个精筛器它会更细致地看query 和 chunk 的相关性回答价值语义匹配程度所以一个常见组合就是召回负责扩大候选范围重排负责压缩高质量上下文第六步生成——模型不是自己想而是“带资料作答”坑点典型现象根因解决思路不做清洗直接入库检索全是噪声原始文档太脏先做结构化清洗chunk 切太机械句子被腰斩只按长度切引入段落/标题/overlap只做召回不重排答案老引用错片段粗筛结果顺序不准增加 rerankmetadata 缺失无法标注来源入库字段太少保存页码、标题、文档名prompt 没约束模型胡编乱造生成阶段自由发挥明确“只基于上下文回答”Top-K 过大模型看了太多噪声召回结果过宽调小 K 或增加重排到了生成阶段才终于轮到大模型上场。但这里一定要记住RAG 里的生成不是自由发挥而是带着检索到的上下文回答。设最终选出的上下文为那生成过程可以写成1. 生成阶段最核心的不是模型而是 prompt 组织很多人做 RAG 只盯着召回模型向量库rerank 模型但生成阶段真正的关键常常是如何拼接上下文如何限制模型只基于文档回答如何让模型在不知道时明确说不知道如何要求它引用来源所以一个很常见的生成 Prompt 会包括system 角色说明context 文档片段用户问题输出格式要求2. 一个简化版生成目标可以把 RAG 生成阶段写成意思就是在给定问题 q和上下文 C的条件下找出最可能的答案。