Программы для обработки данных из метрических книг

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

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

• Russian generic handwriting (на текстах конца 19го и начала 20го века, в частности из проекта Прожито)
• Rychkov archive (на рукописных тестах Константина Рычкова 1911-1913)
• Russian church slavonic (на церковных текстах 16го века)
  

Для проверки загрузил туда скан метрической книги 1904 года с относительно читабельным текстом, лучше всего отработала модель Russian generic handwriting, на удивление, она распознала довольно много, включая названия населенных пунктов и фамилии. Самое интересное наверное фамилии, так вот из 12 фамилий на листе (6 фамилий отцов + 6 фамилий воспреемников) она распознала правильно 8. Разметка страницы при распознании не сохраняется, зато есть поиск по всем распознанным страницам, т.е. сценарий для себя я вижу какой - загружаем метрику - распознаем все страницы - делаем поиск по нужной фамилии и альтернативным написаниям - вручную смотрим найденные записи.

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

Остальные две модели не распознали почти ничего.

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

Но, теперь ложка дёгтя - сервис платный, при регистрации дают 500 бесплатных кредитов, которых хватит на распознание 400 страниц, далее нужно платить, даже за использование своей собственной модели. Но раз они смогли натренировать модель, значит можно их опыт воспроизвести на open source решениях, конечно для этого нужны данные и опыт в этой теме.

Gloyko написал:

[q]

Мне вот интересно, а "полуслепые" МК она читает?

[/q]

Что такое "полуслепые" МК? Если дадите файл, я могу его прогнать там.

>> Ответ на сообщение пользователя Arcobaleno от 25 октября 2019 22:36

Подскажите, а где вы встречали фамилию Спиридонов и Пелагиада в одном месте? Новенький на форуме, пытаюсь найти записи по фамилиям Спиридоновы-Денежные.

Уже давно в планах написать программу для формирования базы записей метрических книг и ее последующего анализа для идентификации личностей, выявления связей между записями и оценки вероятности совпадений.
Цель у меня прикладная и личная - по некоторым территориям большая часть записей МК не содержит фамилии. Хочется попробовать устанавливать их программно и отыскивать родственников с использованием более поздних данных и поиском совпадений (по вероятным датам рождения, имени, отчеству и т.п.).
Если пойдет - можно сделать и коммерческий продукт.
Основной функционал -- формы ускоренного ввода данных метрических книг. Блок анализа и поиска с вывода потенциальных записей-совпадений, а также формированием списка личностей-предков, с расчетом и выводом вероятности совпадения.

Есть опыт программирования и написания десктопных приложений на Python.

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

1. Проектов высокой степени готовности не нашел. То что есть обычно имеет ограниченный функционал. О своей работе рассказывал пользователь Rychagov, но до концовки и образца дело не дошло, на форуме его давно нет (

2. Excel, макросы VBA стал бы использовать только для маленьких проектов. Сам я этот вариант пробовал, - уже на нескольких сотнях фамилий понимаешь, что это абсолютно негодные инструменты для построения реляционной базы данных и ее анализа. Ну то есть в принципе делать что-то можно, но это как строить небоскреб из мусора в гараже...
Для первого подхода я выбрал Python + sqllite, т.е. реляционная БД, которая хорошо подходит для наших целей.

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

4. Проблема определения человека по ФИО , в том виде как это обсуждалось в данной теме, по большому счету отсутствует.
Основным структурным элементом базы является запись в метрической книге. Личность должна "создаваться" в результате анализа базы данных, после ее создания. Причем, каждый раз результат может быть иным, т.к. базу можно изменять (уточнять, исправлять ошибки) и дополнять. Выявление однофамильцев, ошибок присущих самим данным - это вопрос качества алгоритма анализа, но не ввода и хранения данных.

5. Ключевая проблема - структуризация или семантический анализ отдельных блоков данных при их вводе.
Например, в Книге рождений достаточно просто структурировать данные о дате и порядковом номере рождения, имени т.к. тут вариаций связанных с формой ввода и положением элемента в последовательности практически нет. Иное дело - текст записи о родителях и крестных, который весьма вариативен.
Сейчас вижу два основных способа решения задачи по разбиению этих блоков на структурные единицы (ФИО отца + его сословие и место жительства, религия, ФИО матери и т.п.).
№1 - структурированный ввод, с оригинальным для программы многовариантным алгоритмом разбиения на структурные единицы, с использованием оговоренных сокращений
№2 - использование готовых модулей семантического анализа, например, Natasha. Это более гибкий инструмент, но полученный результат все-равно нуждается в оригинальной переработке + доп вес программе.
Способы №1,2 можно комбинировать. Но легкого решения нет. Гарантированно будут ошибки для специфичных случаев, но продумал способ с ними бороться: программа на лету разбирает вводимый текст, демонстрируя пользователю "разобранный" вариант и сигнализирует об ошибках и несоответствиях, которые можно будет исправить в отдельных формах заготовленных под каждый структурный элемент.

В моем случае легкораспознаваемый шаблон ручного ввода записи, например, о рождении, может выглядеть так (структурные элементы определяются пробелами и переносом строки при вводе):

3 28 1 март евдокия (РОЖДЕНИЕ - №3 за год рождение (женщины) 28 февраля, крещенной 1 марта)
д полюбово к поликарп тимофеев лазарев васса борисова п (РОДИТЕЛИ: отец - деревни полюбово крестьянин Поликарп Тимофеевич Лазарев...
д починок к иван минаев макашенков д полюбово к евдокия пименова лазарева" (КРЕСТНЫЕ: крестный - деревни Починок крестьянин...

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

6. Для более качественного анализа и поиска связей потребуется создание нескольких библиотек. В их числе - перечень имен и их вариаций, например: Иван, пол - муж, вариации - Иоан, Иоанн и т.п..

7. Вопросы общей базы и доступности. Один из вариантов -- создание онлайн версии программы, которая бесплатно предоставляет базовый функционал пользователю, взамен на право доступа к введенным им данным (100 и более летней давности - под жесткие ограничения персональных данных не попадаем). Они, очевидно, имеют самостоятельную немалую ценность.