Главное > Рациональность
Пределы применимости байесовского подхода
mentalgopher:
--- Цитата: kuuff от 04 Апреля 2017, 11:00 ---Вы понимаете слово "редукция"? Редукция -- это операция. Представьте себе обратную операцию, и вы поймёте, что я имею в виду.
--- Конец цитаты ---
Хорошо, я переформулирую.
Как осуществить редукцию по описанию и получить анализ системы - мне понятно в общем случае.
Как в общем случае провести "обратную операцию к редукции" и осуществить синтез системы из элементов (или сказать чего недостаточно) - мне в общем случае непонятно.
Более того, я ожидаю, что доопределить "обратную операцию к редукции" вам не удастся в силу сложности мира, его невычислимости в общем случае.
И в силу этого мне непонятно, зачем вы используете формальные термины в качестве "универсально приложимых метафор".
kuuff:
Вы очень конкретно мыслите. Это хорошо в ряде ситуаций. Но это не позволяет вам мыслить о том, как вы мыслите. И мыслить о мышлении -- это не рефлексия имеющая исключительно теоретическое значение. Мышление -- это поиск, надо, выйдя из исходной точке, пройти многими путями в разные стороны, выискивая тот путь, который ведёт к цели. Эффективная организация этого поиска -- это самостоятельная задача, но чтобы решать эту задачу и пытаться соптимизировать решение, придётся думать о том, как идёт процесс мышления.
Редукция, в общем смысле -- это перевод неких утверждений из одних терминов в другие, из терминов более высокоуровневого описания, в термины низкоуровневого описания. Но в процессе поиска решений задач мы постоянно переводим утверждения не только "вниз", но и "наверх". Даже если речь идёт об инженерной задаче. Если я пытаюсь создать механические часы, то я начинаю редуцировать своё высокоуровневое представление о часах в низкоуровневое. Переводить с языка "циферблат, по которому движутся часовая и минутная стрелки, которые вращаются механизмом, который работает беря энергию от пружины, и дозируя расход этой энергии маятником", на язык конкретных шестерёнок, с конкретным количеством зубьев, формой зубьев, конкретным образом соединённых между собой, конкретным образом расположенными в пространстве относительно друг-друга. Это два разных языка описания задачи, и они оба являются инкапсуляцией. Высокоуровневый язык прячет от нас множество свойств системы, типа положения шестерёнок в пространстве. Низкоуровневый язык позволяет с этими свойствами работать, но при этом теряет какие-то высокоуровневые свойства и не позволяет о них говорить. Они оба нужны нам для того, чтобы разделять и властвовать. Чтобы не держать в голове одновременно всё, размышляя об устройстве часов.
Работая с этими языками мы постоянно переключаемся с одного на другой, потому что языки несовершенным образом приспособлены под устройство задачи, мы постоянно сталкиваемся с какими-то частными рассуждениями/подзадачами, в которых язык, который привёл нас к этой подзадаче, оказывается неприменим для решения этой задачи. Нам приходится переходить от одного языка к другому.
И вот тут вылезают редукция и "эмердженция". Мы на частных задачах редуцируем высокоуровневое описание ситуации в низкоуровневое, чтобы найти там какую-то конфигурацию шестерёнок, которая даст нам то, что нам нужно на высоком уровне. И получив это низкоуровневое описание, мы поднимаемся обратно наверх.
То есть, на самом деле, всё ещё сложнее: в таких ситуациях мышление идёт сразу на обоих уровнях, голова параллельно выстраивает рассуждения в двух разных моделях. Но в примере с часами всегда получается так хорошо, в силу простоты задачи.
То же самое можно продемонстрировать на примере задачи разработки программы. Пишется библиотека, которая инкапсулирует какое-то взаимодействие с системой, выставляя наружу какой-то API, который мы спроектировали таким образом, чтобы потом нам было бы удобно мысля в абстракциях этого API решать более сложную, более высокоуровневую задачу. При этом, поскольку в общей ситуации невозможно создать хороший API не создавая при этом ту часть программы, которая будет пользоваться этим API (или хотя бы не представляя как будет эта высокоуровневая часть работать), то при проектировании мы постоянно мечемся с языка низкоуровневых операций, которые должны быть спрятаны под API, к высокоуровневому представлению задачи, выраженному на языке абстракций предлагаемых этим API. Эта вся проблема, между прочим, в программировании имеет форму специальной олимпиады: top-down vs bottom-up approaches, написание программы сверху-вниз или снизу-вверх. Начать ли писать программу с написаня простых, низкоуровневых функций, постепенно переходя ко всё более и более высокоуровневым, или писать её сверху-вниз, начав с написания самых высокоуровневых, используя в них ещё вызовы ещё ненаписанных функций, затем писать эти ненаписанные функции, полагаясь на другие ненаписанные, и со временем добраться таким образом до простых низкоуровневых функций, написать их, и получить рабочий код.
Просто всё чуть сложнее, чем просто сверху-вниз или снизу-вверх. Разрабатывая систему мы постоянно выполняем переходы туда и обратно.
И понимание этого процесса может позволить оптимизировать процесс поиска решения общей задачи. Я опять же могу нарисовать аналогию. Если мне надо найти выход из лабиринта, то я могу использовать алгоритм, который будет принимать решения основываясь на локальных свойствах лабиринта, на тех свойствах которые я непосредственно наблюдаю находясь в какой-то точке лабиринта. Либо я могу в процессе поиска строить карту той части лабиринта, которую я обошёл, и через это рефлексировать свою деятельность, и находить менее очевидные ходы, которые позволят мне уменьшить время потраченное на обход лабиринта. Больше думать, меньше ходить.
Выныривая из аналогии... Чтобы понимать как происходит процесс мышления, надо иметь какие-то слова, для описания основных операций, как идёт мышление. И я уверен, что редукционный переход и обратный ему "эмерджентный" переход -- это пара операций, для которых обязательно надо иметь в голове слова. Это пара операций, которые всегда надо видеть, и не только потому, что они могут подсказать новый и неочевидных кульбит мысли, но ещё и потому, что отслеживая их можно избавлять мышление от ряда ошибок, которые очень свойственны человеческому мышлению. Например, непродуктивная редукция. Скажем, вопрос "как работает память человека"? Биолог с удовольствием ответит на этот вопрос, начав произносить слова "нейроны, синапсы, образование новых синапсов, увеличение/уменьшение числа синаптических рецепторов,..." Это редукция. Но непродуктивная, потому что она не позволяет ответить на множество вопросов, которые у нас возникают в связи с памятью: почему человек помнит что-то, может узнать это, но не может вспомнить? Помнит ли человек вообще всё, но не всегда может вспомнить, или он помнит не всё? Как меняется содержимое памяти со временем? Меняется ли оно непрерывно, или только когда мы воспроизводим это содержимое? Все эти вопросы существуют на "высоком" уровне абстракции, но исчезают на низком. Это не значит, что надо отказываться от редукционного перехода -- нет, это значит, что для решения этих вопросов нужно уметь выполнять обратный переход. Но мышление человека очень склонно совершать ошибку: услышав объяснение биолога, оно помечает проблему памяти как решённую, а потом, сталкиваясь с вопросами на которые нет ответов, мышление впадает в когнитивный диссонанс (оно же "знает" что проблема решена, так?) и начинает сглаживать противоречие отрицая существование этих безответных вопросов. Говоря, например, "перечисленные проблемы байесианства -- это вовсе не проблемы". Сам по себе когнитивный диссонанс не плох и не хорош, так же как и сглаживание противоречий, но в данном случае это приводит человека к тому, что имея пробелы в своём понимании общей ситуации он не видит этих пробелов, не осознаёт их, избегает осознавать их. Имея белые пятна на карте, человек не видит их примерно так же, как он не видит гориллу, когда считает количество передач мяча (https://www.youtube.com/watch?v=IGQmdoK_ZfY).
И это сказывается также и при решении инженерных задач. В рамках того примера с программированием, это приводит к тому, что проектируя программу и её внутренние API, программист выпускает из рассмотрения какие-то проблемы. Эти проблемы вылезут потом, в процессе реализации проекта, и вот там они могут причинить существенную боль, потому что общая спроектированная структура программы не рассчитана на эти проблемы. И тогда приходится нарушать какие-то инварианты, нарушать инкапсуляцию, городить огород сложных телодвижений, разобраться в которых потом будет невозможно.
Если же всегда чётко выделять редукционные переходы, всегда давать себе отчёт, какие именно свойства системы мы потеряли в результате этого перехода, отслеживать всегда то, в рамках какой модели -- высокоуровневой или низкоуровневой -- мы мыслим, то можно сделать такого рода ошибки менее вероятными. Избежать их совсем не удастся, но можно, по-крайней мере, помечать белые пятна на карте как белые и всегда видеть их, всегда осознавать ущербность карты. Причём не в виде абстрактного утверждения "любая карта не соответствует реальности", а в виде конкретного списка конкретных неточностей карты.
Объяснение биолога -- это объяснение памяти на уровне физиологии. Но объяснение памяти на уровне физиологии не может заменить собой объяснения памяти в терминах психики. Если получив какое-то объяснение я отдаю себе отчёт на каком уровне абстракции находится это объяснение, то я вижу какие уровни абстракции при этом остались без объяснения. Мышление обычного человека успокаивается, когда получает хотя бы одно объяснение. Тренированное же мышление не должно успокаиваться до тех пор, пока оно не получит объяснений на всех уровнях абстракции, которые используются при решении задачи. Если вы порефлексируете своё мышление, вы увидите как те примеры, когда ваше мышление успокаивалось получив одно объяснение, так и примеры тому, когда одного объяснения почему-то оказывалось недостаточно, и мысль продолжала искать второе, на другом уровне абстракции. Но принятие этого решения, этот выбор "искать ещё, или успокоится" происходил неосознанно -- не обязательно неверен, но он исходил из каких-то неосознаваемых эвристик. В ваших силах заменить эти эвристики сознательным процессом, осознающим свои сильные и слабые стороны.
mentalgopher:
--- Цитата: kuuff от 04 Апреля 2017, 12:46 ---Вы очень конкретно мыслите. Это хорошо в ряде ситуаций. Но это не позволяет вам мыслить о том, как вы мыслите. И мыслить о мышлении -- это не рефлексия имеющая исключительно теоретическое значение. Мышление -- это поиск, надо, выйдя из исходной точке, пройти многими путями в разные стороны, выискивая тот путь, который ведёт к цели. Эффективная организация этого поиска -- это самостоятельная задача, но чтобы решать эту задачу и пытаться соптимизировать решение, придётся думать о том, как идёт процесс мышления.
--- Конец цитаты ---
То, что вы описываете как мышление, для меня неотличимо от метода проб и ошибок, пусть и помещённого на вершину иерархии.
Я придерживаюсь подхода Аристотеля про то, что в основе мышления лежит логика, схема.
И меня ничуть не расстраивает, что я не способен мыслить о мышлении. Но если вы способны - предъявите схему.
И вы говорите об оптимизации, но почему-то не предъявляете оптимизируемые параметры. Не надо так, это превращает содержательные разговоры в "за всё хорошее против всего плохого". Keep focus.
--- Цитата: kuuff от 04 Апреля 2017, 12:46 ---Редукция, в общем смысле -- это перевод неких утверждений из одних терминов в другие, из терминов более высокоуровневого описания, в термины низкоуровневого описания. Но в процессе поиска решений задач мы постоянно переводим утверждения не только "вниз", но и "наверх". Даже если речь идёт об инженерной задаче. Если я пытаюсь создать механические часы, то я начинаю редуцировать своё высокоуровневое представление о часах в низкоуровневое. Переводить с языка "циферблат, по которому движутся часовая и минутная стрелки, которые вращаются механизмом, который работает беря энергию от пружины, и дозируя расход этой энергии маятником", на язык конкретных шестерёнок, с конкретным количеством зубьев, формой зубьев, конкретным образом соединённых между собой, конкретным образом расположенными в пространстве относительно друг-друга. Это два разных языка описания задачи, и они оба являются инкапсуляцией. Высокоуровневый язык прячет от нас множество свойств системы, типа положения шестерёнок в пространстве. Низкоуровневый язык позволяет с этими свойствами работать, но при этом теряет какие-то высокоуровневые свойства и не позволяет о них говорить. Они оба нужны нам для того, чтобы разделять и властвовать. Чтобы не держать в голове одновременно всё, размышляя об устройстве часов.
Работая с этими языками мы постоянно переключаемся с одного на другой, потому что языки несовершенным образом приспособлены под устройство задачи, мы постоянно сталкиваемся с какими-то частными рассуждениями/подзадачами, в которых язык, который привёл нас к этой подзадаче, оказывается неприменим для решения этой задачи. Нам приходится переходить от одного языка к другому.
И вот тут вылезают редукция и "эмердженция". Мы на частных задачах редуцируем высокоуровневое описание ситуации в низкоуровневое, чтобы найти там какую-то конфигурацию шестерёнок, которая даст нам то, что нам нужно на высоком уровне. И получив это низкоуровневое описание, мы поднимаемся обратно наверх.
То есть, на самом деле, всё ещё сложнее: в таких ситуациях мышление идёт сразу на обоих уровнях, голова параллельно выстраивает рассуждения в двух разных моделях. Но в примере с часами всегда получается так хорошо, в силу простоты задачи.
--- Конец цитаты ---
Мне всё ещё не ясно, откуда вы берёте иерархию - "высокоуровневое описание" и "низкоуровневое описание".
Скажем, я привёл 9 описаний, мне по работе нужно уметь хотя бы знать ключевые слова из каждой предметной области.
Как их соотнести по уровням:
- геохимия нефти и газа (из чего состоят углеводороды и в каких условиях пребывают)
- геология нефти и газа (какой рельеф вокруг углеводородов, пористость и проницаемость среды)
- инженерия нефтедобычи (каким способом извлекаем)
- физическая модель многофазного потока в пористой среде (выбор какие физ.эффекты важны)
- матфизика и запись диффуров с гранусловиями
- вычислительная математика (каким способом/алгоритмом ведём рассчёт)
- программирование (как закодить алгоритм в конкретном языке программирования)
- машинное обучение (часть параметров в алгоритме обучается автоматически, проверяем точность обучения)
- анализ и визуализация данных (как отображаем насчитанный результат)
В системной инженерии отношение часть-целое является базовым.
Через него задаются уровни "подсистема" - "целевая система" - "использующая система". Но эти уровни вполне физичны, потому что системы нарезаются на 4D индивиды с явными пространственно-временными границами.
Ручка является частью кружки, потому что занимает часть того пространства-времени, которое занимает кружка.
При этом мне совершенно непонятно, как могут быть высокоуровневыми или низкоуровневыми термины.
--- Цитата: kuuff от 04 Апреля 2017, 12:46 ---То же самое можно продемонстрировать на примере задачи разработки программы. Пишется библиотека, которая инкапсулирует какое-то взаимодействие с системой, выставляя наружу какой-то API, который мы спроектировали таким образом, чтобы потом нам было бы удобно мысля в абстракциях этого API решать более сложную, более высокоуровневую задачу. При этом, поскольку в общей ситуации невозможно создать хороший API не создавая при этом ту часть программы, которая будет пользоваться этим API (или хотя бы не представляя как будет эта высокоуровневая часть работать), то при проектировании мы постоянно мечемся с языка низкоуровневых операций, которые должны быть спрятаны под API, к высокоуровневому представлению задачи, выраженному на языке абстракций предлагаемых этим API. Эта вся проблема, между прочим, в программировании имеет форму специальной олимпиады: top-down vs bottom-up approaches, написание программы сверху-вниз или снизу-вверх. Начать ли писать программу с написаня простых, низкоуровневых функций, постепенно переходя ко всё более и более высокоуровневым, или писать её сверху-вниз, начав с написания самых высокоуровневых, используя в них ещё вызовы ещё ненаписанных функций, затем писать эти ненаписанные функции, полагаясь на другие ненаписанные, и со временем добраться таким образом до простых низкоуровневых функций, написать их, и получить рабочий код.
Просто всё чуть сложнее, чем просто сверху-вниз или снизу-вверх. Разрабатывая систему мы постоянно выполняем переходы туда и обратно.
--- Конец цитаты ---
Если я вызываю большой сторонний модуль/библиотеку в одну строчку, это "простая низкоуровневая функция" или нет?
Я понимаю, когда говорят о функциональной декомпозиции в принципиальной схеме - там уровни между функциями прослеживаются (и как правило сторонняя библиотека реализует высокоуровневую функцию).
Я понимаю, когда говорят о модульной декомпозиции - из каких блоков код будет компилироваться.
Я понимаю, когда говорят за архитектурный дизайн и функционально-модульный синтез - и рассматривают разные способы совмещения функциональной и модульной декомпозиций.
--- Цитата: kuuff от 04 Апреля 2017, 12:46 ---И понимание этого процесса может позволить оптимизировать процесс поиска решения общей задачи. Я опять же могу нарисовать аналогию. Если мне надо найти выход из лабиринта, то я могу использовать алгоритм, который будет принимать решения основываясь на локальных свойствах лабиринта, на тех свойствах которые я непосредственно наблюдаю находясь в какой-то точке лабиринта. Либо я могу в процессе поиска строить карту той части лабиринта, которую я обошёл, и через это рефлексировать свою деятельность, и находить менее очевидные ходы, которые позволят мне уменьшить время потраченное на обход лабиринта. Больше думать, меньше ходить.
--- Конец цитаты ---
Вы предлагаете увеличить временные затраты на обдумывание. А принесёт ли такой ход пользу? Если да, то какую?
Может, наоборот, имеет смысл меньше думать и больше ходить?
--- Цитата: kuuff от 04 Апреля 2017, 12:46 ---Выныривая из аналогии... Чтобы понимать как происходит процесс мышления, надо иметь какие-то слова, для описания основных операций, как идёт мышление. И я уверен, что редукционный переход и обратный ему "эмерджентный" переход -- это пара операций, для которых обязательно надо иметь в голове слова. Это пара операций, которые всегда надо видеть, и не только потому, что они могут подсказать новый и неочевидных кульбит мысли, но ещё и потому, что отслеживая их можно избавлять мышление от ряда ошибок, которые очень свойственны человеческому мышлению. Например, непродуктивная редукция. Скажем, вопрос "как работает память человека"? Биолог с удовольствием ответит на этот вопрос, начав произносить слова "нейроны, синапсы, образование новых синапсов, увеличение/уменьшение числа синаптических рецепторов,..." Это редукция. Но непродуктивная, потому что она не позволяет ответить на множество вопросов, которые у нас возникают в связи с памятью: почему человек помнит что-то, может узнать это, но не может вспомнить? Помнит ли человек вообще всё, но не всегда может вспомнить, или он помнит не всё? Как меняется содержимое памяти со временем? Меняется ли оно непрерывно, или только когда мы воспроизводим это содержимое? Все эти вопросы существуют на "высоком" уровне абстракции, но исчезают на низком. Это не значит, что надо отказываться от редукционного перехода -- нет, это значит, что для решения этих вопросов нужно уметь выполнять обратный переход. Но мышление человека очень склонно совершать ошибку: услышав объяснение биолога, оно помечает проблему памяти как решённую, а потом, сталкиваясь с вопросами на которые нет ответов, мышление впадает в когнитивный диссонанс (оно же "знает" что проблема решена, так?) и начинает сглаживать противоречие отрицая существование этих безответных вопросов. Говоря, например, "перечисленные проблемы байесианства -- это вовсе не проблемы". Сам по себе когнитивный диссонанс не плох и не хорош, так же как и сглаживание противоречий, но в данном случае это приводит человека к тому, что имея пробелы в своём понимании общей ситуации он не видит этих пробелов, не осознаёт их, избегает осознавать их. Имея белые пятна на карте, человек не видит их примерно так же, как он не видит гориллу, когда считает количество передач мяча (https://www.youtube.com/watch?v=IGQmdoK_ZfY).
--- Конец цитаты ---
Проблемой в википедии называется вопрос, требующий изучения и разрешения.
Психолог может изучать вопрос как задать ёмкость памяти и как её исследовать. Но где тут уровень?
Такое чувство, что вы предлагаете считать, что нижайший уровень - это квантовая теория поля, а высочайший - это астрономия.
И редуцировать для вас - это значит взять что-то сложное и разложить его на мельчайшие элементы (что обычно непродуктивно). Редуцировать явление можно в разные предметные области, будут возникать разные описания, имеющие разную значимость с т.з. конкретного исследователя. А ваша "анти-редукция" - это не мысленная операция, она подразумевает сборку машины по чертежу - и ещё непонятно, заработает ли та. Поэтому мне вообще непонятно, зачем об этом говорить, потому что получается очень непродуктивно.
--- Цитата: kuuff от 04 Апреля 2017, 12:46 ---И это сказывается также и при решении инженерных задач. В рамках того примера с программированием, это приводит к тому, что проектируя программу и её внутренние API, программист выпускает из рассмотрения какие-то проблемы. Эти проблемы вылезут потом, в процессе реализации проекта, и вот там они могут причинить существенную боль, потому что общая спроектированная структура программы не рассчитана на эти проблемы. И тогда приходится нарушать какие-то инварианты, нарушать инкапсуляцию, городить огород сложных телодвижений, разобраться в которых потом будет невозможно.
Если же всегда чётко выделять редукционные переходы, всегда давать себе отчёт, какие именно свойства системы мы потеряли в результате этого перехода, отслеживать всегда то, в рамках какой модели -- высокоуровневой или низкоуровневой -- мы мыслим, то можно сделать такого рода ошибки менее вероятными. Избежать их совсем не удастся, но можно, по-крайней мере, помечать белые пятна на карте как белые и всегда видеть их, всегда осознавать ущербность карты. Причём не в виде абстрактного утверждения "любая карта не соответствует реальности", а в виде конкретного списка конкретных неточностей карты.
Объяснение биолога -- это объяснение памяти на уровне физиологии. Но объяснение памяти на уровне физиологии не может заменить собой объяснения памяти в терминах психики. Если получив какое-то объяснение я отдаю себе отчёт на каком уровне абстракции находится это объяснение, то я вижу какие уровни абстракции при этом остались без объяснения. Мышление обычного человека успокаивается, когда получает хотя бы одно объяснение. Тренированное же мышление не должно успокаиваться до тех пор, пока оно не получит объяснений на всех уровнях абстракции, которые используются при решении задачи. Если вы порефлексируете своё мышление, вы увидите как те примеры, когда ваше мышление успокаивалось получив одно объяснение, так и примеры тому, когда одного объяснения почему-то оказывалось недостаточно, и мысль продолжала искать второе, на другом уровне абстракции. Но принятие этого решения, этот выбор "искать ещё, или успокоится" происходил неосознанно -- не обязательно неверен, но он исходил из каких-то неосознаваемых эвристик. В ваших силах заменить эти эвристики сознательным процессом, осознающим свои сильные и слабые стороны.
--- Конец цитаты ---
Вы убедите меня, если покажите сообщество людей, которое практикует предложенный вами подход "поиска объяснений на всех уровнях абстракции" и получает хорошие результаты.
Пока что я вижу главный аргумент "знать больше лучше, чем знать меньше" - "лучше быть богатым и здоровым, чем бедным и больным" - "а вы заварки больше кладите".
Помогает ли такой подход концентрировать вероятность для нахождения проблемных мест? Я не вижу как.
Позволяет ли он рассуждать в схемах, которые экономят ресурс внимания и могут явно проверяться/отлаживаться? Я не вижу как.
Предлагаете ли вы методы, которыми будут составляться "конкретные списки конкретных неточностей карты"? Я не вижу таких.
Наконец, позволяет ли вам ваш метод сформулировать конкретную задачу с со списком возможных ответов, которую методы байесовской статистики не решают / дают неверные ответы? Не похоже, скорее ваш подход уводит вас в другие предметные области и вы не возвращаетесь из них назад к исходной задаче. Что грустно. Не надо так.
Добавлено 06 Апреля 2017, 12:36:
--- Цитата: kuuff от 04 Апреля 2017, 12:46 ---Если получив какое-то объяснение я отдаю себе отчёт на каком уровне абстракции находится это объяснение, то я вижу какие уровни абстракции при этом остались без объяснения. Мышление обычного человека успокаивается, когда получает хотя бы одно объяснение. Тренированное же мышление не должно успокаиваться до тех пор, пока оно не получит объяснений на всех уровнях абстракции, которые используются при решении задачи. Если вы порефлексируете своё мышление, вы увидите как те примеры, когда ваше мышление успокаивалось получив одно объяснение, так и примеры тому, когда одного объяснения почему-то оказывалось недостаточно, и мысль продолжала искать второе, на другом уровне абстракции. Но принятие этого решения, этот выбор "искать ещё, или успокоится" происходил неосознанно -- не обязательно неверен, но он исходил из каких-то неосознаваемых эвристик. В ваших силах заменить эти эвристики сознательным процессом, осознающим свои сильные и слабые стороны.
--- Конец цитаты ---
Ключевое моё возражение - что таким образом вы получите эрудированное гуманитарное мышление, которое разбирается в тонких оттенках объяснений. А зачем это нужно?
Я вот совсем недавно окончил курс системного мышления, опирающийся на системную инженерию и инженерный менеджмент. Вся системность упирается в постановку вопросов, внятный ответ на которые, будучи общим знанием команды, продвигает проект к успешному завершению.
Например, вопрос "где наша целевая система, что именно мы производим?" Мы выпускаем металлические чушки и целевая система - это партия товара или мы оказываем сервис по доставке чушек и целевая система поставка заказа с чушками? Ответ на этот вопрос сильно влияет на выбор ключевых показателей и предполагает разную специализацию компании на рынке. Выбор альтернативного ответа приводит к альтернативным действиям.
У вас же я перехода к действиям я вообще не заметил. Посидим, покумекаем, составим суперточную карту. А делать когда? Почему более длительная деятельность с менее точной картой не приведёт к большему успеху?
Основной урок из системного мышления, что я извлёк - он ровно про это - основная польза приходит от забарывания ошибок по ключевым направлениям. Важно уметь концентрироваться на этих ключевых направлениях, как минимум уметь их проговаривать, и важно, чтобы работа с ними влияла на итоговый результат (что тоже нужно уметь проговаривать и обосновывать). Всё остальное - рецепты как применить системный подход в деле.
kuuff:
--- Цитата: mentalgopher от 05 Апреля 2017, 17:15 ---То, что вы описываете как мышление, для меня неотличимо от метода проб и ошибок, пусть и помещённого на вершину иерархии.
Я придерживаюсь подхода Аристотеля про то, что в основе мышления лежит логика, схема.
--- Конец цитаты ---
Логика и схема -- это не мышление и не основа мышления, это результат мышления, это продукт. Точнее даже не продукт, а некий измерительный инструмент, позволяющий эвристически оценить качество продукта.
--- Цитата: mentalgopher от 05 Апреля 2017, 17:15 ---Такое чувство, что вы предлагаете считать, что нижайший уровень - это квантовая теория поля, а высочайший - это астрономия.
--- Конец цитаты ---
Нет. Астрономия описывает не такую уж и сложную систему. Она потрясает масштабами, она потрясает тем разнообразием явлений, которые являются следствиями относительно простых законов. Но и тем не менее, Вселенная, с точки зрения астрономии -- обладает не такой уж и большой сложностью, как система.
Самая сложная проблема, с которой приходилось связываться естественным наукам -- это биология. И за XX век им даже удалось сделать из биологии естественно-научную дисциплину. Сейчас очередь за психологией, которая ещё более сложная проблема, и пока естественно-научный подход буксует на этой проблеме. Уже лет 150 буксует.
Самые сложные проблемы, с которыми приходилось сталкиваться инженерам -- это написание программ: современные программы сложностью своею превышают то, что человек умеет создавать. И кстати в программировании тоже возникают идеи уровней. Начинаются выражения типа "стек ПО", "библиотека/клиентский код" и API между ними, много слоёв библиотек разделённых разными API, и тд. и тп. И споры о том, в каком именно слое надо решать ту или иную проблему.
Кстати я могу привести каноничный пример подобной иерархии с жёстким выделением границ по горизонтали между уровнями. Этот пример называется "модель и уровни OSI". Этим примером надоедают всем айтишникам в процессе обучения или даже на собеседованиях. Кстати, что самое смешное, эта модель с её уровнями так и осталась теоретической моделью, практические реализации, типа стека TCP/IP, всегда существенно отличаются от теоретической модели.
Суть модели в том, что один и тот же трафик, один и тот же поток информации может на разных уровнях модели выглядеть совершенно по разному. Электрические импульсы на самом нижнем уровне, или чёрт-его-знает что на самом верхнем уровне -- как там будет выглядеть трафик уже зависит от конкретного приложения. Нижние уровни занимаются передачей информации по кабелю, более верхние в пределах сегмента сети, ещё более верхние занимаются поиском маршрута и передачей пакетов по найденным маршрутам, ещё более верхние могут обеспечивать такие абстракции как "соединение", позволяя смотреть на трафик как на последовательность равнозначных байтов, а не на последовательность пакетов, которые занумерованы в одном порядке, а приходят в другом, при этом ещё некоторые теряются по пути.
Это очень удобная модель, которая делит одну большую и сложную задачу на много подзадач. Решение каждой подзадачи можно поменять без особых проблем. Собственно мы видим это каждый день, когда наш интернет может работать как через проводное соединение, причём через медный или оптоволоконный кабель, так и через беспроводное, типа wifi или 4G. Содержимое одного уровня меняется, но остальные остаются теми же и продолжают работать.
И это пример. Вообще всё человеческое знание огранизовано примерно схожим образом, но что замечательно в этом примере, как в примере инженерном, это то, что "реальность" (в смысле конкретные технологии) подстраивается под знания, а не знания под реальность. Есть общие знания "как отобразить сайт в браузере", но они делятся на много отдельных кусков, некоторые из которых друг относительно друга располагаются по вертикали (TCP и IP например), а некоторые по горизонтали и они взаимозаменяемы (IPv4 и IPv6, например).
Но реальность всё равно сложнее: я могу взять и поверх существующей TCP/IPv4 сетки построить VLAN, в котором будет крутится TCP/IPv6 сеть. То есть реальные примеры использования не укладываются в эту модель. Но тут уже никто не парится придумывать более сложную модель, которая справится со всеми use-case'ами. Я не уверен почему.
Финально же я добавлю, что любой системный администратор достаточного уровня знаком с OSI, и более того не примет на работу того, кто не знаком. И не потому, что он может объяснить какие конкретно задачи позволяет решать OSI, а потому, что если человек не понимает OSI, значит он недостаточно глубоко понимает устройство сети. Может быть он может собрать сеть и настроить её, но истинного понимания у него нет.
--- Цитата: mentalgopher от 05 Апреля 2017, 17:15 ---И редуцировать для вас - это значит взять что-то сложное и разложить его на мельчайшие элементы (что обычно непродуктивно).
--- Конец цитаты ---
Нет. Не на мельчайшие, а на более мелкие. Точнее, не на более мелкие, а на более простые. Причём эта простота/сложность вполне измерима. Теоретически, по-крайней мере.
--- Цитата: mentalgopher от 05 Апреля 2017, 17:15 ---Вы убедите меня, если покажите сообщество людей, которое практикует предложенный вами подход "поиска объяснений на всех уровнях абстракции" и получает хорошие результаты.
--- Конец цитаты ---
Научное сообщество. Но с некоторыми оговорками: то что творится в моей голове и то как я это излагаю может не совпадать с тем, что творится в головах у других. Точнее оно совершенно точно не совпадает: ведь именно из-за этих несовпадений мне и советуют читать философов. Но в общих чертах, я уверен, в моей голове примерно то же самое, что и у философов.
--- Цитата: mentalgopher от 05 Апреля 2017, 17:15 ---Ключевое моё возражение - что таким образом вы получите эрудированное гуманитарное мышление, которое разбирается в тонких оттенках объяснений. А зачем это нужно?
--- Конец цитаты ---
Чтобы думать о действительно сложных проблемах. Чтобы думать о нерешённых проблемах, о тех проблемах, для которых нет готового алгортима решения. О проблемах, которые сложны настолько, что даже разработка понятийного аппарата является нерешённой проблемой. О проблемах, которые не удаётся даже чётко сформулировать из-за отсутствия законченного понятийного аппарата.
Гляньте на это творчество. Вот там, "Научный Метод" -- это, на самом деле, носитель естественно-научного мышления, который выпадает в прострацию столкнувшись с единичным, уникальным объектом. Он отказывается рассматривать в качестве свидетельств продукты деятельности людей, потому что они для него недостаточно достоверны, он не умеет работать при таком уровне неопределённости. И он вообще ничего не сможет сделать, до тех пор пока ему не удастся создать индустрию, занятую разведением золотых рыбок, с тем чтобы иметь неограниченное количество идентичных золотых рыбок для постановки экспериментов.
И, кстати, чем мне нравится байесианство, оно в этом смысле очень пересекается с гуманитарными методами. Байесианство говорит о том, что мы должны использовать любое свидетельство, в том числе и субъективное, и недостоверное. Байесианство учит нас работать в неопределённых условиях, и делать выводы при недостаточных данных.
--- Цитата: mentalgopher от 05 Апреля 2017, 17:15 ---Я вот совсем недавно окончил курс системного мышления, опирающийся на системную инженерию и инженерный менеджмент. Вся системность упирается в постановку вопросов, внятный ответ на которые, будучи общим знанием команды, продвигает проект к успешному завершению.
Например, вопрос "где наша целевая система, что именно мы производим?" Мы выпускаем металлические чушки и целевая система - это партия товара или мы оказываем сервис по доставке чушек и целевая система поставка заказа с чушками? Ответ на этот вопрос сильно влияет на выбор ключевых показателей и предполагает разную специализацию компании на рынке. Выбор альтернативного ответа приводит к альтернативным действиям.
--- Конец цитаты ---
Нисколько не умаляя этого курса, я бы сказал, что его название несколько вводит в заблуждение. Это не курс системного мышления в общем, это курс системного мышления в рамках некоторого круга проблем. Я не возьмусь очерчивать этот круг и пытаться как-то определить его, но судя по вашему описанию -- это проблемы принятия решений в рамках уже готового понимания ситуации, в рамках готовой системы. Это проблемы где этап исследования либо отсутствует, либо сводится к применению готовых алгоритмов, которые не дают нового понимания ситуации, они не дают новой модели ситуации, новой системы, они лишь обеспечивают существующую модель числами, которые надо подставить в формулы, чтобы получить результат.
Легко думать системно, когда есть система. Попробуйте думать системно там, где нет системы.
--- Цитата: mentalgopher от 05 Апреля 2017, 17:15 ---У вас же я перехода к действиям я вообще не заметил. Посидим, покумекаем, составим суперточную карту. А делать когда? Почему более длительная деятельность с менее точной картой не приведёт к большему успеху?
--- Конец цитаты ---
Делать будут ремесленники, но кто-то должен думать, не так ли? Если пять программистов сидят и кодят то, что им сказал руководитель проекта, то они работают в рамках тех абстракций, которые выбрал руководитель проекта. Но руководителю пришлось подумать над выбором абстракций, чтобы этот выбор не привёл бы впоследствии к тому, что результаты трудов отдельных программистов оказались бы несочетаемыми друг с другом. А если этот проект является частью большего проекта, то руководитель тоже загнан в некоторые рамки продуктов интеллектуального труда, которые были порождены специалистами более высокого класса.
UNIX был построен вокруг простой идеи "всё есть файл", но под этой идеей лежат огромные массивы кода, которые обеспечивают идею файла -- обычного в файловой системе, директории, которая тоже файл, FIFO, pipe, файлы устройств, сокеты, всякие специальные файловые системы в linux'е, типа procfs или udev. А если копнуть глубже, то там найдётся код, который работает с конкретными контроллерами накопителей информации, типа SSD или жёстких дисков. Там очень много кода. Кода организованного идеей "всё есть файл". Так вот, надо обладать очень широким видением ситуации, чтобы породить идею "всё есть файл", идею которая позволяет построить целую операционную систему.
mentalgopher:
--- Цитата: kuuff от 07 Апреля 2017, 15:17 ---Логика и схема -- это не мышление и не основа мышления, это результат мышления, это продукт. Точнее даже не продукт, а некий измерительный инструмент, позволяющий эвристически оценить качество продукта.
--- Конец цитаты ---
Тогда я не понял, что вы называете мышлением.
Для меня наличие логики в "мыслительных ходах" означат наличие мышления. Нет логики (известного типа) - нет мышления (известного типа).
--- Цитата: kuuff от 07 Апреля 2017, 15:17 ---Нет. Астрономия описывает не такую уж и сложную систему. Она потрясает масштабами, она потрясает тем разнообразием явлений, которые являются следствиями относительно простых законов. Но и тем не менее, Вселенная, с точки зрения астрономии -- обладает не такой уж и большой сложностью, как система.
Самая сложная проблема, с которой приходилось связываться естественным наукам -- это биология. И за XX век им даже удалось сделать из биологии естественно-научную дисциплину. Сейчас очередь за психологией, которая ещё более сложная проблема, и пока естественно-научный подход буксует на этой проблеме. Уже лет 150 буксует.
--- Конец цитаты ---
Вау. Вы называете проблемой не "разработать набор методов, решающих задачу Х", а что-то другое, возможно, продвижение в исследовательской программе.
И непонятно, что для таких проблем будет сложностью.
--- Цитата: kuuff от 07 Апреля 2017, 15:17 ---Самые сложные проблемы, с которыми приходилось сталкиваться инженерам -- это написание программ: современные программы сложностью своею превышают то, что человек умеет создавать. И кстати в программировании тоже возникают идеи уровней. Начинаются выражения типа "стек ПО", "библиотека/клиентский код" и API между ними, много слоёв библиотек разделённых разными API, и тд. и тп. И споры о том, в каком именно слое надо решать ту или иную проблему.
--- Конец цитаты ---
Хмм, считаете ли вы, что система самолёт (с собственной ЛВС на борту) проще, чем софт для автопилота?
--- Цитата: kuuff от 07 Апреля 2017, 15:17 ---Это очень удобная модель, которая делит одну большую и сложную задачу на много подзадач. Решение каждой подзадачи можно поменять без особых проблем.
--- Конец цитаты ---
Инженеры называют это модульностью и то, насколько системы легко бьются на модули - compositionality.
--- Цитата: kuuff от 07 Апреля 2017, 15:17 ---Научное сообщество. Но с некоторыми оговорками: то что творится в моей голове и то как я это излагаю может не совпадать с тем, что творится в головах у других. Точнее оно совершенно точно не совпадает: ведь именно из-за этих несовпадений мне и советуют читать философов. Но в общих чертах, я уверен, в моей голове примерно то же самое, что и у философов.
--- Конец цитаты ---
Как вы проверяете, что "содержимое" то же самое?
Как вы задаёте принадлежность к научному сообществу? Вот Талеб, например, принадлежит?
Для меня это не праздные вопросы - знаю много случаев, когда математики что-то насчитали, а потом оказывается, что это нефизично.
Или химики синтезировали что-то новое, а биологи говорят - не, не пойдёт, ядовито. Вроде как и продвижение в своей области, а вроде и тупиковый путь для других областей.
Мне неизвестны сообщества людей (уточняю - научные коллективы), которые ищут "объяснения на всех уровнях абстракции". Каждый копает в направлении своей предметной области, а потом, возможно, открытия из разных областей переплетаются. Отсылаю к "мегабитовой бомбе" Лема.
Идея привязывать возникновение абстракций к чьей-то голове мне кажется вредной.
Полезней смотреть, что даёт людям обучение абстракциям и как это модифицирует их поведение.
--- Цитата: kuuff от 07 Апреля 2017, 15:17 ---Чтобы думать о действительно сложных проблемах. Чтобы думать о нерешённых проблемах, о тех проблемах, для которых нет готового алгортима решения. О проблемах, которые сложны настолько, что даже разработка понятийного аппарата является нерешённой проблемой. О проблемах, которые не удаётся даже чётко сформулировать из-за отсутствия законченного понятийного аппарата.
--- Конец цитаты ---
И как, получается? :troll_face:
Я всё же не понял, что вы предлагаете, кроме прокачки эрудиции.
Инженеры тысячи лет строили мосты, пока сопромата не было. И сейчас работают в тех областях, которые наукой ещё не охвачены.
И я не видел, чтобы они увлекались философией на ваш манер.
--- Цитата: kuuff от 07 Апреля 2017, 15:17 ---Гляньте на это творчество. Вот там, "Научный Метод" -- это, на самом деле, носитель естественно-научного мышления, который выпадает в прострацию столкнувшись с единичным, уникальным объектом. Он отказывается рассматривать в качестве свидетельств продукты деятельности людей, потому что они для него недостаточно достоверны, он не умеет работать при таком уровне неопределённости. И он вообще ничего не сможет сделать, до тех пор пока ему не удастся создать индустрию, занятую разведением золотых рыбок, с тем чтобы иметь неограниченное количество идентичных золотых рыбок для постановки экспериментов.
--- Конец цитаты ---
Когда я читал этот рассказ, мне было скорее грустно - потому что персонажи показаны именно что шаблонно, 0 уровень интеллектуальности по Юдковскому. Естественно-научное мышление вполне умеет делать выводы из наблюдений. А в тексте персонаж не потрудился даже список гипотез набросать (что сделало бы рассказ более вовлекающим).
Так что очень неубедительно.
--- Цитата: kuuff от 07 Апреля 2017, 15:17 ---И, кстати, чем мне нравится байесианство, оно в этом смысле очень пересекается с гуманитарными методами. Байесианство говорит о том, что мы должны использовать любое свидетельство, в том числе и субъективное, и недостоверное. Байесианство учит нас работать в неопределённых условиях, и делать выводы при недостаточных данных.
--- Конец цитаты ---
Где же байесианство так говорит про "субъективные и недостоверные" "свидетельства"? :)
--- Цитата: kuuff от 07 Апреля 2017, 15:17 ---Нисколько не умаляя этого курса, я бы сказал, что его название несколько вводит в заблуждение. Это не курс системного мышления в общем, это курс системного мышления в рамках некоторого круга проблем. Я не возьмусь очерчивать этот круг и пытаться как-то определить его, но судя по вашему описанию -- это проблемы принятия решений в рамках уже готового понимания ситуации, в рамках готовой системы. Это проблемы где этап исследования либо отсутствует, либо сводится к применению готовых алгоритмов, которые не дают нового понимания ситуации, они не дают новой модели ситуации, новой системы, они лишь обеспечивают существующую модель числами, которые надо подставить в формулы, чтобы получить результат.
--- Конец цитаты ---
Nope.
Половина труда системного инженера - это определение системы. Определить значит выявить предметные описания и связи между ними (и отразить всё это в документации).
И инженеры занимаются не исследованиями и формулировкой новых понятий (basic research), а разработками (НИОКР, R&D).
Новые модели тут как раз и возникают.
--- Цитата: kuuff от 07 Апреля 2017, 15:17 ---Легко думать системно, когда есть система. Попробуйте думать системно там, где нет системы.
Делать будут ремесленники, но кто-то должен думать, не так ли? Если пять программистов сидят и кодят то, что им сказал руководитель проекта, то они работают в рамках тех абстракций, которые выбрал руководитель проекта. Но руководителю пришлось подумать над выбором абстракций, чтобы этот выбор не привёл бы впоследствии к тому, что результаты трудов отдельных программистов оказались бы несочетаемыми друг с другом. А если этот проект является частью большего проекта, то руководитель тоже загнан в некоторые рамки продуктов интеллектуального труда, которые были порождены специалистами более высокого класса.
--- Конец цитаты ---
То, что руководитель проекта выбирает какие-то абстракции - противоречит моему опыту. "Мышление происходит промеж людей" - если руководитель и может внутри команды сказать, что будем делать так-то и так-то, то это не избавляет его от объяснения что сделано представителям заказчика. А значит, должен быть более-менее единый язык, в рамках которого будет взаимопонимание.
--- Цитата: kuuff от 07 Апреля 2017, 15:17 ---UNIX был построен вокруг простой идеи "всё есть файл", но под этой идеей лежат огромные массивы кода, которые обеспечивают идею файла -- обычного в файловой системе, директории, которая тоже файл, FIFO, pipe, файлы устройств, сокеты, всякие специальные файловые системы в linux'е, типа procfs или udev. А если копнуть глубже, то там найдётся код, который работает с конкретными контроллерами накопителей информации, типа SSD или жёстких дисков. Там очень много кода. Кода организованного идеей "всё есть файл". Так вот, надо обладать очень широким видением ситуации, чтобы породить идею "всё есть файл", идею которая позволяет построить целую операционную систему.
--- Конец цитаты ---
И для меня большой вопрос, что появилось первым - идея что "всё есть файл" позволяет написать операционную систему, или люди начали писать и поняли, что так делать эффективно и впоследствии обобщили наблюдения и перешли на такую организацию во всех частях системы.
Мнение, что "сначала была порождена идея, а потом она была реализована" - очень похожа на результат КИ знание задним числом.
Вполне допускаю, что человека, обладающего "очень широким видением ситуации" для "порождения глубокой идеи" могло и не быть, было найдено удачное частное решение (в рамках командной деятельности), которое оказалось легко обобщаемым и легло в основу архитектурного решения.
Навигация
Перейти к полной версии