Ценность использования графов знаний
Графы знаний и семантическая технология являются предпочтительным подходом к решению сложных бизнес-задач, особенно тех, которые требуют глубокой интеграции информации, которую раньше было трудно согласовать, например данных, связанных с клиентами и соблюдением нормативных требований.
Почему это кажется сложным?
В целом, традиционные технологии поощряют сложность, и они поощряют ее за счет специального внедрения новых структур данных. Когда вы решаете насущную проблему, введение новой структуры данных (новый набор таблиц, новая структура данных json, новое сообщение, новый API и т. д.) кажется целесообразным. Что редко замечается, так это накопленный эффект многих мелких решений, принятых таким образом.
Мы были у клиента из сферы здравоохранения, который признался (они почти хвастались этим), что у него есть данные о пациентах в 4000 таблицах в различных системах. Это в значительной степени гарантирует, что у вас нет надежды получить полную картину о здоровье и обстоятельствах пациента. Не существует человека, который мог бы написать соединение из 4000 таблиц, и нет системы, которая могла бы его обработать, даже если бы оно было возможно записать.
Это проявляется везде, куда бы мы ни посмотрели. Каждое корпоративное приложение, которое мы подробно рассмотрели, в 10–100 раз сложнее, чем необходимо для решения поставленной задачи.
Системы систем (то есть совокупность тысяч прикладных систем, управляемых фирмой) в 100–10 000 раз сложнее, чем должно быть. Эта сложность проявляется для пользователей, которым приходится потреблять информацию (так много систем, которые нужно опрашивать, каждая из которых произвольно отличается), а также для разработчиков и интеграторов, которые борются с действиями по защите от чтения, чтобы сохранить целостность хотя бы частичной.
Два других фактора усугубляют проблему:
- Приобретение новых компаний неизбежно приводит к возникновению новой экосистемы приложений, с которой необходимо иметь дело.
- Неструктурированная информация. Огромное количество важной информации по-прежнему представлено в неструктурированной (текстовой) или полуструктурированной форме (XML, Json, HTML). До сих пор было практически невозможно осмысленно объединить эти знания со структурированной информацией, на которой работает бизнес.
Давайте посмотрим, как это проявляется с точки зрения клиента 360° и соблюдения требований.
Клиент 360
В конце концов, большинство фирм решают, что предоставление информации обо всем, что известно об их клиентах, имеет большое стратегическое значение. Есть несколько причин, по которым это сложнее, чем кажется.
Мы суммируем некоторые из них здесь:
- Данные о клиентах повсюду. Каждая система, которая размещает заказ или предоставляет услугу, имеет свой собственный, часто локально сохраняемый набор данных о «клиентах».
- Данные о клиентах содержатся в различных форматах. Электронная почта и звонки в службу поддержки представляют собой одни из самых богатых способов взаимодействия большинства компаний со своими клиентами, однако этим компаниям сложно объединить данные таких звонков с данными о транзакциях клиентов.
- В разных системах клиенты идентифицируются по-разному. Каждая система, работающая с клиентами, присваивает им какой-то идентификатор клиента. Некоторые системы используют эти идентификаторы. Многие этого не делают. В конце концов кто-то предлагает «универсальный идентификатор», чтобы у каждого клиента был ровно один идентификатор. Это почти никогда не работает.
Слишком легко недооценить, насколько сложно будет изменить все устаревшие системы, которые хранят данные о клиентах. И, как следует из следующего пункта, это может быть логически невозможно.
Само понятие «клиент» широко варьируется от системы к системе. В некоторых системах клиент является отдельным контактом, в другом случае это фирма, но в другой роли и в еще одной таблице. Для некоторых это банковский счет (я знаю, как странно это звучит, но мы это видели). Каждая система должна хранить разные данные о клиентах для выполнения своей конкретной функции. Централизация этого процесса создает бремя сбора большого количества данных во время подключения клиента, которые могут быть никем не использованы.
Согласованность
Основная причина сложности систем, связанных с соблюдением требований, заключается в том, что вы соблюдаете обширную сеть законов и постановлений, написанных исключительно в текстовом виде и охватывающих широкий спектр пересекающихся юрисдикций. Эти законы и правила постоянно меняются и всегда по-новому интерпретируются посредством выводов, проверок и судебных дел.
Общий подход заключается в том, чтобы выделить небольшой объем, прочитать как можно больше и создать специальные системы для их поддержки. Но трудность заключается в том, что на протяжении всего процесса в нём участвуют люди. Все документы необходимо интерпретировать, и для того, чтобы эта интерпретация была реализована, как правило, она должна осуществляться с помощью системы, созданной вручную.
Кратко о графах знаний и семантической технологии
Графы знаний и базы данных графов в последнее время получили широкое распространение, поскольку стало известно, что многие крупные цифровые компании имеют в своей основе граф знаний:
- Google. Граф знаний Google – это то, что сделало их способность отвечать намного лучше, чем поиск по ключевым словам, который запустил их первое предложение. Это также обеспечивает их целевое размещение рекламы.
- LinkedIn, Facebook, Twitter — все они способны быстро масштабироваться и быть гибкими, поскольку построены на графовых базах данных.
- Большинство крупных финансовых учреждений. Почти все крупные финансовые учреждения в той или иной форме разрабатывают инициативу «Граф знаний» или «База данных графов».
Графовые базы данных
База данных графов выражает всю свою информацию в единой простой структуре отношений: два «узла» соединены «ребром».
Узел — это некая идентифицируемая вещь. Это может быть человек, место, электронная почта или транзакция.
Ребро — это связь между двумя узлами. Он может указывать, где кто-то живет, что он отправил или получил электронное письмо или что он был стороной транзакции.
Графовая база данных не требует настройки эквивалента реляционной структуры таблицы перед сохранением каких-либо данных, и вам не нужно знать всю структуру базы данных и все ее метаданные, чтобы использовать графовую базу данных. Вы можете просто добавлять новые ребра и узлы к существующим узлам, как только вы их обнаружите. Сеть (граф) растет органично.
Наиболее распространенным вариантом использования графовых баз данных является аналитический. Существует целый класс аналитики, использующей свойства сети (т. е. насколько тесно Х связан с У, какой кратчайший путь от a до b).
Графы знаний
Большинство графовых баз данных ориентированы на данные низкого уровня: транзакции, коммуникации и тому подобное. Если вы добавите к этому слой знаний, большинство людей будут называть это графом знаний.
Область медицинских знаний (болезни, симптомы, взаимодействие лекарств и даже весь геном человека) была преобразована в графы знаний, чтобы лучше понять и изучить взаимосвязанную природу здоровья и болезней.
Часто знания в графе знаний извлекаются из документов и преобразуются в структуру графа. Когда вы объединяете граф знаний с конкретными данными в базе данных графов, эта комбинация очень эффективна.
Семантическая технология
Семантическая технология — это подход на основе открытых стандартов к графам знаний и графовым базам данных. (Google, Facebook, LinkedIn и Twitter начинали с подходов с открытым исходным кодом, но создали свои собственные версии этих технологий.)
Большинству фирм мы рекомендуем использовать открытые стандарты. На каждом уровне стека существует множество продуктов с открытым исходным кодом и продуктов, поддерживаемых поставщиками, а также накоплен большой объем знаний о том, как решать проблемы с помощью этих технологий.
Семантические технологии реализуют алфавитный набор стандартов, включая: RDF, RDFS, OWL, SPARQL, SHACL, R2RML, JSON-LD и PROV-O. Если вы с ними не знакомы, это звучит как техно-болтовня. Суть семантической технологии заключалась в том, что она сложна. Так и есть, особенно если вам нужно принять и понять все это одновременно. Но мы используем эту технологию уже почти 10 лет и выяснили, как помочь людям адаптироваться, используя тщательно подобранные подмножества каждого из стандартов и приводя примеры, чтобы радикально сократить кривую обучения.
Несмотря на то, что некоторые остаточные сложности все еще существуют, мы считаем, что вложение времени того стоит. Стек семантических технологий решил большое количество проблем, которые графовым базам данных и графам знаний приходится решать самостоятельно, по частям.
Некоторые из этих возможностей:
Схемы. Графовые базы данных и даже графы знаний не имеют стандартной схемы, и если вы хотите ввести ее, вам придется реализовать эту возможность самостоятельно. Семантические технологии имеют очень богатый язык схем, который позволяет определять классы на основе того, что они означают в реальном мире. Мы обнаружили, что дисциплинированное использование этого языка формальных схем создает модели предприятия, которые понятны, просты и в то же время охватывают все необходимые детали.
Глобальные идентификаторы — семантическая технология использует URI (версия Unicode, которая называется IRI) для идентификации всех узлов и дуг. URI очень похож на URL-адрес, и лучше всего создавать его на основе вашего доменного имени. Именно эти глобальные идентификаторы позволяют графам «самособираться» (в семантической технологии не пишутся объединения, данные уже объединены системой).
Управление идентификацией – семантическая технология имеет несколько подходов, позволяющих жить с тем фактом, что вы присвоили несколько идентификаторов одному и тому же человеку, продукту или месту. Один из основных называется «sameAs» и позволяет системе знать, что «n» разных URI (которые были созданы из данных в «n» разных системах с «n» разными локальными идентификаторами) все представляют один и тот же объект в реальном мире, и вся информация, прикрепленная к любому из этих URI, доступна всем потребителям данных (конечно, с соблюдением требований безопасности).
Разрешение ресурсов – некоторые системы имеют глобальные уникальные идентификаторы (вы видели те 48-значные строки цифр и букв, которые идут в комплекте с лицензиями на программное обеспечение и тому подобное), но они не очень полезны, если у вас нет специальных средств для выяснения того, что они собой представляют или означают. Поскольку передовая практика семантических технологий предполагает, что ваши URI должны основываться на принадлежащем вам доменном имени, у вас есть возможность предоставить людям возможность узнать, что «означает» URI и с чем он связан.
Вывод — с помощью семантической технологии вам не нужно выражать все явно, как в традиционных системах. Существует большой объем информации, которую можно вывести на основе формальных определений в графе знаний как части семантической схемы и в сочетании с подробными утверждениями данных.
Управление ограничениями – большинство графовых баз данных и графов знаний не были созданы для интерактивного онлайн-доступа к обновлениям для конечных пользователей. Из-за их гибкости сложно обеспечить управление целостностью. Семантическая технология имеет менеджер ограничений, управляемый моделью, который может обеспечить поддержание целостности базы данных.
Источники данных. Одним из ключевых вариантов использования семантической технологии является объединение данных из разных источников. Это создает новое требование при просмотре данных, полученных из многих источников, которые вам часто необходимо знать: откуда взялся этот конкретный фрагмент данных? Semantic Technologies решила эту проблему общим способом, который может сводиться к отдельным утверждениям данных.
Реляционная интеграция и интеграция больших данных — вы не будете хранить все свои данные в графовой базе данных (семантической или какой-либо другой). Часто вам захочется объединить данные на графе с данными в существующих системах. Семантические технологии предоставили стандарты, и есть поставщики, которые реализовали эти стандарты, так что вы можете написать запрос, который объединяет информацию в графе с информацией в реляционной базе данных или хранилище больших данных.
Трудно охватить столь широкую тему на одной странице, но, надеюсь, это дает представление о том, что дает этот подход.
Применение графовой технологии
Так как же эти технологии позволяют решать некоторые более распространенные бизнес-задачи?
Клиентское обслуживание в банке
Мы работали с банком, который мигрировал в облако. В рамках миграции они хотели унифицировать свое представление о своих клиентах. Они собрали рабочую группу из всех подразделений, чтобы создать единое определение клиента. По сути, это была невыполнимая задача.
Для некоторых подразделений (инвестиционно-банковская деятельность) клиентом была компания, для других (обработка кредитных карт) — обычно физическое лицо.
Существовали различия не только в типе, но и все данные, которые они хотели и должны были иметь в этих разных контекстах, были разными.
Кроме того, одна группа (корпоративные клиенты) придерживалась очень широкого определения клиента, включающего всех, с кем они потенциально могли связаться. Излишне говорить, что группа «Знай своего клиента» не могла согласиться с этим определением, поскольку каждый новый клиент обязывает их выполнять предписанный набор действий.
Мы снова и снова обнаруживали, что если вы начнете с термина (скажем, «Клиент») и попытаетесь дать ему определение, вы будете глубоко разочарованы. С другой стороны, если вы начнете с формальных определений (одно из которых для «Клиента» может быть «Лицо, которое является владельцем или бенефициаром финансового счета» (и, конечно, финансовый счет должен быть формально определен), нетрудно прийти к соглашению о том, что означает эта концепция и каков будет набор людей в этом случае. Отсюда нетрудно прийти к согласованному названию для каждой концепции.
В данном случае мы создали набор формальных семантических определений для всех концепций, связанных с клиентами. На первый взгляд может показаться, что мы только что капитулировали и позволили каждому иметь собственное определение того, что такое «Клиент». Хотя в модели существует несколько определений «Клиента», они полностью интегрированы таким образом, что любое лицо может быть автоматически отнесено к категории и одновременно к нескольким определениям «Клиента» (что обычно и происходит).
Представленная ниже картинка, в которой, к счастью, опущены многие детали реализации, отражает суть идеи. Каждый овал представляет определение «Клиент».
В правом нижнем углу показана группа людей, подписавшихся на бесплатную услугу кредитного рейтинга. Это люди, у которых есть «Счет» (счет кредитной отчетности), но это счет без финансовых обязательств (нет баланса, вы не можете использовать его и т. д.). Требования «Знай своего клиента» (KYC) действуют только для людей с финансовыми счетами. Это совпадение предполагает, что у некоторых людей есть финансовые и нефинансовые счета. Синяя звезда представляет финансового клиента, который также подпадает под правила KYC. Наконец, высокий овал вверху представляет группу людей и организаций, которые не должны быть клиентами, так называемые «санкционные списки». Вы можете подумать, что эти два овала не должны пересекаться, но поскольку санкции постоянно меняются, а наши знания об отношениях с клиентами постоянно меняются, вполне возможно, что мы обнаружим постфактум, что текущий клиент находится в санкционном списке. Мы представили это как коричневую звезду, которая одновременно является финансовым клиентом и кем-то, кто не должен быть клиентом.
Мы считаем, что этот подход уникальным образом справляется со сложностью, присущей отношениям крупных компаний со своими клиентами.
В другом случае мы использовали аналогичный подход для поиска клиентов, которые также были поставщиками, что часто представляет интерес и обычно трудно обнаружить последовательно.
Поставщик правовой и нормативной информации
Еще один похожий проект, над которым мы работали, был с крупным поставщиком правовой и нормативной информации. Фирма обрабатывает несколько миллионов документов в день, в основном судебные разбирательства, а также все изменения в законах и правилах. В течение многих лет эти документы маркировались с помощью комбинации скриптов и тегов. Постепенно актуальность и точность их маркировки стали отставать от конкурентов.
Им нужно было помочь им разработать онтологию и граф знаний, а так же применить компьютерную лингвистику для извлечения данных из документов и согласования их с онтологией. Теперь релевантность их концептуального поиска сейчас значительно опережает конкурентов.
Теперь они начинают работу над системой следующего поколения, которая выводит этот базовый вопрос на новый уровень: можно ли вывести новую информацию при поиске, используя имеющийся у них граф знаний плюс более глубокое моделирование значений?
Инвестиционный банк
Отдел юридического и нормативного регулирования крупного инвестиционного банка. Наша первоначальная задача заключалась в том, чтобы помочь с соблюдением законов о хранении документации. На обоих концах этой области существуют сложности. С одной стороны, существуют сотни юрисдикций, которые постоянно принимают и изменяют законы и правила. На другом конце находятся миллиарды документов и баз данных, которые необходимо последовательно классифицировать, прежде чем ими можно будет правильно управлять.
Мы построили графы знаний, в которых собрана вся контекстная информация, окружающая документ или репозиторий. Сюда входили такие данные: кто является автором, кто разместил это там, в каком отделе они находились, какой код стоимости они взимали и т. д. Для каждого бита этих контекстных данных были доступны текстовые данные. Нам удалось добавить простую обработку естественного языка, которая позволила им точно классифицировать около 25% данных, находящихся под управлением. Хотя 25% вряд ли можно назвать полным решением, это можно сравнить с ½ от 1%, которые до этого момента были правильно классифицированы. Начиная с этого, они запустили проект с более сложным НЛП и машинным обучением, чтобы создать «мастер классификации» для конечных пользователей, который могут использовать все менеджеры репозиториев.
Мы перешли к другим связанным вопросам соответствия, включая управление юридическими блокировками, операционными рисками и более комплексный подход к соблюдению всех требований.