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

Популярная тема – оценивать “успехи ИИ” в процентах “программного кода”, который эти ИИ-системы сгенерировали. Вот утверждают, что 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. Тем не менее, люди смогли сформулировать понятие об алгоритмической неразрешимости, и найти алгоритмически неразрешимые проблемы, объяснив, со строгими доказательствами, почему эти проблемы алгоритмически неразрешимы. При этом исходные объяснения с доказательствами получены, так сказать, без “искусственных интеллектов”. К этой области напрямую и относится вопрос о том, как можно было бы реально взвешивать ИИ по “доле программного кода”, им сгенерированного. И максимально упрощенный ответ очень простой: никак.

Адрес записки: https://dxdt.ru/2025/03/14/15178/