Pull to refresh
35
0
Send message
В нашем же блоге была пара статей про устройство нашего распознавания.
Первая часть и вторая часть. Вам нужна больше вторая часть. Только омнифонтовый классификатор там назван байесовским, чтобы быть более приближенным к стандартной терминологии.
У нас есть несколько классификаторов, построенных следующим образом: выбираем много (порядка сотни) базовых признаков, собираем из них вектор, объявляем такие вектора нашим пространством признаков и строим на них байесовский классификатор
Это как раз про омнифонтовый классификатор (в самой статье сильно больше написано).
Про устройство дифференциального классификатора там тоже отдельный раздел, название в этом случае совпадает :)
Это будущее уже есть, называется PDF.
Осталось только научится строить правильные интерпретации текста, чтобы потом их все вместе сохранять.
На этот вопрос два ответа, на самом деле.
Во-первых, FineReader умеет распознавать текст с фотографий, в том числе и плохого качества – когда обработку фотографий начинали разрабатывать (лет 8 назад) большинство цифровых фотоаппаратов как раз были такого качества как сейчас вебкамеры.
Во-вторых, по-хорошему, текст с камеры нужно распознавать не с фото, а с видеопотока, так есть много шансов итеративно исправлять ошибки распознавания. Сейчас у нас такой готовой для пользователей технологии нет, что будет дальше посмотрим, следите за будущими анонсами.
Про CJK (китайский-японский-корейский) вообще отдельная тема разговора, в особенности в том, что касается распознавания отдельных символов. Если коротко, то классификаторы для символов там свои с более сложным набором признаком. И есть еще дополнительный уровень предварительного отсева, когда для изображения отсекаются целые наборы иероглифов, на которые картинка точно не похожа. Но вообще про иероглифическое распознавание нужно еще одну статью писать (и про арабский кстати тоже).

Про автоматическое определение языка — оно сделано на трех уровнях.
Первый уровень — это просто по внешнему виду по определенному набору признаков (без распознавания) определяем общий стиль письма, здесь важно понять есть в тексте иероглифы или нет, китайским языком его распознавать или европейскими – от этого зависит какие классификаторы мы будем использовать.
Второй уровень — когда в продукте поставлен автоселект из большого количества языков. Тогда система распознавания в очень быстром режиме распознает текст сборным языком с алфавитом из всех разрешенных символов. Дальше проверяется несколько критериев — насколько часто мы выбрали символы специфичные для какого-то языка, насколько часто на попадались слова которые есть в словаре языка и т.д. По этим критериям формируется сокращенный список языков, которые скорее всего есть на странице.
Третий уровень – это нормальное распознавание с выбранным набором языков. Здесь мы делаем выбор на этапе построения слова из вариантов распознавания (в первой части статьи про это было рассказано — Распознавание текста в ABBYY FineReader (1/2)). Здесь мы уже оперируем языковыми моделям, мы проверяем под какую модель попадают варианты слова, какие есть варианты языков для предыдущих и для следующих слов и на основе этого уже делаем выбор.
А это идея!
Семантический анализатор у нас уже (ABBYY Compreno). До компилятора осталась всего ничего.
(Кстати возможно если сделать тестовую выборку больше обучающей, то падение на добавленном шуме будет видно)
Стандартный подход — чтобы тестовая выборка была в 10 раз больше обучающей, соотношения меньше обычно берут только если с составлением базы есть серьезные проблемы… Я не знаю какое именно соотношение было у авторов в исследовании, но проблем с объемом базы у них точно не было — они брали очень большие известные датасеты.
Если мы хотим этого избежать, то нужно вводить уровень уверенности в ответе, разрешить ответ «не знаю».
У большинства классификаторов, в том числе и нейросетей, получить уверенность в ответе достаточно легко. Действительно, в этой статье был бы интересно посмотреть — у найденных ошибочных примеров насколько падает уверенность по сравнению с правильно обученными соседями? К сожалению в статье этих данных нет.
Если текст в строке написан разным шрифтом, то у нас есть специальный механизм, который пытается такие строки поделить на части с одинаковым размером шрифта — еще до разбиения строки на слова. Но даже если этот алгоритм не сработал, то особой проблемы не будет — большинство методов дальше все равно закладываются что какие-то символы могут больше или меньше, чем средняя высота символов в слове.
Я бы выложил исходный код, но он:
  1. Закрыт. Хорошо это или плохо — тема для длинного и скучного холивара, но на данный момент это такой факт.
  2. Чтобы в нашем коде разобраться и понять что же там за алгоритмы в основе используются нужно много бессонных ночей. У меня эти ночи были — поверьте словесное описание иногда бывает сильно проще и понятнее.

Но вообще спасибо за замечание — может быть в других статьях я попробую сложные вещи хотя бы псевдокодом описывать (помимо текста), для удобства восприятия.
Кстати — идея нагенерить с помощью Марковских цепей примеров для машинного обучения очень крутая. Мы используем отдельные классификаторы, чтобы подтвержать линии порезки между некоторыми парами символов. Но количество пар ограничено — просто потому что в нормальных текстах количество встречающихся пар сильно меньше возможно и распределено очень неравномерно — поэтому приходится обходится только совсем частыми парами для обучения.
Коллега 57Ded в общем все правильно ответил — для склеек мы смотрим горизонтальный профиль фрагмента и находим на нем подозрительные точки локальных минимумов. Для каждой возможно точки порезки мы еще ищем путь порезки — сверху до низу с минимальным разрезанием черного и без сильных скачков. И все такие точки порезки добавляются в ГЛД как отдельные вершины.
Ну и два дополнительных очень полезных чита:
  1. Некоторые пары символов лучше распознавать сразу целиком как один символ без порезки. Потому что в типографиях они печатаются вместе (это то, что называется лигатурами) — fi, fl, ft, ...
  2. Для некоторых символов уже на этапе формирования варианта распознавания слова стоит сгенерить вариант, как если бы в букве была незамеченная порезка. Скажем, если видим букву «m» — стоить проверить варианты распознавания с «r»+«n»

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

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity