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

What were the main challenges to be overcome when developing the software? Were there any particularly knotty problems?

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

И здесь есть повод задуматься. Всё-таки с точки зрения сложности задач не так уж это интересно – низкое качество изображения и декоративные шрифты. Мы примерно то же самое могли сказать и пять лет назад, и десять, и двадцать. Да, несомненно, прогресс есть – и для большей части версий известный обозреватель и наш старый друг Сергей Голубицкий находил как раз те картинки, которые оказывались на «переднем крае» наших технологий – чтобы именно их новая версия FineReader стала обрабатывать практически идеально, а старая пока «спотыкалась».

Но чтобы рассказать о том, какие трудности перед нами стоят ещё, стоит прибегнуть к небольшой метафоре. Вот какие трудности у вас возникли, чтобы решить следующую задачу

Хм… Скорее всего, большинство нормальных людей подумают, что не так-то просто извлекать корни пятой степени. И если спросить «а какие трудности возникают с решением этой задачи», захочется рассказать, как извлекать корни пятой степени, раскладывая число в ряд и пользуясь векторными операциями… Но для «искусственного разума», извлечение корня будет чуть ли не самым простым из его действий. Настоящие трудности будут другими:

• Распознать рукописные цифры
• Разобрать и декомпозировать формулу
• Вообще как-то догадаться, что этим нужно заниматься

Можно заметить, что в этом примере, чем проще часть задачи для человека, тем сложнее она для «искусственного разума». Это ни в маркетинговые материалы не вставишь, ни в интервью не скажешь… «Мы стали меньше ошибаться с разбором формулы» — «Гы-гы-гы, формулу каждый дурак разобрать может, ерундой вы занимаетесь».

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

Мы как раз подошли к связи метафоры и задач распознавания. Само словосочетание «задача распознавания» является ловушкой. Потому что когда задача распознать нечто уже поставлена, то она является хорошо сформулированным вопросом. А как мы знаем, правильно задать вопрос – это уже существенная часть решения задачи.

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



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

А ведь помимо перекоса на изображении могут быть перспективные искажения, и тогда одним поворотом задачу не решить. У фотографий двухстраничных документов, например, паспортов, перспективные искажения могут быть свои для каждой страницы. Кривые строчки на журнальном развороте могут возникать как в результате искривления листа, так и из-за «художественной» верстки. Нужно ли их разгибать в последнем случае и пытаться распознать? Без более сложных моделей документов тут уже не обойтись, а для того чтобы определять, какая из них подходит к изображению, нужен соответствующий классификатор. С перспективными искажениями мы уже научились бороться, а с остальными случаями предстоит еще долгий путь к совершенству.

Далее, мы начали учиться сегментировать страницу. Выделять колонки текста, картинки, таблицы… Как отличить текст от картинки? Да нет ничего проще, к нашим услугам Over9000 статей на эту тему. Реализовали, всё хорошо, запускаем и видим следующую картинку:



В более ранних версиях FineReader'а наш умный текстовый классификатор радостно нам сообщал, что здесь имеется куча хорошо организованного текста, а анализатор таблиц радостно рисовал на нём очень хорошо отсегментированную таблицу… Но человеку, который переводил в электронный формат учебник по базам данных, кажется, нужно вовсе не это: в данном случае нужен просто пример скриншота MS Access, а распознавать таблицу и как-то использовать данные из неё никто и не собирался. В последних версиях мы научили FineReader не трогать содержимое скриншота и оставлять его картинкой.
Или вот такая неожиданность



Ясное дело, перед нами текст. Несколько блоков текста. Но даже не очень внимательный читатель может заметить, что там есть нечто ещё.

По-хорошему, конечно, эту диаграмму стоит разобрать, весь текст распознать, а рамки нарисовать векторными командами. Но вот незадача, мы заранее не знаем, в какой формат её предстоит записать и какие команды нам будут доступны. Потому часто разумно будет сохранить эту диаграмму как картинку. Да, текст, да, как картинку. Искусственный разум пришёл в полное замешательство, плюнул на этих людишек и ушёл привычно вычислять корни пятой степени.

Спрашивается, и что с этим делать?

Здесь важен даже не ответ на предыдущий вопрос. Даже если мы его поймём, то мы зададим себе и другой вопрос:
А как часто надо будет такие задачи решать? Да, вопрос тот же, что и в примере с формулой. И ответ не всегда прост.
Для нас оказалось, что среди проблем с сегментацией страницы доля тех, что вызвана неадекватным восприятием нами скриншота и диаграммы, достаточно велика. Поэтому в свежих версиях мы «объяснили» нашему движку, что такие объекты бывают, как они устроены и чем отличаются от таблиц, блоков текста и просто картинок. Но если бы мы сочли, что проблема редкая и «экзотическая», то скорее всего ничего бы делать не стали – чем вызвали бы ярость у тех, кто обрабатывает страницы с большим количеством скриншотов и диаграмм.

Думаете, только с необычными объектами такие проблемы? Ничего подобного – в той же сегментации есть примеры только с текстом. Скажем, большинство популярных ныне алгоритмов сегментации страницы (сразу вопрос – а будет ли интересно, если мы напишем по ним небольшой обзор?) говорят, что если есть две группы текстов на почтительном расстоянии друг от друга, то они должны оказаться в разных блоках. Логично, чёрт возьми – не надо смешивать две колонки в один блок. «Пожалуйте, пожалуйте», — говорит нам мироздание:



«Ну…», — говорит разработчик, — «делаем так, чтобы номера списка от списка не отваливались… Скажем, колонки из одних чисел будем стараться присоединять к нормальному тексту». «Ай молодца!», — говорит мироздание:


Здесь уже мы не сможем приклеить цифры (номера строк) к тексту, не сломав его связность и возможность дальнейшего использования – то, ради чего пользователь и запускал нашу программу. Но ничего, поплевав на руки, в очередной версии справились и с этим.

К чему это всё? Кажется, что одним из вызовов для нас, создателей распознавалки, является изменчивость и, как следствие, недоформулированность стоящих перед нами задач. Более того, можно считать, что это одно из важных отличий искусственного интеллекта от интеллекта естественного. Потому что недоформулированность задачи – привычная среда для естественного разума и проклятие для учёного и инженера. Возвращаясь к системе распознавания, одно из направлений развития – это всего лишь более тщательная и выверенная формулировка задачи, причём большинство подзадач уже либо давно решены, либо не представляют особой сложности. А вопросом для нас может оставаться лишь то, решение каких из задач в данный момент нужнее всего нашим пользователям. Так получилось, что это не «фичи программы», а именно развитие технологий.

(совместно с logicview)