关于 PDF 抽取的吐槽

今天一下午写了8,9个 PDF 抽取的脚本。最后又回归最开始简单的模式了,要疯了,谁懂啊。

我是下午的工作是这样的(我是这么疯的)

  1. 最开始使用最简单的策略,先使用 PyPDF2.PdfReader(file) 读取文件,然后在每一页使用 page.extract_text() 提取文字。如果不足 50 个字认为是图片,使用 OCR 识别。其实发现效果还是不错的
  2. 但是不安分的我开始想,我记得有一个库叫pdfplumber,它对表格信息友好,且能识别图片。所以,我就想,如果我的脚本可以提前甄别图片、表格和纯文本,分别对他们进行OCR、pdfplumber提取表格和pypdf提取文本,那岂不是无敌了。结果,,,,一步错步步错
  3. 首先是pdfplumber提取表格的效果,真的很糟糕,经常提取出来一堆空白
  4. 其次是考虑OCR的时候,把OCR当回事的时候,真的会吃大亏。
    a. 直接对 PDF 使用 OCR,会出现大范围的乱码
    b. 对图片进行灰度处理和二值化处理,效果会好一些,但是仍然不如直接使用pypdf提取文字的效果
    c. 所以我又使用 opencv 进行降噪和对损失的图片进行还原,使用的是qpdf,发现结果好点,但还是不如直接用pypdf
    c. 把图像转换成base64的格式,这个我做出来了,后来想想,我真是个东西啊,我做出来这玩意有啥用,没用啊,我的工作内容用不到这啊
  5. 在进行表格和图像处理优化的时候,我想到了多线程。结果多线程也是个坑,用了多线程不一定会加速。我严重怀疑是因为我没用队列控制线程的排队。因为我之后写划分chunk 代码的时候用了Queue进行线程排队,又快又没有出现cache丢失或充写的情况
  6. 最后回归最开始的方案,因为要考虑源信息,使用json存文件了(其实我认为用jsonl更好)
  7. 作为优化,我使用了正则对文本数据进行了处理

总结

  1. 多线程用不好的话,效果不一定好。最好处理好排队的逻辑
  2. OCR 是一个坑,慎用
  3. jsonl 对并行处理更友好
  4. 正则对数据处理是一个好想法
相关推荐
棱角~~2 小时前
10款PDF转Word软件工具的使用感受及其亮点!!!
经验分享·pdf·word·学习方法
shujuwa662 小时前
什么是开源软件(OSS)?
pdf·编辑器·电脑·word·开源软件
晨欣4 小时前
Mac如何将多个pdf文件归并到一个
macos·pdf
慧都小妮子5 小时前
Spire.PDF for .NET【页面设置】演示:获取 PDF 文件中的页数
java·pdf·.net
新加坡内哥谈技术12 小时前
Claude 3.5 Sonnet模型新增了PDF支持功能
人工智能·pdf
weixin_4046793114 小时前
pdf转图片
linux·运维·开发语言·python·pdf
大飞攻城狮21 小时前
2024年中国生成式人工智能应用与实践展望白皮书(中英文版)|附147页PDF文件下载
大数据·人工智能·pdf·产品经理·大模型学习·大模型入门·大模型教程
努力的光头强1 天前
太炸裂了,Ollama跑本地模型已成为历史,现在都在使用这个工具,而且还能集成本地知识库
人工智能·ai·pdf·产品经理·llama
蛊明1 天前
Firefox不能直接在浏览器中打开PDF
前端·pdf·firefox