原贴链接

我开始有点沮丧了。我正在为一个涉及发票信息提取的学术项目开发一个移动应用程序。由于这是一个非商业项目，我不能使用像谷歌视觉或Azure AI视觉这样的付费解决方案。到目前为止，我研究了几种可能性，最好的是用SuryaOCR/Marker进行数据提取，用Qwen 2.5 14B进行数据解释，再通过正则表达式进行一些小的验证。我在选择上也受到限制，因为我有一个12GB显存的RX 6700 XT，由于我的GPU缺乏支持，我不能运行Hugging Face模型。我也试过一些视觉模型，如Llama 3.2 Vision，以及各种OCR解决方案，如PaddleOCR、PyTesseract和EasyOCR，但由于缺乏布局检测，它们都不尽如人意。我想问你们是否有人遇到过类似的情况，如果有任何想法或建议，因为我在数据提取方面快没有选择了。这些发票主要是葡萄牙语的，所以很多OCR模型最终缺乏对布局检测的支持。提前谢谢了。

讨论总结

原帖主因学术项目（非商业性）开发发票信息提取的移动应用时面临诸多限制，如不能使用付费方案、GPU硬件限制等，在数据提取方面快无计可施。评论者们积极提供各种解决方案，包括推荐不同的OCR模型、工具，分享自己的相关经验，也有人针对原帖主的情况提出疑问以更好地提供帮助。

主要观点

  1. 👍 推荐使用pdftotext工具并附带 -layout选项解决数据提取问题
    • 支持理由：对于非扫描PDF能保留文本格式，经充分提示很多模型可对纯文本进行列感知数据提取。
    • 反对声音：无
  2. 🔥 推荐尝试Gemm 3 12B解决数据提取问题
    • 正方观点：原帖主在开发提取发票信息的移动应用时面临多种限制，这可能是一个新的解决思路。
    • 反方观点：无
  3. 💡 推荐Mini - CPM - V - 2.6或Gemma3 - 12b - it用于OCR
    • 解释：认为它们在这方面做得相当不错，但也指出可能会在不确定输出时产生幻觉，还推荐了Mini - CPM - V - Q8解决幻觉问题。
  4. 💡 docling使用EasyOCR且在大多数情况下效果不错
    • 解释：这是一种可行的OCR使用情况，或许原帖主可以参考。
  5. 💡 之前做类似项目时SuryaOCR是较好的OCR方法
    • 解释：在当时试过的OCR方法中相对较好，因为其他试过的在某些方面较差。

金句与有趣评论

  1. “😂 Try the python utility pdftotext with the -layout option.”
    • 亮点：直接给出一个可能解决原帖主数据提取问题的工具及使用选项。
  2. “🤔 Durian881：Maybe you can try Gemm 3 12B. It’s a new vision model from Google.”
    • 亮点：针对原帖主的困境提供新的模型尝试建议。
  3. “👀 你可以使用Mini - CPM - V - 2.6或Gemma3 - 12b - it用于OCR。它们看起来在这方面做得相当不错。”
    • 亮点：推荐具体的OCR工具，且表达出对其效果的肯定。
  4. “😎 g0pherman：I know that docling uses EasyOCR, but it does a good job in most cases.”
    • 亮点：提供了docling使用EasyOCR效果较好的信息。
  5. “🙌 由于内容的异质性，我发现的最好的OCR方法是SuryaOCR，当时其他所有我试过的在某种程度上都差得多。”
    • 亮点：通过比较说明SuryaOCR在之前类似项目中的优势。

情感分析

总体情感倾向积极，大家都在积极为原帖主出谋划策。主要分歧点较少，可能是因为大家只是在分享自己的经验或者推荐自己认为可行的方案，还没有到深入对比不同方案优劣的阶段。

趋势与预测

  • 新兴话题：可能会进一步探讨不同OCR模型在处理特定语言（如葡萄牙语）发票时的布局检测问题。
  • 潜在影响：如果能找到适合原帖主情况的解决方案，可能会对其他有类似限制（非商业项目、硬件受限等）的开发项目提供参考范例。

详细内容：

标题：学术项目中发票信息提取的困境与探索

在 Reddit 上，一则关于为学术项目开发涉及发票信息提取的移动应用的帖子引起了广泛关注。该帖子获得了众多的点赞和大量的评论。原帖作者表示，由于项目的非商业性质，无法使用如 Google Vision 或 Azure AI Vision 等付费解决方案。目前已研究了多种可能性，包括 SuryaOCR/Marker 用于数据提取和 Qwen 2.5 14B 用于数据解释，并通过 RegEx 进行了一些小的验证。

作者还面临硬件限制，其拥有的 RX 6700 XT 显卡（12GB VRAM）无法运行 Hugging Face 模型，且尝试的多种视觉模型和 OCR 解决方案都因缺乏布局检测功能而效果不佳。由于发票主要是葡萄牙语，许多 OCR 模型缺乏对布局检测的支持，作者因此向大家求助。

讨论中，观点纷呈。有人建议使用 python 工具 pdftotext 的 -layout 选项，称对于生成的而非扫描的 PDF，它能保留间距、视觉列等给出文本。还有人提到可以尝试 Gemm 3 12B、Mini-CPM-V-2.6 或 Gemma3-12b-it 等模型用于 OCR。也有人推荐 olmOCR，认为其文本锚定功能可能会有帮助。

有人分享自己的经历，比如有人会按需租用 GPU，如在 vast.ai 上租用 RTX4090 来处理工作。

对于所推荐的模型，有人认为对于追求的精度，需要使用更大的 GPU，否则保持现状。也有人指出某些模型在特定情况下效果出色，但在作者的场景中可能不适用。

在众多建议和观点中，共识在于找到适合具体需求和硬件条件的解决方案至关重要。特别有见地的观点如根据具体语言和布局需求选择合适模型，丰富了讨论。

总之，这场关于发票信息提取的讨论展现了技术探索中的多样性和复杂性，为遇到类似问题的人提供了丰富的思路和参考。