
问企业把文档喂给RAG系统结果大模型答非所问问题出在哪里答大概率问题不在大模型在文档解析环节。企业文档大多是PDF、扫描件、带复杂表格和双栏排版的报告。大模型本身不具备“看懂”这些格式的能力它只能处理文本。如果文档解析环节没做好喂给大模型的就是一堆乱码。文档解析是RAG系统的第一道关这道关没过后面分块、向量化、检索做得再好都没用。一、企业文档的三种“难搞”类型类型一双栏排版科技论文、行业报告、政府文件、招股说明书最喜欢用双栏排版。如果按页面从左到右、从上到下的顺序读取读到的是“左边栏第一段→右边栏第一段→左边栏第二段→右边栏第二段”上下文完全打乱。大模型拿到这段文字根本无法理解哪些内容是属于同一个段落或同一个论述单元的。用户提问“这篇文章的核心结论是什么”模型可能会把左右栏打乱的内容拼接在一起形成一个逻辑混乱的回答。解法文档解析引擎必须具备版面分析能力——识别页面中的分栏边界Column Detection将每个栏内的内容独立提取、按栏排序后再组合确保同一栏的段落保持原有的逻辑顺序。类型二复杂表格财报里的利润表、招标文件里的技术参数对照表、产品手册里的规格对比表——这些表格往往有跨行跨列、合并单元格、多层表头。如果用传统PDF文本提取工具提取出来的是一串没有结构的文字流横纵坐标关系完全丢失。比如一张“不同型号产品在不同温度下的工作电流”表格提取出来可能是“型号A25℃1.2A 型号A40℃1.5A 型号B25℃0.8A 型号B40℃1.1A”但模型不知道哪个数字对应哪个型号、哪个温度。解法表格解析需要做结构还原——识别表头区域、识别行/列对应关系、重建单元格的坐标体系最终输出JSON或Markdown格式的结构化表格而不是纯文本。大模型拿到结构化表格之后才能正确处理“横向对比”“按条件筛选”这类查询。类型三扫描件图片早期的企业档案、合同扫描件、历史技术文档本质是图片里面没有可提取的文字信息。不做OCR处理的话系统读到的就是空页面。即使做了OCR如果用的是基础OCR引擎对于模糊字迹、手写批注、印章覆盖的文字识别错误率会非常高。“-40℃”可能被识别成“-4O℃”“客户名称”可能被识别成“客户各称”一个字符错了整个答案就错了。解法采用高精度OCR引擎如PaddleOCR、Tesseract、阿里云OCR支持模糊图像增强、旋转校正、手写体识别。关键字段温度数值、型号编号、金额数字要额外做数字识别校验降低单个字符识别错误的影响。二、文档解析的4步标准流程第一步格式识别判断文档类型——是纯文本PDF还是扫描件图片。扫描件走OCR通道纯文本PDF走直接提取通道。混合文档扫描件可编辑文字混合做分页识别不同页面走不同通道。第二步版面分析识别页面结构——分栏边界、表格区域、图片区域、标题/正文/页眉/页脚。这一步决定了后续解析的“布局地图”。版面分析不准后面的解析就是错的。第三步内容提取根据版面分析结果对不同的区域使用不同的提取策略——表格区域走表格结构还原正文区域走段落连贯性重组图片区域走OCR。第四步内容组装把提取出来的内容重新组装成有序的、结构化的文本流保留层级关系章→节→段落→表格输出到下一步的分块模块。三、3个必须做好的工程细节细节一数字和单位不能分开表格里的“温度-40℃~85℃”提取出来后如果被错误地拆成“温度”“-40”“℃~85”“℃”几个碎片大模型就无法正确理解这是一个完整的温度范围参数。必须在提取环节就做数字和单位的绑定识别把“-40℃~85℃”作为一个完整的数值单元输出。细节二页眉页脚必须剔除PDF文档的每一页都有页眉章节名和页脚页码、公司名。如果不剔除分块时这些重复信息会被嵌入到每个信息块里干扰向量检索的精度。版面分析阶段要标记页眉页脚区域内容提取时直接丢弃。细节三多页表格要拼接有些大表格跨了3-4页如果不做拼接处理每一页提取出来的都是一个“半截表格”单独看没有意义。做法是检测跨页表格的特征——表头在上一页重复出现、列数相同——自动识别跨页表格把多页内容合并成一个完整的表格后再做结构化输出。FAQQ开源PDF解析库能用吗A能用但不全能用。PyPDF2适合处理纯文本PDFpdfplumber支持表格提取但双栏排版处理不了paddleocr适合扫描件。企业场景建议组合使用——pdfplumber做表格、paddleocr做扫描件、自研版面分析做双栏重组。不要指望一个库解决所有问题。Q文档解析一次要花多久A100页的PDF纯文本解析约1-2秒扫描件OCR约30-60秒。如果文档量很大每天数百份建议做异步处理——上传后先入队后台慢慢解析解析完成后通知用户。Q解析完了怎么确认效果好不好A抽样人工检查。随机抽10份文档看提取后的文本流是否符合阅读逻辑——表格是否完整、段落是否连贯、双栏顺序是否正确。如果抽样合格率低于90%说明解析策略需要调整。总结文档解析是RAG系统最容易被忽视但最致命的环节。不要在文档解析环节省力气——前面省10%的力气后面检索和生成要花90%的力气去填坑。一份“干净”的文档输入直接决定了整个RAG系统的上限。