В качестве одного из примеров работы Архиграф.ЛОГОС и библиотки Ridley, разберу процесс диагностики оборудования. На примере гипотетического поезда.
Представим картину - поезд останавливается на станции, мимо каждого вагона проходит сотрудник (диагност) и высокотехнологичным молотком стучит по узлам и агрегатам, выявляя неисправности (недавно путешествовал и видел этот процесс).
В качестве итога сотруднику нужно сдать отчет о проведенной диагностике.
Допустим, этот отчет он пишет в произвольной форме, на естественном языке - простом, бытовом, сдобренном профессиональными терминами.
Поставим задачу автоматического анализа текста отчета. Опишем концептуальную модель.
Проще говоря, здесь описано только что могут быть поезда, которые следуют по маршруту, у поездов есть вагоны и так далее. Эта концептуальная схема может быть наполнена экземплярами классов (Individual в терминах OWL) - так мы добавим конкретный поезд, конкретный вагон, свяжем его соответствующим схеме ребром (предикатом) с конкретным поездом.
Конечно на практике всё может быть сложнее - больше вершин и ребер в графе. В схему можно включить больше доменов - информацию об остановках, добавить сотрудников с зонами ответственности, пассажиров… Надеюсь, смысл вам ясен. Иногда графовые базы сравнивают с SQL-табликами, в которых всё всегда связано (не нужно делать много хитрых join).
Переходим к анализу отчета диагноста. Представим такой текст: “Осмотрен поезд №ХХХ, в вагоне №1 найдена неисправность на узле А. Сломана деталь Б - треснул подшипник.”. Конечно у меня нет реального отчета, это только мои домыслы.
Не буду вдаваться в детали, но из этого текста можно собрать подграф нашего графа знаний. О том, как это делается, можно почитать в других статьях этого блога.
Если у нас нет онтологии и мы применим к этому тексту какой-то простой подход - выделим именованные сущности, обучим несколько классификаторов выдавать тип сообщения (например применим подход с intent, как в чат-ботах), или подход с slot filling - мы можем получить неплохой результат.
Но что, если мы захотим изменить схему? Перестроить связи, добавить новые узлы? Или захотим анализировать отчеты о проданных товарах и услугах (чай в подстаканнике, чистую наволочку), информацию о вынужденных остановках, о смене вагонов на станциях? Будем писать классификаторы для NERов и Интентов? Собирать и размечать датасеты? Схема может усложняться бесконечно. В какой-то момент станет понятно, что такой простой подход может решать только узкие задачи, а расширение его будет обходиться всё дороже.
Собственно по этой причине и разработан Архиграф.ЛОГОС и библиотека Ridley.
P.S.
Еще немного размышлений на тему семантики. Смысловые отношения между сущностями в дистрибутивных семантических нейросетевых моделях (те что выдают вектора эмбеддингов) представлены отношениями (расстоянием) векторов в семантическом пространстве. То что происходит в черной коробке нейронки - чаще всего тайна. Если вы экспериментировали с такими моделями, то знаете что результаты могут быть неожиданными. Если нас интересует анализ смысла слов, именно смысла высказываний, того в какие отношения вступают сущности в тексте, нам нужна еще и понятная структура диалога/смысла текста. Чтобы внести эту структуру в нейронку, поверх можно добавить еще один архитектурный слой - программный, где кодом описывают как интерпретировать результаты. Или обучить, например, seq2seq модель и еще раз столкнуться с последствиями вероятностной природы нейронок и зависимостью от датасетов. Архиграф.ЛОГОС решает несколько задач - объяснимость модели и принятых решений, гибкость в изменении модели предметной области и скорость изменений - в этом подходе просто не нужны долгие процессы разметки датасетов и обучения нейросетей (хоть они там и есть, даже целых 3 штуки).