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

Google уже некоторое время назад для многих пользователей заменил поисковую выдачу на результаты некоторой системы ИИ (LLM), которая генерирует ответы на запрос, “синонимизируя” собранные в интернетах тексты. Не слишком довольные нововведением пользователи извлекли из новой системы массу неверных, абсурдных ответов. И из Google опубликовали разъяснение, что пользователи не совсем правы. В этом разъяснении, на примере запроса “How many rocks should I eat?” (“Сколько камней мне следует есть?”), объясняют, что причина абсурдных, неверных ответов в том, что, во-первых, это редкий запрос (!), во-вторых – для такого запроса в вебе опубликовано мало релевантных данных (да):

Prior to these screenshots going viral, practically no one asked Google that question. […]

There isn’t much web content that seriously contemplates that question, either. This is what is often called a “data void” or “information gap,” where there’s a limited amount of high quality content about a topic.

(До того, как эти скриншоты [т.е., с ответом ИИ про рекомендуемое к ежедневному поеданию количество камней] стали “вирусными”, практически никто не задавал Google такой вопрос. Кроме того, в вебе не много контента, который серьёзно рассматривает такой вопрос. Это то, что часто называют “лакуной в данных” или “информационным пробелом”, когда имеется ограниченное количество тематического контента высокого качества.)

Казалось бы, “интеллект” – он на то и “интеллект”, – тем более, в сервисе поиска информации, – что должен выдать ответ о наличии тут той самой лакуны (“data void” – называть можно так, или иначе, но смысл один), предупредить, что данные в вебе не позволяют судить о данном вопросе “со всей серьёзностью”. Но нет: ИИ LLM – не для этого.

Docker Hub заблокировал доступ с российских IP-адресов. Последовало множество насмешливых инструкций в стиле “простейшего перехода на зеркала и прокси”. Проблема тут, впрочем, привычная: в практике Docker, в сопутствующих скриптовых обвязках (всякий CI/CD), и так не всё хорошо с аутентификацией источников сборок и самих “контейнеров”. Методы, типа DCT (Docker Content Trust), конечно, есть, это известно. Вопрос в их эффективности и использовании на практике. А прокси и “разбегание” зеркал – тут только добавляют ненадёжных слоёв. Кстати, целевые манипуляции часто удобнее проводить именно с точками выхода прокси и точками входа зеркал (вспомните, как работает разное перемешивание и, скажем, onion routing – тут ситуация обратная).

(Update, 09/06/24: доступ вернули через несколько дней.)

Небольшое техническое сообщение. Предположительно (!) (но вполне вероятно), что в относительно скором времени у меня не будет возможности продлевать регистрацию домена dxdt.ru. Домен этот я зарегистрировал в апреле 2004 года, но с тех пор времена и правила заметно изменились. Я не склонен переоценивать значимость сайта под данным доменом, но знаю, что записки, которые здесь иногда появляются, кто-то всё ещё читает. Поэтому и решил (несколько заранее) опубликовать это сообщение, чтобы, – если что, – не выглядело “внезапным исчезновением”. Отдельно отмечу, что если разделегируется dxdt.ru, то, соответственно, из заметных ресурсов, не будет доступен и tls.dxdt.ru – техническое описание TLS (впрочем, я там обновлений не планирую, так или иначе).

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

NRO (штатовская военно-космическая разведка) продолжает выводить на околоземную орбиту свою специальную часть от более общей программы, связанной со Starlink от SpaceX. В этот запуск отправили, насколько можно понять, несколько десятков аппаратов. Вообще же речь тут про сотни спутников, которые, скорее всего, используют некоторые базовые компоненты, совпадающие со спутниками Starlink, а также разделяют со Starlink, как системой, технологии запуска и управления. Эти спутники выводят на низкую орбиту (от 300 км), так как задумана именно близкая к поверхности, быстрая система, которая позволит эффективно решать задачи разведки новыми способами: много точек наблюдения, обеспечиваемых работающей синхронно однотипной аппаратурой.

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

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

Конечно, нетрудно догадаться, как упомянутый фрагмент был сгенерирован LLM: в интернетах очень много текстов, содержащих обороты вида “число”, “число делится на”, “и на”, “а значит” и т.д., и т.п. Эти же тексты, очень часто, содержат и цифры. Система LLM работает не со словами, а с так называемыми “токенами”, слову может соответствовать несколько токенов (может случиться и наоборот, как ни странно; вообще, способы “токенизации” составляют очень важную часть данной технологии генерирования текстов). Есть токены от “цифр” (записи чисел в тексте), или от склеек букв с цифрами. Токены собираются в цепочки не просто по вероятности, но с добавлением элемента случайности и подмешивания прочих элементов, добавляющих мнимой оригинальности в выдачу генератора текстов. Возвращаемся к исходной фразе: какие-то обороты “про делимость” попали по токенам в выдачу, и тут же затесались посевдослучайным образом какие-то другие токены, выдавшие цифры (1 и 1, 2, 3). Получилась “оригинальная” фраза.

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

Не слишком сложно составить и представление о том, как в генераторах с LLM вообще возникают “оригинальные тексты” – то есть, грамматически корректные сочетания слов, которых не было в исходных корпусах, взятых для “обучения”, – и о том, насколько эти тексты связаны с исходными задачами, равно как и с интеллектом. Рассмотрим условную “обучающую выборку”, которая состоит из следующих текстов (коротких фраз): “лис сел на пень”, “жук сел на сук”, “медведь сел на муравейник”, “заяц проплыл на лодке”, “жук залёг под дерево”, “сом залёг на дно”, “сом проплыл под веслом”. Слова из этой выборки отображаются в токены, а LLM генерирует свои фразы, исходя из предполагаемой вероятности того, что один токен следует за другим, переставляя при этом токены (см. ниже). Вероятности здесь происходят из того, что за словом “сел”, согласно обучающей выборке, с вероятностью единица следует “на”, за словом “жук” – с вероятностью 1/2 следует “сел” и так далее. Вероятности записываются в таблицы, где, в самом примитивном варианте, значение вероятности выбора для следующего токена зависит от предыдущего (этому соответствуют марковские цепи, которые и задаст двумерная таблица).

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

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

То есть, сначала говорилки, построенные на генераторах псевдослучайных цепочек слов, “обучали”. Потом объявили, что говорилки обучились и “успешно сдают экзамены” (ЕГЭ, например; это при том, что такая говорилка не сможет даже найти на столе и заполнить анкету). Видимо, сдавшие экзамены говорилки можно использовать для работы с абитуриентами. А на следующем шаге – уже и непосредственно в процессе обучения обучающихся (“человеков”). Нейросеть с LLM и сейчас способна читать лекцию. Непрерывно. По любому, вообще говоря, предмету, даже по полностью вымышленному.

“В дальнейшем университет планирует использовать сервис YandexGPT API и в других задачах — например, чтобы рекомендовать студентам подтянуть знания по тому или иному предмету на дополнительных курсах или давать советы по темам выпускных квалификационных работ” – написано в тексте новости.

В советском мультике из серии “Простоквашино” (1978 г.) Галчонок, представляющий собой автоматическую говорилку с обучением, смог переключить мышление почтальона Печкина между уровнями осознания, да ещё и в свою, – Галчонка, – пользу. То ли ещё будет.

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

Вообще, нетрудно представить следующую ситуацию. Предположим, есть некоторый диспетчер соединений, работающий в паре с пакетным фильтром. Этот фильтр анализирует пакет данных (то есть, последовательность байтов, имеющую конкретную длину) по заданным правилам на уровне значений байтов внутри пакета и расстояний между байтами с заданными значениями. Например, определяет, что пакет представляет собой начало TLS-соединения с некоторыми свойствами и – перенаправляет этот пакет, как и всю сессию, на какой-то заданный входной узел. Этот узел – уже может быть элементом балансировщика трафика, или входить в состав какого-то механизма DPI, предназначенного для борьбы с возможными атаками, или играть какую-то ещё роль. Базовые правила для фильтра позволяют узнавать заявленные версии TLS (это значения полей в сообщении), определять предлагаемые клиентом криптосистемы – всё по значениям байтов на определённых позициях. Скажем, таким способом можно детектировать начало TLS-сеанса с поддержкой ГОСТ-TLS, со стороны клиента, чтобы на стороне сервиса перенаправить соответствующие сессии на сервер, настроенный конкретно для ГОСТ.

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

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

То есть, для определения IP-адреса test.ru в глобальной DNS производится поиск “документа” по ключу “test.ru” с извлечением из этого “документа” A-записи, в которой содержится IPv4-адрес. A-записи – это малая часть. В DNS хранятся данные многих типов, например: AAAA – адреса IPv6, MX – имена почтовых серверов, SSHFP – отпечатки хост-ключей SSH и др. При этом, хоть A-записи и очень важны для работы самой DNS, они не являются основными. Основные записи, в смысле иерархии, это SOA-записи (определение основных параметров доменной зоны) и NS-записи (определение списка серверов имён).

DNS позволяет выполнять обратное преобразование – IP-адрес в символьное имя. Но для этого всё равно используется схема “ключ-значение”, где в качестве ключа выступает DNS-имя так называемой обратной зоны, которое формируется из октетов (байтовых элементов) IP-адреса. Это имя располагается в технической зоне .ARPA. То есть, никакого “обратного” поиска “ключа” по “значению” – в DNS нет, но есть прямой поиск записей в специально сконструированных обратных зонах по значению имени, взятому в качестве ключа. Пример обратной зоны: 1.1.1.1.in-addr.arpa – соответствует IPv4-адресу 1.1.1.1 (сервис Cloudflare one.one.one.one).

Если обратную зону в DNS не внести, то и определить через DNS соответствие IP-адреса символьному имени только по IP-адресу и штатным способом – не выйдет. (Но, конечно, можно просканировать все доступные доменные зоны по всем доступным ключам (именам) на предмет A-записей и, таким образом, найти имена, соответствующие данному IP в прямой записи; этих имён может быть очень много.)

Поиск записей в DNS производят программы-резолверы, которые опрашивают DNS-серверы в соответствии с иерархией ключей (DNS-имён): так, tls.dxdt.ru – это имя третьего уровня, находящееся внутри dxdt.ru, а dxdt.ru – второго уровня внутри .ru, а ru – первого уровня внутри корневого домена, имя которого состоит из пустой строки и, при использовании полной записи, тоже отделяется точкой справа, вот так: tls.dxdt.ru. – здесь корневой домен идёт после крайней правой точки. Совокупность программ и протоколов, используемых для поиска в DNS, тоже нередко обозначается буквами D, N и S, но здесь S – это сервис (service), то есть, речь уже идёт про сервис доменных имён.

Основой работы DNS как сервиса является кэширование данных на разных уровнях, в основном, кэширование обеспечивают программы-резолверы. Кэширование решает две основных задачи: это исключение излишней нагрузки и сохранение доступности при кратковременных отказах. Для обеспечения работы сервиса, записям, публикуемым в DNS, сопоставляются различные технические параметры, самый важный из них – это TTL (Time To Live), значение которого позволяет определять динамические параметры кэширования.

При штатной работе, DNS действует именно как база данных: из неё извлекаются далеко не только IP-адреса узлов, про которые так часто пишут, но и списки имён серверов, значения ключей и подписей DNSSEC, значения TXT-записей. Так как DNS является в Интернете всеобъемлющей системой, то и DNS-записи, отличные от A- и AAAA-записей, постоянно используются. Так, TXT-записи, позволяющие опубликовать под заданным именем текстовую строку, повсеместно используются для подтверждения тех или иных прав по управлению доменной зоной, например, при выпуске TLS-сертификатов или при публикации “почтовых” ключей DKIM.

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

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

О принципах, на которых работает GPS-спуфинг (или GNSS-спуфинг) – я довольно подробно писал почти восемь лет назад.

На Ars Technica попался занятный краткий обзор научного исследования, посвящённого выяснению того, как использование в заголовках СМИ оборотов типа “учёные полагают”, “учёные думают” (в оригинале – scientists believe, так как исследование об английском языке) влияет на читательскую оценку “достоверности” понятий, упомянутых в том же заголовке. Собственно, противопоставлены там слова “думать/полагать” (believe) и “знать” (know), а абсолютно точно перевести на русский довольно сложно. То есть, предположим, читатели читают заголовки: “Учёные думают, что на Марсе есть вода” и “Учёные знают, что на Марсе есть вода” – влияет ли разница в семантике заголовков на классификацию конкретным читателем утверждения “на Марсе есть вода” как являющегося бесспорным “научным фактом” или как “одного из возможных мнений”? Исходное исследование строится на опросе многих людей-участников, которым предлагали оценить различные варианты заголовков.

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

Тут, несомненно, можно вспомнить различные концепции из области философии науки, как раз касающиеся того, насколько процесс согласования различных мнений эту самую науку определяет. Например, можно даже предположить, что исход “квантовых опытов” определяется тем, как исследователи между собой согласуют интерпретацию результатов. Но к заголовкам СМИ и концепции Believe in Science – это уже не относится.

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

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