Поток ИИ-багрепортов в QEMU назвали DoS-атакой на мейнтейнеров

Нагрузка, которую ИИ-агенты создают для сопровождающих открытых проектов, получила новое определение. Даниэль Берранже (Daniel Berrangé), инженер отдела виртуализации Red Hat, назвал массовый наплыв автоматически сгенерированных багрепортов «атакой типа отказ в обслуживании» на мейнтейнеров.

Поводом стал случай с QEMU. По словам Берранже, один пользователь менее чем за десять минут завёл свыше 125 отдельных багрепортов. Все они касались вывода Undefined Behavior Sanitizer (UBSan) — предупреждений и срабатываний assert'ов, — но не содержали ни одной по-настоящему острой проблемы.

Отчёты без анализа и без правок

Особенно показательно то, чего в этих сообщениях не было. Репорты игнорировали шаблон оформления бага, не несли никаких следов человеческого разбора вывода UBSan и не предлагали ни одного исправления. Иными словами, машина исправно выгружала сырые предупреждения санитайзера, а осмысливать их предлагалось людям на другом конце.

«QEMU столкнулся с тем, что один автор подал более 125 отдельных багрепортов менее чем за десять минут, и все — по выводу ubsan. Отчёты игнорировали шаблон, не показывали никаких признаков человеческого анализа вывода ubsan и не содержали предлагаемого исправления», — написал инженер в Mastodon. Его вывод прямолинеен: «По сути это атака типа отказ в обслуживании на сопровождающих проекта».

Всего за день от пользователя под именами C4oy1zZ / anwardawa981 пришло 132 багрепорта, многие из которых создавались с интервалом в считанные секунды. Аккаунт был пожалован в GitLab как злоупотребление.

Что предлагают делать

Берранже видит очевидное техническое решение: GitLab стоит ограничить число багрепортов, которые может открыть один автор, если он не является участником проекта. Простое ограничение скорости (rate limiting) отсекло бы подобные лавины, не мешая обычным пользователям.

Этот эпизод продолжает череду жалоб сопровождающих на то, как ИИ и большие языковые модели меняют характер их работы. Низкий порог входа для генерации «отчётов» оборачивается тем, что ценность отдельного сообщения падает, а нагрузка на живых людей, которым всё это приходится разбирать, растёт. Автоматизировать создание проблем оказалось куда проще, чем автоматизировать их решение.

Источник: Phoronix