serge_gorshkov


Сергей Горшков - о бизнесе в сфере ИТ

о семантической интеграции, программировании, управлении...


Previous Entry Share Next Entry
ИТ как отрасль-дауншифтер: от экспертных систем к Excel'ю
serge_gorshkov
Когда я рассказываю потенциальным клиентам о семантических технологиях и управлении знаниями, нередко кто-нибудь из слушателей в возрасте 45+ восклицает: "Да это же экспертные системы!". И, как правило, после этого теряет интерес к теме.

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

Что же случилось потом - куда делись эти системы? Почему в первой половине 90-х (когда я начинал свой путь в ИТ) о них уже порядком забыли, а в моде были реляционные СУБД, электронные таблицы и объектно-ориентированное программирование? Почему на очередном витке развития технологий, в 2000-х, в моду вошли BI, big data, машинное обучение, то есть средства, основанные в первую очередь на статистическом анализе массивов численной информации, а не логических вычислениях? По моему мнению, причины этого явления таковы.

  1. Простые и очевидные проблемы - несовершенство тогдашних пользовательских интерфейсов, недостаток производительности при сложных вычислениях и обработке больших объемов данных, недостаточное развитие сетевых архитектур. Да, Prolog - мощный язык, но отраслевой эксперт писать на нем не сможет: конструирование и отладка правил превращается в ад. Если вычисление логического вывода возможно только на мэйнфрейме, а не на PC, это сильно сужает сферу применения технологии. В отсутствие сети всю базу знаний необходимо держать локально на каждой машине, что порождает, например, бесконечные сложности с синхронизацией. Все эти причины очевидны, но их недостаточно для объяснения провала экспертных систем. Значит, должны быть и более важные.

  2. Эти системы требуют от человека слишком много думать! Формализовать картину мира, осознать и сформулировать правила получения логических выводов - это огромная и очень сложная работа, на которую способен далеко не каждый специалист. Любая ошибка в формализации приводит к тому, что система выдает неверные результаты, что дискредитирует, конечно, в первую очередь саму систему, а не того, кто ее наполнял. Моя гипотеза состоит в том, что при широком распространении экспертных систем качество их наполнения резко падает, они начинают "гнать лажу", у них портится репутация, и от них отказываются.

  3. В базовом варианте любая система получения логических выводов страдает позитивизмом. Считается, что она содержит единственно "правильную" модель мира, в которой образуются заведомо корректные выводы. Однако на практике (см. предыдущий пост) картины мира даже у разных сотрудников одной компании могут кардинально отличаться. Отсутствие поддержки разных точек зрения - еще один фактор, который вызывает отторжение к "умной" системе у пользователей, порождает протест и несогласие с ней.

  4. Чисто технической причиной, "срубившей" на корню ростки экспертных систем, стал рост популярности объектно-ориентированного программирования. ООП - полезная парадигма разработки ПО, но она подразумевает принципиально иной способ моделирования объектов и их связей, нежели онтологическое моделирование в экспертных системах. То же самое относится к реляционным СУБД: формализация модели мира в виде структуры реляционной базы исключает возможность автоматизации логических вычислений с данными о мире, по крайней мере в терминах любых видов формальной логики. Рост популярности этих технологий массово перестроил сознание автоматизаторов в противоположную онтологическому моделированию сторону.

  5. За экспертные системы взялись слишком рано. В 1970-х годах еще не были толком решены задачи базовой корпоративной автоматизации (ERP и т.п.), следовательно - не были накоплены объемы исходной информации, которую можно использовать как основание для получения логических выводов. Все данные в такие системы приходилось вносить вручную, тратя на это время; нельзя было ни автоматически получить исходную информацию, ни применить полученные выводы. В результате, экономический эффект от применения даже корректно наполненной экспертной системы оказывался ограниченным.

К сегодняшнему дню, как в старом анекдоте, "ложечки нашлись, а осадочек остался". бОльшая часть перечисленных проблем решена, почти все - осознаны; создан полный стек технологий для работы с онтологическими моделями (OWL + SPARQL + SWRL + машины логического вывода и т.д.). 99% даже самых маститых ИТ-специалистов, помнящих "старые добрые времена", не смогут толком объяснить, чем же плохи были тогдашние экспертные системы, и уж тем более - почему это отношение надо переносить на сегодняшние технологии. Но, как и 40 лет назад, люди стремятся выбирать самые простые средства обработки данных, самые очевидные инструменты, и крайне не любят предаваться рефлексии и задумываться о том, как они думают, чтобы "научить" этому информационную систему... У меня сложилось впечатление, что любой администратор охотнее примет решение на основании колонки цифр, рассчитанных по принципиально непознаваемому алгоритму неким "черным ящиком", вобравшим в себя статистику всего чего угодно вплоть до плотности газов в атмосфере Венеры, нежели на основании четко обоснованного многоступенчатого логического вывода, полученного на основании знаний экспертов. Поверить мистическому оракулу куда проще, чем конкретному эксперту (использование слова "оракул" не является ссылкой на название конкретных компаний или программных продуктов :)) ).

Как я уже неоднократно говорил, Карфаген должен быть разрушен. Упрощение структуры данных и методов их обработки, обусловленное человеческой ленью и стремительно растущим объемом доступных данных, имеет очевидное противоречие с задачей повышения эффективности их использования (впрочем, далеко не у всех такая задача имеется). Развитие ИТ должно происходить в сторону действительного, а не мнимого повышения "интеллектуальности" систем, усложнения и совершенствования методик моделирования, применения логических вычислений. Рано или поздно онтологическая революция свершится.

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

  • 1
Движение экспертных систем повалилось из-за того, что наобещали горы того, что выполнить не смогли. После чего, оттуда ушли деньги.

Это основная и единственная причина резкого падения интереса.

Онтологии - это просто ребрендинг, позволяющий стрясти денег. Сейчас подошли big data и deep learning. В следующем десятилетии придумают новые волшебные слова.

Экспертные системы есть и достаточно развитые, например в медицине. И кудесники IBM пишут части своих чудо-модерновых программ на том же Прологе. Потому что ничего лучше не придумано.

Другое дело, задач для простых систем сейчас море и экспертные системы просто теряются на их фоне.

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


Про завышенные ожидания и обещания - верно и понятно, я тут больше про причины того, _почему_ тогда эти обещания не были выполнены.

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

Например, ни одна старая экспертная система не могла бы хранить информационную модель предприятия, то есть выступать в виде RDM+MDM, а сегодня мы можем это делать (кроме нашего продукта - см. TopBraid RDM). Стандартизованы и расширены способы доступа к модели => расширились способы ее применения. Старые системы были слишком сфокусированы на единственной функции - автоматизации получения выводов, что само по себе не делало системы достаточно практичными.

Отсюда же сложности с интеграцией, которые сегодня преодолены в обе стороны - можно легко автоматически получать новую информацию в модель, делать на ее основании выводы и автоматически отправлять куда-то результаты. Можно даже поставить онтологический механизм в основу интеграционной/аналитической архитектуры (см. проект Optique и нашу логическую витрину данных) - со старыми системами такое бы и присниться не могло.

Изменить хотелось бы отношение к технологиям формализации знаний и получения логических выводов - на этом уровне не важно, говорим мы о семантике или о Прологе. Эти технологии часто не рассматривают как возможное решение даже для тех задач, где они очевидно необходимы, например - в системах поддержки принятия решений. Скажем, потенциальные сценарии развития событий будут рассчитывать как угодно - нейросетями, анализом вероятностей на основе больших массивов данных, фиксированными алгоритмами на C++ - но только не при помощи модели и логических вычислений на ней. Это, я считаю, чисто психологическая проблема как заказчиков, так и интеграторов, с которой можно и нужно работать.


Эти обещания не были выполнены, потому что они были нереальны.

Семантические технологии - это куча жутких, совершенно не пригодных для нормальной работы, стандартов. Все идеи идут ещё с тех времён.

Старые системы включают в себя такие вещи, как управление японскими электричками на нечётком прологе.

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

> Семантические технологии - это куча жутких, совершенно не пригодных для нормальной работы, стандартов. Все идеи идут ещё с тех времён.

Это слишком сильное, эмоциональное и не подкрепленное аргументами заявление :)
Которое мы и другие разработчики, работающие с этими технологиями, опровергаем делом.

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


1. Маркетинга вокруг много и шанс потерять в нем разумное зерно достаточно велик. Впрочем семафором тут будет то, что маркетологи чаще всего работают с уже раскрученными технологиями. Таким образом отсеем 90% мусора, а с остальным придется разбираться.
2. Задач для старых подходов тоже еще полно. Освоены далеко не все возможности механизации...
3. У меня есть ощущение, что сейчас у экспертных систем вполне может появиться новая жизнь, технологии действительно серьезно ушли вперед...
4. Кстати, про обещания и их невыполнения: чем сложнее технология, тем сложнее контролировать эксперта и тем сложнее отличить его от шарлатана. Так что это будет всегда. Тут нечего обсуждать.
5. Жизнь идет вперед и на смену старым (не пригодным...) семантическим стандартам придут новые. Ждем их от Сергея Горшкова...
6. Квалифицированные кадры вытесняются неквалифицированными. Последние смелее врут, а проверить квалификацию не возможно... Но мне кажется - это ваще не по теме здесь...

В целом я согласен с постом!

> на смену старым (не пригодным...) семантическим стандартам придут новые. Ждем их от Сергея Горшкова...

Спасибо за комплимент, но - тут формируются завышенные ожидания от Сергея Горшкова )) Как бы не повторить мне судьбу экспертных систем... ))


5 и 6 не работают. Стандарты имеют тенденцию застывать. Можно вспомнить цепочку от двух лошадиных задниц в Римской Империи до ускорителей для шаттлов.

Пролог действительно не для эксперта, а для программиста. А вот в Gensym G2 уже в конце 80-х вполне можно было писать правила логического вывода на человеческом языке (и даже по-русски) в нормальном графическом интерфейсе. Только это дорого (и тогда и сейчас). Плюс интегрировать динамическую экспертную систему с другими информационными системами по вполне стандартным протоколам (ODBC, OPC, JMS, COM, ...).
Думаю, проблема с экспертными системами в том, что при большом числе правил их отладка и поддержание непротиворечивости становится слишком трудоёмкой задачей. В результате, весь потенциальный выигрыш от подхода "нужное правило вызывается тогда, когда складываются входные условия" не реализуется и всё скатывается в излишнюю модульность, где каждый модуль знаний весьма примитивен и машина логического вывода становится слишком мощным (и даже непонятным) инструментом.
Пришедшие следом технологии, такие как ООП и РСУБД, выиграли больше за счёт того, что в них стало можно отступать от принципа 100% согласованности данных в программе с реальностью за окном, то есть вычислительная модель (все эти методы и поля развесистых структур данных, домены данных с первичными и внешними ключами) стала чуть важнее модели предметной области. В экспертных системах практически нет возможностей для подмены понятий, для хаков во имя эффективности вычислений, а обрабатываемые термы являются скорее терминами, чем именами переменных. В современных же программах "реальностью" является диаграмма классов или схема базы данных, а эксперты и пользователи подстраиваются под неё.

Со многим из сказанного согласен. В особенности в части проблемы управляемости правил, возможности охватить умом их выполнение. Как только машина превращается в "черный ящик", она вместо инструмента и помощника становится противником, с которым приходится сражаться.

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

И вот сейчас, как нам кажется, открывается окно для применения другого подхода, который вернет все на свои места: во главу угла поставит субъекта - владельца системы, его интересы и возможности, ресурсы и операции, а ИТ-система будет не создавать собственную версию мира, а поддерживать ту точку зрения на него, в которой владелец системы думает обо всем этом. Да еще учтет точки зрения других субъектов, оперирующих в той же части реальности, и предоставит возможности "наведения мостов" между ними. Будет автоматически перестраивать свое поведение по мере изменения представлений субъектов о реальности. Звучит почти фантастически, но все необходимое для этого у нас уже есть.


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

>> И вот сейчас, как нам кажется, открывается окно для применения другого подхода, который вернет все на свои места
Думаю, настоящий владелец системы не пустит других субъектов "на свою делянку", поэтому моделирование чужих точек зрения будет ему неприятно. А вот фиксация и программная поддержка сложных договоренностей его с субъектами, наверняка будет востребована, поэтому "под капотом" эта новая технология моделирования может дать хороший результат. Особенно по прошествии времени, когда в обычных технологиях уже забывается, для кого было принято то или иное решение, и что _точно_ значит наименование переменной или столбца таблицы базы данных.

> Думаю, настоящий владелец системы не пустит других субъектов "на свою делянку", поэтому моделирование чужих точек зрения будет ему неприятно

В реальности встречаются ситуации, когда владелец сознательно идет на это. Самый простой случай - если какая-то часть деятельности предприятия подлежит регулированию со стороны государства (техническому, санитарному и др.), это уже автоматически создает внешнюю точку зрения. Для владельца объект X - котельная, со своими связями и свойствами, а для гос. инспектора - промышленный объект IV категории опасности с другими свойствами. Конечно, отчеты инспектору нужно предоставлять в "его" терминологии. Точно также приходится "мириться" с чужой точкой зрения при работе на любого крупного заказчика, или при совместной работе нескольких предприятий над одним большим продуктом (оборонка, например).

Особо клиентоориентированные предприятия - тут, правда, нужен незаурядный менеджмент - пытаются применять такой подход даже для общения с обычными клиентами и подрядчиками. Минимум один пример у меня есть перед глазами. Дело в том, что услуга, которую продает предприятие, и услуга, которую покупают его клиенты - это в общем-то две разные услуги. Но между ними можно навести своего рода "логический мост", и тогда станет понятно, как именно отражаются те или иные события внутри предприятия на том, как видит и оценивает услугу ее клиент. Построить такую модель не просто, зато ее ценность очень высока.



Ещё немного критики в адрес экспертных систем.
Довольно сложно спроектировать базу знаний так, чтобы на ней одновременно работал и прямой и обратный логический вывод. В результате, если работает только один (чаще прямой), то в машине обработки декларативных знаний хочется заменить движок на более привычный для обработки императивных знаний, с итераторами и пр. Трудно остаться в логической парадигме при широких технологических возможностях, ведь все входы и выходы задачи уже определены.
Есть и смежная с этой проблемой другая: кроме правил установки термов в истинное значение (а именно это всем интересно), приходится писать нудные правила их сброса в ложное значение (чаще всего это строго противоположные высказывания). А это почти удвоение объёма базы знаний, повышенная когнитивная нагрузка на инженера знаний. И самое обидное, что синтаксис не позволяет в одном выражении написать сразу и то и другое (как if ... else ...). Дополнительно всё осложняется при обработке неизвестных значений (ни true, ни false).
И последнее. Современное программирование приучило пользователей хотеть неформализованного (не зря в названии поста упоминается Excel), поэтому от требований вида "вот это сложите и сюда выведите" никуда не деться, а всю грязную работу по онтологической идентификации такой "суммы" выполнять очень трудно (особенно зная, что сумма промежуточная, "на выброс"), поэтому интуитивно хочется больше вычислять, чем моделировать.

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

Сергей, возможно, проблема в том, что вы слишком хорошо объясняете :). Вы ведь продаете «семантику», а не «технологии». Может быть, о технологиях можно вовсе умалчивать?

Если все-таки спросят, от экспертных систем всегда можно дистанцироваться. Дескать, у нас Datalog, а не Prolog, и description logic, а не Horn clauses. Мол, все это гораздо лучше приспособлено для решения реальных бизнес-задач, и вообще эти технологии лучше рассматривать как часть модного движения NoSQL.

Лично мне, правда, не очень понятно, в чем прелесть «семантики» (и много ли можно о ней рассказать) без апелляции к тем технологиям… Желание иметь дело с «things, not strings, причем чтобы у things были URI, звучит на мой взгляд как «чтобы все были свободны и у каждого было по два раба».

Но есть считающие ровно наоборот. Вот некто Manu Sporny, некогда главный в W3C по JSON-LD, его нельзя заподозрить в нелюбвии к «семантике», пишет (http://manu.sporny.org/2014/json-ld-origins-2/) о технологиях очень уничижительно. Не цитирую тут, вдруг вы баните за мат в своем журнале :).

Мы стараемся продавать решение задач заказчика :)

Другое дело, что использование онтологического моделирования и части стека семантических технологий (что в совокупности можно упрощенно обозначить словом "семантика") при этом выступает в роли преимущества. Объяснив, что это такое, мы можем объяснить, почему построенные на этой основе решения лучше, чем другие.

Парадокс состоит в том, что отстраиваться нам нужно не только от экспертных систем, но и от Semantic Web в обычном понимании (у большинства респондентов, правда, нет вообще никакого понимания этого термина). То, что мы делаем, не имеет отношения к linked data, к публикации данных в веб-страницах и т.п. Когда попадаешь на человека, слышавшего об этих вещах, приходится долго и нудно объяснять, что фактически мы используем только triple store как хранилище данных, SPARQL как язык запросов к нему, и OWL как способ записи формализованной модели - все. Даже конструктор правил и движок логического вывода у нас уже свой, SWRL не подходит по ряду причин.

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

Если же респондент когда-то что-то читал, например, про RDFa - ему крайне сложно объяснить, что предлагаемая нами технология ничего общего с этим не имеет.

Статья товарища Manu Sporny производит впечатление бури в стакане воды. Конечно, большинству веб-кодеров использование URI в качестве идентификаторов сущностей действительно покажется сложным. Но для меня эта проблема из параллельного мира. В том смысле, что если это считать проблемой, то все остальное, с чем мы каждый день имеем дело, нужно признать вообще какой-то непонятной хренью, и пойти программировать интернет-магазины на Joomla :))
Какой-то жуткой инновационности в JSON-LD я не увидел - немного синтаксического сахарку, и все.


Да, драматизма в истории с JSON-LD много, а вот сути маловато. Было бы куда интереснее, если бы они у себя в модели по полной развили использование контекста (т.е. "обстоятельства" в добавление к "подлежащее/сказуемое/дополнение"). Если уж с взялись отстраняться от RDF, то во всем бы. Но, увы. ManuSporny объясняет, что нужно избегать использование @graph, насколько это возможно.

Может нам свою модель данных свараганить, русскую? ;)

Edited at 2017-02-26 11:47 am (UTC)

Машина логического вывода.

Здравствуйте, Сергей!

На одном дыхании прочитал Ваш журнал. Большое спасибо Вам за Вашу просветительскую и популяризаторскую деятельность!

Можно поинтересоваться, в чем возникли проблемы с SWRL? И вообще где можно побольше почитать про машины логического вывода? Вы в своей книге совсем мало уделяете этому вопросу, на сайтах посвященных Semantic Web этот вопрос вообще похоже не затрагивается. В то время как у меня эта тема вызывает наибольший интерес и больше всего вопросов. Может быть есть какие-то хорошие учебники?

И ещё вопрос: насколько реально написать свой движок логического вывода с нуля? Может ли это сделать дилетант-одиночка за несколько месяцев или не стоит даже браться?

Евгений.

Re: Машина логического вывода.

Тема машин логического вывода освещается очень скупо. Даже элементарную документацию найти не так-то легко. Но можно )
Выгуглить можно довольно многое (конечно, только на английском).
Например, есть вот такой хороший tutorial: https://dior.ics.muni.cz/~makub/owl/

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

Мы, например, созданием своего движка решали проблемы недостаточного функционала, неудобства создания правил SWRL и медленной скорости их применения. Для решения конкретных прикладных задач.




Re: Машина логического вывода.

Спасибо за ссылку!

У меня задача: поиск как вширь, так и вглубь, причем потенциально бесконечный, поэтому сам пользователь должен этим как-то управлять. Кроме того, отдельный вопрос: что делать с противоречиями. Мне надо, во-первых, получить полный путь, как получено это противоречие. Во-вторых, поиск на этом не должен останавливаться, а надо найти в идеале все возможные противоречия. Вопрос оптимизации по времени тоже важен, разумеется.

  • 1
?

Log in

No account? Create an account