Проблемы инженерных обоснований для существ, личности, сообщества, общества
Многочисленные проблемы появляются в тех случаях, когда мы выходим из инженерии киберфизических систем и/или программных систем в инженерию систем другой природы, и вот несколько примеров:
-
Проектирование финансов предприятия, сводящееся к бюджетированию. Обычно оно связано с разработкой бюджета, а затем исполнением бюджета, что занимает годичный цикл. Движение beyond budgeting и аналогичные ему1 представляет собой по факту попытку сделать непрерывное бюджетирование по модели DevOps, где сначала вместо годичного цикла (за год может случиться и скачок цен на продукцию, и уход надёжных поставщиков материалов, и скачки в валютных курсах, и забастовки, и наоборот — новые открытия, которые дают новые коммерческие возможности, но строгий годичный бюджет не даст возможность выжить в этих условиях) идут «итерации» бюджетирования «скользящим окном» сначала квартальным, потом месячным, но затем всё переходит к непрерывному бюджетированию, где разные части бюджета непрерывно дорабатываются, публикуются как план расходов, а потом происходит контроль исполнения бюджета, и в случае явных ошибок идёт быстрое изменение бюджета. Если на заводе Tesla кто-то знает, что он может улучшить свою часть инженерного процесса, то он просто обязан это сделать: купить новое оборудование и провести эксперимент. Для того, чтобы это сделать, нужна упрощённая процедура выделения финансов — ровно это и происходит. Не надо год ожидать, пока проверят твоё обоснование, rationale этих трат. Не надо потом год ждать, пока результаты эксперимента окажутся в основном производственном процессе.
-
При покупке предприятий, при заключении крупных сделок обычно проводят процедуры проверки due diligence2, чтобы убедиться в отсутствии каких-то неприятных сюрпризов, которые могут произойти после завершения сделки. Это тоже инженерное обоснование, «входной контроль», но речь идёт о личностях и организациях, и возникает сразу много интересных особенностей. Как минимум, полностью меняется терминология, полностью меняются процедуры, а ещё это разовое действие — хотя и тут возможны варианты, по ходу проекта ведь сразу начинается организационное развитие уже совместного (после M&A3, merges and acquisitions) предприятия.
-
Если речь идёт о показаниях в суде и высказываемых в них претензиях/claims отдельных людей, то как могут быть устроены обоснования? Врёт или не врёт человек, может быть проверено на детекторе лжи, который сам по себе может врать или не врать, надёжность такого «доказательства» очень низка. Можно использовать «сыворотку правды», хотя это по факту конспирология (набор легенд) и вряд ли работает с надёжностью выше случайности4, причём можно и попросту пытать «по старинке», хотя пытки — метод «испытаний» тоже не самый надёжный и полученное под пытками или даже угрозами пыток свидетельство/evidence в основу аргумента сегодня не положишь, поэтому и обосновать мало что получится. Тут сразу поднимается множество вопросов об этике методов получения свидетельств/улик/показаний/замеров, включая «судебный поединок»5 как ранее считавшийся вполне SoTA методом и сводящийся к дуэли. И вот мы получили вроде как свидетельства/улики/evidence такими сомнительными методами. Как оценивать результаты, как строить аргумент, если заранее известно, что свидетельство ненадёжно? Никакой же статистики для отдельных людей по отдельным вопросам набрать нельзя, а должны же быть вопросы про false positive и false negative заключения, ибо от ложных обоснований как positive, так и negative могут быть весьма драматические последствия (скажем, пожизненное заключение невиновных на основе ложных обоснований, сделанных судом). Всегда нужно помнить, что на любой плохой метод инженерного обоснования можно вспомнить метод ещё хуже, и по факту используются все эти методы, иногда и в одном проекте.
-
Клинические испытания6, которые массово проводятся прямо сейчас в порядке реализации идеи «доказательной/evidence-based медицины», представляются нерациональными, их нельзя считать получением надёжных обоснований7. Дело в том, что получаемая статистика относится к группе людей, а назначение лекарства после испытания получает один человек, а не группа. И при текущем положении дел с методами аргументирования классической статистикой путём проведения клинических испытаний даже двойным слепым методом, ничего сказать про персональное назначение препарата потом нельзя, но можно сказать методами причинного вывода/causal inference. По большому счёту, вся сегодняшняя «доказательная медицина» построена на песке, она ничего не доказывает (вернее, доказывает, но совсем не то, что нужно для инженерной части: для предсказуемого изменения мира), малопонятно, что с этим делать. Причинный вывод сегодня мало кем понимается, хотя он и решает множество имеющихся проблем. Впрочем, и текущий вариант причинного вывода нельзя считать последним словом: он опирается на расчёт байесовской, а не квантовоподобной вероятности, то есть заведомо даёт искажённый по сравнению с реальностью результат8. Тут есть ещё один интересный момент: если у вас больной заведомо умрёт, но есть минимальный шанс, что выживет, если вы дадите ему потенциально опасное лекарство, которое ещё не прошло клинических испытаний ни по какой методике (скажем, просто не успели): вы будете испытывать это лекарство на таком больном? Это будет лечение или испытание? А если вы оставите каких-то больных «контрольной группы» без этого лекарства, они ж заведомо умрут! Этично ли это? Вопросы множатся и множатся. Ровно такое же рассуждение надо проводить и для психотерапии, которая тоже терапия и должна быть evidence-based, и тут тоже огромное число вопросов к воспроизводимости результатов индивидуальных интервенций, набору статистики для абсолютно уникальных случаев и даже неотличимости «разговора с другом» или «разговора с AI» от терапевтического вмешательства. Переход от врача или психотерапевта к AI тут ничего не меняет: многочисленные статистические (даже двойным слепым методом) свидетельства того, что «AI не хуже человека-профессионала» не убирает вопросов к обоснованности того, что делает человек-профессионал в случае индивидуальных назначений.
-
Обоснование успешности обучения как инженерное обоснование какого-то мастерства. Подробней этот вопрос поднимается в руководстве по инженерии личности, вывод там печальный: экзамены обычно не показывают успешности обучения, кроме самых простых случаев элементарных навыков. Диплом вуза не показывает успешности в работе, результаты ЕГЭ не показывают успешности в жизни. Более того, большие проблемы с «экзаменами» (benchmarks) как методом получения свидетельств для обоснования успешности создания машинного интеллекта, то есть «испытания» тут понятно, как сделать, но положить их в основу обоснования успешности — нельзя.
-
Обоснование идей по социальной инженерии поднимает те же вопросы «экспериментов на людях». При этом даже в случае получения отрицательных результатов (например, все случаи сознательного устройства общества на основе социалистических идей были провальны, но попытки продолжаются и продолжаются, несмотря на «отрицательный результат испытаний», под лозунгом «они там всё неправильно делали, а вот у нас непременно получится!»). Одно из решений тут — ход на классический либерализм как обобщение хода, выработанного в ходе Реформации и кровопролитных религиозных войн католиков и гугенотов: они там все разрешили друг другу маршировать прямо в ад, ибо честно считали, что именно это и происходит, но прекратили насаждать путь в рай военным путём. Поэтому кто хочет маршировать прямо в социалистический голод и диктатуру (как считают одни) или социалистический рай (как считают другие) — пусть марширует, если не втягивает в это других людей, это неплохое начало. Но если это реальная социальная инженерия («я социальный инженер, то есть политик, знаю, как вам жить, верьте мне, я умней вас, неразумных»), а не допотопная эволюция, то неплохо бы для начала получить какие-то обоснования — и чтобы они были не «верую, так лучше», а не менее надёжны, чем инженерные обоснования для автопилотируемого автомобиля или атомной электростанции. И тут оказывается, что как и для клинических испытаний, как для экзаменов «готовности к жизни», как для «интеллекта» каких-то надёжных методов обоснования успешности социального инженерного проекта (обоснования успешности результата социальных реформ) нет. Это не значит, что нельзя предлагать каких-то «умных мутаций» и как-то пытаться выделить их результаты среди всего многообразия жизненных явлений (легко ведь сделать и неверные выводы: «100% из попробовавших в своей жизни огурцы людей рано или поздно умерли. Значит, огурцы вредны, статистика не может врать!»).
Проблема налицо: образование, социальная инженерия (политика), менеджмент, медицина, психотерапия — всё это, конечно, инженерия, но пока игнорирующая главный технический инженерный тренд: ход на непрерывное обоснование, ведение обосновывающего дела, автоматизацию экспериментального получения свидетельств успешности или неуспешности предлагаемых методов.
Без различения model-based и model-driven.
https://ru.wikipedia.org/wiki/Теория_субъективной_ожидаемой_полезности и https://ru.wikipedia.org/wiki/Теория_ожидаемой_полезности, https://ru.wikipedia.org/wiki/Ординалистская_теория_полезности, https://ru.wikipedia.org/wiki/Кардиналистская_теория_полезности, https://ru.wikipedia.org/wiki/Предельная_полезность. Вполне могут переводить сегодня и «ценность», при этом понимание на русском будет хуже. Вот сравните: «добавленная ценность» и «добавленная полезность» — первое непонятно как понимать, а второе — вполне понятно. В английском бывает https://dictionary.apa.org/subjective-expected-value, но запросто будет и https://en.wikipedia.org/wiki/Subjective_expected_utility. В принципе, нюансы использования value — «общее ощущение», а utility — «структурированная оценка в моделях и теориях».
Smart mutation — не случайные, а алгоритмически наиболее вероятно ведущих к лучшему, из https://arxiv.org/abs/1709.00268 или https://arxiv.org/abs/2206.08896
https://ailev.livejournal.com/1106188.html, это текст ещё 2014 года. События 2022 года показали, что в этом мире «непрерывной разработки» отключить миллионы людей от пользования самыми разными системами стало не просто легко, а очень легко.
https://arxiv.org/abs/2410.02543, но ещё в 2021 году была предложена работа https://www.pnas.org/doi/full/10.1073/pnas.2120042119, в которой давалась таблица соответствия понятий термодинамики, биологической эволюции и машинного обучения. Число подобных работ растёт.
https://en.wikipedia.org/wiki/Geometrical_frustration, обязательно смотрите там фильм про неустаканенность магнетизма в твёрдых телах
https://en.wikipedia.org/wiki/Geometrical_frustration, там обязательно смотрите видео Frustrated magnetism in solids, ибо нужно понимать динамику происходящего, она лучше даётся в видео.
первый абзац в https://ailev.livejournal.com/1621262.html
Математика по физике агентов в сочетании с active inference можно найти в https://chrisfieldsresearch.com/, а работы по active inference — в https://www.activeinference.org/
https://youtu.be/XvVa-mByxMs?t=1240, больше информации в «Minimal physicalism as a scale-free substrate for cognition and consciousness», 2021, https://chrisfieldsresearch.com/min-phys-NC-2021.pdf
https://ailev.livejournal.com/1416697.html
https://en.wikipedia.org/wiki/Fitness_landscape#/media/File:Visualization_of_a_population_evolving_in_a_dynamic_fitness_landscape.gif, со страницы https://en.wikipedia.org/wiki/Fitness_landscape
Картинка в высоком разрешении— https://ic.pics.livejournal.com/ailev/696279/212554/212554_original.png
Картинка в высоком разрешении: https://ic.pics.livejournal.com/ailev/696279/285342/285342_original.png
If there is an issue between SE and EoS, it may be semantic, rather than grammatical. Classically, the first word moderates the second: so, in SE, 'systems' appears to moderate (describe the type or flavour of) engineering; and in EoS, 'engineering' appears to moderate (describe the type and flavour of) systems. — из prof. Dereck Hitchins, «SYSTEMS ENGINEERING VS. ENGINEERING OF SYSTEMS - SEMANTICS?», https://systems.hitchins.net/profs-blog/systems-engineering-vs.html
"It's relatively easy to make a prototype but extremely difficult to mass manufacture a vehicle reliably at scale. Even for rocket science, it's probably a factor of 10 harder to design a manufacturing system for a rocket than to design the rocket. For cars it's maybe 100 times harder to design the manufacturing system than the car itself. The issue is not about coming up with a car design — it's absolutely about the production system," Musk said. "You want to have a good product to build, but that's basically the easy part. The factory is the hard part." — https://www.businessinsider.com/elon-musk-says-building-factory-100-times-harder-than-making-car-2019-3
Картинка в высоком разрешении — https://ic.pics.livejournal.com/ailev/696279/276990/276990_original.png
По мотивам https://www.researchgate.net/publication/200026050_Collaborative_Networks_Reference_Modeling
Обычно deep, «глубина» в речи означает рост числа уровней какой-то иерархии. Скажем deep learning — это многоуровневое обучение, то есть обучение нейронных сетей с числом скрытых уровней/слоёв больше одного. В углублении разделения труда речь идёт об увеличении числа уровней иерархии по отношению специализации (род-вид) между методами.
См. доклад Влада Свяжина рассуждениями об этой идее, с 1:04:11, https://www.youtube.com/watch?v=lpgpnCoV14w&t=3851s
Подходы к определению импровизации см. в https://ailev.livejournal.com/1730660.html
О плохих объяснениях рассказывается в курсе «Создание объяснений», см. также книгу Дэвида Дойча «Начало бесконечности. Объяснения, которые меняют мир».
Turton, Richard, et al. (2003) Analysis, Synthesis, and Design of Chemical Processes, Upper Saddle River, NJ: Prentice Hall.
Термин появился ещё в 2011 году https://go.forrester.com/blogs/11-02-07-i_dont_want_devops_i_want_noops/, но дебаты идут до сих пор, ибо путается создание платформы (где нужны пока люди) и её работа без людей.
https://www.anandtech.com/show/21408/tsmc-roadmap-at-a-glance-n3x-n2p-a16-2025-2026, к этим «проектным нормам» нужно относиться с осторожностью, https://www.iguides.ru/main/other/sovremennye_tekhprotsessy_grandioznyy_obman_razbiraemsya_v_marketingovykh_tonkostyakh_protsessorov/
https://en.wikipedia.org/wiki/Cognitive_behavioral_therapy на базе behavior and cognitive psychology, https://www.apa.org/ed/graduate/specialize/behavioral-cognitive
См. про архитектурную оптимизацию в https://ailev.livejournal.com/1464563.html
https://www.diapazon-pharm.ru/kisecnorastvorimye-kapsuly-preimusestva-i-spros, https://patents.google.com/patent/RU2569742C1/ru
https://www.researchgate.net/publication/343999144_How_Formal_Requirements_Specifications_Inhibit_Creativity_in_Software_Engineering, и то же самое про шаблонизированные требования https://www.researchgate.net/publication/354528878_How_Templated_Requirements_Specifications_Inhibit_Creativity_in_Software_Engineering. Эта тема «иллюзии требований» разрабатывается с 2013 года, https://www.researchgate.net/publication/255831240_The_Illusion_of_Requirements_in_Software_Development
https://ru.wikipedia.org/wiki/Клеточный_автомат, https://ru.wikipedia.org/wiki/Автоматное_программирование
)пример Netflix — https://jivimberg.io/blog/2023/09/04/the-inverse-conway-maneuver/, ещё один пример — https://www.thoughtworks.com/insights/blog/customer-experience/inverse-conway-maneuver-product-development-teams
Пример architecture characteristics worksheet — https://www.developertoarchitect.com/downloads/architecture-characteristics-worksheet.pdf, в классической инженерии их продолжают называть system quality attribute — https://en.wikipedia.org/wiki/List_of_system_quality_attributes
https://www.aia.org/sites/default/files/2024-11/AIA_Design_Deconstruction_Adaptability_Reuse.pdf
https://www.cerebras.net/blog/cerebras-wafer-scale-engine-inducted-into-the-computer-history-museum/
https://www.artlebedev.ru/izdal/yazyk-shablonov/ — по-русски pattern language переведён как «язык шаблонов».
В сборнике Transactions on Pattern Languages of Programming IV, 2019
https://en.wikipedia.org/wiki/Current_reality_tree_(theory_of_constraints), https://www.6sigma.us/six-sigma-in-focus/current-reality-tree/
https://www.amazon.com/How-Measure-Anything-Intangibles-Business/dp/1118539273, 3rd edition, 2014
Есть русский перевод, https://www.litres.ru/dzhez-hambl/uskoryaysya-nauka-devops/, но мы рекомендуем всё-таки читать оригинал
https://www.anthropic.com/news/paris-ai-summit, февраль 2025
Но некоторые архитекторы ещё в 2019 году выражали сожаление по поводу неиспользования термина и ухода от явного обсуждения ситуации, «ИТ-архитекторы же продолжают сидеть в своих башнях из слоновой кости, подобно Винни-Пухам, застрявшим после сытного перекуса в домике Кролика. Даже тег DevArchOps остаётся неизвестен гуглу и воспринимаемся им как бессмысленный набор символов», https://mxsmirnov.com/2019/06/06/architecture-as-a-code/#more-2892.
https://www.litres.ru/atul-gavande/chek-list-kak-izbezhat-glupyh-oshibok-veduschih-k-fatalnym-po/
Тут, конечно, не нужно путать с 6D для экспоненциальных технологий от Peter Diamandis и Steven Kotler (exponential organizations должны быть digitised, deceptive, disruptive, dematerialized, demonetized, democratized, это Singularity University в 2016, когда модно было искать везде экспоненты и единорогов) — https://www.diamandis.com/blog/the-6ds
https://en.wikipedia.org/wiki/Concurrent_engineering, не путайте с collaborative engineering, http://ailev.livejournal.com/943532.html
Подробней смотри серию публикаций https://ailev.livejournal.com/1549559.html, https://ailev.livejournal.com/1548016.html, https://ailev.livejournal.com/1550931.html
https://www.arxiv.org/abs/2502.19414, https://arxiv.org/abs/2502.06556, https://arxiv.org/abs/2502.09858
https://en.wikipedia.org/wiki/Cognitive_bias, https://utminers.utep.edu/omwilliamson/engl1311/fallacies.htm
Вот пример 2015 года, http://new.gva.vc/ru/about/news/512/?PAGEN_2=4
Для софта, например, https://www.guru99.com/code-review-tools.html, для информационных моделей
Дэвид Дойч, «Начало бесконечности. Объяснения, которые меняют мир»