Решение OCR/поиск через 4 миллиона листов бумаги и 10 000 добавленных ежедневно

Ответ 1

Разделить и победить!

Если вы решите пойти по пути выполнения этого "внутри дома". Ваш дизайн должен иметь масштабируемость с первого дня.

Это один редкий случай, когда задача может быть разбита и выполняется параллельно.

Если у вас есть документы 10K, даже если вы создали и развернули 10x (сканеры + серверы + пользовательское приложение), что означало бы, что каждая система должна обрабатывать только около 1k документов.

Задача заключалась бы в том, чтобы сделать это дешевым и надежным "ключом под ключ" .

Сторона приложения, вероятно, является более легким элементом, если у вас есть хорошая автоматическая система обновления, разработанная с самого начала, тогда вы можете просто добавить оборудование при расширении своей фермы/кластера.

сохраняя ваш дизайн модульным (т.е. использовать дешевое оборудование), позволит вам смешивать и сопоставлять оборудование/замену по требованию, не влияя на ежедневную пропускную способность.

Судебное разбирательство первоначально имело решение "под ключ", которое могло легко поддерживать 1000 документов. Затем, когда это работает, безупречно его масштабируйте!

Удачи!

Изменить 1:

Хорошо, вот более подробный ответ на каждый конкретный вопрос, который вы подняли:

Каковы те системы, которые используются для проверки чеков и почты, и они читать действительно грязную ручную написание действительно хорошо?

Одна такая система, используемая почтовой/почтовой компанией "TNT" здесь, в Великобритании, предоставляется компанией, расположенной в Нидерландах "Prime Vision и их HYCR Двигатель.

Я настоятельно рекомендую вам связаться с ними. Рукописное распознавание никогда не будет очень точным, OCR на печатных персонажах может иногда достигать 99% точности.

У кого-нибудь есть опыт создания базы данных с кучей OCR'd доступные для поиска документы? Какие инструменты следует ли использовать для моей проблемы?

Не специально для документов OCR'd, но для одного из наших клиентов я создаю и поддерживаю очень большую и сложную EDMS, которая содержит очень большое количество форматов документов. Он доступен для поиска несколькими способами: с широким набором разрешений на доступ к данным.

В плане предоставления консультаций я бы сказал несколько вещей, которые нужно иметь в виду:

• Хранить документы в файле и иметь ссылку в базе данных
• Хранить документ непосредственно в базе данных в виде данных BLOB.

Каждый подход имеет свой собственный набор pro и con. Мы выбрали первый маршрут. С точки зрения возможности поиска, как только у вас есть метаданные фактических документов. Это просто вопрос создания пользовательских поисковых запросов. Я построил поиск по ранжированию, он просто дал более высокий рейтинг тем, которые соответствовали большей части токенов. Конечно, вы можете использовать инструменты поиска в полке (библиотека), такие как Lucene Project.

Вы можете рекомендовать лучшее OCR библиотеки?

да

• tessnet
• tesseract (как и выше, но для .NET)
• OCROPlus Google Sponsored

Как программист, что бы вы сделали с решить эту проблему?

Как описано выше, см. диаграмму ниже. Сердцем системы будет ваша база данных, вам нужно будет иметь передний слой презентации, чтобы клиенты (может быть веб-приложение) могли искать документы в вашей базе данных. Вторая часть - это серверы OCR под ключ.

Для этих "OCR-серверов" я бы просто реализовал папку "drop" (которая может быть папкой FTP). Ваше пользовательское приложение может просто контролировать эту папку (Folder Watcher Class в .NET). Файлы могут быть отправлены непосредственно в эту папку FTP.

Ваше пользовательское приложение OCR будет просто контролировать папку для удаления и при получении нового файла, сканировать его, генерировать метаданные, а затем переместить его в папку "Отсканированные". Те, которые дублируются или не могут сканировать, могут быть перемещены в их собственную папку "Failed Folder".

Затем приложение OCR будет подключаться к вашей основной базе данных и делать некоторые вставки или обновления (это перемещает META DATA в основную базу данных).

В фоновом режиме вы можете синхронизировать свою "сканированную папку" с зеркальной папкой на вашем сервере базы данных (ваш SQL-сервер, как показано на диаграмме) (это физически копирует ваш отсканированный и OCR'd документ на главный сервер, где связанные записи уже перемещены.)

В любом случае, как бы я справился с этой проблемой. Я лично реализовал одно или несколько из этих решений, поэтому я уверен, что это будет работать и быть масштабируемым.

Здесь важна масштабируемость. По этой причине вы можете посмотреть альтернативную базу данных, отличную от традиционных.

Я бы порекомендовал вам по крайней мере подумать о базе данных типа NoSQL для этого проекта:

Например,

• Cassandra
• HyperTable
• CouchDB

Un-ashamed Plug:

Конечно, за 40 000 фунтов стерлингов я бы построил и установил для вас все решение (включая аппаратное обеспечение)!

:) Я издеваюсь за SO-пользователей!

ИЗМЕНИТЬ 2:

Обратите внимание на упоминание META DATA, под этим я подразумеваю то же, что и другие. Тот факт, что вы должны сохранить оригинальную копию отсканированного файла изображения вместе с метаданными OCR'd (чтобы он мог выполнять поиск текста).

Мне показалось, что я понимаю это, если предположить, что это не было частью моего решения.

Ответ 2

Работая в медицинском учреждении, занимающемся вводом данных, OCR почти наверняка не работает. В наших формах были специальные текстовые поля с отдельной коробкой для каждой буквы, и даже для этого программное обеспечение было правильным только примерно в 75% случаев. Были некоторые формы, которые позволяли писать свободную форму, но результат был повсеместно тарабарщин.

Я бы порекомендовал идти по маршруту метаданных; сканировать все, но вместо того, чтобы пытаться распознавать каждую форму, просто сохраните ее как изображение и добавьте теги метаданных.

Мое мышление таково: цель OCR в этом случае - разрешить чтение всех форм с компьютера, что упрощает поиск данных. Тем не менее, вам не нужно OCR, чтобы сделать это здесь, все, что вам нужно сделать, это найти способ, который позволит кому-то быстро найти форму и получить нужную информацию вне формы. Таким образом, даже если вы храните каждую форму в качестве изображения, добавление правильных тегов метаданных позволит вам извлекать все, что вам нужно, когда вам это нужно, и человек, выполняющий поиск, может либо прочитать его непосредственно с сохраненной формы, либо напечатайте его и прочитайте так.

EDIT: Один довольно простой способ выполнения этого плана может состоять в использовании простой схемы базы данных, где каждое изображение сохраняется как одно поле. В зависимости от ваших потребностей каждая строка может содержать следующее:

• название изображения
• идентификатор пациента
• дата посещения
• ...

В принципе, подумайте о том, как вы хотите искать данный файл, и убедитесь, что он включен как поле. Вы смотрите пациентов по идентификатору пациента? Включите это. Дата визита? Одна и та же. Если вы не знакомы с разработкой базы данных вокруг требований поиска, я предлагаю нанять разработчика с навыками проектирования баз данных; вы можете получить очень мощную, но быструю схему базы данных, которая включает в себя все, что вам нужно, и достаточно мощна для ваших потребностей в индексировании. (Имейте в виду, что большая часть этого будет очень специфична для вашего приложения. Вы хотите оптимизировать это для своей ситуации и обеспечить его настройку, а также вы можете в самом начале.)

Ответ 3

В настоящее время вы решаете неправильную проблему, а 300K - это арахис, как показывают другие. Вы должны сосредоточиться на устранении 10K страниц в день, которые вы получаете сейчас. Другая проблема требует фиксированной суммы денег.

OCR работает только надежно для рукописного ввода в очень ограниченных областях (распознавая номера банков, почтовые индексы). Прекрасные результаты, которые рекламируют компании OCR, имеют печатные компьютерные документы в стандартных форматах и ​​стандартных шрифтах.

Ввод данных не должен быть на бумаге. Период. Сосредоточьтесь на этом. Еще раз нажмите на проблему.

И да, это не проблема программиста. Это проблема управления.

Ответ 4

update
с использованием идеи @eykanal в качестве отправной точки
примерами метаданных, которые вы хотите сохранить, будет идентификатор документа, местоположение исходного изображения и что-то для поиска запись (идентификатор пациента, ssn или имя и т.д.). Данные "локатора записи", вероятно, должны быть введены ключом для ввода данных, глядя на физическую форму при их сканировании.

оригинал:

• Не уверен, что вызваны считыватели чеков, но (по крайней мере, для проверок) они ищут только числа, поэтому с таким ограниченным набором символов они намного точнее, чем общее OCR.

О чем подумать:
Возьмите 10 секунд как примерное время страницы для сканирования.
Затем 10 000 * 10/60/60 = ~ 27,8 часа для сканирования ежедневного приема.

Это означает, что более трех человек, работающих полный рабочий день, просто для сканирования каждый день. Это может быть хорошо с вами и вашим работодателем, но я бы предположил, что дешевле аутсорсинг сканирования. Даже 3 сотрудника с низкой зарплатой, объединенные после льгот и т.д., Будут > 100 тыс. В год.

И
В прошлых опытах с xerox doc-сканерами они приводили к примерно 50-100 тыс. Данных изображения на страницу в зависимости от настроек и не включая текст OCR. Учитывая, что вы говорите о медицинских записях, вам, вероятно, понадобится также их хранить (я могу представить, что есть юридические проблемы, если вы этого не сделаете). Это означает от 200 до 400 концертов за то, что у вас есть, плюс от 1/2 до 1 гигабайта в день.

Ответ 5

Невозможно найти программное обеспечение OCR, которое будет надежно читать почерк, особенно ручное письмо, которое вы бы назвали "грязным".

Вы можете потратить много денег на систему сканирования, но это будет очень дорогостоящим, очень быстрым (по крайней мере, 15 тыс. долл. на сканер для конечных пользователей, а также стоимость программного обеспечения, обучение и т.д.). И без надежного OCR вам также придется вручную вводить все данные, которые вы хотите захватить из каждого документа. Очевидно, что это значительно увеличит ваши затраты (больше программного обеспечения, дополнительных сотрудников и т.д.), Не говоря уже о времени возврата с момента создания новых документов, когда они будут доступны пользователям, может быть неприемлемым для ежедневного объема, который вы говорите о.

Вам лучше отправить все ваши документы в компанию, такую ​​как Iron Mountain. Для тома, о котором вы говорите, и если документы, которые вы хотите отсканировать/закрепить, не слишком сложны, я был бы удивлен, если бы вы не смогли получить более выгодную цену, чем $0,8 за страницу.

Такая компания может доставлять ваши изображения и данные для импорта в какое-то программное обеспечение для управления документами, или вы можете написать свое собственное приложение.

Ответ 6

Заметки OCR-ing врачей не могут быть легкими: D

Попытайтесь выяснить, какая из этих 4M-страниц сразу необходима, и нанять Iron Mountain для них.

Как и в остальном, пусть ваш клиент знает, что вам задали несколько неосуществимую задачу, и попытайтесь найти практическое решение - может быть, они могут просто ввести небольшую часть этих документов и полагаться на статистику?

В будущем, если вы сможете отформатировать информацию на несколько вариантов, то, что-то вроде Scantron, может быть доступным решением.

Ответ 7

По моему мнению, самая большая проблема заключается в том, чтобы получить цифру papper.
Когда у вас есть изображения, я могу представить два решения (или лучшие идеи).

• Напишите приложение (а не Webapp!!!), которое показывает изображения один за другим секретариатам. Секретари отмечают изображения как ссылку на изображение, а теги хранятся в базе данных. Пользовательский интерфейс должен быть очень хорошо разработан (не время загрузки, функция автоматического угадывания...), чтобы получить как можно больше рабочей скорости.

• (мой любимый) Используйте программу OCR для сканирования изображений, чтобы получить текст с возможностью поиска. Затем выполните приложение, которое создало дерево слов, используемых в документах. Каждое слово должно иметь ссылки на документы, к которым он принадлежит. Такие слова, как (в а...), должны быть исключены из дерева. Затем вы можете быстро поискать дерево и найти документы. Если вы хотите совместить группы слов, поиск каждого слова и пересечение результатов. Чтобы выполнить более продвинутый поиск, бросьте текст дыры, я бы порекомендовал модифицированную версию DFA, которая может обрабатывать один символ данных, используя только дешевую инструкцию, такую ​​как поиск таблицы (очень продвинутый, я знаю это из-за моего интереса к дизайну компилятора)... он должен можно сканировать бросить дыры в текстовых данных (на уровне GB) в приемлемое время...

Это просто предложения!!!!! Я просто подумал об этом... Может быть, есть что-то полезное!

Ответ 8

Лучшее программное обеспечение OCR, которое я когда-либо видел в своей жизни, называется ABBYY: http://www.abbyy.com/company

У меня есть программное обеспечение и использую его дома для проектов, связанных с работой. Он будет сканировать документы, даже документы с графикой, такие как логотипы и флажки и т.д., И конвертировать полученный документ в Microsoft Word или PDF. Это самый распространенный экспорт. Вне зависимости от того, что он не может преобразовать в текст (например, логотип), он просто создаст графическое изображение и поместит его в документ.

Что касается почтового ветки, то они используют специальное программное обеспечение OCR (возможно, ABBYY), которое может распознать ручную запись: http://en.wikipedia.org/wiki/Remote_Bar_Coding_System

ABBYY также имеет SDK, поэтому, если вы хотите написать собственное приложение и интегрировать OCR в него, вы также можете это сделать!

Ответ 9

Как и многие другие, ваша ситуация в значительной степени является стандартной проблемой управления ECM (корпоративным контентом)/архивирования.

Обычно это обрабатывается с помощью "платформы сканирования" (в зависимости от объема, большие, вероятно, будут что-то вроде EMC² Captiva или Kofax, или они могут быть сделаны вне сайта, как вы уже указали) для сканирования бумажные документы и хранить цифровые документы в каком-либо хранилище. Этот репозиторий традиционно является платформой ECM, такой как Documentum (EMC²), FileNet (IBM), OpenText,... Эти платформы будут предлагать вам всевозможные функции для использования в сочетании с вашими цифровыми документами, включая полнотекстовый поиск. Конечно, все вышеперечисленное имеет цену.

Чтобы высказать свое мнение по вашим конкретным вопросам:

• Что такое те системы, которые используются для проверки чеков и почты, и они действительно хорошо читают действительно грязную ручную запись?

Хорошо любое решение для сканирования. Я не эксперт по сканированию, но я сомневаюсь, что любое из этих решений даст хорошие результаты при написании.

2. У кого-нибудь есть опыт создания базы данных с набором доступных для поиска документов OCR'd? Какие инструменты следует использовать для моей проблемы?

Неа. Но это то, что репозитории ECM будут обрабатывать для вас. Существуют альтернативы, в первую очередь Apache Lucene (http://lucene.apache.org) в мире Java.

3. Вы можете рекомендовать лучшие библиотеки OCR?

Как упоминалось ранее, единственная библиотека OCR, о которой я знаю, дает несколько достойные результаты - ABBYY.

4. Как программист, что бы вы сделали для решения этой проблемы?

Если вам не нужен ECM, и вы уверены, что в будущем вам не понадобятся дополнительные функции, предоставляемые платформой ECM, тогда стоит посмотреть на создание чего-то привычного. Маловероятно, что это будет легко и просто, поэтому вам придется потратить много времени на его разработку, и имейте в виду, что сохранение чего-то вроде этого масштабируемого будет непростой задачей.

Ответ 10

Бесплатный загрузочный сервер OCR: http://www.watchocr.com/

Как показано на slashdot: http://linux.slashdot.org/story/10/07/22/1852234/Open-Source-OCR-That-Makes-Searchable-PDFs

По крайней мере, сделайте снимок.