[Bug]: OpenDataLoader, TCADP and SoMark PDF parsers label text that is not markup as doc_type_kwd “table”

这个报错出现在用 RAGFlow 的 OpenDataLoader、TCADP 或 SoMark 远程 PDF 解析器解析含表格的 PDF 时，解析器把非

标记的纯文本打上 doc_type_kwd: "table" 标签，导致下游 QA chunker 解析不出问答对。若你遇到的是

celebrityanime
2026年 9月 29日
AI 工具排错

快速结论：这个报错出现在用 RAGFlow 的 OpenDataLoader、TCADP 或 SoMark 远程 PDF 解析器解析含表格的 PDF 时，解析器把非 <table> 标记的纯文本打上 doc_type_kwd: "table" 标签，导致下游 QA chunker 解析不出问答对。若你遇到的是同样的错标行为，优先检查解析器输出的 doc_type_kwd 是否与文本形态一致。

适用环境：Issue 中确认的环境为 macOS、arm64、Go 测试、CGO_ENABLED=0，代码版本 893fc7801（从源码运行 Go parser 与 chunker 测试，未使用镜像版本）。

最快修复方案：升级到包含 #20092（提交 516b9cf0f）的 main 分支。该提交已在 main 上确认修复此问题；若无法升级，属暂无确认的一步修复方案。

注意事项：Python 侧的同名解析逻辑已不适用，因为 #20289 与 #20306 已从 main 移除 deepdoc/parser/opendataloader_parser.py 与 rag/flow/parser/parser.py。该修复针对的是解析器打标签行为，不涉及 QA chunker 本身的逻辑。

问题场景

使用 RAGFlow 的远程 PDF 解析器（OpenDataLoader、TCADP、SoMark）解析含表格的 PDF 文档，并将解析结果送入 QA chunker（extractQAJSON）时触发。QA chunker 会把 doc_type_kwd: "table" 的条目当作 HTML <table> 处理，交给 extractQATable（internal/ingestion/component/chunker/qa.go:563）用 html.Parse 读取 <tr> 行。但上述三个解析器给纯文本内容也打上了 "table" 标签，导致这些条目解析不出任何 QA 对。

报错原文

[Bug]: OpenDataLoader, TCADP and SoMark PDF parsers label text that is not <table> markup as doc_type_kwd "table"

原因分析

按照契约，带 doc_type_kwd: "table" 的条目应包含 <table> 标记；DeepDoc 表格构建器（internal/deepdoc/parser/pdf/table/table_construct.go:85）以及 docx、html、markdown、xlsx 生成器都遵循这一约定，markdown 解析器也用 isTableHTML 做同样判断。但三个远程 PDF 解析器破坏了该契约：

OpenDataLoader（pdf_parser_opendataloader.go:149）：表格元素只有 content 或 text 而没有 html 时，直接写入纯 content。
OpenDataLoader（:144、:172）：表格元素只有 cells 时，单元格用 " | " 拼接、每行一条，而非渲染为 HTML 表格。
TCADP（pdf_parser_tcadp.go:102）：表格元素的 content 不是 HTML 时，直接写入纯 content。
TCADP（:97、:138）：表格元素只有 table_data.rows 时，同样用 " | " 拼接。注意 TCADP 代码是共享的，parseWithTCADP 也服务于 xlsx、xls、csv、pptx 的 TCADP 路径。
SoMark（pdf_parser_somark.go:199）：当表格格式不是 html 时（:60 读取 SOMARK_TABLE_FORMAT），直接写入块 content，例如一个 markdown 表格。

实测中，用 extractQAJSON 处理两行表格：纯文本条目和 markdown 表格条目均得到 0 个 QA 对，只有 <table><tr>... 形式的 HTML 条目能得到 2 个 QA 对。

环境排查

确认 RAGFlow 代码提交是否为 893fc7801 或受影响的相近版本，以及是否已合入 #20092（516b9cf0f）。
确认运行的是 Go parser 与 chunker 源码测试，还是镜像版本；Issue 中镜像版本标注为 Not applicable。
确认操作系统与架构：macOS、arm64。
确认 CGO_ENABLED=0 的 Go 测试环境。
确认涉及的解析器路径：OpenDataLoader、TCADP（含 xlsx/xls/csv/pptx 共享路径）、SoMark，以及下游 QA chunker。
确认解析出的条目中 doc_type_kwd 是否为 "table"，同时检查其文本是否以 <table 开头。

解决步骤

先将代码更新到包含 #20092（提交 516b9cf0f）的 main，该提交在 main 上确认修复了此问题。
如果暂时无法升级，可在本地检查解析器输出：对 OpenDataLoader 调用 openDataLoaderItems，对 TCADP 调用 tcadpAnyToItems，对 SoMark 调用 soMarkBlockToItem，确认返回条目的 doc_type_kwd 与文本形态。
按 Issue 中给的最小复现：openDataLoaderItems 传入含 cells 的 table 元素、tcadpAnyToItems 传入含 table_data.rows 的 table 元素、soMarkBlockToItem 传入 markdown 表格内容，检查每个调用返回条目的文本是否不以 <table 开头。
把这类条目传给 extractQAJSON，确认当前是否返回 0 对，以定位问题范围。
在修复版本上重复上述验证流程。

验证方法

修复后，doc_type_kwd: "table" 的条目应携带 <table> 标记：当服务返回结构化单元格或行时，解析器应把它们渲染为 <table> 标记；当服务只返回表格区域的自由文本时，条目应被标为 text。用 extractQAJSON 处理同一两行表格，应能得到 2 个 QA 对，而不是 0 个。