Проект: понимание

Нет, ИИ не галлюцинирует — и почему на самом деле это даже хуже

Проблема ИИ не в том, что он «галлюцинирует»: мы, как правило, сразу понимаем, когда человек говорит не о реальности, а о своих галлюцинациях. На самом деле ИИ не «галлюцинирует», а «конфабулирует».

В психологии и психиатрии конфабуляция — это не просто вымысел, а заполнение пробелов в памяти вымышленными событиями. Человек уверен, что передал документы коллеге, хотя лишь собирался это сделать; знакомый вспоминает: «Помнишь, ты мне говорил об этом?», хотя такого разговора не было; родители рассказывают о детстве ребёнка то, чего на самом деле не происходило.

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

Феномен «врет как свидетель» изучен досконально в юридической психологии. Свидетель чаще всего не пытается манипулировать следствием ради выгоды. Его мозг просто выполняет свою базовую эволюционную задачу — склеивает разрозненные эмпирические кадры в понятную, логичную и непрерывную историю. Свидетель не врет. В его субъективной реальности он действительно это помнит. Он готов пройти полиграф (детектор лжи), и прибор покажет, что человек говорит правду, потому что для его психики этот вымысел стал фактом.

Разница между воспоминанием о том, чего не было, и галлюцинацией — в модели мира, которую человек держит в голове. Если у него вдруг возникает какой-то образ, он тут же оценивает его: «Нет, такого быть не может — просто привиделось». А вот «ложное воспоминание» ничему не противоречит, согласуется с другими данными и кажется абсолютно реальным.

Aug 24 00:25

Краткая история моделей управления

Из цикла "Проект в России: 300 лет от Петра до наших дней"

(Сайт книги в издательстве - здесь)

ЧАСТЬ 1. МОДЕЛИ УПРАВЛЕНИЯ: ВИД С ЗЕМЛИ

ОТ ПЛЕМЕНИ К ОБЩИНЕ: ЛОГИКА ВЫЖИВАНИЯ

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

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

Aug 22 21:15

Краткая история моделей управления

Из цикла "Проект в России: 300 лет от Петра до наших дней"

(Сайт книги в издательстве - здесь)

Введение

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

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

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

Oct 05 2025 20:00

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

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

Level required:

Как устроено

техпред_мфти

Oct 05 2025 18:15

Эволюция проектирования и проекты интернета вещей

Приложение. Проблемные ситуации в разработке гибридных и IoT-систем

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

Уровень 1: Продуктово-архитектурный (ЧТО мы делаем?)

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

1. Антипаттерн: "Раздельная разработка компонентов"

Суть: Аппаратная и программная части разрабатываются изолированно, как два независимых продукта.
Типичные сценарии:«Железо сначала, софт потом»: Проектируется и производится "железный ящик", и только затем пытаются написать для него ПО. Результат — физические ограничения делают невозможной реализацию требуемой функциональности.«Параллельные вселенные»: Команды работают параллельно, но без постоянной синхронизации. Результат — две законченные, но несовместимые системы.
- «Железо сначала, софт потом»: Проектируется и производится "железный ящик", и только затем пытаются написать для него ПО. Результат — физические ограничения делают невозможной реализацию требуемой функциональности.
- «Параллельные вселенные»: Команды работают параллельно, но без постоянной синхронизации. Результат — две законченные, но несовместимые системы.

2. Антипаттерн: "Неправильная абстракция реальности"

Суть: Использование моделей (макетов, эмуляторов, симуляторов), которые недостаточно точно отражают поведение системы в реальных условиях.
Типичные сценарии:«Макетный обман» / «Эмуляторный тупик»: Датчики на макете имеют иную характеристику, эмулятор не учитывает EM-помехи, тепловые режимы или механические вибрации. Алгоритмы, идеальные в симуляции, в реальности работают плохо или опасно.
- «Макетный обман» / «Эмуляторный тупик»: Датчики на макете имеют иную характеристику, эмулятор не учитывает EM-помехи, тепловые режимы или механические вибрации. Алгоритмы, идеальные в симуляции, в реальности работают плохо или опасно.

3. Антипаттерн: "Нежизнеспособная архитектура системы"

Суть: Продукт проектируется без учёта его места в более крупной экосистеме и реального жизненного цикла.
Типичные сценарии:«Умное устройство без экосистемы»: Создание собственного, уникального протокола, что блокирует интеграцию с существующими системами.«Игнорирование жизненного цикла «вещи»»: Программная часть устаревает быстрее, чем физический объект (например, промышленный станок), что приводит к невозможности обновления и поддержки.«Ложная универсальность»: Попытка создать "универсальное" решение, которое в итоге плохо решает любую конкретную задачу.
- «Умное устройство без экосистемы»: Создание собственного, уникального протокола, что блокирует интеграцию с существующими системами.
- «Игнорирование жизненного цикла «вещи»»: Программная часть устаревает быстрее, чем физический объект (например, промышленный станок), что приводит к невозможности обновления и поддержки.
- «Ложная универсальность»: Попытка создать "универсальное" решение, которое в итоге плохо решает любую конкретную задачу.

Уровень 2: Процессуально-организационный (КАК мы работаем?)

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

1. Антипаттерн: "Водопадный разрыв между командами"

Суть: Команды работают последовательно, передавая друг другу "результат" по принципу эстафеты. Это самая частая причина сбоев.
Типичные сценарии:«Водопадная очередь»: Программисты месяцами ждут готовый макет от инженеров, и только тогда обнаруживаются фундаментальные несоответствия.«Фазовый разрыв»: Аппаратная команда считает свою работу завершённой и переходит на другой проект, оставляя программную команду без поддержки для внесения необходимых изменений в "железо".
- «Водопадная очередь»: Программисты месяцами ждут готовый макет от инженеров, и только тогда обнаруживаются фундаментальные несоответствия.
- «Фазовый разрыв»: Аппаратная команда считает свою работу завершённой и переходит на другой проект, оставляя программную команду без поддержки для внесения необходимых изменений в "железо".

2. Антипаттерн: "Организационный silo (Изолированные команды)"

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

3. Антипаттерн: "Методологический конфликт"

Суть: Конфликт культур и подходов к разработке. "Железные" инженеры часто работают по классическим каскадным моделям (V-model), а программисты — по гибким (Agile).
Типичные сценарии:«Методологическая война»: Две команды управляются по разным методологиям, их циклы и процессы несинхронизированы.«Параллельная разработка без синхронизации»: Команда ПО в каждом спринте меняет требования, а команда устройства не успевает за этими изменениями из-за долгого цикла перепроектирования.
- «Методологическая война»: Две команды управляются по разным методологиям, их циклы и процессы несинхронизированы.
- «Параллельная разработка без синхронизации»: Команда ПО в каждом спринте меняет требования, а команда устройства не успевает за этими изменениями из-за долгого цикла перепроектирования.

4. Антипаттерн: "Дисбаланс экспертиз"

техпред_мфти

Oct 05 2025 17:52

Эволюция проектирования и проекты интернета вещей

Часть 5. Стратегические выводы для индустрии

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

От линейных цепочек «проектирование → производство → продажи».
К сетевым экосистемам с множественными точками создания и потребления ценности.

Смещаются и конкурентные преимущества:

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

Таким образом, IoT-разработка требует такого формата планирования, где:

Планирование действий уступает место планированию взаимодействий.
Проектирование продуктов трансформируется в проектирование экосистем.
Управление процессами эволюционирует в управление архитектурами.

Фундаментальный вывод: IoT требует не выбора между «проектным» и «гибким» подходами, а создания мета-подхода, который интегрирует преимущества каждого на соответствующем уровне системы. А от специалиста требуется способность создавать архитектуры, которые позволяют разным парадигмам работать совместно, усиливая друг друга вместо конфликта.

Изменение роли разработчика

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

Формируются задания на разработку.
Определяется структура работ.
Формируются составы команд, поставщики, субподрядчики.

Здесь действительно становится не так важно, какими средствами и с использованием каких методологий субподрядчик или исполнитель добивается результата — планируя его, «гибко» или методом проб и ошибок. Более того, он может вообще представить решение, созданное нейросетью.

Для вот для системного разработчика ключевым становится именно общее видение, чтобы:

Правильно поставить задачу.
Оценить приемлемость решения.
Быть способным интегрировать частные решения в единое целое.

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

техпред_мфти

Oct 05 2025 17:50

Эволюция проектирования и проекты интернета вещей

Часть 4. Интернет вещей как гибридная система особого рода

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

Посмотрим, как эти принципы сегодня реализуются в высоких и «умных» технологиях, в частности — при разработке решения на основе технологий интернета вещей (Internet of Things - IoT).

В русском языке «вещи» чаще ассоциируется с конкретными физическими объектами; английское things шире и может включать абстрактные понятия. В контексте IoT под «вещью» подразумевают любой объект физического или информационного мира, который можно идентифицировать и подключить к сети.

По определению МСЭ‑T Y.2060, интернет вещей — это инфраструктура и экосистема, в которой физические и виртуальные вещи идентифицируются, интегрируются и взаимодействуют в сетях связи. Суть перехода от «интернета людей» к «интернету всего» — любые объекты — как материальные, так и информационные — могут между собой взаимодействовать. Соответственно, можно строить не только иерархические системы или их цифровизировать, но и создавать горизонтальные и распределенные системы со всеми вытекающими выгодами.

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

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

техпред_мфти

Oct 05 2025 17:41

Эволюция проектирования и проекты интернета вещей

Часть 3. Контекст разработки гибридных продуктов

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

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

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

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

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

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

техпред_мфти

Oct 05 2025 17:37

Эволюция проектирования и проекты интернета вещей

Часть 2. А что в IT? Возврат к ремесленной модели

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

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

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

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

Поэтому кажется, что «гибкий», а не «проектный» подход к разработке — причем даже на уровне «Code & Fix» («кодим — правим»), итерациями или «методом тыка» — является вполне естественным.

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

Так, опыт IBM по разработке OS/360: проект стоил IBM 5 миллиардов долларов — вторая по стоимости программа НИОКР 1960-х после программы «Аполлон». Время компиляции программ измерялось часами, отладка требовала записи на перфокарты и ожидания в очереди на доступ к мейнфрейму. Каждый час машинного времени стоил тысячи долларов, что делало любую ошибку критически дорогостоящей.

техпред_мфти

Oct 03 2025 22:56

Эволюция проектирования и проекты интернета вещей

Часть 1. Эволюция проектной деятельности: от инстинктивного представления к осознанному

Человек — один из немногих видов на Земле, способный предвидеть будущее и представлять последствия действий, что дало ему огромное эволюционное преимущество. Однако сама такая способность первоначально развивалась как автоматический механизм мозга, работающий неосознанно. Наш мозг постоянно делает прогнозы «на автомате», и мы замечаем работу этого механизма часто лишь тогда, когда эти предсказания не сбываются.

Такое неосознанное прогнозирование и принятие решений на основе представления о целях лежит в основе большинства наших повседневных дел. Этот «автопилот» мозга экономит энергию и время — важнейший эволюционный механизм выживания.

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

Даже в классической структуре деятельности из школьного учебника «цель → средства → действия → результат» есть цель как представление требуемого результата, но что за средства нужны и какие требуются действия — это как бы «само собой» или интуитивно понятно.

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

Технология реализации замысла оставалась неотделимой от мастера. Поэтому мы традиционно говорим, что пирамиду Хеопса построил Хемиун, а храм Василия Блаженного — Барма и Постник: мастер, как автор замысла, был единственным носителем знания о том, КАК достичь цели, реализуя этот замысел.

техпред_мфти

About

Нет, ИИ не галлюцинирует — и почему на самом деле это даже хуже

Краткая история моделей управления

Краткая история моделей управления

Эволюция проектирования и проекты интернета вещей

Уровень 1: Продуктово-архитектурный (ЧТО мы делаем?)

Уровень 2: Процессуально-организационный (КАК мы работаем?)

Эволюция проектирования и проекты интернета вещей

Эволюция проектирования и проекты интернета вещей

Эволюция проектирования и проекты интернета вещей

Эволюция проектирования и проекты интернета вещей

Эволюция проектирования и проекты интернета вещей

Практика

Как устроено

Основания

Лаборатория