1. 准确率上不去先承认一个反直觉的事实RAG的最短板往往不在模型做RAG项目的人大概率都经历过这个循环上线后效果不理想第一反应是“换个更强的底座模型试试”试了一圈发现答错的问题只挪了个位置并没有消失。上个星期还有同事拿着评测结果来找我说GPT-4o级别的模型在某些问题上照样胡编最后我让他把知识库里检索出来的原文片段打出来看他沉默了——原来系统压根没找到正确的段落。这不是个别现象。RAG全链路里大家天然把注意力放在“生成”这一头因为模型的表现最直观、最容易被感知。但实际上RAG的最短板的出现位置往往比你想的要早得多——在文档进入系统之前就已经决定了系统能答到什么程度。1.1 RAG全链路拆解模型只是最后一段把一条RAG链路摊开看它其实是这样的文档接入拿到PDF、Word、扫描件、网页等原始材料文档解析把版式、表格、图片、公式从原始文件里“抠”出来文本清洗去掉页眉页脚、乱码、水印、无关注释分块按一定策略把长文本切成chunk配合滑动窗口做重叠向量化用embedding模型把chunk转成向量索引存储进向量库、设置元数据过滤字段检索根据用户问题做相似度召回重排与精排对召回结果做相关性调整生成把TopK片段拼进Prompt交给大模型作答很多团队优化RAG动不动就调模型、换embedding、改Prompt但回溯一下上面的链路会发现第1到第6步也就是文档进入向量库之前的全部环节往往被当成了“理所当然的事”。一个最典型的场景是PDF里一张表格被解析出来之后变成了乱序的纯文本模型确实也“检索”到了这个片段但里面信息是错的它再怎么生成都是错。1.2 把“答错”拆成三件事是没找到、找到错的、还是理解错了要定位问题首先得把一个笼统的“答错”拆开。我在项目里一般把错误归成三类没找到知识库里根本没有相关内容或者有但没被召回。常见表现是模型回答说“根据现有资料无法确认”。找到错的召回结果跟问题相关但里面没有答案或者有答案但被切碎、被乱码污染。常见表现是模型一本正经地拿无关段落生成一个看似合理的回答这就是典型的幻觉。理解错了召回内容是对的但模型没有从中提炼出正确答案。常见表现是原文有明确答案模型却答偏了。这三类错误的修复方向完全不同。只有第三类是真正需要换模型、调Prompt去解决的前两类问题换再大的模型都没用。而前两类错误的根源绝大部分都指向文档进入系统之前的那段工程链路。所以别急着替模型背锅。先从“文档进门”那一刻开始查起。2. 文档在“进门”之前就坏了解析环节的四大暗坑文档解析是整个RAG项目里最无聊、最不被重视但出事率最高的环节。它的目标只有一个把原始文件里的所有信息“无损”地搬进系统。听起来简单做起来全是坑。2.1 扫描件和图片型PDF不OCR等于给系统喂天书先看一个最极端的场景拿到一批扫描版的书籍或合同整个PDF就是一页页图片没有任何文字层。如果你直接拿PyPDF2或者最朴素的解析方式提取文本结果可能是空空如也或者变成一张张整页截图。这种文件只能走OCR路线。我通常的组合是先用PaddleOCR或Tesseract做版面分析文字识别复杂的表格版式配合PP-Structure这类结构化OCR工具但OCR有个特别容易踩的坑OCR输出的坐标信息如果没保留好顺序就会乱。扫描件常见的是双栏排版识别出来如果不做栏位判断可能把左右两栏文字交叉拼接读起来完全不通顺。所以如果你看到召回片段里的文字像“跳跃式”的先怀疑版面判断没做好。还有图像和表格内容OCR只能识别文字图片本身不会被还原。你可以在chunk里保留一段图文说明文本但真正让模型“看图”需要多模态能力或者让解析器把图片截取出来单独存储、用多模态模型描述后存为文字。具体取舍看你的场景如果是知识库要存图片技术文档建议走多模态链路如果只是纯文本问答OCR文字就够用了。2.2 表格结构重建RAG丢失信息最严重的重灾区表格是RAG项目里最容易翻车的东西没有之一。普通文本解析顺序乱了顶多不通顺表格解析乱掉数字对不上号答案直接变成错的。我举一个真实案例一份行业研报里面有各家公司的季度营收对比表。原始表格结构是“行公司列季度”。解析完之后变成了线性文本流季度和数字被打乱有的单元格甚至跑到了其他公司的名下。用户问“某公司Q3营收多少”系统把Q2的数字当成了Q3答案是错的。这不是模型不行是解析环节把表格拆坏了。解决这类问题我的经验是按表格复杂度分级简单表格结构规整、无合并单元格pdfplumber的extract_table函数就能拿到相对完整的二维数组配合TableTransformer这类模型可以做单元格级别的还原然后转成Markdown表格或HTML结构再入库。复杂表格合并单元格、多级表头、跨页推荐MinerU这类专门做结构化文档解析的工具它对表格有自己的后处理手段能把表格以HTML结构输出保留合并关系。完全花式的表格扫描件中的复杂报表只能用OCR版面分析硬啃识别后还需要人工抽样校验。另一个技巧是不要把表格完全拍平成一个Markdown表格就扔进chunk里。超宽的表格比如20列的数据在分块后会被截断表头也经常丢失。我更推荐先把表格转成“摘要式描述关键行数据”或者保留HTML结构并在分块时尽量让一个完整表格落在一个chunk内。2.3 双栏排版、页眉页码与乱码让语义分块分崩离析的小问题比起表格双栏排版问题更隐蔽因为表面上文本提取得“很完整”。真实情况是论文PDF是左右双栏的解析器按页面物理顺序从上往下读导致左边栏读到一半跳去右边栏、又跳回来整段文字一句话被拦腰截断成两半。分块之后这些切碎的片段会让检索质量急转直下。页眉页脚也是经典问题。一份60页的PDF每页顶部有公司名称底部有页码解析后如果不去除向量化之后你会发现检索“某公司2023年报”时系统匹配到的全是页眉里那个公司名真正的财报正文反而排到了后面。乱码更麻烦。某些PDF字体编码异常解析出来全是“锟斤拷”“口口口”这种替换字符。这些chunk索引进向量库不影响相似度计算但一旦被召回模型就没法用了。还有隐藏水印有些文档的页面背景嵌入了整页文字水印光是复制PDF内容时能看到“本资料仅供参考”反复出现如果不清理检索时会被水印噪音严重干扰。所以解析后必须有一道清洗工序这个我在下一章展开说。2.4 工具选型从PyMuPDF到MinerU适合的才是最好的文档解析工具的选择取决于你手里的材料类型。我把常用方案整理成一个表方便对照参考场景推荐工具说明文本型PDF快速提取PyMuPDFfitz速度快保留基础位置信息中文支持好PDF表格抽取pdfplumber对规整表格效果好可自定义表格线规则复杂版式/论文双栏MinerU开源、支持版面分析、公式识别、表格结构化扫描件/图片OCRPaddleOCR中文识别率优秀支持版面分析和表格还原通用文档解析DoclingIBM开源支持PDF/DOCX/PPTX/HTML多格式深度版式多模态unstructured商业级解析按API调用适合企业级其中MinerU和Docling是最近社区讨论热度很高的两个开源项。之前我做一个金融项目时用MinerU把一批招股说明书转成了Markdown结构化文本表格、标题层级都很完整后面分块和检索省了很多力气。注意一件事解析结果一定要保存一份中间产物比如统一的Markdown或JSON文件不要只存在向量库里。排查问题的时候这份中间产物就是你的案发现场。3. 清洗、分块与索引决定检索上限的“三座山”解析完成之后文本仍然是“刚从原生文档里剖出来”的原始状态。直接拿去分块、建索引往往就是把脏数据永久固化。我习惯把这几个环节统称为“前处理”它们共同决定了检索质量的上限——embedding和模型只是在这个上限内发挥。3.1 脏数据清洗清单看不见的页眉页脚、隐藏水印和乱码字符清洗工序不复杂但必须系统化地做。我在项目里会走一份固定的清洗清单页眉页脚/页码用正则识别并剔除比如页码一般是“第 X 页 / X / N”这类格式。注意不要误伤正文里的数字。乱码替换字符把“锟斤拷”“”“口”这类替换符直接删掉或者做字符集转码修复。重复水印识别整页重复出现的句子并剔除。有个粗暴但好用的方法统计全文高频短句如果某个句子出现频率异常高且长度短很可能就是水印。多余空白与空行把多个连续换行合并成段落分隔避免分块时出现大量空块。控制字符剥离不可见的Unicode控制字符、零宽空格等它们会影响分块和匹配。编码修复中文文档经常出现GBK和UTF-8混排需要统一转码。清洗之后最好做一个可重复运行的pipeline。每次接入一批新文档跑同样的解析清洗流程输出同样的结构化格式。别拿到一批文档就手工处理一次那样既慢又容易漏。3.2 分块策略固定窗口、语义分块、父子分块怎么选分块是前处理阶段最核心的决策。块太小语义不完整句子被切断块太大检索噪音多向量化后特征被稀释。没有一个万能参数要根据你的文本特性来定。固定窗口重叠最常见比如chunk_size512个token、overlap50个token。重叠区域就是典型的滑动窗口思想目的是让跨边界的信息至少在一个完整chunk里出现过。这个方案适合新闻、网页、通用说明文。结构感知分块按Markdown标题、段落、列表项来切。文档结构化解析做得好比如用MinerU转出了带标题层级的Markdown直接按标题切分是很稳的。注意标题层级要注入到chunk里比如chunk开头带上“### 2.3 双栏排版”检索时能大幅提升相关度。语义分块用embedding模型计算句向量之间的相似度在“语义断裂处”切分。成本略高但适合逻辑跳跃明显的材料。父子分块Parent-Child Chunking小chunk比如128 token负责召回匹配同时保存其所属的父块比如1024 token。检索时用子块找位置把父块喂给模型。这个方案是检索精度和上下文完整度之间的有效折中尤其适合长文档QA。另外一个容易忽略的细节中文分词对token数的影响。512个token对于英文大约是380个词对于中文大约是800到1000个汉字。如果你照抄英文项目的chunk_size中文场景下块会偏大。建议先对一份真实文档做token统计再定参数。3.3 滑动窗口与上下文增强把相邻片段的信息“缝合”起来滑动窗口思想在RAG里不只是重叠分块那么简单。实际应用中还可以做两层“缝合”一是给模型喂回答上下文时不只是召回的那一个chunk而是把它的前后相邻1-2个chunk一并带上。因为很多答案的线索是跨段落分布的比如“根据表2-1的数据可知”——如果你只召回到了“表2-1”的标题块没有召回数据块模型无法作答。把相邻上下文带上之后这种跨块逻辑就能被弥补一些。二是做“文档级滑动窗口”增强把整段长文本切成多个固定窗口后对每个窗口都做一次不完全重叠的窗口扩展让每个chunk都携带前后一至两句话的“触角”。有研究显示这种简单的滑动窗口扩展比直接加overlap更能保持叙事完整性代价是索引体积增加。实操层面我见过最省心的一种组合是父块1024 token 子块256 token 子块滑动窗口128 token。召回子块输出父块。对大段的研报、论文、产品文档都很友好。3.4 索引与元数据让检索有路可循很多RAG项目只做“向量检索”忽略元数据过滤这会在知识库规模变大之后迅速遇到瓶颈。向量相似度适合找“语义近”的文本但滤掉“来源错误”“类型不符”“时间过期”的内容还得靠元数据。我会给每个chunk至少打上这几类元数据来源文件名、文档路径、URL文档类型研报、合同、技术文档、FAQ章节路径从顶级标题到当前标题的完整层级时间戳发布日期、更新日期作者/部门如果适用混合检索也是值得做的BM25关键词检索与向量检索的结果做加权融合。比如用户问“2024年营收”字面匹配很重要用户问“公司今年赚钱了吗”语义匹配更重要。我一般用RRFReciprocal Rank Fusion把两路召回排序融合实测稳定胜过单路向量。4. 不花一分钱换模型也能定位病根的验证方法排查RAG问题最忌讳的是“盲调”一会儿改Prompt一会儿换embedding一会儿换模型改了一圈问题依旧。这里分享一套我在项目中反复使用的溯源验证法核心思路是用同一个模型做对照实验逐段缩小嫌疑范围。4.1 三层溯源法用同一个模型找出问题环节先准备好一组已知答案的问题集不用多20到50条足够对每条问题做如下三层检查第一层检查召回结果。把检索TopK出来的chunk直接展示出来不看模型输出。问自己两个问题正确的信息在不在这些chunk里排序靠前的chunk是不是相关如果正确信息压根没出现那模型再强也无济于事问题在检索链路上游解析、分块、embedding、索引。第二层把召回chunk直接拼给模型。手动构造一个Prompt“以下是参考资料…… 请根据资料回答问题……”把召回的内容原样拼进去看模型能不能答对。如果模型能答对说明模型能力没问题问题出在系统Prompt把模型带偏了或者你用了太复杂的指令把它的注意力带歪了。如果模型答不对再看chunk本身质量。第三层阅读chunk原文。直接在中间产物解析后的Markdown或JSON里搜答案的关键词。看看原文到底长什么样文字是否乱序、乱码表格数字是否错位答案是否被分块拦腰截断内容是否来自页眉页脚这类噪音到这一层前端问题就完全暴露了。你不需要换任何模型就能把责任定位到具体环节。4.2 构建一个30问的最小评估集排查类的工作最怕没有基准。我强烈建议每个RAG项目都维护一份“真值清单”30到50条有标准答案的问题每条对应文档里的具体参照段落。构建清单时注意覆盖三类问题直接抽取型“某公司的注册资本是多少”——考精确查找能力总结归纳型“这个产品的三大优势是什么”——考跨段落整合能力推理判断型“如果应收账款增加对现金流可能有什么影响”——考知识加工能力有了这份清单每次改动前跑一遍记录“召回正确率”和“最终正确率”两个指标。前者看检索层后者看整体链路。两个指标差异很大说明问题多半在生成端差异很小但都低说明前端还有硬伤。4.3 从“召回结果”到“错误类型”对照表最后把排查结果落到表格里后续看问题会清晰得多。我常用的对应关系大概是这样现象优先怀疑的环节验证手段召回结果为空或乱码文档解析/OCR直接看解析中间产物召回了无关段落但相关段落在库里分块策略、embedding、元数据缺失用关键词搜索确认相关段落确实已入库召回内容相关但答案被截断分块大小/重叠率增大chunk_size或改用父块召回内容相关且完整模型仍答错Prompt或生成模型手动拼接chunk输入排除检索层嫌疑数字、人名等实体错乱表格解析检查表格是否按行列结构输出多个来源冲突导致答错重排/去重加入重排序模型或按来源优先级加权这张表看起来简单但是在项目里特别实用。它能帮你把“模模糊糊觉得系统不对”变成“某项指标明确不合格”处理起来就有了抓手。5. 一次真实排错复盘从“换模型”到“重建知识库”做个复盘吧上个月处理的一个真实案例完整还原一下排查链路。5.1 第一次误判以为模型太弱客户反馈内部知识问答系统在回答“截至2024年底某项目累计成交金额是多少”时给出了错误数字。当时大家的直觉是模型理解力不足或者Prompt引导不到位计划换一个更强的模型。我的建议是先别换打开日志看召回。于是我把这个问题的TopK召回片段拉出来发现系统确实召回了相关表格所在的chunk而且这个chunk在向量相似度排序里排第一看起来一切正常。5.2 顺着链条往下挖召回结果不对劲但把召回片段做人工阅读后问题立刻出现了。片段里虽然有“累计成交金额”这几个字但后面的数字和文档原文对不上原文是“1,286万元”召回片段里变成了“1,268万元”。这说明文本是从某种解析结果里来的但数字已经被改写过。于是我去翻了解析中间产物发现表格被解析成了一张结构错乱的二维数组部分单元格内容串位列标题和数值对应关系被打破。更关键的是这个错乱发生在文档刚进系统的那一步后续所有环节都在忠实传递这个错误。5.3 病根确认PDF表格数字被“重新编码”进一步排查发现这份PDF本身是扫描件最初走的是一条“先用OCR识别文字、再用规则提取表格”的流程。OCR对数字的识别本身有误差同时表格线的断裂又导致列位置判断错误两个问题叠加最终产出了那份错位数据。这里要补充一个惨痛教训当时解析出来的中间产物没有保留原始图片块也没做OCR置信度校验。如果我们一开始就在解析层面对数字字段做“OCR置信度低于阈值则标记待人工复核”的逻辑这批坏数据根本不会进到知识库里。 升级方案是把这批PDF换成MinerU的结构化解析链路其自带表格结构重建对扫描版式明显更稳。同时我在清洗环节加了数字抽查逻辑用正则抓取文档中“万元”“亿元”附近的数字和人工标注的结果做抽样比对一旦发现异常率高就停止入库并人工介入。5.4 重建知识库后的前后对比重建知识库后同一道题的召回片段里数字正确了模型答案自然也就正确了。整个过程没有更换大模型、没有调Prompt只动了文档进门之前的那段链路。这件事给我的感触很深遇到RAG答错的场景首先默认是前处理问题再去怀疑模型。因为模型是通用能力前处理是你的专属数据管道。前者是标准件后者才是真正藏着项目差异和风险的地方。几点经验送给正在被RAG准确率折磨的人如果你现在正被“答非所问”困扰我的建议是先别急着打开模型配置页。花半天时间把你最头疼的10个问题拿出来走一遍上面的溯源流程看看问题到底出在第几环。最后分享一个实操技巧从接入第一批文档开始就把解析后的结构化中间产物Markdown或JSON单独存一份并且给每个chunk生成时记录来源文件名和章节路径。等到排查问题时这三样东西——中间产物、chunk与来源的映射、召回日志——会帮你省出大把时间。文档解析、清洗、分块这些“脏活累活”才是RAG项目真正的护城河。