结构化提取

手工录入发票的痛点到底有多深？我在一家中型企业做财务自动化的时候，亲眼见过行政助理把一天200多张发票一张张手动录入系统——从发票代码到金额、税额、开票方信息，平均每张耗时45秒。一个月下来，光是发票录入就消耗了将近40个工时，而且错误率高达3.2%（主要是数字看错、小数点位置搞错）。更让人头疼的是，月底集中报销的时候，发票像雪片一样飞来，财务部门经常加班到晚上十点才能处理完。这不是效率问题，这是人力成本的系统性浪费。后来我用OCR技术重构了整个发票处理流程，把单张发票的处理...

提到OCR（光学字符识别），很多人第一反应是Tesseract、PaddleOCR这些传统工具。但说实话，如果你用过豆包大模型的视觉能力，就会发现一个被严重低估的用法——直接用大模型做OCR，准确率吊打大部分专用工具，还省去了模型训练和部署的麻烦。 这篇文章我把自己踩过的坑和总结的最佳实践全部整理出来，从注册到实战调优，一步到位。 为什么选豆包大模型做OCR而不是传统方案？ 传统OCR方案最大的痛点是什么？中英混排识别差、手写体基本放弃、复杂版面（表格、多栏排版）需要大...

为什么选择GLM-OCR而不是传统OCR方案 做过OCR项目的人都知道，传统方案（Tesseract、PaddleOCR）在中文场景下总有一股"差不多就行"的味道——准确率卡在90%上下，遇到手写体、倾斜文本、多语言混排就拉胯。GLM-OCR的出现改变了这个局面，它把大语言模型的理解能力嫁接到OCR上，不是单纯"看图识字"，而是"读图理解"。 我在实际项目中对比过：同样一张含有中英日三语的发票图片，PaddleOCR识别错了7个字，Tesseract直接漏掉两行，而GLM-O...