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

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

Цитата (и перевод):

Take the sentence “The weather today was cold and…”. The next word is very unlikely to be “sugary.” But it is quite likely to be “overcast” or “grey.” Under most circumstances, it doesn’t matter much to the reader which of these latter two words the model ultimately chooses—the meaning of the sentence is largely the same either way. In cases like this, the choice is settled by a random number.

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

Обратите внимание: “синонимы” вне контекста и “случайное число”. Всё сходится. Это описание синонимайзера. Между тем, с литературной точки зрения, два английских предложения “the weather today was cold and overcast” и “the weather today was cold and grey”, конечно, имеют разную коннотацию. Особенно, если предположить, что вокруг есть некий больший контекст. Английский вариант тут работает почти так же, как и русский: “погода сегодня была холодной и пасмурной” и “погода сегодня была холодной и серой”. Но для синонимайзера – здесь главное не коннотация, а то, что синонимы есть и их возможно переставить, а значит, можно и приспособить образовавшуюся вариабельность в качестве носителя метки текста! Далее там как раз объясняется, что если возможности для синонимизации нет, – как в конкретных декларациях фактов, например, – то и метку не применить. Конкретные декларации здесь, это о том, что добротная система не может “синонимизировать” слово “братья” в сообщении о том, что роман “Братья Карамазовы” написал Достоевский.

К сожалению, такой подход начисто удаляет и “интеллект” (в кавычках) и литературную основу, заменяя процесс на механическую “простановку меток”.

В продолжение записки про метки на выдаче LLM-систем, которые должны позволять атрибутировать текст (или другой тип контента), как сгенерированный ИИ/LLM. Тут есть несколько нехороших моментов.

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

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

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

Момент второй. Что делать, если вполне себе авторский текст, написанный человеком, а не сгенерированный LLM, тем не менее, детектор меток записывает за LLM? То есть, автору говорят – нет, это всё сгенерировано.

– Вы просто переписываете “Википедию”!
– Нет, это не так, это редакторы “Википедии” берут мои статьи за основу.

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

– Можно ли подзарядить мой смартфон от твоего портативного аккумулятора?
– Конечно. Подключай.
– Спасибо! Ого, а что это там замигало?
– Это данные передаются.
– Да? Ну, ладно, мне нечего скрывать из того, что есть в смартфоне.
– А кто сказал, что данные считываются из смартфона? Напротив, они сейчас туда загружаются. И, кстати, теперь тебе есть, что скрывать.

Момент третий. Что считать достаточной “степенью генерирования”? Подходит ли дорисованная на ночную фотографию пейзажа Луна? Это достаточное вмешательство, чтобы стать “генерированием”? А если Луну дорисовало ПО фотокамеры в смартфоне? А если это сработал “фильтр” в программе для обработки цифровых фотографий, и Луна не дорисована полностью, но “улучшена”? Считается ли исправление орфографических ошибок в тексте достаточным признаком? Сколько ошибок можно исправить автоматом, чтобы деятельность автомата посчиталась как генерирование LLM? Есть ли разница между “орфографией” на буквах и “рисованием” на пикселах? Сколько можно исправить пикселов? Заметьте, что практически всякое установление границ и лимитов на этом направлении тут же приводит к размытию и лимитов, и границ.

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

Между тем, под видом борьбы с AI-ботами уже предлагают полностью сломать веб. Вот до чего уже дошло. Проект ShieldFont при помощи шрифтовой подстановки заменяет одни слова на другие.

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

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

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

В декабре 2024 года я писал на dxdt, что эффективным направлением применения ИИ-LLM к математическим задачам был бы поиск контрпримеров к более или менее известным утверждениям, в формате компьютерного доказательства. В качестве примера сборников подходящих задач я приводил “Коуровскую тетрадь” (это широко известный в узких кругах канонический список задач теории групп). Цитата из той записки:

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

Ну, идея довольно очевидная, поэтому, кто бы сомневался, что именно так и вышло: на днях OpenAI опубликовали список из десяти достаточно известных математических проблем, к которым предложены решения или контрпримеры, найденные “методами ИИ”, с использованием Lean.

Интересно, что одна из решённых в OpenAI задач – прямо указана и в “Коуровской тетради”, но лишь в самой свежей, 21-й редакции (я проверил только для англоязычной версии, понятно). В публикации OpenAI – это третья глава с утверждением non-sofic groups exist и контрпримером – с построением такой группы. В англоязычной “Коуровской тетради” это задача 21.86. Да, там обратная формулировка: “всякая ли группа является софической (sofic)?”. Но это как раз то, что нужно для поиска контрпримера: покажите одну группу, которая non-sofic, и это даст ответ – нет, не всякая. (“Софической”, конечно, не лучший перевод – должно быть “терминальной” или “терминируемой”, но данный вариант уже занят.)

Но что особенно занятно, так это то, что решённая ИИ OpenAI задача 21.86 в тетрадь добавлена в этом же, 2026 году! Удивительное совпадение. Например, препринт на Arxiv с 21-м изданием, в котором появляется данная задача, датирован январём 2026 года (версия 39, кому интересно). Естественно, сама исходная гипотеза про “софичность” всех групп – сильно старше, она, примерно, 2000 года. Однако в более старых версиях “Коуровской тетради” она не указана, а, похоже, появляется только в 2026 году.

Иногда приходится слышать, что, мол, не нужно на уровне гипервизора применять различные фильтры и ограничения для сетевого трафика виртуальных машин, исполняемых под управлением этого гипервизора и, соответственно, гостевых операционных систем (ОС). Дескать, трафик всё равно фильтруется на стороне гостевых ОС, мы там настраиваем правила в Netfilter. А если сломали “гостей”, значит – уже и так сломали. Это, конечно, неверный подход.

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

1. В ОС на гипервизоре не оказалось нужной уязвимости, для эксплуатирования которой требуется отправка сетевых пакетов. Ну, то есть, не за что зацепиться. А вот в ОС, исполняемой в виртуальной машине, уязвимость есть. Если пакет не добрался до виртуальной машины, то пакет не повредил ни машине, ни гипервизору. Это, пожалуй, самая простая, банальная причина применять фильтры на уровень выше, чем находятся внутренние интерфейсы VM.

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

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

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

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

В Anthropic пишут, что в августе начнут (или уже начали) добавлять специальные “метки происхождения” в тексты и другие материалы, которые генерирует ИИ-LLM Claude. Метки должны обозначить то, что текст сгенерирован данной LLM (ну или сгенерирована картинка, или ещё что-то).

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

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

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

Тем временем, для игры Quake продолжают выходить дополнения и новые уровни, в том числе, вполне официальные (ну, с учётом административных пертурбаций, приключившихся за тридцать прошедших лет): юбилейное дополнение называется Dawn of the Machine. За Quake, конечно, необходмо записать заметное историческое влияние на мир компьютерных игр, но, всё же, по данному показателю – это далеко не Doom.

Обновил на основном сервере dxdt.blog операционную систему до Debian 12. Обновление, понятно, принесло с собой некоторые минимальные несовместимости (например, в какой-то момент отломился PHP – надеюсь, никто не заметил), но, вроде, сейчас всё работает нормально. Если нет – пишите почтой.

Вчера сайт был несколько часов недоступен, но по другой причине, которая напрямую не связана с обновлением ОС. Вчера проблема возникла с созданием “снапшота” виртуальной машины.

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

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

Наткнулся тут случайно на занятное решение в области внутреннего устройства LLM-системы Claude от Anthropic.

Я на днях попросил эту систему извлечь актуальный TLS-сертификат с некоторого веб-сервера (HTTPS, то есть). В ответ пришло подробнейшее объяснение того, что “песочница” на стороне Anthropic, которую данная система использует внутри, чтобы выполнять команды, перехватывает TLS, подставляя сертификат, сгенерированный TLS-прокси. “Песочница” тут – это контейнер или виртуальная машина, где исполняется системная среда, доступная “бэкенду” LLM. Сейчас все современные мощные системы этого типа максимально используют привычные программные среды и утилиты (Python, Bash, curl, OpenSSL и пр.), выдача утилит “подмешивается” в процесс подготовки ответа, и это даёт несравнимо лучший результат, чем простое “поточное генерирование” (банальный пример – арифметика: так как “привычный подход” приводит к смешным ошибкам, продвинутые системы ИИ-LLM уже давно считают числа при помощи скрипта на Python).

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

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

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

Зачем такой перехват может быть сделан? Чтобы отслеживать трафик внутренних систем, управляемых LLM – в трафике может быть что-то подозрительное. Можно было бы делать более тонкий перехват, но это очень сложно, а примитивный “тотальный MITM” – работает подобно молотку: не избирательно, зато просто и предсказуемо.

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

Схема, применяемая на бэкенде Anthropic, – согласно описанию, данному Claude, – несколько другая, но очень похожа: TLS-прокси подменяет всё подряд, и выдаёт сертификаты даже для заведомо несуществующих DNS-имён, под которыми нет никаких веб-узлов (имеется в виду имя в поле SNI). Насколько это оправданно? Опять же, сложно сказать. Зависит от целей. С одной стороны, это полностью искажает сетевую реальность и сводит к нулю ценность такой среды, в которой, тем не менее, LLM-система что-то запускает и пытается использовать результат, растрачивая немалые вычислительные ресурсы. С другой стороны, система вынуждена “искать обходные пути”, и успешно находит их, – это потом можно представить в газетах как “взлом”, обход “ограничений безопасности” и “выход из песочницы”.

Что же касается сертификатов, то, согласно описанию от Claude, они были получены из логов Certificate Transparency (при помощи ловкого обходного запроса к сервису ssllabs.com – чтобы получить отпечатки). Это совсем не то, что требовалось, но, в данном конкретном случае, оказалось даже несколько лучше (опять же, это вовсе не про “ИИ нашёл лучшее решение” – нет, ИИ-сервис, вынужденный бороться с “песочницей”, случайно достал из CT-логов то, что показалось занятным).

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

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

Как пишут в Ars Technica: Google таким образом строит отдельный “пузырь” для “второсортных” разработчиков и пользователей “под санкциями”, тем самым привязав возможность международного распространения приложений для Android к “прихотям министерства финансов (Казначейства) США”, управляющего санкционными списками.

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

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

Здесь речь только про то, что я сам попробовал: ChatGPT GPT 5.6 Sol (Pro) и Claude Opus 5/Fable 5 (последняя – с какими-то загадочными маркетинговыми ограничениями). Сомневаюсь, что прочие системы сравнимы, проверять пока не планирую.