1. 问题不在模型在文档进系统之前RAG 答错的时候绝大多数人的第一反应是换模型。从 7B 换到 14B从 14B 换到 70B从开源换到闭源账单翻了几倍效果提升却微乎其微。我见过太多团队在这个循环里反复横跳最后得出一个错误结论“RAG 这条路走不通。”但如果你把整个链路拆开看模型只是最后一步。在模型看到问题之前文档已经经历了解析、切分、向量化、检索、重排这一整套流程。任何一个环节出问题模型再强也救不回来。这就像你给一位顶级厨师一堆烂掉的食材他做出来的菜不可能好吃。问题不在厨师在食材进厨房之前就已经坏了。这篇文章就是写给那些正在被 RAG 答非所问困扰的人。不管你是刚搭完第一个 RAG demo 的新手还是已经上线了知识库系统但效果不达预期的开发者我都会从文档进入系统之前的环节开始一步步拆解问题出在哪里、怎么排查、怎么修复。核心关键词就一个文档结构化解析。这是整个 RAG 链路里最容易被忽视、但回报率最高的环节。我自己的经验是一个中等规模的知识库项目如果把文档解析和切分做扎实检索命中率能从 40% 出头拉到 75% 以上而且不需要换任何模型。下面我把这套方法论完整展开。2. 文档进系统之前到底发生了什么2.1 一条完整的 RAG 链路拆解很多人对 RAG 的理解停留在“把文档扔进去问问题模型回答”这个层面。但实际链路要长得多。我把它拆成七个阶段文档采集从各种来源获取原始文件PDF、Word、Excel、网页、数据库导出等。格式解析把二进制文件转成可处理的文本流同时提取表格、图片、标题层级等结构信息。内容清洗去掉页眉页脚、水印、乱码、重复段落、无关广告。切分策略把长文档切成适合向量化的片段决定切多长、怎么切、重叠多少。向量化用 embedding 模型把每个片段转成向量。检索与重排根据用户问题召回相关片段再用重排模型精排。生成回答把检索到的片段拼进 prompt让 LLM 生成最终答案。模型只在第 7 步出现。前面六步全是“文档进系统之前”的事。而根据我的排查经验RAG 答错的案例里超过七成的问题出在第 2 到第 4 步。2.2 为什么文档解析是最大的隐形杀手PDF 是最常见的文档格式也是最容易出问题的格式。一个看起来排版整齐的 PDF底层可能是一堆绝对定位的文本框没有任何语义结构。你直接抽文本得到的可能是第三章 系统架构 本章介绍 系统的整体 架构设计 包括 数据层 服务层 和 应用层 三个 主要部分标题、正文、列表全混在一起段落边界完全丢失。这种文本喂给 embedding 模型向量质量极差。检索的时候用户问“系统架构分几层”这段文本可能因为“架构”“层”这些词被召回但模型拿到的是碎片化的信息生成答案时自然容易胡编。更隐蔽的问题是表格。PDF 里的表格抽出来经常变成一串没有分隔符的数字和文字比如“产品A 100 200 300 产品B 150 250 350”你根本不知道这些数字对应什么列。如果知识库里有大量表格数据检索质量会断崖式下跌。还有一个容易被忽略的点多栏排版。学术论文、产品手册经常用双栏甚至三栏排版。直接抽文本会把左右栏的内容交错在一起读起来像精神错乱。我见过一个技术文档知识库因为原始 PDF 是双栏的抽出来的文本把“注意事项”和“操作步骤”混在一起导致模型给出的答案把警告当成了步骤。2.3 一个真实案例从 38% 到 79% 的命中率提升去年我帮一个团队排查他们的 RAG 知识库。他们的场景是内部技术文档问答文档量大概 2000 多份主要是 PDF 和 Word。上线三个月用户反馈“经常答错”或者“答非所问”。他们试过换 embedding 模型、换 LLM、调 top_k效果都不明显。我让他们把检索命中率打出来看只有 38%。也就是说超过六成的用户问题检索阶段就没找到正确的文档片段。模型再强也没用。我们花了两周时间做了一件事重做文档解析和切分。具体包括用版面分析工具识别标题、正文、表格、图片区域按标题层级做递归切分而不是固定长度切分表格单独处理转成 Markdown 格式保留结构去掉页眉页脚和重复的水印文字改完之后检索命中率直接拉到 79%。模型没换embedding 没换只是文档进系统之前的处理变了。这个案例让我更加确信RAG 的效果瓶颈大多数时候不在模型在数据预处理。3. 文档结构化解析的核心技术点3.1 版面分析让机器看懂文档的“排版语言”版面分析要解决的问题是给定一页文档的图像或 PDF识别出哪些区域是标题、哪些是正文、哪些是表格、哪些是图片、哪些是页眉页脚。这是文档结构化解析的第一步也是最关键的一步。目前主流方案分两类基于规则的方法利用 PDF 的字体大小、加粗、位置坐标等元信息做判断。比如字体大于正文 1.5 倍且居中大概率是标题。这种方法快、成本低但对扫描件和复杂排版效果差。基于深度学习的方法用目标检测模型如 LayoutLM、YOLO 系列在文档图像上做区域检测。精度高能处理扫描件和复杂版面但需要 GPU 资源推理速度慢一些。我的建议是混合使用先用规则快速处理电子版 PDF对规则搞不定的页面再走深度学习模型。这样在成本和精度之间取得平衡。具体操作上你可以用 Python 的pdfplumber库提取每个字符的字体、大小、坐标信息然后写规则判断区域类型。对于扫描件用PaddleOCR或者LayoutParser做版面检测。下面是一个简单的规则示例import pdfplumber def classify_block(chars): avg_size sum(c[size] for c in chars) / len(chars) is_bold any(Bold in c[fontname] for c in chars) if avg_size 14 and is_bold: return heading elif avg_size 11: return subheading else: return body这个规则很粗糙但已经能处理大部分结构清晰的文档。关键是要根据你的文档特点调整阈值。我一般会先抽样 20 份文档统计标题和正文的字体大小分布再定阈值。3.2 表格提取别让结构化数据变成乱码表格是 RAG 知识库里的高价值内容也是最容易在解析阶段被毁掉的内容。PDF 表格提取的难点在于PDF 本身不存储表格结构只存储线条和文本的位置。你需要根据线条和文本对齐关系重建表格。常用的工具有工具适用场景优点缺点pdfplumber电子版 PDF有明确表格线精度高API 简单对无边框表格效果差camelot电子版 PDF多种表格类型支持 lattice 和 stream 两种模式依赖 Ghostscript环境配置麻烦tabula简单表格上手快复杂表格容易错位PaddleOCR 表格识别扫描件、图片表格端到端支持无边框需要 GPU速度慢我的经验是有边框的表格用 pdfplumber无边框的表格用 camelot 的 stream 模式扫描件用 PaddleOCR。提取出来的表格一定要转成 Markdown 或 HTML 格式再入库保留行列结构。千万不要把表格拍平成一串文本。举个例子一个产品参数表型号功率重量价格A100100W2.5kg599B200150W3.1kg899如果拍平成“A100 100W 2.5kg 599 B200 150W 3.1kg 899”用户问“B200 的重量是多少”检索很难精准命中。但如果保留 Markdown 表格结构embedding 模型能更好地理解行列关系检索准确率会高很多。3.3 标题层级重建给文档画一张“骨架图”标题层级是文档的骨架。有了骨架你才能做递归切分才能让每个片段携带上下文信息。但 PDF 里的标题往往只是“字体大一点的文本”没有语义标记。重建标题层级的方法是先识别所有候选标题块然后根据字体大小、编号格式如“第一章”“1.1”“一、”推断层级关系。比如字体 18pt编号“第一章” → 一级标题字体 14pt编号“1.1” → 二级标题字体 12pt编号“1.1.1” → 三级标题推断出层级后你可以构建一棵文档树。每个叶子节点是一个内容块每个非叶子节点是一个章节。切分的时候按章节切而不是按固定字数切。这样每个片段都有明确的主题边界不会出现“上半段讲架构下半段讲部署”的情况。我通常会把这个文档树存成 JSON结构大概是这样{ title: 系统设计文档, children: [ { title: 第三章 系统架构, level: 1, children: [ { title: 3.1 数据层, level: 2, content: 数据层采用... } ] } ] }这个结构后续做检索增强时非常有用。你可以在每个片段的开头拼接它的父级标题路径比如“系统设计文档 第三章 系统架构 3.1 数据层”这样即使片段本身没有出现“架构”这个词检索时也能通过标题路径匹配到。3.4 切分策略固定长度是最偷懒也最坑的做法很多人切分文档就是按 500 字一刀切重叠 50 字。这种做法在简单场景下能用但在知识库场景下问题很大。因为文档的语义边界往往不在 500 字的位置。你可能把一段完整的操作步骤切成两半前半段在片段 A后半段在片段 B。用户问“怎么配置”检索到片段 A模型只看到一半步骤回答自然不完整。更好的做法是递归切分优先按标题切标题下内容太长再按段落切段落太长再按句子切。这样每个片段都是语义完整的单元。具体参数上我一般这样设置一级标题下的内容如果不超过 800 字整个作为一个片段超过 800 字按二级标题切二级标题下超过 600 字按段落切段落超过 400 字按句子切相邻片段之间保留 10% 到 15% 的重叠防止边界信息丢失这些数字不是固定的要根据你的文档特点调整。技术文档段落短可以切细一点法律合同段落长可以切粗一点。关键是保持语义完整性而不是追求固定长度。还有一个技巧在切分时给每个片段加上元数据比如来源文件名、章节路径、页码。检索到片段后你可以把这些元数据一起展示给用户方便溯源。模型生成答案时也可以引用这些元数据提高可信度。4. 实操从原始文档到高质量知识库的完整流程4.1 环境准备与工具选型我推荐的技术栈是这样的PDF 解析pdfplumber camelot表格 PaddleOCR扫描件Word 解析python-docxHTML 解析BeautifulSoup readability版面分析LayoutParser可选用于复杂版面切分LangChain 的 RecursiveCharacterTextSplitter 或自己写向量化BGE-M3 或 text-embedding-3-large向量库Milvus 或 Qdrant重排BGE-reranker-v2-m3安装依赖pip install pdfplumber camelot-py[cv] python-docx beautifulsoup4 langchain milvus pymupdf如果你要处理扫描件还需要安装 PaddleOCRpip install paddlepaddle paddleocr这套组合我在多个项目里用过稳定性和效果都不错。成本上除了 embedding 和 LLM 的 API 费用其他都是开源免费的。4.2 文档解析的完整代码实现下面是一个完整的 PDF 解析流程包含版面分析、表格提取和标题层级重建import pdfplumber import camelot from collections import defaultdict def parse_pdf(pdf_path): result { blocks: [], tables: [], metadata: {} } with pdfplumber.open(pdf_path) as pdf: result[metadata][pages] len(pdf.pages) for page_num, page in enumerate(pdf.pages): # 提取字符级信息 chars page.chars if not chars: continue # 按行分组 lines defaultdict(list) for char in chars: line_key round(char[top], 1) lines[line_key].append(char) # 识别每个行的类型 for line_key in sorted(lines.keys()): line_chars sorted(lines[line_key], keylambda c: c[x0]) text .join(c[text] for c in line_chars) avg_size sum(c[size] for c in line_chars) / len(line_chars) is_bold any(Bold in c[fontname] for c in line_chars) block_type classify_block(avg_size, is_bold, text) result[blocks].append({ page: page_num 1, type: block_type, text: text.strip(), size: avg_size, bold: is_bold }) # 提取表格 tables camelot.read_pdf(pdf_path, pagesall, flavorlattice) for table in tables: result[tables].append({ page: table.page, data: table.df.to_dict(records) }) return result def classify_block(size, is_bold, text): if size 16 and is_bold: return h1 elif size 13 and is_bold: return h2 elif size 11 and is_bold: return h3 elif text.strip().startswith((•, -, ·)): return list else: return body这段代码会输出一个结构化的文档表示包含每个块的类型、文本、页码和字体信息。接下来你需要根据这些块重建标题层级。4.3 标题层级重建与递归切分拿到块列表后按顺序遍历遇到标题就压栈遇到正文就挂到当前栈顶的标题下def build_document_tree(blocks): root {title: root, level: 0, children: [], content: []} stack [root] for block in blocks: if block[type] in (h1, h2, h3): level int(block[type][1]) node { title: block[text], level: level, children: [], content: [], page: block[page] } while stack and stack[-1][level] level: stack.pop() stack[-1][children].append(node) stack.append(node) else: stack[-1][content].append(block[text]) return root然后做递归切分def recursive_split(node, max_len800, overlap100): chunks [] # 如果当前节点内容不超过 max_len整个作为一个片段 full_text \n.join(node[content]) if len(full_text) max_len and not node[children]: chunks.append({ text: full_text, path: get_path(node), page: node.get(page) }) return chunks # 否则先处理子节点 for child in node[children]: chunks.extend(recursive_split(child, max_len, overlap)) # 当前节点的直接内容也切分 if full_text: for i in range(0, len(full_text), max_len - overlap): chunk_text full_text[i:i max_len] chunks.append({ text: chunk_text, path: get_path(node), page: node.get(page) }) return chunks def get_path(node): # 返回从根到当前节点的标题路径 path [] current node while current and current[title] ! root: path.insert(0, current[title]) current current.get(parent) return .join(path)这个切分逻辑的核心思想是优先保持语义完整性其次才考虑长度限制。每个片段都携带标题路径检索时可以用路径做过滤或加权。4.4 向量化与入库的注意事项切分完成后每个片段需要向量化。这里有几个坑第一不要只向量化正文。把标题路径拼在正文前面一起向量化效果会好很多。比如系统设计文档 第三章 系统架构 3.1 数据层 数据层采用 PostgreSQL 作为主存储...这样即使正文里没有“架构”这个词检索“系统架构”时也能命中。第二表格单独向量化。表格转成 Markdown 后单独作为一个片段不要和正文混在一起。表格的 embedding 和正文的 embedding 分布差异很大混在一起会互相干扰。第三保留元数据。每个片段入库时把来源文件、页码、章节路径、块类型都存进去。检索时可以按这些字段过滤也可以展示给用户做溯源。Milvus 的 collection schema 大概这样设计from pymilvus import CollectionSchema, FieldSchema, DataType fields [ FieldSchema(nameid, dtypeDataType.INT64, is_primaryTrue, auto_idTrue), FieldSchema(nameembedding, dtypeDataType.FLOAT_VECTOR, dim1024), FieldSchema(nametext, dtypeDataType.VARCHAR, max_length65535), FieldSchema(namesource, dtypeDataType.VARCHAR, max_length512), FieldSchema(namepage, dtypeDataType.INT64), FieldSchema(namepath, dtypeDataType.VARCHAR, max_length1024), FieldSchema(nameblock_type, dtypeDataType.VARCHAR, max_length32), ] schema CollectionSchema(fields)4.5 检索与重排的调优入库之后检索环节也有几个关键参数要调top_k召回数量。太小容易漏太大引入噪声。我一般设 20 到 30然后靠重排精排到 5 到 8 个。相似度阈值低于阈值的直接丢弃。BGE 系列模型一般设 0.5 到 0.6。重排模型BGE-reranker-v2-m3 效果很好能把 top 20 里的正确片段排到前面。混合检索向量检索 关键词检索BM25按权重融合。对于包含专有名词的查询关键词检索能补向量检索的短板。混合检索的融合公式final_score alpha * vector_score (1 - alpha) * bm25_scorealpha 一般设 0.7偏向向量检索。如果查询里专有名词多可以降到 0.5。4.6 一个完整的端到端示例把上面的流程串起来def build_knowledge_base(pdf_paths): all_chunks [] for pdf_path in pdf_paths: # 1. 解析 parsed parse_pdf(pdf_path) # 2. 重建层级 tree build_document_tree(parsed[blocks]) # 3. 递归切分 chunks recursive_split(tree) # 4. 表格单独处理 for table in parsed[tables]: table_md dataframe_to_markdown(table[data]) chunks.append({ text: table_md, path: f{pdf_path} 表格, page: table[page], block_type: table }) # 5. 加上来源信息 for chunk in chunks: chunk[source] pdf_path all_chunks.extend(chunks) # 6. 向量化并入库 embeddings embed_texts([c[text] for c in all_chunks]) insert_to_milvus(all_chunks, embeddings) return len(all_chunks)这个流程跑完你的知识库质量会比直接切分高出一个档次。检索命中率的提升是立竿见影的。5. 常见问题与排查技巧实录5.1 检索命中率低的排查清单当你发现 RAG 答错时按这个顺序排查排查项检查方法常见问题修复方案文档解析质量随机抽 10 个片段人工阅读文本乱序、表格拍平、页眉页脚混入重做解析加版面分析切分边界检查片段是否在句子中间断开固定长度切分导致语义断裂改用递归切分标题路径片段是否携带章节信息缺少上下文检索匹配度低拼接标题路径一起向量化向量模型用相同文本测相似度模型不适合中文或领域不匹配换 BGE-M3 或领域微调top_k 设置看正确片段是否在召回列表里top_k 太小正确片段没召回到增大 top_k加重排相似度阈值看低分片段是否被误召回阈值太低噪声太多提高阈值到 0.5 以上这个清单我用了很多次基本能覆盖 90% 的检索问题。5.2 表格和图片的特殊处理表格处理的核心原则是保留结构单独入库。不要把表格拍平成文本也不要把表格和正文混在一个片段里。表格转成 Markdown 后单独作为一个片段block_type 设为 table。检索时如果查询涉及数值对比或参数查询可以优先召回表格片段。图片的处理更复杂。如果图片里有文字用 OCR 提取出来作为图片的描述文本入库。如果图片是流程图或架构图可以考虑用多模态模型生成描述。但这一步成本较高建议只对高价值图片做。我一般会在解析阶段把图片单独存下来记录页码和位置。然后在切分时在图片位置插入一个占位符比如[图片: 图3-1 系统架构图]。这样检索到这段文本时用户知道这里有一张图可以点击查看原图。5.3 多栏排版和页眉页脚的坑多栏排版是 PDF 解析的经典难题。双栏文档直接抽文本会把左右栏交错。解决方法是用版面分析识别栏边界然后按栏分别抽取。页眉页脚的问题更普遍。很多 PDF 每页都有相同的页眉和页脚直接抽文本会把这些重复内容混进正文。解决方法是在解析阶段识别每页顶部和底部的固定区域直接丢弃。或者用文本相似度检测如果某段文本在超过 80% 的页面出现大概率是页眉页脚。还有一个坑是水印。有些 PDF 带半透明水印抽文本时水印文字会混进正文。这种情况需要用图像处理的方法先去掉水印层或者用 OCR 时设置置信度阈值过滤。5.4 增量更新与版本管理知识库不是一次建好就完事了。文档会更新新文档会加入。你需要一套增量更新机制每个文档用文件哈希做唯一标识新文档入库时先查哈希是否已存在如果存在且哈希相同跳过如果存在但哈希不同删除旧片段插入新片段如果不存在正常插入版本管理上我建议保留每个片段的版本号和生效时间。检索时默认只召回最新版本但可以按时间范围查询历史版本。这对于合同、政策类文档特别重要。5.5 效果评估别凭感觉用数据说话最后说评估。很多人调 RAG 凭感觉觉得“好像好了一点”。这是不靠谱的。你需要一套评估集准备 100 到 200 个真实用户问题每个问题标注正确的文档片段 ID每次调整后跑一遍评估集算命中率Recallk和 MRR对比调整前后的数据确认是否真的有提升我一般用 RAGAS 框架做评估它支持 faithfulness、answer relevancy、context precision 等指标。但最核心的还是检索命中率因为这个指标直接决定了模型能看到什么。评估集的建设本身也有技巧。不要自己编问题要从真实用户日志里捞。用户怎么问你就怎么测。我见过很多团队用自己编的“标准问题”做评估结果上线后效果差很多因为真实用户的问法和预期完全不一样。6. 我踩过的坑和最后分享几个技巧第一个坑过度依赖自动解析。我早期做知识库时觉得工具能搞定一切结果上线后发现大量文档解析错误。后来我加了一步随机抽 5% 的文档做人工校验发现错误就调整解析规则。这一步看似费时但能避免上线后的大规模翻车。第二个坑切分粒度一刀切。不同文档类型需要不同的切分策略。技术手册可以切细一点法律合同要切粗一点。我现在的做法是按文档类型配置不同的切分参数而不是全局一套。第三个技巧在片段开头加“摘要句”。对于长片段我让 LLM 生成一句摘要放在开头。这样即使片段很长embedding 也能抓住核心主题。成本很低效果提升明显。第四个技巧用查询改写提升检索效果。用户的问题往往很短比如“怎么配置”。直接拿这个去检索命中率很低。我加了一步查询改写让 LLM 把用户问题扩展成更完整的查询比如“系统配置的步骤和方法”。改写后的查询检索命中率能提升 15% 到 20%。最后一个建议先把文档解析做扎实再考虑换模型。我见过太多团队在模型上花了大价钱却不愿意在数据预处理上投入时间。这是本末倒置。一个中等规模的 RAG 项目文档解析和切分的工作量应该占到整个项目的 40% 以上。这部分做不好后面全是空中楼阁。
