Anatoly Levenchuk (ailev) wrote in dot15926,
Anatoly Levenchuk
ailev
dot15926

Categories:

Схема интеллектуального акта

Я считаю, что есть три стадии жизненного цикла интеллектуального акта (happy path, чему учат в школе, а не "включая всю экзотику, озарения и исключения, которые можно встретить в жизни).

1. Формализация, моделирование: блендинг, мэппинг, отождествление реальности и модели, двух разных моделей одной реальности, паттернирование (отождествление паттерна-модели и паттерна-в-реальности), аналогии, распознавания (отождествление модели того-что-распознаётся), перевод. Марковские цепи, глубокое обучение, распознавание образов, анализ сцен, нейронные сети и прочие веса.

Я бы назвал это "пониманием" -- сюда, конечно, входят все эти "ага!" и "озарения".

2. Формальные (по правилам) вывод, рассуждение, вычисления: расчёт по численной модели/формулам, применение консистентной теории, нахождение максимума/оптимума, дискретная математика и прочая логика. Солверы, оптимизаторы, виртуальные машины, процессоры.

Думание и использование озарений -- это тут.

3. Объяснение (деформализация, демоделирование): метафоризация, нарративизация, диалог, интерфейс, визуализация и т.д.: перевод вычисленного в те описания, из которых делалась формализация шага 1.

"Мысль изречённая есть ложь": вот решаемая тут проблема. Мало решить систему уравнений, нужно ещё и объяснить, что означает полученный в результате "думания" результат.

Ничего не мешает использовать второе для первого, или первое для второго, и вместе первое и второе для третьего. Но я бы их различал.

Объять необъятное невозможно. Пока мы в .15926 проекте концентрируемся на крохотном кусочке: представлении общего формального знания, получаемого мэппингом нескольких формальных знаний в общее представление (общая онтологическая/семантическая репрезентация, а не общая синтаксическая репрезентация). Но само по себе это бессмысленно, это 1/3 часть дела. Переводчик с языка на язык бесполезен, если переведённое затем никто не использует. Справочные данные (теория, опыт) бессмысленны, если нет вычислений с ними, если нет отождествления объектов реального мира на соответствие им. Мало перевести какие-то текстовые данные в "формальный вид", нужно ещё суметь организовать какое-то вычисление над этими данными. Если никто не вычисляет, то бессмысленно было преобразовывать.

Какой-то гарантией осмысленности является переброс данных между двумя вычислимыми моделями: тогда распознавание сущностей предметной области одного моделера в данных предметной области другого моделера полезно, в одном из этих моделеров/вычислителей может быть проведено рассуждение над данными другого моделера/вычислителя. Ежели задача ставится просто "преобразвать текст в формальное представление", то хорошего не будет. А вот ежели "выдрать из текста всё то, что кушается таким-то моделером/программой планирования/САПР/PLM", то вполне.

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

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

Это замечание, заметим, противоречит постановке задачи "преобразовать требования (ТЗ или стандарта) в ISO 15926", ибо выдирать из текста нужно только те требования, которые потом можно будет как-то проверить в известном CAD/PLM софте. А если их просто "преобразовать и затем хранить" -- то это бессмысленное преобразование, информационное загрязнение окружающей среды.

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

То есть пока "нашими" темами являются:
-- паттерны (архитектурные, онтологические и любые другие)
-- аналогии (Хофштадтер) и прототипы (Лакофф), меры семантической близости, VAE (от ViviMind)
-- метафоры и блендинг
-- извлечение фактов в компьютерной лингвистике

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

Так что на некоторое время паттерны -- это наше всё, нельзя объять необъятное. "Распознаём паттерны, делаем мэппинги. Онтология своя, моделеры/солверы/оптимизаторы заказчика, информация третьих лиц". Лужу, паяю, ЭВМ починяю...

См. также про эпистемологию в http://dot15926.livejournal.com/38046.html. Слоган может выглядеть так: "Мэппинги из эпистемологий третьих лиц в эпистемологию заказчика. Хорошую онтологию имеем свою".
Subscribe

  • Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 15 comments