Автоматизированное управление электронными документами? Решили ли мы эту задачу? Часть 1

Данная статья Тима Шинкля (Tim Shinkle – на фото) была опубликована 9 декабря 2016 года на австралийском сайте «IDM - Image и Data Manager» («Специалист по управлению графическими образами и данными»).

Облачные провайдеры недавно представили новые мощные облачные сервисы для обработки больших данных и использования искусственного интеллекта (ИИ). Эти облачные сервисы обещают наконец-то получить отдачу от использования возможностей ИИ для автоматизации управления электронными документами (electronic records management, ERM). Но готов ли уже к этому рынок? И смогут ли эти новые сервисы окончательно убедить скептиков в том, что ИИ действительно может использоваться для эффективной автоматизации управления электронными документами?

Много лет назад, на рубеже тысячелетий, я работал директором по технологиям (Chief Technology Officer) у ведущего тогда поставщика программного обеспечения для управления документами - компании TruArc. На тот момент TruArc недавно представила и запатентовала решение AutoRecords - первое коммерчески доступное приложение искусственного интеллекта (ИИ) для управления электронными документами, и мы надеялись получить огромное преимущество в конкурентной борьбе. И хотя у нас были некоторые успехи во внедрении AutoRecords, но были и проблемы. Главной проблемой было то, что решение не всегда работало достаточно хорошо для того, чтобы убедить скептиков, да и рынок не был готов.

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

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

Хотя ИИ существовал уже достаточно давно (еще в 1996 году компьютерная программа Deep Blue фирмы IBM стала первой машиной, выигравшей шахматную партию у действующего чемпиона мира Гарри Каспарова), он всё ещё не стал широко распространенной технологией.

Мой комментарий: На мой взгляд, термин «искусственный интеллект» всегда означает технологию будущего. Как правило, мы не относим к ИИ уже привычные технологии, которые когда-то, на заре своего развития, уверенно попадали в эту категорию! :)

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

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

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

Опыт внедрения AutoRecords показал, что большинство организаций не было готово к решениям на основе ИИ. Это стало очевидным, когда мы столкнулись с проблемами во время исследования возможностей AutoRecords, проведенного Национальными Архивами США (NARA). Исследование включало применение устаревших перечней, первоначально разработанных для бумажных документов, и использование плохо подходящих обучающих наборов документов, которые оказались неэффективными для AutoRecords. Кое-кто, конечно, может сказать, что это недостаток ИИ - разве ИИ не должен автоматически адаптироваться к Вашим специфическим условиям? Как оказалось, ИИ, как и ребенок, не может сразу начать «бегать» до того, как научится «ползать», а затем «ходить». Требуются время и определенные инвестиции для того, чтобы научить и подготовить его правильно «бегать».

Но проблема с AutoRecords не сводилась только к неготовности организаций. Было много других проблем, с которыми нам ещё предстояло столкнуться. Крупной проблемой было то, что у нашего решения была единая точка отказа -  процесс классификации (категоризации).

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

Проблему с «одномерной» классификацией можно проиллюстрировать на простом примере резюме. Резюме имеет характерную структуру, и AutoRecords можно было очень хорошо научить, на что оно похоже. Однако очень часто недостаточно просто сказать, что документ – это резюме.

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

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

Затем возникает проблема ложных положительных и отрицательных результатов классификации. В документе может просто обсуждаться резюме, и сам он резюме являться не будет; или, наоборот, резюме, описывающее опыт работы, может быть классифицировано как-то иначе. Как оказалось, люди редко опираются на один элемент информации, когда принимают решение о том, что объект является документом. Почему ИИ должен действовать иначе? Нам нужно больше измерений, а попытка угадать одну наиболее подходящую категорию давало нам в итоге лишь один кусочек головоломки.

Среди прочих проблем можно назвать следующие:

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


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


• Масштабируемость. Когда мы начинали внедрять AutoRecords, мы имели дело с тысячами документов единовременно, однако в нынешние времена некоторым из наших крупных клиентов потенциально предстоит работать с массивами из миллиардов документов, и объёмы данные только растут. Совсем недавно крупное американское федеральное ведомство попыталось использовать развернутые на собственной площадке (необлачные) ИИ-сервисы для анализа своих документов, только для того, чтобы с запозданием понять, что на обработку имеющихся у них документов уйдут годы, и новые документы будут поступать быстрее, чем они смогут обрабатывать существующие.


• Перемены и изменения. Алгоритмы, технологии, сроки хранения и правила управления документами все время изменяются. Систему AutoRecords необходимо обновлять, переобучать и постоянно дополнять новыми инструментами для того, чтобы подключаться к множеству разных хранилищ и технологий. Данная технология требовала больших усилий на обновление и обслуживание средств интеграции, причём часто приходилось иметь дело с недостаточно развитыми API-интерфейсами.

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

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

(Окончание следует, см. http://rusrim.blogspot.ru/2017/11/2.html )

Тим Шинкль (Tim Shinkle, о нём см. также https://www.linkedin.com/in/tim-shinkle-4583121/ ), вице-президент американской фирмы Millican and Associates по оказанию услуг в области менеджмента информации

Источник: сайт IDM – Image and Data Manager
http://idm.net.au/article/0011369-automated-electronic-records-management-are-we-there-yet