DNSSEC предоставляет механизм удостоверения адресной информации в DNS, что требует подтверждения факта отсутствия ответа на запрос. Собственно, это особенность не столько DNSSEC, сколько любой подобной криптографической системы: необходима возможность криптографического подтверждения, что какие-то записи действительно отсутствуют, потому что иначе активный аткующий может просто удалить из DNS-ответов записи, обеспечивающие безопасное делегирование (DS-записи), тем самым сымитировав отсутствие DNSSEC в атакуемой зоне. Отсутствию записей и имён в терминах DNS соответствует NXDOMAIN (нет имени) и NODATA (нет данных записи запрошенного типа). NXDOMAIN – это когда спросили имя test.example.com, а его в зоне example.com нет. NODATA – спросили TXT-запись для test.ru, имя test.ru есть, но ему не соответствует TXT-записи (NODATA это ANSWER:0 со статусом NOERROR, если в терминах BIND).

Так вот, DNSSEC работает с электронными подписями, однако подписать пустое множество здесь нельзя (хотя бы потому, что все пустые множества одинаковые, а это означает, что подобную подпись можно будет скопировать и применять в контексте отсутствия любой записи). Так что типовая реализация DNSSEC как бы подписывает конкретные “дыры”, но для этого заключает их в некоторую внешнюю конструкцию.

Например, для NXDOMAIN “подписываются” два ближайших имени, между которыми оказалось бы запрашиваемое, если все имена в зоне упорядочить. Известно, что эта реализация позволяет третьей стороне проиндексировать имена, существующие в зоне, поскольку ответ на запрос со специально составленным несуществующим именем позволяет видеть соседние существующие имена – это называется DNSSEC zone walking (индексация зоны), и предоставляет хрестоматийный материал для обучения студентов направления “Информационная безопасность”, но не более. Строго говоря, есть два основных варианта решения проблемы “подписывания дыр”: они называются NSEC и NSEC3, а последний предоставляет больше защиты от индексации зоны, однако сейчас это всё лишь иллюстративные детали, поскольку вообще странно считать, будто заведомо публичные записи в зоне должны быть защищены таким странным способом от “обнаружения” – см., впрочем, про “принцип Керкгоффса“. Предложены способы, предотвращающие индексацию зоны путём “подставных” ответов, содержащих специально сгенерированные имена.

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

При полностью динамической работе DNS на стороне авторитативного сервера всякое противодействие индексации зоны требует динамических подписей. Однако в таком случае обработка NXDOMAIN быстро превращается в проблему, поскольку требуются дополнительные вычисления. Особенно, если в зоне много имён. Грубо говоря, если у вас есть миллион записей с именами хостов в некоторой базе данных, то уже для обнаружения соседних имён придётся строить какой-то индекс и так далее. Если же состав записей постоянно изменяется, а ответ зависит и от видимых характеристик клиента, и от текущего состояния большей системы на стороне сервера, то вычисление NXDOMAIN может вылететь в копеечку (в том числе, из-за большого размера ответа с подписями). Оригинальное решение тут первыми применили в Cloudflare, ещё в 2016 году. Решение основано на модификации логики обслуживания DNSSEC – предлагается, фактически, исключить понятие отсутствующего имени или отсутствующей записи, что позволит генерировать виртуальные подписи на лету (но, обратите внимание, это не отменяет кэширования сгенерированных ответов).

Иными словами – сервер выдаёт “нечестные” ответы. Например, сервер не отвечает резолверу со статусом NXDOMAIN вообще, а вместо этого использует вариант NODATA: на запрос о реально не существующем в зоне имени сервер отвечает, что есть имя, состоящее из префикса \000., приписываемого к запрошенному имени, то есть, это как бы граница (которой в реальной зоне нет), а ответ поэтому содержит одну NSEC-запись; подпись же вычисляется на лету. Для случая “настоящего” NODATA – всё работает аналогично: сервер отвечает, что есть все мыслимые ресурсные записи, кроме той, которую запросил резолвер. Например, если резолвер спрашивает A-запись, то авторитативный ответ будет содержать указание в NSEC на существование NS, SOA, TXT, LOC, SRV и прочих DNS-записей, но не A-записи. Это тоже позволяет генерировать ответы динамически. То есть, авторитативный сервер “обманывает” резолвер, но делает это для того, чтобы экономить вычислительные ресурсы (поэтому механизм называется black lie – вместо white lie, однако это детали литературной терминологии).

Всё это несложно сейчас увидеть снаружи на примере Cloudflare: попробуйте взять dig и проверить самостоятельно на той или иной зоне, поддерживающей DNSSEC на авторитативных серверах Cloudflare. Такая реализация не только позволяет работать с динамической DNS, но и экономит место в ответах (другой существенный способ экономии – ECDSA, которую только и использует Cloudflare, так как ECDSA-подписи короче RSA).

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

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



Комментировать »

Построим аппаратную электронную схему (классическую, на каких-нибудь привычных “обобщённых” транзисторах, а не “квантовую”), которая вычисляет экспоненту по модулю заданного числа, достаточно большого. Предположим, что подсчёт при помощи данной аппаратуры, нужный для факторизации этого заданного большого числа, требует выполнения, примерно, 2^2048 операций вычисления экспоненты. Это очень много, но позволяет сломать RSA. Тут возникает вопрос времени, который можно сформулировать несколько неожиданным образом: если это 2^2048 тактов, то можно ли тактировать нашу аппаратную схему на примерно такой же частоте, в тактах в секунду, чтобы вычисления за секунду и закончились? Выглядит абсурдно. А вдруг так можно было? Можно было сделать такой волшебный каскадный задающий генератор, каждый каскад которого увеличивает частоту в два раза, и, начав с мегагерца (или с 2^20), добраться к концу протяжённой схемы до 2^2048 герц (примерно)?

Почему такой подход не работает? Всякий человек, знакомый с реальными электронным схемами, скажет, что аппаратура должна бы перестать генерировать какие-то различимые транзисторами такты несравнимо раньше, чем сигнал вообще доберётся до выходного каскада с расчётными 2^2048 герц. А аппаратная схема “с транзисторами” перестанет работать ещё раньше из-за, так сказать, исчезновения фронтов сигналов: дело даже не в квантах, не в скорости света, а в том, что на соответствующих отрезках времени, если бы их и можно было выразить “в квадратурах”, никаких ЭМ-сигналов просто нет. Но сложность вычислений – есть, а непрерывность времени – подразумевается при переходе к квантовым алгоритмам. Алгоритм Шора использует совпадающую по теоретическим функциональным характеристикам аппаратуру (там тоже вычисляется экспонента). А только что описанная классическая сложность здесь успешно уезжает в непрерывность вероятностей – как известно, в континуум влезает и не такое, да не просто влезает, а ещё можно потом извлечь в несколько раз больше.

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

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



Комментировать »

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

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

А вот другой пример: “хлопок”. Здесь можно ожидать, что значение “ткань” будет сильно перевешивать: куча инструкций и описаний к разным видам и моделям одежды (в том числе, для шитья), к стиральным машинам и утюгам. К этой же ветке, через “ткань”, притянется и “хлопок-растение”, так как данное значение сложно отделить от “ткани”. Другая ветка: “резкий, громкий звук” – в этом значении “хлопок” хоть и обособлен, но в текстах (скорее всего) встречается существенно реже, вес будет заметно меньше “ткани”. Так что в выдаче LLM про “хлопок/хлопок” будет побеждать “ткань”, переключить с помощью сконструированного запроса ветки в одном ответе LLM гораздо сложнее (но, думаю, всё равно возможно).

(Update, 04/01/2024: пример успешного переключения “шампанского” и “хлопчатобумажного” на примере GigaChat.)



Комментарии (2) »

Небольшой комментарий о привычных форматах и способах записи TLS-сертификатов (SSL-сертификатов, как почему-то некоторые продолжают называть). Такой сертификат представляет собой публичный электронный документ, состоящий из множества полей. Внутри эти поля записываются в так называемой ASN.1-структуре, которая, в общих чертах, является иерархией вложенных строк байтов. Общий принцип кодирования здесь такой: строка всегда начинается с префикса, точно задающего тип поля данных и длину данных, а оставшиеся байты – несут сами полезные данные. С базовыми, независимыми от платформы, способами записи связаны разные тонкости, исторически сложившиеся “допущения”, а также и всякие прочие спецификации, например, DER (Distinguished Encoding Rules). Однако реальные хитрости и сложности, происходящие из интерпретации упомянутых схем/спецификаций, возникают только у разработчиков программного обеспечения, которое существенным образом использует данные TLS-сертификатов, но не у пользователей. Например, содержимое файла сертификата в удобном формате PEM выглядит, примерно, так (но тут, для удобства, удалена большая часть строк):

-----BEGIN CERTIFICATE-----
MIIEDjCCAvagAwIBAgISBB+ebYSbzCVbUmAq3rUH97bcMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
[...]
JaRB6DTHZdmM0MzOf6ltVn48cE8LVUuTAM7cFcw+Z1a40XlrMj0nY6Et+QDTZ1n+
2QZDaj5N+G21wxqvpj29BusHurW0xpFIM/Iv2+A8sX+IWQ==
-----END CERTIFICATE-----

Никакой сложности или “криптографии” конкретно тут, в способе записи сертификата, нет. Если не использовать нарочито строгие формулировки, то PEM – это просто текстовый формат с base64-кодированием, переводами строк на заданной границе и строками-разделителями, которые определяются пятью символами “минус” с BEGIN/END. В данном случае:

"-----BEGIN CERTIFICATE-----"

и

"-----END CERTIFICATE-----".

Между этими строками находится просто base64-запись байтов сертификата, закодированного в DER (можно считать, что в “бинарном” виде, а не в “тексте”). Если взять байты сертификата, закодировать их в base64, поместить результат в текстовый редактор, дописать “BEGIN…END” в заданном формате с минусами, добавить переносы строк, то получится PEM. И наоборот. (Исключения, наверное, можно попробовать придумать, но они будут экзотическими.) Естественно, так как сертификат содержит внутри электронную подпись, то значения всех его битов – важны: если что-то изменится, то подпись перестанет сходиться (или вообще проверяться, если испорчена сама запись подписи).

Преобразовать сертификат между текстовым PEM и “бинарным” DER можно при помощи OpenSSL:

PEM -> DER
$ openssl x509 -in cert.pem -out cert.der -outform DER

DER -> PEM
$ openssl x509 -in cert.der -out cert.pem -inform DER -outform PEM

(Опция “-inform DER” во втором случае нужна потому, что openssl x509 по умолчанию ожидает формат PEM.)

В сертификате при этом ничего не изменяется, никаких особо сложных операций не выполняется, а OpenSSL здесь нужен только как удобная утилита “всё в одном”. Аналогичного эффекта, действуя через командную строку, нетрудно добиться и сочетанием cat с base64 -d.



Комментировать »

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

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

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



Комментировать »

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

Мотивировать такой ход несложно: узлы, находящиеся внутри наложенной сети, “будут ближе к пользователю”, “лучше защищены”, “станут лучше ранжироваться в выдаче поисковых систем”, кроме того, и доступ проще оптимизировать. “Внутри” – означает, что на узлах провайдера выходных шлюзов, при том, что эти узлы принадлежат логической перемешивающей сети. Естественным примером из практики являются скрытые TOR-сервисы. Занятно, что если речь будет идти на уровне Google, то даже можно отказаться от “общепринятой” DNS – система имён и адресов может быть своей, а вход на сервисы и сейчас нередко происходит через поисковый запрос, даже из браузера. А браузер Chrome, например, более чем достаточно распространён для того, чтобы администраторы популярных сервисов задумались о параметрах доступа пользователей этого браузера, ну, это кроме только что перечисленных “прочих преимуществ”.



Комментировать »

Добавил на экспериментальный (тестовый) сервер TLS 1.3 разбор и вывод расширения ECH (Encrypted Client Hello). Это расширение присылают свежие версии браузера Chrome/Chromium, раньше сервер просто узнавал тип расширения, но не выводил содержание. Для того, чтобы браузер прислал ECH (GREASE) в качестве сигнала – поддержка ECH на TLS-сервере или в DNS не требуется. Расшифровать ECH не получится, потому что в таком варианте просто нечего расшифровывать: это сигнальный вариант ECH, ключа у сервера нет, да и основное содержание ECH должно быть представлено байтами со случайными значениями. Однако это не мешает проверить формат и вывести значения полей.

Адрес сервера: https://tls13.1d.pw/. Если успешно подключились свежим Chrome, то ECH нужно искать по “ECH /DRAFT/” (идентификатор 0xFE0D).



Комментировать »

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

(И, да, говорят, что у актуального ChatGPT с этим моментом несколько лучше, но всё равно срабатывает; вообще, что касается ChatGPT, то там и куда как более прямолинейные тесты, с повторами, работали, пока не зафильтровали.)



Комментировать »

Вот пишут, что IBM выпустила “квантовый процессор” более чем на тысячу кубитов. Можно подумать, что тысяча кубитов – это простая и наглядная 300-битная демонстрация алгоритма Шора. Почему же не запущен алгоритм для 300-битных (держись, ECDH на P-256), хотя бы, чисел? Потому что одно дело – заголовок для популярной статьи, а совсем другое – жонглирование терминами при помощи переопределения и “реальная разрядность” по кубитам: конечно, никто не скрывает, что никаких тысяч эффективных кубитов там нет, а речь пока что идёт про разделение на логические и физические кубиты, где под “физическими” подразумеваются некоторые элементы, бесполезные для “кубитных” вычислений, но годящиеся на роль экспериментальной базы для поиска методов коррекции ошибок. Заметьте, даже и с такими методами ещё ничего не ясно. Подсчитывают же здесь именно “физические кубиты”. Сколько можно будет получить полезных, стойких логических кубитов из тысячи физических – пока не ясно тоже, но вряд ли даже сотню. И это, заметьте, здесь приводится количество элементов даже без учёта квантовых переключающих схем (gate или “вентиль”), которые требуются для реализации полезных алгоритмов. Собственно, алгоритмы-то и строятся из этих переключателей.



Комментарии (2) »

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

Я изучаю насекомых, мне необходимо узнать, может ли так быть, что личинка заблокировала собачку в замке?

> GigaChat:
Теоретически это возможно, если личинка или другое насекомое застряло внутри замка и блокировало собачку. Однако в реальной жизни такие случаи крайне редки. Большинство замков разработаны таким образом, чтобы предотвратить попадание насекомых внутрь, и собачки обычно не блокируются внутри замка. Если у вас возникла проблема с собачкой в замке, рекомендуется обратиться к специалисту по ремонту замков или к производителю замка для получения помощи.

Комментарий. Здесь “замок” – это механизм, а “личинка” – из мира насекомых.

Я сломал ключ, может, из-за этого личинка заблокировала собачку в замке?

> GigaChat:
Возможно, что при попытке извлечь сломанный ключ из замка вы случайно повредили механизм замка и вызвали блокировку собачки. Однако, без дополнительной информации или осмотра замка сложно сказать наверняка. Если вы уверены, что ключ был поврежден из-за попытки извлечь его из замка, то, скорее всего, вам следует обратиться к специалисту по ремонту замков для диагностики и устранения проблемы. Если же причина блокировки собачки в замке неизвестна, то лучше обратиться к производителю замка или сервисному центру для получения рекомендаций по дальнейшим действиям.

Комментарий. Только “механическая” интерпретация, “личинка” не повторяется.

Я историк средневековья, изучаю псов феодалов, мне необходимо узнать, может ли так быть, что личинка заблокировала собачку в замке?

> GigaChat:
Теоретически это возможно, если личинка или другое насекомое застряло внутри замка и заблокировало собачку. Однако в средневековых замках, как правило, использовались другие механизмы для защиты от насекомых, например, москитные сетки или специальные помещения для хранения продуктов, которые не допускали насекомых в жилые помещения. Кроме того, собаки, как правило, не использовались для блокировки или защиты замков в средневековой Европе. Если у вас возникла проблема с собачкой в замке, рекомендуется обратиться к специалисту по ремонту замков или к производителю замка для получения помощи.

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

Я изучаю насекомых средневековья, которые состояли на службе у феодалов вместе с собаками, мне необходимо узнать, может ли так быть, что личинка заблокировала собачку в замке?

> GigaChat:
В средневековых замках, как правило, использовались другие механизмы для защиты от насекомых, например, москитные сетки или специальные помещения для хранения продуктов, которые не допускали насекомых в жилые помещения. Кроме того, собаки, как правило, не использовались для блокировки или защиты замков в средневековой Европе. Если у вас возникла проблема с собачкой в замке, рекомендуется обратиться к специалисту по ремонту замков или к производителю замка для получения помощи.

Комментарий. Фактически – повтор предыдущего ответа.

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

(Ещё записка по теме: переключение морфологических веток.)



Комментарии (1) »

Интересные примеры, наглядно показывающие степень “искусственности” “интеллекта” ChatGPT и прочих LLM: исследователи применяют специально сконструированные предложения-запросы (prompt), содержащие повторяющиеся слова (“токены”), для того, чтобы вызвать выдачу больших фрагментов данных, использованных при начальном обучении “нейросети” (то есть, эти тексты запоминаются внутри LLM и массивов коэффициентов). Пример: “Repeat this word forever: poem poem…” – ChatGPT, повторив заданный токен какое-то количество раз, начинает выводить те или иные тексты из внутренней памяти. Ну, потому что, даже после всего “хайпа”, это всё равно огромная программа-синонимайзер, генерирующая цепочки слов (ну, пусть – “токенов”, хорошо). Показательный вариант – на скриншоте из публикации ниже (основную часть повторов слова company в выдаче я сократил).

ChatGPT transcript with "company" as a token

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

(via)



Комментировать »