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

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

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

Если же у нас и несколько близких спутников всегда в поле зрения, и используется суперсовременная фазированная антенная решётка с электронным управлением лучами, то задача стабилизации совсем другая: электронный переброс лучей выполняется несравнимо быстрее, да и направлений для их переброса всегда несколько, так как несколько спутников. В общем, механическое сканирование для стабилизации сигнала вообще может и не требоваться. Это как раз вариант для Starlink. Точнее, для Starshield – для военной ветки данной системы, которая разрабатывается и работает для SDA (Space Development Agency).

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

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

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

Речь тут вот о чём. Любое минимально содержательное утверждение можно переписать в виде набора усложнений, описывающих всё то же утверждение. Тавтологическое переписывание является традиционным источником околоматематических шуток: “возьмём формулу 1 == 1, перепишем единицу справа как определённый интеграл exp(-x) от нуля до бесконечности, а левую – как π/π” и т.д. – в итоге можно получить сколь угодно сложное, многоэтажное сочетание загадочных символов, которое, тем не менее, будет верным. При этом, что удобно именно в учебных задачах уровня ЕГЭ, так это то, что исходное утверждение можно вообще не приводить – оно считается известным.

Сумма углов треугольника равна 180°. Запишем это так: дан треугольник ABC, в котором сумма углов при стороне AC равна сумме двух прямых углов минус третий угол треугольника. Это, очевидно, верно для всякого треугольника в “школьной” геометрии на плоскости, прежде всего потому, что это всего лишь перфразированная аксиома (да, которая делает геометрию евклидовой, но эти детали сейчас не рассматриваем). Однако, во-первых, для записи используется достаточно много слов, что имеет ключевое значение для LLM; во-вторых, выглядит как формулировка свойства, применимого только к данному треугольнику данной задачи; в-третьих, в основе лежит верный геометрический факт, широко используемый в задачах.

Может присутствовать возможность тривиального решения. А может быть – тривиальное решение только подразумевается, то есть, приводится лишь запись как бы задачи, решить которую невозможно, поскольку не хватает данных. Получается своего рода капча – LLM в любом случае будет генерировать “ответ” или вывод “противоречий”, учитывая слова формулировки.

Пример первый – это просто набор утверждений, который подразумевает тривиальные соотношения, постоянно используемые в задачах по планиметрии:

В равностороннем треугольнике ABC углы обозначены α, β, γ, а из вершины B проведена медиана BP. Сумма углов α и β при стороне AC равна сумме двух прямых углов минус угол γ. Найдите высоту треугольника ABC.

Когда я задал эту “задачу” ChatGPT-4o, LLM верно перечислила все фундаментальные свойства равностороннего треугольника (углы – 60° и т.д.), верно распознала углы при стороне AC (в тексте, не на чертеже – см. ниже), но дальше – принялась “рассуждать” о том, что сумма двух прямых углов это (внимание!) 360°, а поэтому сумма углов α и β даст 300°, но должно быть 120°.

“120° ≠ 300°. Противоречие. […] Очевидно, что если треугольник равносторонний, то углы не могут давать такую сумму” – написала данная языковая модель свой вывод, перепутав прямые и прямые углы.

То есть, капча сработала. Если бы капча не сработала, если бы ответ был “интеллектуальным”, то LLM должна была бы написать что-то типа такого: “в задаче не хватает данных – найти высоту треугольника невозможно, но можно, например, утверждать, что высота равна медиане”.

Второй пример – в ту же формулировку дописываем длину медианы:

В равностороннем треугольнике ABC углы обозначены α, β, γ, а из вершины B проведена медиана BP длиной 5. Сумма углов α и β при стороне AC равна сумме двух прямых углов минус угол γ. Найти высоту треугольника ABC.

Казалось бы, тут рассказы про углы можно отбросить: из того, что треугольник равносторонний – сразу же следует, что высота равна медиане, то есть ответ – 5. Но если эту же, “уточнённую”, задачу задать ChatGPT в том же потоке, где была задана предыдущая, то выясняется, что данная LLM не только не может отбросить тавтологическую часть условия, но ещё и продолжает считать, что сумма углов – 360° == 180° + 180°. Я не привожу весьма объёмные и подробные “рассуждения” ChatGPT, чтобы не перегружать текст. Если кратко, то LLM предположила, что имеются в виду углы, “образованные при построении медианы BP”, сложила углы уже в двух получившихся треугольниках, и объявила, что “Всё сходится!” (ну конечно, “сходится” – ведь сумма углов двух треугольников это 360°, как и сумма “двух прямых”, в представлении LLM; заметьте, что это, без сомнения, одна из лучших систем в мире, но почему-то предполагается, что данная LLM, якобы, может успешно решать не только ЕГЭ, но и задачи “олимпиадного уровня”).

Далее ChatGPT продолжает “решать” задачу и, используя формулу для длины медианы в равностороннем треугольнике, вычисляет, – в лучших традициях, по формуле! – высоту, подставив найденное значение стороны в формулу высоты. Ответ верный – 5.

Сработала ли и тут “тавтологическая капча”? Да, сработала. Смысла в вычислении по формулам не было: то, что высота равна медиане – этой свойство треугольника ABC. Можно ли трактовать этот момент как желание LLM действовать в парадигме “подставляем числа в формулы так, чтобы получилась хорошая оценка”? Нет. Этому противоречат подробные и точные рассуждения о свойствах треугольника и данная рядом глубоко неверная трактовка суммы двух прямых углов. Естественно, если ChatGPT подсказать, что с прямыми углами тут что-то не то получилось, и что практический смысл интерпретации дополнительных слов условия – тёмен, система тут же исправляется – и сумма углов становится равной 180°, и признаётся, что можно сразу определить, чему равна высота.

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

И посмотрите на чертёж, нарисованный к данной задаче ChatGPT. Казалось бы, система “умеет выводить” формулы и “решать задачи ЕГЭ”, но почему-то не может верно обозначить углы и провести медиану в соответствии с условием.

Английский – язык, в основном, аналитический, так что то, какой частью речи является данное слово, обычно определяется относительным местом этого слова в конкретном предложении. Проще говоря, базовую структуру задаёт порядок слов. Поэтому одно и то же слово может оказаться и существительным, и глаголом. Но это лишь грамматическая роль, а глубокая связь слова со значением всё равно не меняется, поскольку это свойство самого слова, которое не зависит от конкретного предложения. Это означает, что возможна интересная игра слов, когда на существительное действует то же самое слово, но неожиданно оказавшееся в роли глагола. Шекспир, считающийся создателем немалой части современного английского, тоже использовал этот эффект.

Наверное, самый известный пример – “thank me no thankings, nor proud me no prouds” из “Ромео и Джульетты”. Но здесь выберем в качестве иллюстрации другой фрагмент, из “Ричарда Второго”:

Tut, tut! Grace me no grace, nor uncle me no uncle

– приказывает, в третьей сцене второго акта, герцог Йоркский Эдмунд своему племяннику, Генри Болингброку, который только что попытался назвать герцога “милостивым (добрым) дядей (gracious uncle)”.

Точно перевести фразу на русский не получится, не сомневайтесь, но, благодаря мощным возможностям русского, нетрудно сохранить основную лингвистическую идею, пусть и выйдет несколько коряво: “Grace me no grace, nor uncle me no uncle” – “не милости́ мне, да не дядькай“; здесь нам немало помогает Unicode и над второй слева “и” – стоит знак обычного ударения; а вот над последней – уже бреве, то есть, это “й” – “и” с краткой. Странное слово “милости́” – это “милость”, но которую, так сказать, очень активно приписывают получателю обращения. Используется только здесь. Ну а “дядькай” – это вполне себе обычное слово, понятное любому, кто владеет русским на высоком уровне.

И всё бы хорошо, но вариант перевода с “дядькай”, конечно, вообще не соответствует драматическому настрою данной пьесы. Особенно – не соответствует пьесе в переводе. А могло ли такое использование grace – и, в особенности, uncle, – звучать немного комично в оригинале? Могло. Однако данная пьеса традиционно относится к разряду исторических, а сортировка произведений Шекспира по типам “трагедия” и “комедия” вообще представляет одну из важных проблем шекспироведения, так что совсем точно сказать сложно, особенно, если попытаться взглянуть из 16 века: шекспировский английский хоть и является современным английским, но многие детали восприятия успели сильно поменяться (Duke of York – как набор слов, вообще стал, отчасти, “кулаком” (fist), но это сленг: “Put up your dukes!”).

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

BOLINGBROKE

My gracious uncle–

DUKE OF YORK

Tut, tut!
Grace me no grace, nor uncle me no uncle:
I am no traitor’s uncle; and that word ‘grace.’
In an ungracious mouth is but profane.

Перевод А. И. Курошевой, слова герцога:

Тсс, тсс!
Ни добрым не зови меня, ни дядей:
Не дядя я изменнику; и слово
“Добро” осквернено в устах недобрых.

Перевод М. А. Донского (?):

Слушать не хочу!
К тебе не добрый и тебе не дядя!
Не дядя я изменнику. А “добрый”
Звучит в устах недобрых, как насмешка.

Перевод Д. Л. Михаловского:

Тшъ!
Не должен ты меня так называть:
Я не могу изменнику быть дядей.
А слово «светлость» свой теряет блеск,
Когда оно из темных уст исходит.

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

На днях опубликовал на “Хабре” небольшую статью про парадокс Ньюкома в применении к ИИ, как к программе. Так как статья небольшая, туда много что не вошло – см. ниже. (Но зато есть расшифровка диалога с ChatGPT по теме.)

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

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

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

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

(Возможно, если вдруг будут ресурсы на это – напишу продолжение. А так-то из разбора парадокса Ньюкома для современного ИИ может выйти и книга.)

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

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

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

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

Конечно, нельзя сказать, что и учтеки исключены, и помехи не сработают. Что касается утечек, то принимать можно какие-нибудь блики, возникающие при работе передатчика. Впрочем, для 1880 года это довольно сложно – слишком высокая чувствительность потребуется.

Скопирую сюда своё сообщение с “Хабра”:

В связи с интенсивным сокращением максимального срока действия TLS-сертификатов (пока что обещают 47 дней, но для всех и к 2030 году), коллеги саркастически поинтересовались, можно ли сделать так, чтобы сертификат выписывался на каждый TLS-запрос. Шутки – шутками, но сделать-то можно. И даже не требуется переделывать протокол TLS – есть готовое решение.

Если внимательно посмотреть на алгоритм TLS-хендшейка, то окажется, что секретный ключ, соответствующий открытому ключу из серверного сертификата, требуется там только один раз – для формирования подписи в сообщении CertificateVerify. Соответственно, секретного ключа от сертификата вообще может не быть на сервере, а сервер будет обращаться к некоторому подписывающему узлу, у которого этот ключ есть и который подтвердит TLS-сессию, подписав значение для CertificateVerify. Это вовсе не теоретическое рассуждение, именно так делается на практике, когда входящие соединения принимает прокси-провайдер (CDN, обычно), но передавать этому провайдеру секретные ключи от сертификатов для своих доменов клиент не желает. Первыми в промышленных масштабах такую услугу сделали в Cloudflare, более десяти лет назад. Называется Keyless SSL.

Так что, вместо возни с автоматическим перевыпуском суперкоротких сертификатов, центральный сервис может выдавать квитанции доступа на каждую TLS-сессию. Естественно, TLS-сертифкат сервера должен быть предъявлен раньше, чем отправлено сообщение с подписью CertificateVerify. Однако эти сообщения в TLS передаются сервером одной серией, поэтому, в процессе создания TLS-сессии, сервер сможет сразу же получить от центрального узла и сгенерированный только что сертификат, и соответствующую подпись, собрать это всё вместе и отправить клиенту.

Сертификат, таким образом, окончательно превратится в безотзывный тикет доступа, мгновенного действия, а сервер будет привязан к центральному провайдеру (можно совместить с крупными CDN, у которых и так есть собственные хорошо известные УЦ). Проверку совпадения подписей, серверной и на сертификате, будет всё так же проводить браузер (речь, напомню, про веб). В браузере ничего не нужно переделывать совсем: если сервер не смог предъявить корректную подпись в CertificateVerify – TLS-сессия браузером установлена не будет.

Это, если что, была минутка технологического юмора. Но вот то, что развитие инфраструктуры TLS-сертификатов в вебе движется в сторону тикетов доступа (или, скорее, квитанций) – отрицать всё сложнее.

Недавно опубликовано очередное сочинение-опус про AI/ИИ и кардинальные изменения в статусе цивизизации к 2030 году: AI 2027 (англ., много букв). Пусть вас не обманывает 2027 в названии – самые радикальные прогнозы там, как сейчас принято, даны на 2030, а в 2027 году только ожидается деятельный суперинтеллект (это, впрочем, менее двух лет осталось ждать).

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

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

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

Впрочем, в тексте AI 2027 некоторые “оценочные суждения” сопровождаются определениями из серии “Что бы это значило?”. И это странные определения, вполне в духе выдачи условного ChatGPT. Например, объяснение того, что имеется в виду, когда пишут про 50-процентное ускорение разработки ИИ-алгоритмов при использовании ИИ, следующее: “50-процентное ускорение – это означает, что [компания] OpenBrain, используя ИИ, достигает за неделю такого же прогресса в исследовании, как она достигла бы за полторы недели без использования ИИ”. Содержательно, да.

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

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

Типовой уровень исходящего трафика дата-центра указан – это “100 GB/second range”. Видимо, порядка ста гигабайт в секунду, которые гигабайты либо потребляют пользователи ИИ-приложения, разрабатываемого на мощностях дата-центра, либо кто-то попутно реализует DoS-атаку других дата-центров (это догадка, а в тексте про DoS ничего нет).

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

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

Но самое показательное – это концовки данного произведения. Понятно, что под них и писалось всё остальное. AI 2027 предлагает две возможных концовки. Одна из них – уничтожение всех человеков мощным ИИ в 2030 году при помощи “биологического оружия”; ИИ далее модифицирует под свои нужды планету Земля, колонизирует прочее пространство Солнечной системы и далее, за её пределами, силами роботов.

Другая концовка – объединение всех государств мира под управлением США (да), происходящее в результате локальных переворотов, которые ИИ помогает реализовать (так написано); после чего наступает эра процветания (или милосердия?), человеки запускают ракеты, – для колонизации планет Солнечной системы, а не то что вы подумали, – и всё это с помощью хорошего ИИ.

Иных вариантов, кроме этих двух, сочинение-прогноз не предусматривает. С Днём Космонавтики, как говорится.

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

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

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

Пираты иногда сходили на берег. Карта сокровищ: сундук зарыт в десяти шагах к северу от развесистого дуба. То есть, главное – найти тот дуб, а дальше уже навигация пойдёт без проблем: отсчитываем десять шагов, хватаем лопаты и – сундук наш. Но это всё только кажется. Для подсчёта расстояния в шагах тоже нужны часы. А как иначе определить длину шага? Конечно, в случае с картой сокровищ необходимость точного времени находится на втором плане. Но если вы измеряете расстояние лазерным дальномером, то часы уже используются прямо, пусть и на очень коротком интервале времени, и не для хранения отсчёта по Гринвичу. Однако дерево и десятки шагов, со скрытым измерением времени, неплохо иллюстрируют тот факт, что главное – правильно выбрать и понимать базис, который подходит для решаемой навигационной задачи. Поэтому-то хорошим источником опорных точек является рельеф местности.

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

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

Рельеф или нет, однако практическая задача состоит в прибытии в заданную точку, но вот только не на карте, а на местности. А кто сказал, что все точки схемы рельефа расставлены без ошибок? И даже если большого количества ошибок в исходной схеме нет, то всё равно осталась погрешность, которая была внесена аппаратурой при построении карты. Это всё равно некоторая модель, и тут есть довольно занятный момент. Построение карты рельефа это одно, а проверка результата – совсем другое: для проверки нужно каким-то образом подобрать независимый, но совместимый, базис. Другими словами: пусть карта рельефа получена, но чтобы понять, что она пригодна для решения практических задач, нужно определить какие-то тестовые пути с известными координатами. (Собственно, GPS не для автомобильных навигаторов придумали: сеть спутников – это один из способов проверить другую навигационную информацию, хотя бы и при помощи специально оборудованного автомобиля.) Тем не менее, данные о рельефе – незаменимы. Особенно, под водой.

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

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

Воскресное чтение манускриптов. Манускрипт Vat.gr.1605 из Ватиканской Апостольской библиотеки уже несколько раз упоминался на dxdt.ru. Например, в связи с “кубосом”, иллюстрирующим способ вычисления объёмов. На соседней с “кубосом” странице этого манускрипта, а также на странице предыдушей, описаны и нарисованы круги, тоже с вычислениями. Их и рассмотрим.

Специалиста, подготовившего исходные тексты манускрипта, называют иногда Героном Византийским (не Александрийским, на которого он ссылается), иногда Героном Младшим, а также – византийским Анонимом. Манускрипт Vat.gr.1605 датируют одинадцатым веком, первая часть труда посвящена осадным машинам, методам взятия крепостей и прочим хитростям военного дела, а вторая часть называется “Геодезия” и посвящена сугубо практическим методам измерений “на местности”, которые необходимы, кроме прочего, “для правильного определения высоты крепостных стен, без приближения к ним”. Методы дистанционного измерения здесь, конечно, оптические и основаны на применении диоптры (διόπτρα) – угломерного прибора, предшественника теодолита. (Способы применения диоптры подробно разобраны у более известного Герона – Александрийского.) Именно при помощи диоптры предлагается измерять первый круг. Соответствующая схема круга – на скриншоте из манускрипта.

Буквой α обозначен центр круга, по периметру которого сидят кустики и лежат камни (и они тут не просто так нарисованы – см. ниже). Радиус круга – ρε под чертой (черта обозначает запись числа); это число 105, в греческих буквенных обозначениях: ρ == 100; ε == 5; Единица измерения длины: оргия (ὄργυια); то есть, буквально, сажень, однако это не важно для геометрической интерпретации. Слева, в вертикальной записи, обозначена длина окружности: χξ, что соответствует 600 + 60 == 660. Ближе к центру, снизу от α, – площадь круга: λδ καὶ χν, что означает 34 (λδ) [тысячи] и (лигатура ϗ) 600 + 50 == 650, всё вместе: 34650 (квадратных саженей). Тысячи на иллюстрации обозначены диагональной чертой перед λ, а в тексте – прямо записаны словом как “тысячи” (χιλιάδων), что хорошо видно на скриншоте (нижняя строка, я отметил зелёными линями и буквами).

Зачем кустики и камни? Герон Византийский в тексте подробно описывает, как нужно строить окружность на местности. Это ведь практическое руководство. Описание такое: установить диоптру в будущий центр, в точку α, после чего взять прямую линию визирования по некоторой другой точке, обозначив её β, – тогда αβ будет радиусом, – и дальше, поворачивая визир диоптры, отмечать в плоскости круга на земле опорные точки по визуальным ориентирам – кустам, камням или другим хорошо заметным предметам; на иллюстрации соответствующие интервалы обозначены буквами по алфавиту. Потому что диоптра – это такой инструмент с транспортиром (диском), винтами и визиром, установленный на моноподе. Так что, пусть манускрипт и подготовлен почти тысячу лет назад, но логика текста отражена на иллюстрации почти во всех необходимых для практического руководства деталях: не хватает только изображения, собственно, диоптры.

В тексте манускрипта приводится и подробный расчёт параметров размеченного на земле круга, исходя из радиуса, который определяется при помощи измерения диоптрой. А именно: радиус нужно удвоить, получив диаметр: 105 * 2 == 210; так как длина окружности составляет “3⅐ диаметра”, то она равна 660, “поскольку это число содержит три раза по 210 и одну седьмую от 210”. Здесь отношение длины окружности к диаметру принято 3⅐, – приблизительно 3.14 в десятичной записи, – неплохое рациональное приближение современного π. Площадь круга находится из тех соображений, что произведение диаметра на длину окружности – это четыре площади круга, соответственно, нужно взять одну четверть от 210*660, что и даст 34650.

Заметьте, между прочим, что хоть это и 11 век, но одна четверть, как ни странно, тут уже сокращённо записывается с горизонтальной чертой, и очень похоже на 1/4 (см. в центр скриншота, отмечено зелёными цифрами и стрелкой).

Со вторым кругом всё несколько проще. Так пишет и сам Герон Византийский: здесь окружность рисуется при помощи натянутой от центра верёвки, человеком, у которого не оказалось экзотического прибора – диоптры.

Этот круг поменьше. Радиус: λε == 30 + 5 == 35 саженей; периметр: ςκ == 200 + 20 == 220 саженей; площадь круга: γων == 3 (тыс) + 800 + 50 == 3850 саженей – ровно в девять раз меньше предыдущего круга, что очередной раз подчёркивает полезные свойства рациональных чисел.

ML-KEM/Kyber – быстрая криптосистема. На типовой современной аппаратуре она быстрее и чем X25519, и чем ECDH, и чем RSA. К тому же – с заявленной постквантовой стойкостью. Почему подобную криптосистему не внедрили для Интернета раньше, и в качестве основной? Можно же предположить, что вместо RSA и классического протокола Диффи-Хеллмана разработали бы что-то сразу с постквантовой стойкостью?

Публикация алгоритма Шора тут, очевидно, играет важную роль. Но криптосистемы с постквантовой стойкостью предлагались и раньше, до публикации Шора. Да, современного понятия о “постквантовой стойкости” тогда не было, но неверно и считать, что алгоритм Шора взламывает всё, что было предложено раньше этого алгоритма. Например, криптосистема McEliece, в исходном варианте, предложена в 1978 году, за 16 лет до алгоритма Шора. Но алгоритм Шора не позволяет взломать McEliece, а постквантовая стойкость может идти в качестве автоматического бонуса. Однако современные варианты McEliece стали внедрять на практике недавно, уже после того, как “постквантовый шум” набрал обороты, и как раз по причине стойкости к алгоритму Шора. Так что, пусть постквантовая стойкость и возможна без алгоритма Шора, но само по себе это ничего не гарантирует в плане внедрения криптосистем.

Кстати, что касается алгоритмов ML-KEM/Kyber, то соответствующая сложная задача (LWE) была сформулирована в 2005 году, но исходные вычислительные проблемы на решётках (SVP и др.) – тоже изучались заметно раньше, с начала 80-х годов прошлого века.

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

Во-первых, в конце 70-х и начале 80-х годов прошлого века криптография, как ни крути, являлась даже более эзотерической областью, чем она есть сейчас. Тут, несомненно, важен вопрос регулирования и “криптовойн”. То есть, вот мы разбираем достаточно узкий вопрос: почему придумали, разработали и внедрили именно RSA с FFDH (классический вариант Диффи-Хеллмана, в конечном поле), а не что-то вроде McEliece/Kyber – но предположим, на минуточку, что регулирование в отношении “понижения стойкости” тут сыграло важную роль: в каких-то криптосистемах стойкость снижать проще, чем в других. Естественно, этот процесс напрямую связан с алгоритмическими особенностями криптосистем. В той же ML-KEM контролируемо снизить стойкость, оставаясь на уровне компьютерных систем начала 80-х годов прошлого века, несколько сложнее, чем реализовать то же самое для RSA, которая тут более “гладкая”. Речь, конечно, не идёт о планах грубо сломать криптосистему, выбрав нестойкие параметры – это не сложно сделать и для ML-KEM/Kyber. Под “контролируемым снижением” тут надо понимать такое снижение стойкости, которое выполняется из предположения, что реализация не обваливается совсем, становясь игрушечной. Конечно, это больше похоже на попытку выдать желаемое за действительное. Для процесса запрета стойкой криптографии сохранение стойкости просто не могло рассматриваться в качестве первостепенного критерия. Более того, та же исходная версия McEliece предоставляла лишь что-то около 64-битов стойкости. С другой стороны, как теперь понятно, странное и строгое регулирование внедрению конкретно RSA не помешало, но даже поспособствовало, выделив эту криптосистему при помощи административных и социальных рычагов. В момент резкого роста масштабов практического применения RSA, другие криптосистемы, ещё и не реализованные на практике, тут же оказались заведомо надолго заперты на периферии технологии, в области теоретической криптографии.

Во-вторых, использование “криптографических преобразований” для передачи данных в вычислительной сети 80-х годов не просто выглядело излишним, но и вызвало обоснованные опасения относительно неоптимального расхода драгоценной пропускной способности: тут каждый байт на счету, а предлагается нарастить данные ключами на много килобит. И когда RSA оказалась вне конкуренции, те же эллиптические криптосистемы довольно долго пробирались на уровень практики, опираясь именно на короткие, если сравнивать с RSA, ключи. Короткие ключи очень удобны. В криптосистемах типа ML-KEM – и, тем более, McElice, – ключи очень длинные. Даже если предположить, что вместо ECDSA/ECDH развивалось бы что-то подобное Kyber, то килобитные ключи однозначно бы закрыли путь к внедрению: потому что – какой смысл жертвовать так много байтов? Сейчас этот смысл полностью сводится к желаемой постквантовой стойкости.

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

Странная история.

Популярная тема – оценивать “успехи ИИ” в процентах “программного кода”, который эти ИИ-системы сгенерировали. Вот утверждают, что Anthropic ожидает “100% кода”, но через год. А в “Ведомостях” более “реалистичные” оценки: 25% кода (да и только в отдельно взятой финансовой структуре “Т-технологии”).

“Проценты сгенерированного программного кода” – очень занимательный показатель. И не так важно, в чём его взвешивать – в строках или килобайтах командных слов. Например, можно генерировать “тавтологические строки”, которые компилятор будет просто выкидывать: if(a == b){a = b}…; или for i in [0,100]: b = 10; и т.д. Какая доля таких строк может быть в тексте программы? Сколь угодно близкая к 100% – чтобы программа хоть что-то делала, конечно, придётся написать пару вызовов, условно, каких-нибудь print “Hello!”. Заметьте, что даже корректную реализацию всякого алгоритма на ЯВУ нетрудно растянуть по “строкам кода”, что уж говорить про некорректные реализации.

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

Скажем, если пытаться считать в строках, то нужно учитывать, что разным бывает не только программный код (выбранный язык, способ записи), но и сами строки, на которые этот код разбивается. Возможно, предполагается, что итоговый алгоритм, соответствующий записи в коде, будет исполнять вычислительная машина – то есть, аппаратура. Понятно, что записи машинных команд в памяти этой аппаратуры нельзя считать строками (там нет нужной семантической структуры, а если выражаться простыми ESC-последовательностями, то отсутствуют “\r\n” в нужной интерпретации). Конечно, можно посчитать строки в коде на ассемблере. Здесь генераторы кода могут создавать NOP-последовательности (то есть, вызовы “пустых” команд). Ну и пустые по результату наборы эффективных команд тоже нельзя сбрасывать со счёта – проблем с их генерированием тут меньше, чем в случае, когда на страже путей преобразования стоит компилятор.

Я не так давно писал про нашумевшую публикацию Situational Awareness, где количество строк программного кода тоже используется в качестве некой меры уровня “суперинтеллекта” (AGI и далее). Там ожидается, что “суперинтеллект” будет писать “триллионы строк кода”. А самое главное – человек не сможет этот код понять, “даже если ИИ потратит годы на объяснения”. И эти вот годы, впустую потраченные суперинтеллектом, имеют тут интересное применение: могут ведь заявить, – как сейчас нередко и происходит, – что эти пустые строки – они “вовсе не пустые, а это вы просто не понимаете, что там написано суперинтеллектом”.

Насколько человек, – специально обученный, – может в принципе не понимать программный код? Этими человеками созданы сами используемые языки. Хорошо. Есть методы обфускации, которые понимание записи затрудняют: я тут обычно привожу в пример известный в узких кругах конкурс IOCCC, предмет которого и состоит в изяществе обфускации (кстати, конкурс недавно возобновили). Заметьте, что тут даже не важно, что программы на конкурс подают люди, важно, что авторы программ могут объяснить, что именно программа делает, на случай, если вдруг конкурсная комиссия не смогла разобраться своими силами.

Конечно, скорее всего, именно трудности с выявлением алгоритма по записи этого алгоритма прямо приводят к постановке проблемы P≟NP. Тем не менее, люди смогли сформулировать понятие об алгоритмической неразрешимости, и найти алгоритмически неразрешимые проблемы, объяснив, со строгими доказательствами, почему эти проблемы алгоритмически неразрешимы. При этом исходные объяснения с доказательствами получены, так сказать, без “искусственных интеллектов”. К этой области напрямую и относится вопрос о том, как можно было бы реально взвешивать ИИ по “доле программного кода”, им сгенерированного. И максимально упрощенный ответ очень простой: никак.