?

Log in

No account? Create an account

serge_gorshkov


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

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


Previous Entry Share Next Entry
Нет пророкам в своем отечестве!
serge_gorshkov
Всегда приятно видеть подтверждение правильности того, что мы делаем. Недавно на хабре появился пост о "второй по крутизне частной компании Силиконовой Долины", которая делает софт под названием Palantir на тех же принципах, о которых я твержу который год.
Они сделали систему, помогающую в проведении расследований - как правоохранительным органам, так и, предположим, финансовым структурам - основанную на, внимание:

  • Сборе разнородной информации в единое целое, и

  • Качественном анализе цепочек связей.

Излишне говорить, что все разрабатываемое моей компанией ПО преследует эти же самые цели.
Пост искренне рекомендую, он интересный.

  • 1
Вам надо какой то коробочный продукт выпустить, в идеале, не завязанный на Россию (с интерфейсом на разных языках). Только надо правильно выбрать нишу... инструмент-то хороший и потенциал большой (в разных сферах). Сосредоточиться надо на чем то конкретном, не по тому, что не может быть универсального инструмента, а по тому что потребитель уверен, что не бывает универсального инструмента...

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

Авторам Палантира повезло в том плане, что они родом из PayPal, давно были сфокусированы на проблеме проведения расследований - под это и заточили свой продукт.

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

Кстати, а в чем суть технологии? Я помню вы показывали семантический конструктор выборок данных. Но тут другая история...

"Управления рисками ... в кап. строительстве", подразумевает анализ данных о проектной деятельности. А откуда вы возьмете эти массивы данных ? Или вы не собираетесь управлять рисками, а только даете риск-менеджеру инструмент по анализу данных (семантичекий конструктор)?

Технологии в Палантире, или у нас?
Общая идея в обоих случаях сводится к тому, чтобы связать в единый граф множество разнородной информации, а затем делать запросы к этому графу. Конкретный конструктор запросов может выглядеть по-разному (про наш я как-то постил видеоролик, а палантировский немного показан в посте), но под этим в любом случае лежит механизм поиска паттернов в графе. То есть, результат работы конструктора запроса - это паттерн вида "A связан таким-то отношением с B, а B связан с C" (конечно, конструкция конкретного паттерна может быть любой, включать доп. фильтры и так далее). А дальше находится множество всех комбинаций вершин и ребер графа, которые отвечают этому паттерну.

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

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


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

Это точно. Вообще, в моделировании мелочей не бывает, но правильно выбранные связи действительно критичны для удобства последующего использования.
Мы только что закончили делать модель для информационной системы, >1000 классов и около 350 типов связей. Связи рефакторили раз пять, наверное...

Связи сами придумываете, или на стандарты опираетесь?
Мне нравится "палитра связей" Gellish - см. лист "Gellish English" файла TOPini.xls из архива http://sourceforge.net/projects/gellish/files/The%20Gellish%20Dictionary%20and%20its%20Language%20Definition/Gellish_EN_Jul2008/Gellish_EN_part_0_TOPini_Aug_2008.zip

Словарь интересный, особенно тем, что для большинства терминов они различают can и shall.
Мы придумывали связи сами, и в ряде случаев они были куда более специфичными, типа "получает мощность от" (имеется в виду, электрическую).
Хотя много и общих, типа "является частью", которые можно было найти в этом словаре.
Одним из главных вопросов, которые приходилось постоянно решать, был вопрос о том, создавать ли новую связь в зависимости от типов объектов, которые она соединяет. С идеологической точки зрения понятно, что "цех является частью производственного комплекса" и "должность является частью орг. структуры подразделения" - одна и та же связь. Однако с точки зрения удобства использования иногда хочется, чтобы это были разные связи, потому что они не пересекаются: должность не может быть частью производственного комплекса, а цех - частью орг. структуры. Так что в ряде случаев мы такие специализировали. По идее, для этого в семантике есть специальный механизм - rdfs:subPropertyOf.


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

Кстати, из моей производственной практики. Цех, с одной стороны является частью технологического комплекса оборудования и сооружений, а с другой стороны - частью организационно-административной структуры. То есть, цех создают/изменяют/ликвидируют подписью высокого лица. А уже под эту подпись выстраивают (или переограживают другим, новым забором) объекты капитального строительства.

Почему-то применения у семантических технологий поневоле получаются какие-то криминалистические…

Решил вот посмотреть в DBpedia, у кого из шахматистов с наивысшим рейтингом нет гроссмейстерского звания. Думал, свежие вундеркинды будут какие-нибудь или из женщин кто. Оказалось, у первого же найденного рейтинг, если судить по статье в Википедии, дутый.

Так спрашивал:

SELECT ?elo ?player
WHERE {
    ?player dbp:peakrating ?elo .
    FILTER (
        NOT EXISTS { ?player dbp:title dbr:Grandmaster_(chess) } &&
        NOT EXISTS { ?player dbp:title "Grandmaster"@en } &&
        NOT EXISTS { ?player dct:subject dbc:Chess_grandmasters}
    )
}
ORDER BY DESC (?elo)

«Первый найденный» — это не Ласкер, а следующий.

Edited at 2016-01-08 07:36 pm (UTC)

А это потому, что в криминалистических применениях как раз есть явная потребность в выявлении (и доказательстве!) некой скрытой истины. Требование доказательности создает главное основание для применения семантики.

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

  • 1