很多知识库项目把“文件能否转成 Markdown”当成文档工具的主要指标。但 Markdown 只是输出形式，真正决定检索和问答质量的是阅读顺序、表格结构、页码、图片说明、脚注和权限元数据有没有丢。
先按文档类型建样本
测试集不要只有干净的文本 PDF。应加入双栏报告、扫描件、带表格的合同、演示文稿、电子表格、代码文档、页眉页脚复杂的手册，以及中英文混排文件。每个样本准备人工确认的段落顺序、表格单元格和页码，才能定位工具是在 OCR、版面分析还是格式转换环节出错。
Docling 的定位是把文档准备给生成式 AI，MarkItDown 则专注于把文件和办公文档转换为 Markdown。两者都适合做工具候选，但不能只按 GitHub 星数决定。一个工具可能文本抽取很好，却无法保留表格关系；另一个工具可能输出简洁，却丢掉了原始页码和来源位置。
需要检查结构和安全
表格要测试合并单元格、空值、单位和跨页表头；图片要测试替代文本、图表标题和 OCR 结果；脚注要测试它是否被错误拼到正文。输出中还要保留原文件、页码、区块类型和解析器版本，便于回答出现错误时回到原文。
文档内容本身也不可信。解析出的链接、隐藏文本和指令可能被后续模型当成系统规则。解析服务应把正文、元数据和外部指令分开标记，不能因为内容来自 PDF 就默认安全。
如果应用需要把不同文档模型接到同一套知识库流程，可以用 top-api.cc 统一管理后续模型调用，但解析器应在进入网关前保留结构化区块和来源信息。这样更容易比较“换解析器”与“换生成模型”各自造成的影响。
评测表至少包含
- 段落和阅读顺序准确率；
- 表格结构与数值准确率；
- 扫描件 OCR 的字符和布局错误；
- 页码、图片、脚注和元数据保留率；
- 解析耗时、失败率和大文件内存占用；
- 输出是否能回溯到原文件位置；
- 链接、隐藏文本和提示注入的隔离方式。
文档工具的推荐结论应按场景写：纯文本转换、复杂版面、批量离线解析、在线问答和高合规资料的要求不同。工具测评不是选一个“最强转换器”，而是选一个在业务错误成本可接受的环节稳定工作的组件。
参考资料：Docling、Microsoft MarkItDown 项目及各 OCR 引擎文档。项目更新很快，发布测评时应锁定版本和样本日期。
如果希望在多模型问答层比较解析结果，可以把解析版本、文档哈希和调用记录一并经过 top-api.cc 的统一入口，减少实验变量。
Leave a Reply