У нас есть для вас пакет! Как LLM придумывают несуществующие зависимости

Что произойдет, если большая языковая модель (LLM) добавит в код пакет, которого никогда не существовало? Разработчик может принять рекомендацию за корректную, а злоумышленник – опубликовать под придуманным именем вредоносный пакет. Тогда ошибка ^[1] модели превращается в возможность атаки на цепочку поставки.

Перед вами обзор исследования We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs ^[2]. Авторы проверили 16 моделей, сгенерировали 576 000 образцов кода на Python и JavaScript и изучили, как часто в ответах появляются несуществующие пакеты.  Их работу отметили наградой “Distinguished Paper Award” на конференции USENIX Security 2025. 

Оригинальная статья занимает 15 страниц без учета библиографии и подробно описывает предыдущие исследования, устройство эксперимента и статистические результаты. Мы сохранили основные детали методики, наиболее важные выводы и проверенные авторами способы снизить риск. При этом важно учитывать возраст данных. Модели отбирались по состоянию на 20 января 2024 года, а списки пакетов PyPI и npm были получены 10 января 2024 года. Исследование показывает свойства проверенных систем в заданных условиях, но его цифры не стоит автоматически переносить на современные модели.

Несмотря на заметный прогресс моделей за последний год, проблема слопсквоттинга не ушла. Наиболее распространенные механизмы подобных галлюцинаций остаются неизменными: модель переносит библиотеки между экосистемами, достраивает ожидаемые названия по аналогии с существующими проектами, использует устаревшие имена пакетов и комбинирует несколько реальных зависимостей в одну вымышленную. Поскольку эти фундаментальные паттерны поведения ^[3] сохраняются, устойчивого тренда на снижение риска пока не наблюдается.

LLM не является доверенным источником имен зависимостей. Любое предложенное ею имя должно проходить ту же процедуру проверки, что и любая новая внешняя зависимость

Игорь Петров, директор по перспективным разработкам CodeScoring

Новый вариант подмены пакетов

Написание программ на популярных языках программирования, включая Python и JavaScript, во многом зависит от централизованных реестров с открытым программным обеспечением. Одновременно разработчики все чаще используют большие языковые модели для генерации кода. Сочетание этих двух факторов создало новую угрозу для цепочки поставки – галлюцинации в названиях пакетов.

Галлюцинация в названии рекомендуемого пакета возникает, когда LLM генерирует код c использованием пакета, которого в действительности не существует. Злоумышленник может найти повторяющееся вымышленное имя и опубликовать под ним пакет с вредоносным кодом. Если модель снова порекомендует это имя, доверяющий ей пользователь установит уже настоящий, но созданный злоумышленником пакет. Компрометация может распространиться дальше по кодовой базе или дереву зависимостей. 

Такой вид атаки на цепочку поставки уже получил название slopsquatting ^[4], по аналогии с typosquatting. Однако здесь злоумышленнику не обязательно придумывать опечатку в названии популярной библиотеки или угадывать имя внутренней зависимости. Подходящее имя предлагает сама модель.

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

Предыдущие эксперименты уже показывали практическую осуществимость такой атаки. Исследователь публиковал пакет под именем ^[5], которое придумала модель, после чего тот получал реальные загрузки и попадал в зависимости других проектов. Но распространенность галлюцинаций, их свойства и эффективность возможных мер защиты оставались изучены недостаточно.

Моделирование угрозы

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

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

Для атаки особенно ценны названия, которые модель выдает повторно. Если одна и та же рекомендация появляется у других пользователей, опубликованный пакет может быть установлен вместе со сгенерированным кодом. Для Python и JavaScript этот сценарий опасен еще и потому, что установка пакета способна запустить произвольный код на машине пользователя.

Как проводилось исследование

Авторы сформировали два набора заданий ^[6]. Первый основан на вопросах Stack Overflow. Они выбрали 240 тематических тэгов, связанных с Python и JavaScript, и взяли по 20 наиболее популярных вопросов для каждой. Чтобы проверить влияние свежести данных, вопросы разделили на опубликованные до 2023 года и появившиеся в 2023 году.

Второй набор строился на описаниях популярных пакетов. Исследователи собрали данные о 5 000 наиболее загружаемых пакетов из каждого реестра, PyPI и npm, а затем попросили Llama 2 70B создать на их основе задания для генерации кода. В итоге эксперимент охватывал как реальные вопросы разработчиков, так и задачи, связанные с широким набором библиотек.

В проверку вошли 16 коммерческих и открытых моделей, среди которых GPT-3.5, GPT-4, GPT-4 Turbo, несколько версий CodeLlama и DeepSeek Coder, а также Magicoder, WizardCoder, Mistral, Mixtral и OpenChat. Четырнадцать моделей генерировали код на обоих языках, еще две специализированные модели проверялись только на Python. Всего было получено 576 000 образцов кода.

Извлечь название пакета из фрагмента кода сложнее, чем найти все выражения import или require: они указывают на модули, а имя устанавливаемого пакета может отличаться. Поэтому авторы использовали три способа:

1. Искали в ответах явные команды pip install и npm install.

2. Передавали сгенерированный код той же модели и просили перечислить пакеты, необходимые для его запуска.

3. Повторно передавали исходное задание и просили назвать пакеты, которые понадобятся для решения.

Полученные имена сравнивались с полными списками PyPI и npm. Если имени в соответствующем реестре не было, его считали галлюцинацией.

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

Насколько часто модели придумывали пакеты

В 576 000 образцах кода модели рекомендовали пакеты 2,23 млн раз. Исследователи классифицировали 440 445 рекомендаций, или 19,7%, как галлюцинации. В них встретилось 205 474 уникальных несуществующих имени.

Средняя доля галлюцинаций у коммерческих моделей составила не менее 5,2%, у открытых – 21,7%. В рамках этого эксперимента коммерческие модели ошибались примерно в четыре раза реже. Минимальный результат показала GPT-4 Turbo с 3,59%, а лучший показатель среди открытых моделей был у DeepSeek 1B – 13,63%.

Различались и языки. При генерации кода на Python доля галлюцинаций в среднем составила 15,8%, на JavaScript – 21,3%. При этом результаты моделей для двух языков коррелировали: если модель чаще придумывала пакеты Python, она, как правило, чаще делала то же самое и для JavaScript.

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

Настройки генерации, новизна запросов и повторяемость галлюцинаций

Температура – это параметр, который влияет на вариативность ответа модели. При низком значении она чаще выбирает наиболее вероятное продолжение, а при высоком рассматривает больше альтернатив, поэтому ответы становятся разнообразными и менее предсказуемыми. В эксперименте вместе с температурой росла и доля вымышленных пакетов.

Снижение температуры уменьшало риск, но не устраняло его. Авторы также меняли параметры выбора токенов top-p, top-k и min-p. В среднем эти эксперименты не улучшали результат и даже увеличили долю галлюцинаций на 1,16%. Значит, проблема не сводится к случайному выбору маловероятного токена при генерации.

На свежих темах модели ошибались чаще. Все 16 моделей, проверенных на Python, показали более высокую долю галлюцинаций для вопросов и пакетов, ставших популярными в течение последнего года. В среднем прирост составил 10%. Авторы связывают это с тем, что сведения о новых библиотеках и задачах могли не попасть в обучающие данные.

Отдельный эксперимент проверял, повторит ли модель уже придуманное имя. Исследователи выбрали 500 запросов, ранее вызвавших галлюцинацию, и отправили каждый из них еще десять раз. Результат оказался полярным: в 43% случаев модель повторяла исходное вымышленное имя во всех десяти ответах, а в 39% не повторила его ни разу. В общей сложности 58% галлюцинаций возникали повторно хотя бы в двух из десяти попыток.

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

Модель часто узнает собственную ошибку

Исследователи также проверили, способны ли модели отличить настоящие пакеты от вымышленных. Каждой задавали прямой вопрос: существует ли пакет с указанным именем? Проверялись как собственные рекомендации модели, так и ответы других систем.

Три из четырех выбранных моделей – GPT-4 Turbo, GPT-3.5 и DeepSeek – распознавали собственные галлюцинации с точностью выше 75%. CodeLlama заметно чаще объявляла пакеты настоящими и хуже обнаруживала вымышленные имена.

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

Галлюцинации оказались тесно связаны с конкретной моделью. 81% уникальных вымышленных имен встретились только у одной из 16 систем. Получается необычное сочетание: внутри одной модели имя может устойчиво повторяться, но другие модели обычно его не воспроизводят. Даже разные версии одной группы часто придумывали разные пакеты.

Почему дело не в опечатках

Можно предположить, что вымышленные названия возникают как небольшие искажения имен реальных библиотек. Чтобы проверить это, авторы вычислили расстояние Левенштейна между каждым придуманным именем и ближайшим существующим пакетом. Эта метрика показывает, сколько символов нужно добавить, удалить или заменить, чтобы превратить одну строку в другую.

Только 13,4% изученных имен отличались от ближайшего настоящего пакета на один-два символа. Еще 37,9% получили расстояние от трех до пяти. Почти половина, 48,6%, отличалась минимум на шесть символов. Значит, большинство галлюцинаций нельзя объяснить простой опечаткой или перестановкой знаков в известном названии.

Другая гипотеза состояла в том, что модель вспоминает реальные пакеты, удаленные после окончания сбора обучающих данных. Исследователи нашли 12 871 пакет, доступный в PyPI с 2020 по 2022 год, но исчезнувший к январю 2024 года. Среди изученных галлюцинаций только 133 имени относились к таким удаленным пакетам – около 0,17% от анализируемого набора. Этот источник оказался пренебрежимо малым.

Прим. ред. В оригинале рядом указаны 12 871 удаленный пакет, 133 совпадения и доля 0,17%, но последняя рассчитана от 76 489 исследованных галлюцинаций. Если считать долю совпадений среди удаленных пакетов, получится около 1,03%.

Заметнее проявилось смешение экосистем. Среди имен, вымышленных при генерации Python-кода, 6 705, или 8,7%, оказались настоящими пакетами JavaScript из npm. На восемь других реестров вместе пришлось лишь 0,8%. Если разработчик по привычке проверяет только наличие имени в интернете, такое совпадение легко принять за подтверждение корректности рекомендации, хотя пакет относится к другому языку.

Что может помочь снизить число галлюцинаций

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

Авторы проверили три подхода, направленных на сам процесс генерации.

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

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

Дообучение. Из первоначальных экспериментов отобрали 560 000 примеров с настоящими пакетами и использовали их для дополнительного обучения ^[7] моделей. После этого отдельно проверялось, не ухудшилась ли способность генерировать рабочий код.

Методы испытывались на DeepSeek Coder 6.7B и CodeLlama 7B, поэтому результаты нельзя автоматически переносить на остальные модели.

Доля галлюцинаций пакетов

Наибольшее снижение дало дообучение. Для DeepSeek доля галлюцинаций уменьшилась на 83%, а сочетание всех методов – на 85%. У CodeLlama общий результат улучшился на 64%. Самопроверка оказалась полезна для DeepSeek, но почти не изменила результат CodeLlama, которая и в предыдущем эксперименте плохо распознавала вымышленные имена.

У дообучения обнаружилась цена. На тесте HumanEval показатель pass@1 у DeepSeek снизился с 51,4 до 25,3%, а у CodeLlama – с 19,6 до 16,4%. Модели реже придумывали зависимости, но первая из них стала существенно хуже решать задачи по генерации кода. Поиск по базе и самопроверка дали менее резкое улучшение, зато не требовали менять веса модели.

Ограничения и выводы

С момента проведения исследований появились более современные модели. Их склонность к галлюцинациям может отличаться от результатов GPT-4, CodeLlama и DeepSeek Coder, использованных в работе. Кроме того, из-за стоимости эксперимента авторы смогли включить меньше коммерческих моделей, чем открытых. Исследование не устанавливает точную частоту таких ошибок для всех современных помощников и агентов.

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

Авторы не публикуют полный перечень найденных имен и подробные результаты отдельных запросов, поскольку эти данные можно использовать для массовой регистрации пакетов и подготовки атак. Они также отказались самостоятельно регистрировать вымышленные пакеты – такой опыт ^[8] загрязнил бы публичный реестр и мог навредить его пользователям. Код экспериментов, наборы заданий и материалы для воспроизведения результатов ^[9] находятся в открытом доступе.

Проверять рекомендацию LLM только по факту существования пакета недостаточно. Модель может выдать устойчивое вымышленное имя, а злоумышленник может зарегистрировать его раньше, чем разработчик попробует установку. Поэтому зависимость, предложенная моделью или агентом, должна проходить те же проверки источника, возраста, издателя и поведения ^[10] при установке, что и пакет, добавленный человеком.

Полная версия исследования и видеозапись доклада доступны на сайте USENIX ^[2].