dxdt.ru: занимательный интернет-журнал

Некоторое время назад я написал на “Хабр” о попытке использовать ChatGPT для генерирования кода OpenSCAD: задача была – сгенерировать код, описывающий простейший Y-образный разветвитель шлангов; для этого я составил подробнейший “промпт” на естественном языке (есть в статье).

Конечно, выдача ChatGPT оказалась абсолютно бесполезной – в статье есть скриншоты рендеринга того, что сгенерировала LLM. В комментариях спросили, почему я выбрал “чат-бот”, вместо “специализированной модели”. Скопирую сюда свой подробный ответ, чтобы он не потерялся:

Есть целый ряд причин.

Во-первых, эта штука не написала в ответ, что, мол, “вижу, тут требуется 3D-объект, но я всего лишь чат-бот – обратитесь к специализированной системе”. Напротив – оно прямо и уверенно пишет, что точно умеет в OpenSCAD, знает все детали, приводит примеры (я спрашивал), а также предлагает проверить, что всё в коде корректно и верно при помощи рендеринга в OpenSCAD (да, такой вот “напор” демонстрирует). Опять же – что такое “чат-бот”? Если это средство занять назойливых клиентов в чате технической поддержки пустопорожним переливанием запроса в ответ – ну, да, тогда с OpenSCAD лучше не подходить. Но позиционируется-то этот инструмент явно иначе.

Во-вторых, не то чтобы была у меня какая-то уверенность, но я предположил, что в эту систему, – возможно! – уже успели-таки встроить “специализированное решение для 3D”. Это разумное предположение: такая возможность, без сомнения, полезна, системы постоянно обновляют, ждут в этом году “универсальный ИИ”, то и дело утверждается, что оно успешно решает задачи по геометрии на уровне “продвинутого старшеклассника”. Вот и проверили. Если бы оно справилось, это бы не сделало его интеллектом, но результат бы порадовал.

В-третьих, программное, процедурное задание простейших 3D-объектов – вообще-то не сложнее, скажем, реализации алгоритмов быстрой сортировки больших массивов, алгоритмов обработки графов, алгоритмов балансировки параллельной работы с данными и т.д., и т.п. В компьютерной геометрии есть свои сложности, но они точно не в генерировании описания трёх цлиндрических трубочек и параллелепипеда (предположим). Вся такая простая 3D-геометрия – выписывается в векторах, если хотите. С этой геометрией в видеоиграх справляются те же видеокарты, на которых запускают эти же LLM. Задача процедурного определения простейшего 3D-объекта, между прочим, не сложнее и поиска “уязвимостей в ПО”. И уж тем более теряется сложность на фоне разговоров о генерировании видео по текстовому описанию. Конечно, всё это верно только в том случае, если там настоящий интеллект, который именно решает задачу, а не синонимайзер, замещающий решение сгенерированным текстом (или иерархией кластеров пикселей – не важно). Собственно, поэтому-то тут и возможны специализированные решения.

В-четвёртых, постоянно вижу и слышу, как LLM типа “чат-бот” используют для генерации программного кода – для этого ведь даже есть плагины в средах разработки. Код OpenSCAD – это чисто программный код, я же не просил рисовать чертёж в изометрии. Всё подходит.

Наконец, в-пятых: в качестве специализированной системы – я бы всё же предпочёл использовать тот или иной готовый инструмент для параметрического задания типовых объектов в OpenSCAD (Y-образный адаптер к ним тоже относится). Такие инструменты есть. Они детерминированы. Они проще. Натыкать в интерфейсе размеры – быстро. Но они – не LLM, на которых обещают “универсальный интеллект”. Собственно, есть ведь и немало инструментов “визуального программирования”. Даже для специальных систем, типа GNU Radio, но почему-то сейчас про них вообще забыли, а рассказывают именно про генерирование кода LLM, на которые всех заменят.

Часто попадается популярная иллюстрация к протоколу Диффи-Хеллмана, использующая аналогию “смешивания красок”: то есть, стороны, пытающиеся получить общий секрет, смешивают исходную краску, которая известна всем, каждая со своей секретной краской, а потом обмениваются результатами по открытому каналу и смешивают со своим секретом уже результат второй стороны (см. ниже), получая, таким образом, одинаковый “цвет”. Например, в английской “Википедии” сейчас дана именно такая иллюстрация.

(Source: Wikimedia)

Оказывается, такая картинка – не самый плохой способ объяснить что-то содержательное про протокол DH “на пальцах”, пусть некоторые требования и остаются за кадром. Например, эта схема не позволяет показать, почему атакующая сторона не может “перебрать все краски” (естественно, в практическом случае с числами).

Посмотрим на основные моменты, которые подразумевает имеющаяся картинка. Во-первых, результат смешивания красок должно быть трудно обратить – важнейшее свойство для DH, который строится на “однонаправленных” функциях (об этом написано на исходной картинке). То есть, сторона, наблюдающая обмен, не может простым способом разделить краски. Вспомните, что исходная краска, – которая соответствует генератору в “настоящем” DH, – известна всем, в том числе, стороне, пытающейся взломать обмен. По условию – выделить эту краску из смешанных “цветов” оказывается вычислительно невозможно. Во-вторых, операция смешивания красок должна быть “коммутативной” (условно!) – то есть, результат не отличается от порядка подмешивания ингредиентов сторонами. Это не менее важный математический момент “настоящего” протокола, который позволяет обобщить его и перенести с классических вычетов на совсем другие структуры.

Вообще, “коммутативность” тут именно в кавычках, поскольку математическая структура несколько сложнее. Запишем операцию в виде формулы, где “*” соответствует смешиванию красок и действует слева: α * G – означает, что секретная краска α смешана с краской G (чтобы как-то обосновать “левое и правое” действие – считаем, что колер α добавлен в банку к краске G). Тогда: β * (α * G) == α * (β * G) – это то, что происходит в протоколе с красками. То есть, сторона A получает результат смешивания (β * G) и замешивает свою краску α: α * (β * G). Сторона B – наоборот. Казалось бы, должно выполняться (α * β) == (β * α), тогда работает схема. Именно так устроено в классическом DH, но с показателями степенй: (G^β)^α == (G^α)^β. Однако для протокола на красках, вообще говоря, (α * β) == (β * α) хоть и очевидно работает в “локальном” случае, но не применимо в иллюстрируемой схеме – ведь ни у стороны A, ни у стороны B нет готового состава (α * β) – они не могут его приготовить по условию “неразделимости” красок. Вариант (α * β) * G провернуть не получится, по условиям задачи: краски – это не натуральные числа. Поэтому-то “коммутативность” тут – это не настоящая коммутативность (без кавычек). Требуется именно “одинаковость” действия и краски α, и краски β на уже смешанные и подходящие краски. Это можно переписать в других обозначениях: A := α * G (подмешали α в G); B := β * G (подмешали β в G); α * B == β * A – потребовали выполнения базового свойства, необходимого для работы протокола DH на красках: β переводит A в тот же цвет, в который α переводит B.

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

Дело не только в химии: именно обобщение структурной особенности, которая переводит две разных “краски” строго в одну при действии разными элементами (другими “красками”) как раз и позволяет максимально обобщить и сам протокол DH, переписав его в терминах того, что в математике называется “действием группы”. Это, впрочем, отдельная история.

С “красочной” иллюстрацией к DH связан и ещё один занимательный момент. Хорошо, разобрать смешанный “цвет” на составляющие краски трудно – это по условию задачи. Но что мешает атакующему перебрать все доступные краски, подмешивая их к исходной? Результаты смешивания сравниваются с переданными в открытом виде “цветами” (они соответствуют открытым ключам DH) – если цвет совпал, то угадана секретная краска. Естественный вариант защиты: красок слишком много – перебор окажется неприемлемо долгим, а вот сторонам протокола легко выбрать одну секретную краску. Это, опять же, важный математический момент протокола: краски выбрать может быть легко, – вот тысячи, допустим, банок стоят на складских полках, – но реальный DH работает не на красках и там тоже требуется, чтобы был вычислительно простой метод равновероятного случайного выбора нужного числа (секретной “краски”). Да, в классическом варианте с целыми числами – выбрать число случайно и равновероятно не трудно. Вот только тут возникает другая проблема.

Классический вариант DH требует возведения в степень. Показатель степени является секретным ключом. Чтобы атакующая сторона не могла перебрать все показатели за обозримое время, значение должно быть большим. Но как быть стороне протокола, вычисляющей открытый параметр при помощи того же возведения в степень? Последовательно умножать генератор столько же раз, сколько и атакующий – выглядит несколько абсурдно. Хорошо, что знание показателя степени позволяет использовать быстрые методы, построенные на возведении генератора в квадрат и домножении на генератор в “нечётных” случаях: например, чтобы возвести 2 в пятую степень нужно дважды возвести 2 в квадрат и домножить на 2 – (2^2)^2 * 2, это три умножения, а не четыре, как для 2*2*2*2*2. В красках этого нет, но для любого практического воплощения протокола DH данное свойство “удвоения со сложением” необходимо – иначе легитимные стороны протокола оказываются в том же положении, что и атакующая сторона.

Относительно недавно появились общедоступные автоматические ИИ-генераторы “фотореалистичных” изображений, которые работают по текстовому описанию и готовы генерировать разнообразные сюрреалистичные сцены. Эффект от этих фильтров регулярно оценивается как что-то принципиально новое, в плане “фотореалистичности” невиданных сцен. Конечно, отрицать влияние и новизну нельзя, пусть качество выдачи и хромает. Но всё же посмотрите на открытку со скриншота ниже – это открытка 1909 года (больше ста лет назад), из коллекции Библиотеки Конгресса.

Похоже, сроки по “суперинтеллекту” несколько сдвигаются: в свежей колонке лидера OpenAI Альтмана предполагается лишь, что “в 2027 году возможно появление роботов, способных выполнять задачи из реального мира” (2027 may see the arrival of robots that can do tasks in the real world) – что бы это ни значило, так сказать. Какие-то роботы, конечно, уже есть, но подождём 2027 года – будет ли там вообще до обсуждений результатов?

Занятно, что подобные утверждения были популярны, например, в конце 60-х годов прошлого века – считалось, что вот-вот и – “роботы смогут выполнять привычные задачи”. Типа глажки и складывания полотенца, да. Суперинтеллект к 2030 уже не обещают. Но если вы посмотрите профильные футуристические статьи из конца 60-х, то прямо всё узнаётся, один в один; только там, обычно, писали про 2000-й год, а в колонке по ссылке – речь про 2035:

“Сегодня сложно даже представить, что мы откроем к 2035; возможно, мы пройдём от решения [проблем] физики высоких энергий в одном году до начала колонизации космоса в следующем; или от значительного прорыва в материаловедении в одном году до подлинно высокоскоростного интерфейса “мозг-компьютер” в следующем” (It’s hard to even imagine today what we will have discovered by 2035; maybe we will go from solving high-energy physics one year to beginning space colonization the next year; or from a major materials science breakthrough one year to true high-bandwidth brain-computer interfaces the next year.)

Начало колонизации космоса. Да. Но через десять лет. Возможно.

И написано, что сингулярность будет наступать медленно, но ничего нет про то, когда же включат “суперинтеллект”.

Недавно публиковал заметку о том, как перейти с ECDH на ML-KEM в проекте на Go: там на схемах показано, что DH можно уложить в схему KEM, что делает переход почти прозрачным. С этим связан интересный момент, касающийся свойств криптографической схемы, который в англоязычной традиции называется interactive и non-interactive (“интерактивная” и “не интерактивная”).

В ECDH (и в DH вообще) каждая из сторон может в любой момент вычислить общий секрет, если только знает открытый ключ другой стороны. То есть, это “не интерактивная” схема. Буквально: в DH, если сторона A знает открытый ключ стороны B, то A домножает этот открытый ключ на собственный секрет, который тут же выбирает независимо (но в соответствии со свои открытым ключом), и получает на своей стороне общий секрет. Никакого взаимодействия с B для этого не потребовалось. Поэтому, например, статичный открытый ключ DH может быть встроен в сертификат или ещё где-то опубликован, вне зависимости от того, в каком порядке вычисляется общий секрет сторонами. То же самое – для стороны B: этой стороне не требуется участие A для получения общего секрета (но нужен открытый ключ).

В ML-KEM ситуация другая. Прежде всего, здесь у сторон разные роли: одна сторона, – принимающая, A, – передаёт открытый ключ для инкапсуляции секрета, а другая сторона, – отправляющая, B, – инкапсулирует некий секрет в шифротекст строго при помощи этого открытого ключа. То есть, отправляющей стороне нужно получить открытый ключ принимающей стороны (как и в DH, да), потом вычислить общий секрет и шифротекст, отправить шифротекст принимающей стороне – и только тогда принимающая сторона сможет вычислить общий секрет. И сторона A никак не может вычислить общий секрет, пока B не пришлёт шифротекст (не открытый ключ – важно). Это уже существенное отличие от схемы DH: на принимающей стороне необходимо дождаться ответного сообщения от отправляющей стороны, – а это сообщение строго привязано к открытому ключу A, – и только потом можно вычислить общий секрет. Передача открытого ключа стороной B не предусмотрена. Шифротекст B тоже не может получить, пока нет открытого ключа A (в DH – может каждая сторона независимо сгенерировать открытый ключ). В ML-KEM получается, что на принимающей стороне требуется шаг, зависящий от действий отправляющей стороны. Это “интерактивная” схема.

Но главное отличие – DH можно переписать в KEM (не конкретно ML-KEM, а именно в схему), а вот произвольную схему KEM в DH – не выйдет.

Сколько лет Интернету – вопрос многогранный. Дмитрий Бурков пишет, что отсчитывать годы нужно с момента разработки BGP (и это довольно логично, так как BGP в современной Сети используется для обмена информацией о маршрутах доставки пакетов).

На фото ниже, из коллекции Библиотеки Конгресса, – установка краеугольного камня первого здания библиотеки Конгресса, а конкретно – здания Томаса Джефферсона.

Фото постановочное. Капитолий присутствует в качестве фона. Все работники в шляпах. Оно и понятно: это 1890 год, всё строго, а за нахождение на улице, – тем более – на стройплощадке, – без шляпы – могли если и не оштрафовать, то подвергнуть словесному порицанию. Ну, наверное. Не то что сейчас – если без каски.

Увеличенный фрагмент, на котором присутствует и метла, и мастерок:

Попалась статья в The Guardian. Называется “Researchers create AI-based tool that restores age-damaged artworks in hours” (“Исследователи разработали базирующийся на ИИ инструмент, который восстанавливает повреждённые временем художественные полотна за [считанные] часы”). ИИ-хайп продолжает вредить: если прочитать заголовок, то сразу возникает предположение, что это опять дорисовывание при помощи “картиночной LLM”. Однако, не совсем так. Дорисовывание, конечно, есть и в этом случае, но это не генерирование ИИ-картинок.

Исходная работа, по которой написана газетная новость, не содержит упоминания ИИ в заголовке и повествует о методе восстановления при помощи копирования фрагментов из сохранившихся областей картины, копирования совпадающих фрагментов из других полотен того же художника, обработки изображения при помощи типовых библиотек, с целью получения различных масок (разностные маски по пикселам и пр.), а также наложения фильтров из состава пакета Photoshop. Всё делается на основе оцифрованного изображения (скана), с автоматизированным “выравниванием” цветов. В тексте статьи при этом описано, почему прямые методы “нейросетей” на этом направлении не дают подходящих результатов. А основная особенность – метод переноса цифровых правок на физический исходник.

Полученные в автоматизированном режиме и сведённые в Photoshop визуальные дополнения и правки “пикселов” – печатаются на специальной прозрачной плёнке, послойно (см. ниже схему). Подготовленные плёнки особым, обратимым образом наклеиваются на оригинал, дополняя его до состояния отреставрированного произведения. (Да, возникает традиционный вопрос, что же тут нужно считать реставрацией, если дорисованы фрагменты, информация о которых на исходнике полностью утрачена; собственно, в исходной работе этот момент постоянно упоминается.)

В итоге, всё же не “дорисовывание силами ИИ”, а автоматизированная обработка человеком изображения в цифровой форме (фильтры в Python + Photoshop, да) и перенос корректирующего “трафарета” при помощи плёнок – это и есть то, что ускоряет работу, снижая затраты именно в части очень сложного ручного труда реставратора-специалиста. Но в газетном заголовке всё равно “AI-based tool”.

Исходные данные – доступны на Code Ocean.

Если судить по фото и видео, то у потерпевшего катастрофу в Индии Boeing 787-8 Dreamliner (AI171) непосредственно перед столкновением с землей выпущено шасси, но практически полностью убраны закрылки – и это ещё в процессе набора высоты, сразу после отрыва. То есть, похоже, что это продолжение странных историй с автоматическими системами управления суперсовременными “Боингами”.

В прошлом году, например, я написал на dxdt.ru буквально следующее:

Заметьте, впрочем, что так как задействованный математический аппарат квантовой механики манипулирует комплексными числами – или, что эквивалентно, синусами и косинусами, – то все открытые тексты и решения можно уместить в пространстве состояний одного “непрерывного” кубита. Континуум, свернувшийся окружностью за привычным синусом, позволяет это легко проделать. Ещё и места останется, как минимум, в два раза больше, чем займут все решения всех проблем со всеми возможными шифрами в степени всех ключей. Это, впрочем, другая история.

Это лирическое отступление из заметки о том, как именно взламывались бы байты ключей криптосистем TLS, если бы появился практический квантовый компьютер. Конечно, идея о квантовых вычислениях на “непрерывных” квантовых системах, совсем не новая. Если принять, что континуум реально стоит за кубитами, то для произвольных вычислений достаточно одного кубита – это так. Вот, появляются новые интерпретации данного подхода – например, свежая популярная статья в Quanta Magazine о том, что факторизацию чисел можно выполнять на трёх квантовых осцилляторах и одном кубите (исходный препринт). Есть “небольшая” оговорка: чтобы загнать в континуум осцилляторов нужное количество состояний – потребуется слишком много энергии. Скорее всего – экспоненциально много. Понятно, что если так, то уже и 2^128 микроджоулей является недостижимым значением.

Очень много популярных статей “про квантовую механику” начинаются с дежурной фразы, утверждающей что-то вроде такого: “в квантовой механике – частица находится во многих точках пространства одновременно”. (Есть ещё полностью аналогичный вариант про пребывание во многих состояниях.) Примеры найти нетрудно, свежий есть на сайте Quanta Magazine.

Вообще, это сильно напоминает едва ли не столь же распространённую историю про “пересекающиеся параллельные прямые”: казалось бы, прямые – параллельные, но нет – “пересекаются”, да и всё тут!

Если частица “одновременно находится в нескольких местах”, то что это могло бы означать? Допустим, есть утверждение, что результат попытки измерения координат квантовой частицы может выдать разные значения с разной вероятностью. С одной стороны, все подобные экспериментальные измерения обладают некоторой погрешностью. Поэтому всегда можно ввести распределение верояностей.

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

Естественно, можно считать, что это такое свойство – “размытие” частицы по “пространству”. Но если частица стала “размытым облаком”, то вот это размытое облако – и есть же область пространства, занимаемого частицей. То есть, если задуматься, то даже в такой интерпретации, – очень странной, – частица оказывается ещё более локализованной: вот же, описано, где она, буквально. Ну, хорошо, допустим, “сразу везде”, как и утверждается – экстремальный случай. Но отдельные точки пространства, необходимые для того, чтобы вообще “склеивать объёмы” и что-то сравнивать – как их определить? Точки всё равно оказываются некими наборами координат. И если за координаты принять вещественные числа, то утверждение, обратное к размытию вероятностей результатов измерения, опять перестаёт работать: практически невозможно попасть ни в какую заранее выбранную точку.

То есть, буквально, называете координаты точки, – например, (√2, π), – и всё – результат измерений “на приборах” всегда будет другим (потому что нельзя записать в десятичных дробях ни одну координату, ни вторую). А значит, частицу не удалось локализовать в достаточной мере, она осталась столь же “размытым облаком” – и где тогда проводить границу, по какому объёму? Если же сделать координаты дискретными, то необходимость “копирования частицы” по всем экспериментально мыслимым “кубикам” тут же исчезает вовсе, поскольку не только само вычисление вероятности не требует занятия всех возможных “кубиков” копиями частицы, но это не нужно и для непосредственного дискретного измерения.

Кстати, вот тут-то, конечно, сразу возникает и работает контраргумент Бернштейна к невозможности создания квантовых компьютеров, который про битовые строки: буквально – для вычислений над 1000-битными числами не обязательно все их хранить в памяти компьютера. Поэтому для вычисления значений функции, задающей вероятность результатов измерений координат в последовательных экспериментах, не нужно, чтобы частица была сразу во всех точках вычисляемого пространства. Зато вот если бы было нужно, то это тоже оказалось бы полезным. Вот только вряд ли об этом можно было бы узнать, поскольку такой расклад запретил бы не только обычные, но и квантовые компьютеры.

Посудите сами – все точки пространства забиты всеми возможными частицами за все возможные периоды времени и за все возможные эксперименты. Что это за пространство такое? Откуда оно берётся? Да, можно вспомнить про исходный огромный топос, сечение которого и есть наблюдаемый расклад окружающей действительности, но тогда в топос входит и, не менее обобщённое, пространство. Так что это не спасает утверждение про квантовую частицу, “пребывающую сразу во многих точках пространства”. Да и суждений таких, про топос, в научпоп-статьях упомянутого типа “про кванты” что-то не встречается.

Это, впрочем, не отменяет более общего рассуждения про потоки “квантовых” вероятностей, нужные для работы того же алгоритма Шора: эти вероятности, предположим, таки должны быть где-то распределены до того, как проводится измерение, в отличие от обработки тысячи битов на классическом компьютере. Но никакой необходимости одновременного пребывания потенциально локализуемой частицы во множестве точек пространства – нет и здесь.