第271章 数据方案（2 / 2）
请关闭浏览器的阅读/畅读/小说模式并且关闭广告屏蔽过滤功能，避免出现内容无法显示或者段落错乱。
标注人手不够。林晨说了他最想说的一件事。
JD已经给HR了，三天了，简历就收了七份。其中四个是计算机专业的——我们需要的是懂财务的，不是懂代码的。另外三个金融相关的，两个是大三的，基础太薄，一个倒是研二的，但在广州，人过不来。
陈博士想了想。HR那边我去说，让他们加急推。另外你把JD里的薪资往上提一档，鹏城这地方实习生薪资到位了人不难找。
提多少？
日薪从一百五提到两百。别在这上面省。
林晨点了下头，把白板上的内容拍了一张照片，转身出了办公室。
回到工位，张雨的显示器分成左右两块。左边是scrapy的运行日志，绿色的200OK一行一行往下滚，偶尔跳出一行红色的403Forbidden——被反爬了，但scrapy的自动重试机制在十秒之后换了个代理IP重新请求，又变回了绿色。右边是数据看板，三条入库曲线都在往上走。
入库顺利。张雨指着左边那块屏，深交所的页面结构很规矩，css选择器写完基本不用改。上交所的稍微麻烦一点，有些老页面还是table布局，不过也能搞定。
出问题了？林晨看到他浏览器里另外开了一个tab，标题是tesseractOCR。
张雨的表情一下子变了。他把右边屏幕切到一个预览界面——上面是一份年报问询函的扫描件，中间夹了一张财务数据表格。你看这个。问询函本身是纯文本的，爬取没问题。但有些公司在回复问询函的时候，直接把财务附表贴成了图片。PDF转文本到这一步就断了——OCR出来的东西你看。
他点开OCR结果。表格原本是五行六列的结构，OCR输出的文本里行和列全混在了一起——第三行的数字跑到第二行末尾，表头和表体粘在一起，小数点后面的数字被截断或者拼到了隔壁单元格。
我试了三个参数配置——张雨把tesseract的配置文件拉出来给林晨看，ps模式从3到6到11都试了，表格结构识别最好的是ps6，但你看到结果了，还是乱的。字符识别率倒是不低，单个数字几乎没认错，关键是位置信息全丢了。
林晨盯着那张乱掉的表格看了半分钟。字符识别对了但位置丢了——那问题不是OCR引擎，是表格检测。你先做个预处理——把PDF页面做版面分析，表格区域单独切出来，然后用专门的表格识别模型做结构解析，不要把整页丢给tesseract。
专门的表格识别模型？有什么现成的？
微软去年开源了一个table-transforr，专门干这个的。你先拿它试试，识别出表格的行和列的边界框，然后在每个单元格内做OCR。两步拆开做，比一步到位要靠谱。
张雨记了两行笔记。那非表格的部分呢？
纯文本的让模型自动清洗，不用人工介入。只把含表格的页面标记出来，table-transforr跑完之后，单元格级OCR再校验一遍。校验的工作量——他估算了一下，八千份问询函里带财务表格的大概两成，一千六百份左右。每份校验三到五分钟，全走人工得要——
一百多个小时。张雨算得很快。
所以需要标注实习生。林晨把下午和陈博士讨论的结论说了，薪资提了，HR那边在推。人到了之后清洗和标注并行，你这边爬虫和表格识别继续优化。
张雨已经把table-transfitHub页面打开了。
晚上九点多，林晨坐在工位上整理今天的数据方案讨论。他没有写什么总思考，只是在项目文档里加了三个待办事项：法务意见书——公开数据合规边界确认；HR——标注实习生招聘加急；张雨——table-transforr表格识别方案验证。想了想又在让它们自己拖着。
↑返回顶部↑