MindCarver Blog

MindCarver

MindCarver

技术服务于产品

Day16-文档解析与清洗

38分钟阅读

Day 16：文档解析与清洗

学习目标

昨天我们建立了 RAG 系统的全景认知，知道了”先搜后答”的完整流程。今天开始进入第一个工程环节：文档解析与清洗。

这是整个 RAG 管线的起点。如果这一步做不好，后面的切分会乱、向量化会差、检索会偏、答案自然好不了。可以把它比作做菜之前的食材处理——鱼鳞没刮干净，调料再好也白搭。

今天的目标是理解企业中常见的文档格式、每种格式的解析难点、清洗的原则和方法、以及元数据提取的标准。学完之后，你应该能够为一个企业知识库项目设计出合理的文档处理方案，知道面对一堆乱七八糟的文档该从哪里下手。

核心概念

一、PDF 解析

PDF 是企业中最常见的文档格式，也是解析难度最大的格式之一。理解 PDF 的解析问题，是掌握文档处理的关键。

PDF 的本质。 PDF（Portable Document Format）的设计初衷是”在任何设备上看起来都一样”。它的核心是排版信息，不是内容信息。一个 PDF 文件记录的是”在页面坐标 (x, y) 处用 12pt 的 Times New Roman 字体渲染文字’Hello’“，而不是”这里有一段文本，内容是’Hello’”。

这个设计目标导致了 PDF 解析的根本困难：PDF 不关心内容的逻辑结构，只关心视觉呈现。你要从视觉信息中反推内容结构，这本质上是一个”逆向工程”。

PDF 解析的三种方式：

第一种是文本提取。直接从 PDF 文件中提取嵌入的文本信息。这适用于”文字型 PDF”——就是用 Word 或 LaTeX 生成的、文字可以被选中和复制的 PDF。这种方式速度快、准确率高，但对”扫描型 PDF”（由扫描仪生成的图片 PDF）完全无效。

第二种是 OCR（光学字符识别）。对每一页 PDF 进行图像识别，提取其中的文字。这适用于扫描件、照片中的文字、以及一些无法直接提取文本的 PDF。OCR 的准确率受图像质量、字体、语言、排版复杂度影响很大。现代 OCR 工具在干净的单栏文档上表现已经相当不错，但在多栏排版、手写批注、表格密集的页面上仍然容易出错。

第三种是视觉模型解析。这是最近两年兴起的方法，用多模态大模型（如 GPT-4V、Claude 等视觉模型）直接”看”PDF 页面的图像，理解其中的内容结构和语义。这种方法在处理复杂排版（多栏、嵌套表格、图文混排）时效果最好，但成本也最高，处理速度最慢。

PDF 解析的具体挑战：

  • 多栏排版。 学术论文和杂志通常采用双栏排版。文本提取时如果不考虑排版，左栏的最后一行会和右栏的第一行混在一起，导致文本顺序完全错乱。
  • 页眉页脚。 每页重复出现的页眉（文档标题、章节名）和页脚（页码、版权声明）会污染正文内容。如果不去掉，这些重复文本会被当作文档内容参与检索，干扰结果。
  • 表格。 PDF 中的表格是视觉上的格子，但文本提取出来后，行列关系会丢失，变成一段毫无结构的文本。而表格中的信息往往是非常重要的数据。
  • 图片中的文字。 很多 PDF 包含嵌入的图片，图片中的文字（如流程图中的标注、截图中的内容）无法通过文本提取获得。
  • 公式。 数学公式在 PDF 中是用特殊字体渲染的，文本提取出来通常是一堆乱码。
  • 书签和目录。 PDF 文件可能包含书签信息，这其实是很有价值的结构信息，但简单的文本提取会忽略它。

二、Markdown 解析

Markdown 是对 RAG 系统最友好的文档格式，没有之一。

为什么 Markdown 是最友好的？ 因为 Markdown 本身就是纯文本，天然带有结构标记。# 表示一级标题，## 表示二级标题，- 表示列表项，| 表示表格行。这些标记既人类可读，又机器可解析。你不需要做任何”逆向工程”，直接读取文件内容就行。

Markdown 的解析要点：

  • 标题层级。 Markdown 的标题（#、##、### 等）天然提供了文档的结构信息。解析时应该提取标题层级，作为后续切分的边界依据。
  • 代码块。 用三个反引号包围的代码块需要特殊处理。代码块不应该被当作普通文本切分，因为它有自己完整的逻辑含义。
  • 表格。 Markdown 表格用 | 分隔，解析相对容易。但要注意表格可能很宽或很长，直接作为一个整体文本块可能太大。
  • 链接和图片。 Markdown 中的链接和图片标记需要决定是保留还是去掉。链接的 URL 可能没意义，但链接的文字描述可能有价值。图片如果只有 alt text 而没有实际内容，可能需要忽略。
  • 列表。 有序列表和无序列表在 Markdown 中有明确的标记。列表项之间有逻辑关系，切分时需要考虑列表的完整性。

Markdown 的优势在于它是”文本优先”的格式。 它的设计目标就是让人专注于内容而非排版。这和 PDF 的设计目标恰好相反。所以在 RAG 系统中，如果能选择文档格式，优先选择 Markdown。

三、Word 解析

Word 文档（.docx 格式）是企业内部最常见的文档格式之一。

Word 文件的技术结构。 .docx 文件本质上是一个 ZIP 压缩包，里面包含了一组 XML 文件和资源文件。核心的内容存储在 word/document.xml 中，样式信息在 word/styles.xml 中，图片等媒体文件在 word/media/ 目录中。

解析方式：

  • python-docx 库。 这是最常用的 Python Word 解析库。它可以提取段落文本、表格内容、样式信息（标题层级、加粗、斜体等）。但它在处理复杂排版（嵌套表格、文本框、嵌入对象）时力不从心。
  • 直接解析 XML。 对于 python-docx 处理不了的情况，可以直接解压 .docx 文件，解析其中的 XML。这种方式更灵活，但开发成本更高。
  • 转换后解析。 先把 Word 文档转换成 Markdown 或纯文本，再用对应的方式解析。这种间接方式在某些场景下更稳定。

Word 解析的挑战：

  • 样式到结构的映射。 Word 文档中并没有严格的”标题”概念，只有”应用了标题样式的段落”。如果作者没有使用正确的样式（比如用加粗的大字号正文代替标题），解析时就会丢失结构信息。
  • 表格。 Word 中的表格支持合并单元格，这使得解析复杂度显著增加。一个简单的三行四列表格还好，但如果存在合并单元格，行列对应关系就不那么直接了。
  • 嵌入对象。 Word 文档可以嵌入 Excel 图表、Visio 图、公式编辑器生成的公式等。这些嵌入对象的内容通常无法通过标准 API 提取。
  • 修订和批注。 如果文档开启了修订模式，解析出来的文本可能包含删除线和新增标记，需要特殊处理。

四、Excel 解析

Excel 文件在 RAG 场景中的处理方式和文本文档有很大不同。

Excel 的特殊性。 Excel 本质上是结构化数据，不是自然语言文本。一个单元格可能是一个数字、一个日期、一个公式、或者一段短文本。直接把所有单元格的内容拼成一段文本，语义会非常混乱。

解析方式：

  • pandas 库。 用 pandas 读取 Excel 文件是最直接的方式。可以获取每个 sheet 的数据，以 DataFrame 形式处理。
  • openpyxl 库。 比 pandas 更底层，可以获取单元格的格式信息（合并单元格、数据类型、公式等）。

Excel 在 RAG 中的处理策略：

  • 描述性文本化。 不直接把表格数据塞进 RAG，而是把表格内容转换成自然语言描述。比如一个产品价格表，不是存储”产品A | 100元”，而是存储”产品A的价格是100元”。这种转换需要根据表格类型设计不同的转换规则。
  • 摘要化。 对于大型数据表，不逐行处理，而是生成表格的摘要描述。比如”该表包含 2024 年 1-12 月的销售数据，涵盖华东、华南、华北三个区域，月均销售额约 500 万元”。
  • 元数据提取。 提取表格的基本信息（sheet 名、列名、行数、数据类型），作为元数据存储，支持后续的结构化查询。

什么时候应该把 Excel 纳入 RAG 知识库？ 这取决于 Excel 中存储的是什么。如果是操作手册中的数据表、产品规格参数表，适合纳入。如果是原始的交易流水、日志数据，不适合纳入 RAG，而应该通过 Tool Calling 直接查询。

五、HTML 解析

HTML 文档的解析在技术上最成熟，因为 Web 生态已经发展了几十年。

解析方式：

  • BeautifulSoup。 Python 中最常用的 HTML 解析库。可以按标签、class、id 等选择器提取内容。
  • readability 算法。 借鉴浏览器”阅读模式”的思路，从 HTML 页面中提取正文内容，去掉导航栏、广告、侧边栏等无关内容。
  • trafilatura 库。 专门用于从网页中提取正文文本的 Python 库，效果通常比 BeautifulSoup 手工提取好。

HTML 解析的要点：

  • 去掉标签保留文本。 HTML 标签本身是排版信息，应该被去掉，只保留文本内容。但某些标签（h1-h6 表示标题、table 表示表格、ul/ol 表示列表）包含结构信息，解析时应该利用。
  • 处理特殊字符。 HTML 中有大量实体编码（& <   等），需要转换成对应的字符。
  • JavaScript 渲染的内容。 很多现代网页的内容是通过 JavaScript 动态加载的，直接请求 HTML 源码获取不到这些内容。这时候需要用浏览器自动化工具（如 Playwright、Selenium）来渲染页面后提取。

六、OCR 识别

OCR（Optical Character Recognition，光学字符识别）是文档解析中的”最后手段”——当文本提取和格式解析都走不通的时候，用 OCR 来”看”文档中的文字。

OCR 的适用场景：

  • 扫描件 PDF（由扫描仪生成的图片 PDF）
  • 照片中的文字
  • 图片格式的文档（JPEG、PNG 等）
  • PDF 中嵌入的图片里的文字

OCR 的主流工具：

  • Tesseract。 开源 OCR 引擎，支持多语言，免费但准确率一般。适合对准确率要求不高的场景。
  • PaddleOCR。 百度开源的 OCR 工具，中文识别效果在开源工具中名列前茅。支持表格识别、版面分析。
  • 云服务 OCR。 各大云厂商（AWS Textract、Azure Form Recognizer、Google Cloud Vision）提供的 OCR 服务，效果最好但需要付费。
  • 多模态大模型。 GPT-4V、Claude 等视觉模型可以直接识别图片中的文字，准确率很高，还能理解排版结构。但成本最高，速度最慢。

OCR 的挑战：

  • 准确率。 即使最好的 OCR 也不可能 100% 准确。识别错误在专有名词、数字、符号上尤其常见。“退货”被识别成”退赁”、“1000 元”被识别成”1000 兀”——这类错误对 RAG 系统是致命的。
  • 排版理解。 OCR 能识别单个字符，但理解”这些字符属于同一个表格”或”这里是正文区域、那里是页眉”需要额外的版面分析能力。
  • 语言混合。 企业文档中经常出现中英混排，甚至日文、韩文混合。OCR 需要支持多语言识别。

七、文本清洗

解析出来的原始文本通常不能直接用于 RAG，需要经过清洗。

清洗的核心原则：保留有价值的内容，去除噪声，保留结构信息。

常见的清洗操作：

  • 去页眉页脚。 通过模式匹配或频率分析，识别每页重复出现的页眉和页脚文本并去掉。
  • 去水印。 有些文档有水印文字（如”机密”、“草稿”），这些文字会在每个页面重复出现，需要去掉。
  • 去乱码。 文本提取过程中产生的无意义字符序列（通常是编码错误导致的）。
  • 去多余空白。 连续的空格、空行、制表符需要合并和清理。
  • 去页码。 页码通常出现在页脚，但如果页脚清理不干净，残留的孤立数字需要二次清理。
  • 修正常见 OCR 错误。 根据上下文修正常见的 OCR 识别错误。比如把”O”（字母）修正为”0”（数字），把”l”（小写 L）修正为”1”（数字）。
  • Unicode 规范化。 统一全角半角字符，统一引号样式，统一破折号格式。
  • 去导航文本。 对于 HTML 来源的文本，去掉”首页 > 产品中心 > 产品详情”这类面包屑导航文本。

清洗的度： 清洗不是越彻底越好。过度清洗可能丢失有价值的信息。比如去掉所有数字可能导致”退款金额 500 元”变成”退款金额 元”，完全失去了意义。清洗规则需要针对具体文档类型调优，不能一刀切。

八、表格处理

表格是文档解析中最难处理的内容类型之一，也是信息密度最高的部分。

表格处理的两种策略：

  • 文本序列化。 把表格转换成文本序列，保留行列关系。比如”表格第 1 行：产品名称 | 单价 | 库存量。第 2 行：产品 A | 100 元 | 50 件。“这种方式的优点是保留完整信息，缺点是格式冗长。
  • 语义描述。 把表格内容用自然语言描述出来。比如”产品 A 的单价是 100 元，当前库存量为 50 件。“这种方式的优点是语义清晰，适合 RAG 检索，缺点是转换逻辑需要针对不同表格类型设计。

表格处理的关键原则： 表格中的信息不能丢失。如果你发现解析后的文本中找不到表格中的某个数据点，说明解析过程有问题。在 RAG 系统中，丢失表格数据意味着用户问相关问题时检索不到答案。

九、元数据提取

元数据是”关于数据的数据”。在 RAG 系统中，元数据不是用来检索的主体内容，而是用来辅助检索和过滤的信息。

应该提取的元数据字段：

  • 文档级别： 文件名、文件路径、文件类型、文件大小、创建时间、修改时间、文档标题、作者、部门
  • 章节级别： 章节标题、章节层级、章节在文档中的位置
  • 段落级别： 所属章节、在页面中的位置、页码
  • 内容类型： 是正文、表格、列表、还是代码块

元数据的作用：

  • 检索过滤。 用户可以指定”只在合同文档中搜索”或”只看 2024 年更新的文档”。元数据让这种过滤成为可能。
  • 来源标注。 回答用户问题时，可以标注”该信息来自《XX 产品手册》第 3 章第 12 页”。
  • 切分参考。 标题层级可以作为切分的天然边界。
  • 版本管理。 通过修改时间判断文档是否需要重新索引。

概念关系图

文档解析与清洗全流程
=========================================================

[原始文档输入]
    |
    +-- [PDF] -------> 文本提取 / OCR / 视觉模型 ---> 原始文本
    +-- [Markdown] ---> 直接读取 -------------------> 原始文本
    +-- [Word] -------> python-docx / XML 解析 -----> 原始文本
    +-- [Excel] -------> pandas / openpyxl ---------> 结构化数据
    +-- [HTML] -------> BeautifulSoup / readability -> 原始文本
    |
    v
[文本清洗管线]
    |
    +-- 去页眉页脚
    +-- 去水印
    +-- 去乱码
    +-- 去多余空白
    +-- Unicode 规范化
    +-- OCR 错误修正
    |
    v
[结构信息提取]
    |
    +-- 标题层级
    +-- 段落边界
    +-- 表格内容
    +-- 列表结构
    +-- 代码块
    |
    v
[元数据标注]
    |
    +-- 来源文件
    +-- 章节信息
    +-- 页码
    +-- 内容类型
    |
    v
[清洗后文本 + 元数据] -----> 送入 Chunking 环节


不同文档格式的解析难度对比
=========================================================

格式        解析难度    结构保留    表格处理    排版理解
--------------------------------------------------------
Markdown    低          高          中          不涉及
HTML        低          高          高          不涉及
Word        中          中          中          不涉及
Excel       中          不适用      高          不涉及
PDF(文字)   高          低          低          高
PDF(扫描)   很高        很低        很低        高

实战分析

任务一：解析 5 类文档

这是今天最核心的实战任务。找 5 种不同格式的文档，分别设计解析方案。

PDF 文档。 找一份公司的产品手册或技术规范（通常 10-30 页）。尝试用文本提取方式获取内容。检查提取结果中是否有乱码、断行、多栏错乱等问题。如果效果不好，尝试 OCR 方式。

Markdown 文档。 找一篇技术博客或开源项目的 README。直接读取文件内容，提取标题层级。这是最简单的，应该几分钟就能完成。

Word 文档。 找一份公司内部的规章制度文档。用解析库提取段落文本和标题结构。检查样式信息是否正确反映了文档结构。

Excel 文档。 找一个产品参数表或价格表。思考如何将表格内容转换成适合 RAG 检索的文本形式。尝试不同的文本化策略（逐行描述、摘要描述、键值对描述），对比哪种更适合后续检索。

HTML 文档。 找一个公司官网的产品介绍页面。尝试提取正文内容，去掉导航栏和页脚。对比直接提取和 readability 算法的效果差异。

任务二：清洗无效字符

对解析出来的文本进行清洗。重点做以下几件事：

统一字符编码。 确保所有文本都是 UTF-8 编码。如果有 GBK、GB2312 等编码的文本，先做编码转换。

去除控制字符。 文本中可能包含不可见的控制字符（如零宽空格、回车符、换行符），这些字符对检索没有意义，还可能干扰后续的切分和 Embedding。

处理断裂词。 PDF 提取时，跨行的单词可能被断开（如”知识-库”中间有换行）。需要根据规则合并这些断裂词。

去除重复内容。 页眉页脚、水印文字会在每页重复。可以通过统计文本片段在文档中的出现频率来识别这些重复内容。

任务三：提取标题、章节、页码

从清洗后的文本中提取结构信息。

标题识别。 根据文档类型使用不同的策略：

  • Markdown：直接用 # 标记识别
  • Word：根据段落样式（Heading 1-6）识别
  • PDF：根据字号、加粗、缩进等视觉特征识别（难度较大）
  • HTML：根据 h1-h6 标签识别

章节划分。 用标题作为边界，将文档划分成章节。每个章节记录其起始位置和层级。

页码记录。 对于 PDF 文档，记录每个文本片段对应的页码。这对于后续的引用标注非常重要。

任务四：保存文档元数据

设计一个统一的元数据结构，适用于所有文档类型。

每个文档的元数据应该包含：

  • 文档基本信息（文件名、类型、大小、上传时间）
  • 文档内容统计（总字符数、段落数、章节数）
  • 处理信息（解析方式、清洗规则、处理时间、是否有错误）

每个文本片段的元数据应该包含：

  • 来源文档 ID
  • 所属章节标题和层级
  • 页码（如果可获取）
  • 内容类型（正文/表格/列表/代码）
  • 在文档中的相对位置

当日产物说明

产物一：《文档解析脚本》

这不是让你写一个完美的通用解析器，而是针对你选择的 5 种测试文档，设计解析方案并记录每个文档的解析过程。

应该包含：

  • 每种文档类型的解析策略说明
  • 使用的工具或库的选择理由
  • 解析过程中遇到的问题和解决方法
  • 最终解析效果的评估（保留了多少内容、丢失了什么）

质量标准： 另一个人按照你的方案，可以对同类型文档完成基本的文本提取。不需要面面俱到，但关键步骤和踩坑点要记录清楚。

产物二：《文档清洗规则》

这是一份清洗规则的清单，记录你对不同类型噪声的处理方法。

应该包含：

  • 每种噪声类型的识别方法（怎么判断这是噪声）
  • 每种噪声类型的处理方法（怎么去掉或修正）
  • 规则的适用范围和注意事项
  • 可能误杀的内容和相应的保护措施

质量标准： 规则清晰、可执行。不是”大概去掉没用的内容”，而是”遇到 XX 模式的文本，执行 YY 操作”。

产物三：《元数据设计表》

这是文档和文本片段的元数据字段定义。

应该包含：

  • 每个字段的名称、类型、含义
  • 哪些字段是必填的、哪些是可选的
  • 每个字段的取值示例
  • 不同文档类型在元数据上的差异

质量标准： 字段定义清晰、类型明确、含义无歧义。后续切分和检索模块的开发者可以直接基于这个设计来工作。

常见误区与避坑

误区一：解析就是读文件

很多初学者以为文档解析就是用 Python 的 open() 函数读文件内容。实际上，PDF、Word、Excel 这些二进制格式不能直接用文本方式读取。即使读取了，原始内容中包含了大量排版信息、控制字符、二进制数据，需要专门的解析工具来提取有意义的文本内容。

文档解析的核心挑战不是”读到数据”，而是”理解数据”。同样一行文字，它是正文还是页脚？它是标题还是加粗的强调？这些判断需要结合格式信息、位置信息、甚至上下文来综合判断。

误区二：PDF 都是一样的

PDF 的质量参差不齐，解析难度差异巨大。一个用 LaTeX 生成的学术论文 PDF，文本提取效果通常很好。一个扫描的合同 PDF，文本提取可能完全拿不到内容。一个用设计软件排版的宣传册 PDF，多栏、图文混排、艺术字体，文本提取出来的顺序可能完全错乱。

在开始解析之前，先对 PDF 文档做一个分类：文字型还是扫描型？单栏还是多栏？有没有复杂表格？根据分类选择合适的解析策略，而不是用一套方案处理所有 PDF。

误区三：清洗越彻底越好

过度清洗会丢失有价值的信息。我见过一个案例，清洗规则把所有包含”第 X 章”模式的文本都当作页眉去掉了，结果文档的章节标题全没了，后续切分完全失去了结构依据。

清洗的原则是”保守操作”：宁可少去一些噪声，也不要误杀有价值的内容。对于不确定是否是噪声的文本，宁可保留，通过人工审核或后续环节来处理。

误区四：忽略表格中的信息

表格是文档中信息密度最高的部分，也是最容易被解析忽略的部分。很多解析方案只提取了文本段落，对表格要么跳过要么处理得很粗糙。结果就是 RAG 系统回答不了关于表格内容的问题。

表格处理确实困难，但它的价值决定了你不能跳过。即使做不到完美的表格解析，至少应该把表格内容以某种形式保留下来，哪怕是最基础的文本序列化。

误区五：不保存元数据

元数据不是可有可无的附加信息，而是 RAG 系统正常运行的基础设施。没有元数据，你不知道检索到的内容来自哪里、不知道答案引用的出处、不能按文档类型或时间过滤检索范围、不知道知识库中有哪些文档需要更新。

从第一天就把元数据设计好，和文本内容一起保存。后面加元数据比一开始就设计好要痛苦得多。

延伸思考

文档解析与 Day 17 Chunking 的衔接

今天的解析和清洗输出的是”干净的文本 + 结构信息 + 元数据”。明天要做的切分会直接依赖这些输出：

  • 标题层级信息决定切分的边界
  • 段落边界是最基本的切分单元
  • 表格内容可能需要作为独立的 Chunk
  • 元数据会附着在每个 Chunk 上

如果今天的解析质量不好（比如没有提取标题层级），明天的切分就只能用最原始的”固定长度切分”方法，效果会大打折扣。

企业环境中的文档治理

文档解析的技术挑战只是一半，另一半是组织层面的挑战：

  • 文档散落在各个系统（SharePoint、Confluence、钉钉文档、本地文件服务器）中，如何统一收集？
  • 文档格式混乱，同一份文档可能同时存在 Word、PDF、扫描件三个版本，如何去重？
  • 文档更新频繁，如何自动检测文档变更并触发重新索引？
  • 文档权限不同，如何确保 RAG 系统不会把法务部的机密文档展示给实习生？

这些不是纯技术问题，而是需要技术和流程配合解决的治理问题。在给客户设计知识库方案时，文档治理方案和 RAG 技术方案同样重要。

多模态文档处理的未来

企业文档不只是文字。流程图、架构图、组织结构图、数据可视化图表——这些视觉信息在传统 RAG 中被完全忽略了。

多模态大模型的出现为这个问题提供了新的解决思路。用视觉模型理解图表内容，把图表信息转换成文本描述，再纳入 RAG 系统。这个方向正在快速发展，值得持续关注。

自测问题

  1. PDF 的设计目标是什么？这个目标为什么导致 PDF 解析困难？

  2. PDF 解析的三种主要方式分别是什么？各自的适用场景和局限是什么？

  3. 为什么说 Markdown 是 RAG 系统最友好的文档格式？

  4. Word 文档解析中，“样式到结构的映射”问题是什么？举个具体例子说明。

  5. Excel 表格在 RAG 中应该如何处理？直接把单元格拼成文本行不行？为什么？

  6. 文本清洗的核心原则是什么？为什么”清洗越彻底越好”是错误的？

  7. 元数据在 RAG 系统中的四个作用是什么？如果没有元数据，RAG 系统会缺什么能力？

  8. 设计一个统一的元数据结构，列出至少 8 个字段，说明每个字段的含义和用途。

  9. 对于一份扫描件 PDF，你会选择什么样的解析策略？为什么？

  10. 文档解析阶段最容易犯的三个错误是什么？分别会导致什么后果？

关键词

  • PDF 解析：从 PDF 文件中提取文本、结构、表格等内容的过程，是文档解析中难度最大的部分
  • OCR（光学字符识别）：通过图像识别技术提取图片或扫描件中文字的技术
  • Markdown 解析：从 Markdown 格式文件中提取文本和结构信息的过程，最简单的文档解析
  • 文本清洗：去除解析文本中的噪声（页眉页脚、乱码、水印等），保留有价值内容的过程
  • 元数据（Metadata）：描述文档和文本片段属性的数据，包括来源、结构、位置等信息
  • 表格序列化：将表格内容转换成文本形式的方法，保留行列关系
  • 版面分析：识别文档页面中不同区域（正文、标题、表格、图片）的位置和类型
  • Unicode 规范化：统一不同编码形式的字符，如全角半角统一、引号样式统一
  • 文本提取：直接从文档文件中获取嵌入的文本内容，不需要 OCR
  • 视觉模型解析：用多模态大模型直接理解文档页面的视觉内容，提取文本和结构信息

关系图谱