решение для распознавания текста / поиска по 4 миллионам листов бумаги и 10 000 добавляемых ежедневно - PullRequest
12 голосов
/ 17 июля 2010

Я работаю в медицинской лаборатории компании. Они должны иметь возможность поиска по всем своим данным клиента. Пока они хранят около 4 миллионов листов бумаги в течение нескольких лет и добавляют по 10 000 страниц в день. Для данных, которым 6 месяцев, они должны получать к ним доступ около 10-20 раз в день. Они решают, стоит ли потратить 80 тыс. На систему сканирования, и чтобы секретари сканировали все дома, или же нанять компанию, подобную Iron Mountain, для этого. Железная гора будет взимать около 8 центов за страницу, что в сумме составляет около 300 тыс. Долларов за количество бумаги, которое у нас есть, плюс кучу денег каждый день за 10000 листов.

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

  1. Что это за системы, которые используются для сканирования чеков и почты, и они действительно очень хорошо читают беспорядочный почерк?
  2. Кто-нибудь имел опыт создания базы данных с кучей документов, доступных для поиска OCR? Какие инструменты я должен использовать для моей проблемы?
  3. Можете ли вы порекомендовать лучшие библиотеки OCR?
  4. Как программист, что бы вы сделали, чтобы решить эту проблему?

К вашему сведению, ни один из ответов ниже не отвечает на мои вопросы достаточно хорошо

Ответы [ 10 ]

14 голосов
/ 21 июля 2010

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

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

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

РЕДАКТИРОВАТЬ: Одним из довольно простых способов выполнения этого плана может быть использование простой схемы базы данных, где каждое изображение хранится как одно поле.Каждая строка может содержать что-то вроде следующего, в зависимости от ваших потребностей:

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

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

9 голосов
/ 17 июля 2010

Разделяй и властвуй!

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

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

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

Задача состоит в том, чтобы сделать ее дешевой и надежной. «решение под ключ» .

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

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

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

Удачи!

Редактировать 1:

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

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

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

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

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

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

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

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

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

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

да:

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

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

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

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

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

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

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

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

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

Например

alt text

Без стыдного штекера:

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

:) Я шучу ТАК пользователей!

РЕДАКТИРОВАТЬ 2:

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

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

5 голосов
/ 26 июля 2010

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

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

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

3 голосов
/ 17 июля 2010

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

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

Тебе лучше отправить все свои документы в такую ​​компанию, как Iron Mountain. Что касается объема, о котором вы говорите - и если предположить, что документы, которые вы хотите отсканировать / набрать, не слишком сложны, - я был бы удивлен, если бы вы не смогли получить лучшую цену, чем 0,08 доллара США за страницу.

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

3 голосов
/ 17 июля 2010

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

оригинал:

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

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

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

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

1 голос
/ 23 июля 2010

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

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

Стоит хотя бы выстрел.

1 голос
/ 22 июля 2010

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

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

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

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

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

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

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

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

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

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

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

1 голос
/ 22 июля 2010

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

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

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

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

1 голос
/ 21 июля 2010

На мой взгляд, самая большая проблема - получить Papper Digital.
Как только у вас появятся изображения, я могу придумать два решения (или лучшие идеи).

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

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

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

1 голос
/ 17 июля 2010

Записи врачей, занимающихся ОРК, не могут быть простыми: D

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

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

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

...