GLM-OCR公式编号合并算法为什么公式和编号要合并成一个块【免费下载链接】GLM-OCRGLM-OCR: Accurate × Fast × Comprehensive项目地址: https://gitcode.com/GitHub_Trending/gl/GLM-OCR在使用GLM-OCR将 PDF 论文、教材转换成 Markdown 时你是否遇到过这种尴尬公式被完整识别了可旁边的编号(1)却被单独拆成一截孤零零的文字和公式隔开了几个空行公式编号合并算法正是为解决这个痛点而生的——它把布局检测拆散的公式块与编号块重新拼回一个整体让输出里的每个公式都带着自己的编号干净、完整、可引用。1️⃣ 痛点编号为什么总被拆散问题出在 GLM-OCR 的解析流程上。它先由版面检测模型PP-DocLayoutV3把页面切成一个个语义区域再逐个区域做 OCR 识别。在 25 类版面标签中公式display_formula和公式编号formula_number是两类独立的区域公式通常居中编号靠右对齐两个框在页面上互不重叠检测模型不会把它们框成同一个区域每个区域独立送 OCR编号区域识别出的就是(1)这样短短几个字符。结果就是JSON 里有两条相邻记录Markdown 里公式和编号被分成两段像这样——E mc^2 (1)对于式 (1) 表明……这类引用编号和公式被拆开会让后续的结构化解析、PDF 回转、公式检索全部失去关联。2️⃣ 合并算法三步走后处理阶段ResultFormatter按阅读顺序扫描整页区域列表执行 _merge_formula_numbers 方法核心逻辑只有三步第一步识别相邻的公式 编号组合。算法同时兼容两种顺序——顺序场景处理方式公式 → 编号编号在公式下方/识别顺序靠后取下一块确认是formula_number编号 → 公式编号被排在公式前面当前块是编号且下一块是formula为什么两种都要处理因为版面区域是按阅读顺序index排序的编号究竟排在公式前还是后取决于检测框的位置两种情况在真实文档中都会出现算法必须都兜住。第二步清洗编号内容。借助 clean_formula_number 工具函数去掉全角或半角括号(1) → 1 2.1 → 2.1 3 → 3第三步用 LaTeX 的\tag{}把编号挂回公式上。编号不是简单拼接成文本而是作为\tag{}插入公式末尾合并前 $$E mc^2$$ (1) 合并后 $$E mc^2 \tag{1}$$这是 LaTeX 显示公式的标准编号写法任何支持 KaTeX/MathJax 的渲染器都能正确显示Markdown 转 PDF、转网页时编号位置也完全符合排版习惯。3️⃣ 藏在源码里的三个细节细节一为什么只有公式以\n$$结尾才合并因为格式化阶段会先把所有独立公式统一包装成$$\n...\n$$的标准形式以\n$$结尾恰好证明它是一个完整的独立公式块避免误伤行内公式。细节二合并后重排 index。编号块被吸收后剩余区域的index会重新从 0 编号保证下游按序号取块时不出现空洞。细节三编号块若找不到相邻公式会被直接丢弃。孤立的(1)留在正文里只会制造噪声算法选择让它消失。这些行为都受配置开关控制config.py 中enable_merge_formula_numbers默认为True你也可以在 config.yaml 里关掉它做对照实验。同级的enable_merge_text_blocks连字符断行合并和enable_format_bullet_points列表项补全与公式合并算法并列共同构成 GLM-OCR 的 Markdown 净化流水线实现见 postprocess/result_formatter.py。4️⃣ 合并之后公式识别的完整闭环合并算法是最后一公里它的前提是公式本身识别得准。GLM-OCR 对display_formula区域使用专门的公式识别提示词能输出 LaTeX 格式的公式化学结构、分式、矩阵均支持样例见 examples/finetune编号区域则走通用文本识别。识别、清洗、合并三步串起来最终得到编号与公式天然绑定的干净 Markdown文档结构解析器可以直接按$$...$$整块取出公式\tag{}里的编号随手可查论文引用如式 (2.1) 所示在转换后的文档中依然成立前端预览如 apps/frontend 的 OCR 结果页渲染公式时不再出现编号飘走的错位。一句话总结布局检测负责看得准公式编号合并算法负责拼得对——把检测模型拆开的公式与编号用 LaTeX 原生的\tag{}机制重新缝合是 GLM-OCR 输出质量从能看到能用的关键一步。【免费下载链接】GLM-OCRGLM-OCR: Accurate × Fast × Comprehensive项目地址: https://gitcode.com/GitHub_Trending/gl/GLM-OCR创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
GLM-OCR公式编号合并算法：为什么公式和编号要合并成一个块
GLM-OCR公式编号合并算法为什么公式和编号要合并成一个块【免费下载链接】GLM-OCRGLM-OCR: Accurate × Fast × Comprehensive项目地址: https://gitcode.com/GitHub_Trending/gl/GLM-OCR在使用GLM-OCR将 PDF 论文、教材转换成 Markdown 时你是否遇到过这种尴尬公式被完整识别了可旁边的编号(1)却被单独拆成一截孤零零的文字和公式隔开了几个空行公式编号合并算法正是为解决这个痛点而生的——它把布局检测拆散的公式块与编号块重新拼回一个整体让输出里的每个公式都带着自己的编号干净、完整、可引用。1️⃣ 痛点编号为什么总被拆散问题出在 GLM-OCR 的解析流程上。它先由版面检测模型PP-DocLayoutV3把页面切成一个个语义区域再逐个区域做 OCR 识别。在 25 类版面标签中公式display_formula和公式编号formula_number是两类独立的区域公式通常居中编号靠右对齐两个框在页面上互不重叠检测模型不会把它们框成同一个区域每个区域独立送 OCR编号区域识别出的就是(1)这样短短几个字符。结果就是JSON 里有两条相邻记录Markdown 里公式和编号被分成两段像这样——E mc^2 (1)对于式 (1) 表明……这类引用编号和公式被拆开会让后续的结构化解析、PDF 回转、公式检索全部失去关联。2️⃣ 合并算法三步走后处理阶段ResultFormatter按阅读顺序扫描整页区域列表执行 _merge_formula_numbers 方法核心逻辑只有三步第一步识别相邻的公式 编号组合。算法同时兼容两种顺序——顺序场景处理方式公式 → 编号编号在公式下方/识别顺序靠后取下一块确认是formula_number编号 → 公式编号被排在公式前面当前块是编号且下一块是formula为什么两种都要处理因为版面区域是按阅读顺序index排序的编号究竟排在公式前还是后取决于检测框的位置两种情况在真实文档中都会出现算法必须都兜住。第二步清洗编号内容。借助 clean_formula_number 工具函数去掉全角或半角括号(1) → 1 2.1 → 2.1 3 → 3第三步用 LaTeX 的\tag{}把编号挂回公式上。编号不是简单拼接成文本而是作为\tag{}插入公式末尾合并前 $$E mc^2$$ (1) 合并后 $$E mc^2 \tag{1}$$这是 LaTeX 显示公式的标准编号写法任何支持 KaTeX/MathJax 的渲染器都能正确显示Markdown 转 PDF、转网页时编号位置也完全符合排版习惯。3️⃣ 藏在源码里的三个细节细节一为什么只有公式以\n$$结尾才合并因为格式化阶段会先把所有独立公式统一包装成$$\n...\n$$的标准形式以\n$$结尾恰好证明它是一个完整的独立公式块避免误伤行内公式。细节二合并后重排 index。编号块被吸收后剩余区域的index会重新从 0 编号保证下游按序号取块时不出现空洞。细节三编号块若找不到相邻公式会被直接丢弃。孤立的(1)留在正文里只会制造噪声算法选择让它消失。这些行为都受配置开关控制config.py 中enable_merge_formula_numbers默认为True你也可以在 config.yaml 里关掉它做对照实验。同级的enable_merge_text_blocks连字符断行合并和enable_format_bullet_points列表项补全与公式合并算法并列共同构成 GLM-OCR 的 Markdown 净化流水线实现见 postprocess/result_formatter.py。4️⃣ 合并之后公式识别的完整闭环合并算法是最后一公里它的前提是公式本身识别得准。GLM-OCR 对display_formula区域使用专门的公式识别提示词能输出 LaTeX 格式的公式化学结构、分式、矩阵均支持样例见 examples/finetune编号区域则走通用文本识别。识别、清洗、合并三步串起来最终得到编号与公式天然绑定的干净 Markdown文档结构解析器可以直接按$$...$$整块取出公式\tag{}里的编号随手可查论文引用如式 (2.1) 所示在转换后的文档中依然成立前端预览如 apps/frontend 的 OCR 结果页渲染公式时不再出现编号飘走的错位。一句话总结布局检测负责看得准公式编号合并算法负责拼得对——把检测模型拆开的公式与编号用 LaTeX 原生的\tag{}机制重新缝合是 GLM-OCR 输出质量从能看到能用的关键一步。【免费下载链接】GLM-OCRGLM-OCR: Accurate × Fast × Comprehensive项目地址: https://gitcode.com/GitHub_Trending/gl/GLM-OCR创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考