Методология как алгоритмика

В посте "Алгоритмика-2024" (https://ailev.livejournal.com/1727440.html) мы смотрели на алгоритмику, уподобляя её как-то методологии (стратегирование -- поиск способа решения задачи, в нашем случае алгоритма как описания метода вычисления, дающего оптимум по результатам/точности и ресурсам) и операционному менеджменту (операционный менеджмент, рациональное использование ресурсово) и там внутри много ещё всего разного, например, рациональность как способ выбора из множества вариантов алгоритмов. Конечно, там ещё и иерархия хардвера (транзисторы из разных материалов, логические ключи из транзисторов, какие-то вычислительные "ядра" из логических ключей, программирование и микропрограммирование этих самых "ядер" с выходом на софт -- и так дальше вплоть до "алгоритма программы, выполняемой на микросервисах в разных датацентрах мира").

Но всё это можно развернуть и ровно в обратном направлении: а что может дать алгоритмика для методологии, чтобы уж не обучать всему и сразу. При этом помним, что задачи планирования действий в реальном мире (поиск метода решения задачи, а потом составление эффективного плана, соответствующего этому методу -- и можно обсуждать это "логическое потом" как "планирование на лету") пока ещё эффективно не решены ни в GOFAI (экспертные системы на логике, локальные представления) ни в современном AI-на-LLM (нейросетки, имеющие внутри себя какую-то структуру с эмерджентными свойствами -- "виртуальная машина для алгоритмов, изложенных формально и не очень формально, но в распределённых представлениях"). И ещё было огромное число работ в 80х годах, где прямо отождествлялось умение планировать работы и создавать алгоритмы, с мелкими дополнениями о том, что кроме "планирования" можно ещё и "программировать" -- то есть составлять планы "на лету" (управление проектами как upfront планирование и управление программами проектов, в СМД-методологии это различение между проектированием и программированием как "движением в воронке возможностей"). И тогда же в период активных исследований GOFAI до середины 80х обсуждались всякие general problem solvers, общие решатели проблем, с надеждой потом из общих решателей проблем в виртуальном мире перейти к решениям проблем в реальном мире. Всё это было, увы, безрезультатно.

Автор этих строк в качестве первого рабочего задания после университета (1980 год) получил создать язык для описания строительства здания -- и не знал, что он попал в отдел, который как раз занимается проблемами AI на базе класса систем, известных как "фреймовые". Постановка задачи была примерно такой: "давай опишем алгоритм строительства дома на каком-то языке. Но мы знаем продолжительность каждой операции и требуемые ресурсы -- для этого у нас есть СНиПы, строительные нормы и правила. Затем мы просто посчитаем длительность стройки в компьютере. Так что дай нам соответствующий язык описания". Конечно, в головах у всех в 1980 году был именно императивный подход к таким описаниям -- который доблестно провалился. Попытки сначала сделать язык для чего-то маленького (конечно, автор через пару недель попытки описания стройки понял, что задача пока никому не по зубам, хотя за неё брались многие -- но был молод и не отчаивался), например, сделать язык формального описания для книг кулинарных рецептов, тоже ни к чему не привели. И только после многих лет становится понятным, почему всё было так плохо и почему идеи методологии трудно показать в их формализме:

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

2. Это не простой алгоритм, а алгоритм действий в реальном мире, 4E (extended, embedded, embodied, enactive, https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7250653/) и если computer science должна экспериментально подтверждать, что алгоритм эффективно выполним на каком-то железе, то тут методология с операционным менеджментом должны экспериментально подтверждать, что создатель с его мастерством (реализованным тоже аппаратно!) и инструментарием (tooling), реализуя метод, будут получать результаты заданного качества/точности в приемлемое время и при приемлемом расходе ресурсов. Алгоритм — это вроде как последовательность вычислений, а тут — последовательность каких-то трансформаций для создателя, обобщение алгоритма для вычислителя (машины Тьюринга) на материальный/физический мир. И тут надо разбираться с теоретическими обобщениями, например, constructors из constructor theory https://www.constructortheory.org/ как обобщения машины Тьюринга как универсального вычислителя в сторону универсального преобразователя. С помощью подобной теории мы можем пробовать выдать какие-то достижения современной алгоритмики за начальные идеи в методологии, мы вполне можем понимать алгоритмы как "алгоритмы в том числе для станка с ЧПУ" и теории не математические, а вполне себе теории про реальный мир: -- говорить о разных видах оптимизации, включая идеи по линии теоремы о бесплатном обеде: "нет методов, одинаково пригодных для решения разных задач -- одни методы хороши для одних задач, но плохи для других, и наоборот. Поэтому не бывает универсального эффективного метода, для каждого типа задач придётся придумывать новые методы"-- методы существенно зависят от наличной аппаратуры, как алгоритмы зависят от аппаратуры вычислителя, они все должны быть hardware aware, и тут важна аппаратура мастерства (вычислитель, выполняющий алгоритм, описывающий метод, то есть аппаратура "программы"), -- всяческие идеи по поводу разницы описания мира (для метода вообще, онтологии как модели мира) и описания данных (алгоритмы работают со структурами данных, и там модели/схемы данных). Эти замечания делает сейчас Крис Партридж в дискуссии, которую он ведёт с Барри Смитом и Джоном Совой, а также Михай Надином про разницу между концептуальными моделями и онтологиями и концептуальными моделями данных и схемами данных в длиннющем треде https://groups.google.com/g/ontolog-forum/c/83loKPZIPzk/m/ettbIhV9AgAJ. Там много интересного, в том числе о разнице между "описаниями объектов для манипулирования" и "нотациями для непосредственного манипулирования", что мы уже замечали. Но дальше по этой линии идёт DDD (где объекты реального мира сопоставляются объектам программы, как минимум -- моделируются структурами данных), и дальше вычислитель с этими данными сам по себе становится объектом реального мира, а не работает с описанием объекта (линия администрирования: если что-то поменялось в регистре, то это означает изменение в реальном мире -- обсуждается по самым разным линиям, включая теорию речевых актов, работающую с высказываниями, меняющими состояние мира: обещаниями, акцептами и т.д., см. разные работы Jan Dietz по онтологии предприятия). -- ключевой вопрос тут не просто в методологии как "вот какие бывают алгоритмы преобразований" (какие интересные физические штуки происходят), но и "операционный менеджмент" (какие интересные штуки в каком порядке надо сделать, чтобы "получить результат в срок и в бюджет", увеличить проход на заданном уровне качества, задача оптимизации). Тут тоже есть над чем подумать, ибо это ж ещё и реализация принципа наименьшего действия, "природный lean", но при этом оно ж недостижимо и оптимизацию в эту сторону надо делать "вручную", smart mutations методов и, наверное, еще и планов (помним, что алгоритмически задача планирования как-то не решается).3. Трудность в том, что разложение алгоритма представляется как код -- и понимание разных парадигм этого разложения алгоритма трудно. Автор этих строк знает огромное число программистов, которые в начале своей работы буквально страдали, пытаясь писать объект-ориентированно, но выдавая императивный код, а когда речь шла о переходе на функциональное программирование, например программирование на Haskell, имели вообще непреодолимые трудности. Даже если прорваться через типизацию объектов (что тоже проблема для многих людей -- поэтому-то и нужно использовать трюки типа "онтологического дребезга", "тошноты от склеек" и всякие другие альтернативные интерфейсы к мокрой нейросетке новоявленного методолога), то прорваться через функциональную парадигму будет очень трудно. Впрочем, и другие парадигмы тоже -- аспектное, акторское и т.д. программирование, каждое из них хотело быть лекарством, но само становилось проблемой, и даже функциональное программирование тут не исключение, помним про теорему о бесплатном обеде, при этом "функционального железа" нет, лисп-компьютеры в какой-то момент потерпели неудачу, они оказались явно менее скоростными по вычислениям для разных парадигм, и победили классические императивные вычислители. Но в базах данных победил SQL -- функциональный язык, причём полнотьюринговый. Но много ли людей могут похвастаться, что пишут на нём какие-то программы? Та же печальная судьба постигла средства логического программирования, тот же Пролог. Радикальное решение тут -- сразу учить конструктивизму, конструктивной математике, теории категорий. В любом случае, пошаговые представления метода -- работают в мизерном количестве случаев, сама методологическая/функциональная действительность требует функциональных/декларативных представлений, а не императивных. Функции могли бы срабатывать по выполнению предусловий и выдавать ожидаемые постусловия -- но в реальном мире, то есть "методы могли бы срабатывать по выполнению предусловий и выдавать ожидаемые постусловия", следовательно разложение метода должно как-то работать с очень труднопонимаемыми и контринтуитивными описаниями, материал "Разложения, спектры, стеки, слоёные пироги, программы и мастерства методов", https://ailev.livejournal.com/1727162.html, будет плохо пониматься нефункциональными программистами, даже если давать много примеров. Мало ведь понимать, как разложить метод для его описания алгоритмами (ещё и с выбором альтернатив, показано Gielingh в его описании инженерного процесса как мини-эволюции и пример для систем AI приведён в https://ailev.livejournal.com/1726875.html), надо потом хоть как-то понимать, как будет работать итоговый метод, собранный из его составляющих, выбранных при синтезе. И это с учётом трудностей из предыдущих пунктов: это всё не "функциональное или логическое программирование", а "функциональная или логическая методология" -- грубо говоря, программирование роботов, при этом какой-нибудь стадион со всем его персоналом и сооружениями -- робот, хотя и неантропоморфный (этот робот выполняет работы по тому, чтобы как-то загнать в себя несколько десятков тысяч человек, малая часть из которых будут развлекать другую часть, затем провести развлечение, включая пропуск только по билетам, затем кормление всей этой толпы, физическую безопасность, предоставление услуг туалетов. Часть оборудования робота-стадиона -- живые люди, которые ещё не заменены каким-то оборудованием, но они выполняют относительно простые программы). И вот понимать нужно, какими методами работает такой робот, как эти методы непротиворечиво описать и поставить, как отследить их выполнение, как разработать и построить такого робота, как эксплуатировать такого робота -- и это "как" тоже про методы, и это тоже про общую алгоритмику, ибо выполнение должно быть эффективно при заданном качестве выполнения! 4. Это всё происходит в условиях методического сверхразнообразия, кембрийского взрыва методов -- и непонятно, что лучше: взять готовый метод, или создать новый. Например, по данным Американской ассоциации психологии с 1993 года было опубликовано около 39000 новых конструктов и 43000 новых методов. Более половины этих методов никогда не использовались за пределами своей первоначальной статьи, в которой они были представлены, https://osf.io/preprints/psyarxiv/b4muj. Можно поглядеть, как выглядит картинка "методов в психологии" -- интерактивная карта со ссылками на литературу https://rubenarslan.github.io/construct_proliferation/. По идее, если вы хотите рассказать про "методы в психологии", то вам надо понять, как вообще этому учить, вам же надо как-то рассказать что-то важное про вот это месиво методов, где каждый прямоугольничек -- это вполне себе описанный метод, площадь прямоугольничка пропорциональна его распространённости (но ничего не говорит о верности, помним, что теория флогистона и теория эфира когда-то были в физике тоже чрезвычайно распространены вместе с базирующимися на них методами описаний мира). То же самое -- методы создания систем AI, и даже в самих методах физики, и даже в методах самой методологии, да и в кулинарии -- число рецептов как методов готовки конкретных блюд огромно, различать их трудно. Мы не можем по описаниям даже понять, идёт ли речь о каких-то группах вариантов методов, или отдельных методах, которые потом будут классифицированы как общий метод (например, все эти методы на табличках по ссылке классифицированы как "психология", но дальше возможны самые разные классификации -- по частоте употребления, по точности результатов, по выбранной в них онтологии описания предметов методов, по шкале времени описываемых в них работ, ибо мы понимаем, что психология работает с человеческим хардвером и можно оценить скорости). После этого становится непонятным, почему с таким многообразием должны работать люди, а не AI -- и даже в случае AI нет впечатления, что можно эффективно участвовать в этой эволюции методов. Как обычному человеку совладать с таким объёмом знаний, как стать методологом какой-то прикладной предметной области? Вот эта картинка для промышленной/организационной психологии, и это самый лучший случай, ибо исследователей и практиков тут не так много:

Источник: ailev.livejournal.com

Комментарии: