我在一家医学实验室工作.他们需要能够搜索所有客户数据.到目前为止,他们有几年存储大约400万张纸,他们每天增加10,000页.对于6个月大的数据,他们每天需要访问大约10-20次.他们决定是否在扫描系统上花费80k,并让秘书扫描内部的所有内容,或者是否聘请像铁山这样的公司来做这件事.铁山每页收费约8美分,这相当于我们所拥有的纸张数量约为30万美元,加上10,000张每天更多的钱.
我想也许我可以建立一个数据库并在内部进行所有扫描.
那些用于扫描支票和邮件的系统是什么,他们读的手写得非常糟糕？
有没有人有过使用一堆OCR可搜索文档构建数据库的经验？我应该用什么工具来解决我的问题？
你能推荐最好的OCR库吗？
作为一名程序员,你会怎么做才能解决这个问题？
仅供参考,以下答案中没有一个能够很好地回答我的问题
在医疗办公室工作进行数据输入后,OCR几乎肯定不会起作用.我们的表格有特殊的文本框,每个字母都有一个单独的框,即使只有75%的时间,软件也是正确的.有些形式允许自由形式的写作,但结果是普遍的胡言乱语.
我建议去元数据路线; 扫描所有内容,但不是尝试OCR每个表单,只需将其存储为图像并添加元数据标记.
我的想法是:在这种情况下OCR的目标是使所有表单都能从计算机中读取,从而使数据检索更简单.但是,你真的不需要在这里做OCR,所有你需要做的就是找到一些方法让某人能够非常快地找到一个表单,并从表单中获取正确的信息.因此,即使您将每个表单存储为图像,添加正确的元数据标记也可以让您在需要时检索所需的任何内容,并且运行搜索的人可以直接从存储的表单中读取它,或者打印并以这种方式阅读.
编辑:执行此计划的一种相当简单的方法可以是使用简单的数据库方案,其中每个图像都存储为单个字段.根据您的需要,每行可以包含以下内容:
图像名称
病人身份证
访问日期
...
基本上,请考虑您想要搜索给定文件的所有方法,并确保将其作为字段包含在内.您是否通过患者ID查找患者？包括那个.访问日期？相同.如果您不熟悉围绕搜索要求设计数据库,我建议聘请具有数据库设计技能的开发人员; 您最终可以得到一个非常强大而快速的数据库架构,其中包含您想要的所有内容,并且足以满足您的索引需求.(请记住,大部分内容都将高度针对您的应用程序.您需要根据自己的情况对其进行优化,并确保在开始时尽可能地进行设置.)
如果你决定沿着"内部"这条路走下去.您的设计需要从第1天开始具有可扩展性.
这是一个罕见的情况,可以分解任务并行完成.
如果您有10K文档,即使您构建和部署了10x(扫描程序+服务器+自定义应用程序),这意味着每个系统只需要处理大约1k个文档.
挑战在于使其成为廉价可靠的"交钥匙解决方案".
应用程序端可能是更容易的元素,只要您从一开始就设计好自动更新系统,就可以在扩展"服务器场/集群"时简单地添加硬件.
保持您的设计模块化(即使用商品廉价的硬件),将允许您混合和匹配硬件/按需更换,而不会影响日常吞吐量.
最初尝试使用一个可以轻松维持1,000个文档的交钥匙解决方案.一旦这个工作完美无瑕地扩大它!
祝好运!
好的,这里是您提出的每个具体要点的更详细的答案:
那些用于扫描支票和邮件的系统是什么,他们读的手写得非常糟糕？
英国的邮件/邮递公司'TNT'使用的一个这样的系统由荷兰公司'Prime Vision'及其HYCR引擎提供.
我强烈建议你联系他们.手写识别永远不会非常准确,打印字符上的OCR有时可以达到99%的准确率.
有没有人有过使用一堆OCR可搜索文档构建数据库的经验？我应该用什么工具来解决我的问题？
不是专门的OCR文档,但对于我们的客户之一,我构建并维护了一个非常庞大和复杂的EDMS,它拥有各种各样的文档格式.它可以通过多种不同的方式进行搜索,并具有复杂的数据权限访问权限.
在提供建议方面,我想说几点要记住:
将文档保存在文件中并在数据库中包含链接
将文档作为BLOB数据直接存储在数据库中.
每种方法都有自己的一套pro和con.我们选择了第一条路线.在搜索能力方面,一旦掌握了实际文档的元数据.这只是创建自定义搜索查询的问题.我建立了一个基于排名的搜索,它只是给那些匹配更多令牌的人提供了更高的排名.当然,您可以使用货架搜索工具(库),例如Lucene项目.
你能推荐最好的OCR库吗？
是:
tessnet
tesseract(与上面相同,但对于.NET)
OCROPlus Google赞助
作为一名程序员,你会怎么做才能解决这个问题？
如上所述,请参见下图.系统的核心是您的数据库,您需要有一个演示前端层,以允许客户端(可以是Web应用程序)搜索数据库中的文档.第二部分是基于交钥匙的OCR'服务器'.
对于这些'OCR服务器',我只需实现一个'drop folder'(可以是一个FTP文件夹).您的自定义应用程序可以只监视此drop文件夹(.NET中的Folder Watcher Class).文件可以直接发送到此FTP文件夹.
您的自定义OCR应用程序将只监视drop文件夹,并在收到新文件后,扫描它生成元数据,然后将其移动到"Scanned"文件夹.重复或无法扫描的那些可以移动到他们自己的"失败的文件夹".
然后,OCR应用程序将连接到您的主数据库并执行一些插入或更新(这会将META DATA移动到主数据库).
在后台,您可以将"扫描文件夹"与数据库服务器中的镜像文件夹同步(您的SQL服务器如图所示)(然后将扫描的和OCR文档物理复制到链接记录的主服务器)已经被感动了.)
无论如何,这就是我如何解决这个问题.我个人实施了一个或多个这样的解决方案,所以我相信这会起作用并具有可扩展性.
规模能力是关键.因此,您可能希望查看除传统数据库之外的其他数据库.
我建议你至少考虑一下这个项目的NoSQL类型数据库:
例如
卡桑德拉
Hypertable的
CouchDB的
不惭愧的插头:
当然,对于40,000英镑,我会为您构建并设置整个解决方案(包括硬件)!
:)我正在开玩笑的用户!
请注意提到META DATA,我的意思与其他人提到的相同.您应该将扫描的原始副本保留为图像文件,同时保留OCR的元数据(以便它可以允许文本搜索).
我想我已经说清楚了,以防它被认为不是我的解决方案的一部分.
你现在正在解决错误的问题,300K是花生,正如其他人已经表明的那样.您应该专注于每天消除10K页面.另一个问题只需要固定金额.
OCR仅在非常有限的域中可靠地用于手写(识别银行编号,邮政编码).OCR公司所宣传的优秀结果是标准格式和标准字体的印刷计算机文档.
数据输入不应该在纸上.期.专注于做到这一点.提前解决问题.
是的,这不是程序员的问题.这是一个管理问题.
京公网安备 11010802040832号 | 京ICP备19059560号-6 