RAG完整链路拆解离线阶段和在线阶段到底做了什么离线阶段原始文档RAG系统的知识来源可以多种多样PDF文档、网页、Markdown文件、数据库记录、数据库记录、邮件…不同格式的文档需要不同的解析方式这一步通常叫做文档加载值得注意的是这一步的质量直接影响整个系统的上限。如果原始文档本身是扫描或排版混乱的PDF解析出来的文本就会充满噪声后续所有环节都会受损。“垃圾进垃圾出”在RAG里体现的非常明显文档处理清洗与预处理解析出来的原始文本往往不能直接使用需要做一轮清洗去掉页眉页脚、无意义的格式符号、重复内;识别并保留文档的标题结构过滤表格乱码、图片占位符等这一步看起来琐碎但是在实际项目里面文档预处理往往是工程量最大、最容易被低估的部分切片Chunking清洗好的文档不能整篇进向量库需要切成更小的片段。这是RAG系统设计决策最多的一个环节直接影响后续检索的准确度为什么要切原因很直接一篇20页的文档用户的问题可能只和其中的某一段相关如果把整篇文档作为一个单元存储和检索那么检索粒度太粗命中了整篇但是相关内容被淹没要么上下文太长放不进模型或者注意力被稀释切太多合适吗这没有通用的答案需要根据文档类型、模型的上下文窗口、业务问题的颗粒度来决定。向量化Embedding切好的每个chunk,都需要通过Embedding模型转换成一个向量一个高维浮点数数组这个向量代表了这段文字的语义向量化的关键点用户问题和文档chunk必须用同一个Embedding模型来处理这样两者的向量才处于同一个语义空间相似度计算才有意义同时还需要存储对应的元数据这个chunk来自那份文档、原文在那一页、文档的创建时间等。元数据在过滤检索结果时非常重要比如只看最近三个月的文档这类需求就需要依赖元数据来实现存入向量数据库向量和元数据分别存入向量数据库和普通数据库向量数据库的核心能力是近似最近邻搜索能在百万向量中毫秒级找到与查询向量最相似的top-kj结果在线阶段Query处理用户的原始问题不一定适合直接用来检索Query改写把口语化的问题转成更适合检索的形式或者把一个复杂问题拆解成几个子问题分别检索Query扩展对问题做同义词扩展提高召回覆盖面避免因为用词差异漏掉相关文档检索Query向量化之后和向量库里面存储的所有chunk向量做相似度计算通常用余弦相似度召回相似度最高的top-K 个chunkk的值通常在3-10之间更完整的实现会做混合检索同时跑向量检索语义相似和关键字检索精确匹配然后把两路结果合并这样能兼顾语意理解和关键词精确匹配两种优势Rerank精排初步召回的top-K结果相关性不一定都高。Retrank是在召回之后加一道精排用一个专门的Cross-Encoder模型对Query.chunk对打分按新分数重新排序只保留最相关的几条Rerank就是RAG里面最常见也是最有效的手段之一代价是多一次模型推理的延迟上下文构建把最终筛选出来的chunk加上元数据按照一定格式拼装成上下文连同用户的原始问题一起构建出最终的Prompt送给生成模型生成生成模型接收完整的Prompt基于提供的上下文生成回答关键点是Prompt里面有明确的引导指令—让模型优先依据资料回答而不是依赖自身参数知识并要求在答案里标准来源常见误区RAG 向量检索向量检索只是在线阶段一个步骤完整的RAG系统话包括文档解析、Chunking策略、Embedding选型、元数据管理、Rerank、Prompt设计等一系列工程工作缺少任何一个环节都会拖累整体的效果只要模型够强Chunking随便切换就行Chunking是RAG里面最底层的基础设施模型再强如果检索到的chunk要么太短要么太长生成质量都会大打折扣模型能力无法弥补检索质量的缺陷Rerank一定要加Rerank是由代价的多一次模型调用意味着更高的延迟和成本对于实时性要求高、或者文档量较小的场景精确的Embedding合理的top-K往往已经足够先评估是否真的需要再决定是否加