За последнее десятилетие в различных отраслях появилось множество решений на базе технологий больших данных, и сегодня вопросы сбора и хранения данных часто обсуждаются уже в контексте узкоспециализированных частностей. Относительная простота построения корпоративного хранилища привела к тому, что компании стали накапливать огромные массивы данных, неизбежно со временем сталкиваясь с проблемой их качества, согласованности и контроля. Компании стали буквально зарастать наборами данных, собранными в разное время разными подразделениями в разных форматах. Как следствие, выросли расходы на инфраструктуру и переработку данных в ценную информацию.
Ажиотаж вокруг больших данных привел к тому, что данные, не всегда оправданно, стали рассматриваться как самостоятельная ценность — их накапливают, не уделяя особого внимания интеграции с общим информационными полем организации, а сам факт сбора данных за определенный период времени создает у топ-менеджеров ощущение комфорта. Все это иногда приводит к тому, что бизнес не знает точно, какая информация есть в его распоряжении, ошибочно полагая, что, как только потребуется, данные будут обязательно переработаны в нечто ценное, направленное на благо компании. Однако практика свидетельствует об обратном.
Компании часто недооценивают затраты на поиск, предобработку и анализ данных. По подсчетам аналитиков, в среднем только 3% наборов данных, собираемых внутри компаний для отражения ключевых показателей работы подразделений (сведения о заказах, характеристики производства, списки клиентов и пр.), не содержали ошибок. Хуже того, около половины всех вновь поступающих сведений обычно содержат критические ошибки, способные в случае их необнаружения оказать серьезное влияние на производственный процесс.
Сегодня получила распространение идея о необходимости стандартизации терминологии, используемой в рамках одной организации. Например, «ценный клиент» для отдела маркетинга и «ценный клиент» для отдела продаж — не эквивалентные понятия, и для улучшения информативности отчетов необходимо учитывать и уметь объяснять различие между ними. Наличие согласованного словаря, которым может пользоваться как бизнес, так и отдел разработки, — давняя мечта аналитиков, в эпоху больших данных получившая свой финансовый эквивалент: умение сопоставлять информацию из разных источников и быстро реагировать на внешние изменения вполне может стать определяющим фактором финансового успеха.
В ответ на эти запросы бизнеса вопросам контроля качества и согласованности данных стало уделяться больше внимания — появились продукты, реализующие концепции Data 360° и Linked Enterprise Data, но, оставаясь в рамках парадигмы управления данными, можно лишь оптимизировать и улучшать уже существующие процессы до момента, пока их сложность и объемы сырых данных снова не перерастут текущие возможности ИТ-систем компании. Для качественного изменения необходимо перейти от данных к знаниям, и один из возможных путей — применить известный подход формального представления знаний в базе знаний либо в графах знаний (knowledge graph). Как и нейронные сети, базы знаний зародились еще на заре цифровой истории, но, в отличие от нейронных сетей, о базах знаний сегодня пока еще говорят мало, хотя постепенно все больше компаний начинают задумываться об онтологиях, логических выводах и т. п., что свидетельствует о постепенном смещении акцента от ведения бизнеса на основе данных к ведению бизнеса на основе знаний.
Граф знаний — способ формализации знаний о реальном мире. При этом должны выполняться следующие условия.
Составляется формальное описание классов сущностей реального мира («Человек», «Счет», «Автомобиль») с иерархией и ограничениями. Иногда описание включает в себя правила логического вывода (например, если сущность относится к классу «Автомобиль» и имеет более семи мест для перевозки пассажиров, то ее нужно классифицировать как «Автобус»). Такое описание называется онтологией.
Факты о принадлежности сущности к определенному классу, о наличии свойств и связей друг с другом представляются в виде ориентированного графа, где вершинами служат сами сущности и их характеристики, а дугами — свойства, перечисленные в онтологии. Таким образом, каждый записанный факт поддается формальной интерпретации.
Граф знаний позволяет отвечать как на вопросы, относящиеся к онтологии («Какие атрибуты есть у сущности “Клиент”?»), так и на вопросы по накопленным фактам («Сколько различных подрядчиков было у предприятия в 2018 году?», «Какие товары соответствуют товару “Лего Текник — Экскаватор”?»).
Необходимо отличать графы знаний от графовых баз данных из разряда NoSQL, обеспечивающих эффективный доступ к данным, наиболее подходящий для выполнения конкретных алгоритмов. В случае графов знаний формируется единое разделяемое описание предметной области, а фокус смещается с хранения данных к их представлению в терминах предметной области.
Предположим, компания обладает графом знаний, в котором перечислены все используемые ею источники информации, а также все термины, применяемые компанией в документации к бизнес-процессам и в повседневном общении. Кроме того, в том же графе указано, как именно из данных получаются сущности, фигурирующие в отчетах и бизнес-процессах. Все это собрано в одном месте, и каждый сотрудник компании, обладающий соответствующими правами, может посмотреть все этапы трансформации данных и в случае потребности внести корректировки. ИТ-отдел точно понимает запросы бизнеса — его сотрудники опираются на общепринятую в компании терминологию и в ряде случаев выполняют их быстрее, чем ранее, и с меньшим количеством ошибок благодаря возможности делать запросы к базе знаний на формальном уровне. Такая структура значительно повышает прозрачность использования данных в организации, что, в свою очередь, ускоряет выполнение сопряженных операций: получение нужного набора данных, сопоставление таблиц в независимых базах данных и пр.
Граф знаний может также выступать в роли хранилища мастер-данных. Если компания уже располагает MDM-системой, управляющей референтными данными, то база знаний обогащает ее правилами логического вывода, позволяет привести в соответствие с внешними стандартами (например, при слиянии двух организаций, использующих разные MDM-продукты) и расширить новыми концептами без изменений в структуре хранимых данных (например, задать классификацию клиентов). Такие решения называются Semantic MDM (SMDM).
Другой пример основан на реальном проекте, выполненном компанией DataFabric. Используя реестры ЕГРЮЛ и ЕГРИП, можно сформировать граф знаний о всех юридических и физических лицах, участвующих в определенной деятельности в рамках российского правового поля. Получившийся граф может служить для проверки контрагентов как источник статистических данных или для построения аналитических отчетов. В графе содержится около 6 млрд фактов о российских компаниях, включая исторические, не входящие в актуальные версии реестров. В качестве онтологии используется стандарт FIBO (Financial Industry Business Ontology, spec.edmcouncil.org/fibo), что обеспечивает семантическую совместимость с данными из других информационных систем, использующих ту же онтологию для представления сведений, например, о зарубежных компаниях. На базе такого графа знаний работают два сервиса: «Топология Бизнеса» — визуальный интерфейс (рис. 1) к графу знаний; сервис интерактивных анкет (рис. 2) — формирование анкеты предприятия с полями, автоматически заполняемыми из графа знаний после введения ИНН или ОГРН компании. Пользователь ссылается на концепты онтологии и размечает, где в анкете должны быть адрес, название и, например, уставной капитал. При этом можно не только ссылаться на сущности ФНС, но и добавлять к анкете характеристики Росстата и других подключаемых баз данных. Наличие формализованной схемы данных позволяет строить прикладные решения, а пользователям — применять привычную им терминологию, а не выискивать нужный столбец в базе данных. Как результат, существенно уменьшается количество ошибок.
.jpg) |
| Рис. 1. Пример графа знаний в системе «Топология бизнеса» |
.jpg) |
| Рис. 2. Форма создания полей анкеты в сервисе интерактивных анкет |
Переход от данных к знаниям не означает создания новой базы — речь идет о смене парадигмы работы с корпоративной информацией. Данные, обогащенные семантикой с помощью графов знания, становятся доступны для автоматической обработки, что можно считать первым шагом на пути к интеллектуальным информационным системам.
***
Компании, нашедшие способ контролировать рост сложности своих информационных систем, получают преимущество и фундамент для дальнейшего роста, смещая акцент от ведения бизнеса на основе данных к ведению бизнеса на основе знаний, что особенно важно в условиях цифровой экономики. Однако для работы с базой знаний требуется определенная квалификация команды — в компании должен появиться инженер по знаниям, отвечающий за процессы их сохранения, приумножения и распространения. Сегодня на рынке таких специалистов почти нет. Необходимо будет также разобраться с инфраструктурой — технологический стек инструментов поддержки базы знаний может сильно отличаться от имеющегося в компании.
Евгений Хлызов (eugene.hlyzov@datafabric.cc) — технический директор, компания DataFabric (Санкт-Петербург). Статья подготовлена на основе материалов выступления на конференции «Технологии управления данными 2018».
