实现一个陌生的功能，一般会经过这几个阶段如，调研，技术选型，确定最佳技术方案与备选方案，开发，测试，上线；

调研

大致了解不同的产品

最好能上外网，首选用谷歌搜，其次用百度搜；关键词可以是pdf转markdown，或pdf markdown api等等；例如我在百度搜索pdf转markdown，最后得到了方案有

Nought：https://github.com/facebookresearch/nougat
Marker：https://github.com/VikParuchuri/marker
MinerU：https://github.com/opendatalab/MinerU
gptpdf：https://github.com/CosmosShadow/gptpdf
PDF-Extract-Kit：https://github.com/opendatalab/PDF-Extract-Kit
zerox：https://github.com/getomni-ai/zerox
OminiParse：https://github.com/adithya-s-k/omniparse
pix2text：https://github.com/breezedeus/Pix2Text

但是如果在谷歌搜索会得到

TextIn
mathpix
等等

确定优先级

接着可以团队开会确定优先级顺序，如果优先级从高到低依次是效果与性能，开发复杂度，部署成本，时间成本，费用成本，则首选付费api，即第三方公司的云方案；如果优先级从高到低依次是未来能精准适配业务，费用成本，维护复杂度，时间成本，则可以考虑免费的开源框架进行本地部署，如果对性能与效果也有一定的要求，就需要深入了解开源框架源码，进行相应微调；

对不同产品进行测评

pdf转markdown的产品大致分为三种类型，分别是云方案，本地部署，python基本的函数库；

云方案

marker，TextIn，mathpix，aspose，gptpdf等
优点是本地只需下载很小的sdk，以代理的方式调用远程大模型API，性能较好，效果较好；缺点是付费不低，可用性等各方面完全依赖云；
一般官网有文档，可以免费测试；

marker

github上星较多，但是靠不靠谱还要试用才知道；但是很抱歉，官网没有提供试用的接口，要用？先花点钱；但通过两点可以看到marker的缺点；
1）github上的转换示例可以看出，marker对公式，各种符号支持很不好；marker这里很有意思，既没有在官网或github上直接说其对公式符号支持不好，它就给了示例，就让你自己去发现！可谓是扬长避短的哲学！

2）在github上进入到其Discord社区，会发现一些很有用的信息，其中包括marker的创始人的较新的一段话，反映了对公式符号支持不好；这个社区里边创始人比较诚实，主动说了公式符号是个难点，特别是嵌套在文本里的公式符号！


marker的官网显示价格是3美元~5美元/1000页之间

TextIn

合合信息出品的，它有一款叫CS的app，适用于存储文件信息的，用起来还可以；不过它家竟然也出了pdf转markdown的云方案，提供付费API，价格大约是9美元/1000页；相比marker要贵；直接根据官网文档测试了下，对公式符号支持不好，速度可以；上图是转后的markdown，下图是pdf；

https://www.textin.com/document/pdf_to_markdown

mathpix

效果最好，对公式符号支持很好，速度可以，一页稍复杂pdf大概4秒不到；但非常贵，每个月0~40000页pdf，25美元/1000页，大于40000页pdf，10美元/1000页，当然按照企业方案，你一个月给他2000美元，可以允许转20万页pdf；官网允许免费测10页pdf；

aspose

付费方案比较多，费用不低，官网可以自行查看，试了下，但公式这块的效果没有仔细去分析；

gptpdf

13美元/1000页，本地安装个sdk，调用大模型；没有试过；

本地部署

pix2text，minerU，marker（也支持免费的本地部署），pix2text（基础模型免费）
优点是是效果随着pdf格式的变化其输出效果较稳定；缺点是部署对机器配置要求高，因为依赖包比较大，一般2G到5G，另外有付费版模型

pix2text

纯cpu跑转换比较慢，单页稍复杂pdf耗时15秒左右；但效果还可以，对公式符号支持较好；该款产品号称是mathpix的替代品，但如果能把转换速度再上一个台阶，相信还是很有竞争力的；安装包较大，不用docker镜像，直接安装约为2.5G，打成镜像后为9.4G左右；

minerU

本地安装包较大，部署难度大，需要非常高配置的机器才能保证速度快，根据网上分析，对公式符号支持一般；

marker

本地安装包较大，部署难度大，需要非常高配置的机器才能保证速度快；

python基本的函数库

PyMuPDF

支持pdf转docx较好，pdf转markdown较差
，PyMuPDF4LLM，pyMuPDF的升级版，只支持pdf转markdown一些基本标题正文的转换（基本字体），但字体间有数字等其他字符，公式，图片，无法较好处理；

pdfplumber，PyPDF2

执行原理和pymupdfllm类似，无法应对稍微复杂的pdf格式

pdf—>docx—>markdown

优点是性能快，缺点是效果随着pdf格式的变化其输出效果很不稳定，因为函数是固定转换方法，没有经过数据训练

pdf——>html——>markdown

pdf——>html这一步较难，一般网上有付费api，价格不菲，html转markdown难度相对较小

最佳技术方案与备选方案

其实根据上面测试，基本也就能敲定最终技术方案与备选方案；这里之所以有备选方案，是因为，如果在开发或部署最佳方案时遇到很大难题，一时半会难以解决，那么可以赶紧上备选方案以满足业务需求；

开发

开发其实还不是pdf转markdown的难点，难点在于前期调研，对比，测试不同的产品，最终敲定方案；开发无非是结合相关产品的API接口文档，进行函数调用，看入参，返回值，看是否需要轮询以查询结果；

测试

如果选本地部署方案，需要注意测试环境的磁盘容量，如果磁盘容量不够，由于框架涉及的包太大，会导致测试环境部署失败等问题，打成docker镜像，只会让包更大，例如自己搭建一个基于Django的接口demo，大约是15MB，但是打成docker镜像后就变成了75MB，所以只会加大测试或生产环境的负担；虽然docker让项目从开发到测试到生产的迁移变得便捷！

这一期的总结就先到这，一些自己的想法，希望能和大家多多交流！