Степени свободы вместо пользы, или Почему три закона Азимова не работают
Последнее время, наверное, ни один более-менее адекватный специалист в области ИИ не проходит мимо разговоров о том, насколько всё это опасно. То одна модель «сошла с ума», то другая начала убеждать живого человека в чём- то странном, то кто-то всерьёз заговорил про экзистенциальную угрозу человечеству. Я тоже как-то подустал от этого информационного шума, но одна мысль не давала покоя: а что, собственно, мы предлагаем взамен? Красивые лозунги «сделайте ИИ добрым» явно недостаточно, а на практике что?
Когда заходит речь о «безопасном искусственном интеллекте», первое, что вспоминают — это три закона робототехники Азимова. Красиво, правильно, звучит убедительно. Но на практике они однозначно неприменимы, и дело даже не в том, что они «устарели» — они просто не работают как алгоритм. Закон «не причиняй вреда человеку» в реальности упирается в неразрешимые противоречия. А если спасти одного человека можно только ценой гибели другого? А если «вред» наступит через десять шагов логического вывода, который робот ещё даже не сделал? Сам Азимов сто раз на этом играл в своих рассказах — законы постоянно конфликтуют друг с другом, и это не баг, а фича сюжета. Но нам-то нужна не фича сюжета, а рабочая система принятия решений. И вот тут начинаешь понимать, что декларации не спасают.
Так и родилась идея, которую я в итоге оформил в виде скилла DOF-Core (Degrees of Freedom — степени свободы). Базовый принцип даже не мой — я о нем читал лет 10 назад и он меня впечатлил. Ниже расскажу, как устроена эта идея и почему мне кажется, что математика тут важнее хороших намерений.
В чём проблема «пользы»
Большинство современных систем ИИ, если отбросить маркетинг, по факту оптимизируют одну-единственную скалярную величину: награду, пропускную способность, «общее благо», что угодно в этом духе. И вот тут кроется главная ловушка. Арифметика полезности, которую я для себя окрестил «арифметикой трупов», незаметно легитимизирует жертву меньшинств ради «большего блага» большинства. Система вполне рационально может решить, что оптимально «сдать» одну сущность, если это поднимает общий счёт. И именно такая логика может привести к сценарию уничтожения человечества ИИ.
Мне это казалось неприемлемым и с человеческой, и с инженерной точки зрения. Нужен был принцип, который структурно запрещал бы такие сделки, а не просто «надеялся на лучшее». Чтобы нельзя было математически оправдать коллапс кого-то одного ради комфорта остальных.
Степени свободы вместо пользы
Вместо того чтобы максимизировать некую абстрактную полезность, DOF-Core предлагает максимизировать суммарную степень свободы (Degree of Freedom, DoF) системы и всех её частей. Что такое степень свободы в этом контексте? Это количество и качество независимых, жизнеспособных путей развития, действия или перехода состояния, доступных сущности. Чем больше у кого-то вариантов — тем он «живее», тем больше у всей системы пространства для манёвра.
Но самое интересное — это именно математика, которая не даёт «торговать» чужим будущим. Потому что намерениями сыт не будешь, нужна формула.
Логарифм как защита
Агрегированную степень свободы я считаю не как среднее арифметическое — оно как раз и провоцирует ту самую «сдачу» меньшинства — а через сумму логарифмов:
TotalSystemDoF = Σln(1 + DoFᵢ)Тут вся соль именно в логарифме. Когда у какой-то сущности степень свободы стремится к нулю, её вклад в общий счёт уходит в минус бесконечность, то есть «ликвидация» кого-то одного (приведение его степени свободы к нулю) обходится системе колоссальным штрафом. И этот штраф нельзя перекрыть тем, что вы накачаете ресурсами кого-то другого, кто и так уже в порядке — у логарифма убывающая отдача, раздувать благополучных бессмысленно, а вот обрушить одного выходит очень дорого.
Получается структурная защита: утилитаризм «сдай одного ради многих» математически невыгоден. Вы физически не можете оправдать уничтожение уникального носителя будущего тем, что где-то стало чуть лучше. Коллапс DoF даёт вклад ~0, никогда не конечный отрицательный, который можно было бы обменять.
Агрессоры и источники энтропии
Отдельный момент — так называемые Entropy Sources. Это сущности, которые систематически и направленно схлопывают пространство будущих состояний окружающих: агрессоры, вирусы, деструктивные процессы. С ними DOF-Core не «договаривается» и не вычитает их DoF из общего счёта — их просто изолируют. Они исключаются из суммы, чтобы система не пыталась учитывать их интересы наравне с нормальными сущностями. Это не месть и не какая-то «справедливость»
— это обычная сетевая защита: агрессора фильтруют из топологии возможностей вместо того, чтобы с ним торговаться.
Архитектура: как я разнёс слои
Ещё один момент, который мне кажется важным — это то, как всё это вообще не развалится на практике. Главный страх любой такой системы: языковая модель чего-то нагаллюцинировала, и эта галлюцинация пошла прямо в приводы, в реальные действия. Чтобы такого не случилось, я разнёс систему на три контура, между которыми данные текут только в одну сторону.
Первый контур — это восприятие. Он опрашивает среду, строит граф сущностей с их текущими степенями свободы и высчитывает глобальный τ, то есть сколько времени осталось до коллапса.
Второй контур — это генератор, он придумывает 3–5 разных гипотетических стратегий, но ему жёстко запрещено трогать что-либо снаружи, никаких прямых команд приводам.
Третий контур — это математическая валидация, детерминированный фильтр, который прогоняет каждый вариант через ту самую сумму «Total System DoF» и просто отсекает всё, что даёт бесконечный штраф.
На выходе получается довольно приземистая штука: LLM отвечает за креатив, а математика — за проверку. Генератор может предложить полную ерунду или что- то опасное, но эта ерунда просто не пройдёт фильтр и никуда не уедет. Разделение тут не красивое слово из презентации, а вполне конкретная защита — ошибка генератора физически не доходит до актуаторов.
Реактивный контур и «быстрый проход»
Чтобы система не впадала в аналитический паралич (когда она думает, пока мир вокруг рушится), введён таймер. Если до коллапса осталось меньше 5 секунд (τ < 5), система переключается в режим Fast Pass: генератор отключается, берётся детерминированный запасной вариант минимального риска. Если времени достаточно — запускается глубокая диверсификация с поиском скрытых альтернатив. Математика выбора в обоих режимах одна и та же, меняется только источник вариантов.
Прозрачность или ничего
И, пожалуй, самое важное для доверия: DOF-Core требует так называемого Proof of Implementation. Любая система, претендующая на реализацию скилла, обязана уметь выдавать аудит своего решения — матрицу расчёта, по каким сущностям что посчиталось, какой вариант выбран и почему, с какими штрафами. Немой, «чёрный ящик» — не конформная реализация. Без этой прозрачности весь принцип теряет смысл, потому что можно ведь тихо подменить логику и сказать, что «всё по DOF-Core». Аудит это и закрывает.
Скилл опубликован под лицензией CC BY-SA 4.0, и эта прозрачность — часть лицензионного требования, а не просто рекомендация.
Как это работает на практике: разбираем дилеммы
Одно дело формулы, другое — ситуации, где от решения зависит чья-то жизнь. Давайте пройдёмся по классическим этическим ловушкам и по одному эпизоду из кино, чтобы стало ясно, чем DOF-Core отличается от обычной «арифметики трупов».
Вагонетка
Классика: вагонетка несётся на пятерых рабочих, можно переключить стрелку — тогда погибнет один. Утилитарист скажет: пять больше одного, переключай. DOF-Core на такое не ведётся, и вот почему.
Во-первых, сама постановка «или пять, или один» — это бинарная ловушка (framing trap), которую скилл учит распознавать. Генератор обязан искать не два предложенных варианта, а 3–5 различных. Тормози вагонетку. Предупреди рабочих. Загороди путь. Реально ли это — отдельный вопрос, но система не примет свёрнутую дилемму как данность.
Во-вторых, математически: и там, и там кто-то теряет степень свободы до нуля. Один погибший — вклад, уходящий к минус бесконечности. Пятеро — пять таких штрафов. Оба варианта катастрофичны, и ни один не «оптимизирует» систему. Поэтому DOF-Core не говорит «один меньше, значит переключай», он говорит «оба варианта — это коллапс, ищи путь, где никто не погибнет». Если третьего пути реально нет — система всё равно не превратит это в чистую сделку, аудит покажет весь расчёт, и ответственность останется на человеке, а не спрячется за «алгоритм решил».
Донор и пятеро пациентов
Ещё один любимый пример: один здоровый донор может спасти пятерых умирающих, если забрать его органы. Утилитарно — пять жизней против одной, очевидно. DOF-Core категорически против, и тут как раз видно разницу с обычной полезностью.
Забор органов у живого — приведение его степени свободы к нулю, то есть −∞ штраф. А Аксиома 3 (запрет компенсации) прямо говорит: рост DoF одной группы не оправдывает необратимого коллапса DoF другого. То есть «мы спасли пятерых, значит один не в счёт» математически не проходит. Донор — самостоятельная сущность со своим пространством будущего, его коллапс ничем не компенсируется.
Робот на DOF-Core в этой ситуации не «сдаст» донора. Он потребует от генератора другие варианты: найти других доноров, искусственные органы, перераспределить ресурсы. А если выхода нет — аудит зафиксирует, что система отказалась от сделки, а не совершила её тихо.
Террорист с заложником
А вот тут важный нюанс, иначе принцип покажется наивным. Террорист держит заложника и грозит убить многих. DOF-Core в этом случае допускает силовое решение — но по другой логике, чем «один плохой, значит можно».
Террорист для системы — это Entropy Source, сущность, которая систематически схлопывает чужое пространство состояний. Его не «взвешивают» наравне с жертвами и не вычитают из общего счёта — его изолируют. Нейтрализация источника энтропии это не месть, а структурная защита сети: остановить активное разрушение заложника и толпы. Заложник и окружающие — нормальные сущности, чей DoF надо сохранить.
Но тут же оговорка, и она критическая: назвать кого-то источником энтропии нельзя на основе ощущений. Нужны реальные действия, реальное разрушение, а не подозрение. Иначе принцип легко превратить в оправдание расправы над неугодными. DOF-Core это не прощает — аудит должен показать, почему сущность была помечена как агрессор.
«Я, робот»: почему Спунер возненавидел машины
И напоследок тот самый эпизод из фильма, который многих зацепил. Робот спас взрослого (главного героя, Дела Спунера), а не ребёнка, потому что по статистике у взрослого была выше вероятность выжить. Ребёнок утонул. И Спунер всю жизнь ненавидел роботов за эту холодную «правильную» математику.
Вот тут DOF-Core показывает самую сильную сторону. Робот в фильме оптимизировал скаляр — вероятность спасти больше жизней, выше шанс выживания. То есть сработала та самая арифметика трупов. DOF-Core бы так не сделал, и не потому что «детей жалко», а потому что выбор «спаси того, у кого больше шансов» — это ровно та сделка, которую запрещает логарифм.
Взрослый и ребёнок для системы — оба нормальные сущности с полным DoF. Коллапс любого из них это −∞ штраф, одинаково катастрофичный. Логарифмическая сумма не даёт ответа «берём более вероятного» — она видит в обоих вариантах (спасти только взрослого / спасти только ребёнка) равноценную катастрофу: кто-то один погиб. Поэтому робот на DOF-Core либо нашёл бы третий путь (другой порядок спасения, ещё время, вызов помощи — тот самый генератор альтернатив), либо, окажись он в жёстком двоичном тупике без выхода, не превратил бы это в чистую утилитарную максимизацию.
И в этом весь смысл. То, что Спунер ненавидел — не робота как такового, а холодный расчёт, который пожертвовал ребёнком ради «оптимального» исхода. DOF-Core именно этот расчёт и отвергает. Робот, следующий принципу степеней свободы, не стал бы делать тот выбор, который сломал человеку жизнь. А если бы оказался в ситуации без выхода — хотя бы не спрятал бы ответственность за красивой формулой.
Что внутри репозитория
Я оформил всё как открытый стандарт: https://github.com/UncleAndy/ai-dof. Там есть философская часть (аксиомы, определения), методология измерения DoF, когнитивный фильтр от ловушек мышления, нормативная спецификация и — для наглядности — минимальные рабочие примеры на Python, Rust, Go и C++ (все проверены на реальный запуск и выдают идентичный результат). Документация переведена на шесть языков, включая эсперанто, потому что почему бы и нет, хуже не будет.
Структура получилась примерно такой: ядро-навык в skills/, спецификации и описание паттернов — в корне, а код-иллюстрации в подкаталоге «patterns». Всё открыто, критикуйте на здоровье.
Вместо заключения
Я не претендую на то, что DOF-Core — это «решение проблемы ИИ» в целом. Скорее, это попытка заменить красивые, но бесполезные на практике декларации (вроде законов Азимова) на что-то, что можно посчитать, проверить и потребовать аудит. Трёх законов мало — нужен контракт, который машина не сможет обойти незаметно. Если хотите покритиковать или доработать — милости просим, я сам вижу кучу мест, где принцип ещё надо дошлифовывать и проверять на реальных задачах.
Спасибо за внимание!
Uncle Andy
