Русский
Русский
English
Статистика
Реклама

Семантика

MarkedText маркдаун здорового человека

08.01.2021 12:15:36 | Автор: admin

Здравствуйте, меня зовут Дмитрий Карловский и все свои статьи (и презентации) пишу я в MarkDown разметке. И знаете что? Она уже порядочно меня подзаелозила! Тексты я пишу на русском, но большая часть спецсимволов есть только в английской раскладке клавиатуры. А редактирование таблиц - это вечная пизанская башня из вертикальных линий. Короче, есть у него проблемы как с удобством редактирования, так и с наглядностью представления. Так что давайте попробуем спроектировать его с нуля, не таща за собой килотонны головоломных конструкций.

Вёрстка несколько поехала, так как на Хабре выкатили новый кривой визивиг. Так что теперь писать статьи в маркдауне, а потом выкладывать на Хабр будет крайне сложно. С нормальной вёрсткой эту статью вы можете почить на гитхабе: https://github.com/nin-jin/HabHub/issues/39

Принципы

  • Однозначность синтаксиса

  • Простота синтаксиса

  • Единообразность синтаксиса

  • Минимальное влияние на естественный вид текста

  • Удобство редактирования независимо от раскладки

  • Наглядность представления

  • Расширяемость

  • Быстрая и надёжная запоминаемость

В качестве спец-символов форматирования лучше использовать такие, которые есть в любой раскладке, а не только в английской. То есть при прочих равных лучше отдать предпочтение следующим символам: ! " ; % : ? * ( ) _ + / \ . , - =

Существующие решения

В английской Википедии есть сравнительный обзор легковесных языков разметки, так что не будем повторяться. Там приведены следующие языки: AsciiDoc, BBCode, Creole, GitHub Flavored Markdown, Markdown, Markdown Extra, MediaWiki, MultiMarkdown, Org-mode, PmWiki, POD, reStructuredText, Textile, Texy, txt2tag.

Почти все они придерживаются примерно похожих конструкций. Однако, BBCode не является легковесным - это практически HTML с квадратными скобками вместо угловых. Поэтому его мы далее рассматривать не будем. Также проигнорируем и POD, чей синтаксис слишком многословный и не слишком наглядный.

Текстовые блоки

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

Списки

Списки бывают двух типов: упорядоченные и неупорядоченные. Их можно вкладывать друг в друга в произвольной комбинации. В этом случае вложенные списки отображаются с отступом.

Элементы неупорядоченного списка предваряются маркером. По нормам многих языков таким маркером выступает тире. В вебе в основном потребляются "буллеты". В облегчённых языках разметки в основном используются следующие:

- item* item+ item

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

- first- second  - first of second    - first of first of second  - second of second - third
  • first

  • second

    • first of second

      • first of first of second

    • second of second

  • third

Упорядоченные списки предполагают отображение увеличивающегося перед каждым элементом счётчика. Счётчик отделяется от текста элемента списка разделителем - точкой, скобочкой и тп. Некоторые языки предполагают ручное задание значений счётчика, что крайне не удобно поддерживать в актуальном состоянии:

1. item2) item

Некоторые языки позволяют указать специальный маркер списка, который будет отображаться как счётчик - это уже куда удобнее:

# item

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

+ first+ second  + first of second    + first of first of second  + second of second + third
  1. first

  2. second

    1. first of second

      1. first of first of second

    2. second of second

  3. third

Цитаты

Цитаты объединяют произвольные блоки текста, показывая, что их автором является кто-то другой. Распространённая практика - выделять цитаты угловыми скобками:

> quote> - list in quote> > inner quote

Однако, угловая скобочка есть лишь в английской раскладке. Тут гораздо лучше подходит символ кавычки, который уже используется в цитатах внутри строк и доступен не только в английской раскладке:

" quote" - list in quote" " inner quote

Таблицы

Таблицы - это двумерное представление данных. И многие языки стараются сохранять двумерность ради наглядности:

|=  |= table |= header || a | table  | row     || b | table  | row     ||   | table | header ||---|-------|--------|| a | table | row    || b | table | row    |First Header | Second Header------------ | -------------Content from cell 1 | Content from cell 2Content in the first column | Content in the second column

Однако, такое представление сильно бьёт по удобству редактирования - приходится вручную постоянно выравнивать колонки.

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

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

|   | table                                                                                                                          | header || a | There are many variations of passages of Lorem Ipsum available, but the majority have suffered alteration in some form, by injected humour, or randomised words which don't look even slightly believable.  | row     || b | table                                                                                                                          | row     |

Короче, рисовать табличку в тексте - бессмысленное занятие. Однако можно сохранить двумерность представления и без таблицы - достаточно выравнивать содержимое ячеек, относящихся к разным колонкам, друг под другом, но с разным отступом:

!   ! table    ! header! a  ! There are many variations of passages of Lorem Ipsum available, but the majority have suffered alteration in some form, by injected humour, or randomised words which don't look even slightly believable.    ! row! b  ! table     ! row

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

Заголовки

В некоторых языках заголовки выделяются разными типами подчёркиваний:

Level 1 Heading===============Level 2 Heading---------------Level 3 Heading~~~~~~~~~~~~~~~

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

Есть более удобная форма, где уровень заголовка определяется числом спецсимволов в префиксе:

# Level 1 Heading ### Level 2 Heading ##### Level 3 Heading ###

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

## Level 2 Heading== Level 2 Heading** Level 2 Heading!! Level 2 Heading++ Level 2 Heading

Решётка есть лишь в английской раскладке. Плюсы, звёздочки, восклицательные знаки мы задействуем для другой семантики. А вот массивные символы равенства - то, что надо. Заголовки делят текст на секции, так что пара горизонтальных линий отлично это иллюстрируют:

= Level 1 Heading== Level 2 Heading=== Level 3 Heading

Преформатированный текст

В некоторых языках для преформатированного текста используются специальные кавычки:

```markdownpreformatted         text```

Однако, если в таком тексте тоже нужно вывести эти кавычки, то получается облом. Поэтому предпочтительнее вариант с префиксом перед каждой строкой. Например, в качестве такого префикса может выступать отступ, равный 2 или 4 пробелам:

    preformatted             text

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

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

Поэтому мы разделим префикс на две части:

  • Маркер преформатированного текста из 2 пробелов.

  • Маркер форматирования строки из пары спец символов.

Выглядеть оно будет так:

    preformatted            text  --deleted  --   text  ++inserted  ++    text  **highlighted  **       text

А как же указание языка для этого текста? А к чёрту его. Набирать каждый раз название языка утомительно. Откуда брать это название - не понятно. Да и что делать с языками, которые ещё не поддерживаются, - не ясно. Лучше уж тут работает автоматика - она должна либо сама распознать язык, либо использовать универсальную подсветку, подходящую большинству языков.

Инлайн форматирование

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

  • 1 - слишком мало, высок риск, что символ обычного текста будет воспринят как форматирование.

  • 3 - слишком много, каждый раз трижды нажимать клавишу - слишком утомительно.

  • 2 - золотая середина, на этом и остановимся.

Акценты

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

Варианты сильного акцента:

*strong***strong**__strong__'''strong'''''strong''

Апострофы слишком похожи на кавычки и секунды, так что их сразу отбрасываем. Из оставшихся более распространён вариант с "массивными" звёздочкам - его и выберем.

**strong**

strong

Варианты слабого акцента:

'emphasis'''emphasis''_emphasis_/emphasis///emphasis//*emphasis*~emphasis~

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

//emphasis//

emphasis

Правки

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

Итак, типичные формы выделения добавлений:

_insertion___insertion__+insertion+

И удалений:

~deletion~~~deletion~~-deletion---deletion--

Добавления и удаления естественным образом независимо от визуализации ассоциируются с плюсом и минусом, так что воспользуемся именно ими:

++insertion++--deletion--
  • insertion

  • deletion

Ссылки

Ссылки бывают двух видов:

  • Гиперссылка - она переносит вас к цели при клике на неё. Для неё задаётся отображаемое содержимое и урл для перехода.

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

Гиперссылки выглядят в разных языках так:

"Text":http://example.comhttp://example.com[Text]<http: example.com|text="">[Text|http://example.com][[Text|http://example.com]][[http://example.com|Text]][Text http://example.com][http://example.com Text][Text](http://personeltest.ru/away/example.com)`Text <http: example.com="">`_

А встраивания так:

![title](http://personeltest.ru/away/example.com/image.png){{http://example.com/image.png|title}}.. image:: /path/to/image.jpg

Важно отметить, что обычно встраивать разрешено лишь изображения. Если хочется встроить видео или сайт - в лучшем случае предлагается писать HTML. Мы же позволим встраивать что угодно - проверка безопасности для урлов должна происходить системно и регулироваться отдельно. Язык разметки текста никак не должен их регламентировать.

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

Отметим, что встраивание - это фактически цитирование стороннего ресурса, так что кавычка для этого более чем уместна. В качестве же разделителя ссылки на ресурс и его альтернативного представления, лучше подойдёт \, который крайне редко встречается в обычном тексте, в отличие от кавычки.

""Embedded image\http://example.org/favicon.ico""""Embedded video\https://youtube.com/video=1234""""Embedded site\https://marked.hyoo.ru/""

Если альтернативное содержимое опущено, то в качестве него должен быть взят сам урл. То есть следующие два варианта дают идентичный результат:

""http://example.org/favicon.ico""""http://example.org/favicon.ico\http://example.org/favicon.ico""

Для гиперссылок же воспользуемся \ во всех местах:

\\Clickable text\http://example.org/\\Clickable url: \\http://example.org/\\

Разумеется разные типы ссылок можно комбинировать. Например, сделать картинку-ссылку можно так:

\\""Example\http://example.org/favicon.ico""\http://example.org/\\

Инлайн код

Инлайн код выводится моноширинным шрифтом и выключает внутри себя любое форматирование. В каждом языке используется что-то своё:

+monospace text+`monospace text```monospace text`````monospace text```|monospace text|{{monospace text}}{{{monospace text}}}=code=~verbatim~@monospace text@@@monospace text@@

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

This is  monospace text  !

This is monospace text !

Резюме

Теперь давайте соберём все конструкции формата в одной короткой шпаргалке:

= MarkedTextФормат текста с **легковесным форматированием**.--== Принципы+ Синтаксис:- Однозначность- Простота- Единообразность+ Внешний вид:- Минимальное влияние на естественный вид текста- Наглядность форматирования+ Редактирование:- Независимость от раскладки- Быстрая и надёжная запоминаемость== Cравнение с альтернативами! **Язык**! **Плюсы**    ! **Минусы**! MarkedText! - Удобное редактирование таблиц.! - Поддержка сложного форматирования внутри ячеек.! - Простота реализации.! - Легко запоминающийся консистентный синтаксис.! - Удобство редактирования в русской раскладке.! - Колонки не расползаются далеко вправо за горизонтальный скроллинг и не переносятся на новую строку.    ! - Не поддерживается пока что никакими сторонними инструментами.! MarkDown! - Широкая поддержка различными инструментами.! - Наглядное представление таблиц.    ! - Сложности с редактированием таблиц.    ! - Сильно ограниченное содержимое ячеек.== Парсинг    const res = [ ... $hyoo_marked_line.parse( '**text**' ) ]--$mol_assert_equal( res[0].strong, '**text**' )++$mol_assert_equal( res[0].marker, '**' )**$mol_assert_equal( res[0].content, 'text' )== Отзывы" " " Типичный пользователь: Нигде не поддерживается, идите в --жопу-- ++Жодино++ с таким синтаксисом!" " " " Но мы же программисты, мы можем это исправить.. Для этого даже не надо быть экспертом ни по  C++  , ни по  D++  .." " Никому это не нужно (с) Диванный ЭкспертТем не менее, это полезное упражнение в проектировании.== Ссылки- Песочница: \\https://marked.hyoo.ru/\\- \\Статья о MarkedText\https://github.com/nin-jin/HabHub/issues/39\\- \\Парсер на TS\https://github.com/hyoo-ru/marked.hyoo.ru/\\- \\Конвертер в HTML на TS\https://github.com/hyoo-ru/marked.hyoo.ru/tree/master/to/html\\- ""Результат билда $mol_regexp\https://github.com/hyoo-ru/mam_mol/workflows/mol_regexp/badge.svg""

Ссылки

Подробнее..

Анализ тональности в русскоязычных текстах, часть 1 введение

27.08.2020 20:07:22 | Автор: admin
image
Анализ тональности стал мощным инструментом для масштабной обработки мнений, выражаемых в любых текстовых источниках. Практическое применение этого инструмента в английском языке довольно развито, чего не скажешь о русском. В этой серии статей мы рассмотрим, как и для каких целей применялись подходы анализа тональности для русскоязычных текстов, какие результаты удалось достичь, какие проблемы возникали, а также немного поговорим о перспективных направлениях. В отличие от предыдущих работ, я сосредоточился на прикладном применении, а не на самих подходах и их качестве классификации. Первая часть вводная. Мы рассмотрим, что такое анализ тональности, какой он бывает и как его за последние 8 лет применяли для анализа русскоязычных текстов. Во второй части (выйдет на следующей неделе) детально рассмотрим каждое из 32 основных исследований, которые мне удалось найти. В третьей и заключительной части (опять же, будет на следующей неделе) поговорим об общих сложностях, с которыми сталкивались исследователи, а также о перспективных направлениях на будущее.

NB: Статья писалась для научного журнала, поэтому будет много ссылок на источники.

1. Введение


Анализ тональности класс методов контент-анализа в компьютерной лингвистике, основная задача которого заключается в классификации текста по его настроению. С помощью анализа тональности исследователи могут обобщать тональность текстов и делать выводы по разным темам. Например, этот анализ позволяет прогнозировать рынок ценных бумаг [1], вычислять индекс субъективного благополучия [2], прогнозировать результаты выборов [3], оценивать реакцию на какие-то события или новости [4]. Анализ тональности для английского языка уже хорошо проработан [5][7], а другим языкам, особенно русскому, пока что уделено гораздо меньше внимания. Согласно исследованию Omnibus GFK [9], интернетом пользуется 75,4 россиян (90 млн человек) в возрасте от 16 лет. Русскоязычные диаспоры есть на всех континентах, однако основная масса проживает на территории СНГ, по большей части в России и Украине. Согласно исследованию W3Techs, русский язык по распространённости в интернете занимает одно из лидирующих мест. По состоянию на апрель 2020-го 8,6 % из 10 млн самых популярных сайтов в мире были на русском языке. Поэтому русскоязычные тексты являются важным источником данных для автоматического анализа, особенно анализа тональности.

Лишь одно обзорное исследование [10], проведённое Viksna и Jekabsons, посвящено анализу тональности русскоязычных текстов. В нескольких других [11][14] он упоминается в контексте общего сравнения с существующими подходами. Некоторые другие исследования посвящены конкретным аспектам анализа тональности русскоязычных текстов. Например, оценка наилучших подходов [15][18], сравнение архитектур нейросетей для анализа тональности [19], [20], сравнение открытых русскоязычных подборок лексики для оценки настроений [21]. Однако все эти исследования сосредоточены на самих подходах и их скорости классификации, а не на практическом применении и результатах анализа. Я же рассматривал только те работы, в ходе которых получены результаты анализа на основе реальных данных. И не рассматривал те, которые посвящены лишь обучению классификаторов. Это статья сжатый перевод млей статьи, опубликованной в IEEE Access. Если хотите больше подробностей, или просто почитать на английском вам сюда.

Во второй секции кратко описывается задача анализа тональности и текущие подходы, если вы с этим уже знакомы смело пропускайте. Третья секция одна из основных, в ней рассматриваются виды применения анализа тональности для русскоязычных текстов, здесь же описаны 32 основных исследований, их инсайты и слабые стороны. Четвертая секция посвящена текущим сложностям, а пятая перспективным направлениям.

2. Кратко о методах анализа тональности


Анализ тональности класс методов контент-анализа в компьютерной лингвистике, основная задача которого заключается в классификации текста по его настроению. В простых случаях задача анализа тональности сводятся к бинарной классификации текстов на позитивные и негативные. В некоторых случаях добавляют ещё класс нейтральных текстов. Более продвинутые подходы пытаются определять эмоциональные состояния, ассоциируемые с каким-то текстом, например, страх, злость, печаль или счастье. В ряде подходов текстам присваиваются значения заранее определённой шкалы: например, от -2 для негативных до 2 для позитивных; таким образом анализ сводится к задаче регрессии. Аспектный анализ тональности (aspect-based sentiment analysis) это подвид анализа тональности, чья задача заключается в определении отношения к конкретному аспекту основного предмета обсуждения. Все подходы к анализу тональности можно разделить на три группы.

Первая подходы на основе правил (rule-based). Чаще всего в них используются вручную заданные правила классификации и эмоционально размеченные словари. Эти правила обычно на основе эмоциональных ключевых слов и их совместного использования с другими ключевыми словами рассчитывают класс текста [22][24]. Несмотря на прекрасную эффективность в текстах из какой-то определенной тематики, методы на основе правил плохо способны обобщать. Кроме того, они крайне трудоёмки в создании, особенно когда нет доступа к подходящему словарю настроений. Последнее особенно характерно для русского языка, потому что на нём не так много источников, как на английском, особенно в сфере анализа тональности. Крупнейшие русскоязычные словари настроений RuSentiLex [25] и LINIS Crowd [26]. Но в них есть только информация о тональности от позитивной до негативной, без характеристик эмоций. Таким образом, не существует альтернатив таким мощным англоязычным подборкам с обширными эмоциональными характеристиками, как SenticNet [27], SentiWordNet [28] и SentiWords [29].

Вторая группа подходы на основе машинного обучения. Они используют автоматическое извлечение признаков из текста и применение алгоритмов машинного обучения. Классическими алгоритмами классификации полярности являются наивный байесовский классификатор (Naive Bayes Classifier) [30], дерево решений (Decision Tree) [31], логистическая регрессия (Logistic Regression) [32] и метод опорных векторов (Support Vector Machine) [33]. В последние годы внимание исследователей привлекают методы глубокого обучения, которые значительно превосходят традиционные методы в анализе тональности [34]. Это подтверждается и хронологией соревнования SemEval, в ходе которого лидирующие решения успешно использовали свёрточные (CNN) и рекуррентные (RNN) нейросети [35][37], а также методы переноса обучения (transfer learning) [38]. Одна из главных особенностей систем на основе машинного обучения автоматическое извлечение признаков из текста. В простых подходах для представления текста в векторном пространстве обычно используется модель мешок слов (bag of words). В более сложных системах для генерирования эмбеддингов слов применяются модели дистрибутивной семантики, например, Word2Vec [39], GloVe [40] или FastText [41]. Также есть алгоритмы генерирования эмбеддингов на уровне предложений или параграфов, которые предназначены для переноса обучения в разных задачах обработки естественного языка. К таким алгоритмам относятся ELMo [42], Universal Sentence Encoder (USE) [27], Bidirectional Encoder Representations from Transformers (BERT) [43], Enhanced Language Representation with Informative Entities (ERNIE) [44] и XLNet [45]. Одним из их главных недостатков с точки зрения генерирования эмбеддингов является потребность в больших массивах текстов для обучения. Впрочем, это справедливо для всех методов машинного обучения, потому что всем алгоритмам обучения с учителем нужны для обучения размеченные наборы данных.

Третья группа гибридные подходы. Они объединяют в себе подходы двух предыдущих видов. Например, Кумар (Kumar) и его коллеги разработали гибридный фреймворк для анализа тональности персидского языка, в котором сочетаются лингвистические правила, а также модули свёрточных нейросетей и LSTM для классификации настроений [46]. Мескеле (Meskele) и Фрасинкар (Frasincar) предложили гибридную модель аспектного анализа ALDONAr, в которой сочетаются онтология настроений для захвата информации о настроениях, BERT для получения эмбеддингов слов и два слоя CNN для расширенной классификации тональности [47]. Модель показала точность в 83,8 % на датасете SenEval 2015 Task 12 [48] и 87,1 % на датасете SemEval 2016 Task 5 [49]. Языковые модели часто применяются в гибридных алгоритмах, как и решения на основе правил [50][52]. С одной стороны, комбинация методов на основе правил и машинного обучения обычно позволяет добиться более точных результатов. А с другой гибридные подходы наследуют трудности и ограничения составляющих их алгоритмов.

3. Методология


Чтобы найти ключевые публикации по прикладному анализу тональности русскоязычных текстов, я провёл поиск по научным базам данных, которые охватывают ведущие журналы и конференции по информатике: IEEE Xplore, ACM Digital Library, ScienceDirect, SAGE Journals Online и Springer Link. Чтобы расширить круг источников, помимо англоязычных статей я также изучил русскоязычные статьи из Российского индекса научного цитирования (РИНЦ). Поиск вёлся по запросу ((''SENTIMENT'' OR ''POLARITY'') AND (''ANALYSIS'' OR ''DETECTION'' OR ''CLASSIFICATION'' OR ''OPINION MINING'' OR ''TOPIC MODELING'') AND (''RUSSIAN'' or ''RUSSIA'')). Большинство подходящих статей найдено в ScienceDirect, Springer Link и РИНЦ. Также я изучил предварительные публикации работ ведущих исследователей, чтобы не упустить свежие разработки. В результате удалось собрать несколько тысяч потенциально подходящих статей, не считая серой литературы и препринтов. Предпочтение отдавалось самым свежим и наиболее цитируемым работам. Затем я проанализировал заголовки, ключевые слова и введения остальных публикаций, чтобы сузить выборку источников. Поиск вёлся только по отрецензированным статьям, чтобы улучшить качество выборки. Я исключил серые источники (например, незавершённые работы, редакционные статьи, любые диссертации), а также неподходящие для моего исследования (в которых не применяются модели классификации тональности). Затем для дальнейшего подробного описания в этой статье я вручную выбрал 32 основные публикации, в которых описывался хотя бы один практический подход к анализу настроений в русскоязычных текстах.

4. Применение анализа тональности к русскоязычным текстам


image
Рис. 1. Предложенные категории.

Я решил категоризировать подходы по источникам данных, потому что в этом случае у подходов внутри категорий будут схожие цели, вызовы и ограничения. Хотя некоторые категории содержат всего по одному исследованию, я решил выделить их в связи с фундаментальным отличием используемых подходов, результатов и сложностей. К тому же не забывайте, что русский язык меньше исследован с точки зрения анализа тональности, поэтому количество работ ограничено. На рис. 1 представлен набор категорий. Большинство подходов опиралось на анализ данных из соцсетей, чтобы оценивать отношение пользователей к разным темам. Например, отношение и мнения о конфликте на Украине и связанных с мигрантами проблемах. В последнее десятилетие многие соцсети превратились в современные инструменты социального вовлечения [53], поэтому их можно воспринимать как открытые и широко доступные источники общественного мнения, или хотя бы как его некое отражение [54]. UGC из социальных сетей, как самый распространённый источник информации, были исследован по трём критериям: отношение к разным темам; индексы социального настроения; особенности пользовательского взаимодействия с данными, выражающими разные настроения. Отношение к разным темам изучалось с разных точек зрения. Например, отношение к мигрантам и этническим группам (например, [55]), выражения настроений в ходе Украинского кризиса (например, [56]), измерение уровня социальной напряжённости (например, [57]) или сосредоточенность на дискурсе по каким-то важным вопросам (например, [58]). Обычно эти подходы используют комбинацию тематического моделирования и анализа тональности, чтобы выделить темы и соответствующие настроения. В значительной части исследований (например, [59][67]), в которых тематическое моделирование применяется без последующей классификации полярности (и значит они не рассматриваются в этой статье), анализ тональности упоминается как дальнейший этап развития. В другой части исследований (например, [68]) индексы социального отношения вычисляются на основе выраженных в соцсетях мнений, чтобы получить альтернативу традиционному индексу субъективного благополучия. Наконец, в ещё одной одной части исследований (например, [69]) рассматриваются паттерны взаимодействия пользователей с содержимым в зависимости от его эмоциональной окраски. Одной из основных трудностей в подобных исследованиях является извлечение репрезентативных образцов данных и выделение релевантных текстов для последующего анализа.

Следующий по распространённости источник информации отзывы на продукты и сервисы. Они анализировались с точки зрения характеристик самих авторов отзывов (например, [70]), характеристик продуктов и сервисов (например, [71]), а также характеристик продавцов (например, [72]). В отличие от анализа генерируемых пользователями данных из соцсетей здесь нет трудностей с доступом к старым данным. Посвящённые отзывам сайты часто позволяют пользователям в дополнение к тексту отзыва также ставить оценки, поэтому формально нет нужды в создании модели классификации настроений, ведь нам уже известны классы оценок. Однако в некоторых исследованиях модели классификации тональности используются исключительно из-за академического интереса. Поскольку пользовательские данные в соцсетях и пользовательские отзывы часто отражают субъективные точки зрения, анализ этих данных отличается от анализа новостей. Обычно журналисты стараются избегать оценок и откровенной пристрастности, сомнений и двусмысленности, поскольку в основе их профессии лежит объективность. или хотя бы нейтральность [73]. Поэтому журналисты часто не используют слова, относящиеся к позитивной или негативной лексике, однако прибегают к другим способам выражения своего мнения [74].

Третьим основным источником стали новости из СМИ, которые анализировались по двум критериям: тональность (например, [75]) и формирование экономических и деловых прогнозов на основе тональности новостей (например, [76]). В отличие от анализа генерируемых пользователями данных из соцсетей, здесь нет трудностей с доступом к старым данным, потому что СМИ обычно не ограничивают к ним доступ. Однако авторы некоторых исследований пытались определить отношение общественности к конкретным темам, что, на мой взгляд, требует дальнейшей проработки. Конечно, СМИ можно считать отражением общественного мнения. Но в некоторых случаях политика редакций могла влиять на подачу, так что новости не всегда отражают мнение общества. Чуть меньше внимания исследователи уделили самому свежему направлению: анализу тональности учебников, подобные исследования появились только в 2019-м. Эти работы сосредоточены на сравнении настроений, выраженных в разных учебниках (например, [77]), и на влиянии этих настроений на образовательный процесс (например, [78]). Главная сложность связана с отсутствием лексики определённых настроений и обучающих наборов данных, ориентированных на учебники. Более того, в случае с аналитическими текстами на уровне документов становится сложно связать тексты с каким-то классом настроений, потому что тексты в учебниках длинные и могут содержать в себе сразу несколько разных эмоций.

Чтобы охватить более широкий спектр мнений, некоторые исследования оперируют смешанными источниками данных. В этой группе исследователи обычно изучают отношение к разным темам, таким как Украинский кризис (например, [79]) или освещение в СМИ Алексея Навального (например, [80]). Поскольку источники смешанные, такие данные могут использоваться для любых возможных исследований. Однако в дополнение к широкому спектру выраженных мнений авторы также сталкиваются с характерными для источников сложностями и ограничениями.

Сводка найденных подходов представлена в таблице 1. Если рассмотреть распределение статей по годам, то можно увидеть, что количество исследований тональности русскоязычного текста увеличивалось в 2014-2016 годах и достигло пика в 2017-м. Количество статей, опубликованных в одних и тех же журналах и сборниках материалов конференций, несколько варьируется. И только в семи журналах и сборниках было опубликовано более одной из проанализированных статей. Больше всего обнаруженных статей было опубликовано в сборнике материалов конференции Цифровые преобразования и глобальное общество.

Таблица 1. Сводка обнаруженных исследований. RB подходы на основе правил, ML подходы на основе методов машинного обучения, UNK неизвестные подходы, WL анализ на уровне слов, DL анализ на уровне документов.

Категория Назначение Описание Ссылка Подход Уровень анализа
UGC Отношение к теме Определение принадлежности к этнической группе или мигрантам. [81] ML (Logit) DL
[82] ML (Logit) DL
[83] ML (Logit) DL
[84] RB (SentiStrength) DL
[55] ML (SVM) DL
Определение принадлежности в ходе Украинского кризиса. [85] RB (custom) DL
[86] RB (POLYARNIK) DL
[87] RB (SentiMental) DL
[88] UNK (IQBuzz) DL
[56] RB (custom) DL
Измерение уровня социальной напряжённости. [89] ML (SVM) DL
[57] RB (SentiStrength) DL
Исследование реакции на взрыв метеорита над Челябинском. [58] не указано DL
Оценка реакции на Олимпиаду 2014 в Сочи. [90] RB (SentiStrength) DL
Исследование массовых протестов в России в 2011-2012. [91] RB (SentiStrength) DL
Распределение настроений в Санкт-Петербурге. [92] ML (NBC) DL
Индекс общественного мнения Составление индекса субъективного благополучия. [93] RB (custom) WL, DL
[68] ML (GBM) DL
Поведение пользователей Оценка влияния настроения на обратную связь от аудитории. [69] ML (BiGRU) DL
Рецензии Характеристики рецензентов Определение причин, почему сотрудники покидают российские компании. [70] не указано DL
Характеристики продуктов и сервисов Оценка состояния дорожного покрытия в Северо-Западном Федеральном округе России. [71] ML (NB, SGD) DL
Характеристики торговцев Определения качества товаров, предлагаемых торговцами. [72] ML (RNTN) DL
Новости Содержимое новостей Определение горячих тем и полярности освещения новостей в СМИ. [94] RB (custom) DL
[95] RB (custom) DL
Оценка тональности при упоминании технологий и инноваций в СМИ. [96] RB (custom) DL
Оценка освещаемой повестки дня Владимира Путина и Алексея Навального. [75] UNK (Medialogia) DL
Экономические и деловые прогнозы Создание высокочастотного индикатора деловой активности в России. [76] ML (SVM) DL
Книги Содержимое книг Сравнение тональности в русскоязычных учебниках по обществоведению и истории. [77] RB (custom) WL
Образовательный процесс Оценка корреляции между тональностью образовательных текстов, субъективной оценки иностранных студентов и реального успеха образовательного процесса. [78] ML (не указано) DL
Смешанное Отношение к теме Определение принадлежности в ходе Украинского кризиса [97] UNK (Crimson Hexagon) DL
[79] UNK (Crimson Hexagon) DL
Анализ интенсивности и тональности освещения Алексея Навального в СМИ [80] UNK (Medialogia) DL

Соотношение подходов на основе правил (40,63 %) и машинного обучения (37,5 %) было примерно равное. В первой группе чаще всего использовались либо индивидуальные модели на основе правил, либо SentiStrength [22], ставший самым популярным алгоритмом среди сторонних готовых к использованию решений. А во второй группе чаще всего применялись логистическая регрессия [32], метод опорных векторов [33] и наивный байесовский классификатор [30]. Самыми востребованными были простые методы машинного обучения, а на нейросети пришлось только 16,7 %. Однако начиная с 2019 года доля подходов на основе машинного обучения значительно превысила долю подходов на основе правил. В 15,6 % обнаруженных исследований для анализа тональности применялись сторонние облачные сервисы, например, Medialogia, IQBuzz и Crimson Hexagon. В этих случаях я не смог определить использованные подходы из-за отсутствия официальной информации о применявшихся алгоритмах классификации.

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

5. Далее


На следующей неделе выйдет вторая часть статьи, в ней мы детально рассмотрим каждое из 32 основных исследований, которые мне удалось найти. В третьей и заключительной части (опять же, будет на следующей неделе) поговорим об общих сложностях, с которыми сталкивались исследователи, а также о перспективных направлениях на будущее. Если есть желание прочесть всю статью сразу и на английском, вам сюда.

6. Источники


Полный список источников можно найти здесь.
Подробнее..

Из песочницы Проектируем мульти-парадигменный язык программирования. Часть 1 Для чего он нужен?

29.09.2020 12:13:11 | Автор: admin
Хабр это замечательное место, где можно смело делиться своими идеями (даже если они и выглядят безумно). Хабр видел много самодельных языков программирования, расскажу и я о своих экспериментах в этой области. Но мой рассказ будет отличаться от остальных. Во-первых, это будет не просто язык программирования, а гибридный язык, сочетающий в себе несколько парадигм программирования. Во-вторых, одна из парадигм будет довольно необычной она будет предназначена для декларативного описания модели предметной области. А в-третьих, сочетание в одном языке декларативных средств моделирования и традиционных объектно-ориентированного или функционального подходов способно породить новый оригинальный стиль программирования онтологически-ориентированное программирование. Я планирую раскрыть в первую очередь теоретические проблемы и вопросы, с которыми я столкнулся, и рассказать не только о результате, но и о процессе создания дизайна такого языка. Будет много обзоров технологий и научных подходов, а также философских рассуждений. Материала очень много, придется разбить его на целую серию статей. Если вас заинтересовала такая масштабная и сложная задача, приготовьтесь к долгому чтению и погружению в мир компьютерной логики и гибридных языков программирования.

Вкратце опишу основную задачу


Она заключается в том, чтобы создать такой язык программирования, который был бы удобен как для описания модели предметной области, так и для работы с ней. Чтобы описание модели было как можно более естественным, понятным для человека и близким к спецификациям программного обеспечения. Но при этом оно должно быть частью кода на полноценном языке программирования. Для этого модель будет иметь форму онтологии и состоять из конкретных фактов, абстрактных понятий и отношений между ними. Факты будут описывать непосредственные знания о предметной области, а понятия и логические отношения между ними ее структуру.

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

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

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

Правильный выбор стиля языка программирования важное условие качества кода


Многим из нас приходилось заниматься поддержкой сложных проектов, созданных другими людьми. Хорошо, если в команде есть люди, которые ориентируются в коде проекта и могут объяснить, как он работает, есть документация, код чист и понятен. Но в реальности часто бывает и по-другому авторы кода уволились задолго до того, как вы попали на этот проект, документации или нет совсем или она очень обрывочная и давным-давно устарела, а о бизнес-логике нужного компонента бизнес-аналитик или проект-менеджер может рассказать лишь в общих чертах. В этом случае чистота и понятность кода является критическим показателем.
Качество кода имеет много аспектов, один из них правильный выбор языка программирования, который должен соответствовать решаемой задаче. Чем проще и естественней разработчик может реализовать свои замыслы в коде, тем быстрее он сможет решить задачу и меньше ошибок допустит. Сейчас у нас есть выбор из довольно большого числа парадигм программирования, каждая из которых имеет свою область применения. Например, функциональное программирование предпочтительней для приложений с акцентом на вычисления, так как оно дает больше возможностей для структурирования, комбинирования и повторного использования функций, реализующих операции над данными. Объектно-ориентированное программирование упрощает создание структур из данных и функций за счет инкапсуляции, наследования, полиморфизма. ООП подходит для приложений, ориентированных на данные. Логическое программирование удобно для задач, ориентированных на правила, требующих работы со сложными, рекурсивно-определенными типами данных, такими как деревья и графы, подходит для решения комбинаторных задач. Также свои сферы применения имеют реактивное, событийно-ориентированное, мультиагентное программирование.

Современные языки программирования общего назначения могут поддерживать несколько парадигм. Объединение функциональной и ООП парадигм уже давно стало мейнстримом.

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

Почему я считаю декларативный стиль программирование недооцененным


Попробую обосновать свою точку зрения.

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

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

Задача связывания содержимого базы данных с объектами приложения тоже не так проста. Если структура таблиц в хранилище соответствует структуре понятий на уровне приложения, то можно воспользоваться ORM технологией. Но для более сложных случаев чем доступ к записям по первичному ключу и CRUD операций приходится выделить отдельный слой логики работы с базой данных. Обычно схема базы данных имеет максимально общую форму, так, что с ней могут работать разные сервисы. Каждый из которых отображает эту схему данных на свою объектную модель. Структура приложения становится еще более запутанной, если приложение работает не с одним хранилищем данных, а с несколькими, разного типа, загружает данные из сторонних источников, например, через API других сервисов. В этом случае необходимо создать унифицированную модель предметной области и отобразить на нее данные из разных источников.
В некоторых случаях модель предметной области может иметь сложную многоуровневую структуру. Например, при составлении аналитических отчетов одни показатели могут строиться на основе других, которые в свою очередь будут источником для построения третьих и т. д. Также входные данные могут иметь слабоструктурированную форму. Эти данные не имеют строгой схемы как, например, у реляционной модели данных, но все же содержат какую-либо разметку, позволяющую выделить из них полезную информацию. Примерами таких данных могут быть ресурсы семантической паутины, результаты парсинга WEB-страниц, документы, журналы событий, показания датчиков, результаты предварительной обработки неструктурированных данных, таких как тексты, видео и изображения и т.п. Схема данных этих источников будет строиться исключительно на уровне приложения. Там же будет и код, преобразующий исходные данных в объекты бизнес-логики.

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

Рассмотрим небольшой пример и порассуждаем, как будет выглядеть его реализация с помощью разных парадигм программирования


Предположим, у нас есть 2 CSV файла. В первом файле:

В первой колонке хранится идентификатор клиента.
Во второй дата.
В третьей выставленная сумма счета,
В четвертой сумма оплаты.

Во втором файле:
В первой колонке хранится идентификатор клиента.
Во второй имя.
В третьей адрес электронной почты.

Введем некоторые определения:
Счет включает в себя идентификатор клиента, дату, выставленную суммы, суммы оплаты и долга из ячеек одной строки файла 1.
Сумма долга это разница между выставленной суммой и суммой оплаты.
Клиент описывается с помощью идентификатора клиента, имени и адреса электронной почты из ячеек одной строки файла 2.
Неоплаченный счет это счет с положительным долгом.
Счета связаны с клиентом по значению идентификатора клиента.
Должник это клиент, у которого существует хотя бы один неоплаченный счет, дата которого старше текущей даты на 1 месяц.
Злостный неплательщик это клиент, имеющий более 3х неоплаченных счетов.

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

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

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

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

Наиболее близкой к описанию будет реализация концептуальной модели на языках представления знаний. Примерами таких языков являются Prolog, Datalog, OWL, Flora и другие. Об этих языках я планирую рассказать в третьей публикации. В их основе лежит логика первого порядка либо ее фрагменты, например, дескриптивная логика. Эти языки позволяют в декларативном виде задать спецификацию решения задачи, описать структуру моделируемого объекта или явления и ожидаемый результат. А встроенные механизмы поиска автоматически найдут решение, удовлетворяющее заданным условиям. Реализация модели предметной области на таких языках будет исключительно краткой, понятной и близкой к описанию на естественном языке.

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

Сначала мы объявляем факты с содержимым таблиц в формате: ID таблицы, строка, колонка, значение:

cell(Table1,1,1,John). 

Затем дадим имена каждой из колонок:

clientId(Row, Value) :- cell(Table1, Row, 1, Value).

После чего можно объединить все колонки в одно понятие:

bill(Row, ClientId, Date, AmountToPay, AmountPaid) :- clientId(Row, ClientId), date(Row, Date), amountToPay(Row, AmountToPay), amountPaid(Row, AmountPaid).unpaidBill(Row, ClientId, Date, AmountToPay, AmountPaid) :- bill(Row, ClientId, Date, AmountToPay, AmountPaid),  AmountToPay >  AmountPaid.debtor(ClientId, Name, Email) :- client(ClientId, Name, Email), unpaidBill(_, ClientId, _, _, _).

И так далее.

Сложности начнутся при работе с моделью: при реализации логики рассылки сообщений, передаче данных другим сервисам, сложных алгоритмических вычислений. Слабым местом Prolog является описание последовательностей действий. Их декларативная реализация даже в простых случаях может выглядеть очень неестественно и требует значительных усилий и квалификации. Кроме того, синтаксис Prolog не очень соответствует объектно-ориентированной модели, и описания сложных составных понятий с большим количеством атрибутов будут довольно тяжелыми для восприятия.

Как же нам совместить основной функциональный или объектно-ориентированный язык разработки с декларативной природой модели предметной области?


Наиболее известным подходом является предметно-ориентированное проектирование (Domain-Driven Design). Эта методология облегчает создание и реализацию сложных моделей предметной области. Она предписывает, чтобы все понятия модели были выражены в коде явным образом в слое бизнес логики. Понятия модели и реализующие их элементы программы должны быть как можно ближе к друг другу и соответствовать единому языку, понятному как программистам, так и экспертам по предметной области.

Богатая модель предметной области для примера с должниками будет дополнительно содержать классы для понятий Неоплаченный счет и Должник, классы-агрегаты для объединения понятий счетов и клиентов, фабрики для создания объектов. Реализация и поддержка такой модели более трудоемкая, а код громоздкий то, что раньше можно было сделать одной строчкой, в богатой модели требует нескольких классов. В итоге, на практике такой подход имеет смысл только при работе больших команд над сложными масштабными моделями.

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

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

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

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

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

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

На первый раз достаточно. В следующей публикации я хочу поговорить о некоторых современных технологиях, совмещающих императивный и декларативный стили PL/SQL, Microsoft LINQ и GraphQL. Для тех, кто не хочет ждать выхода всех публикаций на Хабре, есть полный текст в научном стиле на английском языке, доступный по ссылке:
Hybrid Ontology-Oriented Programming for Semi-Structured Data Processing.
Подробнее..

Проектируем мульти-парадигменный язык программирования. Часть 3 Обзор языков представления знаний

04.11.2020 12:10:51 | Автор: admin
Продолжаем рассказ о создании мульти-парадигменного языка программирования, поддерживающего декларативный логический стиль для описания модели предметной области. Прошлые публикации находятся здесь и здесь. Теперь пришло время для описания основных особенностей и требований к языку описания модели предметной области. Но для начала сделаем небольшой обзор наиболее популярных языков представления знаний. Это довольно обширная область, имеющая давнюю историю и включающая ряд направлений логическое программирование, реляционное исчисление, технологии семантической паутины, фреймовые языки. Я хочу сравнить такие языки как Prolog, SQL, RDF, SPARQL, OWL и Flora, выделить те их особенности, которые были бы полезны в проектируемом мульти-парадигменном языке программирования.

Prolog.


Начнем с логического программирования и языка Prolog. Знания о предметной области представляются в нем в виде набора фактов и правил. Факты описывают непосредственные знания. Факты о клиентах (идентификатор, имя и адрес электронной почты) и счетах (идентификатор счета, клиента, дата, сумма к оплате и оплаченная сумма) из примера из прошлой публикации будут выглядеть следующим образом
client(1, "John", "john@somewhere.net").
bill(1, 1,"2020-01", 100, 50).

Правила описывают абстрактные знания, которые можно вывести из других правил и фактов. Правило состоит из головы и тела. В голове правила нужно задать его имя и список аргументов. Тело правила представляет собой список предикатов, соединенных логическими операциями AND (задается запятой) и OR (задается точкой с запятой). Предикатами могут служить факты, правила или встроенные предикаты, такие как операции сравнения, арифметические операции и др. Связь между аргументами головы правила и аргументами предикатов в его теле задается с помощью логических переменных если одна и та же переменная стоит на позициях двух разных аргументов, то значит, что эти аргументы идентичны. Правило считается истинным тогда, когда истинно логическое выражение тела правила. Модель предметной области можно задать в виде набора ссылающихся друг на друга правил:
unpaidBill(BillId, ClientId, Date, AmoutToPay, AmountPaid) :- bill(BillId, ClientId, Date, AmoutToPay, AmountPaid), AmoutToPay < AmountPaid.
debtor(ClientId, Name, Email) :- client(ClientId, Name, Email), unpaidBill(BillId, ClientId, _, _, _).

Мы задали два правила. В первом мы утверждаем, что все счета, у которых сумма к оплате меньше оплаченной суммы, являются неоплаченными счетами. Во втором, что должником является клиент, у которого есть хотя бы один неоплаченный счет.
Синтаксис Prolog очень простой: основной элемент программы правило, основные элементы правила это предикаты, логические операции и переменные. В правиле внимание сфокусированно на переменных они играют роль объекта моделируемого мира, а предикаты описывают их свойства и отношения между ними. В определении правила debtor мы утверждаем, что если объекты ClientId, Name и Email связанны отношениями client и unpaidBill, то они также будут связаны и отношением debtor. Prolog удобен в тех случаях, когда задача сформулирована в виде набора правил, утверждений или логических высказываний. Например, при работе с грамматикой естественного языка, компиляторами, в экспертных системах, при анализе сложных систем, таких как вычислительная техника, компьютерные сети, объекты инфраструктуры. Сложные, запутанные системы правил лучше описать в явном виде и предоставить среде исполнения Prolog разбираться с ними автоматически.

Prolog основан на логике первого порядка (с включением некоторых элементов логики высшего порядка). Логический вывод выполняется с помощью процедуры, называемой SLD резолюция (Selective Linear Definite clause resolution). Упрощенно ее алгоритм представляет собой обход дерева всех возможных решений. Процедура вывода находит все решения для первого предиката тела правила. Если текущий предикат в базе знаний представлен только фактами, то решениями являются те из них, которые соответствуют текущим привязкам переменных к значениям. Если правилами то потребуется рекурсивная проверка их вложенных предикатов. Если решений не найдено, то текущая ветвь поиска завершается неудачей. Затем для каждого найденного частичного решения создается новая ветвь. В каждой ветви процедура логического вывода выполняет привязку найденных значений к переменным, входящим в состав текущего предиката, и рекурсивно выполняет поиск решения для оставшегося списка предикатов. Работа завершается, если достигнут конец списка предикатов. Поиск решения может войти в бесконечный цикл в случае рекурсивного определения правил. Результатом работы процедуры поиска является список всех возможных привязок значений к логическим переменным.
В примере выше для правила debtor правило резолюции сначала найдет одно решение для предиката client и свяжет его с логическими переменными: ClientId = 1, Name = John, Email = john@somewhere.net. Затем для этого варианта значений переменных будет выполнен поиск решения для следующего предиката unpaidBill. Для этого потребуется сначала найти решения для предиката bill при условии, что ClientId = 1. Результатом будут привязки для переменных BillId = 1, Date = 2020-01, AmoutToPay = 100, AmountPaid = 50. В конце будет выполнена проверка AmoutToPay < AmountPaid во встроенном предикате сравнения.

Семантические сети.


Одним из наиболее популярных способов представления знаний являются семантические сети. Семантическая сеть представляет собой информационную модель предметной области в виде ориентированного графа. Вершины графа соответствуют понятиям предметной области, а дуги задают отношения между ними.
image
Например, согласно графу на рисунке выше понятие Кит связано отношением есть (является) с понятием Млекопитающее и живет в с понятием Вода. Таким образом мы можем формальным образом задать структуру предметной области какие понятия она включает и как они между собой связаны. А дальше такой граф можно использовать для поиска ответов на вопросы и вывода из него новых знаний. Например, мы можем вывести знание о том, что Кит имеет Позвоночник, если решим, что отношение есть обозначает отношение класс-подкласс, и подкласс Кит должен наследовать все свойства своего класса Млекопитающее.

RDF.


Семантическая паутина (semantic web) это попытка построить глобальную семантическую сеть на базе ресурсов Всемирной паутины путём стандартизации представления информации в виде, пригодном для машинной обработки. Для этого в HTML-страницы дополнительно закладывается информация в виде специальных атрибутов HTML тэгов, которая позволяет описать смысл их содержимого в виде онтологии набора фактов, абстрактных понятий и отношений между ними.
Стандартным подходом для описания семантической модели WEB ресурсов является RDF (Resource Description Framework или Среда Описания Ресурсов). Согласно ней все утверждения должны иметь форму триплета субъект предикат объект. Например, знания о понятии Кит будут представлены следующим образом: Кит является субъектом, живет в предикатом, Вода объектом. Весь набор таких утверждений можно описать с помощью ориентированного графа, субъекты и объекты являются его вершинами, а предикаты дугами, дуги предикатов направлены от объектов к субъектам. Например, онтологию из примера с животными можно описать в следующем виде:
@prefix : <...some URL...>
@prefix rdf: <http://www.w3.org/1999/02/rdf-schema#>
@prefix rdfs: <http://www.w3.org/2000/01/22-rdf-syntax-ns#>
:Whale rdf:type :Mammal;
:livesIn :Water.
:Fish rdf:type :Animal;
:livesIn :Water.

Такая форма записи называется Turtle, она предназначена для чтения человеком. Но то же самое можно записать и в XML, JSON форматах или с помощью тэгов и атрибутов HTML документа. Хоть в Turtle нотации предикаты и объекты можно сгруппировать вместе по субъектам для удобства чтения, но на семантическом уровне каждый триплет независим.
RDF удобен в тех случаях, когда модель данных сложна и содержит большое количество типов объектов и связей между ними. Например, Wikipedia предоставляет доступ к содержимому своих статей в RDF формате. Факты, описанные в статьях структурированы, описаны их свойства и взаимные отношения, включая факты из других статей.

RDFS


RDF модель представляет собой граф, по умолчанию никакой дополнительной семантики в нем не заложено. Каждый может интерпретировать заложенные в графе связи как посчитает нужным. Добавить в него некоторые стандартные связи можно с помощью RDF Schema набора классов и свойств для построения онтологий поверх RDF. RDFS позволяет описать стандартные отношения между понятиями, такие как принадлежность ресурса некоторому классу, иерархию между классами, иерархию свойств, ограничить возможные типы субъекта и объекта.
Например, утверждение
:Mammal rdfs:subClassOf :Animal.
задает, что Млекопитающее является подклассом понятия Животное и наследует все его свойства. Соответственно, понятие Кит также можно отнести к классу Животное. Но для этого нужно указать, что понятия Млекопитающее и Животное являются классами:
:Animal rdf:type rdfs:Class.
:Mammal rdf:type rdfs:Class.

Так же предикату можно задать ограничения на возможные значения его субъекта и объекта. Утверждение
:livesIn rdfs:range :Environment.
указывает, что объектом отношения живет в всегда должен быть ресурс, относящийся к классу Окружающая среда. Поэтому мы должны добавить утверждение о том, что понятие Вода является подклассом понятия Окружающая среда:
:Water rdf:type :Environment.
:Environment rdf:type rdfs:Class

RDFS позволяет описать схему данных перечислить классы, свойства, задать их иерархию и ограничения их значений. А RDF наполнить эту схему конкретными фактами и задать отношения между ними. Теперь мы можем задать вопрос к этому графу. Сделать это можно на специальном языке запросов SPARQL, напоминающем SQL:
SELECT ?creature
WHERE {
?creature rdf:type :Animal;
:livesIn :Water.
}

Этот запрос вернет нам 2 значения: Whale и Fish.

Пример из предыдущих публикаций со счетами и клиентами можно реализовать приблизительно следующим образом. С помощью RDF можно описать схему данных и наполнить ее значениями:
:Client1 :name "John";
:email "john@somewhere.net".
:Client2 :name "Mary";
:email "mary@somewhere.net".
:Bill_1 :client :Client1;
:date "2020-01";
:amountToPay 100;
:amountPaid 50.
:Bill_2 :client :Client2;
:date "2020-01";
:amountToPay 80;
:amountPaid 80.

Но вот абстрактные понятия, такие как Должник и Неоплаченные счета из первой статьи этого цикла, включают в себя арифметические операции и сравнение. Они не вписываются в статичную структуру семантической сети понятий. Эти понятия можно выразить с помощью SPARQL запросов:
SELECT ?clientName ?clientEmail ?billDate ?amountToPay ?amountPaid
WHERE {
?client :name ?clientName;
:email ?clientEmail.
?bill :client ?client;
:date ?billDate;
:amountToPay ?amountToPay;
:amountPaid ?amountPaid.
FILTER(?amountToPay > ?amountPaid).
}

Секция WHERE представляет собой список шаблонов триплетов и условий фильтрации. В триплеты можно подставлять логические переменные, имя которых начинается с символа "?". Задача исполнителя запроса найти все возможные значения переменных, при которых все шаблоны триплетов содержались бы в графе и выполнялись условия фильтрации.
В отличии от Prolog, где на основе правил можно конструировать другие правила, в RDF запрос не является частью семантической сети. На запрос нельзя ссылаться как на источник данных для другого запроса. Правда у SPARQL есть возможность представить результаты запроса в виде графа. Так что можно попробовать объединить результаты запроса с исходным графом и новый запрос выполнить на объединенном графе. Но такое решение будет явно выходить за рамки идеологии RDF.

OWL.


Важным компонентом технологий семантической паутины является OWL (Web Ontology Language) язык описания онтологий. С помощью словаря RDFS можно выразить только самые базовые отношения между понятиями иерархию классов и отношений. OWL предлагает гораздо более богатый словарь. Например, можно задать, что два класса (или две сущности) являются эквивалентными (или различными). Такая задача часто встречается при объединении онтологий.
Можно создавать составные классы на основе пересечения, объединения или дополнения других классов:
  • При пересечении все экземпляры составного класса должны относиться и ко всем исходным классам. Например, Морское млекопитающее должно быть одновременно и Млекопитающим и Морским жителем.
  • При объединении составной класс включает в себя все экземпляры исходных классов. Например, можно задать, что класс Животное является объединением классов Хищник, Травоядное и Всеядное. Все экземпляры этих классов будут заодно и Животными.
  • При дополнении к составному классу относится все, что не относится к исходному. Например, класс Хладнокровное дополняет класс Теплокровное.
  • Так же можно создавать классы на основе перечислений. Можно указать, что экземпляр составного класса обязательно должен быть экземпляром только одного из исходных классов.
  • Можно задавать наборы непересекающихся классов если экземпляр относится к одному из них, то одновременно он не может относиться к остальным классам из набора.

Такие выражения, позволяющие связать понятия между собой, называются конструкторами.
OWL также позволяет задавать многие важные свойства отношений:
  • Транзитивность. Если выполняются отношения P(x, y) и P(y, z), то обязательно выполняется и отношение P(x, z). Примерами таких отношений являются Больше-Меньше, Родитель-Потомок и т.п.
  • Симметричность. Если выполняется отношение P(x, y), то обязательно выполняется и отношение P(y, x). Например, отношение Родственник.
  • Функциональная зависимость. Если выполняются отношения P(x, y) и P(x, z), то значения y и z должны быть идентичными. Примером является отношение Отец у человека не может быть два разных отца.
  • Инверсия отношений. Можно задать, что если выполняется отношение P1(x, y), то обязательно должно выполняться еще одно отношение P2(y, x). Примером таких отношений являются отношения Родитель и Потомок.
  • Цепочки отношений. Можно задать, что если А связан неким свойством с В, а В с С, то А (или С) относится к заданному классу. Например, если у А есть отец В, а у отца В свой отец С, то А приходится внуком С.

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

Сейчас OWL является фактически стандартным средством для построения онтологий. Этот язык лучше подходит для построения больших и сложных онтологий чем RDFS. Синтаксис OWL позволяет выразить больше разных свойств понятий и отношений между ними. Но и вводит ряд дополнительных ограничений, например, одно и то же понятие нельзя одновременно объявить и как класс и как экземпляр другого класса. Онтологии в OWL жестче, более стандартизированы и, соответственно, более читабельны. Если RDFS это всего лишь несколько дополнительных классов поверх RDF графа, то OWL имеет другую математическую основу дескрипционную логику. Соответственно, становятся доступны и формальные процедуры логического вывода, позволяющие извлекать новую информацию из OWL онтологий, проверять их согласованность и отвечать на вопросы.

Дескрипционная или описательная логика (descriptive logic) является фрагментом логики первого порядка. В ней допустимы только одноместные (например, принадлежность понятия к классу), двухместные предикаты (наличие у понятия свойства и его значения), а также конструкторы классов и свойства отношений, перечисленные выше. Все остальные выражения логики первого порядка в дескрипционной логике отброшены. Например, допустимыми будут утверждения, что понятие Неоплаченный счет относится к классу Счет, понятие Счет имеет свойства Сумма к оплате и Оплаченная сумма. Но вот сделать утверждение, что у понятия Неоплаченный счет свойство Сумма к оплате должно быть больше свойства Оплаченная сумма уже не получится. Для этого понадобится правило, которое будет включать предикат сравнения этих свойств. К сожалению, конструкторы OWL не позволяют сделать это.
Таким образом, выразительность дискрипционной логики ниже, чем у логики первого порядка. Но, с другой стороны, алгоритмы логического вывода в дескрипционной логике гораздо быстрее. Кроме того, она обладает свойством разрешимости решение гарантированно может быть найдено за конечное время. Считается, что на практике такого словаря вполне достаточно для построения сложных и объемных онтологий, и OWL это хороший компромисс между выразительностью и эффективностью логического вывода.

Также стоит упомянуть SWRL (Semantic Web Rule Language), который сочетает возможность создания классов и свойств в OWL с написанием правил на ограниченной версии языка Datalog. Стиль таких правил такой же, как и в языке Prolog. SWRL поддерживает встроенные предикаты для сравнения, математических операций, работы со строками, датами и списками. Это как раз то, чего нам не хватало для того, чтобы с помощью одного простого выражения реализовать понятие Неоплаченный счет.

Flora-2.


В качестве альтернативы семантическим сетям рассмотрим также такую технологию как фреймы. Фрейм это структура, описывающая сложный объект, абстрактный образ, модель чего-либо. Он состоит из названия, набора свойств (характеристик) и их значений. Значением свойства может быть другой фрейм. Также у свойства может быть значение по умолчанию. К свойству может быть привязана функция вычисления его значения. В состав фрейма также могут входить служебные процедуры, в том числе обработчики таких событий так создание, удаление фрейма, изменение значения свойств и др. Важным свойством фреймов является возможность наследования. Дочерний фрейм включает в себя все свойства родительских фреймов.
Система связанных фреймов формирует семантическую сеть, очень похожую на RDF граф. Но в задачах создания онтологий фреймы были вытеснены языком OWL, который сейчас является фактическим стандартом. OWL более выразителен, имеет более продвинутое теоретическое основание формальную дискрипционную логику. В отличии от RDF и OWL, в которых свойства понятий описываются независимо друг от друга, в фреймовой модели понятие и его свойства рассматриваются как единой целое фрейм. Если в моделях RDF и OWL в вершинах графа находятся имена понятий, а в ребрах их свойства, то во фреймовой модели в вершинах графа расположены понятия со всеми их свойствами, а в ребрах связи между их свойствами или отношения наследования между понятиями.
В этом фреймовая модель очень близка модели объектно-ориентированного программирования. Они во многом совпадают, но имеют разную сферу применения фреймы направлены на моделирование сети понятий и отношений между ними, а ООП на моделирование поведения объектов, их взаимодействия между собой. Поэтому в ООП доступны дополнительные механизмы скрытия деталей реализации одного компонента от других, ограничения доступа к методам и полям класса.

Современные фреймовые языки (такие как KL-ONE, PowerLoom, Flora-2) комбинируют составные типы данных объектной модели с логикой первого порядка. В этих языках можно не только описывать структуру объектов, но и оперировать этими объектами в правилах, создавать правила, описывающие условия принадлежности объекта заданному классу и т.д. Механизмы наследования и композиции классов получают логическую трактовку, которая становится доступна для использования процедурам логического вывода. Выразительность этих языков выше, чем у OWL, они не ограничены двухместными предикатами.
В качестве примера попробуем реализовать наш пример с должниками на языке Flora-2. Этот язык включает в себя 3 компонента: фреймовую логику F-logic, объединяющую фреймы и логику первого порядка, логику высших порядков HiLog, предоставляющую инструменты для формирования высказываний о структуре других высказываний и мета-программирования, и логику изменений Transactional Logic, позволяющую в логической форме описывать изменения в данных и побочные эффекты (side effects) вычислений. Сейчас нас интересует только фреймовая логика F-logic. Для начала с ее помощью объявим структуру фреймов, описывающих понятия (классы) клиентов и должников:
client[|name => \string,
email => \string
|].
bill[|client => client,
date => \string,
amountToPay => \number,
amountPaid => \number,
amountPaid -> 0
|].

Теперь мы можем объявить экземпляры (объекты) этих понятий:
client1 : client[name -> 'John', email -> 'john@somewhere.net'].
client2 : client[name -> 'Mary', email -> 'mary@somewhere.net'].
bill1 : bill[client -> client1,
date -> '2020-01',
amountToPay -> 100
].
bill2 : bill[client -> client2,
date -> '2020-01',
amountToPay -> 80,
amountPaid -> 80
].

Символ '->' означает связь атрибута с конкретным значением у объекта и значение по умолчанию в объявлении класса. В нашем примере поле amountPaid класса bill имеет нулевое значение по умолчанию. Символ ':' означает создание сущности класса: client1 и client2 являются сущностями класса client.
Теперь мы можем объявить, что понятия Неоплаченный счет и Должник являются подклассами понятий Счет и Клиент:
unpaidBill :: bill.
debtor :: client.

Символ '::' объявляет отношение наследования между классами. Наследуется структура класса, методы и значения по умолчанию для всех его полей. Осталось объявить правила, задающие принадлежность к классам unpaidBill и debtor:
?x : unpaidBill :- ?x : bill[amountToPay -> ?a, amountPaid -> ?b], ?a > ?b.
?x : debtor :- ?x : client, ?_ : unpaidBill[client -> ?x].

В первом высказывании утверждается, что переменная является сущностью класса unpaidBill, если она является сущностью класса bill, и значение ее поля amountToPay больше значения amountPaid. Во втором, что относится к классу unpaidBill, если она относится к классу client и существует хотя бы одна сущность класса unpaidBill, у которой значение поля client равно переменной . Эта сущность класса unpaidBill будет связана с анонимной переменной ?_, значение которой в дальнейшем не используется.
Получить список должников можно с помощью запроса:
?- ?x:debtor.
Мы просим найти все значения, относящиеся к классу debtor. Результатом будет список всех возможных значений переменной ?x:
?x = client1

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

SQL


Напоследок рассмотрим основные особенности синтаксиса SQL. В прошлой публикации мы говорили, что SQL имеет логическую теоретическую основу реляционное исчисление, и рассмотрели реализацию примера с должниками на LINQ. В плане семантики SQL близок к фреймовым языкам и ООП модели в реляционной модели данных основным элементом является таблица, которая воспринимается как единое целое, а не как набор отдельных свойств.
Синтаксис SQL прекрасно соответствует такой ориентации на таблицы. Запрос разбит на секции. Сущности модели, которые представлены таблицами, представлениями (view) и вложенными запросами, вынесены в секцию FROM. Связи между ними указываются с помощью операций JOIN. Зависимости между полями и другие условия находятся в секциях WHERE и HAVING. Вместо логических переменных, связывающих аргументы предикатов, в запросе мы оперируем полями таблиц напрямую. Такой синтаксис описывает структуру модели предметной области более наглядно по сравнению с линейным синтаксисом Prolog.

Каким я вижу стиль синтаксиса языка моделирования.


На примере со неоплаченными счетами мы можем сравнить такие подходы как логическое программирование (Prolog), фреймовую логику (Flora-2), технологии семантической паутины (RDFS, OWL и SWRL) и реляционное исчисление (SQL). Их основные характеристики я свел в таблицу:
Язык Математическая основа Ориентация стиля Сфера применения
Prolog Логика первого порядка На правила Системы, основанные на правилах, сопоставление с образцом.
RDFS Граф На связи между понятиями Схема данных WEB ресурса
OWL Дескрипционная логика На связи между понятиями Онтологии
SWRL Урезанная версия логики первого порядка как у Datalog На правила поверх связей между понятиями Онтологии
Flora-2 Фреймы + логика первого порядка На правила поверх структуры объектов Базы данных, моделирование сложных систем, интеграция разрозненных данных
SQL Реляционное исчисление На структуры таблиц Базы данных

Теперь нужно подобрать математическую основу и стиль синтаксиса для языка моделирования, предназначенного для работы со слабоструктурированными данными и интеграцией данных из разрозненных источников, который бы сочетался с объектно-ориентированными и функциональными языками программирования общего назначения.
Наиболее выразительными языками является Prolog и Flora-2 они основаны на полной логике первого порядка с элементами логики высших порядков. Остальные подходы являются ее подмножествами. За исключением RDFS он вообще не связан с формальной логикой. На данном этапе полноценная логика первого порядка мне видится предпочтительным вариантом. Для начала я планирую остановиться на нем. Но и ограниченный вариант в виде реляционного исчисления или логики дедуктивных баз данных тоже имеет свои преимущества. Он обеспечивает большую производительность при работе с большими объемами данных. В будущем его стоит рассмотреть отдельно. Дескрипционная логика выглядит слишком ограниченной и неспособной выразить динамические отношения между понятиями.
С моей точки зрения, для работы со слабоструктурированными данными и интеграции разрозненных источников данных фреймовая логика подходит больше, чем Prolog, ориентированный на правила, или OWL, ориентированный на связи и классы понятий. Фреймовая модель описывает структуры из объектов в явном виде, фокусирует на них внимание. В случае объектов с большим количеством свойств фреймовая форма гораздо более читабельна, чем правила или триплеты субъект-свойство-объект. Наследование также является очень полезным механизмом, позволяющим значительно сократить объем повторяющегося кода. По сравнению с реляционной моделью фреймовая логика позволяет описать сложные структуры данных, такие как деревья и графы, более естественным образом. И, самое главное, близость фреймовой модели описания знаний к модели ООП позволит интегрировать их в одном языке естественным образом.
У SQL я хочу позаимствовать структуру запроса. Определение понятия может иметь сложную форму и его не помешает разбить на секции, чтобы подчеркнуть его составные части и облегчить восприятие. Кроме того, для большинства разработчиков синтаксис SQL довольно привычен.

Итак, за основу языка моделирования я хочу взять фреймовую логику. Но поскольку целью является описание структур данных и интеграция разрозненных источников данных я попробую отказаться от синтаксиса, ориентированного на правила, и заменить его на структурированный вариант, позаимствованный у SQL. Основным элементом модели предметной области будет понятие (concept). В его определение я хочу включить всю информацию, необходимую для извлечения его сущностей (entities) из исходных данных:
  • имя понятия;
  • набор его атрибутов;
  • набор исходных (родительских) понятий, служащих для него источниками данных;
  • набор условий, связывающих между собой атрибуты производного и исходного понятий;
  • набор условий, ограничивающих возможные значения атрибутов понятий.

Определение понятия будет напоминать SQL запрос. А вся модель предметной области будет иметь форму взаимосвязанных понятий.

Получившийся синтаксис языка моделирования я планирую показать в следующей публикации. Для тех, кто хочет познакомиться с ним уже сейчас, есть полный текст в научном стиле на английском языке, доступный по ссылке:
Hybrid Ontology-Oriented Programming for Semi-Structured Data Processing

Ссылки на предыдущие публикации:
Проектируем мульти-парадигменный язык программирования. Часть 1 Для чего он нужен?
Проектируем мульти-парадигменный язык программирования. Часть 2 Сравнение построения моделей в PL/SQL, LINQ и GraphQL
Подробнее..

Проектируем мульти-парадигменный язык программирования. Часть 4 Основные конструкции языка моделирования

26.11.2020 14:19:49 | Автор: admin
Продолжаем рассказ о создании мульти-парадигменного языка программирования, сочетающего декларативный стиль с объектно-ориентированным и функциональным, который был бы удобен при работе со слабоструктурированными данными и интеграции данных из разрозненных источников. Наконец-то после введения и обзоров существующих мульти-парадигменных технологий и языков представления знаний мы добрались до описания той части гибридного языка, которая ответственна за описание модели предметной области. Я назвал ее компонентой моделирования.
Компонента моделирования предназначена для декларативного описания модели предметной области в форме онтологии сети из экземпляров данных (фактов) и абстрактных понятий, связанных между собой с помощью отношений. В ее основе лежит фреймовая логика гибрид объектно-ориентированного подхода к представлению знаний и логики первого порядка. Ее основной элемент понятие, описывающее моделируемый объект с помощью набора атрибутов. Понятие строится на основе других понятий или фактов, исходные понятия назовем родительскими, производное дочерним. Отношения связывают значения атрибутов дочернего и родительских понятий или ограничивают их возможные значения. Я решил включить отношения в состав определения понятия, чтобы вся информация о нем находилась по возможности в одном месте. Стиль синтаксиса для определений понятий будет похож на SQL атрибуты, родительские понятия и отношения между ними должны быть разнесены по разным секциям.
В этой публикации я хочу представить основные способы определения понятий.

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

Начнем с фактов.


Факты представляют собой описание конкретных знаний о предметной области в виде именованного набора пар ключ-значение:
fact <имя факта> {
<имя атрибута> : <значение атрибута>
...
}

Например:
fact product {
name: Cabernet Sauvignon,
type: red wine,
country: Chile
}


Имя факта может быть не уникальным, например, может быть множество продуктов с разным названием, типом и страной происхождения. Будем считать факты идентичными, если совпадают их имена, а также имена и значения их атрибутов.
Можно провести аналогию между фактами компоненты моделирования и фактами языка Prolog. Их отличие заключается только в синтаксисе. В Prolog аргументы фактов идентифицируются по их позиции, а атрибуты фактов компоненты моделирования по имени.

Понятия.


Понятие представляет собой структуру, описывающую абстрактную сущность и основанную на других понятиях и фактах. Определение понятия включает в себя имя, списки атрибутов и дочерних понятий. А также логическое выражение, описывающее зависимости между его (дочернего понятия) атрибутами и атрибутами родительских понятий, позволяющие вывести значение атрибутов дочернего понятия:
concept <имя понятия> <псевдоним понятия> (
<имя атрибута> = <выражение>,
...
)
from
<имя родительского понятия> <псевдоним родительского понятия> (
<имя атрибута> = <выражение>
...
),

where <выражение отношений>

Пример определения понятия profit на основе понятий revenue и cost:
concept profit p (
value = r.value c.value,
date
) from revenue r, cost c
where p.date = r.date = c.date


Определение понятия похоже по форме на SQL запрос, но вместо имени таблиц нужно указывать имена родительских понятий, а вместо возвращаемых столбцов атрибуты дочернего понятия. Кроме того, понятие имеет имя, по которому к нему можно обращаться в определениях других понятий или в запросах к модели. Родительским понятием может быть как непосредственно понятие, так и факты. Выражение отношений в секции where это булево выражение, которое может включать логические операторы, условия равенства, арифметические операторы, вызовы функций и др. Их аргументами могут быть переменные, константы и ссылки на атрибуты как родительских так и дочернего понятий. Ссылки на атрибуты имеют следующий формат:
<псевдоним понятия>.<имя атрибута>
По сравнению с фреймовой логикой в определении понятия его структура (атрибуты) объединена с отношениями с другими понятиями (родительские понятия и выражение отношений). С моей точки зрения это позволяет сделать код более понятным, так как вся информация о понятии собрана в одном месте. А также соответствует принципу инкапсуляции в том смысле, что детали реализации понятия скрыты внутри его определения. Для сравнения небольшой пример на языке фреймовой логики можно найти в прошлой публикации.
Выражение отношений имеет конъюнктивную форму (состоит из выражений, соединенных логическими операциями AND) и должно включать условия равенства для всех атрибутов дочернего понятия, достаточные для определения их значений. Кроме того, в него могут входить условия, ограничивающие значения родительских понятий или связывающие их между собой. Если в секции where будут связаны между собой не все родительские понятия, то механизм логического вывода вернет все возможные комбинации их значений в качестве результата (аналогично операции FULL JOIN языка SQL).
Для удобства часть условий равенства атрибутов может быть вынесена в секции атрибутов дочернего и родительских понятий. Например, в определении понятия profit условие для атрибута value вынесено в секцию атрибутов, а для атрибута date оставлено в секции where. Также можно перенести их и в секцию from:
concept profit p (
value = r.value c.value,
date = r.date
) from revenue r, cost c (date = r.date)

Такой синтаксический сахар позволяет сделать зависимости между атрибутами более явными и выделить их из остальных условий.

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

Поскольку список родительских понятий и условия отношений разнесены по отдельным секциям, логический вывод будет немного отличаться от такового в Prolog. Опишу в общем виде его алгоритм. Вывод родительских понятий будет выполнен в том порядке, в котором они указаны в секции from. Поиск решения для следующего понятия выполняется для каждого частичного решения предыдущих понятий так же, как и в SLD резолюции. Но для каждого частичного решения выполняется проверка истинности выражения отношений из секции where. Поскольку это выражение имеет форму конъюнкции, то каждое подвыражение проверяется отдельно. Ели подвыражение ложно, то данное частичное решение отвергается и поиск переходит к следующему. Если часть аргументов подвыражения еще не определена (не связана со значениями), то его проверка откладывается. Если подвыражением является оператор равенства и определен только один из его аргументов, то система логического вывода найдет его значение и попытается связать его с оставшимся аргументом. Это возможно, если свободным аргументом является атрибут или переменная.
Например, при выводе сущностей понятия profit сначала будут найдены сущности понятия revenue, и, соответственно, значения его атрибутов. После чего равенство p.date = r.date = c.date в секции where даст возможность связать со значениями атрибуты date и других понятий. Когда логический поиск доберется до понятия cost, значение его атрибута date будет уже известно и будет является входным аргументом для этой ветви дерева поиска. Подробно рассказать об алгоритмах логического вывода я планирую в одной из следующих публикаций.
Отличие от Prolog заключается в том, что в правилах Prolog все является предикатами и обращения к другим правилам и встроенные предикаты равенства, сравнения и др. И порядок их проверки нужно указывать явным образом, например, сначала должны идти два правила а затем равенство переменных:
profit(value,date) :- revenue(rValue, date), cost(cValue, date), value = rValue cValue
В таком порядке они и будут выполнены. В компоненте моделирования же предполагается, что все вычисления условий в секции where являются детерминированными, то есть не требуют рекурсивного погружения в следующую ветвь поиска. Поскольку их вычисление зависит только от их аргументов, они могут быть вычислены в произвольном порядке по мере связывания аргументов со значениями.

В результате логического вывода все атрибуты дочернего понятия должны быть связаны со значениями. А также выражение отношений должно быть истинно и не содержать неопределенных подвыражений. Стоит заметить, что вывод родительских понятий не обязательно должен быть успешным. Допустимы случаи, когда требуется проверить неудачу выведения родительского понятия из исходных данных, например, в операциях отрицания. Порядок родительских понятий в секции from определяет порядок обхода дерева решений. Это дает возможность оптимизировать поиск решения, начав его с тех понятий, которые сильнее ограничивают пространство поиска.
Задача логического вывода найти все возможные подстановки атрибутов дочернего понятия и каждую из них представить в виде объекта. Такие объекты считаются идентичными если совпадают имена их понятий, имена и значения атрибутов.

Допустимым считается создание нескольких понятий с одинаковым именем, но с разной реализацией, включая различный набор атрибутов. Это могут быть разные версии одного понятия, родственные понятия, которые удобно объединить под одним именем, одинаковые понятия из разных источников и т.п. При логическом выводе будут рассмотрены все существующие определения понятия, а результаты их поиска будут объединены. Несколько понятий с одинаковыми именами аналогичны правилу в языке Prolog, в котором список термов имеет дизъюнктивную форму (термы связаны операцией ИЛИ).

Наследование понятий.


Одними из наиболее распространенных отношений между понятиями являются иерархические отношения, например род-вид. Их особенностью является то, что структуры дочернего и родительского понятий будут очень близки. Поэтому поддержка механизма наследования на уровне синтаксиса очень важна, без нее программы будут переполнены повторяющимся кодом. При построении сети понятий было бы удобно повторно использовать как их атрибуты, так и отношения. Если список атрибутов легко расширять, сокращать или переопределять некоторые из них, то с модификацией отношений дело обстоит сложнее. Поскольку они представляют собой логическое выражение в конъюнктивной форме, то к нему легко прибавить дополнительные подвыражения. Но удаление или изменение может потребовать значительного усложнения синтаксиса. Польза от этого не так очевидна, поэтому отложим эту задачу на будущее.
Объявить понятие на основе наследования можно с помощью следующей конструкции:
concept <имя понятия> <псевдоним понятия> is
<имя родительского понятия> <псевдоним родительского понятия> (
<имя атрибута> = <выражение>,
...
),
...
with <имя атрибута> = <выражение>, ...
without <имя родительского атрибута>, ...
where <выражение отношений>

Секция is содержит список наследуемых понятий. Их имена можно указать напрямую в этой секции. Или же указать полный список родительских понятий в секции from, а в is псевдонимы только тех из них, которые будут наследоваться:
concept <имя понятия> <псевдоним понятия> is
<псевдоним родительского понятия>,

from
<имя родительского понятия> <псевдоним родительского понятия> (
<имя атрибута> = <выражение>
...
),

with <имя атрибута> = <выражение>, ...
without <имя родительского атрибута>, ...
where <выражение отношений>

Секция with позволяет расширить список атрибутов наследуемых понятий или переопределить некоторые из них, секция without сократить.

Алгоритм логического вывода понятия на основе наследования такой же, как и у понятия, рассмотренного выше. Разница только в том, что список атрибутов автоматически генерируется на основе списка атрибутов родительского понятия, а выражение отношений дополняется операциями равенства атрибутов дочернего и родительского понятий.

Рассмотрим несколько примеров использования механизма наследования. Наследование позволяет создать понятие на основе уже существующего избавившись от тех атрибутов, которые имеют смысл только для родительского, но не для дочернего понятия. Например, если исходные данные представлены в виде таблицы, то ячейкам определенных столбцов можно дать свои имена (избавившись от атрибута с номером столбца):
concept revenue is tableCell without columnNum where columnNum = 2
Также можно преобразовать несколько родственных понятий в одну обобщенную форму. Секция with понадобится для того, чтобы преобразовать часть атрибутов к общему формату и добавить недостающие. Например, исходными данными могут быть документы разных версий, список полей которых менялся со временем:
concept resume is resumeV1 with skills = 'N/A'
concept resume is resumeV2 r with skills = r.coreSkills

Предположим, что в первой версии понятия Резюме не было атрибута с навыками, а во второй он назывался по-другому.
Расширение списка атрибутов может потребоваться во многих случаях. Распространенными задачами являются смена формата атрибутов, добавление атрибутов, функционально зависящих от уже существующих атрибутов или внешних данных и т.п. Например:
concept price is basicPrice with valueUSD = valueEUR * getCurrentRate('USD', 'EUR')
Также можно просто объединить несколько понятий под одним именем не меняя их структуру. Например, для того чтобы указать, что они относятся к одному роду:
concept webPageElement is webPageLink
concept webPageElement is webPageInput

Или же создать подмножество понятия, отфильтровав часть его сущностей:
concept exceptionalPerformer is employee where performanceEvaluationScore > 0.95

Возможно также множественное наследование, при котором дочернее понятие наследует атрибуты всех родительских понятий. При наличии одинаковых имен атрибутов приоритет будет отдан тому родительскому понятию, которое находится в списке левее. Также можно решить этот конфликт вручную, явно переопределив нужный атрибут в секции with. Например, такой вид наследования был бы удобен, если нужно собрать в одной плоской структуре несколько связанных понятий:
concept employeeInfo is employee e, department d where e.departmentId = d.id

Наследование без изменения структуры понятий усложняет проверку идентичности объектов. В качестве примера рассмотрим определение exceptionalPerformer. Запросы к родительскому (employee) и дочернему (exceptionalPerformer) понятиям вернут одну и ту же сущность сотрудника. Объекты, представляющие ее, будут идентичны по смыслу. У них будет общий источник данных, одинаковый список и значения атрибутов, на разное имя понятия, зависящее от того, к какому понятию был выполнен запрос. Поэтому операция равенства объектов должна учитывать эту особенность. Имена понятий считаются равными, если они совпадают или связаны транзитивным отношением наследования без изменения структуры.

Наследование это полезный механизм, позволяющий выразить явным образом такие отношения между понятиями как класс-подкласс, частное-общее, множество-подмножество. А также избавиться от дублирования кода в определениях понятий и сделать код более понятным. Механизм наследования основан на добавлении/удалении атрибутов, объединении нескольких понятий под одним именем и добавлении условий фильтрации. Никакой специальной семантики в него не вкладывается, каждый может воспринимать и применять его как хочет. Например, построить иерархию от частного к общему как в примерах с понятиями resume, price и webPageElement. Или, наоборот, от общего к частному, как в примерах с понятиями revenue и exceptionalPerformer. Это позволит гибко подстроиться под особенности источников данных.

Понятие для описания отношений.


Было решено, что для удобства понимания кода и облегчения интеграции компоненты моделирования с ООП моделью, отношения дочернего понятия с родительскими должны быть встроены в его определение. Таким образом, эти отношения задают способ получения дочернего понятия из родительских. Если модель предметной области строится слоями, и каждый новый слой основан на предыдущем, это оправдано. Но в некоторых случаях отношения между понятиями должны быть объявлены отдельно, а не входить в определение одного из понятий. Это может быть универсальное отношение, которое хочется задать в общем виде и применить к разным понятиям, например, отношение Родитель-Потомок. Либо отношение, связывающее два понятия, необходимо включить в определение обоих понятий, чтобы можно было бы найти как сущности первого понятия при известных атрибутах второго, так и наоборот. Тогда, во избежание дублирования кода отношение удобно будет задать отдельно.
В определении отношения необходимо перечислить входящие в него понятия и задать логическое выражение, связывающее их между собой:
relation <имя отношения>
between <имя вложенного понятия> <псевдоним вложенного понятия> (
<имя атрибута> = <выражение>,
...
),
...
where <логическое выражение>

Например, отношение, описывающее вложенные друг в друга прямоугольники, можно определить следующим образом:
relation insideSquareRelation between square inner, square outer
where inner.xLeft > outer.xLeft and inner.xRight < outer.xRight
and inner.yBottom > outer.yBottom and inner.yUp < outer.yUp

Такое отношение, по сути, представляет собой обычное понятие, атрибутами которого являются сущности вложенных понятий:
concept insideSquare (
inner = i
outer = o
) from square i, square o
where i.xLeft > o.xLeft and i.xRight < o.xRight
and i.yBottom > o.yBottom and i.yUp < o.yUp


Отношение можно использовать в определениях понятий наряду с другими родительскими понятиями. Понятия, входящие в отношения, будут доступны извне и будут играть роль его атрибутов. Имена атрибутов будут соответствовать псевдонимам вложенных понятий. В следующем примере утверждается, что в HTML форму входят те HTML элементы, которые расположены внутри нее на HTML странице:
сoncept htmlFormElement is e
from htmlForm f, insideSquareRelation(inner = e, outer = f), htmlElement e

При поиске решения сначала будут найдены все значения понятия htmlForm, затем они будут связаны со вложенным понятием outer отношения insideSquare и найдены значения его атрибута inner. А в конце будут отфильтрованы те значения inner, которые относятся к понятию htmlElement.

Отношению можно придать и функциональную семантику использовать его как функцию булева типа для проверки, выполняется ли отношение для заданных сущностей вложенных понятий:
сoncept htmlFormElement is e
from htmlElement e, htmlForm f
where insideSquareRelation(e, f)

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

Теперь пришло время рассмотреть небольшой пример.


Определений фактов и основных видов понятий достаточно, чтобы реализовать пример с должниками из первой публикации. Предположим, что у нас есть два файла в формате CSV, хранящих информацию о клиентах (идентификатор клиента, имя и адрес электронной почты) и счетах (идентификатор счета, идентификатор клиента, дата, сумма к оплате, оплаченная сумма).
А также имеется некая процедура, которая считывает содержимое этих файлов и преобразовывает их в набор фактов:
fact cell {
table: TableClients,
value: 1,
rowNum: 1,
columnNum: 1
};
fact cell {
table: TableClients,
value: John,
rowNum: 1,
columnNum: 2
};
fact cell {
table: TableClients,
value: john@somewhere.net,
rowNum: 1,
columnNum: 3
};

fact cell {
table: TableBills,
value: 1,
rowNum: 1,
columnNum: 1
};
fact cell {
table: TableBills,
value: 1,
rowNum: 1,
columnNum: 2
};
fact cell {
table: TableBills,
value: 2020-01-01,
rowNum: 1,
columnNum: 3
};
fact cell {
table: TableBills,
value: 100,
rowNum: 1,
columnNum: 4
};
fact cell {
table: TableBills,
value: 50,
rowNum: 1,
columnNum: 5
};


Для начала дадим ячейкам таблиц осмысленные имена:
concept clientId is cell where table = TableClients and columnNum = 1;
concept clientName is cell where table = TableClients and columnNum = 2;
concept clientEmail is cell where table = TableClients and columnNum = 3;
concept billId is cell where table = TableBills and columnNum = 1;
concept billClientId is cell where table = TableBills and columnNum = 2;
concept billDate is cell where table = TableBills and columnNum = 3;
concept billAmountToPay is cell where table = TableBills and columnNum = 4;
concept billAmountPaid is cell where table = TableBills and columnNum = 5;


Теперь можно объединить ячейки одной строки в единый объект:
concept client (
id = id.value,
name = name.value,
email = email.value
) from clientId id, clientName name, clientEmail email
where id.rowNum = name.rowNum = email.rowNum;


concept bill (
id = id.value,
clientId = clientId.value,
date = date.value,
amountToPay = toPay.value,
amountPaid = paid.value
) from billId id, billClientId clientId, billDate date, billAmountToPay toPay, billAmountPaid paid
where id.rowNum = clientId.rowNum = date.rowNum = toPay.rowNum = paid.rowNum;


Введем понятия Неоплаченный счет и Должник:
concept unpaidBill is bill where amountToPay > amountPaid;
concept debtor is client c where exist(unpaidBill {clientId: c.id});


Оба определения используют наследование, понятие unpaidBill является подмножеством понятия bill, debtor понятия client. Определение понятия debtor содержит вложенный запрос к понятию unpaidBill. Подробно механизм вложенных запросов мы рассмотрим позже в одной следующих публикаций.
В качестве примера плоского понятия определим также понятие Долг клиента, в котором объединим некоторые поля из понятия Клиент и Счет:
concept clientDebt (
clientName = c.name,
billDate = b.date,
debt = b. amountToPay b.amountPaid
) from unpaidBill b, client c(id = b.client);


Зависимость между атрибутами понятий client и bill вынесена в секцию from, а зависимости дочернего понятия clientDebt в секцию его атрибутов. При желании все они могут быть помещены в секцию where результат будет аналогичным. Но с моей точки зрения текущий вариант более краток и лучше подчеркивает назначение этих зависимостей определять связи между понятиями.

Теперь попробуем определить понятие злостного неплательщика, который имеет как минимум 3 неоплаченных счета подряд. Для этого понадобится отношение, позволяющее упорядочить счета одного клиента по их дате. Универсальное определение будет выглядеть следующим образом:
relation billsOrder between bill next, bill prev
where next.date > prev.date and next.clientId = prev.clientId and not exist(
bill inBetween
where next.clientId = inBetween.clientId
and next.date > inBetween.date > prev.date
);

В нем утверждается, что два счета идут подряд, если они принадлежат одному клиенту, дата одного больше даты другого и не существует другого счета, лежащего между ними. На данном этапе я не хочу останавливаться на вопросах вычислительной сложности такого определения. Но если, например, мы знаем, что все счета выставляются с интервалом в 1 месяц, то можно его значительно упростить:
relation billsOrder between bill next, bill prev
where next.date = prev.date + 1 month and next.clientId = prev.clientId;


Последовательность из 3х неоплаченных счетов будет выглядеть следующим образом:
concept unpaidBillsSequence (clientId = b1.clientId, bill1 = b1, bill2 = b2, bill3 = b3)
from
unpaidBill b1,
billsOrder next1 (next = b1, prev = b2)
unpaidBill b2
billsOrder next2 (next = b2, prev = b3)
unpaidBill b3;

В этом понятии сначала будет найдены все неоплаченные счета, затем для каждого из них с помощью отношения next1 будет найден следующий счет. Понятие b2 позволит проверить, что этот счет является неоплаченным. По этому же принципу с помощью next2 и b3 будет найден и третий неоплаченный счет подряд. Идентификатор клиента вынесен в список атрибутов отдельно, чтобы в дальнейшем облегчить связывание этого понятия с понятием клиентов:
concept hardCoreDefaulter is client c where exist(unpaidBillsSequence{clientId: c.id});

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

Краткие выводы.


Итак, я предложил три основных вида понятий компоненты моделирования гибридного языка:
  • понятия, созданные на основе трансформации других понятий;
  • понятия, наследующие структуру и отношения других понятий;
  • понятия, задающие отношения между другими понятиями.

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

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

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

Полный текст в научном стиле на английском языке доступен по ссылке: papers.ssrn.com/sol3/papers.cfm?abstract_id=3555711

Ссылки на предыдущие публикации:
Проектируем мульти-парадигменный язык программирования. Часть 1 Для чего он нужен?
Проектируем мульти-парадигменный язык программирования. Часть 2 Сравнение построения моделей в PL/SQL, LINQ и GraphQL
Проектируем мульти-парадигменный язык программирования. Часть 3 Обзор языков представления знаний
Подробнее..

Интернациональное программирование на естественных языках

05.12.2020 14:09:17 | Автор: admin
В последнее время часто попадаются на глаза статьи о новых языках программирования, а так же различные рейтинги и прогнозы, связанные с популярностью компьютерных языков.

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

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

О программистах.


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

Ведь как обычно создаются языки программирования?

У каждого программиста всегда есть какой-то своей предыдущий опыт:

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

А перед тем, как описывать синтаксис, выбирать ключевые слова и начинать основную работу: лексер, парсер, базовые библиотеки, нужно дать ответ на основные вопросы:

  • Компилятор/интерпретатор/транспилятор(transpiler)?
  • Статическая или динамическая типизация?
  • Ручное управление памятью или автоматическое со сборщиком мусора?
  • Модель программирования: ООП, функциональное, структурное или что-то новое?
  • Разрешены ли вставки из других языков программирования и т. д.?

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

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

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

О не программистах.


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

Ведь если не программист начинает программировать, то сам того не осознавая, он автоматически становится программистом ;-). А естественным язык программирования быть не может по определению. Точнее для компьютеров скорее всего естественным будет язык Assembler или набор машинных команд.

Поэтому, цель максимум приблизить язык программирования к естественному человеческому языку.

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

Но в подобно формулировке кроется очень большая проблема!

Любой язык программирования является интернациональным, т.к. его синтаксис не зависит от естественного языка, на котором общается программист.

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

В качестве иллюстрации: раз или два.

Если пофантазировать насчет хотелок к такому языку, то видятся следующие требования и ограничения:

  • Так как каждый пользователь является носителем своего родного естественного языка (или даже нескольких), то жестко задавать ключевые слова невозможно, из чего следует, что основой такого языка должны стать только правила пунктуации, но никак не лексика или грамматика.
  • Компилятор/транслятор должен уметь преобразовывать исходный текст программы не только в машинный код для компьютера, но в другой вариант естественного языка, чтобы пользователь мог работать с исходным текстом на известном ему естественном языке.
  • Очень хочется видеть в новом языке толерантность терпимость к очепяткам. Подобная фича присутствует в письме на естественном языке, и несмотря на наличие опечаток, практически всегда сохраняется смысл. Естественно, в данном случае не стоит доходить до фанатизма. Компилятор не читает мысли и не может в действительности понять, что имел ввиду пользователь, и все же довольно часто можно игнорировать опечатки в тексте программы исходя из контекста (пусть и с выводом предупреждающих сообщений).

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

О гипотетическом языке


Если взять за основу правила письменной речи, то основные соглашения и пунктуация для нового языка могут выглядеть примерно так:

  • Любой текст состоит из предложений и комментариев. Предложения обрабатываются, а комментарии игнорируются.
  • Предложение состоит из последовательности терминов, литералов и символов, разделенных пробелами и знаками препинания и завершается символом конца предложения.
  • Термин слитно написанная последовательность букв, цифр и символов ":" и "_".
  • Литерал константы, включаемые непосредственно в текст программы, тип которой определяется однозначно. Это символьные строки в кавычках, целые и вещественные числа, и некоторые специальные форматы (время, дата).
  • Символы все остальное символы, которые не относятся к знакам препинания, пробельным символам, цифрам и буквам.
  • Знаки препинания символы пунктуации, имеющие специальное значение при разборе текста программы:

    • .,;,!,?, конец предложения.
    • = присвоение значения.
    • "" (кавычки) определение символьной строки.
    • () передача параметров/аргументов или группировка операторов для определения приоритета выполнения операций.
    • [] массив или обращение к элементу массива.
    • {} включение в текст исходного кода программы на обычном языке программирования.
    • $ системная переменная.
    • @ системная функция.
    • , (запятая) перечисление.
    • : (двоеточие) список или логическая связь.

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

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

Так же эта возможность требуется для реализации низкоуровневых функций и для взаимодействия с внешними библиотеками.

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

Для похожих целей служат и символы $ системная переменная и @ системная функция. Если такой символ поставить в начале слова, тогда он станет обозначать объект с соответствующим назначением. Например @exit будет означать функцию, а $var переменную с соответствующими именами, а сами объекты станут доступны как в обычном коде, так и в программных вставках внутри фигурных скобок.

Аналогичным образом организуется и доступ к отдельным полям/методам объектов:
объект@метод или объект$поле.

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

Символ двоеточия : используется для создания списков и для обозначения логической связи между двумя частями слова/текста, в том числе для указания полного пути модуля.

Например, создание списка:

В_строку: элемент 1, элемент 2, последний элемент.
Форматированный_список:
- элемент 1;
- элемент 2;
- последний элемент.


Логическое следствие/указание связи:

module:calc //термин calc, который находится в модуле module
super:module:example$var //переменная $var которая находится в указанной иерархии.

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

О компьютерах


Так как речь идет все же о языке программирования, то не обойтись без стандартных алгоритмических конструкций: следования, ветвления и циклов.

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

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

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

перейти = @goto,
метка = @label,
продолжить = @continue,
прервать=@break и т.д.


И последний по очереди, но наверно самая важная по сути конструкция: передача параметров при вызовах функций. Если стремиться к полностью естественному синтаксису, тогда мы получим тот самый естественный язык, который очень сложно анализировать.

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

Компьютерный: функция(параметр1, функция2(), параметр3=значение).
Естественный: функция параметр1 функция2 параметр3=значение.


Но:

Компьютерный: функция( функция2(параметр) ).
Естественный: функция функция2(параметр).
Или так: функция (функция2 параметр).


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

О возражениях


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

Поэтому напомню про его обязательное свойство умение преобразовывать текст программы с одного языка на другой. Это позволяет писать программы как с использованием строго формального синтаксиса без использования переопеределенных терминов на естественном языке, так и преобразовывать исходный текст в естественный язык для не программиста.
Подробнее..

Проектируем мультипарадигменный язык программирования. Часть 5 Особенности логического программирования

08.01.2021 12:15:36 | Автор: admin
Продолжаем рассказ о создании мульти-парадигменного языка программирования, сочетающего декларативный логический стиль с объектно-ориентированным и функциональным, который был бы удобен при работе со слабоструктурированными данными и интеграции данных из разрозненных источников. Язык будет состоять из двух компонент, тесно интегрированных между собой: декларативная компонента будет ответственна за описание модели предметной области, а императивная или функциональная за описание алгоритмов работы с моделью и вычисления.

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

А сейчас я предлагаю окунуться в некоторые нюансы логического программирования. Поскольку язык компоненты моделирования имеет декларативную логическую форму, то придется решить такие проблемы, как определение семантики оператора отрицания, внедрение элементов логики высших порядков и добавление возможности работы с логическими переменными. А для этого придется разобраться с такими теоретическими вопросами как предположение об открытости/замкнутости мира, отрицание как отказ, семантикой стойких моделей (stable model semantics) и обоснованной семантикой (well-founded semantics). А также с тем, как реализованы возможности логики высших порядков в других языках логического программирования.

Начнем с логических переменных.


В большинстве языков логического программирования переменные используются как символическое обозначение (placeholder) произвольных высказываний. Они встречаются на позициях аргументов предикатов и связывают предикаты между собой. Например, в следующем правиле языка Prolog переменные играют роль объектов X и Y, связанных между собой отношениями: brother, parent, male и неравенством:
brothers(X,Y) :- parent(Z,X), parent(Z,Y), male(X), male(Y), X\=Y.
В компоненте моделирования роль аргументов термов в первую очередь играют атрибуты понятий:
concept brothers (person1, person2) FROM
parent p1 (child = person1),
parent p2 (child = person2),
male(person: person1),
male(person: person2)
WHERE p1.parent = p2.parent AND person1 != person2

К ним можно обращаться по имени напрямую, как в языке SQL. Хоть предлагаемый синтаксис и выглядит более громоздко по сравнению с Prolog, но в случае большого количества атрибутов такой вариант будет удобнее, так как он подчеркивает структуру объекта.

Но в некоторых случаях все-таки было бы удобно объявить логическую переменную, которая бы не входила в состав атрибутов ни одного из понятий, но в то же время использовалась в выражении отношений. Например, если подвыражение имеет сложный вид, то можно разбить его на составные части связав их с логическими переменными. Также если подвыражение используется несколько раз, то можно объявить его только один раз связав его с переменной. И в дальнейшем использовать переменную вместо выражения. Для того, чтобы отличить логические переменные от атрибутов понятия и переменных компоненты вычислений, примем решение, что имена логических переменных должны начинаться с символа $.
В качестве примера можно разобрать понятие, задающее принадлежность точки кольцу, которое описывается внешним и внутренним радиусами. Расстояние от точки до центра кольца можно рассчитать один раз, связать с переменной и сравнить ее с радиусами:
relation pointInRing between point p, ring r
where $dist <= r.rOuter
and $dist >= r.rInner
and $dist = Math.sqrt((p.x r.x) * (p.x r.x) + (p.y r.y) * (p.y r.y))

При этом само это расстояние несет вспомогательную роль и в состав понятия входить не будет.

Отрицание.


Теперь рассмотрим более сложный вопрос реализацию оператора отрицания в рамках компоненты моделирования. Системы логического программирования обычно включают кроме оператора булева отрицания еще и правило отрицания как отказа. Оно позволяет вывести not p в случае неудачи выведения p. В разных системах представления знаний как смысл, так и алгоритм правила вывода отрицания может отличаться.

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

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

Полные базы знаний имеют свои преимущества. Во-первых, нет необходимости кодировать неизвестную информацию достаточно двухзначной логики (истина, ложь) вместо трехзначной (истина, ложь, неизвестно). Во-вторых, можно объединить оператор булева отрицания и проверку выводимости высказывания из базы знаний в один оператор отрицания как отказ (negation as failure). Он вернет истину не только, если хранится утверждение о ложности высказывания, но также если в базе знаний нет о нем сведений вообще. Например, из
правила
p < not q
будет выведено, что q ложно (поскольку нет утверждения, что оно истинно), а p истинно.

К сожалению, семантика отрицания как отказа не так очевидна и сложнее, чем кажется. В разных системах логического программирования его смысл имеет свои особенности. Например, в случае циклических определений:
p not q
q not p

классическая SLDNF резолюция (SLD + Negation as Failure), применяемая в языке Prolog, не сможет завершиться. Вывод утверждения p нуждается в выводе q, а q в p, процедура вывода попадет в бесконечный цикл. В Prolog такие определения считаются не допустимыми, а база знаний не согласованной.
В то же время для нас эти утверждения не составляют проблемы. Интуитивно мы понимаем эти два правила как утверждение, что p и q имеют противоположные значения, если одно из них будет истинным, то второе ложным. Поэтому желательно, чтобы оператор отрицания как отказа умел работать с подобными правилами, чтобы конструкции логических программ были более естественными и понятными для человека.
Кроме того, согласованность базы знаний не всегда достижима. Например, иногда определения правил специально отделяют от фактов, чтобы один и тот же набор правил можно было бы применить к разным наборам фактов. В этом случае нет гарантии, что правила будут согласованы со всеми возможными наборами фактов. Также иногда допустима и несогласованность правил самих по себе, например, если они составляются разными экспертами.

Наиболее известными походами, позволяющими формализовать логический вывод в условиях циклических определений и несогласованности программы, являются Семантика устойчивых моделей (Stable model semantics) и Обоснованная семантика (Well-founded semantics).
Правило логического вывода с семантикой стойких моделей исходит из предположения, что некоторые операторы отрицания в программе можно проигнорировать, если они не согласуются с остальной частью программы. Поскольку таких согласованных подмножеств исходного набора правил может быть несколько, то, соответственно и вариантов решений может быть несколько. Например, в определении выше логический вывод можно начать с первого правила (p not q), отбросить второе (q not p) и получить решение {p, not q}. А затем проделать тоже и для второго и получить {q, not p}. Общим решением будет объединенный набор альтернативных решений. Например, из правил:
person(alex)
alive(X) person(X)
male(X) person(X) AND NOT female(X)
female(X) person(X) AND NOT male(X)

мы можем вывести два варианта ответа: {person(alex), alive(alex), male(alex)} и {person(alex), alive(alex), female(alex)}.
Обоснованная семантика исходит из тех же предположений, но стремится найти одно общее частичное решение, удовлетворяющее всем альтернативным согласованным подмножествам правил. Частичное решение означает, что значения истина или ложь будут выведены только для части фактов, а значения остальных останутся неизвестными. Таким образом, в описании фактов в программе используется двухзначная логика, а в процессе вывода трехзначная. Для рассмотренных выше правил значения обоих высказываний p и q будут неизвестны. Но, например, для
p not q
q not p
r s
s

можно с уверенностью вывести, что r и s истинны, хоть p и q остаются неизвестными.
Например, из примера с alex мы можем вывести {person(alex), alive(alex)}, в то время как утверждения male(alex) и female{alex} останутся неизвестными.

В языке SQL операторы булева отрицания (NOT) и проверки выводимости (NOT EXISTS) разделены. Эти операторы применяются к аргументам разного типа: NOT инвертирует булево значение, а EXISTS/NOT EXISTS проверяет результат выполнения вложенного запроса на пустоту, поэтому объединять их не имеет смысла. Семантика операторов отрицания в SQL очень проста и не рассчитана на работу с рекурсивными или сложными несогласованными запросами, при особой сноровке SQL запрос можно отправить в бесконечную рекурсию. Но сложные логические конструкции явно выходят за рамки традиционной сферы применения SQL, поэтому в изощренной семантике операторов отрицания он не нуждается.

Теперь попробуем разобраться с семантикой операторов отрицания компоненты моделирования проектируемого гибридного языка.
Во-первых, компонента моделирования предназначена для интеграции разрозненных источников данных. Они могут быть очень разнообразными и иметь как полный, так и неполный характер. Поэтому операторы проверки выводимости однозначно нужны.
Во-вторых, форма понятий компоненты моделирования гораздо ближе к запросам SQL, чем к правилам логического программирования. Понятие тоже имеет сложную структуру, поэтому смешение в одном операторе булева отрицания и проверки выводимости понятия не имеет смысла. Булево отрицание имеет смысл применять только к атрибутам, переменным и результатам вычисления выражений они могут быть как ложными, так и истинными. К понятию применить его сложнее, оно может состоять из разных атрибутов и не ясно, какой из них должен отвечать за ложность или истинность понятия целиком. Выводимым из исходных данных может быть понятие целиком, а не отдельные его атрибуты. В отличие от SQL, где структура таблиц фиксирована, структура понятий может быть гибкой, понятие может вообще не иметь требуемого атрибута в своем составе, поэтому понадобится еще и проверка существования атрибута.
Поэтому имеет смысл ввести отдельные операторы для каждого вида отрицаний, перечисленных выше. Ложность атрибутов можно проверить с помощью с помощью традиционного булева оператора NOT, содержит ли понятие атрибут с помощью встроенной функции DEFINED, а результат выведения понятия из исходных данных с помощью функции EXISTS. Три отдельных оператора более предсказуемы, понятны и просты в использовании, чем комплексный оператор отрицания как отказа. При необходимости их можно объединить в один оператор тем или иным способом, имеющим смысл для каждого конкретного случая.
В-третьих, на данный момент компонента моделирования видится инструментом для создания небольших онтологий прикладного уровня. Ее языку вряд ли потребуется особенная логическая выразительность и изощренные правила вывода, способные справиться с рекурсивными определениями и логической несогласованностью программы. Поэтому реализация сложных правил вывода на основе семантики стойких моделей или обоснованной семантики выглядит не целесообразной, по крайней мере на данном этапе. Классической SLDNF резолюции должно быть достаточно.

А теперь рассмотрим несколько примеров.
Понятию можно придать негативный смысл, если определенные его атрибуты имеют значение, указывающее на это. Отрицание атрибутов позволяет явным образом найти такие его сущности:
concept unfinishedTask is task t where not t.completed
Функция проверки неопределенности атрибута будет удобна, если сущности понятия могут иметь разную структуру:
concept unassignedTask is task t where not defined(t.assignedTo) or empty(t.assignedTo)
Функция проверки выводимости понятия незаменима при работе с рекурсивными определениями и иерархическими структурами:
concept minimalElement is element greater
where not exists(element lesser where greater.value > lesser.value)

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

Элементы логики высшего порядка.


В логике первого порядка переменные могут соответствовать только множествам объектов и появляться только на позициях аргументов предикатов. В логике высшего порядка они могут соответствовать также и множествам отношений и появляться на позиции имен предикатов. Другими словами, логика первого порядка позволяет сделать утверждение, что некое отношение верно для всех или некоторых объектов. А логика высшего порядка описать отношение между отношениями.
Например, мы можем сделать утверждения, что некоторые люди являются братьями, сестрами, детьми или родителями, дядями или тетями и т.п.:
Brother(John, Joe).
Son(John, Fred).
Uncle(John, Alex).

Но чтобы сделать утверждение о родственных отношениях, в логике первого порядка нам нужно перечислить все утверждения выше, объединив их с помощью операции OR:
X,Y(Brother(X, Y) OR Brother(Y, X) OR Son(X, Y) OR Son(Y, X) OR Uncle(X, Y) OR Uncle(Y, X) Relative(X, Y)).
Логика второго порядка позволяет сделать утверждение о других утверждениях. Например, можно было бы напрямую указать, что отношения между братьями, сестрами, родителями и детьми, дядями и племянниками являются родственными отношениями:
RelativeRel(Brother).
RelativeRel(Son).
RelativeRel(Uncle).
X,Y(R(RelativeRel(R) AND (R(X, Y) OR R(Y, X))) Relative(X, Y)).

Мы утверждаем, что если для каждого X и Y существует некое отношение R, которое является отношением между родственниками RelativeRel, и X и Y удовлетворяют этому отношению, то X и Y являются родственниками. Аргументами отношений могут быть другие отношения, и переменные могут быть подставлены на место имен отношений.
Логика третьего порядка позволяет строить высказывания о высказываниях о высказываниях, и так далее, логика высшего порядка о высказываниях любого уровня вложенности. Логика высшего порядка гораздо более выразительна, но и намного сложнее. На практике системы логического программирования поддерживают только некоторые ее элементы, которые в основном ограничиваются использованием переменных и произвольных выражений на позициях предикатов.

В языке Prolog элементы такой логики реализованы с помощью нескольких встроенных мета-предикатов, аргументами которых являются другие предикаты. Основным из них является предикат call, который позволяет динамически добавить предикаты в список целей текущего правила. Его первый аргумент трактуется как цель, а остальные как ее аргументы. Prolog найдет в базе знаний предикаты, соответствующие первому аргументу и добавит их в текущий список целей. Пример с родственниками будет выглядеть следующим образом:
brother(john, jack).
sister(mary, john).
relative_rel(brother).
relative_rel(sister).
relative(X, Y) :- relative_rel(R), (call(R, X, Y); call(R, Y, X)).

Также Prolog поддерживает предикаты findall(Template, Goal, Bag), bagof(Template, Goal, Bag), setof(Template, Goal, Set) и др., которые позволяют найти все решения цели Goal, соответствующие шаблону Template и унифицировать (связать) их список с результатом Bag (или Set). В Prolog есть встроенные предикаты current_predicate, clause и др. для поиска предикатов в базе знаний. Также можно манипулировать предикатами и их атрибутами в баз знаний добавлять, удалять и копировать их.

Язык HiLog поддерживает логику высшего порядка на уровне синтаксиса. Вместо специальных мета-предикатов он позволяет напрямую использовать произвольные термы (например, переменные) на позиции имен предикатов. Правило для определения родственников примет вид:
relative(X, Y) :- relative_rel(R), (R(X, Y); R(Y, X)).
Такой синтаксис более декларативен, краток, понятен и естественен по сравнению с Prolog. В то же время HiLog остается синтаксическим вариантом Prolog, так как все синтаксические конструкции HiLog могут быть преобразованы выражения логики первого порядка с использованием мета-предикатов call.
Считается, что HiLog обладает синтаксисом высшего порядка, но семантикой первого порядка. Это значит, что при сравнении переменных, представляющих правила или функции, учитываются только их имена, но не реализация. Существуют также языки, поддерживающие семантику высшего порядка, например -Prolog, которые позволяют вовлечь в процесс логического вывода также и реализацию правил и функций. Но такая логика и ее алгоритмы вывода значительно сложнее.

Теперь перейдем к функционалу логики высшего порядка компоненты моделирования. Для большинства практических задач, связанных с мета-программированием, должно быть достаточно возможностей Prolog и HiLog. HiLog обладает более естественным синтаксисом, поэтому именно его имеет смысл взять за основу. Чтобы можно было использовать произвольные выражения на позициях имен понятий и их атрибутов и отличать их от перемменных, вызовов функций и других конструкций введем специальный оператор динамического указания имен:
< выражение >
Он позволяет вычислить значение выражения и использовать его как имя понятия, его псевдоним или имя атрибута в зависимости от контекста. Если этот оператор стоит на месте имени понятия в секции FROM и значение его выражения определено, то будут найдены все понятия с указанным именем и для них выполнен логический поиск:
concept someConcept ( ) from conceptA a, <a.conceptName> b where
Если значение выражения не определено, например, выражение представляет собой логическую переменную, не связанную со значением, то процедура найдет все подходящие понятия и свяжет значение переменной с их именами:
concept someConcept is <$conceptName> where
Можно сказать, что в контексте секции FROM оператор указания имени имеет логическую семантику.
Также оператор < > можно использовать и секции WHERE на позиции псевдонима понятия или имени атрибута:
concept someConcept ( ) from conceptA a, conceptB b where conceptB.<a.foreignKey> = a.value ...
Выражения в секции WHERE являются детерминированными, то есть они не задействуют логический поиск для нахождения неизвестных значений своих аргументов. Это значит, что выражение conceptB.<a.foreignKey> = a.value будет вычислено только после того, как будут найдены сущности понятия a, и его атрибуты foreignKey и value связаны со значениями. Поэтому можно сказать, что в контексте секции FROM оператор указания имени имеет функциональную семантику.

Рассмотрим некоторые возможные варианты применения логики высшего порядка.
Самый очевидный примером, где будет удобна логика высшего порядка, является объединение под одним именем всех понятий, удовлетворяющих некоторым условиям. Например, имеющих определенные атрибуты. Так понятием point можно считать все понятия, в состав которых входят координаты x и y:
concept point is <$anyConcept> a where defined(a.x) and defined(a.y)
Логический поиск свяжет переменную $anyConcept со всеми объявленными именами понятий (естественно, за исключением самого себя), которые обладают атрибутами координат.

Более сложным примером будет объявление общего отношения, применимого ко многим понятиям. Например, транзитивного отношения родитель-потомок между понятиями:
relation ParentRel between <$conceptName> parent, <$conceptName> child
where defined(parent.id) and defined(child.parent) and (
parent.id = child.parent or exists(
<$conceptName> intermediate where intermediate.parent = parent.id
and ParentRel(intermediate, child)
))

Переменная $conceptName используется во всех трех понятиях родителя, потомка и промежуточного объекта, что означает, что их имена должны совпадать.
Логика высшего порядка открывает возможности для обобщенного (generic) программирования в том смысле, что можно создать обобщенные понятия и отношения, которые можно применить к множеству понятий, удовлетворяющих заданным условиям, не привязываясь к их конкретным именам.

Также динамическая подстановка имен будет удобна в тех случаях, когда атрибуты одного понятия являются ссылками на имена других понятий или их атрибутов, или когда исходные данные содержат не только факты, но и их структуру. Например, исходные данные могут включать описание схем XML документов или таблиц в базе данных. Исходные данные также могут включать дополнительную информацию о фактах, например, типы данных, форматы или значения по умолчанию, условия валидации или некие правила. Также исходные данные могут описывать модель чего-либо, а компонента моделирования будет ответственна за построение метамодели. Работа с текстами на естественном языке также предполагает, что исходные данные будут включать не только высказывания, но и высказывания о высказываниях. Во всех этих случаях логики первого порядка будет недостаточно и необходим более выразительный язык.
В качестве простого примера рассмотрим случай, когда данные включают в себя некие объекты, а также правила валидации атрибутов этих объектов в виде отдельной сущности:
fact validationRule {objectName: someObject, attributeName: someAttribute, rule: function(value) {...}}
Результаты валидации можно описать следующим понятием:
concept validationRuleCheck (
objectName = r.objectName,
attributeName = r.attrName,
result = r.rule(o.<r.attrName>)
) from validationRule r, <r.objectName> o
where defined(o.<r.attrName>)


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

Выводы.


В процессе работы над компонентой моделирования пришлось разобраться с довольно специфичными вопросами логического программирования, такими как работа с логическими переменными, семантикой оператора отрицания и элементами логики высшего порядка. Если с переменными все оказалось довольно просто, то в вопросах реализации оператора отрицания и логики высшего порядка единого устоявшегося подхода нет, и существует несколько решений, имеющих свои особенности, достоинства и недостатки.
Я постарался выбрать такое решение, которое было бы простым для понимания и удобным на практике. Монолитный оператор отрицания как отказа я предпочел разбить на три отдельных оператора булева отрицания, проверки выводимости понятия и существования атрибута у объекта. При необходимости эти три оператора можно скомбинировать и получить семантику отрицания, необходимую для каждого конкретного случая. Для правила вывода отрицания я решил взять за основу стандартную SLDNF резолюцию. Хоть она и не способна справиться с несогласованными рекурсивными высказываниями, но она гораздо проще в понимании и реализации, чем более изощренные альтернативы, такие как семантика стойких моделей или обоснованная семантика.
Логика высшего порядка понадобится для обобщенного и мета-программирования. Под обобщенным программированием я подразумеваю возможность строить новые понятия на основе широкого множества дочерних понятий, не привязываясь к конкретным именам последних. Под мета-программированием я подразумеваю возможность описывать структуру одних понятий с помощью других понятий. В качестве образца для элементов логики высшего порядка компоненты моделирования я решил взять язык HiLog. Он обладает гибким и удобным синтаксисом, позволяющим использовать переменные на позициях имен предикатов, а также простой и понятной семантикой.

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

Полный текст в научном стиле на английском языке доступен по ссылке: papers.ssrn.com/sol3/papers.cfm?abstract_id=3555711

Ссылки на предыдущие публикации:
Проектируем мультипарадигменный язык программирования. Часть 1 Для чего он нужен?
Проектируем мультипарадигменный язык программирования. Часть 2 Сравнение построения моделей в PL/SQL, LINQ и GraphQL
Проектируем мультипарадигменный язык программирования. Часть 3 Обзор языков представления знаний
Проектируем мультипарадигменный язык программирования. Часть 4 Основные конструкции языка моделирования
Подробнее..

Проектируем мультипарадигменный язык программирования. Часть 6 Заимствования из SQL

27.01.2021 14:17:26 | Автор: admin
Продолжаем рассказ о создании мультипарадигменного языка программирования, сочетающего декларативный логический стиль с объектно-ориентированным и функциональным, который был бы удобен при работе со слабоструктурированными данными и интеграции данных из разрозненных источников. Язык будет состоять из двух компонент, тесно интегрированных между собой: декларативная компонента будет ответственна за описание модели предметной области, а императивная или функциональная за описание алгоритмов работы с моделью и вычисления.

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

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

Анонимные определения понятий


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

Иногда нужно немного модифицировать понятие, выбрать отдельные его атрибуты, отфильтровать значения. Если эта модификация нужна только в одном месте, то тогда создавать отдельное понятие с уникальным именем не имеет смысла. Такая ситуация часто встречается, когда понятия являются аргументами функций, например, таких как exists, find или findOne, выполняющих проверку выводимости понятия, нахождения всех или только первого объекта (сущности) понятия. Здесь можно провести аналогию с анонимными функциями в функциональных языках программирования, которые часто применяются в качестве аргументов таких функций как map, find, filter и др.

Рассмотрим синтаксис определения анонимного понятия. В целом он соответствует синтаксису определения обычного понятия за исключением того, что в некоторых случаях можно опустить списки атрибутов и имя дочернего понятия. Если анонимное понятие используется как аргумент функции exists, то его имя и список атрибутов не важны, достаточно проверить, что есть хоть какой-то результат. В функциях find и findOne может не понадобиться имя понятия, если результат вывода используется не как цельное понятие, а только как набор атрибутов в ассоциативном массиве. Если атрибуты не указаны, то по умолчанию применяется механизм наследования и атрибуты будут унаследованы у родительских понятий. Если не указано имя понятия, то оно будет сгенерировано автоматически.

Попробуем пояснить выше написанное с помощью нескольких примеров. С помощью функции exists можно проверить выводимость или не выводимость вложенного понятия:

concept freeExecutor is executor e where not exists (task t where t.executor = e.id and t.status in ('assigned', 'in process'))

В данном примере анонимное понятие:

(task t where t.executor = e.id and t.status in ('assigned', 'in process'))

на самом деле представляет собой понятие, наследующее все атрибуты понятия task:

(concept _unanimous_task_1 as task t where t.executor = e.id and t.status in ('assigned', 'in process'))

Функция find позволяет вернуть в виде списка все значения понятия, которые затем могут быть связаны с атрибутом:

concept customerOrdersThisYear is customer c with orders where c.orders = find((id = o.id, status = o.status, createdDate = o.createdDate, total = o.total) from order o where o.customerId = c.id and o.createdDate > '2021-01-01')

В данном примере мы расширяем понятие customer списком заказов, которые представляют собой объекты, содержащие выбранные атрибуты понятия order. Мы указали список атрибутов анонимного понятия, а его имя пропущено.

Условия в секции where анонимного понятия могут включать атрибуты других родительских или дочернего понятий, в данном случае это c.id. Особенностью анонимных понятий является то, что все подобные внешние переменные и атрибуты должны быть обязательно связаны со значениями на момент запуска поиска решений. Таким образом объекты анонимного понятия могут быть найдены только после нахождения объектов понятия customer.

Внешние соединения


Анонимные определения понятий можно использовать и в секции from, где они будут представлять родительские понятия. Более того, в определение анонимного понятия можно перенести часть условий, связывающих его с другими понятиями, что будет иметь особый эффект. Эти условия будут проверены на этапе поиска решения анонимного понятия и не будут влиять на процесс логического вывода дочернего понятия. Здесь можно провести аналогию между условиями в секции where анонимного понятия и условиями в секции JOIN ON языка SQL.

Таким образом, анонимные понятий могут быть использованы для реализации аналога внешних соединений (left outer join) языка SQL. Для этого понадобится три вещи.

  1. Во-первых, заменить нужное родительское понятие анонимным понятием на его основе и перенести в него все связи с остальными родительскими понятиями.
  2. Во-вторых, указать, что неудача вывода этого понятия не должна приводить к автоматической неудаче вывода всего дочернего понятия. Для этого нужно пометить это родительское понятие с помощью ключевого слова optional.
  3. А в-третьих, в секции where дочернего понятия можно проверить, существуют ли решения данного анонимного понятия.

Разберем небольшой пример:

concept taskAssignedTo (task = t, assignee = u, assigneeName) from task t, optional (user where id = t.assignedTo) u where assigneeName = if(defined(u), u.firstName + ' ' + u.lastName, 'Unassigned') 

Атрибуты понятия taskAssignedTo включают в себя объекты задачи, ее исполнителя и отдельно имя исполнителя. Родительскими понятиями являются task и user, причем значение последнего может быть пустым, если задача еще не имеет исполнителя. Оно обвернуто в определение анонимного понятия, перед которым стоит ключевое слово optional. Процедура логического вывода сначала найдет объекты понятия task, затем на основе user создаст анонимное понятие, связав его с конкретным значением атрибута assignedTo понятия task. Ключевое слово optional указывает процедуре вывода, что в случае неудачи вывода этого понятия, его объект будет связан со специальным значением UNDEFINED. А проверка результата его вывода на уровне дочернего понятия позволяет атрибуту assigneeName задать значение по умолчанию. Если ключевое слово optional не было бы указано, то неудача вывода анонимного понятия привела бы к неудаче текущей ветви поиска дочернего понятия. И такой вариант был бы аналогичен внутреннему объединению (inner join) языка SQL.

Поскольку условия в секции where анонимного понятия включают атрибут assignedTo другого родительского понятия task, то поиск объектов понятия user возможен только после связывания объектов task со значениями. Их нельзя поменять местами:

from optional (user where id = t.assignedTo) u, task t 

Поскольку на начальном этапе значение t.assignedTo будет неизвестным, то создать определение анонимного понятия не получится.

Если в SQL порядок таблиц в секции from не имеет значения, то в Prolog порядок предикатов в правиле однозначно определяет последовательность обхода дерева решений. То же можно сказать и о компоненте моделирования, правило вывода которой основано на SLD резолюции, используемой в Prolog. В ней результат вывода объектов левого понятия определяет ограничения для вывода объектов правого. Из-за этого, к сожалению, не получится реализовать операции right outer join и full outer join таким же естественным образом. Поскольку мощность множества результатов правого родительского понятия может быть больше, чем левого, то в них потребуется вывод в противоположном направлении от правого понятия к левому. К сожалению, особенности выбранной процедуры логического вывода накладывают свои ограничения на функциональность языка. Но операцию full outer join можно сэмулировать соединив внутреннее, левое и правое объединения:

concept outerJoinRelation( concept1Name, concept2Name, concept1Key,concept2Key,concept1 = c1,concept2 = c2) from <concept1Name> c1, <concept2Name> c2where c1.<concept1Key> = c2.<concept2Key>;concept outerJoinRelation(concept1Name, concept2Name, concept1Key,concept2Key,concept1 = c1,concept2 = null) from <concept1Name> c1where not exists( <concept2Name> c2 where c1.<concept1Key> = c2.<concept2Key>);concept outerJoinRelation(concept1Name, concept2Name, concept1Key,concept2Key,concept1 = null,concept2 = c2) from <concept2Name> c2where not exists( <concept1Name> c1 where c1.<concept1Key> = c2.<concept2Key>);

Данное обобщенное понятие описано с помощью логики высшего порядка, описанной в предыдущей статье. Его определение разбито на три части. Первая найдет пересечения понятий, вторая объекты, которые есть у левого понятия и нет у левого, а третье наоборот. Поскольку имена каждой части совпадают, то результаты их логического вывода будут объединены.

Агрегирование


Агрегирование является неотъемлемой частью как реляционной алгебры, так и логического программирования. В языке SQL секция GROUP BY позволяет сгруппировать строки, имеющие одинаковые ключевые значения, в итоговые строки. Она позволяет удалить повторяющиеся значения и обычно используется с агрегатными функциями, такими как sum, count, min, max, avg. Для каждой группы строк агрегатные функции возвращают ординарное значение, рассчитанное на основе всех строк этой группы. В логическом программировании агрегирование имеет более сложную семантику. Это связано с тем, что в некоторых случаях рекурсивного определения правил SLD резолюция попадает в бесконечный цикл и не способна завершиться. Как и в случае отрицания как отказа проблему рекурсии в операции агрегации решают с помощью семантики стойких моделей или хорошо обоснованной семантики. Об этих подходах я попытался кратко рассказать в предыдущей статье. Но поскольку семантика компоненты моделирования должна быть как можно проще, то стандартная SLD резолюция более предпочтительна. А проблему избегания бесконечной рекурсии лучше решить путем переформирования связей между понятиями.

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

concept <имя понятия> <псевдоним понятия> (<имя атрибута> = <выражение>,... )group by <имя атрибута>, ... from <имя родительского понятия> <псевдоним родительского понятия> (<имя атрибута> = <выражение> ,...),...where <выражение отношений>

Секция group by, так же, как и в SQL, содержит список атрибутов, по которым выполняется группировка. Выражение отношений также может включать функции агрегации. Выражения, содержащие такие функции будут считаться неопределенными, пока не будут найдены значения всех родительских понятий и выполнена группировка. После этого их значения могут быть вычислены для каждой группы, связаны с атрибутами и/или использованы для фильтрации групп. При таком отложенном подходе к вычислениям и проверке условий нет необходимости в секции HAVING, отделяющей условия фильтрации до и после группировки. Среда исполнения сделает это автоматически.

Основными функциями агрегации являются count, sum, avg, min, max. Назначение функций можно понять из их названия. Поскольку компонента моделирования умеет естественным образом работать c составными типами данных, то также можно добавить функцию, возвращающую сгруппированные значения в виде списка. Назовем ее group. Ее входным аргументом является выражение. Функция возвращает список результатов вычисления этого выражения для каждого элемента группы. Комбинируя ее с другими функциями можно реализовать любую произвольную функцию агрегации. Функция group будет удобнее, чем такие SQL функции как group_concat или json_arrayag, которые часто используются в качестве промежуточного шага для получения массива значений поля.

Пример группировки:

concept totalOrders (customer = c,orders = group(o),ordersTotal = sum(o.total)) group by customerfrom customer c, order o where c.id = o.customerId and ordersTotal > 100

Атрибут orders будет содержать список всех заказов пользователя, ordersTotal общую сумму всех заказов. Условие ordersTotal > 100 будет проверено уже после выполнения группировки и вычисления функции sum.

Понятие, определенное с помощью функции


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

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

concept <имя понятия> (<имя атрибута>, ... )by <функция генерации объектов>

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

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

Результатом вычисления функции должен быть список объектов понятия. Но, поскольку процедура логического вывода, основанная на поиске с возвратом, будет потреблять эти значения по одному, то можно выходным аргументом функции сделать не сам список, а итератор к нему. Это сделало бы определение понятия более гибким, например, позволило бы при необходимости реализовать ленивые вычисления или бесконечную последовательность объектов. Можно использовать итератор любой стандартной коллекции либо создать свою произвольную реализацию. Элементом коллекции должен быть ассоциативный массив со значениями атрибутов понятия. Сущности понятия будут созданы на их основе автоматически.
Вариант с использование итератора в качестве типа возвращаемого значения имеет свои недостатки. Он более громоздкий и менее удобный по сравнению с простым возвратом списка результатов. Поиск оптимального варианта, сочетающего универсальность, простоту и удобство работы это задача на будущее.

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

concept timeSlot15min (id, hour, minute) by function(query, mode) {var timeSlots = [];var curId = 1;for(var curHour = 8; curHour < 19; curHour += 1) {for(var curMinute = 0; curMinute < 60; curMinute += 15) {timeSlots.push({id: curId,hour: curHour,minute: curMinute;});curId++;}}return timeSlots.iterator();}

Функция возвращает итератор для всех возможных значений 15-и минутного интервала времени за рабочий день. Ее можно использовать, например, для поиска свободных временных интервалов, которые еще не забронированы:

concept freeTimeSlot is timeSlot15min s where not exists (bookedSlot b where b.id = s.id)

Функция не проверяет результат вычислений на соответствие запросу query, это будет сделано автоматически при преобразовании массива атрибутов в сущности. Но при необходимости поля запроса можно использовать для оптимизации функции. Например, сформировать запрос к базе данных на основе полей запроса к понятию.

Понятие через функцию соединяет в себе логическую и функциональную семантики. Если в функциональной парадигме функция вычисляет результат для заданных значений входных аргументов, то в логической парадигме нет разделения на выходные и входные аргументы. Могут быть заданы значения только части аргументов, причем в любой комбинации, и функции необходимо найти значения оставшихся аргументов. На практике реализовать такую функцию, способную выполнять вычисления в любом направлении, не всегда возможно, поэтому имеет смысл ограничить возможные комбинации свободных аргументов. Например, объявить, что некоторые аргументы обязательно должны быть связаны со значениями перед вычислением функции. Для этого пометим такие атрибуты в определении понятия ключевым словом required.

В качестве примера рассмотрим понятие, определяющее значения некой экспоненциальной шкалы.

concept expScale (value, position, required limit) by function(query, mode) {return {_curPos = 0,_curValue = 1,next: function() {if(!this.hasNext()) {return null;}var curItem = {value: this._curValue, position: this._curPosition, limit:  query.limit};this._curPos += 1;this._curValue = this._curValue * Math.E;return curItem;},hasNext: function() {return query.limit == 0 || this._curPos < query.limit; }}}

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

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

Развертывание вложенных коллекций (Flattening nested collections)


Некоторые диалекты SQL, умеющие работать с данными в объектной форме, поддерживают такую операцию как UNNEST, которая преобразует содержимое коллекции в табличный формат (набор строк) и добавляет получившуюся таблицу в секцию FROM. Обычно она используется, чтобы объекты со вложенными структурами сделать плоскими, другими словами, развернуть или сгладить (flatten) их. Примерами таких языков являются BigQuery и SQL++.

Предположим, мы храним информацию о пользователях в виде JSON объекта:

[ {"id":1,"alias":"Margarita","name":"MargaritaStoddard","nickname":"Mags","userSince":"2012-08-20T10:10:00","friendIds":[2,3,6,10],"employment":[{"organizationName":"Codetechno","start-date":"2006-08-06"},{"organizationName":"geomedia","start-date":"2010-06-17","end-date":"2010-01-26"}],"gender":"F"},{"id":2,"alias":"Isbel","name":"IsbelDull","nickname":"Izzy","userSince":"2011-01-22T10:10:00","friendIds":[1,4],"employment":[{"organizationName":"Hexviafind","startDate":"2010-04-27"}]}, ]

Объекты пользователей хранят в себе вложенные коллекции со списками друзей и местами работы. Извлечь вложенную информацию о местах работы пользователя склеив ее с данными о пользователе, взятыми из верхнего уровня объекта, можно с помощью запроса на SQL++:

SELECT u.id AS userId, u.name AS userName, e.organizationName AS orgNameFROM Users u UNNEST u.employment eWHERE u.id = 1;

Результатом будет:

[ {"userId": 1,"userName": "MargaritaStoddard","orgName": "Codetechno"}, {"userId": 1,"userName": "MargaritaStoddard","orgName": "geomedia"} ]

Более подробно эта операция рассмотрена здесь.

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

Поскольку полное определение понятия через функцию слишком громоздко для использования в качестве анонимного понятия:

concept conceptName(attribute1, attribute2, ...) by function(query, mode) {...}

нужно найти способ его сократить. Во-первых, можно избавиться от заголовка определения функции с параметрами query и mode. На позиции родительского понятия аргумент mode всегда будет равен найти все значения понятия. Аргумент query всегда будет пуст, так как зависимости от атрибутов других понятий можно встроить в тело функции. Ключевое слово concept тоже можно выкинуть. Таким образом получаем:

conceptName(attribute1, attribute2, ...) {}

Если имя понятия не важно, то его можно опустить, и оно будет сгенерировано автоматически:

(attribute1, attribute2, ...) {}

Если в будущем удастся создать компилятор, который сможет вывести список атрибутов из типа объектов, возвращаемых функцией, то и список атрибутов можно будет откинуть:

{}


Итак, пример с пользователями и их местами работы в виде понятия будет выглядеть следующим образом:

concept userEmployments (userId = u.id,userName = u.name,orgName = e.orgName) from users u, {u.employment.map((item) => {orgName: item.organizationName}).iterator()} e

Решение получилось немного многословным, но зато универсальным. В то же время, если никакого преобразования объектов вложенной коллекции не требуется, то его можно заметно упростить:

concept userEmployments (userId = u.id,userName = u.name,orgName = e. organizationName) from users u, {u.employment.iterator()} e

Выводы


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

Анонимное понятие это сокращенная форма определения понятия, предназначенная однократного для использования в качестве аргументов функций (find, findOne и exists) или в качестве вложенного определения понятия в секции where. Его можно рассматривать как аналог анонимных определений функций в языках функционального программирования.

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

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

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

Полный текст в научном стиле на английском языке доступен по ссылке: papers.ssrn.com/sol3/papers.cfm?abstract_id=3555711

Ссылки на предыдущие публикации:

Проектируем мультипарадигменный язык программирования. Часть 1 Для чего он нужен?
Проектируем мультипарадигменный язык программирования. Часть 2 Сравнение построения моделей в PL/SQL, LINQ и GraphQL
Проектируем мультипарадигменный язык программирования. Часть 3 Обзор языков представления знаний
Проектируем мультипарадигменный язык программирования. Часть 4 Основные конструкции языка моделирования
Проектируем мультипарадигменный язык программирования. Часть 5 Особенности логического программирования
Подробнее..

Маленький и быстрый BERT для русского языка

10.06.2021 02:22:28 | Автор: admin

BERT нейросеть, способная весьма неплохо понимать смысл текстов на человеческом языке. Впервые появивишись в 2018 году, эта модель совершила переворот в компьютерной лингвистике. Базовая версия модели долго предобучается, читая миллионы текстов и постепенно осваивая язык, а потом её можно дообучить на собственной прикладной задаче, например, классификации комментариев или выделении в тексте имён, названий и адресов. Стандартная версия BERT довольно большая: весит больше 600 мегабайт, обрабатывает предложение около 120 миллисекунд (на CPU). В этом посте я предлагаю уменьшенную версию BERT для русского языка 45 мегабайт, 6 мс на предложение. Уже есть tinybert для английского от Хуавея, есть моя уменьшалка FastText'а, а вот маленький (англо-)русский BERT, кажется, появился впервые. Но насколько он хорош?

Дистилляция путь к маленькости

Чтобы создать маленький BERT, я решил обучить свою нейросеть, используя при этом уже готовые модели в качестве учителей. Сейчас объясню подробнее.

Если очень коротко, то BERT работает так: сначала токенизатор разбивает текст на токены (кусочки размером от одной буквы до целого слова), от них берутся эмбеддинги из таблицы, и эти эмбеддинги несколько раз обновляются, используя механизм self-attention для учёта контекста (соседних токенов). При предобучении классический BERT выполняет две задачи: угадывает, какие токены в предложении были заменены на специальный токен [MASK], и шли ли два предложения следом друг за другом в тексте. Как потом показали, вторая задача не очень нужна. Но токен [CLS], который ставится перед началом текста и эмбеддинг которого использовался для этой второй задаче, употреблять продолжают, и я тоже сделал на него ставку.

Дистилляция способ перекладывания знаний из одной модели в другую. Это быстрее, чем учить модель только на текстах. Например, в тексте [CLS] Ехал Грека [MASK] реку "верное" решение поставить на место маски токен через, но большая модель знает, что токены на, в, за в этом контексте тоже уместны, и это знание полезно для обучения маленькой модели. Его можно передать, заставляя маленькую модель не только предсказывать высокую вероятность правильного токена через, а воспроизводить всё вероятностное распределение возможных замаскированных токенов в данном тексте.

В качестве основы для модели я взял классический bert-multilingual (веса), ибо хочу, чтобы модель понимала и русский, и английский, и его же использую на ранних стадиях дистилляции как учителя по распределению токенов. Словарь этой модели содержит 120К токенов, но я отобрал только те, которые часто встречаются в русском и английском языках, оставив 30К. Размер эмбеддинга я сократил с 768 до 312, число слоёв с 12 до 3. Эмбеддинги я инициализировал из bert-multilingual, все остальные веса случайным образом.

Поскольку я собираюсь использовать маленький BERT в первую очередь для классификации коротких текстов, мне надо, чтобы он мог построить хорошее векторное представление предложения. Поэтому в качестве учителей для дистилляции я выбрал модели, которые с этим здорово справляются: RuBERT (статья, веса), LaBSE (статья, веса), Laser (статья, пакет) и USE (статья, код). А именно, я требую, чтобы [CLS] эмбеддинг моей модели позволял предсказать эмбеддинги предложений, полученные из этих трёх моделей. Дополнительно я обучаю модель на задачу translation ranking (как LaBSE). Наконец, я решил, что неплохо было бы уметь полностью расшифровывать предложение назад из CLS-эмбеддингов, причём делать это одинаково для русских и английских предложений как в Laser. Для этих целей я примотал изолентой к своей модели декодер от уменьшенного русского T5. Таким образом, у меня получилась многозадачная модель о восьми лоссах:

  • Обычное предсказание замаскированных токенов (я использую full word masks).

  • Translation ranking по рецепту LaBSE: эмбеддинг фразы на русском должен быть ближе к эмбеддингу её перевода на английский, чем к эмбеддингу остальных примеров в батче. Пробовал добавлять наивные hard negatives, но заметной пользы они не дали.

  • Дистилляция распределения всех токенов из bert-base-multilingual-cased (через несколько эпох я отключил её, т.к. она начала мешать).

  • Приближение CLS-эмбеддингов (после линейной проекции) к эмбеддингам DeepPavlov/rubert-base-cased-sentence (усреднённым по токенам).

  • Приближение CLS-эмбеддингов (после другой линейной проекции) к CLS-эмбеддингам LaBSE.

  • Приближение CLS-эмбеддингов (после третьей проекции) к эмбеддингам LASER.

  • Приближение CLS-эмбеддингов (после ещё одной проекции) к эмбеддингам USE.

  • Расшифровка декодером от T5 предложения (на русском) из последней проекции CLS-эмбеддинга.

Скорее всего, из этих лоссов больше половины можно было безболезненно выкинуть, но ресурсов на ablation study я пока не нашёл. Обучал я это всё в течении нескольких дней на Colab, по пути нащупывая learning rate и другие параметры. В общем, не очень научно, но дешево и результативно. В качестве обучающей выборки я взял три параллельных корпуса англо-русских предложений: от Яндекс.Переводчика, OPUS-100 и Tatoeba, суммарно 2.5 млн коротких текстов. Весь процесс создания модели, включая некоторые неудачные эксперименты, содержится в блокноте. Сама модель, названная мною rubert-tiny (или просто Энкодечка), выложена в репозитории Huggingface.

И как этим пользоваться?

Если у вас есть Python и установлены пакет transformers и sentencepiece, скачать и запустить модель просто. Например, вот так вы можете получить 312-мерный CLS-эмбеддинг предложения.

Этот эмбеддинг вы можете использовать как признак для любой модели классификации или кластеризации текстов. Как (рекомендуемый) вариант, вы можете дообучить мою модель на собственной задаче. Про это будет отдельный пост, а пока отсылаю вас к обучающи материалам от Huggingface (раз, два).

Насколько быстр и мал мой Энкодечка? Я сравил его с другими BERT'ами, понимающими русский язык. Скорость указана в расчёте на одно предложение из Лейпцигского веб-корпуса русского языка.

Модель

Скорость (CPU)

Скорость (GPU)

Вес на диске

cointegrated/rubert-tiny

6 мс

3 мс

45 мб

bert-base-multilingual-cased

125 мс

8 мс

680 мб

DeepPavlov/rubert-base-cased-sentence

110 мс

8 мс

680 мб

sentence-transformers/LaBSE

120 мс

8 мс

1.8 гб

sberbank-ai/sbert_large_nlu_ru

420 мс

16 мс

1.6 гб

Все расчёты я выполнял на Colab (Intel(R) Xeon(R) CPU @ 2.00GHz и Tesla P100-PCIE c батчом размера 1 (если использовать крупные батчи, то ускорение на GPU ещё заметнее, т.к. с маленькой моделью можно собрать более большой батч).

Как видим, rubert-tiny на CPU работает раз в 20 быстрее своих ближайших соседей, и легко помещается на бюджетные хостинги типа Heroku (и даже, наверное, на мобильные устройства). Надеюсь, эта модель сделает предобученные нейросети для русского языка в целом более доступными для прикладных применений. Но надо ещё убедиться, что модель хоть чему-то научилась.

Оценка качества эмбеддингов

Рекомендованный и проверенный временем рецепт использования BERT дообучать его на конечную задачу. Но дообучение процесс небыстрый и наукоёмкий, а гипотезу об осмысленности выученных эмбеддингов хочется проверить побыстрее и попроще. Поэтому я не дообучаю модели, а использую их как готовые feature extractors, и обучаю поверх их эмбеддингов простые модели логистическую регрессию и KNN.

Для оценки русских моделей есть бенчмарк RussianSuperGLUE, но задачи там сложные, требующие подбора параметров и дообучения моделей, так что к нему я тоже перейду позже. Ещё есть бенчмарк RuSentEval, там задачи более простые, но они слишком абстрактные, ориентированные больше на лингвистические свойства, а хочется начать с чего-то прикладного. Поэтому я собрал свой маленький бенчмарк. Пока что он тоже живёт в блокноте, но надо будет допилить его и выложить в более удобном виде. И вот какие задачи туда вошли:

STS: бенчмарк по семантической близости предложений (переведённый с английского). Например, фразы "Кошка спит на фиолетовой простыне" и "Черно-белый кот спит на фиолетовом одеяле" из этого датасета оценены на 4 из 5 баллов сходства. Качество моделей на нём я мерял ранговой корреляций этих баллов с косинусной близостью эмбеддингов предложений. Для наилучшей модели, LaBSE, корреляция оказалась 77%, для моей 65%, на одном уровне с моделью от Сбера, которая в 40 раз больше моей.

Paraphraser: похожий бенчмарк по семантической близости, но с чисто русскими новостными заголовками и трёхбалльной шкалой. Эту задачу я решил так: обучил поверх косинусных близостей логистическую регрессию, и ей предсказывал, к какому из трёх классов пара заголовков относится. На этом бенчмарке моя модель выдала точность 43% и победила все остальные (впрочем, с небольшим отрывом).

XNLI: предсказание, следует ли одно предложение из другого. Например, из "это стреляющее пластиковое автоматическое оружие" не следует "это более надежно, чем металлическое оружие", но и не противоречит. Оценивал её я как предыдущую логрегом поверх косинусных близостей. Тут на первом месте оказалась модель от DeepPavlov (которая дообучалась ровно на этой задаче), а моя заняла второе.

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

OKMLCup: детекция токсичных комментариев из Одноклассников. Тут моя модель заняла четвёртое место по ROC AUC, обогнав только bert-base-cased-multilingual.

Inappropriateness: детекция сообщений, неприятных для собеседника или вредящих репутации. Тут моя модель оказалась на последнем месте, но таки набрала 68% AUC (у самой лучшей, Сберовской, вышло 79%).

Классификация интентов: накраудсоршенные обращения к голосовому помощнику, покрывающие 18 доменов и 68 интентов. Они собирались на английском языке, но я перевёл их на русский простой моделькой. Часть переводов получились странными, но для бенчмарка сойдёт. Оценивал я по точности логистической регрессии или KNN (что лучше). LaBSE набрала точность 75%, модель от Сбера 68%, от DeepPavlov 60%, моя 58%, мультиязычная 56%. Есть, куда расти.

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

factRuEval-2016: задача распознавания классических именованных сущностей (адреса, организации, личности). Я обучал логистическую регрессию поверх эмбеддингов токенов, а качество мерял макро F1 скором (относительно токенов же, что не вполне корректно). Оказалось, что на таком NER моя модель работает откровенно плохо: она набрала скор 43%, остальные 67-69%.

RuDReC: распознавание медицинских именованных сущностей. Тут моя модель тоже проиграла остальным, но с меньшим отрывом: 58% против 62-67%.

Для всех задач, кроме NER, я пробовал для каждой модели два вида эмбеддингов: из CLS токена и усреднённые по всем токенам. Для меня было неожиданностью, что на многих задачах и моделях эмбеддинг СLS-токена оказывался даже лучше, чем средний (в целом, у него так себе репутация). Поэтому рекомендую не лениться и пробовать оба варианта. Код и результаты моей оценки можно взять из этого блокнота, но лучше подождать, пока я ещё причешу этот бенчмарк.

По итогам оценки оказалось, что модель LaBSE очень крутая: она заняла первое место на 6 из 10 задач. Поэтому я решил выложить LaBSE-en-ru, у которой я отрезал эмбеддинги всех 99 языков, кроме русского и английского. Модель похудела с 1.8 до 0.5 гигабайт, и, надеюсь, таким образом стала чуть более удобной для практического применения. Ну а rubert-tiny оказался по качеству в целом близок к моделям от DeepPavlov и Sber, будучи при этом на порядок меньше и быстрее.

Заключение

Я обещал сделать компактную модель для эмбеддингов русских предложений, и я это наконец сделал. Процесс дистилляции, скорее всего, я настроил неоптимально, и его ещё можно сильно улучшать, но уже сейчас маленькая модель на некоторых задачах приближается к уровню своих учителей и даже иногда обходит его. Так что если вам нужен маленький и быстрый BERT для русского языка, то пользуйтесь: https://huggingface.co/cointegrated/rubert-tiny.

Впереди работы много: с одной стороны, хочется обучить маленький BERT решать задачи из RussianSuperGLUE (и не только), с другой затащить в русский язык хорошие небольшие модели для контролируемой генерации текста (я уже начал делать это для T5). Посему лайкайте данный пост, подписывайтесь на мой канал про NLP, подкидывайте в комментариях и в личке интересные задачи, и, если у вас доведутся руки попробовать rubert-tiny, то обязательно оставляйте обратную связь!
Мне и самому интересно, что будет дальше.

Подробнее..

Из песочницы Разработка бренда в среде lean startup. Часть 1

23.10.2020 18:08:20 | Автор: admin
Очень часто владельцы малого бизнеса или основатели стартапов сталкиваются с проблемой разработки бренда своей компании и отстройки от конкурентов в условиях ограниченных ресурсов. Особенно актуально это сейчас, когда в мире бушует пандемия Covid-19.

Запустив несколько стартапов, я выработал определенный алгоритм разработки бренда для небольших компаний и стартапов, которым относительно легко пользоваться. Эта статья первая из цикла Разработка бренда в среде lean startup. В ней мы сосредоточимся на общем описании подхода к разработке бренда и на практических шагах его реализации.

Данный подход подойдет, как владельцам МСП, стартапов, так и начинающим маркетологам.

Общее описание алгоритма


1. Определить (в одно предложение) цель/боль целевой аудитории, которую мы решаем.

2. Обозначить функциональные, эмоциональные, социальные выгоды и выгоды самовыражения. Приоритизировать выгоды.

3. Выделить ключевое сообщение для целевой аудитории.

4. Определить позиционирование.

5. Сгенерировать 30-50 ассоциаций с вашим брендом.

6. Сгруппировать данные ассоциации и выявить общие категории ассоциаций. Это будут основные элементы (ключевые ассоциации), с которыми будет ассоциироваться ваш бренд. Данных элементов должно быть от 2 до 5.

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

8. Отсеять названия после мозгового штурма

8.1 Отсеивание названий, которые меньше всего отражают суть бренда

8.2 Оставшиеся названия проходят отбор через дополнительный Алгоритм анализа коммерческих названий в русском языке.

8.3 Создаем таблицу соответствия названия бренда ключевым ассоциациям.

8.4 Выбираем 5-6 названий, прошедших этап отсеивания и имеющих максимальную оценку соответствия ключевым ассоциациям.

9. Проверка по базе ФИПСА этих 5-6 названий на наличие зарегистрированных торговых знаков:

www1.fips.ru/iiss/search.xhtml

10. Если вы стартап, и пока не определили подходит ли ваш продукт рынку или нет, то проведите дополнительную проверку наименования бренда на семантическое растягивание / сжатие, если в будущем вам необходимо будет использовать бренд с другой линейкой продуктов.

11. Выбираем одно название, по которому будет создаваться визуальная идентификация. Данный алгоритм будет раскрыт в следующих публикациях.

Разбор шагов алгоритма с примером


Среднее время выполнения по алгоритму для одного человека 30 минут, для группы 40-50 минут (увеличенное время связано с координацией группы, но и результат от группового обсуждения в большинстве случаев лучше).

Пример заказчика


Мы небольшая кондитерская (назовём её Кондитерская), которая производит капкейки из цветной капусты по оригинальному рецепту. Мы предлагаем здоровую альтернативу существующим десертам. Наша целевая аудитория: девушки, женщины, следящие за своим рационом, но при этом любящие десерты.

Прогоняем по алгоритму:

1. Определить (в одно предложение) цель/боль целевой аудитории, которую мы решаем.

В условия ограниченности времени и бюджета наши клиенты ищут решение для здорового питания.

2. Определить функциональные, эмоциональные, социальные выгоды и выгоды самовыражения.

Таблица 1. Выгоды товара.

image

3. Определить ключевое сообщение для целевой аудитории.

Помогаем современным девушкам и женщинам следить за своим здоровьем с помощью здоровых десертов.

4. Позиционирование:

Вкусные и здоровые десерты для современных женщин.

5. Сгенерировать 30-50 ассоциации с брендом. Примерный список.

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

Ассоциации также должны предоставить точку отстройки от конкурентов, которая поддержит ценностное предложение или достигнет паритета с предложением конкурентов. Важно достичь паритета по важным показателям, по которым вас сравнивают с конкурентами. Таким образом, вы не будете исключены из рассмотрения на этапе сравнения.

Таблица 2. Пример листа ассоциаций.

image

6. Сгруппировать данные ассоциации и выявить общие категории. Эти категории и будут основными элементами, с которыми будет ассоциироваться ваш бренд. Данных элементов должно быть 2-5. Группировка, категоризация и обозначение категории это самый трудоемкий процесс во всем алгоритме. Наберитесь терпения.

Таблица 3. Результат категоризации и группировки ассоциаций.

image

7. Этап генерации названия. Используя ключевые элементы / ассоциации из предыдущего шага, генерируем возможные названия для бренда с помощью свободного брейнсторминга. Просто записываем возможные названия бренда. Да пребудет с вами сила фантазии!

Ключевые элементы: Заботливая кондитерская, Здоровье и красота, Говорим на языке вкуса

Таблица 4. Названия, ассоциирующиеся с ключевыми элементами.

image

8. Отсеять названия после мозгового штурма

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

8.2 Оставшиеся названия проходят отбор через дополнительный Алгоритм языкового анализа коммерческих названий в русском языке. О том, как он проводится, я расскажу в отдельном посте, так как описание работы данного алгоритма занимает 2 страницы.

На выходе вы получаете таблицу с оценкой ассоциативности названия по ключевым элементам и результатами из Алгоритма языкового анализа коммерческих названий в русском языке.

Таблица 5. Названия, ассоциирующиеся с ключевыми элементами.

image

Выбираем 5-6 названий с максимальной суммой оценки. Замечу, что здесь присутствует некая субъективность величин оценок, однако, они точно отражают величину ассоциативности наименований относительно друг друга.

9. Проверка по базе ФИПС этих названий.

www1.fips.ru/iiss/search.xhtml

Таблица 6. Результат сверки с базой ФИПС.

image

10. Дополнительная проверка наименования бренда на семантическое растягивание / сжатие.

Допустим мы решили, что выпуск капкейков из цветной капусты не соответствует требованиям рынка. Теперь мы хотим выпускать новую линейку десертов для здорового питания на основе тыквы. Тогда DolceKapusta обладает узкой семантикой для выпуска других линеек питания, но КушайЗдорово, наоборот, обладает широкой семантикой и подходит для выпуска других линеек питания.

11. Останавливаемся на DolceKapusta (Мы решили быть узкоспециализированной кондитерской с броским названием). По этому наименованию пойдёт дальнейшая разработка визуальной идентификации бренда.

Заключение


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

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

Всем успеха!
Подробнее..

Как преобразовать текст в алгебру

23.03.2021 02:06:18 | Автор: admin

Авторы статьи: к.ф.-м.н. С.Б. Пшеничников, к.ф.-м.н. А.С. Вальков

Алгебра и язык (письменность) являются двумя разными инструментами познания. Если их объединить, то можно рассчитывать на появление новых методов машинного понимания. Определить смысл (понять) это вычислить как часть соотносится с целым. Современные поисковые алгоритмы уже имеют задачей распознавание смысла, а тензорные процессоры Google выполняют матричные умножения (свертки), необходимые для алгебраического подхода. При этом в семантическом анализе используются в основном статистические методы. В алгебре выглядело бы странным использование статистики при поиске, например, признаков делимости чисел. Использование алгебраического аппарата полезно также для интерпретации результатов вычислений при распознавании смысла текста.

Под текстом понимается последовательность знаков произвольной природы. Например, естественные языки, нотные тексты, генетические последовательности биополимеров, коды (кодовые таблицы как отношения знаков). В нотных текстах, записанных на нотоносце из одной линейки (нотоносец-нитка), знаками являются ноты, ключи, знаки аллитерации, указания громкости и темпа. В генетических текстах знаками-словами являются триплеты. Знаковые системы вкуса и обоняния пока существуют только как естественные (как образцы, вроде зоопарка). Для осязания существует рельефно-точечный тактильный код-шрифт Брайля. Хабом знаковых систем является семиотика [1], состоящая из трех тегов: семантики, синтактики и прагматики.

Пример языкового текста:

Множество это объект, являющийся множеством объектов. Полином это множество объектов-мономов, являющихся множеством объектов-сомножителей. (1)

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

(множество)1,1 (это)2,2 (объект)3,3 (являться)4,4 (множество)5,1 (объект)6,3 ("точка")7,7 (полином)8,8 (это)9,2 (множество)10,1 (объект)11,3 (моном)12,12 (являться)13,4 (множество)14,1 (объект)15,3 (сомножитель)16,16 ("точка")17,7(2)

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

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

Словарь это исходный текст с удаленными повторами. Текст это знаковая последовательность, в которой есть хотя бы один повтор. В коротких фрагментах текста повторов явно может не быть, но используемые в них слова используются в определенном смысле (контексте), который можно указать ссылкой на толковый словарь или другой текст. Тогда вторую координату в (2) можно считать номером слова в словаре. Словарь текста (2):

(множество)1,1 (это)2,2 (объект)3,3 (являться)4,4 ("точка")7,7 (полином)8,8 (моном)12,12 (сомножитель)16,16(3)

При координатизации (1) (2) основными признаками слов стали индексы, а не то, что внутри круглых скобок (...)i,j. Например, для бинарного кода Морзе латинские буквы являются знаковыми последовательностями. Словарем является последовательность двух знаков-символов (точка и тире), совпадающие с буквами A и N. Порядок знаков в словаре несущественен. Остальные 24 латинские буквы являются кодовыми текстами. Единый текст (с помощью конкатенации) строится из всех букв (как фрагментов текста):

A\rightarrow (\cdot)_{1,1}(-)_{2,2}, B\rightarrow (-)_{3,2}(\cdot)_{4,1}(\cdot)_{5,1}(\cdot)_{6,1}, C\rightarrow (-)_{7,2}(\cdot)_{8,1}(-)_{9,2}(\cdot)_{10,1}, \ldots

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

Замечательно, что такие знаки существуют. Это матричные единицы. Матричные единицы Ei,j (имеют два индекса) это квадратные матрицы, в которых единица находится на пересечении i строки и j столбца, остальные элементы матрицы равны нулю. Например, при размерности n=2:

E_{1,2} = \left\| {\begin{array}{*{20}{c}} 0&1 \\ 0&0 \end{array}} \right\|, E_{2,1} = \left\| {\begin{array}{*{20}{c}} 0&0 \\ 1&0 \end{array}} \right\|, \;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;(4) E_{1,1} = {E_{1,2}}{E_{2,1}} = \left\| {\begin{array}{*{20}{c}} 1&0 \\ 0&0 \end{array}} \right\|,\;\;{E_{2,2}} = {E_{2,1}}{E_{1,2}} = \left\| {\begin{array}{*{20}{c}} 0&0 \\ 0&1 \end{array}} \right\|,

где E1,2, E2,1 и E1,1, E2,2 простые и составные матричные единицы (по аналогии с целыми числами). Произведение матричных единиц отлично от нуля (нулевой матрицы), если внутренние индексы произведения совпадают. Например, E1,1E2,1=0, E2,1E1,2=E2,2. Матричные единицы в дальнейшем будут рассматриваться как некоммутативные обобщения целых чисел. Левые и правые делители таких чисел могут различаться, а также имеются делители нуля. Но многие понятия модулярной арифметики [2] остаются справедливыми.

Обычному тексту (2) соответствует матричный текст P (сумма матричных единиц):

\begin{gathered} P = {E_{1,1}} + {E_{2,2}} + {E_{3,3}} + {E_{4,4}} + {E_{5,1}} + {E_{6,3}} + {E_{7,7}} + {E_{8,8}} + {E_{9,2}} + \\ + {E_{10,1}} + {E_{11,3}} + {E_{12,12}} + {E_{13,4}} + {E_{14,1}} + {E_{15,3}} + {E_{16,16}} + {E_{17,7}} \\ \end{gathered} \;\;\;\;\;\;(5)

Индексы (координаты) в (2) и (5) поэлементно совпадают, но P - математический объект (квадратная матрица). Разделитель (пробел) слов в (2) превращается в операцию сложения матриц. Исходный текст (2) восстанавливается по индексам из (5) забыванием алгебраических свойств (превращением операции сложения в разделитель-пробел) и обратным использованием кодовой таблицы координата-слово.

Универсальным свойством знаковых последовательностей в матричном виде (5) (текстовых полиномов) является уникальность первого индекса. На одном номере последовательности не могут находиться два и более знака. Второй индекс может повторяться.

Матричный словарь, соответствующий (3) имеет вид:

D_R = E_{1,1} + {E_{2,2}} + {E_{3,3}} + {E_{4,4}} + {E_{7,7}} + {E_{8,8}} + {E_{12,12}} + {E_{16,16}} \;\;\;\;\;\;\;(6)

Матричный словарь DR это матричный текст P с исключенными повторами. Размерность матриц P и DR imaximax, где imax номер последнего слова (знака) в тексте. В каждой строке матриц P и DR имеется не более одной единицы, остальные элементы равны нулю. Это свойство является следствием уникальности первого индекса. В матрице DR соответствующие словам текста единицы находятся на её главной диагонали. Остальные элементы диагонали и матрицы равны нулю.

Для матричных текстов выполняются соотношения:

P{D_R} = P,\;\;{D_R}P = {D_R},\;\;{P^2} = P,\;\;D_R^2 = {D_R},

Порядок элементов в (5) несущественен, в отличие от (2). Следовательно, можно совершать преобразования (например, приведение подобных), как в случае числовых многочленов.

Делимое, делитель и частное определяются для любых фрагментов матричного текста F1, F2, ,Fk почти также, как для целых чисел. Элемент Fi (делимый) делится на элемент Fj (делитель), если существует элемент Fij (частное) такой, что Fi=FijFj. В отличие от целых чисел частное располагается слева от делителя. Частное может не являться фрагментом текста.

Фрагмент текста в предельном случае может быть матричной единицей (матричным словом). По (4) матричные единицы сами могут быть простыми и составными. Из n2 матричных единиц 2(n-1) являются простыми, остальные (n2 2n 2) составные (произведения простых).

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

Правый идеал матричного текста это всевозможные номера слов в DR (вторых координат), которые можно разместить на заданных номерах слов в тексте (первых координат).

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

Понятие делимости матричных текстов обобщается на делимость идеалов матричных текстов. Свойства делимости матричных фрагментов текста имеют место при делении идеалов. Понятия НОД и НОК также обобщаются на случай идеалов матричных текстов.

Сравнения целых чисел также обобщаются на случай матричных текстов. Фрагменты матричных текстов F1, F2, ,Fk сравнимы по модулю (мере) Fmфрагмента , если остатки от деления F1, F2, ,Fk на Fm кратны.

Если остатки кратны, то они имеют одинаковые словари. Поэтому фрагменты сравнимы по модулю заданного фрагмента, если остатки от деления фрагментов на заданный фрагмент имеют одинаковые словари. Сравнимость текстов по модулю некоторого текста можно интерпретировать следующим образом. Пусть имеется корпус английского языка. Выбираются шесть книг, наиболее соответствующие шести базовым сюжетам Шекспира. Матричный текст этих шести книг является фрагментом Fm. Тогда остальные книги корпуса, имеющие кратные остатки от деления их матричных текстов на Fm, сравнимы по Fm. Это означает, что можно сделать каталог книг для тех, кого интересуют не только шекспировские сюжеты. Причем кратность остатков является классифицирующим признаком для этого каталога. Классов вычетов в этом примере шесть. Взяв только три книги, например, можно весь корпус английского языка сравнить только по трем сюжетам из шести. Если человек имеет десять любимых книг или авторов, можно классифицировать корпус языка по признакам отличия от этого топтена.

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

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

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

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

Алгебраическая структуризация текста примера (5) выглядит следующим образом:

P = F_1 + F_2,F_1(P) = E_{1,1} + E_{2,2} + E_{3,3} + E_{4,4} + E_{5,1} + {E_{6,3}} + {E_{7,7}}F_2 = E_{8,8} + {E_{9,2}} + {E_{10,1}} + {E_{11,3}} + {E_{12,12}} + {E_{13,4}} + {E_{14,1}} + {E_{15,3}} + {E_{16,16}} + E_{17,7} F_2 = \left( E_{9,2} + E_{10,5} + E_{11,6} + E_{13,4} + E_{14,5} + E_{15,6} + E_{17,7} \right)F_1+ \\ +E_{8,8}+E_{12,12}+E_{16,16}P=F_1+ \left(E_{9,2} + E_{10,5} + E_{11,6} + E_{13,4} + E_{14,5} + E_{15,6} + E_{17,7}\right)F_1 + \\ +E_{8,8} + E_{12,12} + E_{16,16}P=\left(E + E_{9,2} + E_{10,5} + E_{11,6} + E_{13,4} + E_{14,5} + E_{15,6} + E_{17,7}\right)\times \\ \times \left( E_{1,1} + E_{2,2} + E_{3,3} + E_{4,4} + E_{5,1} + E_{6,3} + E_{7,7} + E_{8,8} + E_{12,12} + E_{16,16} \right),P=\left(E + E_{9,2} + E_{10,5} + E_{11,6} + E_{13,4} + E_{14,5} + E_{15,6} + E_{17,7}\right) \left( D_R + E_{5,1} + E_{6,3} \right), \;\;\;\;\;\;\;(7)

где E единичная матрица. Используя свойства матричных единиц, исходный матричный текст в аддитивной форме (5) преобразован в мультипликативную форму (7). Сомножитель (DR+E5,1+E6,3) является некоммутативным аналогом базиса Грёбнера-Ширшова для коммутативных многочленов. Бриллиантовая лемма Ширшова выполняется в сомножителе (DR+E5,1+E6,3) имеются зацепления (повторения) справа по второму индексу, но они разрешимы (имеют общие делители).

При преобразовании (редукции) (7) произошло преобразовании словаря текста:

D_R \rightarrow \left( E_{5,1} +E_{6,3} +E \right) D_R,\;\;\;\;\;\;\;\;\;\;\; (8)

В новом словаре (базисе идеала) появились слова E5,1и E6,3. Это те же слова E1,1знаки (множество) и E3,3 (объект), но находящиеся на пятом и шестом местах текста. Слова как знаки те же, но смысл повторяющихся слов в тексте меняется. Слова определяются контекстами. Слова близки, если их контексты содержат хотя бы одно общее слово. Контексты тем более близки, чем больше общих слов из соответствующего словаря (общих вторых индексов) они содержат.

В естественных языках множественность контекстов слова является причиной неоднозначности понимания смысла слов. Смысл по Фреге это соответствующая часть значений знака (слова). Значения слова это все его контексты (свойства). Например, пусть знак это слово объект. Все его значения в тексте: множество, элемент множества, моном и сомножитель. Это означает, что слово-знак объект обозначает четыре омонима. Смысл это часть значений, например, только моном.

Словарь DR (6) в начале структуризации являлся словарем знаков-слов. В процессе структуризации он преобразуется в контекстно-зависимые матричные конструкции n-грамм (сочетаний слов-знаков, учитывающий их взаимный порядок и расстояние в тексте). Смысловая разметка текста основывается на расширении исходного словаря текста омонимами, а сам текст уже строится по такому расширенному словарю из некоммутативного базиса.

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

Расширенный словарь (базис) вместе с контекстами повторяющихся слов называется матричным контекстным словарем текста.

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

Матричный словарь антонимов - это фрагмент контекстного словаря для слов с противоположными контекстами. Признаком противоположности в языковых текстах является наличие в контекстах отрицательных слов (частиц, местоимений и наречий).

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

Предисловие, введение, заключение, аннотация, реферат - это заголовки, дополненные элементами базиса меньшей частотности, и вычетами, вошедшими в базис (как в алгоритме Бухбергера). Для текста примера вычет это остаток E8,8+E12,12+E16,16 в (7) или в исходном виде (полином)8,8... (моном)12,12...(сомножитель)16,16 остаток от разложения F2 по F1. Именно этими элементами базиса (вычетами) отличаются контексты биграмм множество объект объект множество.

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

Возможна персональная адаптация текстов на основе его реструктуризации. Понять текст это изложить его своими словами основной прием смыслового чтения. Для текстов в матричной форме понять его означает разложить и реструктурировать авторский текст по своему базису.

Для реструктуризации необходима алгебраическая структуризация корпуса текстов языка для составления указанных выше словарей корпуса языка. В этом случае идеалы и классы вычетов матричного кольца Ptxt корпуса матричных текстов должны быть предварительно построены и исследованы.

Более строгое и общее описание алгебры текста изложено в [3].

Литература

  1. Шрейдер Ю. А. Логика знаковых систем. 2010.

  2. Виленкин Н.Я. Сравнения и классы вычетов. Журнал "Квант"

  3. Алгебра текста - С.Б. Пшеничников - препринт на researchgate

Подробнее..

Как преобразовать текст в алгебру примеры

10.04.2021 22:12:11 | Автор: admin

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

1 Код Морзе-Вейля-Герке как алгебра матричных единиц

В азбуке Морзе знаковые последовательности (тексты) 26 латинских букв состоят из точек и тире. Пример выбран из-за предельной краткости словаря ("точка" и "тире").

Слова здесь - точки или тире. 26 букв азбуки - тексты из таких слов. У каждого слова две координаты. Первая координата номер слова (точки или тире) в этой букве (от одного до четырех). Вторая координата номер в словаре (1 или 2). Словарь E11 ("точка") и E22 ("тире").

D_R=E_{11}+E_{22}Таблица 1. Азбука Морзе: латинские буквы как знаковые последовательности (тексты)Таблица 1. Азбука Морзе: латинские буквы как знаковые последовательности (тексты)

Каждой букве (знаковой последовательности) с номером из Таблицы 1 можно поставить в соответствие матричный полином P из матричных единиц 4x4 по формуле (8) из статьи [1].

Таблица 2: Азбука Морзе: буквы как матричные полиномыТаблица 2: Азбука Морзе: буквы как матричные полиномы

Например, букве Q (17) ставится в соответствие матричный полином:

E_{12}+E_{22}+E_{31}+E_{42}= \begin{Vmatrix} 0 & 1 & 0 & 0\\ 0 & 1 & 0 & 0\\ 1 & 0 & 0 & 0\\ 0 & 1 & 0 & 0 \end{Vmatrix}.

Свойством всех 26 полиномов-букв таблицы 2 является то, что крайними правыми сомножителями являются только три матричные единицы E12, E21, E32

Если все 26 полиномов Таблицы 2 представить столбцом ||P||, а также из того, что для матриц и столбцов выполняется:

 \begin{Vmatrix} a_{11} & \ldots & a_{1n}\\ \ldots & \ldots & \ldots\\ a_{m1} & \ldots & a_{mn} \end{Vmatrix} \begin{Vmatrix} b_{1} \\ \ldots \\ b_{n} \end{Vmatrix}= \begin{Vmatrix} a_{11} \\ \ldots \\ a_{m1} \end{Vmatrix}b_1+\ldots + \begin{Vmatrix} a_{1n} \\ \ldots \\ a_{mn} \end{Vmatrix}b_n,

то азбука Морзе структурируется в три левые идеалы наборов матричных полиномов Таблицы 2 с базисами ||P||1, ||P||2, ||P||3.

 \left\|P\right\|=\left\|P\right\|_1\left\|P\right\|_1=\left\|P\right\|_2\left\|P\right\|_2=\left\|P\right\|_3\left\|P\right\|_3,

где

\left\|P\right\|_1=\begin{Vmatrix} E_{12} \\ E_{21} \\ E_{32} \end{Vmatrix}, \left\|P\right\|_2=\begin{Vmatrix} E_{12} \\ E_{21}E_{12} \\ E_{12}+E_{21}E_{12} \\ E_{12}E_{21} \\ E_{21} \\ E_{21}+E_{12}E_{21} \\ E_{32} E_{21} + E_{43}E_{32} E_{21} \\ E_{43}E_{32} E_{21} \\ E_{32} E_{21} \\ E_{32} \\ E_{32} + E_{43}E_{32} \\ E_{43}E_{32} \end{Vmatrix}, \left\|P\right\|_3=\begin{Vmatrix} E_{12}E_{21} \\ E_{12} \\ E_{21} \\ E_{21}E_{12} \\ E_{32}E_{21} \\ E_{32} \\ E_{43}E_{32} E_{21} \\ E_{43}E_{32} \end{Vmatrix}, (1.1)

||P||2(||P||2)T - симметричная матрица - число в диагональных элементах это число базисных элементов (простых и составных матричных единиц), принадлежащих букве, в других элементах число совпадающих базисных элементов в соответствующей паре знаковых последовательностей (букв) - после нормализации характеризует важность буквы в азбуке.

(||P||2)T ||P||2 - симметричная матрица - число в диагональных элементах это число букв, принадлежащих базисным элементам, в недиагональных элементах число совпадающих букв в соответствующей паре базисных элементов после нормализации характеризует важность базисного элемента (заголовка) в азбуке.

Азбука Морзе с алгебраически структурирована в три идеала (класса) с базисами (1.3). Представление азбуки через идеалы описывает все подобные коды с базисами (1.3). Представление азбуки через идеалы приведено в Таблицах 3 и 4:

Таблица 3: Прямая индексацияТаблица 3: Прямая индексацияТаблица 4: Обратная индексацияТаблица 4: Обратная индексация

Азбука Морзе: ABCDEFGHIJKLMNOPQRSTUVWXYZ

из-за свойств матричных полиномов(крайние правые сомножители - только три матричные единицыE12, E21, E32) разбивается на три класса (три идеала) тремя образующими E12, E21, E32:

E12 - заголовок тех букв, которые имеют знак тире на первом месте 4-знаковой последовательности:

_BCD__G___K_MNO_Q__T___XYZ (13 букв)

E21 - заголовок тех букв, которые имеют знак точка на втором месте 4-знаковой последовательности:

_BCD_F_HI_K__N____S_UV_XY_ (13 букв)

E32 - заголовок тех букв, которые имеют знак тире на третьем месте 4-знаковой последовательности:

__C__F___JK ___OP____U_W_Y_ (9букв)

2 Алгебра математического текста

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

Формулы объема конуса VK, цилиндра Vци тора VТ:

 V_K=\frac{1}{3}\pi R_1^2H_1, V_{\text{Ц}}=\pi R_2^2H_2, V_T=\pi^2\left(R_3+R_4\right)r,\ \ \ \ \ \ \ \ \ (2.1)

рассматриваются как тексты. Это означает, что входящие в тексты знаки не являются математическими объектами и для них отсутствуют алгебраические операции. Например, R12 этоR1R1, R1 это не произведение двух чисел, а просто последовательность двух знаков. Знаки в (1): R1и H1 радиус основания и высота конуса,R2 иH2 радиус основания и высота цилиндра, R3 внутренний радиус тора, R4 внешний радиус тора, r радиус образующей окружности тора, это число .

Для семиотического анализа формул как текстов важно наличие повторов знаков. Повторы определяют закономерности. В формулах (2.1) повторов знаков на самом деле больше, чем указанные повторы знака . ЗнакиR1, R2, R3, R4, H1, H2 и r это длины отрезков. Тогда один из знаков, например , является простым (эталон длины), а остальные знаки составными: R1=ar, R2=br, R3=cr, R4=dr, H1=er, H2=fr . Тогда правые части формул (2.1):

\begin{gathered} \frac{1}{3}\pi ararer \\ \pi brbrfr \\ \pi \pi \left(c+d \right)rr \end{gathered} \ \ \ \ \ \ \ \ \ \ \ \ (2.2)

Или в индексной форме:

\begin{gathered} \left(\frac{1}{3}\right)_{1,1}(\pi)_{2,2}(a)_{3,3} (r)_{4,4} (a)_{5,3} (r)_{6,4} (e)_{7,7} (r)_{8,4} \\ (\pi)_{9,2} (b)_{10,10} (r)_{11,4} (b)_{12,10} (r)_{13,4} (f)_{14,14} (r)_{15,4} \\ (\pi)_{16,2} (\pi)_{17,2} \left(c+d \right)_{18,18} (r)_{19,4}(r)_{20,4} \end{gathered} \ \ \ \ \ \ \ \ \ (2.3)

Формулы (2.2) как полином матричных единиц из трех фрагментов

 P=F_1(P)+F_2(P)+F_3(P), \ \ \ \ \ \ \ \ \ \ (2.4)

где:

\begin{gathered} F_1(P) = D_L\left(E_{1,1}+E_{2,2}+E_{3,3}+E_{4,4}+E_{5,3}+E_{6,4}+E_{7,7}+E_{8,4}\right)D_R \\ F_2(P) = D_L\left(E_{9,2}+E_{10,10}+E_{11,4}+E_{12,10}+E_{13,4}+E_{14,14}+E_{15,4}\right) D_R \\ F_3(P) = D_L\left(E_{16,2}+E_{17,2}+E_{18,18}+E_{19,4}+E_{20,4}\right) D_R \\ D_R = E_{1,1}+E_{2,2}+E_{3,3}+E_{4,4}+E_{7,7}+E_{10,10}+E_{14,14}+E_{18,18} \\ D_L = E_{1,1}+E_{2,2}+E_{3,3}+E_{4,4}+E_{5,5}+E_{6,6}+E_{7,7}+ \ldots + E_{20,20} = E \\ D_L=D_R+E_{5,5}+E_{6,6}+E_{5,5}+E_{8,8}+E_{5,5}+E_{9,9} \end{gathered}

Или в блочно-матричной форме:

В столбцах P находятся знаки из трех формул (2.1) . Если в столбце два нуля, это означает, что соответствующий знак имеется только в одной формуле. Например, знак 1/3 (или E1,1), два знака a (или E3,3+E5,3) , один знак e (или E7,7) имеются только в первой формуле для конуса (первая строка (2.5)). Только в цилиндре (вторая строка (2.5)) имеются два знака b (или E11,11+E13,11) и один f (или E15,15). Только в торе (третья строка (2.5)) имеется знак (c+d) (или E20,20). Общие знаки конуса, цилиндра и тора находятся во втором и четвертом столбцах (2.5). Тогда:

\begin{gathered} P = P_{\text{частн}_1}P_{\text{дел}_1}+P_{\text{ост}} \\ P = P_{\text{частн}_2}P_{\text{дел}_1}+P_{\text{ост}} \end{gathered}

где:

 \begin{gathered} P_{\text{частн}_1} = \left(E_{2,18}+E_{4,12}+E_{6,14}+E_{8,16}\right) +\left(E_{10,18}+E_{12,12}+E_{14,4}+E_{16,16}\right)+\\ +\left(E_{18,18}+E_{19,19}+E_{21,12}+E_{22,14}\right), \\ P_{\text{частн}_2} = (E_{2,2}+E_{4,4}+E_{6,4}+E_{8,4})+(E_{10,2}+E_{12,4}+E_{14,4}+E_{16,4})+ \\ +(E_{18,2}+E_{19,2}+E_{21,4}+E_{22,4}), \\ P_{\text{дел}_1} = E_{18,2} + E_{19,2}+E_{12,4} + E_{14,4} + E_{16,4}, \\ P_{\text{дел}_2} = E_{2,2} + E_{4,4}, \\ P_{\text{ост}} = E_{1,1}+E_{3,3} + E_{5,3}+E_{7,7}+E_{11,11} + E_{13,11}+E_{15,15}+E_{20,20}.\\ \end{gathered}

В (2.6) матричный текст раскладывается по разным базисам Pдел1 и Pдел2. Базис Pдел1учитывает взаимные положения между повторяющимися знаками относительно тора в формулах (2.1). Базис Pдел2 учитывает положения между повторяющимися знаками относительно знаков словаря DR в формулах (2.1). В общем случае учет положения знаков в формулах существенен, если знаки некоммутативны (например, знаки это матрицы, вектора, тензоры, гиперкомплексные числа). Но и в скалярном это полезно, например, канонической является формула площади круга r2, а не r2 .

Базис Гребнёра-Ширшова для (2.6):

 \begin{gathered} P_{\text{дел}_1}+P_{\text{ост}} \\ P_{\text{дел}_2}+P_{\text{ост}} \end{gathered}

Тогда:

 \begin{gathered} P= P_{\text{частн}_1} \left( P_{\text{дел}_1}+P_{\text{ост}} \right) \\ P= P_{\text{частн}_2} \left( P_{\text{дел}_2}+P_{\text{ост}} \right) \end{gathered}

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

Метод алгебраическая структуризация текстов позволяет для текстов разной природы найти соответствующие классификаторы и словари. Т. е. классифицировать тексты без априорного задания признаков классификации и наименования классов. Такая классификация называется категоризацией или апостериорной классификацией. Например, для (2.3) классификационными признаками становятся:

  • Pдел1и Pдел2 (общие и r в разных местах формул),

  • общее число слагаемых в круглых скобках Pчастн1и Pчастн2 (четыре),

  • соотношения числа и r в круглых скобках Pчастн1и Pчастн2 (1,1,2 и 3,3,2),

  • сомножители мультипликативной формы Pчастн1 и Pчастн2,

  • всевозможные фрагменты Pост(вычеты, как класс формул с остатком-фрагментом).

Наименования классов совпадает с наименование признаков и их сочетаний.

Литература

[1] Пшеничников C.Б. Алгебра текста. Researchgate Preprint, 2021

Подробнее..

Алгоритм Jerdella решаем проблемы семантического безумия в IT-системах банков

14.10.2020 14:07:29 | Автор: admin
Семантические проблемы в IT системах. Что бывает, когда много разных людей начинают творить

Есть ветхозаветная легенда о том, как люди в древнем городе Вавилон начали строить башню, но Всевышний перемешал им языки, и башня достроена не была. Еще бы, ведь башню строили сотни маленьких групп, которые в совокупности не понимали друг друга. А не понимая друг друга, невозможно взаимодействовать. Действительно, просто безумие называть одну и туже вещь, подразумевая её одинаково, разными словами. И удивительного тут ничего нет.

Ветхозаветную легенду можно с легкостью перенести на современные крупные компании, внедряющие современные ИТ-решения. В пример таких компаний, вне всякого сомнения, можно отнести современные российкие банки, которые имеют десятки, а то и сотни бизнес-подразделений, в которых складывается своя субкультура общения, построенная на своих правилах и уникальном стиле делового оборота. Естественно, при формировании ИТ-инфрастурктуры учитывается устоявшийся в коллективе стиль именования бизнес-сущностей. За последние десять лет появилось множество работ на эту тему, например эта [1]. Те, кто сталкивался с аналитикой информационных систем в банках знают, что такое сделать так называемый маппинг данных, особенно, если конечные системы делали разные команды аналитиков, разработчиков и заказчиков или вендоров. Как правило, на 60% составление маппинга является уяснением сути и семантики передаваемых данных.

Сейчас модной тенденцией является использования комплекса гибких методологий. Об Agile говорят все. Можно до хрипоты спорить, благо он для бизнеса или вред. Но одна вещь не вызовет ни у кого отторжения. В ходе Agile множество разных команд, как внутри банка, так и со стороны разных вендоров рождает множество ИТ-решений для бизнеса, и часто, не взаимодействуя друг с другом, команды рождают свою устоявшуюся терминологию. И в тот момент, когда интеграция все же происходит, случается та самая, описанная в Ветхом Завете ситуация. Чем она не напоминает вавилонский базар с его тысячами торговцев, лавок, товаров, юродивых, факиров и глотателей огня? И вот, все эти люди, вооруженные разными идеями и разными помыслами, начинают строить Башню.

Мы всегда на выходе спринта имеем набор XSD схем (или примеров JSON сообщений) с полями, которые нужно каким-то образом однозначно сопоставить друг другу. И не важно, где идут споры, может быть это набор экселевских таблиц с маппингами, может быть это сотни комментариев в Confluence, может быть это часы конференций в Zoom или Webex, но на наведение порядка в этом семантическом безумии тратится время и нервы, а самое главное деньги.

Конечно же, концепция использования ESB (единой сервисной интеграционной шины банка) и модель глобальных бизнес-объектов, которая используется, например в некоторых европейских банках, где является своеобразной лингва-франка между информационными системами, должны позволить уйти от данной ситуации. Но давайте будем честными, не все компании могут это себе позволить, да и не всем это надо. Ситуация в банковской сфере меняется столь стремительно, что многие заказчики начинают прибегать к концепции взаимодействующих платформ на основе микросервисов, посаженных на какой-нибудь брокер сообщений, типа Kafka. В итоге мы имеем не одну модель данных, а набор моделей данных, созданных под каждый сервис, зачастую отдельной командой. Взаимодействие в рамках данной платформы осуществляется не столь привычными банковским аналитикам XML сообщениями, основанными на использовании жестких XSD схем, разработанных в ходе проектирования командой аналитиков, юристов, представителей бизнеса на века, а более простой и наглядный JSON, пришедший в банковский бек из фронт-разработки вместе с разработчиками, решившими сменить фронт на бек. Не стоит, наверное, говорить, что JSON не может нести жесткую схему. Просто он удобнее для гибких методологий. Его можно поправить, добавив или убрав пару атрибутов. И нет в нем привязки к железобетонным XSD схемам, замешанным на использовании специфических правил записи. JSON проще редактировать и вносить в него изменения. К его изменению проще доступ.

И что мы имеем? Мы имеем набор входных на платформу сообщений, которые надо в соответствии с бизнес-сутью данных передать микросервисам. И вот тут возникает вопрос, а как это сделать побыстрее?


Маппинги данных. Говорим разными словами об одном и том же

В момент интеграции между несколькими ИТ-системами сталкиваются два аналитика. Один со стороны одной системы, другой со стороны соответственно второй системы. В качестве входных данных у них два файла MS Excel, которые нужно, как говорят у нас, смапить для реализации разработки адаптера. В этих файлах указаны атрибуты сообщения в одной колонке (как правило в форме JSON path), а в другой их семантическое описание. Такой документ называется маппингом. И вот тут начинается самое интересное. Кто сталкивался с маппингами, тот знает что в них могут находится такие описания:

номер счета физического лица


номер счета физика


20-значный номер счета физика


12-значный счет физического лица


номер отделения, в котором открыт счет физического лица


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

Вот если бы существовал такой алгоритм, реализованный простым скриптом, написанным на общедоступном языке программирования с огромным количеством удобных библиотек, которые можно легко установить из командной строки через PIP! Такой алгоритм бы подхватывал два файла с расширением xslx и создавал бы третий, в котором уже было бы проведено установление первичного соответствия. Да, вы правы, я о языке Python, который идеально подходит для решения рутинных задач аналитика.

И вот, мы пришли к задаче провести анализ текстовых данных методами языка Python. Наверное для анализа текстовых данных, есть специализированные библиотеки языка Python. Но, когда ты работаешь в банке и тонко чувствуешь его синергетику, возникает желание придать какую-то количественную и осмысленную оценку точности аналитики. Нужно это, в том числе, и для дальнейшего развития механизма автоматизации работы аналитика. Это непреодолимый соблазн для исследователя сопоставить рациональное число явлению или, в нашем случае, попаданию в семантическую суть. Как говорил Платон: Все есть число, весь мир есть число. Поэтому и возникла идея использовать для задания и визуализации точности оценки какой-нибудь из базовых виджетов библиотек PyQt или Tkinter. А для этого, необходимо дать соответствующую числовую характеристику. Тянешь ползунок на экране и регулируешь точность попадания в семантическую цель.
И так, у нас к каждому JSONpath в файле маппинга приложено краткое описание поля, написанное на русском языке кириллическими буквами. И вот тут возникла идея оценить семантическое соответствие, написанного в коментарии в одном файле и в другом, при помощи математического алгоритма, реализованного на языке Python. Да и не просто оценить, а оценить количественно.


На помощь спешит математика. Векторизация комментария в описании полей для JSON. Соединяем лингвистику и аналитическую геометрию

Суть метода состоит в следующем. Предлагается сопоставить каждому комментарию в экселевском файле с описанием полей вектор в 33-мерном евклидовом вещественном пространстве при ортонормированном базисе. Почему в 33 мерном? Да очень просто 33 это количество букв в русском алфавите. Назовем такое пространство Алфавитным. Что может быть проще. Кстати, метод векторизации текстовых данных известен давно и подробно описан в любом учебнике по машинному обучению, например, тут [2]. В получившемся пространстве мы формируем Декартову систему координат с числовыми осями. По каждой из таких осей пространства мы откладываем количество букв в высказывании. Вот тут необхоимо сформировать главную лемму для дальнейших рассуждений: любому высказыванию, выраженному в кириллических буквах, можно однозначно поставить в соответствие вектор в алфавитном 33-мерном евклидовом ортономированном пространстве. Числовыми координатами вектора по соответствующей оси будет количество соответствующей буквы в высказывании. А дальше следует проанализировать семантическое соответствие путем определения разницы между такими векторами по правилам аналитической геометрии. К примеру, алфавитное пространство ABC у нас будет выглядеть следующим образом:

$$display$$ABC=(x_А,x_Б,.....,x_Я),(1) $$display$$


где каждая координата x в соответствующей позиции это количество соответствующей буквы комментарии к полю в экселевском файле. Например, у нас есть комментарий Номер счета физического лица. Сопоставим для него вектор, выходящий из начала координат декартовой системы в алфавитном 33 мерном пространстве, выглядеть он будет следующим образом: координата XА соответствует количеству букв а. И оно равно двум. XБ в данном случае будет равно нулю, так как буквы б в данном высказывании нет. Тоже самое касается и xВ буква в отсутствует. А вот xИ будет равен 3, так как буква и в комментарии встречается три раза.



Рисунок 1. Проекция алфавитного вектора, соответствующего высказыванию Номер счета физического лица на плоскость букв АИ. Количество букв А= 2, количество букв И =3. Вектор в данной плоскости имеет две координаты по количеству букв xA=2, xб=3.

Таким образом, если мы строим вектор, берущий начало в нуле (начале координат) декартовой системы, то алфавитный 33-мерный вектор $\vec{S_1}$ соответствующий высказыванию Номер счета физического лица, у нас получится следующий:

$\vec{S_1}=(2;0;0;1;0;3;0;0;1;3;0;1;1;1;1;3;0;1;2;1;0;1;0;1;2;0;0;0;0;0;0;0;0) $


Теперь, допустим, у нас есть высказывание Номер счета физика (кто работал в банковской среде, то знает, как тут любят слова физик и юрик) и Номер счета клиента. Сопоставим им по данному правилу алфавитные вектора $\vec{S_2}$ и $\vec{S_3}$ соответственно:

$\vec{S_2}=2;0;0;0;0;2;0;0;1;2;0;1;0;1;1;1;0;1;1;1;0;1;0;0;1;0;0;0;0;0;0;0;0),$


$\vec{S_3}=2;0;0;0;0;3;0;0;0;1;0;1;1;1;2;1;0;1;1;2;0;0;0;0;1;0;0;0;0;0;0;0;0)$


Теперь найдем разность между векторами в декартовой системе координат алфавитного пространства, находится она соответственно по хорошо известной из аналитической геометрии формуле:

$\vec{S_{1,2}}=(x_{А,1}-x_{А,2};x_{Б,1}-x_{Б,2};.....;x_{Я,1}-x_{Я,2}) , (2) $


где $x_{n,1}$ и $x_{n,2}$ соответствующие координаты вектора для оси, соответствующей букве.

Рисунок 2. Синим цветом показана разность между векторами $\vec{S}_{1,2}$ на плоскости букв А-И алфавитного пространства.

Таким образом, вектор, соответствующий разнице между высказываниями Номер счета физического лица и Номер счета физика будет выглядеть следующим образом:
$\vec{S_{1,2}}=(0;0;0;1;0;1;0;0;0;1;0;0;1;0;0;2;0;0;1;0;0;0;0;1;1;0;0;0;0;0;0;0;0)$,
вектор, соответствующий разнице между высказываниями Номер счета физического лица и Номер счета клиента будет выглядеть следующим образом:

$\bar{S_{1,3}}=(0;0;0;1;0;0;0;0;1;2;0;0;0;0;-1;2;0;0;1;-1;0;1;0;1;1;0;0;0;0;0;0;0;0)$

,
Далее, вычисляется длина полученных разностных векторов, по формуле:

$|\bar{S_{1,2}}|=\sqrt{({x_1}^2+{x_2}^2+...+{x_33}^2)},(3)$


Если произвести арифметический подсчет, то получится:

$S_{1,2}=3.32$


$S_{1,3}=4.00$


Это математически предполагает, что фраза Номер счета физического лица по своему смыслу ближе к Номер счета физика, чем к Номер счета юридического лица. На это указывают длины разностных векторов. Чем меньше длина, тем ближе по смыслу друг к другу высказывания. Если мы, например, возьмем и сравним высказывания Номер счета физического лица и номер отделения, в котором открыт счет физического лица, то получим цифру 6.63. Что будет указывать на то что, если первые два высказывания близки по смыслу с исходным (разница векторов 3.32 и 4.00 соответственно), то третье, очевидно, даже будет иметь отличную от него бизнес-суть, несмотря на, казалось бы, видимый одинаковый набор слов.

Можно пойти дальше и попробовать через векторизацию количественно оценить близость комментариев по смыслу. Для этого я предлагаю использовать проекции векторов друг на друга. После чего найти отношение между длинной проекции сравниваемого ветора на длину того, с которым сравнивают. Данное отношение всегда будет меньше, либо равно единице. И соотвественно, если высказывания идентичны друг другу, то проекция сольется с вектором, на который проекцию делают. Чем дальше сравниваемое высказывание будет по смыслу, тем меньше будет составлять проекция. Если его умножить на 100 %, то можно получить степень соответствия векторизованных высказываний в процентах. Таким образом, проекция вектора $\vec{{S_2}^\prime}$ сравниваемого высказывания $\vec{S_2}$ на вектор исходного высказывания $\vec{S_1}$ будет находиться по следующей формуле:

$\vec{S_2^\prime}=\frac{(\vec{S_1},\vec{S_2})}{\left|\vec{S_1}\right|}=\frac{x_{А1}x_{А1}+x_{Б1}x_{Б2}+...+x_{Я1}x_{Я2}}{{x_{А1}}^2+{x_{А1}}^2+....+{x_{Я1}^2}}, (5)$


Таким образом, степень соответствия $\delta$ будет рассчитываться по следующей формуле:

$\delta=\frac{\left|\bar{S_2^\prime}\right|}{\left|\bar{S_1}\right|}*100$$ = \frac{x_{11}x_{21}+x_{21}x_{22}+...+x_{n1}x_{n2}}{{x_{А1}}^2+{x_{Б1}}^2+....+{x_{Я1}^2}}*100 , (6)$



Рисунок 3. Иллюстрация проекции $S_2^\prime$ вектора $\vec{S_2}$ на вектор $\vec{S_1}$.
Именно данный параметр предлагается брать за основу при определении семантического соответствия.

Реализация алгоритма на языке Python. Немного об абрикосе. Как задавать и обращаться с векторами


Алгоритм я назвал Jerdella. Ничего странного, просто я из Ростова-на-Дону.

Атмосфера Нахичеванского базара и бескрайние лотки с абрикосами натолкнули меня на мысли о Вавилоне и смешении языков. Рано или поздно, любой канбан становится похож на Нахичеванский базар в Ростове-на-Дону, где у абрикоса есть, как минимум, три названия. И рано или поздно, выходя на базар в обеденный перерыв за абрикосами, ты начинаешь понимать и по-русски, и по-армянски, и по-украински, и в совершенстве овладеваешь блатной феней. Так что, пусть алгоритм будет называться в честь абрикоса.

Еще раз скажу, мне известно, что Python имеет множество библиотек, в том числе и для математической обработки. И есть библиотеки, разработанные специально для методов аналитической геометрии. Например, такой библиотекой является NumPy. Конечно же, ряд читателей зададут вопрос, почему я не использовал NumPy? Отвечаю, во первых я не считаю данную задачу сложной, тут простые вычисления, а во-вторых все же хотелось прочувствовать реализацию алгоритма и самому все разработанные самолично методы пощупать руками, чтобы потом нести за результаты полную ответственность. Есть еще одно обстоятельство, почему не NumPy. Это банковская безопасность. Всем известно, что находясь в сети банка, невозможно устанавливать и обновлять пакеты библиотек через PIP. Поэтому, наша Jerdella будет использовать стандартные пакеты, входящие в поставку PyCharm Community Edition для интерпретатора Python 3.

Итак, язык Python хорош тем, что у него есть возможность реализовывать самые разные структуры данных. И чем нас не устроит список для записи вектора? Список из элементов типа int это то что нужно для определения вектора в алфавитном пространстве и дальнейших операций с ним.
Нами был написан ряд основополагающих процедур, которые я вкратце опишу ниже.

Как задать вектор?


Вектор я задавал следующей процедурой vector:
def vector(self,a):    vector=[]    abc = ["а", 'б', "в", "г", "д", "е", "ё", "ж", "з", "и", "й", "к", "л", "м", "н", "о", "п", "р", "с", "т",                "у", "ф", "х", "ц", "ч", "ш", "щ", "ъ", "ы", "ь", "э", "ю", "я"]    for char in abc:        count=a.count(char)        vector.append(count)    return(vector)


То есть, в цикле for по элементам заранее приготовленного списка abc, я пользовался стандартной операцией по поиску вложений в строку count. После чего, методом append заполнял новый список vector, который и будет являться вектором для дальнейших вычислений.

Как посчитать разницу векторов?


Для этого я создал процедуру delta, принимающую на вход два списка a и b.
def delta(self, a, b):    delta = []    for char1, char2 in zip(a, b):        d = char1 - char2        delta.append(d)    return (delta)

В цикле for путем применения итерации по обоим спискам считалась разница, добавляющаяся на каждом шаге итерации в конец списка delta, который процедура в конечном итоге и возвращала, как вектор.

Как посчитать длину вектора и тем самым оценить разницу?


Для этого я создал процедуру len_delta, которая принимает на вход список, и путем итераций по каждому элементу данного списка (он же является координатой в алфавитном пространстве) по правилу нахождения модуля вектора рассчитывает длину вектора.
def len_delta(self, a):    len = 0    for d in a:        len += d * d    return round(math.sqrt(len), 2)

Как посчитать отношение проекции на вектор и тем самым оценить в процентах совпадение?


Для этого была создана процедура simplify, принимающая на вход два списка. В ней я реализовал формулу (6). И тут важный момент определить какой вектор имеет большую длину. Для большей наглядности оценки совпадения удобнее проецировать меньший вектор на больший.
def simplify(self, a, b):    len1 = 0    len2 = 0    scalar = 0    for x in a: len1 += x * x    for y in b: len2 += y * y    for x, y in zip(a, b): scalar += x * y    if len1 > len2:        return (scalar / len1) * 100    else:        return (scalar / len2) * 100


Обсуждение полученных результатов. Покоряем семантическое пространство, структурируя его


Итак, дело было сделано, и Jerdella прекрасно отрабатывала и успешно формировала автоматически маппинги. Но при условии: 1) Когда количество полей, с одной и другой стороны, совпадало. 2) когда поля были описаны подробно в соответствии со своим бизнес-смыслом. Например, данный алгоритм показывал хорошие результаты при интеграции между CRM Siebel и ESB, на котором использовалась модель глобальных бизнес-объектов. В данном случае и со стороны одной системы, и со стороны другой вендоры с глубокой тщательностью, в соответствии с долговременными контрактами, прописывали бизнес-смысл. Было даже пару раз, когда формировали документ автоматически, и не глядя отдавали в разработку. И все получалось. Казалось бы, можно отправлять аналитиков, делающих маппинги, мести улицы

Но на проектах последних 2х лет, завязанных на Agile, с постоянной миграцией команд и кадров, интеграцией банковских платформ по схеме point-to-point, приносящих и уносящих новую семантику проектов, начались проблемы.
Часто спецификой таких проектов является параллельное написание документации. Аналитики не тратят время на глубокую проработку описания полей, а наскоро описывают их, делая упор на разработку схемы сообщения. Часто в описании поля указано 2-3 слова, дающее составление вектора, жестко направленного по ограниченному числу осей в алфавитном пространстве. Например, описанный алгоритм мало чувствителен к соответствию высказываний, состоящих из небольшого числа слов, например: Номер счета и Банковский счет клиента, если в ряду прочих будут высказывания типа номер отделения, номер строения, номер квартиры, то алгоритм векторизации потянется к ним, потому что совпадений по осям больше. Что делать, если у вас с одной стороны приходит 3000 таких вот плохо описанных реквизитов, а с другой готовы принять только 500 и описание также не очень подробное? И как быть с другой возникающей проблемой несовпадении типов передаваемых данных? Вот тут начинается самое интересное. И возникает вопрос, как кластеризовать и разбить на группы эти не поддающиеся какому-либо описанию 3000 реквизитов?

Тогда у меня возникла идея использовать данный алгоритм и кластеризовать все поля по смыслу. Для этого зададим значение разничного вектора или проекции и сгруппируем таким образом те атрибуты, которые пройдут отбор по значениям данных величин. Ведь у нас в руках появляется числовой параметр соответствия одного термина другому. Язык Python позволяет это сделать просто и изящно. У него в арсенале есть так называемые словари. Ключом такого словаря можно сделать сущность делового оборота, которая нас интересует. Назовем её столбовой сущностью. А значением этого словаря будет являться список, состоящий из словарей, в которых ключом уже будет являтся параметр соответствия, а значением соответствующий комментарий к полю.
Вот, например вот так:


{'Номер счета физического лица': [{4.69: 'Банковский счет клиента'}, {6.0: 'Фамилия'}, {4.8: 'Номер металлического счета'}, {4.8: 'Номер клиента'}]}.


Эту схему можно также визуализировать в форме графа. Со словарями в языке Python можно много чего делать Для визуализации и демонстрации результатов мы применяли открытый интернет-проект www.graphonline.ru. Данная платформа позволяет быстро построить граф, записанный через GraphML.

Рисунок 4. Граф взаимосвязи сущности Номер физического лица. Иллюстрация наличия орбит семантического соответствия у сущности.

Если оценивать параметр длины разностного вектора, рассчитанный по формуле (3) и нарисовать граф, отнормировав его по весам, то можно увидеть локальные скученности терминов, вокруг которых можно провести правильную окружность определенного радиуса. Эту окружность мы в своей работе назвали орбитой семантического соответствия или семантической орбитой. Конечно же, велик соблазн сразу же определить радиус такой орбиты методами статистики. В прочем, это задача мало того, что слишком интересна, но и требует дополнительного осмысления. И может стать темой для дальнейшей работы.
Что это такое и что это дает? Допустим, мы в ходе анализа выделяем для нашего делового оборота множество столбовых сущностей или бизнес-объектов. Задаем точность (параметры $\vec{S_1}$ (формула 3) и $\delta$ формула (5)), и прогоняем алгоритм по всем перечным полей. Таким образом, у нас для каждой столбовой сущности подтягивается в словарь перечень атрибутов из списков конечных систем с указанием точности совпадения в процентах. Таким образом, появляется нечто наподобие семантической карты.

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

Рисунок 5. Прототип семантической карты, построенной в виде графа взаимосвязи сущностей с указанием параметра соответствия .

Можно аналитикам и не договариваться, а просто запустить данный метод и сравнить каждый атрибут с каждым. Получить для каждой пары параметр соответствия и кластеризовать, скажем методами кристаллофизики или астрофизики, где механизм кластеризации отработан десятилетиями. И в сущности, какая разница кристалл сегнетоэлектрика или семантическая карта делового оборота банка? Ну почему нет? Ведь что является кластером в данном случае? Кластер атрибутов это совокупность наиболее близко лежащих друг к другу в алфавитном пространстве сущностей. Вот сущности соответствующие друг другу на 80%, допустим, кластер. В прочем, определение количественной характеристики для кластеризации это тема для отдельного исследования. И вообще, это уже совсем другая история но кластеризация бизнес-сущностей и составление семантических карт это в ближайшем будущем очень перспективная вещь. Особенно, в разрезе машинного обучения.

Когда мы стали получать графы взаимосвязи всех комментарий к полям, мы обнаружили, что кластеризация, действительно, имеет место быть. И самое поразительное, что глядя даже на такую, не сильно структурированную Вселенную семантического смысла (рисунок 6), можно наскоро оценить смысл и специфику передаваемых данных. Можно в этой вселенной различить галактики, туманности, скопления, кучкующиеся вокруг какого-то бизнес-смысла. И самое удивительное, что это действительно увеличило скорость анализа в среднем до 30% времени. Визуализация дает возможность быстрее уяснить смысл. А дальше возникла идея проверить, какие изменения в описания позволяют получить более контрастную картину. То есть, не то чтобы создать единое правило формирования описаний, а скорее понять, что должно произойти чтобы произошло полное перемешивание смыслов.


Рисунок 6. Вселенная семантического смысла. Пример построенного графа, иллюстрирующего семантическое пространство типичной модели данных.

Вместо заключения. Как определение семантики происходит зачастую на самом деле.


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

Мне вспомнилась история. Как-то в одном из полков морской пехоты Северного флота замполит решил организовать хор из матросов. Для чего была выписана музработник, для работы с матросами. И вот замполит подумал: Долго что-то репетируют. А, меж тем, последнее воскресение июля все ближе. И научиться петь растаял в далеком тумане Рыбачий надо бы побыстрее. На вопрос, в чем проблема, музработник сказала, что не удается ей никак разбить пятьдесят матросов по высоте вокала на пять тонов. Тогда замполит сказал Не вижу трудностей! На первый-пятый рассчитайсь

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

Я благодарен следующим авторам за труды, без которых не было бы данной статьи:

[1] Б.Я Шведин. Онтология предприятия: экспириентологический подход. УРСС. 2010.

[2]Б. Бенгфорд, Р. Билбро, Т. Охеда. Прикладной анализ текстовых данных на Python.Машинное обучение и создание приложений естественной обработки языка. Спб. Питер, 2019, 368 с.

P.S. Я хотел бы выразить благодарность своим коллегам из компании Accenture Эльвире Самигулиной и Вере Вишняковой за полезные дискуссии относительно данной статьи

Подробнее..

Из песочницы Ищем Троллей. Алгоритм шинглов amp косинусное сходство

25.09.2020 18:15:34 | Автор: admin

Думаю, многие в напряженных дискуссиях в интернете сталкивались с обвинением людей в том, что они боты, тролли и проплачены Кремлем, Киевом или Вашингтоном. Но как действительно выявить таковых или просто людей пытающихся активно донести своё мнение до остальных?

Возьмём, к примеру четыре текста (комментария):

text_1 = 'Комментарий в первой теме характеризующий Михаил Михайловича умным, целеустремленным и ответственным человеком'text_2 = 'Комментарий из второй темы про Михаил Михайловича, описывающий его как умного, ответственного и упорного человека'text_3 = 'Случайный текст похожей длинны с первыми двумя комментариями не несущей какой либо смысловой нагрузки'text_4 = 'Комментарий из другой темы, не касающийся Михаила, но тоже про умного человека, ответственно подходящего к работе'

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

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

В таких моментах оправдано использование Алгоритма шинглов разбивающего текст n частей, размер которых подбирается опытным путём для конкретной задачи.

Пример:

Текст 1 при n = 3
['ком', 'омм', 'мме', 'мен', 'ент', 'нта', 'тар', 'ари', 'рий', 'ий ', 'й в', ' в ', 'в п', ' пе', 'пер', 'ерв', 'рво', 'вой', 'ой ', 'й т', ' те', 'тем', 'еме', 'ме ', 'е х', ' ха', 'хар', 'ара', 'рак', 'акт', 'кте', 'тер', 'ери', 'риз', 'изу', 'зую', 'ующ', 'ющи', 'щий', 'ий ', 'й м', ' ми', 'мих', 'иха', 'хаи', 'аил', 'ил ', 'л м', ' ми', 'мих', 'иха', 'хай', 'айл', 'йло', 'лов', 'ови', 'вич', 'ича', 'ча ', 'а у', ' ум', 'умн', 'мны', 'ным', 'ым ', 'м ц', ' це', 'цел', 'еле', 'леу', 'еус', 'уст', 'стр', 'тре', 'рем', 'емл', 'мле', 'лен', 'енн', 'нны', 'ным', 'ым ', 'м и', ' и ', 'и о', ' от', 'отв', 'тве', 'вет', 'етс', 'тст', 'ств', 'тве', 'вен', 'енн', 'нны', 'ным', 'ым ', 'м ч', ' че', 'чел', 'ело', 'лов', 'ове', 'век', 'еко']


Текст 1 при n = 5
['комме', 'оммен', 'ммент', 'мента', 'ентар', 'нтари', 'тарий', 'арий ', 'рий в', 'ий в ', 'й в п', ' в пе', 'в пер', ' перв', 'перво', 'ервой', 'рвой ', 'вой т', 'ой те', 'й тем', ' теме', 'теме ', 'еме х', 'ме ха', 'е хар', ' хара', 'харак', 'аракт', 'ракте', 'актер', 'ктери', 'териз', 'еризу', 'ризую', 'изующ', 'зующи', 'ующий', 'ющий ', 'щий м', 'ий ми', 'й мих', ' миха', 'михаи', 'ихаил', 'хаил ', 'аил м', 'ил ми', 'л мих', ' миха', 'михай', 'ихайл', 'хайло', 'айлов', 'йлови', 'лович', 'овича', 'вича ', 'ича у', 'ча ум', 'а умн', ' умны', 'умным', 'мным ', 'ным ц', 'ым це', 'м цел', ' целе', 'целеу', 'елеус', 'леуст', 'еустр', 'устре', 'стрем', 'тремл', 'ремле', 'емлен', 'мленн', 'ленны', 'енным', 'нным ', 'ным и', 'ым и ', 'м и о', ' и от', 'и отв', ' отве', 'ответ', 'тветс', 'ветст', 'етств', 'тстве', 'ствен', 'твенн', 'венны', 'енным', 'нным ', 'ным ч', 'ым че', 'м чел', ' чело', 'челов', 'елове', 'ловек', 'овеко']


Рассчитаем сходство первого и второго / первого и четвертого текстов при n (1,9) по формуле:

sim = len(set(Shingles_1) & set(Shingles_2)) / len(set(Shingles_1) | set(Shingles_2)))

ShingleSize: 10.9166666666666666 / 0.7857142857142857ShingleSize: 20.5196078431372549 / 0.40350877192982454ShingleSize: 30.3404255319148936 / 0.2375ShingleSize: 40.28205128205128205 / 0.18497109826589594 ShingleSize: 50.2289156626506024 / 0.13812154696132597ShingleSize: 60.1896551724137931 / 0.10752688172043011ShingleSize: 70.15730337078651685 / 0.07894736842105263ShingleSize: 80.13333333333333333 / 0.057291666666666664ShingleSize: 90.10989010989010989 / 0.04145077720207254

Закономерная картина, при увеличение длины увеличивается общее количество шинглов и падает отношение общих шинглов к совокупному объёму. Так при больших объёмах текстов лучше использовать длину шинглов от 5 до 8, а при работе с короткими, например твиты или комментарии 2-4.

Но вернемся к практике, возьмём предварительно собранные данные, с популярного российского, развлекательного портала. Ссылка на kaggle.

Для сбора максимально жарких дискуссий был выбран тэг (раздел) Политика, итого собрано:

  • 944 поста с тегом политика
  • 267000 комментариев к ним
  • из них длиннее 100 символов ~ 140 тысяч

Перейдем к коду:

Очистка текста и разделение на шинглы:

def clean_text(text):    text = text.split('\n')    text = list(filter(None, text))    text = ' '.join(text)    text = re.sub(r"http\S+", "", text)    text = re.sub(r'[^\w\s]', '', text)    shingle = [text[i:i + ShingleSize] for i in range(len(text))][:-ShingleSize]    return ','.join(shingle)

Если мы берем только комментарии длиннее 100 символов, то количество итераций сравнения составляет: $inline$140000!/((140000 - 2)!*2! )$inline$, что довольно много и обработка даже в мультипоточном режиме займет достаточно продолжительное время.

Поэтому сравнивать будем не попарно, а матрицами m*n, используя косинусное сходство
где m число строк, которое подбирается опционально в зависимости от объёма оперативной памяти, а n число столбцов, общее количество всех шинглов;

Реализация алгоритма:

csrMatrix = []idArray = []textArray = []for i in range(ChunkSize, sparse_matrix.shape[0] + ChunkSize, ChunkSize):    temp = sparse_matrix[i - ChunkSize:i - 1]    idArray.append(corpusId[i - ChunkSize:i - 1])    textArray.append(OriginalCorpus[i - ChunkSize:i - 1])    csrMatrix.append(temp)matrixCombinations = itertools.combinations_with_replacement(range(len(csrMatrix)), 2)

При m = 20000 и длинной шингла = 8, получаем 7 матриц размером 20000 * 8800000 и следовательно 21 итерации сравнения. Уже намного лучше.

def Sim(A, B, C, D):    similarities = cosine_similarity(B[A[0]].astype(np.float32), B[A[1]].astype(np.float32))    x, y = np.where(similarities > similarityPercent)    res = []    for k, j in zip(x, y):        if D[A[0]][k] != D[A[1]][j]:            res.append((D[A[0]][k], C[A[0]][k], similarities[k][j].item(), D[A[1]][j], C[A[1]][j]))    return ress = pool.starmap(Sim, zip(matrixCombinations, itertools.repeat(csrMatrix), itertools.repeat(textArray), itertools.repeat(idArray)))s = [item for sublist in s for item in sublist]

Чтобы уменьшить занимаемый объём используем так же тип данных float32. Его точности вполне хватает для корректной работы алгоритма.

Результаты работы заносятся в MySQL базу, для дальнейшей обработки. Так например сгруппируем комментарии, посчитав для каждого сходство с его парами:

SELECT FirstText, SUM(sim) as c FROM pikabu.similarity GROUP BY FirstId ORDER BY c DESC

Топ совпадений:

  1. Комментарий удален. Причина: данный аккаунт был удалён.
  2. Комментарий удален. Причина: оскорбление пользователей.
  3. Комментарий удален. Причина: оскорбления, грубое общение и провокации.
  4. Комментарий удален. Причина: запрещено размещать комментарии, единственная цель которых вызвать неприязнь или возбуждение вражды, а также запрещены комментарии с призывами к насилию или травле.

Стандартная ситуация для политических дискуссий в интернете.

Отбрасывая ссылки, сообщения администрации, прочий шум переходим непосредственно к анализу смысловой нагрузки комментариев:

Восемь совпадений
DaimosShip,2020-08-14 23:03:48,
Ермошина подтвердила, что Тихановская записывала свое обращение в ее кабинете в ЦИКе
DaimosShip,2020-08-14 23:05:41,
Ермошина подтвердила, что Тихановская записывала свое обращение в ее кабинете в ЦИКе
DaimosShip,2020-08-14 23:05:52,
Ермошина подтвердила, что Тихановская записывала свое обращение в ее кабинете в ЦИКе
DaimosShip,2020-08-14 23:05:26,
Ермошина подтвердила, что Тихановская записывала свое обращение в ее кабинете в ЦИКе
DaimosShip,2020-08-14 23:05:22,
Ермошина подтвердила, что Тихановская записывала свое обращение в ее кабинете в ЦИКе
DaimosShip,2020-08-14 23:07:02,
Ермошина подтвердила, что Тихановская записывала свое обращение в ее кабинете в ЦИКе
DaimosShip,2020-08-14 23:06:53,
Ермошина подтвердила, что Тихановская записывала свое обращение в ее кабинете в ЦИКе
DaimosShip,2020-08-14 23:06:18,
Ермошина подтвердила, что Тихановская записывала свое обращение в ее кабинете в ЦИКе

Человек за пять минут написал 8 одинаковых сообщений в одной и той же теме, касающихся событий в Белоруссии. Всего в базу попало 260 сообщения данного автора, беглый взгляд на них даёт понять явное негативное отношение к ситуации в Белоруссии, так же сам пользователь идёт на опережения и в качестве аргументов сам называет своих оппонентов ботами.

А ещё у него брат был наблюдателем на выборах:

DaimosShip,2020-08-18 22:52:41
У меня брат был наблюдателем никуда не пустили


Ещё 6 совпадений
NoisePanzer,2017-11-20 14:58:26,
Остаётся ещё около 17 миллионов Вермахта и СС.Не буду утверждать точно, но читал немецкого исследователя, он пишет, что 80% вермахта (НЕ СС!) участвовали в актах геноцида и других военных преступлениях.

NoisePanzer,2017-11-20 15:33:26,
Вы не правы. Читал книгу немецкого исследователя о добровольческом батальоне вермахта. Люди (подавляющее большинство!) добровольно шли убивать невиновных. Работ на эту тему, явно доказывающих, что БОЛЬШИНСТВО немцев было не против массовых убийств очень много. Если вы (вполне резонно) не верите мне, ссылки откопаю и приведу вам.

NoisePanzer,2017-11-20 15:26:55,
Нет. Вы не правы. Читал книгу немецкого исследователя о добровольческом батальоне вермахта. Люди (подавляющее большинство!) добровольно шли убивать невиновных. Работ на эту тему, явно доказывающих, что БОЛЬШИНСТВО немцев было не против массовых убийств очень много. Если вы (вполне резонно) не верите мне, ссылки откопаю и приведу вам.

NoisePanzer,2017-11-21 03:51:46,
Нет. Вы не правы. Читал книгу немецкого исследователя о добровольческом батальоне вермахта. Люди (подавляющее большинство!) добровольно шли убивать невиновных. Работ на эту тему, явно доказывающих, что БОЛЬШИНСТВО немцев было не против массовых убийств очень много. Если вы (вполне резонно) не верите мне, ссылки откопаю и приведу вам.

NoisePanzer,2017-11-21 03:52:14,
Нет. Вы не правы. Читал книгу немецкого исследователя о добровольческом батальоне вермахта. Люди (подавляющее большинство!) добровольно шли убивать невиновных. Работ на эту тему, явно доказывающих, что БОЛЬШИНСТВО немцев было не против массовых убийств очень много. Если вы (вполне резонно) не верите мне, ссылки откопаю и приведу вам.

NoisePanzer,2017-11-21 03:53:22,
Читал книгу немецкого исследователя о добровольческом батальоне вермахта. Люди (подавляющее большинство!) добровольно шли убивать невиновных. Работ на эту тему, явно доказывающих, что БОЛЬШИНСТВО немцев было не против массовых убийств очень много. Если вы (вполне резонно) не верите мне, ссылки откопаю и приведу вам.

Автор явно любитель немецкой исторической литературы

И ещё 4
Kumuj,2018-03-25 01:46:10,
Интересная тенденция на Пикабу вырисовывается, последние пару дней замечаю все больше заплюсованых постов с негативным отношением к императору. Неужели фабрика троллей сбавила обороты и мы можем видеть реальные настроения в интернете?

Kumuj,2018-03-25 01:53:56,
Интересная тенденция на Пикабу вырисовывается, последние пару дней замечаю все больше заплюсованых постов с негативным отношением к императору. Неужели фабрика троллей сбавила обороты и мы можем видеть реальные настроения в интернете?

Kumuj,2018-03-25 01:46:26,
Интересная тенденция на Пикабу вырисовывается, последние пару дней замечаю все больше заплюсованых постов с негативным отношением к императору. Неужели фабрика троллей после выборов сбавила обороты и мы можем видеть реальные настроения юзеров в интернете?

Kumuj,2018-03-25 01:42:29,
Интересная тенденция на Пикабу вырисовывается, последние пару дней замечаю все больше заплюсованых постов с негативным отношением к императору. Неужели фабрика троллей сбавила обороты и мы можем видеть реальные настроения в интернете?

Человек ищет следы фабрики троллей. Привет, коллега.

Идём дальше: 6 человек цитируют одну и туже книгу в разных темах - Осторожно, мат!!!
Strannik196,2018-03-21 23:53:00,
на мой взгляд здесь будет кстати цитата из Пелевина:"Так вот, уловка-22 заключается в следующем: какие бы слова ни произносились на политической сцене, сам факт появления человека на этой сцене доказывает, что перед нами блядь и провокатор. Потому что если бы этот человек не был блядью и провокатором, его бы никто на политическую сцену не пропустил там три кольца оцепления с пулемётами. Элементарно, Ватсон: если девушка сосёт хуй в публичном доме, из этого с высокой степенью вероятности следует, что перед нами проститутка. Я почувствовал обиду за свое поколение. Почему обязательно проститутка, сказал я. А может это белошвейка. Которая только вчера приехала из деревни. И влюбилась в водопроводчика, ремонтирующего в публичном доме душ. А водопроводчик взял её с собой на работу, потому что ей временно негде жить. И там у них выдалась свободная минутка.Самарцев поднял палец: Вот на этом невысказанном предположении и держится весь хрупкий механизм нашего молодого народовластия"

Fynjif18,2020-09-09 13:44:56,
Ну что же вы это прям по Пелевину. Правильно, сказал Самарцев. Так вот, уловка-22 заключается в следующем: какие бы слова ни произносились на политической сцене, сам факт появления человека на этой сцене доказывает, что перед нами блядь и провокатор. Потому что если бы этот человек не был блядью и провокатором, его бы никто на политическую сцену не пропустил там три кольца оцепления с пулеметами. Элементарно, Ватсон: если девушка сосет хуй в публичном доме, из этого с высокой степенью вероятности следует, что перед нами проститутка.

wakeonlan,2020-06-23 01:38:29,
уловка-22 заключается в следующем: какие бы слова ни произносились на политической сцене, сам факт появления человека на этой сцене доказывает, что перед нами б**дь и провокатор. Потому что если бы этот человек не был б**дью и провокатором, его бы никто на политическую сцену не пропустил там три кольца оцепления с пулеметами. Элементарно, Ватсон: если девушка сосет х*й в публичном доме, из этого с высокой степенью вероятности следует, что перед нами проститутка.

KKirill1992,2017-06-18 00:06:30,
Знаете, в книге Хеллера "Уловка-22" есть один персонаж по имени Орр. Так вот, он прикидывался идиотом, но только для того, чтобы спасти себе жизнь. Это я понимаю.Но вы-то с какой целью прикидываетесь идиотом в комментариях на пикабу? У вас что, за спиной стоит фсбшник с волыной?

nezabuddha,2018-11-01 15:29:56,
ru.m.wikipedia.org/wiki/Уловка-22 Нет. Пелевин лишь цитирует принцип, описанный гораздо раньше.

ihateyou,2016-09-19 02:52:14,
Так вот, уловка-22 заключается в следующем: какие бы слова ни произносились на политической сцене, сам факт появления человека на этой сцене доказывает, что перед нами блядь и провокатор. Потому что если бы этот человек не был блядью и провокатором, его бы никто на политическую сцену не пропустил там три кольца оцепления с пулеметами. Элементарно, Ватсон: если девушка сосет хуй в публичном доме, из этого с высокой степенью вероятности следует, что перед нами проститутка. Я почувствовал обиду за свое поколение. Почему обязательно проститутка, сказал я. А может это белошвейка. Которая только вчера приехала из деревни. И влюбилась в водопроводчика, ремонтирующего в публичном доме душ. А водопроводчик взял ее с собой на работу, потому что ей временно негде жить. И там у них выдалась свободная минутка. Самарцев поднял палец: Вот на этом невысказанном предположении и держится весь хрупкий механизм нашего молодого народовластияПелевин "Empire V"

Автор пытается донести до остальных данные о росте уровня поддержки СССР
EtovamneTo,2020-08-18 01:50:22,
Наверное то, что реальность противоположна твоим словам точно не потому что ты здесь откровенно врешь в надежде на то, что сонмы таких же малолетних пизд Совков тебя заплюсуют.По данным опроса Левады центра уровень поддержки СССР сильно вырос за два десятилетия. Сильнее всего у тех, кому сейчас 18-24 годаВне зависимости от того, как мы разбиваем совокупность респондентов, наиболее сильный рост поддержки от 2008-го к 2019-му году фиксируется в отношении двух позиций, характеризующих Советский Союз как государство социальной справедливости и патернализма. Наиболее заметные изменения в поддержке фиксируются в молодежной средеОдно из самых устойчивых представлений, характеризующих положение дел в Советском Союзе, это представление населения о дружбе народов, поддержка которого во всех трех опросах находилась на идентичном уровне. Уверенность в отсутствии межнациональных конфликтов всегда входила в тройку самых популярных суждений о СССР. При этом, например, вопросы о депортации народов в советский период давали высокую долю затруднившихся ответить до трети, что является свидетельством незнания этой страницы в истории своей страны (среди 18-24-летних более половины уходят от содержательного ответа на вопросы о депортациях). Если, напротив, обратиться к суждениям, заметно теряющим поддержку, то на первом месте среди них направляющая роль коммунистической партии (на 14 п.п.) и очереди, дефицит, карточки (на 18 п.п.).https://www.levada.ru/2019/06/24/chernovik/

EtovamneTo,2020-08-18 00:50:15,
Каждый раз, когда я кидаю пруфы, я получаю только тишину, оскорбления и демагогию от коммунистов, изучивших историю страны по выпускам Гоблина и пикабушечкам. Естественно, ни и какой культуре или адекватном уровне IQ речи там и нет.Вот вы посмотрите: комментатор выше ничем не подкрепляет свои слова. А теперь посмотрим это: По данным опроса Левады центра уровень поддержки СССР сильно вырос за два десятилетия. Сильнее всего у тех, кому сейчас 18-24 годаВне зависимости от того, как мы разбиваем совокупность респондентов, наиболее сильный рост поддержки от 2008-го к 2019-му году фиксируется в отношении двух позиций, характеризующих Советский Союз как государство социальной справедливости и патернализма. Наиболее заметные изменения в поддержке фиксируются в молодежной средеОдно из самых устойчивых представлений, характеризующих положение дел в Советском Союзе, это представление населения о дружбе народов, поддержка которого во всех трех опросах находилась на идентичном уровне. Уверенность в отсутствии межнациональных конфликтов всегда входила в тройку самых популярных суждений о СССР. При этом, например, вопросы о депортации народов в советский период давали высокую долю затруднившихся ответить до трети, что является свидетельством незнания этой страницы в истории своей страны (среди 18-24-летних более половины уходят от содержательного ответа на вопросы о депортациях). Если, напротив, обратиться к суждениям, заметно теряющим поддержку, то на первом месте среди них направляющая роль коммунистической партии (на 14 п.п.) и очереди, дефицит, карточки (на 18 п.п.).https://www.levada.ru/2019/06/24/chernovik/

EtovamneTo,2020-08-27 23:22:35,
Нет. Сейчас социалисты те самые малолетние дол*****(с). А это еще в статистику нельзя включать людей моложе 18 лет.По данным опроса Левады центра уровень поддержки СССР сильно вырос за два десятилетия. Сильнее всего у тех, кому сейчас 18-24 годаВне зависимости от того, как мы разбиваем совокупность респондентов, наиболее сильный рост поддержки от 2008-го к 2019-му году фиксируется в отношении двух позиций, характеризующих Советский Союз как государство социальной справедливости и патернализма. Наиболее заметные изменения в поддержке фиксируются в молодежной средеОдно из самых устойчивых представлений, характеризующих положение дел в Советском Союзе, это представление населения о дружбе народов, поддержка которого во всех трех опросах находилась на идентичном уровне. Уверенность в отсутствии межнациональных конфликтов всегда входила в тройку самых популярных суждений о СССР. При этом, например, вопросы о депортации народов в советский период давали высокую долю затруднившихся ответить до трети, что является свидетельством незнания этой страницы в истории своей страны (среди 18-24-летних более половины уходят от содержательного ответа на вопросы о депортациях). Если, напротив, обратиться к суждениям, заметно теряющим поддержку, то на первом месте среди них направляющая роль коммунистической партии (на 14 п.п.) и очереди, дефицит, карточки (на 18 п.п.).https://www.levada.ru/2019/06/24/chernovik/

EtovamneTo,2020-09-10 03:32:13,
Каких? что популярность тематики резко выросла? Погугли тег СССР с рейтингом выше 25.За август 2010 было 44 таких поста.За август 2020 было 274 таких поста.Или что среди молодежи? Да вотПо данным опроса Левады центра уровень поддержки СССР сильно вырос за два десятилетия. Сильнее всего у тех, кому сейчас 18-24 годаhttps://www.levada.ru/2019/06/24/chernovik/

EtovamneTo,2020-09-09 19:00:42,
По данным опроса Левады центра уровень поддержки СССР сильно вырос за два десятилетия. Сильнее всего у тех, кому сейчас 18-24 годаВне зависимости от того, как мы разбиваем совокупность респондентов, наиболее сильный рост поддержки от 2008-го к 2019-му году фиксируется в отношении двух позиций, характеризующих Советский Союз как государство социальной справедливости и патернализма. Наиболее заметные изменения в поддержке фиксируются в молодежной средеОдно из самых устойчивых представлений, характеризующих положение дел в Советском Союзе, это представление населения о дружбе народов, поддержка которого во всех трех опросах находилась на идентичном уровне. Уверенность в отсутствии межнациональных конфликтов всегда входила в тройку самых популярных суждений о СССР. При этом, например, вопросы о депортации народов в советский период давали высокую долю затруднившихся ответить до трети, что является свидетельством незнания этой страницы в истории своей страны (среди 18-24-летних более половины уходят от содержательного ответа на вопросы о депортациях). Если, напротив, обратиться к суждениям, заметно теряющим поддержку, то на первом месте среди них направляющая роль коммунистической партии (на 14 п.п.) и очереди, дефицит, карточки (на 18 п.п.).https://www.levada.ru/2019/06/24/chernovik/

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

GitHub

P.S. Обработка матрицы 140000 * 8800000 заняла примерно 7 минут на процессоре rayzen 5 1600

В дальнейшем планирую продолжать данную тему, буду рад критике и предложениям.
Подробнее..

Токсичность модное слово или реальная проблема?

19.07.2020 00:15:31 | Автор: admin
Слова токсичный, токсичность до сравнительно недавнего времени употреблялись практически только в значении, которое получили еще в древней Греции, где их исходный вариант относился к яду (тогда конкретно, к используемому для стрел). В последнее время же эти слова стали все чаще использоваться применительно к поведению людей. Появление нового термина или расширение значения старого всегда очень любопытный культурно-языковой процесс, на который я предлагаю обратить внимание.

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

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

Несколько позже финансистов, люди стали использовать выражения токсичное поведение, токсичная личность, говоря о разных негативных явлениях социальных отношений. Это выражение стало модным сначала в англоязычной среде, а затем, в виде кальки, перекочевало и в другие. Русский язык не исключение. Например, поиск по Хабру показывает порядка тысячи вхождений подобных выражений. Здесь есть даже пользователь с ником Токсичный Дед. Почему я считаю, что это может быть достойно внимания читателей Хабра? Потому, что IT-индустрия точно также подвержена распространению этого термина, как другие, если не больше благодаря более интенсивной коммуникации с англоязычной культурной средой. И термин токсичный уже много раз можно было встретить в описаниях нашумевших историй из мира IT. Например, поиск по ключевым словам Linus Torvalds toxic возвращает почти полмиллиона результатов. Тогда как если я прав в том, что собираюсь описать далее, употребление этого слова может либо преувеличивать, либо размывать значение реальной проблемы, что вовсе не способствует ее практическому решению. Мое личное внимание эти выражения привлекли тем, что в том, как и почему их употребляют, заметны определенные универсальные свойства и тенденции, на которые я и предлагаю взглянуть, чтобы сделать самостоятельные выводы.

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

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

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

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

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

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

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

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

Некоторые спорные размышления над работой Г. Фреге Смысл и денотат

28.08.2020 18:19:00 | Автор: admin
Термины значение (meaning) и выражать не были введены в качестве
основных терминов семиотики в связи с тем, что они нас только
многозначны и используются настолько по-разному, что лучше было бы
вообще не использовать их в качестве основных терминов при обсуждении
семиотических проблем. Но при желании их, разумеется, можно ввести,
опираясь на более фундаментальные семиотические термины. Так, можно было
бы сказать, что значение знака это его значение-сигнификация и
интерпретанта одновременно, но ни одно из них в отдельности.

Моррис Ч.У. Значение и означивание

В этом небольшом эссе я поделиться с читателем своими размышлениями,
возникшими при прочтении работы Г. Фреге Смысл и денотат[1].


Слабонервных прошу не читать статью (да к тому же написанную 9 лет назад)!


В целом эту работу можно условно разделить на четыре основных части: в
первой, Г. Фреге размышляет над понятием тождества двух имен; во второй,
он обращается к определениям основных понятий семиотики; в третьей
пытается определить денотат предложения. Четвертая часть, пожалуй, самая
спорная во всей этой работе, состоит в попытке подобрать грамматические
аргументы в пользу своей идеи относительно денотата предложения.


1. Основные понятия


Начинает Г. Фреге свою работу с анализа символических утверждений:


a=a


и


a=b.


И ставит по отношению к ним следующий вопрос: Является ли тождество
отношением? Если да, то является ли оно отношением между вещами или
отношением между именами, или знаками, вещей?. И сам же на него
отвечает: Для моего идеального языка я принял второе положение. Тем
самым Г. Фреге утверждает, что данные тождества устанавливают отношения
между знаками aиb. Чем же он это обосновывает?


Для доказательства своего выбора Г. Фреге приводит следующие аргументы:


1. Выражение вида а = а (Кант назвал их аналитическими) истинны a
priori, в то время как истинность выражений вида а = b далеко не всегда
очевидна, и именно поэтому в выражениях вида а = b могут содержаться
существенно обогащающие нас сведения. ....


2. Если же считать, что тождество это отношение между вещами,
обозначаемыми посредством букв а и b, тогда а = b ничем не отличается от
а = а (если, конечно, а = b истинно). Действительно, в этом случае, а =
b выражало бы отношение вещи к самой себе и притом такое отношение,
которое возможно только между вещью и ею же самой, но не между разными
вещами. .


С этим можно было бы согласиться, но встает резонный вопрос: не
вкладываем ли мы при этом в отношение .=. только один из возможных
смыслов, а именно отношение полной эквивалентности всех признаков а и b.
Если же мы вкладываем в отношение .=. эквивалентность любой (или
некоторой фиксированной) части (совокупности) признаков объектов, то
тождества


a=a


и


a=b


могут рассматриваться как тождественность объектов. Такое их понимание
становятся согласованными и допустимым, поскольку при таком понимании
данных тождеств, они могут


  1. указывать на понимание участвующих объектов как экземпляров
    некоторого класса;


  2. указывать на их принципиальную эмпирическую неразличимость (и не
    только из-за эмпирической недоступности для наблюдения различающих
    их признаков);


  3. указывать на возможность использования имени a вместо имени b.



В этом контексте можно сослаться в качестве примеров на возможность
рассуждения в математике о числах, классах эквивалентности и др., в
физике о принципе тождественности квантовых объектов и пр.[2]


Ну, хорошо Вернемся к этому вопросу позже, а теперь продолжим
рассмотрение той интерпретации которую предлагает Г. Фреге: Однако,
утверждая, что a=b, мы скорее имеем в виду, что знаки, или имена,
а и b обозначают одно и то же, следовательно, речь идет именно об
этих знаках, то есть отношением тождества связаны именно знаки. . Итак
мы имеем следующие важные положения теории Г. Фреге:


1. знаки и имена синонимы.


2. в тождестве a=b утверждается, что нечто существующее может
быть поименовано (названо) двумя различными именами а и b.


Первое важно для нас как утверждение о том, что знак представляет
собой имя, а не то что имя есть одна из сторон или признаков
знака. Второе можно принять как одну из допустимых или возможных
интерпретаций отношения тождества в контексте данной работы Г. Фреге:
При этом имена (или знаки) находятся в указанном отношении лишь
постольку, поскольку они что-то называют или обозначают: тождество двух
знаков устанавливается путем соотнесения каждого из них с одним и тем же
обозначаемым. А соотнесение это произвольно: ведь всякий имеет право
считать любое произвольно выбранное событие или вещь знаком для чего
угодно. Тогда получается, что выражение а = b касается уже не сути дела,
а только принятого нами способа обозначения: в таком случае с помощью
подобных выражений мы не могли бы передавать полезную информацию. Однако
ведь именно этого мы чаще всего и хотим. .


Фреге рассматривает следующий пример: Пусть а, b, с прямые,
соединяющие вершины треугольника с серединами противолежащих сторон;
тогда справедливо (1):


(1). Точка пересечения а и b совпадает с точкой пересечения b и с.


Таким образом, мы, строго говоря, имеем две точки:


(2). AB точку пересечения прямых a и b;


(3). BC точку пересечения прямых b и c.



Рисунок 1. Рисунок к примеру Г. Фреге


Тогда утверждение (1) может быть выражено (записано) точно также как и
тождество, рассматриваемое выше:


AB = BC


Из этого Г. Фреге делает вывод: Таким образом, одной точке
соответствуют два разных обозначения или имени. Эти имена (точка
пересечения прямых а и b, точка пересечения прямых b и с) указывают и на
разные способы представления обозначаемого; поэтому в предложении (1)
заключено подлинное знание.


Но, строго говоря, мы можем говорить и о другой интерпретации:
местоположение точек AB и BC совпадают. И в этом смысле, мы должны
говорить об определенном классе эквивалентности точек, которому
сопоставлены точки AB и BC и экземплярами которого они являются. Мы
можем заявлять о факте слияния этих точек. Таким образом, мы можем и в
данном случае говорить для данного тождества как о предметной
(объектной) эквивалентности.


Для чего же это необходимо Фреге? Опирая на эти рассуждения, позволяет
Г. Фреге ввести некоторые понятия семиотики, а, именно, денотат и
смысл: Таким образом, становится ясно, что знак как таковой (будь то
слово, словосочетание или графический символ) может мыслиться не только
в связи с обозначаемым, то есть с тем, что можно было бы назвать
денотатом знака [Bedeutung], но и в связи с тем, что мне хотелось бы
назвать смыслом знака [Sinn]; смысл знака это то, что отражает
способ представления обозначаемого данным знаком. И далее: Из
сказанного следует, что под знаком (или именем) я понимаю любое
обозначение, выступающее в роли имени собственного; денотатом знака
является определенная вещь (в самом широком смысле слова), но не понятие
или отношение, которым будет посвящено отдельное исследование.
Обозначение одной вещи может состоять из нескольких слов или иных
знаков. Для краткости мы будем называть такие обозначения именами
собственными.


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


Здесь мне бы хотелось привести следующую графическую иллюстрацию
собственного понимания этих слов Г. Фреге с использованием нотации
UML[3] (см. Рисунок 2 и Рисунок 3).



Рисунок 2. Графическая иллюстрация отношений между обозначаемым (денотатом) и его именем



Рисунок 3. Альтернативная графическая иллюстрация отношений между обозначаемым (денотатом) и его именем


Итак, смысл это устанавливаемое (или интерпретируемое) отношение между
именем и денотатом. Для нас важно также понять какую кратность могут
иметь роли этого отношения. Из предшествующих рассуждений мы можем
прийти к выводу, что денотат может иметь несколько имен (то, что в
лингвистике называется синонимией). Поэтому мы можем уточнить рисунок 2
образом, представленном на следующем рисунке (см. Рисунок 4):



Рисунок 4. Отношение между денотатом и его именем, с указанием возможной синонимии


Таким на данный момент мы видим отношение (смысл) денотата и его имени:


1. каждому имени должен соответствовать один и только один денотат;


2. у одного денотата может иметься несколько имен.


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


1. Может ли одно и то же имя называть несколько различных денотатов?


2. Может ли имя ничего не обозначать или ему должно должен
соответствовать хотя бы один денотат?


3. Может ли существовать денотат без имени?


Попробуем получить ответ на первый вопрос. Г. Фреге пишет: В идеале
соответствие между знаками, смыслами и денотатами должно быть устроено
таким образом, чтобы всякому знаку всегда соответствовал один
определенный смысл, а всякому смыслу, в свою очередь, всегда
соответствовал один определенный денотат; в то же время денотату (вещи)
может соответствовать не один смысл, а несколько, и один и тот же смысл
может выражаться разными знаками не только в разных языках, но и в
пределах одного и того же языка. Пока Г. Фреге не сказал нам ничего из
того, чего бы ни было показано на вышеприведенном рисунке (см. Рисунок
4). Но в том же абзаце, он пишет: Разумеется, в действительности
указанное соответствие часто нарушается. Как было только что сказано, в
идеальной знаковой системе всякому выражению должен соответствовать
только один определенный смысл; однако естественные языки далеко не
всегда удовлетворяют этому требованию: редко бывает так, чтобы слово
всегда имело один и тот же смысл в разных контекстах. Итак, мы получили
ответ на первый из интересующих нас вопросов:


  • одному и тому же имени в разных контекстах могут
    соответствовать различные денотаты.

На второй вопрос, мы просто так ответа у Г. Фреге не получим. В
указанном абзаце своей работы он пишет: Далее, хотя можно предполагать,
что любому грамматически правильному выражению, выступающему в роли
имени собственного, всегда соответствует некоторый смысл, вовсе не
всякому смыслу соответствует некоторый денотат. И в качестве примеров
следующие выражения:


  • наиболее удаленное от земли небесное тело.


  • ряд, сходящийся медленнее любого другого ряда.



Можно продолжить эти примеры, приведя множество подобных абстракций:


  • вечный двигатель.


  • круглый квадрат



и т.п.


Приведенные примеры Г. Фреге резюмировал следующим образом: Таким
образом, даже если смысл имени очевиден, денотата у него может и не
быть. Но, что-то все равно на этом конце отношения Смысл должно
соответствовать имени?! Хорошо, пусть это будет не объект реального
мира, не предмет, но возможно некоторая абстракция, некоторый концепт,
некая мысль, идея, некоторая сущность понимаемая, воспринимаемая или
репрезентируемая человеческой психикой? Ответа у Г. Фреге пока мы не
находим. Поэтому временно примем, без четкого определения и интуитивно
представляемое расширенное понимание термина денотат, включающего в
себя не только предметы реального мира, но и предметы мира модельного,
нереального. Возможно, нам в последующем придется ввести некоторые
разновидности денотата или отнести его как разновидность некоторого
другого суперкласса (понятию). Но сейчас это позволит нам принять
следующий ответ на второй вопрос:


  • одному и тому же имени в разных контекстах должен обязательно
    соответствовать один или более различных денотатов.


  • одному и тому же денотату могут соответствовать несколько имен.



В этом случае нам потребуется переработать нашу графическую модель
следующим образом (см. Рисунок 5):



Рисунок 5. Модель Денотат-Смысл-Имя


Представлениям Г. Фреге будет соответствовать следующая модель (см.
Рисунок 6):



Рисунок 6. Модель Денотат-Смысл-Имя по Г. Фреге


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


Если мы попытаемся найти ответ на третий вопрос, то можно убедиться что
любой ответ на него содержит в себе парадокс! Действительно, попробуем
предположить, что существует некий предмет, для которого нет имени. И,
это вполне реальная ситуация, когда люди сталкиваются с предметами и
явлениями, для которых у них нет имени (например, дети). Но тогда мы
могли бы дать ему имя Денотат, не имеющий имени. А поэтому, он
оказывается поименованным (обозначенным), а, следовательно, для него не
надо давать имени и т.д. В некотором смысле это абсурд.


Реальность, конечно же, лишена таких парадоксов: непоименованные вещи
вызывают у нас интерес и для классов таких вещей в языке, как правило,
уже имеются специальные общие имена нечто, некто и т.п. Сами
денотаты мы относим к классу сущностей, для которых отсутствуют имена,
а подобные вещи образуют экстенсионал этого класса до поры до
времени, пока им не придумают новое слово. Дети же, начинают сами или с
помощью взрослых осваивать мир имен, прежде всего придумывая и
присваивая осваиваемым предметам реального мира свои собственные
индивидуальные имена.


Поэтому можно принять в качестве ответа на третий вопрос следующее
утверждение:


  • любому денотату соответствует хотя бы одно имя.

Поэтому на это итерации мы должны получить следующую версию модели (см.
Рисунок 7):



Рисунок 7. Модель Денотат-Смысл-Имя с учетом полученных ответов


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



Рисунок 8. Модель Денотат-Смысл-Имя с учетом декомпозиции отношения Смысл


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


У нас остался не проясненным вопрос о ролях установленных отношений
Денотат-Смысл и Имя-Смысл. Но от него пока отвлечемся и возможно
вернемся к нему уже в другой работе.


У нас еще остается один интересный вопрос, содержащийся в примечании
переводчика к использованию Г. Фреге термина денотат:


Буквальный перевод слова Bedeutung значение, смысл. Однако, по ряду
причин, главным образом потому, что здесь Bedeutung употребляется в
смысле денотат, мы предпочли именно этот вариант перевода. Прим.
перев..


Это означает, что реально Г. Фреге мог говорить не о денотате как
предмете реального мира, а значениях имен реального мира! И
только установка переводчика на интерпретацию Bedeutung как денотат в
переводе приводит к иным смыслам. Автор все же надеется что это не так
Однако, это дает ему надежду, поименовать одну из ролей отношения
Денотат-Смысл. Мы могли бы, например, обозначить один из концов этого
отношения как значение (см. Рисунок 9).



Рисунок 9. Модель Денотат-Смысл-Имя с указанием некоторых ролей отношений Денотат-Смысл и Смысл-Имя


На предшествующих рисунках (см. Рисунок 9) мы также видим наличие
дополнительного отношения агрегации. Оставим это отношение пока без
дальнейшего рассмотрения.


Далее Г. Фреге переходит к следующей части своей работы, в которой
освещает свое понимание денотата предложения.


2. Денотат предложения


В начале Г. Фреге напоминает, что им понимается под денотатом слова:
Когда мы употребляем слово обычным образом, его денотат это то, что
мы имеем в виду. И это не расходится с тем, что мы приняли в качестве
рабочей гипотезы ранее.


Но вот что он пишет о предложениях (прежде всего оформленных в виде
прямой речи): Однако иногда нам требуется сказать что-либо о самих
словах или об их смысле, например, когда мы передаем чужие слова
посредством прямой речи. Тогда прямая речь, то есть произносимые нами
слова, обозначает, прежде всего чужие слова слова другого лица, и
только эти последние имеют обычный денотат. Слова в прямой речи это
знаки знаков. На письме в таких случаях изображения слов [Wortbilder]
заключают в кавычки, а изображению слова, заключенному в кавычки, нельзя
приписывать обычный денотат соответствующего слова.


Практически Г. Фреге не ничего конкретного сказал, а самое главное не
прояснил сказанное. Что же, попробуем это сделать за него Итак он
пишет:


1. Прямая речь есть произносимые нами слова, обозначающие чужие
слова, т.е. некоторого третьего лица.


2. Чужие слова имеют обычный денотат.


3. Слова в прямой речи это знаки знаков.


4. Изображению слова, заключенному в кавычки, нельзя приписывать
обычный денотат соответствующего слова.


Разберем первые тезис.


Итак, при передаче прямой речи индивид выступает в качестве
ретранслятора, в буквальном смысле, воспроизводящем чужую речь. В этом
случае он выступает как бы в роли этого третьего лица, подменяет
отсутствующие при этом третье лицо и адресат в этот момент должен
воспринимать его как это третье лицо. Только в этом случае может быть
верен второй тезис Г. Фреге: чужие слова имеют обычный денотат[4]. С
этим можно согласиться лишь в таком простом контексте.


Но почему тогда Слова в прямой речи это знаки знаков.? С целью
анализа смысла этого выражения заменим в нем слово знак на слово
имя: Слова в прямой речи это имена имен.. Пока мы продолжаем
ничего не понимать. Попробуем оставить на время наш анализ и перейдем к
четвертому тезису.


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


  • прямой речи чужим словам, заключенным в кавычки, а


  • чужие слова имеют обычный денотат?



Строго говоря, мы столкнулись с противоречивым высказыванием. Тогда,
скорее всего, четвертый тезис относится не к закавыченному предложению,
а к отдельному слову (словосочетанию) заключенному в кавычки и
размещенному в речи или тексте первого лица (адресанта). Это более
привычная ситуация. В этом случае более вероятно проявление у
закавыченного слова или словосочетания иного смысла или иного денотата.
Но тогда надо говорить о косвенном смысле и косвенном денотате. Что и
делает Г. Фреге дальше: Желая говорить о смысле выражения А, мы можем
прибегнуть к словосочетанию смысл выражения А. Например, чтобы
сообщить что-либо о смысле сказанного третьим лицом, мы пользуемся
косвенной речью. Ясно, что и в этом случае словам, выступающим в
косвенной речи, тоже нельзя приписывать их обычный денотат, ибо в роли
последнего выступает их обычный смысл. Для краткости мы будем говорить,
что в косвенной речи слова выступают в косвенном употреблении и имеют
косвенный денотат. Таким образом, мы будем различать у слов обычный
денотат и косвенный денотат, обычный смысл и косвенный смысл. Косвенный
денотат слова совпадает с его обычным смыслом. Возможность косвенного
употребления слов надо постоянно иметь в виду при установлении
соответствий между знаком, смыслом и денотатом..


Итак, Г. Фреге выделяет следующие разновидности денотатов:


  • обычный денотат,


  • косвенный денотат



и соответствующие им разновидности смысла


  • обычный смысл,


  • косвенный смысл.



Вызывает интерес дальнейшее уточнение денотата и смысла:


Смысл и денотат знака следует отличать от соответствующего этому знаку
представления. Если денотат знака это вещь, данная нам в ощущениях, то
мое представление об этой вещи есть внутренний образ, возникший у меня
на основе моих впечатлений от этой вещи, а также в результате моей
деятельности, физической и мыслительной, связанной с этой вещью[5].
Образ-представление, часто бывает пропитан эмоциями, отдельные его части
могут быть более или менее расплывчатыми. Более того, не всегда, даже
для одного человека, определенное представление связано только с одним
смыслом. Представление (внутренний образ) всегда субъективно оно
меняется от человека к человеку. Отсюда проистекает многообразие
различных представлений, сопряженных с одним и тем же смыслом. У
художника, наездника и зоолога с именем Буцефал будут связаны,
вероятно, очень разные представления. Этим представление существенно
отличается от смысла знака, который может быть общим достоянием, а не
просто частью опыта одного человека. Именно благодаря смыслам знаков
человечество сумело накопить общий багаж знаний и может передавать его
от поколения к поколению[6]..


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


Буквальный перевод слова Bedeutung значение, смысл. Однако, по ряду
причин, главным образом потому, что здесь Bedeutung употребляется в
смысле денотат, мы предпочли именно этот вариант перевода. Прим.
перев..


Перед нами в таком случае встает вопрос: а не использовал ли до этого
момента Г. Фреге слово Bedeutung как слово значение? Вполне
возможно, но тогда и нам необходимо это использовать: что если вместо
отношения Денотат-Смысл использовать отношение Значение-Смысл, а
разновидностями Значения сделать Денотат и Представление? В этом автор
видит свой резон. Итак, мы приходим к следующей итерации нашей модели
(см. Рисунок 10), которую можно было бы назвать Имя-Смысл-Значение.



Рисунок 10. Модель Имя-Смысл-Значение


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


  • денотаты как вещи, данные нам в ощущениях; предметы объективной
    реальности.


  • представления как психические феномены, внутренние образы
    индивидов.



Что касается представлений, то Г. Фреге говорит следующее: Разные люди
могут одинаково воспринимать один и тот же смысл, однако одинаковых
представлений у разных людей быть не может. Si duo idem faciunt, non est
idem (даже если два человека представляют себе одно и то же, у каждого
будет свое собственное представление). Хотя иногда и удается уловить
разницу между представлениями или восприятиями разных людей, точное
сравнение представлений невозможно, так как разные представления нельзя
иметь одновременно в одном сознании.. И с этим можно согласиться.


Но автор эссе не может принять следующее за этим пояснение Г. Фреге об
отношении между денотатом и представлением: Между денотатом и
представлением располагается смысл не столь субъективный, как
представление, но и не совпадающий с самой вещью, то есть с денотатом.
Поясним это соотношение следующим примером. не может выстраиваться
такое отношение между денотатом и представлением, поскольку
однозначно они имеют отношения с именами, знаками, о чем в этом же
абзаце Г. Фреге говорит: Денотат собственного имени это, как мы уже
говорили, сама вещь, которую оно обозначает. Что же касается
представления, связанного с данным именем, то оно абсолютно субъективно.
. Хотя бы неплохо было обозначить некоторую связь между объективной
реальностью и ее представлением в психике (см. Рисунок 11).



Рисунок 11. Модель Имя-Смысл-Значение с учетом отношения отражения реальности в психике


Принятую нами классификацию Значений подтверждает и сам Г. Фреге: Таким
образом, можно было бы показать, что и само представление может
рассматриваться как вещь, то есть как предмет наблюдения. Заметим,
однако, что представление в этом своем новом качестве воспринимается
наблюдателем совсем не так, как оно воспринимается непосредственно
субъектом представления. Впрочем, продолжение этого сравнения может
завести нас слишком далеко..


Далее Г. Фреге возвращается к анализу смыслов предложений: Итак, можно
усматривать три степени различия между выражениями[7] (словами,
словосочетаниями и целыми предложениями): различие затрагивает либо
только представление, либо смысл, но не денотат, либо, наконец, и смысл
и денотат. Поскольку, слово не имеет четкой связи с представлением, для
первой степени могут существовать различия, улавливаемые одними, но не
замечаемые другими говорящими.. С моей точки зрения, хотелось бы
уточнить сказанное Г. Фреге: поскольку слово не имеет четкой связи со
своим значением (как денотатом, так и с представлением), то при попытке
поверхностного понимания могут существовать различия в их значениях,
улавливаемые одними, и не замечаемые другими говорящими.


Можно полностью согласиться со словами Г. Фреге о роли неоднозначности
связи между именем и смыслом в литературном творчестве: Разница между
переводом и оригиналом не должна, вообще говоря, выходить за пределы
первой степени различия. Сюда же относятся различные нюансы и разная
стилистическая окраска, которые придаются смыслу в поэзии и вообще в
художественном тексте. Эти нюансы не объективны: читатель или слушатель
должен сам воссоздавать их для себя по намекам поэта или оратора. Если
бы представления разных людей не были в достаточной степени сходны,
словесное искусство, видимо, не могло бы существовать. Однако точно
установить, насколько представления читателей отвечают замыслам автора,
невозможно..


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


Возвращаясь к вопросу о смысле целого повествовательного предложения, Г.
Фреге пишет: Такое предложение всегда содержит (выражает) некоторое
суждение [Gedanke]. А под суждением Г. Фреге понимает: не
субъективную деятельность мышления, а его объективное содержание,
способное быть достоянием многих.. Итак: целое повествовательное
предложение содержит некоторое объективное содержание, способное быть
достоянием многих.


Г. Фреге дальше ставит вопрос: Должны ли мы рассматривать это суждение
как смысл или как денотат соответствующего предложения?


С моей точки зрения это достаточно странный вопрос. Как мы уже
выясняли, точнее во-первых, смысл и значение настолько тесно
связаны, что одно без другого не существует, как не существует
несвязанных смыслов и имен[8]; во-вторых, наверно, главное содержание
этого вопроса все-таки сводится к тому, что является значением смысла
простого предложения: денотат или представление, или какую форму
приобретает его денотат, что он из себя представляет?[9]


В попытке получить ответ на свой вопрос Г. Фреге, предлагает
использовать следующий метод: Предположим, что у данного предложения
есть денотат. Заменим в нем некоторое слово на другое слово с тем же
денотатом, но с другим смыслом; это никак не должно повлиять на денотат
предложения в целом.. Для своего рассуждения Г. Фреге использует
следующие модельные предложения:


Утренняя звезда это небесное тело, освещаемое солнцем


и


Вечерняя звезда это небесное тело, освещаемое солнцем.


К ним можно добавить и такое:


Венера это небесное тело, освещаемое солнцем.


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


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


Но Г. Фреге волнует вопрос о денотате предложения: Но что же тогда
считать денотатом предложения? И, вообще, имеется ли у предложения какой
бы то ни было денотат? Может быть, у предложения в целом есть только
смысл, но нет денотата? Во всяком случае, можно ожидать, что найдутся
предложения, которые так же как и некоторые их части имеют смысл, но
не имеют денотата..


В качестве примера такого предложения Г. Фреге приводит следующее:


Одиссея высадили на берег Итаки в состоянии глубокого сна.


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


Но как видно из дальнейшего, не признания возможности отсутствия
объективных смыслов (суждений) добивается Г. Фреге данными
рассуждениями: его волнует вопрос о том, как мы понимаем друг друга,
обмениваясь предложениями не имеющих денотатов (как предметов реального
мира или ссылок на них)? И он стремится найти этот денотат (или их
класс): Можно было бы вообще считать, что доискиваться до денотата
имени излишне: если бы нас интересовало только суждение, выраженное в
предложении, можно было бы довольствоваться знанием смысла. Ведь если
рассматривать только смысл предложения, то есть суждение, то незачем
заниматься денотатами отдельных его частей; для смысла предложения важны
только смыслы его частей, а не их денотаты; суждение не изменится от
того, имеет слово Одиссей денотат или нет. Однако сам факт, что нас
волнует вопрос о денотатах отдельных частей предложения, указывает на
то, что мы в общем случае предполагаем наличие денотата и у предложения
в целом. Суждение теряет для нас всякую ценность, как только мы
заметаем, что какая-нибудь из его частей не имеет денотата. Поэтому наше
стремление узнать не только смысл, но и денотат предложения вполне
оправдано..


Выход из этого Г. Фреге видит в использовании людьми истинности
высказывания: Ясно, однако, что тот, кто всерьез считает данное
предложение истинным или ложным, считает также, что имя Одиссей имеет
не только смысл, но и денотат, ибо именно денотату этого имени можно
приписывать или не приписывать состояние, обозначенное в приведенном
предложении соответствующим предикатом.. И далее: Почему самого по
себе суждения нам недостаточно? Потому и лишь потому, что нас интересует
истинность суждений Именно стремление установить истину и заставляет
нас двигаться вперед, от смысла предложения к его денотату.[10]. Но не
все так хорошо с предикатами, иначе бы Г. Фреге не вынес в сноску
следующее: Желательно иметь для знаков, которые должны быть наделены
только смыслом, особое название, например, изображения [Bilder];
тогда слова, произносимые актером на сцене, будут изображениями; более
того, и сам актер будет изображением. К этому можно сделать лишь одно
замечание: Г. Фреге не может, при анализе всего многообразия способов
передачи содержания предложений, обойтись только использованием
денотатов, ему нужны и представления.


Итак, почему же Г. Фреге пошел по этому пути:


  1. Существует необходимость наличия у предложений объективного
    содержания, позволяющего передать их понимание в коммуникационном
    акте от одного человека к другому.


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



Весьма странным ответом на поставленные вопросы является предложение Г.
Фреге считать денотатом предложения его истинностное значение: Мы
вынуждены, таким образом, признать, что денотатом предложения является
его истинностное значение [Wahrheitswert]истина или ложь других
истинностных значений не бывает[11]. Всякое повествовательное
предложение, в зависимости от денотатов составляющих его слов, может,
таким образом, рассматриваться как имя, денотатом которого (если,
конечно, он существует) будет либо истина., либо ложь. Обе эти
абстрактные вещи (истина и ложь) признаются, хотя бы молчаливо. Всеми,
кто вообще делает какие-либо утверждения или считает хотя бы что-нибудь
истинным, то есть даже самыми последовательными скептиками. То, что мы
считаем истинностное значение вещью, может показаться неоправданным
произволом, пустой игрой слов, из которой нельзя извлечь никаких
интересных следствий..


Проблема состоит в том, что то, что он предлагает как следствие из своих
рассуждений является предположением, для которого с точки зрения автора
Г. Фреге так и не нашел достаточно убедительных аргументов. Г. Фреге сам
это осознает: То, что мы считаем истинностное значение вещью, может
показаться неоправданным произволом, пустой игрой слов, из которой
нельзя извлечь никаких интересных следствий. Уточнить, что именно
понимается здесь под вещью, можно только через понятие и отношение..
Поэтому он продолжает: Можно попытаться рассмотреть отношение суждения
к истинности не как отношение смысла к денотату, а как отношение
субъекта к предикату.. И для этого он приводит следующий пример,
состоящий из двух предложений:


(9) Суждение, что 5 простое число, истинно.


(10) 5 простое число.


Тем самым, следуя тем соображениям, которые к данному моменту мы находим
в работе Г. Фреге, мы можем интерпретировать предложение (9) как пример
предложений, выражающих отношение смысла к денотату, а (10) как пример
предложений, выражающих отношение субъекта к предикату.


Согласно Г. Фреге: Утверждение истины в обоих случаях заложено в самой
форме повествовательного предложения, причем даже в тех случаях, когда
эта форма лишена своей обычной утвердительной силы.. Опять таки
почему? Не то того ли, что это так хочется самому Г. Фреге? Мы же видим,
что (9)-ый пример представляет собой предложение, обладающее
императивной модальностью: вы должны отнести число 5 к классу простых
чисел; (10)-ый пример, больше говорит о свойстве конкретного числа 5
т.е. данное предложение носит фактографический характер, сообщает об
имеющемся факте. И только сложившаяся интеллектуальная традиция,
позволяет нам принять точку зрения Г. Фреге: если предложение (9)
произнесено актером со сцены, оно выражает только одно суждение, то же
самое суждение, что и предложение (10).. Но при этом они имеют
различные прагматические цели.


Только оговора Г. Фреге о том, что если (9) произнесено актером на
сцене (т.е. абсолютно нейтральным лицом), оно может не иметь
императивной модальности, и поэтому по всем характеристикам (9) и (10)
будут практически эквивалентными. Но и не только! Все таки, следовало бы
различить их формы:


P(P(5))=true для (9) и


P(5) для (10).


Т.о., вне конкретной коммуникативной ситуации (10) не отражает ничего
кроме некоторого отношения экземплификации или приписывания
экстенсионала 5 классу простых чисел, а это совсем не означает
истинности P(5) [12]. В тоже время очень легко предложение (9) можно
переформулировать в императивной модальности:


Я утверждаю, что суждение 5 простое число истинно.


или


Я нарекаю 5 простым числом


или


Я отношу 5 к простым числам.


В этом смысле поражает следующая за этим оговорка Г. Фреге: Отсюда
следует, что между суждением и его истинностным значением имеет место
совсем не то же отношение, что между субъектом и предикатом. Субъект и
предикат (в логическом смысле этих терминов) являются частями суждения и
находятся на одном и том же уровне с точки зрения познания: соединяя
субъект с предикатом, мы всегда получаем тем самым суждение, но не
совершаем перехода от смысла к денотату, или от суждения к его
истинностному значению. Соединяя субъект с предикатом, мы остаемся на
том же самом уровне, не переходя на следующий. Истинностное значение не
может быть частью суждений, поскольку оно не смысл, а вещь, точно так
же, как не может быть, скажем, частью суждения о Солнце, само Солнце..


Непонятно в силу вышесказанного и другое утверждение Г. Фреге: Если
наше предположение о том, что денотатом предложения является его
истинностное значение [Wahrheitswert], верно, то последнее не должно
изменяться, если какую-нибудь часть предложения заменить выражением,
тождественным ей по денотату, но отличным по смыслу. Это действительно
так и есть. Лейбниц писал по этому поводу: Eadem sunt, quae sibi mutuo
substitui possunt, salva veritate[13].


Удивляет собственно переход от первого ко второму. Ведь в утверждении
Лейбница по своей сути содержится следующая мысль: если не меняется
значение предложения, то и истинность его также не должна меняться, но
не наоборот. Действительно, мы можем привести бесконечное множество
эквивалентных по значению истинности утверждений, но совершенно разных
по смыслу[14]. Автор еще раз убеждается в справедливости собственного
мнения, обратного мнению Г. Фреге: истинностное значение (значение
функции истинности) не может быть денотатом предложения. Раз, каким бы
то ни было образом, был установлен смысл (как отношение между значением
и именем установлено) предложения, то его можно было бы, считать
истинным, пока он позволяет лицу (индивидууму) успешно действовать в
окружающем мире. Другое дело, что само отношение Смысл может иметь
какие-то дополнительные атрибуты истинность, значимость и т.п..


Видно, что Г. Фреге, на самом деле никак не может ничего представить,
что кроме простого скалярного значения (типа числа, булевого значения
или целостного образа) может образовывать денотат предложения
(описывающего ситуацию или фактическое положение дел в мире): Что же
еще, кроме истинностного значения, может быть в общем случае приписано
всякому предложению, что так тесно связано с денотатами его частей и не
зависит от подстановок указанного типа?[15].


Подытоживая все свои рассуждения на тему денотата предложения, Г. Фреге
пишет: Если же денотатом предложения является его истинностное
значение, то все истинные предложения, с одной стороны, и все ложные
предложения, с другой, будут иметь один и тот же денотат: все первые
обозначают истину, все вторые ложь. Отсюда видно, что в денотате
предложения все частное стирается. Поэтому денотат сам по себе нас не
интересует; однако и суждение, взятое в отрыве от денотата, т. е. смысл
сам по себе, тоже не несет в себе нового знания. Этим свойством обладает
только соединение суждения и его денотата (истинностного значения).
Утверждение можно рассматривать как переход от суждения к его
истинностному значению..


Воздержимся от дополнительных комментариев этих слов Г. Фреге, поскольку
автор уже высказался на эту тему. Интересно следующее за ним
утверждение: Впрочем, можно было бы сказать, что утверждение
обязательно связано с разбиением истинностного значения на некоторые
части. Это разбиение выполняется на основе обращения к суждению. При
этом каждому смыслу, имеющему некоторое истинностное значение,
соответствует свое особое разбиение этого истинностного значения на
части. (Слово часть [Teil] употребляется здесь достаточно необычным
образом, а именно: отношение между предложением и его частью переносится
на денотат предложения; тем самым денотат слова мыслится как часть
денотата всего предложения, если само это слово является частью
предложения. Такое словоупотребление, очевидно, не вполне корректно, так
как денотат целого и какой-либо его части еще не определяет денотата
остальной части, а также и потому, что применительно к физическим телам
слово часть употребляется в другом смысле. Для данного понятия
следовало бы найти другое выражение).. Оно интересно тем, что
фактически его можно понимать как существование, по мнению Г. Фреге,
потенциальной возможности вычислять истинностное значение предложения
на основе истинностных значений его частей.


В дальнейшем Г. Фреге приступает к анализу денотата придаточных
предложений. На основе своих грамматических изысканий приходит к
следующим выводам:


1. денотатом придаточного является определенное суждение: для
истинности целого сложноподчиненного предложения безразлично, истинно
или ложно суждение, выраженное в придаточном;


2. денотатом предложения не всегда бывает его истинностное значение.


Если по поводу первого вывода автор собственно ничего не имеет, в силу
всего вышесказанного, то второй вывод вызывает удивление Г. Фреге
пошел на смягчение своего же ранее сделанного предложения. Автор думает,
что это закономерно, поскольку вся концепция денотата предложения как
логического значения не правомерна и построена на слишком зыбком
основании. Что подтверждается и дальнейшими выводами Г. Фреге:


1. Придаточные с союзом чтобы при глаголах типа приказывать или
просить в прямой речи становятся повелительными предложениями. Такие
придаточные имеют только смысл, но не имеют денотата. Приказ или просьба
не являются суждениями, однако они находятся на одном уровне с
суждениями. Поэтому слова, которые входят в придаточное дополнительное
при глаголе типа приказывать, просить и т. п., имеют косвенный
денотат. Денотатом такого придаточного является не истинностное
значение, а приказ, просьба и т.п..


2. Так же обстоит дело с косвенными вопросами.


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


Для подкрепления своей позиции он пытается привлечь ссылки
математические примеры: этот недостаток присущ в какой-то степени и
знаковой системе математического анализа: здесь мы тоже встречаем
выражения, которые внешне выглядят так, как будто они что-то обозначают,
однако в действительности (по крайней мере, до сих пор) денотат их
неизвестен, например: сумма бесконечного расходящегося ряда. . Но
здесь он говорит о значении, тем самым, подтверждая косвенно свое
представление о связи денотата со значением[16].


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


  • находится адекватное понимание;


  • словам подбираются соответствующие значения (будь-то денотаты или
    представления);


  • для предложений также находятся и строятся соответствующие смыслы
    (как правило, из уже готовых компонент, имеющихся ментальных
    образов и репрезентаций).



В заключении, хотелось бы процитировать Г. Фреге, давшего определение
идеального языка: В идеальном языке [Begriffsschrift] любое
грамматически правильное выражение, построенное из ранее определенных
знаков, которое вводится в качестве собственного имени, должно
обязательно обозначать нечто, и всякий новый знак может вводиться в
качестве собственного имени лишь при условии, что ему уже обеспечен
некоторый денотат. . Так что данный нами предпоследний комментарий
может служить доводом того, что идеальным языком обладает практически
каждый из нас.


3. Заключительные замечания


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


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


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


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


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


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


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


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


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


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


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


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


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


На этом этапе сам язык может использоваться и используется, путем
применения процедур подкрепления, фиксирования правильных с точки зрения
социальной употреблений и, наоборот, исправления неправильных
употреблений языковых выражений, для корректировки изначальной
довербальной или уже в некоторой степени вербализованной ментальной
картины мира, для ее социализации, интерсубъективизации. Таким
образом, язык предпосылка, инструмент и цель социальной коммуникации
индивидуумов.


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


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


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


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


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


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


В данном эссе мы рассмотрели некоторые положения работы Г. Фреге Смысл
и денотат (Смысл и значение). Для большей наглядности автор решил
использовать графическую нотацию UML, что позволило ему не только
образно представить довольно абстрактные понятия семиотики, но и (как
ему кажется) прояснить место таких понятий как Смысл и Значение.



Рисунок 12. Заключительная итерация модели Имя-Смысл-Значение


На основе полученной модели (см. Рисунок 12) можно кратко сформулировать
полученные результаты следующим:


  1. Под смыслом мы понимаем устанавливаемое в процессах порождения имени
    или его интерпретации отношение между именем и его значением.


  2. Значения можно разделить на два взаимосвязанных класса сущностей:



  • денотаты как вещи, данные нам в ощущениях; предметы объективной
    реальности;


  • представления (концепты) как психические феномены, внутренние
    образы индивидов;


  • некоторым представлениям (концептам) можно поставить в соответствие
    денотаты.



  1. Одному и тому же имени в разных контекстах должно обязательно
    соответствовать одно или более различных значений.


  2. Любому значению соответствует хотя бы одно имя.


  3. Одному и тому же значению могут соответствовать несколько имен.


  4. Отношение омонимии устанавливается непосредственно не между именем и
    значением, а между именем и смыслом, при этом именно имя агрегирует
    омонимичные смыслы.



Что же у нас осталось нераскрытым? К нераскрытому, в этой работе автора,
содержанию можно отнести:


  • структуру имени;


  • структуру денотата;


  • структуру представления (концепта);


  • роли и их кратности в отношении Значение Смысл Имя.


  • возможные связи или отношения между синонимичными именами, или их
    определениями;


  • присваивание и переприсваивание значений имен и многое многое
    другое.



Но это уже другая работа


[1] Фреге Г. Смысл и денотат (1892) в сборнике Семиотика и
информатика. Выпуск 8. 1977, с. 181-210


[2] Естественно, что Г. Фреге не мог оперировать принципами квантовой
физикой, поскольку последняя родилась почти на два десятилетия позже
написания рассматриваемой нами работы.


[3] Для понимания такой графической нотации читателям рекомендуется
познакомиться со следующими книгами:


Буч Г., Максимчук Р.А., Энгл М.У., Янг Б.Дж., Коналлен Д., Хьюстон К.А.
Объектно-ориентированный анализ и проектирование с примерами приложений
(UML 2) или


Fowler M., Scott K. UML Distilled. A Brief Guide to the Standard Object
Modeling Language.


[4] Здесь мы специально не останавливаемся на модели и структуре
коммуникативного акта. Также не будем обсуждать вопросы контекста и
невербальных компонент коммуникации.


[5] Мы можем объединить представления с восприятиями, для которых
впечатления и акты поведения выступают вместо отпечатков, оставляемых
ими в сознании. Для нас различие между представлениями и восприятиями
несущественно, тем более что в общую картину действительности, наряду с
самими ощущениями и актами поведения, входят воспоминания о них. При
этом восприятие можно рассматривать также и как вещь, поскольку вещи
воспринимаются органами чувств или носят пространственный характер.
ссылка Г.Фреге.


[6] Поэтому нецелесообразно употреблять слово представление для столь
разных понятий. ссылка Г.Фреге.


[7] Наверное, между смыслами выражений.


[8] Вопрос только в характере этих отношений.


[9] Собственно последующие рассуждения Г. Фреге подтверждает наше
предположение.


[10] При этом Г. Фреге делает интересную оговорку: Правда, истинность
интересует нас далеко не всегда. Например, при чтении эпоса нас волнуют,
наряду с красотой языка, только смысл предложений и вызываемые ими
представления (образы) и чувства. Вопрос об истинности этих предложений
увел бы нас из сферы художественного восприятия в сферу научных
изысканий. Вот почему, коль скоро мы воспринимаем поэму Гомера только
как художественное произведение, нам безразлично, в частности, имеет имя
Одиссей денотат или нет.


[11] Сейчас бы Г. Фреге такого заявления бы не сделал!


[12] Математики в случае такого утверждения потребовали бы
доказательства его истинности, несмотря на то, что данное утверждение
содержится в повествовательном предложении, т.е. фактически потребовали
построения его функции истинности. По сути дела, доказательство является
построением функции истинности для формального утверждения.


[13] Два выражения считаются одинаковыми, если они всегда могут
подставляться одно вместо другого, причем истинность целого не
изменяется Прим. перев. работы Г. Фреге.


[14] По Г. Фреге это, наверное, означало бы логическую синонимию.


[15] Ясно, что сейчас представления о возможных типах денотатов гораздо
шире. Но традиция принимать логические значения в качестве денотатов
предложений настолько сильно укоренилась в логической семантике и др.
подобных дисциплинах, что мешает дальнейшему развитию понимания проблемы
смысла и значения. Это прослеживается в многочисленных
логико-семантических трудах нашего времени (спустя более чем 100 лет от
момента написания Г. Фреге рассматриваемой работы), что собственно и
вызвало у автора желание досконально разобраться с этим мнением.


[16] Я не буду говорить о их эквивалентности.

Подробнее..

Смысл текста или представление знаний в системе, основанной на действиях

28.04.2021 10:12:44 | Автор: admin

1. Введение

Еще в работах академиков Анохина П.К. и Судакова К.В [1] отмечалась центральная роль понятия действия в работе мозга человека. Они предложили понятие акцептора результатов действия, как структуры объединяющей информацию о поведенческих актах, выполняемых субъектом. В предыдущей статье [2] я предположил и постарался показать как структуры, представляющие действие, делают возможным представление и обработку знаний в целом, а не только для реализации поведенческих активностей. В статье [3] попытался показать, как в процессе эволюции сознание могло возникнуть в качестве следующего механизма усложнения поведения вслед за рефлексами и эмоциями. Важность описания и представления действия отмечалась и другими авторами, в том числе и здесь на Хабре, например, Александром Болдачевым ( @boldachev) в статье "Семантика и деятельность".

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

Для начала уточним терминологию.

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

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

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

Все понятия в системе представляются в виде Структур действия. Поэтому использование по тексту терминов понятие, действие и структура действия взаимозаменяемо и подразумевает указанную выше структуру, если отдельно не указано иное.

2. Базовые действия системы

Для определенности, будем рассматривать далее некую абстрактную информационную систему, предназначенную для обработки символьной (текстовой) информации.

Для начала определим два Действия чтения символов(read) и вывода символов на печать(print). Также необходимы понятия для представления символов (цифры, буквы, знаки пунктуации и пр.). Будем обозначать Действия подобно математическим функциям именем и заключенными в скобки параметрами, или аргументами f(x1(), x2()). Аргументы и результат тоже Действия. Для упрощения чтения, когда параметры действия не важны, будем писать просто A, например, вместо A(x1(), x2()).

Создание Структур действия будет выполняться служебным действием new(activity, param_num), где activity Активность, составляющая действие, а param_num число параметров, необходимых для Активности, например:

WHAT_IS = new (Activity_mapping, 1)

Если параметры не заданы, то подразумевается пустая активность и действие при выполнении не выдает никакого результата. На Рис.1 схематично показана Структура действия и базовые Действия.

Рис. 1 Структура действия и базовые действияРис. 1 Структура действия и базовые действия

Действия чтения символов и вывода их на печать содержат соответствующие Активности чтения и печати.

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

2.1. Последовательности символов

Указанные ранее понятия позволяют системе работать с одиночными символами. Работа с последовательностями символов может быть организована в системе, например, следующим образом. Представим, что в системе имеются действия сохранения (store) в памяти и чтения из памяти (load) с параметрами: 1) индексом элемента в последовательности и 2) ссылкой на понятие.

Понятие, представляющее последовательность символов ABC, может быть создано тогда следующими действиями:

ABC = new()
store(ABC,0,A)
store(ABC,1,B)
store(ABC,2,C)

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

2.2. Активность сопоставления

Определим, например, два понятия: буква LETTER, и цифра DIGIT.

Тогда мы можем сконструировать Действие WHAT_IS с одним параметром, активность которого будет заключаться в возвращении LETTER, если в качестве параметра указаны понятия А..Я, и DIGIT, если в качестве параметра указаны понятия 0..9.

WHAT_IS = new(Activity_mapping,1)
WHAT_IS(A) => LETTER, WHAT_IS(1) => DIGIT

Активность по сопоставлению аргументов и результата, Activity_mapping, удобно сделать универсальной, содержащей внутреннюю таблицу с соответствием Аргументы-Результат. Это позволит нам реализовывать любые понятия, связанные с классификацией понятий, их свойствами и отношениями между понятиями (Рис.2).

Рис. 2 Активность сопоставления и действие на ее основеРис. 2 Активность сопоставления и действие на ее основе

Активность Activity_mapping будет осуществлять сопоставление входного параметра с имеющейся внутренней таблицей и возвращать соответствующий входным данным результат. Данные в эту таблицу будем заносить специальным действием Learn(arg, action, result). Таким образом мы cможем сообщить системе, что при запуске Действия action с аргументом arg в результате надо выдавать ссылку на result.

2.3. Активность сравнения - свойства и их описание

Так как, во многих случаях, действие возвращает ссылку на результирующее понятие, можно представить Активность (Activity_compare), которая будет сравнивать реальный результат указанного действия с каким-либо понятием, сравнивая их на совпадение. Положительный результат сравнения будем обозначать понятием Да(YES), а отрицательный понятием Нет(NO).

YES = new(), NO = new()

На базе этой Активности (Activity_compare) можно реализовать любое свойство. Для этого введем в системе понятие свойства (PROPERTY). Для реализации сравнения нам необходимо иметь информацию о действии, его аргументах и ожидаемом результате. Реализуем это с использованием действий PROP_ACT, PROP_ARG и PROP_RESULT соответственно. Их аргументом будет понятие свойства.

PROPERTY = new()
PROP_ARG = new(Activity_mapping,1)
PROP_ACT = new(Activity_mapping,1)
PROP_RESULT = new(Activity_mapping,1)

Вот как, например, будет выражено утверждение о том, что понятие something есть буква:

some_prop = new(Activity_compare,1)
Learn(some_prop, WHAT_IS, PROPERTY)
Learn(some_prop, PROP_ARG, something)
Learn(some_prop, PROP_ACT, WHAT_IS)
Learn(some_prop, PROP_RES, LETTER)

Схематично это представлено на Рис. 3.

Рис. 3 Свойство и его возможное влияние на действиеРис. 3 Свойство и его возможное влияние на действие

То есть свойство some_prop сообщает, что при запуске действия WHAT_IS с аргументом something результат будет LETTER. Предположим, что мы считаем достоверным свойство some_prop. Тогда мы вносим изменение в таблицу активности понятия WHAT_IS чтобы при запуске WHAT_IS с аргументом something в качестве результата возвращалось LETTER. Несложно реализовать и более изощренное поведение, чтобы Активность, стоящая за Действием (в данном случае, Activity_Mapping) анализировала утверждения о релевантных свойствах (в которых присутствует заданное действие) на предмет дополнительных параметров, например, достоверности или вероятности и выдавала результат учитывая только достоверные или вероятные утверждения.

Свойства и их влияние на результаты других Действий позволяет определить понятие смысла. Смысл какого-либо описания (в нашем случае, some_prop) содержится во влиянии на результат того или другого Действия (в нашем случае WHAT_IS).

2.4. Объекты как наборы свойств, действия как вид объектов

То, что мы в обычной речи называем объектами, понятиями, является по сути описанием некоторого набора свойств, часто встречающихся совместно и поэтому для удобства определяемых через одно понятие. Для представления в системе объектов введем понятие OBJECT. Объекты могут обладать как общими свойствами (например, название), так и специфическими для определенных видов объектов. Для доступа к общим свойствам объекта предусмотрим действие OBJ_PROPS, которое будет выводить в качестве результата список свойств, то есть объектов подобных some_prop из предыдущего раздела.

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

Кто делает субъект действия (ACT_ACTOR)
Что делает само действие (ACT_ACTION)
С чем, что делает объекты действия (ACT_OBJECT)
Модальность состояние действия (нужно сделать, делается, сделано и т.д.) (ACT_MOD)
и другие возможные свойства (когда, зачем, как, почему, достоверность, вероятность и т.д.)

Иными словами, объект-действие это некоторое высказывание о действии (подобно тому как свойство можно рассматривать как высказывание о результате какого-то действия).

Таким образом, понятие, стоящее за фразой Светит солнце, может быть представлено в системе через объект-действие some_action (предполагаем, что понятия SUN, SHINE, INPROCESS определены ранее):

some_action = new()
Learn(some_action, WHAT_IS, OBJECT_ACTION)
Learn(some_action, ACTOR, SUN)
Learn(some_action, ACTION, SHINE)
Learn(some_action, ACT_MOD, INPROCESS)

3. Смысл текста и знания

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

Смысл проявляется во влиянии на результаты действий. Модификация знаний об объектах и их свойствах приводит к изменению результатов при выполнении действий.

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

4. Запросы к знаниям

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

Вот, например, пример структуры для вопроса Кто светит?:

some_question = new()
Learn(some_question, WHAT_IS, OBJECT_ACTION)
Learn(some_question, ACTOR, Q_ARG)
Learn(some_question, ACTION, SHINE)
Learn(some_question, ACT_MOD, INPROCESS)

Поиск ответа выполняется действием, например, так:

FIND_ANSWER = new(Activity_search_answer,1) FIND_ANSWER(some_question) => SUN

5. Заключение

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

Показанная в данной статье способность с помощью Структур действия представлять знания об окружающем мире, является только одним из проявлений универсальности подхода, основанного на Действиях. В статье [2] было показано, как эти же структуры могут обеспечить планирование поведения и его адаптацию к изменяющимся условиям окружающей среды.

Литература

[1] Александров Ю.И., Брушлинский А.В., Судаков К.В., Умрюхин Е.А. Системные аспекты психической деятельности / М.: Эдиториал УРСС, 1999. 137 с. 17 п.л. ISBN: 5-8360-0021-2

[2] Гурьев А.П., Динамическая семантическая сеть, основанная на действиях. 2019.
http://www.real-ai.ru/action-based-dynamic-semantic-network/

[3] Гурьев А.П., От эффектора к действию. Эволюция нейронных структур. 2020.
http://www.real-ai.ru/evolution-from-effector-to-action/

Подробнее..

Дата-центрическая архитектура волшебная пуля от интеграционных проблем

16.06.2021 18:22:08 | Автор: admin

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

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

А что, если найдется способ избавиться от всех интеграционных проблем разом? Такая "волшебная пуля" существует, и называется она - дата-центрическая архитектура. Ее основная идея состоит в том, чтобы сделать центральным элементом корпоративной ИТ-архитектуры не бизнес-приложения, а данные. Этот принцип изложен в Манифесте дата-центрической архитектуры.

Представьте, что в компании существует единое виртуальное хранилище данных, в котором каждый бизнес-объект или событие существует в единственном экземпляре. Для наглядности можно вообразить, что идея системы MDM (Master Data Management) доведена до логически полного воплощения, и именно MDM является хранилищем всех корпоративных данных; бизнес-приложения не имеют собственных СУБД и работают только с объектами данных из MDM. Преимущества такой архитектуры очевидны:

  • Раз и навсегда отменяется необходимость в интеграционных процедурах.

  • Снижаются затраты на хранение данных за счет избавления от множества копий каждого бизнес-объекта в разных системах.

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

  • Повышается качество данных за счет избавления от неполных, не актуальных представлений бизнес-объектов.

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

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

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

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

Чем такой подход отличается от создания "обычного" корпоративного облака данных (corporate data cloud) или озера данных (data lake)? Прежде всего - методологией использования платформы, особым вниманием к структуре данных и некоторой функциональной спецификой. Если обычный data lake часто представляет собой коллекцию наборов данных, созданных кем-то для решения конкретных задач и заведомо содержащих копию уже существующей где-то информации, то для дата-центрической архитектуры принципиально соблюдение принципа "один объект в реальном мире - один объект данных". И никаких физических срезов, по крайней мере персистентных...

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

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

Когда вся корпоративная информация становится структурированной и логически связной, она приобретает свойства корпоративного графа знаний (corporate knowledge graph), который открывает предприятию новый уровень аналитических возможностей и позволяет гораздо эффективнее монетизировать накопленную информацию.

Какими функциональными свойствами должна обладать платформа, являющаяся ядром дата-центрической архитектуры? Она должна:

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

  • Хранить непрерывную историю модели (структуры) данных. Структура данных столь же изменчива, как и сами данные. Платформа должна иметь возможность представлять объекты данных в соответствии с любой версией структуры. Структура должна формально описывать смысл каждого элемента данных.

  • Поддерживать множество API для работы с данными, включая REST, GraphQL, SPARQL.

  • Предоставлять возможности обнаружения и поиска данных.

  • Иметь развитые инструменты управления доступом к данным и защиты конфиденциальной информации.

  • Поддерживать инструменты прослеживания происхождения данных (data provenance), контроля их качества (data quality), описания степени доверия к данным.

Построение подобных платформ с использованием онтологических моделей открывает и другие возможности. В онтологической модели можно описать в машинно-читаемой и автоматически исполняемой форме не только структуру данных, но и алгоритмы их обработки - правила контроля целостности, арифметических вычислений, дополнения информации (см. спецификации SHACL и SHACL Advanced Functions). Это позволяет по-новому взглянуть и на принцип low code: если в единой корпоративной платформе управления данными хранятся не только данные и описание их структуры, но и машинно-читаемое описание алгоритмов обработки данных, то новые бизнес-приложения, ориентированные на использование таких описаний, станут еще гибче и смогут изменять свое поведение "на лету" без вмешательства не только в код, но и в настройки приложений.

Платформы, отвечающие таким требованиям, уже существуют и применяются и на российском, и на зарубежном рынке.

Подробнее..

Теория здравомыслия

27.12.2020 00:14:52 | Автор: admin

Как мыслить и действовать адекватно ситуации, избавиться от инфантилизма и не наступать на одни и те же "грабли"? Эта статья может стать отправной точкой для получения навыков усвоения материала почти любой сложности.

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

Аристотель уникален тем, что его последователи поклонялись не только его лучшим качествам, но также и его недостаткам, чего он никогда не делал в отношении кого-либо, живого или мертвого; за что и был не раз он порицаем за непоклонение. Огастес де Морган - "наука и здравомыслие" А. Коржибски.

В 1933 году польский математик по имени Альфред Коржибски издал книгу "наука и здравомыслие", а в 1938 году основал институт общей семантики в США. В основе его концепции лежит утверждение о том, что любое человеческое познание ограничивается структурой нервной системы и структурой языка. Это значит, что человек априори не может знать всё обо всём. Коржибски проанализировал структуру языков индоевропейской группы математическими методами и выявил фундаментальные основы логики языка, которым люди пользуются изо дня в день, скрытые в неопределяемых и многопорядковых терминах (принимающие значение только при наличии контекста). Через них показана метафизика лежащая в основе используемого нами языка, его несовершенство, некоторое несоответствие действительности (например, может использоваться одно слово для нескольких сущностей одновременно, что может способствовать неверной оценке и неэффективному поведению (об этом позже)). Для преодоления этого барьера Коржибски ввел в ОС (общая семантика) в обиход не-элементалистский (позже станет понятно что это значит) терминсемантической реакции-психологическая реакция индивидуума на слова, язык и другие символы и события в связи с их смыслом, и психологические реакции, которые становятся смыслами и конфигурациями отношений в тот момент, когда индивидуум начинает анализировать их, или кто-то другой делает это за него.Так же разработал простое и наглядное средство для обучения новым, более адекватным семантическим реакциям - структурный дифференциал. Данный подход предлагаю начать с изложения о понятии механизмавремясвязывания.

Механизм времясвязывания

Этот механизм предполагает, что мы (люди) стоим на плечах друг друга в том смысле, что каждое поколение людей продолжает развиваться с того места на котором закончило предыдущее, т.е. обладает время-связующим элементом с помощью устной и письменной формы передачи информации. Для этого человечество использует язык, основанный на аристотелевой логике, включающая в себя двух-трёх значное ориентирование, которая была дополнена законом исключенного третьего: А или не А (где А - некое утверждение) - одно из этих значений является истинным; а также "язык науки" с помощью которого можно описывать и анализировать научные данные. К сожалению в повседневной жизни используется первый, без существенных изменений, не одну тысячу лет. На протяжении этого времени наука развивалась и среда обитания людей искусственным путем изменилась до такой степени, что структура используемого языка перестала соответствовать человеческой среде и стала порождать множество проблем, и связанные с ними человеческие страдания.

Здесь как раз кое-что добавлю о свойствах языка:

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

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

Процесс абстрагирования

Абстрагирование означает 'отбор,'выбор', 'отделение', 'обобщение', 'вычет', 'удаление', 'опущение', 'разделение', 'отнимание', 'лишение', и [когда используется] как прилагательное не конкретный На неврологическом уровне, абстрагирование - это то, что делает нервная система. Структурно структурный дифференциал (изображен ниже) схож с работой нервной системы.

Центральной идеей метода обучения адекватнымсемантическим реакциямявляется исключение отождествлений в оценке, с помощью исключения из языкового употребления отождествляющего "есть". (Речь идет не просто о слове "есть", а о лежащем в нем значении, а также других словах, где в неявном виде оно присутствует ('являться', знак тире, использующийся как определение и т.д.). Однако, т.к. и без них не обойтись, поэтому автор метода ввел некоторые приемы для осторожного использования этих слов: обозначать их в письме апострофами). Также метод исключает элементализм, который тоже составляет основу А-системы (аристотелевой). Элементализм в прежней А-системе позволяет вербально разделить то, что в реальности неразделимо: тело и ум, пространство и время, действие и последствие и т.д.; элементализм склоняет людей подразумевать, что ранее перечисленное может существовать как отдельные друг от друга сущности и вербально создавать изолированные элементы из динамических взаимосвязанных процессов, обнаруженных в мире, которые включают нас самих. Все это может вводить в заблуждение и порождать неадекватные оценочные реакции. Т.е. лингвистическое влияние очень сильно.

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

Структурный дифференциалСтруктурный дифференциал

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

В верхней части структурного дифференциала расположена парабола, символизирующая уровень события (процесса). Как видно, верхняя часть параболы изображена с обломленным концом, что указывает на ее бесконечность. Это значит, что мы не можем знать 'все' о событии и напоминает о том, что это постоянно меняющийся динамический процесс. Кружочками обозначены характеристики события, их количество бесконечно велико. Свисающие нити от уровня события к уровню объекта символизируют характеристики, которые были учтены при абстрагировании; свободно свисающие нити указывают на характеристики события, которые были упущены при абстрагировании ('все' обо всем знать невозможно!). Уровень объекта (его еще называют немым уровнем) на параболе символизирует объективный уровень, т.е. это то что абстрагирует нервная система из события. На объективном уровне можно увидеть, потрогать, почувствовать и т.д. После уровня объекта изображен прямоугольник символизирующий ярлык - вербальный уровень - ярлыком может быть название чего-либо, чье-то имя и т.д. Ярлык используется для идентификации объекта по его имени, названию. Как видно, на параболе, по свободно свисающим нитям, на уровне ярлыка упущено еще больше характеристик. => по ярлыку можно определить еще меньшее количество характеристик, которыми обладает объект. На следующем уровне абстракции находится уровень описания. На этом уровне мы можем высказать какое-нибудь мнение об объекте. На следующем уровне можем составить заключение из предыдущего уровня абстракции - описания. Далее можно высказать заключении о заключении и т.д. до бесконечности.

Итак, на структурном дифференциале изображены уровни/порядки абстракций: уровень события (процесса), ярлык, описание, заключение об описании, заключение о заключении и т.д.

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

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

Осознанность абстрагирования

Ощущение противоречивости это уже зарождающаяся осознанность. . . . А.Н. Уайтхед

Коржибски утверждал, что для того чтобы быть максимально полезным, язык должен быть подобен по структуре тем событиям, для описания которых он предназначен. Язык "абстракций различных порядков", которые предоставляет структурный дифференциал, представляется удовлетворительным с точки зрения структуры. Это не-элементалистский язык, поскольку он не вводит различия между "чувствами" и "разумом" . Это функциональный язык, поскольку подразумевается, что он описывает то, что происходит в нервной системе, когда она реагирует на стимулы. По физико-химической, структурной, коллоидальной необходимости организм работает как целое. Будучи относительно целостным, он принимает любой дополнительный структурный фактор как реактивный и функциональный, который влияет на работу всего целого ("наука и здравомыслие" А. Коржибски). Это означает, что добавление или утрата чего-либо из организма, будет иметь влияние на организм как целое. Например, если человек лишится какой-нибудь части мозга, части нервной системы или конечности это окажет влияние на организм в целом; поэтому говорить об этом в терминах "+/-" к функции организма неправильно, т.к. на деле это не так.

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

Приведу пример отождествления: когда человек реагирует на вербальном уровне как на объективном: при описании лимона у вас может начаться вырабатываться слюна; в ходе различных словесных перепалок человек склонен реагировать на слова, будто они физически способны оказать на него влияние и т.д.

Примером спутывания порядков абстракций: человек ошибочно принимает описание за заключение или наоборот; ярлык за описание. Следствием этого становится неправильная оценка объекта, ситуации и т.д.

Если мы не осознаем абстрагирование, то мы не можем избежать отождествления или перепутывания объекта с его конечным числом характеристик, с событием, с его бесконечным числом других характеристик. Замешательство между этими уровнями может ввести нас в ситуации, заканчивающиеся неприятными шоками. Приобретаяосознанность абстрагированияи помня о том, что объект не является событием, и что мы абстрагировали характеристики, которые меньше числом и отличаются от тех, что есть у события, мы можем ожидать множество непредвиденных происшествий. Вследствие чего, когда это неожиданное происходит, мы остаемся в безопасности от болезненных и вредных шоков ("наука и здравомыслие" А. Коржибски).

Короче говоряосознанность абстрагирования, это когда человек помнит об опущенных характеристиках объекта при каждом абстрагировании на определенный уровень. На объективном уровне объект можно оценить с помощью визуального контакта, понюхать, потрогать, лизнуть на вкус и т.д. На вербальном уровне это сделать невозможно, поэтому некоторые характеристики опускаются; когда мы высказываем мнение об объекте, то характеристик еще больше опущено, при составлении заключения о нем - еще больше характеристик опускается. А теперь подумайте, на каком уровне абстракции находятся термины экономика, политика? Это обобщающие термины, сколько всего объектов, ярлыков, описаний, заключений, заключений о заключениях они могут в себя включать? Сможете однозначно о них рассуждать с другими людьми?

Можно еще привести пример трудностей, которые становятся невозможными с осознанностью абстрагирования: когда двое и более людей спорят о политике :) В ходе спора они могут разражаться речами бесконечно. Обычно, это еще называют разговором ни о чем. Проблема заключается в том, что участвующие в дискуссии могут не осознавать, что слово политика - довольно высокий уровень абстракции и включает множество аспектов различных сфер деятельности; кроме того у людей могут быть даже разные представления о политике. Такие дискуссии обречены на провал до тех пор пока не будет конкретизировано о каком именно аспекте политики идет речь. Т.к. не существует на объективном уровне такой сущности как политика, то можно спускаться по уровням абстракции вниз от этого обобщенного понятия, до тех пор, пока не появится возможность предъявить факты свидетельствующие о предмете дискуссии. И тогда хотя бы будет понятно о чем речь.

Обучение

Это проклятое односложное слово все принесло математикам больше проблем, чем все остальные слова в словаре. Э.Т. Белл

Коржибски писал о том, что можно обучиться всему чему только заблагорассудится, если вам открыта структура предмета изучения. Структура, соответственно, становится единственным возможным содержанием знания, и все научные технические тонкости, как бы тяжелы и трудоемки они не были, становятся просто необходимыми инструментами для поиска структуры, и инструменты эти сами по себе не обладают никакой особой ценностью и не являются необходимыми для "знания", как только для конкретного случая обнаруживается структура ("наука и здравомыслие" А. Коржибски). Структура языка просматривается в многопорядковых терминах: да, нет, истинный, ложный, функция, свойство, отношение, число, различие, название, определение, абстракция, утверждение, факт, реальность, структура, характеристика, проблема, знать, думать, говорить, ненавидеть, любить, сомневаться, причина, следствие, значение, оценка и многие другие. Это термины, которые принимают определенное значение только при наличии контекста; они неоднозначны или -значны. Сами по себе эти слова бесполезны, но они составляют структуру языка. Точно так же и в математике и многом другом. Структура знания, она как скелет на котором все держится и без него лишь просто набор символов. Например, в математике вам необязательно знать наизусть всю таблицу Брадиса, достаточно лишь знать как ее применить, как бы знать на что "повесить" эти значения, чтобы получить ожидаемый результат.

Заключение

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

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

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

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

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

Подробнее..

Recovery mode Когда можно обойтись без SEO или каким проектам поисковая оптимизация не нужна

11.11.2020 18:11:34 | Автор: admin

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

Когда нет смысла использовать SEO

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

1. Вы предлагаете новый, уникальный продукт, на которые не сформирован спрос

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

Вы можете сами проверить спрос на товар или услугу, воспользовавшись бесплатным сервисомwordstat.yandex.ru.

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

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

Эффективным инструментом для вывода совершенного нового продукта на рынок одновременно с продвижением по околоцелевым запросам может стать реклама на площадке Яндекс.Дзен.

2. Низкий спрос на продукт

Бывает обратная ситуация когда продукт существует давно, но спрос на него крайне мал.

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

Поисковая оптимизация при отсутствии сколько-нибудь заметного спроса задействуется лишь в самых исключительных случаях. Например:

  • Если ваш продукт стоит дорого или очень дорого, то даже при низком спросе на него вложения в SEO могут окупиться.

  • Если конкуренция в каком-то сегменте не очень высокая, то и вложения в SEO могут быть небольшими и также смогут окупиться.

3. Спрос на ваш продукт устойчиво снижается

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

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

Практически ни один продукт не защищен от падения спроса. Яркий пример спиннеры, которые резко ворвались на рынок и в настоящее время выходят из моды.

4. ТОП выдачи занят крупными площадками

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

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

Такие популярные сайты как Авито, Авто.ру, Циан или Wildberries привлекают огромный трафик и имеют высочайший авторитет в плане цитируемости (упоминания).

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

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

5. Ваш ассортимент значительно меньше, чем у конкурентов

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

Поэтому, если на вашем сайте представлено 5 кукол, а у конкурентов их тысяча вкладываться в SEO на данном этапе не следует. Нужно сперва проработать ассортимент расширить его за счет новых позиций, в том числе тех, которых нет у ближайшего конкурента.

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

6. Ваш продукт проигрывает в соотношении цена-качество

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

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

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

В этом случае даже, если SEO сработает и принесет вам много трафика, оно не будет конвертироваться в продажи. А следовательно, теряется весь смысл продвижения.

7. У вас нет уникального торгового предложения (УТП)

Прежде чем вкладываться в SEO, следует хорошенько поработать над маркетингом в частности продумать УТП. Ваше предложение должно чем-то выгодно отличаться от всего, что предлагают конкуренты, чтобы также обеспечить конверсию.

Сильной стороной может быть качество или цена, удобная доставка или профессиональная консультация, или самый большой ассортимент в нише. Еще лучше добавить некую ценность, которую не смогут скопировать конкуренты.

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

8. Вы не желаете или не имеете возможности дорабатывать сайт

SEO-специалисты отнюдь не волшебники, да и поисковые системы сегодня не дают творить чудеса (например, массовыми закупками текстов и ссылок).

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

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

9. Нет денег, маленький бюджет

Нужно понимать, что SEO это трудоемкий и долговременный процесс, требующий вложений. Средства вкладываются, в том числе, в доработку сайта и создание контента. К тому же, конкуренция в поиске такова, что с маленьким бюджетом трудно рассчитывать на большой результат.

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

Если денег нет, советуем попробовать осваивать поисковую оптимизацию самостоятельно или с привлечением менее раскрученных и распиаренных агентств или специалистов.

10. У вас одна посадочная страница в высококонкурентной тематике

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

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

Например, даже если вы предлагаете услуги эвакуатора можно выделить разделы Легковой эвакуатор и Грузовой эвакуатор, а также создать региональные страницы (Эвакуатор в Коломне, Эвакуатор в Серпухове и т. д.).

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

11. Нет никаких альтернативных каналов продаж, а продажи нужны сразу

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

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

Нужно ли вам SEO?

Как видите, ставка на SEO не всегда оправдывает себя. Поисковая оптимизация длительный и ресурсоемкий процесс, который приносит плоды, но только при определенных условиях. Если они заведомо невыполнимы, вы рискуете потерять и деньги, и время. Выбирайте исполнителей, которые вводят клиентов в курс дела и предоставляют объективную информацию о возможностях продвижения сайта, о потенциальных точках роста и перспективах его развития.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru