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

Похоже, сроки по “суперинтеллекту” несколько сдвигаются: в свежей колонке лидера 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.)

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

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

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

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

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

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

Пишут, что под Android браузерные скрипты “Метрики” от “Яндекса” и Pixel от Facebook (принцип тот же) идентифицируют посетителя веб-страницы, обмениваясь токенами с собственным приложением на localhost. Приложение, понятно, должно быть “родственным”: либо от Facebook, либо от “Яндекса” (для каждой корпорации – своё).

Механизм: приложение слушает номер порта на localhost, куда браузерный скрипт отправляет данные и получает ответ, идентифицирующий пользователя. Браузеры доступ не блокируют (дефект, по нынешним временам), а решение “Яндекса” использует ещё и технический домен, который с адресом 127.0.0.1 в A-записи – такой вот половинчатый “DNS rebinding” (это, впрочем, не редкость).

Немного странно, конечно, что этот метод авторы вообще обозначают как “novel tracking method” (то есть, “новый, оригинальный метод отслеживания”). Но, очевидно, подобное блокировать должны именно браузеры (у “Яндекса”, впрочем, есть собственная сборка Chrome/Chromium, которая, как пишут, тоже слушает дополнительный номер порта).

(via)

Очередной пример усиленной сегментации этих вот интернетов: пишут, что Google заблокировал в своём удостоверяющем центре всю DNS-зону spb.ru, ссылаясь на штатовские санкционные списки. Это, в частности, приводит к тому, что TLS на “веб-фронте” Cloudflare перестал работать для адресов в spb.ru. Со списками – не очень понятно: официальное объяснение найти пока не удалось, но на форуме Cloudflare пишут, что, возможно, это из-за названия “СПБ Биржи” (SPB Exchange). Если так, то ситуация совсем печальная: мало того, что активно отключают доступ к веб-узлам, используя TLS и “исторически сложившееся” исключительное положение хорошо известных УЦ в браузерах и CDN-провайдерах, так ещё и Google адреса путает.

Разработчик утилиты curl Даниэль Стенберг снова указывает на то, что сообщения об “уязвимостях”, сгенерированные при помощи ИИ/LLM – это очередной вариант DDoS: сообщения выглядят как настоящие, хорошо оформлены, однако не несут никакого полезного смысла и только отнимают существенное время у разработчиков, вынужденных эти сообщения проверять и вести по ним переписку, опять же, с LLM/ИИ в качестве корреспондента; при этом отмечается, что разработчики curl пока не видели ни одного достоверного сообщения об уязвимости, подготовленного с помощью ИИ, при этом поток мусора (“ИИ-помоев”) – увеличивается.

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

Пишут про “проценты редактирования текстов, сгенерированных ИИ”, которые студенты сдают в качестве собственной, студенческой работы:

Согласно опросу ВШЭ среди студентов десяти топовых российских вузов, подавляющее большинство студентов — 82% — перед сдачей перепроверяют тексты, сгенерированные ИИ. Четверть опрошенных респондентов рассказали, что вносят в такие тексты менее 25% правок. Примерно треть респондентов сообщили, что исправляют от 26% до 50% сгенерированного ответа с учебным материалом. Также 17% принявших в опросе студентов уточнили, что переделывали от 51% до 75% текста. Наконец, более 75% правок вносит каждый десятый учащийся, а 17% респондентов затруднились ответить.

К сожалению, не поясняется, что означают утверждения “вносят менее 25% правок” и “исправляют от 26% до 50% […] ответа” (как вообще можно определить процент внесённых правок?), но делается общий вывод, что, мол, это хорошо. Предположим, проценты означают долю слов, заменённых редактором. Как тогда можно интерпретировать эти результаты?

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

С другой стороны, интересно было бы понимать, что же есть цель обучения и постановки учебных заданий, ответом на которые является текст, сгенерированный ИИ. Если цель – получение самого текста преподавателем, тогда, опять же, преподавателю лучше прямо направить запрос в ИИ/LLM. Не нужно плагать, что преподаватели не умеют составлять такие запросы. Умеют. “Как минимум, я написал те книги, на текстах которых эти LLM обучали”.

Если целью является процесс правки текста студентом, то, наверное, имеет смысл в качестве задания выдавать сразу текст, подлежащий правке. (И такое нередко случается на профильных специальностях.) Если цель – процесс отправки запроса в ИИ/LLM студентом, то это тематика для довольно узкого круга специальностей.

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

В начале апреля, в записке про ненадёжное электропитание дата-центров, в которых работают “вычислительные облака”, я написал на dxdt.ru буквально следующее:

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

Не прошло и месяца, как в Испании электрическая сеть практически полностью, по всей стране, отключилась. Очень похоже, что как раз из-за проблем с управлением самой сетью.

То ли ещё будет.

Кстати, в продолжение недавней записки про аварийное отключение дата-центра “Яндекса”. Речь там о потере входного электропитания “сразу по двум линиям”. Вводных линий там было, действительно, две, но обе подключены к одной подстанции. Это всё согласно объяснению от самого “Яндекса” (вообще, сейчас и наличие минимально внятного объяснения-то становится редкостью, но “Яндекс”, – пока что, – рассказал о ситуации достаточно подробно; это большой плюс, конечно).

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

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

Хорошо известный удостоверяющий центр SSL.com выпускал TLS-сертификаты для доменов без проверки права управления. Как пишут, статус “подтверждённого имени” получал всякий домен, на произвольный почтовый адрес в котором пользователь смог получить код подтверждения для любого другого домена. То есть, можно было разместить заказ на TLS-сертификат для example.com, выбрать способ подтверждения с отправкой кода по адресу email, указанному в TXT-записи (и такое бывает), – например, akhmet@test.ru, – подтвердить получение кода, и доменное имя из состава адреса, – то есть, test.ru, – тоже получало статус прошедшего проверку права управления.

Очередное подтверждение того, что проверка права управления (DCV) должна проводиться перед выпуском каждого сертификата, для всех имён, указываемых позже в сертификате, и только для этих имён, но строго после получения соответствующего заказа (и процесс подтверждения должен быть привязан к конкретному заказу и к конкретному ключу из заказа). И, конечно, никаких проверок по email для TLS-сертификатов.

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

Комапния “Яндекс” пишет, что “поиск Яндекса” научился объяснять “решение математических задач из старшей школы”. Конечно, при помощи нейросетей. Цитата:

Например, он [“Поиск”] может рассказать ход решения показательных и несложных тригонометрических уравнений, а также найти предел функции.
[…]
Яндекс обучил её [нейросеть] на одном миллионе примеров заданий для старшеклассников. Это позволило добиться точности ответов в решении задач в 90% случаев.

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

Для условий задач, составленных с ненамеренными ошибками – часто можно точно обнаружить ошибку, тоже системой компьютерной алгебры (но, понятно, не всегда: если условие испортить специально, то можно построить неразрешимый для компьютера случай). И тем не менее, там все символьные операции алгоритмизируются точно, пусть и не самым тривиальным методом. Так что не требуется угадывание описания процесса поиска ответа при помощи синонимайзера, который не так давно утверждал, что “число делится на 2 и на 11, а значит, делится и на 3”. Да ещё и с какой-то точностью ответов – “в 90% случаев”. Конечно, можно сказать, что 10% случаев – это и есть некорректно составленные задачи, но это будет выдумка, потому что тогда система должна была бы сказать, что задача некорректная, а не выводить неверное решение.